Page 259 -

242 Chapter 9 Software evolution

changes and the costs involved. Such decisions take time to make and, sometimes, it
takes longer to decide on the changes to be made than change implementation. The
speed of the organization’s decision-making processes therefore governs the rate of
change of the system.
Lehman’s fourth law suggests that most large programming projects work in a
‘saturated’ state. That is, a change to resources or staffing has imperceptible effects
on the long-term evolution of the system. This is consistent with the third law, which
suggests that program evolution is largely independent of management decisions.
This law confirms that large software development teams are often unproductive
because communication overheads dominate the work of the team.
Lehman’s fifth law is concerned with the change increments in each system
release. Adding new functionality to a system inevitably introduces new system
faults. The more functionality added in each release, the more faults there will be.
Therefore, a large increment in functionality in one system release means that this
will have to be followed by a further release in which the new system faults are
repaired. Relatively little new functionality should be included in this release. This
law suggests that you should not budget for large functionality increments in each
release without taking into account the need for fault repair.
The first five laws were in Lehman’s initial proposals; the remaining laws were
added after further work. The sixth and seventh laws are similar and essentially say
that users of software will become increasingly unhappy with it unless it is main-
tained and new functionality is added to it. The final law reflects the most recent
work on feedback processes, although it is not yet clear how this can be applied in
practical software development.
Lehman’s observations seem generally sensible. They should be taken into
account when planning the maintenance process. It may be that business considera-
tions require them to be ignored at any one time. For example, for marketing rea-
sons, it may be necessary to make several major system changes in a single release.
The likely consequences of this are that one or more releases devoted to error repair
are likely to be required. You often see this in personal computer software when a
major new release of an application is often quickly followed by a bug repair update.

9.3 Software maintenance

Software maintenance is the general process of changing a system after it has been
delivered. The term is usually applied to custom software in which separate develop-
ment groups are involved before and after delivery. The changes made to the software
may be simple changes to correct coding errors, more extensive changes to correct
design errors, or significant enhancements to correct specification errors or accom-
modate new requirements. Changes are implemented by modifying existing system
components and, where necessary, by adding new components to the system.
There are three different types of software maintenance: