CM: The Nerve of Your Life Cycle Management

Perhaps you view CM as just another component of your ALC management suite. Let's explore a different approach by understanding CM as a capability that can be applied to the various components.

The ALC requires management tools spanning a wide spectrum. From "Request Tracking" and "Requirements Management" through to "Deployment Management," "Problem Tracking" and "Customer Tracking," there are a range of component tools required to manage the lifecycle. Internally, we use our own tool [CM+] for:

• Request Management
• Requirements Tracking and Traceability
• Projects and Activity Work Breakdown Structures
• Document Management
• Software Version Control
• Change Management
• Baseline and Build Definition
• Problem Tracking
• Test Case and Test Run Tracking
• Build and Release Management
• Deployment
• Customer Tracking

That's quite a list of tool components. So, where does Configuration Management fit in? Is it all of these, some of these, none of these? Configuration Management is a backbone technology.

We carefully choose the areas to which we apply Configuration Management. And how much CM we use for each area is carefully customized. Here's how we apply CM in our shop.

We use CM for Source Code Management

- no surprise. Tracking thousands of files and directories requires version identification, baseline definition and context-sensitive ways to view the source tree. And we need control and auditing of the changes to the configuration. Because there are so many objects to track, we need a way of hierarchically collecting and navigating them. Because changes often involve more than one file and/or directory, we need a means of collecting newly created revisions so that we can deal with them as a group (i.e. a change). Because changes are so frequent we also think it's a good idea to be able to track several minor increments without having to redefine a new reference point, or baseline, nearly as frequently.

We also use CM for Requirements Management

In many ways it's much the same as for source code management. Again, though not necessarily files and directories, we have dozens, hundreds or perhaps thousands of requirements, hierarchically arranged. We need to track the various revisions of each requirement, and to collect together revisions which fall out of a given request or focus. Baseline definition is critically important, as is change control. But we don't have the same need for increments in between baselines. We do have the need to be able to specify a given baseline, or even a rule-based alignment, and to view and navigate that easily. We generally don't use files to define each requirement (apart from attachments), but even so, if our mission were only to manage requirements, we'd certainly require a strong CM capability.

Test Cases Are Yet Another Area Requiring CM

Test cases need to be arranged in functional groups, but benefit from automatic number assignment rather than requiring that each test case be given a name, as is typically done for source files. Test cases evolve in much the same way as source code - multiple revisions until the test case is properly defined, and branches when the test case is different in one major release than in another. Although change grouping might be useful, it is less of a requirement because test cases are typically modified individually or according to their functional grouping. Baselines are important so that we can relate the correct test case revisions to the test runs performed on particular builds. We need to be able to track things like which test cases were performed in a given test run, and when did the test case last fail, or last pass successfully. The test case has to be traced to a