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

Practical Business Modeling in the Unified Process

Tom Morgan Software Architect, Fidelity National Information Servicestemx@bellsouth.net

Tom Morgan temx@bellsouth.net

Agenda

Brief Business Modeling introduction

Artifact production in reference implementation

Transformation into Requirements Use-Case Model

Simple steps for Business Rules Model

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)

Find Business Actors and Use Cases – Goal Driven

Step 1: Determine boundaries (or scope) of target business Main business

Step 1: Determine boundaries (or scope) of target business Main business comprised of one business part

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)

Step 1: Determine boundaries (or scope) of target business Narrow focus the Box Office

Step 1: Determine boundaries of target business The Box Office is our box, or business boundary

Start outside box with goal to describe inside

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

Step 2: Finding Business Actors At this point, consider as candidate Business Actors

Step 2: Finding Business Actors Refine to same abstraction, eliminate redundant and ambiguous candidates

Step 2: Finding Business Actors

Step 3: Describe All Business Actors Provide any potentially valuable information

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

Find Business Actors and Use Cases

Zeroing in on correct abstraction level

High Level

Low Level

Step 4: Finding Business Actor Goals

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

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

Initial Survey Diagram Completed

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)

Detail a Business Use Case

Sell Movie Tickets Business Use-Case Specification

Definition: When a Movie Viewer requests admission to one or more movie features at the box office, the business shows movies and sells tickets for admission.

Actors: Movie Viewer

Actor Goal: Go see a movie

Business view of goal: Show movies and sell tickets for admission

Trigger: Movie Viewer requests admission to one or more movie features at the box office

Pre-conditions: The box office is open and staffed Post-conditions: a) Tickets for admission to scheduled movie features are paid for and seating has been adjusted for the features. b) A request couldn’t be fulfilled.

Basic Flow

Start of use case: The business use case begins when a Movie Viewer wants admission to one or more movie features at the theater.

Prepare order: The box office validates the availability of the shows, times, and seats requested. The box office prepares the order according to business policies, reserves the seats, and calculates the amount due.

Collect payment: The box office collects the amount due for the order from the Movie Viewer and gives the Movie Viewer a receipt showing the amount paid and other order details.

Prepare tickets: The box office prepares the tickets and gives them to the Movie Viewer for admission and the business use case ends.

Alternates

Cancel Order: At any step before paying in Collect payment the Movie Viewer cancels the request or is unable to pay. The box office cancels the order and the business use case ends.

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

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

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

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

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

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

Responsibilities may be decomposed by asking “How?”, but not too much

Capture Alternates using UML Combined Fragments in RSA

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

Explore Process Automation

Identify responsibilities needing automation

Identify and describe system components (same stereotype as Worker)

Re-assign responsibilities (manual tasks remain with Worker)

Decompose and refine as necessary

Explore Process Automation - Complete

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

Add Business Entities to diagram

Detail a Business Entity

Explain role in business

Describe lifecycle (use statechart when needed)

Redirect messages – From Worker to Entity

Remove Automation Elements

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

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

Where to go next?

Overlapping disciplines = parallel activities

Finish Business ModelingStart Requirements AND

Deriving the Requirements Use-Case Model

Step 1 – Focus on a single system lifeline (our new scope boundary)

Step 2 – Transform messages ending on scope boundary to use cases

Step 3 – Transform Business Workers to Actors

Step 4 – Transform messages affecting scope to <<include>> <<extend>>

Step 5 – Repeat for other system lifelines

Step 6 – Preserve business process context

The Business Rules Model

Step 1 - Identify business rules location in business process workflows

Basic Flow

Alternates

Step 2 – Identify high level container for rules

Basic Flow

Alternates

Prepare Order Ruleset

Step 3 – Detail business rule definitions

Business Rule Survey

Rule Name: Purchase Time Rule

Definition: Tickets in an order must be purchased within 1 hour of the time for the show.

Step 4 – Validate rule terms against domain model (refine)

Step 5 – Associate rules to rule containers

Basic Flow

Alternates

Prepare Order Ruleset

Questions

Tom Morgan thomas.morgan@fnis.com

Thank You

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

Documents

Light fidelity

· abhayananda@bellsouth.net

Section 4 Fidelity of Implementation - LDAofKY Manual Section 4 - Fidelity of...Section 4 Fidelity of Implementation • What is Fidelity of Implementation? page 4.2 ... • Decisions

FIDELITY INVESTMENTS Fidelity Viewpoints® Webcast: April 22, 2013

Low-fidelity scale factor improves Bayesian multi-fidelity ...RESEARCH PAPER Low-fidelity scale factor improves Bayesian multi-fidelity prediction by reducing bumpiness of discrepancy

Fidelity Magellan

Fidelity dkk

krishnamurti.abundanthope.orgkrishnamurti.abundanthope.org/index_htm_files/The-Origin-of... · abhayananda@bellsouth.net

1 PDG Bob and PDG Jane Molloy jabmolloy@bellsouth.net

Supplemental Information: Fidelity Go Fidelity ......Supplemental Information: Fidelity Go ... 3. Fidelity Go® and Fidelity® Personalized Planning & Advice Brochure Supplement 4

Sketching UX: Low-Fidelity Method; High-Fidelity Results

Fidelity TK

Jeffrey L. Mills, CTP Mills Marketing Group Jeff-mmg@bellsouth.net

FIDELITY BROKERAGE RETIREMENT CUSTOMER ......traditional, rollover, and SEP IRAs), Fidelity Roth IRAs, Fidelity SIMPLE-IRAs, and Fidelity Retirement Plan accounts [Profit Sharing,

Robby Davis Lee County High School Leesburg, Georgia rdavis65@bellsouth.net

Low-Fidelity Prototyping · Fidelity in Prototyping Fidelity refers to the level of detail High fidelity? – Prototypes look like the final product Low fidelity? – Artists renditions

Fidelity Global Disciplined Equity Class of the Fidelity

Fidelity Technology Innovators Class of the Fidelity ... · Fidelity Technology Innovators Class of the Fidelity Capital Structure Corp. ... 2019 2018) Investments at fair value through

Isaiah - Malachi. E-Mail: JohnStevenson@Bellsouth.net Website: FACILITATOR: John Stevenson

Judy Graves Monday, July 25, 2016 4… · 2016. 8. 10. · 1 From: Judy Graves Sent: Monday, July 25, 2016 4:41