Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services

Slides:



Advertisements
Similar presentations
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Advertisements

Chapters 7 & 9 System Scope
Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
Object-Oriented Analysis and Design
Rational Unified Process
Use-case Modeling.
Systems Analysis and Design in a Changing World, Fourth Edition
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Analysis Concepts and Principles
© Copyright Eliyahu Brutman Programming Techniques Course.
SE 555 Software Requirements & Specification Requirements Analysis.
Source: Peter Eeles, Kelli Houston, and Wojtek Kozaczynsky, Building J2EE Applicationa with the Rational Unified Process, Addison Wesley, 2003 Prepared.
Object Oriented Analysis and Design Using the UML
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 /26 RUP Architecture.
Chapter 7: The Object-Oriented Approach to Requirements
USE Case Model.
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
RUP Fundamentals - Instructor Notes
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
Copyright by Dr. Clarence Lau, IVE(TY)
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Business Modeling : basic concepts Extracted from Rational UML Profile for business modeling.mht.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Approaching a Problem Where do we start? How do we proceed?
 A software application is like a city  Modeling = Architecture  OOP = Civil Engineering  UML Classes = Blueprints of Buildings  UML is a common.
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
UML-1 8. Capturing Requirements and Use Case Model.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
1 Chapter 4 Analyzing End-to-End Business Processes.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Requirements Workshop Techniques for E-Business Projects
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Object-Oriented Techniques
Unified Modeling Language
Introduction to Unified Modeling Language (UML)
Enterprise Data Model Enterprise Architecture approach Insights on application for through-life collaboration 2018 – E. Jesson.
Rational Rose 2000 Instructor Notes Use Case Realization Structure
Engineering Quality Software
Software Development Process Using UML Recap
Presentation transcript:

Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services

Practical Business Modeling in the Unified Process Tom Morgan Agenda  Brief Business Modeling introduction  Artifact production in reference implementation  Transformation into Requirements Use-Case Model  Simple steps for Business Rules Model

Practical Business Modeling in the Unified Process Tom Morgan Business Modeling overview  Challenges addressed  How do you know your software directly addresses business issues?  How do you know your use cases are accurate?  What is the big picture, or context, to is being developed?  Small knowledgebase – techniques from various sources  A lot of “feel your way” needed  Different approaches depending on objective  Lifecycle timing  Started in early Inception, peeking near end of Inception, trailing off through Elaboration and Construction phases.  Consists of:  Business Use-Case Model - The “What” (actors, goals, use cases)  Business Analysis Model - The “How” (workers, entities, events, automation)  Business Rules Model - The “Constraints” on the “How” (rules)

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 1: Determine boundaries (or scope) of target business  Main business

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 1: Determine boundaries (or scope) of target business  Main business comprised of one business part

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases  Step 1: Determine boundaries (or scope) of target business  Main business comprised of two business parts (others omitted here)

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 1: Determine boundaries (or scope) of target business  Narrow focus the Box Office

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 1: Determine boundaries of target business  The Box Office is our box, or business boundary  Start outside box with goal to describe inside

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 2: Finding Business Actors  Outside of business boundary – our box  May be inside other business areas, or boxes  Concessions, Accounting, Projection  Identify Roles from real Instances  A Business Actor instance can fill many roles  Avoids confusion when Actors and instances don’t all share common goals

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 2: Finding Business Actors  At this point, consider as candidate Business Actors

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 2: Finding Business Actors  Refine to same abstraction, eliminate redundant and ambiguous candidates

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 2: Finding Business Actors

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 3: Describe All Business Actors  Provide any potentially valuable information

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 4: Finding Business Actor Goals  Identify Goals from Business Actor towards the business  Goals should be at same abstraction level  Start high level and refine from there  Experience helps – you’ll get better

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases  Zeroing in on correct abstraction level Why? How? High Level Low Level

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 4: Finding Business Actor Goals

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 5: Finding Business Goals from Business Actor Goals  Flip the goal and describe from the business perspective,  Describes Business Goal to address Business Actor Goals

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven  Step 6: Find Business Use Cases  Derive Business Use-Case name from Business Goal and Detail attributes  Begin to establish business vocabulary in glossary  A lot in business modeling  Build Diagram and refine

Practical Business Modeling in the Unified Process Tom Morgan Find Business Actors and Use Cases – Goal Driven

Practical Business Modeling in the Unified Process Tom Morgan Initial Survey Diagram Completed

Practical Business Modeling in the Unified Process Tom Morgan Next Activity: Detail a Business Use Case  Write a Business Use-Case Specification for each one in our model  External narrative of business process workflow  Manual perspective without system automation  Major distinction from Use Cases in Requirements  Lessons Learned  Many ways and approaches  Study and practice required  Pick a style as a convention  Focus on content, not format  Just writing brings value (discovery, convergence)

Practical Business Modeling in the Unified Process Tom Morgan Detail a Business Use Case

Practical Business Modeling in the Unified Process Tom Morgan Detail a Business Use Case

Practical Business Modeling in the Unified Process Tom Morgan Refine Business Use-Case Model  Add, remove, modify Business Use Cases, Actors, Goals  Merge and extract use-case flows  Model with extend, include, and specialization associations  Err to merging, but be sensible  Manage your energy/precision level  Err to abstraction until necessary  Transition point to Business Analysis Model

Practical Business Modeling in the Unified Process Tom Morgan Important Opportunities of Business Analysis Model  Traceable to business processes  Early involvement of architects  Core development team playing role to make architecture decisions  Identify automation solutions (both vertical and horizontal)  Components emerge (RUP best practice) and reused  Initiates software engineering through visual models (RUP best practice)  Used to derive Requirements Use-Case Model  Mitigates guesswork and risk  Justifies model

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Step 1: Create Business Use-Case Realization  Associate to the correct Business Use Case  Traceability semantics for artifacts  Same name as Business Use Case

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Step 2: Find Business Workers  First sequence diagram – Work Processes  Modeling Steps  Identify and Describe Business Workers  Assign responsibilities to Business Workers  Transforms use-case narrative to UML  Maps use-case behavior to worker responsibility  Roles and tasks inside our box  Identify who does what

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Step 3: Identify and Describe Business Workers  Consider need for specialist, privileges, experience level, functional activities  Start with real people  Evolve or start with automated workers  Look-ahead: Transformed into Actors in Requirements Model  Describe same as Business Actors

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Step 5: Assign responsibilities to Business Workers  Find proper abstraction level  Consists of a group of activities performed by Worker  Not one event or action  Think of time needed to accomplish –Avoid instantaneous or single action items – abstraction too low –Should take longer  Find good sets of verbs to describe  May need another role to solve ambiguities  State with enough focus to avoid future ambiguities

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Responsibilities may be decomposed by asking “How?”, but not too much

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Capture Alternates using UML Combined Fragments in RSA

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan Next Step: Explore Process Automation  Second sequence diagram – Process Automation  Springboard into Requirements model  Start with copy of Work Processes diagram in RSA  Modeling Steps  Identify responsibilities needing automation in business process  Identify and describe system components used for activities  Re-assign responsibilities  Decompose and refine as necessary

Practical Business Modeling in the Unified Process Tom Morgan Explore Process Automation  Identify responsibilities needing automation  Identify and describe system components (same stereotype as Worker)

Practical Business Modeling in the Unified Process Tom Morgan Explore Process Automation  Re-assign responsibilities (manual tasks remain with Worker)

Practical Business Modeling in the Unified Process Tom Morgan Explore Process Automation  Decompose and refine as necessary

Practical Business Modeling in the Unified Process Tom Morgan Explore Process Automation - Complete

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Step 6: Identify Business Entities – Starts Domain Model  Start with the Automation Processes diagram in RSA  Introduce and describe Business Entities  Identify things handled during activities  Identify who uses what  Redirect message ending to Business Entities  Remove Automation elements

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Add Business Entities to diagram

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Detail a Business Entity  Explain role in business  Describe lifecycle (use statechart when needed)

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Redirect messages – From Worker to Entity

Practical Business Modeling in the Unified Process Tom Morgan Find Business Workers and Entities  Remove Automation Elements

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan Develop a Domain Model  Concepts of business domain  Significant business information and relationships  Try to avoid attributes – refinements made in A&D  Just classes keeps model simple and focus at entity level

Practical Business Modeling in the Unified Process Tom Morgan Develop a Domain Model  Sources  Business Entities in Information Processes diagram  Grammatical analysis of Business Use-Case Specification  Stakeholders and business experts  Other guidelines  As much as necessary – you decide  Update glossary with new terms  Abstraction level focus on things and relationships - Classes level only

Practical Business Modeling in the Unified Process Tom Morgan Develop a Domain Model

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan Where to go next?  Overlapping disciplines = parallel activities Finish Business Modeling Start Requirements AND

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 1 – Focus on a single system lifeline (our new scope boundary)

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 1 – Focus on a single system lifeline (our new scope boundary)

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 2 – Transform messages ending on scope boundary to use cases

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 2 – Transform messages ending on scope boundary to use cases

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 3 – Transform Business Workers to Actors

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 3 – Transform Business Workers to Actors

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 4 – Transform messages affecting scope to > >

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 4 – Transform messages affecting scope to > >

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 5 – Repeat for other system lifelines

Practical Business Modeling in the Unified Process Tom Morgan Deriving the Requirements Use-Case Model  Step 6 – Preserve business process context

Practical Business Modeling in the Unified Process Tom Morgan The Business Rules Model  Step 1 - Identify business rules location in business process workflows

Practical Business Modeling in the Unified Process Tom Morgan The Business Rules Model  Step 2 – Identify high level container for rules Prepare Order Ruleset

Practical Business Modeling in the Unified Process Tom Morgan The Business Rules Model  Step 3 – Detail business rule definitions

Practical Business Modeling in the Unified Process Tom Morgan The Business Rules Model  Step 4 – Validate rule terms against domain model (refine)

Practical Business Modeling in the Unified Process Tom Morgan The Business Rules Model  Step 5 – Associate rules to rule containers Prepare Order Ruleset

Practical Business Modeling in the Unified Process Tom Morgan

Practical Business Modeling in the Unified Process Tom Morgan Questions

Practical Business Modeling in the Unified Process Tom Morgan Tom Morgan Thank You