The Unified Software Process:

Best Practices for Software Development Teams

General Information

Joel Pech, Software Engineering Specialist on
Rational Software field team for IA-KS-NE & KC, MO
jpech@rational.com, 319-228-8781

Unified Software Development Process,
by Ivar Jacobson, Grady Booch and Jim Rumbaugh
Addison Wesley, 1999

Rational Unified Process
Our product that puts a unified software process on
each desktop (some graphics for todays talk are
from this product).

Agenda

Why Rational Software focuses on process

What is the problem
6 fundamental Best Practtices
Structure of the Unified Software Process
The Rational Unified Process product

Rationals Mission

Ensuring the success of customers

who depend on
developing or deploying software

Reality

Only 26% of software

projects succeed.
Standish Group, CHAOS Report, 1998

The Rules Have Changed

Release frequency

Enterprise
Enterprise IT
IT
ISV
ISV
Technical/Embedded
Technical/Embedded

Cost of failure

Complexity

The Challenge

and,
yet most tools
Software
are
for ...
development
is a
team sport ...

Individuals

The Answer: Elevate the Solution

Teams

Improve cross-functional
team productivity

Individuals

Improve individual productivity

Rational Elevates the Solution

Organizations

Improve multi-team proficiency

Teams

Improve cross-functional
team productivity

Individuals

Improve individual productivity

Rational Unifies Software Teams

Product Leadership
Leadership
Product

Requirements
Requirements
Management
Management
Visual
Visual
Modeling
Modeling
Automated
Automated
Testing
Testing

Products

Process

Tools

Best
Practices

Skills
Services

Manage
Requirements

Use
Component
Architectures
Model Visually

(UML)

Verify Quality
Change
Change
Management
Management

Control
Changes

Project
Technical
Project
Technical Support
Support &&
Tools
Tools Application
Application
Implementations
Implementations
Customer
Customer Success
Success

Education
Education
and
and Training
Training

Software Engineering
Engineering Leadership
Leadership
Software

Develop
Iteratively

Agenda

Why Rational Software focuses on process

What is the problem
6 fundamental Best Practtices
Structure of the Unified Software Process
The Rational Unified Process product

The Business Problem

Software:

Increasingly
more critical
Needs to be
delivered faster
Needs to be
higher quality

But...

We estimate
only 26% of
software projects
will succeed.
Standish Group
CHAOS Report
1998

Rationals Unique Approach

Requirements
Requirements
Management
Management
Visual
Visual
Modeling
Modeling
Automated
Automated
Testing
Testing
Change
Change
Management
Management

Develop
Iteratively

Customer Success
Best
Practices

Tools
Services

Manage
Requirements
Use
Component
Architectures
Model Visually
(UML)
Verify Quality
Control
Changes

Customer Tool
Project Best Practices Expert
Support Training Implementation Education Consulting

Software Development is a Job for Teams

Challenges
Performance
Engineer

Larger teams
Specialization

Analyst

Distribution
Rapid technology
change

Project
Manager
Developer
Tester
Release
Engineer

The Problem...

Processes are not linked
properly to tools, or are not
properly automated

If process is used, different
functional teams use
normally inconsistent
processes and modeling
languages

Most software projects use
no well-defined process.
Instead team members
(re-)invent process as they
go

Process
Process

Tool
Tool

??

Requirements
Requirements book
book
Test
Test process
process
Analysis
Analysis process
process
Design
Design book
book

??
??

??

??

??
??

??

Agenda

Why Rational Software focuses on process

What is the problem
6 fundamental Best Practtices
Structure of the Unified Software Process
The Rational Unified Process product

6 Fundamental Best Practices

Capturing experiences from
1,000s of projects
Develop
Iteratively
Manage
Requirements

Best
Practices

Use
Component
Architectures
Model Visually
(UML)
Verify Quality
Control
Changes

Best Practices Enable High-Performance Teams

Result
More Successful
projects

Performance
Engineer

Analyst

Develop Iteratively

Project
Manager

Manage
Requirements

Best
Best
Practices
Practices

Use Component
Architectures
Model Visually
Verify Quality
Control
Change

Developer
Tester
Release
Engineer

Practice 1: Develop Software Iteratively

An initial design will likely be flawed with respect to
its key requirements

Late-phase discovery of design defects results in
costly over-runs and/or project cancellation

The time and money spent implementing a

faulty design are not recoverable

Waterfall Development

Requirements
Analysis
Design
Code & Unit
Testing
Subsystem
Testing
System Testing

T I M E

Waterfall Development: Risk vs. Time

R
I
S
K

Requirements
Analysis
Design
Code & Unit
Testing
Subsystem
Testing
System Testing

T I M E

Iterative Development
Requirements
Analysis & Design
Planning
Implementation

Initial
Planning

Management
Environment
Deployment
Evaluation
Test
Each iteration
results in an
executable release

Risk Profile of an Iterative Development

Waterfall
Staffing

Inception

Elaboration

Construction

Risk

Transition

Preliminary
Iteration

Architect.
Iteration

Architect.
Iteration

Devel.
Iteration

Devel.
Iteration

Time

Devel.
Iteration

Transition
Iteration

Transition PostPostIteration
deployment

Iterative Development Characteristics

 Use Case Driven
 Risk Driven
 Architecture Centric

Iterative Development Advantages

 Critical risks are resolved before making large
investments
 Initial iterations enable early user feedback
 Testing and integration are continuous
 Objective milestones provide short-term focus
 Progress is measured by assessing
implementations
 Partial implementations can be deployed

Practice 2: Manage Requirements

Elicit, organize, and document required functionality and
constraints

Track changes and document tradeoffs and decisions

Business requirements are easily captured and
communicated through use cases

Use cases are important planning instruments
Use-Case Model

Use Cases drives

the work from
analysis through
test

realization

influenced by

verifies

Design Model
Implementation Model

Test Model

Catch Requirements Errors Early

Analyze
the problem

Elicit stakeholder
needs

Use an iterative
approach

Maintain traceability and

control of evolving
requirements

Gain agreement with the

customer

Model system-user
interaction

Establish a baseline and

change control process

Practice 3: Use Component Architectures

Design, implement and test your architecture up
-front!
up-front!

A systematic approach to define a good architecture

resilient to change by using well
-defined interfaces
well-defined

by using and reverse engineering components

derived from top rank use cases

intuitively understandable

Applicationspecific
Businessspecific

Component-based
Architecture with
layers

Middleware
Systemsoftware

Resilient, Component-Based Architectures

Resilient
 Meet current and future requirements
 Improve extensibility
 Enable reuse
 Encapsulate system dependencies

Component-based
 Reuse or customization of components
 Select from commercially-available components
 Incremental evolution of existing software

Practice 4: Visually Model Software

Capture structure and behavior of architectures and
components

Show how the elements fit together

Hide or expose details as
appropriate

Maintain consistency
between design and implementation

Promote unambiguous communication
Find
OK

Video Clip

Visual modeling improves our ability

to manage complexity

What Is the Unified Modeling Language?

The UML is a language for
 visualizing
 specifying
 constructing
 documenting

the artifacts of a software-intensive system

Visual Modeling Using UML Diagrams

Use case
diagram

Class diagram

Statechart
diagram

add file

DocumentList

Use Case 1

FileMgr

Actor A

Actor B

Document
add( )
delete( )

fetchDoc( )
sortByName( )

name : int
docid : int
numField : int
get( )
open( )
close( )
read( )
sortFileList( )
create( )
fillDocument( )

Use Case 2
FileList
fList
add( )
delete( )

add file [ numberOffile==MAX ] /

flag OFF
read() fill the
code..

Writing

Openning

close file

Use Case 3

close file
Reading

Closing

rep
Repository
(from Persistence)

File

read( )

GrpFile

name : char * = 0
readDoc( )
readFile( )

Collaboration
diagram

9: sortByName ( )

Repository

mainWnd : MainWnd

1: Doc view request ( )

read( )
open( )
create( )
fillFile( )

DocumentList

Deployment
diagram
Wi ndows95

Wi ndow95

FileManager

Wi ndows95

2: fetchDoc( )

Document

gFile : GrpFile

4: create ( )

-
.EXE
-

8: fillFile ( )

Wi ndows
NT

user :

Solaris

fileMgr : FileMgr

- .EXE

GraphicFile

3: create ( )

Alpha
UNIX
-.EXE

6: fillDocument ( )

File

FileList

IBM
Mainframe

7: readFile ( )
5: readDoc ( )

document : Document

repository : Repository

mainWnd
user

-
.

Wi ndows
NT

fileMgr :
FileMgr

document :
Document

1: Doc view request ( )

2: fetchDoc( )

gFile

repository

Component
diagram

3: create ( )

4: create ( )

5: readDoc ( )

-
- .

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

-

-
.

9: sortByName ( )

Sequence
diagram

Forward and
Reverse
Engineering

Target
System

Practice 5: Verify Software Quality

Create tests for each key scenario to ensure that all
requirements are properly implemented

Verify software reliability - memory leaks, bottle necks

Unacceptable application performance hurts as much
as missing functionality and unacceptable reliability

Test every iteration - automate test!
Cost

Software problems
are 100 to 1000 times
more costly to find
and repair after
deployment

Development

Deployment

Iteration 1

Iteration 2

Test Suite 1 Test Suite 2

Automated
Tests

Functionality

Testing in an Iterative Environment

Iteration 3

Test Suite 3

Iteration 4

Test Suite 4

Practice 6: Control Changes to Software

Change Request Management

Measurement

Configuration Management

Configuration Management Concepts

Decompose the architecture into subsystems

Assign subsystems to a team
Establish secure workspaces for each developer
 Provide isolation from changes made in other workspaces
 Control all software artifacts - models, code, docs, etc.

Establish an integration workspace

Establish an enforceable change control mechanism

Release a tested baseline at the completion of each
iteration

Change Request Management Concepts

Approved Decisions

New Feature

Change Control
Process

New Requirement
Fix Bug

Change requests come from

many sources throughout the
product lifecycle

Vision
Require.
& Use
Cases

Customer and
End-User Inputs
Marketing
Developer inputs

Code
Tests
Change
Request
System

Testers inputs

Measurement
Objective measurements provide meaningful
project status information
10

ging?
r
e
v
i
D
ng?
i
g
r
e
Conv

9
8

Priority 1
Defects

7
6
5
4
3

Closures per day

Discovery per day

2
1
0
11

12

13

14

15

16

Day

17

18

19

20

Best Practices Reinforce Each Other

Develop
Iteratively

Best
Practices

Manage
Requirements

Ensures users involved

as requirements evolve

Use Component
Architectures

Validates architectural
decisions early on

Model Visually
(UML)

Addresses complexity of
design/implementation incrementally

Verify Quality

Measures quality early and often

Control Changes

Evolves baselines incrementally

Summary: Best Practices of Software Engineering

The result is software that is

 On Time
 On Budget
 Meets Users Needs

Performance
Engineer
Analyst

Develop Iteratively

Project
Manager

Manage
Requirements

Best
Best
Practices
Practices

Use Component
Architectures
Model Visually
Verify Quality
Control
Change

Developer
Tester
Release
Engineer

Agenda

Why Rational Software focuses on process

What is the problem
6 fundamental Best Practtices
Structure of the Unified Software Process
The Rational Unified Process product

History
Project management

Rational Unified
Process 5.5

Project Web site template

Real-time
ROOM

Rational Unified
Process 5.1

Performance
testing
Business
Engineering
Configuration
& change Mgmt

Requirements
College

OMT
Booch

1999

UML 1.3
Example artifacts
E-development roadmap
Java programming guidelines
Objectory
UI design

1998

Data Engineering

Rational Objectory
Process 4.1
Rational Objectory
Process 4.0

Rational
Approach

UML 0.8

10/1997

UML 1.1

SQA
Process

12/1996

Objectory
Process 3.8

1995

Process Notation
Activity

Worker
Signifies a role
that may be
played by an
individual or a
team of
individuals in
the
development
organization

Use-Case
Specifier

responsible for

Use Case

Use-Case
Package

Describes a piece of
work a worker may
be asked to
perform.

Describe a
Use Case

Artifact
Signifies a piece of
information that is
produced, modified, or
used by a process

Workers Are Used for Resource Planning

Re s o urc e

Worker

Ac tivitie s

Paul

Designer

Define Operations
...

Mary

Use-Case Specifier

Describe a Use Case

...

Joe

Use-Case Designer

Distribute Behavior
...

Sylvia

Design Reviewer

Review Use-Case Model

...

Stefan

Architect

Define Use-Case View

Define Logical Viiew
...

Each individual in the

project is assigned to
one or several workers

Process Architecture
Time
Phases
Process Workflows

Inception

Elaboration

Construction

Transition

Business Modeling
Requirements
Analysis & Design

Content

Implementation
Test
Deployment

Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)

Iter.
#1

Iter.
#2

Iter.
#n

Iter.
#n+1

Iterations

Iter.
#n+2

Iter.
#m

Iter.
#m+1

Phases in the Process

Major
Milestones

Inception

Elaboration

Construction

Transition

time

The Unified Software Process has four phases:






Inception - Define the scope of project

Elaboration - Plan project, specify features, baseline
architecture
Construction - Build the product
Transition - Transition the product into end user community

Inception Phase
 Purpose

To establish the business case for a new system or for

a major update of an existing system
To specify the project scope

 Outcome

A general vision of the projects requirements, i.e., the

core requirements
Initial use-case model and domain model (10-20%
complete)

An initial business case, including:

Success criteria (e.g., revenue projection)

An initial risk assessment
An estimate of resources required

 Milestone: Lifecycle Objectives

Elaboration Phase
 Purpose

To analyze the problem domain

To establish a sound architectural foundation
To address the highest risk elements of the project
To develop a comprehensive plan showing how the project
will be completed

 Outcome

Use-case and domain model 80% complete

An executable architecture and accompanying
documentation
A revised business case, incl. revised risk assessment
A development plan for the overall project

 Milestone: Lifecycle Architecture

Construction Phase
 Purpose
To incrementally develop a complete software product
which is ready to transition into the user community

 Products

A complete use-case and design model

Executable releases of increasing functionality
User documentation
Deployment documentation
Evaluation criteria for each iteration
Release descriptions, including quality assurance
results
Updated development plan

 Milestone: Initial Operational Capability

Transition Phase
 Purpose

To transition the software product into the user

community

 Products

Executable releases
Updated system models
Evaluation criteria for each iteration
Release descriptions, including quality assurance
results
Updated user manuals
Updated deployment documentation
Post-mortem analysis of project performance

 Milestone: Product Release

Iterations and Phases

Releases

Inception

Preliminary
Iteration

Elaboration

Architect.
Iteration

Architect.
Iteration

Construction

Devel.
Iteration

Devel.
Iteration

Transition

Devel.
Iteration

Transition
Iteration

Transition
Iteration

An iteration is a distinct sequence of activities with an

established plan and evaluation criteria, resulting in an
executable release (internal or external).

Iteration Assessment
Iteration N Cost and
Schedule Actuals

Iteration N Assessment

Quality Assessment
for Iteration N

Test Results
Defect Density
Architecture
Stability
Other metrics

Compare iteration actual cost,

schedule, and content with iteration
plan
Determine rework (if any) to be done
Assign to future iteration(s)
Determine what risks have been
eliminated, reduced, or newly
identified in this iteration
Update project plan
Prepare detailed plan for next
iteration
Use revised risk list and select
appropriate scenarios

Revised Risk List

Revised Project Plan

Total Cost
Overall
Schedule
Scope/Content

Iteration N+1 Plan

Cost
Schedule
Content

Models and Workflows

Each major workflow describes
how to create and maintain a
particular model
Business
Modeling

Business Model

Requirements
Workflow
Analysis Design
Workflow

realized by
Use-Case
Model
implemented by
Design
Model

Implementation
Workflow
Test Workflow

verified by
Implementation
Model

Test
Model

Bringing It All Together...In an iteration,

Phases
Process Workflows

Inception Elaboration

you walk through

all workflows

Construction

Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment

Supporting Workflows
Workflows
group
activities
logically

Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)

Iter.
#1

Iter.
#2

Iter.
#n

Iter. Iter.
#n+1 #n+2

Iterations

Iter.
#m

Iter.
#m+1

Example of a Workflow

Agenda

Why Rational Software focuses on process

What is the problem
6 fundamental Best Practtices
Structure of the Unified Software Process
The Rational Unified Process product

Process Made Practical

Role-based activity support

Accessible, easy to use, web-enabled
Automated by tools
e-coach integrated with tools
Configurable and customizable

Process Delivery In the Past.

Thick binder on every developers shelf

.collecting dust
hard to understand, hard to use, seen as driving
overhead

Role-based Activity Support

Value-add to each team member

Detailed hands-on guidelines
Productivity-enhancing document templates
Non-intrusive
Activity

Worker
Signifies a role
that may be
played by an
individual or a
team of
individuals in
the
development
organization

Use-Case
Specifier

responsible for

Use Case

Use-Case
Package

Describes a piece of
work a worker may
be asked to
perform.

Describe a
Use Case

Artifact
Signifies a piece of
information that is
produced, modified, or
used by a process



Easy to Use

Interactive knowledge base accessible from tools

Web-enabled with powerful graphical navigation
Search engine, index...

Searchable
Accessible
Navigable
Easy to use

Automated by Tools
Microsoft
Visual Studio

Apex

VB Design
guidelines

Rose

Ada, C++ Prog.

guidelines

Tool mentors
Report generation scripts
Stereotype icons

SoDA

Tool mentors

Robot
Tool mentors
Test templates

RequisitePro
Tool mentors
Requirement templates

Purify
Quantify
PureCoverage

Tool mentors
CM guidelines
Tool mentors
Document templates

ClearCase

ClearQuest

Change management
guidelines
Tool mentors

e-coach - Tool Mentor

Tool Mentor Topics - Using ClearCase to...
Set Up the Implementation Model
Create an Integration and Build Workspace
Create Private Workspace
Check Out and Check In
Configuration Items
Promote Configuration Items
Baseline the Project
Release Subsystem(s)

e-coach - Extended Help

Context sensitive
process
guidance from
tools

Questions?

Please feel free to contact me at
jpech@rational.com or 319-228-8781

www.rational.com

IBM Application Framework for e-business
 www.ibm.com/ebusiness

Microsoft Windows DNA

 www.microsoft.com/dna