8/10/2019 g46_pub

1/59

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

8/10/2019 g46_pub

2/59

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 generallycopy 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 o

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.

8/10/2019 g46_pub

3/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE CONTENTS

_________________________________________________________________________________________

________________________________________________________________________________________

TABLE OF CONTENTS

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

2.

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

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

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

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

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

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

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

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

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

5.2

CONTROL............................................................................ ................................................................. ......... 5-25.3 STATUS ACCOUNTING................................................................... ................................................................ 5-4

5.4 AUDIT.......................................................... ................................................................... .............................. 5-4

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

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

6.2 CONFIGURATION MANAGEMENT OFFICER (CMO) ......................... ............................................................... 6-1

6.3 CONFIGURATION LIBRARIAN (CL) ................................................................................................................. 6-2

6.4 CONFIGURATION AUDITOR (CA) ..................................................................................... .............................. 6-2

6.5 IMPACT ANALYSIS GROUP (IAG) .................................................................................... .............................. 6-2

6.6 SCMIN DEVELOPMENT PHASE................................................................ ..................................................... 6-3

6.7 SCMINMAINTENANCE PHASE................................................................. ..................................................... 6-3

7.

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

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

7.1.1 Selection ........................................................................ ................................................................. ......... 7-1

7.1.2 Designation ............................................................................. ................................................................ 7-2

7.1.3 Description ........................................................ .................................................................... .................. 7-3

7.2 PLANNING........................................................................... ................................................................. ......... 7-6

7.3 CONTROL............................................................................ ................................................................. ......... 7-7

7.3.1 Physical Control ............................................................ ................................................................... ....... 7-7

7.3.2 Check In Procedure ................................................................. ................................................................ 7-8

7.3.3 Check Out Procedure ........................................ ................................................................. ..................... 7-9

7.3.4 Change Control ............................................................. ................................................................... ..... 7-10

7.3.5 Assembly of High Level Product ............................................................................... ............................ 7-12

7.3.6

Control of Variants .................................................................. .............................................................. 7-13

7.3.7

Control of contractors Work................................................... ............................................................. 7-14

7.3.8 Database Administration .......................................................... ............................................................. 7-15

7.4 STATUSACCOUNTING ............................................................. ............................................................. 7-16

7.4.1 Product Status Reporting ......................................................... ............................................................. 7-16

7.4.2 Change Status Reporting .......................................................... ............................................................. 7-17

7.5 AUDIT.......................................................... ................................................................... ............................ 7-18

7.5.1 Physical Configuration Audit ............................................................... ................................................. 7-18

7.5.2 Quality Assurance of SCM Activities .............................................................. ....................................... 7-19

7.6 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 AuditAttachment 4 : Sample Form of Application Software Configuration Management Review Report

8/10/2019 g46_pub

4/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE PURPOSE

_________________________________________________________________________________________

________________________________________________________________________________________

1-1

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.

8/10/2019 g46_pub

5/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCOPE

_________________________________________________________________________________________

________________________________________________________________________________________

2-1

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 alsodescribes 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.

8/10/2019 g46_pub

6/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE REFERENCES

_________________________________________________________________________________________

________________________________________________________________________________________

3-1

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 ceasedto 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.

8/10/2019 g46_pub

7/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE DEFINITIONS AND CONVENTIONS

_________________________________________________________________________________________

________________________________________________________________________________________

4-1

4. DEFINITIONS AND CONVENTIONS

4.1 DEFINITIONS

None.

4.2 CONVENTIONS

The following acronyms are used in the text of this guide :

BAC Business Assurance Coordinator

CA Configuration Auditor

CB Configuration Board

CL Configuration Librarian

CMO Configuration Management OfficerIAG Impact Analysis Group

PAT Project Assurance Team

PCA Physical Configuration Audit

PID Project Initiation Document

PRINCE PRojects IN Controlled Environments

PSC Project Steering Committee

SCM Software Configuration Management

SDLC System Development Life Cycle

8/10/2019 g46_pub

8/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM CONCEPTS

_________________________________________________________________________________________

________________________________________________________________________________________

5-1

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 :

Identificationof the components that make up the software system and that define its

functional characteristics;

Controlof changes to those components;

Status Accounting of the processing of change requests and, for approved requests,

their implementation status;

Auditon 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.

1 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.

8/10/2019 g46_pub

9/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM CONCEPTS

_________________________________________________________________________________________

________________________________________________________________________________________

5-2

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 theConfiguration 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.

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

2 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 SC M Library

earlier and periodically to safeguard the investment.

Time

Stability

Version Control Version Control &

Change Control

BaselineCheck-in for tracking

of changes

Start

Under

Development

Product

Development

8/10/2019 g46_pub

10/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM CONCEPTS

_________________________________________________________________________________________

________________________________________________________________________________________

5-3

the product3. 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 newversion 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 inthrough CL (See

section 7.3.2), who will log the movement in a Product Movement Log (See section 7.1.3.2).However, read-accessto 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/maintenanceof other products.

In case a baselined product is modified, it should always become a new baseline when

Check In to the SCM Library.

3 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 andsubject to version control at the beginning of the project.

8/10/2019 g46_pub

11/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM CONCEPTS

_________________________________________________________________________________________

________________________________________________________________________________________

5-4

High level product

High level products can be assembledfrom 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 onlyupon 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 Reportswill 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 relevantChange 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.

8/10/2019 g46_pub

12/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM ROLES & RESPONSIBILITIES

_________________________________________________________________________________________

________________________________________________________________________________________

6-1

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 SCMLibrary 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.

8/10/2019 g46_pub

13/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM ROLES & RESPONSIBILITIES

_________________________________________________________________________________________

________________________________________________________________________________________

6-2

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 Assisting the CMO to assure the proper executing of the SCM

Plan.

Tasks 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.

8/10/2019 g46_pub

14/59

SCM PROCESS GUIDE FOR APPLICATION SOFTWARE SCM ROLES & RESPONSIBILITIES

_________________________________________________________________________________________

________________________________________________________________________________________

6-3

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 Roles in a PRINCE Project

Configuration Board PSC

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.

Configuration Management Officer PM

Configuration Librarian A senior member of the project team assigned by

Project Manager.

Configuration Auditor A senior member of the project team assigned by

Project Manager.

Impact Analysis Group PAT and Project Manager

6.7

SCM IN MAINTENANCE PHASE

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

8/10/2019 g46_pub

15/59

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 selectingproducts 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.

8/10/2019 g46_pub

16/59

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 4thversion of the 2nd

release.

Example 3: Version Number 1997/13 of a product means that it is in the 13thversion since

1997.

This Version Number should be stated explicitly at location according to the type of product:

Type Location

Document Front Page and Footer. For details please refer to Standards &

Methods Document Style Manual, OGCIO

Program Source Code 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.

8/10/2019 g46_pub

17/59

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 forexclusive 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 iscreated.

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

8/10/2019 g46_pub

18/59

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.

8/10/2019 g46_pub

19/59

An example of a Product Movement Log is shown below :

Product ID /

Name

Version

No.

Check In / Out

Officer

Check Out

Date(dd.mm.yyyy)

Check In

Date(dd.mm.yyyy)

Physical

location

& name

Change

Request

Ref.

No.

Baseline

(Y/N)?

Production

Version

(Y/N)?

T223 System

Specification1 XXXXXXX 12.2.1997 xxxxxxx

2 XXXXXXX 12.3.1997 13.3.1997 xxxxxxx

3 XXXXXXX 4.5.1997 7.5.1997 xxxxxxx Y

4 XXXXXXX 8.7.1997 9.7.1997 xxxxxxx 12 Y Y

T224 User

Requirement 1 XXXXXXX 2.2.1997xxxxxxx

2 XXXXXXX 11.3.1997 12.3.1997 xxxxxxx Y Y

T321/002 1 XXXXXXX 2.2.1998 xxxxxxx

2 XXXXXXX 11.3.1998 12.3.1998 xxxxxxx Y Y

3 XXXXXXX 4.5.1998 xxxxxxx

This low level product (program) is uniquely identified by the product ID of its parent

product T321 and an extension 002.

A modified

baseline should

always become

a new baseline

when Check

In to the SCMLibrary.

This indicates that the product has been

checked out but not yet checked in.

CL will baseline a product according to the Point ofBaseline stated in the SCM Product List.

When the product first checks in,there is no Check Out Date.

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

simply delete the latest record.

The Change Request Ref. No. should be

recorded for any change of baselined product

This version of program is the production version.

8/10/2019 g46_pub

20/59

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 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.

Configuration

Status

Accounting

Define the requirements and procedures for reporting status

on products and Change Requests.

Configuration

Audit 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.

8/10/2019 g46_pub

21/59

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 alsobe 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. allcomponents 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-copiedproducts 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.

8/10/2019 g46_pub

22/59

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 To centralise the processing of any in-flow of products.

To maintain a log of products modified.

Input New product / Modified product

Method The submission of the product should be accompanied by the following

information :

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 newcopy 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.

8/10/2019 g46_pub

23/59

7.3.3 Check Out Procedure

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

modification.

Objective To centralise retrieval process of products under SCM.

To maintain a log of products being modified.

Input Authorised Change Requests.

Method Each check out request should be accompanied by the following

information :

Product ID / Name

Name of staff to check out

Date of check out

The Change Request Form No(s) which leads to the current checkout 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.

8/10/2019 g46_pub

24/59

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 theChange 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

8/10/2019 g46_pub

25/59

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 berecorded 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.

8/10/2019 g46_pub

26/59

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 ahigh 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 therelease 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.

8/10/2019 g46_pub

27/59

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.

8/10/2019 g46_pub

28/59

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 acceptedproducts 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 contractor-

initiated 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.

8/10/2019 g46_pub

29/59

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 pre-

production 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.

8/10/2019 g46_pub

30/59

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 :

Extraction of Product Movement Log. Statistics of status of all products.

Other useful information of products.

Frequency 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)?

8/10/2019 g46_pub

31/59

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 :

List of Change Requests of various status.

Statistics of Change Requests of various status.

Other useful information of Change Requests.

Frequency 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.

8/10/2019 g46_pub

32/59

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 asthe 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.

8/10/2019 g46_pub

33/59

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.

8/10/2019 g46_pub

34/59

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.

I n 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)

I n case it is a hand-over

fr om SDLC to production fr om 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

8/10/2019 g46_pub

35/59

Attachment 1

Example of Application Software Configuration Management Plan for SDLC

projects

8/10/2019 g46_pub

36/59

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 identify the organization units that participate in the

project;

specify the allocation of activities/tasks to the

organizational units.

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 Define the procedures to be used for change control,

issuing and distributing copies of managed products.

Configuration

Status

Accounting

Define the requirements and procedures for reporting

status on products and changes.

ConfigurationAudit

Define how and when the correctness, integrity andcompleteness of products can be assured.

3. REFERENCES

Initial Request Statement of the project.

4.

DEFINITIONS AND CONVENTIONS

Adopted those defined in Software Configuration Management Process Guide

[G46].

8/10/2019 g46_pub

37/59

5. ROLE ASSIGNMENT

SCM Roles Assignment

Configuration Board (CB) 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

8/10/2019 g46_pub

38/59

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

FS SA&D Phy.

Design

Impl. Production

& systemnursing

Format of

Controlled Copy

M100 Project Initiation Document B MS Word

M210 Project Plan B MS Project

M220 Stage Plans V V V V V B MS Project

T110 FS Management Summary V B MS Word

T121 FS Current Environment

DescriptionV B MS Word

T122 Project Definition V B MS Word / OracleDesigner/2000

T210 SA&D Management Summar V B MS Word

T221 SA&D Current Environment

Description

V B MS Word

T222 User Requirement V V B MS Word / OracleDesigner/2000

T223 System Specification V B MS Word / OracleDesigner/2000

T224 Technical System Option V V B MS Word

T311 Data File Description V B MS Word / DataModel Repository

T312 Program Specification V B MS Word / OracleDesigner/2000

T321/ Program Source V B Text file / OracleDesigner/2000

T330/ System Test Plan, Spec and

ResultsV B MS Word / Data

Model Repository

T341/ Acceptance Test Plan, Spec

and ResultsV B MS Word / Data

Model RepositoryT351 System Manual V B MS Word

T352 Program Manual V B MS Word

T353 Data Manual V B MS Word

T354 Application Operation Manua V B MS Word

T355 Application User Manual V B MS Word

T356 Computer Operating

Procedures ManualV B MS Word

T400 Tender Specification B MS Word / Hard-copy

T600 Evaluation Report B MS Word

T700 Procurement Contract B MS Word / Hard-copy

M600 Project Evaluation Report B MS Word

Key :

V - check in for version control

B - baseline for change control

8/10/2019 g46_pub

39/59

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 2ndchange before baseline.1.0 1stbaseline.

1.3 3rdchange of the 1stbaseline, the working copy to be submitted to CL

for registration.

2.0 2ndbaseline.

7.2 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

8/10/2019 g46_pub

40/59

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 leftto 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.

assigned

approved

rejected

deferred

being implemented (if possible, status information of the implementation) implemented

7.3 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\C/M R R R

Project Plan (M210)

ITSFGH2\CM_DXX\PRJ_PLAN\C/M R R R

Stage Plan (M220)ITSFGH2\CM_DXX\STG_PLAN\

R R C/M R

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

C/M R R R

8/10/2019 g46_pub

41/59

Management Summary (T110)ITSFGH2\CM_DXX\FS_MS\

C/M R R R

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

R R C/M R

Project Definition (T122)ITSFGH2\CM_DXX\PRJ_DEF\

R R C/M R

System Analysis and Design Report (T200)

ITSFGH2\CM_DXX\SA&D_REP\

C/M R R R

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

C/M R R R

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

R R C/M R

User Requirement (T222)

ITSFGH2\CM_DXX\USER_REQ\R R C/M R

System Specification (T223)

ITSFGH2\CM_DXX\SYS_SPEC\R R C/M R

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

R R C/M R

Data File Description (T311)

ITSFGH2\CM_DXX\DATA_SPEC\

R R C/M R

Program Specification (T312)

ITSFGH2\CM_DXX\PRG_SPEC\R C/M R R

Program Module of Sub-system A

ITSFGH2\CM_DXXA\PROG\

ITSFGH2\CM_DXXA\DDL\

R C/M R R

Program Module of Sub-system B

ITSFGH2\CM_DXXB\PROG\

ITSFGH2\CM_DXXB\DDL\

R R C/M R

System Test Plan, Spec. & Result (T330)

ITSFGH2\CM_DXX\SYS_TEST\

R C/M R R

Acceptance Test Plan, Spec. & Result (T341)ITSFGH2\CM_DXX\ACC_TEST\

R C/M R R

System Manual (T351)

ITSFGH2\CM_DXX\SYS_MAN\

C/M R R R

Program Manual (T352)

ITSFGH2\CM_DXX\PRG_MAN\

R C/M R R

Data Manual (T353)

ITSFGH2\CM_DXX\DAT_MAN\

R C/M R R

Application Operation Manual (T354)

ITSFGH2\CM_DXX\AO_MAN\

R C/M R R

Application User Manual (T355)

ITSFGH2\CM_DXX\AU_MAN\

R C/M R R

Computer Operating Procedures Manual (T356)

ITSFGH2\CM_DXX\SYS_MAN\

R C/M R R

Tender Specification (T400)

ITSFGH2\CM_DXX\TDR_SPEC\C/M R R R

Evaluation Report (T600)

ITSFGH2\CM_DXX\TDR_EVAL\C/M R R R

Procurement Contract (T700)

ITSFGH2\CM_DXX\CONTRACT\C/M R R R

Project Evaluation Report (M600)

ITSFGH2\CM_DXX\PRJ_EVAL\C/M R R R

C : Create M: Modify R: Read

8/10/2019 g46_pub

42/59

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 SCMguide 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

8/10/2019 g46_pub

43/59

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.

8/10/2019 g46_pub

44/59

CHANGE REQUEST FORM

End User Ref. No.:

To be filled by the requester OGCIO Ref. No.:

Requester Name: Post:

Signature Tel.:

Date:

Approved by: Post:

Signature Date:

Application System Name:

Application Sub-System Name:

Change Request Type : Problem Report Enhancement

Priority : High Medium Low

Proposed Implementation Date:Change Requested: (use separate sheets if necessary)

Reason for the Change:

To be filled by IAG

Impact Analysis Result: (use separate sheets if necessary)

SM API APII

Estimation of human effort (Man-day):

Estimation of cost: Estimated total adjusted function point:

Remark:

Performed by: Post:

Signature: Date:

Approved by: Post:

Signature: Date:

Page 1 of 2

8/10/2019 g46_pub

45/59

To be filled by CB

Disposition: Approved Deferred to Rejected

Reason/Comment :

End User Representative: Post:

Signature: Date:

OGCIO Representative: Post:

Signature: Date:

To be filled by the implementor

Date of completion:

SM API APII

Actual human effort spent(Man-day):

Actual cost spent: Actual total adjusted function point:

Remark:

Name: Post:Signature: Date:

Page 2 of 2

--- End of Plan ---

8/10/2019 g46_pub

46/59

Attachment 2

Example of Application Software Configuration Management Plan For Systems

In Production

8/10/2019 g46_pub

47/59

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 identify the organization units that participate in

maintaining the system;

specify the allocation of activities/tasks to the

organizational units.

Configuration

Identification 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.

Configuration

Control

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.

Configuration

Status

Accounting

Define the requirements and procedures for record and

report the status of products.

Configuration

Audit

Define the procedures to ensure the correctness, integrity

and completeness of products.

3. REFERENCES

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

SCM Plan for SA&D of the XYZ System.

4.

DEFINITIONS AND CONVENTIONS

Adopted those defined in Software Configuration Management Process Guide

[G46].

8/10/2019 g46_pub

48/59

5. ROLE ASSIGNMENT

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

Assignment

SCM Roles Name Rank/Post Remark

Configuration Board(CB)

CHAN XXNG XX

SM(D)XXSEO 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 responsible for

sub-system B

TSE XX APII(D)XX responsible for both

sub-systems A & B

8/10/2019 g46_pub

49/59

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 Product Name Format of

Controlled Copy

T321 Program source of

Sub-system A

Text file / Oracle

Designer/2000

Program source of

Sub-system B

Text file / Oracle

Designer/2000

T330/ System Test Plan, Spec and Results MS Word / Data

Model Repository

T341/ Acceptance Test Plan, Spec and Results MS Word / Data

Model Repository

T351 System Manual MS Word

T352 Program Manual MS Word

T353 Data Manual MS Word

T354 Application Operation Manual MS Word

T355 Application User Manual MS Word

T356 Computer Operating Procedures Manual MS Word

8/10/2019 g46_pub

50/59

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 therequest 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.

8/10/2019 g46_pub

51/59

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

7.3 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\

R M - M M M R

Program Module of Sub-system B

ITSFGH2\CM_DXXB\PROG\

ITSFGH2\CM_DXXB\DDL\

R - M M M M R

System Test Plan, Spec. & Result (T330)

ITSFGH2\CM_DXX\SYS_TEST\

R M M - - - R

Acceptance Test Plan, Spec. & Result (T341)

ITSFGH2\CM_DXX\ACC_TEST\

R M M - - - R

System Manual (T351)ITSFGH2\CM_DXX\SYS_MAN\

R M M M R R R

Program Manual (T352)

ITSFGH2\CM_DXX\PRG_MAN\

R M M M R R R

Data Manual (T353)

ITSFGH2\CM_DXX\DAT_MAN\

R M M M R R R

Application Operation Manual (T354)

ITSFGH2\CM_DXX\AO_MAN\

R M M M M R R

Application User Manual (T355)

ITSFGH2\CM_DXX\AU_MAN\

R M M M M R R

Computer Operating Procedures Manual

(T356)ITSFGH2\CM_DXX\SYS_MAN\

R M M M R M R

SCM Plan

ITSFGH2\CM_DXX\SCMPLAN\

R R R R R R R

8/10/2019 g46_pub

52/59

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

8/10/2019 g46_pub

53/59

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.

8/10/2019 g46_pub

54/59

CHANGE REQUEST FORM

End User Ref. No.:

To be filled by the requester OGCIO Ref. No.:

Requester Name: Post:

Signature Tel.:

Date:

Approved by: Post:

Signature Date:

Application System Name:

Application Sub-System Name:

Change Request Type : Problem Report Enhancement

Priority : High Medium Low

Proposed Implementation Date:Change Requested: (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 API APII

Estimation of human effort (Man-day):

Estimation of cost: Estimated total adjusted function point:

Remark:

Performed by: Post:

Signature: Date:

Approved by: Post:

Signature: Date:

Page 1 of 2

8/10/2019 g46_pub

55/59

To be filled by Configuration Board

Disposition: Approved Deferred to Rejected

Reason/Comment :

End User Representative: Post:

Signature: Date:

OGCIO Representative: Post:

Signature: Date:

To be filled by the implementor

Date of completion:

SM API APII

Actual human effort spent(Man-day):

Actual cost spent: Actual total adjusted function point:

Remark:

Name: Post:Signature: Date:

Page 2 of 2

--- End of Plan ---

8/10/2019 g46_pub

56/59

Attachment 3

Sample Form of Report on Physical Configuration Audit

8/10/2019 g46_pub

57/59

Report on Physical Configuration Audit

System

/P