®
IBM Software Group
PRJ270: Essentials of Rational Unified Process
Module 4: RUP Content
1
Module 4 Objectives
Be introduced to the content of RUP and its
application by investigating:
 RUP disciplines
• Requirements
• Business Modeling
• Configuration & Change Management
• Environment
• Project Management
• Analysis & Design
• Implementation
• Test
• Deployment
2
Review: RUP Organization Based on Content
RUP content is organized into disciplines.
Discipline: a collection of activities that are all
related to a major “area of concern.”
The disciplines are:
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
3
RUP Disciplines
RUP has disciplines.
Artifacts from each
discipline evolve over the
iterative process.
4
Disciplines Produce and Share Models
Various
disciplines
produce
Models …
Business
Modeling
Analysis &
Design
Requirements
Implementation
Input To
Business UseCase Model
B
B
B
B
Realized By
Use-Case
Model
Automated
By
Business
Object Model
… each of
those models
is Assessed
Design Model Implementation
Model
Verified By
Test
5
Validated By
Deployment
Realized
By
Implemented
By
Requirements Discipline
Purpose
 Establish and maintain agreement with the
customers and other stakeholders on what the
system should do
 Provide system developers with a better
understanding of the system requirements
 Define the boundaries of (delimit) the system
 Provide a basis for planning the technical
contents of iterations
 Provide a basis for estimating cost and time to
develop the system
 Define a user-interface for the system, focusing
on the needs and goals of the users
6
Requirements Types
 Features: used for scoping the project
 Main audience: Stakeholders
 Documented in the Vision artifact
 Functional Requirements: specifying interactions
with system users
 Main audience: users and project team
 Modeled in the Use-Case Model artifact
 Supplementary Requirements: specifying
functionality, usability, reliability, performance,
supportability requirements, and design constraints
 Main audience: architects and designers
 Documented in the Supplementary Specifications
artifact
7
Major Concepts in the Use-Case Model
An actor represents a
person or another
system that interacts
with the system.
Actor
A use case defines a
sequence of actions a
system performs that
yields a result of
observable value to an
actor.
Use Case
8
Actor
 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.
Actor
System
9
A User Can Act as Several Actors
Charlie as depot
manager
Charlie
Depot Manager
Charlie as
depot staff
Depot Staff
10
Use Case
Use Case
 A use case specifies 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.
11
A 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.
Student
Register for
Courses
12
Course Catalog
A Sample UML Diagram: Use Cases
A University Course Registration System
Register for Courses
Student
Select Courses to Teach
Course Catalog
Professor
Maintain Professor Information
Registrar
Maintain Student Information
Close Registration
Billing System
13
What Is in a Use-Case Model?
 Actors and their descriptions
 Use-case diagrams showing relationships
 For each use case:
 Name and brief description
 Textual specification of:
• Flow of events
• Pre-conditions and post-conditions (optional)
• Special requirements
• Other diagrams, such as activity or state
diagrams
14
Review: Disciplines Produce and Share Models
Various
disciplines
produce
Models …
Business
Modeling
Analysis &
Design
Requirements
Implementation
Input To
Business UseCase Model
B
B
B
B
Realized By
Use-Case
Model
Automated
By
Business
Analysis Model
… each of
those models
is Assessed
Design Model Implementation
Model
Verified By
Test
15
Validated By
Deployment
Realized
By
Implemented
By
Use Cases as a Basis for Iteration Planning
Constraints
Use-Case Model
Project
Management
Iteration Plan
Fine-grained plan for
a single iteration
Supplementary
Specifications
During Elaboration, use
cases are implemented to
validate the architecture.
16
Use Cases as a Basis for System Modeling (1)
Use-Case Model
(requirements)
realizatio
n
influence
Design Model
Implementation Model
(classes and objects)
(source code)
17
verification
Test Scripts
Use Cases as a Basis for System Modeling (2)
Use Cases
Analysis Design
Classes Classes
18
Source
Code
Exec
Use Cases as a Basis for Test Planning
The complete behavior of a use case is tested using Test
Scripts and Test Suites.
Test Script
Test Suite
Test Script
Test Suite
19
Requirements Traceability
1
Vision
2
1
Stakeholder
Needs
3
Use-Case
Model
2
Design Model
Supplementary
Specifications
3
Test Suite
4
4
Trace product
requirements
(features) into
detailed requirements
Trace requirements
into design
Trace requirements
into test procedures
Trace requirements
into user
documentation and
training materials
End-User Documentation
Materials and Training
Materials
20
Business Modeling Discipline
 Purpose
 Understand problems in target organization and
identify potential improvements
 Ensure customer and end user have common
understanding of target organization
 Derive system requirements to support target
organization
 Understand structure and dynamics of
organization in which system is to be deployed
 This discipline uses an approach very
similar to that of system development
21
What Business Models Show
 Customers and
vendors
 Business processes
 Organizational
structure
 Roles and
responsibilities
 Products
 Internal deliverables
 Events
Two Business Models
Business
Use-Case Model
Business
Analysis Model
22
Business Modeling and Software Development
Business Modeling acts as:
 Input to Requirements
 Business Use-Case Models help you to
understand the requirements of the system and
identify system use cases
 Input to Analysis & Design
 Business entities from the Business Analysis
Model help identify entity classes in the Analysis
Model
23
Configuration & Change Management Discipline
Purpose: controls change to, and maintains
the integrity of, a project’s artifacts.
24
Configuration Management (CM)
Configuration Management tools
Support members of the project team (especially
those involved in development) by enabling:
 Baselining of versions and concurrent development
 Configuration identification and management
 Configuration status accounting and change tracking
 Version selection
 Software manufacture
 Measurement accounting by element
 A framework for Work Breakdown Structure design
The Product Directory Structure contains elements
of the product under development
25
Sample Product Directory Structure
The structure should be
initiated during Inception and
detailed as the product is
defined.
26
Change Request Management (CRM)
Two basic types of requests need to be
managed:
 Defects
 CRM supports all members of the team by
managing the processes to acquire, assign,
correct, and report defect-related activities.
 Enhancement Requests
 CRM supports the Change Control Board in the
administration of assessment and disposition of
product change proposals.
27
Change Request Management (CRM)
28
Measurement
 Quality:
 Describes the state of the product based on the
type, number, rate, and severity of defects
found and fixed during the course of product
development
 Progress:
 Measurements derived under this aspect, either
through audits or raw data, are useful in
determining the overall completeness status of
the project.
29
Environment Discipline
 Purpose: Focuses on the activities
necessary to configure the process for a
project. Defines what improvements are
realistic under the project’s circumstances:
• Current process
• Current tools
• Current staff skills and capabilities for change
• Current problems and possible improvement
objectives
30
Important Environment Artifacts
Development Process: is a configuration of
the underlying RUP framework that meets
the needs of the project following it.
Development Case: describes the
development process that you have chosen
to follow in your project.
31
Development Case
 Reflects decisions made by team leaders of
the project
 Describes the development process that
you have chosen to follow in your project
 Is contained in Environment discipline
 Is created early in Inception, and updated
during project
Select from
RUP knowledge base
Minimize cost
of process definition
32
Development
Case
Development Case (Partial Example)
Artifacts
How to Use
Review
Details
Tools Used / Templates /
Examples
Incep
Elab
Const Trans
Glossary
Must
Must
Must
Must
Formal –
External
MS Word/Template: Glossary
Requirements
Management Plan
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Requirements
Management
Software
Requirements
Specification
Must
Must
Must
Must
Formal –
External
MS Word/Template: Software
Requirements Specification
Supplementary
Specification
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Supplementary
Specification
Use-Case Model
Should
Must
Must
Must
Formal –
External
Rose/Template: Use-Case Model
Use-Case Package Could
Could
Could
Could
Informal
Rose/Embedded
Stakeholder
Requests
Must
Must
Must
Must
Formal –
External
ClearQuest/Template: Stakeholder
Requests
Vision
Must
Must
Must
Must
Formal –
External
RequisitePro/Template: Vision
33
Project Management Discipline
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.
Main artifacts are:
 Project Plan
 Risk Management Plan
 Business Case
 Iteration Plans
34
Business Case
 Involves estimation of development costs
based on:
 The current Product Directory Structure
 Make, buy, reuse decisions made by the
architect
 Estimation of project benefits to establish
ROI
 Estimation fidelity improves as the project
goes through phases (shown before)
 Typically the “justification” is made for the
next phase, with scoped estimates for the
rest.
35
Iteration Plan
 Focus during Inception and Elaboration
 Project scoping and risk reduction, especially
architectural risks
 Focus during Construction and Transition
 Development efficiency and product quality
36
Discussion: Strategies for Iterative Development
Incremental (1)
Incremental delivery (3)
ElaboInception ration
Prel.
Iteration
#1
Construction
#2
#n+1
#..
#m
#m+1 #m+2 . . Iter.
No.
Prel.
#1
Iteration
Co
nc
ep
tu a
Elaboration
#2
lp
r ot
o ty
pe
Transition
Prel.
#1
#2
#n+1
Iteration
Co
Ar
Re
ch
nc
lea
i te
ep
se
c
tu a
tur
al
lp
b
r ot
as
o ty
eli
pe
ne
#..
#m+1 #m+2 . . Iter.
No.
De
live
ry
#m
“Grand design” (4)
Evolutionary (2)
Inception
Inception
Transition
Construction
Elaboration
#n+1
#..
Construction
Inception
Transition
Elaboration
Construction
Transition
#1
#m+1 #m+2 . . Iter.
No.
Ar
Re
De
ch
lea
live
i te
se
ry
ctu
r al
ba
se
lin
e
#m
Co
37
nc
ep
tu
Ar
ch
al
pr o
i te
to t
#2
Re
ctu
ra
yp
e
lb
as
eli
ne
lea
#3 . .
De
se
Iter.
No.
live
ry
Planning for Iterative Development
Project Plan
Phase Plan
Iteration Plan (current)
Phases and major
milestones
What and when
Iterations for each phase
Number of iterations
Objectives
Duration
Iteration Plan (next)
“Roadmap”
Coarse-grained
Plan
38
Fine-grained
Plans
RUP Planning Guide for Microsoft® Project 2002
 Free download available on RDN
 Allows you to rightsize your project plan by
helping you to:
 plan the number of iterations to include in each
project phase
 incrementally plan each iteration by selecting
from a suggested list of:
• tasks to be undertaken
• potential deliverables and artifacts to be
produced
• roles to be responsible.
 Contains one-click access to RUP
39
What You Can Do in the RUP Planning Guide
Wizards allow you to
select how many
iterations you want in
each phase, as well
as which disciplinebased RUP activities
you want in each
iteration.
Wizards allow you
to select what
deliverables you
want in each
iteration, and to
attach activities or
roles to them.
40
Analysis & Design Discipline
Purpose:
 Transform the requirements into a design
of the system-to-be
 Evolve a robust architecture for the
system
 Adapt the design to match the
implementation environment
Primary artifact is the Design Model.
41
A Design Model:
 Is an object model describing the realization
of use cases
 Serves as an abstraction of the
implementation model and its source code
 Is used as essential input to activities in
implementation and test
42
Use Cases Drive Analysis & Design
Analysis Model (optional)
Use-Case Model
Analysis and
Design
Design Model
Supplementary
Specifications
Architecture
Document
43
Data Model
Use-Case Realization in Analysis & Design
<<realizes>>
Use Case
(Use-Case Model)
Use Case
Use-Case Realization
(Design Model)
Sequence Diagrams
Class Diagrams
44
Collaboration Diagrams
Use-Case Analysis & Design
 The complete behavior of a use case is
allocated to collaborating classes.
45
Sample UML Class Diagram
A University Course Registration System
<<boundary>>
MaintainScheduleForm
<<boundary>>
MainForm
// select maintain schedule()
1
0..1
+ // open()
+ // select 4 primary and 2 alternate offerings()
1
1
<<boundary>>
CourseCatalogSystem
1
0..*
<<control>>
RegistrationController
// add courses to schedule()
// get course offerings ()
// get course offerings()
0..1
1
<<entity>>
Schedule
// create with offerings()
46
Sample UML Sequence Diagram
:
: Student
:RegisterForCoursesForm
:
:RegistrationController
:
:CourseCatalogSystem
: Course Catalog
1: create schedule( )
2: get course offerings( )
3: get course offerings(forSemester)
4: get course offerings( )
5: display course offerings( )
6: display blank schedule( )
47
Implementation Discipline
Purpose:
 Implement classes and objects in terms of
components and source code
 Define the organization of the components
in terms of implementation subsystems
 Test the developed components as units
 Create an executable system
Primary artifact is Implementation Model.
48
What is an Implementation Model?
 An Implementation
Model consists of:
 Components
 Implementation
Subsystems
Telephone Banking
 Components include:
A
 Deliverable
components, such as
executables
 Components from
which the deliverables
are produced, such as
source code files
<<import>>
<<compilation>>
Trading Services
B
Components and implementation
subsystems in a Telephone Banking
System.
49
Build
A build:
 Is an operational version of a system or part
of a system.
 Demonstrates a subset of the capabilities
provided in the final product.
 Is an integral part of the iterative lifecycle.
 Provides review points.
 Helps uncover integration problems as soon
as they are introduced.
50
Test Discipline
Purpose:
 Finding and documenting defects in software quality
 Generally advising about perceived software quality
 Proving the validity of the assumptions made in design
and requirement specifications through concrete
demonstration
 Validating the software product functions as designed
 Validating that the requirements have been implemented
appropriately
The Test discipline:
 Focuses primarily on the evaluation or assessment of
quality realized through a number of core practices
 Acts in many respects as a service provider to the other
disciplines
51
Types of Test
Functionality
Performance
Function test
Benchmark test
Security test
Contention test
Volume test
Usability
Usability test
Reliability
Load test
Performance profile
Supportability
Configuration test
Integrity test
Installation test
Structure test
Stress test
Notice the match with Supplementary
Specifications Types.
52
Test Automation and Tools
 Data acquisition tools
 Static measurement tools
 Dynamic measurement tools
 Simulators or Drivers
 Test management tools
53
Deployment Discipline
 Purpose: Manage the activities associated
with ensuring that the software product is
available for its end users, such as:
 Product deployment
 Testing at the installation and target sites
 Beta testing
 Creating end-user support material
 Creating user training material
 Releasing to customer (in the form of shrinkwrapped package, download site, etc.)
54
Use Cases and End-User Documentation
Use-Case Model
Deployment
Supplementary
Specification
55
End-User Support Material
•User’s Guide
•Online Help
•Demos
•Tutorials
•Training Material
Review
 RUP content is organized into disciplines. A
discipline is a collection of related activities
that are related to a major “area of concern.”
 Disciplines group:
 Activities that are related
 The roles that perform those activities
 The artifacts that result from those activities
 Most disciplines produce models.
 Activities in disciplines have dependencies
that cross discipline boundaries.
56
Exercises
Complete Module 4 Exercise 1: Artifact
Evolution Through Phases in the
Exercises section of your student manual.
This exercise will allow you to become
familiar with some RUP artifacts and how
they evolve through phases.
Complete Discussion Points associated with
Exercise 2.
57
58