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




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.


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 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.


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 [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.

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 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.

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 (i=1 to 5):


  1. Requirements Definition- 25% of requirements for the current system came from a similar system done last year for another customer,
  2. Design- 55% of the designs, mostly coming from the requirements reused in the previous phase, came straight out of the graphical CASE tool library used by the design department,
  3. Code- 35% of the code came unmodified from the organization’s reuse subdirectory on AFS,
  4. Test- 25% of the test cases and drivers from other projects worked just fine without change, and,

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:


  1. Reuse%: Requirements Definition- .15 * .25 = .038
  2. Reuse%: Design- .15 * .55 = .083
  3. Reuse%: Code- .20 * .35 = .07
  4. Reuse%: Test- .30 * .25 = .075
  5. Reuse%: Information Development/admin- .20 * .65 = .13


For a total Product Reuse% of 39.6%.


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 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.


4          Bibliography

[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.


5          Biography

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.