What is Configuration Management?
Configuration Management has its roots in the US Department of Defence in the 1950’s. It started as a technical management discipline and has been widely adopted by many other engineering disciplines, including Systems Engineering and Software Engineering. Configuration Management focuses on establishing, and maintaining, the consistency of a system or product throughout its lifetime. CM is a collection of competencies, techniques and tools whose purpose is to ensure the consistency of the system’s requirements, functional attributes and physical properties.
For the purposes of this paper we shall consider four fundamental, inter-related activities:
Revision control is concerned with controlling access to project artefacts and maintaining a history of changes to each artefact.
Before you can control any artefact you must identify what it is, what information it is going to contain and how it will be controlled.
When an artefact has to change, Change Management controls when, or even if, the changes may be performed.
Release Management focuses on the delivery of software outside the development department.
These activities are inter-related and highly dependent on each other.
Why perform CM?
Good Configuration Management ensures that the current design and build state of the system is known and recorded; and doesn’t rely on the tacit knowledge of the development team.
Being about to access an accurate historical record of system development is very useful – not only for project management and audit purposes, but for development activities such as debugging (for example, knowing what has changed between one set of tests and the next to help identify what could possibly be causing a fault).
Effective use of CM tools enables engineers to formally (and safely) record all change details. In particular, not only what was changed in the product but why it was changed
CM ensures that documentation can be produced which truly describes delivered systems.
Sometimes, it is necessary to rebuild old versions of products to reproduces problems for customers, such as the military, haven’t upgraded their tools to the latest versions.
Finally, and not to be overlooked (since these things happen!) good CM practices enable a system to be rebuilt correctly in the event of mistakes, failures and catastrophes.
Getting CM wrong
Configuration management can seem an awful lot of effort, much of which appears to be an overhead on the development of software. However, getting CM wrong can lead to the following:
– The wrong requirements being accepted
– The wrong design being implemented
– The wrong tools being used for development
– The wrong software being tested
– The wrong test suite being used
– The wrong version of software being released
Any of these could lead to huge amounts of wasted effort, wasted money, late deliveries and seriously dissatisfied customers. It doesn’t matter how good the software is, delivering the wrong product is never going to win you any plaudits.
Latest posts by Glennan Carnie (see all)
- Your handy cut-out-and-keep guide to std::forward and std::move - April 26, 2018
- Setting up Sublime Text to build your project - April 12, 2018
- “May Not Meet Developer Expectations” #77 - February 15, 2018