home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
poulin2.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
13KB
|
335 lines
A Method for Assessing Cross-Lifecycle Reuse
Jeffrey S. Poulin
IBM Federal Systems Company
MD 0220, Owego, NY 13827
Tel: (607) 751-6899
Email: poulinj@vnet.ibm.com
Fax: (607) 751-2800
Abstract
Most current reuse measurement models focus on quantifying the level of software, e.g., code,
reused on a given project [1 ], [2 ], [3 ]. 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 reusein other
phases of the lifecycle, such as design [4], information [5 ], 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 quantifyingthe issues in each
phase of software development, we will depend on our currentco de reusemo dels toreflect 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.
Poulin- 1
1 Background
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 mea-
surement 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 managercan 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.
2 Position
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 [6 ], 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" [7] 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, Itake 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 ss level of code reuse
Observations show Reuse Percent (Reuse%) [8 ] 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) [9] 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 [10] that despite their shortcomings, LOC
not only serve as a good indicator of overall productivity inco de but also provide a good secondary
indicator of work done in other phases.
2.1 Proposed method to quantify total lifecycle reuse
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
workproduct 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:
Poulin- 2
fflCode- Lines of code, Function Points
fflDesign- Module design sheet, Component specification
fflTest- Test cases, test scripts
fflInformation Development- Words, tokens, paragraphs
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 reusetarget
or goal. Also observe that this approach assumes each lifecycle phase has well-defined boundaries
(e.g., we can calculate a Reuse% foreach phase) and that the software development process remains
relatively stable (e.g., that we canmo del thetotal 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 willyield 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 inour general
model [6 ]:
fflRequirements Definition- takes 15 percent of the lifecycle
fflDesign- takes 15 percent of the lifecycle
fflCode- takes 20 percent of the lifecycle
fflTest- takes 30 percent of the lifecycle
fflInformation Development/admin- takes 20 percent of the lifecyle
Knowing the Reuse% in each phase and the relative effort expended in each phase, we can calculate
the overall Product Reuse% as follows:
Xn
Product Reuse% = (Relative lifecycle effort in Phasei) (Reuse% in Phasei)
i=1
where n=number of phases in lifecycle.
2.2 Example total lifecycle reuse calculation
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:
fflRequirements Definition- 25 percent of requirements for the current system came from a
similar system done last year for another customer
Poulin- 3
fflDesign- 55 percent of the designs, mostly coming from the requirements reused in the pre-
vious phase, came straight out of the graphical CASE tool library used by the design depart-
ment,
fflCode- 35 percent of the code came unmodified from the organization's reuse subdirectory
on AFS,
fflTest- 25 percent of the test cases and drivers from other projects worked just fine without
change, and,
fflInformation Development/admin- 65 percent of the documentation, mostly from hyper-
text links to help files and user instructions, came from the Information Development (ID)
database.
The Product Reuse% would equal:
fflReuse%: Requirements Definition- :15 :25 = :038
fflReuse%: Design- :15 :55 = :083
fflReuse%: Code- :20 :35 = :07
fflReuse%: Test-:30 :25 = :075
fflReuse%: Information Development/admin- :20 :65 = :13
For a total Product Reuse% of 39.6 percent.
3 Comparison
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 dis-
tribution of effort [11 ]. The COCOMO model premises all calculations on cost drivers and Effort
Multipliers that reflect the relative difficulty or complexity at each lifecycle phase. COCOMO de-
fines 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 [1] 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. Werethe mo del to address total lifecycle costs or costs avoided, it would
extend the model presented in [2] by including a cost factor related to the value of the units we
choose to measure at each phase.
References
[1] J. G. Jr. and T. Durek, "Software Reuse- Key to Enhanced Pro ductivity: Some Quantitative
Models," Information and Software Technology, vol. 31, no. 5, June 1989.
Poulin- 4
[2] J. Poulin and J. Caruso, "A Reuse Measurement and Return on Investment Model," in Pro-
ceedings of the Second International Workshop on Software Reusability, (Lucca, Italy), 24-26
March 1993.
[3] B. Barnes and T. Bollinger, "Making Reuse Cost Effective," IEEE Software, vol. 8, no. 1,
pp. 13-24, January 1991.
[4] G. Boetticher, K. Srinivas, and D. Eichmann, "A Neural Net-based Approach to Software
Metrics," in Proceedings of the 5th International Conference on Software Engineering and
Knowledge Engineering, (San Francisco, CA), pp. 271-4, 14-18 June 1993.
[5] K. Yglesias, "Limitations of Certification Standards in Achieving Successful Parts Retrieval,"
in Proceedings of the 5th International Workshop on Software Reuse, (Palo Alto, California),
26-29 October 1992.
[6] G. G. Inc., "Software Engineering Strategies StrategicAnalysis Report," tech. rep., April 30,
1991.
[7] T. Bollinger and S. Pfleeger, "Economics of reuse: issues and alternatives," Information and
Software Technology, vol. 32, no. 10, pp. 643-52, December 1990.
[8] J. Poulin and J. Caruso, "Determining the Value of a Corporate Reuse Program," in Proceed-
ings of the IEEE Computer Society International Software Metrics Symposium, (Baltimore,
MD, 21-22 May 1993), pp. 16-27, 21-22 May 1993.
[9] J. Poulin, "Issues in the Development and Application of Reuse Metrics in a Corporate En-
vironment," in Fifth International Conference on Software Engineering and Knowledge Engi-
neering, (San Francisco,CA), pp. 258-262, 16-18 June 1993.
[10] R. Tausworthe, "Information models of software productivity: limits on productivity growth,"
Journal of System Software, vol. 19, no. 2, pp. 185-201, October 1992.
[11] B. Boehm, Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981.
4 Biography
Jeffrey S. Poulin, joined IBM's Reuse Technology Support Center, Poughkeepsie, New York, in
1991. Hisresp onsibilities 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.
Poulin- 5