Art06

Software Reuse: Metrics and Models
WILLIAM FRAKES
Virginia Tech
and
CAROL TERRY
INCODE Corporation

As organizations implement systematic software reuse programs to improve
productivity and quality, they must be able to measure their progress and identify
the most effective reuse strategies. This is done with reuse metrics and models. In
this article we survey metrics and models of software reuse and reusability, and
provide a classification structure that will help users select them. Six types of
metrics and models are reviewed: cost-benefit models, maturity assessment models,
amount of reuse metrics, failure modes models, reusability assessment models, and
reuse library metrics.

Categories and Subject Descriptors: D.2.8 [Software Engineering]: Metrics;
D.2.m [Software Engineering]: Miscellaneous—reusable software; K.6.0
[Management of Computing and Information Systems]: General—economics;
K.6.4 [Management of Computing and Information Systems]: System
Management—quality assurance
General Terms: Economics, Measurement, Performance
Additional Key Words and Phrases: Cost-benefit analysis, maturity assessment,
reuse level, object-oriented, software reuse failure modes model, reusability
assessment, reuse library metrics, software, reuse, reusability, models, economics,
quality, productivity, definitions

1. INTRODUCTION Isoda 1994]. Organizations implement-
ing systematic software reuse programs
Software reuse, the use of existing soft- must be able to measure their progress
ware artifacts or knowledge to create and identify the most effective reuse
new software, is a key method for signif- strategies.
icantly improving software quality and In this article we survey metrics and
productivity. Reusability is the degree models of software reuse and reusabil-
to which a thing can be reused. To ity. A metric is a quantitative indicator
achieve significant payoffs a reuse pro- of an attribute of a thing. A model spec-
gram must be systematic [Frakes and ifies relationships among metrics. In

Authors’ addresses: W. Frakes, Virginia Tech, Computer Science Department, 2990 Telestar Court,
Falls Church, VA 20165; email: ͗frakes@sarvis.cs.vt.edu͘; C. Terry, INCODE Corp., 1100 S. Main St.,
Blacksburg VA 24060; email: ͗cterry@bev.net͘.
Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted
without fee provided that the copies are not made or distributed for profit or commercial advantage, the
copyright notice, the title of the publication, and its date appear, and notice is given that copying is by
permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to
lists, requires prior specific permission and / or a fee.
© 1996 ACM 0360-0300/96/0600–0415 $03.50

ACM Computing Surveys, Vol. 28, No. 2, June 1996

416 • W. Frakes and C. Terry

CONTENTS well as quality and productivity payoff.
Maturity assessment models categorize
reuse programs by how advanced they
are in implementing systematic reuse.
1. INTRODUCTION Amount of reuse metrics are used to as-
1.1 Types of Reuse sess and monitor a reuse improvement
2. COST BENEFIT ANALYSIS
2.1 Cost/Productivity Models
effort by tracking percentages of reuse for
2.2 Quality of Investment life cycle objects. Failure modes analysis
2.3 Business Reuse Metrics is used to identify and order the impedi-
2.4 Relation of Reuse to Quality and Productivity ments to reuse in a given organization.
3. MATURITY ASSESSMENT
3.1 Koltun and Hudson Reuse Maturity Model Reusability metrics indicate the likeli-
3.2 SPC Reuse Capability Model hood that an artifact is reusable. Reuse
4. AMOUNT OF REUSE library metrics are used to manage and
4.1 Reuse Level
4.2 Reuse Metrics for Object-Oriented Systems
track usage of a reuse repository. Organi-
4.3 Reuse Predictions for Life Cycle Objects zations often encounter the need for
5. SOFTWARE REUSE FAILURE MODES MODEL these metrics and models in the order
6. REUSABILITY ASSESSMENT presented.
7. REUSE LIBRARY METRICS
8. SUMMARY
Software reuse can apply to any life
APPENDIX 1: DEFINITIONS OF TYPES OF REUSE cycle product, not only to fragments of
REFERENCES source code. This means that developers
can pursue reuse of requirements docu-
ments, system specifications, design
structures, and any other development
Figure 1, reuse models and metrics are artifact [Barnes and Bollinger 1991].
categorized into types: (1) reuse cost- Jones [1993] identifies ten potentially
benefits models, (2) maturity assess- reusable aspects of software projects as
ment, (3) amount of reuse, (4) failure shown in Table 1.
modes, (5) reusability, and (6) reuse li- In addition to these life cycle prod-
brary metrics. Reuse cost-benefits models ucts, processes (such as the waterfall
include economic cost/benefit analysis as model of software development and the

Figure 1. Categorization of reuse metrics and models.


Software Reuse: Metrics and Models • 417

Table 1. Reusable Aspects of Software Projects

SEI capability maturity model), and 2. COST BENEFIT ANALYSIS
knowledge are also potentially reusable.
As organizations contemplate system-
atic software reuse, the first question
1.1 Types of Reuse that will arise will probably concern
Clear definitions of types of reuse are costs and benefits. Organizations will
necessary prerequisites to measure- need to justify the cost and time in-
ment. Table 2 provides a faceted classi- volved in systematic reuse by estimat-
fication of reuse definitions gathered ing these costs and potential payoffs.
from the literature. Each column speci- Cost benefit analysis models include
fies a facet, with the facet name in bold. economic cost-benefit models and qual-
Below each facet are its corresponding ity and productivity payoff analyses.
terms. (See Appendix 1 for detailed def- Several reuse cost-benefit models
initions of the terms in the table.) have been reported. None of these mod-
Terms in parentheses are synonyms. els are derived from data, nor have they
Development scope refers to whether the been validated with data. Instead, the
reusable components are from a source models allow a user to simulate the
external or internal to a project. Modifi- tradeoffs between important economic
cation refers to how much a reusable parameters such as cost and productiv-
asset is changed. Approach refers to dif- ity. These are estimated by setting arbi-
ferent technical methods for implement- trary values for cost and productivity
ing reuse. Domain scope refers to measures of systems without reuse, and
whether reuse occurs within a family of then estimating these parameters for
systems or between families of systems. systems with reuse. There is consider-
Management refers to the degree to able commonality among the models, as
which reuse is done systematically. Re- described in the following.
used entity refers to the type of the
reused object. 2.1 Cost/Productivity Models
Reuse in an organization can be de-
fined by selecting appropriate facet- Gaffney and Durek [1989] propose two
term pairs from this table. For example, cost and productivity models for soft-
an organization might choose to do both ware reuse. The simple model shows the
internal and external code reuse, allow- cost of reusing software components. The
ing only black box modification as part cost-of-development model builds upon
of a compositional approach. They the simple model by representing the cost
might choose to focus on reuse within of developing reusable components.
their domain (vertical) and to pursue a The simple model works as follows.
systematic management approach. Let C be the cost of software develop-
The following sections discuss in detail ment for a given product relative to all
each of the six types of reuse metrics and new code (for which C ϭ 1). R is the
models. proportion of reused code in the product



Table 2. Types of Software Reuse

(R Յ 1). (Note that R is a type of reuse The cost of development model in-
level; this topic is discussed in detail in cludes the cost of reusing software and
Section 4.) b is the cost relative to that the cost of developing reusable compo-
for all new code, of incorporating the nents as follows. Let E represent the
reused code into the new product ( b ϭ 1 cost of developing a reusable component
for all new code). The relative cost for relative to the cost of producing a com-
software development is: ponent that is not reusable. E is ex-
pected to be Ͼ1 because creating a com-
[(relative cost of all new code) ponent for reuse generally requires
extra effort. Let n be the number of uses
‫ ͑ ء‬proportion of new code ͒ ] over which the code development cost
will be amortized. The new value for C
ϩ ͓͑ relative cost of reused software) (cost) incorporates these measures:
‫ ͑ ء‬proportion of reused software͒ ]. C ϭ ͑ b ϩ ͑ E/n ͒ Ϫ 1 ͒ R ϩ 1 .
The equation for this is:
Other models help a user estimate the
C ϭ ͑ 1 ͒͑ 1 Ϫ R ͒ ϩ ͑ b ͒͑ R ͒ effect of reuse on software quality (num-
ber of errors) and on software develop-
ϭ ͓͑ b Ϫ 1 ͒ R ͔ ϩ 1 , ment schedules. Using reusable software
generally results in higher overall devel-
and the corresponding relative opment productivity; however, the costs
productivity is, of building reusable components must be
P ϭ 1/C ϭ 1/ ͑͑ b Ϫ 1 ͒ R ϩ 1 ͒ . recovered through many reuses. Some
empirical estimates of the relative cost of
b must be Ͻ 1 for reuse to be cost producing reusable components and for
effective. The size of b depends on the cost recovery via multiple reuses are dis-
life cycle phase of the reusable compo- cussed in the next section.
nent. If only the source code is reused, Applications of Cost/Productivity
then one must go through the require- Models. Margono and Rhoads [1993]
ments, design, and testing to complete applied the cost of development model
development of the reusable component. to assess the economic benefits of a re-
In this case, Gaffney and Durek esti- use effort on a large-scale Ada project
mate b ϭ 0.85. If requirements, design, (the United States Federal Aviation Ad-
and code are reused as well, then only ministration’s Advanced Automation
the testing phase must be done and b is System (FAA/AAS)). They applied the
estimated to be 0.08. model to various types of software cate-



Table 3. Barnes’ and Bollinger’s economic investment model

gorized by the source (local, commercial, listed in order of increasing complexity.
or public) and mode of reuse (reused (The quoted definitions are from Booch
with or without change). The equation for [1987].)
C in the reuse economics model was mod-
ified to reflect acquisition, development, Monolithic:
and integration costs. Results show that “Denotes that the structure is always
the cost of developing for reuse is often treated as a single unit and that its
twice the cost of developing an equivalent individual parts cannot be manipu-
nonreusable component. lated. Monolithic components do not
Favaro [1991] utilized the model from permit structural sharing; stack,
Barnes et al. [1988] to analyze the eco- string, queue, deque, ring, map, set,
nomics of reuse. (Note: the Barnes et al. and bag components are monolithic.”
[1988] model is the same as that of Polylithic:
Gaffney and Durek [1989].) The rele- “Denotes that the structure is not
vant variables and formulas are shown atomic and that its individual parts can
in Table 3. be manipulated. Polylithic components
Favaro’s research team estimated the permit structural sharing; lists, trees,
quantities R and b for an Ada-based and graph components are polylithic.”
development project. They found it diffi- Graph:
cult to estimate R because it was un- “A collection of nodes and arcs (which
clear whether to measure source code or are ordered pairs of nodes).”
relative size of the load modules. The Menu, mask:
parameter b was even more difficult End-products of the project. They were
to estimate because it was unclear developed as generalized, reusable com-
whether cost should be measured as the ponents and so were included in the
amount of real-time necessary to install study.
the component in the application and
whether the cost of learning should be Table 4 shows values reported by Fa-
included. varo for E, the relative cost of creating a
Favaro classified the Booch compo- reusable component, b, the integration
nents according to their relative com- cost of a reusable component, and N0,
plexity. The following categories are the payoff threshold value.



Table 4. Costs and payoff threshold values for reusable components [Favaro 1991]

The overall costs of reusable compo- producer activities and consumer activi-
nents relative to nonreusable compo- ties. Producer activities are reuse invest-
nents is E ϩ b. b is expected to be less ments, or costs incurred while making
than 1.0, since it should be cheaper to one or more work products easier to reuse
integrate a reusable component than to by others. Consumer activities are reuse
create the component from scratch. E is benefits, or measures in dollars of how
greater than or equal to 1.0, showing much the earlier reuse investment helped
costs of developing reusable components or hurt the effectiveness of an activity.
are higher than costs of developing non- The total reuse benefit can then be found
reusable components. Favaro found that by estimating the reuse benefit for all
the cost of reusability increased with subsequent activities that profit from the
the complexity of the component. Mono- reuse investment.
lithic components were so simple there The quality of investment (Q) is the
was no extra cost to develop them as ratio of reuse benefits (B) to reuse invest-
reusable components. In contrast, the ments (R): Q ϭ B/R. If Q is less than one
cost of the mask component more than for a reuse effort, then that effort resulted
doubled as it was generalized. The inte- in a net financial loss. If Q is greater than
gration cost b was also high in complex one, then the investment provided a good
applications. The values for N0 show return. Three major strategies are identi-
that the monolithic and polylithic com- fied for increasing Q: increase the level of
ponent costs are amortized after only reuse, reduce the average cost of reuse,
two reuses. However, the graph compo- and reduce the investment needed to
nent must be used approximately five achieve a given reuse benefit.
times before its costs are recovered, and
the most complex form of the mask will 2.3 Business Reuse Metrics
require thirteen reuses for amortiza-
tion. In summary, costs rise quickly Poulin et al. [1993] present a set of met-
with component size and complexity. rics used by IBM to estimate the effort
saved by reuse. The study weighs poten-
2.2 Quality of Investment tial benefits against the expenditures of
time and resources required to identify
Barnes and Bollinger [1991] examined and integrate reusable software into a
the cost and risk features of software product. Although the measures used are
reuse and suggested an analytical ap- similar to the Cost/Productivity Models
proach for making good reuse invest- [Gaffney and Durek 1989] already dis-
ments. Reuse activities are divided into cussed, metrics are named from a busi-



Table 5. Observable Data [Poulin et al. 1993]

ness perspective, and they provide a finer avoidance is calculated as the sum of
breakdown for some calculations. For ex- cost avoidance in the development
ample, cost is broken down into develop- and maintenance activities.
ment costs and maintenance costs.
The metrics are derived from a set of Development cost avoidance
data elements defined in Table 5.
ϭ RSI ϫ 0.8 ϫ ͑ new code cost͒
Given the preceding data, the follow-
ing metrics are defined:
Service cost avoidance
—Reuse percent: reflects how much of
the product can be attributed to re- ϭ RSI ϫ ͑ error rate͒
use. (This is equivalent to R in the ϫ ͑ new code cost͒
Gaffney and Durek model.) Poulin et
al. distinguish the reuse percent of a Reuse cost avoidance
product, the reuse percent of a prod-
uct release, and the reuse percent for ϭ Development cost avoidance
the entire organization.
ϩ Service cost avoidance .
Product Reuse percent —Reuse value added: a productivity in-
dex that differs from the previous def-
ϭ RSI/(RSI ϩ SSI) ϫ 100 percent . initions of relative productivity by in-
—Reuse cost avoidance: measures re- cluding in the definition of reused
duced total product costs as a result of code source code that is reused within
reuse. (This is equivalent to 1 Ϫ RC in the product and source code that is
the Gaffney and Durek model.) Poulin reused by others. (This is quite simi-
et al. estimate that the financial ben- lar to internal and external reuse,
efit attributable to reuse during the discussed in Section 4.1.)
development phase is 80 percent of
the cost of developing new code, de- Reuse value added
rived from studies showing that the ϭ ͑ SSI ϩ RSI ϩ SIRBO͒ /SSI .
cost of integrating an existing soft-
ware element is 20 percent of the cost —Additional development cost: in-
of new development (b in the Gaffney creased product costs as a result of
and Durek model). This study also developing reusable software (same
acknowledges savings that are real- as E in the Barnes and Bollinger mod-
ized in the maintenance phase as re- el). This study estimates the cost of
used software generally contains additional effort at 50 percent of the
fewer errors; the total reuse cost cost of new development.



Table 6. Characteristics of SEL subsystems [Agresti and Evanco 1992]

Additional Development Cost slight modification, Յ 25% of lines
changed) were between 26% and 28%.
ϭ ͑ relative cost of reuse Ϫ 1 ͒ Defect densities were between 3.0 and
5.5 total defects per KSLOC. Table 6
ϫ code written for reuse by others shows four sample rows summarizing
ϫ new code cost . the project characteristics of the sub-
systems showing that a high level of
Relative cost of writing for reuse is the reuse correlates with a low defect den-
cost of writing reusable code relative to sity (size is in KSLOC units).
the cost of writing code for 1-time use The Reusability-Oriented Parallel pro-
(estimated at 1.5). Code written for re- gramming Environment (ROPE) [Browne
use by others is the kloc of code written et al. 1990] is a software component
for reuse by the initiating project. reuse system that helps a designer find
and understand components. ROPE is
2.4 Relation of Reuse to Quality and integrated with a development environ-
Productivity ment called CODE (Computation-Orient-
Because systematic software reuse is ed Display Environment), which supports
uncommon, empirical evidence relating construction of parallel programs using a
software reuse to quality and productiv- declarative and hierarchical graph model
ity is limited. However, several re- of computation. ROPE supports reuse of
searchers have accumulated and pub- both design and code components, focus-
lished statistics that support the notion ing on the key issues of reusability: find-
that software reuse improves quality ing components, then understanding,
and productivity. modifying, and combining them. An ex-
Agresti and Evanco [1992] conducted periment was conducted to investigate
a study to predict defect density, a soft- user productivity and software quality for
ware quality measurement, based on the CODE programming environment,
characteristics of Ada designs. They with and without ROPE.
used 16 subsystems from the Software The experimental design included
Engineering Laboratory (SEL) of NASA metrics such as fraction of code in a
Goddard Space Flight Center. The SEL program consisting of reused compo-
project database provided data on the nents, development time, and error
extent of reuse and subsystem identifi- rates. Reuse rates were reported as “ex-
cation for each compilation unit, and tremely high” for the 43 programs writ-
reported defects and nondefect modifi- ten using ROPE, with a mean reuse
cations. Collectively, approximately 149 rate for a total program (code and de-
KSLOC (kilo-source lines of code) were sign) of 79%. The researchers used total
analyzed. The project database showed development time to measure the effect
that the reuse ratios (fraction of compi- of reusability on productivity. Table 7
lation units reused verbatim or with shows the development time in hours



Table 7. Mean Development Time and [95% Confidence Intervals in Hours] [Browne et al. 1990]

Table 8. Mean Number of Errors and 95% Confidence Intervals [Browne et al. 1990]

for subjects programming in the CODE tween the measures of reuse rate, devel-
environment and those programming in opment time, and decreases in number
CODE and ROPE. The data reveal that of errors.
ROPE had a significant effect on devel- Card et al. [1986] conducted an em-
opment time for all the experimental pirical study of software design prac-
programs. tices in a FORTRAN-based scientific
Error rates were used to measure computing environment. The goals of
quality. Compile errors, execution er- the analysis were to identify the types
rors, and logic errors were all counted. of software that are reused and to quan-
The results are shown in Table 8. The tify the benefits of software reuse. The
use of ROPE reduced error rates, but results were as follows.
the data are less clear than those for
productivity. The researchers attribute —The modules that were reused with-
this to the difficulty of collecting the out modification tended to be small
data and to the lack of distinction be- and simple, exhibiting a relatively
tween design and code errors. low decision rate.
In summary, the CODE/ROPE exper- —Extensively modified modules tended
iment showed a high correlation be- to be the largest of all reused software



(rated from extensively modified to un- productivity. Gaffney and Durek be-
changed) in terms of the number of lieve that the costs of building reus-
executable statements. able parts must be shared across many
—98 percent of the modules reused users to achieve higher payoffs from
without modification were fault free software reuse.
and 82 percent of them were in the
lowest cost per executable statement
3. MATURITY ASSESSMENT
category.
—These results were consistent with a Reuse maturity models support an as-
previous Software Engineering Labo- sessment of how advanced reuse pro-
ratory study [Card et al. 1982] which grams are in implementing systematic
showed that reusing a line of code reuse, using an ordinal scale of reuse
amounts to only 20 percent of the cost phases. They are similar to the Capabil-
of developing it new. ity Maturity Model developed at the
Software Engineering Institute (SEI) at
Matsumura [Frakes 1991] described Carnegie Mellon University [Humphrey
an implementation of a reuse program 1989]. A maturity model is at the core of
at Toshiba. Results of the reuse pro- planned reuse, helping organizations
gram showed a 60 percent ratio of re- understand their past, current, and fu-
used components and a decrease in er- ture goals for reuse activities. Several
rors by 20 to 30 percent. Managers felt reuse maturity models have been devel-
that the reuse program would be profit- oped and used, though they have not
able if a component were reused at least been validated.
three times.
A study of reuse in the object-oriented
environment was conducted by Chen 3.1 Koltun and Hudson Reuse Maturity
and Lee [1993]. They developed an envi- Model
ronment, based on an object-oriented
approach, to design, manufacture, and Koltun and Hudson [1991] developed
use reusable Cϩϩ components. A con- the reuse maturity model shown in Table
trolled experiment was conducted to 9. Columns indicate phases of reuse ma-
substantiate the reuse approach in turity, assumed to improve along an ordi-
terms of software productivity and qual- nal scale from 1 (Initial/Chaotic) to 5
ity. Results showed improvements in (Ingrained). Rows correspond to dimen-
software productivity of 30 to 90 percent sions of reuse maturity such as Motiva-
measured in lines of code developed per tion/Culture and Planning for Reuse. For
hour (LOC/hr). each of the ten dimensions of reuse, the
The Cost/Productivity Model by amount of organizational involvement
Gaffney and Durek [1989] specified the and commitment increases as an organi-
effect of reuse on software quality (num- zation progresses from initial/chaotic re-
ber of errors) and on software develop- use to ingrained reuse. Ingrained reuse
ment schedules. Results suggested that incorporates fully automated support
tradeoffs can occur between the propor- tools and accurate reuse measurement to
tion of reuse and the costs of developing track progress.
and using reusable components. In a To use this model, an organization
study of the latent error content of a will assess its reuse maturity before
software product, the relative error con- beginning a reuse improvement pro-
tent decreased for each additional use of gram by identifying its placement on
the software but leveled off between each dimension. (In our experience,
three and four uses. The models show most organizations are between Initial/
that the number of uses of the reus- Chaotic and Monitored at the start of
able software components directly cor- the program.) The organization will
relates to the development product then use the model to guide activities



Table 9. Hudson and Koltun Reuse Maturity Model

that must be performed to achieve set of categorized critical success factors
higher levels of reuse maturity. Once an (stated as goals) that an organization
organization achieves Ingrained reuse, can use to assess the present state of its
reuse becomes part of the business rou- reuse practice. The factors are orga-
tine and will no longer be recognized as nized into four primary groups: man-
a distinct discipline. agement, application development, as-
set development, and process and
3.2 SPC Reuse Capability Model technology factors. For example, in the
The reuse capability model developed by group “Application Development Fac-
the Software Productivity Consortium tors/Asset Awareness and Accessibility”
[Davis 1993] has two components: an as- is the goal “Developers are aware of and
sessment model and an implementation reuse assets that are specifically ac-
model. quired/developed for their application.”
The assessment model consists of a The implementation model helps pri-



oritize goals and build successive stages reuse level metrics that include factors
of implementation. The SPC identifies such as abstraction level of the life cycle
four stages in the risk-reduction growth objects and formal definitions of inter-
implementation model: nal and external reuse. Work is also
underway [Bieman and Karunanithi
(1) Opportunistic: The reuse strategy 1993; Chidamber and Kemerer 1994] to
is developed on the project level. define metrics specifically for object-ori-
Specialized reuse tools are used and ented systems. The following sections
reusable assets are identified. discuss this work in detail. To date,
(2) Integrated: A standard reuse little work has been done on amount of
strategy is defined and integrated reuse metrics for generative reuse, al-
into the corporation’s software de- though Biggerstaff [1992] implicitly de-
velopment process. The reuse pro- fines such a metric by reporting a ratio
gram is fully supported by manage- of generated source lines to specification
ment and staff. Reuse assets are effort for the Genesis system—40
categorized. KSLOC for 30 minutes specification
(3) Leveraged: The reuse strategy ex- effort.
pands over the entire life cycle and is
specialized for each product line.
Reuse performance is measured and 4.1 Reuse Level
weaknesses of the program identified.
The basic dependent variable in soft-
(4) Anticipating: New business ven- ware reuse improvement efforts is the
tures take advantage of the reuse level of reuse [Frakes 1993]. Reuse level
capabilities and reusable assets. measurement assumes that a system is
High payoff assets are identified. composed of parts at different levels of
The reuse technology is driven by abstraction. The levels of abstraction
customers’ needs. must be defined to measure reuse. For
The SPC continues to evolve the model. example, a C-based system is composed
It has been used in pilot applications by of modules (.c files) that contain func-
several organizations, but no formal tions, and functions that contain lines of
validation has been done. code. The reuse level of a C-based system,
then, can be expressed in terms of mod-
4. AMOUNT OF REUSE ules, functions, or lines of code. A soft-
ware component (lower level item) may
Amount of reuse metrics are used to be internal or external. An internal lower
assess and monitor a reuse improve- level component is one developed for the
ment effort by tracking percentages of higher level component. An external
reuse of life cycle objects over time. In lower level component is used by the
general, the metric is: higher level component, but was created
for a different item or for general use.
amount of life cycle object reused The following quantities can be calcu-
. lated given a higher level item com-
total size of life cycle object
posed of lower level items:
A common form of this metric is based
on lines of code as follows: L ϭ the total number of lower level
items in the higher level item.
lines of reused code in system or module E ϭ the number of lower level items
.
total lines of code in system or module from an external repository in
the higher level item.
Frakes [1990], Terry [1993], and Frakes I ϭ the number of lower level items
and Terry [1994] extend the basic in the higher level item that are
“amount of reuse” metric by defining not from an external repository.



M ϭ the number of items not from an T ϭ total number of lower level
external repository that are used items in the higher level item,
more than once. both internal and external.

These counts are of unique items Internal Reuse Level: IU/T
(types), not tokens (references). External Reuse Level: EU/T
Given these quantities, the following
reuse level metrics are defined [Frakes Total Reuse Level: (IU ϩ EU)/T.
1990]:
The reuse frequency metric is based on
External Reuse Level: E/L references (tokens) to reused components
rather than counting components only
Internal Reuse Level: M/L
once as was done for reuse level. The
Total Reuse Level: variables and reuse frequency metrics
are:
External Reuse Level IUF ϭ number of references in the
ϩ Internal Reuse Level. higher level item to reused
internal lower level items.
Internal, external, and total reuse lev- EUF ϭ number of references in the
els will assume values between 0 and 1. higher level item to reused
More reuse occurs as the reuse level external lower level items.
value approaches 1. A reuse level of 0 TF ϭ total number of references to
indicates no reuse. lower level items in the higher
The user must provide information to level item, both internal and
calculate these reuse measures. The user external.
must define the abstraction hierarchy, a
definition of external repositories, and a Internal Reuse Frequency: IUF/TF
definition of the “uses” relationship. For External Reuse Frquency: EUF/TF
each part in the parts-based approach, we
must know the name of the part, source Total Reuse Frequency:
of the part (internal or external), level of
abstraction, and amount of usage. (IUF ϩ EUF)/TF.
Terry [1993] extended this formal Program size is often used as a mea-
model by adding a variable reuse sure of complexity. The complexity
threshold level that had been arbitrarily weighting for internal reuse is the sum
set to one in the original model. The of the sizes of all reused internal lower
variables and reuse level metrics are: level items divided by the sum of the
sizes of all internal lower level items
ITL ϭ internal threshold level, the within the higher level item. An exam-
maximum number of times an ple size weighting for internal reuse in
internal item can be used a C system is the ratio of the size (cal-
before it is reused. culated in number of lines of noncom-
ETL ϭ external threshold level, the mentary source code) of reused internal
maximum number of times an functions to the size of all internal func-
external item can be used tions in the system.
before it is reused. The software tool rl calculates reuse
IU ϭ number of internal lower level level and frequency for C code. Given a
items that are used more than set of C files, rl reports the following
ITL. information:
EU ϭ number of external lower level
items that are used more than (1) internal reuse level;
ETL. (2) external reuse level;



(3) total reuse level; aged, with similar definitions to the
(4) internal reuse frequency; server perspective.
(5) external reuse frequency; Measurable system reuse attributes
include:
(6) total reuse frequency;
(7) complexity (size) weighting for —% of new system source text imported
internal functions. from the library;
The user may specify an internal and —% of new system classes imported ver-
external threshold level. The software batim from the library;
allows multiple definitions of higher —% of new system classes derived
level and lower level abstractions. The from library classes and the average
allowed higher level abstractions are % of the leveraged classes that are
system, file, or function. The lower imported;
level abstractions are function and —average number of verbatim and
NCSL (Non-Commentary Source Lines leveraged clients for servers, and
of code). servers for clients;
—average number of verbatim and le-
veraged indirect clients for servers,
4.2 Reuse Metrics for Object-Oriented and indirect servers for clients;
Systems —average length and number of paths
Bieman [1992] and Bieman and Karu- between indirect servers and clients
nanithi [1993] have proposed reuse met- for verbatim and leveraged reuse.
rics for object-oriented systems. Bieman Bieman and Karunanithi [1993] de-
[1992] identifies three perspectives from scribe a prototype tool that is under
which to view reuse: server, client, and development to collect the proposed
system. The server perspective is the measures from Ada programs. This
perspective of the library or a particular work recognizes the differences between
library component. The analysis focuses object-oriented systems and procedural
on how the entity is reused by the cli- systems, and exploits those differences
ents. From the client perspective, the through unique measurements.
goal is knowing how a particular pro- Chidamber and Kemerer [1994] pro-
gram entity reuses other program enti- pose a metrics suite for object-oriented
ties. The system perspective is a view of design. The paper defines the following
reuse in the overall system, including metrics based on measurement theory:
servers and clients.
The server reuse profile of a class (1) Weighted methods per class;
characterizes how the class is reused by (2) Depth of inheritance tree;
the client classes. The verbatim server (3) Number of children;
reuse in an object-oriented system is (4) Coupling between object classes;
basically the same as in procedural sys- and
tems, using object-oriented terminology.
(5) Responses for a class.
Leveraged server reuse is supported
through inheritance. A client can reuse Among these, the most significant to re-
the server either by extension, adding use is the metric depth of inheritance tree.
methods to the server, or by overload, This metric calculates the length of inher-
redefining methods. (Note that McGre- itance hierarchies. Shallow hierarchies
gor and Sykes [1992] offer good defini- forsake reusability for the simplicity of
tions of the object-oriented terminology understanding, thus reducing the extent
used in this section.) of method reuse within an application.
The client reuse profile characterizes Chidamber and Kemerer assert that this
how a new class reuses existing library metrics suite can help manage reuse op-
classes. It too can be verbatim or lever- portunities by measuring inheritance.



4.3 Reuse Predictions for Life Cycle No Attempt to Reuse
Objects Part Does Not Exist
Frakes and Fox [1995] present models Part Is Not Available
that allow the prediction of reuse levels Part Is Not Found
for one life cycle object based on reuse Part Is Not Understood
levels for other life cycle objects. Such
Part Is Not Valid
models can be used to estimate reuse
levels of later life cycle objects such as Part Can Not Be Integrated
code from earlier ones such as require- Each failure mode has failure causes
ments. The authors define both temporal associated with it. “No Attempt to Re-
and nontemporal models, and discuss use,” has among its failure causes, for
methods for tailoring the models for a example, resource constraints, no incen-
specific organization. The models are tive to reuse, and lack of education. To
based on reuse data collected from 113 use the model, an organization gathers
respondents from 29 organizations, pri- data on reuse failure modes and causes,
marily in the US. The study found that and then uses this information to prior-
there were significant correlations be- itize its reuse improvement activities.
tween the reuse levels of life cycle objects,
and that prediction models improved as
data from more life cycle objects were
6. REUSABILITY ASSESSMENT
added to the models.
Another important reuse measurement
area concerns the estimation of reus-
5. SOFTWARE REUSE FAILURE MODES ability for a component. Such metrics
MODEL are potentially useful in two key areas
Implementing systematic reuse is diffi- of reuse: reuse design and reengineer-
cult, involving both technical and non- ing for reuse. The essential question is,
technical factors. Failure modes analysis are there measurable attributes of a
provides an approach to measuring and component that indicate its potential
improving a reuse process based on a reusability? If so, then these attributes
model of the ways a reuse process can will be goals for reuse design and re-
fail. The reuse failure modes model reengineering. One of the difficulties in
ported by Frakes and Fox [1996] can be this area is that attributes of reusabil-
used to evaluate the quality of a system- ity are often specific to given types of
atic reuse program, to determine reuse reusable components, and to the lan-
impediments in an organization and to guages in which they are implemented.
devise an improvement strategy for a sys- In this section we review work in this
tematic reuse program. area.
Given the many factors that may af- In a study of NASA software, Selby
fect reuse success, how does an organi- [1989] identified several module at-
zation decide which ones to address in tributes that distinguished black-box
its reuse improvement program? This reuse modules from others in his sam-
question can be answered by finding out ple. The attributes included:
why reuse is not taking place in the
organization. This can be done by con- —Fewer module calls per source line;
sidering reuse failure modes—that is, —Fewer I/O parameters per source line;
the ways that reuse can fail. —Fewer read/write statements per line;
The reuse failure modes model has
seven failure modes corresponding to —Higher comment to code ratios;
the steps a software engineer will need —More utility function calls per source
to complete in order to reuse a compo- line;
nent. The failure modes are: —Fewer source lines.



Figure 2. Reuse library system.

This data suggest that modules possess- ponents. Potentially reusable software
ing these attributes will be more reus- is identified, and a method to measure
able. distances from that ideal is defined. By
Basili et al. [1990] reported on two measuring the amount of change neces-
reuse studies of systems written in Ada. sary to convert an existing program into
The first study defined measures of data one composed of maximally reusable
bindings to characterize and identify re- components, an indication of the reus-
usable components. Data binding is the ability of the program can be obtained.
sharing of global data between program
elements [Hutchins and Basili 1985]. 7. REUSE LIBRARY METRICS
Basili et al. [1990] proposed a method to
identify data bindings within a pro- As can be seen in Figure 2, a reuse
gram. After identification of the bind- library is a repository for storing reus-
ings, a cluster analysis computes and able assets, plus an interface for search-
weights coupling strengths. A coupling ing the repository. Library assets can be
is based on references to variables and obtained from existing systems through
parameters (data bindings). Aliasing, or reengineering, designed and built from
referencing, is not taken into account; scratch, or purchased. Components then
only one level of data bindings is consid- are usually certified, a process for as-
ered. The cluster analysis identifies suring that they have desired attributes
which modules are strongly coupled and such as testing of a certain type.
may not be good candidates for reuse, The components are then classified so
and which modules are found to be inde- that users can effectively search for
pendent of others and are potentially them. The most common classification
reusable. A similar use of module cou- schemes are enumerated, faceted, and
pling information to identify potential free text indexing [Frakes and Gandel
objects in C code has been reported by 1990]. The evaluation criteria for index-
Dunn and Knight [1991]. ing schemes of reuse libraries are: costs,
The second study defines an abstract searching effectiveness, support for un-
measurement of reusability of Ada com- derstanding, and efficiency.



Indexing costs include the cost of cre- can be measured by the number of bytes
ating a classification scheme, maintain- needed to store the collection. Indexing
ing the classification scheme, and up- overhead ratios can be calculated by
dating the database for the scheme. dividing the sum of the size of the raw
These concerns are negligible for a data, and indexing files by the size of
small collection, but become more im- the indexing files. Retrieval speed is
portant as the collection grows. Each of usually calculated by measuring the time
these costs can be measured in terms of it takes the system to execute a search of
dollars or effort. These costs can be nor- a given query on a given database.
malized by dividing total costs by the Quality of assets is another important
number of components handled by the aspect of a reuse library. There is con-
library. siderable anecdotal evidence that this is
Searching effectiveness addresses the most important factor in determin-
how well the classification methods help ing successful use of a reuse library.
users locate reusable components, and Frakes and Nejmeh [1987] proposed the
is usually measured with recall and pre- following metrics as indicators of the
cision. Recall is the number of relevant quality of assets in a reuse library.
items retrieved divided by the number
of relevant items in the database. The —Time in Use: the module should have
denominator is generally not known and been used in one or more systems that
must be estimated using sampling have been released to the field for a
methods. Precision is the number of rel- period of three months.
evant items retrieved divided by the —Reuse Statistics: the extent to which
total of items retrieved. Another effec- the module has been successfully re-
tiveness measure is overlap, which reused by others is perhaps the best
ports the percentage of relevant docu- indicator of module quality.
ments retrieved jointly by two methods.
Frakes and Pole [1994], in a study of —Reuse Reviews: favorable reviews
representation methods for reusable from those that have used the module
software, reported no statistically sig- are a good indication that the module
nificant difference in terms of recall and is of higher quality.
precision between enumerated, faceted, —Complexity: overly complex modules
free text keyword, and attribute value may not be easy to modify or main-
classification schemes. They reported tain.
high overlap measures ranging from .72 —Inspection: the module should have
to .85 for all pairs of the classification been inspected.
methods. —Testing: the modules should have
To reuse a component, a software en- been thoroughly tested at the unit
gineer must not only find it, but also level with statement coverage of 100
understand it. Understanding metrics percent and branch coverage of at
measure how well a classification least 80 percent.
method helps users understand reus-
able components. Frakes and Pole Another class of reuse library metrics is
[1994] used a 7-point ordinal scale (7 ϭ used to measure usage of a reuse library
best) to measure support for under- system. The following list was supplied
standing. They reported no significant by the ASSET system, an on-line com-
difference between the classification mercial reuse library system.
methods using this metric.
In order to be useful, a reuse library —Time on-line (system availability):
must also be efficient. Library efficiency this is a measure of the number of
deals with nonfunctional requirements hours the system is available for use.
such as memory usage, indexing file —Account demographics: assigns users
size, and retrieval speed. Memory usage to the following categories: Govern-



Table 10. Summary of Software Reuse Metrics and Models



Table A1. Definitions of Reuse Types



ment/contractor, commercial, aca- overlap in meaning. For example, the ta-
demia, NonUS; ble terms public and external both de-
—Type of library function performed: scribe the part of a product that was
searches, browses, extracts; constructed externally; private and inter-
—Asset distribution: whether electronic nal describe the part of a product that
or via a human librarian; was not constructed externally but was
developed and reused within a single
—Number of subscriber accounts;
product. The terms verbatim and black-
—Available assets by type: interopera- box both describe reuse without modifica-
tion, supplier listings, local compo- tion; leveraged and white-box describe re-
nents; use with modification. The final four
—Number of extractions by collection: terms in the table describe levels of reuse
number of assets extracted by collec- that can occur in the object-oriented par-
tion, number of assets extracted by adigm. (References in descriptions in Ta-
evaluation level; ble A1 are provided for further informa-
—Listing of assets by domain; tion. They do not necessarily indicate first
—Request for services by: Telnet Log- use of the term.)
ins, modem Logins, FTP, World Wide
Web.
REFERENCES
These metrics can provide good man-
agement information for a library sys- AGRESTI, W. AND EVANCO, W. 1992. Projecting
tem. They can be used to demonstrate software defects in analyzing Ada designs.
IEEE Trans. Softw. Eng. 18, 11, 988 –997.
the value of the library to management
BARNES, B. ET AL. 1988. A framework and eco-
as well as to provide information for nomic foundation for software reuse. In IEEE
continuous quality improvement. Tutorial: Software Reuse—Emerging Technol-
ogy, W. Tracz, Ed. IEEE Computer Society
8. SUMMARY Press, Washiington, D.C.
BARNES, B. AND BOLLINGER, T. 1991. Making
A reuse program must be planned, delib- software reuse cost effective. IEEE Softw. 1,
erate, and systematic if it is to give large 13–24.
payoffs. As organizations implement sys- BASILI, V. R., ROMBACH, H. D., BAILEY, J., AND
tematic software reuse programs in an DELIS, A. 1990. Ada reusability and mea-
surement. Computer Science Tech. Rep. Se-
effort to improve productivity and qual- ries, University of Maryland, May.
ity, they must be able to measure their BIEMAN, J. 1992. Deriving measures of soft-
progress and identify the most effective ware reuse in object-oriented systems. In
reuse strategies. In this article we sur- BCS-FACS Workshop on Formal Aspects of
veyed metrics and models of software re- Measurement, Springer-Verlag.
use. A metric is a quantitative indicator BIEMAN, J. AND KARUNANITHI, S. 1993. Candi
date reuse metrics for object-oriented and Ada
of an attribute. A model specifies relation- software. In Proceedings of IEEE-CS First
ships between metrics. International Software Metrics Symposium.
Table 10 presents a summary of the BIGGERSTAFF, T. 1992. An assessment and anal-
reuse metrics and models discussed. As ysis of software reuse. In Advances in Com-
is typical in an emerging discipline such puters, Marshall Yovits, Ed. Academic Press,
as systematic software reuse, many of New York.
these metrics and models still lack for- BOOCH, G. 1987. Software Componenets with
Ada. Benjamin/Cummings, Menlo Park, CA.
mal validation. Despite this, they are
BROWNE, J., LEE, T., AND WERTH, J. 1990. Ex-
being used and are being found useful perimental evaluation of a reusability-ori-
in industrial practice. ented parallel programming environment.
IEEE Trans. Softw. Eng. 16, 2, 111–120.
Appendix 1: Definitions of Types of Reuse CARD, D., MCGARRY, F., PAGE, G., ET AL. 1982.
The software engineering laboratory. NASA/
The terms in Table A1 describe various GSFC, 2.
reuse issues. Some terms in the table CARD, D., CHURCH, V., AND AGRESTI, W. 1986.



An empirical study of software design practices. FRAKES, W. AND POLE, T. 1994. An empirical
IEEE Trans. Softw. Eng. 12, 2, 264 –270. study of representation methods for reusable
CHEN, D. AND LEE, P. 1993. On the study of software components. IEEE Trans. Softw.
software reuse: using reusable C ϩ ϩ compo- Eng. 20, 8, 617– 630.
nents. J. Syst. Softw. 20, 1, 19 –36. FRAKES, W. AND TERRY, C. 1994. Reuse level
CHIDAMBER, S. AND KEMERER, C. 1994. A met- metrics. In Proceedings of the Third Interna-
rics suite for object-oriented design. IEEE tional Conference on Software Reuse (Rio de
Trans. Softw. Eng. 20, 6, 476 – 493. Janeiro), W. Frakes, Ed., IEEE Computer Sci-
DAVIS, T. 1993. The reuse capability model: a ence Press, Los Alamitos, CA, 139 –148.
basis for improving an organization’s reuse GAFFNEY, J. E. AND DUREK, T. A. 1989. Soft-
capability. In Proceedings of the Second Inter- ware reuse— key to enhanced productivity:
national Workshop on Software Reusability some quantitative models. Inf. Softw. Tech-
(Herndon, VA). nol. 31, 5, 258 –267.
DUNN, M. F. AND KNIGHT, J. C. 1991. Software HUMPHREY, W. 1989. Managing the Software
reuse in an industrial setting: A case study. Process. Addison-Wesley, Reading, MA.
In Proceedings of the Thirteenth International
Conference on Software Engineering, IEEE HUTCHINS, D. H. AND BASILI, V. 1985. System
Computer Society Press, Austin, TX, 329 – structure analysis: Clustering with data bind-
338. ings. IEEE Trans. Softw. Eng. 11, 8, 749 –757.
FAVARO, J. 1991. What price reusability? A case JONES, C. 1993. Software return on investment
study. Ada Lett. (Spring), 115–124. preliminary analysis. Software Productivity
FENTON, N. 1991. Software Metrics, A Rigorous Research, Inc.
Approach. Chapman & Hall, London. KOLTUN, P. AND HUDSON, A. 1991. A reuse ma-
FRAKES, W. 1993. Software reuse as industrial turity model. In Fourth Annual Workshop on
experiment. Am. Program. (Sept.), 27–33. Software Reuse (Herndon, VA).
FRAKES, W. (Moderator). 1991. Software reuse: LILLIE. 1995. Personal communication.
is it delivering? In Proceedings of the Thir- MARGONO, T. AND RHOADS, T. 1993. Software
teenth International Conference on Software reuse economics: cost-benefit analysis on a
Engineering (Los Alamitos, CA). IEEE Com- large-scale Ada project. In International Con-
puter Society Press, Los Alamitos, CA. ference on Software Engineering ACM, New
FRAKES, W. 1990. An empirical framework for York.
software reuse research. In Proceedings of the MCGREGOR, J. AND SYKES, D. 1992. Object-Ori-
Third Workshop on Tools and Methods for ented Software Development: Engineering
Reuse (Syracuse, NY). Software for Reuse. Van Nostrand Reinhold,
FRAKES, W. AND FOX, C. 1995. Modeling reuse New York.
across the software lifecycle. J. Syst. Softw. OGUSH, M. 1992. A software reuse lexicon.
30, 3, 295–301.
Crosstalk (Dec.).
FRAKES, W. AND FOX. C. 1996. Quality improve-
POULIN, J. S., CARUSO, J. M., AND HANCOCK,
ment using a software reuse failure modes
D. R. 1993. The business case for software
model. IEEE Trans. Softw. Eng. 24, 4 (April),
274 –279. reuse. IBM Syst. J. 32, 4, 567–594.
FRAKES, W. AND GANDEL, P. 1990. Representing PRIETO-DIAZ, R. 1993. Status report: Software
reusable software. Inf. Softw. Technol. 32, 10, reusability. IEEE Softw. (May), 61– 66.
653– 664. SELBY, R. W. 1989. Quantitative studies of soft-
FRAKES, W. AND ISODA, S. 1994. Success factors ware reuse. In Software Reusability, Volume
of systematic reuse. IEEE Softw. 11, 5, 14 –19. II, T. J. Biggerstaff and A. J. Perlis, Eds.,
FRAKES, W. B. AND NEJMEH, B. A. 1987. Addison-Wesley, Reading, MA.
Software reuse through information retrieval. TERRY, C. 1993. Analysis and implementation
In Proceedings of the Twentieth Annual Ha- of software reuse measurement. Virginia
waii International Conference on Systems Sci- Polytechnic Institute and State University,
ences. Kona, Jan., 530 –535. Master’s Project and Report.

Received April 1994; revised October 1995; accepted November 1995


Art06

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à Art06

Similaire à Art06 (20)

Art06