Page 252 -

Chapter 9 Software evolution 235

Software development does not stop when a system is delivered but continues
throughout the lifetime of the system. After a system has been deployed, it inevitably
has to change if it is to remain useful. Business changes and changes to user expec-
tations generate new requirements for the existing software. Parts of the software
may have to be modified to correct errors that are found in operation, to adapt it for
changes to its hardware and software platform, and to improve its performance or
other non-functional characteristics.
Software evolution is important because organizations have invested large
amounts of money in their software and are now completely dependent on these sys-
tems. Their systems are critical business assets and they have to invest in system
change to maintain the value of these assets. Consequently, most large companies
spend more on maintaining existing systems than on new systems development.
Based on an informal industry poll, Erlikh (2000) suggests that 85–90% of organiza-
tional software costs are evolution costs. Other surveys suggest that about two-thirds
of software costs are evolution costs. For sure, the costs of software change are a
large part of the IT budget for all companies.
Software evolution may be triggered by changing business requirements, by
reports of software defects, or by changes to other systems in a software system’s
environment. Hopkins and Jenkins (2008) have coined the term ‘brownfield software
development’ to describe situations in which software systems have to be developed
and managed in an environment where they are dependent on many other software
systems.
Therefore, the evolution of a system can rarely be considered in isolation.
Changes to the environment lead to system change that may then trigger further
environmental changes. Of course, the fact that systems have to evolve in a ‘systems-
rich’ environment often increases the difficulties and costs of evolution. As well as
understanding and analyzing an impact of a proposed change on the system itself,
you may also have to assess how this may affect other systems in the operational
environment.
Useful software systems often have a very long lifetime. For example, large mili-
tary or infrastructure systems, such as air traffic control systems, may have a lifetime
of 30 years or more. Business systems are often more than 10 years old. Software
cost a lot of money so a company has to use a software system for many years to get
a return on its investment. Obviously, the requirements of the installed systems
change as the business and its environment change. Therefore, new releases of the
systems, incorporating changes, and updates, are usually created at regular intervals.
You should, therefore, think of software engineering as a spiral process with
requirements, design, implementation, and testing going on throughout the lifetime
of the system (Figure 9.1). You start by creating release 1 of the system. Once deliv-
ered, changes are proposed and the development of release 2 starts almost immedi-
ately. In fact, the need for evolution may become obvious even before the system is
deployed so that later releases of the software may be under development before the
current version has been released.
This model of software evolution implies that a single organization is responsible
for both the initial software development and the evolution of the software. Most