Predicting Fault Incidence Using Software Change History

By T. Graves, Alan F. Karr, James Stephen Marron, Harvey P. Siy. IEEE Trans. Software Eng., 2000

831 citations recorded by the source corpus.

Subfields: Artificial Intelligence, Information Systems, Software

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

How researchers see this paper

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

In Artificial Intelligence

In Information Systems

In Software

Citations in the corpus

An empirical study of the impact of modern code review practices on software quality (2015, methodology): “However, we feel that our baseline metrics are strong, having been derived from the defect prediction literature (Koru et al. , 2009; Menzies et al. , 2002; Graves et al. , 2000; Nagappan and Ball, 2005, 2007; Hassan, 2009; Bird et al. , 2011).”
Evaluating defect prediction approaches: a benchmark and an extensive comparison (2011, methodology): “…has been refactored NFIX Number of times a file was involved in bug-fixing NAUTH Number of authors who committed the file LINES Lines added and removed (sum, max, average) CHURN Codechurn (sum, maximum and average) Codechurn is computed as R (addedLOC − deletedLOC), where R is the set of all…”
The road ahead for Mining Software Repositories (2008, methodology): “[22] on a commercial system and by Herraiz et al.”
Evaluating Complexity, Code Churn, and Developer Activity Metrics as Indicators of Software Vulnerabilities (2011, background): “Each new change in the system brings a new risk of introducing a vulnerability [15], [19].”
The influence of organizational structure on software quality (2008, methodology): “The intersection of people [9], processes [29] and organization [33] and the area of identifying problem prone components early in the development process using software metrics (e.g. [13] [24] [28] [30]) has been studied extensively in recent years.”
Predicting risk of software changes (2000, background): “Yu, Shen, and Dunsmore(11) and Graves et al.(12) use defect history to predict faults, and Basili and Perricone(3) compare new code units with those that borrow code from other places.”
A Survey on Software Clone Detection Research (2007, background): “Introduction of new bugs can be avoided in critical system functionality by keeping the critical piece of code untouched [97].”
A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction (2008, background): “[6], Nagappan and Ball [16], and Ostrand et al.”
An extensive comparison of bug prediction approaches (2010, background): “showed that the best generalized linear models for defect prediction are based on number of changes [26], we isolate the number of revisions as a predictive variable.”
A large-scale empirical study of just-in-time quality assurance (2013, methodology): “Prior work used product metrics such as McCabe’s cyclomatic complexity metric [33] and the Chidamber and Kemerer (CK) metrics suite [9] and code size (measured in lines of code) [1], [12], [15], [21], [29].”
Predicting the location and number of faults in large software systems (2005, methodology): “Results along these lines can be found in [1], [2], [3], [4], [5], [6], [7], [10], [11], [12], [15], among others.”
Cross-project defect prediction: a large scale experiment on data vs. domain vs. process (2009, background): “There is an extensive body of knowledge on the metrics discussed above when used for predicting quality [12, 13, 19, 22, 28, 29].”
Automatic mining of source code repositories to improve bug finding techniques (2005, positive): “They posit that data based on change history is more useful in predicting fault rates than metrics based on the code, such as size [14].”
Software fault prediction metrics: A systematic literature review (2013, methodology): “The study is concluded in Section 5.”
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 with many unique authors likely lack strong ownership, which in turn may lead to more defects [5, 11].”