What is RUP and Why Use it?
by Phil Marks
What is RUP?
RUP is the abbreviation for “Rational Unified Process” - a systems development
methodology devised by Rational Unified Corporation and now owned by IBM. The author has no connection with
any of these organisations, but has used the process framework in major development projects.
The process was developed as a result of work done by Booch, Jacobson and Rumbaugh
(affectionately known as the Three Amigos), who were in large part the designers of UML (“Universal Modelling
Language). The RUP concept was based on an analysis of what really happens in development projects and why many
projects fail (typically the ‘failure rate’ is 30%).
It fits into the ‘Agile’ project management spectrum at the top end, after XP, Scrum,
RAD and DSDM on a scale of complexity and team size.
By designing the project process in a way which ensures that the riskiest items are
addressed according to highest risk first, then the overall project risk (as initially perceived) is not reduced at
first, but the risk of a large project gaining momentum and then collapsing spectacularly at a late stage is
aggressively addressed. This means that the risk of failure should clearly taper off as a project progresses – this
is quite different to what happens in many ‘traditional’ projects. Of course, it will not protect against the risk
of a business paradigm shift that has not been foreseen.
Briefly, RUP identifies nine project disciplines:
six ‘engineering disciplines’:
- Business Modeling,
- Analysis and Design,
and three ‘supporting disciplines’:
- Configuration and Change Management,
- Project Management,
These are supported by software toolsets (for example UML modelling tools, automated
testing and test management tools and so on). Iterative working is an essential component of the process structure,
with artefacts (in Prince terms these would be called products) being continually refined and retested (remember
that even a test plan should be checked against its defined standards, as it is itself a project
A project is defined in terms of four phases:
1. Inception – this is the high level design of the project itself, including governance,
business case, budgets, risks, plans and, often, assessment of an architectural prototype. The exit gateway is
called the Lifecycle Objective Milestone – that is, what the project is seeking to achieve over the complete
lifecycle (including realisation of the benefits).
Degree of Requirements/Design Changes expected – high
Probability of Requirements/Design Change expected – high
2. Elaboration - this phase involves extension of the teams, design products and prototype
buildout, enhancement of project processes (eg testing) infrastructure, and so on, with a formal exit gateway
known as the Lifecycle Architecture Milestone, the passing of which confirms that an executable architecture has
been demonstrated which ‘realises’, – that is physically delivers – the architecturally risky Use Cases and how
their associated risks are mitigated. It also requires that 80% of Use Cases have been identified and designed,
prioritised according to risk, together with rework of the Business Case and Risks. There are other important
‘tangibles’ required at this time too, including the software architecture model and the development plan. At this
point the project will move into a phase where the risk profile is raised (relatively) as changes will be more
difficult to accommodate.
Degree of Requirements/Design Change expected – moderate
Probability of Requirements/Design Change expected - moderate
3. Construction – in traditional terms, this is where the bulk of the system is built. The
exit gateway is known as the Initial Operational Capability Milestone. In other words, at the end of this phase it
is now ‘on the runway’.
Degree of Requirements/Design Change expected – low
Probability of Requirements/Design Change expected - moderate
4. Transition – the system moves into production, it is available in beta form to the users
and training is underway. It is reviewed against the quality criteria established during the Inception Phase. The
exit gateway is called the Product Release Milestone.
Why Use RUP?
The main reasons are:
- The overall project risk profile is front-loaded.
- The technically risky aspects of the system are addressed and proven early in the
project. If not, the project is redesigned or cancelled before significant resources are committed.
- Each formal phase has its own inbuilt inception, elaboration, construction and
transition phases. After all, the project manager has to ‘deliver the milestones’. This gives the project a
‘fractal’ structure, even down to lowest level programming tasks.
- Testing is a pervasive of the framework process, with proofs/confirmations/reviews a
constant theme, so that problems and issues are flushed out as early as possible.
- Because it is iterative, a project can be designed so that a useful prototype may be
delivered early (unlike a waterfall approach).
- It is ideal for larger projects which have significant technical risks or are
‘ground-breaking’ in other ways.
- The iterative buildout and incremental delivery approach lends itself to situations
where a business area is undergoing rapid change, so that there is early delivery of value, and the shape of
the system can be coupled to the rate of change; this however will also require a suitably flexible underlying
How Should it be Used?
It requires a suitably experienced project manager to make it work effectively. It can be
applied with a light touch or a heavy touch – the experienced project manager will be able to apply a ‘contingent’
approach and adjust the intensity of the process implementation according to the risk profile, team experience and
so on. Indeed, the ability to customise the process is key attribute of a suitable project manager, as the process
lends itself very well to customoisation.
The Technical Architect, lead analysts, lead designers and test team need to be well versed
in the iterative approach.
To be used properly, it will require investment in software toolsets and infrastructure.
Given this, the minimum project size at which the process framework becomes practical is probably in the region of
3,000 – 5,000 man days, unless of course an organisation is large enough to share the overhead across other
It is important that the process is well-understood at the highest levels of project
governance, as the iterative approach is not always easy to grasp by people who are used to a waterfall structure.
Early benefits delivery is nearly always of interest at a governance level.
© 2010 Phil Marks. All Trade and Service marks acknowledged.