Page 253 -

236 Chapter 9 Software evolution

Specification Implementation

Start
etc.
Release 1
Operation Validation

Release 2
Figure 9.1 A spiral Release 3
model of development
and evolution
packaged software products are developed using this approach. For custom software,
a different approach is commonly used. A software company develops software for a
customer and the customer’s own development staff then take over the system. They
are responsible for software evolution. Alternatively, the software customer might
issue a separate contract to a different company for system support and evolution.
In this case, there are likely to be discontinuities in the spiral process. Requirements
and design documents may not be passed from one company to another. Companies
may merge or reorganize and inherit software from other companies, and then find
that this has to be changed. When the transition from development to evolution is not
seamless, the process of changing the software after delivery is often called ‘soft-
ware maintenance’. As I discuss later in this chapter, maintenance involves extra
process activities, such as program understanding, in addition to the normal activi-
ties of software development.
Rajlich and Bennett (2000) proposed an alternative view of the software evolution
life cycle, as shown in Figure 9.2. In this model, they distinguish between evolution
and servicing. Evolution is the phase in which significant changes to the software
architecture and functionality may be made. During servicing, the only changes that
are made are relatively small, essential changes.
During evolution, the software is used successfully and there is a constant stream
of proposed requirements changes. However, as the software is modified, its struc-
ture tends to degrade and changes become more and more expensive. This often hap-
pens after a few years of use when other environmental changes, such as hardware
and operating systems, are also often required. At some stage in the life cycle, the
software reaches a transition point where significant changes, implementing new
requirements, become less and less cost effective.

Initial Evolution Servicing Phaseout
Figure 9.2 Evolution Development
and servicing