Intro to

Rational Unified Process

Software Process Improvement
Marion Lepmets
8.12.2003

Tarkvara-arendus raamistik
Tarkvara-arendus

Tarkvara-arendus
protsess
Mude lid:
ISO/IEC 15504,
CMM-SW, jt.
RUP process

Tarkvara-arendus
vahendid
Tarkvara vahendid:
MS Project,
Rational Rose, jt.
RUP product

Tarkvara-arendus
metoodika
Me e todid:
Spiral,
Waterfall, jt.
RUP approach

Rational Unified Process - RUP

Software development approach:
Iterative
Architecture-centric
Use-case-driven
Software engineering process:
Who is responsible for what
How things are done
When to do them
Process product:
Several out-of-the-box Process Configurations and
Process Views that guide developers in sw development

RUP Approach
Essential Principles:
Attack major risks early and continuously
Ensure that you deliver value to your customer
Stay focused on executable software
Accommodate change early in the project
Baseline an executable architecture early on
Build your system with components
Work together as one team
Make quality a way of life, not an afterthought
RUP Approach

RUP vs Waterfall
Waterfall development approach
Development phases are in a strict sequence
Leaves key team members idle for extended period of
time
Leaves testing to the end of the project lifecycle
RUP approach
Iterative: a sequence of incremental steps or iterations
Each iteration includes most development disciplines
Each successive iteration builds on the work of previous
iterations
Early iterations focus on requirements, later iterations
on implementation and testing
RUP Approach

Iterative approach
Iterative is superior to waterfall:

Accommodates changing requirements

Integration is not one big bang at the end of the project
Risks are discovered and addressed during early integrations
Reuse is facilitated
Defects can be found and corrected over several iterations
Better use of project personnel
Team members learn along the way
The development is improved along the way

The number, duration and objectives of iterations need to be

carefully planned
Tasks and responsibilities of participants need to be defined

RUP Approach

RUP Process
A well-defined software engineering process
The process has two structures:
Dynamic structure: shows how the process, expressed
in terms of cycles, phases, iterations, and milestones,
unfolds over the lifecycle of a project. Represents the
time dimension.
Static structure: shows how process elements
activities, disciplines, artifacts and roles are logically
grouped into core process disciplines (workflows).

RUP Process

Dynamic Structure of Rational

Unified Process
RUP divides a project into four phases:
Inception phase:
Understand the scope of the project
Build the business case
Get stakeholder buy-in to move ahead

Elaboration phase:
Mitigate major technical risks
Create a baseline architecture
Understand what it takes to build the system

Construction phase:
Build the first operation version of the product

Transition phase:
Build the final version of the product and deliver it to the customer

Each phase contains one or more iterations

RUP Process

Static Structure of Rational

Unified Process (1/2)
How process elements are logically grouped into

core process disciplines

Process describes who is doing what, how and when
Four key modeling elements of the RUP:
The who Roles
The how Activities:
Thinking steps understanding the task
Performing steps creating or updating artifacts
Reviewing steps inspecting results against a criteria

The what Artifacts

The when Workflows

RUP Process

Static Structure of Rational

Unified Process (2/2)
RUP Disciplines:
Business modeling
Requirements management
Analysis and design
Implementation
Deployment
Test
Project management
Change management
Environment
RUP Process

RUP Product
RUP product constitutes a complete process

framework composed of several integrated

parts:

Best practices
Process delivery tools
Configuration tools
Process authoring tools
Community/Marketplace
RUP Product

The Spirit of RUP

Attack major risks early and continuously
Ensure that you deliver value to your customer
Stay focused on executable software
Accommodate change early in the project
Baseline an executable architecture early on
Build your system with components
Work together as one team
Make quality a way of life, not an afterthought

Attack Risks Early

Attack major risks early and continuously, or

they will attack you!, Tom Gilb

Unaddressed risks
Correct architecture
Accurate project estimation

Deal with risks at the beginning of each iteration

The right architecture design, implement and test

it in elaboration phase
Attack risks constantly

Deliver Value to Your Customer

Continuous feedback loops from customers
Use case driven approach
Focus on users perspective
Validate the design and implementation with
respect of user requirements through sequence
or collaboration diagrams
Solid basis for writing user manuals

Focus on Executable Software

Measure progress by measuring executable

software
Artifacts other than the actual software are
supporting artifacts
Minimise the number of artifacts produced to
reduce overhead

Accommodate Change Early in

the Project
Cost of change to business solution
Cost of change to the architecture
Cost of change to the design and

implementation
Cost of change to the scope
Change management

Baseline Executable Architecture

Early On
Primary objective of Elaboration phase - baseline

a functioning architecture
Architecture comprises of software systems most
important building blocks and their interfaces
Architecture provides a sceleton structure of the
system 10-20% of final amount of code
Accurate assessments of resource and time estimates of
the project
New members are easily introduced to the project
Ready-made solutions to common problems

Build Your System With

Components
Functional decomposition architecture
Component-based architecture
Systems more resilient to changes in
requirements, technology and data
Encapsulation
Reuse

Work Together as One Team

Teams are organised around architecture
Communication between team members
Reduce the amount if documentation to the

extent possible

Make Quality a Way of Life

Iterative development allows to initiate

testing much earlier than waterfall

development
RUP requires to test capabilities while
implementing increase on quality
More testing
Quality in every development phase

Comparison of processes: RUP, agile

methods and government standards
Low Ceremony: produces minimum supporting

documentation and has little formalism in the

working procedure
High Ceremony: comprehensive supporting
documentation and traceability maintained among
artifacts
Waterfall: linear approach with late integration and
testing
Iterative: risk-driven development approach with
early implementation of an architecture and early
integration and testing

Agile Development: Low Ceremony,

Iterative Approach
Flexibility and ability to adapt to evolving

business environments
Respond to changes that occur during the process
Iterative development with strong focus on
executable software
Minimising the ceremony surrounding software
development
Increasingly complex projects require more
ceremony than a small project

Process Assessment Frameworks:

CMM, CMMI and ISO/IEC 15504
Companies in need of high ceremony

approaches:

Complex systems
Distributed teams
Cost of maintenance is low
Cost of development is high
Time to market slower than for low-ceremony
approaches

The RUP: Iterative Approach with

an Adaptable Level of Ceremony
RUP is a customisable process framework
Users can produce a variety of processes or

RUP configurations:
Light RUP configurations with low ceremony
Average RUP configurations with an average
level of ceremony
Large, more formal RUP configurations with
high ceremony

How Iterative Do You Want to Be?

For a highly iterative, risk-driven approach

with continuous integration and testing you

need:
Know-how
Good process support
Good tool support

How Much Ceremony Do You

Want?
Project factors for lower ceremony:
Operating in a rapidly changing marketplace
Co-located teams
Small teams
Less technical complexity
Project factors for higher ceremony:
Large-scale development
Distributed development
Technically complex projects
Complex stakeholder relationships

SPI Software Process

Improvement
Software Process Assessment
Software Process Improvement
Benefits of SPI:
Increase in productivity (10-30% - judged by
companies)
Lifecycle of production shortens
Traceability of results possible transparency
Personnel skills and know-how growing
The management and roles in organisation clarified

Tarkvaraprotsesside parandamise etapid

Improvements in
organisational units
Organisations needs software process

1.
Examine
organisations
needs

Software process
improvement request
Institutionalised
improvements

Identified
scope and
priorities

8.
Monitor
performance

Improvement
initiation

Validated
improvement
results

7.
Sustain
improvement
gains

6.
Confirm
improvements

Re-assessment
request

Analysed
re-assessment
results

2.
Initiate process
improvement

Preliminary process
improvement
programme
plan
3.

Prepare and
conduct process
assessment

Assessment
request
(Parts 3 and 4)

current assessed
capability

4.
Analyse results
Assessment
and derive
action plan
results

Industrial benchmarks
Practice descriptions from
the assessment model

Approved
action plan

Implemented
improvements
5.
Implement
improvements

Process improvement programme plan for

capability determination.
Target capability profiles from
capability determination
(Part 8)

(Part 2)

Software Process
Models and Standards
ISO/IEC 15504 Information Technology:

Process Assessment
CMM-SW Capability Maturity Model for
Software
CMMI staged and continuous representation
ISO 9001 Quality systems-Model for quality
assurance in design, development, production,
installation and servicing
BOOTSTRAP model and methodology
ISO/IEC 12207 International Standard of
Software Life-cycle Processes

Definitions
Process: a set of interrelated activities, which transform inputs into

outputs
Practice: a software engineering or management activity that
contributes to the creation of the output (work products) of a process
or enhances the capability of a process
Process assessment: a disciplined evaluation of an organisations
software processes against a model compatible with the reference
model
Process improvement: action taken to change an organisations
processes so that they meet the organisations business needs and
achieve its business goals more effectively
Process capability: the ability of a process to achieve a required goal
Process performance: the extent to which the execution of a process
achieves its purpose

Marion Lepmets
Tallinna Tehnikalikool
Arvutitehnika instituut
Raja 15, Tallinn 12617
Telefon: +372 6202 260
Email: marion.lepmets@ttu.ee
www: http://www.pori.tut.fi/~marion