Office of the

Government Chief Information Officer

SOFTWARE
CONFIGURATION MANAGEMENT
PROCESS GUIDE
FOR
APPLICATION SOFTWARE

[G46]
Version : 1.11

Jul 2012
The Government of the Hong Kong Special Administrative Region

The contents of this document remain the property of and may not be reproduced in whole or in part
without the express permission of the Government of the HKSAR

COPYRIGHT NOTICE
2008 by the Government of the Hong Kong Special Administrative Region
Unless otherwise indicated, the copyright in the works contained in this publication is owned
by the Government of the Hong Kong Special Administrative Region. You may generally
copy and distribute these materials in any format or medium provided the following
conditions are met
(a) the particular item has not been specifically indicated to be excluded and is therefore not
to be copied or distributed;
(b) the copying is not done for the purpose of creating copies for sale;
(c) the materials must be reproduced accurately and must not be used in a misleading context;
and
(d) the copies shall be accompanied by the words copied/distributed with the permission of
the Government of the Hong Kong Special Administrative Region. All rights reserved.
If you wish to make copies for purposes other than that permitted above, you should seek
permission by contacting the Office of the Government Chief Information Officer.

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

CONTENTS
_________________________________________________________________________________________

TABLE OF CONTENTS
1.

PURPOSE .............................................................................................................................................................1-1

2.

SCOPE ..................................................................................................................................................................2-1

3.

REFERENCES.....................................................................................................................................................3-1
3.1
3.2

4.

DEFINITIONS AND CONVENTIONS .............................................................................................................4-1

4.1
4.2

5.

IDENTIFICATION ............................................................................................................................................ 5-1

CONTROL ...................................................................................................................................................... 5-2
STATUS ACCOUNTING ................................................................................................................................... 5-4
AUDIT ........................................................................................................................................................... 5-4

SCM ROLES & RESPONSIBILITIES..............................................................................................................6-1

6.1
6.2
6.3
6.4
6.5
6.6
6.7

7.

DEFINITIONS .................................................................................................................................................. 4-1

CONVENTIONS ............................................................................................................................................... 4-1

SCM CONCEPTS ................................................................................................................................................5-1

5.1
5.2
5.3
5.4

6.

STANDARDS .................................................................................................................................................. 3-1

OTHER REFERENCES ..................................................................................................................................... 3-1

CONFIGURATION BOARD (CB) ...................................................................................................................... 6-1

CONFIGURATION MANAGEMENT OFFICER (CMO) ........................................................................................ 6-1
CONFIGURATION LIBRARIAN (CL) ................................................................................................................. 6-2
CONFIGURATION AUDITOR (CA) ................................................................................................................... 6-2
IMPACT ANALYSIS GROUP (IAG) .................................................................................................................. 6-2
SCM IN DEVELOPMENT PHASE ..................................................................................................................... 6-3
SCM IN MAINTENANCE PHASE...................................................................................................................... 6-3

SCM PROCESSES ..............................................................................................................................................7-1

7.1
7.1.1
7.1.2
7.1.3
7.2
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.3.7
7.3.8
7.4
7.4.1
7.4.2
7.5
7.5.1
7.5.2
7.6

IDENTIFICATION ............................................................................................................................................. 7-1

Selection ..................................................................................................................................................7-1
Designation .............................................................................................................................................7-2
Description ..............................................................................................................................................7-3
PLANNING ..................................................................................................................................................... 7-6
CONTROL ...................................................................................................................................................... 7-7
Physical Control ......................................................................................................................................7-7
Check In Procedure .................................................................................................................................7-8
Check Out Procedure ..............................................................................................................................7-9
Change Control .....................................................................................................................................7-10
Assembly of High Level Product ...........................................................................................................7-12
Control of Variants ................................................................................................................................ 7-13
Control of contractors Work ................................................................................................................7-14
Database Administration .......................................................................................................................7-15
STATUS ACCOUNTING .......................................................................................................................... 7-16
Product Status Reporting ......................................................................................................................7-16
Change Status Reporting .......................................................................................................................7-17
AUDIT ......................................................................................................................................................... 7-18
Physical Configuration Audit ................................................................................................................7-18
Quality Assurance of SCM Activities .....................................................................................................7-19
HAND-OVER ................................................................................................................................................ 7-20

Attachment 1 : Example of Application Software Configuration Management Plan For SDLC Projects
Attachment 2 : Example of Application Software Configuration Management Plan For Systems In Production
Attachment 3 : Sample Form of Report on Physical Configuration Audit
Attachment 4 : Sample Form of Application Software Configuration Management Review Report
________________________________________________________________________________________

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

PURPOSE
_________________________________________________________________________________________

1.

PURPOSE
This guide is to provide guidance for OGCIO staff to plan and implement Software
Configuration Management (SCM) in development and maintenance stages of application
software.

________________________________________________________________________________________
1-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCOPE
_________________________________________________________________________________________

2.

SCOPE
This guide describes the principles of SCM, its interfaces and its constituent functions
throughout the development and maintenance stages of application software. It also
describes the generic organization structure and responsibilities for performing SCM.
This guide mainly consists of the following sections, namely :
1. SCM Concepts
2. SCM Roles & Responsibilities
3. SCM Processes
The SCM Concepts section illustrates the concept of SCM and provides a brief description
of the SCM processes adopted in OGCIO.
The SCM Roles & Responsibilities section defines the roles and responsibilities in SCM.
It describes who to implement the SCM processes.
The SCM Processes section describes the SCM processes in details. It explains how the
SCM processes are performed in system development and maintenance phases.
A number of attachments are also provided. Attachment 1 & 2 are examples of SCM Plans
for system development and maintenance phases. Attachment 3 & 4 contain the sample
reports on Physical Configuration Audit and SCM Review respectively.
Configuration management of any system software, hardware, interface and supporting tool
(e.g. the operating system editor, compiler, utilities and CASE tools, etc.) are not covered in
this guide.

________________________________________________________________________________________
2-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

REFERENCES
_________________________________________________________________________________________

3.

REFERENCES

3.1 STANDARDS
IEEE Standard to Software Configuration Management ANSI/IEEE Std-1042-1987 (Reaff.
1993)
Information Technology - Software Life Cycle Processes ISO/IEC 12207
Quality Management - Guidelines for Configuration Management ISO/IEC 10007
Documentation Standards for Implementation Phase, OGCIO [S8]
Practitioner Guide on PRINCE, OGCIO [G38]
3.2 OTHER REFERENCES
PRINCE Configuration Management Guide, CCTA, 1989
PRINCE 2 Project Management for Business, CCTA, 1996
Software Configuration Management Guidebook, NASA-GB-9503, August 1995

Note: As from 1st April 2001, CCTA has become an integral part of the Office of
Government Commerce (OGC) of UK Government. From this date, CCTA ceased
to exist and any further development of International PRINCE was under the control
of OGC. In June 2010, as a result of UK Government reorganisation, OGCs
functions moved into Cabinet Office.

________________________________________________________________________________________
3-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

DEFINITIONS AND CONVENTIONS
_________________________________________________________________________________________

4.

DEFINITIONS AND CONVENTIONS

4.1 DEFINITIONS
None.
4.2 CONVENTIONS
The following acronyms are used in the text of this guide :
BAC
CA
CB
CL
CMO
IAG
PAT
PCA
PID
PRINCE
PSC
SCM
SDLC

Business Assurance Coordinator

Configuration Auditor
Configuration Board
Configuration Librarian
Configuration Management Officer
Impact Analysis Group
Project Assurance Team
Physical Configuration Audit
Project Initiation Document
PRojects IN Controlled Environments
Project Steering Committee
Software Configuration Management
System Development Life Cycle

________________________________________________________________________________________
4-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM CONCEPTS
_________________________________________________________________________________________

5.

SCM CONCEPTS
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 objectives of the Software Configuration Management (SCM) process are :

to identify the configuration of software at discrete points in time; and

to systematically control changes to the identified configuration for the purpose of
maintaining software integrity and traceability throughout the software life cycle.

SCM consists of four functions :

Identification of the components that make up the software system and that define its
functional characteristics;
Control of changes to those components;
Status Accounting of the processing of change requests and, for approved requests,
their implementation status;
Audit on the existence, completeness and integrity of the controlled components, and the
implementation of SCM activities.

SCM is a key process in managing software development, operation, maintenance, and

enhancement. Without SCM, considerable time and effort would be required to control the
products of SDLC projects or systems in production.

5.1 IDENTIFICATION
Products of a SDLC project or system in production may vary widely in complexity, size,
and type. The products may vary from a complete system including all hardware, software
and documentation, to just an algorithm shared by several programs1. A high level product
(e.g. modules) can be decomposed into low level products (e.g. programs). This
decomposition continues until the lowest level is reached where products can be created,
revised, quality reviewed and completed independently. Through the decomposition process,
a hierarchical breakdown structure is formed. The completed low level products will be
used to assemble the high level products in the structure.
Lowest level products that are worth controlling will be selected to be configured and
controlled under SCM.

In general, a product may have both hardware and software components. The concepts for
SCM are similar to hardware CM, but the SCM process must be even more rigorous and deeply
imbedded in the engineering process since software is much more flexible and changeable than
hardware. In this guide, the focal point is on SCM.
________________________________________________________________________________________
5-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM CONCEPTS
_________________________________________________________________________________________

They should first be identified (See section 7.1.1), designated (See section 7.1.2) and
documented (See section 7.1.3) in a SCM Product List (See section 7.1.3.1). In a SDLC
project, more products will be identified as the project proceeds, e.g. individual program
modules will be identified after physical design.
The SCM Product List should be attached to a SCM Plan (See section 7.2) prepared by the
Configuration Management Officer (CMO) (See section 6.2) at the beginning of system
development and/or maintenance phases. The SCM Plan should also document the specific
Configuration Control, Status Accounting, Audit processes to be used as well as the SCM
role assignments.
Different products would need to be controlled at different stages of the system life cycle. A
different set of products would need to be selected for configuration management upon the
transition from system development to system maintenance stage.

5.2 CONTROL
The timing of applying version control and change control to a product will depend on the
project needs, level of risk, sensitivity, and the level of control required for the product2.
Product
Development

Stability

Under
Development

Version Control

Version Control &

Change Control
Time

Start

Check-in for tracking

of changes

Baseline

The above diagram illustrates the progress of development and stability of a product.
During the initial stage of development of a product, changes to the product may not be
recorded and controlled. After a product has come to a stage (e.g. after quality review and
reported complete) that tracking of changes is required, version control should be applied to

Products with high sensitivity (large impact due to small changes) and/or high risk (e.g.
products produced by activities on critical path) are recommended to enter SCM Library early in the
project so that version control and/or change control can be applied earlier. Products that have a
long development life (e.g. more than 6 months) should also be checked in the SCM Library
earlier and periodically to safeguard the investment.
________________________________________________________________________________________
5-2

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM CONCEPTS
_________________________________________________________________________________________

the product 3 . When the product further reaches the stage to become baselined, change
control will also be applied.
Version Control
Each version of a product under SCM or a high level product would be assigned a new
version identity by the Configuration Librarian (CL) when they are modified or assembled.
The version identities should uniquely identify different versions and show the
chronological sequence of their creations.
A SCM Library that holds all master copies of products under SCM and their current and
historical information will be established and operated by the CL (See section 6.3 & 7.3.1)
to control access to the products under SCM and provide status accounting reports when
necessary. All staff should Check out their required products for modification from the
CL (See section 6.3). The modified products should then be Checked in through CL (See
section 7.3.2), who will log the movement in a Product Movement Log (See section 7.1.3.2).
However, read-access to products under SCM is not subject to the Check In and Check
Out procedures.
Change Control
According to the SCM Plan, when a product reaches a stage where change control is
required (See section 7.3.4), the CMO should authorise to baseline it. A baseline is a
frozen state of a product under SCM at a certain point in time. Once the product becomes a
baseline, any change to it must be analysed by the Impact Analysis Group (IAG) (See
section 6.5) and approved by the Configuration Board (CB) (See section 6.1). The
baselined product will form the basis for subsequent work in the development/maintenance
of other products.
In case a baselined product is modified, it should always become a new baseline when
Check In to the SCM Library.

The quality reviewed and completed product, once entered into the SCM Library will start
to be referred and used by other team members for subsequent product development. However,
changes to the product may still arise. Therefore, control is necessary, at least, to maintain the
traceability of versions and changes of the product.
For enhancement project, products of existing system may form the initial SCM Library and
subject to version control at the beginning of the project.
________________________________________________________________________________________
5-3

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM CONCEPTS
_________________________________________________________________________________________

High level product

High level products can be assembled from specified sets of low level products (which may
in turn be built by even lower level products) for specified purposes, e.g. the Feasibility
Study Report for management approval.
The CL is responsible for assembling a high level product only upon request from the CMO
(See section 7.3.5). Changes subsequently made to its constituent products may not
necessarily cause the re-assembly of the high level product.
Although a high level product is not subject to the Check In and Check Out procedures
and the Baseline mechanism, it represents a snapshot of the content of a set of products
under SCM and different assembles (i.e. versions) of it shall be retained in the SCM Library
and logged by the CL.

5.3 STATUS ACCOUNTING

Software configuration status accounting is a record keeping and reporting activity
performed by the CL to maintain the traceability of changes and product versions. The
records contain the information of products under SCM and their current status, based
on which relevant Product Status Reports will be compiled (See section 7.4.1). The
CL should also maintain status information of proposed changes and the
implementation of approved changes, based on which relevant Change Status Reports
will be compiled (See section 7.4.2).

5.4 AUDIT
A Configuration Auditor (CA) (See section 6.4) will assure that the baselined
configuration has been tested to demonstrate that it contains all deliverable entities by
conducting Physical Configuration Audit (PCA) (See section 7.5.1). PCA
authenticates that the components to be delivered actually exist and that they contain all
of the required products, such as the proper versions of source and object code,
documentation, installation instructions, etc. The CA should also ensure that SCM
activities have been properly executed according to the SCM Plan.

________________________________________________________________________________________
5-4

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM ROLES & RESPONSIBILITIES
_________________________________________________________________________________________

6.

SCM ROLES & RESPONSIBILITIES

SCM has to be implemented through the following functional set up/role players of different
responsibilities. In brief, the CMO should be responsible for SCM of a project or system in
production. He/she may delegate the CL role to someone, who would maintain a SCM
Library and implement the Check In and Check out procedures. The IAG will conduct
impact analysis of Change Requests and recommend implementation option to CB, which is
the decision making authority. The CA would conduct the Physical Configuration Audit at
certain checkpoints pre-defined in the SCM Plan.

6.1 CONFIGURATION BOARD (CB)

Responsibilities

Overseeing the SCM System and authorising changes to

baselined product.

Tasks

Give disposition on all recommended Change Requests.

Endorse the SCM Plan prepared at the beginning of the
development or maintenance phase.
Ensure that adequate personnel are assigned for the execution of
the SCM Plan.

6.2 CONFIGURATION MANAGEMENT OFFICER (CMO)

Responsibilities

Establishing, monitoring and operating the SCM processes.

Tasks

Prepare and submit SCM Plan to the CB at the beginning of the

development or maintenance phase.
Assign and delegate authority to CL at the beginning of the
development or maintenance phase, in handling day-to-day
operation of the SCM processes.
Identify products to come under SCM.
Ensure that Configuration Status Accounting and Configuration
Audit reports are prepared and submitted to the CB at intervals
as defined in the SCM Plan.
Authorise the assembly of high level products.
Authorise baseline of products.

________________________________________________________________________________________
6-1

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM ROLES & RESPONSIBILITIES
_________________________________________________________________________________________

6.3 CONFIGURATION LIBRARIAN (CL)

Responsibilities

Monitoring and reporting on all SCM aspects according to the

SCM Plan.

Tasks

Hold information about products under SCM e.g. by

maintaining the Product Movement Log and the SCM Product
List.
Hold information about any high level product assembled e.g.
by maintaining release notes of high level products.
Run a SCM Library to hold master copies of all versions of
products under SCM and any high level product assembled.
Control access to versions of products under SCM through the
Check In and Check Out procedures.
Notify holders of any changes to their copies, e.g. broadcasting
notices of recent changes on various products.
Record status of Change Requests.
Ensure products are re-submitted to the SCM Library after
authorised change, e.g. scanning through the Product Movement
Log periodically to bring up checked out products pending for
checked in.
Produce Configuration Status Accounting Reports.
Assemble and issue high level products together with a release
note stating the contents of the current versions.

6.4 CONFIGURATION AUDITOR (CA)

Responsibilities

Tasks

Assisting the CMO to assure the proper executing of the SCM

Plan.

Monitoring the executing of SCM activities performed

according to the SCM Plan.
Perform Configuration Audits according to the SCM Plan and
whenever necessary.

6.5 IMPACT ANALYSIS GROUP (IAG)

Responsibilities

Assessing changes to the baselined products.

Tasks

Conduct impact analysis for all Change Requests from the

views of business, technical or user.
Advise CB on the actions that should be taken to resolve all
changes raised.

________________________________________________________________________________________
6-2

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE

SCM ROLES & RESPONSIBILITIES
_________________________________________________________________________________________

6.6 SCM IN DEVELOPMENT PHASE

SCM has to be integrated to the project management environments, say, PRINCE, in
OGCIO by the following mappings.
SCM Roles
Configuration Board

Roles in a PRINCE Project

PSC

Configuration Management Officer

The PSC also grants the Project Manager the

authority to handle Change Requests that can be
accommodated within the tolerance given to the
Project Manager as stated in PID.
PM

Configuration Librarian
Configuration Auditor
Impact Analysis Group

A senior member of the project team assigned by

Project Manager.
A senior member of the project team assigned by
Project Manager.
PAT and Project Manager

6.7 SCM IN MAINTENANCE PHASE

SCM is integrated with the system maintenance environments in OGCIO. All SCM roles
should be established in the system maintenance team.

________________________________________________________________________________________
6-3

7.

SCM PROCESSES

7.1 IDENTIFICATION
The CMO should identify products that are worth controlling. They should be selected,
designated and described properly in the SCM Product List. In a SDLC project, more
products will be identified as the project proceeds. The SCM Product List should be
included in the SCM Plan prepared at the beginning of the development or maintenance
phase of the system.

7.1.1 Selection
Each SDLC project or system in production, being unique in scope and nature, should have
their own sets of products selected to come under SCM and documented in the SCM Plan.
The Product Description and/or the Product Breakdown Structure Diagrams given in the
Project Initiation Document (PID) are the recommended starting points for selecting
products to come under SCM. As a general rule, a product is selected if it can be created,
revised and quality reviewed independently. Therefore, it can usually be found at the lowest
level of the product breakdown structure. A high level product should be assembled from its
constituent products, rather than being an item under SCM by itself.
Making Management products (e.g. plans and estimates) under SCM is a useful way of
providing control over development.
Typical examples of product under SCM are given below :

Project Plan
System Specification
Requirement Specification
Design Specification and Design Documentation
Test Plan and Results
All software modules composing the system (e.g. source and/or executable codes)
Implementation Documentation (e.g. System Manual, Program Manual, Data Manual,
Application User Manual, Application Operating Manual and Computer Operating
Procedures Manual)
Standards and procedures
Data Model Repository, if applicable

The above list is not exhaustive. Project team should customise the list according to
individual needs.

7.1.2 Designation
7.1.2.1 Product Identity
A product must be uniquely identifiable. This helps tracking and reporting of product status.
Normally the product ID and Name will be sufficient to uniquely identify a product.
However, to uniquely identify each lower level product further decomposed from a high
level product, an extension may be added to the product ID of the high level product. Project
teams should define their own naming convention which best fit their environments. An
example is given below.
Example :

T321 is the product ID of Programs.

T321/002 is the product ID of program 002.

7.1.2.2 Version Number

Each product is subject to change. To uniquely identify each version, a version numbering
system is essential. The numbering system should show the chronological sequence of the
creation of each version by incrementing the version number. Project teams should define
their own numbering systems which best fit their environments. For implementation
projects, project teams should design their numbering systems according to the prevailing
standard in corresponding installations or data centres. Some examples of numbering system
are given below.
Example 1: Version Number 6 of a product means that it is in the 6th version.
Example 2: Version Number 2.4 of a product means that it is in the 4th version of the 2nd
release.
Example 3: Version Number 1997/13 of a product means that it is in the 13th version since
1997.
This Version Number should be stated explicitly at location according to the type of product:
Type
Document
Program Source Code

Location
Front Page and Footer. For details please refer to Standards &
Methods Document Style Manual, OGCIO
As comment lines at the Heading portion of the source code

If a product in SDLC is selected to continue under SCM in maintenance phase, its version
number should be brought forward instead of resetting it.

7.1.3 Description
7.1.3.1 SCM Product List
For each product, the following minimal set of static information should be maintained and
documented in the SCM Plan :
Point of Baseline

The pre-defined point in time the product is to be baselined.

For SDLC projects: usually at milestone event,
determined by the CMO.
For systems in production: at the completion of the
maintenance cycle of a change request.

Format of Controlled
Copy

The format / media of the controlled copy of the product to

be retained in the SCM Library.

Responsible Officer

Name(s) of officer responsible for the production /

maintenance of the product.

Examples of SCM Product List are given in Attachment 1 & 2. Note that information of
responsible officer is given in section SCM Library of respective attachment.
7.1.3.2 Product Movement Log
For each movement of a product, the following minimal set of information should be kept in
a Product Movement Log by the CL. When a product is checked out, a new entry is
created with a new version number assigned, the name of the check out officer and date
marked. Later, when the product is checked in by the same staff, the check in date will be
marked. This signifies the end of the current movement of a product.
Version Number

When the product is checked out for modification, the

identity of the new version / baseline to which the product
will be modified to, is assigned to the staff checking out.
Marked when the record is created.

Check In / Out Officer

The name of staff who has checked out the product for
exclusive modification. Marked when the record is created.
When the product is checked out for modification, it is
filled with the name of the staff to check out. No one is
allowed to check out or check in the product until the
same staff checks in the modified version. In between the
Check in and Check out process, only read access is
allowed.

Check Out Date

Date of the Check out action. Marked when the record is

created.

Check In Date

Date of the Check in action. Marked when the product is

checked in.
Physical Location &
Name

The physical location and name where the checked in

product is stored.

Change Request Ref. No.

Reference numbers of all Change Requests associated with

this version. Marked when the record is created.

Baseline (Y/N) ?

CMO should refer to the SCM Product List, determine

whether the product has reached the point of baseline and
authorise the CL to baseline the product by marking this
field as Y. If a baselined product is modified, it should
become a new baseline when Check In to the SCM
Library.

Production Version
(Y/N)?

This field is marked Y if the current version of product is

a production version.

An example of a Product Movement Log is shown below :

A modified
baseline should
always become
a new baseline
when Check
In to the SCM
Library.

The Change Request Ref. No. should be

recorded for any change of baselined product
When the product first checks in,
there is no Check Out Date.
Product ID /
Name

T223 System
Specification

T224 User
Requirement

T321/002

Version
No.

Check In / Out
Officer

XXXXXXX

2
3
4

XXXXXXX
XXXXXXX
XXXXXXX

XXXXXXX

XXXXXXX

1
2
3

XXXXXXX
XXXXXXX
XXXXXXX

Check Out
Date

Check In
Date

(dd.mm.yyyy)

(dd.mm.yyyy)

Physical
location
& name

12.2.1997

xxxxxxx

13.3.1997
7.5.1997
9.7.1997

xxxxxxx

2.2.1997

xxxxxxx

12.3.1997

xxxxxxx

2.2.1998
12.3.1998

xxxxxxx

12.3.1997
4.5.1997
8.7.1997

11.3.1997

11.3.1998
4.5.1998

Change
Request
Ref.
No.

xxxxxxx
xxxxxxx

xxxxxxx

12

Baseline
(Y/N)?

Production
Version
(Y/N)?

Y
Y

xxxxxxx

This indicates that the product has been

checked out but not yet checked in.

CL will baseline a product according to the Point of

Baseline stated in the SCM Product List.
This version of program is the production version.
This low level product (program) is uniquely identified by the product ID of its parent
product T321 and an extension 002.

In case a checked out product is checked in without modification, the CL may

simply delete the latest record.

7.2 PLANNING
Each of the activities of SCM requires resources and need to be planned. A SCM Planwhich
defines the SCM procedures to be used and allocates the responsibilities for the SCM
activities, should be prepared by the CMO.
For SDLC projects, the plan should be attached in the PID and endorsed by the CB.
For systems in production, the plan should be prepared before the start of the maintenance
phase and endorsed by the CB.
The following headings of the SCM Plan are recommended :
Role Assignment

Defines the SCM responsibilities for all staff who will be

involved in any SCM activity.

Configuration
Identification

Identify products and illustrate their inter-relationships.

Define the naming/numbering conventions to be adopted for
products.
Define all necessary SCM interfaces to other projects or
external organisations, if any

Configuration
Control

Configuration
Status
Accounting
Configuration
Audit

Define the procedures to be used for change control, issuing

and distributing copies of managed products.
Define in detail the filing structure to be used for the various
categories of products, e.g. hardware, documentation,
magnetic media etc. If a computer based SCM support tool is
to be used, this section should provide the details.
Define the physical and logical access security procedures to
be adopted for the master copies of products.

Define the requirements and procedures for reporting status

on products and Change Requests.

Define how and when the correctness, integrity and

completeness of products can be assured.

Examples of SCM Plan can be found in Attachment 1 & 2. Note that they are examples for
reference but not standard to be followed. Project teams should customize their own plans
according to individual needs.

7.3 CONTROL
Configuration Control is concerned with controlling access to products in all their
representations and managing change to those products. Check In and Check Out are
procedures to manipulate different versions of products and to control access to them.
Change Control procedure is used to manage changes and keep track of their status. Physical
control, variant control, control of contractors work and database administration will also
be discussed here.

7.3.1 Physical Control

7.3.1.1 Physical control of products before checking in
Before checking in (See section 7.3.2), working copies of products are retained by
individual staff. It is their responsibility to :

Ensure that the completeness and integrity of the product to be checked in (i.e. all
components are present and of the correct version).
Ensure that any working copy of product is not being updated by others.

Different file-store directories in individuals working environment should be created to

separate all machine readable products by type, by version, by phases or major checkpoints
of software life cycles etc. Hard-copied products should be stored similarly in separate
physical locations.
7.3.1.2 Physical control of products after checking in
A product becomes under SCM control when the first quality reviewed or completed
version is checked in (See section 7.3.2) and passed to the CL. Thereafter, the CL is
responsible for the physical control of the products.
The CL is responsible to :

Run a SCM Library to hold master copies of all versions of products in the storage
format as recommended in the SCM Plan. For products of machine readable format,
there may be file-store directories (organised by type, by version, by phases or by major
checkpoints etc.) to which only the CL has the privilege of granting access. Hard-copied
products should be stored similarly in separate physical locations.

Hold information about products in SCM Product List and Product Movement Log etc.

Control access of various versions of products through the Check In and Check Out
procedures.

7.3.2 Check In Procedure

Description

This is the procedure of submitting a new or modified product to the CL for

SCM control.

Objective

Input

New product / Modified product

Method

The submission of the product should be accompanied by the following

information :

To centralise the processing of any in-flow of products.

To maintain a log of products modified.

Product ID / Name
Name of staff to check in
Date of check in
Documentary record of quality review or completion

The CL should :
1. check if the product has reached the stage being under control with
reference to the SCM Plan.
2. for baselined product, ensure the baseline is authorized by the CMO.
3. check if the staff to check in has sufficient security level.
4. check if the product already exists in the Product Movement Log.
If it is not in the log, it is a newly quality reviewed or completed product to
be filed to the SCM Library,

check if it has been registered in the SCM Product List. If not, add a
new record to the list.
add a new entry of Product Movement Log.
record the check in officer name.

If it is a product already under SCM control (i.e. has entries in the Product
Movement Log), ensure the product has been checked out by the same
staff by checking against the Product Movement Log.
5. ensure the totality and validity of the physical product and add the new
copy to the SCM Library.
6. mark the Check In Date in the corresponding record of Product
Movement Log. If the product is a baseline version, mark the record as
Baseline. If it is a production version, mark the record as Production.
Output

New version of product, new or updated entry on Product Movement Log,

new entry on SCM Product List.

Frequency

Any time after the SCM Plan was endorsed.

7.3.3 Check Out Procedure

Description

This is the procedure to obtain the latest version of products from CL for
modification.

Objective

Input

Authorised Change Requests.

Method

Each check out request should be accompanied by the following

information :

To centralise retrieval process of products under SCM.

To maintain a log of products being modified.

Product ID / Name
Name of staff to check out
Date of check out
The Change Request Form No(s) which leads to the current check
out action

The CL should :
1. check if the staff to check out has sufficient security level.
2. reject if the latest version of the product has already been checked
out.
3. ensure that any change is authorized by checking the status of
relevant Change Request(s).
4. create a new entry of the product in the Product Movement Log.
Record the check in / out officer name and the check out date.
Increment the Version Number. Also mark any relevant Change
Request Ref. No. in the record.
5. ensure that the latest version stored in the SCM Library is the one
requested. If yes, issue the copy to the requesting staff.
Output

Issued copies of product, new entry of the product in the Product

Movement Log.

Frequency

Any time after the product has been checked in for the first time, when
Change(s) on the product were authorised and implemented.

Retrieval of any previous version of a product is not subject to this procedure. In case for
some reasons a previous version of a product is retrieved and modified, the modified copy,
as a derivation from the mainstream development of the original product, should be
checked in as a brand new product. Please refer to section 7.3.6 for details.

7.3.4 Change Control

Description

The following procedure describes the processing of any change

request for enhancement or problem fixing of baselined products.

Objective

To provide a controlled environment to implement change.

To protect the integrity of the software configuration.

Input

For SDLC projects: any request for change or off-specification

report raised by the Project Manager (and if appropriate the PAT
members), as a result of some project issues.

For systems in production, any change request raised at any time by

individuals or coordinators (for consolidating Change Requests
from user community).

Method

Initiation
If a Change Request proposes enhancement to the original
specification, it should be classified as an enhancement. When it
indicates that a product does not meet its specification and correction
has to be taken, it should be classified as a problem report. The
originator has to document the situation in the Change Request Form.
Note that for SDLC projects, an off-specification situation will usually
lead to a problem fixing whereas a request for change situation will
usually lead to an enhancement.
Upon receipt of a Change Request Form, the CL will assign a Change
Request Ref. No. to it.
Impact Analysis
The CL will pass it to the IAG, who will conduct impact analysis to
determine the products affected as well as the resource requirement,
timescale, cost and risk of the work to implement any necessary
change. The analysis should be conducted from business, user and
technical viewpoints. Result of analysis should be documented on the
Change Impact Analysis Form. The IAG will also re-evaluate the
appropriateness of the change type - Problem report or enhancement,
and if necessary revise it.
Disposition
Based on the analysis, the IAG will prioritise the Change Request and
recommend a feasible option. Upon completion of the impact analysis,
the CB will reject, approve or has the request deferred (e.g. hand-over
to a separate follow-up project).
For SDLC projects, for changes that cannot be accommodated within
the given tolerance, decision is left to CB. Otherwise, the Project

Manager can make the decision.

Implementation
Any approved change will be co-ordinated by the CMO and passed to
corresponding change implementer, who would check out copies of
the affected baselined product from the CL. In case of program change,
besides ordinary unit testing, regression testing would usually have to
be included in the test to assure that errors have not been introduced in
existing functions by the change. Moreover, the associated
documentation has to be revised to reflect the change. At last, the
correctness of the change has to be verified by the Change Request
Originator. The accepted products would be checked in through the
CL.
Monitoring
The following status information of a Change Request should be
recorded by the CL as it is processed. Based on the status information,
Change Status Report(s) can be compiled and submitted to relevant
parties.

assigned
approved
rejected
deferred
being implemented (if possible, status information of the
implementation)
implemented
Output

Processed Change Requests, New baseline of products

Frequency

Any time after the products have been baselined.

Project teams should wherever possible adopt these procedures. It is the essence of the
control mechanism that is vital, not the terminology nor the formality of the procedures. If
for any reason it is necessary to tailor them to suit particular circumstances the new
procedures must be detailed in the SCM Plan.

7.3.5 Assembly of High Level Product

Description

High level products can usually be identified at the higher levels of the
Product Breakdown Structure. They are assembled from a specified set of
low level products (which may in turn be built up by even lower level
products) for a specified purpose, e.g. the FS Report for Funding
Approval. The following procedure describes the steps to assemble a
high level product.

Objective

To assemble high level products based on their constituent products

To maintain information of high level products assembled

Input

Product Breakdown Structure

Lower level products that constitute the high level product required.

Method

Upon authorization from CMO, the CL should :

1. go through the Product Breakdown Structure to get the composition
of the high level product required.
2. retrieve the latest version of the relevant low level products (can be
baselined or under development) from the SCM Library and assemble
the high level product required.
3. Increment the version number of the high level product required.
4. Attach to it a release note containing the following minimal set of
information before issuing.

Product Name
Version Number (see section 7.1.2.2)
Release Date
Details of all constituent products including :
Product Id / Name
Version Number (see section 7.1.2.2)

5. Retain a master copy and the related release note in the SCM Library.
6. If appropriate, notify relevant parties the release of a new version of
the high level product.
Output

Issued copies and master copy of the high level product, with the
release note attached.

Frequency

Upon authorisation from CMO, probably triggered by some external

events e.g. the need to assemble a FS report for funding approval.

The high level product is not subject to the Check In and Check Out procedures and the
Baseline mechanism. The CL is only responsible for centrally storing the master copies of
such products, maintaining release notes and distributing them upon request. All change
requests to a high level product should be redirected to its constituent products under SCM.

7.3.6 Control of Variants

Versions of products usually occur sequentially. In between two version, variants may
exist. Variants are modified product based on the same descent. This is commonly
termed as Branching. They were developed to meet conflicting requirements at the
same time. The situation is most commonly found in products of program modules.
There are two controlling techniques for managing variance:
1. A co-ordinator should be appointed to check out a version of a product and then
distribute it to various developers. The co-ordinator is responsible for merging all
variants created before he/she check in the merged version of product.
2. include the variation as a branch from the main stream design and treated them as
new products.
The variance can be difficult to manage so communication among relevant parties is
extremely important. Co-ordination meetings among relevant parties are highly
recommended to be held periodically.

7.3.7 Control of contractors Work

Items or subsystems which are developed / supplied / maintained by contractor, should also
be controlled and audited for SCM.
The contractor should follow the SCM Plan set out. The SCM processes planned should be
conformed to OGCIOs practice. Moreover, the method of incorporating the accepted
products into the in-house SCM system should be included in the SCM Plan.
The SCM Processes agreed should be rigidly adhered to. They must include Product Status
Reporting and Change Status Reporting. Also, the process of approval for contractorinitiated change proposals must be clearly stated and agreed in advance. There must be
clearly defined limits upon the scope of the contractor's authority in matters concerning the
issuing and making changes.

7.3.8 Database Administration

During SDLC, data structure will gradually be designed and physically set up as databases
for coding, testing, user acceptance and pre-production activities etc. Testing data would be
entered into some testing databases. Current system data would be converted into the preproduction database. Code tables would be set up for testing and production purposes.
Different sets of testing data may be created during the program coding, unit test, integration
test, system test and user acceptance activities etc. They should be identified as separate
products under SCM. At the completion of each activity, the corresponding testing data set
would be baselined and a new testing database would be set up for next stages activities.
All subsequent changes should be applied to the new database.
To manage changes on data content as well as the data structure, SCM change control
procedure still applies, possibly with the following adaptations.

A corporate-wide party can be established to oversee data-related Change Requests on

all systems during the development and/or maintenance phases.
A database administrator (or team) can be delegated to conduct impact analysis and/or
implement all approved changes on both data content and data structure during the
development and/or maintenance phases.
Before production, a model administrator can be specifically assigned to conduct impact
analysis and implement any approved change solely on data structure.
It may not be necessary to inform users the details of all physical data structure changes,
because some changes may be transparent to the users. A summary on those changes can
be compiled and presented to the users at some review meetings.

7.4 STATUS ACCOUNTING

Configuration Status Accounting provides the tracking information to assist in the
management of the SDLC project or system in production. The CL will be responsible for
producing all regular and ad hoc reports on the current status or history of all products
under SCM, and changes implemented and in progress. The minimal set of reporting
requirements are :

Product Status Reporting

Change Status Reporting

7.4.1 Product Status Reporting

Description

It is the procedure to compile report(s) on status of all products under

SCM.

Objective

To report progress of products under SCM.

Input

Product Movement Log

Method

The CL will extract the content of Product Movement Log to compile

listing and derive statistics for various status of products.

Output

Product Status Report, to be submitted to CB and for Configuration

Audit purpose, should contains :

Frequency

Extraction of Product Movement Log.

Statistics of status of all products.
Other useful information of products.

For SDLC projects: at major checkpoints such as the end of each

stage. The report(s) should also be attached in the Project
Evaluation Report as annex at end of project.
For systems in production: as defined in the SCM Plan.

Recommended contents of a Product Status Report are :Entries

Product ID / Name
Version Number
Check In / Out Officer
Check Out Date
Check In Date
Baseline (Y/N)?
Production Version (Y/N)?

Summary
Total no. of products under SCM
Percentage of baselined products

7.4.2 Change Status Reporting

Description

It is the procedure to compile report on status of all Change Requests.

Objective

To report progress of Change Request.

Input

Change Request Forms

Method

The CL can scan through the Change Request Forms to compile listing
and derive statistics for various status of Change Requests.

Output

Change Status Report, to be submitted to CB and for Configuration

Audit purpose, should contains :

Frequency

List of Change Requests of various status.

Statistics of Change Requests of various status.
Other useful information of Change Requests.

For SDLC projects: at major checkpoints such as the end of each

stage. The report(s) should also be attached in the Project
Evaluation Report as annex at end of project.
For systems in production: as defined in the SCM Plan.

Recommended contents of a Change Status Report are :Entries

Change Request Ref. No.
Change Request Date
Change Request Description
Change Request Status
Summary
Total no. of Change Request assigned.
Total no. of Change Request approved.
Total no. of Change Request rejected.
Total no. of Change Request deferred.
Total no. of Change Request being implemented
Total no. of Change Request implemented.

7.5 AUDIT
Configuration Audit is the process of assuring that the configuration has been tested to
demonstrate that it contains all deliverable entities. It also assures the proper execution
of the SCM activities according to the SCM Plan. The process is composed of :

Physical Configuration Audit

Quality Assurance of SCM Activities

7.5.1 Physical Configuration Audit

Description

It is the procedure to perform physical check on all products under SCM

Objective

To ensure that the as-built version of products complies with their

Product Movement Log record.
To ensure that products contain all of the associated items, such as
the unit test plan, specification and results of a program.

Input

Product Movement Log, Latest version of products, Change Requests,

Product Breakdown Structure

Method

Latest version of products is physically checked with their Product

Movement Log by CA. Product Breakdown Structure is referred to check
the completeness of products.

Output

Report on Physical Configuration Audit to be submitted to CB

Frequency

For SDLC projects: recommended at end of project.

For systems in production: recommended annually.

A sample form of report on Physical Configuration Audit was given in Attachment 3.

7.5.2 Quality Assurance of SCM Activities

Description

This is the procedure to assure the quality of all SCM activities as

defined in the SCM Plan.

Objective

To ensure all planned SCM activities have been performed according to

the SCM Plan.

Input

SCM products, e.g. SCM Plan, Change Status Report, Report on Physical
Configuration Audit.

Method

The CA will check the documentary proof of execution of all SCM

activities as stated in the SCM Plan.

Output

SCM Review Report

Frequency

For SDLC projects: recommended at end of project.

For systems in production: recommended annually.

A sample form of SCM Review Report was given in Attachment 4.

7.6 HAND-OVER
A hand-over meeting should always be conducted between the party to take over and the
current project team for transferring relevant materials and experiences. The party taking
over should then prepare a new SCM Plan to be applied in subsequent phases of the
software life cycle.
In case it is a hand-over between any two phases of SDLC :
The party to take over will probably be a project team for carrying out subsequent
phases of SDLC.
The items to be transferred include :

Final SCM Plan.

Final Product Status Report.
Final Change Status Report.
Product Movement Log
All versions of project products.
All follow-up actions of outstanding issues.
All hardware, software, documents and supporting tools for managing the system.
Any proof of quality (e.g. Quality Assurance Review Result)

In case it is a hand-over
from SDLC to production
from production to a SDLC project
The items to be transferred include :

Final SCM Plan

Final Product Status Report
Final Change Status Report
Product Movement Log
All follow-up actions of outstanding issues.
All hardware, software, documents and supporting tools for managing the system.
Any proof of quality (e.g. Quality Assurance Review Result)
All versions of :
a. All hardware & software components composing the systems
b. All implementation documents (Please refer to OGCIOs Documentation
Standard for Implementation Phase for details)
System Manual
Program Manual
Data Manual
Application Operation Manual
Application User Manual
Computer Operating Procedures Manual

Attachment 1
Example of Application Software Configuration Management Plan for SDLC
projects

1.

PURPOSE
This plan describes the Software Configuration Management (SCM) activities for
Application Software to be performed during the FS, SA&D and Implementation
phases of the project ABC for Dept XXX.

2.

SCOPE
The following aspects of SCM would be defined and the way to implement them
would be introduced.
Role
Assignment

Configuration
Identification

3.

identify the organization units that participate in the

project;
specify the allocation of activities/tasks to the
organizational units.
Identify products and illustrate their inter-relationships.
Define the naming/numbering conventions to be
adopted for products.
Define all necessary SCM interfaces to other projects
or external organisations, if any

Configuration
Control

Define the procedures to be used for change control,

issuing and distributing copies of managed products.

Configuration
Status
Accounting
Configuration
Audit

Define the requirements and procedures for reporting

status on products and changes.

Define how and when the correctness, integrity and

completeness of products can be assured.

REFERENCES
Initial Request Statement of the project.

4.

DEFINITIONS AND CONVENTIONS

Adopted those defined in Software Configuration Management Process Guide
[G46].

5.

ROLE ASSIGNMENT
SCM Roles
Configuration Board (CB)

Assignment
TSUI XX, SEO(A), Executive of PSC
CHOI XX, SEO(IT), Senior User of PSC
KWOK XX, SSM(D)XX, Senior Technical
of PSC

Configuration Management
Officer (CMO)

CHAN XX, SM(D)XX, Project Manager

Configuration Librarian (CL)

WU XX, AP1(D)XX for subsystem A

HO XX, AP1(D)XX for subsystem B

Configuration Auditor (CA)

NG XX, AP1(D)XX

Impact Analysis Group (IAG)

KO XX, EO(A), BAC

NG XX, AP1(D)XX, BAC
FUNG XX, EO(IT), UAC
CHAN XX, SM(D)XX, TAC & Project
Manager

6.

CONFIGURATION IDENTIFICATION
The following SCM Product List shows all products identified to come under SCM
for this project, the officer responsible, their points of baseline in time (marked by
) and their recommended storage formats.

Product ID

Product Name

Project
Initiation

M100

Project Initiation Document

M210

Project Plan

M220

Stage Plans

B
B
V

T110

FS Management Summary

T121
T122

FS Current Environment
Description
Project Definition

T210

SA&D Management Summary

T221
T222

SA&D Current Environment

Description
User Requirement

T223

System Specification

T224

Technical System Option

T311

Data File Description

T312

Program Specification

FS

SA&D

Phy.
Design

Impl.

Production
& system
nursing

MS Word
MS Project

V
V
V

V
B
B

V
V

MS Word
MS Word / Oracle
Designer/2000
MS Word

V
V

B
B

B
V

MS Word
MS Word / Oracle
Designer/2000
MS Word / Oracle
Designer/2000
MS Word

T330/<test-no.>

V
V
V
V
V
V

B
B
B
B
B
B

T351
T352

Program Manual

T353

Data Manual

T354

Application Operation Manual

T355

Application User Manual

T356
T400

Computer Operating
Procedures Manual
Tender Specification

T600

Evaluation Report

T700

Procurement Contract

M600

Project Evaluation Report

T341/<test-no.>

Key :
V - check in for version control
B - baseline for change control

MS Project
MS Word

T321/<program-ID> Program Source

System Test Plan, Spec and
Results
Acceptance Test Plan, Spec
and Results
System Manual

Format of
Controlled Copy

MS Word / Data
Model Repository
MS Word / Oracle
Designer/2000
Text file / Oracle
Designer/2000
MS Word / Data
Model Repository
MS Word / Data
Model Repository
MS Word
MS Word
MS Word
MS Word
MS Word
MS Word
MS Word / Hardcopy
MS Word

B
B
B
B

MS Word / Hardcopy
MS Word

7.

CONFIGURATION CONTROL
The Configuration Control procedures as stated in the OGCIO SCM guide would be
followed unless otherwise stated in this plan.

7.1

VERSION CONTROL
A version numbering system is used on both products under SCM and high level
products. The version number is incremented when a new version of the product is
created.
The syntax of version number is : m . n

where both m and n are numeric;

m is the baseline number and n is
the change number.

e.g.
0.2
1.0
1.3
2.0

7.2

2nd change before baseline.

1st baseline.
3rd change of the 1st baseline, the working copy to be submitted to CL
for registration.
2nd baseline.

CHANGE CONTROL
The following formal change control procedure would be applied to any change
requests to baselined products.
Initiation
If a Change Request proposes enhancement to the original specification, it should be
classified as an enhancement. When it indicates that a product does not meet its
specification and correction has to be taken, it should be classified as a problem
report. The originator has to document the situation in the Change Request Form.
An off-specification situation will usually lead to a problem fixing whereas a request
for change situation will usually lead to an enhancement.
Upon receipt of a Change Request Form, the CL will assign a Change Request Ref.
No. to it.
Impact Analysis
The CL will pass it to the IAG, who will conduct impact analysis to determine the
products affected as well as the resource requirement, timescale, cost and risk of the
work to implement any necessary change. The analysis should be conducted from
business, user and technical viewpoints. Result of analysis should be documented on
the Change Impact Analysis Form. The IAG will also re-evaluate the appropriateness
of the change type - Problem report or enhancement, and if necessary revise it.
Disposition

Based on the analysis, the IAG will prioritise the Change Request and if appropriate,
recommend a feasible option. Upon receipt of the impact analysis form, the CB will
reject, approve or has the request deferred (e.g. hand-over to a separate follow-up
project).
For changes that cannot be accommodated within the given tolerance, decision is left
to CB. Otherwise, the Project Manager can make the decision.
Implementation
Any approved change will be co-ordinated by the CMO and passed to corresponding
change implementer, who would check out copies of the affected baselined product
from the CL. The associated documentation has to be revised to reflect the change.
The correctness of the change has to be verified by the Change Request Originator.
The accepted products would be checked in through the CL.
Monitoring
The following status information of a Change Request should be recorded by the CL
as it is processed. Based on the status information, Change Status Report(s) can be
compiled and submitted to relevant parties.

7.3

assigned
approved
rejected
deferred
being implemented (if possible, status information of the implementation)
implemented

SCM LIBRARY
All soft-copies would be retained in different directories (grouped by the types of
soft-copies) of a network file server accessible by authorized personnel. Backup
would be conducted daily and weekly. The weekly backup would be kept off-site.

Project Initiation Document (M100)

ITSFGH2\CM_DXX\PID\
Project Plan (M210)

ITSFGH2\CM_DXX\PRJ_PLAN\
Stage Plan (M220)

ITSFGH2\CM_DXX\STG_PLAN\
Feasibility Study Report (T100)

ITSFGH2\CM_DXX\FS_REP\

C/M

C/M

C/M

C/M

Management Summary (T110)

ITSFGH2\CM_DXX\FS_MS\
Current Environment Description (T121)

ITSFGH2\CM_DXX\FS_CED\
Project Definition (T122)

ITSFGH2\CM_DXX\PRJ_DEF\
System Analysis and Design Report (T200)

ITSFGH2\CM_DXX\SA&D_REP\
Management Summary (T210)

ITSFGH2\CM_DXX\SA&D_MS\
Current Environment Description (T221)

ITSFGH2\CM_DXX\SA&D_CED\
User Requirement (T222)

ITSFGH2\CM_DXX\USER_REQ\
System Specification (T223)

ITSFGH2\CM_DXX\SYS_SPEC\
Technical System Option (T224)

ITSFGH2\CM_DXX\TSO\
Data File Description (T311)

ITSFGH2\CM_DXX\DATA_SPEC\
Program Specification (T312)

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

C/M

ITSFGH2\CM_DXX\PRG_SPEC\
Program Module of Sub-system A
ITSFGH2\CM_DXXA\PROG\
ITSFGH2\CM_DXXA\DDL\
Program Module of Sub-system B
ITSFGH2\CM_DXXB\PROG\
ITSFGH2\CM_DXXB\DDL\
System Test Plan, Spec. & Result (T330)
ITSFGH2\CM_DXX\SYS_TEST\
Acceptance Test Plan, Spec. & Result (T341)
ITSFGH2\CM_DXX\ACC_TEST\
System Manual (T351)
ITSFGH2\CM_DXX\SYS_MAN\
Program Manual (T352)
ITSFGH2\CM_DXX\PRG_MAN\
Data Manual (T353)
ITSFGH2\CM_DXX\DAT_MAN\
Application Operation Manual (T354)
ITSFGH2\CM_DXX\AO_MAN\
Application User Manual (T355)
ITSFGH2\CM_DXX\AU_MAN\
Computer Operating Procedures Manual (T356)
ITSFGH2\CM_DXX\SYS_MAN\

C/M

C/M

C/M

C/M

C/M

C/M

C/M

Tender Specification (T400)

C/M

C/M

C/M

C/M

ITSFGH2\CM_DXX\TDR_SPEC\
Evaluation Report (T600)

ITSFGH2\CM_DXX\TDR_EVAL\
Procurement Contract (T700)

ITSFGH2\CM_DXX\CONTRACT\
Project Evaluation Report (M600)

ITSFGH2\CM_DXX\PRJ_EVAL\
C : Create

M: Modify

R: Read

All hard-copies would be retained in different subject files (grouped by the types of
hard-copies) and secured in a filing cabinet, which is accessible by authorized
personnel.
8.

CONFIGURATION STATUS ACCOUNTING

The Configuration Status Accounting procedures as stated in the OGCIO SCM
guide would be followed unless otherwise stated in this plan.
The detailed requirements for reporting are :
Product Status Report (Frequency : End-Stage Assessment)
Entries
Product ID / Name
Version Number
Check In / Out Officer
Check Out Date
Check In Date
Baseline (Y/N)?
Production Version (Y/N)?
Summary
Total no. of products under SCM
Percentage of baselined products

Change Status Report (Frequency : End-Stage Assessment)

Entries
Change Request Ref. No.
Change Request Date
Change Request Description
Change Request Status
Summary
Total no. of Change Request assigned.
Total no. of Change Request approved.
Total no. of Change Request rejected.
Total no. of Change Request deferred.
Total no. of Change Request being implemented
Total no. of Change Request implemented.

9.

CONFIGURATION AUDIT
The Configuration Audit procedures as stated in the OGCIO SCM guide would be
followed unless otherwise stated in this plan.
A Physical Configuration Audit would be conducted before production.
Quality Assurance of implementation of this plan would be conducted by the
Configuration Auditor at end of project.

10.

CHANGE REQUEST FORM

A standard Change Request Form is attached at the end of this plan. Originator of
any change request should complete the form and submit to their CMO accordingly.

CHANGE REQUEST FORM

End User Ref. No.:
OGCIO Ref. No.:

To be filled by the requester

Requester Name:

Post:

Signature
Date:
Approved by:
Signature

Tel.:
Post:
Date:

Application System Name:

Application Sub-System Name:
Change Request Type :
Problem Report
Priority :
High
Medium
Low
Proposed Implementation Date:
Change Requested:

Enhancement

(use separate sheets if necessary)

Reason for the Change:

To be filled by IAG
Impact Analysis Result:

(use separate sheets if necessary)

SM
Estimation of human effort (Man-day):
Estimation of cost:
Remark:
Performed by:
Signature:
Approved by:
Signature:

API

APII

Estimated total adjusted function point:

Post:
Date:
Post:
Date:
Page 1 of 2

To be filled by CB
Disposition:
Reason/Comment :

Approved

Deferred to

End User Representative:

Signature:
OGCIO Representative:
Signature:

Rejected

Post:
Date:
Post:
Date:

To be filled by the implementor

Date of completion:
SM
Actual human effort spent(Man-day):
Actual cost spent:
Remark:

API

APII

Actual total adjusted function point:

Name:
Signature:

Post:
Date:
Page 2 of 2

--- End of Plan ---

Attachment 2
Example of Application Software Configuration Management Plan For Systems
In Production

1.

PURPOSE
This plan describes the Software Configuration Management (SCM) activities for
Application Software to be performed in maintaining the system XYZ for ABC
Dept.

2.

SCOPE
The following activities of SCM would be defined and the way to implement them
would be introduced.
Role
Assignment

Configuration
Identification

Configuration
Control

Configuration
Status
Accounting
Configuration
Audit
3.

identify the organization units that participate in

maintaining the system;
specify the allocation of activities/tasks to the
organizational units.
identify, name and describe the products under SCM;
identify the relationship/structure between the products;
define all necessary SCM interfaces to other projects or
external organizations, if any.
Define the change controls imposed on the baselined
products on:
identification and documentation of the need of a
change;
analysis and evaluation of a change request;
approval or disapproval of a request;
verification, implementation, and release of a change.
Define the requirements and procedures for record and
report the status of products.
Define the procedures to ensure the correctness, integrity
and completeness of products.

REFERENCES

4.

SA&D Report of XYZ System of ABC Department (T200), V2.1, Dec 1996.
SCM Plan for SA&D of the XYZ System.

DEFINITIONS AND CONVENTIONS

Adopted those defined in Software Configuration Management Process Guide
[G46].

5.

ROLE ASSIGNMENT
Assignment of various SCM roles to project organisation is as follow:

SCM Roles
Configuration Board
(CB)

Name
CHAN XX
NG XX

Assignment
Rank/Post
Remark
SM(D)XX
SEO XX

Configuration
Management Officer
(CMO)

CHAN XX

SM(D)XX

Configuration Librarian
(CL)

WONG XX

API(D)XX

responsible for
sub-system A

LEE XX

API(D)XX

responsible for
sub-system B

Configuration Auditor
(CA)

HO XX

API(D)XX

Impact Analysis Group

(IAG)

WONG XX

API(D)XX

responsible for
sub-system A

LEE XX

API(D)XX

TSE XX

APII(D)XX

responsible for
sub-system B
responsible for both
sub-systems A & B

6.

CONFIGURATION IDENTIFICATION
The following SCM Product List shows all products (products) identified for this
project, their version identities, the officer responsible & suggested storage format:
Product ID
T321<program-ID>

Product Name

T330/<test-no.>

Program source of
Sub-system A
Program source of
Sub-system B
System Test Plan, Spec and Results

T341/<test-no.>

Acceptance Test Plan, Spec and Results

T351
T352
T353
T354
T355
T356

System Manual
Program Manual
Data Manual
Application Operation Manual
Application User Manual
Computer Operating Procedures Manual

Format of
Controlled Copy
Text file / Oracle
Designer/2000
Text file / Oracle
Designer/2000
MS Word / Data
Model Repository
MS Word / Data
Model Repository
MS Word
MS Word
MS Word
MS Word
MS Word
MS Word

7.

CONFIGURATION CONTROL
The Configuration Control procedures as stated in the OGCIO SCM guide would be
followed unless otherwise stated in this plan.

7.1

VERSION CONTROL
The version number of the products under SCM is brought forward from the existing
version number maintained in the SDLC projects. The version numbering scheme
follows that in the SDLC projects.

7.2

CHANGE CONTROL
The following formal change control procedure would be applied to changes to
baselined products.
Initiation
If a Change Request proposes enhancement to the original specification, it should be
classified as an enhancement. When it indicates that a product does not meet its
specification and correction has to be taken, it should be classified as a problem
report. The originator has to document the situation in the Change Request Form.
Upon receipt of a Change Request Form, the CL will assign a Change Request Ref.
No. to it.
Impact Analysis
The CL will pass it to the IAG, who will conduct impact analysis to determine the
products affected as well as the resource requirement, timescale, cost and risk of the
work to implement any necessary change. The analysis should be conducted from
business, user and technical viewpoints. Result of analysis should be documented on
the Change Impact Analysis Form. The IAG will also re-evaluate the appropriateness
of the change type - Problem report or enhancement, and if necessary revise it.
Disposition
Based on the analysis, the IAG will recommend a feasible option, if appropriate.
Upon receipt of the impact analysis form, the CB will reject, approve or has the
request deferred (e.g. hand-over to a separate follow-up project).
Implementation
Any approved change will be co-ordinated by the CMO and passed to corresponding
change implementer, who would check out copies of the affected baselined product
from the CL. In case of program change, besides ordinary unit testing, regression
testing would usually have to be included in the test to assure that errors have not
been introduced in existing functions by the change. Moreover, the associated
documentation has to be revised to reflect the change. At last, the correctness of the
change has to be verified by the Change Request Originator. The accepted products
would be checked in through the CL.

Monitoring
The following status information of a Change Request should be recorded by the CL
as it is processed. Based on the status information, Change Status Report(s) can be
compiled and submitted to relevant parties.

7.3

assigned
approved
rejected
deferred
being implemented (if possible, status information of the implementation)
implemented

SCM LIBRARY
All soft-copies would be retained in different directories (grouped by the types of
soft-copies) of a network file server accessible by authorized personnel. Backup
would be conducted daily and weekly. The weekly backup would be kept off-site.

Program Module of Sub-system A

ITSFGH2\CM_DXXA\PROG\
ITSFGH2\CM_DXXA\DDL\
Program Module of Sub-system B
ITSFGH2\CM_DXXB\PROG\
ITSFGH2\CM_DXXB\DDL\
System Test Plan, Spec. & Result (T330)
ITSFGH2\CM_DXX\SYS_TEST\
Acceptance Test Plan, Spec. & Result (T341)
ITSFGH2\CM_DXX\ACC_TEST\
System Manual (T351)
ITSFGH2\CM_DXX\SYS_MAN\
Program Manual (T352)
ITSFGH2\CM_DXX\PRG_MAN\
Data Manual (T353)
ITSFGH2\CM_DXX\DAT_MAN\
Application Operation Manual (T354)
ITSFGH2\CM_DXX\AO_MAN\
Application User Manual (T355)
ITSFGH2\CM_DXX\AU_MAN\
Computer Operating Procedures Manual
(T356)
ITSFGH2\CM_DXX\SYS_MAN\
SCM Plan
ITSFGH2\CM_DXX\SCMPLAN\

C : Create

M: Modify

R: Read

All hard-copies (if any) would be retained in different subject files (grouped by the
types of hard-copies) and secured in a filing cabinet, which is accessible by
authorized personnel.
8.

CONFIGURATION STATUS ACCOUNTING

The Configuration Status Accounting procedures as stated in the OGCIO SCM
guide would be followed unless otherwise stated in this plan.
The detailed requirements for the reports are :
Product Status Report (Frequency : Quarterly)
Entries
Product ID / Name
Version Number
Check In / Out Officer
Check Out Date
Check In Date
Baseline (Y/N)?
Production Version (Y/N)?
Summary
Total no. of products under SCM
Percentage of baselined products

Change Status Report (Frequency : Monthly)

Entries
Change Request Ref. No.
Change Request Date
Change Request Description
Change Request Status
Summary
Total no. of Change Request assigned.
Total no. of Change Request approved.
Total no. of Change Request rejected.
Total no. of Change Request deferred.
Total no. of Change Request being implemented
Total no. of Change Request implemented.

9.

CONFIGURATION AUDIT
The Configuration Audit procedures as stated in the OGCIO SCM guide would be
followed unless otherwise stated in this plan.
A Physical Configuration Audit would be conducted before implementing the
change into production.
Quality Assurance of implementation of this plan would be conducted by the
Configuration Auditor annually.

10.

CHANGE REQUEST FORM

A standard Change Request Form is attached at the end of this plan. Originator of
any change request should complete the form and submit to their Configuration
Management Officers (CMO) accordingly.

CHANGE REQUEST FORM

End User Ref. No.:
OGCIO Ref. No.:

To be filled by the requester

Requester Name:

Post:

Signature
Date:
Approved by:
Signature

Tel.:
Post:
Date:

Application System Name:

Application Sub-System Name:
Change Request Type :
Problem Report
Priority :
High
Medium
Low
Proposed Implementation Date:
Change Requested:

Enhancement

(use separate sheets if necessary)

Reason for the Change:

To be filled by Impact Analysis Group

Impact Analysis Result:

(use separate sheets if necessary)

SM
Estimation of human effort (Man-day):
Estimation of cost:
Remark:
Performed by:
Signature:
Approved by:
Signature:

API

APII

Estimated total adjusted function point:

Post:
Date:
Post:
Date:
Page 1 of 2

To be filled by Configuration Board

Disposition:
Reason/Comment :

Approved

Deferred to

End User Representative:

Signature:
OGCIO Representative:
Signature:

Rejected

Post:
Date:
Post:
Date:

To be filled by the implementor

Date of completion:
SM
Actual human effort spent(Man-day):
Actual cost spent:
Remark:

API

APII

Actual total adjusted function point:

Name:
Signature:

Post:
Date:
Page 2 of 2

--- End of Plan ---

Attachment 3
Sample Form of Report on Physical Configuration Audit

Report on Physical Configuration Audit

System
/Project

Phase

Reviewer
Product
ID

Product Name

FS
FS/SA&D
SA&D/Impl.
FS/SA&D/Impl.
Maintenance

Date
Latest version
recorded in Product
Movement Log?

All
components
existed?

Production Version
recorded in Product
Movement Log?

Attachment 4
Sample Form of Application Software Configuration Management Review
Report

Application Software Configuration Management Review Report

System / Project

Reviewer

Phase

1. Configuration Identification
1.1 Have the products been identified to come under Software
Configuration Management (SCM) and documented in the Plan?
1.2 Have the points of baseline of each product under SCM been
defined?
1.3 Has the product naming convention been set up?
1.4 Has the version numbering system been established?
2. Configuration Control
2.1 Has the SCM Library been set up and secured?
2.2 Have the Check In and Check Out procedures been
implemented?
2.3 Has the Change Control procedure been carried out?
3. Configuration Status Accounting
3.1 Has the Change Status Report(s) been compiled?
3.2 Has the Product Status Report(s) been compiled?
4. Configuration Audit
4.1 Has the Physical Configuration Audit been performed?

FS
FS/SA&D
SA&D/Impl.
FS/SA&D/Impl.
Maintenance

Date
Y/N

With reference to the Application Software Configuration Management

Plan endorsed at the beginning of the phase :

Notes