FUJ00079076
FUJ00079076
This document is issued by ICL Pathway in response to the document from Horizon received on 16/12/98 concerning the POCL Infrastructure
Acceptance Specification. This document continues the comment / response cycle with respect to version 1.4 of the Acceptance
Specification. Please note that version 1.5 has been issued and version 1.6 is in preparation following agreements reached, most recently at
the review meeting of 16/12/98.
Dave Cooke
ICL Pathway Acceptance Test Manager - POCL Infrastructure
17/12/98
No. I Para I Authors/Document Champions Initial response ICL Pathway response
No. I Comment Explanation
1 Gen. I The solutions are all contained in the Where is the technical solution This is contained in the SADD and the
relevant POCL, DSS and Joint schedules. I documented? Technical Environment Description.
2. Gen. I This approach was agreed between ICL Noted. No action
Pathway and the PDA as the way to
identify functional discreteness for the
purposes of Acceptance testing. However,
ICL Pathway wholly support the view that
each criterion must be considered within
the original business context of the
Requirement.
3. I Gen. I Acceptance is a single activity as defined I Who - specifically - is represented on I This is a Horizon Programme
in the Authorities Agreement Schedule this Forum? managed forum. The ICL Pathway
A07. On-going service monitoring is Director of Customer Services attends
managed by the Horizon Service Review together with a number of his service
Forum. managers.
4. Gen. I POCL, DSS and ICL Pathway have This does not address the comment, Which criterion is this comment related
already completed the Direct Interface i.e. what about failure and contingency I to? The resilience of the
Test phase which is concerned with file where data cannot be passed across__I infrastructure is covered in 467/2 & 4.
exchanges between ICL Pathway and the I an interface or where it fails during As stated, local arrangements will be
AUTHORITIES. transmission? agreed between ICL Pathway When
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
1 of 1
and / or POCL.
FUJ00079076
FUJ00079076
electronic data transfer is not available
due to circumstances outside of ICL
Pathways control then the force
majeure clause 605 in Clauses Joint
v8.0 will apply.
5. Gen. I Requirement 830 is the main requirement I In light of this the Security ATS will Noted
concerned with Contingency. This is need to be examined to ascertain
included within the Security Acceptance sufficient coverage of this attribute
Specification and includes references to which was envisaged to be contained
various contingency procedures. within this ATS - this may result in new
comments on the Security ATS.
6. I Gen. I Given the complexities of the Service and I Noted that the Authorities anticipated I Which criterion is this comment related
system environments within ICL Pathway, I a sub-100% availability. Due to the to?
DSS and POCL, the numbers of types of complexity, the Authorities anticipate a
failures that may have a business impact is I greater need for analysis rather than There is no obligation on ICL Pathway
probably incalculable. using the complexity as a reason to to conduct an external impact analysis
omit analysis of failure. Not every of potential infrastructure failure
POCL's own Acceptance Test Managers _I failure is anticipated to be covered but I events, whether complex or not.
are better placed to assess the business the impacts on the infrastructure, e.g.
impact of Service failure and the adequacy I a Network Interface Card, ethernet ICL Pathway and POCL have agreed
of the recovery and contingency connector, ethernet cable, in-outlet the procedures to be followed in the
procedures within their own area of hub failure etc, would all result in a event of equipment failure in an outlet
specialisation. ICL Pathway do not feel I node becoming isolated. Treatment of I and these are recorded in the various
able to comment on the commercial this isolation would be expected to be I PPDs.
implications to POCL or their Clients, covered.
particularly when the various Service Level In the particular instance mentioned,
Agreements recognise that Service an isolated node would be detected
operation of less than 100% may be a and appropriate warnings would be
reality for periods of time. displayed to the user (criterion 953/2).
7. Gen. I This issue has been addressed in We, POCL, need to see this No action
correspondence to Bob Booth of correspondence, until which the
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
2 of 1
and / or POCL.
FUJ00079076
FUJ00079076
2/12/1998. original comment remains, i.e. this
spec cannot be signed off whilst the
OPS/TMS boundary issue is still under
discussion unless an agreed caveat is
provided.
8. Gen. I This will be agreed as part of the Noted. No action
programme planning activity for NR2+.
9 467/ I Formally the boundary between OPS and_I The “formally” commencement of the Test (a) covers the loss of the ISDN
2 TMS is defined as a programmatic API response pre-judges the outcome of line.
with well-defined success or failure events. I the correspondence on this matter.
These tests provide POCL with further Not withstanding that, the test
evidence of the qualities of the data environment can relatively easily
transfer mechanisms between an outlet simulate a line loss (example chosen)
and the ICL Pathway data-centre. Since by unplugging the ISDN cable for
mid-stream failures will most typically occur I example. Comment therefore re-
within the British Telecom exchanges or in I iterated.
the physical cables running to an outlet, it
not clear what practical tests ICL Pathway
could perform.
10. I 467/ I As in 467/2, the absence of an alternate As point 9. Plus, it should be noted The proposed tests cover failure to
4 telecomms route can only occur if the that the criterion is “network or node” _I network or node.
physical circuits and exchanges offered by I which allows some resilience to be
British Telecom and Energis cease to be within Pathways control (e.g.
available at the point when they are correspondence servers)
invoked. This event is considered to be
extremely rare, but should it occur, the
Service Managers from the affected
organisations would agree a pragmatic
approach to data exchange.
11. I 467/ I Genuinely lost transactions, as distinct It is not acceptable to have any lost / ICL Pathway does not plan to have
5 from incomplete transactions, will be incomplete transactions in the lost/incomplete transactions within the
treated as an error and managed by the technical solution. We require technical solution. The previous
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
3 of 1
and / or POCL.
FUJ00079076
FUJ00079076
Service Management fault resolution confirmation of this. comment was intended to reassure the
process. Authorities that should any operational
incident occur which subsequently
resulted in lost/incomplete transactions
then the incident would be treated as
an error and resolved.
12. I 472/ I This criterion is concerned with the This comment, is I believe, similar in The application interface to the "wires
1 accuracy of data capture, not of the thrust to point 11. and linked to the and boxes" is an abstracted logical
resilience of the counter infrastructure. area surrounding the application interface which is provided by the
This is covered in 472/4. interface to the wires and boxes layer I Riposte Peripheral Broker. This is
of the infrastructure. provided against various criteria (e.g.
On the specific points, a failure of a The response indicates that the LAN 570/1)
counter printer would not prevent failure impacts the services available
transactions being performed. Inamulti- I and it is this behaviour that the There is no discernible delay to the
counter outlet, a hard disc failure would comment is aimed at. counter application if the local counter
cause the counter PC to fail. It is questioning whether a printer printer is unavailable.
ALAN failure would not prevent the failure would “freeze” the application,
counter PC from performing transactions, I e.g. would it wait for the printer to time-
but certain Services may inhibit certain out and “hang’” for the printer
transactions when the counter PC is in this I configured time-out count etc.
disconnected state.
13. I 472/ I This criterion is not concerned with access I Noted. No action
3 to any captured transaction or other data.
If a particular Service has a Requirement
to access previously captured information,
e.g. EPOSS reversals, then this facility will
be tested in that particular Acceptance
specification. The general facilities
available to POCL Auditors are covered in
the Audit Acceptance Specification,
criterion 816/1 covers Outlet events.
14. I 472/ I Smart Cards are not used by any of the Smart cards are used by POLO. The correct use of the POLO card is
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
4of1
and / or POCL.
FUJ00079076
FUJ00079076
Services at Release 2. Test 10.3.1.1 is
performed on a two-counter configuration
where failure of the LAN cable is
equivalent to a LAN Hub failure in a larger
outlet. In both of these situations a
counter no longer has connection to the
LAN. Tests 10.4.3.1/ 2 do test the failure
of the touch screen facility as opposed to
the monitor / display.
If the monitor / display has failed the
counter system cannot be used.
ALAN hub is different as is an inter-
hub failure leaving groups of nodes
talking to each other; indeed a 2
position outlet is special as failure of
the LAN is handled differently as the
nodes can both continue to serve full
function (I believe this is the current
proposal) whereas in 2+ nodes, if a
node cannot see another node it can
only perform basic EPOSS (again my
belief).
Please clarify (f) to be failure of touch
sensitivity and add failure of video
output.
covered in criterion 473/5 & 6.
Criterion 953/2 covers the 2 and >2
counter failure scenarios.
Tests ACO1 to ACO3 will be added which
show the auto-configuration processes for
new single and multi-counter outlets.
Noted. As per usual caveat, review of
subsequent documentation will
ascertain whether the criterion is met.
No action
Following the SD series of tests a variety
of transactions are performed to ensure
the counter system is left in a usable state.
The comment was targeted at data
already held - not at new data added.
Therefore comment re-iterated.
This was understood. A new software
release will use previously held data
(e.g. reference data).
4
15. I 476/
4
16. I 476/
5/6
17. I 537/
2
18. I 538/
This criterion is concerned with software
distribution not roll-out. See response to
comment 15 for auto-configuration tests. It
would of course be impossible for roll-out
to all outlets to be included in the
Acceptance phase, since the Authorities
require the completion of Acceptance as
the pre-cursor to starting national roll-out.
There appears to be confusion in the
term “roll-out”. I interpret this to be the
distribution to one outlet, a group or all
outlets when there is an existing
population of outlets. Please
reconsider in this light, ie. how is it
rolled out to one, a group or all
outlets? Also how do the outlets know
they have received the update which
may be required in the case of a fix.
Criterion 537/2 is concerned with the
distribution of software to outlets.
Other criteria (559/3) require that all
outlets are capable of supporting all of
the contracted Services, and
consequently Software releases will be
to all outlets.
Product availability within an outlet is
controlled by POCL via their reference
data.
The use of GMT as the standard for all
The issue of time has still not been
No action
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
5 of 1
and / or POCL.
FUJ00079076
FUJ00079076
timestamps within Horizon is stated in the
TED section 12.7.10. This will be added to
the review documents.
agreed and should therefore be
treated as a caveat as with other
Acceptance specs.
transaction when the secure time-out is
activated will be retained when the session
19. I 541/ I This comment is not understood. I interpret the comment to be that an ICL Pathway would welcome the
1 indication of how quickly TMS can be I opportunity to significantly increase
scaled is sought. Being scaleable to I the capacity of the infrastructure to
an extra 5% capacity but taking 4 accommodate increased business
years to achieve this is unlikely to volumes. The speed by which this
satisfy the criterion. could occur will not be a limiting factor
in supporting such growth, providing
that the expected partnership between
ICL Pathway and POCL identifies and
plans for such growth. It is expected
that significant enhancements to
infrastructure could take place every
other Release.
20. I 558/ I The timeliness of transactions performed Noted. No action.
2 at the counter is covered in criterion 558/1.
Any failure to meet such times will be
managed via Service Level Agreement
management. The technical mechanisms
and designs used to meet such service
measures are contained within the ICL
Pathway Service and Risk boundary.
21. I 559 I This comment is not understood. OPS is The tests are about capacity whereas I What else is expected?
3 the counter systems environment which criterion relates to ‘support for
clearly supports the Services. transactions’ which involves more than
capacity. Comment therefore re-
iterated.
22. I 921/ I Confirmed. Any data captured as part of a I Noted. No action.
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
6 of 1
and / or POCL.
FUJ00079076
FUJ00079076
is re-activated.
23. I 468/ I We are unclear how the comment relates _I I interpret the comment to be, whatis I Nothing. The architecture is such that
1 to the criterion. ICL Pathway will provide a I done to ensure that the 8 nodes in a9 I a failed counter PC can simply be
fault resolution service for OPS as node outlet are not impacted when the I removed and replaced. Recovery is
described in the test condition and always I ninth node is being rectified. then automatic.
with the agreement of the Post Master.
Where particular circumstances exist in an
outlet the Post Master and the Horizon
System Help Desk will agree a mutually
acceptable approach.
24. I 469/ I The criterion calls for technical Disagree. Would expect the Please explain your concerns.
2 documentation for OPS to be provided. documentation to be such that “the
ICL Pathway does not believe that design I external procurement of applications”
philosophies or support services fall into would integrate successfully with other
this category, particularly since the focus elements. Therefore the areas
of this Requirement is the external covered are reasonable, as would the
procurement of applications. provision of volumetric / performance
data to allow such procurements to be
No failures are quoted in this criterion or in I designed to play to the strengths and
the underlying Requirement. growable areas of the solution and not
introduce difficulties that such
POCL are better placed to understand the I information could negate.
transaction volumes expected in outlets.
There are no requirements on ICL
Pathway to retain and analyse
management information on outlet
transactions, although it may be possible
to provide such information if requested.
25 vo Please see the response to comment 24. I See 24. As above.
26. I 474 I The Declaration of Conformity will refer to I Noted. No action.
the standards quoted in this Requirement
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
7 of 1
and / or POCL.
FUJ00079076
FUJ00079076
and any later versions of any mandatory
standards.
27. I 475 I These criteria do not call for Usability tests. I Disagree. E.g. 475/3 “intuitive and As previously stated, there is no
easy to use” would, from the requirement for ICL Pathway to run
Authorities comment, be satisfied by a I Usability trials as part of Acceptance.
Usability trial, not document review.
However POCL will be aware that an
EPOSS Usability Study was
completed earlier this year with very
satisfactory results.
28. I 476/ I Now included. A new version of this spec has not yet I Contained in version 1.6.
1 been seen with this included.
29. I 476/ I External interfaces have been satisfactorily I Noted. However there is ongoing fault I No action
2 tested during the Direct Interface Test fixing and development. It may be the
phase. The details are contained in the E2E, MOT closure reports and
Horizon Programme closure report monitoring of events in Live Trial may
PCL/TST/CLR/001/V2_0 v2.0 28/08/98. also need to be cited with the DIT
closure as the resolution of this
criterion.
30. a As described in the test condition. Noted. No action
31 ye Confirmed. Noted. No action
32. I 536/ I The Style Guide is not concerned with the I Disagree. The “easy to use” can only
1 operation of the peripherals or input be met if the HCI that utilises the
devices. These are all covered in the two I peripherals is well constructed. The
referenced documents. Style Guide must therefore be
included as a reference.
33. I 537/ I The agenda and scope of the Horizon Noted. No action
1 Service Review Forum is set by POCL.
34. I 555/ I No since there is no requirement for OPS I Noted. No action
1 to read track 3.
35. [5577
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
8 of 1
and / or POCL.
FUJ00079076
FUJ00079076
2 Confirmed. Noted. No action
36. $22) Agreed. Noted. No action
37. I 827/ I It has been agreed that this criterion will be I Noted - pending point 8. No action
3 moved to Later Acceptance.
38. I 869/ I This criterion is concerned with We believe that disaster recovery and _ I AS previously stated, disaster
3 performance requirements and tolerances I contingency should be covered. recovery and contingency are not
in four specific areas. Disaster recovery Comment re-iterated. contained in the text of this criterion.
and contingency are not mentioned.
39. I 463/ I This criterion will be met by the completion I Noted. No action.
6 of an A2A whose timetable for completion
is separately managed by ICL Pathway
and POCL.
40. I 469/ I ICL Pathway have previously reached Whilst POCL may, at this point in time, I ICL Pathway has previously offered a
1 agreement with the POCL Acceptance have no intention of externally comprehensive range of documents to
Test Manager that this criterion should be I procuring applications during NR2, this I assist POCL in external procurements.
deferred, since it is understood that POCL I criterion should either be addressed or I However when discussing the practical
have no intention of externally procuring formally recorded in the NR2 Release I value of a general documentation set
applications during the life of NR2. Contents Description which would then I without any business or functional
need to be approved. Comment re- context it was agreed that this criterion
iterated. should be deferred. There is a strong
association between this criterion and
463/6 (already deferred) which
identifies the need for joint marketing
plans.
41. sr ICL Pathway have previously reached Whilst POCL may, at this point in time, I ICL Pathway has previously offered a
agreement with the POCL Acceptance
Test Manager that this criterion should be
deferred, since it is understood that POCL
have no intention of externally procuring
applications during the life of NR2.
have no intention of externally
procuring applications during NR2, this
criterion should either be addressed or
formally recorded in the NR2 Release
Contents Description which would then
need to be approved. Comment re-
comprehensive range of documents to
assist POCL in external procurements.
However when discussing the practical
value of a general documentation set
without any business or functional
context it was agreed that this criterion
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
9 of 1
and / or POCL.
FUJ00079076
FUJ00079076
iterated.
should be deferred. There is a strong
association between this criterion and
463/6 (already deferred) which
identifies the need for joint marketing
plans.
42
473/
1
ICL Pathway is unaware of any
Requirement to support remote user
access to OPS.
Criterion 473/1 proposes this
possibility. Whilst POCL may, at this
point in time, have no intention of
supporting remote user access during
NR2, this criterion should either be
addressed or formally recorded in the
NR2 Release Contents Description
which would then need to be
approved. Comment re-iterated.
43.
538/
ICL Pathway have been advised that the
business context for enabling transactions
to operate in local and universal time is to
support the method of operation used by
utility meters which do not make daylight
saving time adjustments. Support for
these types of transactions is included in
NR2+ with the introduction of APS Smart
Tokens.
Disagree. This criterion should either
be addressed or formally recorded in
the NR2 Release Contents Description
which would then need to be
approved. Comment re-iterated.
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway, the DSS
COMM16~1
10 of 1
and / or POCL.