An analysis of developer metrics for fault prediction

Matsumoto, Shinsuke; Kamei, Yasutaka; Monden, Akito; Matsumoto, Kenichi; Nakamura, Masahide

doi:10.1145/1868328.1868356

Cited by 97 publications

(57 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…They found that process metrics are better indicators of software quality than code metrics. Similar results have been found by other researchers who also used fault prediction as a quality indicators for their metrics, such as in [15,20]. D'Ambros et al [5] evaluated different sets of metrics in a thorough study on fault prediction.…”

Section: Related Worksupporting

confidence: 73%

“…Although they were originally defined to measure software artifact characteristics, such as the number of lines of code, the number of methods, etc., nowadays metrics are defined to measure developer's activity [19]. The main intuition of these metrics, also called process metrics, is that developers habits have a deeper impact on software quality than the intrinsic characteristics of software artifacts, as suggested by previous research [15,20].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Code ownership in open-source software

Foucault

Falleri

Blanc

2014

Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

Context: Ownership metrics measure how the workload of software modules is shared among their developers. They have been shown to be accurate indicators of software quality. Objective: Since ownership metrics studies were done only on industrial software projects, we replicated such a study on Java free/libre and open source software (FLOSS) projects. Our goal was to generalize an "ownership law" that stated that minor developers should be avoided. Method: We explored the relationship between ownership metrics and fault-proneness on seven FLOSS projects, using publicly available corpora to retrieve the fault-related information. Results: In our corpus, the relationship between ownership metrics and module faults is weak. At best, less than half of projects exhibit a significant correlation, and at worst, no projects at all. Moreover, fault-proneness seems to be much more influenced by module size than by ownership. Conclusion: The results of ownership studies done on closed-source projects do not generalize to FLOSS projects. To understand the reasons for that, we performed an in-depth analysis and found that the lack of correlation between ownership metrics and module faults is due to the distributions of contributions among developers and the presence of "heroes" in FLOSS projects.

show abstract

Section: Related Worksupporting

confidence: 73%

Section: Introductionmentioning

confidence: 99%

Code ownership in open-source software

Foucault

Falleri

Blanc

2014

Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

show abstract

“…Matsumoto et al [50] find that developer-related metrics are good distinguishing factors for defect prediction. Specifically, the modules that are touched by more developers contain more bugs.…”

Section: Related Workmentioning

confidence: 99%

Personalized defect prediction

Jiang

Tan

Kim

2013

2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE)

207

164

View full text Add to dashboard Cite

Abstract-Many defect prediction techniques have been proposed. While they often take the author of the code into consideration, none of these techniques build a separate prediction model for each developer. Different developers have different coding styles, commit frequencies, and experience levels, causing different defect patterns. When the defects of different developers are combined, such differences are obscured, hurting prediction performance.This paper proposes personalized defect prediction-building a separate prediction model for each developer to predict software defects. As a proof of concept, we apply our personalized defect prediction to classify defects at the file change level. We evaluate our personalized change classification technique on six large software projects written in C and Java-the Linux kernel, PostgreSQL, Xorg, Eclipse, Lucene and Jackrabbit. Our personalized approach can discover up to 155 more bugs than the traditional change classification (210 versus 55) if developers inspect the top 20% lines of code that are predicted buggy. In addition, our approach improves the F1-score by 0.01-0.06 compared to the traditional change classification.

show abstract

“…This provides a rough idea of the complexity of each feature and its fault propensity [38,43]. The size of a feature was calculated in terms of the number of Lines of Code (LoC).…”

Section: Non-functional Attributesmentioning

confidence: 99%

“…We collected the number of developers involved in the development of each Drupal feature. This could give us information about the scale and relevance of the feature as well as its propensity to faults related to the number of people working on it [43]. This information was obtained from the web site of each Drupal module as the number of committers involved [12].…”

Section: Non-functional Attributesmentioning

confidence: 99%

Variability testing in the wild: the Drupal case study

et al. 2015

View full text Add to dashboard Cite

Variability testing techniques search for effective and manageable test suites that lead to the rapid detection of faults in systems with high variability. Evaluating the effectiveness of these techniques in realistic settings is a must, but challenging due to the lack of variability intensive systems with available code, automated tests and fault reports. In this article, we propose using the Drupal framework as a case study to evaluate variability testing techniques. First, we represent the framework variability using a feature model. Then, we report on extensive non-functional data extracted from the Drupal Git repository and the Drupal issue tracking system. Among other results, we identified 3,392 faults in single features and 160 faults triggered by the interaction of up to 4 features in Drupal v7.23. We also found positive correlations relating the number of bugs in Drupal features to their size, cyclomatic complexity, number of changes and fault history. To show the feasibility of our work, we evaluated the effectiveness of non-functional data for test case prioritization in Drupal. Results show that non-functional attributes are effective at accelerating the detection of faults, outperforming related prioritization criteria as test case similarity.

show abstract

An analysis of developer metrics for fault prediction

Cited by 97 publications

References 22 publications

Code ownership in open-source software

Code ownership in open-source software

Personalized defect prediction

Variability testing in the wild: the Drupal case study

Contact Info

Product

Resources

About