Practical considerations in deploying statistical methods for defect prediction: A case study within the Turkish telecommunications industry

Aye Tosun*, Aye Bener, Burak Turhan, Tim Menzies

*Corresponding author for this work

Research output: Contribution to journalArticlepeer-review

66 Citations (Scopus)

Abstract

Context: Building defect prediction models in large organizations has many challenges due to limited resources and tight schedules in the software development lifecycle. It is not easy to collect data, utilize any type of algorithm and build a permanent model at once. We have conducted a study in a large telecommunications company in Turkey to employ a software measurement program and to predict pre-release defects. Based on our prior publication, we have shared our experience in terms of the project steps (i.e. challenges and opportunities). We have further introduced new techniques that improve our earlier results. Objective: In our previous work, we have built similar predictors using data representative for US software development. Our task here was to check if those predictors were specific solely to US organizations or to a broader class of software. Method: We have presented our approach and results in the form of an experience report. Specifically, we have made use of different techniques for improving the information content of the software data and the performance of a Naïve Bayes classifier in the prediction model that is locally tuned for the company. We have increased the information content of the software data by using module dependency data and improved the performance by adjusting the hyper-parameter (decision threshold) of the Naïve Bayes classifier. We have reported and discussed our results in terms of defect detection rates and false alarms. We also carried out a cost-benefit analysis to show that our approach can be efficiently put into practice. Results: Our general result is that general defect predictors, which exist across a wide range of software (in both US and Turkish organizations), are present. Our specific results indicate that concerning the organization subject to this study, the use of version history information along with code metrics decreased false alarms by 22%, the use of dependencies between modules further reduced false alarms by 8%, and the decision threshold optimization for the Naïve Bayes classifier using code metrics and version history information further improved false alarms by 30% in comparison to a prediction using only code metrics and a default decision threshold. Conclusion: Implementing statistical techniques and machine learning on a real life scenario is a difficult yet possible task. Using simple statistical and algorithmic techniques produces an average detection rate of 88%. Although using dependency data improves our results, it is difficult to collect and analyze such data in general. Therefore, we would recommend optimizing the hyper-parameter of the proposed technique, Naïve Bayes, to calibrate the defect prediction model rather than employing more complex classifiers. We also recommend that researchers who explore statistical and algorithmic methods for defect prediction should spend less time on their algorithms and more time on studying the pragmatic considerations of large organizations.

Original languageEnglish
Pages (from-to)1242-1257
Number of pages16
JournalInformation and Software Technology
Volume52
Issue number11
DOIs
Publication statusPublished - Nov 2010
Externally publishedYes

Funding

This research is supported in part by Turkish Scientific Research Council , TUBITAK, under Grant Number EEEAG108E014 , and Turkcell A.Ş.

FundersFunder number
TUBITAKEEEAG108E014
Turkish Scientific Research Council

    Keywords

    • Experience report
    • Naïve Bayes
    • Software defect prediction
    • Static code attributes

    Fingerprint

    Dive into the research topics of 'Practical considerations in deploying statistical methods for defect prediction: A case study within the Turkish telecommunications industry'. Together they form a unique fingerprint.

    Cite this