Release made prior to final release for testing purposes

To more infrequently used data etc. To a store which may be more expensive to access, but is secure and cheap to maintain. Within CM, Archive is meant as a copy of a configuration or collection of CI’s which are stored ready for subsequent reuse at some distant future time

A resource that is, or can be used as, a substitute when a file has been corrupted. The word is also used as a verb, to backup i.e. to make a copy in anticipation of future failure or corruption.

Within CM, backup is meant as a copy of a working environment, taken on a regular basis to provide security against disaster or loss. The lifetime of the backup may be quite short, depending upon the frequency that the backup copies are taken.

A Baseline is a snapshot of the state of a Configuration Item and its component Configuration Items at a point in time. Baselines, plus approved changes from those Baselines, constitute the current Configuration Identification. The first Baseline for a Configuration Item will be established when the specifications of the item have been prepared, reviewed and agreed. Subsequent baselines will normally be established at points at which the current Configuration Item is ready to be used as a basis for further work in which a major transformation in the Configuration Item will take place.

I.e. end of Requirements Phase, Coding Stage, Testing, integration etc. The entity within which the baseline records is held is itself a CI, which will adopt a new version (or revision) for each new baseline.

Scheduling of builds, selection of components, performance and recording of builds.

The construction of a Configuration, from its component CI’s. The usually involves some processing or conversion of the Component CI’s (e.g. Compiling source code, text processing etc).

The administration and Control of all Technical Exception documents, including logging, storing, distribution and impact analysis.

All request for Support, Bug Fixes, Enhancement etc will be logged, indexed, assessed and approved or rejected in a consistent manner. The assessment would include prioritization and Impact Analysis (e.g. whether interfaces, Design Consistency, or other parts of the system would be affected).

Decisions to create or change Products should be made by a Change Control Board (CCB). All viewpoints should be represented on the CCB, especially those of the Buyer and the End User. The CCB should endeavor to reach decisions by consensus, with one member, normally the Chairman. The decision of the CCB should be logged. On a large Project, more then one level of CCB may be needed, with major impact problems being passed upwards from CCB’s managing parts of the development to a higher level CCB.

See Change Control Board.

The process of evaluating, approving or disapproving, and co-ordinating changes to Configuration Items after formal establishment of their Configuration Identification.

Defined as the discipline of identifying and defining the Configuration Items in a system, controlling the release and change of those items throughout their Lifecycle, recording and reporting the status of Configuration Items and Change Requests, and verifying the completeness and correctness of Configuration items.

The process of verifying that all the required Configuration Items have been produced, that the current version agrees with specified requirements, that the technical documentation completely and accurately describes the Configuration Items and that all Change Requests have been resolved. Regular Configuration Audits should be held. Inspection of plans, procedures, working practices, repositories and other records would be included in such audits.

Configuration Item is an entity with unique identification, which has the potential to become part of the controlled configuration of the system, and is under the control of Configuration Management. A Configuration Item may very widely in size, complexity and type, from the entire system (including Hardware, Software and Documentation) to a single module.

A Configuration is the complete technical description required to build, test, accept, install, operate, maintain and support a system. It includes all documentation pertaining to the system as well as the system itself.

The process of designating the Configuration Items in a system (including versions and variants) and recording their characteristics.

A Configuration Review is a management tool for establishing a Baseline.

The process of recording and reporting information that is needed to manage a Configuration effectively, including the proposed changes to the Configuration and the implementation status of approved changes.

A formal and Documented method to identify and control the Configuration Items of a system, define the data required to describe each one, define how they are to be stored and report on their status.

All Customer Contact (e.g. Requirements Capture, problem reports and deliveries) will be logged and the records held in a generally accessible format, to Annabel other members of the team to check for consistency.

Level at which items are to become Configuration Items, i.e. under the control of the CM system.

A documented and uniquely identified request for assistance in relation to a supported product, system or service. This is used as a means of organizing and controlling the input to the Change Control procedure. It is effectively a first or second- line support document for delivered (internal and external) items at any point in the lifecycle.

Specifying and Identifying all systems components, including versions and variants.

Impact Analysis is the term given to process of assessing the ramifications of pursuing a particular course of action – typically a change to the existing system.

Integration of all components, controlling the building and testing of all components. The integration of CM activities.

Item Type defines the type if Item to be controlled. All CI’s with the same Item Type will use the same Life Cycle; i.e. all SQL Scripts will use the same Life Cycle, as will all Functional Specifications.

A controlled repository, where versions of CI’s are stored.

There will be only one “Master” copy of any item. Where duplication if items can occur, appropriate mechanisms must be in place to detect and manage variants.

The performance of the Configuration Management Roles should be measured. The CM activities will generate metrics about the progress of the Project generally, e.g. number and type of rereceived per month, average manpower cost per bug fix.

This is a point in a project when a major objective is achieved. It may be a Release, a Baseline or a major control point.

A form used to document any situation where the system fails to meet its specification in some respect. The situation should first be recorded on a Project Issue Report and only transferred to an Off-Specification Report on the authorization of the Project Manager.

A documented a uniquely identified request for assistance in relation to a supported product, system or service. This report is then used as a record of the organization and control of the resolution of the problem, which may result in the preparation of a Change Request.

Mechanism for reporting errors, difficulties and queries by Customers and Project Members. Problem Reports often lead to Change Request.

Any output from a Project. PRINCE distinguishes between Management Products (which are produced as a part of the Management of the project) and the Quality.

Products (which are those Products which make up the system. A Product may be an Item of Software, Hardware or Documentation and may itself be a collection of other Products.

A document used to raise any issues relating to the Project in any way. After assessment by the PAT, they may be answered directly or converted on the authority of the Project Manager to either a Request For Change or an Off-Specification Report.

Scheduling and defining the content of each release, tracking of progress towards each release, performance and recording of release.

A Release is a set of new or changed Configuration Items which is promoted for use at a more advanced stage of the Life Cycle and which comes under the control of a higher authority (e.g. Specification of Design; Implementation to Testing; Installation to use). A release will consist of a set of Configuration Items of specified Baselines, collected together for use by others in the development process or by users. For example a set of Software modules may be collected together and released for Testing.

A storage area for CI’s. This may, for example, be a filing cabinet for documents, a database for software or a designated room for hardware.

A submission containing details of a proposed modification to the system. It can be raised only with the authority of the Project Manager as a result of analysis of a Project Issue Report.

Recording and Reporting current and historical data on the status of each CI. The status of all versions should be readily determinable, e.g. for what purposes they are approved for use. The lifecycle status (e.g. new; testable; tested, approved; released) for intermediate and end product must be defined and controlled. The configuration of each released baseline needs to be documented, as does the configuration of the released system.

Sub-Contractor Control activities are concerned with the incorporation into project configuration items of items developed outside of the project environment. The CM Plan shall define the activities for incorporating the externally developed items into Project Configuration Items. Also the CM Plan shall define activities to co-ordinate changes to those external items with their developers. The CM Plan shall describe:

1. What CM requirements are to be part of the sub-contractors agreement?
2. What configuration Audits and Reviews of sub – constructor’s items will be held.
3. How external items will be tested, verified, accepted and merged with the Project software.

The History and content of all versions of items “handed over” from one person or organization to another must be traceable, as must the results of the “handover”, i.e. whether the version was accepted or used.

One item version is a variant of another, if neither is a revision of the other. Variants allow one item to meet conflicting requirements at the same time. Temporary variants allow parallel development and will eventually be merged. Permanent variants are not merged but enable the CI to meet different functional requirement. An example might be a screen with text in a different (foreign) language.

The means by which items are identified, the dependency, information associated with them, the means by which it is stored and how access to it is controlled. The establishment of baselines containing that item and its constituent parts.

A Configuration Item may have a number of versions relating to the continuing development of that Configuration Item. In the first instance, a Configuration Item will be created and submitted to the CMS (the first version). The Configuration Item will then undergo a number of modifications as it is tested and error corrected, or as changes are requested. Subsequent submission of the Configuration Item to the CMS will be distinguished by an increasing version number.