A Framework for Software Product Line Practice, Version 5.0

Configuration Management

The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items [SEI 2000a].

Configuration management (CM) refers to a discipline for evaluating, coordinating, approving or disapproving, and implementing changes in artifacts that are used to construct and maintain software systems. An artifact may be a piece of hardware or software or documentation. CM enables the management of artifacts from the initial concept through design, implementation, testing, baselining, building, release, and maintenance.

At its heart, CM is intended to eliminate the confusion and error brought about by the existence of different versions of artifacts. Artifact change is a fact of life: plan for it or plan to be overwhelmed by it. Changes are made to correct errors, provide enhancements, or simply reflect the evolutionary refinement of product definition. CM is about keeping the inevitable change under control. Without a well-enforced CM process, different team members (possibly at different sites) can use different versions of artifacts unintentionally; individuals can create versions without the proper authority; and the wrong version of an artifact can be used inadvertently. Successful CM requires a well-defined and institutionalized set of policies and standards that clearly define

the set of artifacts (configuration items) under the jurisdiction of CM
how artifacts are named
how artifacts enter and leave the controlled set
how an artifact under CM is allowed to change
how different versions of an artifact under CM are made available and under what conditions each one can be used
how CM tools are used to enable and enforce CM

These policies and standards are documented in a CM plan that informs everyone in the organization just how CM is carried out.

Aspects Peculiar to Product Lines

CM is, of course, an integral part of any software development activity, but it takes on a special significance in the product line context. As illustrated in the following figure, CM for product lines is generally viewed as a multidimensional version of the CM problem for one-of-a-kind systems.

Configuration Management and Software Product Lines

The core assets constitute a configuration that needs to be managed, each product in the product line constitutes a configuration that must be managed, and the management of all these configurations must be coordinated under a single process.

CM for product lines is therefore more complex than it is for single systems. CM capabilities such as parallel development, distributed engineering, build and release management, change management, configuration and workspace management, and process management must be supported by the tools, processes, and environments put in place for CM in a product line context. In particular

In single-system CM, each version of the system has a configuration associated with it that defines the versions of the configuration items that went into that system's production. In product line CM, a configuration must be maintained for each version of each product.
In single-system CM, each product with all of its versions may be managed separately. In product line CM, such management is untenable, because the core assets are used across all products. Hence, the entire product line is usually managed with a single, unified CM process.
Product line CM must control the configuration of the core asset base and its use by all product developers. It must account for the fact that core assets are usually produced by one team and used in parallel by several others. Single-system CM has no such burden: the component developers and product developers are the same people.
Only the most capable CM tools can be used in a product line effort. Many tools that are adequate for single-system CM are simply not sufficiently robust to handle the demands of product line CM. (See the "Tool Support" practice area for a more complete discussion of tools.)

The mission of product line CM is allowing the rapid reconstruction of any product version that may have been built using various versions of the core assets and development/operating environment plus various versions of product-specific artifacts. One product line manager summed up the problem this way: "Sometime, in the middle of the night, one of your customers is going to call you and tell you that his version of one of your products doesn't work. You are going to have to duplicate that product in your test lab before you can begin to troubleshoot."

Product line CM must also support the process of merging results either because new versions of core assets are included in a product or because product-specific results are introduced into the core asset base. Finally, since introducing changes may affect multiple versions of multiple products, you'll want your product line CM system to deliver sound data for an impact analysis to help you understand what impact a proposed change will have.

Although few papers or reports on CM mention software product lines explicitly, academic research and industry analysis show that software CM (SCM) is clearly evolving in ways that will support the needs of product lines. Westfechtel and Conradi, observing the overlap between software architecture and SCM, describe five approaches for the integration of the two disciplines [Westfechtel 2003a]. Estublier and colleagues document both successful (e.g., change sets) and failed (e.g., advanced system models) transitions of research into industrial practice and observe that current research is breaking the underlying assumption that SCM is programming-language and application independent. In particular, they note that all high-end SCM systems are slowly but surely covering the spectrum of functionality identified by Dart in 1991 [Estublier 2005a, Dart 1991a].

Similarly, on the industry side, Schwaber at Forrester Research observes that today's SCM market encompasses a range of four solution segments of cumulatively increasing functionality: (1) version control, (2) software configuration management, (3) process-centric software configuration management, and (4) application life-cycle management [Schwaber 2005a]. According to Schwaber and colleagues, all the major vendors now offer process-centric SCM solutions, and there is growing interest in expanding SCM into application life-cycle management.

Application to Core Asset Development

The entire core asset base is under CM, with support for all the tasks described in the preceding section. Core assets, after all, may be developed in parallel by distributed teams, may need their builds and releases to be managed, and so forth. Beyond this support, however, core asset development requires other features of the organization's CM capability. First, it requires a flexible concept of assets that encompasses hardware, software, and documents of all varieties. One of the more useful features of a CM tool is the ability to report the differences between two versions of an artifact. However, doing so often requires fluency in the language in which the artifact is represented. (If you've ever tried to execute a DIFF command on two binary files, you get the point.) Thus, a tool's difference-reporting capabilities may weigh heavily in the selection process.

Application to Product Development

The CM process should make it easy to set up the initial configuration of a new product. Each time a new product is developed (which can occur very often in a healthy and robust product line), the task of determining the appropriate core assets and how to make them available must be supported.

CM also has to keep track of all the versions of configuration items that are used, including the version of the tool environment (compilers, test suites, and so on) used to create the configuration. Incorporating new versions of core assets to build a new version of a product is a task that requires an impact analysis that must be supported by CM. Changes in core assets must be communicated via the CM process to the core asset development organization.

Example Practices

IEEE/ANSI standard for CM plans: There is a finely detailed IEEE/ANSI CM standard that contains a comprehensive outline for a CM plan as well as several fully worked out examples of CM plans for different kinds of systems and organizations [IEEE 1987a]. These plans contain change control policies, describe organizational roles, define artifact life cycles, and, in general, make a fine starting point for an organization wishing to craft its own CM plan. One sample plan, called the "Software Configuration Management Plan for a Product Line System," is of particular interest. This plan is for a hypothetical organization that produces many versions of a product for a multitude of customers, some of whom are internal to the organization itself. This plan hypothesizes an engineering group (that would seem to mirror our notion of a core asset group) as well as several product groups. This and other similarities to our concept of a product line built as a product family make this plan an excellent place to start.

CMMI steps for CM: SEI Capability Maturity Model Integration, Version 1.1 for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) lists the following practices as instrumental for a CM capability in an organization [SEI 2000a]:

Identify the configuration items, components, and related work products that will be placed under configuration management.
Establish and maintain a configuration management and change management system for controlling work products.
Create or release baselines for internal use and for delivery to the customer.
Track change requests for the configuration items.
Control changes in the content of configuration items.
Establish and maintain records describing configuration items.
Perform configuration audits to maintain the integrity of the configuration baselines.

Best practices from practitioners: Wingerd and Seiwald have written a set of high-level best practices based on their experience, and the experience of others, with deploying SCM [Wingerd 2005a]. Berczuk builds on the success of the "patterns" movement to cast best practices as a collection of 15 SCM patterns [Berczuk 2003a]. Walrad and Strom propose an alternative to the customary branch-by-release branching model [Walrad 2002a], and the Configuration in Industrial Product Families (ConIPF) program in Europe applies the concept of configuration models from knowledge engineering to the problem of product derivation in product families [Hotz 2006a].

Practice Risks

CM imposes intellectual control over the otherwise unmanageable activities involved in updating and using a multitude of versions of a multitude of artifacts, both core assets (of all kinds) and product-specific resources. Without an adequate CM process in place, and without adequate, adherence to that process, developers will not be able to build and deploy products correctly, let alone recreate earlier versions of products. Inadequate CM control can result from the following:

an insufficiently robust process: CM for product lines is more complex than CM for single systems. If an organization does not define a robust enough CM process, CM will fail, and the product line approach to product building will become less efficient.
CM occurring too late: If the organization developing the product line does not have CM practices in place well before the first product is shipped, building new product versions or rebuilding shipped versions will be very time-consuming and expensive, negating one of the chief benefits of product lines.
multiple core asset evolution paths: There is a risk that a core asset may evolve in different directions–something that can happen either (1) by design in order to enable the usage of a core asset in different environments such as multiple operating systems or (2) by accident when a core asset evolves within a specific product. When done by design, the evolution might be unavoidable and increase the complexity of the CM. You must watch for evolution by accident, because it can degrade the usefulness of the core asset base.
unenforced CM practices: Owing to the complexity of the total product line configuration, not enforcing a CM process can result in total chaos (a result that's much worse than that for a single-system).
insufficiently robust tool support: CM that is sophisticated enough to support a nontrivial product line requires tool support, and there is no shortage of available commercial CM systems. However, most of them do not directly support the functionality required for the CM to be useful in a product line context. Many of them can be "convinced" to provide the necessary functionality, but this convincing is a time-consuming task requiring specialized knowledge. If the organization fails to assign someone to customize the CM system for the product line, the CM tool support is likely to be ineffectual. Such a person needs to have both a good understanding of the product line processes and a solid grounding in CM.