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
|