Understanding the impact of code and process metrics on post-release defects

Abstract

Research studying the quality of software applications continues to grow rapidly with researchers building regression models that combine a large number of metrics. However, these models are hard to deploy in practice due to the cost associated with collecting all the needed metrics, the complexity of the models and the black box nature of the models. For example, techniques such as PCA merge a large number of metrics into composite metrics that are no longer easy to explain. In this paper, we use a statistical approach recently proposed by Cataldo et al. to create explainable regression models. A case study on the Eclipse open source project shows that only 4 out of the 34 code and process metrics impacts the likelihood of finding a post-release defect. In addition, our approach is able to quantify the impact of these metrics on the likelihood of finding post-release defects. Finally, we demonstrate that our simple models achieve comparable performance over more complex PCA-based models while providing practitioners with intuitive explanations for its predictions.

Are Bullies More Productive? Empirical Study of Affectiveness vs. Issue Fixing Time

“…We built a logistic regression model 16 for classifying the issue fixing time as short or long based on a set of independent variables characterising Jira issues [30]. The output of the logistic regression model, given the metric values of a particular issue, is the probability of the issue to be fixed in a short or long time.…”

“…Finally, we evaluated the impact of each metric in the model as shown in Figure 2, using the general approach proposed by Shihab et al [30]:…”

Method-level bug prediction

“…Therefore, it is possible that our work suffers from the bias opposed by characteristics of the development process unique to these communities. We selected these systems because they are relatively large, actively developed, and were extensively studied before [48,16,9,21,20,41], allowing us to contribute to an existing body of knowledge. In particular, Eclipse emerged to a "de facto standard" case study when analyzing opensource systems.…”

“…These metrics are rarely used in isolation but instead are often combined for building bug prediction models [2,41]. The goal is to either achieve (significantly) higher prediction results or to study which of the metrics are better predictors for bugs [9,33].…”

“…Since most prediction models were evaluated on different systems-and frequently with different performance measures-researchers have also investigated which approaches provide the best and most stable performance across different systems [24,30,41,9].…”