Information Technology Reference
In-Depth Information
11.7.2 Authorizing Changes to the Product
A maintenance programmer is assigned the task of determining the fault that
caused the failure and repairing it. After the code has been changed, the repair
must be tested, as must the product as a whole. Then, the documentation must be
reviewed and updated to reflect the changes. In particular, a detailed description of
what was changed, why it was changed, by whom, and when must be added to the
prologue comments of any changed code artifact. A similar set of steps is followed
when performing perfective or adaptive maintenance; the only difference is they
are initiated by a change in requirements rather than by a defect report. Before the
product is distributed, it must be subjected to software quality assurance testing
performed by an independent group; that is the members of the maintenance SQA
group must not report to the same manager as the maintenance programmer.
Testing during post-delivery maintenance is difficult and time consuming, and the
SQA group should not underestimate the implications of the software maintenance
with regard to testing. Once the new version has been approved by the SQA group,
it can be distributed (Schach
2007
).
11.7.3 Ensuring Maintainability
A well-written product goes through a series of different versions over its lifetime.
As a result, it is necessary to plan for post-delivery maintenance during the entire
software process. During the design workflow, information hiding techniques
should be employed; during the implementation variable names should be selected
that will be meaningful to future maintenance programmers. Documentation
should be complete, correct and reflect the current version of every component
code artifact of the product. In other words, just as software development per-
sonnel should always be conscious of inevitable post-delivery maintenance, so
software maintenance personnel should always be equally conscious of future post-
delivery maintenance (Schach
2007
).
11.7.4 Problem of Repeated Maintenance
One of the most frustrating difficulties of software development is the moving-target
problem. As fast as the developer constructs the product, the client can change the
requirements. Not only is this frustrating to the development team, frequent changes
can result in a poorly constructed product. These also may result in an increased cost
of the product. The more a completed product is changed, the more it deviates from
its original design, and the more difficult further changes become. Under repeated
maintenance, the documentation is likely to become even less reliable than usual,
and the regression testing data may not be up to date (Schach
2007
).
