Rational Unified Process

The rational unified process (RUP) centres around the use of the Unified Modelling Language (UML). UML is a method for diagrammatically representing systems as a set of clearly defined objects interacting with each other in discreet behaviours(use cases). Behaviours are described using sequence diagrams which are basically time lines showing how actions by one object lead to actions by other objects.

ALL the business objects in a system are modelled in this way, not just those intended to be represented in code. During planning analysts work with the customer to identify and describe, in normal language, a conclusive list of 'Use Cases'. A use case describes a single user interaction with the system as a narrative which includes the systems internal response to user actions. Use cases are then used as the basis for sequence diagrams.

UML diagrams are meant to serve the same purpose in a software project as blue prints do in a building project. They are technical enough to provide an unambiguous specification for the developer but sufficiently intuitive that a layman can usefully review them with only a little help. Use cases also provide a means of forming unambiguous consensus during the analysis phase.

An interesting feature of UML is that once it has been captured in a software package it can be used to generate a code framework which can be fleshed out by human developers.

The rational unified process is iterative on a longer time scale than other adaptive (agile) methodologies. Each iteration is intended for full deployment and is not a mere user feedback point. It is intended that a project should be designed to undergo several releases increasing in power each time. Each iteration consists of 4 formal phases as follows.

Inception phase

The purpose of this phase is to make sure the iteration has a valid business case and to provide a baseline for future monitoring. The artefacts from this stage include

business case
success factors
expected revenue
market recognition
financial forecast
a basic use case model
project plan
risk assessment
project description
core project requirements
constraints
key features

the project may be cancelled at this stage if the sponsor is not content with the results, or it may be repeated with fresh assumptions.

Elaboration phase

During this phase the object model is developed and the use cases identified in the inception phase are added to and fleshed out. Everything is done to prepare for coding. All the black holes should be resolved or mitigated. At the end of this phase all the UML documentation should be comprehensive and complete.

As well as UML modelling uncertainties concerning technologies should be resolved with prototypes and experimental code. By the end of this phase there should be no major uncertainties about how things are to be developed.

The end of the Elaboration phase is marked by the Lifecycle Architecture Milestone.

Construction phase

This is when most of the coding happens. On large projects this phase may be broken down into iterations to validate the whole system a few use cases at a time. At the end of this phase the first release of code is issued to the customer.

It is believed that the use of UML to unambiguously describe the system being built will reduce the possibility that code has to be reworked because it does not do what the user wants or does not fit in with other systems.

The end of the construction phase is called the Initial Operational Capability Milestone.

Transition phase

During this phase the system is bedded in. The end users are trained. Bugs are reported and fixed.

This phase ends with Product Release Milestone.