Home

Software Maintenance Lifecycle Modeling

D Vijay Rao, VVS Sarma and NK Srinivasan Department of Computer Science & Automation Indian Institute of Science Bangalore 560 012, India.

Abstract

Maintenance of legacy systems, representing a massive, long-term business investment, is an important but relatively new research area. A generic, unified lifecycle model (ULM) integrating the product, process and project views of software development and maintenance based on re- entrant lines is proposed. The proposed re-entrant line model represents the software maintenance process in a software organisation. The existing model for software development predicts project metrics such as the development time, cost and product quality for any new project to be taken up by the organization. The routing matrix of the artifacts in the ULM can be modified to derive different types of lifecycle models such as Waterfall, Prototyping, Spiral and Hybrid models. The ULM is modified to depict the complex set of activities associated with software maintenance. Quantitative metrics such as release time of versions, cost, time and effort for maintenance are estimated using this model.

1. Introduction

The area of software maintenance has not received adequate attention in the literature because it was considered as a fairly routine activity with no challenge for creative people. Today, when salaries of programmers have become a major part of the data processing budget, the difficulties in software maintenance are slowly becoming apparent. A large proportion of the software products in operation are the so-called ‘legacy systems’ [TrTi95, LLFG97, BMW96, BM97]. Such systems, that typically are the backbone of an organization’s information flow and business, represent a massive, long-term business investment. Unfortunately, such systems are often brittle, slow and inextensible. Capturing legacy system artifacts in a way that it can support organizations into the future is an important but relatively new research area. Maintenance of such systems involves modifying and using software products after delivery by the vendor or third parties in order to correct faults discovered during operation, to enhance performance or other attributes. This process also involves incorporating the changes requested by the user, and adapting the product to a changed environment [Schne96, Schne98, Schne87, SchEb98]. Maintenance is a hard problem because of the following reasons: a) The processes that created the product cannot be traced. b) Changes are not adequately documented. c) Changes produce ripple effects. d) There is a generally short sighted view that maintenance is strictly a post-delivery activity and programs have not been designed and developed with maintenance in mind. In cases where an existing software system has undergone extensive upgrades (lots of changes), maintenance becomes difficult and costly. Over time, legacy software can become technically obsolete and must be replaced. Software maintenance is the process of modifying existing operational software while leaving its primary functions intact. The definition includes the following types of activity within the category of software maintenance [Boe88]. 1. Redesign and re-development of smaller portions (less than 50% new code) of an existing software product. 2. Design and development of smaller interfacing software packages that require some redesign (of less than 20%) of the existing software product. 3. Modification of the software product’s code, documentation, or database structure. 4. Software maintenance [Pari88, PicC93, PaZve83, Mayr94] is classified into two main categories: a) Software Update, which results in a changed functional specification for the software product, b) Software Repair, which leaves the functional specification intact. In turn, software repair can be classified into three main sub-categories [LS80]: 1) Corrective maintenance (of processing, performance, or implementation failures), 2) Adaptive maintenance (to changes in the processing or data environment), 3) Perfective maintenance (for enhancing performance or maintainability).

2. Metrics and Models in Software Maintenance A number of models to depict the maintenance process, evolution of software products, metrics to depict the maintenance cost, effort and release of products in maintenance phase have been proposed [Pigo97, Aji95, BK97]. Boehm proposes the COCOMO model and extends it for software maintenance effort estimation. Visaggio [Visa94] proposes a metric for expressing the entropy of a software system and for expressing the entropy of a software system and for assessing the quality of its organization from the perspective of impact analysis. This metric called “structures information” is based on a model dependency descriptor and takes into account both the structure of the components at all levels of abstraction and the structure derived from the links between the different levels of abstraction [CDM, Proc89, EGK01, Soft]. Conventionally, maintainability has been regarded as a property or attribute of the software product rather than the process. [Snee95, YChan88, RUV92] The underlying assumption is that the difficulty in maintaining a system correlates with its complexity. [PooL92, Schne87, Nies97, Schne96] This has stimulated various metrics to assess complexity. Some address code-level complexity (example McCabe; Halstead) while others suggest design level metrics, such as module fan-in and fan-out. Wake and Henry [WH88] advocate that towering the complexity of systems and sub-systems would ultimately help in reducing the maintenance costs of the sub-systems. They developed a model that uses several software quality metrics as parameters to predict the maintenance activity. Yau et al [YNTL88] propose a systems approach to model the maintenance process and software. They also suggest empirical approaches to quantify maintainability. Schneidewind [Schne96] proposes a unified approach to consider the efficiency of the test effort that is a part of the maintenance process and a determinate of reliability and risk of deployment in analyzing the stability of the maintenance process. He defines long-term relationships and metrics that are computed over a sequence of releases: • Mean time to failure (MTTF), • Total failures normalized by KLOC change to the code, • Total Maintenance Test Time normalized by KLOC change to the code, • Remaining failures normalized by KLOC change to the code, • Time to next Failure, • Remaining Failures Risk metric, • Time to Next Failure Risk metric, • and short-term relationships and metrics are computed within a given release: • Total Maintenance Test Time vs. Number of Remaining Failures, • Failure Rate vs. Total Test time. Lehman and Belady [LehB87] considered program evolution dynamics. They classified programs into three classes, S, P, and E, and associate different lifecycle models for each class of programs. Niessink and Vliet [Nies97] predict maintenance effort with function points and conclude that size of the component to be changed has a larger impact than the size of the change itself. Gamalel-Din and Osterweil [Gama88] suggest a new lifecycle model that accounts for process maintenance, dynamic maintenance, process execution history and product-related maintenance. They also suggest empirical approaches to quantify maintainability. A model for measuring software modifiability was proposed by Yau and Chang [YChan88] where the modifiability of a module (or program) is interpreted as the ease of effort to make changes to the module (or program). Chapin [Chap88] was among the first to suggest a lifecycle for software maintenance that consists of the following steps: Understand existing system, define the objectives, analyze, specify, design, program, code and compile, debug and test, revalidate, train, and, convert and release. He concludes on the strong note that software development lifecycle (SDLC) should not be used for maintenance activities. A different lifecycle called software maintenance lifecycle (SMLC) that reflects the complex set of activities of the maintenance phase should be modeled and estimates of the effort, cost and time be made based on it. In this paper, a software maintenance lifecycle (SMLC) is proposed based on re-entrant lines that depict the complex set of activities associated with maintenance. Quantitative metrics such as release time of versions, cost, time and effort for maintenance are estimated. These values form the basis of a DSS that helps decide the next course of action for a legacy system management. 3. Legacy systems and SMLC models Legacy information systems (LIS) that comprise a majority of the software products in operation today evolve over a long period of time from research prototypes and earlier versions [BLW99]. Each successive release involves substantial additions or changes in functionality from previous releases. Some of the characteristics of legacy systems are as follows: a) Growth and non-homogeneity: These are products with functional growth over a long period of time consisting of components that are quite different functionally, with each component displaying different characteristics. b) Size: The product has a large number of modules, with each module containing functions, procedures, and a large amount of code that have been modified by different people in different releases. c) Compiler change: The compiler used for earlier versions is changed and code that was optimal for an earlier compiler could be sub-optimal or wrong for a later one. Attempts to better utilize compilers and to optimize code also introduce changes to various parts of the system. d) Platform change: The product evolves from initially running on a specified platform to a later platform (e.g. change from DOS to Windows). e) Developer change: The original developers are no longer available. The development processes used in different releases of such legacy products have also evolved over time. However, the processes share several common features and the overall generic process remains stable. The generic process includes the following major phases:” requirements, design, coding, and unit testing, regression testing, component, and system testing. All these product and process characteristics, changing and growing requirements and expectations of users have to be carefully analyzed and modeled for legacy systems. Several solutions have been proposed to address these problems. These solutions fall generally into three categories: a) Re-development, which rewrites existing applications; b) Wrapping, which provides a new interface to a component making it more easily accessible by other components; c) Migration, which moves the LIS to a more flexible environment, while retaining original system’s data and functionality. Given the scale, complexity, and risk of failure in LIS projects, a well defined, easily implemented, and detailed methodology is essential to the project’s success. Although partial solutions such as wrapping are widely adopted, such solutions are short-term and can actually complicate LIS maintenance management over the long-term. On the other hand, re-development approaches tend to be too risky for most organizations. Bisbal et al [BLW99] strongly advocate the migration methods as a solution for LIS. Brodie and Stonebraker [Brod95] propose the Chicken Little strategy, which lets LIS and target systems inter-operate during migration using a mediating module, known as a ‘gateway’. Butterfly methodology [Wu97] assumes that although the LIS must remain operable throughout migration, the LIS and target system need not inter-operate during the process. This assumption eliminates the need for gateways and their potential complexity. 4. Viewing Maintenance as a Reuse Oriented Development Basili [Bas90, LVis95] was the first to propose a high-level organizational paradigm to several maintenance tasks and then apply that paradigm to several maintenance process models. Maintenance is viewed as a reuse oriented software development, where the new version of the system is viewed as a new system that reuses many of the old system’s components. Four maintenance process models have been proposed. a) Quick-fix model, b) Iterative enhancement model, c) Full-reuse model, and d) Iterative reengineering model. All the four models reuse the old system and so are reuse-oriented. Which model is chosen for a particular modification is determined by a combination of management and technical decisions that depend on the characteristics of the modification, the future evolution of the product line, and the support environment available. 4.1 Quick-fix model

Old System New System

Requirements Requirements

Design Design

Code Code

Test Test

Figure 1: Quick-fix process model

The quick-fix model represents an abstraction of the typical approach to software maintenance. In this model the existing system’s source code is taken and the necessary changes are made to the code and the accompanying documentation is also updated. The code is then recompiled as a new version. This may be straightforward as a change to some internal component, like an error correction involving a single component or a structural change or even some functional component enhancement. Figure 1 demonstrates the flow of change from the old system’s source code to the new version’s source code. It is assumed -but not always true- that the accompanying documentation is also updated. This model can be viewed as reuse-oriented as the new system is created by reusing the old system or by modifying the old system. Viewing maintenance of systems as reuse-oriented development gives more freedom in the scope of change than viewing it in a modification or patch orientation.

4.2 Iterative-enhancement model Iterative-enhancement is an evolutionary model proposed for development in environments where the complete set of requirements for a system was not fully understood or where the developer did not know how to build the full system. Although iterative-enhancement was proposed as a development model, it is well suited to maintenance. It assumes a complete and consistent set of documents describing the system. The iterative-enhancement model • starts with the existing system’s requirements, design, code, test, and analysis documents; • modifies the set of documents, starting with the highest-level document affected by the changes down through the full set of documents; and • at each step of the evolutionary process, lets you redesign the system, based on analysis of the existing system.

Old System New System

Requirements Requirements

Design Design

Code Code

Test Test

Figure 2: Iterative-enhancement model This process assumes that the maintenance organization can analyze the existing product, characterize the proposed set of modifications, and redesign the current version where necessary for the new capabilities. Figure 2 demonstrates the flow of change from the highest-level document affected by the change through the lowest-level document. This model supports the reuse orientation more explicitly. An environment that supports the iterative-enhancement model also supports the quick-fix model. 4.3 Full-reuse model While iterative-enhancement starts with evaluating the existing system for redesign and modification, a full-reuse process model starts with the requirement analysis and design of the new system and reuses the appropriate requirements, design, and code from any earlier versions of the old system. It assumes a repository of documents and components defining earlier versions of the current system and similar systems. The full-reuse model • starts with the requirements for the new system, reusing as much of the old system as feasible, and • builds a new system using documents and components from the old system and from other systems available in the repository; and develop new documents and components where necessary. Here, reuse is explicit, packaging of existing components is necessary, and analysis is required to select the appropriate components. Figure 3 demonstrates the flow of various documents into the various document repositories (which are all part of the larger repository) and how those repositories are accessed for documents for the new development.

Old System Repository New System

Requirements (R) Requirements

Design (D) Design

Code (C) Code

Test (T) Test

Figure 3: Full Reuse model

4.4 Iterative re-engineering model Lanubile and Visaggio [LVis95] propose an iterative reengineering model in which the reengineering process and the quick-fix maintenance process work together as concurrent processes that share the existing system. The iteration rate of the reengineering process is not tied to the modification rate but to the effect of modifications to the system evolution. Each time the cost of changes becomes intolerable and the reliability decreases under an acceptable threshold, an iteration of the reengineering process starts.

Old System New System Reengineered System

Requirement Requirements Requirements

Design Design 3. Re-Design Design 2. Quality Control 1. Reverse Engg. 4. Forward Engg. Code Code Code

Test Test Test

Figure 4: Iterative reengineering model

Re-Engineering for Reuse (RE2) is another form of maintenance that uses a combination of the above strategies to redesign the LIS with the aim of generating reusable assets, whereby knowledge of the old system is not lost, and rebuild a new system that reuses the assets simultaneously. Model differences: The difference between the second and third approaches is more one of perspective than style. The full-reuse model allows one to design the new system’s solution from the set of solutions of similar systems. The iterative-enhancement model takes the last version of the current system and enhances it. Both approaches encourage redesign, but the full-reuse model offers a broader set of items for reuse and can lead to the development of more reusable components for future systems. By contrast the iterative-enhancement model encourages you to get the existing systems to get the extensions for the new system. 5. Modeling the Maintenance process using ULM The ULM is used for maintenance activities by re-defining the tasks at each station and changing the routing matrix appropriately for each of the maintenance lifecycle.

b b b 1 2 b3 4 Understand, Specify, Program Debug, Test, Analyze Design coding, revalidate, b existing Analysis Re-engineer, Convert system, 5 b b7 b system, Define 6 Integrate, 8 Release. Objectives (Service Regression (Service b (Service 10 Station b testing b Station b 11 12 9 Station - Team 2) (Service - Team 4) - Team 1) Station - Team 3)

p i Artifact for rework to b i No Accept buffer b i with p for Release probability i i, i = 1 ..12 Yes

Release

Figure 5: ULM modified to depict Maintenance phase of software lifecycle

The full-reuse model for maintenance is considered as a special case of Reengineering for reuse model with two lifecycles - one to denote the reverse engineering process and the other to denote the forward engineering process. Reusable assets are created as part of the reverse engineering lifecycle and these assets are used for development of the new system in the forward engineering process. Reverse Engineering Process

b b1 b 2 3 b 4 Understand, Specify, Program Debug, Test, Analyze Design coding, revalidate, existing b Analysis b Re-engineer, b Convert b5 6 7 8 system, Define Integrate, system, Objectives (Service Regression Release. (Service b Station b testing b (Service b 9 10 11 12 Station - Team 2) (Service Station - Team 1) Station - Team 4) - Team 3)

pi Artifact for rework to b No Accept i buffer b with i for Release probability p b i i i, i = 1 ..12 b i = Yes

Release

Develop Reusable Assets

Repository of Reusable Assets

Develop with Reusable Assets

Forward Engineering Process

R R R R b b b 1 2 b3 4 Requirements Design Integration Independent

R Analysis Analysis and Verification & R R R b Coding & System Validation 5 b b7 b 6 Unit Testing Testing 8 Quality Control (Service R R R R b (Service 10 (Service b (Service b12 Station b 9 11 Station Station Station - Team 4) - Team 1) - Team 2) - Team 3)

p i Artifact for rework to b i No buffer b i with Accept p probability i R i, i = 1 ..12 Reusable artifacts Yes

Release

Figure 6: ULM representing the Re-engineer for Reuse strategy of maintenance

6. A Case Study CASSA has developed three products that can be classified as LIS. Three products Mission Communication system (MC), multi-mission planning system (MP) and war-game software (WG) [VRN99], that are continuously upgraded and maintained are studied as a case study. The three products undergoing maintenance are studied as projects MC1, MP1 and WG0.These projects are characterized as follows: Project MC1: This is a mission communication system that is used for transferring data between different computers in a secure manner. The system uses ASIC hardware and modems with communication software and drivers to implement the secure communication between computers. The requirements for this project changed over 70% of the original requirements. The users requested for a change of algorithms, platform from DOS to Windows NT with client-server architecture. Project MP1: The multi-mission planning system was developed with a fixed set of requirements to enable the pilot plan the missions on ground. The product was completed and after user trials, handed over to the users for use. As there no additional requirements for the product, the only maintenance that was required was corrective / perfective maintenance for the product. Also, there was no further development of the product-line by the organization. Project WG0: The third category of products that are developed and maintained are the war game simulation packages for the defence services. These applications satisfy all the necessary conditions for being classified as LIS. Every game played on these packages comes with new requirements and evolution of the software. For each of these projects (MC1, MP1 and WG0), it would now be very helpful to obtain quantitative metrics such as cost and effort required to follow the decision strategy, and from these estimate the release time of the new version of the software. Table 1: Three products undertaken for maintenance activities Product/ Number of Number of modules Requirements to Project change MC1 156 113 (>60%) MP1 188 102 (30-60%) WG0 122 34 (<30%)

Table 2: ULM estimates for maintenance time and cost for the three products undergoing maintenance New New Re-Engineer Re-Engineer Maintenance Maintenance development development for Reuse for Reuse Project Dev. Time Dev. Cost Dev. Time Dev. Cost Dev. Time Dev. Cost MC1 94 1296 63 844 119 1631 MP1 68 986 102 1121 86 1466 WG0 94 2894 121 3122 82 2984

Based on the number of personnel and the effort predicted for the maintenance activities, the release time of the new version is estimated. 7. Decision analysis Decision analysis is the formal study of how people ought to make rational decisions, particularly when faced with uncertain information, as well as a collection of techniques to support the analysis of decision problems. Making good decisions involves defining alternatives, assessing the possible impacts of each alternative, determining the preferences or values by which the decision will be based, and evaluating the alternatives. Structuring decision problems involves defining alternative decisions that can be made, uncertain outcomes that may result, and criteria by which to evaluate the value of the various combinations of decisions and outcomes [Rob79, WaHi72]. A decision tree is a graphical representation of a decision problem (Figure 7). A decision tree consists of the following:

• Decision nodes, represented by squares. These represent points at which decisions must be made. • Decision branches, which stem from decision nodes. Each branch corresponds to a decision alternative. • Event nodes, represented by circles. These represent points at which uncertain outcomes will occur. • Event branches, which stem from event nodes. Each branch corresponds to an event. • Terminal nodes, which represent the result (payoff) of a combination of decisions and events.

Quick Fix Maint Iterative Enhancement Full - Reuse Yes Develop Product Quick Fix Maint Line No Iterative Enhancement Quick Fix < 30% Iterative Enhancement Maint Full - Reuse

New Re-Develop No.of Requirements Yes Wrapping to add / change 31 - 60% Develop Product Migration 2 Line RE No Quick Fix Iterative Enhancement Full - Reuse

Quick Fix Iterative Enhancement > 61% Maint Full - Reuse New Re-Develop Wrapping Yes Migration Develop Product RE2 Line Quick Fix No Iterative Enhancement Maint Full - Reuse

New Re-Develop Wrapping Migration RE2 Figure 7: Decision tree for the Maintenance process Decision trees that contain a single set of decision nodes followed by a set of events nodes are called single stage decision trees; those that contain sequences of decision and event nodes are called multistage decision trees. When an individual, or organization faces the same decision problem repeatedly, then over the long run, the decision can be made based on expected value. The expected value approach is to select the decision alternative with the best-expected payoff. Let

P(S j ) be the probability that event S j occurs. V (Di , S j ) is the payoff for Di under S j , and n is the number of events. The expected value approach is to calculate the expected payoff for each decision alternative Di as

n E(Di ) = ∑ P(S j )V (Di , S j ) . j=1 The decision alternative with the highest expected payoff is selected as the optimal decision. Organizations that develop and maintain software are often faced with important decisions on migrating LIS to new platforms; maintain old code or develop afresh; or reengineer the old system to build a new system while creating and using reusable assets and components in the process. These complex decisions are represented as a decision tree. We consider the three projects MC1, MP1 and WG0 that were executed and completed and the decision tree to decide upon the course of maintenance action for each of these projects. These decision trees are presented in Figures 8- 10. The decision chosen as the outcome of the decision tree (from the various set of alternatives) for the three projects is summarized as: Project MC1: Develop new. Project MP1: Maintenance (Iterative Enhancement). Project WG0: Re-engineer for reuse. In real life decision problems, estimation of the subjective probabilities corresponds to the arcs of the decision tree and the choice of utilities involves considerable effort and trial and error procedures. 8. Conclusions Maintenance of software products is important and is emerging as a new field of research. The lifecycle of maintenance is radically different from the lifecycle of development, as the nuances involved in maintenance activities are far more complex than the development. So far, no lifecycle models associated with maintenance of products that provide quantitative estimates of maintenance metrics are studied. In this chapter, we use the ULM to depict the tasks associated with maintenance of Legacy Information Systems. Quantitative estimates are obtained for three maintenance projects using the ULM. These are useful in calculating the release time of the new version and the maintenance cost of the product. Then, the maintenance strategies for three different projects are analyzed. The connection between Maintenance phase and CBSE is established. This helps in viewing maintenance as a reuse activity with generation of reusable components while maintaining the LIS. This is an important method in overcoming the software crisis. A decision support system based on decision trees is presented to determine the next course of action for the maintenance of projects.

References [TrTi95] Troster, J., Tian, J., Measurement and defect modeling for a legacy software system, Annals of Software Engineering, Vol. 1, 1995, pp. 95-118. [LLFG97] De Lucia, A, Di Lucca, G. A., Fasolino, A. R. , Guerra, P., Petruzzelli, S., Migrating legacy systems towards Object-Oriented platforms, CSM, 1997, pp. 122-129. [BMW96] Burd, E., Munro, M., Wezeman, C., Extracting reusable modules from legacy code: considering the issues of module granularity, International Workshop on Reverse Engineering, Monterey, California, 1996. [BM97] Burd, E., Munro, M., Enriching program comprehension for software reuse, International Workshop on Program Comprehension, Dearborn, Michigan, USA, 1997. [Schne96] Schneidewind, N. F., Measuring and evaluating maintenance process using reliability, risk, and test metrics, Proceedings of Conference on Software Maintenance, Arizona, October 1996, Computer Society Press of the IEEE, Washington, DC, pp. 232-239. [Schne98] Schneidewind, N. F., How to evaluate legacy system maintenance, IEEE Software, July/August 1998, pp. 34-41. [Schne87] Schneidewind, N. F., The state of software maintenance, IEEE Trans. on Software Engineering, Vol. SE-13, No. 3, March 1987, pp. 303-309. [SchEb98] Schneidewind, N., Ebert, C., Preserve or redesign legacy systems? IEEE Software, July/August, 1998, pp. 14-21. [Boe88] Boehm, B., 1988, A spiral model for software development and enhancement, IEEE Computer, 21, 5, pp. 61-72. [Pari88] Parikh, G., Techniques of Program and System Maintenance (2e), Wellesley, Massachusetts: QED Information Sciences, 1988. [PicC93] Pickard, M. M., Carter, B. D., Maintainability: What is it and How do we measure it? ACM SIGSOFT Software Engineering Notes, Vol. 18, No. 3, July 1993. [PaZve83] Parikh, G., Zvegintzov (Eds.), Tutorial on Software Maintenance, IEEE Computer Society Press, Silver Spring, Maryland, 1983. [LS80] Leintz, B. P., Swanson, E. B., Software Maintenance Management, Reading, Massachusetts: Addison-Wesley, 1980. [Pigo97] Pigoski, T. M., Practical Software Maintenance: Best practices for managing your software investment, New York: John Wiley and Sons, 1997. [Proc89] Theme issue on Software Maintenance, Proceedings of the IEEE, Vol. 77, No. 4, April 1989. [Ybai90] Yun, W. Y., Bai, D. S., Optimal software release policy with random lifecycle, IEEE Trans Reliability, Vol. 39, No. 2, June 1990, pp. 167-170. [Aji95] Ajila, S., Software Maintenance: An approach to impact analysis of object change, Software-Practice and Experience, Vol. 25, No. 10, October 1995, pp. 1155-1181. [BK97] Burch, E., Kung, H-J., Modeling Software Maintenance Requests: A case study, Proceedings of the International Conference on Software Maintenance, 1997, pp. 40-47. [Visa94] Visaggio, G., Process improvement through data reuse, IEEE Software, July 1994, pp. 76-85. [CDM] Cimitile, A., De Lucia, A., Munro, M., An overview of structural and specification driven candidature criteria for reuse reengineering processes, Centre for Software Maintenance, University of Durham, Durham, UK. [EGK01] Eick, S. G., Graves, T. L., Karr, A. F., Marron, J. S., Mockus, A., Does code decay? Assessing the evidence from change management data, IEEE Trans. on Software Engineering, Vol. 27, No. 1, January 2001, pp. 1-12. [Soft] IEEE Software, Special issue on Software Maintenance, May 1986, January, 1990.

[Snee95] Sneed, H. M., Estimating the costs of software maintenance tasks, Proceedings of the International Conference on Software Maintenance, 1995, IEEE Computer Society Press, Los Alamitos, California, pp. 168-181. [VSS00] Vijay Rao D., Sarma, VVS, Srinivasan NK, ‘A systems engineering approach to software lifecycle modeling’, Proceedings of the 24th National Systems Conference, 7-9 Dec. 2000, Bangalore, pp.452-461. [YChan88] Yau, S. S., Chang, P-S., A metric for modifiability for software maintenance, Proceedings of Conference on Software Maintenance, Arizona, October 1988, Computer Scoiety Press of the IEEE, Washington, DC, pp. 374-381. [RUV92] Rombach, H. D., Ulery, B. T., Valett, J. D., Toward full life cycle control: Adding maintenance, measurement to the SEL, Journal of Systems Software, Vol. 18, 1992, pp.125-138. [PooL92] Poo, D. C. C., Layzell, P. J., An evolutionary structural model for software maintenance, Journal of Systems Software, Vol. 18, 1992, pp. 113-123. [Nies97] Niessink, F., Van Vliet, H., Predicting maintenance effort with function points, Proceedings of the International Conference on Software Maintenance, 1997, IEEE Computer Society Press, Los Alamitos, California, pp. 32-39. [WH88] Wake, S., Henry, S., A model based on software quality factors which predicts maintainability, Proceedings of Conference on Software Maintenance, Arizona, October 1988, Computer Society Press of the IEEE, Washington, DC, pp. 382-387. [Schne96] Schneidewind, N. F., Measuring and evaluating maintenance process using reliability, risk, and test metrics, Proceedings of Conference on Software Maintenance, Arizona, October 1996, Computer Society Press of the IEEE, Washington, DC, pp. 232-239. [LehB87] Lehman, M. M., Belady, L. A., Program evolution - Processes of software change, London: Academic Press, 1985. [Gama88] Gamalel-Din, S. A., Osterweil, L. J., New perspectives on software maintenance, Proceedings of Conference on Software Maintenance, Arizona, October 1988, Computer Society Press of the IEEE, Washington, DC, pp. 14-22. [Chap88] Chapin, N., Software maintenance lifecycle, Proceedings of the IEEE-CS Conference on Software Maintenance, 1988, pp. 6-13. [BLW99] Bisbal, J., Lawless, D., Wu, B., Grimson, J., Legacy Information Systems: Issues and Directions, IEEE Software, September/October 1999, pp. 103-111. [Bas90] Basili, V.R., Viewing maintenance as reuse-oriented software development, IEEE Software, January 1990, pp. 19-25. [LVis95] Lanubile, F., Visaggio, G., Iterative reengineering to compensate for Quick-fix maintenance. Proc. International Conference on Software Maintenance, Opio, France, IEEE Computer Society Press, Los Alamitos, California, 1995, pp. 140-146. [VRNKS99] Vijay Rao, D., Srinivasan, N. K., Defect analysis during software maintenance and enhancement phase - A case study, in Proceedings of the National Seminar on Reliability Analyses and Engineering (NSRAE), VSSC Trivandrum, 1999. [Rob79] Roberts, F.S., Measurement Theory with applications to Decision making, Utility, and the social sciences, Reading, Massachusetts: Addison-Wesley, 1979. [WaHi72] Warfield, J. N., Hill, J. D., A Unified Systems Engineering Concept, A Battelle monograph, No. 1, June 1972. [VSS00] Vijay Rao D., Sarma, VVS, Srinivasan NK, ‘A systems engineering approach to software lifecycle modeling’, Proceedings of the 24th National Systems Conference, 7-9 Dec. 2000, Bangalore, pp.452-461. [VR95] Vijay Rao, D., Estimation of software release times based on a queueing model for software testing. MSc(Engg.) thesis, Department of Computer Science and Automation, Indian Institute of Science, Bangalore, India, 1995. [VRNKS01] Vijay Rao, D., Srinivasan, N.K., Sarma, V.V.S., A systems engineering approach to software development process modeling, Proceedings of the 25th National Systems Conference, 13-15 Dec. 2001, Coimbatore, pp.290-278. [VRNKS02] Vijay Rao, D., Srinivasan, N.K., Sarma, V.V.S., A systems engineering approach to software development process modeling, Paritantra, Vol. 7, No.1, Aug. 2002, pp. 22-31, 2002. [VR01] Vijay Rao, D., A unified approach to quantitative software lifecycle modeling. Ph D thesis, Department of Computer Science and Automation, Indian Institute of Science, Bangalore, India, September 2001. Quick Fix a 11 E 1

a 12 Iterative Enhancement E 2 a 1 a 13 Full - Reuse E Maint 32 Re-Develop E a 21 4 New a 2 a 22 Wrapping E No.of Requirements a 5 to add / change > 61% Yes 2 a Develop Product RE 23 a Migration E Line 3 6 No E 7 Quick Fix E 8 b11

b Iterative b 12 Enhancement E 9 Maint b 13 Full - Reuse E 10 b1 b 21 Re-Develop E 11 b2 New b E 22 Wrapping 12 b 23 b 3 Migration E13 RE 2 E 14

Decision Outcome Utility (PEM) Expected Value E i

Quick Fix (0.3) 30 E 1 = 0.9

Maintain (0.1) Iterative Enhancement (0.4) 50 E 2 = 2.0

Full Reuse (0.3) 70 E 3 = 2.1

Redevelop (0.4) 70 E 4 = 22.4 Develop Product Line New (0.8) Wrapping (0.3) 80 E5 = 19.2 Migration (0.3) 80 E6 = 19.2 RE 2 (0.1) 60 E 7 = 6.0

Quick Fix (0.3) 30 E 8 = 0.9 Maintain (0.1) Iterative Enhancement (0.4) 50 E 9 = 2.0 Full Reuse (0.3) 70 E 10 = 2.1

Redevelop (0.4) 80 E 11 = 25.6 One Time Development New (0.8) Wrapping (0.3) 90 E12 = 21.6 Migration (0.3) 90 E13 = 21.6 RE 2 (0.1) 40 E 14 = 4.0 Project MC1 Decision : One Time Development, Redevelop New

Figure 8: Decision tree for Maintenance of Project MC1

Quick Fix E a 1 11 a 12 Iterative E Maint Enhancement 2 a 13 a1 Full - Reuse E 32

Re-Develop E a 4 21 a a 2 New 22 E Wrapping 5 a a 3 a No.of Requirements Yes 23 to add / change 31 - 60% Develop Product Migration E6 Line 2 No RE b

E 7 Quick Fix E 8 b1

b2 Iterative E Enhancement 9

b3 Full - Reuse E 10

Outcome Utility (PEM) Expected Value E Decision i

Quick Fix (0.1) 30 E 1 = 2.4

Maintain (0.8) Iterative Enhancement (0.8) 90 E 2 =57.6

Full Reuse (0.1) 40 E 3 = 3.2.

Redevelop (0.4) 30 E 4 = 1.2 Develop Product Line New (0.1) Wrapping (0.3) 40 E5 = 1.2 Migration (0.3) 30 E6 = 0.9

2 RE (0.1) 60 E 7 = 6.0

Quick Fix (0.1) 60 E 8 = 6.0

One Time Development Iterative Enhancement (0.8) 80 E 9 = 64.0

Full Reuse (0.1) 20 E 10 = 2.0

Project MP1 Decision : One Time Development, Iterative Enhancement Maintenance

Figure 9: Decision tree maintenance of Project MP1 E Quick Fix 1

a1

Iterative Maint a2 E Enhancement 2

a a 3 Full - Reuse E 32

No.of Requirements Yes to add / change Develop Product < 30% Line No

b b Quick Fix E 1 4 Maint

b2 Iterative E 5 Enhancement

Decision Outcome Utility (PEM) Expected Value E i Quick Fix (0.1) 25 E 1 = 2.5

Develop Product Line Iterative Enhancement (0.1) 40 E 2 = 4.0

Full Reuse (0.8) 90 E 3 = 72.0

Quick Fix (0.3) 40 E 4 = 12.0

One Time Development

Iterative Enhancement (0.7) 60 E 5 = 42.0

Project WG0 Decision : Develop Product Line, Full Reuse Strategy for Maintenance

Figure 10: Decision tree for Project WG0