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,
• Requirements,
• Analysis and Design,
• Implementation,
• Test,
• Deployment

and three ‘supporting disciplines’:

• Configuration and Change Management,
• Project Management,
• Environment.

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 - 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 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 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 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. Early benefits delivery is nearly always of interest at a governance level.

© 2010 Phil Marks. All Trade and Service marks acknowledged.