top - download
⟦f2f47dfde⟧ Wang Wps File
Length: 93660 (0x16ddc)
Types: Wang Wps File
Notes: ACDN/PIP/002
Names: »2877A «
Derivation
└─⟦46c7b66fa⟧ Bits:30006139 8" Wang WCS floppy, CR 0233A
└─ ⟦this⟧ »2877A «
WangText
X…00……00……00……00…5…0a……00……00…5…0b…1…02…0…09…0…0c…0
0…05…/…0b…/…01….…09….…0b….…0c….…0d….…0e…. -…09…-…0f…-…06…,…0d…,…02…+…08…+…0f…+…06…*…0b…*…0e…*…0f…*…02…*…07…)…0d…)…02…(…08…(…0c…(…0d…(…0e…(…0f…(…02…'…0a…'…02…'
&…0b…&…01…&…05…%…0a…%…00…$…08…$…0f…$
…02…ACDN/PIP/0002
…02…830515 …02…#
ACDN PROGRAM IMPLEMENTATION PLAN…02…issue 1 …02…ACDN
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
P̲A̲G̲E̲
1. INTRODUCTION
1
1.1 Scope
1
1.2 Applicable Documents
1
1.3 Abbreviations
2
2. ORGANISATION
4
2.1 Communications Division of CR
4
2.2 The ACDN Organisation
4
2.2.1 Program
Management
4
2.2.2 Project
Management
4
2.2.3 System
Engineering
8
2.2.4 Software
Engineering
9
2.2.5 Hardware
Engineering
10
2.2.6 Integrated
Logistics
Support
11
2.2.7 QA
and
Configurations
Management
13
2.2.8 Contracts
and
Budget
Management
Support
13
2.2.9 General
Line
Management
Responsibilities
14
3. CHRISTIAN ROVSING/AIR CANADA LIAISON
15
3.1 Authority
15
3.2 Reporting
15
3.2.1 Progress
Reports
15
3.2.2 Progress
Meetings
19
3.3 Approval and Submittal of Documentation
19
4. SUMMARY OF DEVELOPMENT ACTIVITIES
20
4.1 Contractual Milestones
20
4.2 Overall Work Breakdown Structure
23
4.3 Master Schedule
26
4.4 Deliverable Documents
27
4.5 Development Approach
28
4.6 System Development Baselines
31
4.6.1 System
Requirement
Baseline
31
4.6.2 System
Design
Baseline
31
4.6.3 Preliminary
Design
Baseline
32
4.6.4 Detailed Design Baseline
32
4.6.5 Implementation
Baseline
33
4.6.6 System
Verification
Baseline
33
4.6.7 System
Acceptance
Baseline
33
4.7 Verification Approach
34
4.8 Development and Migration Strategy
35
4.8.1 Migration Plan
35
4.8.2 Terminal Migration
38
4.8.3 Software Development Activities
41
5. PROJECT MANAGEMENT
44
5.1 Objective
44
5.2 Deliverable Items and Documents
45
6. SYSTEM ENGINEERING
46
7. HARDWARE ENGINEERING AND PROJECT
47
7.1 Development Approach
47
7.2 Organisation
49
7.2.1 Introduction
49
7.3 Work Break-down Structure (WBS)
51
7.4 Block Diagrams and Deliverables
52
7.4.1 Toronto
Node
52
7.4.2 Montreal
Node
54
7.4.3 Winnipeg
Node
56
7.4.4 Network
Management
Host
58
7.4.5 Electronic
Mail
Host
60
7.5 Schedule
62
8. SOFTWARE ENGINEERING
63
8.1 Software Development Approach
63
8.1.1 Software Development Lifecycle
63
8.1.2 Documentation
Produced
During
Development
68
8.1.3 Software
Development
Tools
70
8.1.4 QA
of
Software
Development
71
8.2 Organisation
72
8.3 Work Break-down Structure (WBS)
74
8.3.1 Summary
Software
Development
(WBS)
74
8.4 ACDN Software Documentation
75
8.4.1 ACDN
Software
Documentation
Tree
75
8.5 Schedule
77
9. INTEGRATION AND ACCEPTANCE TESTS
78
9.1 Objective
78
9.1.1 Subsystem
Integration
Testing
78
9.1.2 Acceptance
Tests
80
9.1.3 Particular
Acceptance
Tests
84
9.2 Organisation
85
9.2.1 System
Engineering
Test
Team
85
9.2.2 SW
Engineering
Integration
and
Test
Team
87
9.3 Work Break-down Structure (WBS)
87
9.3.1 Summary
Integration
and
Acceptance
Test
87
9.4 Deliverable Items and Documents List
88
9.4.1 Test
and
Integration
Documentation
Tree
88
9.5 Schedule
90
10. INTEGRATED LOGISTICS SUPPORT
92
10.1 Objective
92
10.2 Organisation
92
10.3 Work Break-down Structure (WBS)
94
10.4 Deliverable Items and Documents List
97
10.5 Schedule
97
11. APPLICABLE STANDARDS
98
12 DEPENDENCIES
99
APPENDICES (Separate Volumes)
A. Master Plan
B. Detailed Plan
C. Work Package Descriptions
D. Activity List
1. I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
1.1 S̲C̲O̲P̲E̲
The purpose of this implementation plan is to define
the overall plan for the development of the Air Canada
Data Network (ACDN).
Nothing in this document constitute contractual commitments.
The plan is a working document that will be maintained
throughout the life-time of the project. In the first
issue of the document many of the plans and work breakdown
structures contained herein are only defined at the
highest activity level. During execution of the project
these plans and work breakdown structures will be further
refined.
The plan is a complete description of the project.
It addressses all tasks through definition, implementation
and delivery of hardware and software components to
integration of these components into identified subsystems.
Furthermore, is addresses installation, training and
subsequent system maintenance support.
The emphasis is on the following major activities,
which are managed by Christian Rovsing:
- Project Management
- System Engineering
- Hardware Development and Production
- Software Development
- Integration and Factory Acceptance Test
- Transportation
- Site Installation and Test
- Site Acceptance
- Network Acceptance
- Documentation
- Logistics Support
- System Maintenance
- Implementation and Migration Plans
The plan is divided into several volumes:
- Main Document (this volume)
- Master Plan (Appendix A)
- Detailed Plan (Appendix B)
- Work Package Descriptions (Appendix C)
- Activity Data Base (Appendix)
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
(1) Contract between Air Canada and Christian Rovsing
A/S (CEP 82-7, dated 82.12.22).
(2) ACDN Documentation Plan
ACDN/PLN/0001, issue 3.
(3) ACDN System Requirements Specification
ACDN/SRS/0001, issue 5.
1.3 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
AC Air Canada
ACDN Air Canada Data Network
ACNC Current Air Canada Collins Network Controller
ARINC
ATP Acceptance Test Plan
BCS Basic Communication Software
CD Communications Division
CDR Critical Design Review
CGO AC Cargo Host
CI Configuration Item
CM Configuration Management
CNT CNCP Telex
CPCI Computer Program Configuration Item
CPH Copenhagen
cps Characters per Second
CR Christian Rovsing A/S
CRINT CR Internal (document)
CRT Cathode Ray Tube (of VDU)
CU Channel Unit
DD Deliverable Document
DDR Detailed Design Review
DOC Document
ECU Electronic Mail Host Channel Unit Subsystem
EMH Electronic Mail Host
EMP Electronic Mail Processor Subsystem
EMS Electronic Mail Software
ENAS External Network Access Software
EWP Engineering Working Paper
FAT Factory Acceptance Test
GWY Gateway (to the ACNC)
HAS Host Access Software
ICC Intelligent Communication Controller
ICD Interface Control Document
ILS Integrated Logistics Support
INAS Internal Network Access Software
ITS Integration Test Software
K 1024
lpm Lines per Minute
MMD Mini Module Disk Drive
NAT Network Acceptance Test
NCC Network Control Center
NCS Network Control Software
NCU Notal Switch CU Subsytem
NMH Network Management Host
NMP Network Management Processor Subsystem
NMS Network Management Software
NSP Nodal Switch Processor Subsystem
NSS Nodal Switch Software
OPNS AC Operations Host
OS Operating System
OTS Operational Test Software
PDR Preliminary Design Review
PIP Program Implementation Plan
PMH AC Passenger Management Host
PMS Protected Message Service
PSAT Provisional Site Acceptance Test
PSP Product Specification
PU Processor Unit
QA Quality Assurance
QC Quality Control
RES AC Reservation Host
RCCSH AC Regional Carrier/Corporate Services Host
SAT Site Acceptance Test
SCP System Control Subsystem
SCS System Control Software
SCU System Control CU Subsystem
SDR System Design Review
SITA
SMD Storage Modul Disk Drive
SRR System Requirement Review
SRS System Requirement Specification
SVR System Verification Review
TAS Terminal Access Software
TPL Test Plan
TPR Test Procedure
TRP Test Report
TSP Test Specification
UDF Unit Development Folder
VAT Version Acceptance Test
VCD Version Control Document
VDU Visual Display Unit (of CRI)
VIA AC VIA Reservation Host
VTAM Virtual Terminal Access Method
WBS Work Breakdown Structure
WP Work Package
WPD Work Package Description
WPN Work Package Number
WU Work Unit
YUL Montreal
YWG Winnipeg
YY2 Toronto
2. O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
The organization established by Christian Rovsing A/S
(CR A/S) around the ACDN project is described in the
following sections.
2.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲D̲i̲v̲i̲s̲i̲o̲n̲ ̲o̲f̲ ̲C̲R̲
At the time when the ACDN contract was awarded to CR
A/S, the company formed a new division - the Communications
Division. The Communications Division (CD) will generally
develop networks, communications products and message
switching systems. The CD is located in Ballerup,
Copenhagen, in a newly constructed building. This
building is specifically built to contain the facilities
needed for development, integration and test of communication
systems. The organizational placement of the Communications
Division with the CR company is shown on figure 2.1-1.
The Communications Division is managed by mr. J]rgen
H]g and mr. Hans J]rgen Jakobsen.
The organization of CD is shown in figure 2.1-2.
2.2 T̲h̲e̲ ̲A̲C̲D̲N̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The ACDN project resides organizationally within the
CD Projects Department. The ACDN project organization
is shown in figure 2.2-1.
Basically the ACDN project is organized to provide
concentrated attention to all phases of the development,
integration and test, and logistics support.
Geographically the ACDN project team is devided into
two groups, one based in Ballerup and one based in
Toronto at AC's premises.
The Ballerup group is the main project group. It has
the necessary organization and resources to perform
project management, system engineering, hardware engineering,
software engineering, project support, integrated logistic
support and support functions for configuration management,
quality control functions contracts administration,
budget administration and project administration.
The Toronto group is organizationally subordinate to
the project manager in Ballerup. Its organization is
designed for software engineering, and it has the necessary
resources for running a local project office, and for
performing configuration management.
Fig. 2.1-1…01…CR ORGANIZATION
Fig. 2.1-2…01…ORGANIZATION OF THE COMMUNICATIONS DIVISION
Fig. 2.2-1…01…ACDN PROJECT ORGANIZATION
2.2.1 P̲r̲o̲g̲r̲a̲m̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Communications Division Management has the ultimate
authority for approving all changes, additions and
deletions to the ACDN contract and to approve all contracts
with subcontractors.
2.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The ACDN Project Manager and the ACDN Deputy Project
Manager has been assigned the authority to manage and
direct the resources necessary to deliver the ACDN
systems. The major responsibilities include:
o P̲r̲o̲j̲e̲c̲t̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲ to determine the project "Success
Parameters" and ensure that they are coordinated
within the project.
o P̲r̲o̲j̲e̲c̲t̲ ̲O̲r̲g̲a̲n̲i̲z̲i̲n̲g̲, that is to develop a work breakdown
structure.
o P̲r̲o̲j̲e̲c̲t̲ ̲S̲t̲a̲f̲f̲i̲n̲g̲
o P̲r̲o̲j̲e̲c̲t̲ ̲D̲i̲r̲e̲c̲t̲i̲n̲g̲ to provide day-to-day management
and technical directions to the project staff.
o P̲r̲o̲j̲e̲c̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲.
o P̲r̲o̲j̲e̲c̲t̲ ̲S̲u̲b̲c̲o̲n̲t̲r̲a̲c̲t̲i̲n̲g̲.
o C̲u̲s̲t̲o̲m̲e̲r̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲.
The Toronto resident Project Group Manager is the representative
of Project Manager as authorized, and to perform liaison
between AC's Project Manager and CR's Project Manager.
The Project Group Manager reports to the Project Manager/Deputy
Project Manager.
The project manager reports to the Projects Department
Manager.
The Project Office in Ballerup is a support function
for the Project Manager. The Project Office shall
o maintain records of all written communications
pertaining to the ACDN project
o maintain a library of all written communications
o maintain records of all documents produced during
the projects
o maintain a library of all documents produced during
the project
o distributed documents as defined in the associated
distrubution lists
o distributed DCNs to all holders of the corresponding
document
o forward copies of all documents produced in Ballerup
to the Toronto Project Office
The Toronto Project Office is a similar support function
for the Toronto Project group manager. The Toronto
Project Office shall
o maintain records and a library of all written communication
received and sent by the Toronto Project group
o forward copies of such communication to the Ballerup
Project office
o maintain records of all documents produced locally
during the project
o submit copies of all such documents to the Ballerup
Project office
o maintain a library of all documents produced during
the project.
2.2.3 S̲y̲s̲t̲e̲m̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
System engineering and design analysis tasks will be
performed by the ACDN System Engineering group in close
collaboration with the CD System Engineering Department
to ensure that the ACDN software/hardware requirements
will result in a production of sw/hw that will be consistent.
The major areas of responsibilities are as follows:
- refinement of the PIP including the corresponding
WBDs
- control of the system engineering tasks and the
day-to-day direction of the system engineering
team
- creation of the System Requirements Specification
- establishment and control of software interfaces
between the subsystem components, and hardware/software
interfaces
- monitor and analysis of external interfaces
- establishment of the system design.
- evaluation of the software and hardware design
- perform the sizing analysis to monitor memory budgets
- perform the systems performance analysis
- review subsystems design
- perform the System Maintainability/Availability
analysis
- perform the system Integration and Acceptance Test
and design a test environment.
The System Engineering Manager reports to the Project
Manager/Deputy Project Manager. See section 2.2.9
for the general responsibilities of the System Engineering
Manager.
2.2.4 S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
The Software Engineering team has been assigned the
responsibility for the development of the software
used in the ACDN system. The major areas of responsibility
of the Software Manager:
- creation of a development plan and schedule, control
of software development, and the day-to-day direction
of the software team
- in cooperation with the CD System Engineering Department
Manager and the CD Product Development Department
Manager to create the work descriptions of the
tasks to be performed by the CD Products Development
Department
- creation of the work descriptions of the tasks
to be performed by the Toronto project team
- control of the software development tasks being
performed by the SD and possible other subcontractors
plus reporting of the progress
The major areas of responsibility of the Software Development
team are as follows:
- perform the preliminary design of all subsystems
in the application software
- perform the detailed design of all modules in the
application software
- perform the coding and unit test of all modules
- perform the integration and test of the software
plus assist in the acceptance test phase
- provide support during the installation and warranty
period
- perform the detailed design, code, test and integration
of the software to be used in the Test Drive System
(TDS)
- ensure that the development standards are being
enforced
- ensure that all documentation, internal and external
(deliverable), is produced on schedule and in accordance
with standards
Within the ACDN organization the Software Manager reports
to the Project Manager/Deputy Project Manager. See
section 2.2.9 for the general responsibilities of the
Software Manager.
2.2.5 H̲a̲r̲d̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
The Hardware Engineering team has been assigned the
responsibility for the development/coordination of
the hardware for the ACDN system. The major areas
of responsibility are as follows:
- Provide support to the Production Division during
final test and integration as well as to the maintenance
team during the installation and warranty period.
This support must be provided when required.
- perform refurbishment/re-integration of site equipment
before it is shipped for installation
- design lay-out of site equipment
- production of configuration drawings
- h/w development specifications on
o a system level and on
o a detailed level
- refinement of the PIP including the corresponding
work breakdown descriptions
- creation of the work descriptions of the tasks
to be performed by possible other subcontractors
- design and development of all special hardware,
cabeling, racks and all other items needed for
the ACDN system
- development, fabrication, and test of the Test
Drive System (TDS) supporting the software factory
acceptance test
Within the ACDN organization the Hardware Manager reports
to the Project Manager/Deputy Project Manager. See
section 2.2.9 for the general responsibilities of the
Hardware Manager.
2.2.6 I̲n̲t̲e̲g̲r̲a̲t̲e̲d̲ ̲L̲o̲g̲i̲s̲t̲i̲c̲s̲ ̲S̲u̲p̲p̲o̲r̲t̲
The Integrated Logistic Support team has been assigned
the responsibility of the following support activities:
- produce the plans for documentation, transportation,
installation, and training
- perform the site surveys and prepare for installation
- verify that all sites are ready for installation
- transportation of all final deliverable items to
the sites
- supervise and perform the installation of the ACDN
system and verify that the system is ready to undergo
the Site Acceptance Tests
- ensure that hardware and software support is provided
during the warranty period
- perform the training of the Air Canada personnel
- produce a Spare Part List and deliver the parts
to the sites
- develope the deliverable documentation related
to the ACDN project
Within the ACDN organization the Integrated Logistics
Support manager reports to the Project Manager/Deputy
Project Manager. See section 2.2.9. For the general
responsibilities of the ILS manager.
2.2.7 Q̲u̲a̲l̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲a̲n̲d̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The QC and CM team has been assigned the responsibility
for the overall quality control of the hardware and
software in accordance with the CD standards. The
major areas of responsibility of QC are as follows:
- monitor that standards for documentation are adhered
to
- monitor that development methodology standards
are adhered to
- monitor the quality of testing
- participate in reviews
- be responsible for QA of subcontractors on the
ACDN project
- monitor that change procedures are followed
- approve all deliverable documents and programs
The QC staff in Ballerup is responsible for all such
quality control and assurance activities whether pertaining
to project activities in the Ballerup group or the
Toronto group.
The CM team is responsible for:
- maintaining of proper hardware configuration control
- maintaining of proper software configuration control
- maintaining of proper documentation configuration
control
- maintaining of software retention libraries (backup
copies)
- maintaining a project software library
The Toronto project group has its own local CM resources.
The QC/CM Managers report directly to the Communication
Division Management.
2.2.8 C̲o̲n̲t̲r̲a̲c̲t̲s̲ ̲a̲n̲d̲ ̲B̲u̲d̲g̲e̲t̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲
The contracts and budget management support functions
shall assist the project manager in all routine administrative
matters pertaining to
- issue of invoices
- budgeting
- budget control
- execution of received invoices
2.2.9 G̲e̲n̲e̲r̲a̲l̲ ̲L̲i̲n̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
This section defines the general responsibilities of
each of the managers reporting to the Project Manager/Deputy
Project Manager. The project line managers are responsible
for that their part of the project is delivered on
time, within budgets and according to requirements.
This responsibility includes:
P̲r̲o̲j̲e̲c̲t̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲. Using the project guidelines,
develop the WBS elements for his part of the program,
and produce a schedule for their implementation.
P̲r̲o̲j̲e̲c̲t̲ ̲S̲t̲a̲f̲f̲i̲n̲g̲. Interface with the Project Management
during the planning of staffing to ensure proper
match of resources to project needs.
P̲r̲o̲j̲e̲c̲t̲ ̲D̲i̲r̲e̲c̲t̲i̲n̲g̲. Direct the technical activities
of work package managers within his area of responsibility.
Ensure that all started work activities include
all necessary data including task description,
funding and schedule.
C̲h̲a̲n̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲. Ensure that negotiated modifications
and changes to the program are communicated to
the implementing teams.
P̲r̲o̲j̲e̲c̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲i̲n̲g̲. Assess the performers output
to ensure that the activities are performed according
to the schedule, standards and specifications.
Ensure that the project's reporting requirements
are met at his level.
Q̲u̲a̲l̲i̲t̲y̲. Review deliverables/conduct reviews.
3. C̲H̲R̲I̲S̲T̲I̲A̲N̲ ̲R̲O̲V̲S̲I̲N̲G̲/̲A̲I̲R̲ ̲C̲A̲N̲A̲D̲A̲ ̲L̲I̲A̲I̲S̲O̲N̲
3.1 A̲u̲t̲h̲o̲r̲i̲t̲y̲
Acting on behalf of Air Canada is the Air Canada Project
Manager through whom all communication between AC and
CR shall be passed.
Acting on behalf of CR is CR's authorized Project Manager
or his authorized representative.
3.2 R̲e̲p̲o̲r̲t̲i̲n̲g̲
The reporting described in this paragraph deals solely
with progress reporting and progress meetings. Daily
communication via letters, telexes, etc. will not be
described here.
3.2.1 P̲r̲o̲g̲r̲e̲s̲s̲ ̲R̲e̲p̲o̲r̲t̲s̲
CR will submit to AC periodic reports according to
the contract paragraph 11.
The report will be preceeded by a table of contents
as illustrated by fig. 3.2.1-1. For each of the sections,
Management to Integrated Logistics support, CR will
report on Accomplishments since last report, near term
activities, and problems/issues if any related to activities
involving AC.
The accomplishments and near term activities are limited
to the contractual line items and are therefore identified
by a line item number.
The problems/issues will be reported on the form illustrated
by fig. 3.2.1-2. This form is used in order to assure
that each identified problem/isssue has been addressed
completely with a suggested action plan and actionee.
A̲p̲p̲e̲n̲d̲i̲x̲ ̲A̲ of the progress report will contain a status
over the contractual payments. Therefore, for each
payment in the payment plan the appendix will contain
an entry identifying the line item by number and title
and the status in form of
- date of completion
- date of AC receival
- date of approval if applicable
- date of invoice
- invoice number
- date of payment
A̲p̲p̲e̲n̲d̲i̲x̲ ̲B̲ contains a status over the Engineering Change
Proposals (ECP) and Engineering Change Orders (ECO)
issued on the ACDN program.
The ECP status contains the following detailed information:
- ECP number
- title
- date of issue
- name of responsible manager
- identification of approving telex of letter
- approval date
- ECO number(s)
The ECO status list contains the following detailed
information:
- ECO number
- identification of impacted configuration item(s)
- ECP number
- date of issue
- name of responsible manager
- identification of approving telex or letter
- approval date
A̲p̲p̲e̲n̲d̲i̲x̲ ̲C̲ contains the action item list indicating
the status over the actions to be performed by CR.
A̲p̲p̲e̲n̲d̲i̲x̲ ̲D̲ contains the action item list indicating
the status over the actions to be performed by AC.
…01…T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
I̲T̲E̲M̲ P̲A̲G̲E̲
MANAGEMENT ...................................
SYSTEM ENGINEERING ...........................
SOFTWARE ENGINEERING .........................
HARDWARE ENGINEERING .........................
INTEGRATED LOGISTICS SUPPORT .................
APPENDIX A, Contractual payment status .......
APPENDIX B, ECP/ECO status ...................
APPENDIX C, Action item List, CR .............
APPENDIX D, Action item List, AC .............
Fig. 3.2.1-1
Fig. 3.2.1-2
3.2.2 P̲r̲o̲g̲r̲e̲s̲s̲ ̲M̲e̲e̲t̲i̲n̲g̲s̲
Progress meetings will be held as stipulated in the
contract paragraph 11. One week prior to the meeting
CR and AC shall coordinate the agenda for the meeting.
The progress report described in 3.2.1 will be presented
at the meeting and handed over at the meeting. Therefore,
this item is always on the agenda.
For each meeting a minutes of meeting will be written
and approved prior to the end of the meeting.
3.3 A̲p̲p̲r̲o̲v̲a̲l̲ ̲a̲n̲d̲ ̲s̲u̲b̲m̲i̲t̲t̲a̲l̲ ̲o̲f̲ ̲d̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
This subject is covered by the contract special provision
paragraph 8.
4. S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲A̲C̲T̲I̲V̲I̲T̲I̲E̲S̲
4.1 C̲O̲N̲T̲R̲A̲C̲T̲U̲A̲L̲ ̲M̲I̲L̲E̲S̲T̲O̲N̲E̲S̲
Milestones month
---------------------------------------------------
program management
1 Down-payment
2 Program
Implementation
Plan
3 Ministry
Approval
equipment development and production
6 EMH,
Test
Environment,
FAT
7 EMH,
Spares
8 Hardware
Development
9 Toronto
Node,
FAT
10 Montreal
Node,
FAT
11 Winnipeg
Node,
FAT
12 Toronto
Node,
spares
+ consumeables
13 Depot,
Spares
and consumeables
14 Montreal
Node,
spares
and consum.
15 Winnipeg
Node,
spares
and consum.
system engineering
5 System
Requirement
Specification
16 System
Design
Specification
17 RMA Report
18 Test
Procedures
software development
19 BCS,
detail
design
20
unit
test
23 Prel
TAS/AC40x,
detail
design
24
unit
test
25 Prelim
INAS,
detailed
design
26
unit
test
27 Prelim
NCS,
detailed
design
28
unit
test
29 .............................VERSION
1 20
Milestones month
----------------------------------------------------
30 Prel. IBM VTAM/AC 40x, detail design
31 unit test
32 .............................VERSION 2 20
35 Prel. IBM VTAM/3270, detail design
36 unit test
.................................VERSION 3 20
21 NSS, detailed design
22 unit test
33 TAS, detail design
34 unit test
37 UNIVAC CMS, detail design
38 unit test
41 SCS, prelim design
42 unit test
43 NCS, prelim design
44 detail design
45 EMS, detail design
46 unit test
50 INAS, prelim design
51 detail design
47 .............................VERSION 4 28
39 UNIVAC VIA, detail design
40 unit test
48 ENAS, detail design
49 detail design
52 NMS, preliminary design
53 NMS, nmh/ncc
54 NMS, inventory control
55 NMS, statistical acquisition
56 NMS, network modelling
57 NCS, geo back-up, detail design
58 unit test
59 .............................VERSION 5 31
60 Volume Generator, prelim design
61 unit test
62 Message gen, detail design
63 unit test
Milestones month
----------------------------------------------------------
documentation
64 documentation plan
65 sys descrip manual
66 instal manual
67 operating manual
68 network operator manual
69 technical manuals
70 peripheral equip manual
71 programming and development tools
72 s/w description
training
73 training plan
74 maintenance course, prep
75 conduct
76 gen system course, prep
77 conduct
78 network course, prep
79 conduct
80 network oper course, prep
81 conduct
82 s/w course, prep
83 conduct
implementation
4 Site Survey Report
- EMH transportation and installation
84 Toronto Node, trans and installation
85 ..............VAT
86 Montreal Node, trans and installation
87 ..............VAT
88 Winnipeg Node, trans and installation
89 ..............VAT
90 Network Acceptance Test 33
91 Retension 33
4.2 O̲V̲E̲R̲A̲L̲L̲ ̲W̲O̲R̲K̲ ̲B̲R̲E̲A̲K̲-̲D̲O̲W̲N̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
This section presents the Work Breakdown Structure
(WBS) applied on the ACDN project.
The WBS is a hierarchical structure as illustrated
in the figure overleaf. All work packages necessary
for implementing the program will be included in the
WBS.
The following WBS groups are included in the structure:
W̲B̲S̲ ̲ ̲ ̲ ̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1.0 Program Management
2.0 System Engineering
3.0 Equipment, Production and Integration
4.0 Equipment Development
5.0 Standard Software
6.0 Software Development
7.0 Acceptance Tests
8.0 Documentation
9.0 Training
10.0 Transportation
11.0 Installation
12.0 Equipment Maintenance
13.0 Software Maintenance
The WBS is described by means of Work Package Descriptions
(WPD). The WPDs are constructed by performing a preliminary
design of the system. However, the WPDs do not represent
a design, but is used by the management team as a planning
tool to obtain enough visibility in order to control
what to produce, resource allocation, schedule, and
cost.
The WBS contains Summary Work Packages (SWP) and Work
Units (WU).
̲S̲u̲m̲m̲a̲r̲y̲ ̲W̲o̲r̲k̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲ have the following characteristics:
a. it represents a summary of lower level SWPs and/or
WUs (nesting 10)
b. it shall be specified by means of a WPD
c. it may or may not have childs specificed, dependant
of the stage of detailed planning
d it shall specify a clearly identifiable functional
task, eg. project administration, development of
a software system, etc.
e. it can be associated with a clearly defined organizational
entity such as a division, department project line
function or team
W̲o̲r̲k̲ ̲U̲n̲i̲t̲ have the following characteristics:
a. it represents the lowest level in the WBS
b. it shall be specified by means of a WPD
c. it is a clearly identifiable functional task which
one person may perform in a reasonable time (less
than 1 month).
WPDs can at any time be updated and will be updated
prior to turn over to a developer.
Figure 4.2-1
The ACDN Master WBS and second level WBS breakdown
may be found in Appendix A and B respectively.
4.3 M̲a̲s̲t̲e̲r̲ ̲S̲c̲h̲e̲d̲u̲l̲e̲
The ACDN Master schedule the timing of the major project
milestones identified in section 4.2 is included in
Appendix B.
4.4 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
The documents to be produced and delivered as part
of the ACDN project are defined in the Documentation
Plan.
4.4.1 O̲t̲h̲e̲r̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
During the project a number of additional working documents
will be produced which are not deliverables, but which
may contain information which is essential in order
to understand design decisions taken during the development
of ACDN. All such documents will be available to AC
and CR participants through the two document libraries
in Ballerup and Toronto.
4.5 D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
The implementation of the ACDN has three major objectives:
- based on top-down development and baseline management
provide an efficient overall technical control
of the ACDN development
- development to take place by means of an incremental
implementation where software is developed through
a number of builds
- migration from the existing ACNC network to the
new ACDN network aimed at meeting ACs objectives.
The baselines and development approach are further
described in the remainder of this section while section
4.8 describes the migration approach.
The following development phases have been defined
for the ACDN program:
- system requirement specification
- system design
- preliminary design
- detailed design
- coding and unit test
- subsystem integration and test
- system integration and test
- system acceptance
- network acceptance
Each phase results in establishment of a baseline.
At any time, during the ACDN program development cycle,
all previously established baselines together with
approved changes to the baselines, constitute the contractual
identification of the system.
To assure correctness and completeness of a baseline,
series of reviews, analyses and inspections are conducted,
during which the produced documents and components
are evaluated.
The use of early validation and verification accomplished
via reviews, walk-throughs, and analyses will furthermore
contribute to secure that the final product meets its
requirements. Furthermore, it provides management
with better tools to measure progress - and thus serves
to ensure proper attention to critical items thereby
providing the most important tool for schedule control.
The Requirements Specification phase is a refinement
of the commitments presented by the proposal as clarified
through the clarification notes and augmented by the
requirements of the Request for Sealed Tender. The
outcome of this phase is a specification for ACDN network
functional and physical capabilities; a document which
consists of contractual commitments of exactly what
is to be provided presented in an unambiguous way.
This document forms the baseline for the design and
subsequent validation processes; thus, an important
aspect of the document is to present commitments in
a form which is verifiable.
The System Design phase is a refinement and consolidation
of the design presented in the proposal. An important
part in this phase is that of decomposition of the
system into constituent subsystems and establishing
the exact functions and performance to be provided
by a given subsystem together with the exact interfaces
between subsystems.
When the system design phase is completed the subsequent
hardware and software development phases can proceed.
The software design is broken down into the following
phases:
- preliminary design
- detailed design
- coding
- unit test
- subsystem integration and test
while hardware development concurrently takes place
in the following steps:
- preliminary design
- detailed design
- fabrication and unit test
- hardware subsystem integration and test.
The software and hardware development efforts are concluded
in a
- system integration and test, and
- system acceptance.
The final Network Acceptance Test constitutes the last
phase of the ACDN development.
Figure 4.5-1 depicts the overall development lifecycle.
Figure 4.5-1
The development activities following the system design
phase are structured in a number of versions. A version
is a well-defined functional subset of the final system.
Versions serve as the vehicle for an effective the
migration plan.
4.6 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲B̲A̲S̲E̲L̲I̲N̲E̲S̲
The hardware and software implementation will be divided
into a number of subphases where each completed subphase
results in establishing of a baseline. The formal
establishment of a baseline is normally achieved through
a review or audit process where the baseline must be
approved. In order to distinguish between reviews where
approval is required from AC and reviews where approval
is a sole cr responsibility, the term 'internal review'
is used for the latter. However, AC participation is
encouraged for internal reviews in order to ensure
an optimal project implementation. The following subsections
describe the baselines.
4.6.1 S̲y̲s̲t̲e̲m̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The system requirement definition phase will be completed
by a System Requirements Review (SRR). The objective
of this review is to ensure the compliance and completeness
of the system requirements. After ACs approval of the
System Requirements Specification, and associated Interface
Control Documents, these will establish the baseline
for all subsequent development activities.
4.6.2 S̲y̲s̲t̲e̲m̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
During the system design phase, the system requirements
are broken down into subsystems and components of hardware
and software.
An internal System Design Review (SDR) will be scheduled.
The purpose of this is to ensure:
a) that the system design specification represents
a complete and optimal synthesis of the system
requirements
b) that the system is complete and feasible, and
…86…1 …02… …02… …02… …02…
c) that a technical direction is provided to the implementation
d) that a proper interface exists between subsystems
After approval of the system design specification by
the ACDN project management, this will establish the
design requirement baseline.
4.6.3 P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The actual design of subsystems identified during the
system design will be divided into two phases; the
preliminary design phase, and the detailed design phase
The preliminary design baseline (subsystem design)
is established prior to detailed design in order to
a) evaluate the progress and technical adequacy of
the selected design approach
b) determine its compatibility with the requirements,
and
c) assess the existence and compatibility of the physical
and functional interfaces between components that
make up subsystems
An internal Preliminary Design Review (PDR) will be
conducted to ensure correctness and adequacy of the
preliminary design baseline.
4.6.4 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
Before the actual implementation is initiated, internal
Detailed Design Reviews (DDR) will be conducted to
a) determine that the detailed design satisfies the
preliminary design baseline.
b) assess the exact interface relationship between
the components of each subsystem
After approval the detailed design forms the baseline
for implementation of the actual hardware or software
components.
4.6.5 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
When the Hardware/Software components have been produced
these shall be tested and integrated into subsystems.
The baselines are established when the subsystems have
been approved by the CR QA .
4.6.6 S̲y̲s̲t̲e̲m̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
At the time of completion of system integration and
verification, a System Verification Review is conducted
to verify that the system performs as required, and
that product specification, manuals, and handbooks
are accurate.
4.6.7 S̲y̲s̲t̲e̲m̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
The formal system acceptance phase has been separated
into a number of sub-phases each resulting in a baseline.
The Acceptance baselines are:
- Factory Acceptance baselines (Hardware)
- Provisional Site Acceptance baselines (Hardware)
- Version Acceptance baselines
- Network Acceptance baselines
For further details refer to section 9.
4.7 V̲E̲R̲I̲F̲I̲C̲A̲T̲O̲N̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
This section addresses the strategy to be applied in
order to assure that all requirements will be implemented
in accordance with the SRS and associated ICDs.
In order to assure that all requirements are identified
the ACDN system requirements defined in the ADCN System
Requirements Specification and associated ICDs will
be allocated to the pertinent hardware and software
subsystems. This is done during system design and will
be documented in a Verification Control Document.
To assure that the requirements are implemented in
the hardware subsystems/items the requirements will
be allocated to each subsystem/item in the Product
specifications or the Subsystem Specifications. The
detailed design review shall verify that the requirements
are accounted for. The test cases developed for the
items and subsystems will test the allocated requirements.
During the system integration and verification the
VCD will be used to track the requirements.
4.8 I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲M̲I̲G̲R̲A̲T̲I̲O̲N̲ ̲S̲T̲R̲A̲T̲E̲G̲Y̲
The purpose of this section is to provide an overview
on the development and migration activities taking
place at CR respectively AC facilities. Chapters 5
thru 10 provides the detailed planning of these activities.
The development activities and the migration of AC
terminals and hosts, existing as well as new, to the
new ACDN data network will be parallel activities.
Furthermore, it is envisaged that parallel development
activities will take place at CR's location in Ballerup
and at AC's location in Canada.
A number of measures will be taken to meet these targets:
o an initial development and test system will be
made available at AC facilities, Toronto early
1983.
o hardware will be configured to meet the changing
needs during the development phase.
o part of the network equipment is used by CR for
in-house development and test in Copenhagen.
o refurbishment to final configurations will take
place at AC facilities, Canada.
o software will be developed in versions aimed at
satisfying AC migration plans.
Development activities will start at the mutual acceptance
of System Requirements and proceed to the end of 1984.
Migration starts 2nd quarter 1984 and proceeds beyond
the final ACDN acceptance test until the full host
and terminal population has been taken over by the
ACDN network by end 1985.
4.8.1 M̲i̲g̲r̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲
This section presents in narration writing the migration
from the existing ACNC to the new ACDN in terms of
functionality.
The detailed functional capability migration appears
from the SRS. Furthermore this section may contain
AC provided information other than that necessarily
required for ACDN migration, details which provide
a better understanding of AC host/terminal plan. The
ACDN is developed and integrated with the ACNC in the
following baselines:
- VI (V1, V2, V3), acceptance 2nd. quater 1984
- V4, acceptance 1st quarter 1985
- V5, acceptance 2nd quarter 1985
The development, integration and acceptance schedule
are in accordance with the ACDN master schedule.
4.8.1.1 V̲e̲r̲s̲i̲o̲n̲ ̲V̲I̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Version VI of the ACDN consists of one node located
in Toronto and connected to the ACNC via a full functioning
gateway. The functional capabilities shall be provided
as specifyed in section 4.8.3.1. The attachments and
services supported by the ACDN shall be as follows:
a. Terminal Access Services
i AC40X terminals via ICC sites.
ii IBM 3270 SNA terminals
- These terminals shall have access to applications
on hosts connected to the ACNC and the
OPNS/CGO host connected to the ACDN
iii Standard TTY terminals
- These terminals shall have access to ACDN
supervisory function only in this version.
b. Host Access Services
i RES, VIA, Dorval Host via ACNC and gateway
ii OPNS/CGO host
c. ACNC Gateway Services
- Full gateway capability, including access service
for ACNC terminals to the OPNS/CGO host
d. Limited Network Control Service and Network Management
Service, Sufficient for support of the VI configuration.
The existing ACNC shall provide the following basic
capabilities for VI:
- Host handling (RES, VIA, Dorval Host)
- Terminal Handling for all devices connected to
ACNC
- Protected Message Service (PMS)
- External Network Access Services
The VI-ACDN shall be able to offload the ACNC and migrate
the current terminal population over a period of 18
- 24 months. This migration starts with 100 - 200 terminals
and is envisaged to grow by a rate of 200 - 600 terminals
per month (corresponding to 1 to 3 ICC site per month.)
4.8.1.2 V̲e̲r̲s̲i̲o̲n̲ ̲V̲4̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Version V4 of the ACDN consists of the VI configuration
with a node located in Montreal and an Electronic Mail
Host. Further the full set of NCC Services shall be
available except for the geographical backup capability.
The functional capabilities shall be provided as specifyed
in section 4.8.3.2.1.
The attachments and services of version VI shall be
supported plus the following:
…02…a. Terminal Access Services
i. Std. TTY fully operational
ii IBM 3270 BSC terminals
iii Intercolor terminals for the NCC functions
b. Host Access Services
i. RCCSH (Std. IBM VTAM)
c. Electronic Mail Services, which means that ACDN
can take full responsibility of the type B traffic,
thus relieving the ACNC of this capability.
e. Operational Test Services
d. Full Network Control Services and Network Management
Service except for the geographical backup
The ACNC shall provide the same services as for version
VI of the ACDN except for PMS, which can be taken over
by the ACDN EMS.
4.8.1.3 V̲e̲r̲s̲i̲o̲n̲ ̲V̲5̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Version V5 of the ACDN is the final ACDN consisting
of 3 nodes (Toronto, Montreal and Winnipeg) interconnected
by the backbone network. Furthermore the NCC's are
now dualized and the Network Management Host is included.
The functional capabilities shall be provided as specifyed
in section 4.8.3.2.2.
The attachment and services of version VI and V4 shall
be supported plus the following:
a. Terminal Access Services
i. 2780/3780 RJE
ii 3777 RJE, SNA
iii NTR
iv Uniscope 100/200
v. Low Speed TTY
b. Host Access Services
i. VIA connected to Toronto node
ii. Dorval Host connected to Montreal node
c. External Network Access Services
i ARINC interface
ii SITA interface
iii Low jSpeed P-P interface, incl. CNT
iv Telex interface
v PDN interface
d. Network Management Host services
e. Full geographical backup for the NCC service.
Figure 4.8-1
4.8.2 H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲t̲a̲g̲e̲s̲
The equipment is seen as stable configurations through
a number of phases identified as stages:
4.8.2.1 C̲R̲ ̲C̲o̲p̲e̲n̲h̲a̲g̲e̲n̲
a. June- Nov. 1983:
CR/stage 1
- Test and Development system 0 and 1
1. The TDS 0 and 1 will provide a development
environment for 20 simultaneous programmers.
b. Nov.-Dec 1983:
CR/stage 2
- TDS 0 and 1
- Toronto Node
1. The TDS 0 and 1 will Provide development environment
for 20 simultaneous programmers.
2. The Toronto Node will be configured as the
final nodal system. It will be used as test
bed and partly as development environment.
c. Jan. 84 - May. 84:
CR/stage 3
- TDS 0 and 1
- Montreal Node
1. The TDS 0 and 1 provide development environment
for 20 simultaneous programmers. It will be
used to hold the master versions.
2. The Montreal Node will be used 100% as test
bed for the unit test and system integration.
d. May-Dec. 1984:
CR/stage 4
- Winnipeg Node.
- NMH
- TDS 0 and 1
1. The Winnipeg Node and NMH will be configured
in its ultimate form to provide test bed for
unit and system test.
4.8.2.2 A̲C̲ ̲T̲o̲r̲o̲n̲t̲o̲
a. Feb.-Dec. 1983:
AC/stage 1
- EMH equipment
1. The EMH equipment will be configured into two
systems:
i a development system capable of supporting
6 simultaneous programmers. The total CRT
termination capability will be 12 CRTs.
ii a test bed environment enabling unit test
and system integration test-out.
b. Jan.-May. 1984:
AC/stage 2
- EMH equipment
- Toronto Node
1. The EMH equipment will be configured as stated
for AC/stage 1.
2. The Toronto Node equipment will be configured
serving two purposes:
i Gateway/FEP capability, i.e. provide the
environment for integration with:
- ACNC resources
- OPNS/CGO Host
- OPNS/CGO native terminals
ii Limited testbed capability for development
activities in Canada.
d. Jun.-Dec. 1984
AC/stage 3
- Toronto Node/NCC
- Montreal Node
- Electronic Mail Host
1. The Toronto Node/NCC will be in its final H/W
configuraton providing final nodal/network
control services.
2. The Montreal Node will be in its final H/W
configuration providing final ACDN nodal services.
3. The EMH will be in its final H/W configuration
providing final ACDN EMH services.
d. Jan. 85 - Jun. 85
AC/stage 4
- Toronto Node/NCC
- Montreal Node/NCC
- Winnipeg Node
- Network Management Host
- Electronic Mail Host
All equipment will be in their final configuration.
4.8.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
The ACDN software will be delivered to AC in the form
of three (3) versions. Each new version provides additional
functional capabilities to the ACDN system.
These Versions are categorized into two main groups
according to their capabilities:
The Version VI development activities will provide
AC with a virtual third Network Controller integrated
with a host front-end. This version will provide limited
final capabilities.
Version 4 and 5 defines end products in the sense that
they provide full network capabilities in the functions
supported.
The development of Version VI and Version 4 and 5 are
parallel development activities.
This section provides a high level narrative description
of the above mentioned major system implementations.
The detailed version-and functionality by version description
may be found in the System Requirement Specification
(3).
4.8.3.1 T̲h̲e̲ ̲V̲I̲ ̲T̲o̲r̲o̲n̲t̲o̲ ̲S̲y̲s̲t̲e̲m̲
The Version I Toronto system shall provide the following
capabilities:
a. Support of a small number of terminals communicating
through the Gateway to ACNC supported hosts, RES,
VIA and HIS.
b. Support of the OPS/CGO IBM host and a number of
OPS/CGO terminals. These terminals will also be
required to communicate with ACNC hosts although
their main destination will be the OPS/OGO host.
c. Support of the following AC access environment,
whether ACNC or ACDN connected:
Concentrators:
a. LCCS (4.8 kbps)
b. ICC
c. ACSI
Terminals:
a. AC40X (X=1,2,3,4,5,6,7,8)
b. FIDS
c. TTY Model 40
Printers:
a. EXTEL
b. DI-AN
c. GTE 200
d. Boarding Pass Printer (CTS)
e. Printer with built in AFTN I/F
f. MAC
g. TRAVICOM
h. ASTAC
In more details the VI functional capabilities are:
a. Gateway interface to ACNC by means of ICC access
lines. Thus, the ACDN will be emulating an ICC
site.
b. Support of up to 5 x 9.6 Kbps FDX access lines
to ACNC.
c. Interface and control of ICC access lines to the
local ICC environment. This covers running the
ACNC primary part of the ICC protocol.
d. Interface to and control of AC 40X CRTs. This includes
sign-on to the applications residing on the existing
ACNC network (RES, VIA, HIS) as well as provision
to the terminal user of statistics reports.
e. Interface to a control of AC printers. This includes
the capability to run the TDP protocols to the
printer, while the ACNC will be responsible for
burning a message and maintaining the TYPE B data
base.
f. Support of multi-sign-on to hosts residing on the
ACNC.
g. Capabilities to monitor and test access lines.
h. Network definition tools for handling the terminals,
CRTs as well as printers, associated with ICC access
lines, an average of 64 diveces per access line.
i. IBM VTAM standard host channel support.
This includes capabilities which support the host
network control functions by providing a 3705 emulation
capability.
j. Connectivity of a limited number of ACDN and ACNC
connected to AC 40X terminals to the OPNS/CGO host.
k. Connectivity from the OPNS/CGO to the entire AC
printer population in order to provide fast type
B (e.g. ticket traffic) by means of the existing
ACNC PMS mechanism, or directly within ACDN.
l. AC 40X terminals and printers mapped onto OPNS/CGO
host/device population view.
m. Monitor, control and test facilities.
n. OPNS/CGO native cluster controller interface capability
…86…1 …02… …02… …02… …02…
o. Connect native terminals (IBM) and AC 40X terminals
to OPNS/CGO host.
p. Facilities for monitoring and control of native
OPS/CGO access lines. This includes capability
to add and remove access lines. This includes tools
for handling the associated terminal devices.
q. The number of native access lines is 10 maximum.
4.8.3.2…02…T̲h̲e̲ ̲A̲C̲D̲N̲ ̲N̲e̲t̲w̲o̲r̲k̲
The final ACDN shall be successively developed from
Version I by provision of versions V4 and V5, as described
below.
4.8.3.2.1 A̲C̲D̲N̲ ̲V̲e̲r̲s̲i̲o̲n̲ ̲4̲
The major version shall provide all necessary facilities
for:
a. Operation and control of a transport network between
multiple nodes.
b. Support of protected message switching as implemented
by the EMH system.
c. Provision of IBM host access at each node.
d. Provision for IBM terminal access at each node.
e. Majority of Network Control exclusive of geographical
backup.
f. Support of the RCCSH IBM host and IBM compatible
terminals currently operating on an independent
network.
4.8.3.2.2 A̲C̲D̲N̲ ̲V̲e̲r̲s̲i̲o̲n̲ ̲5̲
This version shall provide all the functional capabilities
and fullfil the performance requirements specified
in the SRS and associated ICDs.
Explicitly the following functionality shall be added
to Version 4 by the final version (V5):
a. Network Management
b. NetWork Control inclusive of geographical backup
c. Access to VIA host through channel
d. Access to DRV HIS
e. Access to external networks
f. Cutover of VIA host and terminals to the ACDN
5. P̲R̲O̲J̲E̲C̲T̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
5.1 O̲b̲j̲e̲c̲t̲i̲v̲e̲
The ACDN Project Manager and the ACDN Deputy Project
Manager has been assigned the authority to manage and
direct the resources necessary to deliver the ACDN
system. The major responsibilities include:
o P̲r̲o̲j̲e̲c̲t̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲ to determine the project "Success
Parameters" and ensure that they are coordinated
within the project. Additionally all tasks, inputs
and deliverabled shall be defined. These shall
be used to create schedules and budgets.
o P̲r̲o̲j̲e̲c̲t̲ ̲O̲r̲g̲a̲n̲i̲z̲i̲n̲g̲, that is to develop a work breakdown
structure so that the proper interfaces are developed
to ensure inputs being ready when needed.
o P̲r̲o̲j̲e̲c̲t̲ ̲S̲t̲a̲f̲f̲i̲n̲g̲.̲ Work with the line managers to
determine what people can best support the project
and then phase them in and out of the project so
that the job is accomplished within cost and schedule,
and contractual commitments are met.
o P̲r̲o̲j̲e̲c̲t̲ ̲D̲i̲r̲e̲c̲t̲i̲n̲g̲ to provide day-to-day management
and technical directions to the project staff,
making interpretations of the plan, and by working
out modifications and changes with the customer
and the line organization. Directing the project
to produce the required items on the right schedule
for the agreed-upon cost.
o P̲r̲o̲j̲e̲c̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲, that is to conduct regular reviews
of the project items or individuals so that line
management and the customer will be regularly and
routinely informed on project progress, accomplishments,
and/or problems.
o P̲r̲o̲j̲e̲c̲t̲ ̲S̲u̲b̲c̲o̲n̲t̲r̲a̲c̲t̲i̲n̲g̲ to establish the necessary
contracts with subcontractors, if any, and assure
that proper control procedures are established.
o C̲u̲s̲t̲o̲m̲e̲r̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲.̲ The project management is the
focal point for all customer inquiries and shall
approve all project related customer reports.
The Project Officer of the ACDN organization performs
on behalf of the management the daily routine work
necessary to monitor the plans and budgets.
5.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲ ̲I̲t̲e̲m̲s̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
The deliverable items which fall directly under the
responsibility of the project management are the Progress
Reports and the documents identified in the Documentation
Plan.
6. S̲Y̲S̲T̲E̲M̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲
Systems engineering and design analysis tasks will
be performed by the ACDN Systems Engineering group
to ensure that the ACDN software/hardware requirements
will be consistent. The major areas of responsibilities
are as defined in section 2.2.3.
7. H̲A̲R̲D̲W̲A̲R̲E̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲S̲U̲P̲P̲O̲R̲T̲
7.1 D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
For the Air Canada project the following hardware developments
are scheduled:
1. V35 Interface
2. Current Loop Interface
3. Watch Dog Customerization
- Watchdog Switch Panel
- Configuration Crate Adapter
4. Mains Filter redesign for CSA approval
The hardware section of the project team will be responsible
for the development of the above mentioned items.
These items will be developed in accordance with figure
7.1-1. Module/item development scheme.
Fig. 7.1-1…01…Module/Item development scheme
7.2 O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
7.2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
Within the ACDN project organization, the Hardware
Team has the responsibility for developing the ACDN
site equipment.
The tasks are allocated into Groups, shown in fig.
7.2.1-1.
Fig. 7.2.1-1…01…Organization
7.3 W̲o̲r̲k̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲(̲W̲B̲S̲)̲
The Hardware Engineering activities includes:
- Equipment Production and Integration (WBS 3)
- Equipment Development (WBS 4)
These WBS's are described in Appendix A, B, C and D.
7.4 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲s̲ ̲a̲n̲d̲ ̲D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
7.4.1 T̲o̲r̲o̲n̲t̲o̲ ̲N̲o̲d̲e̲ (incl. NCC)
7.4.1.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
7.4.1.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
o Watchdog Subsystem
- Watchdog with associated operator's position
(VDU and matrix printer)
- Crate Control Adaptors in each Unit of Toronto
Node
o System Control Subsystem (SCPs)
- 2 Processor Units, each with
o 2 CPUs
o 768 Kwords of memory
o System Control CU Subsystem (SCUs)
- 2 80 Mbytes MMD with 2 Mbytes fixed head disks
and associated CR80 modules (2 32K disk controllers
and 2 associated adaptors)
(NCC) - 4 Colour Graphical Terminals and associated
CR80 termination modules
(NCC) - 1 TI810 150 cps matrix printer and associated
CR80 termination module
- Channel Units, etc. as required to connect
above
o Nodal Switch PU Subsystem (NSPs)
- 3 Processor Units, each with
o 4 CPUs
o 512 Kwords of memory
o Nodal Switch CU Subsystem (NCUs)
CR80 device controller and adaptors required to
connect:
- 2 host channels (IBM or Univac)
- 5 56 Kbps internodal trunks
- 69 2.4 Kbps ICC access lines
- 5 9.6 Kbps ACNC access lines
- 2 2.4 Kbps ARINC lines
- 1 2.4 Kbps ICC type to SITA
- 2 150 bps CNT (AES weather)
- 3 150 bps CNT (Airline switching)
- 2 250 bps CPAIR/BA
- 4 low speed connections
o S-net Subsystem
- 2 suprabusses and associated CR80 modules
- 2 suprabus connection to EMH complex
o Rack, cables, fans, etc. required by above CR80
units and modules.
7.4.2 M̲o̲n̲t̲r̲e̲a̲l̲ ̲N̲o̲d̲e̲ (incl. NCC)
7.4.2.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
7.4.2.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
o Watchdog Subsystem
- Watchdog with associated operator's position
(VDU and matrix printer)
- Crate Control Adaptors in each Unit of Toronto
Node
o System Control Subsystem (SCPs)
- 2 Processor Units, each with
o 2 CPUs
o 768 Kwords of memory
o System Control CU Subsystem (SCUs)
- 2 80 Mbytes MMD with 2 Mbytes fixed head disks
and associated CR80 modules (2 32K disk controllers
and 2 associated adaptors)
(NCC) - 4 Colour Graphical Terminals and associated
CR80 termination modules
(NCC) - 1 TI810 150 cps matrix printer and associated
CR80 termination module
- Channel Units, etc. as required to connect
above
o Nodal Switch PU Subsystem (NSPs)
- 3 Processor Units, each with
o 4 CPUs
o 512 Kwords of memory
o Nodal Switch CU Subsystem (NCUs)
CR80 device controller and adaptors required to
connect:
- 2 host channels (IBM or Univac)
- 5 56 Kbps internodal trunks
- 81 2.4 Kbps ICC access lines
- 17 9.6 Kbps IBM access lines
- 16 4.8 Kbps IBM access lines
o S-net Subsystem
- 2 suprabusses and associated CR80 modules
o Rack, cables, fans, etc. required by above CR80
units and modules.
7.4.3 W̲i̲n̲n̲i̲p̲e̲g̲ ̲N̲o̲d̲e̲
7.4.3.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
7.4.3.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
o Watchdog Subsystem
- Watchdog with associated operator's position
(VDU and matrix printer)
- Crate Control Adaptors in each Unit of Toronto
Node
o System Control Subsystem (SCPs)
- 2 Processor Units, each with
o 2 CPUs
o 768 Kwords of memory
o System Control CU Subsystem (SCUs)
- 2 80 Mbytes MMD with 2 Mbytes fixed head disks
and associated CR80 modules (2 32K disk controllers
and 2 associated adaptors)
o Nodal Switch PU Subsystem (NSPs)
- 4 Processor Units, each with
o 4 CPUs
o 512 Kwords of memory
o Nodal Switch CU Subsystem (NCUs)
CR80 device controller and adaptors required to
connect:
- 2 host channels (IBM or Univac)
- 6 56 Kbps internodal trunks
- 58 2.4 Kbps ICC access lines
- 4 9.6 Kbps IBM access lines
- 4 4.8 Kbps IBM access lines
o S-net Subsystem
- 2 suprabusses and associated CR80 modules
o Rack, cables, fans, etc. required by above CR80
units and modules.
7.4.4 N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲H̲o̲s̲t̲ ̲S̲y̲s̲t̲e̲m̲
7.4.4.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
7.4.4.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
o Processor Unit Subsystem (NMP)
- 1 PU with
o 2 CPUs
o 768 Kwords of memory
o Channel Unit Subsystem (NCUs)
- 2 80Mbytes MMD with 2 Mbytes fixed head disks
and associated CR80 modules (2 32K disk controllers
and 2 associated adaptors)
- 1 300 Mbytes SMD disk and associated CR80 modules
(1 32K disk controller and associated adaptor)
- 2 FT9000 Tape decks and associated CR80 modules
- 3 VDUs and associated CR80 termination modules
- 1 high speed printer (600 lpm) and associated
CR80 termination module
- Channel Units as required to connect above
o S-net Subsystem
- 2 suprabusses and associated CR80 modules
o Rack, cables, fans, etc. required by aove CR80
units and modules.
7.4.5 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲H̲o̲s̲t̲ ̲S̲y̲s̲t̲e̲m̲
7.4.5.1 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
7.4.5.2 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
o Watchdog Subsystem
- Watchdog with associated operator's position
(VDU and matrix printer)
- Crate Control Adaptors in each Unit of the
EMH
o Processor Unit Subsystem (EMPs)
- 2 Processor Units, each with
o 2 CPUs
o 512 Kwords of memory
o Channel Unit Subsystem (ECUs)
- 2 80 Mbytes MMD with 2 Mbytes fixed head disks
and associated CR80 modules (2 32K disk controllers
and 2 associated adaptors)
- 2 300 Mbytes SMD disks and associated CR80
modules (2 32K disk controllers and 2 associated
adaptors)
- 1 FT9000 Tape Deck and associated CR80 modules
- 4 VDUs and associated CR80 termination modules
- 1 TI810 150 cps matric printer and associated
CR80 termination module
- Channel units as required to connect above
o S-net Subsystem
- 2 Suprabusses and associated CR80 modules
o Rack, cables, fans etc. required by above CR80
units and modules
7.5 S̲c̲h̲e̲d̲u̲l̲e̲
Refer to Appendix A and B.
8. S̲O̲F̲T̲W̲A̲R̲E̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲
8.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲A̲p̲p̲r̲o̲a̲c̲h̲
This section describes the methods and practices which
shall be used during the ACDN software development
activity in order to ensure an effective, controlled
and cost-effective project.
8.1.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲L̲i̲f̲e̲c̲y̲c̲l̲e̲
The software development methodology adopted for the
ACDN project is based on a top-down process which starts
after the system design phase and which when completed
is followed by an acceptance test phase. The software
development lifecycle is divided into the following
5 phases:
o preliminary design
o detailed design
o code and unit test
o subsystem integration and test
o system integration and test
In the ideal situation these phases are only traversed
once and followed by the system acceptance phases.
However - as explained in section 4.5 - in order to
effectively support the ACDN migration plan according
to which five successive versions have to be produced
and delivered in a short timeframe, a variation of
the ideal development methodology has had to be deviced.
In this ACDN development model the five different
versions of the ACDN system will each proceed through
the five development phases and will overlap in time.
The details of how this is planned to take place with
a minimum of interaction between the five concurrent
activities is explained in section 8.5.
In the remaining part of this paragraph the contents
of the five software development phases is described.
8.1.1.1 P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲D̲e̲s̲i̲g̲n̲
The preliminary design may commence when the system
design is completed. The system design has partitioned
the ACDN system into subsystems like Network Control
Software, Nodal Switch Software etc., functional and
performance requirements have been allocated to each
subsystem, appropriate data structures have been designed,
and the interfaces between subsystems defined.
The preliminary design is the next iteration in the
design process whereby the subsystems are decomposed
into units, functional and performance requirements
are allocated to units, the interfaces between units
are defined, and the data structures further refined.
A unit is defined as a software package which has a
size suitable for detailed design and implementation
by one person. In general the size of a unit is in
the order of 1000 high order language (e.g. Pascal)
statements.
During the decomposition the guidelines for top-down
development defined in the applicable software design
standard shall be followed.
The preliminary design of a subsystem is completed
by a preliminary design review.
8.1.1.2 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
Detailed design starts when preliminary design is completed.
The purpose of the detailed design is to specify the
logic which implements the functional, performance
and interface requirements of the program units.
The logic shall be specified by means of pseudocode
in a top-down manner starting at a level where each
pseudocode statement has a logic complexity corresponding
to a procedure in the final implementation.
The detailed design of a unit is completed when the
level of the pseudocode specification corresponds to
approximately 5 high order language statements per
pseudocode statement in the final source program.
When the detailed design of a unit is completed, a
detailed design review shall be conducted to ensure
the quality of the design.
8.1.1.3 C̲o̲d̲i̲n̲g̲ ̲a̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲
The coding and test of a unit may commence after completion
of the detailed design of the unit.
Coding is performed by transforming each pseudocode
statement in the unit detailed design specification
into statements of a real programming language.
In parallel with the programming of the unit development
testing and debugging of the unit is performed.
Two different approaches to the unit coding and test
may be used:
- top-down development whereby the high level control
flow statements and high level procedures are coded
and tested first. This requires stubs to be coded
for lower level procedures as well as a test driver
to be programmed.
- bottom-up development and test whereby the low
level procedures are coded and tested first (and
independent of each other). This requires a number
of test drivers to be programmed.
The method to be followed shall be defined for each
unit individually.
When a unit is coded and unit tested the following
results shall be available:
- the source and object unit program
- a (set of) test driver(s) which can effectively
test the unit, i.e. activate all statements in
the unit at least once, activate the unit with
a range of input parameters in its valid input
data domain, activate the unit with a range of
input parameters outside the domain of valid inputs
- input data files to drive the tests
- output data files of validated outputs from the
tests
- job files to test the unit (cf figure 8.1.1.3-1)
The objective is that retesting of the unit shall be
as simple and cheap as possible. Therefore one of
the following two alternatives shall be adopted for
the unit:
- the test driver is capable to verify the result
of the tests, or
- the test outputs contain only data that are invariant
to minor changes in the unit. This means that
output data may n̲o̲t̲ contain e.g. location values.
It shall be kept in mind that other units can very
often be used (as the basis) for test drivers of a
unit.
Fig. 8.1.1.3-1…01…UNIT TEST SETUP
8.1.1.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̲
As the units of a subsystem complete unit coding and
test they shall be integrated into the corresponding
subsystems.
Subsystem integration and test shall lead to an integrated
subsystem where
- all allocated functional requirements are verified
- all allocated performance requirements are verified
- all internal interfaces (i.e. unit interfaces)
are tested
Test drivers will in general have to be written for
this purpose. Like for unit test, these test drivers
and associated test inputs and outputs are deliverables
from the activity and shall be maintained for documentation
and retesting purposes.
8.1.1.5 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
When subsystems have passed subsystem integration and
test they shall be integrated into the final system.
This integration and test activity shall verify that
- all functional requirements are verified
- all allocated performance requirements are verified
- all internal interfaces (between subsystems) are
tested
The system integration and test will therefore have
a large common subset with the system acceptance test
and may share test setup and procedures with the acceptance
test to a large extent.
8.1.2 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲d̲u̲c̲e̲d̲ ̲D̲u̲r̲i̲n̲g̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲
The software development activities are recorded in
a number of documents. The different types of documents
produced are described for each development phase in
the following subsections.
8.1.2.1 P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲D̲e̲s̲i̲g̲n̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The preliminary design is documented in terms of product
specifications (cf Product Specification Standard).
One product specification is produced for each subsystem.
These documents are deliverables, which record the
final functional design of each subsystem to the unit
level.
Design decisions and analyses worked out during the
preliminary design phase are documented in engineering
working papers which are for internal use only.
8.1.2.2 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
During detailed design, the program logic of program
units is specified. The design is recorded in a Unit
Development Folder (UDF) for each unit (cf UDF Standard).
UDFs are for internal use only.
Design decisions and analyses worked out during the
detailed design are documented in engineering working
papers. They are for internal use only.
8.1.2.3 U̲n̲i̲t̲ ̲C̲o̲d̲i̲n̲g̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
During the coding and test of units the following machine
readable types of documents are produced
- source program files
- object program files
- job files
- compile and link time listings
These documents are produced for the unit program and
the associated test drivers.
Further documents produced are
- test input data files
- test output data files
Finally a test report is generated, which documents
the successful completion of unit testing.
Source program files shall be produced in accordance
with the proper source program layout standards (SWELL
Programming Standard, PASCAL Programming Standard).
Prior to the unit code and test phase test specifications
and procedures are worked out as part of the UDF.
8.1.2.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̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Prior to the subsystem integration and test the following
test documents are produced as part of the subsystem
PSP:
- test plan
- test specification
- test procedure
During the subsystem integration and test the following
machine readable documents are produced for subsystem
test drivers:
- program source files
- object files
- job files
- compile and link time listings
Further, test data input and output files are generated.
Successful completion of the subsystem test is documented
in a test report.
8.1.2.5 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Documents similar to those generated during subsystem
integration and test are produced.
8.1.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲T̲o̲o̲l̲s̲
During the software development phases the following
standard software development tools are used:
- EDITOR
for production of documents and source programs
- SWELL compiler
for translation of SWELL source modules into
linkable object modules
- PASCAL compiler
for translation of PASCAL source modules into
linkable object modules
- Cross Reference Generator
for production of PASCAL cross reference listings
- Linker
for production of executeable object programs
from linkable object modules
- DEBUGGER
for interactive symbolic debugging of SWELL
programs and 'hexadecimal' debugging of PASCAL
programs
- System Generator
for building of system boot modules
- Parser Generator
for generation of interactive modules
Further a number of miscellaneous tools are used for
- building and maintaining software libraries
- generation of safety copies
8.1.4 Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲o̲f̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲
The quality of the produced software is ensured by
the following means:
- a̲n̲a̲l̲y̲s̲e̲s̲
during all software development phases peformance
analyses shall be worked out in order to ensure
that all performance requirements are met and that
CPU and memory budgets are kept
- r̲e̲v̲i̲e̲w̲s̲
a number of internal reviews are held in order
to assess and validate the design process: preliminary
design reviews and detailed design reviews
- t̲e̲s̲t̲s̲
a thorough development testing shall be performed
as described in section 8.1.1
8.2 O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The ACDN software development organization is shown
in figure 8.2-1 overleaf. The software development
team is divided into a number of subsystem teams each
managed by a subsystem manager. This division follows
closely the Work Breakdown Structure which breaks down
the ACDN system into subsystems and which shall be
finally defined during the system design. The organization
shown is therefore only tentative.
One of the subsystem teams belong to an organizational
unit outside of the Communications Division. In order
to take advantage of the expertise of the CR System
Division, the Electronic Mail Software will be subcontracted
to this division.
Each subsystem team is responsible for one subsystem,
and will carry out the development work for each subsystem
staged in up to 3 versions.
A separate Integration and Test team has been defined
which is responsible for the development of the test
software needed during subsystem and system integration.
Fig. 8.2-1…01…ACDN SOFTWARE DEVELOPMENT ORGANIZATION
Figure 8.2-2
S/W Subsystem Assignments.
8.3 W̲o̲r̲k̲ ̲B̲r̲e̲a̲k̲-̲d̲o̲w̲n̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲(̲W̲B̲S̲)̲
This section contains a hierarchically developed WBS
for the software development. The WBS given in the
first issue of the PIP is only tentative and subject
to change according to the outcome of the system design.
It will be revised according to the system design
and refined as the preliminary design progresses.
The generic structure of the final WBS is as follows:
W̲P̲N̲ W̲P̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
6.n Subsystem n
6.n.1 Subsystem n preliminary design
6.n.2 Subsystem n unit development
6.n.2.p subsystem n, unit p
6.n.2.p.1 subsystem n, unit p detailed design
6.n.2.p.2 subsystem n, unit p coding and test
6.n.3 subsystem n integration and test
8.3.1 S̲u̲m̲m̲a̲r̲y̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲W̲B̲S̲
The Software Engineering WBS is described in Appendix
A, B, C and D.
8.4 A̲C̲D̲N̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
This section defines the categories of software documentaion
to be produced during the ACDN project. The Documentation
Plan contains a complete list of all documents to be
produced during the software development phases. The
list contains both deliverable documents as well as
working documents.
8.4.1 A̲C̲D̲N̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲T̲r̲e̲e̲
The ACDN software documentation is divided into the
major categories shown in figure 8.4.1-1.
Figure 8.4.1-1
8.5 S̲C̲H̲E̲D̲U̲L̲E̲
Refer to Appendix A and B.
9. I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲ ̲T̲E̲S̲T̲S̲
9.1 O̲b̲j̲e̲c̲t̲i̲v̲e̲
The objective of integration and acceptance testing
is to verify and demonstrate the correct operation
of all subsystems of deliverable equipment and computer
program end items (CPEIs). The objective of integration
test respective acceptance test is destinguished below.
…02…The overall acceptance test plan will be outlined in a
ACDN Acceptance Plan document.
9.1.1 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲i̲n̲g̲
Subsystem Integration Testing is the process of verifying
that all subsystem units fulfil allocated function-
and performance requirements and conform to specified
internal and external unit- and subsystem interfaces.
Subsystem Integration Test planning will be documented
in a Subsystem Integration and Test Plan during the
Detailed Design phase for the particular subsystem.
The test plan is subject to review at DDR.
The Subsystem Integration And Test Plan will specify
at least the following:
- Development test activity
- Integration test prerequisites
- Integration test metodology
- Integration test schedule
- Responsibilities for conducting the integration
testing
- Planned methods for test monitoring and control
The Subsystem Integration Test phase will be concluded
by a formal Subsystem Acceptance Test with the purpose
of qualifying the subsystem for system integration.
9.1.1.1 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲i̲n̲g̲
System Integration Testing is the process of verifying
that all subsystems fulfil allocated functional and
performance requirements and conform to specified internal
and external subsystem interfaces.
System Integration Test planning will be documented
in a System Integration and Test Plan when all subsystem
packages have been defined during the System Design
Phase.
The Test Plan is subject to review at PDR.
The System Integration and Test Plan will specify at
least the following:
- Development test activity
- Integration test prerequisites
- Integration test metodology
- Integration test schedule
- Responsibilities for conducting the integration
testing
- Planned methods for test monitoring and control
The System Integration Test phase will be concluded
by a Dry-Run leading to the factory or in-plant version
acceptance test.
9.1.2 A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲s̲
The objective of acceptance testing is to demonstrate
and verify that a system operates in accordance with
allocated function and performance requirements.
The result of an acceptance test will be the customer's
accept, conditionally accept or disaccept of a delivered
system.
Acceptance testing will be performed against the established
System Requirement baseline (SRS). Each baselined requirement
shall be verified through one of the below methods:
a) E̲x̲a̲m̲i̲n̲a̲t̲i̲o̲n̲: This method is a non functional verification,
such as visual inspection of the physical characteristics
of the item or of the documentation associated
with the item.
b) A̲n̲a̲l̲y̲s̲i̲s̲:̲ This method is a non-functional verification,
such as deduction or translation of data, review
of analytical data, or performance of a detailed
analysis.
c) T̲e̲s̲t̲ ̲D̲e̲m̲o̲n̲s̲t̲r̲a̲t̲i̲o̲n̲:̲ This method is a functonal
verification, such as actual operation wherein
the element of verification is instrumented, measured,
or displayed directly (test) or where the element
of verification is logically obvious, as the result
of some other verification, but not itself displayed
(demonstration).
9.1.2.1 A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲s̲ ̲i̲n̲ ̲G̲e̲n̲e̲r̲a̲l̲
The following basic rules will apply to acceptance
testing in general:
a) Acceptance testing will be based on a formally
approved Test Specification (TSP). The TSP shall
as a minimum identify and specify the following:
- the test object
- the requirements to be verified
- the system functions to be exercised
- the test methods and constraints
- the test evaluation criteria.
b) Acceptance testing will be based on a formally
approved Test Procedure (TPR). The TPR shall specify
the exact conduct of the acceptance test including
as a minimum the following:
- test control, initialization and setup
- the procedure for test execution
- detailed step-by-step procedural descriptions
of each individual test
The Test Specification and the Test Procedure may
be combined into a single document if convenient
c) The formal execution of the TSP/TPR, i.e. the acceptance
test conduct, results in generation of a set of
test results. These are registered for incorporation
in the Test Report (TRP).
d) A formal Test Report (TRP) is generated as result
of the acceptance test. The TRP shall consist of
the following:
- Conclusion, specifying discrepancies (if any)
to be corrected prior to repetition of test.
- Complete discrepancy list.
- Collection of all registered test input and
associated test results.
The Test Report is subject to formal approval.
The approval shall signify formal acceptance.
e) Repetition of acceptance testing may be required
as a result of conditional acceptance. In such
case the relevant part of the test shall be repeated
as concluded by the Acceptance Test Report.
The general acceptance test cycle is illustrated in
the figure overleaf.
Acceptance Test Cycle, General
Figure 3.1.2.1
9.1.3 P̲a̲r̲t̲i̲c̲u̲l̲a̲r̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲s̲
The acceptance test categories applied on the ACDN
project are:
o Equipment Acceptance Tests
- Factory Acceptance Tests
- Provisional site Acceptance Tests
o System Acceptance Tests
- Version Acceptance Tests
- Network Acceptance Tests
The acceptance test categories, described in more details
below, are all subject to the general acceptance test
requirements specified in section 9.1.2.1.
9.1.3.1 F̲a̲c̲t̲o̲r̲y̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲
The purpose of Factory Acceptance Testing (FAT) is
to demonstrate readyness for site installation and
acceptance of a given hardware system or subsystem.
The FAT will be conducted by execution of M&D programs
and standard operating system software.
9.1.3.2 P̲r̲o̲v̲i̲s̲i̲o̲n̲a̲l̲ ̲S̲i̲t̲e̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲
The purpose of Provisional Site Acceptance Testing
(PSAT) is to demonstrate and verify that a particular
hardware system or subsystem fulfils its basic requirements
(not operationally).
The Provisional Site Acceptance Test will be a repetition
of the Factory Acceptance Test. Thus, the TSP/TPR for
FAT and PSAT are identical. A seperate Test Report
will be generated.
9.1.3.2 V̲e̲r̲s̲i̲o̲n̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲
For each of the five baselined (SRS) versions of the
ACDN software system a Version Acceptance Test (VAT)
will be conducted. The purpose of the VAT is to demonstrate
and verify that the set of requirements allocated to
a given system version are indeed fulfilled.
The VAT will be conducted in full at one site for the
purpose of qualifying the version.
A specified subset of the VAT will be repeated on the
remaining sites in order to qualify these prior to
version cutover. This qualification provides final
site Acceptance (SAT).
9.1.3.4 N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲T̲e̲s̲t̲
The purpose of the Network Acceptance Test (NAT) is
to demonstrate and verify the full set of system requirements
as baselined in the System Requirement Specification
(SRS).
The NAT will be performed on the fully installed and
site accepted ACDN network after completion of software
version 5.
9.2 O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The responsibilities for integration- and acceptance
testing are distributed within the ACDN organization.
The organization is illustrated in figure 9.2.
9.2.1 S̲y̲s̲t̲e̲m̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲T̲e̲s̲t̲ ̲T̲e̲a̲m̲
The System Engineering Test Team has the overall integration
and acceptance responsibility, including:
- System Integration Planning
- Acceptance Test Planning
- Generation of ATP
- Generation of acceptance TPRs
- Integration on the system level
- Conducting acceptance tests
- Producing acceptance TRPs
INTEGRATION AND ACCEPTANCE TEST ORGANIZATION
FIGURE 9.2
9.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲T̲e̲a̲m̲ ̲
A seperate Integration and Test Team in the Software
Engineering group is responsible for
- Development of test software needed during system
integration and test
- Planning of integration on the subsystem level
- Integration on the subsystem level
- Generating the associated documentation (TPL, TSP,
TPR, TRP).
9.3 W̲o̲r̲k̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲(̲W̲B̲S̲)̲
The Integration and Test WBS is described in Appendix
A, B, C and D.
9.4 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲ ̲I̲t̲e̲m̲s̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲ ̲L̲i̲s̲t̲
This section defines the categories of test documentation
to be produced during the ACDN project. The Documentation
Plan contains a complete list of all documents to be
produced for the purpose of system integration and
acceptance testing. The list contains both deliverable
documents as well as working documents which are for
CR in-house use only.
9.4.1 T̲e̲s̲t̲ ̲a̲n̲d̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲T̲r̲e̲e̲
The ACDN acceptance test- and system integration documentation
are divided into the categories shown in figure 9.4.1.
ACDN INTEGRATION AND ACCEPTANCE DOCUMENTATION TREE
FIGURE 9.4.1
9.5 S̲c̲h̲e̲d̲u̲l̲e̲
Refer to Appendix A and B.
Figure 9.5-1 illustrates generically the relation between
the major system/subsystem milestones and the production
of test and integration documentation.
TEST DOCUMENTATION SCHEDULE, GENERIC
FIGURE 9.5-1
10. I̲N̲T̲E̲G̲R̲A̲T̲E̲D̲ ̲L̲O̲G̲I̲S̲T̲I̲C̲S̲ ̲S̲U̲P̲P̲O̲R̲T̲
10.1 O̲b̲j̲e̲c̲t̲i̲v̲e̲
This chapter discribes the logistics support aspect
of the ACDN program:
- Documentation
- Training
- Transportation - Installation
- Equipment Maintenance incl. Spares
- Software Maintenance
Each of above disciplines will be described by highlighting
the main activities.
Additionally, the chapter will describe the organization,
present the schedules and list the items to be delivered.
10.2 O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The logistics support activities will be carried out
by the Integrated Logistics Support Department (ILS)
of the System Division.
The ILS department manager and ACDN project office
will interface with respect to policies, project reviews
and schedules. The individual sections within ILS
will interface with relevant members from the ACDN
project team in all technical aspects.
Fig. 10.2-1…01…Integrated Logistics Support Department
10.3 W̲o̲r̲k̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲(̲W̲B̲S̲)̲
The ILS WBS' for
- documentation (WBS 8)
- training (WBS 9)
- transportation (WBS 10)
- installation (WBS 11)
- equipment maintenance (WBS 12)
- software maintenance (WBS 13)
are described in Appendix A, B, C and D.
10.4 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲ ̲I̲t̲e̲m̲s̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲ ̲L̲i̲s̲t̲
The devliverable documentation is described in the
ACDN documentation plan (2).
10.5 S̲c̲h̲e̲d̲u̲l̲e̲
Refer to Appendix A and B.
11. A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲S̲
CD standards, procedures, and recommandations, which
apply to the ACDN project, are collected in the ACDN
Standards Handbook.
The following documents have been selected:
S̲y̲s̲t̲e̲m̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
ICD Standard
Integration and Test documentation Standard Acceptance
Test Documentation Standard.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲
Software Design Guidelines
Software Subsystem Documentation Standard
UDF Standard
Product Specification Standard
Software Verification Standard
Completed Item Inspection and Testing
Pseudo Code Standard
SWELL Programming Standard
C Programming Standard
Pascal Programming Standard
Module Heading Standard
H̲a̲r̲d̲w̲a̲r̲e̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲:̲
IAB Standard
C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Configuration Management Plan
Configuration Item Identification Standard
Version Description Document Standard
G̲e̲n̲e̲r̲a̲l̲:̲
Design Reviews
Problem Handling Standard
User's Manual Standard
12. D̲E̲P̲E̲N̲D̲E̲N̲C̲I̲E̲S̲
In order to enable development and integration test
of ACDN a number of facilities, services and support
from AC is required, as specified in appendix E to
the contract.
