Analysis of effort estimation based on software project models
ISCIT'09 Proceedings of the 9th international conference on Communications and information technologies
Defect prediction from static code features: current results, limitations, new approaches
Automated Software Engineering
Testing the theory of relative defect proneness for closed-source software
Empirical Software Engineering
Usage of multiple prediction models based on defect categories
Proceedings of the 6th International Conference on Predictive Models in Software Engineering
An analysis of developer metrics for fault prediction
Proceedings of the 6th International Conference on Predictive Models in Software Engineering
An industrial case study of classifier ensembles for locating software defects
Software Quality Control
An in-depth study of the potentially confounding effect of class size in fault prediction
ACM Transactions on Software Engineering and Methodology (TOSEM)
Hi-index | 0.01 |
The importance of the relationship between size and defect proneness of software modules is well recognized. Understanding the nature of that relationship can facilitate various development decisions related to prioritization of quality assurance activities. Overall, the previous research only drew a general conclusion that there was a monotonically increasing relationship between module size and defect proneness. In this study, we analyzed class-level size and defect data in order to increase our understanding of this crucial relationship. In order to obtain validated and more generalizable results, we studied four large-scale object-oriented products, Mozilla, Cn3d, JBoss, and Eclipse. Our results consistently revealed a significant effect of size on defect proneness; however, contrary to common intuition, the size-defect relationship took a logarithmic form, indicating that smaller classes were proportionally more problematic than larger classes. Therefore, practitioners should consider giving higher priority to smaller modules when planning focused quality assurance activities with limited resources. For example, in Mozilla and Eclipse, an inspection strategy investing 80% of available resources on 100-LOC classes and the rest on 1,000-LOC classes would be more than twice as cost effective as the opposite strategy. These results should be immediately useful to guide focused quality assurance activities in large-scale software projects.