ICL Pathway
FUJ00079823
FUJ00079823
ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
Distribution:
ICL Pathway Development Directorate Incident/Defect
Management
Procedure
N/A
This document describes the ICL Pathway Development
Directorate Incident/Defect Management process
APPROVED
John M‘lean FELO1 — Development Directorate
Lionel Higman FELO1
Mike Anderson FELO1, Peter Lindsey FELO1, Janet Dore FELO1,
Anne Cooper FELO1, Bob Davis BRAO1, Evandro Manolas
BRAO1, Jonathan Comley FELO1, John Newitt FELO1, Graham
Chatten FELO1, Alex Nicholson BRAO1, Steve Doyle FELO1,
Chris Wannell FELO1, Lorraine Holt FELO1, Alan D’alvarez, Chris
Humphries FELO1, Pat Lywood BRAOI, Mik Peach BRAOI,
Sheila Bamber BRAO1, John Dicks FELO1, David Groom FELO1,
Dave Royle FELO1.
N/A
N/A
ICL Pathway Library FELO1, Reviewers
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 1 of 27
ICL Pathway
ICL Pathway Development Directorate Ref:
Incident/Defect Management
Version:
COMMERCIAL IN CONFIDENCE Date:
DE/PRO/OI5S
1.0
25/10/00
0.0 Document Control
0.1
Document History
0.1 12/06/00 First Draft for Review (not in PVCS) N/A
0.2 11/09/00 Draft for review N/A
0.3 4/10/00 Draft for Review N/A
0.4 15/10/00 Final Draft NA
1.0 25/10/00 APPROVED N/A
0.2 Approval Authorities
Terry Austin Development
Director
David Groom Quality Manager
Peter Jeram Manager, _ Delivery
Units
Gill Jackson B&TC Manager
Cliff Wakeman TDA Manager
Jan Morrison Manager, Technical
Integration
0.3 Associated Documents
CM/MAN/005
PinICL Reference Data ICL Pathway
Guide
CS/PRD/074 CS Incident Management I ICL Pathway
Process
CM/PRD/001 Software Configuration I ICL Pathway
Management Version
control process
CM/PRD/003 Work Package Request I ICL Pathway
Process
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 2 of 27
FUJ00079823
FUJ00079823
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
CM/MAN/009 PinICL Training Manual ICL Pathway
DE/PRO/003 ICL Pathway Development I ICL Pathway
Directorate Processes
PA/PRO/001 Change Management I ICL Pathway
Process
PA/PRO/014 Pathway PinICL Problem I ICL Pathway
Management Process
PA/PRO/O16 ICL Pathway Development I ICL Pathway
Directorate Problem
Management Process
0.4 Abbreviations/Definitions
Note: Unless a specific Version and Date is referred to above, reference should be
made to the current (Approved) Version of the document.
SSC System Support Centre
SMC System Maintenance Centre
CCD Contract Controlled Documents
PPD Process and Procedure Description
HSH Horizon System Help Desk
RMF Release Management Forum
QFP Quality Filter Process
cP Change Proposal
CCN Change Control Note
CR Change Request
SPTS Service Provision and Technical Support
PIT Product Integration Team
TI Technical Integration
OSD Operational Services Division
QFPF Quality Filter Process Forum
OTT Operational Test Team
WP Work Package
KEL Known Error Log
KPR Known Problem Register
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL
3 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
PinICL An ICL system used by Pathway for Incident/Defect Management.
Modified for ICL Pathway by Application Management.
PVCS A proprietary Configuration Management System used by ICL
Pathway and developed by Merant International Ltd
cs Customer Service - A Directorate within ICL Pathway
CM Configuration Management
DU Delivery Unit - Development Directorate organisational unit
responsible for developing products
DM Delivery Unit Manager
Call A term used to reference the Incident/Defect record held in PinICL
Incident An observed difference between expected and actual behaviour of a
Pathway Product captured in the PinICL System
Defect An agreed difference between designed and actual behaviour of a
Pathway Product
Fix An Incident that has resulted in a software correction to a Pathway
Product
B&TC Business and Technical Conformance
Call Logger Originator of the Incident
Stack A term used to identify a holding area of Incidents in the PinICL
System. Generally relates to a team name or function eg QFP Stack
TDA Technical Design Authority
Customer A Directorate within ICL Pathway
Requirements
R’qmts A term used for business requirements (used in diagrams)
0.5 Changes in this Version
General update to all areas. Revised Process Flows
0.2 General update to all areas. Revision to process flows.
0.3 General update to all areas to reflect comments obtained at 0.2.
Measures now withdrawn from process template.
0.4 Minor updates to text, typographical errors and consistency.
Added reference to CS ownership of processes in 2 Scope
Added reference to Live Calls in 4.1.2 Process rationale
Minor changes to all process flows
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 4 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Correction/improvement to Change Management process flow.
Changes to Target Release Assignment process flow and additional
wording. added to process rationale for Live Calls.
1.0 APPROVED Issue -Minor updates to text.
0.6 Changes Expected
Changes are expected to be made to:
Reflect further improvements (as required) to the processes identified, their integration with
other ICL Pathway processes and the specified standards.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 5 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Table of Contents
1 Introduction .. 7
2 Scope..
3 Incident/Defect Management Process ..............cccccessssesseeseeseseseeseeseeneeeesteneeneeses 9
BL OVORVIOW Loo eecceecceecceeesseeeeseesesneesseeseseesnessinesnneessenetsneesneesssneesnensssesssneeesessas 9
3.1.1 Process Flow....
3.1.2 Process description... ceeececeesesseseeseeseesessessesteseestseeseseeesetsneeeeeeee D
4 Process Components ..............:ccsesesesereeeesesesesececeeeeesersesececeeeeeessnenseseeeseeeeeeeeeee 11
AL Incident Capture... cece eeeeseee cess eeseeesneeeesseeeneesneetsseeetessessteenteeeeeee LD
4.1.1 Process Flow....
4.1.2 Process Description ........c.c.ccecceccscseceeseesesseeseseseeseesesseeteseeeesesneeeeanensees 11
4.2 Quality Filter Process. ..........ccescssseessessseeceesseessesseeesesseeseeesneeseeneesereseesneeseee 12
4.2.1 Process Flow....
4.2.2 Process description.............c:cccceccecec tess eesseeseeeeesneereesseeseeneeeteeseesseesee 13
4.2.3. Quality Filter Process — Incident Analysis ................ceccecesseeeeeeeseeneeee 15
4.2.4 Quality Filter Process - Change Management................00cceeeneeeee LT
4.2.5 Quality Filter Process - Solution Component..........0...000.:c0seeeeeeee 18
4.3 Incident Closure... cecceeeceeeceeeeeeseeseeeeeseeseneeesseessnessssessseseseessessseeres 20
4.3.1 Process Flow...
4.3.2 Process description... cece eeseeeseeseesteseeeeeeesteeteeeessesseeeneeeees 21
44 Target Release Assignment.............0..cccccccesecs sees ee teseeeeeeseeeeeneeeeseeeeenes we 22
44.1 Process Flow....
4.4.2 Process Description .............cscccessescesssecsessseeseesseeenesseesseesneeseesessetsseesees 22
45 Defect Resolution... cecccecceceecseeeeecc ness eesesseeeneseneeseesneeneeneeeesseseneeseee 24
4.5.1 Process Flow....
4.5.2 Process description..........c.cecececsessesseseseeseeseeseseeseeseereeeseseeseeneeeaensees 24
4.6 Defect Test and Closure... eecceeccseesseessseesesesssntessnesesstessenseneesssenssneeess 20
4.6.1 Process Flow....
4.6.2 Process description..........c.cececeeccecseeeseeseeseeseeeseeeeseeseseeseeeeseereeeeaneeee 26
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 6 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
1 Introduction
This document describes the ICL Pathway Development Directorate Incident/Defect
Management process. It supersedes and replaces PA/PRO/014 (Pathway PinICL
Problem Management Procedure).
The process has been decomposed and the following Sub Processes identified:
e Incident capture
© Quality Filter Process
o Incident Analysis
o Change Management Actions
co Solution Components
¢ Incident Closure
¢ Target Release Assignment
¢ Defect Resolution
¢ Defect Test and Closure
The document has been 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 Incident/Defect Management Process,
identifying; sub processes, process flows, inputs and outputs.
Section 4.0 describes each sub-process identifying; process flows, inputs and
outputs
A process flow diagram and a process flow description have been produced for each
component using a standard format.
2 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, Reference Data Team, OSD and
Operational Test Team.
e¢ Development for Incidents generated by: Business and Technical
Conformance during planned testing activities; and likewise for
Delivery Units during planned testing activities.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 7 of 27
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
FUJ00079823
FUJ00079823
End-to-End Ownership (Threads)
End-to-End Threads - raise incidents and monitor progress through to
closure (as either Incidents or successfully tested Defects).
1.0 Incident 3.0 Incident 4.0 Target Release 6.0 Defect Test
Cale Closure Assignment and Closure
Customer
Service
RMF
t I t
2.0 Quality Filter Process
‘Common Processes provided
by the Delivery Units which
can be considered as a service
to the End-to-End Threads 5.0 Defect
2.1 Incident 2.2 Change .
Resoluti
‘Analysis Menagement ee
2.3 Solution
Components
Two sub-processes are also established as services to these End-to-End Threads:
© Quality Filter Process.
¢ Defect Resolution.
As illustrated above.
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 such as
with the Customer Service Incident Management for Incident Capture.(CS/PRD/074).
It should also be noted that Customer Service has their own processes covering:
Incident Capture; Incident Closure; Release Management Forum; and Defect Test and
Closure.
The process flow diagrams also include steps required to update information in
PinICL, which is the ICL Pathway tool for Incident/Defect Management. Principally it
is the Response Codes and ensuring that the correct Product and Product Group are
selected that are referenced.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 8 of 27
ICL Pathway
ICL Pathway Development Directorate
Incident/Defect Management
COMMERCIAL IN CONFIDENCE
Ref: DE/PRO/OI5S
Version: 1.0
Date: 25/10/00
FUJ00079823
FUJ00079823
3 Incident/Defect Management Process
3.1 Overview
3.1.1 Process Flow
Incident/Defect Management Process - Overview
Tie
Service
Support
Live
I Service
iI
}
/ Formal 7 ise
Test Release Petal
f Assignment: Defect
Aopeoved
Rejected tape Rleme
Gore a G0 Defer
__I 1.0 Incident RespnseI 3.0 Incident Testing Fatale
Capture Closure > ond
ald Defects eden FP Forum Closure
for
Anadis
Tacients Pama Dee
ecemmendd ee et
a doowe prem ie
2.0 Quality Filter Process Testing
os : 5.0 Defect
2 lucdent 22 Chang
Anais “> ataaagement Resolution
233 Sstton
Ream Yor Fst conan
Sayeed Rail Defers
Sespected Dail Defects
3.1.2 Process description
Process Owner: Development Director.
Process
Objectives: of Pathway Product.
product.
To capture differences between expected and actual behaviour
To analyse these differences and resolve any resulting defects to
To determine a suitable Target Release for any resulting defects.
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL
9 of 27
ICL Pathway
ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
FUJ00079823
FUJ00079823
Process Rationale:
The process is built on the fundamental that only the Call
Logger of the Incident or a member of the same team is
permitted to close.
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 comprehensive record is maintained through out the life of
the Incident/Defect and all decisions catalogued. The PinICL
system provides the mechanism for achieving this audit log
Inputs/Triggers:
Formal test stage.
Live system use.
Live system operation.
Observation.
The trigger is the observation of a difference between expected
and actual behaviour of a Product or Service.
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 Pathway Programme Staff, but mainly:
Delivery Unit Managers.
CS staff responsible for operation and support.
B&TC and CS Managers responsible for Test stages.
B&TC and CS Managers responsible for releasing product to
the live estate.
Programme and Directorate Management Teams.
Outputs:
Closed Incidents
Closed Defects.
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 10 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Standards: PinICL Training Manual and PinICL Reference Data Guide.
4 Process Components
4.1 Incident Capture
4.1.1 Process Flow
1.0 Incident Capture oe
I
Formal
Test i. neato
Sess code30 = Team
Leader Approved
Review Incident Details. me
Capare I Tivestgate I_I Confim Product and Proust Team
Incident“) andcollect +>} ‘ret wi tone ‘ig Leader
cn cole required to investigate en Route to QFP Cade
Det Jaden Proposed target release for Approval 50 Team Leader
Bix. PinlCL Prionity Anproved
x
=
Route to QFP
‘Code 38 - Potential Problem Identified.
Target release se to current Release
Customer Service Incident Management Process
~ Reference No.CS/PRD:074
4.1.2 Process Description
Process Owner:
Manager, Delivery Units.
B&TC Manager
CS Manager (is a separate CS process)
Process
Objectives:
Provide an approved Incident for analysis
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 11 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Rationale: I Any member of Pathway’s staff can originate an Incident.
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.
Vast majority of Incidents captured originate from scripted
testing or from the live service.
Live service Incidents arrive with the target release set at the
current release.
All other Incidents have the target release set to unknown but
the text should be updated 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 Pathway Programme Staff, but mainly:
B&TC Staff who undertake testing
Delivery Unit Staff who undertake testing
CS 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.
4.2 Quality Filter Process.
4.2.1 Process Flow
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 12 of 27
ICL Pathway
ICL Pathway Development Directorate
Incident/Defect Management
COMMERCIAL IN CONFIDENCE
Ref: DE/PRO/OI5S
Version: 1.0
Date: 25/10/00
FUJ00079823
FUJ00079823
2.0 Quality Filter Process
Incident returned
fiom Delivery Unit
Incidents returned
further review
by Call logger
Incident Team
Leader Approved
This is be comple is
ode 62
(Code 66 Eninaceen: Reqiet
22Change
‘Management
=
2.1 Incident
Analysis
ky
Rete
on
4.2.2 Process description
Process Owner: Manager, Delivery Units.
Process Minimise the time spent in analysis for each Incident.
Objectives:
Improve the effectiveness of isolating product defects.
Identify change management issues.
Provide guidance on the areas to be considered and the decisions
required.
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL
13 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Rationale: I The process is operated under the control of the Incident/Defect
Manager.
QFP Representatives are identified for each of the Delivery
Units.
QFP Administration maintains a list of these representatives.
QFP Administration assigns Incidents to the 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 with a
recommendation as to where it should go.
As Incidents are routed for analysis onto the QFP Stack the QFP
Representatives are expected to identify Incidents relevant to
their own product areas and not wait until the Incident is
assigned by QFP administration.
This is a fast moving process and the emphasis is on
appropriateness, consequently 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.
Inputs/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.
2.3 Solution Components.
Resources: QFP Representatives.
Incident/Defect Management.
Pathway Managers responsible for testing.
Outputs: Incidents returned to Call Logger for either closure or further
action.
Suspected build Incident.
Target Release Assignment.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 14 of 27
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
FUJ00079823
FUJ00079823
4.2.3 Quality Filter Process — Incident Analysis
4.2.3.1 Process flow
2.1 Quality Filter Process - Incident Analysis
)
Ys
te
‘oP Tnsficon a
Representa ‘ovidence
— Bae Lie
‘With Call i focuments
Tame cc
)
4.2.3.2, Process description
Process Owner: Manager, Delivery Units.
Process Rapidly review and assess Incidents.
Objectives: Improve effectiveness of detailed analysis by filtering out
inappropriate Incidents.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 15 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Rationale: I Initial investigation is undertaken.
If the QFP Representative believes this Incident or this Incident
plus others reveals a design weakness then it can be escalated to
the TDA as a Problem and progressed in accordance with the
ICL Pathway Development Directorate Problem Management
Process, PA/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 are sent to TI.
The Incident can be updated and returned to the Call Logger for
a variety of reasons e.g.:
No fault in product.
User error.
Duplicate call.
Insufficient Evidence.
The Incident can be updated and routed to the TDA 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 Delivery Unit and identification of solution
components.
A QFPF review is required if the Target Release has not been
set or is inappropriate.
Inputs/Triggers: Approved Incidents.
Incidents returned by Call Logger.
Incidents returned after defect consideration.
Incidents returned from TDA Problem Management Process.
Incidents returned from Change Management for further
consideration.
Sub Processes: None.
Resources: QFP Representative.
Incident/Defect Management.
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 16 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
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 the TDA.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
4.2.4 Quality Filter Process - Change Management
4.2.4.1 Process flow
2.2 Quality Filter Process_- Change Management
Return to
FP
Design
Issue
Discus wih aie Change Design Rein I I ¢ .
tse
Eror
in Rgmts when CONCP
Authorised
Return fr lose Cate t6—Eemsemet et
‘New Rant raved wih
Client
4.2.4.2 Process description
Process Owner Technical Design Authority.
Process Identify actions and decisions that impact Contract Controlled
Objectives: Documents or fundamental Specification of Requirements and
Technical Design.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 17 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Rationale: I The QFP Representative refers to the Technical Design
Authority any Incident that brings into question the design or
requirements implemented.
Requirements Issues will be progressed by TDA directly with
Business Requirements.
Any resulting change will be in the form of a CP or CR with
supporting CCN 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.
Incidents/Defects that if corrected would cause change to Base
Line Documents.
Sub Processes:
None.
Resources: Technical Design Authority.
QFP 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.
4.2.5 Quality Filter Process - Solution Components
4.2.5.1 Process Flow
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 18 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
2.3 Quality Filter Process - Solution Components
)
Workaround oe
Ral =
current [J ae Mit
Ponat raise nds I I pansy Review PinlCL
‘ent to cover all ent details
PPP detect coud ee >) Product and Product
/I Investigation I components Impact Group Root Cause.
Parallel /
Work in Produce
other Unit Impact
4.2.5.2 Process description
Process Owner: Manager, Delivery Units.
Process Define actions needed with an identified solution and
Objectives: consequential actions.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 19 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Rationale: I 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 Delivery 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.
Inputs/Triggers: Incident — Initial analysis completed.
Target Release assigned by QFPF/RMF.
Sub Processes: None.
Resources: QFP Representative.
Problem Management.
Outputs: Incidents - all solution components.
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
4.3 Incident Closure
4.3.1 Process Flow
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 20 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
3.0 Incident Closure
. Response
rejected
‘Agree
Review Incident
Closure,
Review hi
closing details for
accuracy
4.3.2 Process description
Process Owner: B & TC Manager.
Manager, Delivery Units.
CS Manger. (is a separate CS process)
Process Verify that the actions taken to investigate the Incident have an
Objectives: 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 Pathway Programme Staff, but mainly:
Delivery Unit Test Staff.
B&TC Staff.
CS Test Staff and Live Support Staff.
Outputs: Closed Incidents.
Incidents returned for further consideration either Response
Rejected or Further Information Provided.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 21 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
4.4 Target Release Assignment
4.4.1 Process Flow
4.0 Target Release Assignment
Release Management Forum ‘Route to QEP Code 6 Live tix Authorised te
Live fix calls, Meet Live Fix > piileenin a
on Yo.
‘Aes dere
‘Quality Filter Process Forum,
Review ue
aaa] agree Ye
Deel ead a ROMS Ase
—— Ca erm Trvecal
an Cae Liv eps Regi
Identified Test Baseline $
4.4.2 Process Description
Process Owner: I Manager, Delivery Units.
B & TC Manager.
CS Manager (RMF is a separate CS process).
Process Ensure an appropriate Target Release is selected and approved for the
Objectives: delivery of the corrected defect.
Process Under the control of the Incident/Defect Manager interactions, are initiated
Rationale: 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.
place daily.
Typically during intense periods of formal testing, QFPF meetings will take
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL
22 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
The QFPF will comprise:
Delivery Unit QFP Representatives.
Release Managers.
Test Managers.
TDA Representative.
SSC Representative.
TI Representative.
Incident/Defect Management are 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 identified. If a
live fix is being recommended the Incident is updated requesting that a live
fix impact is to be provided to the RMF for consideration.
The Target Release consideration also takes on board any KPR impact. The
KPR is produced by B&TC and indicates any Incidents outstanding from
formal testing visible to the client. Each Incident on the KPR has an agreed
Target Release with the Client. The KPR procedure is owned by B&TC and
is identified in DE/PRO/003.
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 Pathways 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.
Business Requirements via their QFPF representative are asked to approve
all deferrals beyond the next Target Release.
All decisions agreed by either the RMF or QFPF are recorded in the
Incident.
Inputs/Triggers: I Incidents with Potential Solutions Identified.
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 23 of 27
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/OI5S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
FUJ00079823
FUJ00079823
Live Incidents recommended for deferral
Sub Processes: I None.
Resources: Delivery Unit QFP Representative.
QFP administration.
CS Release Management.
Test Stage Management.
Business Requirements
Outputs: Incident with Target Release agreed.
Standards: PinICL Training Manual and PinICL Reference Data Guide.
4.5 Defect Resolution
4.5.1 Process Flow
5.0 Defect Resolution
Bazaine
Impacts Fix
‘ise Defect
loser
Product 6 :
ewe To coe
aces
Cee
4.5.2 Process description
Process Owner: Manager, Delivery Units.
Process Identify the steps and actions needed during defect resolution.
Objectives:
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 24 of 27
ICL Pathway
ICL Pathway Development Directorate Ref: DE/PRO/OLS
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
FUJ00079823
FUJ00079823
Process Rationale:
DE/PRO/003 ICL Pathway Development Directorate Processes
CM/PRD/001 Software Configuration Management Version
Control and CM/PRD/003 Work Package request are applicable
to this Process.
The relevant Delivery Unit undertakes detailed analysis work
identifying the fix to be made.
A check is made to establish that the work can be completed for
the Target Release identified. If this is not the case or the detail
of the fix has changed it is returned to QFP 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 TDA 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 TI who either accept and fix the
defect or reject for further analysis by QFP as more likely a
Delivery Unit Incident.
Inputs/Triggers:
Suspected build Incidents passed directly to TI 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: Delivery Units.
Technical Integration.
Outputs: Resolved defects ready for testing.
Potential Product Defects returned to QFP for further
consideration (either from TI or delivery units).
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 25 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O15
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Standards: PinICL Training Manual and PinICL Reference Data Guide.
4.6 Defect Test and Closure
4.6.1 Process Flow
6.0 Defect Test and Closure
Close f
Defect \
Test Rig
Request Build Upgraded [> Test
(SPT)
Return to
call
Fix a ©
4.6.2 Process description
Process Owner: Manager, Delivery Units.
B&TC Manager.
CS Manager (is a separate CS process)
© 2000 ICL Pathway Limited COMPANY CONFIDENTIAL 26 of 27
FUJ00079823
FUJ00079823
ICL Pathway ICL Pathway Development Directorate Ref: DE/PRO/O1S
Incident/Defect Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 25/10/00
Process Verify that the actions taken to correct defects have been
Objectives; 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.
Resources:
Potentially all Pathway Programme Staff, but mainly:
Delivery Unit Staff responsible for testing.
B&TC 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.
© 2000 ICL Pathway Limited
COMPANY CONFIDENTIAL 27 of 27