top - download
⟦04aabc758⟧ Wang Wps File
Length: 21212 (0x52dc)
Types: Wang Wps File
Notes: PROPOSAL
Names: »0419A «
Derivation
└─⟦74b766e5b⟧ Bits:30006076 8" Wang WCS floppy, CR 0033A
└─ ⟦this⟧ »0419A «
WangText
…00……00……86…1 …02… …02… …02… …02… …02…
Ref LJG/12.80 ICL Defence Region
Computer House
322 Euston Road
London NW1
Christian Rovsing A/S
(Attention Mr Gert Jensen)
Lautrupvang 2
DK-2750 Ballerup
Denmark 16 Dec 80
…02…Dear Sirs,
O̲U̲T̲L̲I̲N̲E̲ ̲I̲C̲L̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲
1. I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
a) International Computers Ltd (ICL) has pleasure in submitting to Christian Rovsing
A/S (CR) its proposals for the design, coding and unit testing of a number of
Software work packages, as agreed in CR…08…s telex CPS/106/TLX/0004 dated 3 Sep 80.
These work packages are identified in this proposal and specified in the accompanying
Annexes. This proposal is an outline which will form the basis of a Budgetary
Proposal to be prepared by ICL in the UK during early 1981.
b) ICL further proposes to undertake work packages of a non-software development
nature, which are closely related to ICL…08…s experience in this type of application.
c) Each work package identified will consist of a number of deliverable components,
which are listed with the work package specifications in the Annexes. The contents
of the deliverables will be agreed with CR prior to contractual agreement, as
will the format and presentation media for these deliverables.
d) The work will be undertaken in the UK with scheduled meetings to review progress,
agree deliverables, discuss proposed changes etc. The timescales will be in line
with the current CAMPS Master Plan (ie April - December 1981).
2. P̲R̲O̲P̲O̲S̲E̲D̲ ̲W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
a) Three categories of work package have been identified: consultancy, software-related
packages, and non-
software-related packages.
b) C̲o̲n̲s̲u̲l̲t̲a̲n̲c̲y̲. A pre-requisite before any software implementation work can be progressed
is to specify the package interfaces, as anticipated in CR's telex of 3 Sep 80.
Annex A gives details of the Interface- Definition work package proposed.
c) S̲o̲f̲t̲w̲a̲r̲e̲-̲R̲e̲l̲a̲t̲e̲d̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲. Three Application Software packages, related to ICL…08…s
experience and closely linked to each other, have been selected. Their implementation
as a group will significantly simplify the interfaces bewteen ICL and CR. The
proposed Packages are:
Traffic Handling Package See Annex B
…02……02……02…Message Distribution Package See Annex C
…02……02……02…Terminal Package See Annex D
…02… The next section of this proposal states the framework within which these work packages
will be undertaken
d) N̲o̲n̲-̲S̲o̲f̲t̲w̲a̲r̲e̲-̲P̲a̲c̲k̲a̲g̲e̲s̲.̲ Two such tasks have been identified:
…02……02… U̲s̲e̲r̲ ̲H̲a̲n̲d̲b̲o̲o̲k̲s̲.̲The task of writing User Handbooks is closely related to the work
involved in implementing the User Interface (as implied in the Terminal Package).
S̲y̲s̲t̲e̲m̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲&̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲s̲.̲ These are directly related to ICL's experience
in implementing the OPCON system in the UK.
3. S̲O̲F̲T̲W̲A̲R̲E̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲F̲R̲A̲M̲E̲W̲O̲R̲K̲
3.1 S̲O̲F̲T̲W̲A̲R̲E̲ ̲R̲E̲L̲A̲T̲E̲D̲ ̲W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
a) Each work package will be composed of a number of well defined, functionally self-contained
modules. Module sizes will conform to CR standards, and have clearly defined
interfaces to other modules constituting the package. In this way the complexity
of the work package will be reduced to specific clearly comprehensible and maintainable
components.
b) The deliverable entities which will be provided with each such work package are
as follows:
*Functional design specification for complete work
…02…package
*Hierarchical breakdown of the work package into
…02…module components, which show transfer of data
…02…and control between them.
*Interface specification for each software module
*Detailed functional specification for each software
…02…module
…02…Source and compilation listings for each module
Source & compiler output in machine readable form for each module
…02…Module test specifications and sample results
Implementation specific documentation, for example an explanation of an unusual
algorithm which may have been employed.
c) Items above marked by an asterisk will be required to have been submitted by ICL
to CR for approval, and a period of 10 working days will be allowed for this approval
being given. Once approval has been given, these components will be subject to
change control. In general this is to ensure conformity of design with the requirements
of performance. Where more specific coding practices are determined by CR as
necessary for this purpose they will be communicated by CR as a standard.
d) It is anticipated that if a phased development/delivery approach is agreed, then
a phased delivery will consist of a certain number of modules, together with dummies
for those modules not provided.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲ ̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲/̲S̲U̲P̲P̲O̲R̲T̲
a) Modules are to be delivered in module-tested form with agreed test results according
to an agreed delivery schedule. Where bugs are uncovered following initial integration,
bug clearance is to be undertaken gratis by ICL except where the failure arises
from incorrect specification or non-compliance with agreed interface specifications
by CR. Where bugs do not prevent module use, and if the principle of multiple
delivery of modules at increasing level of capability has been agreed, bug clearance
will be undertaken at a subsequent delivery; otherwise a period of one month from
final delivery will be allowed for identification of these bugs.
b) Responsibility for clearance of bugs uncovered beyond the circumstances outlined
above will be undertaken by:
…02…ICL on an inclusive charge basis within the package
…02…price for a further agreed period.
…02…or ICL on a maintenance basis
…02…or CR.
the chosen option to be agreed.
c) ICL support on site at CR or elsewhere for integration/trials support is to be
made available on a time and materials basis.
4. W̲O̲R̲K̲I̲N̲G̲ ̲A̲R̲R̲A̲N̲G̲E̲M̲E̲N̲T̲S̲
4.1 P̲R̲E̲R̲E̲Q̲U̲I̲S̲I̲T̲E̲S̲
a) CR will have identified the design and delivery mechanism: in particular whether
a phased delivery of any work packages is required (each subsequent phase providing
further facilities). If such is the case, CR will relate the delivery phases
to a build plan drawn up by them.
b) All external interfaces required by each work package will have been specified
and will be subject to change control (See para 4.6).
c) Development and delivery schedules for each of the work packages will have been
agreed between ICL and CR.
d) CR will specify the programming language to be employed.
e) CR will have ensured that adequate documentation is available to ICL concerning
CAMPS itself and related aspects of the CR80 (eg the architecture, development
utilities, the operating system under which the devopment will take place, diagnostic
procedures, the programming language).
f) CR will have ensured that adequate training facilities are available for ICL software
development staff. These facilities will be agreed prior to contract. Examples
are:
…02…Formal tuition
…02…Self training material
…02…On-job experience
4.2 A̲G̲R̲E̲E̲D̲ ̲C̲R̲ ̲F̲U̲R̲N̲I̲S̲H̲E̲D̲ ̲I̲T̲E̲M̲S̲
a) The contract will include terms for the provision to ICL of the necessary computer
equipment and software (whether by providing ICL with a development machine or
by formal leasing of a machine for the necessary time.)
b) Error-free and efficient operating-system software and utilities will be supplied
by CR.
4.3 S̲E̲C̲U̲R̲I̲T̲Y̲
a) ICL will conform with NATO security regulations as they apply to the CAMPS project
in respect to such factors as:
…02…Staff employed
…02…Document control & transmission
…02…Non-disclosure of classified information
…02…Computer media control.
b) As a regular contractor to the UK Ministry of Defence, ICL is accustomed to handling
classified material well beyond the requirements of the CAMPS project.
4.4 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲(̲Q̲A̲)̲ ̲&̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲C̲O̲N̲T̲R̲O̲L̲(̲Q̲C̲)̲
ICL will conform with the CAMPS Project Standards of Design, Documentation and Programming.
QC procedures will be employed which specifically ensure this conformity. Where
specific QA subjects remain undocumented, ICL standards will conform to those adopted
in negotiation with the UK Ministry of Defence for 0521 certification.
4.5 P̲R̲O̲G̲R̲E̲S̲S̲
a) It is proposed that monthly progress meetings be held in Denmark at which ICL
will report progress on a formal basis. These meetings will afford an opportunity
to raise and resolve unforeseen issues. A monthly schedule is proposed.
b) Weekly progress reports to an agreed format will be sent by post.
4.6 C̲H̲A̲N̲G̲E̲ ̲C̲O̲N̲T̲R̲O̲L̲
a) At contract Signature a start-date will be agreed. Any alteration by CR to this
date may result in change control procedures being invoked.
b) Subsequent to commencement of work on defined packages any changes in scope, design
or availability of CR items whether occasioned by changes in or clarification
of customer requirements or otherwise are to be subject to Change Control, as
follows:
Changes intiated by CR: ICL will inform CR within 5 days if there is a cost/schedule
impact and within 10 days specify the actual values, with a rationale in justification.
The cost of preparation of this study will be chargeable to CR on a time and materials
basis. Work is to continue on the existing baseline until the changed cost/schedule
impact has been agreed, unless CR require immediate implementation of the change;
in this case CR will indemnify ICL against any cost increase or schedule delay
involved.
Changes initiated by ICL: If in the course of implementation, ICL encounters opportunities
for design improvement, an ECP will be raised for consideration by CR and subsequent
change control procedure. In these circumstances the question of cost penalties
does not arise.
On behalf of ICL
Yours faithfully,
L.J. GLASSON
ANNEX A TO
ICL PROPOSAL TO CR
DATED 16DEC80
W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲1̲:̲ ̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
ICL will provide consultancy services for the purpose
of assisting Interface Definition in the detailed design
phase commencing in January 1981 at Ballerup. The
work to be undertaken comprises:
…02…Identification of: all package interfaces
…02… all process interfaces
…02… principle module interfaces
…02…Definition of data/control transfer requirements
…02…for:
…02… all process interfaces
…02… principle module interfaces
…02…Detailed definition of interface format and
…02…content for:
…02… all process interfaces
…02… principle module interfaces.
The definitions of of the second and third items above
will be placed under Change Control.
Annexes C,D and E show interfaces already identified
for the respective packages. Shown overleaf are Environmental
Interfaces needed by the ICL Software team in the UK.
ICL proposes to supply the services of two experienced
system/communications consultants with directly relevant
experience. The work will be undertaken in Ballerup
in close association with CR and co-ordinated with
senior technical ICL consultancy in the UK (specifically
Mr J Glasson and Mr R Gordon). These services will
be made available on a time and materials basis.
E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲A̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
The following support and environmental interfaces
will be required by the ICL software team in the UK:
L̲o̲c̲a̲l̲ ̲t̲o̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲: Environmental software (eg CSF,
TMP etc) as necessary to test adequately the modules/processes
that are developed.
G̲l̲o̲b̲a̲l̲:Compilers/assemblers/Linkers
Libraries
Debugging aids
Dump facilities
Utilities
ANNEX B TO
ICL PROPOSAL TO CR
DATED 16DEC80
W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲2̲:̲ ̲ ̲T̲R̲A̲F̲F̲I̲C̲ ̲H̲A̲N̲D̲L̲E̲R̲
This package controls the handling of ACP127 message
traffic across the CAMPS telegraph interfaces, and
communications with other external systems (CCIS/SCARS).
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Receipt and control of incoming traffic from NICS TARES
and low speed telegraph lines (for example TRC and
local telegraph lines)
Transmission and control of outgoing traffic to NICS
TARES and low speed telegraph lines.
ACP127 analysis and control of manual correction of
incoming messages.
ACP127 synthesis and control of manual routine assistance
of outgoing messages.
Circuit and Channel control and Channel continuity
checks (including periodic automatic generation and
awaiting receipt of channel check messages).
Automatic FLASH receipt and acknowledgement checks.
Collection of statistics directly related to facilities
controlled by this package.
I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
To be defined during the course of Work Package 1 (See
over for provisional list of interfaces for consideration).…86…1
…02… …02…
T̲R̲A̲F̲F̲I̲C̲ ̲H̲A̲N̲D̲L̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲(̲T̲H̲P̲)̲
P̲R̲O̲V̲I̲S̲I̲O̲N̲A̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲L̲I̲S̲T̲
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲w̲i̲t̲h̲:…02…P̲u̲r̲p̲o̲s̲e̲:
Camps Systems Functions
a. Queue Monitor…02…Inter-process communication
…02…Device queues. Terminal
…02…Queues (correction & routing
…02…assistance).Checkpoints
b. Log…02…Logging.
c. Statistics…02…Statistics (in,out,rejected
…02…channel availablity,traffic
…02…reports)
d.Message Monitor…02…Access to & updates of messages
…02…& MCB
e.Timer…02…Channel Checks;flash-
…02……02…acknowledge;midnight
Message Distribution…02…Messages for distribution
Terminal Handler…02…In association with CSF, queue
…02…message for:
…02… Message garble correction
…02… Message routing assistance
…02… Group count verification
…02…Queue reports for supervisor
…02…Release notification
…02…Accept message upon release
…02…Accept out-message
…02…Represent message for
…02… correction
…02…Message for Routing Assistance
Storage & Retreival…02…Incoming TI
…02…Out release serial No/SSN
…02…Outgoing TI
IO Control…02…Access to external channels
…02…Access to CCIS/SCARS/NICS
…02… (via CR Corp. interface)
Table Management…02…CCIS VDU pages update
…02…Access to appropriate tables
SS & C…02…Co-ordination of channel
…02…control
ANNEX C TO
ICL PROPOSAL TO CR
DATED 16DEC80
W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲3̲:̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
This package performs the distribution to users (via
terminals, SCARS, CCIS etc) of incoming and outgoing
messages, messages for co-ordination and release, and
comments. It is involved in all distribution based
upon SCDs.
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Creation of a distribution list for incoming messages
and distribution of comments and outgoing messages
to user-designated recipients.
Interaction with MDCO for manual assignment of the
distribution list for a message, and assistance when
a message cannot be delivered.
Reports for users when delivery of messages for co-ordination
and comments is not possible.
Delivery to appropriate queues.
I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
To be defined during the course of Work Package 1.(See
over for provisional list of interfaces for consideration)
D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲ ̲-̲ ̲P̲R̲O̲V̲I̲S̲I̲O̲N̲A̲L̲ ̲L̲I̲S̲T̲ ̲O̲F̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲w̲i̲t̲h̲:̲…02…P̲u̲r̲p̲o̲s̲e̲:̲
Traffic Handler…02…Queued refs to in/out messages
…02… & comments from CCIS/SCARS
Terminal Package…02…Messages/Comments for Staff
…02… Cells
…02…Messages for co-ordination
…02…Comments for distribution
…02…Delivery problems
Table Management…02…Access to tables & parameters
Camps System Functions:
…02…a. Message Monitor…02…Access to & update of messages,
…02… comments & MCBs
b. Queue Monitor…02…Handling of Process Queues.
ANNEX D TO
ICL PROPOSAL TO CR
DATED 16DEC80
W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲4̲:̲ ̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲P̲A̲C̲K̲A̲G̲E̲
This package controls the man-machine interface for
CAMPS (with the exception of the Engineer's control
console) and provides common facilities for all users
of the system, and for those processes which communicate
with users.
ICL is aware that a decision has yet to be made regarding
the choice of VDU, and therefore proposes that the
package be sub-divided into two components:
…02…The man-machine interface (independent of
…02…terminal hardware characteristics)
…02…The device-driver.
In order to be independent of final choice of hardware
and to avoid the need for interfacing with the terminal
maunufacturer, ICL proposes to undertake development
of the device-indepndent component only: it is considered
more appropriate for CR to provide the device driver.
If a firm decision is reached by CR on choice of VDU
manufacturer within the timescales of ICL's proposal,
ICL would at CR's request extend the scope of this
package to include both components.
F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Checking of terminal function.
Input and initial checking of all user commands (including
use of PEC)
User transaction control and common functions (such
as cancel, suspend/resume, delete).
Syntax validation of transaction data, and output of
error codes and highlighting fields in error.
Basic editing facilties, page mode and roll up mode.
Allocation of Transaction Identifiers and Special Handling
number series.
Access by COPSY to VDU header for Security Interrogation
and Warning. Routing to COPSY of security-related
inputs (eg Sign-in).
System access to terminals (via queues or via direct
responses).
Terminal queue control (queue commands for interactive
terminals; automatic output at non-interactive terminals;
single-user and shared queues; precedence, pre-emption
and time-outs).
Printer spooling and re-run facilities.
Status reports on terminal activities (including facilities
for transactions to supply entries for status reports).
Collection of Statistics directly related to facilities
controlled by this sub-system.
User interface to CCIS and SCARS.
Conversion of messages between VDU and Database formats.
Merging of text with screen-format template.
Screen-template selection and control.
Semantic validation for each type of transaction.
Control of VDU header
Initial Command validation and interpretation.
Control of FLASH message warning (ie queue-status highlighting).
I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
To be defined during course of Work Package 1 (See
over for provisional list of interfaces for consideration).
T̲E̲R̲M̲I̲N̲A̲L̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲(̲T̲E̲P̲)̲-̲ ̲P̲R̲O̲V̲I̲S̲I̲O̲N̲A̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲L̲I̲S̲T̲
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲w̲i̲t̲h̲…02…P̲u̲r̲p̲o̲s̲e̲:̲
Camps Systems Functions…02…Access to Message/Comment
…02…Access to MCB
…02…Events for Logging (CSF
…02… passes to LOG)
…02…Reports on system conditions
…02… generated by CSF Report
…02… Generator(eg system overload)
…02…Queue input/access/status
…02…Timeout reports from CSF
…02…Date/time requests
…02…Statistics information
…02… (CSF passes to STP)
…02…Table Management…02…Access to Tables
…02…Access to Global No.Series
…02…Access System Parameters
Storage & File…02…No direct access - via
Management…02…CSF
SS & C…02…Access to COPSY
…02…Error reporting
…02…Ordered closedown
…02…Command Completion reports
Storage & Retrieval…02…Message retrieval requests
…02…Response to above
…02…Offline disc-mount req.
…02…Reports from SAR
Traffic Handling…02…Outgoing messages & reruns
…02…Incoming Service Messages
…02…Reports from THP
…02…Messages for Correction
…02…Station Serial No (for Release
…02… notification)
Distribution…02…Messages/Comments/Notifications
…02… of Release for queueing
…02…Messages for MDCO
…02…Supervisor Re-distribution
Log & Account.…02…Supervisor Log traces
…02…Timer log reports
…02…Command completion reports by
…02… LOG
…02…Transaction Status reports
Statistics…02…Supervisor requests for Stats
…02…Stats for printout
…02……02…Command Completion reports
ANNEX F TO
ICL PROPOSAL TO CR
DATED 16DEC80
W̲O̲R̲K̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲6̲:̲ ̲ ̲U̲S̲E̲R̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
Since ICL is proposing to undertake the development
of the Terminal Package, which provides the man/machine
interface at a functional level, it is appropriate
for ICL to also produce the user/supervisor handbooks.
A further advantage would be ICL's access to English-
speaking technical authors in the UK.
The Handbooks will describe the terminal itself, keyboard
functions, sign-in, sign-out, together with detailed
explanation of all transactions and commands, and their
parameters and associated screen formats.
A full explanation of all error conditions which the
user may encounter will be given, together with direction
as to the appropriate course of action to be taken
for each one.
D̲E̲L̲I̲V̲E̲R̲A̲B̲L̲E̲S̲
Accurate and easily-understood user documentation,
probably supplied in two volumes each of about 200
pages.
