Fujitsu Services
Horizon Generic Release Acceptance Process PA/PRD/013
1.0
COMPANY IN CONFIDENCE Date: 13/09/04
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Internal Distribution:
External Distribution:
Approval Authorities:
Horizon Generic Release Acceptance Process
Process Definition
NA
This document describes a process, agreed by both Post Office
Limited and Fujitsu Services Post Office Account, that governs
the Acceptance of Releases to the Horizon system from Fujitsu
Services Post Office Account to Post Office Limited.
APPROVED
Jan Holmes (Programme Assurance)
Post Office Limited :
David Smith, David Gray, Bob Booth, Jason Crellin, Torstein
Godeseth, Simon Glynn, Keith Baines, Marc Reardon
Fujitsu Services Post Office Account :
Gill Jackson, Peter Jeram, Allan Hodgkinson, Bob Gurney,
Hilary Forrest, Colin Lenton-Smith, Janusz Holender
To be defined
David Smith, Mike Wells, Keith Baines, Mark Burley, Clive
Reed, Simon Glynn, PO Librarian
‘Name Position Signature Date
Peter Jeram POA Systems Integration
Director
David Smith Post Office Delivery Director
© 2004 Fujitsu Services
COMPANY IN CONFIDENCE Page: 1 of 20
FUJ00001889
FUJ00001889
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
Document Control
0.1 Document History
VersionNo. I Date —_I Reason for Issue Associated _
ae i a : CP/PinICL ~
0.1 04/03/04 First draft N/A
0.2 25/03/04 Initial description of overall process N/A
0.3 05/04/04 Review comments from HF and SG (Post Office) N/A
04 14/04/04 Review comments from HF, GJ, AH plus re-structuring N/A
0.5 16/04/04 Review comments from PJ, Ad’A, TD. N/A
0.6 24/05/04 Review comments from SG, PJ, TG, DG (Post Office) N/A
0.7 01/06/04 Review comments from DS, KB, IOD (Post Office) N/A
O08 11/06/04 Review comments from SG, PJ (Post Office) N/A
0.9 15/06/04 Review comments from SG (Post Office) N/A
0.10 20/07/04 Review comments from TG, PJ, LP (Post Office) N/A
0.11 19/08/04 Final review meeting FELO1 (18/08/04) N/A
1.0 13/09/04 Raised to Approved N/A
0.2 Review Details
Review Comments by :
Review Comments to : Jan Holmes
Post Office Limited Mandatory Review ‘Authority /
Name
Delivery Director
David Smith (*v0.5)
Commercial Director
Ian O'Driscoll (*v0.5)
Commercial Manager
Simon Glynn (*v0.2)(*v0.5)(*v0.7)(#V0.8)
Contract Manager
Keith Baines (*v0.2)(*v0.5)
Business Solutions
Mike Wells
David Gray (#v0.2)(*v0.5)
Marc Reardon
Peter Jones (#V0.5)(*v0.7)(#v0.9)
Torstein Godeseth (*V0.5)(*v0.9)
1 Services Post Office Account Mandatory
Review Authority a i:
‘Name
Louis Prastitis(*v0.9)
Systems Integration Director
Peter Jeram (#v0,3) (*0.4)
© 2004 Fujitsu Services
COMPANY IN CONFIDENCE
Page: 2 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
RASD Tony Drahota (*v0.4)
Delivery Director Alan D’ Alvarez (*v0.4)
Release Manager Gill Jackson (*v0.2) (*v0.3)(*v0.10)
Release Manager Bill Reynolds
Release Manager John Burton
Commercial Director Colin Lenton-Smith
Commercial Manager Hilary Forrest (*v0.2) (*v0.3)
Design Authority Allan Hodgkinson (v0.3)
Optional Review / Issued for Information
Bob Gurney
( *vn.n ) = Reviewers that returned comments
0.3 Associated Documents
Reference Vers I Date I Title Source
[1] I Unreferenced 11/02/04) Acceptance Guidelines (B. Gurney)
[2] Unreferenced 3 24/02/04) Acceptance Guidelines (S. Glynn)
[3] CA023320087_101 Schedule I : Interpretation
[4] CA023570007_18 Schedule 20 : Development Services
[5] I CA023230079_39 Schedule 24 : Banking Implementation
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
Acceptance Schedule I : means acceptance of a Service or Release in accordance with the
relevant acceptance procedure;
cD Conceptual Design
cT Commercial Terms
DP Design Proposal
E2E End to End
FS Fujitsu Services
© 2004 Fujitsu Services
COMPANY IN CONFIDENCE
Page: 3 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
HLTP High Level Test Plans
ITU Integration and Testing Unit
Joint ISL Joint Information Systems Landscape
LST Live System Test
PEAK System used by Post Office Account to record and monitor bugs found during
testing.
PO Post Office Limited
POA Post Office Account (Fujitsu Services)
RASD Requirements, Architecture and Strategy Development
Release Schedule 1 : means a documented collection of software and/or data provided by
Fujitsu Services to deliver a Service or Services;
RV Release validation
SI Systems Integration
SV&I System Validation and Integration
0.5 Changes in this Version
Version
Changes
0.9
Transfer definitions from Section 0.4 to Section 3..
0.6 Changes Expected
Changes
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 4 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
0.7 Table of Contents
1.0 Purpose of Document 6
2.0 Derivation 6
3.0 Definitions 6
3.1 ACCEPTANCE 6
3.2. ACCEPTANCE PROCESS STAGES 7
3.3. REQUIREMENTS STATEMENT 7
3.4. ACCEPTANCE CRITERION 7
3.5. ACCEPTANCE METHODS 8
3.6 I ACCEPTANCE TRACKING 8
3.7. ACCEPTANCE INCIDENT 8
3.8 I ACCEPTANCE INCIDENT COLLECTION 9
3.9 I ACCEPTANCE PROGRESS INCIDENT 9
3.10 ACCEPTANCE DISPUTE 9
4.0 Generic Acceptance Process 9
41 DOCUMENTATION REQUIREMENTS 9
42 ROLES AND RESPONSIBILITIES 10
4.2.1 Release Acceptance Manager 10
4.2.2 Release Acceptance Board 10
4.3 CHANGES TO RELEASE CONTENTS 10
5.0 Progressing Through Acceptance 10
5.1 ACHIEVING RELEASE STAGE PROGRESSION ial
5.1.1 From Fujitsu Test to End-to-End (Acceptance Gateway 1) il
5.1.2. From End-to-End to Pilot/Soft Launch (Acceptance Gateway 2) ll
5.2. ACHIEVING RELEASE ACCEPTANCE (ACCEPTANCE GATEWAY 3) 11
53 RULES FOR PROGRESSING TO THE NEXT STAGE 12
6.0 Handling Acceptance Testing Evidence 13
7.0 Managing Acceptance Incidents 14
7.1 RAISING ACCEPTANCE INCIDENTS 14
7.2. ANALYSING AND CLASSIFYING ACCEPTANCE INCIDENTS. 15
73 REPEAT TESTING 16
7.4 RECTIFICATION PLAN 16
8.0 Release Acceptance Dispute Process 16
8.1 GENERAL 16
8.2 RELEASE ACCEPTANCE DISPUTE RESOLUTION 17
9.0 Annex A : Acceptance Incident Severity Matrix 18
10.0 Annex B : Release Acceptance Board TORs 19
11.0 Annex C : Acceptance Methods 20
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 5 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
1.0
COMPANY IN CONFIDENCE 13/09/04
1.0 Purpose of Document
2.0
3.0
3.1
The purpose of this document is to describe a clear, agreed process that enables
objective confirmation (or otherwise) of the fulfilment of Fujitsu Services’ (FS)
delivery obligations and, where such confirmation has been linked, confirmation of
obligations to payment by Post Office Ltd (PO).
The process includes a mechanism for managing any/all rectification activities
identified in order to complete the fulfilment of any acceptance criteria that have not
been met.
Derivation
The document is derived from a number of sources :
» FS document Acceptance Guidelines dated 11/02/04.
PO review comments (S60, S70/S75) TDA dated 13/02/04.
PO IT Commercial Review dated 16/02/04
Joint PO/FS review meeting dated 23/02/04.
Vv
PO document Acceptance Guidelines v0.3 dated 24/02/04 containing points of
agreement in meeting between PO and FS on 23/02/04.
> Email exchanges not formally captured.
> Schedule I : Interpretation
> Schedule 20 : Implementation
> Schedule 24 : Banking Implementation
Definitions
Acceptance
Schedule 1 defines Acceptance as “...means acceptance of a Service or Release in
accordance with the relevant acceptance procedure”. In practice the primary target for
acceptance is the Release since this will comprise the applications, services and
infrastructure changes required to deliver a business service to the Post Office.
Acceptance is a process between PO and FS to provide :
» Confirmation that such deliverables are fit to proceed to the next stage in the
acceptance process or into Live;
> Confirmation that FS has met the specified requirements, and any related
contractual obligations, in an agreed manner.
In general, a Release will consist of a set of deliverables arising from one or more
Work Packages, such Work Packages containing Commercial Terms stating what, if
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 6 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
2 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
any, Acceptance Criteria are applicable to the Acceptance Process for such Work
Package(s) and related Release
3.2 Acceptance Process Stages
Although some acceptance criteria may be satisfied during the Solution Specification
stage of the Joint Working ISL it is anticipated that the majority will be dealt with
during the following stages :
> System Validation and Integration, owned by Fujitsu Services.
> E2E Test, owned by Post Office.
> Pilot/Soft Launch, owned by Post Office.
This can be represented diagrammatically :
OA Acceptance RA Acceptance OA Acceptance
Gateway 4 Gateway 2 Gateway?
Solution Bulld and Tea Stage
I
Fults)
Endto End Stage $ Piiotson Full Live
(Post Ofte) Launch Stage Running
Sokation
Speaitication
Stage
paproi301 [Fujita Tea va Fujtas Tea (RV 8 LST) (Wenitoring
Note : This diagram is for illustrative purposes only and is not meant to imply that the
Fujitsu SB&T stage will always operate in parallel to the PO E2E stage. In practice,
however, it often will.
3.3. Requirements Statement
A clear statement of a business requirement of PO, as presented in the Requirements
Catalogue of the PO Conceptual Design (CD) and the agreed listed hierarchy of
documents referred to from the CD where such documents contain requirements, for
example Interface Specification.
One or more agreed Acceptance Method(s) will be allocated against each
Requirement Statement and these will be documented in the Requirements Catalogue
in the CD.A Requirement Statement may be subject to FS caveat detailing any
exceptions to full compliance during the preparation and submission of the associated
Commercial Terms (CTs), subject to PO agreement.
3.4 Acceptance Criterion
A clear, objective and unambiguous statement against which fulfilment (with
supporting evidence) of a Requirement Statement using an Acceptance Method (see
Annex C) can be determined. There will be one Acceptance Criterion against each
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 7 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
3.5
3.6
3.7
instance of an allocated Acceptance Method. There may be Requirements that are, in
themselves, measurable and unambiguous. In such cases the Acceptance Criterion
should be marked ‘as per the Requirement’. Acceptance Criteria will be documented
in the Requirements Catalogue in the CD.
Acceptance Methods
One of an agreed set of pre-defined techniques by which Requirements Statements
can be objectively measured as fulfilled or not, each against one or more agreed
Acceptance Criteria (see 3.3 and 3.4 above). Acceptance Methods are described in
more detail at Annex C.
In general, a Requirement Statement may be allocated one or more Acceptance
Methods. The objectives in allocating Acceptance Method(s) to Requirements
Statements are to:
» Progress toward overall Release Acceptance as efficiently as possible, ie to
keep the number of formal acceptance stages to the minimum necessary,
ideally one, but subject to also being able to:
> Identify and resolve defects (non-compliances) as early as possible in the
Acceptance timeframe, to reduce overall development costs and risks.
Each Acceptance Method has one owner, either FS, PO or a 3“ party. The owner is
responsible for producing, within the agreed timescale, evidence that an Acceptance
Criterion has either:
> Been met, with evidence or
> That it has not been met, with evidence.
In summary, the relationships are:
One Requirement Statement may have one or more Acceptance Methods.
One Acceptance Method will have one Acceptance Criterion.
Each Acceptance Method will have one Owner.
Note : Acceptance Method in this context is a type of and not an instance. Thus an
instance of a type, eg Document Review, may address a number of Acceptance
Criteria from one or more Requirements Statements.
Acceptance Tracking
Acceptance tracking will be achieved through the production of a single Acceptance
Tracking Document that will be derived from the various Requirements Catalogues in
the CDs being delivered by the Release.
The Acceptance Tracking Document will be produced by PO.
Acceptance Incident
An Acceptance Incident is raised when the Acceptance Method fails to prove that an
Acceptance Criterion has been met. Acceptance Incidents are classified according to
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 8 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
2 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
3.8
3.9
3.10
4.0
4.1
Annex A. An Acceptance Incident manifests itself as a PEAK report that is allocated
to an Acceptance Incident Collection within PEAK.
Acceptance Incident Collection
A facility in PEAK whereby fault reports deemed to be Acceptance Incidents can be
grouped for management and reporting purposes. It is proposed that an Acceptance
Incident Collection is established for each Release.
Acceptance Progress Incident
An Acceptance Incident is classified for the purposes of Release Stage Progression as
high, medium or low, in accordance with Annex A.
Acceptance Dispute
Within the context of this process ‘Dispute’ is defined in Paragraph 8.1. It is NOT a
Dispute in the broader context of the overall Agreement between Post Office Ltd and
Fujitsu Services.
Generic Acceptance Process
The process described in this paragraph is based on that presented in Schedule 24 but
without the specific links to Network Banking. It refers to a Release in the context of
a number of independent application software and/or infrastructure products,
interfaces and processes that are ‘bundled’ together, each of which may go through
the Acceptance process independently before the results are brought together to
consider the Release as a whole for Release Authorisation purposes.
Documentation Requirements
The following documentation is required by the Acceptance process :
> Requirements Catalogues from the CDs that form the definition of (changes
being introduced in) the Release.
> Acceptance Tracking Document that will be constructed from the
Requirements Catalogues of the Release CD’s. This will be updated with the
outcomes of the various Acceptance activities. Its production and maintenance
is the responsibility of Post Office.
> High Level Test Plans (HLTP) containing the Functions and Conditions that
are mapped against the Acceptance Criteria. HLTP’s are produced by the
owners of each of the Stages, and by implication the executors of the tests
conducted in those Stages (POA for Fujitsu Solution Build and Test, Post
Office for End to End Test) and are subject to review by the other party.
Fujitsu Services will use reasonable endeavours to produce drafts of the HLTPs by the
date specified in the overall Release Plan. Post Office and Fujitsu Services will use
reasonable endeavours in working towards reviewing the documents by Post Office
by the date(s) specified in the overall Release Plan.
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 9 of 20
Fujitsu Services Horizon Generic Release Acceptance Process
FUJ00001889
FUJ00001889
PA/PRD/013
1.0
COMPANY IN CONFIDENCE 13/09/04
4.2
4.2.1
4.2.2
4.3
Roles and Responsibilities
Release Acceptance Manager
The primary responsibility for managing Release Acceptance rests with the respective
Release Acceptance Manager of Post Office and Fujitsu Services. This may be a
specified individual or, more likely, a role adopted by the respective Release
Managers. A Release Acceptance Board will be nominated for each Release and the
primary function of this Board is to settle disputes that cannot be resolved by the
Release Managers.
Release Acceptance Board
The Release Acceptance Board shall be constituted, deal with the matters and meet at
the intervals as set out in Annex B.
Changes to Release Contents
Prior to Release Acceptance, as described in Section 5.2, where either Party requests a
change to any provision of the Commercial Terms that relate to the Release, the
Change Control Procedure will be followed and both Fujitsu Services and Post Office
will review the Acceptance Criteria to determine whether any changes are required.
Such changes may include:
> Deletion of criteria that were derived from deleted provisions;
» Addition of new criteria relating to new or extended provisions; and/or
» Modification of criteria relating to changed provisions.
If changes are made to Release Tests that are already in progress or have been
completed then, unless both Parties agree otherwise, or the results of those changed
Release Tests can be derived from the results of Release Tests already carried out,
those tests shall be repeated.
Progressing Through Acceptance
Section 3.2 identifies the three key stages during which Acceptance takes place,
namely Fujitsu Test, E2E and Pilot/Soft Launch. Progression from one stage to the
next is controlled by an Acceptance Gateway that has to be passed through.
Acceptance Gateways have parameters associated with them that are configured to
meet the specific arrangements agreed between Post Office Ltd and Fujitsu and reflect
the characteristics of the Release. The parameters are :
» The Rules identified in paragraph 5.3.
> Number and status of High Severity Acceptance Progress Incidents.
> Number and status of Medium Severity Acceptance Progress Incidents.
Acceptance Gateway 1, between Fujitsu Test and E2E is fully configurable and
reflects the fact that, by agreement of both parties, Fujitsu Test and E2E can run in
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 10 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
1.0
COMPANY IN CONFIDENCE 13/09/04
5.2
parallel. Acceptance Gateways 2 and 3 have defaults associated with them that can be
amended via the Commercial Terms for the Release.
Depending on the nature of the Commercial Terms agreed for the Release, the
Gateways may constrain progression or merely act as a marker to acknowledge that a
particular stage is complete.
After Release Acceptance, provided that Fujitsu Services continues to meet an
obligation using the release content as tested or demonstrated to Post Office during
the Acceptance process, Post Office will not be entitled to require that Fujitsu
Services meets that same obligation in some other way.
Achieving Release Stage Progression
From Fujitsu Test to End-to-End (Acceptance Gateway 1)
Progression from Fujitsu Test Stage to E2E Stage can occur once all of the following
have been satisfied, as determined by the Commercial Terms for the Release :
» The Rules in paragraph 5.3;
The number and status of any High Severity Acceptance Progress Incidents
has been agreed; and
> The number and status of any Medium Severity Acceptance Progress Incidents
has been agreed.
Note that the default values for these parameters are null meaning that unless the
Commercial Terms specifically introduces a constraint at this Gateway, progression
from Fujitsu Test to E2E is a matter for agreement at the working level.
From End-to-End to Pilot/Soft Launch (Acceptance Gateway 2)
Subject to any amendments introduced by the Commercial Terms for the Release,
progression from E2E Stage to Pilot/Soft Launch Stage can occur once all of the
following have been satisfied :
> Subject to Rules 4 to 8 in paragraph 5.3 all Tests scheduled for the E2E Stage
have been completed;
> There are no outstanding High Severity Acceptance Progress Incidents; and
> The number of outstanding Medium Severity Acceptance Progress Incidents is
5 or less and an agreed workaround exists for each of them.
Achieving Release Acceptance (Acceptance Gateway 3)
Subject to any amendments introduced by the Commercial Terms for the Release,
Release Acceptance occurs once all of the following have been satisfied:
> The earliest planned date as specified in the Release Plan for completion of
Pilot/Soft Launch has occurred;
» Subject to Rules 4 to 8 in paragraph 5.3 all Release Tests have been
completed;
> There are no outstanding High Severity Acceptance Incidents;
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 11 of 20
Fujitsu Services
FUJ00001889
FUJ00001889
Horizon Generic Release Acceptance Process PA/PRD/013
2 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
Vv
The number of outstanding Medium Severity Acceptance Incidents is 5 or
less;
Each Medium Severity Acceptance Incident has an agreed rectification plan,
agreement to which has not been unreasonably withheld; and
Each Low Severity Acceptance Incident has a target Release for rectification.
5.3 Rules For Progressing to the Next Stage
1.
If the Parties do not agree whether Release Acceptance or Release Stage
Progression can occur, the matter will be resolved through the Disputes
Resolution procedure described in Section 8.
If, following investigation by Fujitsu Services, an Acceptance Incident or
Acceptance Progress Incident is found to have been caused solely by a fault or
deficiency in anything other than those elements of the Release provided by
Fujitsu Services, it shall not count towards the thresholds identified in
paragraph 5.1 or 5.2 of this process, subject to modification by the
Commercial Terms for the Release.
Acceptance Incidents or Acceptance Progress Incidents that result from the
same failure or deficiency will be counted as a single Acceptance Incident or
Acceptance Progress Incident (as applicable) for the purposes of the thresholds
identified in paragraph 5.1 or 5.2 of this process, subject to modification by
the Commercial Terms for the Release.
Tf, other than as a result of a Default of Fujitsu Services, it is impossible for a
Test to be carried out when scheduled in the Release Testing Plan then that
Test becomes known as a “Deferred Test". Deferred Tests will be carried out
by Fujitsu Services as soon as reasonably practicable or at such later time as
the Parties may agree (which shall be no later than 6 months after Release
Acceptance) provided that performance on that agreed date does not, other
than as a result of a Default of Fujitsu Services, become impossible (in which
event the Deferred Test shall be carried out by Fujitsu Services as soon as
reasonably practicable).
The non-occurrence of a Deferred Test at the time originally scheduled in the
Release Testing Plan will not prevent Release Stage Progression or Release
Acceptance, each of which will be assessed on the basis of:
» Those Tests scheduled to take place for that Release Stage Progression or
for Release Acceptance, as the case may be, which are not Deferred Tests;
and
Those Deferred Tests which, when rescheduled in accordance with Rule 4
above of this process are due to take place for the purposes of the next
Release Stage Progression or for Release Acceptance, as the case may be.
v
If, when a Deferred Test is carried out after Release Acceptance, it is not
successfully completed, that failure shall not of itself constitute a Default
under the Agreement or entitle Post Office to raise an Acceptance Incident or
Acceptance Progress Incident.
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 12 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
7. The failure of Fujitsu Services to carry out a Deferred Test in accordance with
Rule 4 above constitutes a Default under the Agreement.
8. Rule 6 above does not act to reduce or alter the liability of Fujitsu Services for
any breaches by it of the Agreement.
6.0 Handling Acceptance Testing Evidence
6.1 Evidence (including, without limitation, test results, test observations, data or other
information) provided by Fujitsu Services for review in relation to Acceptance Tests
("Acceptance Testing Evidence") shall by default be available to all Post Office
employees and contractors unless such evidence is:
» Confidential Information, in which case disclosure shall be governed by the
provisions of Clause 50 of the Agreement; or
» Considered to be or categorised as sensitive in accordance with paragraphs 6.2
or 6.3 of this process, in which case disclosure will be governed by those
provisions (as applicable).
6.2 Acceptance Testing Evidence that can reasonably be considered to be particularly
sensitive because access to such information could compromise the security of the
Release or other Post Office Services will be restricted to named employees or
contractors of Post Office who will be nominated by Post Office to review it on Post
Office's behalf. Access to the information will be in accordance with such reasonable
conditions as may be imposed by Fujitsu Services.
6.3 Subject to paragraph 6.4, Acceptance Testing Evidence categorised by Fujitsu
Services (acting reasonably) as particularly commercially sensitive to Fujitsu Services
will only be disclosed to named employees or contractors of Post Office (such named
individuals to be approved by Fujitsu Services). Post Office will place such named
employees and contractors under a duty to keep confidential and not disclose Fujitsu
Services’ commercially sensitive information to any other person or Party without
Fujitsu Services’ prior written consent (which consent shall not be unreasonably
withheld or delayed).
64 — Fujitsu Services will not be entitled to categorise any Acceptance Testing Evidence as
commercially sensitive where that evidence solely reflects a visible manifestation or
result of the operation of the Release content, as opposed to how the Release content
achieves that manifestation or result.
6.5 Sensitive information disclosed as Acceptance Testing Evidence pursuant to
paragraphs 6.3 or 6.4 above may also be disclosed by Post Office or Fujitsu Services
to the Release Acceptance Board if such disclosure is necessary for the resolution of a
dispute.
6.6 At Post Office's request Fujitsu Services will supply supporting evidence for the
completion of an Acceptance Test that can reasonably be regarded as necessary for
Post Office to validate whether the Acceptance Criteria for that test have been met.
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 13 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process Ref: PA/PRD/013
Version: 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
7.0
7A
TAA
Managing Acceptance Incidents
Raising Acceptance Incidents
Subject to paragraph 7.1.5 below :
An Acceptance Incident will be raised by Fujitsu Services when the Acceptance
Method used fails to prove that the Acceptance Criterion has been met. In addition,
Fujitsu Services will report to Post Office any material undesirable occurrences,
which are not Acceptance Incidents, observed by it whilst conducting Acceptance
Tests.
Post Office may raise an Acceptance Incident whenever Post Office becomes aware
of evidence that any of the above circumstances have arisen or becomes aware that
the Acceptance Criteria are not being met or that introduction of the Release content
has resulted or might reasonably be expected to result in the existing Applications or
the Infrastructure Services no longer functioning or being performed (as the case may
be) in accordance with the provisions of the Agreement.
7.1.2 Where the Conceptual Design (as caveated by Commercial Terms) expressly states that
the application will not permit specified functions or activities or cause certain
specified behaviour, and those functions, activities or behaviour are observed to occur
during testing of the application then the observing Party will (in the case of Fujitsu
Services) or may (in the case of Post Office) raise an Acceptance Incident.
Tf:
> A Release Test is required in respect of a provision of the Conceptual Design
(as caveated) of the type referred to in paragraph 7.1.2 above; or
> An Acceptance Incident is raised in relation to such provision,
the Release Test or proof of resolution of that incident (as the case may be) will take
the form of a reasonable demonstration or examination that the functions, activities or
behaviour referred to in paragraph 7.1.2 above do not occur. Fujitsu Services will not
be required to demonstrate on an ongoing basis that such functions, activities or
behaviour do not occur or will not occur.
Tf, following a successful Release Test or proof of resolution of an Acceptance
Incident as referred to in paragraph 7.1.3, a further Acceptance Incident will (in the
case of Fujitsu Services) or may (in the case of Post Office) be raised in accordance
with paragraph 7.1.1 above if the applicable functions, activities or behaviour above
are observed to occur again.
Each Party will raise an Acceptance Incident as soon as reasonably practicable after
becoming aware of such incident. However, Acceptance Incidents may not be raised
in respect of any Acceptance Criteria before commencement of the Release
Acceptance stage or phase designated in the Release Testing Plan for testing those
Acceptance Criteria. Once Release Acceptance has occurred no new Acceptance
Incidents may be raised. For the purposes of this paragraph a "new Acceptance
Incident" means an Acceptance Incident that occurs after the Release Acceptance
Date or which occurs on or before that date, but is not reported to Fujitsu Services
before the Release Acceptance Date. Once Release Stage Progression has occurred no
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 14 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
2 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
7.2
721
7.22
7.2.3
additional Acceptance Incidents will be classified as Acceptance Progress Incidents in
respect of that Release Stage Progression.
An Acceptance Incident manifests itself as a PEAK fault report that has been
allocated to the Acceptance Incident Collection for that Release. PEAKs will be
allocated to the Release AI Collection following review by the Test Team Managers
from both parties.
A PEAK that is allocated to the AI Collection can only be closed with the agreement
of both Test Team Managers.
If a dispute arises whereby agreement cannot be reached between the Test Team
Managers as to the status of a PEAK in the Al Collection the matter will be escalated
to the Release Acceptance Managers for resolution. If the Release Acceptance
Managers cannot agree as to the status the matter will be escalated according to the
Release Acceptance Dispute Procedure described in Section 8..
Analysing and Classifying Acceptance Incidents
Acceptance Incidents will be analysed by Fujitsu Services and a written report
detailing Fujitsu Services’ proposals for:
v
the severity classification of the Acceptance Incident as identified in Annex A;
Vv
related rectification activities (if applicable);
Vv
re-testing dates/periods (if applicable); and
> the severity classification of the Acceptance Incident as a Release Progress
Incident (if applicable)
provided to Post Office's Release Acceptance Manager. This information will be
included in the Test Report issued at the time of completing the Fujitsu Test and E2E
Stages.
Each Acceptance Incident will be classified according to its severity for the purposes
of Release Acceptance and, if that Acceptance Incident remains outstanding prior to
Release Stage Progression, then for the purposes of the Release Stage Progression in
question, Fujitsu Services will propose and Post Office and Fujitsu Services will agree
(such agreement not to be unreasonably withheld) the severity classifications for each
Acceptance Incident in accordance with the criteria at Annex A to this process.
For the purpose of paragraph 7.2.2 an Acceptance Incident will be regarded as having
been caused by the introduction of the Release:
» if that incident is identified in a Release Test, regardless of the Acceptance
Method used, or the Release Pilot/Soft Launch; and
> where the behaviour of the Horizon Service Infrastructure giving rise to that
incident (i) has not been previously observed, or (ii) had been previously
observed in relation to the Application (other than the current Release) or the
Infrastructure Services but such behaviour had been resolved prior to
commencement of testing of the Release; unless
> following investigation by Fujitsu Services, that incident is found to be
unrelated to the introduction of the Release.
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 15 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
2 10
COMPANY IN CONFIDENCE Date: 13/09/04
7.2.4 Where an Acceptance Incident can be attributed to faults in the Release the severity of
7.3
7.4
741
74.2
8.0
8.1
that incident (for the purposes of Release Acceptance and Release Stage Progression)
shall be classified with reference to the fault in the Release alone.
Repeat Testing
Any failed Test may, prior to the end of the agreed Pilot/Soft Launch, be repeated by
Fujitsu Services as many times as necessary in order for Release Acceptance and/or
Release Stage Progression to be achieved. Fujitsu Services will propose dates for such
repeat tests having regard to the overall Release Plan. Post Office will be responsible
for making personnel available to observe repeat testing if required. In the case of
repeated non-Fujitsu Services or Post Office Tests, Post Office will be entitled to the
same elapsed time for the repeated activity as was scheduled for the original failed
activity. Fujitsu Services will only propose repeat tests when it reasonably believes a
different (i.e. improved) outcome would result.
Rectification Plan
For each Medium Severity Acceptance Incident outstanding on the Release
Acceptance Date, Fujitsu Services will prepare a written Rectification Plan that
includes:
» A statement of the operational impact and any necessary temporary procedures
to be adopted by Users;
> A description of how rectification is to be achieved; and
» A timetable for rectification.
For each Low Severity Acceptance Incident outstanding on the Release Acceptance
Date, Fujitsu Services will identify a target Release for rectification.
Release Acceptance Dispute Process
General
If Post Office and Fujitsu Services do not agree on:
> The form or content of the Release Tests as defined in the HLTPs;
> Changes to Acceptance Criteria, Release Tests, Release Testing Specifications
or the Release Testing Plan consequent upon changes to the provisions of the
Conceptual Design;
> Whether any Tests should be repeated pursuant to Section 7.3 above as a
consequence of changes to the Release Tests;
Results of Release Tests;
>» Whether an event or occurrence is a Acceptance Incident or a Acceptance
Progress Incident or both;
> Classification of severity of Acceptance Incidents or Acceptance Progress
Incidents;
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 16 of 20
FUJ00001889
FUJ00001889
Fujitsu Services Horizon Generic Release Acceptance Process PA/PRD/013
2 1.0
COMPANY IN CONFIDENCE Date: 13/09/04
8.2
8.2.1
8.2.2
8.2.3
>» Whether an Acceptance Incident has been caused by a deficiency or fault in a
component of Horizon Service Infrastructure used in the Release itself (for
which Fujitsu Services is responsible) or a deficiency or fault in other services,
systems or data (including, without limitation, Reference Data) of Post Office
or a third Party (for which Post Office is responsible); or
» Adequacy of rectification plans,
the Parties will refer such dispute (the "Dispute") to the Release Acceptance Board.
For the avoidance of doubt Dispute in the context of this Acceptance Process is not
the same as Dispute in the broader context of the Agreement between Post Office Ltd
and Fujitsu Services.
Release Acceptance Dispute Resolution
Each Dispute referred to in the circumstances described in Section 8.1 of this process
will be referred to the Release Acceptance Board to obtain a resolution. The Release
Acceptance Board is required to reach an agreed resolution
The Decision of the Release Acceptance Board will be final and binding on the
Parties.
In the event that a Release Acceptance Dispute cannot be resolved through the above
process it will be escalated and handled as per the Dispute Resolution Procedures
described in Annex 2 to Schedule 4 of the Agreement.
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 17 of 20
Fujitsu Services
COMPANY IN C
Horizon Generic Release Acceptance Process Ref:
1.0
13/09/04
)NFIDENCE
9.0 Annex A: Acceptance Incident Severity Matrix
Severity
High
Description (for the purp
Release Acceptance)
The Acceptance incident was caused by
the introduction of the Release and
results in a defect that would render the
Applications or the Infrastructure
Services unfit for operational use.
s of Release Stage
Progression)
The Acceptance Incident was caused by the
introduction of the Release and results in a defect
which would render the Applications or the
Infrastructure Services unfit for testing during the
Release E2E Stage or Release Pilot/Soft Launch
(whichever is applicable)
Medium The Acceptance Incident was caused by I The Acceptance Incident was caused by the
the introduction of the Release resulting I introduction of the Release and results in a defect that
in a defect that would not prevent I would significantly prejudice the validity of the testing to
operation of the Applications or the I be carried out in the Release E2E Stage or Release
Infrastructure Services but would cause I Pilot/Soft Launch (whichever is applicable).
significant problems in the operational
use of one or more of the Applications or
the Infrastructure Services.
Low The Acceptance Incident was caused by I The Acceptance Incident was caused by the
the introduction of the Release resulting I introduction of the Release resulting in a defect which
in a defect that does not have a I would have some but no significant effect on the
significant effect on operational use of I validity of the testing to be carried out in the Release
the Applications or the Infrastructure I E2E Stage or Release Pilot/Soft Launch (whichever is
Services. applicable)
Non An incident raised by either Party which, I An incident which
Incident _I following investigation is found:
> Not to be a defect,
» Not to have resulted from the
introduction of the Release; or
> — Not to fall within the high, medium
or low categories set out in this
column
» Is nota Acceptance Incident, or
> Would have no effect on the validity of the testing
to be carried out in the Release E2E Stage or
Release Pilot/Soft Launch Stage
© 2004 Fujitsu Services
COMPANY IN CONFIDENCE
FUJ00001889
FUJ00001889
PA/PRD/013
Page: 18 of 20
Horizon Generic Release Acceptance Process
Version:
COMPANY IN CONFIDENCE Date:
FUJ00001889
FUJ00001889
PA/PRD/013
1.0
13/09/04
10.0 Annex B : Release Acceptance Board TORs
Board Release Acceptance Board
Purpose Consider and attempt to resolve Release Acceptance disputes
Starting At commencement of Release
Date
Frequency I As required to resolve disputes during the Acceptance activity
PO Ltd Mandatory attendees
Attendees Delivery Director (Chair)
Commercial Manager
Optional attendees
Release Manager
Release Design Authority
Testing Manager
Fujitsu Mandatory attendees
Services .
‘Attendees SI Director
Commercial Director
Optional attendees
Release Manager
RASD Director
Delivery Director
© 2004 Fujitsu Services COMPANY IN CONFIDENCE
Page: 19 of 20
Fujitsu Services
FUJ00001889
FUJ00001889
Horizon Generic Release Acceptance Process Ref: PA/PRD/013
1.0
)NFIDENCE Date: 13/09/04
COMPANY IN C
11.0 Annex C : Acceptance Methods
Walkthrough
Document Acceptance Criteria that cannot be objectively verified by a test of the Release may be
Review satisfied by PO undertaking a Document Review. The outcome of any such review will be
documented by PO in the Document Review report. FS will supply a list of documents (and
any specific references within such documents) for POL review, which may satisfy the
agreed acceptance criteria
Design Acceptance Criteria may be satisfied by PO evidencing a Design Walkthrough of the Fujitsu
Services’ design. The outcome of any such design walkthrough will be documented by PO in
the Design Walkthrough report.
Fujitsu Test
Tests that are run and managed by Fujitsu Services for the purpose of verifying that a
Fujitsu Services Release satisfies the relevant Acceptance Criteria. Fujitsu Services will
produce a test report presenting the results of the tests. The assessment of the results of
these tests, in conjunction with the Acceptance Criteria, will be by inspection carried out by
Fujitsu Services or jointly with PO.
PO (E2E) Test
Tests that are run and managed by PO, which in terms of the scope of this process, are for
the purpose of verifying in terms of the E2E solution, Acceptance Criteria have been met.
PO shall provide to FS appropriate evidence of any non-compliances.
Monitoring
PO shall specify any requirement beyond the level of support that Fujitsu Services are
required to provide under normal operational practice (such as a report etc). Duration,
nature and characteristics to be agreed in advance between PO and FS and will take place
during the Pilot/Soft Launch. The total duration of Monitoring and the requirements on
Fujitsu Services to produce data/reports to support Post Office Monitoring to be agreed
between PO and FS for a particular Requirements Statement.
Statement of
Fact
Where the solution to an Acceptance Criterion is self-evident and does not lend itself to
formal proving. This may typically take place during the production of the Design Proposal
Statement of
Relates to Acceptance Criterion that represent either:
Obligation .
> Anexisting Fujitsu Services obligation, where that obligation is impacted by the
Release, or
> Agreed additional Fujitsu Services obligation (to be recorded subsequently as an
amendment to the contract clauses, schedules, or contract controlled documents)
Other Used by exception, to be agreed between the parties
© 2004 Fujitsu Services COMPANY IN CONFIDENCE Page: 20 of 20