Page 263 -

246 Chapter 9 Software evolution

Documentation

System documentation can help the maintenance process by providing maintainers with information about the
structure and organization of the system and the features that it offers to system users. Although proponents of
agile approaches such as XP suggest that the code should be the principal documentation, higher-level design
models and information about dependencies and constraints can make it easier to understand and make
changes to the code.
I have written a separate chapter on documentation that you can download.
http://www.SoftwareEngineering-9.com/Web/ExtraChaps/Documentation.pdf

4. Program age and structure As changes are made to programs, their structure
tends to degrade. Consequently, as programs age, they become harder to under-
stand and change. Some systems have been developed without modern software
engineering techniques. They may never have been well structured and were
perhaps optimized for efficiency rather than understandability. System docu-
mentation may be lost or inconsistent. Old systems may not have been subject to
stringent configuration management so time is often wasted finding the right
versions of system components to change.

The first three of these problems stem from the fact that many organizations still
consider development and maintenance to be separate activities. Maintenance is seen
as a second-class activity and there is no incentive to spend money during development
to reduce the costs of system change. The only long-term solution to this problem is to
accept that systems rarely have a defined lifetime but continue in use, in some form,
for an indefinite period. As I suggested in the introduction, you should think of sys-
tems as evolving throughout their lifetime through a continual development process.
The fourth issue, the problem of degraded system structure, is the easiest problem
to address. Software reengineering techniques (described later in this chapter) may
be applied to improve the system structure and understandability. Architectural
transformations can adapt the system to new hardware. Refactoring can improve the
quality of the system code and make it easier to change.

9.3.1 Maintenance prediction

Managers hate surprises, especially if these result in unexpectedly high costs. You
should therefore try to predict what system changes might be proposed and what
parts of the system are likely to be the most difficult to maintain. You should also
try to estimate the overall maintenance costs for a system in a given time period.
Figure 9.10 shows these predictions and associated questions.
Predicting the number of change requests for a system requires an understanding
of the relationship between the system and its external environment. Some systems
have a very complex relationship with their external environment and changes to that