Evaluating CM Tools


How do you evaluate a CM tool? What's important to you? Did you know that a good CM tool could actually make the difference between success and failure?

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 would 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 a "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, redistribute my data, calculate and perform manual synchronization operations (e.g., between sites or data partitions). Also, 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. 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).


About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.