The RUP and Iterative Development

By contrast, the RUP uses an iterative approach

(iterate = repeat), that is, a sequence of incremental
steps or iterations. Each iteration includes some, or
most, of the development disciplines (requirements,
analysis, design, implementation, and so on)
Each iteration has a well-defined set of objectives
and produces a partial working implementation of
the final system. Each successive iteration builds on
the work of previous iterations to evolve and refine
the system until the final product is complete.
 Iterative Development in the RUP. The Rational Unified Process promotes an
iterative approach—in each iteration you do a little requirements, analysis, design,
implementation, and testing. Each iteration builds on the work of the previous
iterations to produce an executable that is one step closer to the final product.
 The RUP and Iterative Development
It accommodates changing requirements.
Requirements change and "feature creep"—the
addition of features that are technology or customer-
driven—have always been primary sources of project
trouble, leading to late delivery, missed schedules,
dissatisfied customers, and frustrated developers.
Instead, iterative development focuses the team on
producing and demonstrating executable software in
the next few weeks, which forces a focus on the most
essential requirements.
 The RUP and Iterative Development

Integration is not one "big bang" at the end of a

project. Leaving integration to the end results in
time-consuming rework—sometimes up to 40
percent of the total project effort. To avoid this, an
iterative approach breaks a project down into
smaller iterations, each ending with an integration in
which building blocks are integrated progressively
and continuously, minimizing later rework.
 The RUP and Iterative Development

Risks are usually discovered or addressed during

early integrations. The RUP's integrated approach
mitigates risks in early iterations, where all process
components are tested. Since each iteration exercises
many aspects of the project, such as tools, off-the-
shelf software, and team members' skills, you can
quickly discover whether perceived risks prove to be
real and also uncover new, unsuspected risks at a
time when they are easier and less costly to address.
 The RUP and Iterative Development

Management has a means of making tactical

changes to the product— to compete with existing
products, for example. Iterative development quickly
produces an executable architecture (albeit of limited
functionality), which can be used for quick release of
a product with a reduced scope to counter a
competitor's move.
 The RUP and Iterative Development

Reuse is facilitated. It is easier to identify common

parts as they are being partially designed or
implemented in iterations, than to recognize them
during planning. Design reviews in early iterations
allow architects to spot potential opportunities for
reuse and then develop and mature common code
for these opportunities in subsequent iterations.
 The RUP and Iterative Development

Defects can be found and corrected over several

iterations, resulting in a robust architecture and a
high-quality application. Flaws are detected even in
early iterations rather than during a massive testing
phase at the end. Performance bottlenecks are
discovered at a time when they can still be addressed,
instead of creating panic on the eve of delivery.
 The RUP and Iterative Development

It is a better use of project personnel. Many organizations

match their use of a waterfall approach with a pipeline
organization: The analysts send the completed requirements to
designers, who send a completed design to programmers, who
send components to integrators, who send a system to testers.
These many handoffs are sources of errors and
misunderstandings and make people feel less responsible for
the final product. An iterative process widens the scope of
expertise of the team members, allowing them to play many
roles and enabling a project manager to use the available staff
better, while simultaneously removing harmful handoffs.
 The RUP and Iterative Development

Team members learn along the way. The project members

have several opportunities along a development cycle to learn
from their mistakes and to improve their skills from one
iteration to another. More training opportunities can be
discovered as the result of assessing the earlier iterations. In
contrast, in a waterfall approach, you have only one shot at
design or coding or testing.
 The RUP and Iterative Development

The development process itself is improved and refined along

the way. The assessment at the end of an iteration not only
looks at the status of the project from a product or scheduling
perspective, but also analyzes what, in both the organization
and the process, can be improved in the next iteration.
 The RUP—A Well-Defined Software
Engineering Process
The Rational Unified Process itself was designed with techniques similar to those
used in software design. In particular, it is modeled using the Software Process
Engineering Metamodel (SPEM) —a standard for process modeling based on the
Unified Modeling Language (UML). The process has two structures or, if you prefer,
two dimensions:

Dynamic structure. The horizontal dimension represents the dynamic structure or

time dimension of the process. It shows how the process, expressed in terms of
cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project

Static structure. The vertical dimension represents the static structure of the
process. It describes how process elements—activities, disciplines, artifacts, and
roles—are logically grouped into core process disciplines (or workflows).
The RUP—A Well-Defined Software
Engineering Process
 The Dynamic Structure of the Rational
Unified Process
The dynamic structure deals with the lifecycle or time dimension of a project. The
RUP provides a structured approach to iterative development, dividing a project
into four phases: Inception, Elaboration, Construction, and Transition. The
objectives and milestones of the phases are listed in the sidebar
 The Dynamic Structure of the Rational
Unified Process

Inception. Establish a good understanding of what system to build by

getting a high-level understanding of all the requirements and
establishing the scope of the system. Mitigate many of the business
risks, produce the business case for building the system, and get buy-
in from all stakeholders on whether to proceed with the project.
 The Dynamic Structure of the Rational
Unified Process

Elaboration. Take care of many of the most technically difficult tasks:

Design, implement, test, and baseline an executable architecture,
including subsystems, their interfaces, key components, and
architectural mechanisms, such as how to deal with inter-process
communication or persistency. Address major technical risks, such as
resource contention risks, performance risks, and data security risks,
by implementing and validating actual code.
 The Dynamic Structure of the Rational
Unified Process

Construction. Do most of the implementation as you move from an

executable architecture to the first operational version of your
system. Deploy several internal and alpha releases to ensure that the
system is usable and addresses user needs. End the phase by
deploying a fully functional beta version of the system, including
installation and supporting documentation and training material
(although the system will likely still require tuning of functionality,
performance, and overall quality).
 The Dynamic Structure of the Rational
Unified Process

Transition. Ensure that software addresses the needs of its users.

This includes testing the product in preparation for release and
making minor adjustments based on user feedback. At this point in
the lifecycle, user feedback focuses mainly on fine-tuning the
product, configuration, installation, and usability issues; all the
major structural issues should have been worked out much earlier
in the project lifecycle.
 The Static Structure of the Rational Unified
Process
The static structure deals with how process elements—activities,
disciplines, artifacts, and roles—are logically grouped into core
process disciplines. A process describes who is doing what, how,
and when.
The Static Structure of the Rational Unified
Process
 The Static Structure of the Rational Unified
Process
Roles
A role is like a "hat" that an individual (or group) wears during a
project. One individual may wear many different hats. This is an
important point because it is natural to think of a role as an
individual on the team, or as a fixed job title, but in the RUP the
roles simply define how the individuals should do the work, and
they specify the competence and responsibility that the
individual(s) playing that role should have. A person usually
performs one or more roles, and several people can perform the
same role.
 The Static Structure of the Rational Unified
Process
Activities
An activity of a specific role is a unit of work that an individual in that role may be
asked to perform. The activity has a clear purpose, usually expressed in terms of
creating or updating some artifacts, such as a model, a component, or a plan.
Each activity is assigned to a specific role. An activity generally takes a few hours
to a few days to complete, usually involves one person, and affects one or only a
small number of artifacts. An activity should be usable as an element of planning
and progress; if it is too small, it will be neglected, and if it is too large, progress
would have to be expressed in terms of an activity's parts. Activities may be
repeated several times on the same artifact—especially when going from one
iteration to another, refining and expanding the system—by the same role, but
not necessarily by the same individual.
 The Static Structure of the Rational Unified
Process
Steps
Activities are broken down into steps, which fall into three main categories:

1. Thinking steps, where the person playing the role understands the nature of
the task, gathers and examines the input artifacts, and formulates an outcome

2. Performing steps, where the role creates or updates some artifacts

3. Reviewing steps, where the role inspects the results against some criteria

Not all steps are necessarily performed each time an activity is invoked, so steps
can be expressed in the form of alternate flows.
 The Static Structure of the Rational Unified
Process

Artifacts
An artifact is a piece of information that is produced,
modified, or used by a process. Artifacts are the tangible
project elements: things the project produces or uses
while working toward the final product. Artifacts are used
as input by roles to perform an activity and are the result
or output of other activities.
The Static Structure of the Rational Unified
Process
 The Static Structure of the Rational Unified
Process

Workflows
A mere listing of all roles, activities, and artifacts does not quite
constitute a process. You need a way to describe meaningful
sequences of activities that produce some valuable result and to
show interactions between roles—this is exactly what workflows
do. Workflows come in different shapes and forms; the two most
common workflows are Disciplines, which are high-level workflows
and Workflow Details, which are workflows within a discipline.
The Static Structure of the Rational Unified
Process
 The RUP—A Customizable Process Product

Each project and each organization have unique needs requiring a

process that is adapted to their specific situation. To accommodate
this requirement, the RUP product constitutes a complete process
framework composed of several integrated parts:
 The RUP—A Customizable Process Product

Best practices. The RUP comes with a library of best practices,

produced by IBM Software and its partners. These best practices
are continually evolving and cover a broader scope than this book
can cover. The best practices are expressed in the form of phases,
roles, activities, artifacts, and workflows
 The RUP—A Customizable Process Product

Process delivery tools. The RUP is literally at the developers'

fingertips because it is delivered online using Web technology,
rather than using books or binders. This delivery allows the process
to be integrated with the many software development tools in the
Rational Suite and with any other tools so developers can access
process guidance within the tool they are using.
 The RUP—A Customizable Process Product

Configuration tools. The RUP's modular and electronic

form allows it to be tailored and configured to suit the
specific needs of a development organization
 The RUP—A Customizable Process Product

Process authoring tools. Rational Process Workbench

(RPW) is a process authoring tool, allowing you to capture
your own best practices into the RUP format
The RUP—A Customizable Process Product

Community/Marketplace: The Rational Developer

Network (RDN) online community allows users to
exchange experiences with peers and experts, and
provides access to the latest information in terms of
artifacts, articles, or additional RUP content.
The RUP Process Framework. The RUP product consists of a broad set of best
practices, configuration tools for selecting appropriate best practices, process
delivery tools for accessing these best practices, an online community for
exchanging artifacts and experiences, and process authoring tools for adding
your own best practices to the RUP.
 The RUP—A Customizable Process Product

Who Uses the RUP Product?

Roughly 10,000 companies are using the RUP product.
They use it in various application domains, evenly
distributed over both large and small projects. This variety
shows the versatility and wide applicability of the RUP
product. Here are examples of the various industry
sectors around the world that use it:
The RUP—A Customizable Process Product
Who Uses the RUP Product?
 Conclusion

We discussed that the Rational Unified Process, or the

RUP, denotes three very different things:
 Conclusion

1. The RUP is an approach for developing software,

which is iterative, architecture-centric, and use-case-
driven. It is described in whitepapers and books, and the
most complete set of information about the RUP
approach can be found in the RUP product itself.
 Conclusion

2. The RUP is a well-defined and well-structured

software engineering process. It clearly defines project
milestones, who is responsible for what, how things are
done, and when you should do them.
 Conclusion

3. The RUP is also a process product that provides you

with a customizable process framework for software
engineering. You can configure the RUP product to
support small or large teams and disciplined or less-
formal approaches to development. It also allows you to
add your own best practices and to share experiences and
artifacts with peers and experts.