International Conference on Product Focused Software Process Improvement (profes2000) Model

International Conference on Product Focused Software Process Improvement (profes2000)Modeling and Analysis of Software Aging ProcessAkito Monden1, Shin-ichi Sato2, Ken-ichi Matsumoto1, Katsuro Inoue1,31 Graduate School of Information Science, Nara Institute of Science and Technology,8916-5 Takayama, Ikoma, Nara 630-0101, Japan{akito-m, matumoto}@is.aist-nara.ac.jp2 NTT DATA Corporation, Laboratory for Information Technology,Department of Research & Development HeadquartersKayabacho-Tower, 21-2, Shinkawa 1-chome, Chuo-ku, Tokyo 104-0033, Japans-sato@rd.nttdata.co.jp3Graduate School of Engineering Science, Osaka University1-3 Machikaneyama-cho, Toyonaka, Osaka 560-8531, Japaninoue@ics.es.osaka-u.ac.jpAbstract. This paper proposes a model of successful maintenance that can represent how maintainability ofeach software module changes as it ages. We found that some of the metrics, measured from 20 years oldsystem, fit our model; i.e., values of those metrics seem to be proportional to the degree of maintainability.We described each metric’s critical line – a value that can be used for deciding whether a module should bere-engineered or not. We also described the interpretations on how each software metric relates tomaintainability.1 IntroductionMany organizations have aged software that had been developed many years ago and have been continuously modified and expanded till today[4]. While they are so crucial to organizations’ survival, they cannot be retired.However, in order to keep aged software up to date, the maintenance cost tends to increase year by year because “modifying the software” itself makes the software more difficult to be modified. That is, aging software becomes more complicated, unreadable and unchangable over time[2][6][7].In order to successfully maintain a large system for many years, organizations need to keep software modules not to become too much complicated[1]. They need to keep up improving the maintainability of each module by cleaning up spaghetti codes, reconfiguring module structures, redesigning functional logic and data handling, etc.For example, functional strength can be gained by reengineering one big module into several smaller modules with more explicit interfaces.Therefore, in case a maintainer needs to add functions to a large system, he/she has several possible choices.For example, making a few changes in several modules, throwing away several modules and redesigning them as new modules, restructuring modules then add functions, and so on. Indeed, it is often very difficult to say which choice will be the best. Making a few changes in modules may be less expensive than redesigning the modules, however, future maintenance cost may become more expensive in this case[8][9]. Organizations want a certain criterion or a guide that can help in making above decision.The goal of this research is to find criteria for making above decision. We believe that one of criteria is realized by a certain set of software metrics that indicates the degree of maintenance difficulty of each module. Ifa module turned out to be quite difficult to be maintained, we should somehow re-engineer it instead of keep onexpanding it. Yet, although various software metrics have been proposed as complexity measure, it is not easy to say which metric should be used as such criterion in a large and aged system.Our approach is to analyze the aging process of a large system that has been successfully maintained. We consider that succeeded system is appropriately maintained, i.e., decisions in maintenance activities have been made properly. We first propose a process model of successful software maintenance that can represent how maintainability of each module changes as it ages. Next, based on the model, we carry out cross-sectional analysis on software metrics collected from a succeeded system that has been maintained over 20 years. Finally, we give interpretations on how each software metric relates to maintainability.Rest of this paper first proposes a software aging model (Section 2). Next describes data we use (Section 3), then we analyze the data based on our model, and give interpretations (Section 4). In the end, conclusions and future topics will be shown (Section 5).2 Software Aging Model in Successful MaintenanceAging of software is not due to the lapse of time. It is due to the change of complexity caused by continuous maintenance activities. Here, the maintenance activities contain both that cause software more complicated and that can reduce the complexity. The former includes expansions of functions, and the latter includes a sort of re-engineering activity. Our claim is that a successful maintenance process contains both of these activities in good balance, i.e., organizations do some re-engineering action before software becomes too much complicated. Furthermore, this aging process should be applied to every software module because each module in a large system does not become aged equally. Some modules may be more aged than others because frequency of revisions may be different.Based on above discussion, we propose a model that represents successful maintenance process of each software module (Figure 1). In Figure 1, the change of maintainability of one module is shown. The revision number in the figure indicates the number of maintenance activities done to that module. Basically, as the revision number increases, maintainability of the module becomes worse. So far, before it becomes too much difficult to maintain (we call this point critical line), an action to improve maintainability will be made. Therefore, maintainability of a module does not exceed the critical line greatly. Otherwise, the module is redesigned as a new module (Figure 2). In this case, revision number is set to zero. These two processes can keep the maintenance cost relatively low because the cost required to revise modules under the critical line is much lower than those exist over the line. Although the enhancement and redesign of a system also has a price, it is said that there is a line that cost reduction in future maintenance becomes greater than that price[8][9]. In our model, we explicitly give this critical line in the figures.does not touch that module as much as possible. Thus, the revision number of this module will not increase greatly (Figure 3). However, if a maintainer needs to repeatedly revise such a module, an action to improve the maintainability is carried out (Figure 4). These two processes also keep the maintenance cost low.After all, in case an organization tries to keep maintenance cost of a whole system low, maintainability of every module tends to converge upon the critical line as its revision number increases (Figure 5). Hence, based on our model, if we plot every module’s maintainability of a successfully aged system into a scatter diagram, the shape of the graph will be like Figure 6. In Figure 6, there are both modules of good maintainability and of bad maintainability in the low revision number area. And, as revision number increases, modules that have extreme maintainability (both very good and very bad) are disappeared. Finally, in the high revision number area, most of modules are very close to the critical line.Figure 6 also indicates an another very important property. That is, we can use this figure for finding software metrics that are proportional to the maintainability. If we draw a scatter diagram with revision number and a metric measured from each module of a successfully aged system, shape of the diagram is expected to resemble Figure 6, if the metric is proportional to maintainability. In this case, we do not need to measure time series (historical) data. We need only cross sectional data - metrics collected in a certain period. From next section, based on our model, we are to find a set of metrics that indicates the degree of maintainability.3 Data for Analysis3.1 Target SoftwareThe target software is categorized to “system software” which is an application that controls physical devices[3]. The software is working on a mainframe machine. This software has been maintained for about twenty years and modified and expanded many times during that period. It was written in a COBOL based language (expansion of COBOL with macros). It consists of 1854 modules (source files). Each module contains several procedures (subroutines).3.2 Collected MetricsAs shown in Table 1, we have measured 44 metrics from each 1854 modules. Table 1 shows the mean value and the standard deviation of each metric. It can be seen that values are widely scattered around the mean value. These metrics are common metrics used for predicting the reliability of software by many researchers[5][10][11]. Since some of these software metrics, such as the number of loops, have extremely high correlation with LOC (lines of code) and/or NODE (the number of nodes), we normalized them by LOC or NODE. In Table 1, metrics No.16 to 44 are normalized.This normalization is indispensable to our analysis. If we do not do this, it becomes extremely difficult to analyze the correlation between revision number and each metrics. For example, even in case if we see there is a strong correlation between the revision number and the number of loops, we cannot decide whether it points out “revisions make software more complex because revisions cause increase of loops” or it just says “revisions make software larger and it is natural that larger software have more loops”. So we needed to normalize size-related metrics with LOC or NODE. Metrics related with statement (such as the number of comment lines) are normalized by LOC; and, metrics related with nodes (such as the number of loops) are normalized by NODE.Table 2 shows correlation values between REVISON (revision number) and each metric. It is seen most of metrics have very weak correlation with REVISION. Metrics that have relatively large correlation value (over .4) are LOC, VOCABURARY, LENGTH, VOLUME, and INFORMATION. These five metrics are the sort of size metric and have large correlation values each other (.50 ~ .99). On the other hand, the only metric that has relatively large negative value (under -.4) is OPERTR_UNQ/L (The number of unique operators per LOC). However, since there is no metric that have strong correlation with REVISION, it seems no useful information can be derived. This indicates that measuring correlation value is not enough helpful for analyzing the software aging process.Table 1. Collected Metrics (1)METRICS EXPLANATIONSMeanStd.Dev.1 REVISION Revision number 49.62 44.812 LOC Lines of Code 631.82 564.423 VARNAME Average length of variable name 8.16 .7204 FANIN Number of FAN-INs 4.96 33.45 FANOUT Number of FAN-OUTs 7.37 9.896 VOCABULARY Halstead’s Software Science (vocabulary) 254.78 149.037 LENGTH Halstead’s Software Science (length) 1249.72 1233.138 VOLUME Halstead’s Software Science (volume) 10484.80 11308.579 DIFFICULTY Halstead’s Software Science (difficulty) 30.94 21.3010 EFFORT Halstead’s Software Science (effort) 517219 173225711 ABST_LEVEL Halstead’s Software Science (abstraction level) .0509 .053212 INFORMATION Halstead’s Software Science (information) 299.76 198.5813 LANG_LEVEL Halstead’s Software Science (language level) 11.96 9.7914 MAX_NESTLEVEL Maximum of nest level 5.12 1.8715 NODE Numbers of nodes 247.54 245.4916 OPERTR_UNQ/LNumber of unique operators per LOC .0602 .042417 OPERTR/L Number of operators per LOC .846 .21018 OPERND_UNQ/L Number of unique operands per LOC .450 .16019 OPERND/L Number of operands per LOC 1.04 .22820 COMMENT/L Number of comment lines per LOC .508 .15521 DECLARE1/L Number of variable declarations per LOC .0142 .015222 DECLARE2/L Number of variable declarations excluding membervariables in data structure per LOC.124 .10523 EXT_VAR/L Number of external variables per LOC .405 .27424 DEFINED/L Number of defined variables per LOC .652 .14225 USED/L Number of used variables per LOC .946 .280Table 2. Collected Metrics (2)Dev.Std.Mean METRICS EXPLANATIONSNumber of defined external-variables per LOC .464 .24026DEFINED_EXT/L27 USED_EXT/L Number of used external-variables per LOC .564 .33428 CYCLOMATIC/N Cyclomatic Number per NODE .257 .11629 BRANCH/N Number of branches per NODE .186 .075930 NESTLEVEL/N Sum of nest level per NODE 2.71 1.0431 LOOP/N Number of loops per NODE .0158 .015732 JUMP/N Number of jump nodes per NODE .0538 .051433 MYERS/N Myer’s Interval per NODE .292 .13634 INNER_PROC/L Number of procedure declarations per LOC .0180 .011035 NOTREACHED/N Number of unused nodes per NODE .00452 .045036 SUBST/N Number of substitution nodes per NODE .646 .13137 IO/N Number of I/O nodes per NODE .0121 .036738 ARITHMETIC/N Number of arithmetic operator per NODE .0235 .036139 COMPARE/N Number of comparison operator per NODE .0704 .038340 LOGICAL/N Number of logical operator per NODE .0264 .026041 INT_CALL_UNQ/L Number of unique local-procedure calls per LOC .0109 .0083042 INT_CALL/L Number of local-procedure calls per LOC .0187 .017643 EXT_CALL_UNQ/L Number of unique external-procedure calls per LOC .00838 .014144 EXT_CALL/L Number of external-procedure calls per LOC .0140 .0220Table 3. Correlation between REVISION and metrics REVISION LOC VARNAME FANIN FANOUT 1.000 .512 .056 -.047 .265 VOCABURARY LENGTH VOLUME DIFFICULTY EFFORT .517 .464 .467 .323 .181 ABST_LEVEL INFORMATION LANG_LEVEL MAX_NESTLEVEL OPERTR_UNQ/L -.279 .456 .042 .353 -.430 OPERTR/L OPERND_UNQ/L OPERND/L COMMENT/L NODE/L .190 -.314 .065 -.058 -.092 DECLARE1/L DECLARE2/L EXT_VAR/L DEFINED/L USED/L -.027 0.029 .068 -.012 .181 DEFINED_EXT/L USED_EXT/L CYCLOMATIC/N BRANCH/N NESTLEVEL/N -.055 .087 -.100 .125 LOOP/N JUMP/N MYERS/N INNER_PROC/L NOTREACHED/N .064 .015 -.052 -.266 -.026 SUBST/N IO/N ARITHMETIC/N COMPARE/N LOGICAL/N -.056 .097 .139 .133 .100 INT_CALL_UNQ/LINT_CALL/L EXT_CALL_UNQ/L EXT_CALL/L .019 .173 -.137 -.0864 Analysis of Software Aging Process4.1 Metrics Fit to the ModelIn this section, based on the model described in Section 2, we present metrics that seems to be proportional to the maintainability; then, we give interpretations on how and why they relate to maintainability. We found that nine metrics fit our model, i.e., the scatter diagrams of these nine metrics resemble Figure 6. That is, there are both modules of low metric value and of high metric value in the low revision number area; and, as revision number increases, metric value converges upon the critical line. Below we illustrate the diagrams classifying them into four groups:1) Metrics related to the branch of control flow.The metrics of BRANCH/N, CYCLOMATIC/N, MAX_NESTLEVEL, and NESTLEVEL/N are all seemed to be proportional to the degree of maintainability (Figure 7). In figure 7, horizontal axis is the revision number, and vertical axis is for each metric. The critical line for each metric is seen .22 in BRANCH/N, .25 in CYCLOMATIC/N, 7.0 in MAX_NESTLEVEL, and 3.0 in NESTLEVEL/N respectively. Below we state our interpretations for both lower half and upper half of each diagram.- Lower half of each diagram:When we add new functions to software modules, we inevitably add branch nodes to the target module to connect control flows to newly added functions. Therefore, the number of branch per node (and also the nest level of branch per node) tends to increase, as the number of revisions becomes larger.- Upper half of each diagram:It is very difficult to maintain a module that has too many branches. Therefore, such module is re-engineered so that branches are reduced (Nesting part may be rebuilt as a new procedure). It is quite natural to say that increase of the branch nodes makes software difficult to comprehend because it becomes very difficult to figure out in what situation each branch becomes true.2) Metrics related to the number of variables appeared in each statement.The metrics of DEFINED/L, USED/L, and OPERND/L are also seemed to be proportional to the maintainability (Figure 8). Just as Figure7, horizontal axis indicates the revision number, and vertical axis is for each metric. The critical line for each metric is seen .60 in DEFINED/L, 1.0 in USED/L, and 1.0 in OPERND/L respectively. Here, the operand in the metric OPERND/L includes variables, defined constant values, registers, macros, etc. Below we describe our interpretations.- Lower half of each diagram:If we add new functions to software modules, we inevitably need to pass values to added functions, and get return values from them. Moreover, we may also need to write some equations to calculate values that will be passed to added functions. In this case, metrics related to the number of variables appeared in each statement may become larger. Thus, values of DEFINED/L, USED/L and OPERND/L become larger. Especially, if each newly added function is called from more than one place, values of these metrics may increase more.- Upper half of each diagram:Naturally, if there were so many variables appeared in each statement, it is very difficult to follow up how the value of each variable changes. Therefore, maintainability is bad in this case. In such a case, re-engineering activities will take place to arrange similar equations and functions into a new procedure.3) INT_CALL/L (Number of local-procedure calls per LOC).The metric INT_CALL/L is another candidate that proportionally affects the maintainability (Figure 9). The critical line of this metric is seen around .013. Our interpretations are below:- Lower half of the diagram:In case we add a new procedure to a module in maintenance phase, this procedure tends to have strong coupling with other part of the program because such a procedure is not supposed to be added in the ancient design. Consequently, the added function is called from several part of the module; and, the metric INT_CALL/L increases.- Upper half of the diagram:If there were too many procedure calls in the program, it is difficult to follow up the control flow. In this case, we need to enhance the modularity of procedures by redesigning and restructuring them.4) VARNAME (Average length of variable name)The metric VARNAME can be proportional to the maintainability (Figure 10). Yet, we do not have a clear interpretation or hypothesis on why the length of variable name converges to the critical line. For the further analysis, we may need to measure standard deviation of the length of variable name.4.2 Metrics Do Not Fit to the ModelMost of metrics shown in Table 1 does not fit to our model, however, those metrics can also have a possibility to affect the maintainability (although their effect may not be proportional). We classified those metrics into three groups from the shape of scatter diagrams:1) Rising patternThe scatter diagrams of metrics in this group are somewhat rising (Figure 11). In the left side of Figure 11, we describe typical shape of the diagram in this group. Right side of the figure shows an example of a metric in this group. Metrics in this group are LOC, VOCABURARY, LENGTH, VOLUME, DIFFICULTY, LANG_LEVEL, NODE, and OPERTR/L. Most of them are related to the size of a module. It is natural that size of a module is enlarged by continuous expansions in maintenance phase.2) Falling patternThe diagrams of metrics in this group are somewhat going down (Figure 12). Left side of Figure 12 describes typical shape, and right side is an example. Metrics in this group are ABST_LEVEL, OPERTR_UNQ/L,OPERND_UNQ/L, INNER_PROC/L, EXT_CALL_UNQ/L, and EXT_CALL/L. These metrics have a tendency to decrease as revision number increases.3) No patternThe diagrams of metrics in this group seemed to have no characteristics in their shape. Metrics in this group are FANIN, FANOUT, EFFORT, COMMENT/L, DECLARE1, DECLARE2, EXT_VAR/L, DEFINED_EXT/L, USED_EXT/L, LOOP/N, JUMP/N, NOTREACHED/L, SUBST/L, IO/L, ARITHMETIC/N, COMPARE/N, LOGICAL/N, and INT_CALL/L. These metrics can be regarded to have weak relation to maintainability of modules.5 SummaryIn this paper, we proposed a process model of successful software maintenance that can represent how maintainability of each module changes as it ages. We found that some of the metrics, measured from 20 years old system, fit our model; i.e., values of those metrics seem to be proportional to the degree of maintainability. We described each metric’s critical line – a value that can be used for deciding whether a module should be re-engineered or not. We also described the interpretations (hypothesis) on how each software metric relates to maintainability.We are going to show our result and interpretations to engineers who maintained the system we analyzed, and ask them if the result and interpretations agree with their mind. We are also planning to choose modules that should be re-engineered, by using critical lines we derived; and, we will ask engineers if those modules are really difficult to be maintained or not. Furthermore, we are to give mathematical explanations to our model in the future.References1. V. Basili, L. Briand, S. Condon, Y. Kim, W. L. Melo, J. D. Valett. Understanding and predicting the process of softwaremaintenance releases, In Proceedings of the 18th International Conference on Software Engineering, pp.464-474, Berlin, Germany, Mar. 1996.2. K. Bennett. Legacy systems: Coping with success, IEEE Software, Vol.12, No.1, pp.19-23, Jan. 1995.3. C. Jones. Large software system failures and successes, American Programmer, pp.3-9, Apr. 1996.4. D. L. Parnas. Software aging. In Proceedings of the 16th International Conference on Software Engineering, pp. 279-287, Sorrento, Italy, May 1994.5. M. Pighin, and R. Zamolo. A predictive metric based on discriminant statistical analysis, In Proceedings of the 19thInternational Conference on Software Engineering, pp.262-270, Boston, USA, 1997.6. N. F. Schneidewind, and C. Ebert. Preserve of redesign legacy systems?, IEEE Software, Vol. 15, No.4, pp.14-17,July/Aug. 1998.7. M. Solvin, and S. Malik. Reengineering to reduce system maintenance: A case study, Software Engineering, pp.14-24,Research Institute of America Inc., July/Aug. 1991.8. H. M. Sneed. Economics of software re-engineering, Journal of Software Maintenance: Research and Practice, Vol.3,No.3, pp.163-182, 1991.9. H. M. Sneed. Planning the reengineering of legacy systems, IEEE Software, Vol.12, No.1, pp.24-34, Jan. 1995.10. S. Takabayashi, A. Monden, S. Sato, K. Matsumoto, K. Inoue, and K. Torii. The detection of fault-prone program usinga neural network, In Proceedings of the International Symposium on Future Software Technology’99, pp.81-86, Nanjing,China, Oct. 1999.11. M. D. Weiser. Program slicing, IEEE Transactions on Software Engineering, Vol.10, No.4, pp.352-357, 1984.。