Got Configuration Management Best Practices?


If you keep track of the individual component specifications as well as the dependencies between them, there can be very large range of possible final configurations. For example, say that there are four parts used to build a widget. Part A can be from vendors one through five. Part B can be from vendors one, two, or six, but if vendor two is used, part A can only be selected from vendors two or five. Part C can be from vendors three, five, six, or seven, but if vendor three is used, Part B can only be from vendor six. And finally, Part D can be from Vvndors one through three or nine (vendor eight was recently disqualified), but if vendor nine is used, Part C can only be from vendor three. This not only becomes very complex very quickly, it means that the resulting build, especially if the parts are selected manually, must be validated as a part of the final inspection before a product can be approved for shipping.

Imagine the complexity of building an aircraft! Everything, down to the individual washer, must be accounted for, tracked and checked. When life-critical devices such as pacemakers or drug pumps are considered, even the software used needs to be tracked at a “hardware” level using its part number and release version information.

Documentation - Doing and Controlling
When one starts dealing with documentation, there is always the challenge of knowing what to include, where to put it and whether to control it. There are so many types of documents these days: requirements, interface specifications,  user stories, user manuals, online help, program documentation, build records, and the list goes on, that knowing what to put in each of them (especially without repeating content) is something that needs to be planned ahead. When each new class of document is identified, it needs to be factored into the overall planning.

As far as knowing where to put each document, think more in terms of a retrieval system than a storage system. Most people think in terms of storing documents in hierarchies, but when trying to find information on a topic we end up reverting to search engines instead of doing a logical breakdown based on content. Of course, if you have a good search engine that can access documents in a version control or document management system, it may not be as big a problem.

As to whether to control or not control a class of documents, it depends on what they intended for. If they tie to specific versions of source (or other component or product that is released multiple times), or if regulatory requirement mandate it, then they should be versioned. If they are working documents (think project plans, schedules, etc.), then they maybe should be versioned. This becomes a joint decision between CM and management. Anything else should be addressed on a case-by-case basis. However, once a decision has been made it should not be changed.

Even though these categories have been discussed often and many book have been written, do not be afraid to look at the world of development from fresh perspectives. This often illuminates why problems have been experienced in the past. People that are new to CM, or those that have been using one development paradigm for most of their working lives, may not have the time or breadth of experience to see if the way things are developed is affecting their CM world. This is the reason CM Crossroads is such a valuable resource – use it!

User Comments

1 comment
Bruce Logan's picture

This article struck chords in so many different ways! Thank you for articulating these points so well, and in one place. As it happens, I'm busy with a Quality Management review process at present, and some of the points raised above are certainly going to find their way into my recommendations soon!

October 28, 2014 - 5:36am

About the author

AgileConnection is a TechWell community.

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