3.3 Introducing the Unified Process

The Unified Process (UP) (Jacobson et al, 1999) has emerged as a popular iterative and incremental development process for building enterprise systems based on an object-oriented approach, and using UML. It promotes a set of best practices, namely that development should be organised in short timeboxed iterations and that it should be adaptive to accommodate inevitable change. A commercial version of the UP, the Rational Unified Process (RUP) (Krutchen, 1999), is its most well-known implementation although there are many others around. RUP was developed by Rational, which was acquired by IBM in 2003. We will, from here onwards, be talking about the UP but the characteristics of the process that are mentioned are also present in the RUP.

Timeboxing means that a (usually) short fixed period – for example, three to four weeks – is devoted to each iteration. Consequently, at each iteration only a small set of requirements is considered and progressed to the implementation and testing stages. Each iteration results in a working but possibly not yet complete system that normally delivers an increment of functionality on the previous incomplete system. Typically many iterations with progressive integration of increments are required before the product can be delivered.

Being adaptive means that adjustments are allowed at each iteration. The motivation for this is the recognition that requirements may change throughout development, and that such changes should be welcome rather than resisted. By involving customers and users at each iteration, feedback can be gained quickly and the required adjustments made within the next iteration. So each iteration may provide an increment over the previous one, or simply revisit its output.

Other best practices promoted by UP are:

• dealing with high-risk issues in early iterations
• prioritising the user’s perspective by involving users in requirements, evaluation and feedback
• building a view of the system’s architecture in early iterations.

A UP project is organised into four major phases:

1. Inception. The business case is developed, together with an idea of the scope of the system and a rough estimate of the effort required.
2. Elaboration. The core of the system is developed in an iterative fashion. In this phase all major risks are addressed and resolved, most of the requirements are identified and dealt with, and a more realistic estimate of the effort required is made.
3. Construction. The final product is constructed, including the remaining lower-risk and easier elements of the system, again in an iterative fashion.
4. Transition. This includes beta testing and deploying the system.

Within the UP phases, development work is organised within many disciplines, the UP term for development activities such as requirements, analysis, design and testing. An example of disciplines and their relationship to UP phases is shown in Figure 9.

Maximise

Figure 9 UP phases and disciplines

Show description|Hide description

This shows a square with columns representing the UP phases, named from left to right: inception, elaboration, construction and transition. The rows in the square represent the UP disciplines named from top to bottom: domain modelling, requirements, analysis and design, implementation, testing, project management and deployment. Each of the UP phases is split into further columns each representing an iteration.

Figure 9 UP phases and disciplines

The figure illustrates what a UP project might look like. The columns represent iterations. For each discipline, the relative effort is represented throughout the UP phases and their iterations. For instance, most of the domain modelling (referred to as business modelling in the UP) occurs in the early iterations of the inception and elaboration phases, while most of the implementation occurs within the construction phase.