Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Configuration Management
Make/Buy/Mine/Commission Analysis
Measurement and Tracking
Process Discipline
Scoping
Technical Planning
Technical Risk Management
Tool Support
Organizational Management
Practice Areas
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

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

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

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

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]:

  1. Identify the configuration items, components, and related work products that will be placed under configuration management.
  2. Establish and maintain a configuration management and change management system for controlling work products.
  3. Create or release baselines for internal use and for delivery to the customer.
  4. Track change requests for the configuration items.
  5. Control changes in the content of configuration items.
  6. Establish and maintain records describing configuration items.
  7. 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:

Further Reading

[Burrows 2005a]
Burrows and Wesley provide a thorough comparison of commercially available CM tools. Their work is required reading for anybody who plans to buy such a tool. Relevant CM industrial standards from IEEE and ISO should also be on every project manager's bookshelf [IEEE 1987a, IEEE 2005a, ISO 1995b].

[Crossroads 2006a]
The CM Crossroads Web site (www.cmcrossroads.com) is an online resource that offers articles, white papers, book reviews, tool reports, discussion forums, and the Configuration Management Journal. It also includes links to other sites with CM information; Software Development magazine's July 2005 article on CM tools and trends is one such example. (To locate that article or others, go to http://www.sdmagazine.com.1)

[Krueger 2002a]
Krueger provides an in-depth discussion of variation management for software product lines.

[Leon 2005a]
Leon's book, now in its second edition, is a comprehensive general CM reference.

Next Section Table of Contents Previous Section

 

1 In May 2006, Software Development magazine merged with Dr. Dobb's Journal. However, past issues of the magazine are still available at this URL.