top - download
⟦0b21c6bbc⟧ Wang Wps File
Length: 28294 (0x6e86)
Types: Wang Wps File
Notes: CPS/TSP/005
Names: »1155A «
Derivation
└─⟦2f7a68440⟧ Bits:30006045 8" Wang WCS floppy, CR 0071A
└─ ⟦this⟧ »1155A «
WangText
/…07….…0a….…0f….…05…-…86…1
…02…
…02…
…02…
…02…CPS/TSP/005
…02…URH/811002…02……02…#
SYSTEM
INTEGRATION
AND
TEST
PLAN
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
5
1.1 PURPOSE ...................................
5
1.2 PROJECT REFERENCES ........................
5
1.3 TERMS AND ABBREVIATIONS ...................
6
1.3.1 Terms .................................
6
1.3.2 Acronyms ..............................
6
2 DEVELOPMENT TEST ACTIVITY .....................
7
2.1 UNIT TESTING ..............................
7
2.1.1 Elementary Unit Testing ...............
8
2.1.2 Compound Unit Testing .................
8
2.1.3 Unit Testing Summary ..................
8
2.2 PACKAGE INTEGRATION
AND TEST ..................................
9
2.3 DEVELOPMENT TEST EVALUATION ...............
9
3 TEST PLAN .....................................
10
3.1 SYSTEM DESCRIPTION ........................
10
3.2 SYSTEM I & T TASK
DESCRIPTION ...............................
10
3.2.1 System Integration Pre-
requisites ............................
11
3.2.1.1 Hardware Subsystem ................
11
3.2.1.2 System Software
Subsystem .........................
11
3.2.1.3 Application Software
Packages ..........................
12
3.2.2 Integration Sequence
Outline ...............................
13
3.3 SYSTEM I & T MILESTONES ...................
14
3.3.1 System Build 1
Capabilities ..........................
15
3.3.2 System Build 2
Capabilities ..........................
16
3.3.3 System Build 3
Capabilities ..........................
20
3.4 INTEGRATION SCHEDULE ......................
20
3.5 TEST MANAGEMENT ...........................
22
3.5.1 Management Organization ...............
22
3.5.2 Test Planning .........................
23
3.5.3 Test Control ..........................
23
3.5.3.1 Package Turnover
Letter ............................
24
3.5.3.2 Software Problem
Reports (SPR) .....................
24
3.5.3.3 Software Modifica-
tion Record (SMR) .................
26
3.5.3.4 Regression Testing ................
26
3.5.3.5 Software Defect
Monitoring ........................
28
3.5.4 Resource Estimates ....................
29
3.5.4.1 Manpower Resources ................
29
3.5.4.2 Equipment Resources ...............
30
1̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲
The purpose of the System Integration and Test Plan
is to outline the:
a) Development Test activity
b) Integration Test prerequisites
c) Integration Test methodology
d) Integration Test schedule
e) Responsibilities for conducting the Integration
Testing
f) Planned methods for test monitoring and control
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
a) CAMPS System Requirement Spec. CPS/210/SYS/0001
b) CAMPS System Design Spec., CPS/SDS/001
c) UDF Standard, SD/STD/006
d) Software Test Plan, CPS/TSP/001
e) Software Integration Plan, CPS/TSP/002
f) CAMPS Acceptance Plan, CPS/PLN/012
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
a) Build:
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.
b) Software Unit:
A piece of software documented by a Unit Development
Folder (UDF).
1.3.2 A̲c̲r̲o̲n̲y̲m̲s̲
CR C̲hristian R̲ovsing A/S
LOG L̲og P̲ackage
MDP M̲essage D̲istribution P̲ackage
SSC S̲ystem S̲tatus and C̲ontrol Package
SYS CAMPS S̲ystem S̲oftware
TEP T̲erminal P̲ackage
THP T̲raffic H̲andling P̲ackage
TMP T̲able M̲anagement P̲ackage
SAR S̲torage a̲nd R̲etrieval Package
STP S̲tatistics P̲ackage
SDS CAMPS S̲ystem D̲esign S̲pecification
CPS/SDS/001
UDF U̲nit D̲evelopment F̲older
WP W̲ork P̲ackage
SMR S̲oftware M̲odification R̲ecord
SPR S̲oftware P̲roblem R̲ecord
KER K̲e̲r̲nel
MMS M̲essage M̲anagement S̲ystem
IOC I̲nput/O̲utput C̲ontrol
SFM S̲torage and F̲ile M̲anagement
CSF C̲AMPS S̲ystem F̲unctions
2̲ ̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲T̲E̲S̲T̲ ̲A̲C̲T̲I̲V̲I̲T̲Y̲
The CAMPS 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.
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.
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
3) Calculation accuracy.
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..
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 as described under
para 2.1.1 b) 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.
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.
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 outlined in para 2.1
and 2.2 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.
3̲ ̲ ̲T̲E̲S̲T̲ ̲P̲L̲A̲N̲
This section provides a system description, a description
of the integration test task, a test schedule and an
outline of the planned test management.
3.1 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Prior to initiation of the System Integration and Test
(I & T) task the following elements of the CAMPS System
breakdown must be available (ref. SDS):
a) CAMPS Hardware Subsystem
b) CAMPS System Software Subsystem
c) CAMPS Application Software Packages, (one or more)
3.2 S̲Y̲S̲T̲E̲M̲ ̲I̲ ̲&̲ ̲T̲ ̲ ̲T̲A̲S̲K̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The system I & T task consists of combining the elements
listed under para 3.1, a), b) and c) above to become
the complete CAMPS system.
The System I & T activity is planned to be conducted
in the following way:
By means of CAMPS 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 System I & T at
an early stage of the development process, some of
the software packages will be developed in up to three
steps identified as builds. Each build is planned to
require approx. equal amounts of the package development
effort.
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.
3.2.1 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲P̲r̲e̲r̲e̲q̲u̲i̲s̲i̲t̲e̲s̲
As mentioned in para 3.1 certain prerequisites regarding
elements of the CAMPS Subsystems must be fulfilled
prior to initiation of the System I & T task. The required
prerequisites regarding the Hardware-, System Software
Subsystem and Application Software Packages are described
in the following.
3.2.1.1 H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
Prior to System I & T the following tests must be completed
for the CAMPS Hardware Subsystem:
a) DSMT System Test
b) Factory Acceptance Test
These tests are described in CAMPS Acceptance Plan.
3.2.1.2 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
CAMPS System Software Subsystem consists of the following
packages:
a) Kernel (KER)
b) I/O Control (IOC)
c) CAMPS System Functions (CSF)
d) Storage and File Management (SFM)
e) Message Management (MMS)
f) System Status and Control (SSC)
g) Table Management (TMP)
Prior to System I & T the System Software Packages
must be integrated and tested. For some of the packages
the development is planned to be divided into up to
three builds. As a consequence hereof three builds
will be defined for the System Software Subsystem.
Each build will be identified by the contained functions.
For each build a test of the contained functions shall
be completed before delivery for System I & T.
For the following the three builds of the System Software
Subsystem are denoted:
Build 1: SYS 1
Build 2: SYS 2
Build 3 SYS 3
3.2.1.3 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
CAMPS Application Software Subsystem consists of the
following packages:
a) Traffic Handling (THP)
b) Message Distribution (MDP)
c) Terminal Package (TEP)
d) Storage and Retrieval (SAR)
e) Log and Accountability (LOG)
f) Statistics (STP)
For some of the packages, the development will be divided
in up to three builds. Each build is defined by the
contained functions.
For the remaining packages all of the package functions
will be developed before release for System I & T.
For the following the package builds are denoted by
the package acronym followed by a number, for example:
Build 1: THP 1, TEP 1
Build 2: THP 2, TEP 2
Build 3: THP 3, TEP 3
3.2.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 Application 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 traffic 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 CAMPS 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. An outline of the functional
capabilities of each System Build is given in para
3.3.
The System I & T workpackages and their execution sequence
are defined as follows:
WP/SEQUENCE NO. CONSISTING OF COMPLETION OF
I&T of PACKAGE/ SYSTEM BUILD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲B̲U̲I̲L̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
1 SYS 1
2 TEP 1
3 THP 1
4 MDP 1
5 SYS 2
6 TEP 2
7 THP 2
8 LOG 2
9 STP 2
10 SYS 3
11 SAR
12 LOG 3
13 THP 3
14 TEP 3 3
3.3 S̲Y̲S̲T̲E̲M̲ ̲I̲ ̲&̲ ̲T̲ ̲M̲I̲L̲E̲S̲T̲O̲N̲E̲S̲
Completion of a certain number of System I & T workpackages
defines a System Build as indicated in para 3.2.2.
System Builds will be regarded as milestones for the
System I & T task.
For identification of the System I & T milestones the
functional capabilities of the defined System Builds
will be outlined in the following. The functional capabilities
referenced are described in detail in the SRS. Functions
marked with an asterisk will only be partly available
in the indicated build.
3.3.1 S̲y̲s̲t̲e̲m̲ ̲B̲u̲i̲l̲d̲ ̲1̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The following functional capabilities will be available
in Systems Build 1:
M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
Preparation of Message Header
Preparation of Message Text
Correction of Header/Text
Coordinate/Release/Defer
Message Coordination
C̲o̲m̲m̲e̲n̲t̲s̲
New Comment Preparation
Comment Presentation
M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲
L̲o̲c̲a̲l̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
A̲C̲P̲1̲2̲7̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
*Conversion of Operational Messages with Plain
Text.
T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
Channel Selection and Identification
Procedures related to the ZEN Prosigns
M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
A̲C̲P̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
*Format Line Detection
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Automatic Distribution
T̲e̲r̲m̲i̲n̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
Physical Access
L̲o̲g̲i̲c̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲
VDU's
Stand Alone Devices
*F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲ ̲o̲f̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲o̲d̲e̲s̲
*̲S̲t̲a̲t̲u̲s̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲A̲v̲a̲i̲l̲a̲b̲l̲e̲ ̲f̲r̲o̲m̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲s̲
P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲a̲t̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲s̲
Use of Visual Display Units
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
*Engineering Functions Implementation
*Engineering Functions Detailed Definition
3.3.2 S̲y̲s̲t̲e̲m̲ ̲B̲u̲i̲l̲d̲ ̲2̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The following functional capabilities will in addition
to those of System Build 1 be available in System Build
2:
M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
Message Editing
Append Message
C̲o̲m̲m̲e̲n̲t̲s̲
Comment Editing
E̲n̲t̲r̲y̲ ̲o̲f̲ ̲C̲o̲m̲p̲l̲e̲t̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Entry from PTR
A̲C̲P̲1̲2̲7̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Conversion of Complete Messages
M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
A̲C̲P̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
Selection of Parameter
Determination of Message Type
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Distribution of Messages with Encrypted Text and
Data Messages
Distribution of Service Messages
P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲a̲n̲d̲ ̲Q̲u̲e̲u̲i̲n̲g̲
P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲a̲t̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲s̲
Requirement to Printed Output
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Common Requirements for Commands
Command Processing Control
Message Processing Control
Terminal Position Control
User Control
External Connection Control
OCR, PTR/PTP and Stand Alone Teleprinter Control
Report Control
Statistics Control
Log Control
Offline Storage Control
Security Warning Control
Supervisor Engineering Commands
Queue Control at Restart
S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲P̲r̲i̲n̲t̲
R̲e̲p̲o̲r̲t̲ ̲P̲r̲i̲n̲t̲
L̲o̲g̲ ̲P̲r̲i̲n̲t̲
M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲
Incoming Message Assistance
Routing Indicator Assignment
Handling of Outgoing Messages with Encrypted
Text.
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Distribution
Retrieve for Distribution
R̲e̲p̲o̲r̲t̲s̲
General
Security Reports
Warning Reports
Command Completion Reports
Queue Status Reports
Channel Reports
Deletion Request Reports
S̲t̲a̲t̲u̲s̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
B̲a̲c̲k̲-̲U̲p̲ ̲o̲f̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲F̲i̲l̲e̲
E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
H/W Configuration Status Display
L̲o̲g̲g̲i̲n̲g̲
Categories of Transactions to be logged
Logging Events
Storage of Log Records
Print of Log Records
Tracing of Log Information
D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲ ̲L̲o̲g̲ ̲R̲e̲c̲o̲r̲d̲s̲
L̲o̲g̲ ̲R̲e̲c̲o̲r̲d̲s̲ ̲R̲e̲l̲a̲t̲i̲n̲g̲ ̲t̲o̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
NICS-TARE/TRC/Point-to-Point Connection
Messages.
Valid Messages
Invalid Messages
L̲o̲g̲ ̲R̲e̲c̲o̲r̲d̲s̲ ̲R̲e̲l̲a̲t̲i̲n̲g̲ ̲t̲o̲ ̲O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
NICS-TARE/TRC/Point-to-Point Connection
Messages
C̲h̲a̲n̲n̲e̲l̲ ̲D̲i̲s̲c̲o̲n̲t̲i̲n̲u̲i̲t̲y̲
NICS-TARE/TRC/Point-to-Point Connection
Channel Discontinuity
T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲o̲n̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Incoming Messages
Outgoing Messages
Rejected Messages
S̲t̲o̲r̲a̲g̲e̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲
C̲h̲a̲n̲n̲e̲l̲ ̲A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲ ̲a̲n̲d̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
U̲s̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲s̲
Formats A, C1, G1, M, O
Formats B, D, F, G2, H, I, N, P1, P2, Q, R
S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲a̲n̲d̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
Types of Messages to be stored
Types of Transactions to be stored.
3.3.3 S̲y̲s̲t̲e̲m̲ ̲B̲u̲i̲l̲d̲ ̲3̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
System Build 3 shall contain all of CAMPS functional
capabilities.
3.4 I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲S̲C̲H̲E̲D̲U̲L̲E̲
The time schedule for System I & T is shown overleaf.
SYSTEM I & T SCHEDULE
3.5 T̲E̲S̲T̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
This section contains an outline of the management
organization and -activities planned for control of
the System I & T task.
3.5.1 M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
The purpose of the System I & T task is to verify,
that each of the developed application software packages
meet the system requirements, which it is designed
to meet.
The responsibility for conductance of the System I
& T task lies with the System I & T Team, which has
the line of reference indicated on fig. 3.5.1-1.
FIGURE 3.5.1-1 …01…SYSTEM I & T ORGANIZATION
3.5.2 T̲e̲s̲t̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲
Part of the System I & T planning activity is elaboration
of test specification and -procedures.
A Test Specification and a set of Test Procedures will
be elaborated for each System I & T workpackage.
The System I & T Test Procedures will be based on the
Test Procedures for the Functional Test.
The Test Procedures for each System I & T workpackage
will be selected as the subset of the Test Procedures
for the Functional Test, which is relevant for verification
of the system functions contained in that I & T workpackage.
System I & T Specifications and Procedures for each
workpackage will be delivered to the responsible development
team for coordination of the development test activity.
3.5.3 T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
Software development and integration testing up to
package level is conducted by the Software Engineering
team.
To ensure visibility of the software development- and
integration test activity, each of the executed tests
shall include testcases derived from the specified
System I & T testcases. The testcases are derived by
mapping the functional performance specified in the
system level testcases onto the corresponding functional
performance of each of the involved software units.
By following this approach errors discovered during
System I & T are reduced to package interface errors.
When Software I & T is accomplished to the package
or -build level, the package or build is turned over
to the System I & T team.
In the following paragraphs and on fig. 3.5.3-1 is
given an outline of the formalized tools, which will
be used for management of the System I & T task.
3.5.3.1 P̲a̲c̲k̲a̲g̲e̲ ̲T̲u̲r̲n̲o̲v̲e̲r̲ ̲L̲e̲t̲t̲e̲r̲
Delivery of a software package for System I & T must
be enclosed by a Turnover Letter containing a complete
identification of all contained software units. The
identification for each unit must include version no,
latest date of issue and status category (Ref. Software
Integration Plan, para 2.4.3).
3.5.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲r̲o̲b̲l̲e̲m̲ ̲R̲e̲p̲o̲r̲t̲s̲ ̲(̲S̲P̲R̲)̲
After receival of a software package for System I &
T the relevant test procedures are selected and executed.
If an error is detected a Software Problem Report (SPR)
is issued. The SPR shall contain a narrative description
of the error symptoms, Test Procedure and step no.
at occurrance, accumulated run-time and possible hardcopy
documentation.
The SPR shall further contain indication of error type
and category and priority of error correction. The
following definition shall apply:
a) E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲
Error Type Definition
A Minor reproduceable error
B Minor non reproduceable
error
C Major reproduceable error
D Major, non reproduceable
error
b) E̲r̲r̲o̲r̲ ̲C̲a̲t̲e̲g̲o̲r̲y̲
C̲a̲t̲e̲g̲o̲r̲y̲ ̲1̲
1) Loss of a message or other transaction.
2) Corruption of a message or other transaction
3) A message or transaction being missent.
4) Misapplication of security rules.
5) Failure of accounting procedures.
C̲a̲t̲e̲g̲o̲r̲y̲ ̲2̲
1) Loss of service to more than 25% of all channels
and user connecting points.
2) Loss of service to more than 50% of all operating
positions or system reporting facilities.
3) Loss of ability to recover the system
C̲a̲t̲e̲g̲o̲r̲y̲ ̲3̲
1) Errors not included in 1 and 2 above.
c) E̲r̲r̲o̲r̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲
Priority Definition
1 Top priority, System I &
T is held up by the error
2 Medium priority, System
I & T is adversely affected
by the error
3 Low priority, System I &
T is not affected by the
error.
The SPR is logged by Configuration Management and is
together with the software package returned for correction
by the responsible development team.
3.5.3.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲R̲e̲c̲o̲r̲d̲ ̲(̲S̲M̲R̲)̲
When a detected error is identified and corrected a
Software Modification Record (SMR) is issued and logged
by Configuration Management. The SMR shall contain
a description of the affected units and modules, and
an indication of which System functions that use the
affected units and modules. The SMR is submitted with
the software package at renewed delivery for System
I & T.
3.5.3.4 R̲e̲g̲r̲e̲s̲s̲i̲o̲n̲ ̲T̲e̲s̲t̲i̲n̲g̲
In case of renewed delivery of a software package for
System I & T the enclosed Turnover Letter and SMR is
analysed, and all functions, which include modified
units or modules, must be retested. This retest of
possibly affected functions is called regression testing.
When regression testing is completed, the system I
& T workpackage is continued from the point, where
the error occurred during the previous execution of
the workpackage.
FIGURE 3.5.3-1…01…SYSTEM I & T CONTROL FLOW
3.5.3.5 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲f̲e̲c̲t̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
In paras 3.5.3.3-4 is outlined how software errors
and their corresponding correction is reported and
accounted.
Based on the accounted SPR's a monitoring of the trend
in occurances of Software defects is planned. The purpose
of this monitoring of software defects is to provide
a measure of the software reliability and correspondingly
to give an indication of testing efficiency and testing
progress.
The software defect monitoring will be conducted by
plotting the accumulated number of detected software
errors vs. the accumulated run-time. Separate plots
can be made for each error category.
It is expected that the relationship between the accumulated
no. of errors and the accumulated run-time can be expressed
as:
acc. err. no. = 1 - exp (kt)
where t is the acc. run-time, and the constant k can
be determined from the plotted curve. When the constant
k has been determined a prediction of the expected
no. of detected software errors within a certain run-time
can be made.
3.5.4 R̲e̲s̲o̲u̲r̲c̲e̲ ̲E̲s̲t̲i̲m̲a̲t̲e̲s̲
Resources required for conductance of the System I
& T task is here divided into equipment for test execution
and manpower for test control. Software prerequisites
described in para 3.2.1 are assumed to be available
as needed.
3.5.4.1 M̲a̲n̲p̲o̲w̲e̲r̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲
The System I & T execution task is estimated to require
a manpower effort of approximately 5 manyears. According
to the schedule outlined in para 3.3 this effort must
be performed during a period of approx. 6 months. This
means, that over the 6 month period an average of 10
persons will be required for conductance of this task.
The test execution workload is estimated to vary considerably
during the I & T period. It is anticipated, that in
the beginning of the test period the frequency of error
occurances will be high. In this phase a substantial
workload consisting of error correction will be imposed
on the software development team, while the workload
on the I & T team will be moderate.
Later in the I & T period the error occurrance frequency
is expected to decrease resulting in an increasing
workload for the I & T team.
The anticipated simultaneous increase and decrease
in manpower needs for System I & T - and Software Development
tasks will likely result in a transfer of manpower
from one task to the other.
3.5.4.2 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲
The need for equipment required for test execution
will vary with the workload imposed on the System I
& T team. In the initial testphase it is only possible
to perform a sequential execution of the I & T workpackages
with only one test team.
Later in the I & T period, when a number of system
functions have been verified, it will be possible to
have two test teams working in parallel. This will
require the availability of two sets of CAMPS equipment
for test execution.
It is estimated, that during the first 2 months of
the I & T period one CAMPS system will be sufficient
for I & T execution. During the remaining 4 months
period two CAMPS systems will be needed for I & T execution.
This need is catered for in the Program Plan.
