Download Rational Unified Process (RUP) - International Information

Rational Unified Process (RUP): A new way to look at Project
Development Life Cycle
Abstract:
The paper highlights the key concept of the iterative process of the software development
lifecycle- IBM Rational Unified Process (RUP) and the difference with Waterfall
methodology. Based on writer’s experiences with both of the Software development
lifecycle, the paper unfolds the basic difference of these methodologies along with
explaining RUP Iteration, which is time boxed mini Waterfall methodology, with the
chance of revisiting the methodology at the end of each cycle. The paper also moves
along explaining the description of the disciplines, artifacts with respective roles along
with what these artifacts capture as it progresses.
1
What is Project and how does the Project get started:
Project usually can be formulated by a company’s internal and external needs and
activities such as ‘Strategic Initiative’ which in other words part of Company’s Strategic
Plan, company’s business unit initiative, regulatory or compliance requirement,
information technology improvement and maintenance etc. There are several general
steps ‘an idea’ goes through prior it is being approved:
 Formulate an idea or concept
 Gain Management Support/Sponsorship
 Develop an appropriate Business Case
 Obtain resource commitments
 Begin project and follow chosen methodology
Software Project Life Cycle and difference between the methodologies:
“The Project Life Cycle refers to a logical sequence or stages of activities to accomplish
the project’s goals or objectives.” (Visitask, 2010) Waterfall and Rational Unified
Process (RUP) are two proven but very different methodologies for initiating and
managing projects in order to ensure successful on time implementation of a project
within budget and with expected functionality. The key difference between Waterfall
methodologies and RUP can be segmented in few practices.
2
RUP is an Iterative Development process where the team builds the system in smaller
portion focusing on the risk early. Each smaller portion which is called ‘iteration’ is a
mini-waterfall method resulting in an executable portion of the system. Waterfall on the
other hand focuses on to complete everything in succession. Finish the requirements, and
then design the system, then code and then test. Below figure shows how feedback loop
is confined to the previous step.
Figure 1 Disciplines in Waterfall model (Wapedia. 2011).
Also in RUP Risk management is critical to where as Risk Management minimally
influence the process in Waterfall method.
RUP also is a ‘Use Case driven’ methodology for capturing requirement where Use
Cases are usually description of the function in narrative, plain English of the primary
input and in Waterfall requirements often contain design and implementation
information and most cases requirement captured in declarative statement. (Idiom
Software Ltd .2011)
Also in Waterfall method requirement specs are very large and stand on its own. It is very
inefficient to track from lower to higher level of detail. In RUP details unfolds as
3
progressive level where successive level provides more depth than the previous level
.Also test cases can be traced to the requirements they validate.
What is RUP:
RUP is the short form of IBM Rational Unified Process which focuses on performing all
of the software development tasks in smaller time segment referred to as iterations. The
iterations move through phases that have specific goals. RUP is supported by the use of
the Rational tool set.
RUP is based on following practices:
 Develop software iteratively
 Manage Use Cases and requirements
 Use component based architecture
 Model software visually
 Verify software quality
 Control changes to software (IBM Developer Works.2004)
Below Figure 2 references Phases, Disciplines and Iterations within RUP. Each discipline
is expressed in terms of roles (who performs the task), activities (how they perform these
tasks), and artifacts (what the activity achieves). A role defines the behavior and
responsibilities of an individual, or a group of individuals, responsible for activities and
artifacts. (IBM Developer Works.2004)
4
Figure 2: Phases, disciplines and iterations in RUP (IBM Corporation.2007)
Disciplines:

Business Modeling: The modeling techniques which is used to define business
processes.

Requirements: The technique of eliciting stakeholder requests and transforming
them into set of requirements that provides the scope for the project the system to
be built and provide detailed requirements for what the system must do.

Analysis and design: The process of transforming Requirements into the
specifications for the design of the software the project will develop.

Implementation: The process of developing, organizing, and unit testing and
integrating the components implemented based on design specifications.
5

Test: The process of evaluating and assessing the product quality.

Deployment: The activities associated with ensuring that the software product is
available for its users.

Configuration and change management: The process of controlling and
synchronizing the creation of the set of work products composing a software
system.

Project Management: Activities that focus on project planning, risk management,
monitoring progress and metrics.

Environment: The management of the software development environment that
supports the development team, including both processes and tools.
Phases and Iterations:
RUP is composed of four phases. Inception, Elaboration, Construction and Transition.
Since RUP follows an iterative approach, a phase may consist of one or more iterations.
Inception:
Inception is Lifecycle Objective Milestone of the project where project team and stake
holders agree on scope via Vision & Outlined Use Cases, Use Case Prioritization Matrix
have been drawn where roughly 20% of requirements have been detailed.
Goal: to achieve concurrence among all stakeholders on the objective of the project. The
phase is important for both new development and enhancements; however there is more
emphasis on this phase for new development efforts.
6
The major objectives of the Inception phase are –

Establishing the project’s software scope and boundary conditions,
including an operational vision, acceptance criteria and what is intended to
be the product and what is not.

Discerning the criteria use cases of the system: the primary scenarios of
the operation that will drive the outcomes of the project.

Estimating the overall cost and schedule for the project in high-level.

Estimating potential risk or sources of unpredictability.

Preparing the supporting environment for the project.
Elaboration:
Lifecycle Architecture Milestone of the project where candidate architecture has been
completed and technical risk mitigated. 80% to90% of requirements has been detailed in
this phase.
Goal: to baseline the architecture and design of the system to provide a stable basis for
the bulk of the development effort in the next phase, Construction.
The major objectives of this phase are –

To ensure that the architecture, requirements and plans are stable enough
and the risks sufficiently mitigated to be able to predictably determine the
cost and schedule for the completion of the development. For most
projects passing this milestone also corresponds to the transition from a
7
light-and-fast, low-risk operation to a high cost and high risk operation
with a substantial organizational inertia.

To address all architecturally significant risks of the project

To establish a base lined architecture which typically exposes the top
technical risks of the project.

To produce an evolutionary prototype of production quality components,
as well as possibly one or more exploratory, throw-away prototypes to
mitigate specific risks.

To demonstrate that the baselines architecture will support the
requirements of the system at a reasonable cost and in reasonable time.

To establish a supporting environment.
Construction:
This phase produces the product with Initial Operational Capability. Product is working
in this phase and system test completed.
Goal: to clarify the remaining requirements and completing the development of the
system based upon the base lined architecture.
The major objectives of this phase are –

To minimize development costs by optimizing resources and avoiding
unnecessary scrap and rework.

Achieve adequate quality as rapidly as practical.
8

Complete the analysis, design, development and testing of all required
functionality.

To iteratively and incrementally develop a complete product that is ready
to transition to its user community.

To decide if the software, the sites and the users are all ready for the
application to be deployed.
Transition:
In this phase Product is completed and waiting for release.
Goal: to ensure that the software is available to users.
The major objectives of this phase are –

Beta testing to validate the new system against user expectations.

Beta testing and parallel operation relative to a legacy system that it’s
replacing.

Training of users.

Tuning activities such as bug fixing, enhancement for performance and
usability.

Obtaining acceptance of the final product from the stakeholders through
methods such as User Acceptance Testing (UAT).
Iterations:
The iterations are set period of time within a project in which the project team produces
a stable, executable portion of the project’s scope. Iterations are ‘time boxed’ which
9
means the schedule for an iteration should be regarded as fixed, and the scope of the
iterations content will be actively managed to meet that schedule. The number of
iterations will be determined by what is required within each phase to reach the life cycle.
Content management is mostly iteration based also early and continuous risk mitigation is
a big priority in all iteration. Iteration generally ranges from one week to three months.
Iteration also accommodate changing requirements, product improvement and refinement
facilitated in iteration, increased learning and product improvement and increased
reusability are few usability of iterations.
Artifacts:
“Artifacts are either final or intermediate work products produced and used during a
project. Artifacts capture and convey project information, and may take various shapes or
forms.” (Rational Software Corporation. 2003) To make developing a complete software
system manageable, the artifacts are organized into sets. Several artifacts can be used in a
number of disciplines. There are several Artifacts or work products required to produce
throughout the stages in Project Life Cycle. Below are the few.
Vision:
This artifact provides a high-level basis for the more detailed technical requirements that
are visible to the Stakeholders. It is written from the customers' perspective, focusing on
the features of the system and acceptable levels of quality (non-functional requirements)
Basically the Vision Work Product is the mechanism in RUP to capture the project’s
scope.
10
There are 4 key areas of the Vision:
●
Problem Statement
●
Stakeholder and User Descriptions
●
Stakeholder Needs
●
System Features
Use Case Diagram – Use Case
A Use Case is a textual specification describing the interaction between actors and the
system. The Use Case diagram provides an overview of the system's intended behavior
and intended functionality for the system. It is a visual representation of how the users of
a system interact with it.
Figure: 3 shows how Use Case diagrams receive input from Vision doc and also Use
Case diagrams contain Use Cases. (Rational Software Corporation. 2003)
11
Figure 3: Use Case Diagram (Rational Software Corporation. 2003)
Referring to figure 3 , Use Case diagram ‘the stick figure’ refers as Actor and the ‘ovals’
refer use case model element. There will be one use case model element for each
identified Use Case.
An Actor is a role that a person, another system, device, and time or clock plays when
directly interacting with the system. The Use Case is written from the Actors point of
view which describes what the system must do, not ‘how’ it will be implemented in the
system.
Supplementary Spec:
Supplementary Spec captures the system requirements that are not readily captured in the
Use Cases of the Use Case model.
Quality attributes of the system to be captured through Supplementary Specs, including:
•
Usability requirements
•
Performance requirements
•
Reliability requirements
•
Supportability requirements
Below figure 4 refers to the Supplementary Specification which captures the Technical
requirement that did not get captured in Use Case.
12
Figure 4: Supplementary Specification
Use Cases and Supplementary Specs are basically the detailed requirement for the
project. In most cases Functional and Business Rules were separated from detailed
requirement document of Waterfall model and translated into Use Case Models and
Specifications. System-wide Non Functional requirement, System-Wide Business Rules
and Design Constraints are translated into Supplementary Specifications.
The Requirements Prioritization Matrix:
The Requirements Prioritization Matrix is an Excel base Spreadsheet tool used to rank all
identified and outlined Use Cases and/or other requirements to enable iteration planning.
It has several color coded categories where it ranks the issues on the basis how much the
issues impact Use Cases/or other key requirements.
13
There are 4 categories in the Matrix:
Critically Ranked : Use Cases and/or other requirements have one or more attributes:
technical risk, domain contribution, non-functional issues, and business value.
Secondarily Ranked : Use Cases and/or other requirements support the Critical ones and
have a modest impact on architecture.
Ancillary Ranked : Use Cases and/or other requirements are of have no impact on
architecture and are of least importance to the project.
Out of Scope : Use Cases and/or other requirements are functionality that has been taken
out of scope through negotiation if trivial or a change management process if material.
The Master Test Plan and Strategy:
This Artifact facilitates the planning, control and strategic approach of the test effort. It
defines the general approach that will be employed to test the software and to evaluate
the results of that testing, and is the top-level plan that will be used by managers to
govern and direct the detailed testing work. Apart from helping to estimate the project
testing resource it also provides the visibility to the stakeholders the test effort to gain the
approval.
There are 9 key areas of the Master Test Plan and Strategy•
Purpose, Intended Audience and Scope- The purpose of this document is
to recommend and describe the testing strategies to be employed; intended
Audience is Stakeholders both internal and external and the scope such as
the functionality and usability of the intended project.
14
•
Governing Evaluation Mission : To ensure that a delivered solution meets
the business needs on an ongoing basis.
•
Target Test Items : Which parts of the project need to be tested.
•
Test stages: Type of tests needs to occur-Unit, integration, User
Acceptance, Regression etc.
•
Test Approach: How to measure the extent of testing. When to stop testing
along with test exclusion.
•
Technique: Objective of each test, required tool, success criteria, special
considerations etc.
•
Support tools, Environment: Supporting tools and the test environment
such as Database name, QA repository, End User Views.
•
Master Test Plan and Strategy Risks, Assumptions, Constraints, and
Dependencies: The Risk of every single test criteria may occur; mitigation
technique and their contingencies will be tallied in a spread sheet.
Development Case:
This Artifact is an Excel spread sheet which helps team efficiently apply RUP to their
project by making sure the project produces only Artifacts that are required and add
value. Development Case tally up the team resources’ and time required for the project
on RUP measurement that best meet their needs. RUP has different lifecycle of the
project structure that requires the deliverables and Artifacts depending on the resources
15
and time frame-Maintenance, Lite, or Full. The Development Case also associates roles
to Artifacts including sign-off and review.
Development Case captures
Which Artifacts (work products) will be used and which will not for a certain
Discipline.

Description of customized use of RUP disciplines and associated Work Products

Which Life Cycle (Inception, Elaboration, Construction, Implementation) the
Artifacts will be needed.
-When work products will be started and substantially complete

Status in terms of completion for each Artifact.

Responsibility Charting
-Responsible, Accountable, Consulted, and Informed
The Development Case helps teams avoid:
− Sacrificing quality by missing needed artifacts.
− Sacrificing cross-project communications.
− Taking unapproved shortcuts.
How to Measure Progress:
16
At the end of Inception phase the main goal is to give the Vision document a sense of
stability. The Vision document translates problem statement, stakeholder & user profiles,
stakeholder needs and the system features. To complete the Vision document all
stakeholders of the project for have to be identified, all perspectives have to be
considered and have to make sure all the features captured which solves the problem
stated. By getting Stakeholders signoff proves scope has been agreed upon.
The Requirements Prioritization Matrix prioritizes the Use Cases and Requirements. At
the end of Inception phase requirement matrix has to be in an order, all identified Use
Cases are outlined and also all Use Cases and/or other Requirements have to be ranked
based on risk. By ranking Use Cases and/or other Requirements based on risk project
manager can tally up the requirement to give the project a sense of direction and
identifies which requirement is out of scope.
To move to the next phase, project manager measures whether the first iteration for
‘Elaboration’ was planned correctly. Objectives has to be set, Milestones has to be agreed
upon by the project team, Work Products needs to be identified, Assignments has to be
Made and also Evaluation Criteria has to be Understood. That means Next iteration is
planned and project team ready to move forward.
Figure 5 shows how resource allocation inside the projects gets adjusted as the project
moves on to the next phase.
17
Figure 5: Resource under the discipline as Phases of the Project progress
After the Inception Phase, the measurement should show demonstrable progress in:

What percentage of the Use Case Scenarios has been realized?

How many planned vs. executed Test Cases are there?

What percentage of the Test Cases has been passed?
Iteration plan communicates and keeps track of the phases. The basic iteration plan
focuses on the Key Milestones of the projects, Key Objectives, Key Work Products, and
Product Planning & Assignments along with Evaluation Criteria.
1. Key Milestones: Key milestones of an iteration like iteration start and end date, dates
for to complete, reference architecture etc are tabulated in an excel sheet.
2. Key objective of the iteration: key objectives of iteration and the priority based on the
importance. Objectives such as ‘Successfully transition from inception to Elaboration18
focusing on training and mentoring sessions to meet the iteration goal’, ‘Validate
reference architecture will work as planned and Realize top ranked “critical” Use Case
scenarios’ can all have 1st priority opposed to ‘Address usability issues via user interface
prototype with User subject matter expert’ which can have lower priority.
3. Key work products: Work product like the Artifacts will get produced and maintained
in a project such as Use Cases, Supplementary Specs, and Use Case Prioritization matrix
etc will be shown in a matrix stating the current state of the documents in terms of
completeness. Notes also point out in terms of how much key elements these documents
provide.
4. Product Planning & Assignments:
Work Product Planning & Assignment provides and collects the information of the name
and description of the actual work and ‘who’ the work is assigned to, ‘what’ is the
priority level, estimated effort hours, start and end date of the task. If an assignment has a
higher priority and some other assignment is depending on the finished product of
assignment, the matrix clearly identifies the bottleneck .
5. Evaluation Criteria: Evaluation Criteria provides the percentage of the Test Cases
passed, whether the Reference Architecture been validated, Use case scenario for Plan
and design created and validated and Stake holder’s concurrence on the proto type along
with the priority.
Resource management in RUP:
19
In RUP phases (Inception, Elaboration, Construction and Transition) limit and regulate
the involvement of the project team keeping the project under a sizable budget. Since
RUP follows an iterative approach, a phase may consist of one or more iterations. Most
Cases whole project team has some part of involvement depending on what iteration and
phase the project in.
Below figure shows Team Resource distribution in different phases of the project.
Figure6: Resource distribution
Chart gives a descent idea on the Technical and Business Team involvement citing
Project Management and Analyst role as business team and Software Architect,
Developer and Tester as Technical Team. Most cases project manager has to weigh in
20
both roles. Y axis of the graph depicts the head count showing amount of involvement of
each team in a single phase of the project.
In Inception phase a significant amount of Project Manager and Analyst role can be seen
opposed to the technical roles as the work mostly emphasizes on establishing the projects
scope and building operational Vision. Most of the work at this point is due to analyzing
business side of the project. As project moves along to Elaboration and Construction
phase, more and more technical involvement (such as Software Architect, Developer and
Tester) reduces the business roles. In Transition phase Technical involvement
significantly gets reduced (apart from where End User and Beta testing takes presence) as
project waits for the release.
Conclusion:
RUP is a unique Software development process developed by Rational Corporations
which is eventually bought by IBM. Later, IBM rolled out the methodology to their
clients in different industries (such as healthcare industry) where in-house software
development needed a boost. This Iterative software development methodology also
comes with a package of software to support it. Rational Software tools (such as Rational
Clear Quest, Rational Clear Case, Test Manager) created on account of supporting the
methodology to keep this whole methodology as a single package to standardize it and to
make it a consistent approach to project development. It is grounded on current best
practices and industry standards across the application development life cycle. RUP is on
the way to replace traditional waterfall method.
21
References:
Visitask. (2010).Project Life Cycle-Project Cycle Management Retrieved June 12, 2011
from Visitask group website: http://www.visitask.com/project-life-cycle.asp
IBM Corporation (2007). IBM Rational Unified Process. Retrieved June 8, 2011, from
ftp://public.dhe.ibm.com/software/rational/web/datasheets/RUP_DS.pdf
Idiom Software Ltd (2011). Idiom and Rational Unified Process. Retrieved June 4, 2011,
from http://www.idiomsoftware.com/pdfs/IDIOM%20and%20RUP.pdf
IBM Developer Works (2004). Software Project Management -- A Mapping between
RUP and the PMBOK. Retrieved June 03, 2011 from
http://www.ibm.com/developerworks/rational/library/4721.html
Rational Software Corporation (2003). Rational Unified Process: Artifacts. Retrieved
June 14, 2011, from http://rup.hops-fp6.org/process/artifact/ovu_arts.htm
Wapedia (2011). Wiki: Waterfall model. Retrieved June 14, 2011, from
http://wapedia.mobi/en/Waterfall_model
22