RATIONAL UNIFIED PROCESS

THE RATIONAL UNIFIED PROCESS

 RUP is an OO Software Development paradigm
from Rational, a unit of IBM.

 Goal :To develop high quality software that

meets the needs of its end-users, within a
predictable schedule and budget.

 Provides industry-tested practices for software and

systems delivery and implementation and for
effective project management.
FEATURES
 Process product -development team for the RUP
works closely with customers, partners, Rational's
product groups.
ensures that the process is continuously updated
and improved upon to reflect recent experiences and
evolving and proven best practices.
 models – creates & maintains models. No large

paper work.
The RUP is a guide for how to effectively use the
Unified Modelling Language that clearly
communicate requirements, architectures and
designs.
Originally created by Rational Software
 Configurable Process - No single process.
The Unified Process fits small development teams
as well as large development organizations
founded on process architecture that provides
commonality across a family of processes.
It can be varied to accommodate different
situations. It contains a Development Kit,
providing support for configuring the process to
suit the needs of a given organization.
 Best Practices - describes how to effectively
deploy commercially proven approaches to software
development for software development teams.
These are called “best practices” because are
commonly used in industry by successful
organizations.
EFFECTIVE DEPLOYMENT OF 6 BEST
PRACTICES
 Develop software iteratively
 Manage requirements

 Use component-based architectures

 Visually model software

 Verify software quality

 Control changes to software

DYNAMIC STRUCTURE: ITERATIVE
DEVELOPMENT

 An iterative process breaks a development cycle

into a succession of iterations.
 A development cycle is divided into a sequence of
four phases that partition the sequence of
iterations.
 The phases are inception, elaboration,
construction, and transition.
FROM SEQUENTIAL TO AN
ITERATIVE CYCLE
 Waterfall Risk
Risk

Risk Reduction

Iterative Risk

Time
THE PHASES
 RUP is divided into four phases is to distinguish
among the different focuses of activities at
different times in the project lifecycle.
 Inception - Do you and the Customer have a
shared understanding of the system?
 Elaboration - Do you have an architecture to be
able to build the system?
 Construction - Are you developing product?

 Transition - Are you trying to get the Customer

to take ownership of the system?
MANAGE REQUIREMENTS
 The RUP describes how to elicit, organize, and
document required functionality and constraints.
 easily capture and communicate business
requirements.
 use case – a way to capture functional
requirements and to ensure that these drive the
design, implementation and testing of software,
making it more likely that the final system
fulfills the end user needs.
ARCHITECTURE VIEW
 describes how to design an architecture
that is flexible, accommodates change, is
understandable, and promotes more
effective software reuse.
 architectural view - abstraction of a
model that focuses on its structure and its
essential elements.
 supports component-based software
development. The RUP provides a
systematic approach to defining an
architecture using new and existing
components.
VISUALLY MODEL SOFTWARE
 Shows how to visually model software to capture
the structure and behaviour of architectures and
components allows to hide the details.

 Visual abstractions - see how the elements of

the system fit together; maintain consistency
between a design and its implementation.

 Unified Modelling Language (UML), created

by Rational Software, is the foundation for
successful visual modelling.
 Class
Diagrams
Use-Case
Diagrams Object
Sequence Diagrams
Diagrams

Collaboration Models Component

Diagrams Diagrams

Static
Statechart Deployment Diagrams
Diagrams Diagrams
Activity
Diagrams
Dynamic
Diagrams
VERIFY SOFTWARE QUALITY
 Quality is reviewed with respect to the
requirements based on reliability, functionality,
system performance.
 Quality assessment is built into the process, in
all activities - planning, design, implementation,
execution ; involving all participants, and not
treated as an afterthought or a separate activity
performed by a separate group.
 Reliability

Functionality

Performance
CONTROL CHANGES TO SOFTWARE
 Describes how to control, track and monitor
changes to enable successful iterative
development.
 Guides you in how to establish secure workspaces
for each developer by providing isolation from
changes made in other workspaces and by
controlling changes of all software artifacts (e.g.,
models, code, documents, etc.).
 Brings a team together to work as a single unit
by describing how to automate integration and
build management.
PROCESS OVERVIEW
 The process can be described in two dimensions,
or along two axis:
 the horizontal axis represents time and shows
the dynamic aspect of the process as it is
enacted, and it is expressed in terms of cycles,
phases, iterations, and milestones.
 the vertical axis represents the static aspect
of the process: how it is described in terms of
activities, artifacts and workflows.
 In an iteration, you
walk through all
ITERATIVE MODEL GRAPH Phases
workflows

Process Workflows Inceptio Elaboration Construction TTransitio

n
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting
Workflows
Configuration Mgmt
Management
Workflows
group Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
activities Iteration(s) #1 #2 #n #n+ #n+ #m #m+
1
logically 1 2
Iterations
DEFINING THE PRODUCT VISION
AND THE BUSINESS CASE
 establish the business case for the system and
delimit the project scope.
 must identify all external entities with which the
system will interact (actors) and define the
nature of this interaction at a high-level -
identifying all use cases and describing a few
significant ones.
 The business case includes success criteria, risk
assessment, and estimate of the resources
needed, and a phase plan showing dates of major
milestones.
OUTCOME

 A vision document: a general vision of the core

project's requirements, key features, and main
constraints.
 An initial use-case model (10% -20%) complete).

 An initial business case, which includes business

context, success criteria (revenue projection,
market recognition, and so on), and financial
forecast.
 An initial risk assessment.

 A project plan, showing phases and iterations.

BUILDING AN ARCHITECTURAL
PROTOTYPE
 Analyse the problem domain, establish a sound
architectural foundation, develop the project
plan, and eliminate the highest risk elements of
the project
 An executable architecture prototype is built in
one or more iterations, depending on the scope,
size, risk of the project
 Should address the critical use cases identified in
the inception phase, which typically expose the
major technical risks of the project.
 Ensures that the architecture, requirements and
plans are stable enough, and the risks are
sufficiently mitigated, so you can predictably
determine the cost and schedule for the
completion of the development.
OUTCOME

 A use-case model (at least 80% complete) — all

use cases and actors have been identified & all
descriptions have been developed.
 A Software Architecture Description.

 An executable architectural prototype.

 A revised risk list and a revised business case.

 A development plan for the overall project

showing iterations and evaluation criteria for
each iteration.
 An updated development case specifying the
process to be used.
 A preliminary user manual (optional)
IMPLEMENTING THE SYSTEM
 a manufacturing process - emphasis on
managing resources and controlling operations
to optimize costs, schedules, and quality.
 The management mindset undergoes a
transition from the development of intellectual
property during inception and elaboration, to
the development of deployable products
during construction and transition.
 The outcome is a product ready to put in hands
of its end-users
OUTCOME

 The software product integrated on the adequate

platforms.
 The user manuals.

 A description of the current release.

TRANSITION PHASE
 Purpose : transition the software product to the
user community.
Once the product has been given to the end user,
issues usually arise that require you to develop
new releases, correct some problems, or finish the
features that were postponed.
 This includes:

• “beta testing” to validate the new system

against user expectations
• parallel operation with a legacy system that it
is replacing
• training of users and maintainers
ITERATIVE DEVELOPMENT
Requirements
Analysis & Design
Planning
Implementation
Initial
Planning Management
Environment
Deployment

Evaluation
Test
Each iteration
results in an
executable
release
BENEFITS OF AN ITERATION
APPROACH
 Risks are mitigated earlier
 Change is more manageable

 Higher level of reuse

 The project team can learn along the way

 Better overall quality

REASONS FOR FAILURE OF ITERATIVE
DEVELOPMENT
 Lack of planning of each iteration
 Poor choice of requirements to implement in
earlier iterations
 Focus on documents and reviews

 Treatment of early iterations as throw-away

prototypes
USING RATIONAL UNIFIED PROCESS – A CASE STUDY

Using RUP
•No restrictions or guidelines were put on the use of RUP

•Courses in RUP, and RUP Online (an electronic process guide on web) was purchased
and installed.

•No common guidance for the use of RUP in projects was given.

•The company had no defined goals for introducing RUP.

•It was basically based on a belief that RUP would increase the professionalism in
the company.

About Company
•Norwegian software consultancy company with 50 employees, located in two different
geographic offices.
•They are mainly developing software systems with heavy back-end logic and often with a
web front-end, typically portals. However, they also develop lighter solutions with most
emphasis on the front-end.