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.
RUP was the result of work by 'The Three Amigos' - (Booch, Jacobson and Rumbaugh who earlier developed UML) on what really happens in projects and why they fail.
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.
The project process is designed in a way which ensures that the highly risky items (often architecture both software and hardware) are addressed first. The overall project risk (as initially perceived) is not reduced at first, but the risk of a large project becoming 'unstoppable' and then collapsing amidst major grief and financial write-off at a late stage is aggressively addressed. This means that the overall risk of failure should clearly taper off as a project progresses - this is quite different to what happens in many typical non-Agile projects. Of course, it will not protect against the risk of a business paradigm shift that has not been foreseen.
In summary, 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, Environment 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 - 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 final phase as the system moves into production. Available in a beta version to the users and training is underway. It is reviewed against the quality criteria defined during the Inception Phase. The exit gateway is called the Product Release Milestone.
Why Use RUP?
The main reasons are:
1. The project risk profile is front-loaded.
2.Technical risks are addressed by priority and mitigation is 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 of the framework process. Testing effort is required throughout, with proofs/confirmations/reviews a constant theme, so that problems and issues are flushed out as early as possible, both from non software products and other project products such as Use Cases, budgets, plans and infrastructure behaviours.
4. Because it is iterative, a project can be designed so that a useful prototype may be delivered early (unlike a waterfall approach).
5. It is ideal for larger projects which have significant technical risks or are 'ground-breaking' in other ways.
6. The iterative buildout and incremental delivery structure is ideal for situations where a business area is undergoing rapid change, so that there is early delivery of value. The shape of the system can therefore 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 approach.
To work effectively, a RUP deployment 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!
Author Resource:
Highly experienced Banking, ERP and commercial systems development project manager. Find out more at=> www.projectpdq.com Phil Marks, BSc, MSc, MBA, MBCS, Certified Information Technology Professional
![[Valid RSS feed]](http://www.articlecoop.com/images/icon_Rss.png "XML Feed For RSS"){kind=icon}
Category Rss Feed
Print This Article
Add To Favorites
