1

Rational Unified Process

2
Agenda
Part I: Introduction
Part II: Disciplines & Workflows
Part III: Phases & Iterations
Part IV: Configuring RUP

3
Whats Rational?

Three important contributors
Grady Booch (Booch Method)
James Rumbaugh (OMT Method)
Ivar Jacobson (OOSE Method)

Introduction
4
Why Unified?
Unification of Development Approaches using UML



Unification of the Work Of many Methodologists

Introduction
5
Whats 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 users requirements into a
software system[Jacobson]

Introduction
6
History Of RUP
Rational Unified Process
1998
Rational Objectory Process
1996-1997
Objectory Process
1987-1995
The Ericsson Approach
UML
Introduction
7
Process 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
8
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 continue
Features
9
Process Framework
Rational Unified Process
My Development Process
My Project
Is specialized to
Is enacted as
Features
10
The Architecture of RUP
time and the lifecycle process disciplines or
workflows
Features
11
The 3+1 Keywords
Architecture Centric

Use Case Driven

Iterative and Incremental

Risk Confronting
3+1 Keywords

}
From USDP
12
Use-Case
Model
Implementation
Model
Design
Model
Analysis
Model
Test
Model
Deployment
Model
RUP is Use Case Driven
Specified by
Realized by
Implemented by
Distributed by
Verified by
3+1 Keywords

13
RUP is I terative & I ncremental
Code and unit test
Design
Subsystem integration
Requirements
analysis
System test
3+1 Keywords

Iteration 1
Code and unit test
Design
Subsystem integration
Requirements
analysis
System test
Iteration 2
14
RUP is Architecture Centric
Process
View
Deployment
View
Logical
View
Implementation
View
Programmers
Software management
Performance
Scalability
Throughput
System Integrators
System topology
Delivery, installation
communication
System Engineering
Use-Case
View
Structure
Analysts/
Designers
End-user
Functionality
3+1 Keywords

15
RUP is Risk Confronting
3+1 Keywords

Iteration 3...
Construction
Inception
Architectural prototype
Draft specifications & models
Elaboration
Initial executable system
Refined specifications & models
Final system
Intermediate system
Transition
Focus on the 20% that really matter:
The primary use cases
The architectural components
The driving scenarios
R
i
s
k
R
i
s
k
Inception
16
Part I I
Process
Disciplines & Workflows
17
Definition
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.

18
Workflows in RUP
Workflows
Core Process
Workflows
Support Process
Workflows
19
Business 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

20
Requirements
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
vision
glossary
21
Analysis 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.
Workflows
22
I mplementation
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
23
Test
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 Model
Test Case
24
Deployment
The Deployment Workflow describes the
activities associated with ensuring that the
software product is available for its end users
Workflows
25
Environment
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
26
Configuration 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.

Workflows
27
Project 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.
Managing people: hiring, training, coaching
Managing budget: defining, allocating, etc.
Managing contracts, with suppliers and customers
NOT
Workflows
28
Key Concepts
Workflows
29
I mplementation Workflow
Plan the Integration
Implement Components
Structure the
Implementation Model
Implement Components
Implement Components
[more components to
implement in this
iteration]
[more system builds
for this iteration]
[more subsystem
integration for this
iteration]
Workflows
30
Structure the I mplementation Model
Worker
Activity
Structure the
Implementation Model
Use-Case
Specifier
Workflow
Details
Design
Model
Implementation
Model
Software Architecture
Document
Artifact
31
Activity: Structure the Implementation Model
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

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

Worker: Architect
Guidelines: Guidelines: Implementation Subsystems
Tool Mentor:
Structuring the Implementation Model Using Rational Rose
Setting Up the Implementation Model Using Rational ClearCase




32
Artifact: 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.
Worker:
Architect
Template:
Microsoft Word Template
HTML Template

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

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


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


33
Checkpoints: 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.
34
Use-Case SpecificationHTML Template
<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 customers name and address. A Glossary of
Terms is often useful to keep the complexity of the use case manageableyou may want to define things like
customer information there to keep the use case from drowning in details.
35
Part I I I
Phases and I terations
36
Lifecycle Phases
I nception Understand what to build
Define the Scope of Project and Develop Business Case
and Critical Use-Case
Elaboration Understand how to build it
Plan Project, Specify Features, and Baseline the
Architecture
Construction Build the Product
Produce a beta product
Transition Transition the Product to its Users
Produce final product
Phases
I nception Elaboration Construction Transition
time
37
Milestones
I nception Elaboration Construction Transition
time
Lifecycle
Objectives
Milestone
Lifecycle
Architecture
Milestone
Initial
Operational
Capability

Product
Release
38
Phases and I terations
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
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition
Iteration
Inception Elaboration Construction Transition
Minor Milestones: Releases
Phases
39
I teration as Waterfall
In an iteration,
you walk
through all
workflows
Phases
40
The I teration Life Cycle: A Mini-
Waterfall
Results of previous iterations
Up-to-date risk assessment
Controlled libraries of models,
code, and tests
Release description
Updated risk assessment
Controlled libraries
Iteration Planning
Requirements Capture
Analysis & Design
Implementation
Test
Prepare Release
Selected scenarios
Phases
41
I teration
Phases
Initial
Planning
Planning
Requirements
Capture
Analysis & Design
Implementation
Test
Deployment
Evaluation
Management
Environment
42
What the I terative Lifecycle I s
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
43
Phases and I terations: A Sample
Phases
Short e-Business Project
5 Project Member
No of Iterations
I nception Elaboration Construction Transition
Project
Length
I teration
Length
1 1 3 1
3-4
month
2-3
weeks
10% 30% 50% 10% Time:
44
Risk Profile of an I terative
Development
Risk
Transition
Inception
Elaboration
Construction
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition
Iteration
Post-
deployment
Waterfall
Time
Copyright 1997 by Rational Software Corporation

Phases
45
Part I V
Configuring RUP
46
Why 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
Each have
different Risk
Each have
different Equipment
Each have
different Objectives
Each have
different Safety
and Security
Essentials
Configure RUP
47
Which Do I Need for My Project
Configure RUP
48
Who Configures The RUP?
Configure RUP
Assess
Current
Organization
Engineer
Process
Development
Organization
Assessment
Development
Case
Project Specific
Templates
Develop
Development
Case
Develop
Project Specific
Templates
Launch
Development
Case
49
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
50
Tools: Rational Suite
Rose
TeamTest
RequisitePro
SoDA
ClearCase
ClearQuest
Purify
Quantify
PureCoverage
Content Studio Project Console
Rational Unified
Process
Jacobson: a process without integral
tools is just an academic idea!
51
References
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
52
Rational Unified Process
http://www.BaridSoft.ca
This presentation can be download from: