The CCM Cube

Configuration and change management (CCM) covers three interdependent functions. These key aspects can be illustrated using the "CCM cube" shown in Figure 13-1.

Figure 13-1. The CCM cube

The cube has three faces, and each face examines a different aspect of the problem. All three aspects are deeply intertwined:

• The configuration management face is related to the product structure.

  Configuration management (CM) deals with artifact identification, versions, and dependencies among artifacts, as well as the identification of configurations that are consistent sets of interrelated artifacts. It also deals with the issue of providing workspaces to individuals and teams so that they can develop without constantly stepping on one another's feet.

• The change request management face is related to the process structure.

  Change request management (CRM) deals with the capture and management of requested changes generated by internal and external stakeholders. It also deals with the analysis of the potential impact of the change and with the tracking of what happens with the change until it is completed.

• The status and measurement face is related to the project control structure.

  Status and measurement deals with the extraction of information for project management from the tools that support the configuration management and the change request management functions. The following information is useful for an assessment:

  - The product's status, progress, trends, and quality

  - What has been done and what remains to be done

  - The expenditures

  - The problem areas that require attention

Now let's examine each of these three aspects in detail.

Configuration Management

The configuration management aspect of this discipline deals with the product structure, as shown in Figure 13-2. Important artifacts are placed under version control. As an artifact evolves, multiple versions exist, and you must identify the artifact, its versions, and its change history.

Figure 13-2. Product structure and workspaces

Artifacts depend on one another. As a result, each change causes a ripple effect. When an artifact has been modified, dependent artifacts should be revisited and possibly modified or regenerated. For example, a C++ source file depends on the header files it includes. It also depends on the class specification it implements.

The latest version of an artifact often is the best one, but there are many circumstances in which things are not that simple: Multiple developers may work in parallel on the same artifact, or variants of the same artifact may be required for different end products.

The knowledge of the dependencies among artifacts, the transformations that occur along the dependencies, and perhaps the tool used to effect these transformations can be exploited to re-create stacks of dependent artifacts. For example, a makefile can be created to trigger the recompilation and linkage of an entire application based on a few modified source files.

Build management is about making sure that components that would constitute a build are available and are assembled in the right order based on their dependency hierarchies. Effective build management requires that we can trust that constituent components have been developed and tested adequately to be included in a build. This is akin to the notion of a pedigree: An artifact is OK only if its ancestors are OK.

A workspace provides a "sandbox" in which individual developers or small teams work as if they were isolated. It provides access to a necessary set of artifacts. Workspaces, playing the role of staging areas, can be used for basic development or for the progressive integration of products.

The overall product structure ”the organization of all artifacts ”is driven by the implementation view of the architecture.

Change Request Management

Change request management deals with the process structure and is shown at the top of the cube in Figure 13-3. A change request is a documented proposal of a change to one or more artifacts. Change requests can be raised for a variety of reasons: to fix a defect, to enhance product quality (such as usability or performance), to add a requirement, or simply to document the delta between one iteration and the next .

Figure 13-3. Change requests

Change requests have a life represented as a simple state machine, with states such as new, logged, approved, assigned, and complete. As the change requests go from state to state, information about the change is added, such as the reason for the change, the motivation, the affected artifacts (artifacts that must be modified simultaneously ), and the impact on the design, the architecture, the cost, and the schedule. Not all change requests are acted on. A management decision must take into account the result of the impact analysis and relative priorities to determine which changes will be implemented, when they will be implemented, and in which release they will be implemented.

To perform a given change, the exact workflow is driven by the type of artifacts affected and their dependencies. If a change affects the design of a class, the workflow will include the Activity: Design Class and the Role: Designer. The workflow may also include any activity and role affected downstream, such as Activity: Review Class, Activity: Database Design, Activity: Implement Class, and so on. In a sense, change requests drive the actual process.

Changes to artifacts are tracked and associated with the corresponding change request. Change requests are closed when the change has been completed, tested, and included in a release.

Status and Measurement

The status and measurement aspect deals with the project control structure and is shown on the right face of the cube in Figure 13-4. Change requests have a state, as well as other attributes such as root cause, nature (such as defect or enhancement), severity, priority, and area affected (such as layer or subsystem). The various states of a change request provide useful tags as the basis for measurement reporting.

Figure 13-4. Status and measurement

Many change requests are accumulated in a change request database, and they represent the bulk of the work to be done during an iteration, especially in the construction and transition phases.

From this database, we can extract status information on the progress of the project:

• Overall progress of the project relative to the changes

• Number of changes made in the various states

• Age of the change requests ”that is, how long they have been in a particular state

We can also extract reports on the distribution according to the following:

• By severity or priority

• By layer or subsystem affected

• By team

• By root cause

Trend reports look at the derivative of these measurements over time, a measure that is useful for projection.