Task: Establish Configuration Management (CM) Policies
This task describes how to develop CM Policies which includes Configuration Identification Practices, Baselining Practices, Archiving Practices, and Configuration Reporting Requirements.
Disciplines: Configuration & Change Management
Purpose

The purpose of this task is to establish project configuration management policies to be used to monitor and safeguard project assets, and to enforce software development practices. Project policies should improve communication amongst the team members and minimize problems encountered when integrating their work. 

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Steps
        Define Configuration Identification Practices
        Purpose:  To identify and store work products in a secure repository 
        Tool Mentors: Creating Baselines Using Rational ClearCase 

        Configuration identification is a core piece of configuration management and is defined by the IEEE as "an element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation". In terms of software configuration management, configuration identification means being able to find and identify the correct version of any project work product quickly and easily. The negative impact of having an ineffective configuration identification system is measured in terms of lost time and quality.

        Labels identify specific versions of work products. The set of work products that constitute a version of a subsystem are, collectively and individually, identifiable by a particular version and label. Labels are therefore useful in re-use or referencing original sets of versioned work products.

        The following is a suggested product-level work product labeling convention that can be used for labeling paths and work products in the Product Directory Structure.

        <SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

        <SYSTEM> Identifies the system

        <A> Stands for the three letter acronym (TLA!). This is used for the various kinds of work products used in the creation of the system. For example,

        PLN  Project Plans 
        REQ  Requirements Files 
        USC  Use Cases 
        MOD  Model Files 
        SRC  Source Code Files 
        INT  Public Interfaces 
        TST  Test Scripts and Results 
        DOC  Documentation (User, Release Notes) 
        BIN  Executables 

        <SUBSYSTEM> Identifies each subsystem

        <A> Stands for the three letter acronym for the various kinds of work products used in the creation of the subsystem. In accordance with the table above.

        R|A|B  Stand for release, alpha, or beta 
        <X>  Integer, stands for a major release (e.g. 1) 
        <Y>  Integer (optional), stands for a minor release 
        <Z>  Integer (optional), stands for an alternative release (patches, ports, etc.) 
        BL  Stands for base level (an internal release) 
        Integer, for internal releases 

        Here are some examples:

        T2K_R1.0  Release 1 of the Thorn 2000 system 
        T2K_GUI_R2.0.BL5  Internal release of the GUI system intended for delivery in release 2 
        T2K_B1.1  Beta release 1.1 of the Thorn 2000 system 
        T2K_R2.0.BL16  Internal system baseline #16 of thorn 2000 intended for creating release 2 
        T2K_R1.0.5  Maintenance release of Thorn 2000 
        Define Baselining Practices

        A baseline provides a stable point, and a snapshot of the project work products. Concept: Baselining describes when in the project lifecycle baselines need to be created. This step provides further guidance on the practice.

        Baselines identify fixed sets of versions of files and directories and are created at given project milestones. Baselines can be created for a subsystem, or for the entire system. Baselines should be identified in accordance with the scheme outlined in the preceding process step (Define the Work Product Labeling Convention).

        One distinction that needs to be made at the time of creating a baseline are whether you will be creating:

        • A 'Subsystem Baseline' with ALL the versions of files and directories that have been modified in the subsystem or subsystems.
        • A 'System Baseline' with a SINGLE version of all files and directories in all subsystems.

        As a general guideline, it would facilitate release management to create System Baselines at the major and minor project milestones, and Subsystem Baselines as required or at a higher frequency. As a 'rule of thumb' it is a good idea to create a baseline if up 30% of the elements in a subsystem have been changed.

        Define Archiving Practices

        The purpose of this step is to ensure that project software and related assets (master documents) are backed-up, cataloged and transferred to designated storage sites. Archives show their value in times of re-use or disaster. As such, archives need to be done regularly and at major and minor milestones.

        Labeling guidelines described earlier under the process step 'Define the Work Product Labeling Convention' can be used when creating archiving labels. However, additional information may be required on where the actual media is to be stored. For example:

        SERIAL NUMBER  123456789 
        VOLUME  1 of 3 
        VAULT  B5 
        DATE OF STORAGE  99-June-21 

        All product related information should be maintained on a database to facilitate release and re-use.

        Define Configuration Status Reporting Requirements
        Purpose Change activity is a powerful indicator of project status and trends. The purpose of this process step is for the Project Manager to define what product related change data is to be reported, by whom and at what frequency. 
        Substeps:  
        Tool Mentors:  

        Configuration Status Reporting , if used, describes the various sources for creating Configuration Status Reports.

        Select Change Request Based Reports To top of page

        Here, you should select reports that can be derived from the Artifact: Change Requests submitted to the project. There are a number of useful Change Request based reports.

        Under the 'aging' category, reporting could be requested in terms of the number of Artifact: Change Requests over time periods of a week or month based on the following criteria:

        • Submitted
        • Assigned
        • Resolved
        • Priority

        Listing problems by state can help determine how close to completion the project might be. For example, if the bulk of the problems have been resolved then completion is closer than if the bulk of the problems are in the submitted state.

        Under the 'distribution' category, reporting could be requested to answer the following types of questions:

        • Who is finding, what kind of defects, at what point in the project?
        • Who are the problems being assigned to?
        • How many problems are open under a given engineer?
        • How severe are the defects that are being found?
        • Where in the process are the problems being caused (root cause)?
        • When are the problems getting fixed?
        • How many defects are there?
        • How severe are these defects?

        These metrics can help in the analysis of work load, who is working on the most critical problems, and how quickly the problems are being closed.

        Under the 'trend' category, reports could be requested to answer the following types of questions:

        • How many defects are open this day, week or month?
        • How many defects have been closed this day, week or month?

        This data is useful assessing repair rates and could provide indications of engineering efficiency.

        Define Reporting Frequency To top of page

        Ensure that reports are received at the right frequency to be provide meaningful input for decision making. Reports could be requested on the following basis:

        • Daily - it is unlikely that reports would be required at this frequency
        • Weekly - Trend, Distribution and Count Reports, Build Reports
        • Monthly - Trend, Distribution and Count Reports, Build Reports
        • By Iteration - Trend, Distribution and Count Reports, Build Reports, Version Descriptions
        • By Phase - Trend, Distribution and Count Reports, Audits, Build Reports, Version Descriptions
        • At Project-End - Trend, Distribution and Count Reports, Audits, Build Reports, Version Descriptions


        More Information