A WORKING DEFINITION OF "CONFIGURATION MANAGEMENT"
--------------------------------------------------

> Would you happen to have a "simple" explanation of what CM is and how it is
> applied?

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 need 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-inhouse
 - 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 what area of industry do you wish to apply CM?  For software I can
recommend a few books, or a few consultants (myself included).

>    I am particularly interested in it's application within quality
> management/ ISO9000.

ISO9001/2/3 markedly does not mention configuration mangement, which is
probably a very good thing. ISO9000 nearly requires Configuration
Identification in 4.8. where mentions identification of the whole product.
CM requires identification of all of the components for which there is
an individual specification and to which an individual change may be made.
4.8 is more concerned with traceability into the customer domain, which
is closer to Version Cointrol.

ISO9001/2/3 4.10.5 requires inspection and test records, which nearly
equates to Status Accounting. ISO9000 implies the records stay with the
component, and thus by integration, with the product.

ISO9001/2/3 4.3 handles Requirements changes, 4.4.9 Design changes, and
4.13 changes to the components and product through failure to conform to
specification. These fairly well cover Configuration Change Control.

ISO9001/2/3 4.17 could be interpreted to cover auditing the record
keeping which is Configuration Audit.

ISO9000 does not need to mention CM as does ISO9000-3 [interpretation of
ISO9001 for software]. It has the components already.  Quality management
should go beyond ISO9000, which declares itself to be a minimum
specification/model.

  |-----------------------------------------------------------------|
  | Regards, Geoff Cozens                                           |
  | gcozens@qualmtry.demon.co.uk                                    |
  | ISO9000 Quality System Designer for IT and for Small Businesses |
  |-----------------------------------------------------------------|

---------------------------------------------

[The above is has been republished at this site with the kind permission of 
Geoff Cozens]


--------