Template for IDA Project (Project Id) Template for specific development (Contract Id)

Change Control Procedure

Issue 1

Change Control Procedure IDA-MS-CCP Issue 1

Page ii

TABLE OF CONTENTS

0 PREFACE.............................................................................................................................1 0.1 Purpose of this document............................................................................................1 0.2 Use of this document...................................................................................................1 0.3 Purpose of configuration management......................................................................2 1 IN R!"UC I!N.................................................................................................................# 1.1 Purpose..........................................................................................................................# 1.2 !$er$ie%........................................................................................................................# 1.3 "efinitions.....................................................................................................................# 1.# Acron&ms.......................................................................................................................' 2 (!F )ARE C*AN+E C!N R!,..................................................................................2.1 "iagnose Pro./em.........................................................................................................2.1.1 Identification of the Pro./em....................................................................................2.1.2 In$estigation...............................................................................................................2.1.3 Re$ie% in$estigation resu/ts.....................................................................................2.2 0a1e changes................................................................................................................2 2.3 (oft%are Configuration Contro/.................................................................................2 2.3.2 Fi3...............................................................................................................................2 2.3.3 est..............................................................................................................................2 2.# Re/ease change..............................................................................................................2 3 "!CU0EN C*AN+E C!N R!,.................................................................................4 3.1 Identif& Need for "ocument to .e Changed..............................................................4 3.1.1 Identification of the enhancement...........................................................................4 3.1.2 In$estigation...............................................................................................................4 3.2 Change document.........................................................................................................4 3.2.2 Update........................................................................................................................5 3.2.3 Re$ie%........................................................................................................................5 3.3 Re/ease change..............................................................................................................5 # C!N RAC UA, C*AN+E C!N R!,........................................................................10 A PR!6,E0 REP!R F!R0..........................................................................................11 6 RE,EA(E N! E..............................................................................................................12 C C*AN+E C!N R!, F!R0.........................................................................................13 "!CU0EN C!N R!,....................................................................................................1# "!CU0EN (I+N!FF......................................................................................................1# "!CU0EN C*AN+E REC!R"....................................................................................1#

Change Control Procedure IDA-MS-CCP Issue 1

Page 1

0
0.1 #1

PREFACE
PURPOSE OF THIS DOCUMENT This document is a generic Change Control Procedure document for use by IDA Projects. It provides guidance and template material hich is intended to assist the relevant management or technical staff! hether client or supplier! in producing a project" specific Change Control Procedure document. It is also useful bac#ground reading for anyone involved in developing or monitoring the IDA $anagement %ystem &IDA" $%'. USE OF THIS DOCUMENT This Preface is addressed to the users of this generic document and is not meant to be retained in any project" specific Change Control Procedure documents based on it. The remaining sections &numbered 1! (! )!*' constitute a template that should be used to construct the project"specific Change Control Procedure document. Te+t in normal case is in the most part ,boilerplate- that can be retained! amended or deleted in the document. Te+t in italics provides instructions on ho to complete a section and should be removed once the section is ritten.

0.2 #1 #(

#)

The template should be used pragmatically! that is " here a section is not relevant it should be omitted. Conversely! the material contained in this document is not necessarily e+haustive. if there is a subject that is relevant to the IDA Project! but is not included in this document! it should still be included. This document has been prepared using $% 0ord 12. The follo ing variables are currently recorded as 3ile ,Properties- under $% 0ord. They may be modified by that means or over ritten directly at each occurrence in the document! at the discretion of the user. a. Summary Properties Title Type o document !i.e. Change Control Procedure" Author Author!s" o document #ey$ords Document re erence !i.e. IDA-MS-CCP" %. Custom Properties Pro& Id Short mnemonic o IDA Pro&ect !set' in this document' to Pro&ect Id" Pro&ect (ull name o IDA Pro&ect !set' in this document' to Template or IDA Pro&ect" Contr Id Short identi ier o contract !set' in this document' to Contract Id" Contract (ull name o contract !set' in this document' to Template or speci ic de)elopment" *ersion Issue num%er !currently Issue 1" Date Date o document !currently 1+ ,anuary -..1"

#/

Change Control Procedure IDA-MS-CCP Issue 1

Page -

0.3 #1

PURPOSE OF CONFIGURATION MANAGEMENT Change Control is the process of handling proposed alterations to items that have been previously designated as fi+ed. This means that an item only becomes subject to change control once it has been signed"off! stored in a baseline and placed under configuration control. The aim of change control is to ensure that if a signed"off item is changed then a. b. c. all sta#eholders have an opportunity to participate in the control of any subse4uent changes all recipients are made a are of any changes that occur there is an audit trail hich connects a change to a configuration item to the reason for its change! and hich records the participation and authorisation of those people concerned ith the change. level of authority re4uired to change each Configuration Item &CI'. methods for handling proposals for changing any CI.

#(

Proper change control re4uires definition of the5 a. b.

#)

As a configuration item passes through unit! integration! system and acceptance tests! a higher level of authority is needed to approve changes. This is called the promotion of a CI. 6ust as programmers sign off unit tests! team leaders sign off integration tests! and project leaders sign off system tests! so change approval demands a level of authority corresponding to the status of the CI. Changes occur naturally in the evolution of the soft are system. This evolution should be planned and implemented using controlled libraries of soft are and documentation. Changes can also occur because of problems in development or operation. %uch changes re4uire bac#trac#ing through the life cycle to ensure that the corrections are carried out at the appropriate level &e.g. system design or module design'! and ith the same degree of 4uality control as as used for the original development. The level of authority for each change depends on the part to be changed! and on the phase in the lifecycle that has been reached. Change control! hether it be for soft are! documentation or contractual matters! typically follo s the follo ing generic process5 a. b. c. d. e. identify reason for change investigate impact 8 configuration items to be changed! costs! timescales! ris#s revie change 8 accept or reject ma#e changes as agreed! and update configuration status release changes.

#/

#7

#9

:evie of changes is normally underta#en by a nominated Change :evie ;oard &C:;'. This has the authority to accept or reject the change. <ote! ho ever! that its responsibilities should be ider than revie ing individual changes in isolation. It needs to ta#e a broader and longer term vie of a system and assess! for e+ample a. hether the number and e+tent of proposed changes indicate that re4uirements are changing! and the current system is unli#ely to meet future re4uirements cost"effectively! and

Change Control Procedure IDA-MS-CCP Issue 1

Page /

b. #2

hether a group of lo "level soft are changes can be more cost"effectively implemented through a re" rite of a higher" level module. or are symptomatic of a fault in the design! hich should be rectified by re" design and re" rite. or can be delayed for more cost"effective implementation ithin a batch containing additional future changes.

This document contains procedures for three types of change control5 a. b. c. soft are change control document change control contractual change control.

#=

The underlying philosophy is the same! ho ever the forms used! and the details of the procedures vary! so they are described separately.

Change Control Procedure IDA-MS-CCP Issue 1

Page 0

1
1.1 11 1.2 11

INTRODUCTION
PURPOSE This procedure de ines ho$ change control is handled in >Project Id?. OVERVIEW There are three types o change control 2 so t$are change control document change control contract change control.

11.3 11

The underlying philosophy is the same' ho$e)er the orms and the details o the procedures )aries so they are descri%ed separately. DEFINITIONS Change Control is the process o handling proposed alterations to items that ha)e %een pre)iously designated as i3ed. This means that an item only %ecomes su%&ect to change control once it has %een signed-o ' stored in a %aseline and placed under con iguration control. The aim o change control is to ensure that i a signed-o item is changed then 1. all sta4eholders ha)e an opportunity to participate in the control o any su%se5uent changes -. all recipients are made a$are o any changes that occur /. there is an audit trail $hich connects a change to a con iguration item to the reason or its change' and $hich records the participation and authorisation o those people concerned $ith the change.

1-

Proper change control re5uires de inition o the2 a. le)el o authority re5uired to change each Con iguration Item !CI"6 -. methods or handling proposals or changing any CI.

1/

As a con iguration item passes through unit' integration' system and acceptance tests' a higher le)el o authority is needed to appro)e changes. This is called the promotion o a CI. ,ust as programmers sign o unit tests' team leaders sign o integration tests' and pro&ect leaders sign o system tests' so change appro)al demands a le)el o authority corresponding to the status o the CI.

Change Control Procedure IDA-MS-CCP Issue 1

Page 7

10

Changes occur naturally in the e)olution o the so t$are system. This e)olution should %e planned and implemented using controlled li%raries o so t$are and documentation. Changes can also occur %ecause o pro%lems in de)elopment or operation. Such changes re5uire %ac4trac4ing through the li e cycle to ensure that the corrections are carried out at the appropriate le)el !e.g. system design or module design"' and $ith the same degree o 5uality control as $as used or the original de)elopment. The le)el o authority or each change depends on the part to %e changed' and on the phase in the li ecycle that has %een reached. ACRONYMS CI Con iguration Item

1.4

Change Control Procedure IDA-MS-CCP Issue 1

Page 8

2
#1 #(

SOFTWARE CHANGE CONTROL

This section of this procedure applies to soft are that has been placed under configuration management. %oft are problems can be reported at any stage in the lifecycle. Problems can fall into a number of categories according to the degree of regression in the life cycle " i.e. ho far bac# you need to go to fi+ the problem. Problem categories include5 operations error. user documentation does not conform to code. code does not conform to design. design does not conform to re4uirements. ne or changed re4uirements.

#) 2.1

%election of the problem category defines the phase of the lifecycle at hich corrective action needs to start. DIAGNOSE PROBLEM

2.1.1 Iden !"!#$ !%n %" &e P'%()e* 11 I a discrepancy %et$een desired and actual %eha)iour is identi ied !this co)ers %oth %ugs and modi ication re5uests" then Section A o a Pro%lem 9eport (orm !see Appendi3 A" should %e completed. The Pro%lem 9eport (orm should %e gi)en a uni5ue re erence. The orm should %e passed to the indi)idual responsi%le or the con iguration management o the so t$are !e.g. Maintenance Manager' pro&ect Technical Architect 4no$n as the Controller". That indi)idual should maintain a ile o all such orms recei)ed' and place a copy o the orm into that ile. The indi)idual should then arrange or a re)ie$ o the issue on the orm' this may %e a %ug that needs a i3 or an enhancement that is %eing proposed.

1-

1/

2.1.2 In+e, !-$ !%n 11 The in)estigation may %e per ormed %y the Controller' or any other suita%ly 4no$ledgea%le indi)idual. The in)estigator should record the results o the in)estigation in Section : o the Pro%lem 9eport (orm. The suggested action can include no action.

2.1.3 Re+!e. !n+e, !-$ !%n 'e,/) , 11 All parties $ith a legitimate interest in the so t$are should re)ie$ the results o the in)estigation. They may %e ormally constituted into a So t$are Change 9e)ie$ :oard !SC9:". The 9e)ie$ers should indicate $hether the recommended action arising rom the in)estigation should %e implemented or re&ected. I the recommendations are re&ected then the Controller should ile the completed Pro%lem 9eport (orm or uture re erence.

1-

Change Control Procedure IDA-MS-CCP Issue 1

Page +

1/ 2.2 11

I the recommendations are accepted and a decision is made to implement then the process mo)es on to the ne3t stage ; Ma4e changes. MA0E CHANGES The i3 may )ary rom a simple change to one so t$are module to e3tensi)e changes to design' documentation and code. In all cases' the changes need to %e tied %ac4 to the authorised Pro%lem 9eport (orm. SOFTWARE CONFIGURATION CONTROL The Controller should log and ile the Pro%lem 9eport (orm. The (i3 should %e allocated to de)elopers and scheduled.

2.3 11

2.3.2 F!1 11 1The so t$are should %e i3ed in line $ith the recommendations on the Pro%lem 9eport (orm. The ne$ )ersion o the so t$are should %e stored as a separate )ersion in the con iguration management !CM" li%rary that holds the so t$are. The change to the code should %e identi ied in the rele)ant code headers' and also in any a)aila%le comment ields in the CM li%rary.

2.3.3 Te, 11 Test and )eri ication acti)ities should match the e3tent o the changes. All code should %e tested' %ut i there are design and documentation changes then these should also %e re)ie$ed' and %e su%&ect to similar 5uality control measures as or a original de)elopment. The impact o the changes on other areas o the system should %e assessed' and i the ris4 o introducing ne$ pro%lems is signi icant' then regression tests should %e run. RELEASE CHANGE Completed changes $ill %e incorporated into a ne$ release o the so t$are. The release may include other changes as $ell' or may &ust include the changes re5uired %y the one Pro%lem 9eport (orm. The release is trac4ed on the 9elease <ote !see Appendi3 :" using a uni5ue release num%er. The Controller schedules the i3 so that it is included in a controlled release o the re)ised system. This may %e a matter o hours i the i3 is an urgent %ug- i3 to 4eep the system running' or it may not occur or a num%er o $ee4s. The release may %e per ormed %y the Controller or another de)eloper !4no$n as the 9eleaser". The 9eleaser should record all release details on the 9elease <ote. The release num%er should also %e recorded on the original Pro%lem 9eport (orm. The 9eleaser arranges or the i3 to %e deli)ered and installed. =nce the client has e3pressed satis action a%out the correctness o the i3' the releaser signs the 9elease <ote and iles it.

2.4 11

11/

10

17

Change Control Procedure IDA-MS-CCP Issue 1

Page >

3
#1 #(

DOCUMENT CHANGE CONTROL

This section applies to documents that have been placed under configuration management. Document Change Control is very similar to %oft are Change Control. indeed changes to documents are sometimes triggered by a Problem :eport 3orm. @o ever! the follo ing procedure is based upon use of a Change Control 3orm &see Appendi+ C'. In general a Problem :eport 3orm is used to record problems! hile a Change Control 3orm is used to record proposed enhancements. As both lead to changes! in many situations the t o forms are interchangeable. IDENTIFY NEED FOR DOCUMENT TO BE CHANGED

3.1

3.1.1 Iden !"!#$ !%n %" &e en&$n#e*en 11 I an enhancement to a document !e.g. a change re5uired to a unctional speci ication" is identi ied then Section A o a Change Control (orm should %e completed. The Change Control (orm should %e gi)en a uni5ue re erence. The orm should %e passed to the indi)idual responsi%le or the con iguration management o the document !eg Author' pro&ect Technical Architect" 4no$n as the Controller. That indi)idual should maintain a ile o all such orms recei)ed' and place a copy o the orm into that ile. The indi)idual should then arrange or a re)ie$ o the issue on the orm' this may %e an error that needs correction or an enhancement that is %eing proposed.

1-

1/

3.1.2 In+e, !-$ !%n 11 The in)estigation may %e per ormed %y the Controller' or any other suita%ly 4no$ledgea%le indi)idual. The in)estigator should record the results o the in)estigation in Section : o the Change Control (orm. The suggested action can include no action. Reviewers of the Investigation Results

3.1.2.1 11

All parties $ith a legitimate interest in the document should re)ie$ the results o the in)estigation. They may %e ormally constituted into a Change 9e)ie$ :oard !C9:"' or may more in ormally consist o designated representati)es rom pro&ect sta4eholders. The 9e)ie$ers should indicate $hether the recommended action arising rom the in)estigation should %e implemented or re&ected. I the recommendations are re&ected then the Controller should ile the completed Change Control (orm or uture re erence. I the recommendations are accepted and a decision is made to implement the change then the process mo)es on to the ne3t stage2 Change document. CHANGE DOCUMENT The amendment to the document is trac4ed on the Change Control (orm.

11/ 3.2 11

Change Control Procedure IDA-MS-CCP Issue 1

Page ?

3.2.2 U2d$ e 11 1The Author should re)ie$ the Change Control (orm' and apply the change re5uested. The ne$ )ersion o the document should %e stored as a separate )ersion in the con iguration management !CM" li%rary that holds the documents. The change to the document should %e identi ied in the change history o the document' and %y mar4ingup the te3t.

3.2.3 Re+!e. 11 The author should dou%le-chec4 that the change has %een applied consistently and correctly to all rele)ant documents' %ut $here %ene icial a separate indi)idual !4no$n as the 9e)ie$er" should also chec4 the ne$ )ersion o the document. I it appears that the impact o the change on the system could %e signi icant' ull re)ie$ o all other related documentation should %e done. The re)ie$er completes the Change Control (orm and signs it o $hen the re)ie$ is complete. RELEASE CHANGE The Controller schedules the change so that it is included in a controlled release o the re)ised document. This may %e a matter o hours i the change is urgent and needed to 4eep the pro&ect running to schedule' or it may not occur or a num%er o $ee4s. The release is recorded on the Change Control (orm. The release may %e per ormed %y the controller or the pro&ect manager !4no$n as the 9eleaser". The 9eleaser should record all release details on the Change Control (orm. The 9eleaser arranges or the ne$ )ersion o the document to %e deli)ered to all its readers. The 9eleaser then signs the Change Control (orm to indicate the change is complete.

13.3 11

11/ 10 17

Change Control Procedure IDA-MS-CCP Issue 1

Page 1.

4
#1

CONTRACTUAL CHANGE CONTROL

Change control procedures may be included in contracts ith suppliers. They should describe the processes for identifying reasons for change investigating impact 8 configuration items to be changed! costs! timescales! ris#s revie ing change 8 accept or reject.

#(

<ote that the role of the Change :evie ;oard &C:;' or its e4uivalent &represents of both parties to the contract ho have sufficient authorisation to ma#e contractual changes' is a crucial one5 agreed changes ill be contractually binding on both parties. 0ording for a change control procedure for inclusion in a contract should be carefully chec#ed. The approval of the Aegal %ervice should be sought. The process for change control and configuration management of the contract document itself should be similar to that for documents described in %ection ( above.

#) #/

Change Control Procedure IDA-MS-CCP Issue 1

Page 11

PROBLEM REPORT FORM

Problem Report orm

!ection A
Project / System ocation of Pro!lem 'nvironment (etails Pro!lem (etails
Inclu#e in#ication of im%ortance + any B/,!ne,, De$d)!ne, Give System Name P'%()e* Re"e'en#e N/*(e' Give "o#ule$ Screen or Re%ort name System &ersion Num!er Give #etails such as )%erating System / "achine / )ffice / *ity / *ountry Give #etails such as S%ecification that #efines how the system shoul# o%erate$ Ste%.!y.ste% #escri%tion of what ha%%ene# an# how to re%ro#uce the %ro!lem$ ocation of any su%%orting evi#ence /eg re%ort$ screen %rint$ log file0.

Pro!lem (ate
*ritical ,igh "e#ium ow

1ic2 if *ontinue# )verleaf Give (ate Pro!lem Raise# Give Name$ )rganisation$ an# *ontact Num!er

Person Raising Pro!lem

!ection "
Investigator of Pro!lem Investigation )utcome Suggeste# Priority
*ritical / ,igh / "e#ium / ow Print Name Suggeste# 3ction an# #etails of other items affecte#

Give Sche#ule for Resolution

Release Num!er Signoff Reviewer Project "anager

H%. % U,e &!, F%'* Problem Raiser com%letes 3 !o4es in !ection A an# %asses to Project "anager. Project #anager arranges investigation of %ro!lem$ #e%en#ing on outcome %ro!lem is rejecte#$ or given a %riority$ an# sometimes a cost. Project "anager com%letes !ection ". 5orm is then retaine# in %roject files.

Signature

(ate

Change Control Procedure IDA-MS-CCP Issue 1

Page 1-

RELEASE NOTE

Release $ote
!ection A
Project / System Pro!lem Reference Num!ers *hanges in Release
System Name ist all %ro!lem reference num!ers resolve# !y this Release (escri!e changes in this release

Items 6eing *hange#

ist ALL items !eing change#

1ic2 if *ontinue# )verleaf

Installation Instructions

Give as much #etail as %ossi!le or cross reference relevant #ocuments

1ic2 if *ontinue# )verleaf

!ection "
3ttachments Source *o#e 6uil# Scri%ts Release Reference Signoff Releaser Project "anager '4ecuta!les (ata (ocumentation 7%#ates
Give reference num!er an# / or #ate for release to customer

Signature
1o in#icate release is com%lete 1o in#icate release has !een fully reviewe#

H%. % U,e &!, F%'* Person #a%ing Release com%letes 3 !o4es in !ection A an# %asses to Project "anager. Project #anager reviews release %ac2 an# com%letes !ection ". 5orm is then retaine# in %roject files

Change Control Procedure IDA-MS-CCP Issue 1

Page 1/

CHANGE CONTROL FORM

Change Control orm

!ection A
Project *ontrolle# Item I#entification of 3s%ect to !e *hange *hange (etails
Inclu#e in#ication of im%ortance an# urgency 1ic2 if *ontinue# )verleaf 5or (ocument give section num!er / %age num!er 5or Software give "o#ule$ Screen or Re%ort name *hange Num!er Item &ersion

Re8uester of *hange
Print Name

(ate Raise#

!ection "
Investigator of *hange Im%act$
give #etails of other items affecte#

Investigation )utcome
Reject / 3ction at No *ost / 3ction at *ost

Suggeste# Priority
,igh / "e#ium / ow

(ate Investigate#

!ection C
Im%lementor
(ate Sche#ule#

!ection D
*hange Im%lemente# Im%lementator Project "anager
H%. % U,e &!, F%'* Change Re&uester com%letes 3 !o4es in !ection A an# %asses to Project "anager. Project #anager arranges investigation of re8uest$ #e%en#ing on outcome re8uest is rejecte#$ or given a %riority an# cost$ an# with investigator com%letes !ection " ' C$ form is then retaine# in %roject files. )nce change is im%lemente# !ection D is signe#.off.

Signature

(ate

Change Control Procedure IDA-MS-CCP Issue 1

Page 10

DOCUMENT CONTROL
it/e7 Issue7 "ate7 Author7 "istri.ution7 Reference7 Fi/ename7 Contro/7 Change Control Procedure Issue 1 1+ ,anuary -..1 Mar4 Pillatt @C DA @nterprise ; Aa)ino Murgia Pro&ect Team IDA-MS-CCP --11+/?.8.doc 9eissue as complete document only

DOCUMENT SIGNOFF
Nature of (ignoff Author 9e)ie$er Person Mar4 Pillatt ,ohn :rin4$orth (ignature "ate Ro/e Senior Consultant Pro&ect Controller

DOCUMENT CHANGE RECORD

"ate .> Decem%er -... 10 Decem%er -... 8ersion Issue 1 Dra t 1 Issue 1 Dra t Author Mar4 Pillatt Mar4 Pillatt Change "etai/s Initial Dra t Bpdate ollo$ing ,ohn :rin4$orth re)ie$ comments 9e- ormatting Add Introduction and issue

17 ,anuary -..1 1+ ,anuary -..1

Issue 1 Dra t / Issue 1

Sue Turner Mar4 Pillatt