scope:

Foreword

Implementing software reuse entails more than creating and using libraries of assets. It requires formalizing the practice of reuse by integrating reuse processes and activities into the software life cycle. Unless reuse is explicitly defined in the software life cycle processes, an organization will not be able to repeatedly exploit reuse opportunities in multiple software projects or products. Without this repetition, the improvement to the software life cycle and the software products that result from the practice of reuse will be limited and, perhaps, disappointing.

Systematic reuse is the practice of reuse according to a well-defined, repeatable process. Practicing systematic reuse enables significant software productivity, quality, and cost improvements. The major benefits that systematic reuse can deliver are as follows:

- Increase software productivity;

- Shorten software development time;

- Move personnel, tools, and methods more easily from project to project;

- Reduce software development and maintenance costs;

- Produce higher quality software products;

- Improve software product interoperability;

- Provide a competitive advantage to an organization that practices reuse.

There are a variety of approaches to implement the concept of reuse. What distinguishes systematic reuse is the avoidance of the proliferation of multiple versions of otherwise common elements. For example, if a reuse approach results in multiple instantiations of a common element, each of which may be modified by software developers, then the element is no longer common and can no longer be maintained as a single element apart from its instantiations. In the context of this standard, systematic reuse excludes those approaches.

The potential for reuse is enormous since the majority of each software product can be built with assets, assuming they are available. An asset is any item, such as a design or test plan, that has been designed to be used in multiple contexts, such as multiple software products, multiple implementations of a software product, or multiple software projects.

One major problem encountered by organizations attempting to practice reuse is that reuse is simply missing from their software life cycle processes. The intent of this standard is to address this problem by defining a common framework for reuse processes and by defining how to integrate the practice of reuse into traditional software life cycle processes.

Reuse processes describe how software products are built with assets and how to build and manage these assets. The reuse process framework presented in this standard covers both the life cycle of a software product that is developed from assets and the life cycle of an asset.

IEEE/EIA Std 12207.0-1996 defines software life cycle processes in general. This standard adds to IEEE/EIA Std 12207.0-1996 the life cycle processes and activities that enable the practice of systematic reuse. Thus, the use of this standard requires access to and an understanding of IEEE/EIA Std 12207.0-1996.

For organizations that already employ systematic reuse processes, this standard may be used to determine the conformity of those processes to this standard, and as a basis for improvement of those processes where warranted. When establishing or improving systematic reuse processes, organizations are encouraged to assess the business case. While systematic reuse enables major benefits such as those already described, there are costs, risks, and other considerations that may prevent those benefits from being realized. These include the following:

- The degree to which reuse benefits are relevant to the organization. For example, a very small organization, or one that experiences insignificant time and costs to develop and maintain software products, may not be in a position to benefit sufficiently from systematic reuse to justify the required commitments and investments.

- The availability of suitable tools and assets that are designed for reuse. The capital costs entailed by new software tools can be significant. The costs of acquiring and/or developing assets may not be justified in relation to the expected benefits.

- The software maturity of the organization. While the organization may wish to undertake systematic reuse, its capability maturity may be insufficient to implement the processes in this standard. Or, the organization may lack the means to change its infrastructure to support the processes of systematic reuse while continuing to operate its business as usual. Capability maturity should be objectively assessed in relation to this standard, and missing prerequisites, both as to capability maturity and as to infrastructure, need to be put in place before attempting to undertake systematic reuse.

- The willingness of the people within the organization to make the necessary changes to the way in which they work. Many software organizations have cultures that are not conducive to systematic reuse. Changing attitudes and associated non-reuse behaviors can be difficult. Policy changes and capital investments, which require senior management to be firmly committed to the achievement of systematic reuse, may be necessary.

Organizations interested in undertaking systematic reuse are advised to analyze their abilities to adopt this standard. A business case that clearly describes the goals, investments, costs, risks, and benefits, along with a timeline for achieving the transition to systematic reuse, is an excellent way to ensure success.

This standard provides the basis for software practices that enable the incorporation of reuse into the software life cycle processes.

IEEE Std 1517-1999 may be used to

- Acquire, supply, develop, manage, and maintain assets;

- Acquire, supply, develop, operate, and maintain software products that are built in whole or in part with assets;

- Manage and improve the organization's software life cycle processes with respect to the practice of software reuse;

- Establish software management and engineering environments based on reuse processes;

- Foster improved understanding between customers and vendors and parties involved in the reuse-based life cycle of a software product or system and assets;

- Facilitate the use of assets to develop software products and systems;

- Facilitate the development of assets.

IEEE Std 1517-1999 has been written to work with and integrate into IEEE/EIA Std 12207.0-1996.

Scope

This standard is intended to describe reuse processes and to relate them to the software life cycle processes that are defined in IEEE/EIA Std 12207.0-1996.¹ (See Annex D of this document.) In this sense, this standard supplements IEEE/EIA Std 12207.0-1996. This standard uses process specifications from IEEE/EIA Std 12207.0-1996 to describe reuse processes.

The scope of this standard will be broader than a single project because reuse processes, such as Domain Engineering, transcend the life cycle of any single software product and apply to a set of related software products.

This standard describes reuse processes at the reference level, as defined by the Basili architecture for process abstraction [B1].² In the Basili architecture, the responsibility for each process is assigned to a party referred to as the "agent." From this viewpoint, this standard can be viewed as a list of agents and their minimum responsibilities.

Like IEEE/EIA Std 12207.0-1996, this standard uses the term party to indicate the individual or organization responsible for executing a process or activity. The party is often designated with a name derived from the name of the process or activity. For example, the party (individual or group) responsible for Domain Engineering may be termed the domain engineer.

The limitations of this standard are in

- Describing a high-level framework for reuse processes, but not the details of how to perform the activities and tasks included in the processes;

- Describing the responsibilities inherent in the various processes, but not the detailed data or control connections among the processes;

- Specifying software life cycle reuse processes at the reference level, but not prescribing a specific software life cycle process model or software methodology;

- Viewing reuse processes as an assignment of continuing responsibilities to agents, but not as a series of steps (procedures) to be performed;

- Specifying provisions for acquiring assets, but not provisions for integration of commercial off-the-shelf (COTS) assets that are not supplied in source code form.

In this standard, as in IEEE/EIA Std 12207.0-1996, there are a number of lists for tasks; none of these is presumed to be exhaustive-they are intended as examples.