Assess Reuse Risks and Costs

SOFTWARE ACQUISITION GOLD PRACTICE^™

ASSESS REUSE RISKS AND COSTS

FOCUS AREA: RISK – Risk Management

Definition and Summary: The process of applying risk-management strategy, conducting complete risk and cost trade-off analysis to software acquisition and development reuse techniques, and the mapping of reuse artifacts (components, products, COTS (commercial-off-the-shelf), GOTS (Government off-the-shelf), or NDI (non-developmental item)) to domains, architectural definitions and user requirements in order to effect decisions about reuse.

The Software Engineering Body of Knowledge [SWEBOK, 2004] describes software reuse as being a key factor in maintaining and improving productivity and competitiveness in the acquisition and development of software. It goes on to say that effective software reuse requires a strategic vision that reflects the “unique power and requirements” of reuse techniques.

The implementation of software reuse embodies more than just the creation and use of asset libraries. The successful implementation of reuse requires that its techniques be formalized by integrating reuse processes and activities into the overall software life cycle. By necessity, then, effective software acquisition and development strategies must consider the influence of reuse on overall project and organization risks and costs.

There are a number of different approaches to software reuse, summarized in the figure below. While this Gold Practice will not go into significant detail on how to perform reuse, highlighting instead the benefits, risks and costs associated with it, it is important to recognize the scope of reuse opportunities that may exist.

Approaches to Software Reuse [Sommerville, 2004b]

The ability to successfully implement a reuse program, which implies a careful, strategic balancing of reuse risks and costs, can result in the following qualitative benefits:

· Increased dependability through reused software that has been tried and tested in working systems

· Reduced process risks resulting from less uncertainty in the costs of reused software vs. new development software

· Reduced product risks by reusing proven components (performance, quality, reliability) and through development consistency

· Effective use of specialists who develop reusable software that captures their knowledge for all projects, not just specific projects

· Compliance to standards, e.g., user interface standards that can be implemented as a set of standard reusable components

· Accelerated development that allows systems/products to be brought to market as early as possible, leveraging reductions from decreased development and validation time through strategic reuse

· Economies of scale in product-line reuse become achievable through domain models, reusable components and common environments

[Poulin, 1997], [Putnam, 2003], [Leach, 1997] and [Lim, 1998] have reported some of the quantitative benefits achieved through software reuse:

· Nippon Electric Company: Achieved 6.7 times higher productivity and 2.8 times better quality through 17% reuse. They improved software quality 5-10 times over a 7-year period through the use of unmodified reuse components in the domain of basic system software development and in the domain of communication switching systems.

· GTE Corporation: Saved $14 million in costs of software development with reuse levels of 14%. GTE Data Services benefited from $1.5M in cost savings in 1988 for 20-50% reuse

· Multiple Ada Projects: A study of 75 Ada projects in 15 firms totaling 30M LOC found reuse resulted in 10 times higher quality with reuse levels of 10-18%.

· Toshiba saw a 20-30% reduction in defects per line of code with reuse levels of 60%

· DEC reported cycle times that were reduced by a factor of 3-5 through reuse levels of 50-80% and an increase of 25% in productivity through software reuse

· Hewlett-Packard (HP) cited quality improvement on two projects of 76% and 24% defect reduction, 50% and 40% increases in productivity, and a 43% reduction in time to market with reuse levels up to 70%. ROI ranged from 215% for one development to 410% for the other

· Raytheon achieved a 50% productivity increase in the MIS domain from 60% reuse using COBOL

· A study of nine companies showed reuse led to 84% lower project costs, cycle time reduction of 70%, and reduced defects

· 312 projects in aerospace industry

§ Average 20% increase in productivity; 20% reduction in customer complaints; 25% reduction in time to repair; 25% reduction in time to produce the system

· Japanese industry study

§ 15-50% increase in productivity; 20-35% reduction in customer complaints; 20% reduction in training costs; 10-50% reduction in time to produce the system

· Simulator system developed for the US Navy

§ Increase of approximately 200% in number of SLOC produced per hour

· NASA Report

§ Reduction of 75% in overall development effort and cost

· AT&T reported a 50% decrease in time-to-market for 40-90% reuse

· Raytheon Missile Systems experienced a 1.5 times increase in productivity from 40-60% reuse

· SofTech had a 10-to-20 times increase in productivity for reuse greater than 75%

DESCRIPTION OF THE PRACTICE:

SUMMARY DESCRIPTION

The “Assess Reuse Risks and Costs” practice is one of the cornerstones of the Software Program Manager Network (SPMN) Best Practices platform. The practice essentials, as listed at the SPMN site, are:

The use of reuse components, COTS, GOTS, or any other non-developmental items (NDI) should be treated as a risk and managed through risk management
Application of reuse components, COTS, GOTS, or any other NDI will be made only after successful completion of a NDI acceptance inspection. This inspection needs to consider the process used to develop it, how it was document, number of users, user experience, and compliance with essential program considerations such as safety or security.
Before a decision is made to reuse a product or to acquire COTS, GOTS, or NDI, a complete cost trade-off should be made considering the full life cycle costs, update requirements, maintenance costs, warranty and licensing costs, and any other considerations which impact use of the product throughout its life cycle
All reuse products, COTS, GOTS, or NDI decisions should be based on architectural and design definitions and be traceable back to an approved user requirement
All reuse components, COTS, and COTS need to be tested individually first against program requirements and in an integrated software and system configuration prior to release for testing according to the program test plan
Reuse, COTS, GOTS, and NDI decisions will be continuously revisited as program conditions change.

The intent of the DACS Gold Practice on “Assess Reuse Risks and Costs” will focus on many of the characteristics of reuse, plus a number of techniques that can/should be used as part of a reuse strategy to assess the impact of reuse on overall risk and cost, thereby allowing projects and organizations to make informed decisions on reuse implementation. The Gold Practice is structured to first present the basic characteristics of reuse, then, in separate sections, discuss risk assessment and cost assessment as they pertain to software reuse.

DETAILED DESCRIPTION

The use of reuse components, COTS, GOTS, or any other non-developmental items (NDI) should be treated as a risk and managed through risk management
Application of reuse components, COTS, GOTS, or any other NDI will be made only after successful completion of a NDI acceptance inspection. This inspection needs to consider the process used to develop it, how it was document, number of users, user experience, and compliance with essential program considerations such as safety or security.
Before a decision is made to reuse a product or to acquire COTS, GOTS, or NDI, a complete cost trade-off should be made considering the full life cycle costs, update requirements, maintenance costs, warranty and licensing costs, and any other considerations which impact use of the product throughout its life cycle
All reuse products, COTS, GOTS, or NDI decisions should be based on architectural and design definitions and be traceable back to an approved user requirement
All reuse components, COTS, and COTS need to be tested individually first against program requirements and in an integrated software and system configuration prior to release for testing according to the program test plan
Reuse, COTS, GOTS, and NDI decisions will be continuously revisited as program conditions change.

Implementation guidelines for this practice are also listed at SPMN the site, and include the development of a Reuse Plan that provides discussion of how reused software is to be tested, verified, modified and maintained, and by whom; the integration of the Reuse Plan into a Software Development Plan that documents the approach for evaluating and enforcing reused functionality against system requirements; suggestions within the Reuse Plan for a systems engineering process that identifies software requirements by taking reusable artifacts into account; a Reuse Test Plan that identifies how reused code will be integrated and tested; assurance that accurate cost estimation is performed when integrating COTS, GOTS and in-house code into the system; and appropriate planning by the software acquirer and developer to estimate the costs associated with obtaining the necessary licenses (both development and run-time) over the system life cycle, as well as the costs incurred to maintain and support the software.

As one alternative, software reuse activities can be formally managed through the use of standards such as IEEE Std 1517-1999, “IEEE Standard for Information Technology – Software Life Cycle Processes – Reuse Processes”, which provides a basis for incorporating systematic reuse into software life cycle processes that are suitable for use with IEEE/EIA 12207, “IEEE Standard for Information Technology – Software Life Cycle Processes. The benefits of conforming to IEEE Std 1517-1999 are described [McClure, 2001] as improvement in the software life cycle processes used to develop and maintain software applications and systems; adoption of the best software reuse practices; adoption of a component-based development (CBD) approach; improvement in the quality of developed software applications and systems; decreases in software development and maintenance costs; decreases in software development and maintenance times; an understanding of software reuse terminology; increases in the competitive advantage of software applications and systems; and the ability to extend a software life cycle model to include reuse processes, activities and tasks. A supporting set of standards that may be useful in formalizing a reuse process are IEEE Std 1420.1-1995, 1420.1a-1996 and 1420.1b-1999 (R2002), “IEEE Standard for Information Technology – Software Reuse – Data Model for Reuse Library Interoperability”. This standard, and its supplements, describe information that software reuse libraries should be able to exchange in order to interchange assets. Formalizing software reuse processes is an important contributor to reducing reuse risks and costs.

The thrust of the original SPMN practice was primarily focused on software products and components. There are a number of references that relate reuse to opportunities beyond simple code reuse. Sommerville [Sommerville, 2004a and 2004b] identifies software reuse opportunities at the application system, component, and object and function levels. His approaches (see Figure 1) suggest a much wider definition than that implied by the SPMN practice. These reuse approaches are described as follows:

Design Patterns: Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions
Component-Based Development: Systems are developed by integrating components (collections of objects) that conform to component-model standards
Application Frameworks: Collections of abstract and concrete classes that can be adapted and extended to create application systems. A framework is a conceptually complete design plus an incomplete implementation. Types of frameworks include system infrastructure; middleware integration; and enterprise application.
Legacy System Wrapping: Legacy systems that can be “wrapped” by defining a set of interfaces and providing access to these legacy systems through these interfaces
Service-Oriented Systems: Systems are developed by linking shared services that may be externally provided
Application Product Lines: An application type is generalized around a common architecture so that it can be adapted in different ways for different customers. A type of application system reuse. Adaptation may involve component and system configuration; adding new components to the system; selecting from a library of existing components; or modifying components to meet new requirements.
COTS Integration: Systems are developed by integrating existing application systems. A type of application system reuse. COTS systems are usually complete application systems that offer an Application Programming Interface (API).
Configurable Vertical Applications: A generic system is designed so that it can be configured to the needs of specific system customers
Program Libraries: Class and function libraries implementing commonly-used abstractions are available for reuse
Program Generators: A generator system embeds knowledge of a particular type of application and can generate systems or system fragments in that domain. Involves the reuse of standard patterns and algorithms.
Aspect-Oriented Software Development: Shared components are woven into an application at different places when the program is compiled. Addresses a major software engineering problem (separation of concerns).

Figure 1: Approaches to Software Reuse [Sommerville, 2004b]

Ambler [Ambler, 2004], in the context of discussing reuse opportunities on a Rational Unified Process (RUP) Project, defines several categories of reuse, summarized in Table 1.

Table 1: Categories of Reuse [Ambler, 2004]

Reuse Category	Description
Architecture-Driven Reuse	· The reuse and/or development of reusable technical and business components and services described by your enterprise architecture models · Sometimes referred to as domain-component reuse
Artifact Reuse	· The reuse of previously created development artifacts: use cases; standards documents; domain-specific models procedures and guidelines; and other applications
Code Reuse	· The reuse of source code within sections of an application and potentially across multiple applications · Includes use of Web services
Component Reuse	· The reuse of pre-built, fully-encapsulated components in the development of your application
Framework Reuse	· The reuse of collections of classes that, together, implement the basic functionality of a common technical or business domain
Inheritance Reuse	· The use of inheritance in your application to take advantage of behavior implemented in existing classes
Pattern Reuse	· The reuse of publicly documented approaches, called patterns, to solving common problems
Template Reuse	· The reuse of a common set of layouts for key development artifacts – documents, models and source code – within your organization

The realm of potential reusable assets and artifacts are listed in [Lim, 1998] and [Leach, 1997] and include algorithms; architecture; classes/instances; cost models, plans and schedules; data used by programs; designs; documentation; estimates; experiential, metrics and measurement data; human interfaces; inputs to application generators; inputs to very high-level languages; intellectual capital (i.e., knowledge and expertise); interface specifications; modules; negotiations (either with customers or with software suppliers); plans; programs and common systems; reconfiguration of flexible, reusable systems; requirements; test cases; and transformation systems, filters and glueware.

Taking the concept of reuse one level higher, Lim [Lim, 1998] has defined an entire framework for reuse that encompasses both technical and non-technical characteristics. This framework is presented in Figure 2.

Figure 2: A Framework for Software Reuse [Lim, 1998]

Adoption represents the process of formally accepting and institutionalizing reuse. Topics that are directly related to reuse adoption cover technology transfer techniques and maturity models. Maturity models represent patterns showing the emergence of reuse characteristics through process growth or maturity.

A number of reuse maturity models have been developed over the years [Lim, 1998], some aligned with the SEI’s Capability Maturity Model (CMM), while others are simply meant to represent the overall scope of a reuse program. As summarized in Table 2, the Bassett model describes five reuse maturity levels through which organizations evolve. The Bollinger model is based on a 6-stage reuse scale. The Cusumano model represents a 4-level reusability spectrum. The Koltun & Hudson, Griss, REBOOT and SPC-1 (where SPC represents the Software Productivity Consortium) models all reflect five levels of reuse maturity. The SPC-2 model is based on a 4-stage reuse risk reduction growth implementation model, while the Lim model, which does not explicitly number it steps, reflects a 4-stage reuse growth implementation process.

Table 2: Reuse Maturity Models

Level	Bassett	Bollinger	Cusumano	Koltun & Hudson	Griss	REBOOT	SPC-1	SPC-2	Lim
0		Throwaway
1	Unaware	Maintenance	None	Initial Chaotic	No Reuse	Initial Chaotic	Ad Hoc	Opportunistic	Ad Hoc
2	Latent	Personal	Some	Monitored	Leverage	Repeatable	Repeatable	Integrated	Systematic
3	Project	Project	More	Coordinated	Ad Hoc Opportunistic	Defined	Portable	Leveraged	Domain-Oriented
4	Systematic	Corporate	Most	Planned	Systematic Managed	Managed	Architecture	Anticipating	Strategy-Driven
5	Cultural	Commercial		Ingrained	Domain-Specific	Optimized	Systematic

More recently, Putnam [Putnam, 2003] has presented a 6-stage evolution of the progression of reuse, presented here in Figure 3. Initially, of course, there was no reuse, followed by what he terms “Hip Pocket” reuse, meaning there was very little of it, and what there was probably performed in an ad hoc manner. Reuse from a dedicated repository was the next step in the evolution, and included costs associated with code acquisition; code development; repository operation; start-up costs; finding costs; modification costs; verification costs. Next came product-line reuse, which represents a line of software products put out by a single company division that provides an opportunity to reuse the software from one of the products in later production of the same line. Putnam also considers Enterprise Resource Planning (ERP) systems, where software packages implement the administrative functions common to many businesses, to be a form of reuse. Finally, he considers architecture-wide reuse to be the current stage in the evolution of software reuse, where components are reusable throughout the extent of a given architecture, or sometimes through many architectures (component-based software engineering or component-based development). In this stage of evolution, little new code needs to be developed and companies that specialize in component-building will supply reusable artifacts to companies building systems.

Figure 3: The Evolution of Software Reuse [Putnam, 2003]

Returning to Figure 2, the Economics block addresses the production, brokering and consumption of reuse goods and services, where cost/benefit analysis determines the economic worthiness of pursuing a reuse program or creating a reusable asset; finance relates to the funding of a reuse program; and accounting deals with tracking/controlling a reuse program.

The Strategy block considers how reuse will be employed to meet the organization’s goals. In some cases, it may help formulate organizational strategies that relate to the decision cycle used to determine the role of reuse; competitive positioning; and critical success factors used to identify the organization’s priorities.

The Personnel block defines the roles/responsibilities of the people involved in reuse, and includes the establishment of incentives necessary to motivate engineers.

Within the Organization block, structure refers to the formal system of working relationships that permit both the division of labor and the coordination of tasks to achieve effective software reuse. Related to structure is the concept of “integrating mechanisms”, which includes the rules and procedures that may be used to facilitate coordination between different stakeholders.

The Metric block defines a way of measuring some attribute of developing software with reusable assets. Not limited to code, these metrics also measure the reuse of infrastructure, which is the underlying foundation or basic framework that supports reuse.

Effective marketing helps the reuse organization achieve its goals by accurately determining the needs and wants of the target organizations and delivering the desired value.

The key to successful reuse within the legal context is to strike the appropriate balance in allocating known risks among all parties so that reuse will not be encumbered by unnecessary and undesirable legal problems.

Manufacturing for reuse involves the manner in which the process is linked to the product. Popular strategies include the application of group technology (a manufacturing technique used to identify/group similar parts so that their manufacture is streamlined) and flexible manufacturing systems which capitalize on economies of scale and reduce labor costs.

On the technical side of Lim’s framework, reuse processes represent those systematic procedures that are to be implemented in producing, brokering and consuming reusable software.

Reuse tools are broadly defined as those instruments which facilitate the reuse of products or byproducts during the software life cycle, including reuse libraries, application templates and generators which, in turn may be categorized into compositional or generative reuse techniques (see Glossary).

Lim also provides some definition for what constitutes reusable assets by the life cycle phase for which they are most appropriate (Table 3) and by the intended overall scope of the reuse activity, ranging from personal reuse to international reuse (Table 4). We’ll see some of the issues associated with the scope of reuse when we talk about reuse risk in the next section.

Table 3: Reusable Assets by Software Life Cycle Phase [Lim, 1998]

Phase	Reusable Asset
Requirements	Requirements specifications, trade studies, cost models
Analysis	Project models, histories, system simulations
Design	Designs, standards, frameworks, consumer reports, historical engineering costs, design simulations
Develop	Code modules, programmer’s manuals, operating manuals, unit test cases, codes simulations, operator training programs
Integrate and Test	System and subsystem test plans, procedures and cases; detailed interface simulations
Maintain	Problem/trouble report tracking systems; regression test plans, procedures, cases

Table 4: Scope of Reuse [Lim, 1998]

Reuse Type	Description
Personal	Practiced by the individual software engineer. Over time, a personal library of routines is accumulated for the individual’s use. Every individual is responsible for producing/maintaining their own work products.
Intraproject	Reuse within a project. Usually involves designating one or more engineers to create the reusable work products (e.g., a function library) for other project members to reuse. A project policy must be established on reuse to address contractual issues.
Interproject	Practice of reuse across multiple projects. Reuse at this level highlights the issues of coordination and organization among several groups and, possible, geographical locations.
Enterprise-Wide	Organizations which fall under this category include commercial companies and organizational units within the Government (e.g., the Air Force). At this level, reuse requires support and coordination of multiple levels of management in multiple organizations. Depending on enterprise size, a broker may be required to match the supply and demand needs of enterprise constituents.
Interenterprise	Reuse across enterprises, including the practice of reuse across several different companies
National	Reuse of work products on a national level. At this scope, management issues are of utmost importance.
International	Reuse of work products across countries

While many of the attributes of software reuse that we have discussed up to this point have been from the perspective of the software developer, Reifer [Reifer, 1997] provides a good overview of software reuse strategies from the perspective of software acquisition personnel. These are characterized in Table 5.

Table 5: Software Reuse Acquisition Scenarios [Reifer, 1997]

Scenario	Characterization
Share Cost of Development	Develop systems and assets under shared cost constraint; government can reuse the architecture; contractor retains rights to market the reusable assets commercially
Provide Suitable Market Incentive	Government provides a large enough market to stimulate contractor to provide system and reusable assets that satisfy requirements at no cost to the government; contractor retains rights to market reusable assets
Develop via Shadow Project	Develop needed reusable assets through a separately funded and managed shadow project; separate funding line established; award fee used as incentive; rights negotiable
Develop via Reuse Libraries – I	Develop system from reusable assets in government reuse library; contractors generate reusable assets for libraries that, when used, earn them either a royalty or fee
Develop via Reuse Libraries – II	Develop system from reusable assets in government reuse library; stimulate reuse via incentive fees derived from savings due to reuse
Build Based on Proprietary Architecture	Procure based solely on contractor-owned, proprietary software architecture; contractor retains rights to the reusable assets developed under contract and domain model; government owns delivered system
Upgrade Based on Legacy Software	Upgrade system based on legacy software; re-engineer legacy to fit architecture; contractor retains rights to new reusable assets developed as incentive; government gets rights for delivered system
Develop Under Security Concerns	Develop classified systems using a large, multicultural team; sharing restricted to inside the program; government retains rights; outside use of architecture/assets not practical due to security concerns
Develop Prototype Using COTS/GOTS	Develop prototype system composed of COTS and GOTS software assets within an existing architecture; devise strategy for full-scale development based upon results; use of award fee as incentive
Develop System Using COTS/GOTS	Develop system using COTS and GOTS software for multiple government agencies; system cost is fixed price and is adjusted based upon the number of users ; contractor gets maintenance job as incentive
Pursue Product-Line System Developments	Develop system to government-owned and managed product-line architecture; separate contractor teams develop the architecture/assets and application; government owns architecture/assets but provides contractor commercial rights as an incentive

REUSE RISKS

There are many possible motivations for wanting to reuse software, and each of them has its own associated risk that must be addressed. At the organization level, one of the enablers supporting reuse is cost reduction, i.e., how can the cost of development and maintenance of an organization’s software products be reduced? A reuse-enabled business strategy can help to increase revenues by (1) reducing product times-to-market and (2) obtaining competitive positioning and advantage by entering markets and/or creating new products through reuse. In Table 6, Ezran [Ezran, 2002] provides an effective summary of the motivations that should be considered when deciding on software reuse as an option. The potential risks associated with these various motivations need to be considered.

Table 6: Motivations for Considering Reuse [Ezran, 2002]

Criteria to Be Considered	Questions to Be Answered
BUSINESS
Market Position	· Do software processes need to be improved? · Does the business Information Systems (IS) efficiency need to be improved? · What is the business position in the marketplace? · What are competitors doing? · Is investment needed to improve business efficiency and competitiveness?
	Investing in reuse is justified if the company needs to reinforce its position in the marketplace
Business Opportunities	· Is the company/department activity well structured into business domains with recurring applications/systems in each domain? · Is software a critical issue for the success of the business?
	Investing in reuse may not be worthwhile if the company does not have a software-intensive business and if the activity is not structured into applications families or product lines
Company Strategy	· Does the ability of the business to react need to be improved? · Do product lines need to be built? · Does knowledge of the business domains need to be capitalized? · Does the efficiency of the Information System need to be improved?
	Three main reasons to introduce reuse are to (1) capitalize on the business domains, (2) build product lines or reinforce the company product offerings, or (3) improve IS and its consistency with the business
SOFTWARE DEVELOPMENT
Functional Stability	· Are functional requirements stable with identified variabilities?
	If not, the scope of software reuse may be limited to technical and generic assets
Technical Stability	· Are the software development environments, tools and platforms well defined and stable?
	If not, the company should first focus on domain models and business objects
Process Maturity	· Does the company have an acceptable maturity level regarding software engineering? · Has the company adopted a quality system, an agreed software life-cycle, architecture, best practices, etc.?
	If not, it may be too early to implement a reuse program, but it may not be too early to think about/anticipate it
STAFF
Technology Mastery	· Are the development teams experienced in development technologies?
	Mastery of implementation technologies and design techniques may be seen as a prerequisite to putting reuse into practice
Motivation and Change Acceptance	· Is the staff ready to accept changes? · What needs to be done to ensure motivation?
	Reuse will never be institutionalized without a clear answer to these questions

Mili [Mili, 2002] takes a look at the aspects of reuse across the multiple dimensions of Component-Based Software Engineering (CBSE), COTS-Based Development (CBD) and Product Line Engineering (PLE). These aspects are presented in Table 7 and should be considered as potential risk areas in implementing a reuse strategy.

Table 7: Aspects of Reuse Across Multiple Dimensions [Mili, 2002]

Aspect	Component-Based Software Engineering (CBSE)	COTS-Based Development (CBD)	Product Line Engineering (PLE)
ORGANIZATIONAL
Primary interactions	§ Involvement of component and application engineers § Library retrieval	§ Strong relationship with third party (component vendor)	§ Strong involvement of domain engineers
Primary reuse skills	§ Component engineer § Application engineer § Reuse librarian	§ Reuse manager	§ Domain engineer § Architect
TECHNICAL
Integration	§ Compositional with other components § Generative	§ Compositional only	§ Compositional into domain architecture § Generative
Constraints	§ Components comply with component model (not necessarily domain constraints)	§ Components comply to application constraints	§ Components comply to domain architecture constraints
Support service responsibilities	§ Application engineers	§ Component vendor	§ Domain engineers
Packaging	§ Binary source code may be available and modifiable	§ Binary black box components	§ Reference architecture, middleware infrastructure; guidelines; binary components; source code
Retrieval	§ Public or domain libraries	§ Commercial advertisement	§ Domain libraries
Implementation technology	§ Defined by component model	§ Not controllable	§ Defined by reference architecture
ECONOMICAL
Component acquisition	§ Adapt	§ Buy	§ Instantiate
Market scope	§ Driven by ROI from an application developer perspective	§ Driven by ROI from the component provider perspective	§ Driven by ROI from the domain engineering perspective
Economical motivations	§ Common component models	§ Common market	§ Common design and architecture

Regardless of the reuse strategy employed, assuming that the organization has decided that it is beneficial to their business to pursue software reuse, the actual implementation of a reuse program means that choices and tradeoffs regarding risk (and cost) need to be made considering all of the issues raised in Tables 6 and 7.

Leach [Leach, 1997] sees two broad dilemmas and four fundamental problems associated with reuse. The first dilemma is the assessment of the applicability of the reuse products versus the payoff that can be expected from the reuse. The second dilemma concerns software component size versus its potential for reuse. The four fundamental problems are (1) finding appropriate reuse components, (2) understanding those components, (3) modifying them, if necessary and (4) composing reuse components, i.e., building them yourself. There are numerous barriers or disincentives that can result in increased risk to a software reuse program. These can include, at the individual level:

· The “not-invented here” syndrome, based on the mistrust of code quality that hasn’t been personally developed

· “We’re builders not integrators”, i.e., the actual building of components is more satisfying than integration of components into systems

· The fear that measurements used to assess the development process will be used to assess personal performance

· Unprofessional developers who cut corners, use obscure techniques, poorly document their products, ignore efficiency, etc.

· Environments where plagiarism is discouraged, i.e., copying others’ work is considered wrong, leading to a reinvention culture

· Job protection, where efficiency improvements through reuse are viewed as threatening job security (fewer developers required)

· A basic resistance to change that may render developers obsolete with younger developers

· Rivalry among developers is viewed as beneficial to productivity, leading to secrecy and a lack of cooperation

· Fear of the introduction of unknown new processes that may adversely impact developer performance

· Hard to locate components, making it easier to build a component than to try to find it, if it even exists

· Limited or no methodology support to promote reuse objectives or reuse incorporation during analysis and design

· Lack of support that makes it easier to build a component from scratch than it is to “fix” a reuse component that does not perform to the required specification

· Resource constraints resulting from a reusable code component that may meet functionality requirements, but requires too many time/space considerations for its execution

· Alteration effort, where a developer may not be able to assess whether the similarity between a reusable component and a new set of requirements makes it feasible to be reused, or more productive to start from scratch

At the management level, barriers or disincentives that inhibit reuse may result from:

· A loss of status due to changes to an organizational structure that may translate to loss of power (i.e. control of fewer staff), thereby appearing as a demotion

· A loss of budget, where efficiency improvements may be interpreted as a requirement for a smaller development budget, thereby leading to budget reassignment impacting a manager’s position

· A fear of failure based on a concern that teams will not be able to make the best use of the reuse process, allowing higher-productivity teams to leap-frog them for increased budgets

· The cost of setting up tools/libraries may have to come from the budget of current projects, making them fall behind and reflecting poorly on managers

· If bugs are found in library components, the cost of fault resolution for fixing them may come out of the project budgets that are using them

· Managers may fear the loss of control of their budgets, as funding reusable component development/usage leads to less accountability

· The primary rejection of software reuse is that pressures to complete current development projects may be too great to allow introduction of slack time to initiate effective reuse processes

Sommerville [Sommerville, 2004a] summarizes some of these issues in Table 8.

Table 8: Problems Associated With Reuse [Sommerville, 2004a]

Problem	Comments
Increased maintenance costs	If the source code of a reused software system or component is not available, then maintenance costs may be increased as the reused elements of the system may become increasingly incompatible with system changes.
Lack of tool support	CASE toolsets may not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account.
Not-invented-here syndrome	Some software engineers prefer to re-write components, as they believe that they can improve on the reusable component. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software.
Creating/maintaining a component library	Populating a reusable component library and ensuring the software developers can use this library can be expensive. Current techniques for classifying, cataloguing and retrieving software components are immature.
Finding, understanding and adapting reusable components	Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they will routinely include a component search as part of their normal development process.

Taking a more macroscopic view, there are some general managerial, legal and technical factors that will influence the level of risk associated with software reuse.

A common factor in organizations reporting successful reuse, thereby representing a risk in organizations that do not, is management support for reuse. Success/risk factors include the use of rewards (establish a reward program for creators and consumers of reusable parts); education (determine how people should be educated about reuse); organization (establish and support the project reusability group); motivation (abolish the “not-invented-here” syndrome and establish employee training incentives and reward programs); and finances (accept and commit to up-front costs).

Technical factors having the most impact on software reuse success, therefore representing potential areas of risk, are component identification and standardization associated with domain analysis; identification of the process or methodology needed to implement or manage reuse; the creation process of designing “for “ reuse, the use of COTS software, or engineering reusable software; characterization of the environment, including integrated tool and process support; component classification and retrieval from a software library; component customization through transformation; and the abstraction or encapsulation mechanisms associated with the reuse language.

Frakes [Frakes, 1996] classified software reuse failure (which we can consider to be the manifestation of a risk) into seven distinct failure modes and, as part of a survey that he performed, concluded that the most important or prevalent failure mode was that no one was attempting to implement reuse. In 2001, however, Fichman [Fichman , 2001] regrouped Frakes’ failure modes into three more generic categories: Reuse Candidate Not Sought (Frakes’ Failure Mode 1); Reuse Candidate Can’t Be Used (Frakes’ Failure Modes 2-4); and Reuse Candidate Not Found (Frakes’ Failure Modes 5-7). Based on these three groupings, a different conclusion can be reached, i.e., the most important or prevalent reuse failure modes are that (1) reuse candidates can’t be used and (2) reuse candidates can’t be found. Table 9 summarizes these two studies, and includes potential causes for each failure mode. (Note that the blue entries in the Cause column represent potential causes that were not selected by any of the Frakes’ study respondents.).

Table 9. Reuse Failure Modes in the Software Industry [Frakes, 1996][Fichman, 2001]

REUSE FAILURE	CAUSE
Fichman: Reuse Candidate Not Sought (32)
1. No attempt to reuse (32)	· Resource constraints · No incentive · Time constraints · Utility of reuse unclear · Lack of education · Communications problems · Legal problems · No management support · No reuse support organization · No customer support · Not-invented-here syndrome · Nonegoless programming · Reuse technology immature · No success model · More fun to write than use
Fichman: Reuse Candidate Can’t Be Used (62)
2. Part not integratable (22)	· Environment incompatibilities · Improper form · Hardware incompatibilities · Too much modification required · Nonfunctional specifications · Linkage to extraneous software
3. Part not understood (21)	· Inadequate documentation · Too complex
4. Part not valid (19)	· Poor inspection, testing, verification · Poor support from producer · Inadequate performance · Lack of standards · Insufficient information
Fichman: Reuse Candidate Can’t Be Found (37)
5. Part does not exist (18)	· Part not designed for reuse · No economic incentive · Novel technology
6. Part is not found (12)	· Insufficient representation · Poor or no search tools · Inability to specify search
7. Part is not available (7)	· No reuse repository · Part is proprietary/classified · No import organization · Part can’t be scavenged · Part can’t be found · Source code missing

The Software Productivity Consortium [SPC, 1993a] provides a fairly comprehensive list of the risks associated with reuse adoption. These are presented in Table 10.

Table 10: SPC Reuse Adoption Risks [SPC, 1993a]

Risk Category	Risk Description
ORGANIZATIONAL RISKS
Organizational Structure	· Inadequate support for acquiring/managing reusable assets or supporting users may arise if the organization is not set up to manage software reuse · Reusable assets may be difficult to find if they are not kept in a specific place or under control of any group · Reuse activities may conflict with the company’s standard development process and methodology · It is difficult to maintain components if one group is trying to cover too many complex domains · Reuse is inefficient because managers lack sufficient authority
Organizational Politics	· Existing organizational objectives conflict with the reuse objective being introduced · The development staff do not believe reuse will make their jobs more productive, challenging or rewarding · A reuse incentive program may be viewed as a management “stunt”, rather than an initiative from which developers can benefit · Poor use of library components because (1) users don’t know the library exists, (2) do not believe its components are relevant, (3) do not know how to access them, or (4) do not trust them · Reuse activity is low because it conflicts with the current culture or developers prefer to build their own · Reuse activity is low because of the sudden imposition of a reuse plan in place of traditional methods is resisted by developers · Managers shun reuse because they fear that the organizational change (e.g., assigning asset development to a separate group) will reduce their empire · The funding model for asset maintenance may fail because support for reusable assets was reduced before the costs were amortized
Organizational Capability	· The asset library or development environment is not adequate for development with reuse · Policy guidelines fail to promote use of reusable assets · Contract terms do not permit the developer to realize benefits of reuse or protect them if reuse-specific problems arise · Lost opportunity for reuse in current/future projects because inappropriate standards were chosen (an old standard may not have enough potential to make it worthwhile to write reusable software objects but would allow reuse if parts already exist) · Reuse activity is low because staff is not adequately trained in utilizing reusable assets on hand, recognizing opportunities to apply them, or building reusable assets · Poor component access reduces reuse activity and its cost effectiveness (developer’s terminal lacks access to the repository; terminals having access are unfamiliar or inaccessible) · Developers have difficulty with reuse because support from library staff is poor · Inefficient component retrieval results from a lack of abstracts that help a developer quickly determine what the essential features of reusable assets are · Difficulty is encountered during component selection because specialized knowledge is needed about the component or its environment in the system · Components are difficult to reuse because they are not specifically designed and documented for reuse (e.g., perhaps component developers were not trained to write reusable components · Library content is poorly understood be developers because content is not well publicized · Users have difficulty finding components because no search tools are provided · Users have difficulty finding components because tools do not support standard library search methods (i.e., hierarchical or keyword search, or a faceted classification system) · Users have difficulty finding components because insufficient support is provided to select components for specialized functions (tutorial or model-based guidance may be needed) · Excessive effort is devoted to fixing components because no support is available from the library staff or component authors · Poor development cost estimates may arise from a lack of cost models, or the historical data necessary to use them · Reuse activity and efficiency can be inhibited by limited management vision · Reuse potential is misjudged because of poor market awareness · Future gains possible through reuse are missed because of excessive emphasis on near-term productivity · Low reuse effectiveness because reuse is treated as a side issue, rather than an integral part of systems or software engineering · Weak responses to requests for contributions to the asset library because there are no incentives · Reuse is inefficient because roles for reuse activities are poorly defined · Reuse is inefficient because communication between application engineers, library support personnel and domain engineers is inadequate · Costs/schedules can be affected when reuse across contractors on multicontractor projects increases interdependency
Individual Personnel Capability	· Reuse activity is low because personnel do not have experience with selecting and using reusable assets · Reuse activity is low because personnel are reluctant to change from the current practice · There is poor reuse effectiveness because training in reuse was limited
PROCESS RISKS
Life-Cycle Processes	· Reuse activity is low because the chosen development cycle provides no indication of where/how reuse is to be evaluated or implemented · Management cannot track reuse activity because reuse data collection is inadequate · There are disappointing reuse levels because reuse was not considered early in the project development cycle · There are disappointing reuse levels because the development processes, methods or tools are not compatible with the reuse strategy
Phase-Independent Activities
Resource Management	· Products are inadequate because overly ambitious schedules lead to inferior design and implementation choices · There is poor design for reuse because requirements for product evolution were not defined · Reuse costs are high because of inadequate asset documentation · Inadequate reuse arises from difficulty in finding, understanding or applying reusable assets · Reuse activity is low because retrieval tools were poorly chosen or training was inadequate · Reuse costs are high because missing components result in a loss of reuse opportunities or expensive searches to find them, which may result from poor repository management · Excessive effort is devoted to fixing components because no quality checks are made on new entries or the library entries have no associated quality metric so that users will know what to expect · Excessive effort is devoted to adapting components because the range of uses is so narrow or so broad that performance suffers · Components from previous projects do not integrate well for new applications because there was no common architecture · Applications costs are high despite a good reuse library because of a failure to capture the knowledge needed to apply the components in building an application (domain knowledge) (considerable support is needed from domain experts) · The reuse library is underfunded because the cost of cataloging components was not included · Inappropriate reuse can result from a lack of knowledge or training concerning data rights · Failure to innovate and update assets arises from overemphasis on reuse to cut cost · Reusing assets is difficult because a common notation for describing assets is lacking · Reusing assets is difficult because architecture or interface standards for reusable assets are not defined or observed · Few contributions are made to the asset library because there is no defined process for testing/accepting new assets · Difficulty in supporting reuse may arise from failure to involve the library support staff in the reviews during the development of assets · Customer rejection of vendor test data can arise from poor reuse planning or vendor selection · Delivery problems may arise from failure to allow for custom upgrades from component vendors (especially if customer requirements change during development)
Configuration Management	· Component versions proliferate because there is inadequate control of assets · Low use efficiency results from failure to analyze the domain before creating a component library (i.e., components often cannot be reused or architecture needs extensive modification for new applications) · Lower than expected productivity improvement results because the organization focused on low-level component reuse and ignored possibilities for reuse of large components and subsystems · Difficulties may arise when reusing assets from distributed libraries because the configuration management procedure does not address the needs of distributed libraries · Unpredictable problems arise during reuse because configuration management on assets is poor · Problems arise during system integration because configuration control was not applied to the design · Problems arise during system integration because configuration control was not applied to the support software · Problems arise in reusing assets because baselines at departure points in the evolution of an asset were not established
Quality Management	· Poor design choices for building reusable assets can result from inadequate risk management · Poor quality assets for future reuse may arise from inadequate inspections, walkthroughs and verification · High development cost and resistance to reuse on the part of developers can arise when poor component quality leads to frequent failures · Developers cannot tell if a component fits their requirements because documentation is poor and does not tell them what they need to know · Components perform poorly and often have to be replaced by custom code · Components have excessive memory requirements · A component is difficult to understand because no documentation is provided · Code components are poorly utilized because supporting information is omitted (e.g., specifications, operator’s manuals, version descriptions, test procedures and integration test plans) · A component is difficult to modify because its code is incomprehensible · Applying reusable assets is difficult because interface design documentation for them is weak · Poor performance of completed systems can arise because memorable performance goals in assets requirements documents were lacking · Assets do not fit the application because established standards were not observed in building the assets · Problems arise during system integration because support software was not adequately documented · Problems arise during system test because support software was not tested adequately · Costly fixes during the application phase are needed because testing for reusable assets was not adequate · Poor asset quality may result from failure to involve a third party in testing reusable assets · Poor asset quality may result from failure to hold design reviews for reusable assets
Phase-Dependent Activities
Project Definition	· Assets become obsolete before development cost is amortized because the changing or immature nature of the technology was not recognized · Components seldom fit new requirements because component requirements could not be anticipated · A contract is lost because of failure to recognize cost, schedule or risk reductions available through reuse · Reuse potential is reduced by a poorly written contract (i.e., the contract does not permit full utilization of assets) · Poor reuse efficiency may arise from an inadequate build versus reuse tradeoff procedure
Concept of Operations	· Customers are unhappy with products because the design does not provide for user training or system maintenance · Customers are unhappy with products because the design does not provide fault tolerance · Users are unhappy with the system because human factors were not considered in the design of reusable interface components · The reused design poorly matches the concept of operations for current application
Requirements	· Reuse potential is low because of excessive customer requirements · Higher risk and cost can result from failure to reuse requirements
Design	· Components are difficult and costly to apply because they are overly complex · Low performance and high complexity may result from using components that do not fit the current design · Reusable components may not meet performance, operability or supportability requirements unless selection is done carefully
Implementa-tion	· The system performs poorly because components were inappropriate, poorly designed, or too general · The system is too large because components were inappropriate, poorly designed, or too general · Proliferation of component versions and high costs may result from poor change control
Integration and Test	· High development costs may result from poor quality components containing many errors · There are excessive testing costs because the possible reuse of test procedures and test data were ignored · High testing costs arise because test cases supplied with third-party components were inadequate
Acceptance	· There is low customer satisfaction because a reused design does not provide the expected user interface
Evolution	· Assets become obsolete because inadequate funds were allocated for updating them · Reuse potential is reduced because of a failure to plan for evolution of the system · Reuse potential is reduced because of inflexible system design

Methods	· Reuse is low because methods are incompatible with application of reusable assets · Components are difficult to understand because of inadequate viewpoint representation (behavior, information, function) · Poor reuse results because poor software engineering methods were used · Poor productivity improvement results because the benefits of reusing designs or test methods were ignored · Poor productivity with reuse results because the methodology used does not support it
Automation	· Development costs remain high because incompatible development tools are used · Tools do not support reuse · The development environment does not support reuse · Expensive workarounds occur because of inflexible or inappropriate reuse · Difficulty meeting the competition is experienced despite high levels of reuse because the opportunity to automate program construction or code generation was ignored · Excessive documentation costs accrue because the opportunity to automate document generation was ignored
PRODUCT RISKS
Algorithm	· Inefficient algorithms are used in components · There is inadequate fault tolerance of components
Architecture	· Low levels of reuse or longer development times may result from a lack of standard architecture · Excessive component revisions may result from poor system modularization leads · Failure to use high-level abstractions can result from excessive focus on low-level parts
Physical Realization	· Processor needs are underestimated because of insufficient modeling or poor component documentation · Memory requirements are underestimated because of poor component documentation or insufficient planning

Lim [Lim, 1998] has also proposed a software reuse classification scheme that identifies reuse success factors and risk factors, summarized here in Table 11.

Table 11: Conditions for Successful Reuse vs. Unsuccessful Reuse (Based on [Lim, 1998])

Success Factors	Risk Factors
Narrow, standardized domains	Broad domains, spanning several application areas
Well-understood domains and architectures	No emergence of architectural archetype, i.e., archetypes need to be developed from scratch each time they are used
Slowly changing domain technology (domain stability)	Rapidly changing domain technology increases probability of obsolescence
Intercomponent standards	Additional interface software required to allow two software components to “plug together”
Economies of scale in market	Limited reuse of an asset or limited applications of a reuse technology (i.e. .generator) to support economies of scale
Economies of scale in technologies	Limited number of larger reuse components available (limited potential for improving productivity through reuse)
Infrastructure support	Infrastructure is not well-defined or not sufficiently mature
Standardized reuse implementation technology	Inability to mix technologies, process models and cultures to achieve successful reuse
High quality reusable assets and domain expertise are available	Availability of high-quality assets and domain expertise is questionable
Strong, focused support for reuse initiatives from senior management advocates	Ambivalent, ambiguous support for reuse initiatives from senior management
Cultural acceptance and integration of reuse into the organization	Indifference or resistance to acceptance of reuse into the organization

Reifer [Reifer, 1997] provides some insight into the strengths and weaknesses of alternate reuse strategies (Table 12), where weaknesses should be viewed as potential risk areas that should be acknowledged and overcome as an integral part of the reuse strategy and process.

Table 12: Strengths and Weaknesses of Alternate Reuse Strategies [Reifer, 1997]

Strategy

Strengths

Weaknesses

Product-Line Architecture

· Product-line oriented

· Investments limited to what the architecture needs

· Reuse of COTS/3^rd-party software is emphasized

· Economies of scale/breadth possible

· Systematic approach

· Major culture change needed

· New infrastructure must be created (policies, processes, organizations, etc.)

· Investments are large

· Suppliers might rebel

· Switchover takes a lot of time and effort

Megaprogramming

· Project-oriented

· Reuse becomes a natural part of business

· Participatory

· No central group or taxes needed to fund reuse

· Major culture change needed

· Infrastructure must be built (processes, etc.)

· Large investments to cut over to reuse as you build systems

Library

· Service-oriented

· Opportunistic by nature

· Simple and easy to implement

· Costs are reasonable

· Can make a near-term impact

· Provides services that users are willing to pay for

· Often bureaucratic since access must be protected

· Taxes on users are possible/probable

· Users are often directed to use library or else

· General vs. domain-specific parts populate the library

Electronic Shopping Mall

· Market-based (forces brokers to focus on business issues)

· Partnerships are possible (to reduce costs)

· Makes money or business folds

· Market may not be strong enough to justify up-front expenses

· Start-up costs are high

· Focuses attention outside, not inside, thereby causing user dissatisfaction

Ezran [Ezran, 2002] mentions a number of points that should be considered prior to making the decision as to whether to pursue the implementation of a reuse process, all of which should be assessed in the context of risk management activities. Before creating an asset, it needs to be understood that developing a reusable asset represents an investment. Therefore, there should be a decision-making process to minimize risks. If the following questions are not, or cannot be, answered, the investment of developing the asset may not be profitable:

· Is this asset significant for the business of the company?

· What is the business potential and the probability that there will be a similar requirement?

· Who are the potential reusers?

· What is the cost overhead, compared to developing the same software without reusability?

Any decision to develop a reusable asset should be taken only after having considered the answers to these questions.

Reusing an existing asset may also include some risks, and poses its own set of decisions in order to minimize those risks:

· Is the asset compatible with architecture constraints?

· Does the asset meet functional requirements?

· If not, should the asset or the requirements be adapted? In both cases, what is the corresponding loss/gain in terms of functionality?

· How is the application likely to evolve? Will someone be able to make the incorporated asset evolve satisfactorily?

· Are there any property or legal constraints that apply to the reused asset or to the resulting application?

· What is the cost of developing the application (or part of it) without the reuse asset?

· What is the cost of understanding, testing and adapting the asset?

Having answered these questions, an informed decision can be made based on a comparison of the effort saved against the identified risks.

Reifer [Reifer, 1997] makes the following suggestions regarding how to handle risk management activities for software reuse processes:

· Assess the reuse risks that have been identified during risk management activities

· Monitor risk and track resolution of risk items to make sure that plans are working properly

· Get all stakeholders impacted by reuse risks involved in the process of risk management

· Risk management is an ongoing process – as soon as one risk is closed out, a new one appears

· Factor reuse risks into all work plans and schedules – make the necessary adjustments

· Involve all stakeholders in figuring out how to mitigate risks

Lim [Lim, 1998] goes a bit further in taking a look at some of the issues that need to be addressed, breaking those issues down by the type of reuse that we discussed earlier, namely Personal, Intraproject, Interproject, Enterprise-Wide, Interenterprise, National and International. Table 13 presents issues related to metrics, which are an important tool for managing risks related to software reuse.

Table 13: Metrics Issues by Scope of Reuse [Lim, 1998]

Reuse Type	Metrics Issues
Personal	· Track characteristics of reuse work products for individual use
Intraproject	· If a reuse library is established, determine metrics for its usage · Identify appropriate reuse process, product and work product metrics which correspond to the new roles of the engineers
Interproject	· Address all metric issues outlined in previous levels · Ensure that methods for collecting reuse metrics are consistent across all projects · Identify reuse metrics which measure the reuse of work products across projects and, if necessary, appropriate transfer prices
Enterprise-Wide	· Address all metric issues outlined in previous levels · Provide greater emphasis on process metrics for managing the increased complexity for enterprise-wide reuse · Establish standard metric collection guidelines and policies on the enterprise-wide use of shared work products · May require staff dedicated to the collection of reuse metrics across the enterprise
Interenterprise	· Address all metric issues outlined in previous levels · Consider establishing a team dedicated to collecting reuse metrics · Identify appropriate reuse metrics in order to properly package and support the reusable work products for interenterprise use
National	· Address all metric issues outlined in previous levels · Identify appropriate reuse metrics in order to properly package and support the reusable work products for national reuse
International	· Address all metric issues outlined in previous levels · Identify appropriate reuse metrics in order to properly package and support the reusable work products for international reuse · Have localization specialists tailor the metrics information for reusable work products

Some specific metrics that should be considered for managing reuse risk have been proposed by Reifer [Reifer, 1997] and are presented in Table 14 from the perspectives of an executive; a product-line or line-of-business manager; a project manager; or a software engineer. Note that the metrics at the two higher levels tend to be more focused on the financial paybacks of reuse, while at the lower levels the emphasis becomes related more closely to technical performance, quality and reliability.

Table 14: Candidate Reuse Metrics [Reifer, 1997]

Viewpoint

Measurement Issues

Metrics/Measures

Executive

· Overall profitability

· Organizational effectiveness

· Capital expenditures

· $ profit/$ sales

· Win ratio or ROI

· Return on capital

Product-Line or Line-of-Business Manager

· Customer satisfaction

· Cost of goods sold

· Market share

· Time to market

· Satisfaction Index

· $/source line of code

· $ sales/$ market

· Months

Project Manager

· Budget performance

· Schedule performance

· Requirements volatility

· Product quality

· Cycle time

· $ actual/$ planned

· Time actual/time planned

· Change request frequency

· Customer complaints or first-pass field test

· Process downtime

Software Engineer

· Size

· Complexity

· Reliability

· Productivity

· Source lines of code

· Cyclomatic number or Halstead ratio

· Error density or rate

· Source lines of code/staff month of effort

There are a number of legal factors that can impact the success of a software reuse process. These include the legal rights and responsibilities associated with software reuse; the ability/need to sue if reuse parts are substandard; software copyright and proprietary issues; personal and organizational liabilities; contractual requirements; and product content. Lim provides us with a glimpse into some of the legal and contractual issues that need to be addressed when assessing the risk associated with reuse, as well as considerations that should be factored into software reuse warranty decisions as they relate to areas of perceived risk. These issues and considerations are summarized in Tables 15 and 16, respectively.

Table 15: Legal and Contractual Issues by Scope of Reuse [Lim, 1998]

Reuse Type	Legal Issues	Contractual Issues
Personal	· None	· None
Intraproject	· None	· Designate who will produce and maintain reusable work products, what will be created, and when the work products will be available · Assign responsibility for correcting a reusable work product if a defect is detected · If leveraging will be allowed, designate responsibility for the leveraged work products
Interproject	· None	· Address all of the contractual issues outlined in the previous levels · If a broker function is required, determine responsibility for screening and qualifying the work products prior to use · Fairly allocate the risks and rewards among all projects to encourage reuse
Enterprise-Wide	· None	· Address all of the contractual issues outlined in the previous levels · Establish standard guidelines and policies on the enterprise-wide use of shared work products
Interenterprise	· Determine who owns the reusable software and what ownership rights, if any, are exclusive · Determine the conditions under which users are allowed the rights to reuse work products	· Address all of the contractual issues outlined in the previous levels
National	· Address all of the legal issues outlined in the previous levels · Provide protection of intellectual property rights for widespread distribution of reusable work products	· Address all of the contractual issues outlined in the previous levels
International	· Understand applicable international property laws and regulations of software reuse	· Address all of the contractual issues outlined in the previous levels

Table 16: Software Reuse Warranty Considerations [Lim, 1998]

	Software component developed to be reusable, or modified for reuse	Existing software component identified reusable “as is”	Commercial software component
Software component characteristics requiring warranty consideration	· Reusable assets should perform to the level described in supporting documentation · Developers of reusable components should support this concept	· Same as for new and/or modified software · Original developer may not be willing to warrant for reuse · Any existing warranty may be exclusive of or voided by reuse elsewhere	· Typically, only the standard commercial warranty will be offered · May be sufficient · Commercial vendor may consider extended coverage
Remedies required	· Fix the software component to perform at documented levels · Consequential damages possible if user adequately tested component prior to reuse, but defect not detectable. Consider use of liquidated damages	· Same as for new and/or modified software, but… · Conditions above still apply	· Consequential damages typically excluded · Performance to documented levels warranted
Warranty duration	· Some reasonable period after delivery (typically not more than 1 to 2 years) · Software may not change, but a prudent business person would not commit to longer periods	· Same as for new and/or modified software	· Commercial limits (90 days to 1 year typical)
Cost/benefit analysis results	· What is the added warranty cost over the warranty period? · What is the likelihood that the component will be reused in the warranty period? · What is the likelihood that a failure can be discreetly identified? · What are the administration costs?	· Same as for new and/or modified software, but… · Also assess whether reuse warranty costs necessarily duplicate any existing warrant costs.	· Included in commercial-off-the-shelf (COTS) price · Usually difficult to analyze added cost for extra coverage · Commercial pricing protection

Of course, the ability to successfully manage and mitigate risk depends on a well thought out and structured reuse strategy that will allow informed decisions to be made on the level of software reuse that should be implemented, and how the risks associated with it should be controlled. As mentioned previously, IEEE Std 1517-1999 provides a basis for incorporating systematic reuse into software life cycle processes that are compatible for use with IEEE/EIA 12207.

The Software Productivity Consortium (SPC) has also developed and published a Reuse Adoption Strategy [SPC, 1993a] as a process tool that can be used to implement a formal, viable process for managing software reuse. A block diagram of this process is presented as Figure 4.

Figure 4: SPC Reuse Adoption Strategy [SPC, 1993a]
Cick here to enlarge

The yellow block in this figure represents the step in the SPC process that refines, evaluates and selects a reuse adoption strategy for implementing reuse that considers the risks associated with each potential strategy. The entrance criteria to this block is predicated on the documentation of an updated Reuse Program Plan that includes the reuse adoption goals and constraints and has been reviewed and approved by the sponsor. It is also assumed that alternative reuse adoption strategies have been identified. The tasks included within this activity block are to (1) assess risks of alternative strategies, (2) analyze the organizational impact of alternative strategies, (3) analyze the economics of alternative strategies, and (4) select a reuse adoption strategy. Inputs into the activity are based on some pre-defined number of alternative reuse adoption strategies in order to put reasonable bounds on the problem. The controls for the activity are based on specific elements of the Reuse Program Plan, most notably the reuse adoption objectives, goals and constraints, as well as the activity sponsor. The output of the activity is a selected (i.e., preferred) reuse adoption strategy. The mechanisms for the activity are the reuse agent and the SPC Reuse Economics Spreadsheet Model. Exit criteria from the activity represents the selection of a suitable reuse adoption strategy that has been approved by the sponsor. There are a number of analytical techniques that can be used to carry out the risk analysis required during this activity. Appendix C from the SPC document [SPC, 1993a] includes a checklist to assist in dealing with reuse-related risk issues.

Finally, the CMMI Risk Management Process Area [Chrissis, 2003] can easily be adapted to provide an emphasis on software reuse. Although not specifically established to do so, Table 17 suggests an adaptation of how this CMMI Risk Management Process Area might be adapted to address a reuse process.

Table 17: Adapting the CMMI Risk Management Process Area for Reuse

Continuous Representation

Staged Representation

SG 1 Prepare for Reuse Risk Management

SP 1.1-1 Determine Reuse Risk Sources and Categories

SP 1.2-1 Define Reuse Risk Parameters

SP 1.3-1 Establish a Reuse Risk Management Strategy

SG 1 Prepare for Reuse Risk Management

SP 1.1-1 Determine Reuse Risk Sources and Categories

SP 1.2-1 Define Reuse Risk Parameters

SP 1.3-1 Establish a Reuse Risk Management Strategy

SG 2 Identify and Analyze Reuse Risks

SP 2.1-1 Identify Reuse Risks

SP 2.2-1 Evaluate, Categorize and Prioritize Reuse Risks

SG 2 Identify and Analyze Reuse Risks

SP 2.1-1 Identify Reuse Risks

SP 2.2-1 Evaluate, Categorize and Prioritize Reuse Risks

SG 3 Mitigate Reuse Risks

SP 3.1-1 Develop Reuse Risk Mitigation Plans

SP 3.2-1 Implement Reuse Risk Mitigation Plans

SG 3 Mitigate Reuse Risks

SP 3.1-1 Develop Reuse Risk Mitigation Plans

SP 3.2-1 Implement Reuse Risk Mitigation Plans

GG 1 Achieve Specific Reuse Goals

GP 1.1 Perform Reuse Base Practices

GG 2 Institutionalize a Managed Reuse Process

GP 2.1 Establish an Organizational Reuse Policy

GP 2.2 Plan the Reuse Process

GP 2.3 Provide Reuse Resources

GP 2.4 Assign Reuse Responsibility

GP 2.5 Train People

GP 2.6 Manage Reuse Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and Control the Reuse Process

GP 2.9 Objectively Evaluate Reuse Adherence

GP 2.10 Review Reuse Status with Higher Level Management

GG 2 Institutionalize a Managed Reuse Process

GP 2.1 Establish an Organizational Reuse Policy

GP 2.2 Plan the Reuse Process

GP 2.3 Provide Reuse Resources

GP 2.4 Assign Reuse Responsibility

GP 2.5 Train People

GP 2.6 Manage Reuse Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and Control the Reuse Process

GP 2.9 Objectively Evaluate Reuse Adherence

GP 2.10 Review Reuse Status with Higher Level Management

GG 3 Institutionalize a Defined Reuse Process

GP 3.1 Establish a Defined Reuse Process

GP 3.2 Collect Reuse Improvement Information

GG 3 Institutionalize a Defined Reuse Process

GP 3.1 Establish a Defined Reuse Process

GP 3.2 Collect Reuse Improvement Information

GG 4 Institutionalize a Quantitatively Managed Reuse Process

GP 4.1 Establish Quantitative Objectives for the Reuse Process

GP 4.2 Stabilize Reuse Subprocess Performance

GG 5 Institutionalize an Optimizing Reuse Process

GP 5.1 Ensure Continuous Reuse Process Performance

GP 5.2 Correct Root Causes of Reuse Problems

REUSE COSTS

There are a number of economic factors that can affect the success (or lack thereof) of a software reuse strategy, so how can you find out whether the implementation of reuse will be cost effective for your organization? Techniques include cost-benefit analysis of software reuse, performance measurements (based on the types of metrics discussed in the last section), system costing/estimation, pricing criteria/strategies and determination of reuse support costs.

[Mili, 2002], [Lim, 1998], [Tomer, 2004], [Poulin, 1997] and [Fichman, 2001] all discuss, in varying levels of detail, the cost elements that should be considered when assessing software reuse.

Mili discusses how productivity gains can be quantified by the difference in development costs that stems from reusing existing assets versus developing custom assets from scratch. Quality gains can be quantified by the difference in maintenance costs that stems from reusing existing assets versus developing custom assets from scratch. Time-to-market gains can be quantified by the difference in development schedule that stems from reusing existing assets versus developing custom assets from scratch.

Lim categorizes the cost of software reuse as creation, development and maintenance costs; performance degradation costs (where reusable software assets are more “general” than their non-reusable counterparts); the risk of obsolete assets (i.e., changes in technology and/or strategy may impact the value of the assets in a reuse library); and security considerations (e.g., reused code may contain proprietary information. It is recognized, however, that the bulk of costs from implementing reuse is from the development and maintenance of reusable assets, tools and one or more reuse libraries.

Tomer goes into a little more detail in his characterization of reuse cost elements, breaking them down as follows:

· Product Construction Costs, which are comprised of:

o Asset Acquisition Cost (includes the cost of purchasing the asset from a source outside the product, as well as the effort invested in seeking the appropriate asset)

o Asset Development Cost (includes the cost of the analysis, design and coding of new or modified artifacts, as well as the cost incurred by all the verification and validation activities performed directly on the asset)

o Product Integration, Verification and Validation Cost (includes the cost of partial and full integrations, design reviews, subsystem and system testing, and acceptance testing)

· Core-Asset Construction Costs

o Asset Acquisition Cost is the same type of cost as for product assets

o Asset Development Cost is similar to the development cost of product asset development. Product integration, verification and validation costs do not apply, but for compound assets constructed in ways similar to the product, the cost of integration, verification and validation incurred until the core asset is ready for use may be considered entirely as this asset’s development cost.

· Infrastructure Costs

o Repository Establishment and Maintenance Cost (includes the cost of database analysis and design tool development or purchase, database administration, etc.)

o Repository Storage and Cataloging Cost (includes the cost of the effort needed for approving the artifacts for the repository and determining the metadata required in order to enable efficient search and retrieval of core assets in the catalog)

o Domain Analysis Cost (incurred by a set of activities needed to define the scope and the contents of candidate reuse assets, together with locating them in past products and making them available for the core-asset repository)

The Tomer study [Tomer, 2004] also develops a reuse cost model and applies it to an industrial case study.

Poulin describes metrics that should be considered as typical reuse cost-benefit elements (see Table 18).

Table 18: Typical Reuse Cost-Benefit Elements [Poulin, 1997]

Description	Unit
Benefits of Reusing Software…
Reduced cost to design	Labor-Months * $/design
Reduced cost to document	pages * $/page
Reduced cost to implement	$/Line of Code
Reduced cost to unit test	Labor-Months * $/Labor-Month
Reduced cost to design tests	Labor-Months * $/Labor-Month
Reduced cost to document tests	pages * $/page
Reduced cost to implement tests	Labor-Months * $/Labor-Month
Reduced cost to execute testing	Labor-Months * $/Labor-Month
Reduced cost to produce publications	pages * $/page
Added revenue due to early product delivery	months * $/month
Reduced maintenance costs	errors * $/error
Added revenue due to increased sales	sales * $/sale
Reduced tool costs	$
Reduced equipment costs	$
Reduced management costs	Labor-Months * $/Labor-Month
Benefits of Producing Reusable Software…
Added revenue due to income from selling	$ * # users
Added revenue from fees or royalties	$ * # users * # copies
Cost of Reusing Software…
Cost of performing Cost-Benefit analysis	Labor-Months * $/Labor-Month
Cost of performing domain analysis	Labor-Months * $/Labor-Month
Cost of locating/assessing reusable parts	Labor-Months * $/Labor-Month
Cost of integrating reusable parts	Labor-Months * $/Labor-Month
Cost of modifying reusable parts	Labor-Months * $/Labor-Month
Cost of maintaining modified reusable parts	errors * $/error
Cost of testing modified reusable parts	Labor-Months * $/Labor-Month
Fees for obtaining reusable parts	$
Fees or royalties for reusing parts	copies used * $/copy
Cost of Producing Reusable Software…
Cost of performing Cost-Benefit analysis	Labor-Months * $/Labor-Month
Cost of performing domain analysis	Labor-Months * $/Labor-Month
Cost of designing reusable parts	Labor-Months * $/Labor-Month
Cost of modeling/design tools for reusable parts	$
Cost of implementing reusable parts	$/Line of Code
Cost of testing reusable parts	Labor-Months * $/Labor-Month
Cost of documenting reusable parts	pages * $/page
Cost of obtaining reuse library tools	$
Cost of added reuse library equipment	$
Cost of resources to maintain reuse library	Labor-Months * $/Labor-Month
Cost of management for development, test and library support groups	Labor-Months * $/Labor-Month
Cost of producing publications	pages * $/page
Cost of maintaining reusable parts	Labor-Months * $/Labor-Month
Cost of marketing reusable parts	$

Finally, Fichman proposes a methodology that considers the cost of reuse failure as an integral part of the reuse cost estimation process. The costs of reuse failure are defined as those costs incurred when a developer attempts reuse of an existing component and fails. Failure may mean that a software component is not reused in the end, or the cost of the reuse exceeds the cost of developing the component from scratch. The Fichman approach uses failure hazard rates and failure probabilities to ascertain the cumulative cost of the reuse failure. Table 19 provides an example of the Fichman methodology for two scenarios: one where the hazard rate is increasing, and the other for when the hazard rate is decreasing. Note that both scenarios are based on the same overall chance of failure (50%).

Table 19: The Cost of Reuse Failure Modes [Fichman, 2001]

	Step 1	Step 2	Step 3	Cumu- lative
Scenario I – Increasing Hazard
Failure hazard in Step N	0.10	0.20	0.30
Failure probability in Step N	0.10	0.18	0.22	0.50	Overall chance of failure
Cost attempting Step N	$100	$100	$100
Cumulative cost if failure occurs in Step N	$100	$200	$300
Expected value of failure cost for each step	$10	$36	$66	$112	Expected total cost of failure
Scenario II – Decreasing Hazard
Failure hazard in Step N	0.30	0.20	0.10
Failure probability in Step N	0.30	0.14	0.06	0.50	Overall chance of failure
Cost attempting Step N	$100	$100	$100
Cumulative cost if failure occurs in Step N	$100	$200	$300
Expected value of failure cost for each step	$30	$28	$18	$76	Expected total cost of failure

It should be obvious that in order to justify implementation of software reuse there should be demonstrable cost savings. The generic costs that need to be considered in calculating cost savings include those associated with selecting, understanding, modifying, certifying and maintaining reused software. As reported by Leach [Leach, 1997], the amount that can be saved through software reuse depends on numerous factors, including:

§ The life-cycle model used in the software development process

§ The development history of the software system (of which the artifact is a substantial portion)

§ The cost of beginning a policy of software reuse

§ The cost of creating/maintaining a reuse library of software artifacts

§ The percentage of the system that is created using existing software artifacts

§ The percentage of change in each software artifact being reused

§ The different goals for reuse programs at different levels in an organization

Lim [Lim, 1998] highlights some of the financial and accounting issues that should be considered in the implementation of a reuse program as a function of the scope of the reuse. Although explicitly summarized as a cost accounting function, Table 20 implicitly highlights the risks that should be considered, and how they can be mitigated, when addressing software reuse decisions. Financial and accounting elements are essential in the funding, measuring and tracking of an economically viable reuse program. Financing decisions address alternatives for the initial and ongoing funding of the reuse effort, whereas accounting deals with the measurements taken as an integral part of the reuse process.

Table 20: Finance and Accounting Issues by Scope of Reuse [Lim, 1998]

Reuse Type	Finance Issues	Accounting Issues
Personal	· Determine the economic worthiness of producing or re-engineering a work product for reuse	· None
Intraproject	· Address all financial issues outlined in previous levels · Identify the level of funding required to support reuse	· Effort expended for developing and reusing software must be accounted for and tracked
Interproject	· Address all financial issues outlined in previous levels · Identify the appropriate funding and pricing methods	· Address all accounting issues outlined in previous levels · Design/implement a reuse management control system with transfer prices if necessary
Enterprise-Wide	· Address all financial issues outlined in previous levels	· Address all accounting issues outlined in previous levels · Establish appropriate accounting guidelines and policies on the enterprise-wide use of shared work products
Interenterprise	· Address all financial issues outlined in previous levels	· Address all accounting issues outlined in previous levels · Revenues from the sale or licensing of reusable work products appear on the corporation’s financial statements
National	· Address all financial issues outlined in previous levels	· Address all accounting issues outlined in previous levels · Understanding which reusable work product lines should be carried (managerial accounting) and determining product costs (cost accounting) are of greater importance
International	· Address all financial issues outlined in previous levels	· Understand varying accounting conventions for offices in different countries

To assess the cost of implementing a software reuse strategy, there are a number of models that have been developed and promoted over the years. Poulin [Poulin, 1997] has identified the three most common types of reuse economic models. Cost avoidance models attempt to address the question “how much money did I not have to spend because something was reused, rather than having to build it from scratch?”. Return-On-Investment (ROI) models analyze the net benefit of reuse after a certain level of resources have been expended and answer the question “what long-term economic justification is offered by implementing reuse?”. Using this type of model, benefits are typically shown in terms of effort or savings. This type of model may also take into account the time value of money for projects that extend over longer durations. Cost-benefit models help to decide whether software should be considered at all. This type of model analyzes reuse problems by itemizing all of the cost factors influencing reuse, sums the values for the appropriate factors, then bases the business decision on the model outputs.

Since the literature contains a plethora of available reuse cost models, some of which require a great deal of detail in order to use them effectively, only a few basic models will be presented here.

In Lim’s book [Lim, 1998], detailed comparisons are provided between 7 reuse economic models (out of 17 from his original work) using a common lexicon that he developed. One of those models explicitly incorporates a risk factor [Lim, 1992]. For brevity, only this model is presented here (Table 21). Readers interested in details of the 7 models are encouraged to obtain the reference. Anyone interested in the details of all 17 models should contact Wayne Lim at wlim@lombardhill.com

Table 21: A Risk-Based Software Reuse Model [Lim, 1998]

Source	Description
[Lim, 1992]	Calculates the value from reuse by taking the sum of the consumer costs reduced and avoided and the increased profit from reuse, less the producer costs. This figure is then multiplied by a probability which accounts for risk, and finally discounted to take into account the time value of money.
Model

LEGEND:

Consumer
Cc_wrp	Cost to consumer to create product/system without reuse
Cc_rp	Cost to consumer to create product/system with reuse

Producer
Cp_r	Cost to producer to create an asset for reuse

Profit
P	Profit from increased revenues enabled by reuse

Risk
p	Probability of receiving cash flow

Time Value
i	Interest rate by which cash flows are discounted
M	Number of time periods under consideration

Output
NPV	Net Present Value

Lim has also proposed a reuse cost model that states that the cost of debugging software is economically justified when it does not exceed the expected loss due to failure of the software. The break-even point (when the cost of debugging equals the expected loss due to failure) when the code component is used in one product is:

where,

C_d = Cost of debugging

t = Anticipated lifetime of a software product (or combined lifetimes of all copies of a product)

f = Relative frequency with which a code component is executed

E = tf = Number of times the code will be executed

p = Probability that a code component contains a fault

r = fp = Reliability; or the probability of code causing a product failure

c_f = Cost per failure of a code component

If the code component has the potential to be reused in N products, then the total number of executions of the component would be:

The breakeven point when the code component is used in N products is, then:

Since E_total> E, it must be true that C_dN > C_d. The more a piece of code is executed, the greater the expenses for debugging the code that can be justified since it is amortized over several uses. Reuse affords more debugging, which decreases “p”, the probability that the code component contains a defect, and thereby improves “r”, the reliability of the product.

Reifer [Reifer, 1997] describes a basic reuse cost model that was developed by the Software Productivity Consortium (SPC). This model is as follows:

where,

COST = Cost of software development

b = Relative cost to reuse software (b = 1 for new software)

R = Proportion of reused code in the product (R < 1)

E = Relative cost of developing a reusable asset (E > 1)

N = Number of reuses over which the asset development costs will be amortized

Poulin [Poulin, 1993] and Stirna [Stirna, 2005] have described a number of reuse cost measurements that quantify Reuse Cost Avoidance (RCA), Project ROI, and Corporate ROI. These measurements follow:

The Reuse Cost Avoidance (RCA) measurement is intended to quantify the financial benefit of reuse. This is a particularly important metric because it shows the tremendous ROI potential of reuse. Since RCA is a key metric for performing ROI analysis of reuse programs, RCA helps with the insertion of reuse technology. The basic formulae for computing RCA are:

· RCA = DCA + SCA

where,

DCA = Development Cost Avoidance (in dollars) and is calculated as:

DCA = RSI * (1-RCR) * NCC

where,

RSI = Reused Source Instructions (in thousands)

RCR = Relative Cost of Reuse (in decimal)

NCC = New Code Cost (in dollars per thousand source instructions)

Notes: The authors indicate that the relative cost of reuse, i.e., the cost for understanding and integrating reusable parts, is typically about 20% of developing new code (RCR = 0.2). The calculation should also consider that development may typically constitute only 40% of the total system life cycle.

and,

SCA = Service Cost Avoidance (in dollars) and is calculated as:

SCA = RSI * (SDER) * (SDRC)

where,

RSI = Reused Source Instructions (in thousands)

SDER = Software Development Error Rate is the average number of total valid unique program analysis reports (TVUA) per thousand source instructions

SDRC = Software Development Repair Cost is the historical average cost per TVUA (in dollars)

The Project Return on Investment (ROI) measurement calculation is performed using the following formula:

Project ROI = RCA + ORCA – ADC

where,

ROI = Return on Investment that would occur in infinite time (in dollars)

RCA = Reuse Cost Avoidance (see above) for the initiating project (in dollars)

ORCA = Reuse Cost Avoidance for other projects benefiting from the reusable code written by the initiating project (in dollars)

ADC = Additional Development Cost of writing reusable code to the initiating project (in dollars)

and,

where,

ORCA = As described above

SIRBO = Source Instructions Used by Others (in thousands) for each other project

RCR = As described above (in decimal) for each other project

NCC = As described above (in dollars per thousand source instructions) for each other project

SDER = As described above (per thousand source instruction) for each other project

SDRC = As described above (in dollars) for each other project

and,

ADC = (RCWR – 1) * CWRO * NCC

where,

RCWR = Relative Cost of Writing Reuse (number > 1.0)

CWRO = Code Written for Reuse by Others (in thousands)

NCC = As described above

Poulin [Poulin, 1993] has defined the Relative Cost of Writing for Reuse (RCWR) factor as the ratio of the cost of developing a reusable asset divided by the cost of developing an equivalent custom-tailored asset. Mili [Mili, 2002] has published a variety of RCWR factor values (summarized in Table 22) that have been developed since the early 1990’s based on the experiences of a number of sources.

Table 22: Relative Cost of Writing for Reuse (RCWR)

Source	RCWR Factor
Bardo	1.15 – 1.25
Caldwell	1.25 – 1.30
Favaro [1996]	1.00 – 2.20
Gaffney & Cruichshank [1992]	1.50
IBM	1.25 – 2.00
Jones [1994]	1.50
Lim [1998]	1.11 – 1.80
Lockheed Martin	1.86
Margano & Rhoads [1992]	2.00
Pant, et. al. [1996]	1.55
Poulin [1997]	1.50
Reifer [1997]	1.10 – 1.36
Tracz [1995]	1.60

The Corporate Return on Investment measurement is based on the most common way to express ROI at this level, i.e., the internal rate of return (IRR) method, where the discount rate “k” is chosen such that:

where,

C₀ = Corporate reuse start-up costs (in dollars)

R_i = Revenue (savings) in year “i” (in dollars)

C_i = Costs in year “i” (in dollars)

n = Number of years for which revenues are to be considered

k = Discount rate (in decimal)

Finally, the SPC [SPC, 1993a] has also developed and published a model for calculating ROI from software reuse. This model is:

where,

N = Expected number of applications (versions, products, etc.) to be produced by the organization

E = Efficiency of the library infrastructure; the ratio of the amount of reused code in an application system to the available reusable code

C_VN = Unit cost per code size of new code developed for an application system

C_VR = Unit cost per code size of reusing code from the reuse library in an application system

C_DE = Unit cost per code size of the investment in the reuse program

Reference [SPC, 1993b] includes a number of additional reuse economic models that can be used to determine ROI, the break-even number of systems, the effect of reuse on software quality and productivity, and to evaluate incremental investment strategies.

CHARACTERISTICS OF IMPLEMENTATION: