The Rational Unified Process

Department of Computer Science

Mlardalen University
Emil Eric
Majid Gorbani
Andreas Selenwall
June 10, 2004

1
 Abstract
It is claimed that only 26% of major IT projects are successful. There
are many reasons for this, but one way to make a project more likely to
succeed is to use a formal process for software development. The Rational
Unified Process (RUP) is such a process. RUP was developed by unifying
several object oriented development processes. The RUP has also formed
the basis for many variants including the Unified Process, an open initia-
tive and many commercial derivations. This report describes the process
model from analyzing, designing, implementing, testing and maintenance
to the final delivery of the product.
Keywords: RUP, UP, OPEN, software development, process phases,
workflow

2
Contents
1 Introduction 5
1.1 Problem area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Process description 6
2.1 Static structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Dynamic Structure: Iterative Development . . . . . . . . . . . . 8
2.2.1 The sequential process . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Four process phases . . . . . . . . . . . . . . . . . . . . . 10

3 Process workflow 11
3.1 Project Management Workflow . . . . . . . . . . . . . . . . . . . 11
3.1.1 Project Risk . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Business and Requirements Modelling . . . . . . . . . . . . . . . 13
3.2.1 Business Modelling . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Requirements Modelling . . . . . . . . . . . . . . . . . . . 14
3.3 The analysis and Design workflow . . . . . . . . . . . . . . . . . 14
3.3.1 Analysis versus design . . . . . . . . . . . . . . . . . . . . 15
3.3.2 The analysis model . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 The design model . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 The implementation workflow . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Test workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.1 Testing in the iterative lifecycle . . . . . . . . . . . . . . . 19
3.5.2 Type of test . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.3 The test model . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.4 Workers and artifacts . . . . . . . . . . . . . . . . . . . . 21
3.5.5 The test workflow . . . . . . . . . . . . . . . . . . . . . . 21

4 Project Planning with the Rational Unified Process 22

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Project Start Activities . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 Developing a Business Case . . . . . . . . . . . . . . . . . 22
4.2.2 Identify and Assessing risks . . . . . . . . . . . . . . . . . 23
4.2.3 The Vision . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Initiating the project . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 The Software Development Plan . . . . . . . . . . . . . . 24

3
 4.3.2 The iteration plan . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3 The architecture . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4 Building and testing products . . . . . . . . . . . . . . . . 27

5 Related process models 27

5.1 OPEN: an overview . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 RUP and OPEN: a qualitative comparison . . . . . . . . . . . . . 28
5.2.1 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2 Project management elements . . . . . . . . . . . . . . . . 29

6 Discussion and Conclusion 30

4
1 Introduction
This chapter considers the purpose and limitations of the project and how the
Rational Unified Process(RUP) works in generall.
RUP is a software engineering process developed and marketed by Rational
Software. It is a disciplined approach to assigning and managing tasks and re-
sponsibilities in a development organization. The goal with this process is to
produce, within a predictable schedule and budget, high-quality software that
meets the needs of its end users. RUP is a process ”framework” for software
development, which covers the life cycle of a project and guides the development
team in the activities of project management as well as the technical activities.
The RUP has a solid structure; its description is coherent and uses in itself
an object-oriented approach. Its structure transcends the traditional model of
the development in cascade to offer a powerful software development frame-
work based on a controlled and optimized iterative cycle. The RUP proposes a
framework making it possible for an organization of software development of all
sizes to work, extend and improve its process according to its objectives. The
RUP is a rich base of knowledge of the best practices harvested by Rational
over the years. RUP captures many of the best practices in modern software
development and presents them in a tailorable form that is suitable for a wide
range of projects and organizations. RUP delivers these best practices to the
project team online in a detailed, practical form.

1.1 Problem area

The problem of systems engineering is to design and implement a system that
meets a broad set of requirements [1]. Depending on circumstances, there might
be other system requirements such as logistics support, security, and remote
training needs. Some of these requirements are familiar to software development.
Some cannot be addressed without hardware, software, and worker considera-
tions. Systems design requires that all three types of components be specified
concurrently. The system problem then differs from the software-only problem
in that system engineering addresses a broader set of requirements than are
normally addressed in software efforts. A way to handle these problems is to
use the Rational Unified Process (RUP), like a process model, that addresses
the problem of system specification, analysis, design, and development.

1.2 Purpose
The purpose with this project is to make research to see how the Rational
Unified Process (RUP) works.

5
2 Process description
2.1 Static structure
A model process describes who does what, how, and when. The Rational Unified
Process is represented with the use of four primary modeling elements, which are
workers, activities, artifacts, and workflows. A worker defines the behavior and
responsibilities of an individual or a group of individuals working as a team.
Workers represent a role played by individuals on a project, and define how
they carry out their work. Workers have activities, which define the work they
perform. An activity is something a worker does that provides a meaningful
result in the context of the project. Activities have input and output artifacts.
An artifact is a work product of the process; workers use artifacts to perform
activities, and produce artifacts in the execution of activities. Artifacts are
pieces of information that are produced, modified, or used by a process.
Core workflows, in the Rational Unified Process, represent a partitioning of
workers and activities into logical groupings called areas of concern or disci-
plines. The core process workflows are grouped into six engineering workflows:
Business Modeling, Requirements, Analysis and Design, Implementation, Test,
and Deployment; and three supporting workflows: Project Management, Con-
figuration and Change Management, and Environment.
Three individuals elements are shown in figure 1.

Figure 1: Static structure

6
2.1.1 Workers
The worker is the core element in the whole process, as a result the workers
defined the behaviour and responsibilities of an individual or a group of indi-
viduals working together as a team. It is helpful to think of a worker as a hat
that an individual can put on during the project. One person may have on
many hats. This is important because it is common to think of a worker as the
individual or the group, but in the RUP the term worker refers to the roles that
classify how the individuals should do their work.
Some examples that a worker possibly will be take part in are:

• System analyst – a person acting as system analyst leads and coordinates

requirements elicitation and use-case modelling by outlining the systems
and delimiting the system.
• Designer – a person acting as a designer defines the responsibilities, oper-
ations, attributes and relationships of one or more classes.
• Test Designer – a person acting as a test designer is responsible for the
planning, design, implementation and evaluation of tests.

It is essential to know that workers are not individuals. They explain that
an individual should conduct itself in the business and the responsibilities of
each individual.

2.1.2 Activities
Each worker has activities, which characterize the work they perform. An ac-
tivity is a unit of work that an individual in that role may be asked to perform,
and that produces a consequential result in the context of the project. The
purpose of the activity is to create or update artifacts such as a model, class
or a plan. Every activity may be frequently doing some operation on the same
artifact, particularly from one iteration to another as the system is refined and
expanded. Some instances of the activities:
• Plan an iteration: performed by the worker: Project Manager

• Find use cases and actors: performed by the Worker: System Analyst
• Review the design: performed by the Worker: Design Reviewer
• Execute a performance test: performed by the Worker: Performance
Tester

2.1.3 Artifact
Activities have input and output artifacts. An artifact is information that is
produced and modified or used by a process. Below is some examples of what
an artifact could looks like:

7
 • A model, such as the use-case model or the design model
• A model element - an element within a model - such as a class , a use case,
or a subsystem
• A document, such as a business case or software architecture document

• Source code
• Executables

2.1.4 Workflows
A simple record of all workers, activities and artifacts does not quite represent
a process. We need a way to describe meaningful sequences of activities that
produce some important result and to show interactions between workers. A
workflow is a sequence of activities that produces a result of observable val-
ues. In UML terms, a workflow can be articulated as a sequence diagram, a
collaboration diagram, or an activity diagram.
The Rational Unified Process is organized to reach the goal using the fol-
lowing:
• Core workflows
• Workflow details

• Iteration plans

2.2 Dynamic Structure: Iterative Development

2.2.1 The sequential process
There has been a lot of problems and failures in software development on the
sequential or waterfall process. This is surprising because at first, this method
seems like a reasonable approach to system development.
The typical step to solve a problem by sequential process can be as follow:
1. It is a requirement to completely understand the problem and write down
to get all interested part figuring out what they (users) accomplish.
2. Design a solution that can satisfy all requirements and constraints.
3. Implement the solution.

4. Verify that the implementation satisfy the requirement.

5. Deliver.

8
 Figure 2: The sequential process

The representation below shows the whole sequential process.

This kind of planning is the common development method used by building
constructors because the problem field is relatively well known; the engineers
can draw on hundreds of years of experimentation in design and construction.
But in contrast, software engineers have had only a few decades to explore their
field. During the seventies and eighties the software developers worked very
hard to accumulate experimental results in software design and during the 1980
the sequential problem solving was the only method used.
In the sequential processing the developers have only one shot on each step
of sequence of project, with very little opportunity to learn from their mistakes.
The design must be almost perfect and also the rest of the sequence like coding,
programming and testing whitout any errors or fault.
If the sequential, or waterfall processing works for the short projects or those
with a small amount of novelty or risk, RUP breaks down the lifecycle of a large
project into a succession of small waterfall projects. In this way you take a
smaller step each time on every sequence and you have time to address some
requirements and some risks, design a little, implement a little, validate it, and
then take on more requirements, design some more, build some more, validate,
and so on, until you are finished. This is the iterative approach.
Figure 3 shows the difference of sequence and iterative processing.
The iterative process breaks a development cycle into a succession of iter-
ations. Each sequence looks like a mini waterfall and involves the activities of
requirements, design, implementation, and assessment.

9
 Figure 3: Difference between sequential and iterative approach

2.2.2 Four process phases

Phases and milestones To control the project and to give the appropriate
focus for each iteration, a development cycle is divided into a sequence of four
phases that partition with help of milestones the sequence of iterations. These
milestones provide points at which we can decide to proceed, abort, or change
course. Finally, we must partition and organize the sequence of iterations ac-
cording to specific short-term objective.

Figure 4: RUP four phases

The Rational Unified Process consists of cycles that may repeat over the
long-term life of a system. The software lifecycle is based on four phases, through
which the project evolves linearly in time. The phases are: Inception Phase,
Elaboration Phase, Construction Phase, and Transition Phase. Each of these
phases is composed of one or more iterations and follows a waterfall pattern
containing requirement elicitation, analysis, design, implementation, test, and

10
deployment, and results in a release (either internal or external) of an executable
product, which grows incrementally from iteration to iteration to become the
final system. Each phase is concluded with a well-defined milestone - a point in
time at which a certain critical decisions must be made, and therefore key goals
must have been achieved.
Lets briefly review the four phases in a cycle: for example

• Inception Phase – During the inception phase the core idea is developed
into a product vision. In this phase, we review and confirm our under-
standing of the core business drivers. We want to understand the business
case for which the project should be attempted. The inception phase
establishes the product feasibility and delimits the project scope.
• Elaboration Phase – During the elaboration phase the majority of the Use
Cases are specified in detail and the system architecture is designed. This
phase focuses on the ”Do-Ability” of the project. We identify significant
risks and prepare a schedule, staff and cost profile for the entire project.
• Construction Phase – During the construction phase the product is moved
from the architectural baseline to a system complete enough for transition
to the user community. The architectural baseline grows to become the
completed system as the design is refined into code.
• Transition Phase – In the transition phase the goal is to ensure that the
requirements have been met to the satisfaction of the stakeholders. This
phase is often initiated with a beta release of the application. Other activ-
ities include site preparation, manual completion, and defect identification
and correction. The transition phase ends with a postmortem devoted to
learning and recording lessons for future cycles.

The four phases (Inception, Elaboration, Construction, and Transition) con-

stitute a development cycle and produce a software generation. The iterative
approach accommodates changes in requirements and in implementation strat-
egy. It confronts and mitigates risks as early as possible. It allows the develop-
ment organization to grow, to learn, and to improve. It focuses on real, tangible
objectives.

3 Process workflow
3.1 Project Management Workflow
The purpose of the Project Management Workflow is to provide a framework
for managing risks, by practical guidance on how to plan, execute and mon-
itor projects. The project plan encapsulates the process the project should
follow, divide the problem into sub-tasks, assigning tasks to teams and setting
a timescale for each task. The plan evolves during the project’s lifecycle due

11
to monitoring and measurements of the product so far. A project plan is di-
vided into two parts, the phase plan and the iteration plan. The phase plan is a
coarse-grained plan with overall information about each of the four phases, and
should contain date of major milestones, staffing estimates for each phase an
estimation of the numbers of iterations included in each phase. Iteration plan
is the detailed plan for each iteration and should describe that exact iteration.
Each iteration plan includes
• Requirements
• Analysis and Design
• Deployment
• Test and evaluation
In each iteration you should identify tasks, tasks and sub tasks, and establish
start and end dates for each task. Gannt charts are often used to show tasks
start and end date.
Each iteration also addresses three extra workflows items.
• Monitoring and Control Project – Checking that the project is on plan
• Plan for extra iteration – Develop the plan for the next iteration
• Manage iteration – Monitors progress of the project and plans for the next
iteration, deciding when to change iteration and whether the project still
is viable.

3.1.1 Project Risk

A risk comprises three elements
• An undesirable event
• An estimate of the severity of the consequnces of the event
• The probability that the event will occur
The risk of the project is a good basis for if the project is viable.
The artifacts produced in the Project Management Workflow is the Software
Development Plan, the Business case, detailed plan for each iteration and work
schedule.
The Software Development Plan consists of
• Measurement plan
• Risk management plan
• Product acceptance plan
• Problem resolution plan

12
 • Project organization and staffing
• Monitoring and control processes
• Plan phases and iterations

3.2 Business and Requirements Modelling

There are nine core workflows in the Rational Unified Process which can be
divided into two groups, Core Process Workflow and Core Supporting Workflow.
Core Process Workflows

• Business modelling
• Requirements
• Analysis and Design
• Implementation

• Test

• Deployment
Core Supporting Workflows
• Configuration and Change Management

• Project Management
• Environment
The Core Supporting Workflows are the administrative parts of the projects,
how to communicate within the project, the project plan and which type of
environment we are developing for and which we are developing in.

3.2.1 Business Modelling

In business modelling there are three active workers, the Business Process An-
alyst, the Business Designer and the Business Model Reviewer. In Business
Modelling we document business processes using business use cases. This as-
sures a common understanding between all stakeholders (a stakeholder is any
person or representative of an organization who has a stake - vested interest -
in the outcome of a project, [7] ) what business process needs to be supported
in the model.
The Business Case developed provides the business information necessary to
determine if the project is worth investing in, Return On Investment (ROI). Its
main purpose is to develop an economic plan for realizing the Vison. The Busi-
ness Case definition must contain the answer to ”Why is the product needed?”.
It must be brief and easy for the team members to understand. At critical

13
milestones in the project there must be a check if the project is accurate to the
ROI stated in the Business Case and if the project should be continued.
One of the major problems that can occur in Business Modelling is lack of
communication between the business engineering team and the software engi-
neering team, thus the output from business engineering is not used properly
in the software development. The Rational Unified Process address this prob-
lem by providing a common language to communicate between teams and thus
preventing this problem from occuring. The output from this workflow is doc-
umented in a Business Object-model. Business Modelling is one of the first
things you do in the project since the result of Business Cases and Return On
Investment is the information stakeholders will use to decide if the project is
worth investing in. After the project is approved other activities can start.

3.2.2 Requirements Modelling

In the requirements workflow we identify what the system should and should
not do and what requirements to prioritize. This is done through meetings with
the customer, refining the requirements after each meeting until the requirement
team has the same picture of the system as the customer. In the process we will
find and document actors and use-cases.
The three active workers in the Requirements workflow are, the System
Analysts, the Software Architect and the Requirements Reviewer.
Each worker has its own role in capturing the requirements.
• The System Analysts has the role of
– Finding a common vocabulary - to assure that the requirements team
understand what the customer wants
– Develop the requirements management plan
– Finding actors and Use-Cases
– Develop a Vision – capture the importance of the requirements work-
flow, analyzing the problem, understand stakeholders needs, defining
the system and managing the requirements as they change
– Elicit stakeholders requests - see that the requirements are under-
stood
• Software Architect – Prioritize Use-Cases - find which Use-Cases are more
important and urgent than others.
• Requirement Reviewer – Review requirements.

3.3 The analysis and Design workflow

Analysis and design bridge the gap between requirements and implementation.
This workflow uses use cases to identify a set of objects that is subsequently
refined into classes, subsystems and packages. Analysis and design result in a

14
design model, which can be abstracted using three architectural views. The log-
ical view presents the decomposition of the system into a set of logical elements,
e.g. classes, subsystems, packages and collaborations. The process view maps
those elements to the processes and threads in the systems. The deployment
view maps the processes to a set of nodes on which they execute.

3.3.1 Analysis versus design

The purpose of the analysis and design workflow is to translate the requirements
into a specification that describes how to implement the system. Early in the
project, it is important to establish a robust architecture so it will be possible
to design a system that is easy to understand, build and evolve [3]. The purpose
of analysis is to transform the requirements of the system into a form that maps
well to the software designers area of concern - that is, to a set of classes and
subsystems. This transformation is driven by the use cases and is shaped further
by the systems non-functional requirements. Analysis focuses on ensuring that
the systems functional requirements are handled. As a result, analysis expresses
a nearly ideal picture of the system. The purpose of design, on the other hand,
is to adapt the results of analysis to the constraints imposed by non-functional
requirements, the implementation environment, performance requirements, and
so forth. Design is a refinement of analysis. It focuses on optimizing the systems
design while ensuring complete requirements coverage.

3.3.2 The analysis model

There is generally one design model of a system; the analyse procedure intro-
duces a very abstract view of the system which will later be defined in design.
The first phase of this model is the aspects of the system. In some companies,
which systems lives very long or there are many variants of the system, a sep-
arate analysis model has proved very useful. The analysis model omits most of
the details of how the system works and provides an overview of the systems
functionality.
The extra work required to ensure that the analysis and design models re-
mains consistent must be balanced against the benefit of having a view of the
system that represents only the most important details of how the system works.
In figure 6, RUPs four phases in the analysis workflow are shown, e.g. the ar-
chitectural analtysis, use case analysis, class analysis, package analysis and how
they are related to each other.

3.3.3 The design model

The design model consists of a set of collaborations of model elements that
provide the behavior of the system. This behavior is derived from the use-case
model and nonfunctional requirements. The design model consists of collab-
orations of classes which may be aggregated into packages and subsystems to
help organize the model and to provide compositional blocks within the model.

15
 Figure 5: RUPs four phases in the analysis workflow [6]

A class is further a description of a set of objects that share the same respon-
sibilities, relationships, operations, attributes and semantics. A package is a
logical grouping of classes, perhaps for organizational purposes that reduce the
complexity of the system. A subsystem is a kind of package consisting of a set
of classes that act as a single unit to provide specific behaviors [9].
The designer defines the responsibilities, operations, attributes and relation-
ships of one or several classes and determines how they should be adjusted to
the implementation environment. In addition, the designer may have respon-
sibility for one or more design packages or design subsystems, including any
classes owned by the packages or subsystems.
Design can optionally include the following workers:
• Database designer – the database designer is needed when the system
being designed includes a database.
• Capsule designer – the capsule designer is a kind of designer who focuses on
ensuring that the system is able to respond to events in a timely manner.
• Architecture reviewer and design reviewer – these specialists review the
key artifacts produced through this workflow.

3.4 The implementation workflow

The implementation workflow has four purposes:

16
 1. To define the code in terms of implementation subsystems organized in
layers.

2. To implement classes and objects in terms of components.

3. To test the developed components as units.

4. To integrate into an executable system the results produced by individual

implementers or teams.

[10] To define the implementation process; builds, integration and prototypes

most be taken in consideration.

3.4.1 Builds
A build is a part of a system, e.g. a subsystem that demonstrates a subset of
capabilities to be provided in the final product. During the developing process
there will be numerous builds, each helping to recognize integration problems as
soon as they are introduced. Builds are an integral part of the iterative lifecycle.
Each build is placed under configuration control in case there is a need to roll
back to an earlier version when added functionality causes breakage. Projects
generally try to produce builds at regular intervals, up to one each day, but at
least one per week toward the end of an integration.

3.4.2 Integration
Integration refers to an activity in which separate software components are com-
bined into a whole. Integration is done at several levels of the implementation
for the following purposes:
• To integrate the work of a team working with the same subsystem before
the subsystem is released to system integrators.
• To integrate subsystems into a complete system.

The RUP approach to integration is that the software is integrated incremen-

tally. Incremental developmant means that code is written and tested in small
pieces and then is combined into a working whole, piece by piece. Incremental
development offers the following benefits:
• Faults are easy to locate. When a new problem occurs during the integra-
tion, the new component is the first place to look for the fault. Incremental
integration also makes likely that defects will be discovered one at a time,
something that makes it easier to identify faults.
• The components are tested more fully. Components are integrated and
tested as they are developed. This means that the components are exer-
cised more often than they are when integration is done in one step.

17
 • Some parts of the system are running earlier. It is better for the morale
of developers to see early results of their work instead of waiting until the
end to test everything.
[16]

3.4.3 Prototypes
Prototypes are used in a directed way to reduce risk. A prototype is a variant of
a real product and is used to show something concrete and executable to users,
customers and managers. You can view prototypes in two ways: by what they
explore and by how they evolve [18]. In the context of the first view, there are
two main kinds of prototypes:
• Behavioral prototype, which focuses on exploring specific behavior of the
system.
• Structural prototype, which explores architectural or technological con-
cerns.
In context of the second view, there are also two kinds of prototypes:
• Exploratory prototype, which is thrown away after it is finished and you
have learned whatever you wanted from it.
• Evolutionary prototype, evolves to become the final system.

3.4.4 Workflow
Implementation is tied closely to design, and there are clear tracing links from
design elements to implementation elements, for example classes to code. The
persons playing the role as designers and implementers can either modify the
design model and regenerate the corresponding code and then alter the design
to match the modification. This closes a gap in the process and helps avoid
errors in translating the design.

3.5 Test workflow

The purpose of testing is to assess product quality. The test is not accrue in the
final moment of the product development, but also begins early in the project
with the assessment of the architecture and continues through the assessment
of the final product delivered to customers. The test workflow involves the
following:
• Verifying the interactions of components
• Verifying the proper integration of components
• Verifying that all requirements have been implemented correctly

18
 • Identifying and ensuring that all discovered defects are addressed before
the software is deployed.
When you talk about the quality in general it means principally the absence
of defects, but if the product does not reach the wished requirement, it is as
useless as the product with a defect.
The test workflow provides the feedback mechanism for the project, enabling
quality to be measured and defects to be identified. Testing activities begin early
in the project, with test planning and some assessment occurring even in the
inception phase, and continue throughout the project.

3.5.1 Testing in the iterative lifecycle

Testing is not a single activity, nor is it a phase in the project during which we
assess quality. If developers are to obtain timely feedback on evolving product
quality, testing must occur throughout the lifecycle. The tests depends on the
projects current phase:

• In general, whenever there is an implementation result, there is a test

• Inception phase: initial test planning, prototype testing
• Elaboration phase: test architectural baseline
• Construction phase: significant testing at each build

• Transition phase: re-test fixes and regression tests

– Regression tests: in a new build, re-apply tests from old builds to
make sure nothing broke in new build
• Evolve test model

– Create new test cases for next build

– Refine prior test cases into regression tests
– Remove obsolete tests and corresponding test procedures and com-
ponents

3.5.2 Type of test

The testing have many kind of types, each one focusing on specific area, a test
of software during the development has many variation of testing, a test could
be a single unit of code, integrated units, or a complete application or system.
Here are some of the most common types of test:
• Benchmark test – comparing the performance of a target-of-test to a
known standard such as existing software or measurement

19
 Figure 6: Testing during the software development lifecycle

• Configuration test – verifying that the target-of-test functions is an ac-

ceptable manner on different configuration (hardware or software)

• Installation test – verifying that the target-of-test installs properly and

can be installed successfully on different configuration or under different
conditions, such as insufficient disk space or on the different operation
system or platform
• Integrity test – verifying the target-of-test is reliable, robust, and resis-
tance to failure during the execution

• Performance test – verifying the acceptability of the target-of-tests per-

formance using various configurations while the operational conditions
remain constant
• Stress test – verifying the acceptability of the target-of-tests performance
when abnormal or extreme conditions are encountered, such as diminished
resources or an extremely high number of users

The quality is everyones responsibility. Quality is not produced by a quality-

personal or some testing organization.

3.5.3 The test model

The test model is an illustration of what will be tested and how it will be
tested. It is a view of the design and implementation models, depicting the

20
tests themselves, as well as aspects of the target-of-test that are relevant to
the testing effort. It includes the group of the test cases, test procedures, test
scripts, and expected test results along with a description of their relationships.
• Test cases – the set of test data, execution conditions, and expected test
results developed for a specific test objective. Test cases can be derived
from use cases, design documents, or the software code.
• Test procedure – the set of detailed instructions for the setup, execution,
and evaluation of test results for test case.
• Test components – the classes and components that realize the test de-
signs, including drivers and stubs.

3.5.4 Workers and artifacts

Two main workers are concerned in the workflow:
• The test designer is responsible for the planning, design, implementation,
and evaluation of testing. This involves generating the test plan and test
model, implementing the test procedures, and evaluating test coverage,
results, and effectiveness.
• The tester is responsible for executing the system tests. This effort in-
cludes setting up and executing tests, evaluating test execution, recover-
ing from executing tests, evaluating test execution, recovering from errors,
assessing the results of testing, and logging change requests.

3.5.5 The test workflow

plan test The purpose is to identify and describe the testing that will be
implemented and executed. This is accomplished by generating a test plan that
contains the requirements for test and test strategies. Test planning is done so
the test efforts can be measured and managed.

design test The purpose is to identify, describe, and generate the test model
and its reported artifact. The design is done to ensure that the test software
meets its requirements and is structured and organized well. In the design
activity, the test designer analyzes the target-of-test and develops the test model
and, in the case of performance test, the workload model.

implement test The purpose is to implement the test procedures that were
defined in the Design Test section. The creation of test procedures usually is
done in the contest of a test automation tool or programming environment. The
output artifact is a computer-readable version of the test procedure, referred to
as a test script. If special test code (e.g., a test harness, drivers, or stubs) is
needed to support or perform testing, the designer and the implementer work
with the test designer to design and implements the test code.

21
4 Project Planning with the Rational Unified
Process
In this chapter we will take a closer look into the project planning and what
the essentials are. To some of these essentials there are recommendations from
RUP on which are the key elements that should be in the documents [14].

4.1 Introduction
If the project is viable after the project start activities we will define the project
organizational structure based on the project characteristics and external con-
straints. The recommendations from the Rational Unified Process is to define
in terms of positions, teams, responsibilities and hierarchy. We will also define
staff requirements based on effort estimates, desired schedule, chosen organiza-
tional structure and mapping of roles, the RUP recommends that you define
staff required for the project by type (skills and the domain of the project),
experience and caliber, that you adjust the software development team from its
baseline during the project lifecycle, that is while the project moves forward
different staff members are required in different positions. For example:
• In the Inception Phase the focus will be on management functions. De-
veloping the Vision, etc.
• In the Elaboration Phase the focus will be on the architecure. The staff
will consist of more designers.
• In the Construction Phase the focus will be on developments. The staff
will consist of more developers.
• In The Transition Phase the focus will be on Quality Assurance / Software
Assessment.

4.2 Project Start Activities

4.2.1 Developing a Business Case
The idea with the business plan is to see whether the project is worth investing
in, or Return Of Investment (ROI). It is up to the manager to find if the project is
worth investing in and the report is the artifact. The business case is essential for
the future of the project, the stakeholders must feel that this is worth investing
in due to the artifact and the market needs.
The following steps are recommended by the RUP when developing the busi-
ness case:
1. Describe the product and the need it fulfills
2. Define the product or project objectives at a high level

22
 3. Develop a financial forecast including projected revenues and costs for the
project
4. Describe the project constraints that could potentially impact risk and
cost
5. Describe the options that could impact the projects success

4.2.2 Identify and Assessing risks

This an important task and its best place is in the startup of the project. This
part builds a basis for risk mitigation in the iterations. RUP is risk-driven,
that is, it focuses on risks and mitigate risks. This is done by identifying and
handling risks early in the development. In this process a Risk List will be
created by identifying in decreasing order of priority events that could lead to
problem, with each risk associated with a plan to mitigate the risk. The risks
should be a focal point for the planning project activities and a basis for how
iterations are organized.
Its important to have continuos checks on the activities, what it produces
and their configurations to track issues and handle them when they occur. RUP
uses regular status assessments and provides a mechanism for addressing, com-
municating and resolving management issues. Each issue should be assigned to
a person accountable for the resolution.
RUP has some steps they recommend you follow when working on risks:
1. Identify potential risks that would decrease the likelihood that the devel-
opment team will be able to deliver the project with the right features,
the specified level of quality, on time and within budget.
2. Analyze and prioritize the risks by estimating the impact of each and the
likelihood of its occurence to determine the risk exposure for each risk
3. Identify risk avoidance strategies to reorganize the project so that you can
reduce or eliminate risks
4. Identify risk mitigation strategies
5. Identify risk contingency strategies
6. Revisit risks frequently within iterations and subsequent phases

4.2.3 The Vision

Having a clear and correct Vision assures us that the project is defined after
and moving towards the stakeholders needs. The Vison captures the essence
of the Requirements Workflow by analyzing the problem, understanding the
stakeholders needs, defining that system and managing the requirements as
they change. Some other features of the Vison Document is that it
• Provides a high-level basis for more detailed technical requirements

23
 • Captures very high-level requirements
• Captures design constraints
• Provides input to the project-approval process – this part is closely related
to the Business Modelling
• Problem statement – What is to be done?

The Vision also identifies stakeholders, users and what their needs are.

4.3 Initiating the project

After the Business Case is approved we start working on the Initiate Project
activity. This activity will assign the Executive Management and Project Plan-
ning team and will also set up the criteria for project completion, when this
criteria is reached the project has successfully been completed. In this activity
you also assign a project review team who will be responsible for the overall
view of the project, a project planning team responsible for the planning of the
project (gantt chart where we allocate resources for different activities), main-
taining the project plan and report project status. Also this is when we approve
the project acceptance criteria (a way for the stakeholders and customers to de-
termine when a delivered product is acceptable).

4.3.1 The Software Development Plan

A word of wisdom: ”The product is only as good as the plan for the product”,
Johnson Space Center Shuttle Software Group
A Project Plans function is to give the team information about:
• Roles – who is doing what in the project
• Budget
• What to deliver and when

• Resource allocation – when a certain resource must be available and for

what purpose
• Provides a basis for measuring progress and expenditures
• Gives the planner a baseline to support replanning activities
• Helps the customer and management to see what went wrong when a
project failes
The Project Plan is target based, it identifies deliverables on the project.
It contains a variation of views depending on the stakeholder (the customer,
team members and management), it must be measurable from a time view and
a deliverable view, to easier identify what has been delivered and where we are

24
in the project timeline. Its also very important that each team member knows
what have been delivered and what will be delivered. The plan must be up to
date.
The Project Plan, or the Software Development Plan as it is called in the
Rational Unified Process, contains all information to manage the project and is
maintained throughout the project to keep it updated as it changes. The Soft-
ware Development Plan contains the schedule for the project, the resource needs
for the project and compare progress against the schedule to update members
with the actual progress of the project. Here are a list of the content of the
Software Development Plan:
• Schedule – Project Plan, Iteration Plan, Resources and Tools

• Requirements Management Plan

• Configuration Management Plan
• Problem Resolution Plan

• Quality Assurance Plan

• Test Plan

• Test Cases
• Evaluation Plan
• Product Acceptance Plan
In smaller projects each part can consist of just a couple of words briefly de-
scribing each part of the content.
The Software Development Plan is a very critical part of the project. The
major activities are defining the project structure and estimating the size of the
project. IBM Rational have made an estimation of the project time by earlier
experience in software development. By their estimations, about 10

4.3.2 The iteration plan

For each iteration there is a related Iteration Plan, these are represented in the
Vision. The Iteration Plan is written after the project plan is completed. RUP
is iterative and incremental, thus it is divided into phases and activities. Each
iteration in a phase is risk driven, the aim in each phase is to mitigate risk,
this reduces the possibilities of future risks. Each iteration must have an iter-
ation plan which contains a detailed description of that phase, which workers
are needed and what they will do, activities and which artifacts will be deliv-
ered. The Iteration Plan is more detailed than the project plan and has clear
objectives (and milestones) for each phase. To fully understand the projects
current status and it is progress is to identify which phase you are in, this must
be realized by all project team members. Every phase delivers something. The

25
Figure 7: A graph showing time for each phase for a typical RUP project [11]

Inception Phase delivers for example the Vision document. Associated with
each deliverable is a workflow template which contains important aspects such
as activities, resources and other deliverables required to complete this deliver-
able, and an artifact, the document produced by the project. RUP has provided
us with some sample deliverables based on a normal RUP project.
• Business Cases - information about cost and benefits of the product

• Vision - What the product does, the market for the product and the
product main features
• Use-Case Model - Defines the systems functional requirements

• Supplementary Requirements - non-functional requirements for the sys-

tem, for example documentational requirements

As stated earlier there is a workflow associated with each deliverable. The

workflow template idenitifies activities needed to create the deliverable. An
activity includes roles which helps find what resources are needed and must be
filled with actual workers, artifacts and guidance (help steps). Unfit activities
can be omitted from an iteration (or project regarding the plan). Time for an
activity depends on the time allocated for the whole iteration.
To be able to see the progress of the project and if it is off-track and how
to get the project back on track we use monitoring and control processes. This
is usually done by checking the project so it follows the Software Development
Plan (SDP) to see that the project is still in its scope. RUP has the following
recommendations.
1. Define project indicators to alert the project manager to instigate correc-
tive actions as required
2. Define sources for project indicators

26
 3. Define and communicate a procedure and report frequency for project
team members to report their status.

4. Define tresholds for the projects indicators.

5. Define a procedure for project status reporting

After each iteration assess success and failures, that is, compare results to
what was expected. For example functionality, performance, capacity and qual-
ity. Also you should check if the requirements are still valid, if the goals are too
high or too low and if the features of the product are still economically justified.
After this control you might need to make some changes to the Vision document
and the risk list.

4.3.3 The architecture

The architecture should contain the structure of the systems significant com-
ponents interacting through interfaces, ”What are the main pieces and how do
they fit together?”. The essence of the Analysis and Design Workflow are define
a candidate architecture, refine the architecture, analyze behaviour and design
components of the system. The architecture design results in the Software
Architecture Document which defines the architectural design which describes
important aspects of the architecture, and multiple views with specific con-
cerns, depending on the stakeholders (End User, Designers, Managers, System
Engineers, Maintainers, etc).

4.3.4 Building and testing products

This is the essence of the Implement and Test workflow. The product is in-
crementally coded, built and tested, each iteration (after the Inception Phase)
delivers an executable. After the Elaboration Phase an architectural prototype
will be available for evaluation and a user-interface prototype might be included.
Through each iteration in the Construction Phase components are integrated
into an executable.

5 Related process models

5.1 OPEN: an overview
Open is a tailorable process-focused framework for software development [19].
It is described in terms of its metamodel or framework. The process itself is
created as an instantiation of this framework. In figure 9, shown below, an
overview of the framework is described.
The framework is a combination of people in context of an organizational
culture; tools and available technology, together with Work Units (e.g. activ-
ities and tags) and Work Products (e.g. code, planning and documents). It

27
 Figure 8: An overview of the OPEN framework [12]

has a strong focus not only on software development but also on project man-
agement [20]. OPEN combines the adaptability to construct a process to the
specific needs of an individual domain and continually adapt the process to
particular projects. This enhances the incorporation of component-based devel-
opment architectural patterns that will be increasingly in demand.

5.2 RUP and OPEN: a qualitative comparison

5.2.1 Flexibility
A major difference between RUP and OPEN is that OPEN is a flexible meta-
level framework, augmented by a repository of process component instances,
from which industry creates their own organizationally tailored method. OPEN
can be described as a component-based process construction facility. This gives
a high degree of flexibility. RUP, on the other hand, is a pre-packaged, pre-
configured instance of its own metamodel [21] and could be described as a tai-
lorable methodology; that is, RUP is a pre-selected instantiation of a metamodel
such as the OPEN framework [22].
According to official description of RUP, the tailoring is restricted to chang-
ing relative durations; expanding, modifying and removing steps from specific
activities; adding new checkpoints to the review activities. A comparison of the
creation routes for RUP and OPEN is shown in figure 10.

28
 Figure 9: Creation routes [15]

Figure 10: RUP phases and OPEN:s activities [17]

5.2.2 Project management elements

The key element in OPEN is that the linkages between activities and tasks and,
secondly, between tasks and techniques are accomplished, as throughout OPEN,

29
by the use of possibility matrices which assist the method engineering in tailor-
ing the most high quality software development in the most efficient manner.
OPEN also suggests that you define your own project charter which contains
an agreed statement on (1) Business Statement, (2) Problem Statement, (3)
Description, (4) Context Model, (5) Methodology, (6) Project Resource Esti-
mates and Schedules, (7) Quality Assurance, (8) Implementation Review and
(9) Risk Analysis [23]. This charter is an encapsulated agreed statement on the
constraints and resources available. In contrast, in RUP all of the project man-
agement elements are grouped together as a separate project management subset
supporting workflow, which operates in parallel to the other subset workflows
and across each iteration workflow. In addition, the actual depth of support for
project management is limited. And use of non-standard project management
terminology complicates the RUP model further – for instance the use of the
word activity to mean task, i.e. the smallest unit of work. There are many areas
in RUP that show difficulties from a project management viewpoint. Ambler [24]
identifies a number of weaknesses in RUP’s support for project management:

• The neglect of several aspects of the larger scale management issues, es-
pecially maintenance and support,
• The omission of any support for reuse and cross-project capability,
• The over-dependence on existing tools (of the vendor) leads to neglect of
areas that cannot be automated,
• Weakness in areas such as metrics management, reuse management, people
management and testing,
• The linking of prototypes linked to ends of iterations providing the ability
to make go/no go decisions,
• The serious investment in software tool support (RUP is after all a tool/product
itself).

6 Discussion and Conclusion

”IKIWISI (Ill Know It When I See It), the users dont know what they want but
they know what they do not want when they see it” [25]
This quote reflects why the Rational Unified Process model divides the prob-
lem into different parts with early prototype builds. Prototyping in an early
phase prevents larger failures and eastablish the solution with the customer in
different stages in the development process. ( by iterative refinement it is easy
to evaluate the result )
If the sequential, or waterfall processing works for the short projects or those
with a small amount of novelty or risk, why not break down the lifecycle of a
large project into a succession of small waterfall projects? In this way you take
a smaller step each time on every sequence and you have time to address some

30
requirements and some risks, design a little, implement a little, validate it, and
then take on more requirements, design some more, build some more, validate,
and so on, until you are finished. This is the iterative approach.
Another problem is that the technology is changing and also the market.
New software and hardware techniques and products become known, and you
want to use and exploit them, and the competition might introduce better
products. The sequential, or waterfall, process works somewhat well on the
small projects ranging from a few weeks to a few months. On a small project
it is always clear what would happen, and on projects in which all hard aspects
were well understood, but when you work on bigger problems the sequential or
waterfall method doesnt seem quite manageable as on small projects.
The content of the above mentioned is, a specific process model could never
suite for every software projects, e.g. software projects varies in both time and
quantity. The RUP, as described in this report, is suited for greater software
projects because it contains more extensive work that would be a waste of time
in smaller projects.

31
List of Figures
1 Static structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 The sequential process . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Difference between sequential and iterative approach . . . . . . . 10
4 RUP four phases . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 RUPs four phases in the analysis workflow [6] . . . . . . . . . . 16
6 Testing during the software development lifecycle . . . . . . . . . 20
7 A graph showing time for each phase for a typical RUP project
[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8 An overview of the OPEN framework [12] . . . . . . . . . . . . . 28
9 Creation routes [15] . . . . . . . . . . . . . . . . . . . . . . . . . 29
10 RUP phases and OPEN:s activities [17] . . . . . . . . . . . . . . 29

32
References
[1] http://businessweek.itpapers.com/abstract.aspx?&scid=445&docid=52444
[2] Identifying Extensions Required by RUP (Rational Unified Process)
http://mdh.lub.lu.se
[3] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 171-172
[4] http://mdh.lub.lu.se/cgi-bin/ftxt/ebsco/00985589 2003 29 2 181-
193/9108494
[5] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 171-172
[6] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 170-171
[7] http://www.softwaretesting.nildram.co.uk/cont542.htm

[8] http://www.awprofessional.com/article/printerfriendly.asp?p=30317
[9] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 174-175
[10] A. Cockbum, Selecting a projects methodology, IEEE Software 17 (4)
(2000) 84-85
[11] ”Planning Project with the Rational Unified Process”,
http://www.rational.com
[12] A. Cockbum, Selecting a projects methodology, IEEE Software, 2000, p.
68
[13] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 184
[14] ”The Ten Essentials of RUP”, http://www.rational.com
[15] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating the
process metamodel, 1999, p 53
[16] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 185
[17] H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating the pro-
cess metamodel, 1999, p 56
[18] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating the
process metamodel, 1999 p 102

33
[19] A. Cockbum, Selecting a projects methodology, IEEE Software, 2000, p
64-71

[20] B. H-Sellers, A. Bulthuis, Object Oriented Metamethods, Springer, New

York, 1998, p 158
[21] P. Hruby, Designing customizable methodologies, 2000, 22-31

[22] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating the

process metamodel, 1999, p 51-57
[23] R.T. Du and B. H-Sellers, The changing paradigm for object project man-
agement. Object Magazine 5,1995, p 54-60 also see page 78
[24] Ambler, S., Completing the Unified Process with process patterns,
http://www.ambysoft.com/unifiedProcess.html, 1999
[25] P. Kruchten, The Rational Unified Process An Introduction Second Edi-
tion, USA, 2000, p. 56

34