Towards a Maintenance Process that Reduces Software Quality Degradation Thanks to Full Reuse
Abstract
The degradation of quality in software systems, due to maintenance interventions, is one of the primary reasons for its premature aging or its retirement before obtaining a return on investments. Nevertheless, quality degradation is considered an inevitable consequence of maintenance. On the other hand, this work takes into account a maintenance process, based on the full reuse model, which seems to have important features for controlling software degradation, alleviating some of the common problems related to maintenance. Unfortunately, at the moment, there is no evidence on experimentation of the model. In this optic, our work proposes an experimentation, guided by quantitative metrics, which is being carried out in an industrial setting. Thanks to empirical validation, either the model, its instrumentation and metrics can be transferred to other organizations wanting to adopt them.
Introduction
It is commonly acknowledged in the software engineering community that software maintenance implies software degradation [6,7,9]. Although a software system is new and well engineered, software maintenance tends to cause its quality to degrade and the system to age [6, 7]. As a consequence, maintenance becomes more costly and less accurate and the system reduces its economical value. An interesting approach to software maintenance, introduced in the early 90’s within the software community, is the “full reuse model” [5]. It seems to enclose many advantages although there are no reported experiences in literature related to its experimentation in industrial setting. In our opinion, properly applying the “full reuse model” in software maintenance not only doesn’t lead to degradation but increases quality and reduces maintenance costs.
According to Basili [5], “For effective reuse, you need to be able to incorporate the reuse process model in the context of development. You need to combine the development and maintenance models to maximize the context dimensions. You need to integrate characterization, evaluation, prediction, and motivation into the process”.
Following these guidelines, we defined a development process for developing reusable software components and storing them in a repository, a full reuse maintenance process which uses the components of the repository for carrying out the maintenance activities, a tool that supports both processes and manages the repository. We also designed a measurement plan using the GQM-QIP approach [12, 13] in order to characterize and evaluate the full reuse model.
For space reasons and the purpose of this work, only the maintenance process will be taken into account. The aims of this work are to provide evidence on how full reuse maintenance avoids system degradation alleviating the problems related to it. The novelties of our work are to:
– experiment the full reuse model within an industrial setting by carrying out an experimentation in a Small to Medium Enterprise (SME) with the aim of verifying if this approach is useful for controlling software degradation during its maintenance and/or improving its quality
– use a GQM approach to operatively characterize the experiment results;
– use the QIP paradigm in an experiment based on historical series for controlling and avoiding threats.
At the moment, the experiment is being executed. Therefore this paper proposes and presents our research goal and how we intend achieving it.
The remaining part of this work is organized as follows: in Related Works what is intended for software reuse and how it has been conceived in literature are presented; Terminology and Basic Concepts list the terms familiar to the application domain and used throughout the paper; Full Reuse Maintenance illustrates what is intended by full reuse and how it is applied to a maintenance process; RAPID Tool describes the tool that guarantees automated support for effectively applying full reuse; Experimentation shows how we have planned to carry out the experimentation in industrial setting within a SME; finally conclusions are drawn.
Related Works
In the past years the scientific and industrial community have focused their attention on technologies and techniques able to drastically reduce software production and maintenance costs and improve productivity and quality. This continuous evolution has led paradigms such as Product Lines [10] and Aspect Oriented Programming [11] passing through Object Oriented programming. A constant factor that is present in this process is considering the “reuse” concept as a strength and using it as a guideline for structuring a software system:
– the core idea in Product Line engineering “is to synchronize and organize the development of multiple products around a single reuse infrastructure”, “…to develop common or similar functionality explicitly for reuse in multiple systems and thus to distribute cost and effort”.
– Object Oriented and Aspect Oriented Programming consider reuse important although they can be seen as orthogonal to one another: while the tendency in OOP is to find commonality among classes and push it up in a reuse oriented inheritance tree (vertical direction), AOP attempts to realize scattered concerns as first reusable class elements and eject them horizontally from the object structure.
For software reuse we intend the use of entire or partial products from an existing system to produce new software or modify existing ones. It can be distinguished in ad hoc or informal and systematic [1, 4].
The former happens fortuitously and is based on the individual programmer’s initiatives; it is commonly and informally referred to as “cut and paste”, although we don’t agree on the fact that this can be considered as a form of reuse. We focus our attention on full reuse as a type of systematic reuse, which is more formal in that it requires planning and a specific approach for adopting it, as a consequence it involves investment and risk.
Adopting systematic reuse, in both a development and maintenance process seems to enclose many advantages due to the fact that new software doesn’t necessarily have to be written. In fact, as pointed out in [4], reusing existing software components (or modules) may imply:
– cycle time reduction because less work must be done to produce the various components;
– quality improvement because the reused components are already tested when they are selected for reuse and then they are re-tested if they are subject to further modifications;
– productivity improvement because less effort is needed to produce the same final product.
Unfortunately all these considerations are reasonable but poorly proven, and as stated by Poulin [15] “These papers often present casual opinions, invalidated processes, or lack any scientific or engineering basis”. In spite of the constant need for developing high quality software and avoiding system decay as a consequence to maintenance intervention and the importance of adopting reuse concepts within a product line, there are few works on the consequences and benefits of applying systematic reuse to software development and maintenance, for example [2, 3, 4]. Furthermore there aren’t works that show advantages of full reuse, using experimentation.
Terminology and Basic Concepts
Before going on, it is useful to point out the terminology and the basic concepts used in the rest of the paper. They are terms familiar to the application domain and used to characterize both the development and maintenance processes and the tool used to make full reuse possible within the SME.
In the context of this work, a software system can be seen as a set of transactions. A transaction carries out a specific function by realizing the interaction between the user and machine. It is made up of four parts: the preliminary activities necessary to launch the dialogue forms; form reception and control of the data introduced; data base update; on-line printing that displays the information requested on video. Transactions are classified in families, each carrying out a specific function. A transaction family is defined by means of a schema. A schema identifies all the steps that must be executed in order to carry out the transaction and specifies how they are distributed across the four parts. A step contains lines of code, and may also include calls to elementary functions (such as for calculating the date) known as routines, or to data base access functions called crud. The steps are defined by means of templates that define the structure and automatically generate part of the code related to that step according to the specifications provided by the developer. All the templates are stored in the repository. Each template has a fixed part which is independent from the application and a part that must be specialized to the application it is included in and must be defined by the developer.
This means that the effort required is limited to specializing the step to the specific context, in other words few lines of code must be written. Finally, an element of primary importance that is crucial for adopting reuse is the repository. The repository is a reuse library in which all the reusable software components, also called modules, are stored. The modules can be routines or crud called within the steps, schemas used for defining the transactions, or templates.
The Full Reuse Maintenance
In [5] three different types of reuse models are proposed. The main concepts common to each reuse model can be summarized as follows: first the software components in the repository must be identified, then they must be examined to see if they are appropriate for the specific needs of the context in which they are to be applied, finally they are integrated into the new system. Among the various reuse models, we have focused our attention on full reuse.
The model refers to both development and maintenance processes. For what concerns development, reuse of existing components that are stored in a repository is emphasized. In particular, given the system requirements, the developer identifies the transactions and, consequently, the schemas that implement the functions specified. Each step of the schema is defined according to a specific template which the developer specializes by providing the name of the step and calls to routines, for elementary functions, or crud, for access to data base. If the routines or crud are already included in the repository they can be reused, otherwise they must be created by using appropriate templates. The first are partially automatically generated, while crud are entirely generated. In this context, reuse of a component in the repository not only implies reusing its code but also all the documentation and test cases related to it. In this way reusable components are continuously generated and contribute to populating the repository.
For what concerns maintenance, the full reuse model can be summarized in the following steps:
– a request for maintenance of a software system in use is received;
– after a primary impact analysis, the maintainer identifies the transactions and the list of modules (templates, routines, or crud) that are impacted and require maintenance (primary impact analysis);
– for each module, the latest updated version is retrieved from the repository. If it matches and fulfills the maintenance request, in that it corrects the defect, then the old version of the module containing the defect is substituted with the updated one (modification design). “No match” in the repository means that the module being examined has never been modified in previous moments with refer to the specific maintenance request.
In this case, the module is modified “by hand” (modification execution). More precisely, the modification refers to the templates used to define the module itself, therefore the list of templates are retrieved from the repository and subject to maintenance in order to correct the defects. Once completed, the updated module is stored in the repository. In this way the repository contains the latest versions of all the modules that make up the software system.
– note that, module reuse implies reusing documentation, code and test cases. Therefore before a module is updated and stored in the repository, it is adequately tested (regression test planning, test execution, defects elimination).
– once all the modules impacted by the maintenance request have been modified, each remaining module of the software system is updated with its last version in the repository. In this way the system benefits from maintenance interventions carried out in previous moments on other modules that are not directly involved in the current maintenance request.
These are the main concepts that characterize the maintenance process (RApid software Maintenance prOcess) applied in the SME considered in the experimentation. A graphical representation is given in figure1.
Figure1: RAMO: Rapid software Maintenance prOcess
For sake of clarity we provide an example of how full reuse maintenance is applied. Let S1 and S2 be two different software systems that exploit reusable modules (Figure2). This implies that they have some modules in common, in that they require the same functions, and other distinct modules according to the specific functions that are implemented in each application domain. Suppose that a maintenance request is made for system S2. The impact analysis points out the need to modify modules M3, M31, and M41 of S2. Once maintenance is completed, the updated versions of these modules are stored in the repository together with their documentation and new test cases. After some time, suppose that a maintenance request is made from S1. It involves modifying M1. Since an updated version is not present in the repository, the module is modified “by hand” and stored. Also, since the repository contains updated versions of modules M3 and M31 (as a consequence to the maintenance request previously made for S2), these are substituted to the old versions. In this way, although an explicit request was not made for M3 and M31, they are updated anyway at “zero costs”.
Figure2: Systems adopting full reuse maintenance
RAPID Tool
Automated support is important for effective full reuse. In the experimentation we are conducting, a tool called RAPID (Rapid aPplication maIntenance and Development) is used. It is the core part for both the development and maintenance processes. In summary, the tool allows to carry out the following functions:
– create transactions by applying the schema which defines all the required steps related to the specific transaction;
– automatic generation of modules (crud), from a template, that access the database;
– partial generation of routines and steps, from a template, necessary for carrying out elementary functions in the first case and for defining a transaction in the other;
– compilation of all the modules developed;
– repository management.
The RAPID tool manages the repository throughout three main functions:
– RETRIEVE, which searches the repository for reusable modules as a consequence to a request made by the developer. If the repository contains a module that exactly matches the request, the tool inserts a call to that module in the step, otherwise the tool provides the routine that partially matches the request. In this case it must be customized by the author to the specific context it is to be used in. Finally if no module matches the request the tool provides a template that the developer must complete in order to generate the module;
– MAINTENANCE, which updates the repository. Each time a module is completed, this function extracts its essential characteristics (description, input to the module, output produced) and stores it in the repository;
– FULL REUSE. Each time a module is identified in the repository to be reused, this function extracts all the information associated to it such as code, test cases and documentation. Also, with refer to maintenance, the function updates the system being maintained with the latest versions of all the components. This is possible because the modules stored in the repository are characterized by a module name, description, input to the module, output produced and finally the last update date.
Experimentation
In order to evaluate the benefits (system quality improvement, cost and effort reduction, increase of productivity) that we assume full reuse has on software maintenance, we have planned to carry out a case study that evaluates the RAMO and compares it to a classic maintenance process. To perform such a study we selected two projects, that according to [14] will be referred as sister projects. They are typical of the organization: banking application written using COBOL, CICS and DB2. The experimental subjects are programmers of the SME and have the same experience and skills. They were randomly grouped and assigned to the projects selected. The programmer assigned to the project involving RAPID processes were previously trained and skilled for using both the tool and the rapid maintenance process.
The experimental design is based on historical series.
Project A: conventional maintenance Oa1,Oa2,Oa3 Oa4,Oa5,Oa6 Oa7 Oa8,Oa9
Project B: rapid maintenance Ob1,Ob2,Ob3 I Ob4,Ob5,Ob6 I Ob7,Ob8,Ob9
In order to characterize the full reuse maintenance process (RAMO) we have defined a measurement plan according to the GQM approach. It is made up of two goals, one characterizes and evaluates a classic maintenance process and the other refers to RAMO; thirteen questions and forty-eight metrics.
M31
M1 M4 M3
S2
M31
M1 M2 M3
S1
M41 M42
Each Oxy in the experimental design, where x={projectA (a); projectB (b)} and y={i-th month of observation | i=1…9}, corresponds to an observation of the project evolution after one month of work. For each Oxy, the measurements included in the GQM plan will be collected.
Every 3 months of work a set of improvement actions I will be executed in the project involving the RAPID processes. The improvement actions I will be suggested by the interpretation of the measurements included in the GQM plan. This is necessary in order to control the maturity effect that affect the programmer (confidence in using the tool, ability in execute the rapid processes etc.) and control threats to the experiment.
At the present the experiment is running and we are collecting the measurements. The repository at the moment contains about 100 transaction for a total of about 600 reusable modules.
In order to understand how the GQM-QIP approach have been integrated and applied within the experimental design, we provide a brief explanation. In particular, the two goals used to characterize and compare a classic maintenance process with one using full reuse are:
Goal1: evaluate the classic maintenance process In order to characterize it
With refer to efficiency and efficacy
From the point of view of the developer In the context of conventional maintenance
Goal 2: evaluate the rapid maintenance process
In order to improve it
With refer to efficiency and efficacy
From the point of view of the developer
In the context of rapid maintenance
Goal1 characterizes the classic maintenance process (primary quality model)using nine questions, each of which are refined in metrics. On the other hand, Goal2 is distinguished in two sections, the first (primary quality model) characterizes the rapid maintenance process and includes nine questions and a set of metrics, the same as for Goal1, considered in a rapid development context, the second section (confirming quality model) compares the metrics collected in both goals in order to point out the benefits of using a rapid maintenance process rather than a classic one, and which are the possible improvement actions to adopt in case of weaknesses identified in the process. For clearness we illustrate how this is done by considering a question and describing the metrics related to it, and finally by showing how these are compared within the confirming quality model:
Questionclassic maintenance : what is the productivity of the classic maintenance process?
Metricclassic maintenance : ES’: Effort spent to maintain a module by using a classic maintenance process.
Questionrapid maintenance : what is the productivity of the rapid maintenance process?
Metricrapid maintenance: ES’’: Effort spent to maintain a module by using a rapid maintenance process.
As it can be seen, the questions and metrics are the same but applied to a different context. Once the metrics have been collected, they are used for answering the following question and measuring its metrics defined in the confirming quality model of Goal2:
Questionconfirming quality model: what is the improvement, in terms of productivity, obtained by using the rapid maintenance process?
Metricconfirming quality model: S = ES’’- ES’: Effort saved in maintaining a module by using the rapid maintenance process compared to a classic maintenance process
For what concerns interpretation, it provides guidelines for answering the questions of the measurement plan, in order to conclude if the goal is fulfilled or not. Interpretation of a metric depends on its values and can be defined according to existing baselines within the organization collecting the measures, values collected during subprojects of the project, similar experiences made in other contexts and used as reference.
With refer to the above metrics, the interpretation is done by comparing the values of the metrics collected in each observation (Oxy) with those collected during the previous observation (Oxy-1). This comparison points out if there has been an improvement or not in the metrics values and, according to the case, which are the strengths or weaknesses that are associated. The interpretation for the metric of the confirming quality model listed above can be summarized as follows:
If the value of S (Metricconfirming quality model) fulfills expected baseline, then we can conclude that the rapid maintenance process improves software productivity. Otherwise the weakness depends on factors such as developer’s knowledge of the rapid maintenance process. Since this may represent a possible threat for the execution of the experiment, an appropriate improvement action (I) is to carry out training on job related to the rapid maintenance process through walkthrough inspections.
In an analogous way, all the questions, and therefore metrics allow to measure, monitor and avoid threats throughout the experiment.
Conclusions
In this work we have described how we intend to experiment a full reuse maintenance process in an industrial setting. This contributes to filling a gap that, to the authors’ knowledge, has been left in the research of the concepts related to full reuse. In particular, it would be interesting to overcome such a gap if the model results, as we expect, able to reduce software system degradation and eventually improve its quality.
Finally, with refer to our case, the measures necessary for controlling the costs and benefits such as the ones mentioned in [1,16] have been defined, are being experimented and will be improved through the experiment presented in this work.. We have defined the resources implied for conducting the experimentation and for evaluating the results.
The instrumentation (RAPID tool) for supporting the execution of the maintenance process has been realized. At the moment the software systems involved in the projects of the experimentation are being developed by using a rapid development process which allows to populate the repository with software components that will be reused during maintenance. Unfortunately, at the moment the experimentation is being executed, therefore we still don’t have experimental data. We assume that by the date of the workshop the first experimental results will be available.
References
[1] W.B. Frakes, S. Isoda, “Success Factors of Systematic Reuse”, IEEE Software, vol11, no5, Sept. 1994, pp. 14-19.
[2] W.C. Lim, “Effects of Reuse on Quality, Productivity and Economics”, IEEE Software , vol11, no5, Sept. 1994, pp.23-30.
[3] R.Joos, “Software Reuse at Motorola”, IEEE Software, vol.11, no.5, Sept. 1994, pp. 42-47.
[4] M. Morisio, C. Tully, M. Ezran, “Diversity in Reuse Processes”, IEEE Software, July-August 2000, pp.56-63
[5] V.R. Basili, “Viewing Maintenance as Reuse-Oriented Software Development”, IEEE Software, January 1990, pp.19-25
[6] M.M. Lehman, “Laws of Program Evolution-rules and tools for programming management”, Proceedings of the Infotech Stat of the Art Conference, Aril 1978, Pergamon Press, 1978, 11/1-11/25.
[7] G. Visaggio, “Assessing the maintenance process through replicated, controlled experiments”, the Journal of System and Software, 1999, 44: 187-197.
[8] M.M. Lehman, J.Ramil, P.Wemnick, D. Perry, W. Turski, “Metrics and laws of software evolution- the ‘90’s view”, Proceedings of the 4th International Software Metrics Symposium, 1997, pp. 20-32
[9] R. France, J.M. Bieman, “Multi-View software evolution: a UML-Based framework for evolving object-oriented software”, Proceedings of the International Conference on Software Maintenance, 2001, pp.386-395.
[10] P. Knauber, D.Muthing, K. Schmid, T. Widen, “Applying product line concepts in small and medium-sized companies”, IEEE Software, September/October, 2000, pp.88-95.
[11] R.Wiley, T.Elrad, R.E. Filman, A.Bader, “Aspect-Oriented programming”, Communications of the ACM, October 2001, vol.44, no. 10, pp.29-32.
[12] Briand, L.C, Differding C.M, Rombach, H.D., “Practical Guidelines for Measurement-Based Process Improvement”, SOFTWARE PROCESS – Improvement and Practice, Vol.2, 1996 pp. 253-280.
[13] V.R. Basili, G. Caldiera, H.D. Rombach, “Goal Question Metric Paradigm”, Encyclopedia of Software Engineering, John Wiley & Sons, Volume 1, 1994, pp. 528-532.
[14] E.N. Fenton, S.L. Pfleeger, Sofware Metrics: A Rigorous and Practical Approach, second edition, Int’l Thomson Computer Press, London, 1996
[15] J.S. Poulin, “Reuse: Been here, done that”, Communications of the ACM, vol.42, no.5, May 1999, pp.98-100.
[16] W. Frakes, C.Terry, “Software Reuse: Metrics and Models”, ACM Computing Surveys, vol.28, no.2, June 1996, pp.415-435.
