Evaluating CM Tools

[article]
Summary:

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).

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!