Operation and maintenance:Maintenance

Maintenance

81.1 Purpose

The objective of the maintenance stage is to keep the system running at an acceptable level. This chapter discusses types of maintenance and techniques for managing maintenance.

81.2 Strengths, weaknesses, and limitations

Where appropriate, the strengths and weaknesses associated with specific maintenance tools and techniques will be discussed in context.

81.3 Inputs and related ideas

Maintenance is the last stage in the system development life cycle and, consequently, is affected by everything that happens in the previous stages. Errors made during the analysis and design stages can significantly impact maintenance. More specifically, maintenance relies on the documentation created during the analysis (Part IV), design (Part VI), testing (Chapters 74 and 75), and implementation (Chapter 76) stages, and the system maintenance life cycle parallels the system development life cycle.

81.4 Concepts

Maintenance begins when the system is released and continues for the life of the system. Over a period of years, it is not unusual for the cost of maintaining a system to significantly exceed the cost of developing it, so a primary objective is controlling maintenance costs. When the cost of maintaining and operating an obsolete or inefficient system exceeds the cost of replacing it, the system life cycle ends and a new life cycle begins.

81.4.1 Development and maintenance

The key to controlling maintenance costs is to design systems that are easy to change, so the link between development and maintenance is very strong. Using such tools as database management software (Chapter 45), data normalization (Chapter 28), program generators, fourth-generation languages, structured techniques (Chapter 62), and object-oriented techniques (Chapters 29 and 66) forces the system designer to create independent modules, to separate the logic from the data, and to avoid programming “tricks.” Coding standards can help to enforce a consistent software style that helps to minimize the maintenance programmer’s learning time. Walkthroughs and inspections (Chapter 23) are excellent tools for enforcing standards and also help to familiarize personnel with the work of others.

Many of the analysis and design methodologies, tools, and techniques employed during system development can be applied to system maintenance, but there are significant differences between development and maintenance. System development (typically) focuses on new systems and considers such issues such as functional productivity, flexibility, integrity, and user friendliness. Maintenance, in contrast, is concerned with refining and improving the operational efficiency and effectiveness of an existing system and, consequently, is constrained by the existing system’s scope, boundaries, and platform, and often must be performed in a short time frame and with a limited budget. Development is a one-time activity, so outsourcing is a viable option. Maintenance is a continuing activity more appropriately performed by in-house personnel. Finally, such resources as test data and test cases, program code, and documentation must be created by the system developers, but are available to the maintenance personnel.

81.4.2 Types of maintenance

There is much more to maintenance than fixing bugs. The categories suggested by Swanson² and extended by Reutter¹ are widely accepted.

81.4.2.1 Corrective maintenance

The objective of corrective maintenance is to remove errors or bugs from the software, the procedures, the hardware, the network, the data structures, and the documentation. Corrective maintenance activities include both emergency repairs (fire fighting) and preventive (or corrective) repairs. For example, maintenance programmers are concerned with such tasks as removing residual software bugs, improving the integrity and reliability of the programs, streamlining and tightening data validation routines, correcting invalid processing and reporting, and minimizing downtime.

Maintenance programmers use such traditional debugging tools as static code analyzers, on-line debuggers, and dynamic debugging tools. On-line debuggers are used to trace the order in which modules are executed or to exhibit the names and data values of selected variables as they change. Dynamic debugging tools are used to identify all the possible paths to a given statement, to flag all the statements that modify or access a given data element, or to allow the programmer to determine what happens if the value of a given variable is changed.

In an ideal world, systems and software are so reliable that the need for corrective maintenance does not exist, but that ideal world does not exist and probably never will. However, using such tools as database management software, application development systems, program generators, fourth-generation languages, structured techniques, and object-oriented techniques can significantly improve software reliability.

81.4.2.2 Adaptive maintenance

The point of adaptive maintenance is to enhance the system by adding features, capabilities, and functions in response to new technology, upgrades, new requirements, or new problems. Note that adaptive maintenance is reactive. The idea is to fix the system when the general business climate, competition, growth, new technology, or new regulations make change necessary. The key to minimizing adaptive maintenance costs is to isolate system-dependent features.

81.4.2.3 Perfective maintenance

The point of perfective maintenance is to enhance the system by improving efficiency, reliability, functionality, or maintainability, often in response to user or system personnel requests. Corrective and adaptive maintenance are reactive. Bugs are fixed as they are discovered. An upgrade to an operating system can necessitate a change to application software. Perfective maintenance, in contract, is proactive. The idea is to fix the system before it breaks.

Restructuring efforts are aimed at enhancing performance without changing how the system works or what it does. The code might be converted to a more efficient language or run through an optimizing compiler. Code conversion software might be used to reorganize the code or convert the logic to a more structured form. Note that the code is not rewritten, just restructured.

The point of reengineering is to change the system to make it better without affecting its functionality or external behavior. The idea is to gradually “clean up the mess” by doing such things as restructuring files and databases and encasing old code in a wrapper of well-structured or object-oriented code. Reengineered software is easier to reverse engineer or to farm out to subcontractors.

The objective of reverse engineering is to extract an abstract model from the system’s physical documentation and then use the model as a base for creating a functionally equivalent system. For example, an analysis of a set of source code might generate a structure chart, a set of data dictionary entries, or an entity-relationship diagram. Reverse engineering has been applied to software almost as long as software has existed. For example, Microsoft might reverse engineer its Excel spreadsheet program to produce equivalent programs to run on different computers or to create an object-oriented version of Excel.

81.4.2.4 Preventive maintenance

Although not explicitly part of the Swanson/Reutter model (except by implication), ongoing preventive maintenance is an important part of any system’s standard operating procedures. The objective of preventive maintenance is to anticipate problems and correct them before they occur. Files and databases must be updated, periodically reorganized, and regularly backed up. Control totals must be reset. New software releases must be installed.

System performance monitoring is an important key to preventive maintenance. The idea is to conduct periodic audits and to run regular benchmark tests to determine if the system is continuing to perform to expectations. Both hardware and software are monitored to measure system load and system utilization. The information derived from performance monitoring provides an early warning of potential system problems and often initiates other forms of maintenance.

81.4.3 Managing maintenance

Maintenance is expensive. The elements of a system often interact in unexpected ways, and ripple effects (unexpected bugs or new errors caused by a change intended to fix an initial problem) can be devastating. Sometimes, apparently unrelated maintenance problems are tightly linked. Consequently, maintenance must be carefully managed. Formal maintenance procedures are the key to managing maintenance.

81.4.3.1 The system maintenance life cycle

The system maintenance life cycle is similar to the system development life cycle. Configuration management (Chapter 80), the process of managing and controlling changes to a system, defines a context or methodology, including formal procedures for requesting, evaluating, and implementing changes. Evaluation analysis (a phase that parallels the information gathering and problem definition stage of the system development life cycle) is used to assess the impact of a proposed change. The objective is to identify and document the applications, programs, routines, and other components that must be modified, the likely impact of the change on normal operations, and the time, cost, and other resources required to implement the change. Next, the change is analyzed, designed, coded, and tested. After the work is done, the change is released (Chapter 76).

81.4.3.2 Prioritization

Given the budgetary and resource constraints imposed on the system maintenance process, it is not unusual to have a backlog of change requests. Some organizations rely on simple first-in-first-out or (less frequently) last-in-first-out schemes to prioritize the requests. Other organizations prioritize the requests based on a preliminary evaluation analysis (Section 81.4.3.1). Note that a sound evaluation analysis is the key to deciding if maintenance or new system development is needed to solve the problem.

81.4.3.3 Fire fighting

Some maintenance problems require an immediate response. Following a system crash, a major integrity threat, the release of a new government regulation with a tight deadline, or a similar problem, a fix is needed right now, and formal procedures must wait. Such fire fighting activities are (or should be) relatively rare, however, and emergency patches should be formally incorporated into a subsequent release.

81.4.3.4 Standards and quality assurance

Many system developers (and many maintainers) view all maintenance as fire fighting. Consequently, in their rush to get the job done, they sometimes ignore or disregard quality assurance and other standards. It is important that all changes be made in a consistent manner. Consequently, such standards as code efficiency targets, fault tolerance rates, operational sequence optimization guidelines, and expected performance norms must be established and enforced, and even true fire fighting activities must be brought up to standards after the fact.

81.5 Key terms

Adaptive maintenance —

Maintenance activities intended to enhance the system by adding features, capabilities, and functions in response to new technology, upgrades, new requirements, or new problems.

Configuration management —

The process of defining, managing, controlling, and auditing the changes made to the original system.

Corrective maintenance —

Maintenance activities intended to remove errors or bugs from the software, the procedures, the hardware, the network, the data structures, and the documentation.

Evaluation analysis —

A maintenance phase (similar to the problem definition stage in the system development life cycle) during which the impact of a particular change is evaluated.

Fire fighting —

Making emergency repairs, often under extreme time pressure.

Maintenance —

The final stage of the system development life cycle; a continuing series of activities and costs intended to keep the system running at an acceptable level.

Perfective maintenance —

Maintenance activities intended to enhance the system by improving efficiency, reliability, functionality, or maintainability, often in response to user or system personnel requests.

Preventive maintenance —

Regularly scheduled maintenance activities; the intent is to anticipate problems and correct them before they occur.

Reengineering —

Changing a system to make it better without affecting its functionality or external behavior.

Restructuring —

Efforts aimed at enhancing performance without changing how the system works or what it does.

Reverse engineering —

Extracting an abstract model from a system’s physical documentation and then using the model as a base for creating a functionally equivalent system.

Ripple effects —

Unexpected bugs or new errors caused by a change intended to fix an initial problem.

Static code analyzer —

A program that scans (but does not execute) the code and flags such potential errors as synonyms, poor structure, inconsistent usage, dead code, unreferenced variables, and other deviations from coding standards.

81.6 Software

Numerous configuration management and version control software packages are commercially available. Examples include CMVC (Configuration Management Version Control) from IBM, PVCS from Intersolv, SPARCworks/TeamWare from Sun Microsystems, STS/CM (Configuration Management) from Neuma Technology Corporation, VCS-UX Version Control System from Diamond Optimum Systems, Inc., and Visual SourceSafe from Microsoft. QVCS (Quma Version Control System) is a shareware product. This list is by no means complete, nor does it constitute an endorsement.

Debugging tools, such as static code analyzers, on-line debuggers, and dynamic debugging tools are found in most software development environments.

81.7 References

81.7.1 Citations

1.  Reutter, J., Maintenance is a management problem and a programmer’s opportunity, AFIPS Conf. Proc. 1981 Natl. Comput. Conf., Vol. 50, Chicago, May 4 to 7, 1981, 343.

2.  Swanson, E., The dimensions of maintenance, 2nd Int. Conf. Software Eng., Proc., San Francisco, October 13 to 15, 1976, 492.

81.7.2 Suggestions for additional reading

1.  Arthur, L. J., Software Evolution: The Software Maintenance Challenge, John Wiley & Sons, New York, 1988.

2.  Birrell, N. D. and Ould, M. A., A Practical Handbook for Software Development, Cambridge University Press, Cambridge, UK, 1985.

3.  Fournier, R., Practical Guide to Structured System Development and Maintenance, Yourdon, Englewood Cliffs, NJ, 1991.

4.  Martin, J. and McClure, C., Software Maintenance. The Problem and Its Solutions, Prentice-Hall, Englewood Cliffs, NJ, 1983.

5.  Parikh, G., Handbook of Software Maintenance, John Wiley & Sons, New York, 1985.