Configuration Management Services

CA Service

Configuration Management

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:

  • Which versions of which software modules comprise which release of a software product?
  • What design description correctly describes this software module?
  • Have we proved that this software or systems product complies with its specification? Can it be shipped to a customer?
  • Is this system component subject to change request?
  • Who is authorised to approve changes to this component?

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).

Services

CA works with organisations to improve their configuration management processes. Our ways of working include:

  • Providing the Configuration Manager for a project
  • Developing configuration management plans and strategies
  • Developing and deploying configuration management procedures
  • Developing configuration management support tools
  • Conducting configuration audits (of a project's work products)
  • Conducting configuration management process audits.

Case Studies

Foxboro
(Hong Kong Mass Transit Railway)
Hong Kong's Mass Transit Railway System (MTR) underwent a major refurbishment of its traction power and environmental control systems. Foxboro Australia Pty Ltd won a A$70 million contract to provide a Supervisory Control and Data Acquisition System to control the distribution of traction power to the trains and to regulate air flow, temperature and humidity in 37 MTR stations and connecting tunnels.
The MTR system configuration comprised triply redundant central computers communicating, via a fibre optic wide area network, with 230 remote terminal units (RTUs) installed in 37 stations. The RTUs performed local direct digital control of traction power, emergency smoke extraction and air-conditioning plant and transmitted sensor signals to the central SCADA system. CA's task was to develop a configuration management strategy to guarantee the integrity of the system in the operation and maintenance phases of its life cycle. This involved generating configuration management plans, strategies, software tools (ref Database Design: Case Studies) and procedures for configuration identification, change management and configuration audit. The overall objective was to ensure that, for the operational life of the system, the correct software and configuration files would be installed in the correct target RTUs and that an RTU could not operate with corrupt data.
Rockwell Ship Systems
(Collins Class Submarines)
CA developed a software requirements specification for a Configuration Management Support System (CMSS) to be implemented on the Royal Navy submarine combat system contract. We supported the specification with a CMSS prototype developed with the Ingres relational database system.

True Stories from the Annals of CM

by Les Chambers

Waste

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.

Embarrassment

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.

Tragedy

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.