Lombard Hill Group
About
Clients
Register
Services
Seminars
Products
Articles
Reuse Economic Calculator

Lombard Hill Group

The Lombard Hill Group empowers organizations to implement
software reuse programs that result in greater productivity,
quality and shortened time-to-market


About: Lombard Hill Group



Lombard Hill Group is comprised of experienced professionals with extensive expertise in establishing successful software reuse programs in major corporations. Our mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. Our clients have been in diverse industries such as investment banking, insurance, and electronics. As a firm of experienced practitioners, we emphasize a pragmatic approach to implementing and improving a reuse program.

The Lombard Hill Group has and always seeks collaborative partnerships with other service and product firms. If you have a proposal for such an arrangement, please contact us at

The Lombard Hill Group contact information:

Managing Director Biography



Wayne C. Lim specializes in the strategic planning, economic, organizational, and metric issues of software reuse. He is the author of numerous papers and a Prentice-Hall book, "Managing Software Reuse." Mr. Lim is the recipient of an IEEE Best Article Award for his research in reuse. He helped start and manage the Corporate-wide Reuse Programs at Hewlett-Packard and other organizations.

Mr. Lim completed his MBA degree at Harvard University

About Us


About: Lombard Hill Group



Lombard Hill Group is comprised of experienced professionals with extensive expertise in establishing successful software reuse programs in major corporations. Our mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. Our clients have been in diverse industries such as investment banking, insurance, and electronics. As a firm of experienced practitioners, we emphasize a pragmatic approach to implementing and improving a reuse program.

The Lombard Hill Group has and always seeks collaborative partnerships with other service and product firms.



Managing Director Biography



Dr. Wayne C. Lim specializes in the strategic planning, economic, organizational, and metric issues of software reuse. He is the author of numerous papers and a Prentice-Hall book, "Managing Software Reuse." Dr. Lim is the recipient of an IEEE Best Article Award for his research in reuse. He helped start and manage the Corporate-wide Reuse Programs at Hewlett-Packard and other organizations. Previous work includes strategic planning at Bain & Company and software engineering at Hewlett-Packard


Dr. Lim completed his undergraduate degree at Pomona College, MBA degree at Harvard University and Doctorate at Case Western Reserve University.


Dr. Lim completed his undergraduate degree at Pomona College, MBA degree at Harvard University and Doctorate at Case Western Reserve University.

Please register to gain access to the Reuse Economic Calculator

Recommended Reuse Metrics

JavaScript enabled browser required!

Basic "ReuCalc" Calculator

To find your level of reuse and estimate the benefits to your organization, simply enter the amount of your new and modified software, the amount of software you reused, and the amount of software you wrote for others to reuse. The table contains recommended default values for most information. Push calculate when you finish. Click on highlighted terms for help.

Input your organization's information: Your reuse metrics equal:
New or Changed Source Instructions (LOC): Total Source Instructions (LOC):
Reused Source Instructions (LOC): Reuse%:
Source Instructions Written for Reuse by Others (LOC): Development Cost Avoidance (DCA):
New Development Cost ($/LOC): Service Cost Avoidance (SCA):
Relative Cost of Reuse (RCR): Reuse Cost Avoidance (RCA):
Relative Cost Writing Reuse (RCWR): Additional Development Cost (ADC):
Error Rate (errors/kLOC): Organizational ROI:
Cost per Error ($/Error):


Look here for the Advanced "ReuCalc" Calculator for use by large projects


Explanation of Reuse Metric Terms

Additional Development Cost (ADC)
The cost your organization incurred by writing reusable software for use by other organizations or projects. We calculate ADC by multiplying the historical cost to develop new code by the amount of code written for reuse and adjusting based on the RCWR. For example, with an RCWR = 1.5, the ADC represents an additional cost of 50% over new development.

Cost Avoidance
The financial benefit resulting from not having to expend resources. By reusing software, an organization avoids a cost proportional to the cost of having to develop that software new.

Cost Avoided by Others (ORCA)
The total financial benefit that other organizations experience by reusing your software.

Cost per Error
Your organization's historical cost to fix errors after releasing new software to the customer, in dollars per error. We recommend obtaining this value from your contracts or financial planning group; otherwise use $10,000/error as a default value. Uses dollars ($) for units.

Development Cost Avoidance (DCA)
The cost your organization avoided during the development phase of the project by reusing software. DCA combines with Service Cost Avoidance to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate DCA by multiplying the historical cost to develop new code by the amount of reused code (RSI) and adjusting based on the RCR. For example, with an RCR = 0.2, the DCA represents an 80% savings over new development. Uses dollars ($) for units.

Error Rate
The historical error rate in new software developed by your organization, in errors per thousand lines of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use 0.5 errors/kLOC as a default value. Uses errors per thousand lines of code (errors/kLOC) for units.

External Reuse
Use of software from another organization or application; we count external reuse in our economic models.

Internal Reuse
Use of software within an organization; a normal procedure in software development that does not count as reuse.

Lines of Code (LOC)
(1) A logical line of code in a programming language source file, informally counted by the number of semi-colons in the code and formally counted according to rules established by organizations or code analysis tools. (2) An indicator of overall effort on a program.

New or Changed Source Instructions
The amount of software your organization actually wrote or modified for use only on this application (do not include Source Instructions Written for Reuse by Others). Uses lines of code (LOC) for units.

New Development Cost (Cost/LOC)
The historical cost to develop new software in your organization, in dollars per line of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use the industry average of $100/LOC as a default value. Uses dollars ($) for units.

Organization (of people)
A programming team, department, or other autonomous group with software development responsibility. Many organizations may contribute to software development on a large project.

Organizational ROI
The total financial benefit to the project due to your organization's reuse effort. We calculate Organizational ROI by subtracting your Additional Development Cost (ADC) from your Reuse Cost Avoidance (RCA). Uses dollars ($) for units.

Productivity Index
A metric that shows how an organization changes productivity through reuse relative to an organization that does not participate in reuse, which has a productivity index equal to 1.

Project
A large software development effort, typically made up of many organizations.

Reengineering
The use of existing software in a new application, after modifying the software.

Relative Cost of Reuse (RCR)
The portion of the effort that it takes to reuse a component without modification versus writing it new. The RCR can vary depending on several factors and range from about .03 up to about 0.4. We recommend an RCR = 0.2, which means that it takes about 20% of the effort to reuse software as it takes to write it new.

Relative Cost of Writing for Reuse (RCWR)
The portion of the effort that it takes to write a reusable component versus writing it for one-time use only. The RCWR can vary depending on several factors and can range from about 1.0 up to about 2.2. We recommend an RCWR = 1.5, which means that it takes about 50% additional effort to write reusable software.

Reusability
The attributes or characteristics of software that affect a developer's ability to reuse the software. This calculator does not address software reusability.

Reuse
The incorporation into an application of unmodified software components obtained from other programs external to the application. These external sources typically include other applications, other organizations, and reuse libraries.

Reuse Cost Avoidance (RCA)
The total financial benefit to an organization resulting from reuse of software obtained from someplace else. Since your experience benefits both during development (because you don't have to write the code) and during maintenance (because you don't have to fix errors in the code) the RCA equals the sum of Development Cost Avoidance (DCA) and Service Cost Avoidance (SCA). Uses dollars ($) for units.

Reuse Level
The portion of a program coming from reused software, generally expressed as a percent of the total source lines for the program.

Reuse Leverage
An indicator of the multiplier effect of reuse, used as a productivity index.

Reuse%
The indicator of reuse level based on the definition of RSI.

Reused Source Instruction (RSI)
Software that complies with the reuse definition (counting rules) adopted by IBM, etc. See the reference below for a detailed discussion. Uses lines of code (LOC) for units.

Reuse Value Added (RVA)
A productivity index based on both the amount of reuse achieved by an organization and the amount of the organization's software actually reused by other organizations. We calculate the RVA by dividing the total amount of an organization's software in service by the amount of software the organization maintains.

Service Cost Avoidance (SCA)
The cost your organization avoided during the maintenance phase of the project by reusing software. SCA combines with Development Cost Avoidance (DCA) to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate SCA by multiplying your organization's historical error rate by the historical cost to fix those errors and by the amount of reused code (RSI). Uses dollars ($) for units.

Source Instructions Reused by Others (SIRBO)
The total amount of software produced for reuse by your organization that other organizations actually reuse. Calculated by taking the sum of your Source Instructions Written for Reuse by Others over every occurrence of its use. Uses lines of code (LOC) for units.

Source Instructions Written for Reuse by Others (WRO)
The amount of software your organization wrote for reuse (reusable code). This software took extra effort to write, and therefore represents an investment in reuse. Uses lines of code (LOC) for units.

Total Source Instructions
The total number of lines of code in the application delivered by your organization. Calculated by taking the sum of New or Changed Source Instructions, Reused Source Instructions (RSI), and Source Instructions Written for Reuse by Others. Uses lines of code (LOC) for units.

Reference:

Poulin, Jeffrey S. Measuring Software Reuse: Principles, Practices, and Economic Models. Addison-Wesley (ISBN 0-201-63413-9), Reading, MA, 1997.

Reference: Poulin, Jeffrey S. Measuring Software Reuse: Principles, Practices, and Economic Models. Addison-Wesley (ISBN 0-201-63413-9), Reading, MA, 1997. Developed by Jeff S. Poulin.

Recommended Reuse Metrics

JavaScript enabled browser required!

Advanced "ReuCalc" Calculator

For projects that consist of many organizations (or applications), use this calculator to find the total level of reuse and estimate the reuse benefits. Use a row of the table for each organization or application. On the left side of the calculator, put the organization or application name, the amount of software reused, and the amount of software written for others to reuse, and the amount of new or changed software written by that organization. The calculator will add these values (TSI) and fill in the reuse metrics for each organization on the right side of the table. The totals for the project will appear in the last row. Click on highlighted terms for help.

PROJECT DATA

 

REUSE METRICS

#

Application

RSI LOC

LOC WRO

New LOC

TSI LOC

Reuse %

RCA($)

ADC($)

ROI($)

 

1

 

2

 

3

 

4

 

5

 

6

 

7

 

8

 

9

 

 

Totals:

 

The table below contains recommended default values needed to calculate the reuse metrics. The first row of this table contains the name of the organization (or application) you entered above. If you wish to use any value other than the default values provided, simply change them below.

PARAMETERS

#

Application

RCR

RCWR

$/Error

Error Rate

$/LOC

1

2

3

4

5

6

7

8

9

Explanation of Reuse Metric Terms

Additional Development Cost (ADC)

The cost your organization incurred by writing reusable software for use by other organizations or projects. We calculate ADC by multiplying the historical cost to develop new code by the amount of code written for reuse and adjusting based on the RCWR. For example, with an RCWR = 1.5, the ADC represents an additional cost of 50% over new development.

Cost Avoidance

The financial benefit resulting from not having to expend resources. By reusing software, an organization avoids a cost proportional to the cost of having to develop that software new.

 

Cost Avoided by Others (ORCA)

The total financial benefit that other organizations experience by reusing your software.

 

Cost per Error

Your organization's historical cost to fix errors after releasing new software to the customer, in dollars per error. We recommend obtaining this value from your contracts or financial planning group; otherwise use $10,000/error as a default value. Uses dollars ($) for units.

 

Development Cost Avoidance (DCA)

The cost your organization avoided during the development phase of the project by reusing software. DCA combines with Service Cost Avoidance to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate DCA by multiplying the historical cost to develop new code by the amount of reused code (RSI) and adjusting based on the RCR. For example, with an RCR = 0.2, the DCA represents an 80% savings over new development. Uses dollars ($) for units.

 

Error Rate

The historical error rate in new software developed by your organization, in errors per thousand lines of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use 0.5 errors/kLOC as a default value. Uses errors per thousand lines of code (errors/kLOC) for units.

External Reuse

Use of software from another organization or application; we count external reuse in our economic models.

Internal Reuse

Use of software within an organization; a normal procedure in software development that does not count as reuse.

Lines of Code (LOC)

(1) A logical line of code in a programming language source file, informally counted by the number of semi-colons in the code and formally counted according to rules established by organizations or code analysis tools. (2) An indicator of overall effort on a program.

 

New or Changed Source Instructions

The amount of software your organization actually wrote or modified for use only on this application (do not include Source Instructions Written for Reuse by Others). Uses lines of code (LOC) for units.

 

New Development Cost (Cost/LOC)

The historical cost to develop new software in your organization, in dollars per line of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use the industry average of $100/LOC as a default value. Uses dollars ($) for units.

 

Organization (of people)

A programming team, department, or other autonomous group with software development responsibility. Many organizations may contribute to software development on a large project.

 

Organizational ROI

The total financial benefit to the project due to your organization's reuse effort. We calculate Organizational ROI by subtracting your Additional Development Cost (ADC) from your Reuse Cost Avoidance (RCA). Uses dollars ($) for units.

Productivity Index

A metric that shows how an organization changes productivity through reuse relative to an organization that does not participate in reuse, which has a productivity index equal to 1.

Project

A large software development effort, typically made up of many organizations.

Reengineering

The use of existing software in a new application, after modifying the software.

 

Relative Cost of Reuse (RCR)

The portion of the effort that it takes to reuse a component without modification versus writing it new. The RCR can vary depending on several factors and range from about .03 up to about 0.4. We recommend an RCR = 0.2, which means that it takes about 20% of the effort to reuse software as it takes to write it new.

 

Relative Cost of Writing for Reuse (RCWR)

The portion of the effort that it takes to write a reusable component versus writing it for one-time use only. The RCWR can vary depending on several factors and can range from about 1.0 up to about 2.2. We recommend an RCWR = 1.5, which means that it takes about 50% additional effort to write reusable software.

Reusability

The attributes or characteristics of software that affect a developer's ability to reuse the software. This calculator does not address software reusability.

Reuse

The incorporation into an application of unmodified software components obtained from other programs external to the application. These external sources typically include other applications, other organizations, and reuse libraries.

 

Reuse Cost Avoidance (RCA)

The total financial benefit to an organization resulting from reuse of software obtained from someplace else. Since your experience benefits both during development (because you don't have to write the code) and during maintenance (because you don't have to fix errors in the code) the RCA equals the sum of Development Cost Avoidance (DCA) and Service Cost Avoidance (SCA). Uses dollars ($) for units.

Reuse Level

The portion of a program coming from reused software, generally expressed as a percent of the total source lines for the program.

Reuse Leverage

An indicator of the multiplier effect of reuse, used as a productivity index.

 

Reuse%

The indicator of reuse level based on the definition of RSI.

 

Reused Source Instruction (RSI)

Software that complies with the reuse definition (counting rules) adopted by IBM, etc. See the reference below for a detailed discussion. Uses lines of code (LOC) for units.

 

Reuse Value Added (RVA)

A productivity index based on both the amount of reuse achieved by an organization and the amount of the organization's software actually reused by other organizations. We calculate the RVA by dividing the total amount of an organization's software in service by the amount of software the organization maintains.

 

Service Cost Avoidance (SCA)

The cost your organization avoided during the maintenance phase of the project by reusing software. SCA combines with Development Cost Avoidance (DCA) to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate SCA by multiplying your organization's historical error rate by the historical cost to fix those errors and by the amount of reused code (RSI). Uses dollars ($) for units.

 

Source Instructions Reused by Others (SIRBO)

The total amount of software produced for reuse by your organization that other organizations actually reuse. Calculated by taking the sum of your Source Instructions Written for Reuse by Others over every occurance of its use. Uses lines of code (LOC) for units.

 

Source Instructions Written for Reuse by Others (WRO)

The amount of software your organization wrote for reuse (reusable code). This software took extra effort to write, and therefore represents an investment in reuse. Uses lines of code (LOC) for units.

 

Total Source Instructions

The total number of lines of code in the application delivered by your organization. Calculated by taking the sum of New or Changed Source Instructions, Reused Source Instructions (RSI), and Source Instructions Written for Reuse by Others. Uses lines of code (LOC) for units.


Reference:

Poulin, Jeffrey S. Measuring Software Reuse: Principles, Practices, and Economic Models. Addison-Wesley (ISBN 0-201-63413-9), Reading, MA , 1997.


Jeff Poulin owns this page.

Service Offerings

Strategy & Management

  • Reuse Business Strategy
  • Reuse Management Training
  • Reuse Legal Issues

People

  • Reuse Organizational Structures
  • Reuse Staffing
  • Reuse Engineer Training

Processes

  • Reuse Adoption and Institutionalization Process
  • Reuse Processes for Producing, Brokering, and Consuming

Measurement

  • Reuse Assessment
  • Reuse Metrics
  • Reuse Economics

Assets

  • Guidelines for Reusability

Technology

  • Reuse Libraries and Tools
  • Domain Analysis

Detailed Description of Service Offerings



Reuse Business Strategy

  • Guidance in deciding on, deliberately choosing, and implementing reuse as a software development strategy. Presentation of Case Study Data on the improved quality, productivity, and shortened time to market (reduced cycle time) achieved through successful software reuse.


Reuse Management Training

  • Training for all management levels and disciplines, covering the definition of software reuse; the evolution of the reuse concept, the benefits and costs of reuse; critical success factors; overcoming obstacles to successful reuse; the strategic and competitive role of reuse in the organization; implementation strategies for successful reuse; organizational structures for successful reuse, the role of finance in successful reuse; the need for internal marketing to support the reuse effort; legal issues; and measurement and tracking of the impact of reuse on the organization and its strategic and tactical goals.


Reuse Legal Issues

  • Education of organizations with respect to legal rights, liabilities, and obligations of reusing and leveraging software.


Reuse Organizational Structures

  • Identification and implementation of appropriate reuse organization structures through a reuse organizational framework and case studies of seven reuse programs.


Reuse Staffing

  • Determination of organizational roles, responsibilities, training, and incentive mechanisms needed to achieve successful reuse. Development of appropriate selection criteria for personnel, educational requirements, and motivational techniques for implementing and sustaining successful reuse.


Reuse Engineer Training

  • Training for engineers covering reuse processes, design for reuse, design with reuse, reuse metrics, reuse libraries and tools.


Reuse Adoption and Institutionalization Process

  • Mentoring an organization through the process of adopting and institutionalizing software reuse. This includes the activities of deciding on reuse, planning for reuse, creating a vision for reuse, developing and executing an implementation strategy and measuring success.


Reuse Processes

  • Baselining the organization's current processes and developing a plan for reengineering these processes to support software reuse. Such processes would enable the production, consumption and brokering of reusable assets.


Reuse Assessment

  • Implementation of a Reuse Assessment, an analytical and diagnostic method for collecting both qualitative and quantitative data on software development with reusable assets. The assessment benefits the participating organization by providing an analysis of the reuse infrastructure, and a set of recommendations for improving the organization's reuse program. For more detailed information, click here.


Reuse Metrics

  • - Framework Identification of metrics, including economic, library, process, product, and asset metrics, to measure the effectiveness of reuse and the impact of reuse on the organization's goals and objectives.

    - Case Study Data Presentation of data on the improved quality, productivity, and shortened time to market (reduced cycle time) achieved through software reuse. Also available are data on the additional development and documentation effort required by phase to create a reusable asset.


Reuse Economics

  • - Cost/Benefit Analysis Determination of whether a reuse program is economically viable for the organization at this time; which reusable assets should be created; and the sequence that they should be created. Creation and application of reuse economic models to determine the cost/benefit, return-on-investment, payback, and breakeven times of a reuse asset or program.

    - Funding and Pricing Identification of appropriate funding techniques ranging from charge-per-reuse to a centrally charged system. Determination of appropriate transfer prices, charges and financial incentives among internal organizations for an assembled product or service, for reuse across organizations.


Guidelines for Reusability

  • Description of guidelines for enhancing and developing software with reusability.


Reuse Libraries and Tools

  • Implementing and planning an organizational reuse library. Determining the appropriate representation method, search and display scheme, configuration management and entry/exit criteria. Description of the advantages and disadvantages of tools that enable reuse such as application templates, generators, and subroutine libraries.


Domain Analysis

  • Describing the role of domain analysis in software reuse and comparing various domain analysis approaches.


Reuse Needs Assessment

Overview
The Lombard Hill Group offers a reuse needs assessment which 1) benchmarks an organization's current reuse practices; 2) qualitatively evaluates the potential for reuse; and 3) identifies the organizational reuse areas for improvement.


The Reuse Needs Assessment
The Reuse Needs Assessment is an analytical and diagnostic tool for collecting both qualitative and quantitative benchmark data on software development with reusable assets. The assessment benefits the reuse program by analyzing the management, personnel, metrics, technology, process, and reusable asset aspects of the reuse infrastructure; qualitatively identifying roadblocks to reuse as well as further reuse opportunities; benchmarking the costs/benefits of reusable assets, and determining the current levels of reuse by artifact in the organization. A representative sample of the deliverables from this Assessment follows. (Note: Unless otherwise noted, the data shown below is hypothetical but representative of actual data from past Assessments.)

Reuse Needs Analysis
Using hypothetical data, the keviat chart in figure 1, Reuse Needs Assessment Results, compares the respondents' ratings of how important an area is to software reuse to how well the organization has performed in this area.


Figure 1

The chart in figure 1 is based on responses to standardized questions answered by the target organization staff during the Reuse Needs Assessment process. The information from this chart provides an overview of the target organization and summarizes quantitative findings of the reuse needs assessment.

Further information on the organization's status within each of the six areas of software reuse is also available and presented when relevant. For example, in figure 2, more detailed ratings are provided for a subset of the management category, the overall investigation. Shown are the ratings for two of multiple questions that constitute the overall investigation subcategory.


Figure 2

Reuse Gap Analysis
Gap analysis is useful as a tool to identify reuse areas which require attention. As shown in figure 3, the performance rating of a given area is mapped against its importance rating. For example, the reuse areas in the northwest quadrant of the matrix are areas which are rated highly in importance but rated low in terms of current performance. These are the areas on which an organization's efforts should be focused, in order to migrate them to the northeast quadrant.


Figure 3

Reuse Metrics and Economics
If data is available from the organization, the Reuse Needs Assessment can optionally calculate the improved quality, increased productivity and shortened cycle time from reuse. For example, we determined for one reuse program that quality had improved by 24%, productivity had increased by 40% and the time-to-market had been reduced by 42% through software reuse. In addition, the Reuse Needs Assessment determines the cost/benefit of producing and reusing a reusable asset (not shown).

The Reuse Needs Assessment Process
Following are the steps of the Reuse Needs Assessment:

1) Identify target organization
2) Coordinate tasks with pilot project to undergo assessment
3) Gather initial information and deliver preliminary questionnaire and metric worksheets
4) Conduct assessment interviews
5) Analyze data and present findings
6) Create and deliver Reuse Needs Assessment report to organization (optional)

Benefits
The Reuse Needs Assessment benchmarks organizations that are considering or currently conducting reuse. When data is available, the assessment benefits the organization by:

  • Identifying Reuse Improvement opportunities in six major reuse areas: Management, Personnel, Metrics, Technology, Process, and Reusable Assets

  • Qualitatively evaluating the potential for reuse

  • Determining the Reuse Economics

  • Benchmarking the level of reuse, the improved quality, productivity and shortened Time-to-Market resulting from reuse (optional)

  • Documenting the additional producer effort by phase to create reusable assets (optional)

  • Identifying differences in producer and consumer perceptions (optional)

Seminar Offerings

Does Your Reuse Program Measure Up?: Reuse Assessment, Economics and Metrics

Abstract

Attendees will be provided an overview and analysis of effective methods in three key reuse areas. Specifically, they will learn:



  • What a reuse assessment is, its objectives, the process of conducting an assessment, tools which can be used in the assessment, and how its use can optimize reuse within an organization.
  • What the benefits and costs of software reuse are, how to conduct a cost/benefit analysis for reuse, and some economic results from applying the cost/benefit model in several organizations.
  • Why organizations should measure, a framework for reuse metrics, a process for measuring reuse, what and how a core set of reuse metrics can facilitate institutionalization of a reuse program.


  • This tutorial offers an indepth analysis of some of the major concepts and tools necessary for adopting, tracking, evaluating, and improving upon a reuse program. The session will begin with an overview of a reuse adoption and institutionalization model. We will then focus on three specific concepts, reuse assessment, economics, and metrics, and show how each fits into the context of the model, and facilitates reuse institutionalization. We will discuss each concept in detail, including its importance within the reuse process, its implementation within the organization, and its proper use for furthering reuse goals. We will illustrate these concepts using industry examples whenever possible.

Outline

INTRODUCTION

  1. Reuse Definitions used in the tutorial
  2. A Reuse Adoption and Institutionalization Model
  3. Where do Reuse Assessments, Economics and Metrics Fit in?

CONDUCTING A REUSE ASSESSMENT

  1. What is a Reuse Assessment?
  2. Objectives of the Reuse Assessment
  3. The Reuse Assessment Process
  4. Reuse Assessment Tools

ECONOMICS OF REUSE

  1. Benefits and Costs of Software Reuse
  2. A Cost Justification Model For Software Reuse
  3. How to Conduct a Cost/Benefit Analysis
  4. Economic Results

SOFTWARE REUSE METRICS

  1. The Rationale for Reuse Metrics
  2. Key Considerations in Measuring Reuse
  3. A Framework for Reuse Metrics
  4. A Process for Identifying Appropriate Metrics
  5. Use of a Core Set of Metrics


Length

Half day


Managing Software Reuse: A Case-Based Tutorial

Abstract

Utilizing the case method, attendees will be provided an overview and analysis of effective methods in several key areas. Specifically, they will learn:



  • How to initiate a reuse program, reuse adoption and institutionalization models, the possible roles of a corporate reuse program, and how to select pilot projects.
  • How to investigate reuse, how reuse can support or drive organizational strategy, what the benefits and costs of software reuse are, how to conduct a cost/benefit analysis for reuse, and some economic results from applying the cost/benefit model in several organizations.
  • How to plan for reuse, how some organizations are creating a reuse vision/mission statement, how to organize and staff the reuse program, how to fund a reuse program, why organizations should measure, how to market software reuse, and what some of the legal and contractual issues are.
  • How to implement the reuse plan, technology transfer and change management issues and choosing a conversion strategy.


  • This tutorial is an interactive, case-based seminar on establishing a software reuse program for your organization. This tutorial will cover the definition of software reuse and the evolution of the reuse concept, its benefits and costs, its obstacles and critical success factors, its strategic role in the organization, implementation strategies, staffing,organizing, financing, and marketing the reuse effort, legal issues, and measurement and tracking of the impact of reuse on the organization. Prior to the seminar, attendees are asked to read a case of an organization attempting to implement reuse.

1.INTRODUCTION

  1. The Software Development Challenge
  2. Reuse Definitions
  3. Evolution of the Software Reuse Concept
  4. Reuse Adoption and Institutionalization Models

2. INITIATING SOFTWARE REUSE

  1. Role of a Corporate Reuse Program

3. INVESTIGATING SOFWARE REUSE

  1. Benefits and Costs of Reuse
  2. Inhibitors to Reuse
  3. Critical Success Factors
  4. Deciding on Reuse as a Strategy

4. PLANNING FOR SOFTWARE REUSE

  1. Staffing
  2. Organizing
  3. Financing
  4. Measurement and Tracking
  5. Marketing
  6. Legal and Contractual

5. IMPLEMENTING SOFTWARE REUSE

  1. Technology Transfer
  2. Change Management
  3. Conversion Strategy


Length

Half day


Product Offerings

To purchase surveys, go to the registration page

A Survey of Reuse Prologues

Lombard Hill Group Report No: AP-12000

This survey identifies twelve reuse prologues developed by both the private and public sectors. A prologue is a description of the information elements included with each software component.



A Survey of Reuse Economic Models

Lombard Hill Group Report No: AP-12001

This report baselines reuse economic modeling by surveying and comparing seventeen economic models and presenting conclusions and recommendations for further research. Each model is described in its original terminology and translated using a common lexicon. The analyses indicate a great deal of commonality among the set of models. While this may indicate that researchers are arriving at similar models independently, it may also suggest that we should direct our efforts at forging new ground in reuse economics. Five areas for further research in reuse economics are recommended, and general guidelines for helping organizations decide on a suitable economic model are discussed. The 'Reuse Cost Calculator' spreadsheet that is now being bundled with the report was developed by the Data and Analysis Center for Software (DACS) (www.thedacs.com) as part of their Gold Practices Initiative. The DACS is a DoD-sponsored Information Analysis Center (IAC) administratively managed by the Defense Technical Information Center (DTIC). The DACS is technically managed by the Air Force Research Laboratory (AFRL) in Rome, NY and operated by ITT Industries, Advanced Engineering and Sciences.

Managing Software Reuse

ISBN 0135523737

Your copy may be ordered from amazon.com or a bookstore near you.



Managing Software Reuse is a comprehensive, step-by-step, guidebook to an integrated approach for investigating, planning, and implementing software reuse. With the reuse potential and aptitude model, the author shows when reuse should not be implemented in an organization and illustrates the case with reuse failures. He introduces the forward-thinking concept of Strategy-driven reuse, the deliberate choice and implementation of reuse for gaining competitive advantage. Examples and data from real-life reuse programs in companies such as Hewlett-Packard, IBM, GTE, Nippon Telegraph and Telephone Corporation, and First Boston are used to highlight key concepts. A useful outline is provided for the reader to create a reuse infrastructure and implementation plan.

Managing Software Reuse is an invaluable reference and includes the world's most extensive collection of surveys on reuse adoption strategies (eleven strategies), success factors (five studies), economic models (seventeen models), reuse maturity models (seven models), assessments (nine assessments), organizational structures (seven structures), metrics, processes (ten processes), domain analyses approaches (nine approaches), reusability guidelines (nine guidelines), prologues (five prologues), and certification levels (eight examples).

Included in the book is an extensive list and description of companies reusing software in the aerospace, banking, computer and electronic equipment, information systems and business applications, analytical instruments, insurance, manufacturing, pharmaceuticals, telecommunications, transportation, and utilities industries.

Managing Software Reuse shows exactly how to:

  • utilize an adoption model to systematically institutionalize reuse
  • select pilot projects that pave the way for wide deployment of reuse
  • perform a cost-benefit analysis to determine whether reuse is economically viable
  • harness the potential of software reuse to obtain competitive advantage
  • conduct a reuse assessment for your organization
  • create a reuse vision and mission statement to guide the reuse effort
  • organize, train, and motivate your staff to support reuse
  • identify and implement appropriate reuse metrics
  • manage the legal and contractual aspects of software reuse
  • establish processes for producing, brokering, and consuming reusable assets
  • select appropriate reuse tools for your organization

OUTLINE FOR MANAGING SOFTWARE REUSE:

I. INTRODUCTION
1. THE SOFTWARE DEVELOPMENT CRUNCH
2. SOFTWARE REUSE - DEFINITION, SCOPE AND FRAMEWORK
3. EVOLUTION OF THE SOFTWARE REUSE CONCEPT
4. MAJOR TRENDS IN REUSE
5. REUSE IN INDUSTRY
6. ORGANIZATIONAL REENGINEERING FOR REUSE: A REUSE ADOPTION AND INSTITUTIONALIZATION MODEL
Appendix 6-A: A Survey of Reuse Adoption Strategies

II. INITIATING REUSE
7. THE ROLE OF A CORPORATE REUSE PROGRAM
8. IDENTIFYING REUSE POTENTIAL AND APTITUDE
Appendix 8-A: A Survey of Prior Research on Reuse Success Factors
9. SELECTING PILOT PROJECTS

III. INVESTIGATING REUSE
10. REUSE INVESTIGATION
11. BENEFITS AND COSTS OF SOFTWARE REUSE
12. A COST JUSTIFICATION MODEL FOR SOFTWARE REUSE
Appendix 12-A: A Survey of Reuse Economic Models
13. DECIDING ON REUSE AS A STRATEGY
Appendix 13-A: A Survey of Reuse and Maturity Models
14. CONDUCTING A REUSE ASSESSMENT
Appendix 14-A: A Survey of Reuse Assessments

IV. PLANNING FOR SOFTWARE REUSE
15. A REUSE VISION AND MISSION STATEMENT
16. STAFFING FOR SOFTWARE REUSE
17. ORGANIZATIONAL STRUCTURES FOR SOFTWARE REUSE
Appendix 17-A: A Survey of Prior Research on Reuse Organizational Structures
18. FINANCE AND ACCOUNTING FOR A REUSE PROGRAM
19. REUSE METRICS
Appendix 19-A: A Survey of Reuse Metrics
20. MARKETING REUSABLE SOFTWARE
21. LEGAL AND CONTRACTUAL ISSUES OF SOFTWARE REUSE
22. MANUFACTURING REUSABLE SOFTWARE

V. PROCESSES AND TOOLS
23. REUSE PROCESSES
Appendix 23-A: A Survey of Reuse Processes
Appendix 23-B: A Survey of Domain Analysis Approaches
Appendix 23-C: A Survey of Reusability Guidelines
24. REUSE TOOLS
Appendix 24-A: A Survey of Information Elements (Prologues)
Appendix 24-B: A Survey of Certification Levels

VI. IMPLEMENTING SOFTWARE REUSE
25. IMPLEMENTATION STRATEGY

VII. MONITORING AND CONTINUOUS IMPROVEMENT
26. MONITORING AND CONTINUOUSLY IMPROVING THE REUSE PROGRAM

VIII. FUTURE TRENDS
27. FUTURE TRENDS

APPENDIX A. A REUSE INFRASTRUCTURE AND IMPLEMENTATION PLAN OUTLINE
APPENDIX B: SOFTWARE REUSE LEXICON

.

Clients include:

Articles

What is Software Reuse?

Software reuse is the use of existing assets in some form within the software product development process. More than just code, assets are products and by-products of the software development life cycle and include software components, test suites, designs and documentation. Leverage is modifying existing assets as needed to meet specific system requirements.
Read More

Applying Cluster Analysis to Software Reuse

Cluster analysis is "concerned with grouping of objects into homogeneous clusters (groups) based on the object features. [Kusi]" Cluster analysis was applied to software reuse at the Manufacturing Productivity (MP) section of the Software Technology Division of HP to solve a problem concerning the maintenance of their reusable assets, called "utilities".
Read More

What is Software Reuse?





PURPOSE

The purpose of this document is to provide a brief introduction to software reuse. It defines software reuse and its basic mechanics, describes what motivates organizations to pursue reuse and how the engineer's and manager's tasks will change with reuse, and explains how to get started in reuse. If you feel that you would like more information after having read this document.



WHAT IS SOFTWARE REUSE?

Software reuse is the use of existing assets in some form within the software product development process. More than just code, assets are products and by-products of the software development life cycle and include software components, test suites, designs and documentation. Leverage is modifying existing assets as needed to meet specific system requirements. Because reuse implies the creation of a separately maintained version of the assets, it is preferred over leverage.

Current thinking is that reuse is most effective when it is practiced systematically. Systematic reuse is when reuse of assets is planned with well-defined processes and life cycles, commitments for funding, staffing, and incentives for production and use of the reusable assets.

Reuse can be achieved through different modes. Compositional reuse involves constructing new software products by assembling existing reusable assets, while generative reuse involves the use of application generators to build new applications from high level descriptions.

Leveraging involves the modification of previously developed software for a new product. When managed correctly, leveraging can be advantageous over creating software from scratch in that it requires less time and effort. On the other hand, because it is difficult to correctly predict the impact of modifications, leveraging may result in lower quality software. It can also lead to multiple versions of a software component and consequently, an increased maintenance burden.



MOTIVATIONS FOR REUSE

Today's organizations face competitive pressures in shortening the time required to bring a product to the market, reducing software development and maintenance costs, and increasing the quality of their software. While not a panacea, organizations have increasingly turned to a reuse strategy in order to meet their business goals. Implemented appropriately, reuse can aid in achieving some or all of the following goals:

* Increase productivity

After an initial investment, reuse of existing assets will enable projects to decrease the cost of developing and maintaining software. Hewlett-Packard (HP) reuse projects have reported productivity increases from 6 to 40%.

* Shorten time-to-market

By reusing software to shorten the critical path in delivering a product, organizations within HP have reported a reduction in time-to-market from 12 to 42%.

* Improve software quality

Software that has been used multiple times will possess fewer defects than freshly coded components. One HP organization had mature reused code that had a defect density which was ten times better than new code. Quality improvements in HP products from reuse have ranged from 24 to 76%.

* Provide consistency and interoperability across products

Standard interfaces and common use of components across products facilitates ease of use and interoperability. For example, when several software products reuse the same user interface scheme, terms and conventions are used consistently. Reuse also contributes to interoperability. For example, when a component that contains an error-message handling routine is reused by several systems, these systems can expect consistent behavior.

* Ensure product/system conformance with user requirements through prototyping

Because the availability of reusable components facilitates prototyping, user requirements may be more easily validated. This prototyping will also enable detection and resolution of defects earlier in the software life cycle - avoiding more costly fixes later in the life cycle.

* Reduce risk

Risk in creating new software is reduced when available reusable components already encompass the desired functionality and have standard interfaces to facilitate integration.

* Leverage technical skills and knowledge

Reuse enables specialists to optimize software architectures and assets which may then be reused by others who are focussing on meeting product features and market needs.

* Improve functionality and/or performance

Reuse allows for the investment of time to improve functionality and/or performance. Because this time can be amortized over multiple uses of the assets, this investment for such improvements is more economically justified than the case where they would only be for single product.



PROCESS OF REUSE

Experience has shown that reuse is not merely creating a repository, having engineers deposit assets and hoping that other engineers will reuse the repository's contents. Rather, successful implementation of reuse requires an infrastructure to support reuse. A critical aspect of the infrastructure is the process of reuse.

In its simplest form, the process of reuse consists of four major activities: manage the reuse infrastructure (MRI), produce reusable assets (PRA), broker reusable assets (BRA) and consume reusable assets (CRA). A few terms are defined to facilitate our discussion: Producers are those who create reusable assets with the specific goal of reusability. Consumers are those who use reusable assets to produce enduser products or further reusable assets. Each of the four major activities are now briefly defined.

The function of Manage the Reuse Infrastructure (MRI) is to establish the reuse rules, roles, and goals in the infrastructure to support reuse. MRI drives the reuse process. This includes designating conventions and standards; approving additions, deletions, and changes to the library; commissioning component construction; coordinating schedules and resources and aligning reuse goals to business goals. This function also establishes and awards incentives, interprets metrics data, and implements economic models. Overall, MRI is responsible for the planning of the reuse effort.

The Produce Reusable Assets (PRA) activity develops, generates, or reengineers assets with the specific goal of reusability. PRA includes domain analysis and domain engineering. Domain Analysis is the process of identifying, collecting, organizing, analyzing and representing the commonality and variability among systems in an application domain and software architecture from the study of existing systems, underlying theory, emerging technology and development theories within the domain of interest. Domain Engineering is the construction of components, methods, and tools and their supporting documentation to solve the problems of system/subsystem development by the application of the knowledge in the domain model and software architectures.

The Broker Reusable Assets (BRA) activity aids the reuse effort by qualifying or certifying, configuring, maintaining, promoting and brokering reusable assets. This process also includes classification and retrieval for assets in the reuse library.

The Consume Reusable Assets (CRA) activity occurs when systems are produced using reusable assets. Users utilize the library and associated tools to gain an understanding of the reusable assets available to them; identify and retrieve needed components; integrate the components into their system; and provide feedback to the librarian on existing and needed components.



ENGINEER'S TASKS

Reuse requires new job roles and different tasks for the engineer. This will be illustrated with an analogy to the task of home construction. The advent of prefabricated parts for home construction has provided home builders with a less costly alternative to construction from scratch. Home builders can rely upon standard parts which may be used to construct homes in a much shorter time than historically possible. However before such prefabricated parts are made available to the home builder, they must be specified, designed and created.

Analogously, one of the roles necessary with reuse is the producer engineer who creates the reusable assets. Among, the changes that the producer engineer will find in the task of creating reusable software relative to regular software product development are:

* Increased design time

In constructing prefabricated home parts, designing a door for a single instance of use is generally less complex than designing one that would accommodate usage for several rooms in a home or in several types of homes. Likewise, designing software for a one time use generally takes less time than that required to make the software reusable. The new challenge lies in designing the software for multiple products. New roles created include the domain expert and domain analyst who perform analyses to specify the requirements prior to the design of the assets. A is a domain expert person who is very knowledgeable about a particular domain. This person will generally be aware of existing and planned products in the domain. A domain analyst extracts and analyzes information about a domain from existing components, product plans, domain experts and other sources to produce domain models.

* Understanding of multiple contexts of use

Just as a home parts builder anticipates the conditions and contexts of how a door will be used (e.g. weather conditions), the producer engineer needs to anticipate how the asset will be used in future reuses.

* Reallocation of time

Without reuse, the engineers' time is spent developing software from scratch. With reuse, user engineers spend more of their time locating, understanding and integrating reusable components.

* Increased documentation

In order to facilitate understanding and therefore reuse of software, adequate documentation is required for the user.
The consumer engineer employs the reusable assets. Just as a home builder designs a home with the knowledge of what prefabricated parts are available, the user engineer practices asset-centered design, designing a product which takes advantage of the available reusable assets. Among the changes that the user engineer will find in the task of reusing software relative to regular software product development are:

* More time allowed for innovation

Reuse allows the engineer to avoid creating redundant assets, freeing time for the innovative aspects of development.

* Greater potential for prototyping

Having an existing set of assets encourages rapid prototyping to validate end-user requirements.

Engineers may also participate in a "reuse software evolution" or steering committee. This committee is the mechanism to bring the disparate producers and consumers together to facilitate decision making regarding the evolution of the reusable assets.



MANAGER'S TASKS

New tasks and roles will also be created for the managers. All managers will need to focus not just their own projects but also on how they can contribute to the success of the organization's portfolio of projects. An essential aspect of this view is to understand that reuse is a strategic investment requiring long term commitment which will pay back in the long run.

Managers of both producer and user engineers will find themselves helping or managing efforts at identifying commonality, utilizing metrics, and conducting assessments and reviews to ensure that the necessary assets are produced and used.

The new roles of reuse sponsor, champion, or manager may also be created.

The sponsor is usually a manager(s) who authorizes and reinforces the reuse program. The primary job of the sponsor is to oversee and ensure that the reuse program has adequate resources.

The reuse champion is the individual or group who advocates and supports the reuse program. This champion, who may be a manager or engineer, is an evangelist for software reuse and has the key role of convincing and selling the reuse concept to constituencies. Successful reuse champions are usually individuals who are well-respected for their technical and personal leadership.

The reuse manager has the overall responsibility for reuse planning, managing the flow of information and assets between producers and consumers, and for ensuring that the infrastructure supports the reuse effort. This manager may be directly responsible for the mechanics of reuse or indirectly through a reuse council, steering committee or review board. An effective reuse manager has the ability and skills to understand and handle process issues, coordinate collaboration of several different organizations, recognize and balance short and long term goals, identify and solve cultural and organizational impediments, and communicate and influence at multiple managerial levels.

It is important to note that many or a single individual can serve any or all of these roles.



GETTING STARTED

A successful program in reuse starts with the recognition of reuse potential. If your organization has substantial duplication across existing or new product lines and/or within a given product, then your situation may warrant further investigation into the feasibility of reuse. Stable, mature and well-understood domains offer the best possibilities for reuse. Assuming that the necessary management and resource commitments exist, the steps to implement reuse briefly consist of:

* Assess organizational readiness

Understand the people, process, product, technology, asset, economic, metric and management facets of the organization and how reuse will impact each of these aspects.

* Identify and collect metrics

While this activity is done throughout the reuse effort as necessary, collecting metrics early will enable us to benchmark the organization and show the impact when reuse is implemented. Metrics are identified based on those business goals reuse is assisting the organization in reaching.

* Select a target set of users and pilot project

Identify a set of product efforts that may be good candidates for reuse. Factors to consider include the readiness of the engineers and managers to apply reuse, whether reusable components can be made available to them within their development schedule, etc.

* Identify domains in the organization

Enumerate a list of domains that are in common within the organization. These may include horizontal domains (e.g., graphical user interfaces, error handling) and vertical domains (e.g., manufacturing applications, medical imaging).

* Collect an inventory of existing material

Locate candidate components for each identified domain.

* Analyze the domain

An informal domain analysis may be conducted for the chosen domain. This analysis includes determining features common to systems in the domain and assessing the range of variability.

* Examine the existing organizational structure

Consider establishing an independent producer group. This would dedicate resources to ensure that the necessary assets are created, managed and supported.

* Create and manage reusable assets

Make, buy or re-engineer existing assets for users. Bring these assets under a source control and configuration management system.

* Establish a process for producing, managing and using the reusable assets

After obtaining a clear understanding of the current process for software product development, determine a process for producing, managing and using reusable assets that address the particular needs of the organization.

* Utilize tools, technology, and standards

Examine whether to create or use existing tools, technology and standards for your reuse program.

* Conduct reviews and walkthroughs to reinforce reuse

Throughout the product development life cycles, perform reviews to ensure adherence to reusability objectives.

* Pursue continuous process improvement

Continuously monitor and pursue incremental improvements to the reuse program. Explicitly solicit feedback from the users, end-users and other participants in the reuse effort.

The Lombard Hill Group provides expertise in practical implementation and improvement of software reuse programs.

Applying Cluster Analysis
to Software Reuse



Abstract
Cluster analysis, a method of classifying objects based upon specific features, has many potential benefits in software reuse. At the Manufacturing Productivity section of Hewlett-Packard, we applied such an analysis to a set of reusable assets and identified "include file" configurations that would minimize the maintenance effort of such files. In this paper, we define cluster analysis within the context of group technology and present an example of how this analysis was applied and utilized.

Keywords: cluster analysis, group technology, manufacturing concepts, domain analysis.



1. Background
The purpose of group technology in manufacturing is to utilize economies of scope by identifying and exploiting the similarities in the parts to be manufactured and the sequence of machines that are necessary for the processing of those parts. Parts are classified into families on the basis of characteristics such as size and geometry. Machines which are used to process the part families are situated in proximity to each other in "machine cells".

Wemmerlov and Hyer [Wemm] highlight three ways that group technology benefits are achieved:

* By performing similar activities together, less time is wasted in changing from one unrelated activity to the next
* By standardizing closely related items or activities, unnecessary duplication of effort is avoided
* By efficiently storing and retrieving information related to recurring problems, search time is reduced



2. Position

One of the means for family identification in group technology is cluster analysis. Cluster analysis is "concerned with grouping of objects into homogeneous clusters (groups) based on the object features. [Kusi]" Cluster analysis was applied to software reuse at the Manufacturing Productivity (MP) section of the Software Technology Division of HP to solve a problem concerning the maintenance of their reusable assets, called "utilities".

The MP section produces large application software for manufacturing resource planning. The MP reuse program started in 1983 and continues to the present. The original motivation for pursuing reuse was to increase the productivity of the engineers to meet critical milestones [Nish]. MP has since discovered that reuse also eases the maintenance burden and supports product enhancement. Reuse was practised in the form of reusable assets (application/architecture utilities and shared files) and generated code. Total code size for the 685 reusable assets was 55 Thousand lines of Non-Commented Source Statements (KNCSS). The reusable assets were written in Pascal and SPL, the Systems Programming Language for the HP 3000 Computer System. The development and target operating system was the Multi-Programming Environment (MPEXL).

The utilities at MP are many (685 utilities) and small in size (lines of code range from 14 to 619 Non-Commented Source Statements). In manufacturing systems software developed by MP, a transaction constitutes a cohesive set of activities used for inventory management and is a subunit of the manufacturing systems software.

Within each transaction, calls are made to the appropriate utilities as required which are contained in an include file specific to the transaction. However, this has led to a proliferation of different include files since each transaction is usually created by a different engineer. When a utility is modified, all the include files which contain this utility need to be identified and updated with the new version. This has resulted in a tremendous amount of effort.

In an effort to reduce the potential amount of effort required for future updates, an analysis using cluster analysis was conducted on the use of utilities by transactions.

First, a 13 x 11 matrix was created by designating the rows as transactions and the columns as utilities. (Figure 1). A "1" indicates that a transaction makes a call to the particular utility, and a "0" indicates that a transaction does not make a call to the particular utility.

Input Matrix

(Rows are transactions; columns are reusable assets)

1 0 1 0 0 0 0 0 0 0 0

0 0 1 0 0 0 0 1 0 0 1

0 0 1 0 0 0 0 1 0 0 0

0 0 0 0 0 0 0 1 0 0 1

0 0 1 0 0 0 0 0 0 0 1

0 0 1 1 0 0 0 0 0 0 1

0 0 1 0 0 0 0 0 0 0 0

0 1 0 0 1 0 1 0 0 0 1

0 1 0 0 1 0 1 0 0 0 0

0 1 0 0 1 1 1 0 1 1 1

0 1 0 1 1 1 1 0 1 1 1

0 1 0 1 0 0 1 0 0 0 1

0 1 0 1 1 0 1 0 0 0 1

Column (Reusable assets):
1=Adj-summary-qty
2=Autobofill
3=check'store'up
4=invalid-fld-check
5=potency-inv-qty
6=prep'for'pcm
7=print-document
8=report-neg-qty
9=send'to'pcm
10=update'pcm'buff
11=write-stock-file

Rows (Transactions):


1=adjhand
2=issalloc
3=isseu
4=issord
5=issunp
6=issbo
7=move
8=recinloc
9=recinsp
10=recwo
11=recrun
12=recpopt
13=recpoit


Figure 1

The matrix is then used as an input file to a clustering algorithm provided by Dr. Andrew Kusiak of the University of Iowa.

The output solution, as shown in figure 2, reorders the reusable assets into "clusters". The results suggest that we place utilities (depicted by the columns) 1, 3 and 8 into a single include file for transactions 1 to 7.

Utilities 2,5,6,7,9,10 should be placed into another include file for transactions 8,9,10,11,12,and 13.

Utilities 4 and 11 can either be placed in both include files or a separate one may be created for them.

Cluster Analysis Solution

(Rows are transactions; columns are reusable assets)

1
1
1
3
8
2
5
6
7
9
0
1
4
Row
1
1
1
2
1
1
1
3
1
1
4
1
1
5
1
1
6
1
1
1
7
1
8
1
1
1
1
9
1
1
1
10
1
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1
12
1
1
1
1
13
1
1
1
1
1

Figure 2

Benefits of Cluster Analysis for Reuse

Cluster analysis is useful in the creation of include files with specified utilities that would reduce the effort required to maintain the files. In our example with the MP section, prior to cluster analysis, thirteen individual include files were maintained; one for each transaction. By utilizing cluster analysis, we were able to identify the commonalities and differences within the thirteen include files and specify a core set of two include files. By reengineering the thirteen include files into two, the number of files to maintain can be reduced by 85%.

Cluster analysis also has further applications in software reuse. It may be used to identify "families of systems" i.e. those that share the same features. For example, we can apply cluster analysis to a matrix where the columns depict the features of software systems/products and the rows, the software systems/products. The analysis would cluster the features to the software systems/products. thereby helping to identify families of systems which share common features. This information may be useful in determining specific reusable assets to create.



3. Comparison
Some researchers have utilized cluster analysis for the purposes of reuse classification. For example, Maarek and Kaiser [Maar] describe the use of conceptual clustering to classify software components. Taxonomies of software components are created "by using a classification scheme based on conceptual clustering, where the physical closeness of components mirrors their conceptual similarity." The objects are gathered into clusters where they are more 'similar' to each other than to the members of other clusters.

Acknowledgements

My acknowledgements to Dr. Andrew Kusiak, Dr. Sylvia Kwan and Alvina Nishimoto for their help and input to this paper.

[Kusi] Kusiak, Andrew and Wing Chow, Decomposition of Manufacturing Systems, IEEE Journal of Robotics and Automation, vol. 4, no. 5.

[Maar] Maarek, Yoelle and Gail Kaiser, Using Conceptual Clustering for classifying reusable Ada code, Using Ada: ACM SIGAda International Conference, ACM Press, New York.

[Nish] Nishimoto, Alvina, "Evolution of a Reuse Program in a Maintenance Environment", 2nd Irvine Software Symposium.

[Wemm] Wemmerlov, Urban and Nancy Hyer, Group Technology, chapter 17 in Handbook of Industrial Engineering, Gavriel Salvendy, ed., John Wiley & Sons.