ARCHIVED - Configuration Management Procedure

This page has been archived.

Objectives

To ensure that all Department X's configuration items are uniquely identifiable and accessible.

To ensure that updates to all baseline items are controlled and traceable.

To ensure that the status of all baseline items is known.

Scope

All items used in development and support undertaken by Department X conform to this procedure. (An item is any software component, release, tool, documentation or hardware unit required for the purpose of creating or supporting customer deliverables.)

References

CM011 Configuration Management Plan Outline

CM012 Configuration Management Handover Form

CM031 Request for Change Form

SD100 Review Procedure

QA010 Quality Assurance Procedure

QA011 Software Quality Plan Outline

CM020 Version Identification Procedure

CM030 Change Control Procedure

PR011 Life Cycle Standard

Outstanding Issues

None.

Approvals

Development Manager.

Responsibilities

The Development Manager is responsible for appointing a Configuration Librarian or delegating that authority to Project Managers.

The Project Manager is responsible for the application of this procedure to the relevant project.

The Project Manager is responsible for the development of the Configuration Management Plan for his/her project.

The Quality Assurer assures that this procedure is followed on the project.

The Project Team is responsible for implementation of this procedure on the project.

The Configuration Librarian is responsible for the operation of the Configuration Management system, for the education of staff in its use, and for the production of reports as required by project organizations.

Inputs

Configuration Items, as defined in Section 2, above (i.e. software component, software release, hardware unit, documentation, tools).

Configuration Management Handover Forms.

Archive/Deletion Forms.

Outputs

Controlled Items.

Configuration Reports.

Configuration Management Plan Standard.

Configuration Management Plan.

Control Mechanisms

Request for Change Forms ensure that changes are co-ordinated and controlled.

Reports from Configuration Control facilitate external review of the configuration library.

CM Handover Forms provide records of item deposit.

Internal audits ensure conformance to this procedure and propose improvements to the process.

Procedure

General

The Development Manager ensures that this procedure and the Configuration Management Plan Standard are maintained and continue to satisfy the needs of the organization.

The Development Manager appoints a Configuration Librarian to provide a configuration library across generally used platforms.

The Configuration Librarian sets up and maintains the configuration library system, in line with this procedure and in particular, the characteristics defined in Configuration Library Characteristics below.

The Configuration Librarian creates any necessary work instructions required to ensure that staff efficiently and correctly utilize the configuration library. He/she also provides any necessary training to staff.

The Configuration Librarian creates any documentation required in order to support and maintain the configuration library.

The Configuration Librarian ensures that all commonly used software tools and development environments are deposited into the configuration library.

The CM activities and the CM Library are audited in accordance with the Quality Assurance Procedures and the Quality Assurance Plan.

Project Initiation

At project initiation, the Project Manager decides if the general configuration library is suitable for his/her project. If not, then he/she appoints a Configuration Librarian, who implements a project-specific configuration library, in line with this procedure, including the characteristics defined in Configuration Library Characteristics below. Where necessary, the Project Manager creates a project-specific work instruction to describe the detailed operation of that project's configuration library.

The CM Plan is developed, as described in the next section.

The Project Manager ensures that the project's configuration items are identified at or before the phase defined in the Life Cycle Standard and then reviewed and updated at each subsequent phase.

The Project Manager identifies any new/additional software tools to be used in the project and informs the Systems Manager.

The Systems Manager ensures that a project development and support network is set up and that all its hardware items are catalogued and uniquely tagged.

The Systems Manager ensures that the new tools and the network software are stored within a configuration library.

The Configuration Management Plan

The Project Manager determines whether a Configuration Management Plan is needed for his/her project. If so, the Project Manager, Configuration Librarian, and/or project team generates the CM Plan. This plan follows the content and format as defined in the Configuration Management Plan Standard.

The Configuration Management Plan is issued for peer review, as per Review Procedure, by the project team, Quality Assurer, affected groups, and other people as required by the Project Manager.

The Configuration Management Plan is controlled as per this procedure.

Typically, the CM Plan reflects the CM activities as outlined in this procedure, though there is some variance due to project type, size, and special constraints. For a particular project, the CM Plan (if one exists) takes precedence over the activities outlined in this procedure.

Project Development/Support

The Project Team uniquely identifies all configuration items, as per the Version Identification Procedure. This includes all files, documentation, build instructions, tools and releases delivered to a customer, plus all internal documentation and test software.

The Project Team stores items in the configuration library, by submitting them to the Configuration Librarian accompanied with a CM Handover Form.

The Project Team creates baseline releases as required by the Life Cycle .

The Configuration Librarian ensures that all baseline releases are built from configuration items stored in the configuration library.

The Project Team accesses and retrieves configuration items as required, via the version identification scheme described in the Version Identification Procedure, in order to build and test other configuration items and releases.

In order to update a configuration item, the Project Team retrieves a copy from the library and marks the item as reserved for modification. If the item is already in that state, then the Project Team takes appropriate action to co-ordinate the different changes.

The Project Team performs all changes to configuration items, as per the Change Control Procedure.

When a configuration item is approved for release to a customer, the project team requests the Configuration Librarian, via the CM Handover Form, to mark it as ship authorized.

Formal releases, for shipment to customers, are built by the Configuration Librarian from configuration items (including build instructions) stored within the configuration library.

The Project Manager can request copies of a ship authorized item for ongoing shipment outside of the company.

The project team can submit an Archive/Deletion Form, approved by the Project Manager, in order to:

i. request the Configuration Librarian to delete an item from the library.

ii. store specific configuration items off-line (usually in order to optimize use of on-line storage).

Configuration Library Characteristics

The Configuration Librarian is responsible for a configuration library with the following characteristics:

Storage and retrieval of configuration items associated with a project, identified in conformance to the Version Identification Procedure.

Provision of an audit trail of changes to a configuration item (viz. revision history).

Identification of projects on which individual configuration items are used.

Support of sharing of configuration items across projects.

Identification of variants of configuration items.

Identification of configuration items as either ship authorized or not. (Ship authorization implies that the configuration item is approved for release to customers).

Identification of configuration items that have been extracted for modification, such that on receipt of a subsequent request a warning can be issued.

Read-only access to any project item by any project member.

Deletion of items only on receipt of an approved request.

Backup and archiving of contents.

Report generation:

i. A list of all projects which have configuration items stored.

ii. A description of the relationship (viz. derivation) between any stored versions of a configuration item.

iii. A description of the related configuration items, e.g. Design Specification and source code.

iv. A list of affected configuration items associated with a particular implemented Request for Change.

v. Configuration item status e.g. being modified, items per project, latest version id, stored versions, history of changes, projects on which item is used.

vi. Change status, related to Request for Change Forms, e.g. number open/closed/raised by project, longevity distribution.

vii. List of which items have been distributed to which customer.

An example of actual implementation is documented in Appendix A.

Pre-Configuration Control

Prior to handover to the Configuration Librarian, no formal configuration control is required.

Header information in editable files is maintained in line with post-configuration identification, but not necessarily with a detailed history of changes. Any such history can be removed prior to handover.

Prior to handover, version identification is performed as required by the Project Team.

Associated Forms

CM Handover Form, CM012.

Request for Change Form, CM031.

Archive/Deletion Form.

 

 

Appendix A: Configuration Management Example Implementation

A.1 Overview

A.1.1 This Appendix describes the actual configuration management system being used by Department X.

A.1.2 It conforms to the principles defined in the procedure, except as stated in the section on Variants. Change control occurs as defined in the Change Control Procedure.

A.1.3 It defines a manual system based on discipline and a certain amount of trust. As such, it is suitable for the current operations within Department X but will need to be reviewed as the size of operations increase.

A.1.4 This Appendix could be a work instruction.

A.2 Drive allocation

A.2.1 Products

A.2.1.1 Each standard product is allocated a unique drive name:

Drive P - Product 1

Drive Q - Product 2

Drive R - Product 3

etc.

A.2.1.2 The Product Manager has the final approval over the content of the drive associated with that product.

A.2.2 Common

A.2.2.1 An additional pseudo drive, drive N, is reserved for files common across more than one product.

A.2.2.2 The Configuration Librarian has overall responsibility for the contents of the pseudo drive.

A.2.3 Network

A.2.3.1 An additional pseudo drive , drive O, is reserved for files used in the common operations network.

A.2.3.2 The Systems Manager is responsible for the contents of the Network drive.

A.2.4 Bespoke

A.2.4.1 Bespoke projects, not based on the standard products or classed only as variants of standard products, are allocated a drive number by the Configuration Librarian, following a request by the Project Manager.

A.2.4.2 The Project Manager is responsible for the contents of the corresponding Bespoke drive.

A.2.5 Management

A.2.5.1 A read-only file, drvalloc.doc, is maintained in the root directory of drive N by the Configuration Librarian, describing the current drive allocation.

A.2.5.2 A read-only file, cmmgt.doc, is maintained in the root directory of drive N by the Configuration Librarian, containing this implementation information (as currently being read).

A.2.5.3 In addition to the structures and information files described within this Appendix, the member of staff responsible for a directory/sub-directory may decide to include additional on-line information in the form of a read-only file, readme.doc, in the appropriate directory/sub-directory.

A.2.5.4 In the directories and sub-directories, files can be deposited or updated, only following approval, as defined in the appropriate procedure. An additional directory, Delta, is provided to store proposed or draft changes.

A.2.5.5 All files in the configuration library are marked as readonly. When an update is required, a copy is made to a personal work area. A readme file is created associated with the file to be updated and named as per the master, with a .rme extension. If such a file already exists, then the member of staff uses the information in it to resolve any conflicting updates. When an update is approved, the member of staff responsible checks to see that the master version being superseded is the same as that which was copied out to be modified. The readme file is deleted.

A.3 Network directory

A.3.1 The following sub-directories exist:

A.3.1.1 HARDWARE Hardware environment: list of kit, content and identifiers

A.3.1.2 CONSUME Operations consumables

A.3.1.3 TRAINED Trained Operators

A.3.1.4 DATA Data

A.3.1.5 GUIDE Operations Guide

A.3.1.6 APP_SOFT Applications software

A.3.1.7 OPS_SOFT Operations software

A.4 Main directories

A.4.1 Each drive has 3 main directories:

MP Management Products

TP Technical Products

QP Quality Products

A.4.2 The structure of each drive is further discussed below.

A.5 Management Products

A.5.1 The following sub-directories exist:

A.5.1.1 BUSINESS Business case, Terms of Reference

A.5.1.2 PLANS Project Plans, Stage Plans, Exception Plans

A.5.1.3 BOARD Project Board Reports

A.5.1.4 HILITE Highlight Reports

A.5.1.5 CHKPOINT Checkpoint Reports

A.5.1.6 REVIEWS Review Minutes

A.6 Technical Products

A.6.1 The following sub-directories exist:

A.6.1.1 APPLICNS

Applications Products, containing further sub-directories corresponding to the releases of the product. This sub-directory contains the internal life cycle documents: requirements/design/test/acceptance specifications plus test reports. It also contains installation and build products. (See also the RELEASE directory for ship authorized items.)

A.6.1.2 OPERATNS

Operations Products, specific only to the network used on this project. See drive B for common Operations files.

A.6.1.3 SECURITY

Security Risk Assessments

A.6.1.4 USER

User Products, containing further sub-directories corresponding to each approved revision of the product. This includes manuals, operator's guides, etc.

A.6.1.5 EDUCATN

Education Products: materials, guides, specification and strategies.

A.6.1.6 RELEASE

Release Packages, containing further sub-directories corresponding to each release (viz. customer recognizable product) approved for shipment out of Department X. A file, rel-info.doc, exists in the RELEASE sub-directory to describe the release history and scope of each sub-directory.

A.7 Quality Products

A.7.1 The following sub-directories exist:

A.7.1.1 PRODUCT Product Descriptions

A.7.1.2 REVIEW Quality Review invites, action lists, minutes, results

A.7.1.3 EXCEPTS Project Issues, Request For Change status reports

A.8 Variants

A.8.1 The Configuration Librarian maintains a log of the relationships between projects.

A.8.2 The Project Manager maintains a log of the relationships between files within the project.

A.8.3 When approving a Request for Change, the approver checks that these logs have been considered and appropriate measures taken to initiate any required changes.

A.8.4 Variants cannot have children.