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

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

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

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

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

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

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

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:

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

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.