It is important to take a step back from the conventional term of what a CM tool offers and what capabilities you may think a CM tool provides. As development becomes more complex, there are demands to add capabilities to handle the complexity. This is very true with CM. While it may have started as a simple version control tool, the better CM tools are now far more complex and rich in their capabilities. Before you begin the evaluation, do some pre-work so that you have more clarity on the capabilities that you desire.

Dividing up the CM Tool space
This section will attempt to identify the various CM capabilities within a rough framework. Even if you do not agree with this division or you think that some of these areas are misplaced, it is important to ascribe a clear understanding of these capabilities. It is not meant to be comprehensive but to provide a framework to understand that there are different areas in CM and to ensure that the evaluation team understands what they are really looking for.

Version control:  These are tools that offer the capability to store elements and then manage whole or incremental changes of an element (aka versioning), most commonly source code, but often executables and documentation. The more advanced tools in this space offer workspace management and branching & merging capabilities. In addition, there is an expectation that a reporting ability exists that can list the elements within a version control repository specific to a release. This helps in the ability to audit the repository. More details include:

·         Tools in this category typically fall into the development phase but can live throughout the full project lifecycle if documents and other artifacts are being managed.

·         Some people consider document management tools as a type of version control tool since they offer version control functionality and a means for identifying information (a.k.a., attributes) on items.

Change control: These are tools that help you document, manage, and track changes. This may often be called change management although this term is often applied to a broader meaning of the word change (e.g., organizational change management). These tools offer the capability to identify a change and then establish a workflow by which the change can be tracked along a change lifecycle. In addition, there is an expectation that there is the ability to identify and report on the status of configuration items known as a baseline. This helps in identifying baselines for requirements, design, code, build, test, and release and the capability to audit each. More details include:

·         Tools in this category typically live throughout the project lifecycle if changes that impact the project baselines of are being managed.

·         Sometimes requirements management, change control, and defect tracking tools are included in this since each provides similar capabilities.

Build management:  These tools offer the capability to identify a code baseline and then generate executables. More advanced tools in this space offer bill-of-materials reports and dependency and traceability checking that help with integrity and audit. Some people see tools in this space as separate from CM tools but are very closely aligned. More details include:

·         Tools in this category typically fall into the development phase of the project lifecycle.

·         This category may be divided further into build management and continuous build.

·         Build management has a broad focus on providing an automated approach to the full build process (tagging code, setting up build space, executing build, logging build results, and sometimes even some smoke tests).

·         Continuous build has a narrower focus and more specifically on an automated approach to build every time someone checks in a code module to ensure that everything builds together therefore reducing large merge conflicts.

Release engineering: These tools offer the capability to migrate and install deliverables onto a production system. Other details include:

·         Tools in this category typically live the release phase, but may get initiated in the development and test phase.

Considerations leading into the CM Tool Evaluation
Now that you have a good idea of the capabilities you are looking, the next steps are areas to consider prior to performing the evaluation of the candidate CM tools available on the market. These considerations focus on converting capabilities into requirements, applying context, and recognizing that you may need more than one tool to meet your needs.

Capabilities to Requirements
You should build a list of capabilities that you desire irrespective of whether you agree or disagree with the division of capability as laid out above. The important thing is that you identify the capabilities you need prior to actually performing an evaluation. The key is these capabilities form the starting point for requirements. You may drill down deep and sub-divide a capability into multiple requirements. For example, if you consider continuous build as a capability, you may break this down into: ability to support Ant; ability to tie the build process into a version control tool; and the ability to perform build on demand.

Applying Context
In addition to capabilities, it is important to apply the context in which you will be working. The context defines the playing field in which the CM capabilities will be utilized. In this case, it is important to understand how the CM capabilities must work within the context of the development methodology being used and the context on how distributed the development teams may be. Consider for a moment if the CM tool desired might be different if the team is using a phased approach (e.g., Waterfall) vs. an iterative approach (e.g., agile). If the project team is following agile methods, there may be a strong need to support continuous build upon check-in, the a stronger need to support unit testing within the developer’s workspace, a need for a flexible process, and a strong need for refactoring support.

The context also becomes input into expanding the requirements. Consider if the project you intend to implement CM is distributed across several sites. Might this change the type of version control that is needed? Would the “version control” capability be further divided into a requirement that calls for version control that works across multiple sites (e.g., a replication capability of the version control repository) and a requirement to provide flexible branching and merging?

The CM Tool (or Tools) for You
As you conduct the evaluation process, you may find that one CM tool meets all of your required capabilities and requirements therein. However, you may also find that your requirements are not met by one tool. In this case, it may imply that you end up needing two tools (or more) to meet all of your CM needs. This is not unreasonable, in part because there is yet to be a CM tool that meets all of the practices and processes of CM.

Summary
CM can mean different things to different people. Does “control” in CM mean managing all baselines or just the code baseline? Agreeing on exactly all of the CM capabilities is not the point. The point is to ensure you are clear on what possible CM (or CM-related) capabilities there are and then deciding which ones are important to you. By first identifying and understanding the capabilities, provides a good starting point to identifying your needs and then further drilling down to capture requirements for the CM tool evaluation. Then by understanding the context you are working in (e.g., methodology of the development team, the distributed nature of the work, etc.), can help you tailor the tool need for the team.

So, the next time someone asks you, “What is a CM tool?” you can respond that there are a number of areas that CM covers, so it depends on which CM capabilities are best for them and their situation.