An exploratory study of package metrics as change size indicators in evolving object-oriented software

Transcription

1 Comput Syst Sci & Eng (2013) 4: CRL Publishing Ltd International Journal of Computer Systems Science & Engineering An exploratory study of package metrics as change size indicators in evolving object-oriented software Mahmoud O. Elish Information & Computer Science Department King Fahd University of Petroleum & Minerals Dhahran 31261, Saudi Arabia Software change size prediction can be very useful and helpful in guiding the maintenance team; distributing the resources more efficiently; and, thus, enabling project managers and their teams to focus their effort and attention on the highly unstable artifacts during the software evolution process. This paper empirically explores a set of package-level metrics as change size indicators in evolving object-oriented software. Both structural properties (SP) metrics and historical changes (HC) metrics were explored. Metrics were collected and evaluated in the context of seven major releases of Apache Ant. The results indicate that there are statistically significant correlations between each of the HC metrics and packages change size in multiple, sequential releases of Apache Ant. In addition, it was observed that the HC metrics are more accurate than the SP metrics in predicting change size in packages throughout the releases. Furthermore, there was no confounding effect of package size in the validity of some of the metrics. Keywords: Software metrics, software evolution, change size, packages, object-oriented software. 1. INTRODUCTION Software changes are inevitable if software systems need to sustain and increase their value, and thus remain useful [21]. During software evolution, software undergoes series of changes such as corrective, perfective, adaptive, and preventive changes [16, 22]. Some parts of the software are more prone to changes than others. These parts require particular attention because they require more effort, and increase development and maintenance costs [17]. As object-oriented software systems grow in size and complexity, their classes will become too finely grained to be used as the sole organizational unit for them. In object-oriented designs, packages represent a coarse-grained design structure [7]. A package, in this context, refers to a group of classes that a designer has decided to put together. The way a design is decomposed into packages and the way the classes are distributed into them influence the design quality [7, 20]. The importance of packages has been recognized by software developers, and they become a fundamental part of modern object-oriented programming languages [15]. Identifying and characterizing change-prone packages can enable software developers to focus timely preventive actions on the packages with similar characteristics in the future releases. These preventive actions include peer-reviews, inspection, testing and refactoring. Consequently, software developers can utilize their resources more efficiently and deliver higher quality software systems in a timely manner. However, previous studies were only limited to change-proneness at the class-level [5, 6, 17 19, 23]. Furthermore, most of them have focused on the analysis of single release of a software system. vol 28 no 4 July

2 AN EXPLORATORY STUDY OF PACKAGE METRICS AS CHANGE SIZE INDICATORS IN EVOLVING OBJECT-ORIENTED SOFTWARE The main objective of this study is to empirically explore a set of package-level metrics as change size indicators in evolving object-oriented software. These metrics, if empirically valid, will be essential for objective and quantitative identification and characterization of change-prone packages and for effective prediction of their change size during software evolution throughout the releases. In addition, these metrics will provide useful guidance to practitioners involved in development and maintenance of evolving large-scale software. The rest of this paper is organized as follows. Section 2 reviews related works. Section 3 defines the package-level metrics under investigation. Section 4 discusses the conducted empirical study and its results. Section 5 concludes the paper and suggests directions for future work. 2. RELATED WORK A number of research studies have investigated the relationships between some class-level metrics and change-proneness of object-oriented classes. Li and Henry [19] observed significant correlation between some metrics and the amount of changes in classes in two systems. Koru and Liu [17] used tree-based models to identify and characterize change-prone classes in two open source software products. Koru and Tian [18] compared high-change classes and classes with the highest measurement values in two open source software products. They found that the top classes in change-count rankings and the classes with the highest measurement values were different. Bieman et al. [5] described a method to identify and visualize classes and class interactions that are most change-prone. Bieman et al. [6] found that classes that play roles in design patterns are changed more often than other classes in four of the five examined software systems. Tsantalis et al. [23] proposed a probabilistic approach to estimate the change-proneness of an object-oriented design by evaluating the probability that each class of the system will be affected when new functionality is added or when existing functionality is modified. Elish and Al-Khiaty [10] derived and validated a set of evolution-based metrics as potential indicators of the change-prone classes of an object-oriented system when moving from one release to the next. Other few research studies have explored the relationships between some package-level metrics and some external software quality attributes. Gupta and Chhabra [15] proposed a package coupling metric and empirically evaluated it as indicator of package understandability. They observed a correlation between the proposed metric and package understandability. Elish [9] explored the relationships between Martin metrics [20] and package understandability. He found correlation between all Martin metrics, except the Ce metric, and the effort required to understand a package. Zimmermann et al. [24] used a bug database to calculate pre- and post-release faults for every package and file in the Eclipse releases 2.0, 2.1, and 3.0. Then, they aggregate some of the method and class-level complexity metrics at package-level and correlate them with pre- and post-release faults of a package. The results showed that the combination of complexity metrics can predict defects, suggesting that the more complex the code is, the more faults it has. However, the predictions were far from being perfect [24]. Elish et al. [11] evaluated and compared three suites of package-level metrics in predicting the number of pre-release faults and the number of post-release faults in packages using Eclipse as a case study. Ducasse et al. [7] proposed some package-level metrics based on dependencies between packages, but correlations between these metrics and external software quality attributes have not be established. Numerous research studies have also explored indicators for some other important aspects of software evolution such as identification of the performance characteristics of the bug fixing process of open source applications [12], and source code authorship identification [13]. In summary, literature review suggests that design metrics are generally associated with changeproneness. However, previous studies were only limited to change-proneness at the class-level. Studying change-proneness at the package-level is important because packages represent a coarse-grained design structure [7]. In addition, the way a design is decomposed into packages and the way the classes are distributed in them influence the design quality [7, 20]. 3. PACKAGE-LEVEL METRICS In this study, two sets of package-level metrics are explored: structural properties metrics and historical changes metrics. 3.1 Structural Properties Metrics The structural properties (SP) metrics are product-based metrics that measure different structural properties of packages such as size, coupling, and stability. This study considers, as SP metrics, the popular suite of package-level metrics proposed by Martin [20]. The metrics are defined next [2, 20]: Number of Classes and Interfaces (NC) This metric is defined as the number of concrete and abstract classes (and interfaces) in a package Afferent Couplings (Ca) This metrics is defined as the number of other packages that depend upon classes within a package. It measures the incoming dependencies (fan-in) Efferent Couplings (Ce) This metric is defined as the number of other packages that the classes in a package depend upon. It measures the outgoing dependencies (fan-out) Abstractness (A) This metric is defined as the ratio of the number of abstract classes (and interfaces) in a package to the total number of classes in the package. The range for this metric is zero to one, with zero indicating a completely concrete package and one indicating a completely abstract package. 252 computer systems science & engineering

3 M. O. ELISH Instability (I) This metric is defined as the ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce/(Ce + Ca). This metric is an indicator of the package s resilience to change. The range for this metric is zero to one, with zero indicating a completely stable package and one indicating a completely unstable package Distance from the Main Sequence (D) This metric is defined as the perpendicular distance of a package from the idealized line (A + I = 1). This metric is an indicator of the package s balance between abstractness and stability. A package squarely on the main sequence is optimally balanced with respect to its abstractness and stability. The range for this metric is zero to one, with zero indicating a package that is coincident with the main sequence and one indicating a package that is as far from the main sequence as possible. 3.2 Historical Changes Metrics The historical changes (HC) metrics are process-based metrics that measure previous historical changes that occurred to a package. In this study, three HC metrics are explored, which are defined next Age (AG) This metric is defined as the age of a package at release i. The age of a package starts with zero and is incremented by one as it moves from one release to the next. At a release i, the range for this metric is zero to (i minus one), with zero indicating a package that was introduced at release i, and (i minus one) indicating a package that was introduced at the first release Changes since Previous Release (CSPR) This metric is defined as the number of lines in the code (excluding comment and blank lines) that were added, deleted and modified in a package since the previous release. A modified line is counted twice because it is considered as a deletion and an addition Changes since Birth Release (CSBR) This metric is defined as the number of lines in the code (excluding comment and blank lines) that were added, deleted and modified in a package since its birth release, i.e. the release at which the package was introduced. A modified line is counted twice because it is considered as a deletion and an addition. The CSBR metric will be equal to the CSPR metric if a package was introduced at the previous release. 4. THE EMPIRICAL STUDY This section discusses the conducted empirical study that evaluates the package-level metrics under investigation as change size indicators in evolving object-oriented software. 4.1 Goal The goal is to explore whether the package-level metrics that are collected from release i are good early indicators of the change size in packages from release i to i + 1 (the following release). Using the GQM template [4] for goal definition, the goal of this empirical study is defined as follows: Evaluate the SP metrics (NC, Ca, Ce, A, I, and D), and the HC metrics (AG, CSPR, and CSBR) for the purpose of predicting packages change size with respect to their correlation with package change-proneness and their predictive capability from the point of view of researchers and practitioners in the context of evolving object-oriented software systems. 4.2 Hypotheses This study examined the following null hypotheses: Hypothesis 1: There is no correlation between each of the SP metrics and packages change size in multiple, sequential releases of object-oriented software. Hypothesis 2: There is no correlation between each of the HC metrics and packages change size in multiple, sequential releases of object-oriented software. Hypothesis 3: The HC metrics are not significantly more accurate than the SP metrics in predicting packages change size in multiple, sequential releases of object-oriented software. 4.3 Examined Software This study examined the packages of Apache Ant [1], which is an open source Java-based build tool from the Apache Software Foundation. It is rapidly becoming the de-facto build tool for J2EE projects. In this study, seven major successive releases of Apache Ant were analyzed, from its first release (1.1) to the most recent release at the time of this study (1.7). Precisely, the releases are 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 1.7. Apache Ant was selected because it represents one of the most popular and widely-used open source software systems/tools that are actively evolving. In addition, all its releases are publicly available; each with a detailed release history/notes. 4.4 Independent and Dependent Variables The independent variables are the nine package-level metrics: the six SP metrics (NC, Ca, Ce, A, I, and D); and the three HC metrics (AG, CSPR, and CSBR). The dependent variable, i.e. change size, is the number of lines in the code (excluding comment and blank lines) that were added, deleted and modified per package from release ito the next release i + 1. Formally, change size = added lines + deleted lines +2 modified lines. A modified line is counted twice because it is considered as a deletion and an addition, similar to other research studies [10, 14, 19]. For example, if four new lines were added to a package; vol 28 no 4 July

4 AN EXPLORATORY STUDY OF PACKAGE METRICS AS CHANGE SIZE INDICATORS IN EVOLVING OBJECT-ORIENTED SOFTWARE seven lines were deleted; and five lines were modified, then the change size is 21 lines ( ). 4.5 Data Collection JDepend tool [2] was used to measure the SP metrics. ExamDiff Pro tool [3] was used to measure the HC metrics. It was also used to measure the change size per package comparing release i and release i + 1 (following release). Table 1 provides descriptive statistics of the collected measures. It can be observed that the number of classes in these packages varies from 1 to 286 with an average of around 17 classes. The average values of the Ca and Ce metrics indicate that these packages have more efferent coupling than afferent coupling. Accordingly, the average value of the I metric is above 0.5. It can be also observed that, on average, around 3800 lines of code (LOC) were changed per package from one release to the next; and around 8800 LOC since their birth release. Table 1 Descriptive statistics. Metric Min Max Avg. Std. Dev. NC Ca Ce A I D Age CSPR CSBR Change size Correlation Analysis The correlation analysis aims to determine if each individual package-level metrics is significantly related to the change size. This analysis was performed to test hypotheses 1 and 2. Spearman rank correlation was performed, and the significance of the correlation was tested at the 0.05 level of significance, i.e. 95% confidence level. Table 2 provides the correlation coefficients between the SP metrics and change size throughout the releases; p-values are between parentheses. Significant correlations (i.e. p-value < 0.05) are marked with (*). Figure 1 shows the number of times that each SP metric is significantly correlated with change size throughout the releases. Figure 2 shows the number of SP metrics that are significantly correlated with change size in each release. The main observations are: All the SP metrics are significantly correlated with change size from release 1.6 to 1.7. Each SP metric is significantly correlated with change size in at least one release. Throughout the releases, at least one SP metric is significantly correlated with change size. None of the SP metrics is significantly correlated with change size throughout the releases. The NC metric is significantly correlated with change size the highest number of times (5 out of 6) throughout the releases. The A metric is significantly correlated with change size the lowest number of times (1 out of 6) throughout the releases. From release 1.2 to 1.3, the lowest number of SP metrics (1 out of 6) is significantly correlated with change size. The positive correlation between the NC metric and change size suggests that large packages are more change-prone than small ones, and thus there is a need to investigate the confounding effect of package size (Section 4.8). In addition, the positive correlations between each of the Ca and Ca metrics and change size suggest that packages that are tightly coupled to other packages are more change-prone than loosely coupled packages. The negative correlation between the I metric and change size is surprising, and suggests that the I metric is invalid instability measure. Based on the correlations reported in Table 2, the null hypothesis 1 is accepted since none of the SP metrics was found to be significantly correlated with change size throughout the releases. Table 3 provides the correlation coefficients between the HC metrics and change size throughout the releases; p-values are between parentheses. The correlation between change size and the HC metrics was not applicable (N/A) from release 1.1 to release 1.2 since release 1.1 is the first release and thus the values for all HC metrics for all packages are zeros. Moreover, since the CSPR and CSBR metrics are equal for each package in release 1.2, they have the same correlation with change size, i.e., It can be observed that all the HC metrics are significantly correlated with change size throughout the releases. These are all positive correlations. This means that the larger the package changes since the pervious release or the birth release, the larger the amount of changes the package will undergo from the current release to the following release. It also means that old packages are more changeable than recent packages. Therefore, the null hypothesis 2 is rejected, i.e. there are significant correlations between each of the HC metrics and packages change size in multiple, sequential releases of object-oriented software. When comparing Tables 2 and 3, it can be noticed that there are higher correlation coefficients between change size and the HC metrics than the SP metrics throughout the releases in general. However, there are some SP metrics such as the NC and Ce metrics whose correlations with change size are competitive. 4.7 Prediction Models For each release, two different multivariate regression models were built to predict the change size in each package from release i to release i +1 (following release). One model (SP-Model) was build using only the SP metrics, and the other model (HC-Model) was built using only the HC metrics. The accuracy of these two models was then evaluated and compared under leave-one-out cross validation. 254 computer systems science & engineering

5 M. O. ELISH Table 2 Correlation between SP metrics and change size. Metric Release 1.1 to 1.2 Release 1.2 to 1.3 Release 1.3 to 1.4 Release 1.4 to 1.5 Release 1.5 to 1.6 Release 1.6 to 1.7 NC (0.104) (0.007)* (0.003)* (<0.000)* (<0.000)* (<0.000)* Ca (0.041)* (0.057) (0.135) (0.038)* (0.113) (0.011)* Ce (0.493) (0.051) (<0.000)* (0.005)* (<0.000)* (<0.000)* A (0.935) (0.109) (0.451) (0.969) (0.342) (0.007)* I (0.041)* (0.086) (0.159) (0.039)* (0.228) (0.016)* D (0.935) (0.104) (0.038)* (0.055) (0.315) (0.006)* *Correlation is significant at the 0.05 level Table 3 Correlation between HC metrics and change size. Metric Release 1.1 to 1.2 Release 1.2 to 1.3 Release 1.3 to 1.4 Release 1.4 to 1.5 Release 1.5 to 1.6 Release 1.6 to 1.7 AG N/A (0.020)* (0.002)* (0.044)* (0.005)* (0.001)* CSPR N/A (0.005)* (<0.000)* (<0.000)* (0.005)* (<0.000)* CSBR N/A (0.005)* (<0.000)* (0.001)* (0.002)* (<0.000)* * Correlation is significant at the 0.05 level 6 6 of releases No NC Ca Ce A I D SP Metric ofsp metrics No Release Figure 1 The number of times each SP metric is significantly correlated with change size throughout the releases. Figure 2 The number of SP metrics that are significantly correlated with change size in each release. In this study, we used de facto standard and commonly used prediction accuracy measures: mean magnitude of relative error (MMRE) and prediction at level q (Pred(q)) measures. MMRE over a dataset of n observations is calculated as follows: MMRE = 1 n n MRE j j=1 where MRE j is a normalized measure of the discrepancy between the actual value (x j ) and the predicated value ( ˆx j ) of observation j. It is calculated as follows: x j ˆx j MRE j = Pred(q) is a measure of the percentage of observations whose MRE is less than or equal to q. It is calculated as follows: Pr ed(q) = k n where k is the number of observations whose MRE is less than or equal to a specified level q, and n is the total number of x j observations in the dataset. In this study, we used Pred(0.25) because it is commonly used in the literature. Figure 3 shows the MMRE values that have been achieved by the SP-models and the HC-Models throughout the releases. It can be observed that the HC-Models has achieved around 50% less MMRE than the SP-Models throughout the releases. These results indicate that the HC-Models have superior performance compared to the SP-Models. Figure 4 shows the Pred(0.25) values that have been achieved by the SP-models and the HC-Models throughout the releases. The change size of around 7% of the packages in release 1.2 has been predicted within 0.25 MRE using the HC-Model. This percentage has increased throughout the releases, except release 1.5, to reach around 22% in release 1.6. On the other hand, lower Pred(0.25) values have been achieved by the SP-Models compared to the HC-Models. The change size of less than 5% of the packages in 4 out of the 6 releases has been predicted within 0.25 MRE using the SP-Models. Moreover, the SP-models were not able to predict the change size of any package in releases 1.1 and 1.2 within 0.25 MRE. Wilcoxon nonparametric test was also performed to determine whether or not there is a statistically significance difference in vol 28 no 4 July

6 AN EXPLORATORY STUDY OF PACKAGE METRICS AS CHANGE SIZE INDICATORS IN EVOLVING OBJECT-ORIENTED SOFTWARE MMRE P red(0.25) SP-Model HC-Model Release Figure 3 MMRE results. 30% 25% 20% 15% 10% 5% 0% SP-Model 0.00% 0.00% 4.35% 12.50% 3.85% 9.52% HC-Model 7.69% 17.39% 18.75% 9.62% 22.22% Release 4.8 Confounding Effect of Package Size This study also investigated the potential confounding effect of package size on the validity of the package-level metrics under investigation with respect to their relationship with change size. This helps to determine if the relationship between these metrics and change size in packages is real regardless of the package s size. This study followed the same approach suggested by El Emam et al. [8] to determine whether there is a confounding effect of package size. The idea is to include a size metric (NC in this study) as another independent variable, in addition to a package-level metric, in a prediction model for change size. If there is a statistically significant difference in the results with and without the size metric, then this indicates a confounding effect of size on the validity of the metric under evaluation. In order to examine the confounding effect of size on each package-level metric, two prediction models for change size were built: (i) one based on that metric only and (ii) one based on that metric and NC metric. Wilcoxon nonparametric test was then performed, at 95% confidence level, to evaluate the significance difference between the results obtained from each model. 5 reports the Z statistic values and p-values for the Wilcoxon test results. If the p-value is less than 0.05 (highlighted in bold), then there is a confounding effect of size on the validity of the corresponding metrics. It can be observed that the associations between all of the SP metrics, except the D metric, and change size disappear after controlling for package size confounder. Among the HC metrics, only the association between the AG metric and change size disappears. However, there is no confounding effect of package size on the validity of the CSPR and CSBR metrics with respect to their relationship with change size. Figure 4 Pred(0.25) results. the prediction performance between the HC-Models and the SP- Models. This test was chosen because it does not require any underlying distribution in the data, and is not influenced by outlier data points. Table 4 presents the Z statistic values and the corresponding p-values of that test throughout the releases of Apache Ant. As can be observed, the results indicate that the HC-Models are significantly better than the SP-Models in all release at 0.05 level of significance (95% confidence level), except in release where the significant is at 90% conference level. These results indicate that the HC-Models have superior performance compared to the SP-Models. Therefore, the null hypothesis 3 is rejected, i.e. the HC metrics are significantly more accurate than the SP metrics in predicting packages change size in multiple, sequential releases of object-oriented software. Table 4 Wilcoxon test for significance between HC-Models and SP-Models. Release Z p-value Table 5 Wilcoxon test for confounding effect of package size. Metric Z p-value Ca Ce A I D AG CSPR CSBR CONCLUSION This paper has empirically explored a set of package-level metrics as change size indicators in evolving object-oriented software. Both structural properties (SP) metrics and historical changes (HC) metrics were explored. Metrics were collected and evaluated in the context of seven major releases of Apache Ant. The main findings of this study can be summarized as follows. There are significant correlations between each of the HC metrics and packages change size in multiple, sequential releases of Apache Ant. In addition, there are higher correlation coefficients between packages change size and the HC metrics than the SP metrics throughout the releases in general. How- 256 computer systems science & engineering

7 M. O. ELISH ever, there are some SP metrics such as the NC and Ce metrics whose correlations with packages change size are competitive. It was also observed that the HC metrics are more accurate than the SP metrics in predicting packages change size throughout the releases. Furthermore, there was no confounding effect of package size in the validity of some of the metrics. This study has a number of limitations that are not unique to it but are common with most of the case studies in the literature. Seven major releases of Apache Ant were analyzed in this study. Despite being a typical open-source system with reasonable size, additional studies involving other systems are needed to further support the findings of this study and to accumulate knowledge. This study was limited to nine package-level metrics. These metrics were selected due to their popularity and the availability of metrics tools to collect them. More metrics can be explored as a future work. In addition, this study was a regression and correlation study. Association between some of the explored package-level metrics and the change size was observed but causality of the association cannot be claimed. In other words, claims cannot be made as altering a package to decrease its coupling would certainly increase its future change size. This study has contributed initial empirical evidence on the usefulness and effectiveness of some package-level metrics as change size indicators in evolving object-oriented software. Such metrics will be essential for objective and quantitative identification and characterization of change-prone packages and for effective prediction of their change size during software evolution throughout the releases. In addition, these metrics will provide useful guidance to practitioners involved in development and maintenance of evolving large-scale software. There are some possible directions for future work. One direction would be conducting additional studies to further support the findings of this paper, and to accumulate knowledge. Another direction would be validating the explored package-level metrics with respect to other external software quality attributes. It would also be interesting to explore more package-level metrics, and to apply computational intelligence models to this type of problems for improved prediction accuracy. ACKNOWLEDGMENTS This research work is funded by King Fahd University of Petroleum & Minerals under Research Grant No. JF REFERENCES V. Basili and H. Rombach, The TAME Project: Towards Improvement-Oriented Software Environment, IEEE Transactions on Software Engineering, vol. 14, no. 6, pp , J. Bieman, A. Andrews, and H. Yang, Understanding Changeproneness in OO Software through Visualization, in 11th IEEE International Workshop on Program Comprehension, pp , J. Bieman, G. Straw, H. Wang, P. Munger, and R. Alexander, Design Patterns and Change Proneness: An Examination of Five Evolving Systems, in 9th International Software Metrics Symposium, pp , S. Ducasse, M. Lanza, and L. Ponisio, Butterflies: A Visual Approach to Characterize Packages, in 11th IEEE International Software Metrics Symposium, K. El-Emam, S. Benlarbi, N. Goel, and S. Rai, The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics, IEEE Transactions on Software Engineering, vol. 27, pp , M. Elish, Exploring the Relationships between Design Metrics and Package Understandability: A Case Study, in 18th IEEE International Conference on Program Comprehension, pp , M. Elish and M. Al-Khiaty, A suite of metrics for quantifying historical changes to predict future change-prone classes in objectoriented software, Journal of Software Maintenance and Evolution: Research and Practice, In press. 11. M. Elish, A. Al-Yafei, and M. Al-Mulhem, Empirical Comparison of Three Metrics Suites for Fault Prediction in Packages of Object-Oriented Systems: A Case Study of Eclipse, Advances in Engineering Software, vol. 42, no. 10, pp , C. Francalanci and F. Merlo, Empirical analysis of the bug fixing process in open source projects, International Journal of Computer Systems Science and Engineering, vol. 25, no. 4, G. Frantzeskou, S. MacDonell, E. Stamatatos, S. Georgiou, and S. Gritzalis, The significance of user-defined identifiers in Java source code authorship identification, International Journal of Computer Systems Science and Engineering, vol. 26, no. 2, T. Graves, A. Karr, J. Marron, and H. Siy, Predicting Fault Incidence Using Software Change History, IEEE Transactions on Software Engineering, vol. 26, no. 7, pp , V. Gupta and J. Chhabra, Package Coupling Measurement in Object-Oriented Software, Journal of Computer Science and Technology, vol. 24, no. 2, pp , IEEE, IEEE Standard Glossary of Software Engineering Terminology, A. Koru and H. Liu, Identifying and characterizing change-prone classes in two large-scale open-source products, Journal of Systems and Software, A. Koru and J. Tian, Comparing High-Change Modules and Modules with the Highest Measurement Values in Two Large-Scale Open-Source Products, IEEE Transactions on Software Engineering, vol. 31, no. 8, pp , W. Li and S. Henry, Object-Oriented Metrics that Predict Maintainability, Journal of Systems and Software, vol. 23, no. 2, pp , R. Martin, Agile Software Development: Principles, Patterns and Practices: Prentice Hall, I. Sommerville, Software Engineering, 7th Edition ed.: Addison- Wesley, E. Swanson, The Dimensions of Maintenance, in 2nd International Conference on Software Engineering, pp , N. Tsantalis, A. Chatzigeorgiou, and G. Stephanides, Predicting the Probability of Change in Object-Oriented Systems, IEEE Transactions on Software Engineering, vol. 31, no. 7, pp , T. Zimmermann, R. Premraj, and A. Zeller, Predicting Defects for Eclipse, in 3rd International Workshop on Predictor Models in Software Engineering, vol 28 no 4 July

8