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