Preventive Maintenance! Do we know what it is? Mira Kajko-Mattsson Software Maintenance Laboratory Department of Computer and Systems Sciences Stockholm UniversityRoyal Institute of Technology Electrum 230 SE-164 40 KISTA
[email protected] Abstract
IEEE 94. Std 610.12-1990 1131 Maintenance-( I ) The process of modifying a software system or component after delivery to correct faults. improve performance or other attributes, or adapt to a changed environment. ( 2 ) The pracesr ofretaining a hardware system or component in. or restoring it to. a state in which it can perform its required functions. Srr U/JW preventive maintenance. CorrertivemrintenPnfe: Maintenance performed to correct faults in hardware or software. Adaptive maintenance Software maintenance performed to make a computer program usable xn a changed environment Perfectivemaintenance: Software maintenance performed to improve the performance. maintainability. or other attributes of a computer program Preventivemaintenance: Maintenance performed for the purpose of preventing problems before they occur.
Inconsistency exists within the software community surrounding the understanding of and the adherence to the IEEE definition of preventive maintenance, due to congruence between the IEEE definitions of perfective and preventive maintenance. A panel debate is advocated to discuss the definition and current state of preventive maintenance practice.
1
IEEE 94. Std 12194998 1141 Software Maintenance: Modification of a software product after delivery to correct faults. IO improve performance or other attributes, or to adapt the product to a modified environment. Correctivemaintenance: Reactive modification of a software product performed after deliver! to correct discovered faults. Adaptive maintenancc Modification o f a software product performed after delivery lo keep B computer program usable in a changed or changing environment. Perfectivemaintenance: Modification of a software product after delivery to improve performance or maintainability. Preventivemaintenance: IEEE Std 1219-1998 doer not define preventive maintenance.
Introduction
Close scrutiny reveals inconsistency in the way the software community interprets and applies the IEEE definition of preventive maintenance [ 13, 141. Analysis contrasting current practice with the IEEE definition of maintenance and its categories (see Table 1) [13, 141, reveals overlap between preventive and perfective maintenance. This paper advocates a panel debate to discuss the following: 1.
What is preventive software maintenance?
2.
What is the current state of preventive software maintenance practice within research and industry?
3.
Why does preventive maintenance mean different things to differentpeople?
4.
Is there any overlap between preventive maintenance and other categories such as perfective, adaptive or corrective maintenance?
5.
Should preventive software maintenance concern safety critical systems only?
6.
Can we as software engineers learn anything from preventive hardware maintenance?
Table 1. IEEE definitions of maintenance categories.
2
Current state of practice
Maintenance means working with ageing software. Two types of software ageing have been identified: software product ageing and software process execution ageing. Software product ageing is degradation in software code and documentation quality by continual maintenance. Software process execution ageing is manifest as degradation in performance or transient failures in continuously running software systems.
2.1
Software product ageing
Improving maintainability is one method suggested for combating software product ageing. Maintainability is “the ease with which a software system or a component can be modified ....” [13]. According to the IEEE [13, 141, maintainability is included in perfective maintenance. Some authors adhere strictly to this definition [9, 21, 23, 25, 261, while others claim that maintainability is a feature of preventive maintenance [6, 8, 1 I].
1063-6773/00$10.000 2000 IEEE
In order b provide an early evaluation of system maintainability, models have been proposed that predict change difficulty in the maintenance process [4]. Various
12
reverse engineering and reengineering technologies have been suggested for improving maintainability [3, 17, 191. According to Pearse [21], the reengineering process should run concurrently with the general maintenance process. One should periodically monitor system ”health” and prevent system “illness” by checking the system maintainability level. The frequency of applying the reengineering process should not be linked to the modification rate but to the maintainability level [ 171.
suggests that maintainability came under the umbrella of perfective maintenance when the IEEE [ 131 took over Swanson’s original categorisation of maintenance types [24] which did not include preventive maintenance. Preventive maintenance was added subsequently by the IEEE [13] without the overall revision of the existing maintenance categories and their definitions. This has led to the overlap between perfective and preventive maintenance, thereby causing some degree of confusion within the software community.
Using programming style guidelines has been suggested as a method for improving preventive maintenance. Good programming style can reduce the impact of change and thereby reduce maintenance costs [18]. Writing reusable software has also been proposed for promoting preventive maintenance [ 181. Reusing welltested software increases efficiency during the corrective maintenance phase.
When scrutinising IEEE definitions of the other maintenance categories, it becomes apparent that the IEEE definition of perfective maintenance does not explicitly express its objectives. Enhancements for example are not stated explicitly as a constituent, though can be implicitly understood by inference from“improved performance” [ 13, 141 and “other attributes” [ 131 (see Table 1).
Issuing corrected release announcements is also seen by industry as a form of preventive maintenance. Reporting a recurring software problem is costly for both the maintainer and user, especially when the product has a large usership [I]. The cost of preparing and distributing the corrected product to all users must always be weighed up against the resources needed to reactively manage software problems for the individual user at the upfront and execution maintenance process levels [ 151.
Acquiring an understanding of preventive maintenance requires the reader’s immersion in the pertinent literature on maintenance and its various categories. This reveals that disagreement not only exists regarding defining preventive maintenance, but also in defining software maintenance, its categories and scope, and the dividing line between software development and software maintenance [ 2 6 ] . Given the disagreements, it is of little wonder that software maintenance costs vary between 40%-90% of total software life cycle costs.
Swanson claims that not only software, but also user knowledge of particular. systems should be maintained [25]. Most organisations today view this as a preventive measure. Significant resources can be saved at the upfront maintenance process level [ 151 through providing (a) ongoing user training in relevant systems and their operation, (b) written recovery/restart instructions [5], and (c) notification about known problems.
2.2
The majority of the maintenance categories are today covered by generic maintenance process models. Unfortunately these generalised models do not help us in acquiring an objective understanding of the scope of each maintenance category. One remedy would be to agree on a single classification system for maintenance categories and their inherent activities. There have already been some attempts made in this direction [7, 16, 201. One common, detailed classification system would substantially aid the creation of specialised process models for each maintenance category. This would provide good opportunity for scrutinis ing the definition of each category and its respective name, aims and most importantly would lead us towards a common and objective understanding.
Software process execution ageing
The performance characteristics of a software system are degraded over time through continuous running. The effects become manifest in reduced service performance and/or failures (system crashes or hangs). Other problems such as data inconsistency, memory leakage, unreleased file-locks, data corruption, storage space fragmentation and an accumulation of round-off errors may also occur.
Acknowledgements
“Software rejuvenation” has been advocated as a preventive maintenance measure [2, 10, 121. The software is periodically stopped and restarted in order to refresh its internal state. This prevents, or at least postpones the occurrence of failures. Though software rejuvenation implies overheads, it prevents more severe (and therefore more costly) failures.
3
I wish to thank the Swedish National Board for Industrial and Technical Development (NUTEK) for making this study possible.
References [l]
Final remarks
How did maintainability become a property of either perfective or preventive maintenance? Investigation
13
Adams, E., N., Optimising Preventive Service of Software Products, IBM/Research and Development, vol. 28, no. 1, pp. 2-14, January 1984.
[41
[51
Avritzer A., Weyuker, E., J., Monitoring smoothly degrading systems for increased dependability, Joumal of Empirical Software Engineering, 2( I), 1997.
IEEE Standard for Software Maintenance, IEEE Std 1219- 1998. The Institute of Electrical and Electronics Engineers, Inc. 1998.
Bennet, K., H., Do Program Transformations Help Reverse Engineering, Proceedings for International Conference on Software Maintenance, Bethesda, Maryland, USA, November 16-20, 1998, pp. 247-254.
Kajko-Mattsson, Mira, Maintenance at ABB (I): Software Problem Administration Processes, Proceedings, Conference on Software Maintenance, Oxford, Sept, 1999.
Briand, L., C., Measuring and Assessing Maintainability at the End of High Level Design, Proceedings for International Conference on Software Maintenance, Montreal, Quebec, Canada, September 27-30, 1993, pp. 88-97.
Kitchenham B., et al., Toward an Ontology of Software Maintenance. Joumal of Software Maintenance 1999, 1 1 (6):365-389. Lanubile, F., Visaggio, F., Iterative Reengineering to Compensate for Quick-Fix Maintenance, Proceedings for Intemational Conference on Software Maintenance, Opio (Nice), France, October 17-20, 1995, pp. 140-146.
Calow, H., Maintenance Productivity Factors - A Case Study, International Conference on Software Maintenance, Sorrento, Italy, 1991, October 15-17, 1991, pp. 250-253.
Lieberherr, K., J., Holland I., M., Tools for Preventive Software Maintenance, Proceedings for International Conference on Software Maintenance, Miami, Florida, October 16-19, 1989, pp. 174-178.
Capretz, M., A., M., Munro M., CONFORM - A Software Maintenance Method Based on the Software Configuration Management Discipline, Proceedings for International Conference on Software Maintenance, Orlando, Florida, November 9-12, 1992, pp. 183-192.
von Mayrhauser, A., Wang, J., Experience with Reverse Architecture Approach to Increase Understanding. Proceedings for Intemational Conference on Software Maintenance, Oxford, England, August 30 - September 13, 1 9 9 9 , ~131-138. ~.
Chapin, N., The job of software maintenance. In Proceedings Conference on Software Maintenance, 1987, Los Alamitos CA, 1987; 4-12.
Parikh G . The several worlds of software maintenance a proposed software maintenance taxonomy. ACM SIGSOFT Software Engineering Notes 1987, 12(2):5I53.
Colbrook A., Smythe C., The Retrospective Introduction of Abstraction into Software, Proceedings for International Conference on Software Maintenance, Miami, Florida, October 16-19, 1989, pp. 166-173.
Pearse, T., Maintainability Measurements on Industrial Source Code Maintenance Activities, Proceedings for Intemational Conference on Software Maintenance, Opio (Nice), France, October 17-20, 1995, pp. 295-303.
Cote, V., St-Pierre, D., A Model for Estimating Perfective Software Maintenance Projects, Conference on Software Maintenance, San Diego, California, November, 26-29, 1990, pp. 328-334.
Pigoski, T., M., Practical Software Maintenance, John Wiley & Sons, 1997.
Garg S., Puliafito S., Telek M., Trivedi K., S., Analysis of Preventive Maintenance in Transaction Based Software Systems, IEEE Trans. On Computers, 47( l), pp. 96-107, 1998.
Schneidewind, N., F., Setting Maintenance Quality Objectives and Prioritising Maintenance Work by Using Quality Metrics, International Conference on Software Maintenance, Sorrenio, Italy, 1991, October 15-17, 1991, pp. 240-249.
Hajani, D.-R., Queille, J.-P., Proceedings for International Conference on Software Maintenance, Orlando, Florida, November 9-12, 1992, pp. 127-136.
Swanson, B., The dimensions of maintenance, Proceedings of the 2"d International Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos CA, pp. 492-497.
Huang, Y., Kintala C., Kollettis N., Software rejuvenation: Analysis, module and applications. In Proc. of 25Ih Int. Symposium on Fault-Tolerance Computing (FTCS-25), Pasadena, CA, USA, June 1995.
Interview with E. Burton Swanson, Software Maintenance: Research and Practice, Vol. 7, 303-3 15, 1995.
IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 (1991 Corrected Edition). The Institute of Electrical and Electronics Engineers, Inc., 1994.
Swanson, B., E., IS Maintainability: Should It Reduce the Maintenance Effort? SIGCPR 1999, New Orleans LA, USA.
14
