Asma Shaheen

09-Ms-Se-07
Rational Unified Process
RUP is an object-oriented software engineering
process, provides a disciplined approach to assigning
tasks and responsibilities within a development
organization. Its goal is to ensure the production of
high quality software that meets the needs of its end
users, within schedule and budget.
What is the Rational Unified Process?
A software engineering process
Process framework
RUP building blocks
RUP is based on a set of building blocks, or content
elements, describing what is to be produced, the necessary
skills required and the step-by-step explanation describing
how specific development goals are to be achieved. Main
building blocks are the following
Roles (who) – A Role defines a set of related skills,
competencies and responsibilities.
Work Products (what) – A Work Product represents
something resulting from a task, including all the
documents and models produced while working through
the process.
Tasks (how) – A Task describes a unit of work assigned to
a Role that provides a meaningful result.
Static Structure
The Rational Unified Process model is built on three
entities: roles, activities, and artifacts.
Workflows relate activities, artifacts, and roles in
sequences that produce valuable results.
Example of the Workflow
Dynamic Structure: Iterative Development
The sequential, or waterfall, process is fine for small
projects.
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
Process Overview
Two Dimensions
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 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, workers and workflows.
Four Project Life cycle Phases
The RUP has determined a project life cycle
consisting of four phases
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase
Inception Phase
The primary objective is to establish the business
case for the system and delimit the project scope.
To accomplish this must identify all external
entities with which the system will interact
(actors). This involves 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 milestone.
Outcome of the inception phase
The outcome of the inception phase is:
A vision document: a general vision of the core project's
requirements, key features, and main constraints.
A 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.
Evaluation criteria for the inception phase
The project is checked against the following criteria:
Stakeholder concurrence on scope definition and
cost/schedule estimates.
Requirements understanding as evidenced by the fidelity
of the primary use cases.
Credibility of the cost/schedule estimates, priorities, risks,
and development process.
Depth and breadth of any architectural prototype that was
developed.
Establishing a baseline by which to compare actual
expenditures versus planned expenditures.
Elaboration phase
The purpose of the elaboration phase is to analyze the
problem domain, establish a sound architectural
foundation, develop the project plan, and eliminate
the highest risk elements of the project.
Outcome of the Elaboration phase
A use-case model (at least 80% complete) — all
use cases and actors have been identified, and
most use case descriptions have been developed.
Supplementary requirements capturing the non
functional requirements and any requirements
that are not associated with a specific use case.
A Software Architecture Description.
An executable architectural prototype.
A revised risk list and a revised business case.
Evaluation criteria for the elaboration phase
This phase must pass the Lifecycle Architecture
Milestone by meeting the following deliverables
Is the vision of the product stable?
Is the architecture stable?
Does the executable demonstration show that the
major risk elements have been addressed and credibly
resolved?
Do all stakeholders agree that the current vision can
be achieved if the current plan is executed to develop
the complete system, in the context of the current
architecture?
Is the actual resource expenditure versus planned
expenditure acceptable
Construction Phase
The primary objective is to build the software system.
In this phase, the main focus is on the development of
components and other features of the system. This is
the phase when the bulk of the coding takes place.
Outcome of the Construction phase
The outcome of the construction phase is a product
ready to put in hands of its end-users. At minimum, it
consists of:
The software product integrated on the adequate
platforms.
The user manuals.
A description of the current release.
Evaluation criteria for the construction
phase
This phase must pass the Initial Operational
Capability Milestone by meeting the following
deliverables.
Is this product release stable and mature enough
to be deployed in the user community?
Are all stakeholders ready for the transition into
the user community?
Are the actual resource expenditures versus
planned expenditures still acceptable?
Transition Phase
The primary objective is to 'transit' the system from
development into production, making it available to
and understood by the end user. The activities of this
phase include training the end users and maintainers
and beta testing the system to validate it against the
end users' expectations. The product is also checked
against the quality level set in the Inception phase.
Outcome of the Transition phase
“beta testing” to validate the new system against user
expectations
parallel operation with a legacy system that it is
replacing
conversion of operational databases
training of users and maintainers
roll-out the product to the marketing, distribution,
and sales teams
Evaluation criteria for the construction
phase
This phase must pass the Product Release Milestone, by
meeting the following deliverables
Is the user satisfied?
Are the actual resources expenditures versus planned
expenditures still acceptable?
Core Process Workflows
The core process workflows are divided into six
core “engineering” workflows:
1. Business modeling workflow
2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
And three core “supporting” workflows:
1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow
Core Processes
 In Business Modeling document business processes using so called
business use cases. This assures a common understanding among all
stakeholders of what business process needs to be supported in the
organization.
 The goal of the Requirements workflow is to describe what the
system should do and allows the developers and the customer to
agree on that description. To achieve this, elicit, organize, and
document required functionality and constraints; track and document
tradeoffs and decisions.
 The goal of the Analysis & Design workflow is to show how the
system will be realized in the implementation phase. Build a system
that:
 Performs—in a specific implementation environment- tasks and
function specified in the use-case descriptions.
 Fulfills all its requirements.
 Is easy to change when functional requirements change.
Core Processes
The purposes of Implementation Discipline are:
 To define the organization of the code in terms of implementation
subsystems that are organized in layers.
 To implement classes and objects in terms of components
 To test the developed components as units.
 To integrate the results produced by individual implementers into an
executable system.
The purposes of Test Discipline are:
 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 that defects are addressed prior to the deployment
of the software.
Supporting Processes
The purpose of the Deployment workflow is to successfully
produce product releases, and deliver the software to its end
users. It covers a wide range of activities including:
 Producing external releases of the software.
 Packaging the software.
 Distributing the software.
 Installing the software.
 Providing help and assistance to users.
The purpose of the Environment workflow is to provide
the software development organization with the software
development environment—both processes and tools—that
are needed to support the development team.
Cont..
The Change Management discipline in RUP describe
how to control the numerous artifacts produced by the
many people who work on a common project. Control
helps avoid costly confusion, and ensures that resultant
artifacts are not in conflict.
This Project management workflow focuses mainly on
the specific aspect of an iterative development process.
goal is to make the task easier by providing:
 A framework for managing software-intensive projects.
 Practical guidelines for planning, staffing, executing, and monitoring
projects.
 A framework for managing risk.
Six best practices
RUP effectively deploy commercially proven approaches to
software development.
Develop iteratively 
 It is best to know all requirements in advance; however, often this
is not the case. Several software development processes exist that
deal with providing solution on how to minimize cost in terms of
development phases.
Manage requirements 
 Always keep in mind the requirements set by users.
Use components 
 Breaking down an advanced project is not only suggested but in
fact unavoidable. This promotes ability to test individual
components before they are integrated into a larger system. Also,
code reuse is a big plus and can be accomplished more easily
through the use of object-oriented programming.
Cont..
Model visually 
 Use diagrams to represent all major components, users, and their
interaction. "UML", short for Unified Modeling Language, is one
tool that can be used to make this task more feasible.
Verify quality 
 Always make testing a major part of the project at any point of
time. Testing becomes heavier as the project progresses but should
be a constant factor in any software product creation.
Control changes 
 Many projects are created by many teams, sometimes in various
locations, different platforms may be used, etc. As a result it is
essential to make sure that changes made to a system are
synchronized and verified constantly.
Activities across one development cycle
Typical Iteration Plans
An iteration in the inception phase to define the
project vision and the business case
An iteration early in the elaboration phase to build an
architectural prototype
An iteration late in the construction phase to
implement the system
Defining the product vision and the
business case
Building an Architectural Prototype
Implementing the system
Implementing the Rational Unified Process
Step 1: Assess the Current
State
Step 2: Set (or Revise)
Goals
Step 3: Identify Risks
Step 4: Plan the Process
Implementation
Step 5: Execute the Process
Implementation
Step 6: Evaluate the
Process Implementation
Implementing the Rational Unified Process
Summary
Rational Unified Process, or RUP, is a configurable
software development process platform that delivers
practices and a configurable architecture.

Enables the developer to select and deploy only the