Evaluating CM Tools

• costs and maturity levels?
• Will it support re-use?
• Will build production be more efficient and reliable?
• Will developer and management productivity improve?
• Will I be able to make more timely decisions?

Look at Your Use Cases

What about all the other features: Ease of labelling, merge tool, interactive branch diagrams, compatibilitiy with SQL tools, etc. Well, don't look at the features - look at your use cases. What operations are you going to do? How frequently? How easy are they to do?

We have a lot of prospective clients looking at CM+ (Neuma's CM tool) and asking questions like: how easy is it to label? how difficult is it to put together a configuration view description? what about merging - we do a lot of that? what's your API like - we had a lot of difficulty integrating our last CM solution with a Problem Tracking capability. We tell them - it's easy to label, you don't have to put together configuration view description files, and you can plug in any number of differencing and merge tools, including the ones we ship with the product. We've got a variety of API capabilities. BUT these are really not that important [in CM+]. You won't need to do labelling any more. Pick a product/stream and optionally promotion level, or a build or baseline identifier and your view is set. Merging will move from a high-use to a minimal use frequency. You'll start out with a full suite of management tools and standard support for IDE integration - so you won't really be as interested in the APIs.

So be careful when you're evaluating to first put yourself in the context of the new tool. If you currently use a 7-way merge tool and your current process requires 7-way merges frequently, don't evaluate a new tool for its 7-way merge capability. First find out if you're still going to have to do 7-way merges. If you want SQL compatibility because you have to mine out all of the traceability links to feed into another database which will let you cross reference them and generate the data for building a release report (I'm out of breath too!)... first find out if your new tool will let you generate a release report with a couple of clicks. Don't discount the tool because it doesn't have SQL compatibility. You're looking for a new tool to eliminate your complexities, your dependencies and your headaches. If a new tool will eliminate these problems, don't be looking for features that will help you deal with them.

As a CM manager, ask yourself, before you evaluate: What would I rather be spending my time on - tedious configuration management tasks that should be automated, or change management. If a tool makes you spend a lot of time creating baselines, doing promotions, dealing with exceptions, generating status reports and version/build documents, or if the information is not quickly available with a few clicks, you may want to cast your tool search wider, especially if climbing the process maturity ladder is one of your goals.

Scalability

What happens to my performance as my project grows from hundreds to thousands to hundreds of thousands of objects? Does response remain snappy? Look for "smart client" technology that scales easily from 2 to 2000 users.

How many users, roles and disciplines do you need to support. When you move from 10 to 50 users is it a big deal or "no big deal." Do I eventually hit a wall and have to split my server and or repository up?

What's the Score

When it comes