Nine Characteristics of a COTS and Reuse Management Plan

NEWS AT SEI

Authors

Bill Anderson

Edwin J. Morris

Dennis B. Smith

Mary C. Ward

This library item is related to the following area(s) of work:

System of Systems

This article was originally published in News at SEI on: January 1, 2005

Commercial, military, and other government organizations continue to increase their reliance on reused software to provide major capabilities in new systems. This reused software goes by many different labels, including commercial off the shelf (COTS), government off the shelf (GOTS), shareware, freeware, open source, and non-developmental items.

When components are used for large-scale systems of systems, they can have unforeseen effects on other parts of the systems. One way to minimize these effects is to develop a COTS and reuse management plan, similar to one that we recently developed in collaboration with a large DoD program.

In developing this plan, we identified nine characteristics that are fundamental to long-term use of complex reusable software. These characteristics include

1) A product line strategy: A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Building a set of software systems as a software product line, compared to developing the systems one at a time in isolation from each other, has been shown to shorten development time, increase productivity, increase quality, and reduce cost.

A product line strategy provides for systematic reuse. This contrasts with a “clone-and-own” approach in which a reusable asset is discovered, modified, and installed in the product. When using such an approach, maintenance and evolution are no longer shared with other members of the product family.

To effectively implement a software product line, the reuse management plan should define processes for

  • determining when a product line is appropriate
  • developing a flexible product line architecture
  • identifying the core components within the product line
  • building a production plan that describes how the core components will be reused
  • defining a construction management process to control maintenance and evolution of the product line

2) An iterative process: Use of COTS components does not lend itself to waterfall-type development, since neither reused components nor our understanding of them is static. Managing the dynamic nature of components and their interactions with each other and the rest of the system is a key to effective reuse.

A COTS and reuse management plan should follow an iterative approach to development and long-term sustainment of systems that supports

  • iterative refinement of system requirements, architectures, and reuse-component commitments to balance the tension between users and implementers and reuse components effectively
  • early identification of risks and application of risk-mitigation strategies

3) A reuse component manager: It is also important to consolidate management activities under a central authority. This authority serves as the clearinghouse for information and the organizer of reviews and other tasks. Each component considered for reuse should be assigned a reuse component manager.

Among the responsibilities of the reuse component manager are

  • notifying affected organizations of plans or changes to plans for use of a component
  • organizing and stewarding life-cycle activities such as component (re)evaluations, version upgrades, analysis of patches, reviews
  • monitoring risks associated with use of the component
  • directing market-watch activities for the component
  • developing and implementing a strategy to create and manage vendor/provider relationships

4) Risk-based management of components: Virtually any characteristic of a component or component provider may increase the risk for a specific system. The processes that may require tailoring based on reuse component risks are

  • requirements processes to focus on putting critical components to best use
  • evaluation processes that change the scope and extent of evaluation activities
  • review processes that assure that high-risk components are reviewed with sufficient frequency by the right people
  • engineering processes to focus proper attention on the component and its interactions with the rest of the system
  • problem and risk reporting processes
  • processes for validating and approving patches and upgrades

5) Full life-cycle coverage: Our experience suggests that long-term costs of maintaining reused code often exceed initial procurement costs. Life-cycle challenges include

  • guidance on architecting, designing, integrating, and testing when using reused components
  • problem reporting and management
  • impact analysis for requirements changes, new versions, problems, and patches
  • license management
  • managing relationships with component providers
  • metrics for reuse components
  • periodic reviews of the health of the component (health check)

6) Aggressive evaluation and selection of components: A wide-ranging and aggressive evaluation and selection process for components should be documented as part of the plan.

This process includes

  • a make-reuse decision that is based on analysis of the expectations for the component within the system and of the marketplace of components that can be reused
  • organized planning for evaluation and selection of components
  • evaluation criteria for critical aspects of the component
  • defined processes for evaluation and selection of components (Bergey, J.; O’Brien, L.; & Smith, D. Options Analysis for Reengineering (OAR): A Method for Mining Legacy Assets (CMU/SEI-2001-TN-013, ADA395201). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2001.) that provide guidance on evaluation and selection of large-scale assets (like subsystems) and COTS components, respectively; these processes can be modified to fit other types of reuse components.
  • mechanisms for capturing not only information about components but also impact of components on requirements, architecture, design, implementation, testing, and deployment of the system

7) A complete historical record: Central to any good reuse management plan is complete documentation about reuse components considered, selected, and used within the system.

Data should include

  • history of evaluation/selection of reuse components, including criteria, rationale for criteria, data/results of evaluation, and rationale for selection
  • licensing information
  • history and archive for version releases
  • metrics data and analysis
  • identification of other components that depend on the reuse component and components on which the reuse component depends
  • results of periodic reviews and component health checks
  • information about preparation of a component version for inclusion in the system (e.g., tailoring, modification, parameters and settings)

8) A component health check: The status of reuse components should be reviewed frequently (for instance, biannually) to determine whether existing strategies for use of the component remain valid.

The component health checkup normally considers four primary sources of information:

  1. information gathered by the component manager while performing his/her activities
  2. information summarized from tracking the reuse component (e.g., problems, risks, patches, versions, vendor plans)
  3. information gathered during market-watch activities
  4. information from users about evolving expectations for the component

9) Metrics for improvement: The typical metric associated with reuse components is an equivalent SLOC count that is intended to represent the effective savings of procuring rather than building the component. Often this count includes measures of the integration effort associated with the component.

Later in the development process, actual performance in incorporating the reuse component against earlier estimates is often tracked. In addition other sources of data can include

  • stability or instability of requirements related to reuse components
  • a summary and analysis of defects in reuse components
  • stability of contacts and consistency of information regarding the reuse components
  • frequency of release schedule and success in meeting schedules
  • complexity of adaptation code

About the Authors

Edwin Morris is a Senior Member of the Technical Staff at the Software Engineering Institute, assigned to the Integration of Software-Intensive Systems (ISIS) Initiative. He is currently investigating approaches to achieving technical interoperability between complex systems and programmatic interoperability between the organizations that build and maintain them. Previous activities involved improving processes and techniques for the evaluation and selection of COTS products, and the development of the COTS Usage Risk Evaluation (CURE) technology. Before coming to the SEI, Ed developed custom operating systems for embedded microprocessors along with support tools to predict and monitor the performance of real time systems.

William B. Anderson is a senior member of the SEI technical staff. Bill’s research interests include integration and interoperability of complex software systems, COTS and reuse management, cost estimation, and business case justification of complex systems. A former Vice President for a Fortune 500 company, Bill is broadly experienced with factory floor and business; processes, support systems, automation, and management. He has many years of experience in large system project management and has successfully led operational, financial, product line, and new product launch groups.

Dennis Smith is the Lead for the SEI Initiative on the Integration of Software Intensive Systems. This initiative focuses on addressing issues of interoperability and integration in large scale systems and systems of systems. Earlier, he was the technical lead in the effort for migrating legacy systems to product lines. In this role he developed the method “Options Analysis for Reengineering, OARS to support reuse decision-making. Dr. Smith has also been the project leader for the CASE environments project. This project examined the underlying issues of CASE integration, process support for environments and the adoption of technology.

Dr. Smith has published a wide variety of articles and technical reports, and has given talks and keynotes at a number of conferences and workshops. He has an M.A. and PhD from Princeton University, and a B.A from Columbia University.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.