SOFTWARE IN PRACTICE
The process of:
The purpose of configuration identification is to maintain control of an evolving system by:
We achieve this by:
An Example of Configuration Identification
The figure illustrates the configuration of a railway network environmental control system. The system has a central operation control centre and many railway stations linked by a wide area network. Each station has:
The figure illustrates the configuration identification record for one of the stations (Central).
Identifying the Configuration
Here are several real-life scenarios where failure to properly identify a configuration has caused financial loss.
Scenario 1 - Which Software is this?
An installation engineer located in Hong Kong experiences regular control system crashes. The Brisbane based development shop can't reproduce the problem in its test environment. After a week of investigation (cost = $5,000) a development engineer discovers site engineers have installed the wrong release of a configuration file in a remote terminal unit.
Solution: The central supervisory computer software is upgraded to automatically check the configurations of all remote units against an automated configuration item register.
Scenario 2 - Back to the Past
A new software release works fine for two weeks then catastrophically fails when a new feature is used for the first time. We have to revert to the previous release to recover (real quick).
BUT WHAT WAS IT???
Solution: Keep a Configuration Item Register that describes the evolution of the software product. Note that this function is usually performed by a source code control system, however a manual record may have to be kept of the documents that describe various versions of hardware and software configuration items.
Scenario 3 - If You Can't Build it they Will NOT Come
A software house goes bankrupt because it cannot reliably build its core product. See sidebar How Embarrassing Is This.
Solution: In your next job, as your first priority, set up a configuration register and pay more attention to configuration identification.
Scenario 4 - The Apocalyptic Test of an Effective Configuration Identification Strategy
Thirty years after your system is deployed the Martians come to earth with ray guns locked and loaded (get ready, it's not a matter of IF but WHEN). They blast your system into subatomic particles leaving you with nothing but the system documentation locked away in a vault at the North Pole. Could you recreate an exact facsimile of your system from these frozen specifications and design descriptions? Is all your documentation up-to-date? What versions of what documents describe the operational baseline - the one lolling around your feet in very small pieces? Not to put too fine a point on it but:
IS YOUR CONFIGURATION ACCURATELY IDENTIFIED?
How Embarrassing Is This
by Les Chambers
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.