ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr4/proceedings/detex/koltun.detex

Text File | 1992-04-05 | 11KB | 257 lines

 [12pt] article









  A Reuse Maturity Model

  Philip Koltun and Anita Hudson
CASE Center
Harris Corporation
1025 W. NASA Blvd., MS 3A-8155
Melbourne, FL 32919
407-727-5958, 407-727-4686
E-mail:  [e-mail]
         [e-mail]





The authors have prepared a draft Reuse Maturity Model to assess
organizational processes instrumental to achieving high levels of
reuse. This position paper outlines the model and its rationale,
and lists sample questions that might be used to determine maturity
level. The authors have presented portions of the model informally
at prior Software Productivity Consortium-sponsored workshops, and
have received initially positive reactions. Participation in the
5th Annual Workshop on Software Reuse would present an additional
opportunity to gather valuable feedback. The model, in fact,
provides a concise way of gathering information on reuse practices
within industrial organizations. Thus, asking attendees to plot
their reuse maturity should prove a useful exercise.

  0.3in

   Keywords:
Reuse process, process model, reuse maturity model, reuse maturity
characteristics



  Position
The model consists of a maturity framework with five levels:
Initial/Chaotic, Monitored, Coordinated, Planned, and Ingrained.
Ten dimensions or aspects of reuse maturity have also been
enumerated. For each dimension, an attribute or characteristic
situation has been specified for each maturity level. Thus, for
example, at the Initial level of reuse maturity, we suggest that
the dimension ``Reuse Inventory (Assets)'' would characteristically
be a ``Salvage Yard - no apparent structure to the collection.''
Incorporation of such characteristic descriptions should enable
companies to find their place in the maturity framework with a
minimum of effort.

Motivation for developing the Reuse Maturity Model comes from
observing the enormous impact the Software Engineering Institute's
software Capability Maturity Model has had. The SEI has focused
attention on process issues in a most remarkable way by examining
characteristic engineering practices and providing a means to
classify an organization into one of five maturity levels.
Moreover, the SEI has established the principle in people's minds
that the quality of a software product is dictated by the quality
of the processes used to develop that product. We seek to
capitalize on that notion by focusing attention on the underlying
processes needed to successfully reuse software. Furthermore, the
SEI has convinced executive managers that process improvement must
come a step at a time, by laying a foundation for process
improvement on which other improvement activities can build. We
seek to convince executive managers of a similar notion: that a
solid foundation for software reuse must be laid and built upon, a
step at a time.

We also admire the impact which the SEI achieved with the
presentation of an integrated maturity model.  Attempts to foster
higher levels of reuse may have foundered in the past because they
dealt only with technology issues, such as classification
mechanisms, or only with business issues, such as data rights.
Through our Reuse Maturity Model, we hope to convince executive
management that achieving reuse requires a comprehensive approach.
Many pieces must fall into place before significant advances can be
made. In a manner similar to the SEI model, an organization must
satisfy all the conditions for Level 2 reuse maturity in order to
lay the foundation for achieving Level 3 reuse maturity.

The Reuse Maturity Model was developed during a year-long system
improvement project at Harris Corporation.  We identified numerous
obstacles that must be overcome in order to achieve high levels of
reuse, among them:



   Cultural:  Incentives and management backing must be put in
     place; any tendency toward NIH (``Not Invented Here'') syndrome
     must be eliminated.

   Institutional:  A corporate-wide forum is needed to discuss
     common product areas where reuse could pay off. Points in the
     product development cycle must be identified where reuse
     concerns can always be raised and resolved. An ongoing group
     must take up responsibility for advocating reuse and managing
     reusable assets on a day-to-day basis - in other words, for
     making reuse succeed.

   Financial:  The costs and benefits must be understood for a
     product life cycle based on a "Design for Reuse" philosophy.
     Reusable work-products must be viewed as capital assets that
     require maintenance and enhancement.

   Technical:  Guidelines, techniques, and standards for making
     things reusable must be developed; mechanisms must be put in
     place to ensure they are followed.  Taxonomies and retrieval
     mechanisms for cataloguing and recovering reusable parts will
     be needed; assurance mechanisms will be needed to guarantee
     the suitability of a part for a stated purpose; etc.

   Legal:  Negotiations must be undertaken to determine how to
     retain rights to components developed under customer contract
     and recover costs in a reuse context.  Mechanisms will be
     needed for payment and collection of royalties (a la the music
     industry) for use and reuse in the commercial arena.



We concluded that achieving reuse must be recognized for what it
is: a challenge requiring significant organizational commitment and
fundamental organizational changes. Moreover, these changes will
not occur overnight, but must be undertaken step by step. The
authors hope that formulation of the Reuse Maturity Model will
enable executive management to see Software Reuse as an
interconnected set of cultural, institutional, financial, technical
and legal challenges that must be tackled in coordinated fashion.

Figure 1 presents the dimensions of reuse maturity considered
critical in analyzing an organization's commitment to reuse. For
each combination of maturity level and maturity dimension, the
authors have described a characteristic situation that might exist.
Figure 2 was developed for briefing executive management. It
describes each reuse maturity level narratively and highlights key
realizations and events that might provide the impetus to advance
to the next maturity level.

Questions have been formulated to determine an organization's
readiness to encourage reuse.  A subset of the questions, presented
below, suggest a myriad of activities needed to promote reuse.



Has an incentives program been established (organizational
     awards, individual awards, etc.)?

     Have metrics of reuse been established?  collected? Have
     savings attributable to reuse been established?  Have the
     costs of non-reuse been identified?

     Is there a designated individual or group responsible for
     making reuse happen (by collecting reusable things, assessing
     their quality, enhancing them, etc.)?

     Is there a catalog of reusable components?

     Are life-cycle products (requirements, designs,
     implementations, documentation, test plans, etc.) all
     collected?

     Is a central review of all projects performed to assess
     commonality and reuse potential?

     Is reuse activity linked to strategic business plans (i.e.
     product development plans)?

     Do training programs exist for reuse?

     Are reuse concerns addressed at various life cycle points
     (SSR, PDR, CDR, etc.) and incorporated in project reviews?

     For the most part, do people work on projects similar to ones
     in their work experience?

     Is a lessons learned exercise (including characterization of
     work products) a mandatory part of project closeout?

     Is a use history and a reuse history kept for each item in the
     inventory?


The authors hope that presenting such questions will help executive
managers realize that large-scale reuse is harder to achieve than
it might first appear. We hope to convey the message that one
person can reuse the tools and components he's built before and a
small group can share such things effectively. But large-scale
reuse, the kind that results in competitive leverage, requires
organizational planning and commitment.

Our Reuse Maturity Model suggests an orderly way to build the basis
for reuse, that is, by taking the characteristic description at
each maturity level/maturity dimension combination and turning it
into a positive activity.  For instance, the characteristic
description at the Coordinated level/Classification Activity
dimension suggests working out a single classification scheme and
periodically publishing the catalog of reusable components.

In terms of continuing work on the Reuse Maturity Model, we are
just beginning to systematically collect feedback from industrial
organizations on its usefulness. Inasmuch as we have seen many
Level 1 Reuse organizations, only a handful of companies at the
intermediate levels, and can only hypothesize what a Level 5 Reuse
company would look like, we expect some significant revisions will
be needed to the model. An additional step will be augmenting the
reuse maturity questionnaire and organizing subsets of the
questions to address each level of reuse maturity separately. We
will also consider a scoring scheme to determine an assigned reuse
maturity number.  While calculating a score is less important than
identifying reuse process areas needing improvement, a
single-number maturity level nonetheless provides something for
people to latch onto. Progress toward reuse process improvement can
be more objectively measured.


  About the Authors

Phil Koltun is Manager of the CASE Center at Harris Corporate
Headquarters, with responsibility for internal consulting on
software tools, methodologies, and practices with all of Harris'
divisions.  Previously, he managed a software technology center at
Harris which performed applied research on artificial intelligence,
database, and computer security problems.

Phil has also chaired the Florida High Tech Council's Software and
Computer Science Research Subcommittee, and is current chair of the
Industry Advisory Board of the Software Engineering Research
Center, an industry-university cooperative venture.

He holds a Ph.D from the University of North Carolina-Chapel Hill
in the area of software methodology.

Anita Hudson is a member of the CASE Center at Harris Corporate
Headquarters, where one of her responsibilities is to transfer
reuse technology throughout the corporation. Prior to joining the
CASE Center (as a charter member), Anita was a software engineer in
the Harris Government Satellite Communications Division.

She has been a member of the SPC (Software Productivity Consortium)
Reuse Technical Advisory Group for 2 years and participated in the
STARS/Users Workshop Discussion Group on Technical Barriers to
Reuse.

Anita holds a B.S. in Computer Science from Florida Institute of
Technology.