is RUP (Rational Unified Process)?
aspects of RUP and how it is used.
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 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, Requirements (capture, management), Analysis and
Design, Implementation, Testing, Deployment
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 artefact).
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 -
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
Degree of Requirements/Design Change expected - low Probability of Requirements/Design Change expected -
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:
1. The overall project risk profile is front-loaded.
2.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.
3. Testing is a pervasive part of the framework process, with proofs/confirmations/reviews a constant theme, so
that problems and issues are flushed out as early as possible.
4. Because it is iterative, a project can be designed so that a useful prototype may be delivered early (unlike a
5. It is ideal for larger projects which have significant technical risks or are 'ground-breaking' in other
6. 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 systems architecture.
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 customisation.
The Technical Architect, lead analysts, lead designers and test team need to be well versed in the iterative
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 4,000 - 5,000 man days,
unless of course an organisation is large enough to share the overhead across other projects.
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. However, early benefits
delivery is nearly always of interest at a governance level!
© Phil Marks, February 2010
Banking, ERP and commercial systems specialisations. Find out more at=> http://www.projectpdq.com
Phil Marks, BSc, MSc, MBA, MBCS, Certified Information Technology Professional