^{Highley Recommended, Inc.}

NAVIGATION	CM PLAN SECTION 1
CM Home CM Resources Table of Contents Introduction SCM SCM Activities CM Milestones Tools & Training Support	1. INTRODUCTION 1.1 Scope 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. 1.2 Definitions 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: Maintaining a project-wide history of the development process (Who made the fix? Was the fix in the last release?). Providing a project-wide "undo" facility (A particular change introduced two new bugs, so let's back it out and start over). Automating product builds and making them reliable and efficient (A particular bug was fixed in the 6.0 version, how come it's still broken in 6.10?). Providing for parallel development by Baselining "good" builds and providing a defined branching structure for the project. CM consists of four principal activities: Configuration identification defines the scope of a project by identifying the components (or items) in a project and the relationships between them; Configuration Documentation records the components, relationships, and functionality of the project; Configuration control determines the constraints that are placed on accesses and changes that may be made to the items in a project; and Auditing/Reporting, which provides information about the other two 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: Revisions are different instances of a particular configuration as it changes over time. Each individual and aggregate item in a configuration may be revised independently. When an item is revised all other related items also are implicitly revised. Alternatives are different instances of a particular configuration altered or customized for particular applications. The alteration may happen at the same time and under the same revision. Alternatives usually are implemented either by conditional compilation (e.g. #ifdef), by explicit alternative modules (and parameterized build procedures), or by branches. Releases are different instances of a particular configuration as it progresses through the development cycle. Major releases are typically distinguished as development, integration, software quality test, system verification and validation, alpha test, beta test, release candidate, and production releases. 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, 1.1.1.0, 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.). 1.3 References 1.4 Tailoring Previous Section Next Section

NAVIGATION

CM PLAN SECTION 1

CM Home
CM Resources
Table of Contents
Introduction
SCM
SCM Activities
CM Milestones
Tools & Training
Support

1. INTRODUCTION

1.1 Scope

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.

1.2 Definitions

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:

Maintaining a project-wide history of the development process (Who made the fix? Was the fix in the last release?).

Providing a project-wide "undo" facility (A particular change introduced two new bugs, so let's back it out and start over).

Automating product builds and making them reliable and efficient (A particular bug was fixed in the 6.0 version, how come it's still broken in 6.10?).

Providing for parallel development by Baselining "good" builds and providing a defined branching structure for the project.

CM consists of four principal activities:

Configuration identification defines the scope of a project by identifying the components (or items) in a project and the relationships between them;

Configuration Documentation records the components, relationships, and functionality of the project;

Configuration control determines the constraints that are placed on accesses and changes that may be made to the items in a project; and

Auditing/Reporting, which provides information about the other two 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:

Revisions are different instances of a particular configuration as it changes over time. Each individual and aggregate item in a configuration may be revised independently. When an item is revised all other related items also are implicitly revised.

Alternatives are different instances of a particular configuration altered or customized for particular applications. The alteration may happen at the same time and under the same revision. Alternatives usually are implemented either by conditional compilation (e.g. #ifdef), by explicit alternative modules (and parameterized build procedures), or by branches.

Releases are different instances of a particular configuration as it progresses through the development cycle. Major releases are typically distinguished as development, integration, software quality test, system verification and validation, alpha test, beta test, release candidate, and production releases.

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, 1.1.1.0, 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.).

1.3 References

1.4 Tailoring

Previous Section Next Section