Page 67 -

50 Chapter 2 Software processes

The main difference between the spiral model and other software process models is
its explicit recognition of risk. A cycle of the spiral begins by elaborating objectives
such as performance and functionality. Alternative ways of achieving these objec-
tives, and dealing with the constraints on each of them, are then enumerated. Each
alternative is assessed against each objective and sources of project risk are identi-
fied. The next step is to resolve these risks by information-gathering activities such
as more detailed analysis, prototyping, and simulation.
Once risks have been assessed, some development is carried out, followed by a plan-
ning activity for the next phase of the process. Informally, risk simply means something
that can go wrong. For example, if the intention is to use a new programming language,
a risk is that the available compilers are unreliable or do not produce sufficiently effi-
cient object code. Risks lead to proposed software changes and project problems such as
schedule and cost overrun, so risk minimization is a very important project management
activity. Risk management, an essential part of project management, is covered in
Chapter 22.

2.4 The Rational Unified Process

The Rational Unified Process (RUP) (Krutchen, 2003) is an example of a modern
process model that has been derived from work on the UML and the associated Unified
Software Development Process (Rumbaugh, et al., 1999; Arlow and Neustadt, 2005).
I have included a description here, as it is a good example of a hybrid process model.
It brings together elements from all of the generic process models (Section 2.1), illus-
trates good practice in specification and design (Section 2.2) and supports prototyping
and incremental delivery (Section 2.3).
The RUP recognizes that conventional process models present a single view of
the process. In contrast, the RUP is normally described from three perspectives:

1. A dynamic perspective, which shows the phases of the model over time.

2. A static perspective, which shows the process activities that are enacted.
3. A practice perspective, which suggests good practices to be used during the process.

Most descriptions of the RUP attempt to combine the static and dynamic perspec-
tives in a single diagram (Krutchen, 2003). I think that makes the process harder to
understand, so I use separate descriptions of each of these perspectives.
The RUP is a phased model that identifies four discrete phases in the software
process. However, unlike the waterfall model where phases are equated with process
activities, the phases in the RUP are more closely related to business rather than
technical concerns. Figure 2.11 shows the phases in the RUP. These are:

1. Inception The goal of the inception phase is to establish a business case for the
system. You should identify all external entities (people and systems) that will