Page 265 -

248 Chapter 9 Software evolution

1. Number of requests for corrective maintenance An increase in the number of
bug and failure reports may indicate that more errors are being introduced into
the program than are being repaired during the maintenance process. This may
indicate a decline in maintainability.
2. Average time required for impact analysis This reflects the number of program
components that are affected by the change request. If this time increases, it implies
more and more components are affected and maintainability is decreasing.
3. Average time taken to implement a change request This is not the same as the
time for impact analysis although it may correlate with it. This is the amount of
time that you need to modify the system and its documentation, after you have
assessed which components are affected. An increase in the time needed to
implement a change may indicate a decline in maintainability.
4. Number of outstanding change requests An increase in this number over time
may imply a decline in maintainability.

You use predicted information about change requests and predictions about sys-
tem maintainability to predict maintenance costs. Most managers combine this infor-
mation with intuition and experience to estimate costs. The COCOMO 2 model of
cost estimation (Boehm et al., 2000), discussed in Chapter 24, suggests that an esti-
mate for software maintenance effort can be based on the effort to understand exist-
ing code and the effort to develop the new code.

9.3.2 Software reengineering

As I discussed in the previous section, the process of system evolution involves
understanding the program that has to be changed and then implementing these
changes. However, many systems, especially older legacy systems, are difficult to
understand and change. The programs may have been optimized for performance or
space utilization at the expense of understandability, or, over time, the initial pro-
gram structure may have been corrupted by a series of changes.
To make legacy software systems easier to maintain, you can reengineer these
systems to improve their structure and understandability. Reengineering may involve
redocumenting the system, refactoring the system architecture, translating programs
to a modern programming language, and modifying and updating the structure and
values of the system’s data. The functionality of the software is not changed and,
normally, you should try to avoid making major changes to the system architecture.
There are two important benefits from reengineering rather than replacement:

1. Reduced risk There is a high risk in redeveloping business-critical software.
Errors may be made in the system specification or there may be development
problems. Delays in introducing the new software may mean that business is
lost and extra costs are incurred.