Maintenance

7.4 Maintenance

A frequently quoted fact of the software industry is that something like 70% of the SLC is devoted to maintenance. There may be empirical data somewhere to back this up, or it may just be someone's off-the-cuff observation. The important thing is that it indicates that many companies expend a large share of their software resources in maintenance activities.

Clearly, the heavy majority of effort in the SLC is expended in the maintenance phase. One bank interviewed by the author asserted that no new code had been developed in 15 years. All development activity involved maintenance and enhancement of existing software. While maintenance is considered to be composed of both defect correction and enhancements to the original system, most maintenance is the result of requirements or design deficiency or planned obsolescence. (Planned obsolescence is usually termed phased implementation.) Certainly there will be occurrences of latent coding defects that remained hidden through the testing process, but the majority of defects usually are found to be faulty requirements and design.

Two points about maintenance should be made. First, except for the very simple correction of a very simple coding defect, maintenance is usually a repeat of the SDLC activities. Second, the cost of maintenance is almost never clearly known or recorded.

The role of software quality practitioners is also two-fold: (1) monitor the SDLC-type activities the same as was done in original development, and (2) try to help management realize the true cost of the maintenance effort. Once management can see and understand the cost of maintenance, the task of justifying the SQS activities will become much more achievable.

7.4.1 Types of maintenance

Four broad categories of maintenance are repairs, adaptations, enhancements, and polishing. Repairs are necessary to resolve latent defects that survived the best efforts of the testing program and add improvements to make the system do those things that were wanted but were left out of the original requirements or design. As shown in Figure 7.6, repair of actual defects that were found after the system was placed in full operation account for about 20% of the maintenance activity. Another percentage is the result of additions made to bring the system up to the level of capability originally desired, which might be called polishing. Little definitive data exist to express the degree of effort expended in making these changes, but at least a portion of the enhancement number will include requirements corrections as well as new requirements.

Figure 7.6: Maintenance types.

Enhancements, shown as the largest category in Figure 7.6, are those changes to give the system capabilities that were not originally foreseen. Often, enhancements come at the request of the user who finds that additional capabilities would be desirable. While new requirements and needs frequently do arise over the life of a software system, it is likely that many corrections are being identified as enhancements. Requirements that were overlooked or ignored during the original development often come back as enhancements. That may happen even though they probably were caused by errors in the requirements analysis or design portions of development. Maintenance that is deemed an enhancement should not include any changes that help the system perform as it should have originally.

Adaptations, another large category, are generally in response to changing environmental conditions or the outside world. Environmental conditions might include a change to a different computer or a new operating system. Outside conditions could include a change in government regulations relating to an insurance or banking system.

Software quality practitioners must be closely involved in the maintenance activity to ensure that proper control of the software and documentation configurations is enforced. In a protracted maintenance period, the loss of control of the configuration can mean the introduction of new defects as the existing ones are being found and corrected. Software quality practitioners will monitor and audit the defect reporting and tracking system reports and ensure that the CM function is in operation throughout the maintenance period.

7.4.1.1 Repairs

Repairs reflect defects identified by and reported from all sources. Repairs are the changes made for every defect from the simplest latent coding mistake, such as a misspelled data name, to a requirements deficiency. While repairs consume a minority percentage of the overall SLC costs, they do represent the most expensive tasks. Defects that must be repaired in the maintenance phase almost always affect more than just the code. As stated in Section 7.4.1, those requirements that were known but not addressed should be categorized as defects and processed as repairs.

Each repair will result in the reentry of the development cycle, as shown in Figure 7.7. Each repair must go through the full life cycle as the requirements of the repair are determined: that is, design, code, test, and implementation. The type and impact of the defect will determine how far back into the development products the repair will reach. In the large majority of cases, the ramifications go back through code to design and sometimes requirements. This, in turn, means corrections to documentation, sometimes corrections to other parts of the system in order to accommodate the repair, testing of the changed areas, and regression testing of the entire system. The cost of repairing a requirements defect in the maintenance phase may be as much as 100 times the cost to repair the defect if it had been found in the requirements phase.

Figure 7.7: Repeating the life cycle.

Estimates are that about a third of all corrections themselves introduce new defects. Introduction of new defects is the case especially when short cuts are taken in the repair process. If CM procedures are skipped or testing is slipshod or incomplete, the chances of introducing a new defect are greatly magnified.

7.4.1.2 Adaptations

Adaptations are the modification of capabilities to meet changes from outside the original system. Activities such as these include changes to meet new government regulations, modifications to company procedures, inclusions of new products, and similar conditions that did not exist at the time of the development of the original system.

Adaptations also include those changes made to accommodate implementation approaches. A typical type of implementation approach is the phased implementation. This is usually done when the schedule, the complexity of the system, or outside situations such as hardware availability will not permit implementation of the entire capability of the system all at once. The adaptations are the changes to the edges of the implemented software to interface with the next phase of software being implemented. Since some of the total software system has been missing up to this point, something has been done to allow the existing software to operate until the new software is added. These allowances must be removed when the next software is ready for implementation.

Most often, the problem is in the development planning for the system. Resources, generally schedule resources, are miscalculated and run out before the system is ready for implementation. In this case, the system is partitioned into functional groups that can be implemented one or a few at a time. Some subset of the system is installed, and then, at a later time, additional system partitions are installed piecemeal until the full system is in place. This has the advantage of permitting more attention to the various phases of the SDLC, but it usually is a repair in the context of this chapter.

Only in those cases where there was good reason at the outset to plan for a phased implementation can this not be considered a repair. One case would be an experimental system in which each step is a major evaluation—and possible termination—point of the development. Other cases would be those in which the system has a large number of outside interfaces that become available at inconvenient times or where the complexity of the system dictates that smaller sections be installed one by one. It is probably appropriate to exclude these cases from the realm of maintenance altogether, since they were planned to occur from the beginning of the project.

Adaptations carry significant risk in some cases. There is small risk when the adaptation takes the form of a simple change to a job-entry routine or a spreadsheet formula. They become more threatening when they entail modifications as great as database reconfiguration. Software quality practitioners must monitor adaptations as closely as the other types of maintenance.

7.4.1.3 Enhancements

Enhancements usually follow the full SDLC.

Enhancements occur because the original requirements did not address some need of the user or customer. They are limited to those needs that became visible or recognized after the system has been installed and running. Enhancements cover the addition of new capabilities and the removal of obsolete capabilities. Work performed to modify the software to meet original requirements that were overlooked or misleading is more correctly classed with repairs.

Again, Figure 7.7 shows the return path to the SDLC. Enhancements always reenter the SDLC at the requirements phase, since new requirements are almost always involved, and the entire SDLC traversed. New development planning must take place, which must include planning for the transition to the improved system once it is ready. There may also be some consideration given to provision of the needed capabilities until the software is ready to support them. The entire SDLC is then followed, just as in the original development. Testing and CM play a large role in the enhancement process, just as they do in the repairs process. As discussed in Section 4.1.5.1, regression testing is especially important as well.

The software quality practitioner has the same set of functions in the repair and enhancement processes as in the original development. Since the SDLC is being followed, so must the SQS procedures.

7.4.1.4 Polishing

Polishing may be some of the most difficult of maintenance to perform. Most polishing is performed to increase the operating speed of an application or to reduce its memory requirements. Quite often, these changes can be extremely far-reaching, as loops are removed from the code to increase speed or added to reduce size. When both goals are present, large-scale reengineering of the system may be required. The software quality practitioner should be sure that all participants in the polishing maintenance activities are aware of the breadth of the effects their changes may have. If the polishing is being performed to more closely meet original requirements, it should probably be called a repair. If it is modifying the software in response to external changes, it is more likely an adaptation. Often, polishing may be change for change's sake and not justified at all.

7.4.2 Documentation

Regardless of why or where the SDLC is reentered, it is essential that the system documentation be maintained. It cannot be stressed too much that the documentation of the system is the key to the ease of repair or enhancement. The better the documentation, the more easily the maintenance personnel can find and correct a defect or properly install an enhancement. If the needed documentation is lacking, the maintainer must either recreate it or try to find the affected portion of the system through detective work. When the issues of the documents for the various phases are out of step, as discussed in Section 6.4.2, the maintainer has more work to do in the documentation of his or her work as well.

If more that one change is in progress at one time, such as both an enhancement and a repair, poor documentation practices may allow the two activities to operate on different issues of the system or to conflict with each other. If the documentation is up-to-date and correct, both maintainers can recognize any areas of overlap in their work and can work together during the change process rather than creating another defect that must be repaired.

Software quality practitioners perform an important monitoring and reporting function in the maintenance phase by keeping management informed as to the quality and status of the documentation.

7.4.3 Regression testing

The software quality practitioner has an additional concern in the maintenance phase, that of ensuring that regression testing is accomplished. While the software quality practitioner must monitor the regular SDLC testing function, the maintenance phase introduces the regression testing activity. Although the SDLC is used to create repairs and enhancements, these normally affect only a portion of the entire system. Once the change has been tested for its own correctness, the full system must undergo overall testing to ensure that the changes have not had some unexpected negative effect on the operation of the system as a full entity.

As stated in Section 4.1.5.1, regression testing should be a part of the overall test plan developed for the system during its original SDLC. As the system acceptance test is designed, and data for the test is prepared, a subset of the acceptance test data should be preserved for future regression tests. The expected and actual results should also be preserved. In that way, the correct performance of the original system is known. When regression testing is needed, the same test data that were used for the acceptance test are used. The original results should be received from unchanged parts of the system, showing that unintentional changes have not been made or new defects introduced.

For those changed portions of the system, new regression test data must be prepared for use in future change activity. The software quality practitioner has the responsibility of ensuring that the regression tests are prepared in the beginning and that they are kept up to date during the full SLC. Further, the practitioner must ensure that all differences from the expected results of the regression tests are accounted for.

7.4.4 Maintenance wrap-up

The great majority of effort in the SLC is expended in the maintenance phase.

Repairs make up a significant portion, if not the majority, of the maintenance effort. Repairs include latent defects that survived the testing program and implementing enhancements or improvements required to make the system perform those tasks that were wanted but were left out of the original requirements or design. True enhancements are those additions or modifications that enable the software to perform functions not originally wanted or needed.

Software quality practitioners must be closely involved in the maintenance activity to ensure that proper control of the software and documentation configurations is enforced and that regression testing is fully performed. The software quality practitioner has the responsibility of ensuring that the regression tests are prepared in the beginning and that they are kept up-to-date during the full SLC.

Software quality practitioners perform an important monitoring and reporting function in the maintenance phase by keeping management informed as to the quality and status of the documentation and code.