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