FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
Document Title: Pathway Release Policy
Document Type: Strategy Document
Abstract: This document defines the Pathway policy for the
identification and planning of new Releases of
Software and Data.
Distribution: Pathway Management Team
Document Status: Approved
Document Predecessor: 1.3
Author: Jim Morley, updated by John Hunt
COMMERCIAL IN-CONFIDENCE
Page 1
ICL Pathway Ref:
PATHWAY RELEASE POLICY Version:
Date:
FUJ00232433
FUJ00232433
PA/STR/0003
2.0
29/03/99
Contents List
1. DOCUMENT CONTROL
1,1 DOCUMENT HISTORY
1.2 CHANGES FORECAST
1.3 ABBREVIATIONS USED
2. INTRODUCTION
2.1 PURPOSE
2.2 DEFINITION OF RELEASE
2.3 IDENTIFICATION OF NEW BUSINESS OPPORTUNITIES
2.4 CHANGE CONTROL
2.5 INITIAL AND FUTURE REL.
(SES
3. CLASSIFICATION OF RELEASES
3.1 SOFTWARE RELEASES
3.2 REFERENCE DATA RELEASES:
4, DEFINITION OF RELEASE CONTENT
4.1 DEFINITION OF CHANGES
4.2 PREPARATION OF CCN
4.3 CCN EVALUATION AND DECISION
4.4 RELEASE CONTROL & CONTENT
4.5 EMERGENCY PROCEDURES:
5. MAINTENANCE RELEASES
6. RELEASE SCHEDULE
6.1 SOFTWARE RELEASES
6.2 EXCEPTIONAL RELEASES
6.3 REFERENCE DATA DISTRIBUTION
COMMERCIAL IN-CONFIDENCE
Page 2
a as
ro
25
25
28
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
1. DOCUMENT CONTROL
1.4 DOCUMENT HISTORY
Version I Date Reason
0.1 20/10/96 First Draft for Pathway internal use only
0.2 30/10/96 Second draft following application of Pathway comments.
0.3 30/10/96 Draft for issue to the PDA.
0.4 12/11/96 Updated following PDA comments through Michael
Purchase.
0.5 17/11/96 Updated following PDA & Sponsor comments received
through Michael Purchase.
0.6 18/11/96 Further comments applied from Pathway and PDA.
0.7 24/11/96 Further comments applied from PDA.
1.0 26/11/96 Further comments applied from POCL.
1.1 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
1.3 1/5/98 Brought up to date to recognise differences between
infrastructure and new product releases
2.0 29/03/99 Applied comments and approved ready for issue
1.2 CHANGES FORECAST
None.
1.3 ABBREVIATIONS USED
The terms and abbreviations used in this document are those
defined in the Authorities’ Agreement (Schedule A01).
COMMERCIAL IN-CONFIDENCE
Page 3
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
2. INTRODUCTION
2.1 PURPOSE
This document describes Pathway’s policy for identifying and
planning the development of new Releases of Software and data.
Pathway aims to do this in a manner that is responsive to the
business needs of the Authorities and of Pathway, and which also
conforms to the provisions of the Related Agreements. Overall, it
aims to:
a) establish the principles associated with releases of Pathway
Services in the context of the Related Agreements;
a) establish the principles for regular and on-going Releases of the
Pathway systems and Services; including infrastructure
releases, new product releases and maintenance releases:
a) 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;
a) establish indicative timescales for the different types of Release
in order to put these into context, while recognising that these
may need review when the underlying processes have been
detailed.
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 Services. It will be supported by the development of
associated processes covering the qualification and prioritisation of
business opportunities, the definition of release content, service
management and reference data management in conjunction with
the Authorities. It is important to note that the commercial
incentives to introduce new products and Service improvements as
soon as possible commensurate with proper quality and other
process controls are shared by Pathway and the Authorities alike.
The Score Card mechanism rewards Pathway for volume and
functionality, so it is very much in their interests to facilitate new
Release content which meets business needs.
COMMERCIAL IN-CONFIDENCE
Page 4
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
2.2 DEFINITION OF RELEASE
The Related Agreements define 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 Infrastructure and Supporting 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;
i. changes to business rules, e.g. whether or not to print a receipt
for Automated Payment Transactions;
i. amending the format or information provided for existing
transaction types;
i. franchising an existing outlet, or creating a new outlet;
i. implementing a new client for an existing service;
i. introducing a new client transaction or new product ;
i. re-engineering services within the Authorities’ own operations.
The time, risk and cost of implementing such business changes will
vary, depending upon the extent of:
a) systems development;
a) type of reference data changes;
a) changes to Infrastructure;
a) changes to support Services, such as Help Desk;
a) changes to documentation;
COMMERCIAL IN-CONFIDENCE
Page 5
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
a) training requirements;
a) changes to marketing collateral;
a) network changes and telecommunications;
a) clients process re-engineering;
a) 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
study to prepare and qualify the business case for the Authorities
and for Pathway. This process has yet to be defined, but Pathway
wishes to participate in this work in a spirit of business partnership.
It is anticipated that successful studies will result in an agreed
Business Requirements Definition document, and that this would
form the basis of a formal change request.
2.4 CHANGE CONTROL
The delivery of new or changed Software and Services beyond that
committed in the Related Agreements is subject to Change Control
under Clauses 101.3, and 101.4, and Schedule A05 of, the
Authorities’ Agreement, the POCL Agreement and the DSS
Agreement. Changes that require modification to the Related
Agreements are approved under Clause 101.3 while conforming
changes are approved under Clause 101.4. All Releases except
those described as Class 1 Reference Data Releases at section
3.2.1 below are subject to Change Control. It is emphasised here
that a new Release is the instrument of underlying business
change, and it is this business change that is primarily the subject
of Change Control.
A proposed change becomes contractually committed upon the
presentation of a Change Control Note (CCN) by Pathway and its
approval by the Authorities. The CCN as defined by Schedule A05
requires a detailed explanation of the requirements and
commercial impact of each change together with commitments to
timescales and costs. The Score Card charging mechanism in
Schedule AO6 of the Related Agreements anticipates extension
and re-engineering of products using the existing infrastructure,
and is designed to provide Pathway with incentives for business
COMMERCIAL IN-CONFIDENCE
Page 6
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
change. Section 3 provides further details on the expectation of
Score Card changes for different types of Release.
It is not required that Pathway should commit resources or
expenditure to the development and implementation of a change
until the CCN has been approved. However it is possible that the
lack of a complete specification of a Client's requirements, or the
lack of commercial commitment by a Client at an early stage of
negotiations, could prejudice the time to market for a new Service.
Equivalent circumstances may also occur for BA. To help avoid
such delays, Pathway proposes that the commercial risk that is
inherent in incomplete requirements or Client commitment may be
shared by the relevant Authority and Pathway by mutual
agreement. Clearly the willingness of either party to accept such
risks and the apportionment of the risk between them will be
determined by their perception of the business opportunities. The
acceptance and apportionment of such risks is the key to enable
the time to market for new services to be shortened significantly for
suitable business opportunities. The agreement of the acceptance
and apportionment of any such risks, including any special
conditions for the cancellation of the change, shall be recorded
within the “Risk” section of the CCN.
The value of the potential risks of cancellation identified in the
preceding paragraph will be judged by reference to existing Service
Definitions and the Score Card in Schedule A06 of the Related
Agreements. To the extent that new facilities fall within the scope
of the Basic Score Card options, the potential cost of cancellation
is envisaged to be low. Other additional Services (typically where
no Score Card column exists) will require greater definition before
commencement of work, so that Score Card revisions can be
agreed. The level of assessed risk in such cases will generally be
higher than for an extension of Basic Score Card unless such pre-
work is completed and agreed in advance.
2.5 INITIAL AND FUTURE RELEASES
A pilot system, “IGL”, was delivered first into a single Post Office
(September 1996) and then extended to 10 Post Offices (October
1996).
Schedule B7 of the Authorities’ Agreement describes the initial
COMMERCIAL IN-CONFIDENCE
Page 7
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
functionality of the Services delivered in two Releases. These are
henceforth referred to as Release 1 and Release 2.
Release 2 enables the CONTRACTOR and the AUTHORITIES to
introduce additional functionality at around October 1997, the
release will also be defined in a Release Content Description.
COMMERCIAL IN-CONFIDENCE
Page 8
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
1 was delivered in 3 phases: Release 1a (April 1997); Release 1b
(May 1997); Release 1c (November 1997). Release 1 provided
OBCS, BPS and MIS functionality, interfacing with a range of
CAPS releases, and putting in place a foundation of infrastructure
services to support later releases. It was delivered into 205 Post
Offices.
New Release 2 will provide extended BPS and MIS functionality,
introduces APS and EPOSS functionality, and passes information
to POCL’s interim TIP system for accounting and reconciliation
purposes. New Release 2 forms the basis for initial contractual
acceptance, and will support the mounting of the Live Trial and so
the launching of National Rollout.
Release 2+ is planned to form the basis for concluding contractual
acceptance. It will provide extended APS functionality,
encompassing Smart Card functionality, and serves to sweep up
the remaining outstanding contractual commitments from the
original agreements.
Further releases will 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 infrastructure
services or to significantly enhance existing functionality. The
ongoing maintenance of the services will necessitate fault
correction and service level improvement.
COMMERCIAL IN-CONFIDENCE
Page 9
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/O003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
3. CLASSIFICATION OF RELEASES
Releases are classified as either Software Releases or Reference
Data Releases.
Software Releases fall into 3 main categories: Infrastructure
Releases, New Product Releases, and Maintenance Releases. In
this section we deal with Infrastructure Releases and New Product
Releases. Maintenance Releases are dealt with separately under
section 5.
Similarly, Reference Data Releases fall into a number of categories
according to the impact and indicative timescales for
implementation. It is emphasised that the classifications are not
(and cannot be) exhaustive and the timescales are intended to be
indicative only. Pathway will provide firm timescales for each
Release, on a case by case basis, taking into account, amongst
other things, the business priorities for the associated changes and
relationships with changes to related Authorities and Client
systems.
Similarly, Reference Data releases fall into a number of categories
according to the impact and indicative timescales for
implementation. It is emphasised that the classifications are not
exhaustive and the timescales are intended to be indicative only.
These classifications may be refined through the process of
mapping specific types of business change to the proposed
classes; and this will be developed through the associated process
documents that will support the Release Policy and the clarification
of business requirements for change. The classifications and
processes may also be reviewed in the light of experience.
In the context of new business development and new automation of
existing business, the aim is to develop generic functionality
through Software Releases, and to introduce this functionality for
clients through faster and more frequent Reference Data Releases.
More generally, Pathway and the Authorities will work together to
clarify requirements for anticipated types of change in order to
achieve the best possible flexibility in the Services.
COMMERCIAL IN-CONFIDENCE
Page 10
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
3.1 SOFTWARE RELEASES
Software Releases result from a number of different requirements
to change or extend the Services.
This may be simply in order to maintain them in good working
order, addressing faults, and improving service levels. Such
Maintenance Releases are dealt with separately under section 5.
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 infrastructure services will periodically need to be
refreshed, and existing functionality may on occasion require
significant revision or enhancement, and this would give rise to an
Infrastructure Release.
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 Infrastructure and support
Services, while others require only minor localised software
development with little or no need for changes to the 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 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 Infrastructure
Release. This is important to recognise because certain changes
clash in this respect and do not lie well together in the same
release, typically giving rise to problems in implementation or
migration. Such changes will need to be targeted for separate
releases to avoid such problems. These various characteristics are
described in more detail below.
COMMERCIAL IN-CONFIDENCE
Page 11
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
The impact of software changes will be evaluated and stated ina
Change Proposal (CP). Where a change is requested or
recommended by the Authorities, then a Change Request (CR) and
Change Control Note (CCN) would also be required.
Because of the development, integration and testing lead times
involved with 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.
3.1.1 NEW PRODUCT RELEASES
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
a) 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
Imposes little or no re-integration of existing services
Involves little or no migration from existing services
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
a) Usually introduces significant new business functionality,
and so requires significant levels of user training, which
implies a requirement for a gradual training programme
a) 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
COMMERCIAL IN-CONFIDENCE
Page 12
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
3.1.2 3.1.2 INFRASTRUCTURE RELEASES
The principal characteristics of the changes that form an
Infrastructure Release are as follows:
a) Invasive changes, requiring significant revision to the
existing components of the services already operating
a) Major infrastructure components refreshed, or significant re-
configuring of the existing services and their interfaces
a) Extensive service-wide regression testing required
a) Imposes significant levels of re-integration of existing
services
a) May involve migration from existing service state
a) May introduce major enhancements to existing business
functionality
a) 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.
Beyond these defining characteristics of the changes that may
comprise an Infrastructure Release, a number of further attributes
serve to separate Infrastructure Releases into two distinct types
referred to here as type 1 and type 2.
Type 1 Infrastructure Releases:
I. No straightforward backward compatible path, prohibiting any
gradual introduction across the network of POCL outlets
I. Therefore does not readily support a limited Pilot or a gradual
user training programme, which in general then implies that the
changes involved require little or no user training
I. Must be capable of delivery entirely ‘down the wire’ with little or
no intervention at the outlet
Type 2 Infrastructure Releases:
COMMERCIAL IN-CONFIDENCE
Page 13
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 2.0
Date: 29/03/99
I. Can be implemented with a backward compatible path, allowing
gradual introduction across the network of POCL outlets
I. Therefore can support a limited Pilot and a gradual user training
programme
I. May be delivered/configured involving intervention at the outlet,
though delivery ‘down the wire’ preferable.
It is clear that the nature of implementation of a Type 1
Infrastructure Release clashes violently with that of a New Product
Release. The two cannot be mixed. Essentially one cannot be
phased at the POCL outlet whilst the other can, with obvious
implications regarding user training, software
distribution/activation/configuration, and the feasibility of
introducing the changes as a Pilot.
Care must be taken in planning the content of releases to avoid
these clashes. Changes that force a Type 1 style of implementation
cannot be targeted at the same release as New Product changes,
and vice versa.
Sometimes the requirements of a particular set of business
changes appear on the face of it to cause such a clash. A sort of
‘catch 22’ where, say, a gradual training programme and a pilot are
deemed essential, but where associated infrastructure support
services need to be significantly enhanced in a synchronised
manner across a number of platforms including the counters. The
solution is to de-couple the conflicting elements to avoid the clash,
say, by laying down the supporting services in an infrastructure
release in advance of introducing the new business functionality.
COMMERCIAL IN-CONFIDENCE
Page 14
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
The following table, at a high level, gives a good rule of thumb for
the various combinations when targeting changes at releases and
in planning release schedules:
New Product I Infrastructure I Infrastructure
Release Release - Type I Release - Type
1 2
New Product OK Incompatible OK
Release
Infrastructure 5 F
Release - Type Incompatible OK Care Required
1
Infrastructure OK Care Required OK
Release - Type
2
3.2 3.2
REFERENCE DATA RELEASES
Reference Data Releases are broken down into more detailed
classes according to the impact and indicative timescales for
implementation. The classes are numbered 1 to 5 in order of
complexity and timescale to implement. The different classes are
not mutually exclusive and compound Releases consisting of
elements from different classes can be envisaged. In these
circumstances the Release taken as a whole is classified according
to the class of the highest element within the Release. Generally
the class of a Release (other than for Class 1 Releases) will be
advised by Pathway by analysis of the business requirement,
however the aim will be to identify specific types of business
change in advance so that their characteristics (e.g. timescales,
dependencies and responsibilities) can be understood by the
Authorities when managing their businesses. These would be to
support, for example, negotiation with clients and service
management processes.
Reference data releases will generally exploit existing Score Card
columns and so should not require pricing changes unless a
change to infrastructure is called for or specific limits are breached.
COMMERCIAL IN-CONFIDENCE
Page 15
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
3.2.1 3.2.1
3.2.2 3.2.2
In some instances, co-ordinated attention will need to be paid to
migration from and parallel operation with existing services. For
example, the APS Client Take-on plan includes the on-going
introduction of clients to the extant POCL AP facilities. Hence this
is a special case, and will need to be planned separately from
other changes enabled by reference data in order to ensure the
consistent provision of products across all POCL outlets.
STANDARD REFERENCE DATA CHANGES (CLASS 1 )
This represents the simplest and quickest type of Release to
implement and includes Immediate Reference Data and Advance
Reference data as described in the Related Agreements. Class 1
changes apply only to the value of those defined Reference Data
fields which are conformant with the Service Definitions, the SADD
and other Controlled Documents. No Software is developed and
there are no physical or logistical constraints associated with
Service delivery. Typically, such changes will be characterised by
simple numeric adjustments to POCL trading variables such as the
price of a first class stamp.
The potential for distribution is overnight for use the next day.
Service Level targets apply to this class of Reference Data and
there will be no impact on the Score Card.
This is the only class of Reference Data that is implemented
outside the Change Control procedure.
BUSINESS RULES CHANGES (CLASS 2)
These are relatively simple changes to the permitted values of
Reference Data fields which define how the services operate. Such
changes will require a change to the Service Definitions, SADD
and/or other controlled documents.
No Software needs to be developed and there are no logistical
constraints associated with Service delivery. Testing of Reference
Data parameter changes may be required and also minor changes
to documentation. Typically, such changes will be characterised by
changes to the business rules. An example could be the
requirement, whether or not, to print a receipt for Automated
Payment Transactions. Another example is change to the rules
governing the Extended Verification Procedure (EVP).
COMMERCIAL IN-CONFIDENCE
Page 16
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
3.2.3 3.2.3
The potential for distribution is within one month (and could be
within a week for straightforward cases) from approval of the
Change Control Note, allowing time for any changes to Pathway or
Authorities’ business rules as identified in the impact analysis.
It is unlikely that any change to the Score Card will be required.
COMMERCIAL IN-CONFIDENCE
Page 17
ICL Pathway
FUJ00232433
FUJ00232433
Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
LOGISTICALLY CONSTRAINED CHANGES (CLASS 3)
This represents a class of change that is subject to logistical
constraints on Service delivery. Typically these are physical
changes, such as refurbishment of premises and installation and
testing of counter equipment. Some examples are:
. Franchising an existing Outlet
. Creating a new Outlet
3.2.4 3.2.4
The potential for distribution is within one month from approval of
the Change Control Note, although the actual timescale will be in
line with the associated change in service delivery.
Unless physical limits are breached (Schedule AO06, Annex 4) or
new infrastructure facilities required, it is unlikely that any change
to the Scorecard will be required.
EXTENDED FUNCTIONALITY (CLASS 4)
Class 4 covers more extensive changes which reuse existing
Software in the same business context or modify functionality and
which can be activated by means of Reference Data without new
software development. Examples of Class 4 changes include
modifying the user interface for existing transactions, amending the
format of outputs and re-using existing transaction types for new
Clients with a new set of Reference Data. By their nature, Class 4
changes will probably require testing, data take-on, revisions to
marketing collateral and user documentation, and user training.
The expected turnaround time will vary from case to case and will
need to be determined by impact analysis during the Change
Control process. A significant determinant of timescales will be the
need (or not) for a new Client link. Without such a need,
straightforward transaction type reuse could be envisaged in one
month. Implementing a new Client link could take up to 4 months
from approval of the CCN. Other Class 4 changes are likely to take
between these two extremes.
In most cases no change to the Scorecard will be required other
than to include new lines as appropriate, but this will need to be
verified during Change Control.
COMMERCIAL IN-CONFIDENCE
Page 18
FUJ00232433
FUJ00232433
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 2.0
Date: 29/03/99
3.2.5 3.2.5 NEW FUNCTIONALITY (CLASS 5)
This class of Reference Data Release is directly dependant upon a
related Software Release and is associated with the development
and testing of new Software. Examples are:
. New (or amended) Service requiring changed Software.
. New (or amended) Service requiring a new type of Reference Data.
COMMERCIAL IN-CONFIDENCE
Page 19