SOFTWARE IN PRACTICE
Configuration management is an indispensable project discipline that introduces order into what can become a chaotic multi-variant mix of hardware, software and documentation. It identifies and organises the work products (referred to as configuration items) that are produced by software and systems development projects and protects them against destructive uncontrolled change.
Configuration management answers questions such as:
Configuration management achieves order by:
In short, CM identifies what you're building, where it's up to in the development process, whether or not it complies with its specification and weather changes to its components are warranted.
All projects must have configuration management. Lack of attention to this discipline has been the root cause of many horror stories in software and systems development (refer to the side bar, True Stories from the Annals of CM).
CA works with organisations to improve their configuration management processes. Our ways of working include:
True Stories from the Annals of CM
by Les Chambers
I was asked to help sort out the configuration management of a very large supervisory control and data acquisition system with a point count in excess of 30,000. The system had a central supervisory control node and more than 200 remote controllers. Despite my powerful arguments in favour of CM the developers felt they pretty much had configuration management under control and weren't particularly interested in formalising their CM procedures. They had other priorities. Then two incidents occurred in the space of two weeks that turned them into configuration management zealots: First - A maintenance team failed in their attempt at a software upgrade of a remote site. When they installed the new software everything stopped working. This was annoying and expensive because it had to be done between midnight and 3 AM. They later discovered they had installed the wrong version of a configuration file. Second - Site installation engineers found a bug in some operational software. Back in the development shop the software engineers laboured for a week to reproduce the bug. By Friday they discovered they'd just spent five days looking for a non-existent bug in the wrong version of the software. At that, the team galvanised. It was stunning - how quickly they cleaned up their configuration identification and release procedures. It's amazing what can be achieved when people can reach out and touch the tangible benefits of CM.
The Board of Directors of a small software company has bunkered down in the board room discussing serious issues. They're reflecting on changes in their marketplace and fine tuning the company's strategic plan. Meanwhile down in the development shop there is only one man who knows how to build the company's software product: Ben the Build Manager. Ben is the only one who knows which versions of which software modules make up the latest release of the product; the company's one and only source of income. There is no documented build instruction. It's in Ben's head, which from a management perspective is not a real problem - but for the fact that Ben is unhappy with his salary package and conditions and is looking for another job. The company's sole means of production is about to walk out the door.
A military jet is on landing approach. It suddenly inverts and crashes into the runway killing the pilot. Post-mortems identify that an old version of a software module with a known bug was incorporated into the operational baseline of the jet's avionics system by mistake.