1111

Rational Unified ProcessRational Unified ProcessRational Unified ProcessRational Unified Process

2222

AgendaAgenda

Part I: IntroductionPart I: Introduction

Part II: Disciplines & Workflows Part II: Disciplines & Workflows

Part III: Phases & IterationsPart III: Phases & Iterations

Part IV: Configuring RUPPart IV: Configuring RUP

Part I: IntroductionPart I: Introduction

Part II: Disciplines & Workflows Part II: Disciplines & Workflows

Part III: Phases & IterationsPart III: Phases & Iterations

Part IV: Configuring RUPPart IV: Configuring RUP

3333

What’sWhat’s RationalRational?What’sWhat’s RationalRational?

• Three important contributors

– Grady Booch (Booch Method)

– James Rumbaugh (OMT Method)

– Ivar Jacobson (OOSE Method)

Introduction

4444

Why UnifiedUnified?Why UnifiedUnified?

Unification of Development Approaches using UML

Unification of the Work Of many Methodologists

Unification of Development Approaches using UML

Unification of the Work Of many Methodologists

Introduction

5555

What’s Process?What’s Process?

Defines Who is What, When to do it, and How to reach a certain goal.

A Software Development Process is the set of activities needed to transform a user’s requirements into a software system[Jacobson]

Introduction

6666

History Of RUPHistory Of RUP

Rational Unified Process1998

Rational Objectory Process1996-1997

Objectory Process 1987-1995

The Ericsson Approach

UML

Introduction

7777

Process ProductProcess Product

•Process must be built on Technologies

•People: limit the skill set needed to operate

•Tools are integral to process

•Organization Pattern

Balance

•"Software processes are software, too"

Features

8888

Like a software product is based on UML

Is delivered online using Web technology, not in books or binders

Released by Rational Software approximately twice a year

Like a software product is based on UML

Is delivered online using Web technology, not in books or binders

Released by Rational Software approximately twice a year

Process Product continueProcess Product continue

Features

9999

Process FrameworkProcess Framework

Rational Unified Process

My Development Process

My Project

Is specialized to

Is enacted as

Features

10101010

The Architecture of RUPThe Architecture of RUP

time and the lifecycletime and the lifecycletime and the lifecycletime and the lifecycleprocess disciplines or workflows

Features

11111111

The 3+1 KeywordsThe 3+1 Keywords

Architecture Centric

Use Case Driven

Iterative and Incremental

Risk Confronting

Architecture Centric

Use Case Driven

Iterative and Incremental

Risk Confronting

3+1 Keywords

}}From USDPFrom USDPFrom USDPFrom USDP

12121212

Use-CaseModel

ImplementationModel

DesignModel

AnalysisModel

TestModel

DeploymentModel

RUP is Use Case DrivenRUP is Use Case Driven

Specified bySpecified by

Realized byRealized by

ImplementedImplemented byby

Distributed byDistributed by

Verified byVerified by

3+1 Keywords

13131313

RUP is Iterative & IncrementalRUP is Iterative & Incremental

Code and unit test

Design

Subsystem integration

Requirements analysis

System test

3+1 Keywords

Iteration 1Iteration 1Iteration 1Iteration 1

Code and unit test

Design

Subsystem integration

Requirements analysis

System test

Iteration 2Iteration 2Iteration 2Iteration 2

14141414

RUP is Architecture CentricRUP is Architecture Centric

Process View

Deployment View

Logical View

Implementation View

Programmers Software management

PerformanceScalabilityThroughput

System IntegratorsSystem topology Delivery, installationcommunication

System Engineering

Use-Case View

Structure

Analysts/Designers End-user

Functionality

3+1 Keywords

15151515

RUP is Risk ConfrontingRUP is Risk Confronting3+1 Keywords

Iteration 3... Construction

Inception Architectural prototype

Draft specifications & models

Elaboration Initial executable systemRefined specifications & models

Final system

Intermediate system

Transition

Focus on the 20% that really matter:• The primary use cases• The architectural components• The driving scenarios

Risk

Risk

Inception

16161616

Part IIPart II

Process

Disciplines & Workflows

Process

Disciplines & Workflows

17171717

DefinitionDefinition

Workflow The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business

Core workflow A core workflow shows all activities you may go through to produce a particular set of artifacts.

Workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows.

Workflow The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business

Core workflow A core workflow shows all activities you may go through to produce a particular set of artifacts.

Workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows.

18181818

Workflows in RUPWorkflows in RUPWorkflows

Core Process Core Process

WorkflowsWorkflows

Core Process Core Process

WorkflowsWorkflows

Support Process Support Process

WorkflowsWorkflows

Support Process Support Process

WorkflowsWorkflows

19191919

Business ModelingBusiness Modeling

• To understand the structure and the dynamics of the target organization).

• To understand current problems in the target organization and identify improvement potentials. 

• To ensure that customers, end users, and developers have a common understanding of the target organization.

• To derive the system requirements needed to support the target organization

• To understand the structure and the dynamics of the target organization).

• To understand current problems in the target organization and identify improvement potentials. 

• To ensure that customers, end users, and developers have a common understanding of the target organization.

• To derive the system requirements needed to support the target organization

20202020

RequirementsRequirements

• To agreement with stakeholders • To provide system developers better understanding of the

system requirements. • define the boundaries of the system. • To provide a basis for planning the technical contents of

iterations. • To provide a basis for estimating cost and time to develop the

system. • To define a user-interface for the system, focusing on the

needs and goals of the users.

• To agreement with stakeholders • To provide system developers better understanding of the

system requirements. • define the boundaries of the system. • To provide a basis for planning the technical contents of

iterations. • To provide a basis for estimating cost and time to develop the

system. • To define a user-interface for the system, focusing on the

needs and goals of the users.

Workflows

visionvisionvisionvisionglossaryglossaryglossaryglossary

21212121

Analysis and DesignAnalysis and Design

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, designing it for performance.

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, designing it for performance.

Workflows

22222222

ImplementationImplementation

To define the organization of the code, in terms of implementation subsystems organized in layers

To implement classes and objects in terms of components (source files, binaries, executables, and others)

To test the developed components as units

To integrate the results produced by individual implementers (or teams), into an executable system.

To define the organization of the code, in terms of implementation subsystems organized in layers

To implement classes and objects in terms of components (source files, binaries, executables, and others)

To test the developed components as units

To integrate the results produced by individual implementers (or teams), into an executable system.

Workflows

23232323

TestTest

To verify the interaction between objects.

To verify the proper integration of all components of the software.

To verify that all requirements have been correctly implemented.

To identify and ensure defects are addressed prior to the deployment of the software.

To verify the interaction between objects.

To verify the proper integration of all components of the software.

To verify that all requirements have been correctly implemented.

To identify and ensure defects are addressed prior to the deployment of the software.

Workflows

Test ModelTest ModelTest ModelTest Model Test CaseTest CaseTest CaseTest Case

24242424

DeploymentDeployment

The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users

The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users

Workflows

25252525

EnvironmentEnvironment

The environment workflow focuses on the activities necessary to configure the process for a project.

The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team

The environment workflow focuses on the activities necessary to configure the process for a project.

The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team

Workflows

26262626

Configuration and Change ManagementConfiguration and Change Management

supports development methods maintains product integrity ensures completeness and correctness of the configured

product provides a stable environment within which to develop the

product restricts changes to artifacts based on project policies provides an audit trail on why, when and by whom any

artifact was changed.

supports development methods maintains product integrity ensures completeness and correctness of the configured

product provides a stable environment within which to develop the

product restricts changes to artifacts based on project policies provides an audit trail on why, when and by whom any

artifact was changed.

Workflows

27272727

Project ManagementProject Management

• To provide a framework for managing software-intensive projects.

• To provide practical guidelines for planning, staffing, executing, and monitoring projects.

• To provide a framework for managing risk.

• To provide a framework for managing software-intensive projects.

• To provide practical guidelines for planning, staffing, executing, and monitoring projects.

• To provide a framework for managing risk.

• Managing people: hiring, training, coaching

• Managing budget: defining, allocating, etc.

• Managing contracts, with suppliers and customers

NOT

Workflows

28282828

Key ConceptsKey ConceptsWorkflows

29292929

Implementation WorkflowImplementation Workflow

Plan the IntegrationPlan the Integration

Implement ComponentsImplement Components

Structure the

Implementation Model

Structure the

Implementation Model

Implement ComponentsImplement Components

Implement ComponentsImplement Components

[more components to implement in this

iteration]

[more components to implement in this

iteration]

[more system builds for this iteration]

[more system builds for this iteration]

[more subsystem integration for this

iteration]

[more subsystem integration for this

iteration]

Workflows

30303030

Structure the Implementation ModelStructure the Implementation Model

Worker

Activity

Structure the Implementation Model

Use-Case Specifier

Workflow Details

Design Model

ImplementationModel

Software ArchitectureDocument

Artifact

31313131

Activity: Structure the Implementation ModelActivity: Structure the Implementation Model

Purpose •To establish the structure in which the implementation will reside. •To assign responsibilities for Implementation Subsystems and their contents.

Purpose •To establish the structure in which the implementation will reside. •To assign responsibilities for Implementation Subsystems and their contents.

Steps •Create the initial implementation model structure •Adjust implementation subsystems •Define imports for each implementation subsystems •Decide how to treat executables (and other derived objects) •Decide how to treat test assets •Update the implementation view •Evaluate the implementation model

Steps •Create the initial implementation model structure •Adjust implementation subsystems •Define imports for each implementation subsystems •Decide how to treat executables (and other derived objects) •Decide how to treat test assets •Update the implementation view •Evaluate the implementation model

Input Artifacts: •Software Architecture Document •Supplementary Specifications •Design Guidelines •Design Model

Input Artifacts: •Software Architecture Document •Supplementary Specifications •Design Guidelines •Design Model

Resulting Artifacts: •Implementation View section of the Software Architecture Document •Implementation Subsystems •Implementation Model

Resulting Artifacts: •Implementation View section of the Software Architecture Document •Implementation Subsystems •Implementation Model

Worker: ArchitectWorker: Architect

Guidelines: Guidelines: Implementation SubsystemsGuidelines: Guidelines: Implementation Subsystems

Tool Mentor: •Structuring the Implementation Model Using Rational Rose •Setting Up the Implementation Model Using Rational ClearCase

Tool Mentor: •Structuring the Implementation Model Using Rational Rose •Setting Up the Implementation Model Using Rational ClearCase

32323232

Artifact: Software Architecture DocumentArtifact: Software Architecture Document

    Software Architecture Document

    Software Architecture Document

The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system.

The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system.

Worker:Worker: ArchitectArchitect

Template:Template:•Microsoft Word Template •HTML Template

•Microsoft Word Template •HTML Template

Examples:Examples:•Course Registration System •Collegiate Sports Paging System (e-Business)

•Course Registration System •Collegiate Sports Paging System (e-Business)

More Information:More Information:•Checkpoints: Software Architecture Document •Guidelines: Software Architecture Document

•Checkpoints: Software Architecture Document •Guidelines: Software Architecture Document

•Purpose •Brief Outline •Timing •Responsibility •Tailoring •Annotated Outline (hyperlinks into HTML template in a new window)

•Purpose •Brief Outline •Timing •Responsibility •Tailoring •Annotated Outline (hyperlinks into HTML template in a new window)

   

33333333

Checkpoints: Design ModelCheckpoints: Design Model

Topics

• General

• Layers

General

The model appears to be able to accommodate reasonably expected future change.

The design is appropriate to the task at hand (neither too complex nor too advanced)

The design appears to be implementable

Layers

The design appears to be understandable and maintainable

There are no more than seven (plus or minus two) layers.

The rationale for layer definition is clearly presented and consistently applied.

Topics

• General

• Layers

General

The model appears to be able to accommodate reasonably expected future change.

The design is appropriate to the task at hand (neither too complex nor too advanced)

The design appears to be implementable

Layers

The design appears to be understandable and maintainable

There are no more than seven (plus or minus two) layers.

The rationale for layer definition is clearly presented and consistently applied.

34343434

Use-Case Specification—HTML TemplateUse-Case Specification—HTML Template<Project Name>

Use Case Specification: <Use-Case Name>

 

Version <1.0>

 

<Project Name>

Use Case Specification: <Use-Case Name>

 

Version <1.0>

 

Use Case Specification: <Use-Case Name>

1.                  Use Case Name

[The following template is provided for a Use-Case Specification, which contains the textual properties of the use case.  This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties]

[The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose.  A use-case report (with all properties) may be generated with Rational SoDA.  For more information, see the tool mentors in the Rational Unified Process.]

1.1               Brief Description

[The description should briefly convey the role and purpose of the use case.  A single paragraph should suffice for this description.]

2.                  Flow of Events

2.1               Basic Flow

[This use case starts when the actor does something.  An actor always initiates use Cases.  The use case should describe what the actor does and what the system does in response.  It should be phrased in the form of a dialog between the actor and the system.

The use case should describe what happens inside the system, but not how or why.  If information is exchanged, be specific about what is passed back and forth.  For example, it is not very illuminating to say that the Actor enters customer information. It is better to say the Actor enters the customer’s name and address.  A Glossary of Terms is often useful to keep the complexity of the use case manageable¾you may want to define things like customer information there to keep the use case from drowning in details.

Use Case Specification: <Use-Case Name>

1.                  Use Case Name

[The following template is provided for a Use-Case Specification, which contains the textual properties of the use case.  This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties]

[The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose.  A use-case report (with all properties) may be generated with Rational SoDA.  For more information, see the tool mentors in the Rational Unified Process.]

1.1               Brief Description

[The description should briefly convey the role and purpose of the use case.  A single paragraph should suffice for this description.]

2.                  Flow of Events

2.1               Basic Flow

[This use case starts when the actor does something.  An actor always initiates use Cases.  The use case should describe what the actor does and what the system does in response.  It should be phrased in the form of a dialog between the actor and the system.

The use case should describe what happens inside the system, but not how or why.  If information is exchanged, be specific about what is passed back and forth.  For example, it is not very illuminating to say that the Actor enters customer information. It is better to say the Actor enters the customer’s name and address.  A Glossary of Terms is often useful to keep the complexity of the use case manageable¾you may want to define things like customer information there to keep the use case from drowning in details.

35353535

Part IIIPart III

Phases and IterationsPhases and Iterations

36363636

Lifecycle PhasesLifecycle Phases

InceptionInception Understand what to buildDefine the Scope of Project and Develop Business Case and Critical Use-Case

ElaborationElaboration Understand how to build itPlan Project, Specify Features, and Baseline the Architecture

ConstructionConstruction Build the ProductProduce a beta product

TransitionTransition Transition the Product to its UsersProduce final product

Phases

Inception Elaboration Construction Transition

timetimetimetime

37373737

MilestonesMilestones

Inception Elaboration Construction Transition

time

Lifecycle Objectives Milestone

Lifecycle ArchitectureMilestone

Initial Operational Capability

Product Release

38383838

Phases and IterationsPhases and Iterations

An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external)

Within each phase are a number of iterations

An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external)

Within each phase are a number of iterations

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration

Architect.Architect.IterationIteration

Devel. Devel. IterationIteration

Devel. Devel. IterationIteration

Devel. Devel. IterationIteration

TransitionTransitionIterationIteration

TransitionTransitionIterationIteration

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Minor Milestones: Releases

Phases

39393939

Iteration as WaterfallIteration as Waterfall

In an iteration, you walk through all workflows

Phases

40404040

The Iteration Life Cycle: A Mini-WaterfallThe Iteration Life Cycle: A Mini-Waterfall

• Results of previous iterations• Up-to-date risk assessment• Controlled libraries of models, code, and tests

Release descriptionUpdated risk assessmentControlled libraries

Iteration Planning

Requirements Capture

Analysis & Design

Implementation

Test

Prepare Release

Selected scenarios

Phases

41414141

IterationIterationPhases

InitialInitialPlanningPlanning

PlanningPlanning

RequirementsRequirementsCaptureCapture

Analysis & DesignAnalysis & Design

ImplementationImplementation

TestTest

DeploymentDeployment

EvaluationEvaluation

ManagementManagementEnvironmentEnvironment

42424242

What the Iterative Lifecycle IsWhat the Iterative Lifecycle Is

It is planned and managed It is predictable It accommodates changes to requirements with less

disruption It is based on evolving executable prototypes, not

documentation It involves the user/customer throughout the process It is risk driven

It is planned and managed It is predictable It accommodates changes to requirements with less

disruption It is based on evolving executable prototypes, not

documentation It involves the user/customer throughout the process It is risk driven

Phases

43434343

Phases and Iterations: A SamplePhases and Iterations: A SamplePhases

Short e-Business ProjectShort e-Business ProjectShort e-Business ProjectShort e-Business Project

5 Project Member5 Project Member5 Project Member5 Project Member

No of IterationsNo of IterationsNo of IterationsNo of Iterations

InceptionInceptionInceptionInception ElaborationElaborationElaborationElaboration ConstructionConstructionConstructionConstruction TransitionTransitionTransitionTransitionProject Project

LengthLength

Project Project

LengthLength

IterationIteration

LengthLength

IterationIteration

LengthLength

11 11 33 11

3-4

month

3-4

month2-3

weeks

2-3

weeks

10%10% 30%30% 50%50% 10%10%Time:Time:Time:Time:

44444444

Risk Profile of an Iterative DevelopmentRisk Profile of an Iterative Development

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

Copyright © 1997 by Rational Software Corporation

Phases

45454545

Part IVPart IV

Configuring RUPConfiguring RUP

46464646

Why Do You Need To Configure RUPWhy Do You Need To Configure RUP

•RUP is a Framework not a single Process

•No one process fits all projects

•All thing will be changed

•Technologies

•Organization

•RUP is a Framework not a single Process

•No one process fits all projects

•All thing will be changed

•Technologies

•Organization

Each haveEach have

different Riskdifferent Risk

Each haveEach have

different Riskdifferent RiskEach haveEach have

different Equipmentdifferent Equipment

Each haveEach have

different Equipmentdifferent Equipment

Each have

different Objectives

Each have

different Objectives

Each have Each have

different Safety different Safety

and Securityand Security

Each have Each have

different Safety different Safety

and Securityand Security

EssentialsEssentialsEssentialsEssentials

Configure RUP

47474747

Which Do I Need for My ProjectWhich Do I Need for My ProjectConfigure RUP

48484848

Who Configures The RUP?Who Configures The RUP?Configure RUP

AssessCurrent

OrganizationEngineerProcess

DevelopmentOrganizationAssessment

DevelopmentCase

Project SpecificTemplates

DevelopDevelopment

Case

DevelopProject Specific

Templates

LaunchDevelopment

Case

49494949

How To Configure The RUP?How To Configure The RUP?

Development Case: The development-case description describes the

development process that you have chosen to follow in your project

Roadmap: Roadmaps provide a way of describing how to

use the general-purpose process described in the Rational Unified Process to solve specific types of problems

Configure RUP

50505050

Tools: Rational SuiteTools: Rational Suite

Rose

TeamTest

RequisitePro

SoDA ClearCase

ClearQuest

PurifyQuantify

PureCoverage

Content Studio Project Console

Rational Unified Rational Unified

ProcessProcess

Rational Unified Rational Unified

ProcessProcess

Jacobson: a process without integral

tools is just an academic idea!

Jacobson: a process without integral

tools is just an academic idea!

51515151

ReferencesReferences

Unified Software Development Process, Ivar Jacobson, Grady Booch, Jim Rumbaugh

“Ten Essential Of RUP”, Leslee Probasco “Trends in Software Engineering a personal view”, Ivar

Jacobson “Object Oriented Methodology”, William F. Nazzaro “What is RUP”, Philippe Kruchten Introduction to Rational Unified Process, Philippe Kruchten Rational Unified Process, www.rational.com/rup www.therationaledge.com

Unified Software Development Process, Ivar Jacobson, Grady Booch, Jim Rumbaugh

“Ten Essential Of RUP”, Leslee Probasco “Trends in Software Engineering a personal view”, Ivar

Jacobson “Object Oriented Methodology”, William F. Nazzaro “What is RUP”, Philippe Kruchten Introduction to Rational Unified Process, Philippe Kruchten Rational Unified Process, www.rational.com/rup www.therationaledge.com

52525252

Rational Unified ProcessRational Unified ProcessRational Unified ProcessRational Unified Process

http://www.BaridSoft.cahttp://www.BaridSoft.ca

This presentation can be download from:This presentation can be download from: