Component-based software engineering has an intuitive appeal. In theory, it should provide a software organization with advantages in quali...
Component-based software engineering has an intuitive appeal. In theory, it should provide a software organization with advantages in quality and timeliness. And these should translate into cost savings. But are there hard data that support our intuition? To answer this question we must first understand what actually can be reused in a software engineering context and then what the costs associated with reuse really are. As a consequence, it is possible to develop a cost/benefit analysis for component reuse.
Impact on Quality, Productivity, and Cost
Considerable evidence from industry case studies indicates substantial business benefits can be derived from aggressive software reuse. Product quality, development productivity, and overall cost are all improved.
Quality. In an ideal setting, a software component that is developed for reuse would be verified to be correct and would contain no defects. In reality, formal verification is not carried out routinely, and defects can and do occur. However, with each reuse, defects are found and eliminated, and a component’s quality improves as a result. Over time, the component becomes virtually defect free.
In a study conducted at Hewlett Packard, Lim [LIM94] reports that the defect rate for reused code is 0.9 defects per KLOC, while the rate for newly developed software is 4.1 defects per KLOC. For an application that was composed of 68 percent reused code, the defect rate was 2.0 defects per KLOC—a 51 percent improvement from the expected rate, had the application been developed without reuse. Henry and Faller report a 35 percent improvement in quality. Although anecdotal reports span a reasonably wide spectrum of quality improvement percentages, it is fair to state that reuse provides a nontrivial benefit in terms of the quality and reliability for delivered software.
Productivity. When reusable components are applied throughout the software process, less time is spent creating the plans, models, documents, code, and data that are required to create a deliverable system. It follows that the same level of functionality is delivered to the customer with less input effort. Hence, productivity is improved. Although percentage productivity improvement reports are notoriously difficult to interpret, it appears that 30 to 50 percent reuse can result in productivity improvements in the 25–40 percent range.
Cost. The net cost savings for reuse are estimated by projecting the cost of the project if it were developed from scratch, Cs, and then subtracting the sum of the costs associated with reuse, Cr, and the actual cost of the software as delivered, Cd. Cs can be determined by applying one or more of the estimation techniques The costs associated with reuse, Cr, include
• Domain analysis and modeling.
• Domain architecture development.
• Increased documentation to facilitate reuse.
• Support and enhancement of reuse components.
• Royalties and licenses for externally acquired components.
• Creation or acquisition and operation of a reuse repository.
• Training of personnel in design and construction for reuse.
Although costs associated with domain analysis and the operation of a reuse repository can be substantial, many of the other costs noted here address issues that are part of good software engineering practice, whether or not reuse is a priority.
Cost Analysis Using Structure Points
We defined a structure point as an architectural pattern that recurs throughout a particular application domain. A software designer (or system engineer) can develop an architecture for a new application, system, or product by defining a domain architecture and then populating it with structure points. These structure points are either individual reusable components or packages of reusable components.
Even though structure points are reusable, their qualification, adaptation, integration, and maintenance costs are nontrivial. Before proceeding with reuse, the project manager must understand the costs associated with the use of structure points.
Since all structure points (and reusable components in general) have a past history, cost data can be collected for each. In an ideal setting, the qualification, adaptation, integration, and maintenance costs associated with each component in a reuse library is maintained for each instance of usage. These data can then be analyzed to develop projected costs for the next instance of reuse.
As an example, consider a new application, X, that requires 60 percent new code and the reuse of three structure points, SP1, SP2, and SP3. Each of these reusable components has been used in a number of other applications and average costs for qualification, adaptation, integration, and maintenance are available.
To estimate the effort required to deliver X, the following must be determined:
overall effort = Enew + Equal + Eadapt + Eint
where
Enew = effort required to engineer and construct new software components.
Equal = effort required to qualify SP1, SP2, and SP3.
Eadapt = effort required to adapt SP1, SP2, and SP3.
Eint = effort required to integrate SP1, SP2, and SP3.
The effort required to qualify, adapt, and integrate SP1, SP2, and SP3 is determined by taking the average of historical data collected for qualification, adaptation, and integration of the reusable components in other applications.
Reuse Metrics
A variety of software metrics have been developed in an attempt to measure the benefits of reuse within a computer-based system. The benefit associated with reuse within a system S can be expressed as a ratio
Rb(S) = [Cnoreuse – Creuse]/Cnoreuse
where
Cnoreuse is the cost of developing S with no reuse.
Creuse is the cost of developing S with reuse.
Cnoreuse is the cost of developing S with no reuse.
Creuse is the cost of developing S with reuse.
It follows that Rb(S) can be expressed as a nondimensional value in the range
0 ≤ Rb(S) ≤ 1
Devanbu and his colleagues suggest that (1) Rb will be affected by the design of the system; (2) since Rb is affected by the design, it is important to make Rb a part of an assessment of design alternatives; and (3) the benefits associated with reuse are closely aligned to the cost benefit of each individual reusable component.
A general measure of reuse in object-oriented systems, termed reuse leverage , is defined as
Rlev = OBJreused/OBJbuilt
where
OBJreused is the number of objects reused in a system.
OBJbuilt is the number of objects built for a system.
