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:

 

1. 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
2. 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.
3. 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
4. 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
5. 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
6. 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 “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:

 

1. 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
2. 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.
3. 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
4. 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
5. 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
6. 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

 

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