Fujitsu Services Post
FUJ00079902
FUJ00079902
Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Post Office Account Systems Integration Directorate
Incident/Defect Management
Procedure
N/A
This document describes the Post Office Account Systems
Integration Directorate Incident/Defect Management process
APPROVED
Lionel Higman BRAO1/FELO1 — SI
Contributors:
Internal Distribution: PVCS
External Distribution:
Approval Authorities:
Name Position Signature Date
Gill Jackson
Development Director
Alan D’ Alvarez
Test Director
Jan Holmes
Programme Assurance
Manager
© 2003 Fujitsu Services
Page: I of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
0.0 Document Control
0.1. Document History
‘VersionNo. IDate _I Reason for Issue I Associated
1.0 25/10/00 APPROVED N/A
il 28/02/03 Draft for Review NA
12 28/08/2003 Updated as a result of process failures in the delivery of I N/A
$40
2.0 05/09/2003 APPROVED N/A
0.2 Review Details
Review Comments by : 05 September 2003
Review Comments to : Lionel Higman
“Mandatory Review Authority ‘Name I
ITU PIT Manager Jim Stanton
ITU Release Manager Pete Dreweatt
Host Development Manager Nick Lawman
Counter Development Manager Mark Scardifield
Agent Development Manager Peter Ambrose
ITU Test Designer Janusz Holender
ITU S&VI Manager Debbie Richardson
: Optional Review / Issued for Information
SI Director Peter Jeram
CS Release Manager Sheila Bamber
CS SSC manager Mik Peach
Development Director Gill Jackson
Development Manager Mark Taylor
ITU Director Alan D’Alvarez
SI Programme Assurance Manager Jan Holmes
( * ) = Reviewers that returned comments
© 2003 Fujitsu Services Page: 2 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
0.3 Associated Documents
Reference Version I Date Title Source
CM/MAN/005 PinICL Reference Data Guide PVCS
CM/MAN/009 PinICL Training Manual PVCS
CM/PRD/001 Software Configuration I PVCS
Management Version control
process
CM/PRD/003 Work Package Request Process PVCS.
CS/FSP/006 End to End Support Process, I PVCS
Operational Level Agreement
CS/PRD/074 CS Incident Management Process I PVCS
DE/PRO/003 Post Office Account System I PVCS
Integration Lifecycle Processes
DE/PRO/O16 Post Office Account I PVCS
Development Directorate
Problem Management Process
PA/PRO/O01 Change Management Process PVCS
PA/TEM/001 8.0 23 December I Fujitsu Services Document PVCS
2002 Template
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 Abbreviations/Definitions
Abbreviation — Definition L
Call The term used by the PinICL system to reference the Incidents recorded therein
(commonly known as PinICLs).
Call Logger The originator of an Incident.
ccD Contract Controlled Documents
CCN Change Control Note
CM Configuration Management
oP Change Proposal
CR Change Request
cs Customer Service - A Directorate within Post Office Account
cT Commercial Terms.
Defect A record of an agreed difference between designed and actual behaviour of a Post
Office Account Product or Service captured in the PinICL System
DM Development Unit Manager
DU Development Unit - Development Directorate organisational unit responsible for
developing products
© 2003 Fujitsu Services
Page: 3 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Fix A correction to a Defect.
HSH Horizon System Help Desk
Incident A record of an observed possible difference between expected and actual
behaviour of a Post Office Account Product or Service captured in the PinICL
System
IsD Infrastructure Services Division
ITU Post Office Account Integration & Test Unit
KEL Known Error Log
LST Live Support Test team
Morning Prayers
A meeting held daily within SI to manage and monitor progress within SI. It is
chaired by a member of ITU.
PinICL A Fujitsu Services system used by Post Office Account for Incident/Defect
Management.
PIT Product Integration Team
PPD Process and Procedure Description
PIT Post Office Account Technical Integration
PVCS A proprietary Configuration Management system.
QFP Quality Filter Process
QEPF Quality Filter Process Forum
RASD Requirements, Architecture & Systems Design
RMF Release Management Forum
SMC System Maintenance Centre
SPTS. Service Provision and Technical Support
SSC System Support Centre
Stack A commonly used misnomer for the summary list of Calls currently assigned to a
specific Team in the PinICL system
WP Work Package
0.5 Changes in this Version
‘Version
Changes
2.0
Minor changes in response to comments on version 1.2
0.6 Changes Expected
Changes
None
© 2003 Fujitsu Services
Page: 4 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
0.7. Table of Contents
10 INTRODUCTION...
2.0 SCOPE...
3.0 INCIDENT/DEFECT MANAGEMENT PROCESS ..
3.1 OVERVIEW ...
1.1 Process Flow
2 Process description
4.0 I PROCESS COMPONENTS...
41 INCIDENT CAPTURE
4.1.1 Process Flow...
4.1.2 Process Descriptiot
4.2 QUALITY FILTER PROCES
4.2.1 Process FloW.........5
4.2.2 Process description ...
Quality Filter Process — Incident Analysis.
we
ad
Process flow
4.23.2 Process description... o.cccsnnneennen
4.2.4 — Quality Filter Process - Change Management
4241 Process flow.
4.2.4.2 Process description.....c.sccsnecseenne
4.2.5 Quality Filter Process - Solution Components.
4.2.5.1 Process Flow,
4.2.5.2 Process description.......
43 INCIDENT CLOSURE
4.3.1 Process Flow..
43.) Process description
44 TARGET RELEASE A
4.4.1 Process Flow
44.2 Process Description.
45 DEFECT RESOLUTION
4.5.1 Process Flow
4.5.2 Process description
4.6 DEFECT TEST AND CLOSURE
4.6.1 Process Flow...
4.6.2 Process description
© 2003 Fujitsu Services Page: 5 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
1.0 Introduction
This document describes the Post Office Account Systems Integration Directorate Incident/Defect Management
process, which has been decomposed identifying the following Sub Processes:
e — Incident Capture
© — Quality Filter Process
o Incident Analysis
© Change Management Actions
o Solution Components
¢ Incident Closure
© Target Release Assignment
¢ Defect Resolution
¢ Defect Test and Closure
The document is organised in three sections:
Section 2.0 describes an end-to-end view of the process and illustrates the major owners of Incidents raised.
Section 3.0 describes a summary of the IncidenvDefect Management Process, identifying; sub processes,
process flows, inputs and outputs.
Section 4.0 describes each sub-process identifying; process flows, inputs and outputs
2.0 Scope
The process recognises two major threads of ownership for Incidents raised:
e Customer Service for Incidents generated from the live service and associated activities e.g. Live
Calls, CS Reference Data Team, CS Management Support Unit, ISD and Live Support Team. (This last
continues to hold true even though organisationally LST is now within the Systems Integration
Directorate)
e Development for Incidents generated by: Post Office Account Test Units (other than LST) and
Development Units during planned testing activities.
© 2003 Fujitsu Services Page: 6 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
End-to-End Ownership (Threads)
End to End threads - raise incident and monitor progress through to
Closure (either as Incident, or as Defect after successful fix testing).
1
° 30 40 60
Assign Target
Capture Incident Release Test Fix
Close Incident and
i RMF Close Defect
FP
Common Processes 5.0
provided by the 2.0 Quality Filter Process
Delivery Units which
can be considered as
a service to the End-
to-End Threads i<
24 22
Analyse Incident [> Manage Change Resolve Defect
23
Identity Solution
Components
Two sub-processes are also established as services to these End-to-End Threads:
© Quality Filter Process.
¢ Defect Resolution.
For completeness and to facilitate understanding of the end-to-end nature of the process all components have
been described. However, many of the components will be complemented by local work instructions or replaced
by other processes, for example CS/PRD/074, (Customer Service Incident Management for Incident Capture),
It should also be noted that Customer Service has its own processes covering: Incident Capture; Incident
Closure; Release Management Forum; and Defect Test and Closure. Customer Services also own CS/FSP/006
the document that defines the operational responsibilities of the units involved in the end to end support of the
software delivering the Post Office Account solution in relation to each other.
The process flow diagrams include information required to update Call records in PinICL, which is the Post
Office Account tool for Incident/Defect Management. Principally this is an attempt to reinforce correct use of
Response Codes, Product and Product Group fields.
© 2003 Fujitsu Services Page: 7 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
3.0 Incident/Defect Management Process
3.1 Overview
3.1.1 Process Flow
Incident/Defect Management Process - Overview
Live .
‘Observation
Service oe)
q )
Live Senice
Support ee Potential
io Detect:
Shea ‘Approved
Target
ao RMF Remawe I OP
ejecta] Ct Test Fix
‘Closure ae =
Response pal
Incidents ‘QFP Forum Defect
for Closure
Fixed
Detects Foe
2.1 Analyse 2.2 Manage
Incident“ ”“ change a
> Sous
Defect
2.3 Wentify
i Sotion Rejected Build Defects and Incidents
‘Components returned for further consideration
‘Suspected Suild Defects
3.1.2 Process description
Process Owner: System Integration Director.
Process Objectives: To capture, record and respond to Incidents.
To identify and isolate Defects.
To test and deliver Fixes.
Process Rationale: The process is built on the PinICL System fundamental that only the Call
Logger of an Incident or a member of the same team may close that Incident.
Incident Closure and Defect Test and Closure are the Sub Processes that
verify if the documented conclusions have satisfied the Incident as stated.
Incidents originating from the live service are managed in cooperation with
Customer Service with the Release Management Forum authorising any
change to Target Release.
A record is maintained throughout the life of the Incident/Defect and all
decisions catalogued in the Call in the PinICL system.
© 2003 Fujitsu Services Page: 8 of 28
Fujitsu Services Post Office Account: Systems Integration Directorate Ref:
Incident/Defect Management Version:
Date:
DE/PRO/015
2.0
5 Sep 2003
FUJ00079902
FUJ00079902
Inputs/Triggers:
The trigger is a perceived difference between expected and actual behaviour
of a Product or Service normally found during one of: Formal test stage;
Live system use; Live system operation; General Observation.
Sub Processes:
1.0 Incident capture.
2.0 Quality Filter Process.
2.1 Incident Analysis.
2.2 Change Management Actions.
2.3 Solution Components.
3.0 Incident Closure.
4.0 Target Release Assignment.
5.0 Defect Resolution.
6.0 Defect Test and Closure.
Resources:
Potentially all Post Office Account Programme Staff, but mainly:
Development Unit Managers.
CS staff responsible for operation and support of the live estate.
ITU staff responsible for Test stages.
CS Managers who release product to the live estate.
Programme and Directorate Management Teams.
Outputs:
Closed Incidents
Closed Defects.
Standards:
PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services
Page: 9 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.0 Process Components
4.1 Incident Capture
4.1.1 Process Flow
1.0 Capture Incident
Formal
Test
Stage
Review Incident Details:
‘Confirm Product &
Product Group,
Delivery Unit team
required to investigate;
I Capture
Investigate
Proposed Target Release
for Fix; PinICL Priority.
‘Set Target Release to current-provisional
Route to OFP Code 38
Customer Service
Incident Management Process
Reference No.CS/PRD/074
‘Code 30: Team Leader Approved
Code 38: Potentia! Problem Identifies
Live Service
Support
4.1.2 Process Description
Process Owner: Development Director.
ITU Director
CS Manager (is a separate CS process)
Process Objectives: To provide an approved Incident for analysis.
© 2003 Fujitsu Services Page: 10 of 28
Fujitsu Services
Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
FUJ00079902
FUJ00079902
Process Rationale:
‘Any member of Post Office Account staff identifying a PinICL trigger event
MUST originate an Incident or cause an Incident to be originated.
The Incident needs to be supported by evidence and a description of the
circumstances under which it was observed.
Local Management needs to approve the Incident prior to passing it on to the
Quality Filter Process for analysis.
The vast majority of Incidents captured originate from scripted testing or
from the live service.
Live service Incidents arrive with the target release set (provisionally) at the
current release.
All other Incidents have the target release set to Unknown by the system, but
the Call Logger should update the text to include a recommendation for
release.
Inputs/Triggers:
Formal Test Stage.
Live Service.
Live Service Support
Observation.
The trigger is the formal description of the Incident and associated evidence.
Sub Processes:
None
Resources: Potentially all Post Office Account Programme Staff, but mainly:
ITU Staff who undertake testing
Development Unit Staff who undertake testing
CS Staff that support the live estate
Outputs: Approved Incidents for analysis.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services
Page: 11 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.2 Quality Filter Process.
4.2.1 Process Flow
2.0 Quality Filter Process
‘This i not the complete list
Code 62: No Faultin Product
Code 66: Enhancement Request
C Code 70: Avoidance Action
I fo Code 72: Duplicate Cail
Code 96: Insuffeient Evidence
Code 98: User Error
Incident returned from
delivery unit l
22
Manage Change
24 I
Analyse Incident}
Incidents retumed after
further review by Call
Logger
23
Identity
Solution
Incident Team Leader
Approved
4.2.2 Process description
Process Owner: Manager, Development Units.
Process Objectives: Minimise the time spent in analysis for each Incident.
Improve the effectiveness of isolating product Defects.
Identify change management issues.
Provide guidance on the areas to be considered and the decisions required.
© 2003 Fujitsu Services Page: 12 of 28
Fujitsu Services
Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
FUJ00079902
FUJ00079902
Process Rationale:
The process operates under the control of the Incident/Defect Manager.
QFP Representatives are identified for each Development Unit.
QFP Administration maintains a list of these representatives.
QEP Administration assigns Incidents to QFP Representatives for analysis.
The QFP Representatives are responsible for ensuring that either the Incident
is recommended for closure or a potential product Defect is identified.
If the Incident has been incorrectly assigned it is returned to QFP
Administration with a recommendation as to where it should go.
As Incidents are routed for analysis to the QFP Stack, QFP Representatives
are expected to identify and assign to themselves Incidents relevant to their
own product areas. They should not wait for QFP administration to assign
the Incidents.
This is a fast moving process and the emphasis is on appropriateness, so the
steps indicated in the Process and Sub Processes can and do happen in a
different order to that shown.
The QFPF also can happen at different times during the process and if
required Incidents are reviewed more than once.
Tnputs/Triggers:
‘Approved Incidents.
Incidents returned after further review with Call Logger.
Incidents returned after Defect consideration.
Sub Processes:
2.1 Incident Analysis.
2.2 Change Management.
Solution Components.
Resources:
QEP Representatives.
Incident/Defect Management.
Post Office Account Managers responsible for testing.
Outputs:
Incidents returned to Call Logger for closure or further action.
Suspected build Incident.
Target Release Assignment,
Standards:
PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services
Page: 13 of 28
Fujitsu Services
Incident/Defect Management
Post Office Account: Systems Integration Directorate
FUJ00079902
FUJ00079902
Ref: DE/PRO/015
Version: 2.0
Date: 5 Sep 2003
4.23
4.2.3.1 Process flow
Quality Filter Process — Incident Analysis
2.1 QFP — Analyse Incident
Incidents retumed
by Call Logger
incident returned
by delivery unit
Incident returned
from ASD
DE/PROIO16
‘This ie not the complete list
Code 62: No Fault in Product
‘Code 66: Enhancement Request
Avoidance Action
Code 72: Duplicate Call
Code 96: Insufficient Evidence
Code 98: User Error
a
Assign to
I I FP
I I representative
Besign
problem
escalation
Discuss
With Call
_tegger_—“Agree yg
I Priority,
Incident Team
Leader approved
Incident retumed from
change management
: ‘es
“insufficient
evidence n.
4.2.3.2 Process description
Process Owner:
Baseline
Documents
impacted
40
Target Release
Assigned
Process
Manager, Development Units.
Objectives:
Rapidly review and assess Incidents.
Improve effectiveness of detailed analysis by filtering out inappropriate Incidents.
© 2003 Fujitsu Services
Page: 14 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Process Initial investigation is undertaken.
Rationale: If the QFP Representative believes this Incident or this Incident plus others reveals a System
design weakness then it can be escalated to RASD as a Problem and progressed in
accordance with the Post Office Account Development Directorate Problem Management
Process, DE/PRO/016.
The priority of the call has to be agreed and any discussions undertaken with the Call Logger
if the priority needs to be changed.
Suspected build Incidents may be routed directly to the PIT team.
An Incident can be updated and returned to the Call Logger for a variety of reasons ¢.g.:
No fault in product.
User error.
Duplicate call.
Insufficient Evidence.
The Incident can be updated and routed to the DU Technical Authors if baseline documents
are impacted for review under the Change Management Sub Process.
The Incident can be updated and routed for further detailed review by the Development Unit
and identification of solution components.
A QFPF review is required if the Target Release has not been set or is inappropriate.
Inputs/Triggers: I Approved Incidents.
Incidents returned by Call Logger.
Incidents returned afler Defect consideration.
Incidents returned from RASD Problem Management Process.
Incidents returned from Change Management for further consideration.
Sub Processes:
None.
Resources:
QFP Representative.
Incident/Defect Management.
Outputs:
Incidents returned to Call Logger for either closure or further action.
Suspected build Incident.
Incidents for Solution Components.
Incidents for Change Management.
Incidents for Target Release Assignment.
Problems escalated to RASD.
Standards:
PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services Page: 15 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.2.4 Quality Filter Process - Change Management
4.2.4.1 Process flow
2.2 QFP — Manage Change
analysis ia »
Return for Closure,
ce ae code 72—
I siinvestigate no achon required’ ~f~SO2 wacae
— io
yal ye
Code 66 - Enhancement
request
Change Design ~
nota I I Discuss with Baseline return for closure when
ments I I Customer documents (>> CCNICP authorised
Requirements _} impact
Correct Requirements,
= Return for closure
when CCN/CP
authorised
Code 86 - Enhancement
request
Return for closure —
New Requirement
raised with Client
Code 66 - Enhancement
-
4.2.4.2 Process description
Process Owner Requirements, Architecture and System Design.
Process Objectives: Identify actions and decisions that impact Contract Controlled Documents or
fundamental Specification of Requirements and Technical Design.
Process Rationale: The QFP Representative refers to the relevant Design Authority any Incident
that brings into question the design or requirements implemented.
Requirements Issues will be progressed by the Design Authority directly
with Business Requirements.
Any resulting change will be in the form of a CP or CR with supporting
CCN or CT and will be progressed in accordance with PA/PRO/001 Change
Management Process.
Inputs/Triggers: Incidents that challenge the design implemented.
Incidents that challenge the requirement implemented.
Defects that if corrected would cause change to CCDs.
Sub Processes: None.
© 2003 Fujitsu Services Page: 16 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Resources: Design. Authorities
CCD Technical Authors
QEP Representative.
Incident/Defect Management.
Business Requirements.
Outputs: Incident returned to QFP for potential Defect consideration.
Incidents recommended for closure — no fault in product.
Incidents recommended for closure -Essential changes to design or
requirement CCN/CP.
Incidents recommended for closure -enhancement being progressed with the
client CR.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services Page: 17 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015,
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.2.5 Quality Filter Process - Solution Components
4.2.5.1
Process Flow
2.3 QFP — Identify Solution Components
[Assign Target Release
Route to RMF Code 55)
Live fx impact supplied
Route to QFP code 42
product error ented
‘ f
Potential Jeovereach]_gI ty
peetect "associated I *) KEL
investigation [component I I impa
I Workaround
required for
" current
I baseline
Review:
Call details;
Product
Product Group;
Root Cause
Pe Route aF2
rate one
work in error identiied
other unit I
5
4.2.5.2 Process description
Process Owner: Manager, Development Units.
Process Objectives: Define actions needed with an identified solution and consequential actions.
© 2003 Fujitsu Services Page: 18 of 28
Fujitsu Services
Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
FUJ00079902
FUJ00079902
Process Rationale:
The QFP Representative ensures that all solution components are identified
and can be progressed satisfactorily. If appropriate, a workaround solution
may be required for the current baseline as well as a longer-term solution or
consequential work may be required in another Development Unit, which has
to be worked on in parallel.
Copy (Clone) PinICLs should be used for this task with a separate PinICL
raised for each piece of work. The PinICL should be updated with a clear set
of instructions so that the relationships are clear. The procedure for raising
clone PinICLs is covered in the PinICL Reference Data Guide
CM/MAN/005.
Discussion with CS if a KEL entry is required or needs to be updated. The
Procedure for updating/creating KELs is contained in the PinICL Reference
Data Guide CM/MAN/005.
A QFPF review is required if the Target Release has not been set or is
inappropriate.
For calls where a live fix impact has been requested an Impact statement is
produced and sent to the RMF for Target Release consideration.
Inpuis/Triggers:
Incident — Initial analysis completed.
Target Release assigned by QFPF/RMF.
Sub Processes: None.
Resources: QFP Representative.
Problem Management.
Outputs: Incidents - all solution componenis.
Impacted Incidents for live Fix decision by the RMF.
Incidents for Target Release consideration by QFPF.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services
Page: 19 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.3 Incident Closure
43.1 Process Flow
3.0 Close Incident
Response Route to QFP Code
rejected S2 response
rejected
No
Incident returned ‘Agree
to Call Logger for Review incident
closure against response closure
defined criteria
Yes
‘This is not the complete ist
Code 62: No Faut in Product
Code 66: Enhancement Request
Check incident Coxe 70: Avoidance Action
closing details Code 72: Duplicate Call
for accuracy Code 96: Insufficient Evidence
Coxe 98: User Error
4.3.2 Process description
Process Owner: TTU Manager.
Manager, Development Units.
CS Manger. (This is a separate CS process)
Process Objectives: Verify that the actions taken to investigate the Incident have an agreed
conclusion.
Identify the steps and actions associated with Incident closure.
Process Rationale: I Call Logger is responsible for Incident closure.
Call Logger may reject the response if not satisfied.
Inputs/Triggers: Incidents recommended for closure.
Sub Processes: None.
Resources: Potentially all Post Office Account Programme Staff, but mainly:
Development Unit Test Staff.
ITU Staff.
Live Support Staff.
© 2003 Fujitsu Services Page: 20 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Outputs: Closed Incidents,
Incidents returned for further consideration either Response Rejected or
Further Information Provided.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services Page: 21 of 28
Fujitsu Services Post Office Account: Systems Integration Directorate Ref:
Incident/Defect Management Version:
Date:
DE/PRO/015
2.0
5 Sep 2003
FUJ00079902
FUJ00079902
4.4 Target Release Assignment
4.4.1 Process Flow
4.0 Assign Target Release
assignment
or re-
assignment
Release Management Forum eee f
Live a {
detect . to ure i
vii Route io RME Cone 55 ve Fee ERT RG SHE ne Aer
Target Live fix impact supplied Me
Release
‘Quality Filter Process Forum Raise Clone for
deferred release
Test
Incidents eset Yes
for Review
Target call Live call =
Release and
Defer resolution
to later release
Recommend Live
select
‘option
assignment
assignment,
Route to Devel
to ent Uoit
‘otle Ba Live fx Impact Required
fix for test call
Changes
Baseline?
Resolve for
Baseline in test
Ye
4.4.2 Process Description
Process Owner: Manager, Development Units.
ITU Manager.
CS Manager (RMF is a separate CS process),
Process Objectives: I Ensure an appropriate Target Release is selected and approved for the delivery of the
corrected Defect.
Process Rationale: Under the control of the Incident/Defect Manager interactions, are initiated across the
programme to ensure the appropriate Target Release is identified and agreed.
Two meetings are used to facilitate this:
Release Management Forum.
Quality Filter Process Forum.
The QFPF comprises:
Development Unit QFP Representatives.
Release Managers.
Typically during intense periods of formal testing, QFPF meetings will take place daily.
© 2003 Fujitsu Services
Page: 22 of 28
Fujitsu Services
FU.
Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
FUJ00079902
IJ00079902
Test Managers.
TDA Representative.
SSC Representative.
PIT Representative
Incident/Defect Management is represented at the weekly CS Release Management Forum
where Target Releases for designated calls originating from the live service are
determined.
QFPF review the Incidents and an appropriate Target Release is identified.
If any Fix is proposed to a Release that would impact the planned testing of that Release,
whether by impacting areas of the system that were not to change in that Release, or to
introduce types of testing not already included in that Release or to complicate the Release
and its migration, the issue must be referred to Morning Prayers for discussed with the
POL Release Manager.
Ifa live Fix is being recommended the Incident is updated requesting that a live Fix impact
is to be provided to the RMF for consideration
QFPF and/or RMF (as appropriate) also consider the re-targeting of calls to a different
release where a previously-agreed release is no longer achievable
The QFPF also provides an opportunity to arrange KEL entries with the SSC representative
for agreed Incidents. The procedure for creating and modifying KELS is in the PinICL
Reference Data Guide CM/MAN/005.
At the discretion of the Incident/Defect Manager and Post Office Accounts Programme
Management the QFPF review deferrals:
System Test Incidents.
Business Test Incidents.
All Incidents associated with a baseline being released into the live service.
Live calls recommended for deferral by the QFPF are sent to the RMF for approval. A
clone call is arranged to progress the Incident at the nominated deferred release whilst the
original is returned to the RMF for consideration. The text is updated to reflect the priority
perceived with a recommendation for closure as fixed in a future release. This is either
agreed at RMF (and the Incident closed by the SSC) or a live Fix is requested and the
Incident returned to QFP.
All decisions agreed by the RMF or QFPF are recorded in the Incident.
With the agreement of all QFP representatives, low (typically D priority) calls may have a
KEL raised to describe them and then be closed.
Inputs/Triggers:
Incidents with Potential Solutions Identified.
Live Incidents recommended for deferral
Sub Processes:
None.
Outputs:
Incident with Target Release agreed.
Standards:
PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services Page: 23 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
© 2003 Fujitsu Services Page: 24 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.5 Defect Resolution
4.5.1 Process Flow
5.0 Resolve Defect
Confirmed
Release From,
QFPF
Code 60 - SAW fix
Fix ‘Code 61 - Build Mx
Fails Released to call logger
_ I Baseline Unit
etal impact on Identify [Product
Analysis ree 2nd I gl Dependencies and Integration
clones test I [write handover doc Team
Code 48
Fix released to PIT
>I Build incident Anatysi Build fix
confirmed Route To GFP code 52
Release tromy Suspected Bald Response Rejected
RMF Incidents from QFP
Suspected build nedents
from Incident capture
4.5.2 Process description
Process Owner: Manager, Development Units.
Process Objectives: I Identify the steps and actions needed during Defect resolution.
© 2003 Fujitsu Services Page: 25 of 28
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
FUJ00079902
FUJ00079902
Process Rationale:
DE/PRO/003 Fujitsu Services Post Office Account System Integration
Lifecycle Processes CM/PRD/001 Software Configuration Management
Version Control and CM/PRD/003 Work Package request are applicable to
this Process.
The relevant Development Unit undertakes detailed analysis work
identifying the Fix to be made.
The Development Unit must also check regularly that all calls targeted at a
given Release can be completed for that Release. As soon as it becomes clear
that some calls may not be fixed within the timescales, threatened calls must
be returned to QFP/RMF for further consideration.
A further check is made to ensure no contract controlled documents are
impacted e.g. PPDs. If there are impacts the Incident must be sent to the
Design Authority as a change management action.
If a number of software baselines are being progressed in parallel then a
clone PinICL is required to track each change to each baseline. A common
example would be a live Fix where a clone of the Live Fix would be required
to the current baseline being developed. The procedure for creating clone
PinICLs is identified in the PinICL Reference Data Guide CM/MAN/005.
The Fix is Unit and Link Tested then delivered by PIT ready for testing by
the Call Logger.
A handover note is produced identifying dependencies etc, This is
documented in CM/PRD/001 Software Configuration Management Version
Control.
Build Incidents are analysed by PIT who either accept and Fix the Defect or
reject for further analysis by QFP as more likely a Development Unit
Incident.
Inputs/Triggers:
Suspected build Incidents passed directly to PIT for action.
Suspected build Incidents from QFP.
Fix fails for correction.
Potential Product Defects with approved Target Release from either RMF or
QFPF.
Sub Processes:
None.
Resources: Development Units.
Technical Integration.
Outputs: Resolved defects ready for testing.
Potential Product Defects returned to QFP for further consideration (either
from PIT or Development units).
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services
Page: 26 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
4.6 Defect Test and Closure
4.6.1 Process Flow
6.0 Test Fix and Close Defect
(Defects Code 50 — Ref Data fix released to Call Logger
Wailable for Test/ Code 60 - SIW fix released to call Logger
Available for Test/ Coc et - Buld foto Call Logger
Close code cos tix 5f »
defect Teleasedtocal >\_ Blefeets
Request Test Rig losaer
Build Upgraded I-—>} Test
(PTs)
Return to
Fix failed closure
Code 50 - Fix Failed
to)
4.6.2 Process description
Process Owner: Manager, Development Units.
ITU Manager.
CS Manager (is a separate CS process)
Process Objectives; Verify that the actions taken to correct defects have been successful.
Identify the steps and actions associated with Defect test and closure.
Process Rationale: Call originator is responsible for Defect closure.
All defects are passed to a test team to verify that the fault has been fixed.
Arrange for their test rig to be updated with the new software.
On successful test the Defect is either closed as tested successfully or
updated as tested successfully and routed to Call Logger for closure.
Fix fails are rejected for rework.
Inputs/Triggers: Corrected Defects available for test.
Sub Processes: None.
© 2003 Fujitsu Services Page: 27 of 28
FUJ00079902
FUJ00079902
Fujitsu Services Post Office Account: Systems Integration Directorate Ref: DE/PRO/015
Incident/Defect Management Version: 2.0
Date: 5 Sep 2003
Resources: Potentially all Post Office Account Programme Staff, but mainly:
Development Unit Staff responsible for testing.
ITU Staff responsible for testing.
CS Staff responsible for testing.
Outputs: Rejected Defects — failed test.
Closed defects.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2003 Fujitsu Services Page: 28 of 28