Use of relative code churn measures to predict system defect density

By N. Nagappan, Thomas Ball. Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005., 2005

911 citations recorded by the source corpus.

Subfields: Computer Networks and Communications, Information Systems, Software

View Paper: https://www.semanticscholar.org/paper/b65c215021f062ad66e1c5080d762f589b0dbbf4

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Computer Networks and Communications

In Information Systems

In Software

Citations in the corpus

Don't touch my code!: examining the effects of ownership on software quality (2011, background): “Thus it is not clear whether the increase in failures is attributable to more minor contributors or other measures such as size, complexity, and churn, which are known to be related to defects [25, 28] and are likely related to the number of minor contributors.”
Classifying Software Changes: Clean or Buggy? (2008, methodology): “problem, predicting the bug density of each module by using its software change history [11], [36].”
Evaluating Complexity, Code Churn, and Developer Activity Metrics as Indicators of Software Vulnerabilities (2011, background): “Software Eng., vol. 33, no. 1, pp. 2-13, 2007 [8] Nagappan, N., and Ball, T., "Using Software Dependencies and Churn Metrics to Predict Field Failures: An Empirical Case Study," Proc.”
An Empirical Comparison of Model Validation Techniques for Defect Prediction Models (2017, background): “In addition to the discrimination power, practitioners often use the predicted probabilities to rank the defectprone files [74], [79], [96], [122].”
Automatic Identification of Bug-Introducing Changes (2006, methodology): “This permits useful analysis, such as determining per-file bug counts, predicting bugs, finding risky parts of software [7] [13] [14], or visually revealing the relationship between bugs and software evolution [3].”
On the "Naturalness" of Buggy Code (2015, methodology): “DP is typically used at release-time to predict post-release bugs [35, 57, 42, 36, 11]; so, for this comparison we use the post release bug data collected in Phase-II.”
Predicting Defects for Eclipse (2007, background): “Nagappan and Ball [11] showed that relative code churn predicts software defect density; (absolute) code churn is the number of lines added or deleted between versions.”
Deep Learning for Just-in-Time Defect Prediction (2015, neutral): “Name Description NS The number of modified subsystems [19] ND The number of modified directories [19] NF The number of modified files [20] Entropy Distribution of modified code across each file [21] LA Lines of code added [22] LD Lines of code deleted [22] LT Lines of code in a file before the chang”
Predicting defects using network analysis on dependency graphs (2008, background): “Other effective predictors include code complexity metrics [35] and process metrics like code churn [32].”
Evaluating defect prediction approaches: a benchmark and an extensive comparison (2011, background): “found that relative code churn is a better predictor than absolute churn ( Nagappan and Ball 2005b ).”
Mining metrics to predict component failures (2006, background): “4 Mining Software Repositories In recent years, researchers have learned to exploi t the vast amount of data that is contained in software reposi tories such as version and bug databases [16, 17, 19, 22].”
A systematic and comprehensive investigation of methods to build and evaluate fault prediction models (2010, background): “Nagappan and Ball, 2005; Graves et al., 2000) have included other measures like deltas of structural metrics between subsequent releases , or measures related to fault history and the software development process itself (process metrics).”
An empirical study of the impact of modern code review practices on software quality (2015, methodology): “a lot of change are likely defect-prone (Nagappan and Ball 2005; 2007).”
Predicting faults using the complexity of code changes (2009, background): “[22], and Nagappan and Ball [26] indicate that prior modifications to a file are a good predictor of its fault potential (i.”
An extensive comparison of bug prediction approaches (2010, background): “I. INTRODUCTION Defect prediction has generated widespread interest for a considerable period of time.”
A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction (2008, methodology): “Nagappan and Ball [16] applied successfully statistical regression methods for predicting software defect density using relative code churn.”
The impact of code review coverage and code review participation on software quality: a case study of the qt, VTK, and ITK projects (2014, background): “Components that have undergone a lot of change are likely defectprone [29, 30].”
An exploratory study of the pull-based software development model (2014, methodology): “There are various metrics to determine the size of a patch that have been used by researchers: code churn [24, 27], changed files [24] and number of commits [11].”
The influence of organizational structure on software quality (2008, background): “Nagappan and Ball [26] in a prior study on Windows Server 2003 showed the use of relative code churn measures (relative churn measures are normalized values of the various measures obtained during the evolution of the system) to predict defect density at strong statistically significant levels.”
Learning a Metric for Code Readability (2010, background): “A consensus exists that readability is an essential determining characteristic of code quality [1], [4], [8], [9], [10], [16], [31], [32], [33], [34], [35], [41] , but not about which factors contribute to human notions of software readability the most.”