This Article 
 Bibliographic References 
 Add to: 
Predicting Fault-Prone Software Modules in Telephone Switches
December 1996 (vol. 22 no. 12)
pp. 886-894

Abstract—An empirical study was carried out at Ericsson Telecom AB to investigate the relationship between several design metrics and the number of function test failure reports associated with software modules. A tool, ERIMET, was developed to analyze the design documents automatically. Preliminary results from the study of 130 modules showed that: 1) based on fault and design data one can satisfactorily build, before coding has started, a prediction model for identifying the most fault-prone modules. The data analyzed show that 20 percent of the most fault-prone modules account for 60 percent of all faults. The prediction model built in this paper would have identified 20 percent of the modules accounting for 47 percent of all faults; 2) at least four design measures can alternatively be used as predictors with equivalent performance; 3) size (with respect to the number of lines of code) used in a previous prediction model was not significantly better than these four measures; and 4) the Alberg diagram introduced in this paper offers a way of assessing a predictor based on historical data, which is a valuable complement to linear regression when prediction data is ordinal. Applying the method described in this paper makes it possible to use measures at the design phase to predict the most fault-prone modules.

[1] H. Alberg, Ö. Johansson, and N. Ohlsson, "Predicting Error-Prone Software Modules," Nordic Telecom Seminar,Stockholm, 1993.
[2] D.M. Bates and D.G. Watts, "Nonlinear Regression Analysis and Its Applications,"New York: John Wiley&Sons, 1988.
[3] B. Bergman and B. Klefsjö, Kvalitet, från behov till användning, Studentlitteratur, Lund, 1991.
[4] N.E. Fenton, Software Metrics, A Rigorous Approach. Chapman&Hall, 1991.
[5] N.E. Fenton, S. Lawrence Pfleeger, and R. Glass, “Science and Substance: A Challenge to Software Engineers,” IEEE Software, vol. 11, no. 4, pp. 86–95, July 1994.
[6] N.E. Fenton, M. Neil, and G. Ostrolenk, "Metrics and Models for Predicting Software Defects," Technical Report CSR/10/02, Centre for Software Reliability, City Univ., London, 1995.
[7] U. Heitkoetter, B. Helling, H. Nolte, and M. Kelly, "Design Metrics and Aids to their Automatic collection," Information and Software Technology, vol. 32, pp. 79-87, Jan. 1990.
[8] D.C. Howell, Statistical Methods for Psychology, second edition. Boston: Duxbury Press, 1987.
[9] D. Ince and M. Sheppard, "System Design Metrics: A Review and Perspective," Proc. IEE/BCS Conf. Software Eng. '88, Liverpool Univ., pp. 23-27, July 1988.
[10] J.M. Juran, Managerial Breakthrough.New York: McGraw-Hill, 1968.
[11] J. Kajihara, G. Amamiya, and T. Saya, "Learning from Bugs," IEEE Software, vol. 10, pp. 46-54, Sept. 1993.
[12] F.N. Kerlinger, Foundations of Behavioural Research, third edition. New York: Holt, Rinehart, and Winstone, 1988.
[13] B.A. Kitchenham and P.G. Petersen, "The Development of a Software Quality Model," Seminaire E:O:Q:C sur la Qualite des Logiciels,Brussels, pp. 26-27, Apr. 1988.
[14] T.M. Khoshgoftaar and J.C. Munson, “Predicting Software Development Errors Using Complexity Metrics,” J. Selected Areas Comm., vol. 8, no. 2, pp. 253–261, Feb. 1990.
[15] B. Lennselius, "Software Complexity and Its Impact on Different Software Handling Processes," Proc. Sixth Int'l Conf. Software Eng. and Telecommunications Switching Systems, pp. 148-153, 1986.
[16] B. Lennselius and C. Vrana, "Complexity in the SDL-Graph-Description and Impact on Different Handling Activities," Proc. Second SDL-Users and Implementors Forum,Helsinki, Finland, 1985.
[17] T.J. McCabe, "A Complexity Measure," IEEE Trans. Software Eng., vol. 2, pp. 308-320, Dec. 1976.
[18] F. Mosteller and J.W. Tukey, Data Analysis and Regression.Reading Mass.: Addison-Wesley, 1977.
[19] J.C. Munson and T.M. Khoshgoftaar, "The Detection of Fault-Prone Programs," IEEE Trans. Software Eng., vol. 18, May 1992.
[20] J.D. Musa, "Operational Profiles in Software Reliability Engineering," IEEE Software, vol. 10, no. 2, pp. 14-32, 1993.
[21] G. Myers,Software Reliability; Principles and Practices. New York: Wiley, 1976.
[22] N. Ohlsson, "Predicting Error-Prone Software Modules in Telephone Switches," Industriserien, Dept. of Computer and Information Science, Linköping Univ., Sweden, 1993.
[23] N. Ohlsson, M. Helander, and C. Wohlin, "Quality Improvement by Identification of Fault-Prone Modules Using Software Design Metrics," Proc. Sixth Int'l Conf. Software Quality, pp. 1-13,Ottawa, Oct. 1996.
[24] D. Patridge and N.E. Sharkey, "Neural Computing for Software Reliability," Expert Systems, vol. 11, pp. 167-175, Oct. 1994.
[25] A. Porter and R. Selby, "Empirically Guided Software Development Using Metric-Based Classification Trees," IEEE Software, no. 7, pp. 46-54, 1990.
[26] D.H. Rombach, "Design Measurement: Some Lessons Learned," IEEE Software, vol. 7, no. 2, pp. 17-25, Mar. 1990.
[27] M. Shepperd and D. Ince, "Design Metrics and Software Maintainability: An Experimental Investigation," Software Maintenance; Research and Practice, vol. 3, pp. 215-232, 1991.
[28] M. Shepperd, "Design Metrics: An Empirical Analysis," Software Engineering J., vol. 5, pp. 3-10, 1990.
[29] Martin Shepperd, "A Critique of Cyclomatic Complexity as a Software Metric," Software Eng. J., vol. 3, p. 35, Mar. 1988.
[30] Using Formal Description Techniques: An Introduction to Estelle, Lotos, and SDL, K.J. Turner, ed., John Wiley&Sons, 1993.
[31] E. Yourdon, Decline and Fall of the American Programmer.Englewood Cliffs, N.J.: Prentice Hall, 1992.
[32] H. Zuse,Software Complexity.Berlin: Walter de Gruyter, 1991.

Index Terms:
Complexity, empirical study, fault-prone modules, metrics, prediction, software measurement, regression analysis, software reliability, statistical analysis.
Niclas Ohlsson, Hans Alberg, "Predicting Fault-Prone Software Modules in Telephone Switches," IEEE Transactions on Software Engineering, vol. 22, no. 12, pp. 886-894, Dec. 1996, doi:10.1109/32.553637
Usage of this product signifies your acceptance of the Terms of Use.