3 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. It promotes a set of best practices, namely that development should be organised in short time-boxed iterations, and that it should be adaptive to accommodate inevitable change.

Time boxing means that a (usually) short fixed period of time is devoted to each iteration, e.g. three to four weeks. Consequently, only a small set of requirements is considered at each iteration and progressed to the implementation and testing stages Each iteration results in an executable, but incomplete system. Typically, many iterations and progressive integration of increments are required before the product can be delivered.

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 dealt with 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. Hence, each iteration may provide an increment over, or simply revisit the output of, the previous one.

Other best practices promoted by UP are:

• dealing with high-risk issues in early iterations;

• giving the users' perspective great importance in the process and involving them in the definition of 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 – this is where 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 – this is where 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 – this is where the remaining lower risk and easier elements of the system are constructed, 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. ‘Discipline’ is the UP term for development activities such as requirements analysis and testing. An example of disciplines and their relation to UP phases is given in Figure 3. (A detailed analysis of all of the disciplines here is outside the scope of this course.)

Figure 3 UP phases and disciplines

The figure is only illustrative of what a UP project would 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 occurs in the early iterations of the inception and elaboration phases, while most of the implementation occurs within the construction phase.

This course is loosely based on the UP, with a focus on the elaboration phase and the disciplines of domain modelling (often referred to as business modelling), requirements analysis and design, and to some extent implementation and testing.

The techniques you will learn are not specific to the UP, though. In fact, they can be used in many iterative and incremental processes based on an object-oriented approach to software.