Activity:
Establish Configuration Management (CM) Policies
Purpose
|
Steps
|
Input
Artifacts:
-
Configuration Management Plan
|
Resulting
Artifacts:
-
Configuration Management Plan
|
Frequency:
CM practices described in this activity need to be established by the
beginning of the Elaboration Phase following project approval, and then
re-visited through the project lifecycle at the beginning of the
Construction and Transition Phases.
|
Role:
Configuration Manager
|
Workflow Details:
-
Configuration & Change Management
-
Plan Project Configuration & Change Control
|
Define Configuration Identification Practices
Purpose
-
To identify and store artifacts in a secure repository
|
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 artifact
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 artifacts. The set of artifacts 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 artifacts.
The following is a suggested product artifact labeling convention that can be
used for labeling paths and artifacts 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!) for the various kinds
of artifacts 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
artifacts 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 artifacts.
Concepts:
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 Artifact 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.
or
-
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 components 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, catalogued 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
Artifact 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:
|
Select Change Request Based Reports
Here, you should select reports that can be derived from the 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 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
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
|