ASSESS REUSE RISKS AND COSTS
: 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%
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 “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.
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/3rd-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
|
|
|
Ccwrp
|
Cost to consumer to create product/system without
reuse
|
|
Ccrp
|
Cost to consumer to create product/system with reuse
|
|
|
|
|
Producer
|
|
|
Cpr
|
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,
Cd = 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
cf = 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 Etotal
> E, it must be true that CdN > Cd.
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,
C0 = Corporate
reuse start-up costs (in dollars)
Ri = Revenue
(savings) in year “i” (in dollars)
Ci = 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
CVN = Unit
cost per code size of new code developed for an application system
CVR = Unit
cost per code size of reusing code from the reuse library in an application
system
CDE = 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.