Configuration Management

This is advice reproduced with the kind permission of Geoff Cozens

Configuration Management

Most simply CM is "Looking after what you've got so far".

To start, each "what" must be uniquely identified: That's the point of Configuration Identification. If possible, each identifed "what" fits into one or more relational structure. The primary structure is decomposition/integration of components to make a fully working deliverable "something".

The next important structure is relationship of "this" is derivered from "that". Other structures are for example where both of "these" are derived from the comman "that" if one of these is changed the other must be changed in parallel.

The next item of information is "how completely ready is it?": That's the function of Status Accounting. Decide what stages of incompleteness, correctness and obsoleteness need to be known and to what audience, give each stage a status name (e.g. draft, under review, ready for integration/delievry, operational, superseded), collect the status of each item. Collate the information for the structures to report as required.

All items must be capable of change: That's the purpose of Configuration Change Control. Enable requests for change to be uniquely identified, assist in determining which items to change, notify those involved of the pending/approved change, track the change to integration with the items to be delivered.

Additionally gather together the sets of changed items that work together and release them as a bundled "what". This becomes Version Control. Since a version can be assembled at one point in time, it can be rebuilt later. This also becomes the responsibility of Version Control.

Since status and versions are records of the real "What" and not the thing itself there needs to be a way to prevent divergence. This is Auditing. In configuration management of software it is possible to control the "what" of software, and documentation (manuals, test data, etc) along with the records the Auditing can be less.

That is the classical essense of configuration management.

I believe the role extends to:
- assisting work to be divided into spearate work packages, the interface to which are documented and changed by change control;
- track all requirements with the throughness classically taken for each change;
- keep and report information on defects with the same thoroughness as classically for status of completeness and correctnesss;;
- apply to bought-in items as well as made-in house
- apply to product held in archive, disaster recovery storage or with an agent until contract condition (liquidation of supplier or payment of invoice).

That's CM "simply".

To gain more information contact:
E-mail qia@quality.co.uk
 
 

Return to the Quality Network

Last modified February 2006
We have been serving
the community
since February 12th 1996
Thank you for visiting