Abstract
The benefits of software reuse have been studied for many years. Several previous studies have observed that reused software has a lower defect density than newly built software. However, few studies have investigated empirically the reasons for this phenomenon. To date, we have only the common sense observation that as software is reused over time, the fixed defects will accumulate and will result in high-quality software. This paper reports on an industrial case study in a large Norwegian Oil and Gas company, involving a reused Java class framework and two applications that use that framework. We analyzed all trouble reports from the use of the framework and the applications according to the Orthogonal Defect Classification (ODC), followed by a qualitative Root Cause Analysis (RCA). The results reveal that the framework has a much lower defect density in total than one application and a slightly higher defect density than the other. In addition, the defect densities of the most severe defects of the reused framework are similar to those of the applications that are reusing it. The results of the ODC and RCA analyses reveal that systematic reuse (i.e. clearly defined and stable requirements, better design, hesitance to change, and solid testing) lead to lower defect densities of the functional-type defects in the reused framework than in applications that are reusing it. However, the different “nature” of the framework and the applications (e.g. interaction with other software, number and complexity of business logic, and functionality of the software) may confound the causal relationship between systematic reuse and the lower defect density of the reused software. Using the results of the study as a basis, we present an improved overall cause–effect model between systematic reuse and lower defect density that will facilitate further studies and implementations of software reuse.
This is a preview of subscription content, log in via an institution to check access.
Similar content being viewed by others
References
Baldassarre MT et al (2005) An industrial case study on reuse oriented development. In: Proceedings of the International Conference on Software Maintenance. IEEE Computer Society, Budapest, Hungary, pp 283–292
Briand LC et al (1998) Quality assurance technologies for the EURO Convention—Industrial Experience at Allianz Life Assurance. In: Proceedings of International Software Quality Week Europe. Communications of the ACM, Brussels, Belgium, pp 1–23
Card DN (1998) Learning from our mistakes with defect causal analysis. IEEE Softw 15(1):56–63
Chillarege R et al (1992) Orthogonal defect classification—a concept for in-process measurements. IEEE Trans Softw Eng 18(1):943–956
Emam KE, Wieczorek I (1998) The repeatability of code defect classifications. In: Proceedings of International Symposium on Software Reliability Engineering. IEEE Computer Society, Paderborn, Germany, pp 322–333
Fenton NE et al (2000) Quantitative analysis of faults and failures in a complex software system. IEEE Trans Softw Eng 26(8):797–814
Frakes WB et al (2001) An industrial study of reuse, quality, and productivity. J Syst Softw 57(2):99–106
Freimut B (2001) Developing and using defect classification schemes. IESE report no. 0720.01/E
Grady RB (1992) Practical software metrics for project management and process improvement. Prentice Hall, New York
Huber JT (2000) A comparison of IBM’s orthogonal defect classification to Hewlett Packard’s defect origins, types and modes. In: Proceedings of International Conference on Applications of Software Measurement. San Jose, CA, pp 1–17. http://www.stickyminds.com/stickyfile.asp?i=1764291&j=52901&ext=.pdf. Accessed May 2008
IBM (2008) ODC classification. Available via IBM’s website. http://www.research.ibm.com/softeng/ODC/ODC.HTM. Accessed June 2006 and January 2008.
IEEE (1994) IEEE standard 1044-1993. IEEE standard classification for software anomalies. IEEE
Leszak M et al (2000) A case study in root cause defect analysis. In: Proceedings of the International Conference on Software Engineering. IEEE Computer Society, Limerick Ireland, pp 428–437
Lim WC (1994) Effect of reuse on quality, productivity and economics. IEEE Softw 11(5):23–30
Mohagheghi P et al (2004) An empirical study of software reuse vs. defect density and stability. In: Proceedings of the International Conference on Software Engineering. IEEE Computer Society, Edinburgh, Scotland, pp 282–291
Mohagheghi P et al (2007) Quality, productivity and economic benefits of software reuse: a review of industrial studies. J Empir Softw Eng 12(5):471–516
Morad S et al (2005) Conventional and open source software reuse at Orbotech—an industrial experience. In: Proceedings of the International Conference on Software—Science, Technology & Engineering. IEEE Computer Society, Herzliyah, Israel, pp 110–117
Morisio M et al (2002) Success and failures in software reuse. IEEE Trans Softw Eng 28(4):340–357
Rothenberger MA et al (2003) Strategies for software reuse: a principal component analysis of reuse practices. IEEE Trans Softw Eng 29(9):825–837
Selby W (2005) Enabling reuse-based software development of large-scale systems. IEEE Trans Softw Eng 31(6):495–510
SEVO (2004) Software evolution in component-based software engineering. http://www.idi.ntnu.no/grupper/su/sevo/. Accessed June 2006.
Sindre G et al (1995) The REBOOT approach to software reuse. J Syst Softw 30(3):201–212
Succi G et al (2001) Analysis of the effects of software reuse on customer satisfaction in an RPG environment. IEEE Trans Softw Eng 27(5):473–479
Thomas WM et al (1997) An analysis of errors in a reuse-oriented development environment. J Syst Softw 38(3):211–224
Wohlin C, Runeson P, Höst M, Ohlsson MC, Regnell B, Wesslén A (2000) Experimentation in software engineering—an introduction. Kluwer, Dordrecht
Zhang W et al (2005) Reuse without compromising performance: industrial experience from RPG software product line for mobile devices. In: Proceedings of the International Software Product Line Conference. IEEE Computer Society, Rennes, France, pp. 57–69
Zheng J et al (2006) On the value of static analysis for fault detection in software. IEEE Trans Softw Eng 32(4):240–253
Acknowledgements
This work was financed in part by the Norwegian Research Council for the SEVO (Software EVOlution in Component-Based Software Engineering) project (SEVO 2004) with contract number 159916/V30. We thank StatoilHydro ASA for involving us in their reuse projects and Dr. Parastoo Mohagheghi and Thor André Aresvik for valuable comments.
Author information
Authors and Affiliations
Corresponding author
Additional information
Editor:
Katsuro Inoue
Appendices
Appendix A: Defect Classification Schemes and Definitions of Defect Types
A defect classification scheme is used to characterize the nature of defects. There are three major schemes for classifying defects: the IEEE 1044 standard (IEEE 1994), the Hewlett-Packard (HP) Scheme (Grady 1992), and IBM’s Orthogonal Defect Classification (ODC) scheme (Chillarege et al. 1992). The IEEE scheme provides too many attributes and classifications (more than 140), and in too much detail, to be used effectively in practice. The HP scheme includes attributes for defining the origin, type, and mode. The goal of the HP scheme is to initiate the improvement of processes and the early detection of defects. However, it lacks an attribute to define what the user will experience, if the defect persists after the application has been deployed at the user’s site. The goal of IBM’s ODC scheme is to associate each defect type with a specific stage of development. It is more suitable to use the ODC scheme than the HP scheme when the primary objective is to examine closely trends regarding defects throughout the lifecycle of the project (Huber 2000). While all ODC attributes capture the semantics of a defect (Chillarege et al. 1992), the attributes “defect type, trigger, and impact” play a crucial role in the scheme. Detailed explanations of each attribute value may be found at (IBM 2008; Emam and Wieczorek 1998). ODC has been employed to obtain a first overview of the defects. For example, Briand et al. (1998) classified the defects found in newly introduced inspections according to the impact attribute of ODC in order to characterize the defects found in terms of their visibility to the user. ODC can also be used to evaluate and improve technology. For example, in order to investigate the value of automatic static analysis, the defects found by the static analysis and those not found by this technique can be classified (Zheng et al. 2006).
Emam and Wieczorek (1998) indicate that the use of ODC is, in general, repeatable in many areas of software engineering, although there is no alignment between the Target (which represents the identity of the work product where the fix was implemented) and the type of defect (Huber 2000).
A few studies indicate that ODC can be adapted in minor ways according to project contexts (Emam and Wieczorek 1998; Freimut 2001). In our study, we ran a trial classification on the defects using ODC and found that some defects cannot be classified by classical ODC (Emam and Wieczorek 1998). Thus, we added two defect types, namely GUI-type and data-type. The definitions of the types of defect used in our study are shown in Table 8.
Appendix B: Definitions of Impacts
In this study, we used the definition of impacts of the classical ODC (Emam and Wieczorek 1998), as shown in Table 9.
Rights and permissions
About this article
Cite this article
Gupta, A., Li, J., Conradi, R. et al. A case study comparing defect profiles of a reused framework and of applications reusing it. Empir Software Eng 14, 227–255 (2009). https://doi.org/10.1007/s10664-008-9081-9
Published:
Issue Date:
DOI: https://doi.org/10.1007/s10664-008-9081-9