Quality assurance is a continuous process throughout the project lifecycle from inception till post-delivery. Software metrics are tools to help developers in achieving software quality objectives. Software metrics are used to predict the fault-proneness of classes in software using machine-learning and statistical techniques. However, these methodologies are difficult for daily tasks. Simpler and on the fly methodologies such as threshold values are needed. Metric thresholds can be used to control software quality and to recommend improvements on software code. Thresholds detect the parts of software that need more verification and validation. Many threshold identification techniques were proposed in previous research. However, the techniques do not provide consistent thresholds. The authors compare eight threshold identification techniques to diagnose software fault-proneness. The eight techniques are derived from diagnosis measures such as specificity, sensitivity, recall and precision. Five threshold identification techniques have derived thresholds that are skewed and have large standard deviations. Only three techniques are selected for threshold identification based on consistency and variation in selecting thresholds of software metrics in the systems under study. These techniques find thresholds that have the least variation among the studied techniques. The median of the 11 systems is selected as a representative of all thresholds.

Software metrics are surrogates of many software quality factors such as fault proneness, reusability, and maintenance effort. Software metrics are numbers collected from software code to assess and evaluate where problems are more probable to happen. These numbers are used to flag warnings of the problematic parts of software code using threshold values. However, the proposed techniques did not consider the data distribution and skewness in data. In this research, we aim to propose a methodology based on log transformation to improve the metrics quality. To explore the effect of log transformation on data analysis, we conduct analysis of using software metrics after transformation in identifying fault-prone areas on multireleases of 11 products (41 releases). The results show that the log transformation can be used to derive threshold values for all metrics under investigation. The results of the transformation are then used to conduct fault-proneness classification based on threshold values and compared against the results without transformation. The fault classification with transformation was more successful than without transformation. Copyright © 2015 John Wiley & Sons, Ltd.

Abstract An empirical study of the relationship between object‐oriented (OO) metrics and error‐severity categories is presented. The focus of the study is to identify threshold values of software metrics using receiver operating characteristic curves. The study used the three releases of the Eclipse project and found threshold values for some OO metrics that separated no‐error classes from classes that had high‐impact errors. Although these thresholds cannot predict whether a class will definitely have errors in the future, they can provide a more scientific method to assess class error proneness and can be used by engineers easily. Copyright © 2009 John Wiley & Sons, Ltd.

Object-oriented metrics have been validated empirically as measures of design complexity. These metrics can be used to mitigate potential problems in the software complexity. However, there are few studies that were conducted to formulate the guidelines, represented as threshold values, to interpret the complexity of the software design using metrics. Classes can be clustered into low and high risk levels using threshold values. In this paper, we use a statistical model, derived from the logistic regression, to identify threshold values for the Chidamber and Kemerer (CK) metrics. The methodology is validated empirically on a large open-source system-the Eclipse project. The empirical results indicate that the CK metrics have threshold effects at various risk levels. We have validated the use of these thresholds on the next release of the Eclipse project-Version 2.1-using decision trees. In addition, the selected threshold values were more accurate than those were selected based on either intuitive perspectives or on data distribution parameters. Furthermore, the proposed model can be exploited to find the risk level for an arbitrary threshold value. These findings suggest that there is a relationship between risk levels and object-oriented metrics and that risk levels can be used to identify threshold effects.