Hoja de presentacion

How to Fail with the Rational Unified Process:
Seven Steps to Pain and Suffering
Craig Larman
Chief Scientist, Valtech USA
craig@craiglarman.com
Philippe Kruchten
Rational Fellow, Rational Software Canada
pbk@rational.com
Kurt Bittner
General Manager, Process and Project Management Business Unit, Rational Software
kbittner@rational.com

Abstract: The Rational Unified Process providesa valuable framework for approaching
the business of developing software. As a framework, however, it must be adapted to the
needs of each project team and their circumstances; it is intended to be applied in a light
and agile style, and not adopted as a one-size-fits-all process. This article shares a number
of common pitfalls experienced by teams attempting to adapt the Rational UnifiedProcess to their needs, presented with a little tongue-in-cheek.

The Rational Unified Process (RUP®) [1] [2] has emerged as a popular de facto standard modern software
development process—we feel with good reason. It combines recognized best practices such as adaptive,
iterative, and risk-driven development; has been developed by world-class leaders with experience in both
small and largesystems development; is flexible in its application and extension; and has been coherently
documented in both print and the online RUP product.
Yet, there are factors inhibiting the successful adoption of the RUP, leading to far less than optimal results.
There are patterns in these failures if you wish to learn from them; to that end, if your goal is spectacular
failure with the RUP, we recommendthe following steps.

Step 1: Superimpose “Waterfall” Thinking
Does your development process look something like this?
1.
2.
3.
4.

Try to define and stabilize most of the requirements; sign-off on them.
Do detailed design, based on the requirements.
Implement, based on the design.
Integration, system testing, and deployment.

© Copyright Valtech Technologies & Rational Software,2001

1/14

7/14/2002

This is an example of a linear, sequential “waterfall” lifecycle, and is the first, best, and most common
strategy for total RUP failure. If your process feels anything like the above, you know you have
successfully n ot adopted the RUP.
It has been argued [3] that the waterfall lifecycle as originally intended would not lead to the degree of
failure it hasengendered, and it is rather due to misunderstanding that it has been unskillfully applied. Point
taken, but we are discussing the waterfall as it is commonly applied or misapplied today.
With respect to failure levels, note that an analysis of project success and failure in 1994 [4], when most
development was purely a d hoc or based on waterfall process practices (as today, we would argue),
estimatedthat only 70% of software projects were completed, that over 50% cost at least twice their
original estimate, and that $81 billion US was spent on cancelled projects in the USA alone. This is an
extraordinary problem rate; business as usual is not working.
To their credit, the US Department of Defense, a major contractor of software development services, which
originally promoted waterfallprocesses and attitudes, upon observing so much failure with the approach,
has not only dropped this requirement (removed in 1988 in STD-2167A), but in a 1994 report started to
actively encourage more modern iterative lifecycles to replace the waterfall [5]. Yet, inertia is a problem
and there remains superimposition of “waterfall attitudes” on to projects—“Congratulations, the DoD will
use aniterative process for this project. Now, step one: Please submit the complete requirements so we can
sign off on them. Then we’ll nail down the design, …”
The waterfall-inspired processes were a reaction to prior 1960s a d hoc approaches to developing software.
In contrast to the prior lack of structure, it was a rational response; indeed, waterfall methods of this era
were called structured...