Preparing to Choose a CM Tool

Configuration management (CM) is the ability to answer, at any given time, the question, "What is the state of my system?" Though this may seem simple and straightforward, it’s not an easy question to answer. First, CM isn't limited to software configuration management, which only requires you to determine the software build that was current at a particular date and time. CM is much more comprehensive than that, encompassing such tasks as version control of files, version tracking of external artifacts, task tracking, and bug or issue tracking. Second, systems are complex. One complicating factor is that you probably have several different environments in your system. You will at least have distinct development and production environments. You may also have an integration test environment and, in the case of an operational Web-based application, a deployment staging environment. In addition to managing multiple environments, you may also have portions of your development team in different geographical locations. So as you can see, ensuring you are able to answer this eceptively simple question has profound effects on how you manage the system from inception to operational maintenance.

Once you understand the magnitude of the task, you need to decide how you are going to do it. Configuration management can be done with a word processor, a spreadsheet application, or even a simple pad of paper. That being said, a tool specifically designed for CM usually makes it easier—if it is the right tool for your organization. Each company has its own needs and styles—the tool that was a "lifesaver" for one company may be the death of yours. To determine which CM tool best fits your organization, you need to take a look at what you already do, what a typical CM tool can do to help, and then more specifically, how a tool could help each member of your team within your process.

What is the development process the CM tool should complement?
No configuration management tool can create a coherent process for your team. Once a process is in place the right tool can greatly facilitate it, but trying to force team behavior with the selection of a tool is a losing battle. At best your teams will simply not implement the tool. At worst you may drive people away as you add another task to their workload that appears to add no value.

So before you go out looking for the perfect CM tool, you must look closely at the phases of your own development process. To give you an example of what I'm talking about, I'm going to describe a development process for an N-tiered Weboriented system. The system I’m about to describe may not be much like yours, but it will give you an idea of how to classify your own process.

The qualification phase creates a general concept of the system so that an estimate of the cost and schedule can be generated. During the phase exit review, a management team reviews this information and makes a decision whether or not to implement the project. Each phase will have a phase exit review to give management the opportunity to ensure that teams have accomplished their goals, or to stop the project if it no longer meets business needs.

Once the go-ahead is received, the design phase begins. We gather detailed user requirements to create a detailed design. We build test plans from the requirements. We map all the design and test elements to the requirements so the team can verify that the system will do what was asked of it.

After the design phase exit review,