Page 269 -

252 Chapter 9 Software evolution

Refactoring, carried out during program development, is an effective way to
reduce the long-term maintenance costs of a program. However, if you take over a
program for maintenance whose structure has been significantly degraded, then it
may be practically impossible to refactor the code alone. You may also have to think
about design refactoring, which is likely to be a more expensive and difficult prob-
lem. Design refactoring involves identifying relevant design patterns (discussed in
Chapter 7) and replacing existing code with code that implements these design pat-
terns (Kerievsky, 2004). I don’t have space to discuss this here.

9.4 Legacy system management

For new software systems developed using modern software engineering processes,
such as incremental development and CBSE, it is possible to plan how to integrate
system development and evolution. More and more companies are starting to under-
stand that the system development process is a whole life-cycle process and that an
artificial separation between software development and software maintenance is
unhelpful. However, there are still many legacy systems that are critical business sys-
tems. These have to be extended and adapted to changing e-business practices.
Most organizations usually have a portfolio of legacy systems that they use, with
a limited budget for maintaining and upgrading these systems. They have to decide
how to get the best return on their investment. This involves making a realistic
assessment of their legacy systems and then deciding on the most appropriate strat-
egy for evolving these systems. There are four strategic options:

1. Scrap the system completely This option should be chosen when the system is
not making an effective contribution to business processes. This commonly
occurs when business processes have changed since the system was installed
and are no longer reliant on the legacy system.
2. Leave the system unchanged and continue with regular maintenance This
option should be chosen when the system is still required but is fairly stable and
the system users make relatively few change requests.
3. Reengineer the system to improve its maintainability This option should be
chosen when the system quality has been degraded by change and where a new
change to the system is still being proposed. This process may include develop-
ing new interface components so that the original system can work with other,
newer systems.
4. Replace all or part of the system with a new system This option should be cho-
sen when factors, such as new hardware, mean that the old system cannot con-
tinue in operation or where off-the-shelf systems would allow the new system to
be developed at a reasonable cost. In many cases, an evolutionary replacement
strategy can be adopted in which major system components are replaced by off-
the-shelf systems with other components reused wherever possible.