A
Method for Assessing Cross-Lifecycle Reuse
Jeffrey S. Poulin
IBM
Federal Systems Company
MD
0220, Owego, NY 13827
Tel:
(607) 751-6899, fax: (607) 751-2800
Email:
poulinj@vnet.ibm.com
2
November 1993
Abstract
Most current reuse measurement models
focus on quantifying the level of software, e.g., code, reused on a given
project [Gaffney89], [Poulin93], [Barns91].
One reason for the focus on code reuse metrics lies in the relative ease
of quantifying the amount of code in a given product. A second, perhaps more critical, reason lies in the difficulty of
completely understanding the issues behind reuse in other phases of the
lifecycle, such as design [Boetticher93], information [Yglesias92], and test
cases. This position paper describes a
method to quantify the total amount of cross-lifecycle reuse on a project. However, until we have practical and
reliable methods of understanding and quantifying the issues in each phase of
software development, we will depend on our current code reuse models to
reflect the overall level of reuse in our systems.
Keywords: Reuse
Metrics, Measuring Reuse, Cross-lifecycle metrics.
Workshop Goals:
Learn and exchange information on current reuse issues, methods, and metrics.
Working Groups:
Design guidelines for reuse, Useful and collectible metrics, Reuse and formal
methods.
As a member of IBM’s Reuse Technology
Support Center, the author helped lead the development and acceptance of the
IBM software reuse metrics. He has
conducted research into software measurement techniques and implemented a
program measurement tool for the workstation platform. A common aspect of this measurement work has
remained the need to implement metrics that the software development manager
can easily acquire, understand, and use with the confidence that the values
upon which he makes his business decisions accurately reflect the state of his
product.
To fully determine the complete value of
reuse, we must develop a method of measuring reuse in the total software development
lifecycle. (The emphasis on development means to exclude maintenance
activities.) The other phases of the
lifecycle may include the reuse of requirements specifications, designs, user
documentation, and other products related to the project. Since code really only contributes about 20
percent of the effort to software development [Gartner91], it seems misleading
to claim a total level of reuse on a product based solely on the amount of reused
source instructions.
However, we do not currently have a means
to determine the total reuse on a product based on reuse in each of the
lifecycle stages. We know that where
code reuse takes place, reuse of designs, test cases, and documentation has
probably also taken place. This “inclusion
effect’’ [Bollinger90] of reusing subsequent lifecycle products motivates us to
reuse early in the lifecycle so as to generate the most value out of our reused
parts. Because of this effect, I take
the position (in the form of a hypothesis) that until we develop a
comprehensive system of measuring and combining reuse in each phase of the
software development lifecycle:
HO:
total cross-lifecycle reuse »
level of code reuse
Observations show Reuse Percent (Reuse%)
[Poulin93b] as the most widely used and reported reuse metric.
Reuse% has an advantage in that managers
can easily gather data for, calculate, and understand the metric. This position paper assumes a systematic
method of determining what to count (a reuse definition) [Poulin93c] and does
not attempt to address the financial aspects of cross-lifecycle reuse. Instead, it proposes to use (code) Reuse% as
an overall indicator of the level of reuse on a product. The premise of this position extends the
observation in [Tausworthe92] that despite their shortcomings, LOC not only
serve as a good indicator of overall productivity in code but also provide a
good secondary indicator of work done in other phases.
While we use the code Reuse% as an overall
product indicator, we can work towards realizing the following model of Product
Reuse%. First, we require a means
to measure reuse in each individual stage of the lifecycle. A straightforward approach to measure reuse
in each phase would extend the approach currently used to measure reuse of
code. First, determine the unit of
granularity or work product unit of interest at each stage. Second, base the
Reuse% for
each stage on the portion of units reused
in that stage. We might use the following units for each stage:
Observe that once we define the units to
use at each phase and we put a process (and required tools) in place to track
these units, we can determine the reuse percent for each phase. This may prove useful as an in-process
measurement to indicate how well a product tracks towards a reuse target or
goal. Also observe that this approach
assumes each lifecycle phase has well-defined boundaries (e.g., we can
calculate a Reuse% for each phase) and that the software development process
remains relatively stable (e.g., that we can model the total lifecycle as the
sum of the activity in each of the individual phases). Although these assumptions may not hold for
any given project, they allow us to develop a general equation for Product
Reuse%.
To achieve an overall Product Reuse%, we
determine the portion of total product effort expended in each phase of the
lifecycle. For post-mortem statistics,
actual values will yield the best results, but for a general model we can use
historical averages obtained from the organization product development
office. For example, we might use the
following lifecycle effort profile in our general model [Gartner91]:
Knowing the Reuse% in each phase and the
relative effort expended in each phase, we can calculate the overall Product
Reuse% as follows:
Product
Reuse% = Sum from i=1 to n of
[(Relative lifecycle effort in Phase i) * (Reuse% in Phase i)]
where
n=number of phases in lifecycle.
Let the entire software development cycle
for an organization consist of the five phases above, in the proportions
given. Let the following situations
determine the amount reuse in each phase (i=1 to 5):
5.
Information
Development/admin- 65% of the documentation, mostly from hypertext links to
help files and user instructions, came from the Information Development (ID)
database.
The Product Reuse% would equal:
For a total Product Reuse% of 39.6%.
The detailed version of the COnstructive
COst Model (COCOMO) software cost-estimation model uses phase-dependent Effort
Multipliers to reflect the effect of the cost drivers on the phase distribution
of effort [Boehm81]. The COCOMO model premises
all calculations on cost drivers and Effort Multipliers that reflect the
relative difficulty or complexity at each lifecycle phase. COCOMO defines the following six lifecycle
phases: Requirements, Product Design, Detailed Design, Code and Unit Test,
Integrate and Test, and Maintenance.
The model proposed by Gaffney and Durek
[Gaffney89] also addresses reuse at each lifecycle stage and uses effort
multipliers similar to COCOMO. These
models contrast with the model presented here, which does not consider the value
or complexity of each task because this model does not seek to estimate costs
or ROI. Were the model to address total lifecycle costs or costs avoided, it would
extend the model presented in [Poulin93] by including a cost factor related to
the value of the units we choose to measure at each phase.
[Barns91]
B.H. Barnes and T.B. Bollinger, “Making Reuse Cost Effective,” IEEE Software,
Vol. 8, No. 1,January 1991, pp. 13-24.
[Boehm81]
B.W. Boehm, Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
[Boetticher93]
G. Boetticher and K. Srinivas and D. Eichmann, “A Neural Net-based Approach to
Software Metrics,” Proceedings of the 5th International Conference on
Software Engineering and Knowledge Engineering, San Francisco, CA, 14-18
June 1993, pp. 271-4.
[Bollinger90]
T.B. Bollinger and S.L. Pfleeger, “Economics of reuse: issues and alternatives,”
Information and Software Technology, Vol. 32, No. 10, December 1990, pp.
643-52.
[Gaffney89]
J.E. Gaffney Jr. and T.A. Durek, “Software Reuse- Key to Enhanced Productivity:
Some Quantitative Models,” Information and Software Technology, Vol. 31,
No. 5, June 1989.
[Gartner91]
Gartner Group Inc., “Software Engineering Strategies Strategic Analysis Report,”
April 30, 1991.
[Poulin93]
J.S. Poulin and J.M. Caruso, “A Reuse Measurement and Return on Investment
Model,” Proceedings of the Second International Workshop onSoftware
Reusability, Lucca, Italy, 24-26 March 1993.
[Poulin93b]
J.S. Poulin and J.M. Caruso, “Determining the Value of a Corporate Reuse
Program,” Proceedings of the IEEE Computer Society International Software Metrics
Symposium, Baltimore, MD, 21-22 May 1993, pp. 16-27.
[Poulin93c]
J.S. Poulin, “Issues in the Development and Application of Reuse Metrics in a
Corporate Environment,” Fifth International Conference on Software
Engineering and Knowledge Engineering, San Francisco, CA, 16-18 June 1993, pp.
258-262.
[Tausworthe92]
R.C. Tausworthe, “Information models of software productivity: limits on
productivity growth,” Journal of System Software, Vol. 19, No. 2, October 1992,
pp. 185-201.
[Yglesias92,
] K.P. Yglesias, “Limitations of Certification Standards in Achieving
Successful Parts Retrieval,” Proceedings of the 5th International Workshop
on Software Reuse, Palo Alto, California, 26-29 October 1992.
Jeffrey S. Poulin joined
IBM’s Reuse Technology Support Center, Poughkeepsie, New York, in 1991. His responsibilities on the RTSC included
developing and applying corporate standards for reusable component classification, certification, and measurements. He currently works in Open Systems
Development for IBM’s Federal Systems Company and participates in the IBM
Corporate Reuse Council, the Association for Computing Machinery, and the IEEE
Computer Society. A Hertz Foundation
Fellow, Dr. Poulin earned his Bachelors degree at the United States Military
Academy at West Point, New York, and his Masters and Ph.D. degrees at
Rensselaer Polytechnic Institute in Troy, New York.