Can We Learn Anything from Hardware Preventive Maintenance? Mira Kajko-Mattsson Software Maintenance Laboratory Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Electrum 230 SE-164 40 KISTA mira @dsv.su.se
Abstract
Table 1. IEEE definitions of maintenance categories.
Close scrutiny of software preventive maintenance has revealed that this domain is not unanimously and objectively understood. Confusion predominates with respect to its definition, scope and meaning. In this paper, we present the current state of software preventive maintenance and delineate the disorder reigning in this area. We also make a survey of hardware preventive maintenance in search of issues of interest to be applicable within software preventive maintenance.
IEEE 90; Std610.12-1990 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 process of retaining a hardware system or component in, or restoring it to, a state in which it can perform its required functions. See also: preventive maintenance. Corrective maintenance: Maintenance performed to correct faults in hardware or software. Adaptive maintenance: Software maintenance performed to make a computer program usable in a changed environment. Perfective maintenance: Software maintenance performed to improve the performance, maintainability, or other attributes of a computer program. Preventive maintenance: Maintenance performed for the purpose of preventing problems before they occur. ~
Keywords: software preventive maintenance, hardware preventive maintenance, software ageing, maintainability.
Introduction
1
IEEE 98. Std 1219-1998 Software Maintenance: Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered faults. Adaptive maintenance: Modification of a software product performed after delivery to keep a computer program usable in a changed or changing environment. Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. Preventive maintenance: IEEE Std 1219 does not define preventive maintenance.
Close scrutiny of preventive software maintenance reveals that it suffers from a great disorder. This domain is not unanimously and objectively understood. Confusion predominates with respect to its definition, scope and meaning. In this paper, we present the state of preventive software maintenance and the disorder dominating this software engineering area. We also compare it to the state of hardware preventive maintenance. In an attempt to understand this domain, we did comprehensive literature study and we lead an international panel debate in Silicon Valley on this subject' [19, 271. To find issues of interest within hardware engineering to be applicable within software preventive maintenance, we surveyed the area of hardware preventive maintenance.
2
Maintenance requests cannot be reliably and consistently classified on an intentions basis from available objective evidence. One and the same maintenance task can be differently classified (e.g., either as corrective or perfective) depending on the intentions of the beholder
PI. Regarding the definition of preventive maintenance, the IEEE does not define preventive maintenance as a member of an exhaustive set of maintenance types [8]. It rather defines it as a type that overlaps other types such as perfective, adaptive and corrective. This means that a maintenance request can be understood as an instance of both perfective and preventive (not-either-of), or adaptive and preventive, or corrective and preventive [8]. Generally, the software community associates preventive maintenance with combating two types of ageing: software product ageing and software process
Preventive Software Maintenance
The IEEE definition of maintenance and its categories greatly contributes to this disorder. According to [8, 91, the IEEE's classification of maintenance categories is neither exhaustive nor exclusive (see Table 1).
'
Our panelists were prof. Burton Swanson (UCLA), Dr. Ned Chapin (InfoSci), prof. lvica Crnkovic (Malardalen University), Dr. Shawn Bohner (Meta Group), Mr. Jan-Ola Kruger (SAAB Aerospace), and Mr. Risto Vehvilainen (DPM Consulting Oy).
io~o-4729/01$10.00 0 2001 IEEE
106
Table 2. Swanson’s typology of maintenance [45].
execution ageing. Software product ageing is degradation in software code and documentation quality by frequent maintenance. Software process execution ageing is manifest as degradation in performance or transient failures in continuously running software systems.
2.1
____
Bases of Software Maintenance A. Corrective: performed in response to failures. 1. Processing failure 2. Performance failure 3. Implementation failure B. Adaptive: performed in response to changes in data and processing environments. 1. Change in data environment 2. Change in processing environment C. Perfective: performed to eliminate processing inefficiencies, enhance performance, or improve maintainability. 1. Processing inefficiency 2. Performance enhancement 3. Maintainability
Software product ageing
Due to frequent changes, software systems age. They grow in size and complexity; their architecture gets gradually undermined, maintainers loose their familiarity, and maintenance becomes a difficult, demanding and costly task [26, 281. To combat this, improvement of maintainability of a software product has been suggested. Maintainability has been considered to be the most important prerequisite for keeping a software system healthy, for prolonging its life length, and for minimising the life-cycle cost of a software system. Many authors have pointed out that the cost of failing to build in maintainability into a software system is very high [35, 471. Designing for ease of maintenance should already begin when the system is originally conceived during the predelivery phase [24, 35, 401. A system ill designed for maintenance cannot have maintainability retrofitted to it later [35]. Maintainability must also be continuously maintained as the system evolves. Increased maintainability reduces the maintenance effort thus enabling us to use the same resources to accomplish more change, or accomplish the same change using fewer resources [47,48]. But, what is maintainability? According to the LEEE [21], maintainability is “the ease with which a software system or a component can be modified ....”. This definition is, however, too general. The IEEE does not offer any additional specification of maintainability. Nor do the extant standard process models [ 1 1, 22, 23, 24,491. One maintenance process standard [24] strongly advocates for building in maintainability into the software product. But, it does not suggest any model for it. Individual attempts have been made by researchers to create models of maintainability [5, 20, 36, 20, 381. These models, however, strongly differ from each other. All in all, we know what maintainability is, but we have different opinions of what it looks like. As depicted in Table 1, the IEEE states that the improvement of maintainability is a constituent of perfective maintenance. When scrutinising the publications on software maintenance from the recent decade [19], we have noticed that some authors strictly adhere to the IEEE definition by claiming that maintainability is a constituent of perfective maintenance [13, 39, 42, 46, 471, while others claim that maintainability is a feature of preventive maintenance [lo, 12, 171. How did maintainability become a property of either perfective or preventive maintenance? Investigation suggests that maintainability came under the umbrella of
perfective maintenance when the IEEE [21] took over Swanson’s original categorisation of maintenance types which did not include preventive maintenance (see Table 2 to see Swanson’s original categorisation) [45]. Preventive maintenance was added subsequently by the IEEE [21] 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 and disorder within the software community. According to Swanson [48], a prevention of obsolescence is a constituent of preventive maintenance. Obsolescence of software could mean different things, for instance, software wear-out through continuous change (deteriorated maintainability in this case), or obsolescence with respect to its environment. The first type of obsolescence (the wear-out obsolescence) can be combated by the modernisation of software. To do this, we use methods for measuring the obsolescence [6] and modernisation methods for renovating the software systems. Models have been proposed that predict the wear-out obsolescence (change difficulty) [73. Various modernisation techniques such as reverse engineering and reengineering technologies have been suggested for renovating the software systems [3, 31, 341. The second type of obsolescence, on the other hand, can be remedied by adapting the software system to the new environment. According to Crnkovic [ 141, preventive maintenance is an activity during which we attempt to prevent an unnecessary change in the future. Some call this risk management. We try to look ahead, identify future risks (unknown problems), and prevent them from occurrence. Chapin claims that the most successful looking ahead is done on a scheduled basis [8]. Scheduled maintenance is a cost-effective way of conducting maintenance today. Software preventive maintenance could become part of the software maintenance work in scheduled maintenance. This view has been shared by many other authors. For instance, Pearce suggests that the reengineering process should run concurrently with the maintenance process
107
2.2
[39]. One should periodically monitor system “health” and prevent system ”illness“ by checking the system maintainability level. The degree of applying the reengineering process should not be linked to the modification rate but to the maintainability level instead
Software process execution ageing
The performance characteristics of a software system get degraded over time through continuous running. The effects become manifest in reduced service performance andor failures (system crashes or hangs). Other problems such as data inconsistency, memory leakage, unreleased file-locks, data corruption, storage space fragmentation and accumulation of round-off errors may also occur. “Software rejuvenation” has been advocated as a preventive maintenance measure [ l , 15, 181. 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 the occurrence of more severe and thereby more costly failures.
WI. Using programming style guidelines has been suggested as another method of preventive maintenance. Good programming style can reduce the impact of change and thereby reduce the Occurrence of failures and decrease the maintenance costs [33]. Writing reusable software has also been proposed as an ingredient of preventive maintenance [33]. Reusing well-tested software packages designed for a specific purpose increases efficiency within corrective maintenance [6]. The announcement of new releases containing corrections to the reported software problems corresponds to an industrial understanding of preventive maintenance [27]. It is probably one of the very few preventive methods utilised by the industry today. Many organisations have a high pressure to release new products quickly. In such situations, little attention is given to maintainability. Also resources are too scarce to conduct any form of maintainability control. Tight schedules and squeezed budgets make incorporation of preventive maintenance into the average maintenance work almost impossible. A still typical approach to software maintenance is a quick-fix approach [2]. Maintenance engineers analyse code, infuse some changes into it, and release a new software version thus rendering the system to be less maintainable for each new release. Swanson claims that not only software systems should be preventatively maintained, but also the user knowledge of particular systems [46]. Actually, most organisations today view this as a preventive measure. Significant resources are saved at the upfiont maintenance process level by providing ( 1 ) an ongoing user training in relevant systems and their operation, (b) written recoveryhestart instructions, and (c) notification about known problems [lo, 251. Finally, some authors are of the opinion that preventive maintenance is highly relevant for both safetycritical and non-safety-critical systems. The cost of hardware or software systems being unavailable when required (in peacetime or wartime) is very hard to quantify [15, 30, 441. There is only one numerical evidence showing that for non-safety-critical software systems, it cost over 3.8 billion dollars in lost revenue and productivity in the United States alone in 1991 [44]. Due to this high cost and the continuous growth of software systems in their number and complexity, we simply cannot afford not to perform preventive maintenance on the non-safety-critical systems.
3
Hardware Preventive Maintenance
Hardware maintenance has been extensively researched on, whereas the topic of hardware preventive maintenance has received less attention. The hardware maintenance phase far outweighs the hardware development phase in terms of time and cost. Hardware preventive maintenance involves much greater expenditures than the corrective hardware maintenance [41. The goal of hardware preventive maintenance is to keep installations in normal operating conditions, avoid the deterioration of its components, and prevent them from outage and failures [4]. In many mechanical systems, components wear out as they get older. Their time to failure is age- and usagerelated. If not attended to in time, they may not only fail but also lead to a substantial ripple effect causing damage to many other “healthy” components. For this reason, it is often cost-effective to attend to hardware system components before they fail [50]. Hardware components may be attended to in two ways either by being repaired or replaced. The replacement is often more popular because it allows high availability of systems without compromising their safety andor production capacity. It is accomplished by removing faulty or aged hardware components and replacing them with spare ones. The removed components are then recovered to become spare parts in other systems. Today, the following hardware maintenance types are defined (1) hardware corrective maintenance, (2) planned preventive maintenance, (3) hardware on-condition maintenance, (4) hardware opportunistic maintenance, and ( 5 ) hardware evolutionary maintenance. Hardware Corrective Maintenance is called “breakdown” or “run-to-failure maintenance”. It is performed to restore a system to a state of functioning after the system has entered a state of failure [30]. It is best suited for non-critical systems where capital costs are small, the consequences of failures are slight, there are no
108
safety risks, the failures are easily identified, and the repair is quick [43]. Planned Preventive Maintenance is a scheduled hardware maintenance conducted at predefined ages of the system. Other term for planned preventive maintenance is “hardware preventive maintenance” [43]. The maintenance task (a replacement) is made at a scheduled point in time confident of preventing the hardware component from failing. To be able to do it, it is necessary to estimate mean operating time between failures (MTBF), acceptable number of failures, and a hard life of a system or a system component. Hard life refers to the age at which age-based preventive replacement is to be performed. It is usually based on the expected life of a component or the expected number of failures in that component. This type of maintenance is best suited for systems having a clear wear-out characteristic [43]. Due to the fact that many hardware components do not always obey any wear-out model, the hardware community agrees that this type of maintenance is not always economical [16, 30,431. Hardware On-Condition Maintenance is a preventive maintenance triggered by some predefined value(s) indicating the deteriorated “health” of a hardware system [16, 301. Other term for the on-condition maintenance is “condition based maintenance” [43]. The state of hardware devices is monitored in order to reveal their deteriorated state [ 161. One conducts regular tasks such as scheduled inspections and measurements rather than repair or replacement. Maintenance actions are only scheduled when they are required. For doing this, one needs a preventive maintenance plan with predetermined event types and their values revealing the deteriorated state of the maintained hardware object [ 161. The hardware on-condition maintenance is an expensive type of preventive maintenance. Hence, it should not be applied on all products - only on the most “critical” ones - the ones affecting safety, capital value, and the value of production [43]. Hardware Opportunistic Maintenance may be corrective, preventive or on-condition, but differs from these in so far as it is done when the system is being maintained for some other reason [30]. Hardware Evolutionary Maintenance is the most recent suggestion for a type of hardware preventive maintenance. Removal of hardware components at predetermined ages, as it is the case within planned preventive maintenance, may result in loss of useful life of those components. The ideal situation would be to replace components just before they are about to fail. For this reason, there is a tendency towards prolonging the hard life of a hardware component without increasing the risk of failure. To be able to do this, the maintenance and inspection schedule is continuously adjusted after every
maintenance service. The time interval to the next maintenance andor inspection is determined on the basis of the condition of the hardware component at the moment of the maintenance service. Usually, this time interval decreases in tact the hardware component ages. Within hardware engineering, a maintained systedcomponent can never be restored to an “as good as new” condition [37]. When maintenance is performed by replacing a failed component, or an ageing component with a new one, the performance of the new component would be no longer “as good as new”. Its performance would be the result of its joint performance together with the other already aged components. Hence, the system should acquire the new reality in its survivability profile WI.
4
Final Remarks
In this paper, we have presented the state of preventive maintenance both within software and hardware engineering. We are conscious of the fact that these two domains are different and that they may not be directly comparable. On the basis of our results, we conclude that there is more order within hardware preventive maintenance than within software preventive maintenance. The domain of software preventive maintenance suffers from chaos. The IEEE Standard Glossary does not define preventive maintenance as a member of an exhaustive set of maintenance types [ 8 ] . We have different understanding of preventive maintenance, and we lack an objective understanding of maintainability. The following headlines covey the present understanding of software preventive maintenance: 0 Prevention of software product ageing. Prevention of software process execution ageing [ 1, 15, 181. Prevention of unnecessary change [6, 141, Prevention of failures [48], Prevention of cost [48] Prevention of obsolescence [48], Construction of reusable components [6], Maintenance without knowing problems [14]. Rigorous software development process [29]. Scheduled maintenance [8]. Risk management [5 13. Regular activities based on software conditions and needs [audience of 271, Prevention of more costly maintenance [audience of 271, Due diligence [audience of 271, Changing code prior to customer complaints [9]. Maintenance of user knowledge of particular software products [46], Announcement of corrected releases 1271.
109
on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 1990, pp. 328-334. [14] Prof. Ivica Cmkovic’s expressed opinion (from Malardalen University) during the panel session [27]. [IS] Garg S, Puliafito S, Telek M, Trivedi K, S., Analysis of Preventive Maintenance in Transaction Based Software Systems, IEEE Trans. On Computers, 47(1), pp. 96-107, 1998. 161 Hameury H, Monitoring of States and Preventive Maintenance, CIRED 97, June, 2-5, 1997, Conference Publications No. 438, IEEE 1997, pp. 1.20.1-4. 171 Harjani D-R, Queille J-P, A Process Model for the Maintenance of Large Space Systems Software, Proceedings. International Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 1992, pp. 127-136. 181 Huang Y, Kintala C, Kollettis N, Software rejuvenation: Analysis, module and applications. Proceedings, 25” Int. Symposium on Fault-Tolerance Computing (FTCS-25), Pasadena, CA, USA, 1995. [ 191 Proceedings, International Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 1988-2000. [20] IEEE, Software Quality Metrics Methodology Standard, P106D20, IEEE Computer Society Press, 1989. [21] IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 (1991 Corrected Edition). The Institute of Electrical and Electronics Engineers, Inc., 1994. [22] IEEE Standard for Software Maintenance, IEEE Std 12191998. The Institute of Electrical and Electronics Engineers, Inc. 1998. [23] ISO/IEC 12207 International Standard, Information technology - Software life cycle processes, Ref. Nr. ISO/IEC 12207:1995(E). [24] ISO/IEC FDIS 14764: Information technology - Software Maintenance, Ref. No. ISO/IEC 14764:1999(E). [25] Kajko-Mattsson M, CM3: Upfront Maintenance, Proceedings, Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 200 1. [26] Kajko-Mattsson M, Forssander S, Anderson G, Software Problem Reporting and Resolution Process: State of Practice, Journal of Software Maintenance, Vol. 12, No. 5, pp. 255-285. [27] Kajko-Mattsson M, Preventive Maintenance! Do We Know What It Is? International panel, In Proceedings, International Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 2000. [28] Kajko-Mattsson M, Forssander S, Olsson U, Corrective Maintenance Maturity Model: Maintainer’s Education and Training, in Proceedings, International Conference of Software Engineering, Toronto, Los Alamitos, CA: IEEE Computer Society Press, 2001. (Jan[29] Jan-Ola Kruger’s expressed opinion,
[email protected]= Quality Manager, System Development, S A A B Aerospace) a panelist of [27]. [30] Kumar UD, et al. Evolutionary Maintenance for Aircraft Engines, IEEE Proceedings, Annual Reliability and Maintainability Symposium, 1999.. [31] Lanubile F, Visaggio F, Iterative Reengineering to Compensate for Quick-Fix Maintenance, Proceedings for
W e have immersed in the literature of hardware preventive maintenance with the purpose of finding issues of interest to be utilised within software preventive maintenance. Maybe, we software engineers can learn anything from hardware preventive maintenance. O n e lesson could already be learnt. Isn’t it high time that we integrated software preventive maintenance with the average maintenance work just as hardware maintenance does? The release points could provide good opportunities t o measure the maintainability of the system, and t o determine where it should be improved [32]. But before doing this, we must commonly agree on what preventive maintenance a n d maintainability is.
References [I] Avritzer A, Weyuker El, Monitoring smoothly degrading systems for increased dependability, Journal of Empirical Software Engineering, 2( I), 1997. [2] Basili V, Viewing Maintenance as Reuse-Oriented Software Development, IEEE Software, January 1990, pp. 19-25. [3] Bennet KH, Do Program Transformations Help Reverse Engineering, Proceedings, International Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, IEEE Computer Society Press in Los Alamitos CA, IEEE Computer Society Press in Los Alamitos CA, 1998, pp. 247-254. [4] Biscaglia V, Malaguti M, Gualandi P. Maintenance Planning on MV Distribution Network, CIRED 97, 2-5 June 1997, Conference Publication No. 438, pp. 3.19.13.19.4. [5] Boehm, B, W, Brown JR, Kaspar JR, et al., Characteristics of Software Quality, TRW Series of Software Technology, Amsterdam, North Holland, 1978. [6] Dr. Shawn Bohner’s expressed opinion (from Meta Group) during the panel session [27]. [7] Briand LC, Measuring and Assessing Maintainability at the End of High Level Design, Proceedings for International Conference on Software Maintenance IEEE Computer Society Press in Los Alamitos CA, 1993, pp. 88-97. [8] Chapin N, Do We Know What Preventive Maintenance Is? In Proceedings, International Conference on Software Maintenance, IEEE, Computer Society Press in Los Alamitos CA, 2000, a panelist of [27]. [9] Chapin N, Hale JE, Khan KM, Rami1 JF, Tan W-G, Types of Software Evolution and Software Maintenance, Journal of Software Maintenance, Vol. 13, No. 1, pp. 3-30. [IO] Calow H, Maintenance Productivity Factors - A Case Study, International Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 1991, pp. 250-253. [ 1 I] Carnegie Mellon University, Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1994. [12] Colbrook A, Smythe C, The Retrospective Introduction of Abstraction into Software, Proceedings for Intemational Conference on Software Maintenance, IEEE Computer Society Press in Los Alamitos CA, 1989, pp. 166-173. [I31 Cote V, St-Pierre D, A Model for Estimating Perfective Software Maintenance Projects, Proceedings, Conference
110
International Conference on Software Maintenance, 2001, 1995, pp. 140-146. [32] Lewis J, Henry S, A Methodology for Integrating Maintainability Using Software Metrics, , Proceedings for International Conference on Software Maintenance, 2001, 1989, pp. 32-39. [33] Lieberherr KJ, Holland IM, Tools for Preventive Software Maintenance, Proceedings, International Conference on Software Maintenance, 2001, 1989, pp. 174-178. [34] von Maphauser A, Wang J, Experience with Reverse Architecture Approach to Increase Understanding. Proceedings, International Conference on Software Maintenance, 2001, 1999, pp. 131-138. [35] Martin J, McClure C, Software Maintenance, The Problem and Its Solutions, Prentice-Hall, Inc., E n g l e w d Cliffs, New Jersey 07632, 1983. [36] McCall JA, Richards PK, Walters G.F, Factors in Software Quality”, RADC TR-77-369. 1977, Vols, I, 11, 111, US Rome Air Development Centre Reports NTlS AD/A-049 014,015,055, 1977. [37] Okogbaa OG,, Peng X, Time Series Intervention Analysis for Preventive/Predictive Maintenance Management of Multiunit Systems, IEEE 1998, 0-7803-4778-1/98, pp. 4659-4664. [38] Oman P, Hagemeister J, Metrics for Assessing Software System Maintainability, In Proceedings, International Conference on Software Maintenance, IEEE, Computer Society Press in Los Alamitos CA, 1992, pp. 337-344. [39] Pearse T, Maintainability Measurements on Industrial Source Code Maintenance Activities, Proceedings, lnternational Conference on Software Maintenance, 2001, 1995, pp. 295-303. [40] Pigoski TM, Practical Software Maintenance, John Wiley & Sons, 1997. [41] Reineke DM, Murdock WP, Pohl EA, Rehmert, I., Improving Availability and Cost Performence For
Complext Systems With Preventive Maintenance, Proceedings, Annual Reliability and Maintainability Symposium, IEEE, 1999, pp. 383-388. [42] Schneidewind NF, Setting Maintenance Quality Objectives and Prioritising Maintenance Work by Using Quality Metrics, International Conference on Software Maintenance, 2001, 1991, 1991, pp. 240-249. [43] Starr AG., A Structured Approach to the Selection of Condition Based Maintenance, Proceedings, 5‘h International Conference on FACTORY 2000, 2-4 April 1997, Conference Publication No. 435. [44] Stiffler, J., J., Fault-Tolerant Archtecturese - Past, Present and Future, “Lecture Notes in Computer Science, vol. 774, pp. 117-121, Berlin, Springer Verlag, 1994. [45] Swanson B, The dimensions of maintenance, Proceedings of the 2”d Intemational Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos CA, 1980, pp. 492-497. [46] Interview with E. Burton Swanson, Software Maintenance: Research and Practice, Vol. 7, 303-315, 1995. [47] Swanson BE, IS Maintainability: Should It Reduce the Maintenance Effort? SIGCPR 1999, New Orleans LA, USA. [48] Burton Swanson’s expressed opinion during the panel session [Kajk 20bl. [49] The TicklT Guide, A Guide to Software Quality Management System Construction and Certification to IS0 9001, DISC TicklT Office, 1998. Vermeulen ST, Rijanto H, van der Duyn Schouten FA., Modelling the influence of preventive maintenance on protection system reliability, IEEE Transactions on Power Delivery, Vol. 13, Nr. 4, October 1998, pp. 1027-1032. Vehvilainen R, What is Preventive Software Maintenance, Proceedings, International Conference on Software Maintenance, IEEE Computer Society Press, Los Alamitos CA, 2000, pp. 18-19, a panelist of [Kajk 20bl.
111
