Page 65 -

48 Chapter 2 Software processes

that customers are less likely to encounter software failures in the most impor-
tant parts of the system.

However, there are problems with incremental delivery:

1. Most systems require a set of basic facilities that are used by different parts of the
system. As requirements are not defined in detail until an increment is to be
implemented, it can be hard to identify common facilities that are needed by all
increments.
2. Iterative development can also be difficult when a replacement system is being
developed. Users want all of the functionality of the old system and are often
unwilling to experiment with an incomplete new system. Therefore, getting use-
ful customer feedback is difficult.
3. The essence of iterative processes is that the specification is developed in conjunc-
tion with the software. However, this conflicts with the procurement model of
many organizations, where the complete system specification is part of the system
development contract. In the incremental approach, there is no complete system
specification until the final increment is specified. This requires a new form of
contract, which large customers such as government agencies may find difficult to
accommodate.

There are some types of system where incremental development and delivery is
not the best approach. These are very large systems where development may involve
teams working in different locations, some embedded systems where the software
depends on hardware development and some critical systems where all the require-
ments must be analyzed to check for interactions that may compromise the safety or
security of the system.
These systems, of course, suffer from the same problems of uncertain and chang-
ing requirements. Therefore, to address these problems and get some of the benefits
of incremental development, a process may be used in which a system prototype is
developed iteratively and used as a platform for experiments with the system
requirements and design. With the experience gained from the prototype, definitive
requirements can then be agreed.

2.3.3 Boehm’s spiral model
A risk-driven software process framework (the spiral model) was proposed by
Boehm (1988). This is shown in Figure 2.11. Here, the software process is repre-
sented as a spiral, rather than a sequence of activities with some backtracking from
one activity to another. Each loop in the spiral represents a phase of the software
process. Thus, the innermost loop might be concerned with system feasibility, the
next loop with requirements definition, the next loop with system design, and so on.
The spiral model combines change avoidance with change tolerance. It assumes that