Changes: The Crossroads Between Project CM and Product CM

of a product or product family into another release. Simply, this can be represented by the following diagram.

We've talked about the transformation to this point in time. The WBS was generated by looking at the existing release of the product (the left side of the diagram) and using the requirements tree for the project, spawned activities. The aggregate of these activities, when added to the existing release, results in the planned release (shown on the right side of the diagram). An additional component of the transformation is the generic defect correction (bug-fixing) activity which takes some subset of the outstanding product defects and corrects them so that the product more closely resembles the specifications.

When we talk about the WBS for a development stream, we naturally refer to the stream name. For example, the WBS for the release 2 of a product would normally be referred to as the release 2 project plan. It would transform release 1 of the product into release 2. For this reason, all activities in the release 2 project plan would be tagged with the stream "rel2", for example. If a product road map has been established and some activities need to be pushed into release 3, the tag on the activity is changed, even before the WBS for release 3 exists.

Product CM

Product CM deals with managing a product or set of products. This can occur in several areas: managing several products within one CM library, managing product/sub-product relationships, and managing third party products. Configuration Management deals with managing consistent collections of source files and their deliverables. There are multiple revisions of files and data, typically organized into branches. There are various deliverables which need to be built. There are dependencies both between source files (e.g. includes) and between deliverables.

In most CM systems, branches are used to collect files for a particular release, to collect files into logical changes, to collect incremental files for a patch build or a custom build, to separate promotion levels, etc. More modern CM systems use branches only, or primarily, to organize revisions into release streams. Other first class objects provide additional collection mechanisms. For example, baseline records identify files for a particular release, changes collect files into logical changes, build records collect incremental files for patch or custom builds, promotion models on changes and build records work with the CM tool to provide dynamic promotion level views.

This difference is significant. In one case, development and implementation of clear branching strategies, labeling mechanisms as well as significant merging activity from branch to branch form an extensive component of the CM task. In the latter case, the first class objects (changes, build records, baseline records, etc.) clarify and simplify the CM task. With proper change management and development stream capabilities, branching can be fully automated, merging reduced to transfering non-shared functionality between release streams and labelling can be fully eliminated.

Product CM deals not only with organization of the CM data, but also with support for generation of the deliverables. This implies creation and/or management of build scripts, configuration management of build tools and processes, and support for deployment of files for the build process.

On a related front, Product CM deals with the population of workspaces and the establishment of data views. In some tools, such as ClearCase, these two are intimately connected. Other tools tend to distinguish between the tool view and the user workspace. In these cases comparison of the view to the workspace, and associated synchronization and deployment issues need to be addressed.

Managing Multiple Products

A good CM tool will allow