ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr5/proceedings/ascii/davis_t.ascii

Text File | 1993-05-26 | 19KB | 381 lines

Toward A  Reuse Maturity Model

Ted Davis

Software Productivity Consortium
SPC Building
2214 Rock Hill Road
Herndon, Virginia  22070
Tel: [phone], fax: [phone]
Email: [e-mail]

Roger Williams

Software Productivity Consortium
SPC Building
2214 Rock Hill Road
Herndon, Virginia  22070
Tel: [phone], fax: [phone]
Email: [e-mail]


                      Abstract

This paper suggests a basis for reuse maturity. It describes how the
Virginia Center of Excellence for Software Reuse and Technology Transfer
(VCOE) is developing a model of reuse maturity. We expect development
and validation of the concepts to evolve over several years.  In the
near term, we view the model as a vehicle for capturing successful
reuse practice and for identifying areas where technical and management
problems need to be solved to promote the institutionalization of
reuse. In the longer term we view the model as a vehicle that organizations
can use in identifying actions that they should take to improve their
own reuse capabilities.


Keywords:  Reuse maturity, reuse capability, reuse efficiency, reuse
       proficiency, reuse effectiveness

Workshop Goals:  Promote discussion on what constitutes reuse maturity, what the
         results of improving reuse maturity should be, and the
         requirements a reuse maturity model should satisfy.

Working Groups:  Reuse maturity models


Copyright   1992,  Software Productivity Consortium, Inc. All rights reserved.
This material is based in part upon work sponsored by the Defense Advanced
Research Projects Agency under Grant #MDA972-92-J-1018. The content does not
necessarily reflect the position or the policy of the U.S. Government, and no
official endorsement should be inferred.

Produced by the Software Productivity Consortium under contract to the
Virginia Center of Excellence for Software Reuse and Technology Transfer.


1  Background

The Virginia Center of Excellence for Software Reuse and Technology
Transfer (VCOE) was jointly formed by the Virginia Center for Innovative
Technology and the Software Productivity Consortium. Included in the
VCOE charter is the development of ``Reuse Adoption'' technology,
which supports organizations in the definition, evolution, and implementation
of reuse programs. To support this ``institutionalization'' of reuse,
the VCOE was tasked with developing a Reuse Maturity Model (RMM) which
could be used to define the characteristics of differing reuse processes.
Point-of-departure for the RMM was the SPC's ``Mount Reuse'' five level model
that had been developed in an earlier effort [BH90].

One of the initial purposes of the RMM was to complement and strengthen
the SEI's existing process maturity model by supporting the characterization
of processes that are more systematic in their approach to reuse.

In June of 1992, the VCOE presented a draft of the RMM at a workshop
attended by DoD reuse experts, industry personnel seeking reuse adoption
technology, and industry personnel from other DoD reuse projects including
STARS and CARDS. Although participants approved of some aspects of
the model, they voiced strong objections to others. Some believed
that reuse practice is too immature to even begin to be categorized
by a maturity model. However, most of the negative reaction stemmed
from the relationship of our proposed RMM to the SEI's Capability
Maturity Model (CMM) for processes. Since we had made analogies to
the CMM structure in developing the RMM, many feared that perceived
negative aspects of the CMM would be inherited by production of an
RMM---the most emphatic concern was that a derivative of the RMM
would be used as a mechanism for evaluating a contractor's ability
to reuse. Other participants had an opposite concern: they wanted
to know why there needed to be an RMM that was separate from the CMM.

Our response to the workshop feedback was: 1) to restructure the RMM
so that reviewers could see that it's derivation is not driven by
a need to have 5 maturity levels, and so that they could have greater
visibility and input into the model formulation, 2) to re-emphasize
to the reuse community that we will seek consensus on our model and
that we intend to validate it, and 3) to present the pre-validated
RMM only as a mechanism which postulates and allows examination of
factors leading to successful reuse practice. This paper is an initial
step in our response. In it we present our concept of reuse maturity
and describe what we feel is an appropriate method for formulating
a Reuse Maturity Model.


2  Position

The ultimate need for a model of reuse maturity is to characterize
good reuse practice. Such a characterization of practice would allow
an organization to identify how it might best improve its own software
development efforts. Because the practice of software reuse is not
widespread, not well understood, and not proven as a means for
software productivity and quality improvement,  a Reuse Maturity Model
is needed in the nearer term to provide a common basis for researchers
and practitioners to identify what constitutes good reuse practice. As
a common basis, the model should provide the reuse community with a vehicle
for characterizing best practice, correlating elements of practice
to successful software development, and identifying the most critical
technical or nontechnical barriers to good practice.

These benefits which we expect would come from a Reuse Maturity Model
depend on the assumption that the producers and consumers of reuse
technology can agree on what ``maturity'' means in the context of
software reuse. Therefore, we include here our definition of reuse
maturity which we offer for discussion. In addition, we identify
requirements for a reuse maturity model to serve as a basis for
development of a model.


2.1  Reuse Maturity

Our concept of reuse maturity is based on the assumption that an organization
wants to be more effective in reusing its software assets. Maturity
is intended to be an indication of how effective an organization is
at reuse; this then is the motivation for an organization to increase
its maturity, i.e, that more effective reuse will result. The first
step then is to determine what constitutes effective reuse. Then it
will be possible to define reuse maturity and develop a maturity model
aimed at achieving effective reuse.

Frequently, organizations report reuse results as the percentage of
a product or product line that is comprised of reused software, e.g.,
[PD91] reports reuse as the ratio of total SLOC reused to total
SLOC produced. The implication of these results is that more reuse
is better reuse. Although the citations in [PD91] may be cases
of effective reuse, ``how much'' reuse an organization achieves
is insufficient as an aim for effective reuse.

``How much'' reuse does not reflect how many opportunities for reuse
are missed nor does it reflect how well an organization meets its
intended reuse target (perhaps 75% was feasible, 50% was the organization's
intended reuse, but the actual reuse was 25%). It does not reflect
the benefit realized from reuse with respect to the cost to attain
the benefit (perhaps $90,000 was spent to save $100,000 when it was
only necessary to spend $50,000 to attain the same benefit). It also
does not reflect whether the organization could achieve similar results
in similar situations (perhaps in one instance 40% reuse was achieved,
but in a similar situation only 10% reuse was achieved).

``How much'' reuse an organization achieves may also be subject
to constraints which are beyond the organization's control. For example,
an organization may work in a multi-level classified environment
which forbids reuse from a higher classification level to a lower
classification level. This may severely limit ``how much'' reuse
is achievable, but it should not reflect ineffective reuse if the
organization is capable of exploiting its reuse opportunities within
the constraints of the situation.

An alternative which overcomes the shortcomings identified above is
an adaptation of the concept of process capability, defined in [PCC91],
for reuse--termed reuse capability, which is:

    The range of expected results in reuse efficiency, effectiveness, and
    proficiency that can be achieved by following a reuse process.


Reuse efficiency is the ratio of the actual reuse opportunities
exploited to the organization's targeted reuse opportunities, whether
implicit or explicit. For example, in the case where the potential
reuse is 75%, the intended (targeted) reuse is 50%, and the actual
reuse is 25%, the reuse efficiency is 25/50 = 0.5.

Reuse effectiveness is the ratio of the difference between what it would have
cost to develop  new assets and what it cost to reuse assets times the number of
uses of the reusable assets to the investment costs to acquire or develop the
reusable assets. For example, if it would have cost $100,000 to develop new
assets; $130,000 to develop reusable assets; $10,000 to use the assets; and the
assets are used twice; then, the reuse effectiveness is
2 * (100,000 - 10,000) / 130,000 = 1.38.

Reuse proficiency  is the ratio of the actual reuse opportunities exploited to
the potential reuse opportunities. For example, in the case where the potential
reuse is 75%, the intended (targeted) reuse is 50%, and the actual reuse is 25%,
the reuse proficiency is  25/75 = 0.33.

Thus, an organization with a high reuse capability, not only is able
to achieve more reuse (proficiency), but is also capable of maximizing
its payoff from reuse (effectiveness) and consistently meets its target
(efficiency)---the aim of reuse maturity and the reuse maturity model.

With the aim of achieving a better reuse capability, the preliminary
definition of reuse maturity is:

    The extent to which an organization's process systematically and cost-
    effectively exploits software reuse opportunities.


This definition is based on the concept of systematic reuse defined
in [WPD92] where the opportunities for reuse are predefined and
a process for making use of those opportunities is specified, and
on the principles of reuse economics as captured in the reuse economics
model defined in [GC92]. The implication is that reuse maturity,
as defined above, directly relates to an organization's reuse capability.
This relationship is described in the following section.


2.2  Reuse Maturity and Reuse Capability

Figure 1 characterizes the reuse capability of an organization with
low reuse maturity. The area labeled `Potential Opportunities' represents
the set of potential opportunities in a given environment, i.e., where
an asset (existing or to be developed) satisfies a need (current or
anticipated). It is dashed to indicate that a low reuse maturity process
is one that does not make known the potential opportunities. Because
the potential opportunities are not known, the `Target Opportunities'
will likely fall outside the set of potential opportunities. The target
opportunities represent the set of opportunities pursued by an organization.
The target, also, may not be explicit---this is the case with ad
hoc reuse where an organization is not aware of the reuse activities
performed by its individuals. The set of `Actual Reuse' opportunities
exploited are within the intersection of the potential opportunities
and the targeted opportunities


  Figure 1: Low Reuse Capability


As an example, point a in Figure 1 might represent an asset that was
developed for reuse, but was never used since there was no need for
the asset. Point b might represent an asset collected for reuse for
which there was a need, but it was never found. Point c might represent
an opportunity to develop an asset which would satisfy multiple needs,
but the opportunity was never recognized. Point d represents an asset
which did meet a need and was reused.

`Instance 1' and `Instance 2' represent how an organization's process
might perform when confronted with the same or similar situation.
In this case where the potential opportunities are not known, there
is no explicit target, and no process for assuring actual reuse, the
organization can expect a wide variation in the results.

Reuse efficiency is the ratio of the actual reuse opportunities
exploited to the target opportunities. For `Instance 1' the reuse
efficiency is 0.2, for `Instance 2' the efficiency is 0.08, and the
range of expected results is 0.08 to 0.2 (assuming that these instances
represent the endpoints). In this case the efficiency is low with
a wide variation in results.

Reuse effectiveness is the ratio of the benefit from reuse
to the reuse investment. The reuse investment is proportional to the
effort spent in pursuing the `Target Opportunities' and the benefit
is proportional to the effort saved via the `Actual Reuse' opportunities
exploited. Reuse proficiency is the ratio of the actual reuse opportunities
exploited to the potential opportunities. Similar to reuse efficiency,
there is an expected range of results in reuse effectiveness and proficiency.

Figure 2 characterizes an organization's reuse capability with high
reuse maturity. In this case, the organization's process makes known
the potential opportunities, explicitly establishes a target within
the set of potential opportunities, and has a specified process for
achieving the target. The target may not contain the entire set of
potential opportunities because the potential benefit from those opportunities
outside the target may not have been worth the additional reuse investment,
i.e., the organization maximizes its proficiency with respect to effectiveness.
In this case the reuse efficiency is high with a small variation in
results (0.9 to 0.95).


  Figure 2: High Reuse Capability


2.3  Requirements for a Reuse Maturity Model

The following requirements for a reuse maturity model are provided
for discussion and to serve as a basis for development of a reuse
maturity model:

  * Reuse maturity shall be clearly defined; what constitutes an improved
    maturity shall be clearly identified; and improving reuse maturity should
    lead to an improved reuse capability.

  * A reuse maturity model shall have sufficient flexibility to allow
    organizations to adopt reuse technologies appropriate to their own
    situation, i.e., it should not dictate the use of any one specific
    technology.

  * A reuse maturity model shall be applicable to organizations of varying
    reuse maturity.

  * A reuse maturity model shall aid an organization in determining their reuse
    maturity and allow them to build on their existing capabilities.

  * A reuse maturity model shall encourage reuse by providing a means whereby
    organizations can incrementally commit to reuse and thus reduce the risks
    associated with implementing a reuse program.


3  Comparison

One means for comparison of Reuse Maturity Models is on the basis of the
requirements which they implement. Models reviewed include the Harris Reuse
Maturity Framework (RMF) [KH91], Mount Reuse [BH90], economics model for reuse
[GC92], the SEI Capability Maturity Model (CMM) [PCC91], and the STARS
Conceptual Framework for Reuse Processes (CFRP) [STA92]. Each of these models
provide concepts which may contribute to the development of a model meeting
the requirements stated above, but no single model addresses all of the
requirements.

The RMF identifies factors which should be addressed to improve reuse
practice; Mount Reuse introduces the concept of systematic reuse which
we have incorporated into our definition of reuse maturity; the economics
model provides a basis for defining effective reuse in economic terms
which has influenced our definition of reuse capability; the CMM defines
the concept of capability as an expected range of results, and it
provides a structure for a maturity model (key practices, key practice
areas, and maturity levels) which may provide the needed flexibility
in implementation and incremental commitment; and the CFRP provides
a means for studying reuse processes and a potential organization
of critical reuse maturity success factors.


References

[BH90]  J. Blyskal and B. Hofkin.  Usage Scenario for the Reuse Library Toolset.
        Technical Report EX_US_RLT-90052-MC, Software Productivity Consortium,
    October 1990.

[GC92]  J. Gaffney and R. Cruickshank.  A General Economics Model of Software
    Reuse.  In 14th International Conference on Software Engineering,
    May 1992.

[KH91]  P. Koltun and A. Hudson.  A Reuse Maturity Model.  In Fourth Annual
    Workshop on Software Reuse, November 1991.

[PCC91] M. Paulk, B. Curtis, and M. Chrissis.  Capability Maturity Model for
    Software.  Technical Report CMU/SEI-91-TR-24, Software Engineering
    Institute, 1991.

[PD91]  R. Prieto-Diaz.  Making Software Reuse Work: An Implementation Model.
        ACM SIGSoft Software Engineering Notes, July 1991.

[STA92] STARS.  STARS Reuse Concept--Conceptual Framework for Reuse Process.
    Technical Report STARS-TC-04040/001/00, Defense Advanced Research
    Projects Agency, February 1992.

[WPD92] S. Wartik and R. Prieto-Diaz.  Criteria for Comparing Domain Analysis
    Approaches.  International Journal of Software Engineering and
    Knowledge Engineering, September 1992.


4  Biography

Ted Davis is the technical lead for the VCOE reuse adoption project and is
responsible for developing the Reuse Maturity Model and reuse adoption process.
Previously Ted had supported the development and validation of the Software
Productivity Consortium's Evolutionary Spiral Process for software development
and the Synthesis process for domain engineering. Prior to that, Ted was an
officer in the U.S. Air Force for eight years where he developed and acquired
command and control systems. Ted has a M.S. in Computer Science from Purdue
University and a M.S. in Systems Management from the University of Southern
California.

Roger Williams  is the project manager for the VCOE reuse adoption project and
oversees the production of the Reuse Maturity Model and the Reuse Adoption
Guidebook. His previous work at the Consortium includes management of the
Evolutionary Spiral Process Validation Project and he also supported
development of the systems engineering principles of the Synthesis process.
Roger is an assignee from the Boeing Defense Space Group. His prior work with
Boeing includes support of concept definition and advanced development efforts
for Space Station Freedom software, system and software definition for embedded,
fault tolerant computing systems, and verification and validation of the
Inertial Upper Stage operational flight software. Roger has a B.S. in Systems
Engineering from the University of Florida.