Information Technology Reference
In-Depth Information
When a new release of a system is created, the changes which have been made
may introduce new faults or bring other existing faults to light. The more changes
that are made to a system, the more new faults will be introduced. Therefore, if a
release incorporates a large number of changes, it is likely that there will be a
correspondingly large number of new faults. These have to be fixed in the next
system release.
Lehman's fifth law, the Law of Conservation of Familiarity, suggests that over
the lifetime of a system, the incremental system change in each release is
approximately constant. This 'law' was derived by analyzing systems over many
years and measuring the number of system modules which were modified in each
release.
Lehman suggested that if a lot of new functionality was introduced in one
release of a system, it would be necessary to issue another release fairly quickly.
This would be required to correct errors that have resulted from the system
changes and to improve the performance of the delivered release. Over the lifetime
of a system, this was seen to be a self-regulating process. There was a limit to the
rate at which new functionality could be introduced. This suggests that it is unwise
to change too much of a system's functionality at once. Otherwise an excessive
number of faults may be introduced. A good change strategy is to interweave fault
repair releases and releases which change the system's functionality.
If some system changes are concerned with fault repair and others with
changing the system behavior, mixing these changes into a single release could
cause problems. The faults reported apply to a given version of the system code
and if that code is changed to amend its behavior, it is expensive to check if the
faults still apply. All serious faults (faults which cause system corruption) should
be repaired before functional or behavioral changes are applied.
Release management is complicated by the fact that customers may not actually
want a new release of the system. Some system users may be happy with an
existing system version. They may consider that it is not worth the cost of
changing to a new release. However, as the system's functionality is enhanced,
most customers will eventually decide to change.
This causes CM problems because new releases of the system cannot depend on
the existence of previous releases. Consider the following scenario:
1. Release I of a system is distributed and put into use.
2. Release 2 follows which requires the installation of new data files but some
customers do not need the facilities of release 2 so remain with release 1.
3. Release 3 requires the data files installed in release 2 and has no new data files
of its own.
The software distributor cannot assume that the files required for Release 3
have already been installed in all sites. Some sites may go directly from Release I
to Release 3, skipping Release 2. Some sites may have modified the data files
associated with Release 2 to reflect local circumstances. Therefore, the data files
must be re-distributed and installed again with Release 3 of the system.
