A case study comparing defect profiles of a reused framework and of applications reusing it

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.

Comparing Reuse Strategies in Different Development Environments

“…One study on CB reuse reported on an industrial case study in a large Norwegian Oil and Gas company, involving a reused Java class framework and two applications. It analyzes reasons for differences in defect profiles [77]. The other involved research performed by the National Aeronautics and Space Administration (NASA) Earth Science Data Systems (ESDS) Software Reuse Working Group (WG) that was "established in 2004 to promote the reuse of software and related artifacts among members of the ESDS data product and software development community."…”

Establishing a Defect Management Process Model for Software Quality Improvement

“…Unimportant defects are also no different than critical defects. It's a developer best fortune that prevents a defect to cause a major failure [1]. Even the minor defects in the software create an opportunity for the developer to learn and improve the process by preventing potential major failures.…”

“…Even the minor defects in the software create an opportunity for the developer to learn and improve the process by preventing potential major failures. Defect remains in the whole life of software the defect itself might not be a big problem; but the reality that there was a defect is a big problem [1].…”

“…A defect is a flaw, deficiency or inaccuracy in the software product [1]. Defect remains in the whole life of software; each defect which occurs in the software stages is the defect in that software.…”

“…Fault: wrong or incorrect action taking to solve the problem. Failure: inability of a software work product function to meet the anticipated requirements [1].…”