top - download
⟦1ce062879⟧ Wang Wps File
Length: 68376 (0x10b18)
Types: Wang Wps File
Notes: LKSAA vol. II part 1
Names: »4237A «
Derivation
└─⟦84f7719fc⟧ Bits:30006031 8" Wang WCS floppy, CR 0385A
└─ ⟦this⟧ »4237A «
WangText
?…0a…?…02…>…0a…>…00…=…09…=…0f……86…1
…02…
…02…
…02…
…02…
Issue
1.5
LKSAA
-
VOLUME
II
SYS/84-06-15
Part
1
TECHNICAL
PROPOSAL
Page
#
*…06…1 …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
7 PROJECT ISSUES ...................................
283
7.1 PROJECT IMPLEMENTATION PLAN ..................
283
7.2 PROJECT MANAGEMENT AND CONTROL ...............
285
7.3 QUALITY ASSURANCE ............................
293
7.3.1 Parts
and
Material
(P&M)
.................
294
7.3.2 Reliability
..............................
294
7.3.3 Quality
Control
(QC)
.....................
294
7.3.4 QA-Policy
................................
295
7.3.5 QA
System
................................
295
7.4 DETAILED REQUIREMENTS ........................
296
7.5 DESIGN .......................................
296
7.5.1 Preliminary
Design
.......................
298
7.5.2 Detailed
Design
Baseline
.................
299
7.5.3 Code
and
Unit
Test
Baseline
..............
300
7.5.4 Subsystem
Integration
and
Test
Baseline
..
300
7.6 IMPLEMENTATION ...............................
303
7.7 ASSEMBLY AND FACTORY TEST ....................
303
7.7.1 Factory
Testing
of
Hardware
..............
303
7.7.1.1 Incoming
Inspection
Tests
............
303
7.7.1.2 Hardware
System
Tests
................
304
7.7.2 Factory
Testing
of
Software
..............
305
7.7.2.1 Unit
Testing
.........................
305
7.7.2.1.1 Elementary
Unit
Testing
..........
306
7.7.2.1.2 Compound
Unit
Testing
............
306
7.7.2.1.3 Unit
Testing
Summary
.............
306
7.7.2.2 Package
Integration
and
Test
.........
307
7.7.2.3 Development
Test
Evaluation
..........
307
7.7.2.4 System
Integration
and
Test
..........
307
7.7.2.4.1 Subsystem
I
&
T
and
System
I
&
T
Task
Description
.................
307
7.7.2.4.2 Integration
Sequency
Outline
.....
308
7.7.3 Acceptance
Test
Plan
.....................
308a
7.7.4 FAT
Documentation
........................
308a
7.7.5 Message
Emulation
........................
308a
7.7.6 Start
of
Warranty
........................
308a
7.8 INSTALLATION .................................
309
7.8.1 Requirement
Analysis
.....................
309
7.8.2 Installation
Planning
....................
310
7.8.3 Equipment
Installation
Data
..............
310
7.8.4 Site
Survey
..............................
311
7.8.5 Site
Preparation
Requirements
............
311
7.8.6 Equipment
Installation
Drawings
..........
312
7.8.7 Site
Readiness
Verification
..............
312
7.8.8 Transportation
..........................
313
7.8.9 Site
Installation
........................
314
7.9 TRAINING REQUIREMENT ANALYSIS ................
315
7.9.1 Instruction ..............................
315
7.9.2 Training .................................
315
7.9.3 Training Program Plan ....................
315
7.9.4 Optional Training Courses ................
316
7.9.5 Training Documentation ...................
316
7.10 OPERATIONAL TESTS ..........................
317
7.10.1 Purpose of the Operational Test.........
317
7.10.2 Functional Description .................
317
7.11 ACCEPTANCE TEST ............................
317
7.12 WARRANTY AND MAINTENANCE ...................
320
7.12.1 General .................................
320
7.12.2 Maintenance Planning ...................
320
7.12.3 Maintenance Plan .......................
320
7.12.4 Maintenance Activities .................
323a
7.12.4.1 Preventive Maintenance .............
323a
7.12.4.2 Emergency Maintenance ..............
323a
7.12.4.3 Software Maintenance ...............
323b
7.12.5 Field Support ..........................
324
7.12.6 Spare Parts ............................
324
7.12.7 Tools and Test Equipment ...............
325
7.12.8 Consumables ............................
325
7.12.9 Repair .................................
325
7.12.10 Customer Support .......................
325
7.12.11 Equipment Serviced .....................
325
7 P̲R̲O̲J̲E̲C̲T̲ ̲I̲S̲S̲U̲E̲S̲
The LKSAA Project will be conducted by Christian Rovsing
A/S, using the most efficient Project Management and
Control Features. These techniques have been used by
Christian Rovsing A/S in earlier projects with great
success.
7.1 P̲R̲O̲J̲E̲C̲T̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲P̲L̲A̲N̲
At Christian Rovsing A/S, the Project Implementation
Plan (PIP) is the management tool which is used to
described all significant aspects of a project - See
Figure 7.1-1. The PIP establishes a firm baseline for
all project activities; project status, progress and
performance can be evaluated and controlled by means
of this baseline. Therefore, the PIP has a well defined
structure, and each section identifies the activity,
its organization and operating procedures. Each activity
is placed in a schedule network - consistent with a
master schedule - and the relation to other activities
is shown. Documentation produced by the activity is
listed, and a cross-reference with contractual items
is made for accountability of deliverable items and
unique requirements.
W̲o̲r̲k̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A Work Breakdown Structure (WBS) is created by dividing
all aspects of the project into major tasks. For each
of the major tasks a further breakdown is generated
detailing hardware, software and support tasks. The
WBS consists, therefore, of a family tree of hardware,
software, services and tasks organized to define and
display the work to be accomplished for susccessful
implementation of a project - See figure 7.1-2. As
a planning tool, it defines the Work Packages (WP)
for planning, scheduling and cost control. The actual
WBS and schedule for LKSAA is outlined in fig. 7.1-3.
It is Christian Rovsing A/S's experience that a project
like LKSAA will take approximately 2 years to implement,
and that it might be hazardous to try to overcome it
in one year.
Changes to a WBS are controlled by the configuration
management staff, and approved project changes are,
therefore, reflected int he baseline WBS.
Figure 7.1-1
Project Implementation Plan Covering all aspects of a project
7.2 P̲R̲O̲J̲E̲C̲T̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲C̲O̲N̲T̲R̲O̲L̲
Based on experience at Christian Rovsing A/S, the overview
of management tasks shown in figure 7.2-1 presents
the most significant activities usually encountered.
In this figure, key managers and support functions
are identified and the principal tasks assigned to
the LKSAA project office staff during the requirements
phase are delineated.
The LKSAA Project will be staffed with experienced
engineers with a good knowledge of the german language.
This will alow all project meetings of the LKSAA Project
to be held in german in order to minimize misunderstandings.
Likewise, the System Requirements Specification, which
in detail will describe the requirements to the LKSAA
will be written in german. This will ease communication
with the end user representatives during the project
implementation.
Based on our experience with similar projects, we can
outline the following staffing requirements for LKSAA.
The System Requirements Specification will be prepared
in a 3 month period (ref. figure 7.1-3) by 2-3 experienced
engineers.
The System Design Phase will be performed in the following
3 month period by 3-5 engineers.
The Preliminary and the Detailed Design will be performed
in the following 4 month period by 5-10 engineers.
The Code and Unit Test Phase is estimated to a 5 month
period for the 5-10 engineers.
The following Package and System Integration and Test
Period is estimated to to run in an 8 month period.
5-10 engineers are expected to be involved in this
activity.
The above given estimate of manpower resources needed
on the LKSAA is based on a large extent of re-use of
S/W developed and implemented on the NATO Project
CAMPS.
The need of manpower for the LKSAA will also vary during
the phases of implementation.
Figure 7.2-1 gives an overview of the most significent
activities during the early stages of the program,
where the System Requirements Specification is produced.
Figure 7.2-2 on the other hand depicts the project
organization at a later stage of the project, where
H/W and S/W is developed and produced.
The LKSAA Project Office, under the direction of the
Project Manager is responsible for the overall conduct
of LKSAA. Included in the project office are a System
Engineering Manager. Operation Manager and Logistic
Manager supported by Quality Assurance personnel and
Contracts Administrator. The principal responsibilities
of the project staff are outlined below.
P̲r̲o̲j̲e̲c̲t̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲
As the executive responsible for successful execution
of the LKSAA Project, the Project Manager has authority
over and is responsible for: budget allocation; cost-control;
schedule and on-time performance; technical cognizance
of design; development and control of production; and
test, integration and support activities. The Project
Manager reports directly to senior management for prompt
resolution of project issues. He is directly supported
by the LKSAA Project Office staff and indirectly by
the managers of all operating departments within Christian
Rovsing A/S.
E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲
A senior systems engineer, with a complete understanding
of the technical implications of top-level system specifications,
is responsible for the ultimate technical performance
and compliance with those specifications. He plans,
directs, monitor, audits and controls the design, development,
testing, installation and cut-over of a system with
regard to all technical aspects. He provides the technical
liaison with the customer, with in-house development
and production groups, and with sub-contractors and
suppliers.
O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲ ̲M̲a̲n̲a̲g̲e̲r̲.̲
This manager provides the liaison between the Project
Office and the procurement and production activities.
Scheduling, cost control, configuration control, production
status, and quality
Figure 7.1-3
LKSAA WBS
Figure 7.2-1
Project Management Tasks
Figure 7.2-2
Project Organization
control and his major concern. He is responsible for
establishing and maintaining an up-to-date baseline
configuration and to assess the status and quality
of production during implementation.
L̲o̲g̲i̲s̲t̲i̲c̲s̲ ̲M̲a̲n̲a̲g̲e̲r̲.
The installation and site support tasks are combined
under one manager. The logistics Manager is responsible
for site surveys, delivery and installation, training,
maintenance spares, documentation and site support.
Logistic support tasks are carried out by staff from
the Integrated Logistics Support Department of Christian
Rovsig A/S.
Quality Assurance and Contracts Administration are
company staff functions performed for all projects.
Intensive support is given during start up and critical
phases and continues throughout the project.
Operating Procedures
Formal operating procedures and proven management methods
are used by the LKSAA Project Office to control the
project.
Management procedures define the methods used within
Christian Rovsing A/S for planning, work assignment,
monitoring and coordination of activities within the
LKSAA project.
The Project Office and its staff operate within these
well-established procedures and are responsible for:
Planning: Evaluation of contract requirements
and allocation of work to the various
functional department.
Work
Assignments: Issurance of work statements, specificatons,
budget and schedule requirements.
Monitoring: Periodic review of technical scedules
and cost performance, applying program
control through budget authorization.
Coordination: Coordination of all project activities
between operating departments
Internal management cost/schedule procedures produce
valid, auditable and timely performace reports. Variances
from budget and schedule are quickly identified, and
significant deviations are flagged for immediate project
management attention and corrective action.
Technical supervision and monitoring are effeted by
periodic design reviews with hardware and software
engineering managers.
The primary management controls are based on a well-planned
WBS, master schedule and budget. Firm baselines established
early in the project provide the basis for management.
The master schedule incorporates customer-directed
milestones and indicates the timing relationships of
the WBS elements. Detailed plans derived from the master
schedule establish work package milestones.
The budget baseline allocates the resources among operating
departments after contract award. Work authorizations
are time phased based on schedule constraints. Internal
budget allocations allow for the retainment of funds
for contingencies and unforeseen efforts.
All detailed packages - identified and assigned from
a WBS - are defined by a statement of work, schedule,
and budget, thus establishing a performance measurement
baseline.
Cost Control
The Project Cost and Schedule Control System (CSCS)
applied by Christian Rovsing A/S to medium and large
size projects is based upon a multi-level Work Breakdown
Structure (WBS)
o Level 1 defined the main WBS items within the responsibility
of the manager of each function.
o Intermediate levels define Summary Work Packages
(SWP) within the responsibility of a single task
manager.
o The lowest level defines the Work Package (WP)
that a SWP defines. WP's are the units of effort/tasks
from which project schedule and cost performance
are monitored. As a guideline, each WP should not
exceed a 3 month duration from start to completion.
The total effort is not to exeed 6 man-months.
Reporting by SWP-Managers on progress, i.e. degree
of completion and effort spent on the WP-level, takes
place monthly. Theses reports can give early warnings
of both schedule delays and cost overruns, and thus
serve a dual purpose.
The overall impact of a threatening delay in completion
of a WP is judged from Tracking Forms which easily
identify the interrelations between SWP's in terms
of due dates for input necessary for on-time performance.
The impact of a threatening cost overrun is judged
from regular quarterly as well as ad hoc project budget
revisions, taking into account both cost-to-date and
the latest estimates of cost for completion. The computerized
processing of thee data ensures up-to-date information.
By constantly monitioring schedule and cost performance
from a single source of information, i.e. the SWP-managers
monthly reporting the CSCS applied by Christian Rovsing
A/S ensures consistency in the information. This aides
to identify problem areas and guides in subsequent
corrective action.
Contracts Management and Administration
Contracts Management and Administration is a divisional
staff function providing support services to the Project
Manager.
The function is responsible for:
o Contract terms and conditions in relation to
the customer or prime contractor.
Contract terms and conditions for purchase orders to
sub-contractors and suppliers of standard equipment
and supplies:
o Project budgets
o Invoicing
o Settlement with suppliers and sub-contractors
o Fincance
o Cost control
The function is required to keep such cost and accounting
records as are required to perform audits consistent
with Danish Law and according to the terms and conditions
of the contract.
The function is responsible for the conversion of all
capacity and other budgets and plans into economic
terms permitting the safe establishment of rolling
budgets and long range financial forecasts.
System Engineering Procedure
A product like a message switch similar to LKSAA, in
the context of the Systems Division at Christian Rovsing
A/S, is the result of integration of hardware and software
elements, where the hardware and software elements
and their integration have been achieved by following
a detailed system engineering procedure. In the sections
to follow, system engineering, hardware, software and
system integration will be discussed in terms of their
relationship to final product.
Christian Rovsing A/S has the necessary know-how and
experience to take reponsibility for all major tasks
of system engineering, i.e.:
o Requirements Specification
o Design Specification
o Reliability
o Quality Assurance and Configuration Management
o Testing
o Technical Coordination
Requirements Specification
As the first task in the development of a system product,
all requirements are identified; this provides the
baseline for design procedures and acceptance testing.
Design Specification
The design specification describes how requirements
are to be immplemented; it shows - point for point
- where in the system each requirement is implemented.
Reliability
A reliability analysis and trade-off is performed to
achieve a system design that ensures a required level
of availability.
Testing
Subsequent to the design specification, a test plan
and procedure is specified. Examples of typical tests
are:
o Factory qualification test
o Factory post-production test
o Preliminary site acceptance test
o Network test for integration with other systems
or sites
o Final acceptance test
Technical Coordination
Staff at Christian Rovsing A/S have acquired significant
experience in development of complete system products
and are familiar with the means of technical coordination
that are required such as design reviews and progress
meetings as well as day-to-day communication with customers,
sub-contractors and suppliers.
Hardware
All hardware items are off-the-shelf, NATO qualified
unit. However, the flexibility of the modular design
allows hardware to be delivered to meet a wide range
of requirements with respect to memory capacity, computational
speed, fault tolerant operation and expandability.
Hardware design is documented by:
o A system level equipment specification
o Equipment product specifications
o Equipment data sheets
o Logic and wiring diagrams
Software
All software is well documented and in accordance with
NATO Allied Command Europe (ACE) documentation standards.
The Distributed Advanced Multi-Processor Operating
System (DAMOS) is the standard operating system for
mapped, virtual memory multi-processor configurations;
these configurations range from a single multiprocessor
system with up to 5 CPUs and 32 mega-bytes of memory
to a fault-tolerant system with as many as 16 multi-processors
interconnected through a 512 magabit/sec. messages
transport.
Both operating systems support assembler. SWELL (a
high-level programming language that provides register
specific data manipulation). PASCAL and COBOL. FORTRAN
77 and ADA will be supported in the near future.
In addition to application functions, programmed in
the aforementioned languages, a full range of support
software for input/output, file manipulation, editing
and debugging can be provided.
System integration is facilitated by making all software
coding, i.e. project-specific software, contigent upon
acceptance of a detailed software design specification.
Each software module is then unit-tested before SW/HW
is attempted. After integration at the factory, the
system is pre-tested before formal acceptance testing
is begun. In this way a customer is presented a truly
finished product when acceptance testing starts.
As a consequence of the structued test philosophy,
preliminary test results of system parts can be presented
to the customer if desired.
7.3 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲U̲R̲A̲N̲C̲E̲
To ensure that required levels of quality are met,
from initial design through final acceptance, quality
assurance and configuration management functions are
carried out by impertial staff reporting to a Product
Assurance Manager responsible for all QA tasks within
Christian Rovsing A/S.
The Quality Assurance Manager (QAM), a member of the
corporate staff, reports directly to corporate management
and is responsible for controlling product quality
to specification according to milestones established
in the project master schedule.
Particular QA areas of responsibility are further outlined
in the sub-sections to following.
7.3.1 P̲a̲r̲t̲s̲ ̲a̲n̲d̲ ̲M̲a̲t̲e̲r̲i̲a̲l̲ ̲(̲P̲&̲M̲)
P & M covers procurement control, vendor evaluation
and qualification, as well as receiving inspection
and purchasing.
7.3.2 R̲e̲l̲i̲a̲b̲i̲l̲i̲t̲y̲
This is a supervision function provided for all projects.
Reliability analyses, trade-off's, and tests are performed
by the project team under the supervision and control
of QA.
7.3.3 Q̲u̲a̲l̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲Q̲C̲)̲
This includes the establishment and control of general
QC procedures within the division and special QA procedures
for dedicated projects, as well as the establishment
and control of QA requirements relating to subcontractors
and suppliers.
The QC function is in particular responsible for:
- Evaluation of quality control plans
- Evaluation of inspection plans
- Incoming inspection of parts and materials
and subcontractual items
- In-process inspection
- End-item acceptance test
- Shop procedures
- Control of special procedures
- Methology and calibration relating to test
instrument and tools
- Electrical and environmental tests
- Entrance control and cleanliness control of
restricted clean room areas
- Control of packing and shipping
- Trend reporting
- Quality audits.
7.3.4 Q̲A̲-̲P̲O̲L̲I̲C̲Y̲
The Quality Assurance Policy of the company is defined
in CR/QAP/001, "Quality Assurance Policy".
Based on this policy, the company has implemented a
standard QA-system which is fully compliant with "NATO
Quality Control System Requirements for Industry",
AQAP-1.
7.3.5 Q̲A̲ ̲S̲y̲s̲t̲e̲m̲
A QA System has been developed to ensure on-schedule
delivery of products according to specified quality
requirements.
This standard QA system comprises a series of functions
of which the most important are:
o Q̲u̲a̲l̲i̲t̲y̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲
At an early point in the contract performance,
the quality requirements are reviewed and a contract
related Quality Plan is established. This plan
is based on the standard QA system but may contain
amendments or exemptions, if necessary. The plan
contains detailed scheduling of QA participation
in such activities as design reviews, factory test,
acceptance test, etc.
o D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The QA system provides strict control of all new
designs of both hardware and software. Design Reviews
are scheduled and performed and no design is released
for production/programming without proper approval.
o C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲h̲a̲n̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
A configuration and Change Control system ensures
that all necessary documentation is established
and baselined. Also software is placed under control
after programming and development test. The Change
Control is managed by a board with participation
of a customer representative, if required/desired.
o W̲o̲r̲k̲ ̲I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲s̲
In all areas where necessary for quality, work
instructions and standards are established. Standards
define the required quality level and instructions
define processes needed to reach that level.
o I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
Detailed procedures are established for Inspection
and Test to be performed during development, production
and upon completion of the contract (acceptance
test).
o R̲e̲c̲o̲r̲d̲s̲
All inspection and test results - as well as any
other events significant for the documentation
of the product quality - are recorded and kept
in the QA files until completion of the contract.
7.4 D̲E̲T̲A̲I̲L̲E̲D̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
In close cooperaton with the Ministry of Foreign Affairs,
Christian Rovsing A/S will establish a System Requirments
Specification, SRS. The SRS will, when delivered by
Christian Rovsing A/S and approved by the Ministry
establish a baseline for the LKSAA.
In the SRS all the detailed requirements for the LKSAA
will be described. All areas in RFP and in this proposal
must be covered and any open items must be resolved
before the subsequent project phases can be initiated.
7.5 D̲E̲S̲I̲G̲N̲
The design of the LKSAA will be based on similar projects
conducted by Christian Rovsing A/S. Existing subsystems,
which are available for the LKSAA will be identified
and utilized in order to give a good cost-efficient
solution to the Ministry of Foreign Affairs.
Design of hardware will benefit from the very flexible
and modular concept of the CR80 computer. The basic
concept of the hardware configuration is a dualized
computer, which is similar to many existing systems,
e.g. CAMPS. All controlling and monitoring terminal
equipment will be connected directly to the CR80 through
a number of Channel Units.
In order to interface to various user terminals throughout
the Ministry a standard Local Area Network has been
included. Additional network can be installed as the
need arises.
The crypto subsystem is the only major hardware subsystem,
that may require new hardware design of any extensive
effort, because detailed specifications are not yet
available, but based on our experienced with crypto
subsystems in other projects like FIKS, we believe
that our Local Area Network, which we propose to use
in a dualized fashion, is very well suited for the
management of crypto equipment.
Regarding design of software, we have proposed to use
the CAMPS software to a very large extent. Almost all
requiremtns in the LKSAA for message preparation, switching
and reception are already available in he CAMPS. CAMPS
has been designed on input from all major NATO countries,
and is parameterized to a large extent. This means,
that the LKSAA requirements wil not entail to much
new development.
All new design will be conducted, using the best management
techniques, like design reviews and configuration procedures
in order to achieve the best system for the Ministry
of Foreign Affairs.
Below are presented the baselines that will be established
for each of the phases:
- Preliminary Design
- Detailed Design
- Code and SW Unit Test
- Subsystem SW Integration and Test
7.5.1 P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲D̲e̲s̲i̲g̲n̲
The objectives related to the preliminary design are
to establish the following baseline documents:
- Specification of packages within the subsystems
- Allocation of requirements/functions to all packages
- Specification of detailed interfaces between subsystem
and packages
- Definition of data
- Specification of Data Base Design
The level of documentation applied to the subsystems
is defined in the Subsystem Documentation Standard
SD/STD/013.
The subsystem/package interfaces will be documented
in a LKSAA Application Software Interface Control Document.
Each interface will be specified to the level of the
applied calling mechanism and passed parameters.
Global data and files will be documented in a LKSAA
Software Data Definition Document. Each data item will
be specified to at least the logical level.
The Data Base Design Document will define all files
and their logical contents. In addition the files will
be allocated to medias in order to obtain optimal performance.
The preliminary design baseline will be established
by a Preliminary Design Review (PDR) involving Ministry
of Foreign Affairs, the Software Team, the System Engineering
Team, and Quality Assurance Department. Respectively,
the preliminary design baseline for the Application
Software will be established by the Control Design
Review.
When the management team has approved the baseline
the detailed design will be initiated.
7.5.2 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The documents which represent the baseline for detailed
design are those produced during preliminary design
as well as those applicable to the preliminary design.
The objective with the detailed design baseline is
to establish "as-to-be-coded" design documentation.
The subsystem design described above will be designed
in further details and will be documented in a set
of package design documents.
Packages will be broken down into processes and software
modules.
The Software Interface Control Document will be expanded
to contain a detailed description of each parameter
in each of the package/subsystem interfaces.
Likewise the Software Data Definition Document will
be expanded to contain a detailed definition of each
data item.
In order to maintain a current and accurate design
specification during this and subsequent phases the
concept of Unit Development Folders (UDFs) will be
applied.
The fundamental element in the software design and
development is the Unit Development Folder (UDF), which
is an essential working tool for the program developer.
The UDF begins with the definition of requirements
to be implemented within the unit, from which preliminary
and detailed design description is derived and unit
development test plan(s) describing the development
testing activity. To this is added a list of test cases
that will demonstrate that the unit meets the requirements
and is free of errors and anomalies.
The detailed design baseline for the System Software
will be established by Critical Detailed Design Review
(CDR) involving The Ministry of Foreign Affairs, the
Software Team, the System Engineering Team, and the
Quality Assurance Department. The detailed design baseline
for the Application Software is only an internal baseline,
but will be established by a contractor internal critical
design review.
7.5.3 C̲o̲d̲e̲ ̲a̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The objective of this phase is to produce software
units which are tested to the extent that they are
ready for software subsystem integration and test.
The concept "unit" means an entity consisting of software
modules, which makes up a functional area.
During the process, the design description may be revised
to make it reflect the coded unit. Thus, as the unit
evolves from its initial checkout state to a completely
tested segment of code, the UDF progresses from a "code-to"
specification to an "as-built" specification. By the
time the unit is ready for integration with other units,
the product specification for the unit is complete,
including updated flow charts.
An overview of the contents of UDF test specifications
and procedures are presented in the following.
Unit testing involves the testing of each module using
selected inputs, executing the code, and evaluating
module outputs. The primary intent of unit testing
is to prove that the module solves the right problem.
There are standards of measurement of success of testing
which always is used to insure that sufficient detailed
unit testing has been accomplished.
7.5.4 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The objective of this baseline is to achieve fully
integrated and tested subsystems to be delivered for
system integration and verification.
The subsystem integration is based on the software
integration plan and associated test specifications
and procedures.
Integration testing verifies the linkages between the
software modules which make up entire functions, programs,
and system. Integration testing begins when individual
units/modules start to be merged together according
to the top-down methodology described below.
Integration testing is satisfied when the entire program
responds properly and the module to module interfaces
are shown to have been defined and implemented correctly,
in addition to execution timing and core storage assessment.
It is during integration testing that it is shown that
varied inputs representative of the ranges required
for overall performance produce the expected results
and that the total software package meets the performance
and design requirements.
The sequence of integration of the modules, units,
elements or subroutines into larger and larger testable
packages or groups is simply the application of the
top-down concept to achieve a systematic verification
process.
The t̲o̲p̲-̲d̲o̲w̲n̲ approach to integration starts with the
testing of the highest level system segment once it
is coded. Since this segment will normally invoke or
include lower level segments, code must exist for the
next lower level segment. This code, called a program
stub, may be empty, may output a message for debugging
purposes each time it is executed, or may provide a
minimal subset of the functions required. These stubs
are later expanded into full functional segment, which
in turn require lower level segments. Integration is,
therefore, a continous activity throughout the development
process. During testing, the system executes the segments
that have been completed and uses the stubs where they
have not been completed. It is this characteristic
of continous integration that reduces the need for
special test data drivers. The developing system itself
can support testing because
all the code that is to be executed before the newly
added segments has previously been integrated and tested
and can be used to feed test data to the new segments.
For this reason, most problems are localized to the
recently added code. As the new segments are tested
within the developing system, the control architectue
and system logic are also tested.
In general top-down offers the following advantages:
- simple individual tests
- simple identificaiton of suspect areas
- no need to develop special versions of any program
except for all the stubs.
Below some guidelines are presented for developing
integration test cases to insure that the desired level
of confidence in the overall software product has been
obtained from the integration test phase.
Insure that:
- All components are available and that they have
been unit tested
- Module interfaces are completely defined and properly
implemented
- Modules which perform more than one function meet
applicable requirements and acceptance cirtieria
- Necessary inputs and outputs are properly handled
- The expected ranges of output are evaluated with
respect to the input range of variables between
modules
- There are no unsatisfied external references
- Program entities change only those other entities
that have been designed to be changed or that act
as communication media
- Subroutines preserve and restore all common locations
and register they use, as desired
- Shared storage is protected
- Communication is maintained between dependent loops
so that proper sequencing is maintained
- Error conditions are detected and properly identified
in messages
To establish a baseline for system and application
software, subsystem test report will be produced. The
subsystem integration and test baseline will be established
by the Test Readiness Review.Upon approval the system
integration the test phase will be initiated.
7.6 I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
The new system development required for LKSAA can be
achieved in a similar fashion to ensure the most efficient
system implementation. This model can provide the most
efficient manpower utilization because all documentation
is done before actual coding, allowing easy integration
of new engineers in all phases of the program. This,
in turn, provides a high degree of freedom in manpower
planning throughout the program in order to ensure
fulfilment of the implementation schedule.
A detailed implementation schedule will be established,
which will be used by all parties to ensure timely
availability of all components of the system. The objective
of providing the LKSAA on schedule can only be achieve
if all participants in the project accept their respective
responsibilities.
7.7 A̲S̲S̲E̲M̲B̲L̲Y̲ ̲A̲N̲D̲ ̲F̲A̲C̲T̲O̲R̲Y̲ ̲T̲E̲S̲T̲
7.7.1 F̲a̲c̲t̲o̲r̲y̲ ̲T̲e̲s̲t̲i̲n̲g̲ ̲o̲f̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲
Two levels of test will be conducted on the Hardware
in the system integration period:
a) Incoming Inspection tests
b) Hardware System tests.
7.7.1.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲s̲
A set of Incoming Inspection Tests will be developed.
The scope of each test is to verify individual subsystems
as stand-alone devices.
Incoming inspection test procedures will be developed
for terminals, peripherals etc.
7.7.1.2 H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲s̲
A set of procedures will be developed with the scope
to verify the integrated LKSAA Hardware.
These procedures will be used to verify the Hardware
System prior to shipment. These procedures shall verify
that all Hardware functions required to support the
system operation are functioning properly.
The company has extensive experience in integrating
various makes in hardware, terminals, peripherals,
etc. using this testing mode and has extensive documentation
on procedural items to be addressed in this phase of
testing.
7.7.2 F̲a̲c̲t̲o̲r̲y̲ ̲T̲e̲s̲t̲i̲n̲g̲ ̲o̲f̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The LKSAA development test activity is based on a building
block approach.
Through application of a structured design principle
the software system is broken down into a number of
hierarchial levels. On each level the software is partitioned
into units which are documented and tested individually.
In relation to testing the structured design principle
has the following advantages:
a) it is easier and therefore more economical to detect
and locate errors in small pieces of software.
b) intensive testing of units individually prior to
their integration and testing together reduces
errors discovered later to interface errors.
c) in small units it is possible to execute a comprehensive
paths test. It is seldom feasible to attempt such
analysis after the units have been combined.
7.7.2.1 U̲n̲i̲t̲ ̲T̲e̲s̲t̲i̲n̲g̲
The term software unit as used above implies, that
a software unit can exist at different levels in the
software hierachy. A unit at one level can therefore
be composed of units from a lower level.
For description of the planned testing principles it
is appropriate to divide software units into two groups:
a) elementary units, i.e. units which can not be further
subdivided into individual units.
b) compound units, i.e. units which consist of more
than one elementary unit.
7.7.2.1.1 E̲l̲e̲m̲e̲n̲t̲a̲r̲y̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲i̲n̲g̲
The purpose of elementary unit testing is to verify:
a) that the unit meets its functional, performance-
and interface specifications
b) the correctness of the implemented code with respect
to:
1) Control structure
2) Data handling
7.7.2.1.2 C̲o̲m̲p̲o̲u̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲i̲n̲g̲
After the elementary units have been tested individually
they are integrated into compound units. The integration
process is conducted in an incremental manner. This
implies, that initially two individually tested units
are combined and tested for verification of their combined
specification regarding functional-, performance and
interface capabilities. After successful completion
of this test an additional individually tested unit
is integrated and the added capabilities tested and
verified etc., etc..
7.7.2.1.3 U̲n̲i̲t̲ ̲T̲e̲s̲t̲i̲n̲g̲ ̲S̲u̲m̲m̲a̲r̲y̲
From the above described unit testing approach it is
seen, that code dependant testing is only performed
during the elementary unit test.
All subsequent testing is for each step in the incremental
process a testing of the specified functional-, performance-
and interface capabilities, which are relevant for
the actual compound unit under test.
7.7.2.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
Package integration and test is accomplished through
successive integration and execution of compound unit
tests, until the defined package level of the software
hierachy is reached.
7.7.2.3 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲T̲e̲s̲t̲ ̲E̲v̲a̲l̲u̲a̲t̲i̲o̲n̲
The development test activity consists of:
a) elementary unit testing
b) integration and test up to software package level.
For evaluation of the development test activity a detailed
test documentation will be provided. Each test activity
will be documented by means of:
- a test specification
- test procedure(s)
- a log of test results
Prior to execution of each test activity a review of
the related test specifications and -procedures will
be conducted. The purpose of this review is to ensure
compliance of the test specification with unit requirements.
Further the review shall ensure, that the defined testcases
have a sufficient coverage to establish confidence
in the correct functioning of the units.
7.7.2.4 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
7.7.2.4.1 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲ ̲&̲ ̲T̲ ̲a̲n̲d̲ ̲S̲y̲s̲t̲e̲m̲ ̲I̲ ̲&̲ ̲T̲ ̲T̲a̲s̲k̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The (Sub)System I & T task consists of combining the
Hardware Subsystem, the System Software Subsystems
and the Application Software Packages to become the
complete LKSAA system.
The (Sub)System I & T activity is planned to be conducted
in the following way:
By means of the LKSAA Hardware- and System Software
Subsystems the Application Software Packages are one
by one integrated and tested by execution of the contained
system functions.
In order to facilitate initiation of (Sub)System I
& T at an early stage of the development process, the
software will be integrated in builds (a build is defined
as a selfcontained part of a software package which
is defined by the contained system function). The complete
software package is established by successive addition
of the constituent builds.
By careful planning and coordination of the functions
to be contained in the defined builds, the System I
& T can be conducted as an almost continuous process.
Some advantages of the build development approach are:
a) improved monitoring of the development progress
by dividing the development task into subtasks
(builds).
b) the System I & T activity can start when only a
part of the development process is completed.
c) error identification is simplified by following
a systematic incremental integration procedure.
7.7.2.4.2 I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲O̲u̲t̲l̲i̲n̲e̲
The sequence by which the Software Packages are integrated
is chosen from an operational point of view. This means,
that the System I & T process is initiated by verification
of the System start-up functions. Hereafter simple
user functions are tested followed by message handling
functions etc. etc..
By following this strategy the System I & T task can
be defined as a sequential execution of a number of
workpackages, each consisting of one step in the System
I & T process. Each step in the integration process
consists of addition of an application software package,
or a build hereof, to the already integrated and tested
part of the LKSAA Software System. For each step the
contained functions of the added software are tested
and verified.
After completion of a certain number of workpackages
a System Build is defined.
7.7.3 A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲ ̲P̲l̲a̲n̲
Christian Rovsing A/S will provide an Acceptance Test
Plan, which describes all the tests to be performed.
This plan will also outline the schedule for delivery
and approval of all plans. AA will be given 2 months
for approval of the Test Plan.
7.7.4 F̲A̲T̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
All documentation pertaining to the FAT will be provided
to AA 8 weeks before the FAT for review.
7.7.5 M̲e̲s̲s̲a̲g̲e̲ ̲E̲m̲u̲l̲a̲t̲i̲o̲n̲
The proposed intelligent CR16 terminals can be used
to generate test messages during system testing.
7.7.6 S̲t̲a̲r̲t̲ ̲o̲f̲ ̲W̲a̲r̲r̲a̲n̲t̲y̲
After successful FAT performance the equipment remains
in Chistian Rovsing's possession, until final installation
and handover.- The warranty period starts with beginning
of the Acceptance Test.
7.7.7 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲i̲n̲c̲l̲u̲d̲e̲d̲ ̲i̲n̲ ̲F̲A̲T̲
All basic equipment to be delivered to AA will be tested
at the FAT.
7.8 I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲
7.8.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
a) Christian Rovsing A/S (contractor) shall make the
following major deliveries to Auswartigen Amt (customer):
o Equipment Installation Data
o Site Preparation Requirement
o Equipment Installation Drawings
o Delivery and Installation of Equipment
b) The equipment installation data shall specify the
physical characteristics of the proposed equipment.
c) Site Preparation Requirement (SPR) shall specify
the extent of site preparation Auswartigen Amt
must undertake before equipment is installed. Furthermore
the SPR specifies the division of responsibilities
between customer and contractor concerning site
preparation and installation. In order to generate
the SPR, Contractor will conduct a Site Survey
at Auswartigem Amt.
d) Packaging of central equipment and peripherals
will correspond to the requirements for air and
truck transport to the site.
e) The equipment installation drawings shall show
how the proposed equipment is installed and interconnected.
f) Delivery and installation of equipment will be
performed in accordance with the master schedule
after Contractor has verified that the sites has
been prepared in accordance with the Site Preparation
Requirements. The equipment is delivered C.I.F.
Site.
7.8.2 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲
a) The planning of the installation will start immediately
after contract award. The time span from contract
award to completion of installation will be divided
in two major phases:
1) Site Preparation
2) Site Installation
b) The main activities in phase 1 are:
1) Site survey 12 months prior to start of installation.
2) Preparation and delivery of site preparation
requirements 9 months prior to start of installation.
3) Site preparation by customer during month 9
to month 1 prior to start of installation.
4) Preparation and delivery of equipment installation
drawings 4 months prior to on-site installation.
5) Site readiness verification one month prior
to start of equipment installation.
The main activities in phase 2 are:
6) Transportation to site.
7) On-site installation.
c) A more detailed description of the phase 1 and
2 activities is presented in the following sections.
7.8.3 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲
The equipment installation data are found in chapter
2.4. The equipment installation data will specify the
characteristics of the proposed equipment with respect
to power, power consumption, heat dissapation, environmental
conditions, weight, dimensions, and floor load.
7.8.4 S̲i̲t̲e̲ ̲S̲u̲r̲v̲e̲y̲
a) Contractor will perform a site survey with customer
participation. The purpose of the survey will be
to gather information for the preparation of Site
Preparation Requirements and Equip Inst Drawing
and plans for on-site integration and installation.
b) An important task to be performed in conjunction
with customer during the survey meetings is to
determine the layout of the equipment rooms, the
locations of the AE workstations, and the cable
routing from the FmZ to the AE's.
c) Building schematics and civil engineering drawings
are to be used for the survey and should be handed
over to contractor at start of the survey.
7.8.5 S̲i̲t̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
a) Contractor will prepare site preparation requirements
(SPR) concerning the preparation of each site for
installation of the proposed equipment. The SPR
will be submitted to Customer for approval three
months after completion of the Site Survey.
b) The SPR will be based on the physical characteristics
of the proposed equipment, the equipment rooms
layouts, the surveyed cable routing and other pertinent
data collected during the site survey.
c) The SPR will specify equipment related requirements
to customers facilities concerning access, space,
power supply, grounding, power distribution, locating
of power outlets, heat dissipation, cable ducting,
etc. The SPR will contain floor plans showing the
layout of all major assemblies of the proposed
equipment.
7.8.6 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲D̲r̲a̲w̲i̲n̲g̲s̲
a) Contractor will deliver equipment installation
drawings to Customer for approval 4 month prior
to start of installation.
b) The approved installation drawings will be used
for the installation of the proposed equipment
on each site.
c) The equipment installation drawings will be based
on the approved site preparation requirements,
the hardware configuration and the equipment characteristics.
d) The drawings will show how the proposed equipment
is to be installed and interconnected.
7.8.7 S̲i̲t̲e̲ ̲R̲e̲a̲d̲i̲n̲e̲s̲s̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) Contractor and Customer will jointly perform a
site verification. The verification will take place
30 days prior to the scheduled installation date.
b) The purpose is to verify that the site is ready
for installation, i.e. that the site is prepared
in accordance with the preparation requirements.
c) Final arrangements concerning transportation to
site and contractor's presence at site during installation
and test are also to be made at time of site verification.
7.8.8 T̲r̲a̲n̲s̲p̲o̲r̲t̲a̲t̲i̲o̲n̲ ̲
a) The delivery of equipment will follow the master
schedule. Actual shipping dates are selected to
be in accordance with the readiness of site and
time for transportation.
b) The equipment will be shipped by air or truck and
packed accordingly. Contractor will arrange the
transportation so that his installation team will
be present at site for receipt and unpacking of
the equipment.
c) The packing and marking are proposed to be in accordance
with contractor's standard procedures for CR80
equipment. The following is a brief discussion
of the method:
d) The computer equipment is constructed in a modular
fashion, i.e. 19" racks containg crate assemblies
with plug-in modules. This is reflecting in the
packaging as follows:
1) Modules are packed in styrofoam containers
designed to fit each module size. A number
of modules are put into a cardboard box or
similar of Europe pallet standard size.
2) Crates are packed with styrofoam corners so
that they fit into a cardboard box of Europe
pallet standard size.
3) Each rack or cabinet bay is separately packed
on a wodden pallet, protected with styrofoam
corners, and wrapped in plastic sheets. A skeleton
of timber protects the five free surfaces.
e) Packing lists are forwarded with every shipping
container. One copy of the packing list is enclosed
in the container; on copy will be attached to the
exterior of the container in an envelope clearly
marked "packing list".
f) Each container is to be clearly marked on the exterior
surface with at least:
o purchaser identification
o manufacturer's name and address
o shipping address
In addition each container is clearly labelled with
the identification and number of pieces in the shipment
and with precautionary labelling applicable to handling.
7.8.9 S̲i̲t̲e̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
a) Christian Rovsing A/S will set up an installation
team to perform the installation. The team will
install the equipment in accordance with the Customer
approved installation drawings. Any changes during
installation will be marked on the drawings. Corrected
drawings will be submitted to Customer after completion
of site installation.
b) Installation check-out encompassing hardware verification
will be performed in accordance with an installation
check-out procedure. This task will complete the
installation.
7.9 T̲R̲A̲I̲N̲I̲N̲G̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
Approx. 50 users and operators participating in the
acceptance test of the system shall be trained.
7.9.1 I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Contractor shall supply On-The-Job-training, enabling
the students to use work instructions and procedures
for using and operating the peripheral equipment, specially:
- peripherals in the FmZ
- in- and output equipment in the FmZ, f.ex. the
textreader, printer, word processors and telex
- word processor positions in the FmZ (positions
for trainers are foreseen)
- Crypto-operator in FmZ
- Radio-postition in FmZ
7.9.2 T̲r̲a̲i̲n̲i̲n̲g̲
Thorough training is required for the operating personnel,
including deep knowledge of the system.
The training shall include the knowledge and skills
required for the factory acceptance test of the system.
Contractor shall provide a detailed training plan with
the proposal, describing the foreseen training.
The training program shall be based on the assumption
that the maintenance of system is carried out by contractor.
7.9.3 T̲r̲a̲i̲n̲i̲n̲g̲ ̲P̲r̲o̲g̲r̲a̲m̲ ̲P̲l̲a̲n̲
A Training Program Plan is included as Appendix A,
describing in detail all the training proposed.
The length of one course week described in the Training
Program Plan is 30 lessons of 45 minutes. Please refer
to Appendix A. The courses are assumed to be conducted
during normal working days and hours.
7.9.4 O̲p̲t̲i̲o̲n̲a̲l̲ ̲T̲r̲a̲i̲n̲i̲n̲g̲ ̲C̲o̲u̲r̲s̲e̲s̲
All the courses described in the Training Program Plan
in Appendix A can be conducted by the contractor up
to 15 years after delivery and acceptance of the system.
It is assumed that these courses are conducted at customer
site, using customer facilities and equipment.
The price for the optional courses are negotiated when
requested by the customer.
Contents and scope the courses will be identical to
the initial courses conducted according to the initial
contract.
7.9.5 T̲r̲a̲i̲n̲i̲n̲g̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Students are provided with copies of visual aids (on
paper). Otherwise, the course is based on manuals as
described in the documentation section of this proposal.
7.10 O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲T̲E̲S̲T̲S̲
7.10.1 P̲u̲r̲p̲o̲s̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲T̲e̲s̲t̲
The purpose of this test is to give a final verification
of the operational performance and of the LKSAA System.
7.10.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The verification of the LKSAA System operational performance
is accomplished by operating the system in a live operational
mode.
The test will take place under the contractor's supervision,
but LKSAA personell will operate part of the system
in accordance with agreed test procedures and within
the specified message and transaction loads and characteristics.
7.11 A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲ ̲T̲E̲S̲T̲
The acceptance test criteria shall be that the LKSAA
shall be able to execute the software functions and
the message and transaction load according to the approved
system requirement specification.
An overall acceptance plan will be written by the contractor
and must be agreed between the contractor and the Ministry
of Foreign Affairs. This acceptance plan will specify
the following areas:
- Purpose
- Hardware Configuration
- Software Configuration
- Scope and Constraints for the Operational Tests
- Acceptance Test Specification and procedures
- Acceptance Criterias
- Organizatorial Responsibilities
- Schedule for the Operational Tests
- Deliverables
The acceptance test specification and procedures will
be written by the contractor and must be agreed between
the contractor and the Ministry of Foreign Affairs
as an acceptance criteria for the handover of the LKSAA.
The acceptance test specification and procedure will
be written according to the contract conditions and
the following guideline:
The Acceptance Test Specification shall include the
following information:
1) R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲. List the individual requirements
to be demonstrated by the test.
2) S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲. Provide a detailed list
of the functions of the system which will be
exercised during overall system testing.
3) S̲y̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲d̲i̲t̲i̲o̲n̲s̲. Indicate whether the
system test is to be made using normal system
inputs (type, magnitude or frequency) and database
or whether a special set of exercise inputs
and exercise database is to be used.
4) E̲x̲t̲e̲n̲t̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲. Indicate:
- The extent of testing to be employed.
- When total testing is not ot be employed,
the test requirements either as a percentage
of some well defined total quantity or
a number of samples of descrete operating
conditions or values and the rationale
for adopting limited testing.
5) D̲a̲t̲a̲ ̲R̲e̲c̲o̲r̲d̲i̲n̲g̲. Indicate data recording requirements
including those data types not normally recovered
from the system.
6) Sy̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲s̲t̲r̲a̲i̲n̲t̲s̲. Indicate the anticipated
limitations imposed on the test due to system
or test conditions.
7.12 W̲A̲R̲R̲A̲N̲T̲Y̲ ̲A̲N̲D̲ ̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲
7.12.1 G̲e̲n̲e̲r̲a̲l̲
The maintenance concept described and priced in this
proposal is based on Christian Rovsing A/S (CR) having
maintenance technicians placed within the Auswartigen
Amt (AA) during the warranty period. Latest one year
before the warranty has expired, a maintenance contract
shall be negotiated.
The work to be performed under such contract will be
the same as during the warranty periode. A statement
of work is described in Appendix D, Annex I-IV.
In case that AA wants to take over the responsibility
for On Site System Maintenance, an alternative maintenance
proposal can be found in Appendix D, Annex V.
7.12.2 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲
The purpose of the Maintenance Planning Phase is to
establish a complete maintenance program which will
fulfill the contractual requirements for maintenance
and insure system reliability and availability to AA.
Simultaneously it shall provide a solid base for the
development of a detailed maintenance documentation.
7.12.3 M̲a̲i̲n̲t̲a̲n̲e̲n̲c̲e̲ ̲P̲l̲a̲n̲
a) I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The basic philosophy used in the configuration
of the system is to enable maintenance, both preventive
and emergency, to be performed with a minimum of
system downtime thereby meeting the availability
requirements. This is achieved through the use
of redundant hardware modules and by extensive
use of the board swap principle once the sophisticated
fault detection software has isolated a faulty
assembly.
b) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
Maintenance engineering describes the effort in
the area of maintenance and support necessary prior
to the installation of the equipment.
The general approach to preventive maintenance
is that the applicable procedures are referenced
via an overall system maintenance sheet incorporated
in the various technical manuals. The special
tools and test equipment which will be used for
maintenance are listed and their applications shown
through scenarious displaying the structure of
the hardware with breakpoints.
A failure reporting system will be generated and maintained
according to the contractual conditions.
Incorporated in this system are:
- A maintanance record which will be filled in at
the installations and used in the screening of
systematic errors and used to modify the spare
parts stock.
- a log book which will be located at the installation.
- Field Change Notices used as applicable for updating
of the systems.
c) O̲n̲-̲S̲i̲t̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
During the warranty period a resident system maintenance
specialist will be on-site during normal business
hours
Outside normal business hours a one hour "on-call"
service will be established.
The technicians selected to perform system maintenance
are having several years experience in supporting
similar systems. The technicians will carry out
preventive and corrrective maintenance both on
the CR80 equipment and the connected peripherals.
The preventive maintenance required on the CR80
equipment is restricted to simple tasks such as
cleaning of dust filters, inspection of LED's etc.
Emergency maintenance will typically be carried
out on a module/terminal exchange basis. The trouble
shooting techniques developed for the system configuration
will enable the maintenance personnel to isolate
and replace modules in the CR80 equipment within
one hour. Also the technicians will perform modifications
according to Field Change Notices.
d) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The maintenance technicians will carry out 1st
level maintenance consisting of preventive and
emergency maintenance as previously described.
In most cases logic boards with known faults will
be returned to Christian Rovsing A/S for repair
and then returned to the spare parts complement
of the site. In some instances faulty module,
i.e. power supply, fan assembly, will be repaired
on-site. Christian Rovsing A/S will provide 2nd
and 3rd level maintenance through field service
engineers, in house repair facilities, and software
maintenance support.
7.12.4 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
7.12.4.1 P̲r̲e̲v̲e̲n̲t̲i̲v̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Preventative maintenance will be carried out by the
site technicians, in accordance with the procedures
established in the maintenance manual. The overall
design of the system utilizing redundant hardware will
insure that preventive maintenance will have a minimal
effect on the performance of the system.
7.12.4.2 E̲m̲e̲r̲g̲e̲n̲c̲y̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Emergency maintenance, i.e. fault identification and
module replacement will be carried out by the site
technicians. Repair of defective subassemblies will
be undertaken by Christian Rovsing A/S at no cost during
the warranty period.
Isolation of faulty subassemblies is accomplished by
the use of both on-line and off-line diagnostic software
programs. As stated elsewhere in this proposal, on-line
error detection programs will detect hardware faults
when they occur. This is accomplished both by background
checks and by error detection during data transfer
from one subsystem to another. Depending on the type
of fault the "Watchdog" subsystem will reconfigure
the system designating the standby processor as active.
The defective subsystem is now off-line where further
fault diagnosis can take place in the event the on-line
diagnostic program did not give specific error identifications
pinpointing a specific module. The off-line diatnostic
program provides for a much more thorough check of
the various elements of a subsystem. In addition,
this program will be used to verify repaired modules.…86…1
…02… …02… …02… …02…
7.12.4.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Software Maintenance will be performed as a combination
of on-site and on-plant activities. A technician will
be able to on-site to collect documentation for debugging
such as disc dumps, memory dumps, procure trace-outs
and error-reports. This information will be sent or
brought to the plant for in-depth analysis by software
experts. After software error correction or enhancements
the relevant software packages will again be installed
on-site by a technician. The technician will also be
able to include patches on the system. The system can,
as an option, be provided with facilities to load modified
software and include patch files as a normal operator
command i.e. without assistance from a technician.
Tools for software development and maintenance are
briefly described in the Technical Proposal, Volume
II, part 1, section 2.2.2. These tools can be executed
under an optional version of the High Level Operating
System by setting the stand-by Processor Unit in off-line
mode.
7.12.5 F̲i̲e̲l̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲
Field service engineers will be available from Christian
Rovsing A/S facilities in Copenhagen. This function
will, together with the repair facilities and spares
stock provided at Christian Rovsing A/S, provide the
2nd level of maintenance. The 3rd level maintenance
is software and hardware maintenance support performed
by Engineers resident at Christian Rovsing. This personnel
will assist the Field Service Engineers in case of
severe problems.
7.12.6 S̲p̲a̲r̲e̲ ̲P̲a̲r̲t̲s̲
In order to retain the required availability following
factors are used in calculating the Recommended Spare
Part List (RSPL) for CR modules:
- The number of each type of modul used in the system.
- The Mean Time Between Failure (MTBF).
- The confidence level.
- The board repair turn-around time.
The spare parts for the peripheral equipment is the
sparepart lists recommended by the manufacturers.
The RSPL shall be discussed at a Provisional Conference
between AA and Christian Rovsing in order to establish
the "Approved Spare Parts List" (ASPL).
According to this philosophy the spare parts priced
in this proposal do not reflet the RSPL but are CRs
best estimate at the time of bid.
Delivery of the spare parts according to the ASPL will
take place simultaneously with system installation.
7.12.7 T̲o̲o̲l̲s̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The special tools and test equipment (T&TE) employed
during maintenance will be rather few due to the proposed
maintenance philosophy.
T&TE will be available on site from start of installation
phase.
7.12.8 C̲o̲n̲s̲u̲m̲a̲b̲l̲e̲s̲
Consumables such as ribbon, paper, tapes, discs are
not included in this bid, and are not covered by warranty.
7.12.9 R̲e̲p̲a̲i̲r̲
Repair of modules and subassemblies will be undertaken
by CR free of charge during the warranty period, as
specified in the RFP. After the warranty period a repair
contract can be negotiated.
7.12.10 C̲u̲s̲t̲o̲m̲e̲r̲ ̲S̲u̲p̲p̲o̲r̲t̲
It is assumed that the customer supplies reasonable
working space within AA organization including all
furnitures necessary to perform the associated paper
work. Additionally an office for general repair and
spare part stock shall be supplied including workbenches,
bookcases, chairs and file cabinets.
7.12.11 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲d̲
CR will maintain the equipment in the quantity and
configuration described in section 2.1.4 of this proposal
(issue 1.5). However, final selection of "Document
Printing System" (group 8, "Terminals") will be decided
before end of SRS phase. Any cost impact shall be negotiated.
