Rational Unified Process

Methodology used by Rational Rose

What is the Rational Unified
Process?
It 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 a predictable schedule and budget.
The Rational Unified Process is a guide for how to
effectively use the Unified Modeling Language
(UML).
The UML is an industry-standard language that
allows us to clearly communicate requirements,
architectures and designs.
The UML was originally created by Rational
Software, and is now maintained by the standards
organization Object Management Group (OMG).
The Rational Unified Process is supported by tools,
which automate large parts of the process. They
are used to create and maintain the various
artifactsmodels in particularof the software
engineering process: visual modeling, programming,
testing, etc.

They are invaluable in supporting all the
bookkeeping associated with the change
management as well as the configuration
management that accompanies each iteration.
The Rational Unified Process is a configurable process. No
single process is suitable for all software development.

The Unified Process fits small development teams as well as
large development organizations.

The Unified Process is founded on a simple and clear
process architecture that provides commonality across a
family of processes. Yet, 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.

The Rational Unified Process describes how to
effectively deploy commercially proven approaches
to software development for software development
teams.
These are called best practices not so much
because you can precisely quantify their value, but
rather, because they are observed to be commonly
used in industry by successful organizations.


The Rational Unified Process provides each team member
with the guidelines, templates and tool
mentors necessary for the entire team to take full advantage of
among others the following best practices
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
Develop software Iteratively

It is not possible to sequentially first define the
entire problem, design the entire solution, build the
software and then test the product at the end.
An iterative approach is required that allows an
increasing understanding of the problem through
successive refinements, and to incrementally grow
an effective solution over multiple iterations.
The Rational Unified Process supports an iterative
approach to development that addresses the highest
risk items at every stage in the lifecycle,
significantly reducing a projects risk profile.
As each iteration ends with an executable release,
the development team stays focused on producing
results, and frequent status checks help ensure that
the project stays on schedule.
An iterative approach also makes it easier to
accommodate tactical changes in requirements,
features or schedule.
Manage Requirements
The Rational Unified Process describes how to
elicit, organize, and document the required
functionality and constraints; track and document
tradeoffs and decisions; and easily capture and
communicate business requirements.
The Rational Unified Process captures many
of the best practices in modern software
development in a form that is suitable for a
wide range of projects and organizations.
Visually Model Software
The process shows you how to visually model
software to capture the structure and behavior of
architectures and components.
The industry standard Unified Modeling Language
(UML), created by Rational Software, is the
foundation for successful visual modeling.


Verify Software Quality
Poor application performance and poor reliability
are common factors which dramatically inhibit the
acceptability of todays software applications.
Hence, quality should be reviewed with respect to
the requirements based on reliability, functionality,
application performance and system performance.
The Rational Unified Process assists you in the
planning, design, implementation, execution, and
evaluation of these test types.
Control Changes to Software
The ability to manage change is making certain that
each change is acceptable, and being able to track
changes is essential in an environment in which
change is inevitable.


Process Structure
Two dimensions.
Horizontal axis represents time and shows
the lifecycle aspects of the process as it
unfolds.
Vertical axis represents core process
workflows, which group activities logically
by nature.
Two dimensions of RUP
The Rational Unified Process divides one
development cycle in four consecutive
phases :-
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase
Each phase is concluded with a well-defined
milestonea point in time at which certain critical
decisions must be made, and therefore key goals
must have been achieved.
Inception Phase
During the inception phase, you establish the
business case for the system and delimit the project
scope.
To accomplish this you must identify all external
entities with which the system will interact (actors)
and define the nature of this interaction at a high-
level.
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 milestones.
Inception objectives
Establish software scope and boundary conditions.
operational concept
acceptance criteria
descriptions of what is and what is not included

Discriminate critical Use Cases of the system
primary scenarios of behaviour

Exhibit at least one candidate architecture(The
Software Architect, based on past experience and the
current requirements, proposes a core set of
technologies and high-level designs for a new system)
Estimate overall cost
Estimate risks
Inception activities
Formulate scope of project
Plan and prepare a business case and evaluate
alternatives for risk management, staffing,
project plan.
Synthesise a candidate architecture
Outcome of inception
Product Scope :- Specifies the expected functionality and
objective of the proposed project.
A vision document :- Specifies high level goals and main
constraints.
Business case :- Indicated whether development of project
is economically feasible or not.
A Use-Case model survey all Use Cases and Actors that
can be identified so far.
An initial project glossary.

(An artifact is one of many kinds of tangible by-product produced
during the development of software)
Initial Use Case model (10%-20% complete)
A domain model static picture of scope
A business model (if necessary) workflow
A preliminary development case description to
specify the process used
One or several prototypes
Behavioural, Structural, Exploratory or Evolutionary.
Other Artifacts produced
Evaluation criteria at end
Agreement on scope definition and cost and schedule
estimates .
Requirements understanding as shown by the
correctness of the primary Use Cases.
Credibility of the cost and schedule estimates, priorities,
risks and development process.
Depth and breadth of any architectural prototype that
was developed.
Actual expenditure vs planned expenditure.
Example:-Account Manager, which captures the
functions related to creating and maintaining customer
accounts


Elaboration objectives
To analyse the problem domain
Establish a sound architectural foundation
Develop the project plan
Eliminate high-risk elements
Elaboration objectives
Define, validate and agree the architecture as
quickly as possible.

Agree the vision that came from the inception
phase.

Agree a plan for the construction phase.

Demonstrate that the architecture will support
this vision for a reasonable cost in a reasonable
time.
Elaboration activities
The vision is elaborated and a solid understanding is
established of the most critical Use Cases that drive
the architectural and planning decisions.

The Process, the infrastructure and the development
environment are elaborated, and the process, tools
and automation support are put into place.
Elaboration activities
The architecture is elaborated and components are
selected.

Potential components are evaluated.
make / buy / reuse decisions determine the construction
phase cost and schedule.
Architectural components integrated and assessed
against primary scenarios.
This is done iteratively.
Outcome of elaboration
Use Case model (at least 80% complete).
All Use Cases identified.
All Actors identified.
Most Use-Case descriptions developed.

Supplementary requirements.
(non-functional or not associated with a Use Case)

Software architecture description.
Outcome of elaboration
Executable architectural prototype
Revised risk list and revised business case
Development plan for overall project
course grained project plan, with iterations and
evaluation criteria for each iteration
Updated development case that specifies
process to be used
Preliminary user manual (optional)
Evaluation criteria at end
Is the vision of the product stable?
Is the architecture stable?
Does the executable demonstration show
that major risk elements are addressed?
Is construction phase sufficiently planned?
Do all stakeholders agree that current vision
is achievable, using current plan with
current architecture?
Is the cost acceptable?
Construction
All remaining components and application
features are developed and integrated into
the product
All features are tested thoroughly
Emphasis is placed on managing resources and
controlling operations to optimise cost, schedules
and quality
Parallel construction can accelerate the
availability of deployable releases
Construction objectives
Minimise development costs by optimising
resources and avoiding unnecessary scrap
and rework.
Achieve adequate quality as rapidly as
possible.
Achieve useful versions (alpha, beta or
other test releases) as rapidly as practical.
Construction activities
Resource management, resource control, process
optimisation.

Complete component development and testing
against the defined evaluation criteria.

Assessment of product releases against
acceptance criteria for the vision.
Outcome of construction
A product ready to put into the hands of end
users.
The software product integrated on the
adequate platforms.
The user manuals.
A description of the current release.
Evaluation criteria at end
Often called the beta release, is it ready?
Is the product release stable and mature enough to be
deployed in the user community?
Are the actual resource expenditures vs planned
expenditures still acceptable?
Transition may have to be postponed by one
release if the project fails to reach this milestone.
Transition
This moves the software project to the user
community.
After release, issues usually arise that require new
releases, either to correct problems or finish features
that were postponed.
This phase is entered when a baseline is mature
enough to be deployed in the end-user domain.
This means that some usable subset of the system has
beem completed to an acceptable level of quality and
that user documentation is available.
Transition phase includes
Beta testing to validate the new system against use
expectations.
Parallel operation with the legacy system that the
project is replacing
Conversion of operational databases.
Training of users and maintainers.
Rollout of the product to the marketing,
distribution and sales teams.
It concludes when the deployment baseline has
achieved the completed vision.
Transition objectives
Achieve user self-supportability.
Achieve stakeholder concurrence that
deployment baselines are complete and
consistent with the evaluation criteria of the
vision.
Achieve final product baseline as rapidly
and cost-effectively as practical.
Transition activities
Deployment-specific engineering, i.e. cutover,
commercial packaging and production, sales rollout,
and field personnel training.
Tuning activities, including bug fixing and
enhancement for performance and usability.
Assessing the deployment baselines against the vision
and the acceptance criteria for the product.
The activities depend on the goal
For fixing bugs, implementation and testing are usually
enough.
For new features, iteration is similar to construction phase.
Evaluation criteria at end
Is user satisfied?
Are the actual resources expenditures v
planned expenditures still acceptable?