Evaluating CM Tools

This is not a new topic. But this is what I expect from a CM tool.

• Reliability and Accessibility
• Low Administration and Small Footprint
• Change Packages
• Getting Started Fast
• CM Capabilities
• Integrated Suite
• Easy configuration and process capability
• Easy To Use
• Low Cost of Ownership

The Key Evaluation Areas

1. Reliability and Accessibility - If my team is going to waste time, I'd just as soon have SCCS. A CM tool must have ultra high reliability and availability. If something does go wrong, I want to be able to recover - from disk crashes to disaster recovery. Even from data sabotage. Make backups as painless as possible so that they get done. Don't take down the whole team because a server is down. If my team is distributed, a multiple site solution must allow reliable access to all project data that I'm allowed to access.

2. Low Administration and Small Footprint - These go together - if it's not a small footprint, it's not going to be low administration. Ideally, it's "set-and-forget" technology and I don't have to buy special hardware or software to get the solution going. I don't want a CM tool that's going to force me to spend more on CM - I want one that's going to do the job by itself. I don't mind having to archive transaction journals, do backups, etc. But don't ask me to continually tune my system, re-distribute my data, calculate and perform manual synchronization operations (e.g. between sites or data partitions). And don't ask me to spend weeks on course to learn the system.

3. Change Packages - Sure I want to know what files are in my tree and I want to organize them, but when it comes to making changes, I want to create changes, not just edit files. My changes should flow through the system. Downstream personnel, including builders, should not even need to know if my change involved one file or ten. I don't want to have to check in each file separately, perhaps forgetting one, do delta/difference reports on each file, do promotion of each file or even merge each file into a different branch. I want to do all of these things on a Change basis. And I want to track my structural changes (add, remove, delete...) as part of my Change. Ideally, the change would be the place to associate traceability data, integration information and some level of test data (unit testing).

4. Getting Started Fast - OK, I only have to get started once. Well, at least until I load in a new product. But I want to be able to get started quickly. Low training requirements, easy to install (and evaluate), easy to create a new CM repository, easy to load in source code (latest baseline or multiple baselines), easy to load in multiple products, easy to load in other data such as problem tracking data, planning data, etc.

5. CM Capabilities - version control of files of course, but including binary files. Easy to retrieve any subset of files (point and click preferably). Simple CM strategies - don't give me a book I have to read to understand how our process works. Easy baselining, without tedious work such as file by file labelling. Again, I want the CM tool to help me, not complicate my life. I don't care too much if I have to create my own process or if it's pre-packaged (and reasonable), as long as I don't have to spend weeks or months configuring this process. Don't make me branch to remember promotion levels. Don't make me