|NAVIGATION||CM PLAN SECTION 1|
The Configuration Management Plan (CMP) describes the way any new configuration required by the product will be incorporated into the production flow.
This document describes a set of CM terminology, establishes guidelines and standards for system configuration, problem tracking and problem resolution process. It is expected that outside developers follow the same guidelines and standard. It optionally may be applied to software or hardware acquired or developed for internal use.
This standard applies to software developed in C/C++ and assembly language as well as the build-scripts and other development file types.
Configuration Management (CM) is a discipline for ensuring the integrity of a product and to make its evolution more manageable. Although there is overhead involved in using CM, it is generally agreed that the consequences of not using CM can lead to problems and inefficiencies. The overhead of using CM relates to time, resources, and the effects on other aspects of the product life-cycle.
CM provides four principal services:
CM consists of four principal activities:
Configuration Items (CI) components are all of the individual and aggregate parts that comprise a product. A unique name is assigned to each distinct configuration item. In principal, a product may be divided into many small or a few large components, depending on the particular management needs. For software, an item generally corresponds to individual source or object files, and of subsystems built-up from these units. A source file, it's corresponding object file, a library or subsystem containing the object code, and an executable binary image are all distinct configuration items.
A configuration is a specific collection of items/components and their relationships. (This term may be used to refer to an entire project, one or more specific subsystems, and even individual components).
Subsystem refers to a collection of items that are also part of a larger system.
Product items or deliverables are the items actually delivered to a customer. They may be thought of as the top-level subsystems in a product.
A product is the special configuration consisting of all product items. This includes executables, setup procedures, documentation, etc.
A project is the special configuration consisting of product deliverables plus all non-deliverable items. Source code is the principal non-deliverable, but test suites, test reports, specification documents, etc., are also candidate project items, as per the management needs of the project. Usually a product is a project; however, a substantial project may not include any customer deliverables; e.g. internal tools development might be viewed as a stand-alone project within this organization, though they may be delivered to customers as an integral part of another product.
The project directory is the file system sub-directory containing all project materials.
There are three principal ways in which configurations may change:
A revision history is a record of some or all of the actual changes made over time to a particular configuration.
A revision number is associated with each change in the revision history for each item that may be revised (1.0, 1.1, 184.108.40.206, 2.0, etc.) Different items in a single configuration typically have different revision numbers.
Branches are parallel, independent revision histories for a single configuration.
The trunk is the mainline or default revision history for an item.
Branches subsequently may be merged, whereby a new revision is created, consisting of the changes made to both arbitrary branches.
Version is a generic term, loosely applied to mean "revision", "alternative", " release", or some combination of the three. It is recommended for the team to avoid using it except where the meaning is obvious (e.g.., Test Version, Beta Version, Version 1.2).
A baseline defines a specific state of a configuration. Technically, it identifies a specific revision and alternative for each component in a product. A change to any component item constitutes a prospective new baseline for a configuration. CM policy determines when baselines are declared. Important ones correspond to release milestones; it's often useful to declare separate baselines for individual bug fixes or feature additions as separate baselines.
A Product Release Identification (PRID) is the name for the version number that customers see when they install and operate a product. Pre-production releases also have unique PRIDs.
Version labels are a mechanism for explicitly identifying significant baselines. (It is a general facility that may be used for other purposes, too.)
An official product build or official build is one which depends only on source files, which have been checked into, the source library, and which promotes the product deliverables into the project directory. Official builds never include any local or unofficial components.
A local product build or local build is one which may depend on local components and which always produces local copies of deliverables. The results of a local build are not promoted to the project directory.
Build script or build batch files -- are used in this document as common nouns to describe the command scripts interpreted by the Builder (Make) utility.
An Engineering Change Order (ECO) is our official document to release all project material (executable files, documentation, etc.).