ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
Document Title:
Document Type:
Abstract:
Distribution:
Document Status:
Document Predecessor:
Author:
Pathway Release Policy
Strategy Document
This document defines the Pathway policy for the
identification and planning of new Releases of
Software and Data.
Pathway Management Team
DraftApproved
234.0
Jim Morley, updated by Anne Cooper
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 1 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Rett
Version: 3.05.0
COMPANY.COMMERGIAL IN Date: 28/0616/07/99
CONFIDENCE
Contents List
1,__ DOCUMENT CONTROL
1.1__ DOCUMENT HISTORY.
1.2__ APPROVAL AUTHORITIES.
1:33 _ CHANGES FORECAS!
y
INTRODUCTION.
PURPOSE sss
.2__ DEFINITION OF RELEAS
2.3__ IDENTIFICATION OF NEW BUSINESS OPPORTUNITIES.
2.4 _ CHANGE CONTROL
2.5__ CONTRACTUAL AND FUTURE RELEASES
CLASSIFICATION OF RELEASES
3a__ SOFTWARE RELEASES,
3u__ NEW PRODUCT RE.
3.2 __ SOFTWARE INFRASTRUCTURE RELEASES,
z.3 MAINTENANCE RELEASES.
3.2__ REFERENCE DATA RELEASES. 10
3.3__ EMERGENCY PROCEDURES.
4.__ RELEASE CONTROL & CONTENT...
a__ INTRODUCTION.
Pi
2.5 CONTRACTUAL AND-FUTURE RELEASES...
3. _ CLASSIFICATION OF RELEASES
BASES.
‘NEW. PRODUCE RELEASE:
SOF WARE INFRASTRUCTURE RELEASE:
i DArAR
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 2 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Refs
Version:
COMPANY-COMMERCIAL IN Dates
CONFIDENCE
28/0616/07/99
3.3 EMERGENCY PROCEDURES.
ig R
SOF WARE DISTRIBUTION-AND ACTIVATION,
R Data D:
DOCUMENT CONTROL
rr Us
INTRODUCTION,
Di re
ONTRACFUAL AND FUTURE Ri
CLASSIFICATION OF RELEASES.
R
NEW. PRODUCT RELEASE:
SOF EWARE INERASTRUCEURE RELEASE:
MAINTENANCE RELEASES
rT ‘Data Bi
EMERGENCY PROC}
R SCON
5a Data D:
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE
Page 3 of 22
FUJ00118128
FUJ00118128
I ICL Pathway PATHWAY RELEASE POLICY —-e——PAISTR/003
I Version: 3.05.0
I COMPANY.COMMERCIAL IN Date: 8/0616/07/99
CONFIDENCE
FUJ00118128
FUJ00118128
4 DOCUMENT HISTOR)
INTRODUCTION.
PB
1
CONTRACTUAL AND FUTURER
Ri
NEW_PRODUCT RELEASE’ 8
R Data
DEFINITION-OF RELEASE CONTENT.
R & CON
BE Bi
5 MAINTENANCE RELEASES reerereeerrerrerrrerrereerreererereerererserreereererrrerreerrereerreereerr $b
R DAFAD:
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 4 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
-DOCUMENT CONTROL
1 DOCUMENT HISTORY
Version I Date Reason
O. 20/10/96 I First Draft for Pathway internal use only
oa 30/10/96 I Second draft following application of Pathway comments.
03 30/10/96 I Draft for issue to the PDA.
Og 12/n/96 Updated following PDA comments through Michael
Purchase.
0.5 17/u/96 Updated following PDA & Sponsor comments received
through Michael Purchase.
06 18/u/96 I Further comments applied from Pathway and PDA.
oF 24/u/96 I Further comments applied from PDA.
10 26/11/96 Further comments applied from POCL.
coy 27/11/96 Further comments applied from PDA, BA and POCL
1.2 28/11/96 Incorporates revisions following review by Pathway, PDA,
POCL and BA
3 5/98 Brought up to date to recognise differences between,
infrastructure and new product releases
20 29/03/99 _I Applied comments and approved ready for issue
2a 21/05/99 I Amended to reflect the current definition for Reference
Data changes.
22 22/06/99 _ I Amended to reflect the signed Heads of Agreement @4™
May 1999)
23 25/06/99 _ I Amended to reflect comments from Pathway review
30 28/06/99 _ I Further comments applied and approved ready for issue
EM 1aloqjag I Amended to reflect comments from Horizon/POCL review
40 iglo7/o9 I Pathway review comments applied and approved ready for
30 16lo7/99 I Amended to reflect comments from Horizon/POCL review
CCN 498.
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 5 of 22
FUJ00118128
FUJ00118128
I ICL Pathway PATHWAY RELEASE POLICY ef: PAISTRiogg
I Version: 3.05.0
I COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
1.2, APPROVAL AUTHORITIES
Name Position Signature Date ‘I
Tony Oppenheim Commercial and
Finance Director
Stephen Muchow Customer Service
Director
Liam Foley Business
Development
Director
Terry Austin Development
Director
Mike Coombs Deputy Managing
Director
4.21.3 CHANGES FORECAST +——-[Formatted: Bullets and Numbering )
None.
1.31.4 ABBREVIATIONS USED + (Formatted: Bullets and Numbering )
The terms and abbreviations used in this document are those defined in
Schedule Ao1 of the Agreement.
2. INTRODUCTION
2.1 PURPOSE
This document describes Pathway’s policy for identifying and planning the
development of new Releases of Software and dataData. Pathway aims to do
this in a manner that is responsive to the business needs of POCL, and
which also conforms to the provisions of the Agreement, Overall, it aims to:
a) establish the principles associated with releases of Pathway Services in
the context of the Agreement;
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE
Page 6 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
b) establish the principles for regular and on-going Releases of the Pathway
systems and Sezvicesservices; including sinfrastructureoftware
infrastructure releases, new product releases and maintenance releases:
c) establish the provisions to bring in changes to functionality and new
POCL Clients more quickly and frequently through Reference Data
provided by POCL and/or Pathway and to explain the main qualifiers for
doing this;
d) establish indicative timescales for the different types of Release in order
to put these into context.
The Pathway Release Policy is a key element in the process of
establishing business change, and provides a set of principles for the
timely and efficient introduction of new or improved products and
2.2 DEFINITION OF RELEASE
The Agreement defines a Release to be “a documented collection of
Software and/or data provided by the CONTRACTOR to deliver a Service”,
while the Requirement 476 makes it clear that the definition also includes
Reference Data. Throughout this document releases will be referred to as
either Software Releases or Reference Data Releases. It is possible that both
Software Releases and Reference Data Releases require the co-ordinated
implementation of other hardware/system Infrastructure infrastructure and
Supporting supporting Services services and it will be seen that this
requirement leads to further subdivisions of the definition of Releases later
in the document.
2.3 IDENTIFICATION OF NEW BUSINESS OPPORTUNITIES
Releases are required to support changes of Service delivery in order to
implement business change. This business change will cover a wide range of
scale and complexity. For example:
i, adjustment to POCL trading variables, such as the price of a first class
stamp;
ii. changes to business rules, e.g. whether or not to print a receipt for
Automated Payment Transactions;
iii amending the format or information provided for existing transaction
types;
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 7 of 22
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
iv. franchising an existing outlet, or creating a new outlet;
v. implementing a new client for an existing service;
vi. introducing a new client transaction or new product ;
vii.re-engineering services within POCL's own operations,
The time, risk and cost of implementing such business changes will vary,
depending upon the extent of:
a) systems development;
b) type of reference data changes;
c) changes to ilnfrastructure;
) changes to support Services, such as Help Desk;
e) changes to documentation;
f) training requirements;
g) changes to marketing ceHateralmaterial;
h) network changes and telecommunications;
i) clients process re-engineering;
j) and so on.
All these changes must be taken into account in the process of defining new
business opportunities and setting priorities.
New business opportunities that require Releases-will require a studyto
prepareformal response from ICL Pathway detailing options and costs to
support and qualify the business case for POCL, leis anticipated that
doer t,-and-that th Jd form the basic ofa formal-ch:
vequest-Authorisation for Pathway to commence work will be subject to the
Change Control process.
2.4 CHANGE CONTROL
Where a proposed change to the software includes a change to the
contractual requirements or Contract Controlled Documents then the
change will have to be introduced by a Change Request from POCL ora
Change Proposal from Pathway. A proposed change becomes contractually
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 8 of 22
FUJO0118128
FUJ00118128
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: —_28/0616/07/99
CONFIDENCE
committed upon the presentation of aaChange-Control Note- (CCN) by
Pathway and its approval by POCL.
Pathway will also raise CCNs to introduce Software Infrastructure releases
in order to get POCL’s agreement to implementation.
tis not required that Pathway should-will not commit resources or
expenditure to the development and implementation of a change until the
CCN has been approved, other than the agreed level
assessment and preparation of the CCN.
In certain circumstances where a change is needed urgently it is possible to
implement using the Emergency Procedures defined in Section 3.3.
2.5 CONTRACTUAL AND FUTURE RELEASES
Release 1 was delivered in 3 phases: Release 1a (April 1997); Release 1b (May
1997); Release 1c (November 1997).
The CSR provides extended MIS functionality, introduces APS and EPOSS
functionality, and passes information to POCL’s interim TIP system for
accounting and reconciliation purposes. CSR forms the basis for contractual
acceptance, and will support the mounting of the Live Trial and so the
launching of National Rollout.
The CSRs will provide extended APS functionality, encompassing Smart
Card functionality, and-serves-to-sweep-up the ding
tractual commitments fom th Lagree: ind the
introduction of the Logistics Feeder Service LFS).
Further releases may be required on an ongoing basis. A number of new
products are already envisaged to extend the range of business functionality
available at the counter. There will, from time to time, be a need to refresh
or extend the supporting infrastructusesoftware infrastructure and the
ongoing maintenance of the services will necessitate fault correction.
Performance and Scalabi
to Component scalal
or Reference Data Releases,
3. CLASSIFICATION OF RELEASES + (Formatted: Bullets and Numbering J
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 9 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Refi PAISTRiogg
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: _28/0616/07/99
CONFIDENCE
Releases are classified as either Software Releases or Reference Data
Releases,
Releases, New Product Releases and Maintenance Releases,
Similarly, Reference Data releases fall into a number of categories according
to the impact and indicative timescales for implementation, The timescales
are intended to be indicative only, The classifications may also be reviewed
in the light of experience,
Emergency Procedures for releases of software are described,
6—-CLASSIFICATION OF RELEASES +——[Formatted: Bullets and Numbering }
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 10 of 22
FUJO0118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY — Ref PAISTRiogg
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 8/066 /07/99
CONFIDENCE
243.1 SOFTWARE RELEASES
Software Releases result from a number of different requirements to change
or to extend the Services.
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page u of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
This may be simply in order to maintain them in good working order,
addressing faults, and improving service levels-Such ize, Maintenance
Releases anetlente-atilcsapmatalraadaeseas
It may be that one or more additional areas of business functionality are
required, perhaps introducing an entirely new service. This would give rise
to a New Product Release.
The supporting infrastructureinfrastructure services will periodically need
to be -updated to take account of the infrastructuresoftware infrastructure
required to support new products , releases or workload changes. So,
depending on the nature of the changes required, different types of release
are demanded. The impact of such changes measured in terms of the time,
effort and risk and cost of implementing the changes will vary widely from
one change to another., and these serve to characterise the different types
of release.
Some changes will require extensive development effort and perhaps
involve co-ordinated changes to hardware/system ilnfrastructure and
support Servicesservices, while others require only minor localised software
development with little or no need for changes to the hardware/system
infrastructure or support services, Some can be implemented in a highly
segregated manner, without disrupting too many of the existing
components, whilst others may be highly invasive. As a consequence some
may require little in the way of re-integration effort, whilst others may
require a great deal. All will require extensive comprehensive and
systematic testing of the areas concerned.
Between these extremes there is a continuum of the possible scale and
complexity of implementation of changes, but according to their essential
characteristics, all will fall into their respective categories of either New
Product Release or InfrastructureSoftware Infrastructure Release.
Because of the development, integration and testing lead times involved
with InfrastructureSoftware Infrastructure Releases, it is planned that a
maximum of one a year could be implemented. Several New Product
Releases may be planned each year, but in general releases should be spread
out at least 3 months apart, and avoiding the busy Christmas period where
POCL outlets are involved. Section 6 provides more information on
timescales.
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 12 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
aettag.1.1 NEW PRODUCT RELEASES
Anew product release may contain one or more business products, An
approved CCN will be required to develop and implement a new business
product
The principal characteristics of the changes that form a New Product.
Release are as follows:
a) Non-invasive changes, requiring little or no revision to the existing
components of the services already operating
b
May be implemented by the addition of discrete components,
perhaps entire new services, highly segregated from the existing
components, requiring little or no re-configuring of the existing
services and their interfaces
¢)
May be tested largely in isolation
d) Imposes little or no re-integration of existing services
e
Involves little or no migration from existing services
f) Can be implemented with a backward compatible path, allowing
gradual introduction across the network of POCL outlets, and as
such permits the operation of a limited pilot
g) Usually introduces significant new business functionality, and so
requires significant levels of user training, which implies a
requirement for a gradual training programme
hy
Several can be developed in parallel by virtue of the segregation, are
typically of short duration, and can be implemented flexibly, either
as separate releases or combined as one release
Reference Data changes will be included within the release
+ [Formatted: Bullets and Numbering j
a-41,23.1.2_ SOFTWARE INFRASTRUCTURE RELEASES
An approved CCN will be required to introduce a Software Infrastructure
Release.
The principal characteristics of the changes that form a Softwaren
Infrastructure Release are as follows:
a) Invasive changes, requiring significant revision to existing
components of the services already operating
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 13 of 22
FUJO0118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Ref: -PA/STR/003
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
b
Major infrastructure components refreshed, or significant re-
configuring of the existing services and their interfaces
GS
d
e
Extensive service-wide regression testing required
Imposes significant levels of re-integration of existing services
May involve migration from existing service state
£) May introduce major enhancements to existing business
functionality
Cannot easily be developed in parallel because of the re-integration aspects,
are typically of long duration, and must be implemented as planned and
separate from other releases if possible, Because of the long lead-times such
changes are generally best grouped together as one big release.
3.1.3, MAINTENANCE RELEASES (Formatted: Bullets and Numbering )
From time to time there will be a need for Releases of new Software and
data in order to remove faults or to improve Service Levels without
changing business functionality or business data. Such Releases are called
Maintenance Releases.
Maintenance Releases fall into three main types:
«Performance / capacity improvements (CCN required) +—-{Formatted: Bullets and Numbering )
¢ Scheduled releases containing fault fixes combined with small functional
changes (CCN required’
e U it fault fixes (No CCN required.
Maintenance Releases will range in scope from very minor Releases which
require little regression testing to major Releases that may require full
Regression testing and the recalibration of SLA timings. The requirement
for testing will be determined by reference to assessed technical and
operational impacts for each overall Release and notified to POCL.
Maintenance Releases shall be planned and implemented under Pathway’s
management control.
Minor maintenance releases that are designed solely to rectify faults
reported to ICL Pathway through the incident and problem management
process and that result in no associated changes to designed system
functionality, process, procedure, training or documentation (bug fixes),
will be applied to the system as soon as they have been authorised by ICL
Pathway Customer Service Release Management. POCL Business Service
ent will be notified i diately entries made i i
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 14 of 22
FUJO0118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Res PAISTRiogg
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
Problem Management database, Notification that such releases have been
applied will be given at the regular Horizon Service Review Forum meetings
and will be documented in the Horizon Service Review Book, Although not
subject to the Change Control Procedure POCL will be given the
opportunity to assess the content of the release in terms of possible business
impact.
All other Maintenance Releases shall be subject to the Change Control
rocedure; and the Emergency Change procedure (Section 3.3) shall be
invoked only when immediate action is needed.
2423.2 REFERENCE DATA RELEASES
Reference Data changes fall into three main categories:
Those governed by the Operational Business Change Process + [Formatted: Bullets and Numbering )
¢ Those required as a result of a fault reported via the incident and
problem management process
Those required to implement a business/functional change which will be
released in conjunction with a New Product or Maintenance Release and
are subject to the normal Change Control Process defined in section 2.4.
POCL Reference data releases are governed by the Operational Business
Change processes where the required business change has been defined and
agreed in advance.-Business changes that are implemented through
Ref Data changes that do-not fall into the definition-of Operational
Bacinase 8 eraers lohenas Conuel
s ¥ s #
The purpose of Operational Business Change (OBC) is to predefine
common changes to the POCL business that occur often and require a short
implementation cycle e.g. changing the price of a bus ticket. By pre-defining
these changes the impacting cycle of the change is greatly reduced and the
implementation actions and time scales can be defined in advance.
Operational Business Changes are initiated through the receipt of an OBC
request form and Reference Data files, as defined in the process documents.
Reference Data Releases (under OBC) are broken down into more detailed
change types according to the impact and indicative timescales for
implementation. The change types are documented in the "ICL
Pathway/POCL Interface Agreement for Operation Business Change -
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 15 of 22
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
Product" document. The interface agreement identifies specific types of
business change in advance so that their characteristics (e.g. timescales,
dependencies and responsibilities) can be understood by POCL when
managing their business. These would be to support, for example,
negotiation with clients and service management processes,
The broad categories of change type for Operational Business Change are:
+ Outlet Advanced - requires additional activity from ICL Pathway e.g.
relocating an outlet
+ Outlet Basic - Class 1 reference data change only e.g. change of phone
number
+ Product Advanced - requires additional activity from ICL Pathway
e.g. creation of new buttons on the counter menu
+ Product Basic - Class 1 reference data change only e.g. change to the
price of a bus ticket.
Class 1 Reference Data is reference data that has no additional impact on the
Horizion system, although verification of the new data by POCL is required
for High Risk changes.
3.3 EMERGENCY PROCEDURES
Schedule Aos allows that if Pathway considers that any change is necessary
in order for it to comply with its obligations under the Agreement and there
is insufficient time to comply with the procedures then Pathway shall be
entitled to proceed with such change, provided that it shall as soon as
practicable provide POCL with a CCN for retrospective change. Such
change shall be subject to the procedures described in Schedule Aos, and if
POCL, acting reasonably, do not agree to such change, such change shall be
invalid and Pathway shall at its own expense promptly take all steps
necessary to reverse and remove the effects of such change,
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 16 of 22
FUJO0118128
FUJ00118128
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
3-4._ DEFINITION OF RELEASE CONTENT
3-44.1_RELEASE CONTROL & CONTENT
The Requirement and Solution 476 refers to the testing, control and
approval of Releases while the testing of Releases is described in Pathway’s
testing strategies and plans.
The content of a Release (other than those exclusively containing Fault
fixes) is determined through appropriate documentation baselined by one
or more CCNs that shall be approved prior to a predetermined cut-off date
for each Release, The purpose of this cut-off date is to ensure that the
changes required in each Release are fully defined in time for the start of
detailed design, development and testing. After the cut-off date changes
may only be introduced under Change Control.
Requirement 476 requires POCL’s approval (such approval not being
unreasonably withheld) to the:
* contents of any release
© upgrade path for any release
© timing of the distribution of any release
© timing of the activation of any release
The definition of release content for any specific Release (other than those
exclusively containing Fault fixes), and the development of any more
detailed specifications, will need to take into account, amongst other things,
the business priorities of the business changes in that Release and the
alignment with associated Authority POCL and Client systems. Processes
for release content definition are to be developed to address such issues.
Processes will also be defined to address the co-ordinated development,
trialing and introduction of Releases where these need to be aligned with
POCL system releases e.g. TIP.
42-EMERGENCY PROCEDURES
hiedule-Ace allows thalsP pot decals. hang
pder for itt ply-with its obligations under the Agreement-and there
paiibient es ply-with the procedures then Path shall
titled to .d-with such change, provided that it shall
ticable provide POCL with a CCN for retrospective change-Such
(Formatted Bullets ond Numbering }
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 17 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Refi PAISTRiogg
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
Jhange shall-be subject tothe procedures described in Schedule A dif
POCL, acting bly, do-not agree to such ch: Leahy hall
lid and Pathway-shall at it pence promptly take all ct
yt ciosHorst macho
5:_MAINTENANCE RELEASES ‘(Formatted Bullets and Numbering }
From time to time there will b ee RalesvardPecSaley d
data in order t faults or to improve Service Levels without
changing business functionality or business data- Such Rel Hed
ising. ¥ -
Maintenance Releases.
Maint Rele ill me ps fy ¥ Rel. thich
~ (Formatted: Bullets and Numbering
6.5. RELEASE SCHEDULE
6.15.1. SOFTWARE RELEASES
Pathway plans to implement approved changes-CCNs in ene-ormorea
number of Software Releases each year, disregarding these releases covered
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 18 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
under Maintenance Releases (section-5} and Emergency Procedures (section
433).
In scheduling these releases a number of factors need to be considered.
Due to the long lead-times involved in InfrastructureSoftware Infrastructure
Releases, largely stemming from the need to perform extensive re-
integration, it is impractical to plan for more than one
InfrastructureSoftware Infrastructure Release in a twelve month period.
Whatever the release type concerned, implementation periods need to be
spread out to avoid conflict. The critical interval can be judged from the
experience of other large service contracts, Experience dictates that they
should be at least 3 months apart to achieve the optimum balance between
the business imperative to introduce new functionality and the risk of
adverse impact on Service Levels resulting from excessive rates of change.
Implementations involving the POCL outlets should be planned to avoid
their busy Christmas period wherever possible.
New Product Releases, and some JnfrastructureSoftware Infrastructure
Releases will involve a phased implementation period, with user training
activities and possibly the running of a Pilot. These post go-live activities
need to be scheduled in and taken into consideration regarding the
scheduling of subsequent releases.
Under certain circumstances it may be advantageous to all parties to cluster
a number of releases together into a single implementation period. This is
particularly relevant to New Product Releases. The frequency of Releases
will be reviewed in line with experience gained during live operation. The
current view is that between 2 and 3 releases are likely each year,
comprising including one InfrastructureSoftware Infrastructure release and
one or two New Product Releases. (These-Each New Product Release
maymay-be- combined seleases include one or more business products,
depending on the size and the complexity of each.}
The relationship between the release definition activities and the ultimate
implementation of the release is illustrated below:
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 19 of 22
FUJ00118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
Ro
Jeasen
I baselines
Construct
Release 'n
IContent Definition
Fig 6.1 - Release Planning
Changes which have been approved within the Validity Period of the
associated CCN will be included within the Release Contents Definition for
the Release stated. Three months are allowed for the approval of each —
Release Contents Definition which is then baselined while the Releas
implemented. Thus in steady state, there will be at any time, one live
Release (Release “n”) and two new Releases ( n+1 and n42) at different
stages of design and implementation.
The table below illustrates a possible timetable for, say, a Software
[ise oon No Tad Seeterel
the Autumn,; tthen. avoiding g the Christmas period, a combined £
comprising. maybe 2 New: Products aust tieacaa lnteasies eine Release
SSestal : s, delivered in the following
Suing,
Release I Design I Developme I Test & Implement I Release
Contents nt Integratio Gates
Baseline n
vJanuary I 1Jan- 1Feb- vApr- 1Sep- 1 October
28 Feb 31May 30 Sep 30 Nov
uly aJuly - 31 [Aug - 31 I 1Nov - Mar - TApril
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 20 of 22
FUJO0118128
FUJ00118128
ICL Pathway PATHWAY RELEASE POLICY Refi PAISTRiogg
Version: 3.05.0
COMPANY.COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
[ I July Oct 28 Feb 31 May
Fig 6.2 - Release Timetable
In constructing the illustrative timetable shown above, Pathway has
assumed that the Test & Integration period will encompass a period of
POCL ene-month-(not exclusive}confidence testing-within-which (if
required by POCL) ‘ 3 -
POC Gnd the any fisetostng tthe Relotse thet
may-be required. It is anticipated that the testing and product acceptance
processes after the initial releases will be rationalised by mutual agreement.
For the avoidance of doubt, if an element of the Services under test fails its
testing criteria and it is decided by POCL and Pathway to withdraw it in
order to maintain Release timescales, then that failed element will be
included in the next Release unless otherwise agreed.
5.1.1_ SOFTWARE DISTRIBUTION AND ACTIVATION + ——(Formatted: Bullets and Numbering )
Some software releases will involve a phased implementation period, with
user training activities and possibly a pilot. In these cases there will be a
schedule of software activation agreed with POCL.
The new software for a release will normally be distributed to the outlets
over a period of time (dependent on the size of the software release) prior to
activation. Software release activation will normally be done over a week-
end, but where contact cannot be made with any outlets the activation will
necessarily span a few days. Both Data Centres will normally be upgraded
at the point of Software release activation,
Urgent fault fix maintenance releases may be done overnight during the
week if required.
6.25.2 REFERENCE DATA DISTRIBUTION (Formatted: Bullets and Numbering )
Indicative timescales for the implementation of the different classes of
Reference Data Release are provided in document "ICL Pathway/POCL
Interface Agreement for Operation Business Change - Product".
Reference Data changes initiated as part of fault fixes or new products will
be an integral part of the New Product or Maintenance release of which
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 21 of 22
ICL Pathway PATHWAY RELEASE POLICY Reft PAISTRIogs
Version: 3.05.0
COMPANY-COMMERCIAL IN Date: 28/0616/07/99
CONFIDENCE
they form a part and will be scheduled in accordance with the agreed
release date,
© 1999 ICL Pathway Ltd COMPANY-COMMERCIAL IN CONFIDENCE Page 22 of 22
FUJO0118128
FUJ00118128