Page 61 -

44 Chapter 2 Software processes

Define System Assess Existing Propose System Modify
Requirements Systems Changes Systems

Existing New
Figure 2.8 System Systems System
evolution

Change adds to the costs of software development because it usually means that
work that has been completed has to be redone. This is called rework. For example, if
the relationships between the requirements in a system have been analyzed and new
requirements are then identified, some or all of the requirements analysis has to be
repeated. It may then be necessary to redesign the system to deliver the new require-
ments, change any programs that have been developed, and re-test the system.
There are two related approaches that may be used to reduce the costs of rework:

1. Change avoidance, where the software process includes activities that can antic-
ipate possible changes before significant rework is required. For example, a pro-
totype system may be developed to show some key features of the system to
customers. They can experiment with the prototype and refine their require-
ments before committing to high software production costs.
2. Change tolerance, where the process is designed so that changes can be accom-
modated at relatively low cost. This normally involves some form of incremen-
tal development. Proposed changes may be implemented in increments that
have not yet been developed. If this is impossible, then only a single increment
(a small part of the system) may have to be altered to incorporate the change.

In this section, I discuss two ways of coping with change and changing system
requirements. These are:

1. System prototyping, where a version of the system or part of the system is developed
quickly to check the customer’s requirements and the feasibility of some design
decisions. This supports change avoidance as it allows users to experiment with the
system before delivery and so refine their requirements. The number of require-
ments change proposals made after delivery is therefore likely to be reduced.
2. Incremental delivery, where system increments are delivered to the customer for
comment and experimentation. This supports both change avoidance and
change tolerance. It avoids the premature commitment to requirements for the
whole system and allows changes to be incorporated into later increments at rel-
atively low cost.

The notion of refactoring, namely improving the structure and organization of a
program, is also an important mechanism that supports change tolerance. I discuss
this in Chapter 3, which covers agile methods.