Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts Rational Unified Process...

Rational Unified Process Fundamentals

Module 3: Core Workflows I - Concepts

Rational Unified Process Fundamentals, v. 2000.02.10Copyright © 2000 Rational Software, all rights reserved 2

Where Are We?Where Are We?

Core Workflows - I Introduction Project Management Requirements Analysis & Design


ObjectivesObjectives

Understand the elements of a Core Workflow

Explain the purpose of Core Workflows Understand how models result from Core

Workflows Explain important concepts for

Project Management Requirements Analysis & Design


Core WorkflowsCore Workflows


Core Workflows are Associated with ModelsCore Workflows are Associated with Models


Elements of the Core WorkflowElements of the Core Workflow

Introduction Concepts Workflow Details Activity Overview Artifact Overview Guidelines Overview


Core Workflow: Project ManagementCore Workflow: Project Management

Purpose: Provide a framework for managing software-

intensive projects. Provide practical guidelines for planning,

staffing, executing, and monitoring projects. Provide a framework for managing risk.


Key Concept: Incremental PlanningKey Concept: Incremental Planning

Current iteration

Next iteration

Phases and major milestones What and when

Project plan Phase plan

Iterations for each phase Number of iterations Objectives Duration

Fine-grained Plans

Coarse-grained Plan

“Road-map”


Use Cases as a Basis for Iteration PlanningUse Cases as a Basis for Iteration Planning

Use-Case Model

Iteration Plan

Fine-grained plan for a single iteration

SupplementarySpecification

Project Management

Constraints


time

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

InceptionInception Elab. . .Elab. . .

Beyond Transition: Development CyclesBeyond Transition: Development Cycles

A development cycle includes one execution of all four phases and produces a software generation

Most software systems require multiple cycles

Cycles may be sequential, but more commonly overlap


#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter. No.

Prel.Iteration

Elabo-ration Construction TransitionInception

Incremental (1)

#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter.No.

Prel.Iteration

Elaboration

Cons-truc-tion TransitionInception

Evolutionary (2)

#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter.No.

Prel.Iteration

Elabo-ration

Cons-truc-tion TransitionInception

Incremental delivery (3)

#1 #2 #3 . . Iter.No.

Elabo-ration Construction TransitionInception

“Grand design” (4)

Strategies for Iterative DevelopmentStrategies for Iterative Development


Architecture Concerns in Project ManagementArchitecture Concerns in Project Management

Consistent architecture and development guidelines

Relationship between the architecture and organizational structures

Separation of development concerns (which will provide a basis for separation of work)

Stability of the technical infrastructures Adherence to standards Required skills


Key Concept: RiskKey Concept: Risk

A risk is whatever may stand in our way to success, and is currently unknown or uncertain. Success is meeting the entire set of all

requirements and constraints, and satisfying stakeholder expectations.


Risk TermsRisk Terms

Direct risk - the project has a large degree of control

Indirect risk - the project has little or no control

Risk attributes: Probability of occurrence Impact on the project (severity)

Risk - whatever may stand in the way of our success


Risk ManagementRisk Management

Strategies: Risk avoidance Risk transfer Risk acceptance

Risk mitigation Confront risks Plan for contingencies Monitor risks

Maintain a risk list


Some Sample RisksSome Sample Risks

Resource risks People, skills, funding,. . .

Business risks Competition, ROI, supplier interfaces,. . .

Technical risks Unproven technology, uncertain scope,. . .

Schedule risks Only 24 hours in a day,. . .


Risk Reduction Drives the Iterative LifecycleRisk Reduction Drives the Iterative Lifecycle

Early iterations address the highest risks Risk assessment is a continuous process;

risks change over time Risk profile by phase

Inception - based on unknowns and risks Elaboration - based on risk and critical

scenarios Construction - based on use case, features, and

subsystems completion Transition - based on quality indicators


Core Workflow: RequirementsCore Workflow: Requirements

Purpose: produce requirements artifacts Stakeholders needs Vision document Use case model

• All functional requirements• Some non functional requirements

Supplementary specification • Other non functional requirements

User interface prototype (optional) Traceability


Supplementary Specification

Primary Requirements ArtifactsPrimary Requirements ArtifactsRequirement

Functional Non-Functional (URPS)

Use-Cases


What Is in a Use-Case Model?What Is in a Use-Case Model?

Actors and their descriptions Use-Case diagrams showing relationships For each use case

Name and brief description Flow of events Preconditions and postconditions (optional) Special requirements Other diagrams, such as activity or state

diagrams


The Purpose of a Use-CaseThe Purpose of a Use-Case

Use cases capture requirements, especially functional requirements

They are usable by many stakeholders They drive many activities in the process They trace to several models: design

model, test model


Major concepts in the Use-Case ModelMajor concepts in the Use-Case Model

Actor

Use Case

An actor represents anything that interacts with the system.

A use case (instance) defines a sequence of actions a system performs that yields a result of observable value to an actor.


Actor

System

ActorActor

Actors are not part of the system, they represent roles a user of the system can play.

An actor can actively interchange information with the system.

An actor can be a passive recipient of information.

An actor can be a giver of information.

An actor can represent a human, a machine or another system.


Charlie asdepot staff

Charlie as depotmanager

Charlie

Depot Staff

Depot Manager

A User Can Act as Several ActorsA User Can Act as Several Actors


Use Case

Use CaseUse Case

A use case models a dialogue between an actor and the system.

A use case is initiated by an actor to invoke a certain functionality in the system.

A use case is a complete and meaningful flow of events.

Taken together, all use cases constitute all possible ways of using the system.


Register for Courses

StudentCourse Catalog

A Scenario - One Path Through a Use CaseA Scenario - One Path Through a Use Case

A use case can have many instances. A scenario is a described use-case

instance: a specific sequence of actions that illustrates behaviors of the system.


A Sample UML Diagram: Use CasesA Sample UML Diagram: Use CasesA University Course Registration System

Professor

Select Courses to Teach

Student

Course Catalog

Register for Courses

Maintain Student Information

Maintain Professor Information

Registrar

Billing System

Close Registration


The Use Case Model Relates to Other ModelsThe Use Case Model Relates to Other Models

verificationrealization

Use-Case Model(requirements)

Implementation Model(source code)

Test Model(test cases and procedures)

influence

Design Model(classes and objects)


Use Cases AnalysisClasses

SourceCode

ExecDesignClasses

From Use Cases to ExecutablesFrom Use Cases to Executables


Traceability Links Support Impact AssessmentTraceability Links Support Impact AssessmentTrace product requirements (features) into detailed requirements

Trace requirements into designTrace requirements into test proceduresTrace requirements into user documentation and training materials

Design Model Test Model End-User Documentation Materials and Training

Materials

1

2 43

1

2

3

4

Vision

Use-Case Model

Supplementary Specification

Stakeholder Needs


Core Workflow: Analysis and DesignCore Workflow: Analysis and Design

Purpose: To transform the requirements into a design of

the system to-be. To evolve a robust architecture for the system. To adapt the design to match the

implementation environment. Modeling, using OO techniques & UML

Design model Process view (concurrency) Deployment view (distribution)


Core Workflow: Analysis & Design (cont.)Core Workflow: Analysis & Design (cont.)

Transform requirements into classes and subsystems

Adhere to constraints of nonfunctional requirements implementation environment

Database design Mapping the design model to a data model

Component identification Subsystems and interfaces


What is a Design Model?What is a Design Model?

An object model describing the realization of use cases

Serves as an abstraction of the implementation model and its source code

Used as essential input to activities in implementation and test.


Use Cases Drive Analysis & DesignUse Cases Drive Analysis & Design

SupplementarySpecifications

Use-Case Model

Design Model

Data ModelArchitectureDocument

Analysis and Design

Analysis Model (optional)


Use Case Realization in Analysis & DesignUse Case Realization in Analysis & Design

Use Case(Use-Case Model)

Use-Case Realization(Design Model)

<<realizes>>

Class Diagrams

Sequence Diagrams Collaboration DiagramsUse Case


Use-Case Analysis and DesignUse-Case Analysis and Design

The complete behavior of a use case is allocated to collaborating classes


A Sample UML Diagram: ClassesA Sample UML Diagram: ClassesA University Course Registration System

MainForm

// select maintain schedule()

<<boundary>> MaintainScheduleForm

+ // open()+ // select 4 primary and 2 alternate offerings()

<<boundary>>

1 0..11

CourseCatalogSystem

// get course offerings()

<<boundary>> 1 0..*RegistrationController

// add courses to schedule()// get course offerings ()

<<control>>

1

1

Schedule

// create with offerings()

<<entity>>

1

0..1


ArchitectureArchitecture

What is architecture? Purpose Definition

Architecture representation Architectural views = slices through models UML Prototyping

Architecture milestone Elaboration phase Lifecycle architecture

milestone


Purpose of ArchitecturePurpose of Architecture

Intellectual control Manage complexity Maintain integrity

Basis for reuse Component reuse Architecture reuse Line-of-product

Basis for project management Planning Staffing Delivery


Significant Decisions About Software ArchitectureSignificant Decisions About Software Architecture

the organization of a software system the structural elements and interfaces

which compose the system, the behavior seen in the collaboration of

these elements the composition of these elements into

progressively larger subsystems the architectural style that guides the

organization, composition, and collaboration of elements and their interfaces


Architecture Includes a System in Its EnvironmentArchitecture Includes a System in Its Environment

In addition to structure and behavior, software architecture is concerned with usage functionality performance resilience reuse comprehensibility aesthetics economic and technological constraints and

tradeoffs


Many stakeholders, many viewsMany stakeholders, many views

Architecture is many things to many different interested parties end-user customer project manager system engineer developer architect

Multidimensional reality Multiple stakeholders

multiple views, multiple blueprints


Architectural ViewArchitectural View

An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective


Architecturally significant elementsArchitecturally significant elements

Not all design is architecture Main “business” classes Important mechanisms Processors and processes Layers and subsystems Architectural views = slices through models


Architecture Views Architecture Views

Conceptual Physical

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-user Functionality Programmers

Software management

PerformanceScalabilityThroughput

System integratorsSystem topology

Delivery, installationcommunication

System engineering

Analysts/DesignersStructure


Where is Architecture in the Process?Where is Architecture in the Process?

Primarily from Analysis & Design Architecture in phases and iterations

Drives the risk mitigation of iterations Architecture baseline is an exit criterion for

Elaboration


Summary: Core WorkflowsSummary: Core Workflows

How often do you go through a Core Workflow?

How does the focus on individual Core Workflows change across the Lifecycle?

What is the role of risk in the iterative Lifecycle?

What is the purpose of the Use Case Model?

What is the purpose of the Analysis and Design workflow?

Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts Rational Unified Process...

Documents

Transcript of Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts Rational Unified Process...