Predicting faults using the complexity of code changes

By Ahmed E. Hassan. 2009 IEEE 31st International Conference on Software Engineering, 2009

722 citations recorded by the source corpus.

Subfields: Computer Science Applications, Information Systems, Software

View Paper: https://www.semanticscholar.org/paper/30ea1d7526f120b1275e045f4318e9fb57cc73de

How researchers see this paper

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

In Computer Science Applications

In Information Systems

In Software

Citations in the corpus

A large-scale empirical study of just-in-time quality assurance (2013, methodology): “Other work uses process metrics to predict defect-prone locations [15], [19], [43], [44], [46].”
The Impact of Class Rebalancing Techniques on the Performance and Interpretation of Defect Prediction Models (2018, neutral): “First, defect prediction models can be used to predict modules that are likely to be defect-prone in the future [1], [2], [3], [4], [5], [6], [7], [8], [9].”
Deep Learning for Just-in-Time Defect Prediction (2015, positive): “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”
Evaluating defect prediction approaches: a benchmark and an extensive comparison (2011, methodology): “ Hassan (2009) introduced the concept of entropy of changes, a measure of the complexity of code changes.”
How, and why, process metrics are better (2013, methodology): “We also used a simple line based change entropy metric [8], derived from the location of the changes made: SCTR measures the scattering of changes to a file; scattered changes could be more complex to manage, and thus more likely to induce defects.”
Automatically Learning Semantic Features for Defect Prediction (2016, methodology): “Software defect prediction techniques [12,18,20,23,27,32, 38, 40, 52, 62, 70] have been proposed to detect defects and reduce software development costs.”
Using complexity, coupling, and cohesion metrics as early indicators of vulnerabilities (2011, background): “entities that are being modified frequently and/or recently are likely to have faults [ 30 ].”
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).”
Software Defect Prediction via Convolutional Neural Network (2017, methodology): “[31] used entropy of change features in predicting defect.”
Revisiting the Impact of Classification Techniques on the Performance of Defect Prediction Models (2015, methodology): “, Chidamber and Kemerer (CK) metrics [9]), process metrics [3, 24, 40, 42] (e.”
RCLinker: Automated Linking of Issue Reports and Commits Leveraging Rich Contextual Information (2015, positive): “, the number of defects that affect various classes in a project during its life-time), which can, in turn, be used to build effective bug prediction solutions [24], [7], [43], [28], [41], [63], [21].”
The impact of code review coverage and code review participation on software quality: a case study of the qt, VTK, and ITK projects (2014, methodology): “Change entropy measures how the complexity of a change process is distributed across files [13].”
Transfer defect learning (2013, methodology): “In this paper, we apply a state-of-the-art transfer learning approach, TCA, to make feature distributions in source and target projects similar.”
An extensive comparison of bug prediction approaches (2010, background): “Hassan introduced the entropy of changes, a measure of the complexity of code changes [10].”
Learning to rank relevant files for bug reports using domain knowledge (2014, background): “…behaviors and build interaction patterns; Nagappan et al. [33] utilize the frequency of similar changes described as change burts ; Hassan et al. [15] use code change complexity; Zimmermann et al. [46] build a dependency graph that implies an error-proneness for (cid:12)les linked to buggy…”
Software fault prediction metrics: A systematic literature review (2013, background): “In contrast to source code metrics, process metrics were found to be useful in predicting post-release faults [100,107,58,73,85, 91,60,93,110,88,115,117,118].”
A Systematic Literature Review on Fault Prediction Performance in Software Engineering (2012, critical): “[[52]] The paper does not report the error rate of any of the models it presents.”
On the "Naturalness" of Buggy Code (2015, background): “survey and provide a direct comparison of a number of representative DP approaches (including those using process metrics, such as previous changes [34, 17] and defects [27], and product metrics, such as code complexity metrics [6]).”
Dealing with noise in defect prediction (2011, background): “Defect prediction is a very active area in software engineering research [7, 10, 11, 13, 18, 19, 33, 35].”