top - download
⟦a65be2297⟧ Wang Wps File
Length: 50261 (0xc455)
Types: Wang Wps File
Notes: CPS/TSP/002
Names: »0340A «
Derivation
└─⟦2f7a68440⟧ Bits:30006045 8" Wang WCS floppy, CR 0071A
└─ ⟦this⟧ »0340A «
WangText
…00……00……00……00……00……1f……02……00……00……1f…
…1e……0b……1e…
…1e……07……1d……0d……1d…
…1c……0a……1c……00……1c……06……1b……0d……1b… …1a……0a……1a……0f……1a… …19……0a……19……0f……19……86…1 …02… …02… …02…
…02…CPS/TSP/002
…02…KNN/821215…02……02…#
SOFTWARE INTEGRATION PLAN
…02…ISSUE 1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .................................. 4
1.1 PURPOSE AND SCOPE ...................... 4
1.2 PROJECT REFERENCES ..................... 5
1.3 TERMS .................................. 6
2 SOFTWARE INTEGRATION MANAGEMENT .......... 7
2.1 MANAGEMENT ORGANIZATIONS ............... 7
2.1.1 Test Specification and Procedure
Work Package ....................... 8
2.1.2 Test Execution Work Package ........ 9
2.1.3 Software Test Control Board ........ 11
2.2 INTEGRATION SCHEDULE ................... 12
2.3 INTEGRATION SPECIFICATION AND
PROCEDURES ............................. 13
2.3.1 Integration Test Specifications .... 13
2.3.2 Integration Test Procedures ........ 14
2.4 PRODUCT CONTROL ........................ 16
2.4.1 Software Problem Reporting ......... 16
2.4.2 Software Status Accounting ......... 21
2.4.3 Library Control .................... 21
…02…3 SOFTWARE INTEGRATION DEFINITION AND
STRUCTURE ................................ 24
3.1 INTEGRATION APPROACH ................... 24
3.2 RELEASE PRODUCTS/BUILDS IDENTIFICATION . 25
3.2.1 Functional Capabilities of Build ... 25
3.2.2 Software Units Included in Build ... 37
3.2.3 Required Ressources by Build ....... 38
…02…4 RESOURCE REQUIREMENTS .................... 40
4.1 HARDWARE FACILITIES .................... 40
4.1.1 SW Development System Configuration 41
4.1.2 DSMT Configuration ................. 42
4.1.3 Typical CAMPS HW Configuration ..... 48
4.2 SUPPORT SOFTWARE ....................... 49
4.3 RESOURCE UTILIZATION ................... 49
5 SOFTWARE INTEGRATION REQUIREMENTS ........ 50
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
This plan defines the software integration and test
activities (excluding unit test) to be accomplished
by the CAMPS software development team prior to system
integration and test and acceptance testing.
The purpose of this plan is to establish the level
of thoroughness by which software integration testing
shall be conducted and to describe how the CAMPS software
development team will conduct and monitor the software
integration.
Software integration testing is the second step in
series of tests.
The types of testing which shall be distinguished are:
1) U̲n̲i̲t̲ ̲t̲e̲s̲t̲i̲n̲g̲: Tests a piece of software against
the specifications imposed on it in the design
phase. This usually means testing against detailed
design.
2) I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲i̲n̲g̲: Tests whether a unit tested
piece of software interfaces properly with other
units and whether these units function properly
together within a higher level of integration.
Integration testing will be conducted in two major
phases, which are software and system integration
testing respectively. Software integration consists
of integrating application software units into
major software packages. During system integration,
application software packages are integrated whereby
system capabilities and requirements can be verified.
This is mainly a verification of the consistency
of detail design with architectural design.
3) Q̲u̲a̲l̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲i̲n̲g̲: Systematically tests a
completely integrated piece of software and its
parts against the functional performance and interface
specifications on which the design was based.
This amounts to testing the design against the
requirements specifications.
Qualification tests of CAMPS developed software are
described in the CAMPS Acceptance Plan (CPS/PLN/012),
that describes the following software tests:
- in-plant software test.
- software functional test.
- software operational test.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
- CAMPS System Requirements
CPS/210/SYS/0001
- User Procedures and Associated Formats
CPS/230/ICD/0001
- Supervisor Command and Procedures
CPS/230/ICD/0002
ACP 127 NATO Supp. 3 Procedures
CPS/230/ICD/0003
- NICS TARE Interface Control Document
CPS/ICD/004
- SCARS II Interface Control Document
CPS/ICD/005
- ACE CCIS Interface Control Document
CPS/ICD/006
- TRC, Point-to-point Connection Interface Control
Document
CPS/ICD/007
- OCR Interface Control Document
CPS/ICD/008
- CAMPS System Design Specification
CPS/SDS/001
- CAMPS Program Implementation Plan
CPS/100/PIP/0001
- CAMPS System Development Plan
CPS/PLN/002
- CAMPS Acceptance Plan
CPS/PLN/012
- CAMPS Software Test Plan
CPS/PLN/001
- CAMPS Software Package Specifications
o CAMPS SYSTEM FUNCTIONS CPS/SDS/002
o MESSAGE MANAGEMENT CPS/SDS/003
o SYSTEM STATUS AND CONTROL CPS/SDS/004
o TABLE MANAGEMENT CPS/SDS/005
o INPUT/OUTPUT CONTROL CPS/SDS/006
o STORAGE AND RETRIEVAL CPS/SDS/007
o STATISTICS CPS/SDS/008
o LOGGING CPS/SDS/009
o TRAFFIC HANDLING CPS/SDS/010
o MESSAGE DISTRIBUTION CPS/SDS/011
o TERMINAL PACKAGE CPS/SDS/012
- CAMPS Software Interface Control Document
CPS/ICD/009
- Database Design Document
CPS/DBD/001
1.3 T̲E̲R̲M̲S̲
Build:
For the purpose of this document, a build is defined
as a software entity made up of integrated software
components, which represent a significant partial functional
capability of the CAMPS system functions.
Software Unit:
For integration purposes, a software unit is defined
as a piece of software which has relatively few interfaces
to other pieces of software and which can be developed
by maximum one engineer.
Software Module:
The smallest compilable piece of software.
2̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
This chapter defines the management issues that in
particular shall be emphasized during software integration,
which are:
- management organization
- software integration master schedule
- integration specification and procedures
- software product control
Each of these management areas are discussed in the
section 2.1 through 2.4.
2.1 M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
The CAMPS application software package level verification,
planning, integration, and test execution are the responsibility
of the CAMPS software development organization under
direction of the CAMPS Software manager or by one of
his authorized software integration managers. His
responsibilities in support of the above activities
include the following:
- establish overall SW integration and test schedules.
- monitor SW integration and test budget and schedules.
- organize and chair the SW test control board (SW
TCB).
- ensure sufficient SW project resources are available
to support the test activities.
- monitor the performance of the software test effort.
- determine software retest policy together with
the software test control board (SW TCB).
- ensure SW test and schedule objectives are met.
The CAMPS software integration and test activities
are divided between the two packages:
- specification and procedures.
- integration and test execution
The responsibilities, organization, and reporting procedures
of each package are described in section 2.1.1 and
2.1.2 below. Section 2.1.3 describes the responsibilities
and organization of the SW test control board (SW TCB):
2.1.1 T̲e̲s̲t̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲W̲o̲r̲k̲ ̲P̲a̲c̲k̲a̲g̲e̲
This work package deals with generation of test specifications
and procedures required for integration of application
software units into application software packages (refer
section 3).
These specifications and procedures will be established
per application software package.
In relation to the above work package, the software
manager or one of his authorized software integration
managers has the following responsibilities.
- establish work package activities priorities and
schedules.
- perform day-to-day supervision of the work package.
- keep management informed of activity progress,
problems and plans by providing a weekly status
report to the CAMPS management team.
The overall coordination of the production of each
document will be assigned to a Book Captain whose responsibilities
include the following:
- make writing assignments in coordination with the
SW manager.
- provide document contents direction
- maintain a detailed production schedule updated
weekly.
- keep SW manager continuously advised of activities
and any problems encountered which could adversely
affect the document production schedule.
- coordinate with technical support and documentation
support personnel.
- coordinate review and document update process.
- coordinate documentation distribution.
2.1.2 T̲e̲s̲t̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲W̲o̲r̲k̲ ̲P̲a̲c̲k̲a̲g̲e̲
This work package deals with the integration and verification
procedure for execution of CAMPS application SW packages.
These responsibilities include:
- receive tested SW units (refer section 3.1) and
integrate these.
- isolate and report on SW problems including implementing
temporary fixes as necessary.
- define and perform retest/regression tests required
for new SW updates.
- prepare SW package deliveries to CAMPS system engineering.
- execute final SW verification procedures
- generate the Verification Report
The above activities will be performed under the direction
of the SW manager or by one of his authorized SW integration
managers. His responsibilities include the following:
- establish work package activity priorities and
schedules.
- perform day-to-day supervision of the work package.
- keep management, other test efforts, and support
organizations informed of testing status and all
problems which might affect the progress of the
SW integration and test (I & T ) test activities,
other groups performing concurrent test activities,
and subsequent test activities.
- provide a weekly status report to the CAMPS management
team.
- ensure adherence to SW problem reporting procedures
and other applicable procedures.
- coordinate resources required from and provided
to other organizations.
- establish determination of retest policy.
- call and chair meetings and reviews concerning
the SW test activity.
- participate in the review, approval, and proposed
changes to SW test documentation.
- approve SW configuration and all quick fixes used
during SW I&T testing.
- supervise preparation of the Verification Report.
Each test will be assigned to a Test Conductor whose
responsibilities include the following:
- prepare test case execution materials in accordance
with the approved test procedures.
- initiate document change requests as required to
correct test documentation.
- perform or support test execution.
- analyze and document test results.
- generate Software Problem Reports SPRs for problems
uncovered during testing.
- conduct appropriate retests.
- participate in meetings and technical discussions.
- keep SW manager continuously advised of test activities
and any problems encountered which could adversely
affect the test schedule.
- participate in the preparation of the Verification
Report.
An additional function to be staffed by one or more
people as a part of this work package is that of SW
Library and Information Control. The responsibilities
under this heading include the following:
- install and maintain all of the SW product libraries
under test.
- prepare an installation report for each SW release
installed.
- provide feedback as required to update SW installation
procedures.
- maintain temporary SW fix baseline.
- maintain up-to-date library of SW Problem Report
SPR and temporary fix documentation.
- maintain test case library and assist in preparing
test results packages.
2.1.3 S̲W̲ ̲T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲o̲a̲r̲d̲
The SW Test Control Board (TCB) is authorized to review
and control the SW integration effort in order to ensure
the completeness of each test phase and an orderly
progression to subsequent test phases. The TCB responsibilities
therefore include the following:
- review and approve SW integration and verification
test specifications and procedures at all test
levels to ensure all requirements are adequately
tested.
- review SW test status, test data packages, and
summary reports to ensure that the approved procedures
were used and the SW is ready for the next test
phase.
- review and approve changes to baselined SW test
specifications and procedures.
- ensure that test failures have been corrected and
adequate retesting has been accomplished.
- to approve problem reports/changes generated during
SW integration.
The SW TCB will be composed of representatives from
the following organizations:
- SW Quality Assurance (CR)
- System Engineering Management
- SW Management
- Representatives from each SW test activity as appropriate.
The Chairman (SW manager) will call meetings as required
by the test activity allowing sufficient time for an
adequate review of test materials. Minutes of each
meeting documenting agreements and action items will
be produced.
2.2 S̲C̲H̲E̲D̲U̲L̲E̲
The application software consists of thirteen software
packages. Each software package consists of a number
of software units (5-15).
In order to accommodate early system testing it has
been planned to establish a number of builds for each
software package which supports early system testing.
A build is defined as a software entity made up of
integrated software components, which represents a
significant partial functional capability of the CAMPS
system functions.
The schedule for builds and their dependencies to system
integration where the sequence of events for integrating
software packages into a system (or partial system/system
build) is documented on three separate CAMPS software
Development Perts for Build 1, Build 2 and Build 3.
2.3 I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
This section describes the general requirements which
have to be fulfilled by all software integration specification
and procedures.
2.3.1 I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲a̲n̲d̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Integration testing is principally involved with assuring
that the interfaces have been properly defined and
implemented.
Integrated software component shall be tested according
to test case specifications.
The total set of test cases shall demonstrate.
a) that the integrated software component meets its
functional and performance (timing and sizing)
specifications.
b) that the interfaces between the software components
being integrated are functioning/performing according
to specifications.
Consequently, one subset of the test space must be
designed against the functional/performance requirements
whereas the other subset must be designed against the
interfaces between the software components being integrated.
A cross reference between functional/performance requirements
and test cases shall be established for all tests by
which the software capabilities are being tested.
A cross reference between interface specifications
and test cases shall be established for all tests by
which software interfaces are being tested.
2.3.2 I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
For each of the test cases, specified according to
section 2.3.1, a procedure shall be established.
The procedures shall specify:
- facilities required
- set-up conditions
- sequence of event
- acceptance criteria
a) F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲ ̲R̲e̲q̲u̲i̲r̲e̲d̲
A section in the test procedures shall contain
the minimum facilities required to run the test
case in the test facility.
b) S̲e̲t̲-̲U̲p̲ ̲C̲o̲n̲d̲i̲t̲i̲o̲n̲s̲
The test set-up conditions shall describe all external
environmental conditions that have a bearing on
the test.
c) S̲e̲q̲u̲e̲n̲c̲e̲ ̲o̲f̲ ̲E̲v̲e̲n̲t̲s̲
The test sequence of events must be updated to
show all actions required to run the test in the
test facility, and expected results for that test
facility.
d) T̲e̲s̲t̲ ̲B̲e̲d̲
In connection with the development of a software
unit a complete test bed shall be developed and
utilized in unit testing.
The Test Bed shall be released with the unit and
be available in the future as a basis for tests
after modifications and to be integrated in the
integration test bed as appropriate.
The Test Bed shall consist of:
1) Test Driver
- If the unit under test is not a selfstanding
program, the test driver shall contain
the necessary control structure to invoke
the functions of the test item.
- If the test item does not access its input
data directly, the test driver shall contain
means for accessing proper input data and
convey them to the unit.
- If the test item does not produce direct
output the test driver shall contain means
for accepting output from the unit and
store them in a test output file.
2) Test Data
A Test Data file shall contain all the necessary
data to exercise the test.
3) Test Output File
An output file shall be available for retaining
the results of a test run. The latest test results
shall always be kept on a copy in order to compare
it with the result of a new run.
4) Stubs
One or more stubs as necessary to simulate the
functions of other units with which the unit under
test normally interfaces.
The simulation may be primitive but shall be sufficient
to support the ongoing test.
2.4 P̲R̲O̲D̲U̲C̲T̲ ̲C̲O̲N̲T̲R̲O̲L̲
Product control during SW integration shall consist
of the following elements:
- software problem reporting
- software status accounting
- software library control
Software problem reporting is the mechanism by which
a suspected or existing discrepancy or deficiency in
an existing software component and/or its associated
documentation is reported and processed.
Software status accounting refers to the procedures
which have to be followed, when software and/or its
associated documentation has to be updated.
Software library control refers to the procedures by
which the software products have to be handled.
2.4.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲r̲o̲b̲l̲e̲m̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
Software problem reports shall be generated as a result
of a suspected or existing discrepancy, deficiency
or error in an existing software component and/or its
associated documentation.
Software problem handling shall take place according
to the Problem Handling Standard SD/STD/007.
A separate software problem file will be established
for the software integration phase.
Problem reports shall when generated, undergo a number
of procedural steps until the proposed solution can
be authorised to be implemented. The procedural steps
are:
- logging of problem report
- proposal to solution of problems
- presentation to software change control board and
authorization
- establishing change log record
All problem reports shall be kept in a central file
in which each report is identified by a label (seq.
number). The software problem report file is controlled
by CAMPS software configuration management.
After a report has been logged, a proposed solution
shall be generated. This can be performed by the originator
of the problem report, the responsible work package
manager and/or CAMPS system engineering.
The software change control board described in section
2.1.4 is the authority that approves/disapproves the
problem reports and their associated changes. This
board will meet weekly/biweekly to process the generated
problem reports.
When changes have been approved, a change order log
record shall be generated for each change order to
ensure that proper status accounting is maintained
as described in section 2.4.2.
Overleaf is presented a flowchart of the steps problem
reports shall go through until they represent an authorized
change.
Fig. 2.4.1-1
In order to support error reporting qualitatively,
as well as quantitatively, problems/errors shall be
categorized, which could be as follows.
CATEGORY DEFINITION, EXAMPLE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 Omitted logic Code is lacking
which should be
present. Variable
A is assigned a
new value in logic
path X but is not
reset to the value
required prior to
entering path Y.
2 Failure to reset data Reassignment of
needed value to
a variable omitted.
See example for
"omitted logic."
3 Regression error Attempt to correct
one error causes
another.
4 Documentation in error Software and documentation
conflict: software
is correct. User
manual says to input
a value in inches,
but program consistently
assumes the value
is in centimeters.
5 Requirements inadequate Specification of
the problem insufficient
to define the desired
solution. See Figure
4. If the requirements
failed to note the
interrelationship
of the validity
check and the disk
schedule index,
then this would
also be a requirements
error.
6 Patch in error Temporary machine
code change contains
an error. Source
code is correct,
but "jump to 14000"
should have been
"jump to 14004."
7 Commentary in error Source code comment
is incorrect. program
says DO I=1,5 while
comment says "loop
4 times."
8 IF statement too simple Not all conditions
necessary for an
IF statement are
present.
IF A=B should be
IF A=B and B=C.
9 Referenced wrong data variable Self-explanatory
See Figure 3. The
wrong queues were
referenced.
10 Data alignment error Data accessed is
not the same as
data desired due
to using wrong set
of bits.
Leftmost
instead
of
rightmost
substring
of
bits
used
from
a
data
structure.
11 Timing error causes data loss Shared data changed
by a process at
an unexpected time.
Parallel task B
changes XYZ just
before task A used
it.
12 Failure to initialize data Non-preset data
is referenced before
a value is assigned.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Lesser categories are not defined here
Fig. 2.4.1-2…01…ERROR CATEGORY DEFINITION
The categorization of software problems will furthermore
support the defect measurements, which are described
in the CAMPS System Development Plan CPS/PLN/002.
2.4.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
Status accounting records shall be maintained with
respect to software problem reports and approved software
changes.
The problem log record shall contain an identification
of the problem report and its status (refer section
2.4.1).
The change log record shall contain an identification
of the problem which generated the change and an identification
of the change order. Furthermore, accountance should
be given for all changes to products and/or documents
affected by the change order.
2.4.3 L̲i̲b̲r̲a̲r̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
Library control presented in this section is concerned
with the following subjects:
- software configuration identification
- library structure
- library procedures
The Application and System Software subsystems can
be identified at different levels, which are package
level, subpackage level, and module level. A software
package consists of one or more software subpackages
and a software subpackage consists of one or more modules.
Software items shall be identified as follows:
CPS/XXX/VV/ZZ/UUUU
Version and Release Number
Module Number
SW Subpackage Number
SW Package ID
Project
Examples:
a) A software package with its associated subpackages
and modules has the following identification:
CPS/TEP/0101 Version 0101 of the terminal
package (TEP).
b) A software subpackage in the software terminal
package has the following identification.
CPS/TEP/01/0201 Version 0201 of the subpackage
01 in the terminal package
TEP.
c) A software module in the software terminal package
has the following identification:
CPS/TEP/07/17/0202 Release 02 of version 02
of module no. 17 contained
in subpackage 07 of the terminal
package.
The software library has a structure which reflects
the different phases of development a SW item can exist
in. The software library has therefore been divided
into four categories which are:
cat. 1: Software items which have not yet been module
tested and integrated into a subpackage.
cat. 2: Software items (subpackages) which are being
integrated to software packages and not yet
released for system integration.
cat. 3: Software items (packages) which are being integrated
to a system and not yet released for formal
acceptance.
cat. 4: Software system released for formal acceptance
at system level.
Release numbering is initiated when a module has been
released to category 2.
The version and release number consists of four digits.
The two leading digits decide the functional capabilites
and the last two digits are the release number.
The Release number is incremented each time the module
has been modified and released again. When a new version
has been released the version number is incremented
by one and the release number is reset to 01.
The latest issue date is related to the date of the
latest release number.
3̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
This chapter addresses the general integration approach.
Furthermore, it identifies all software components
which have to be integrated, the integration sequence
and the planned integration steps (build). A build
represents a significant partial functional capability
of a software entity.
3.1 I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
The lowest level software component to be integrated
is a software unit. For integration purposes a software
unit is defined as a piece of software which has relatively
few interfaces to other pieces of software and which
can be developed by maximum one engineer.
All software units have been tested exhaustively during
software unit testing (refer Software Test Plan CPS/TSP/001).
During software integration, software units are integrated
into larger software components in the following called
builds.
Software integration consists of integration of software
units into packages (refer CAMPS Software Page Specifications
(CPS/SDS/002 to CPS/SDS/012) in two or three steps
for each step is produced a build, which will be defined
by the integrated units contained in the build and
the functional capability of the build.
During software integration, a combination of top-down
and bottom-up testing will be used. This approach
has been chosen to combine the advantages of both i.e.,
to minimize number of test drivers and to increase
possibility for concurrent testing.
The system software packages will be integrated as
part of the software integration, while application
packages will be integrated during system integration.
The system software packages are CAMPS SYSTEM FUNCTIONS,
I/O CONTROL, SYSTEM STATUS AND CONTROL, and MESSAGE
MANAGEMENT.
3.2 B̲U̲I̲L̲D̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
This section defines the builds which are to be integrated
for each of the CAMPS application software packages
(CPS/SDS/002 - CPS/SDS/012, refer section 1.2 of this
plan).
A build represents a significant partial functional
capability of a CAMPS application software package.
Each incremental build demonstration is a partial
dry run of the final software application package acceptance
test.
Builds will in this section be defined by their functional
capabilities and the software unit which they consist
of.
To establish builds, software units must be integrated
in a certain sequence. The integration sequences for
the different application software packages are defined
in this section.
3.2.1 F̲u̲n̲c̲t̲i̲o̲n̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲ ̲o̲f̲ ̲B̲u̲i̲l̲d̲s̲
For each of the CAMPS software packages will be defined
between one and three builds.
Each of these builds will be defined by their corresponding
functional capabilities. The functional capabilities
will be derived from the CAMPS system requirements
specification CPS/210/SYS/0001.
In Figure 3.2.1-1, the number of increments for each
CAMPS software package is identified.
The following pages define for each of the identified
builds, the functional capabilities to be included
in the different builds.
Definition of increments has been performed under two
constraints which are:
a) to support system engineering in early integration
of the system builds with a limited number of system
capabilities.
b) to establish visibility and early feedback during
software integration.
As it can be seen from figure 3.2.1-1 some software
packages have only one integration step. This is either
due to the size of the package or, because all functional
capabilities are required by other packages.
Tables 3.2.1-1 to 3.2.1-17 define the functional capabilities
of all builds for each of the application software
packages.
SOFTWARE PACKAGE ABBR. INCREM.1 BUILD INCREM.2 BUILD INCREM.3 BUILD
NAME NAME IDENT. NO. IDENT NO. IDENT. NO.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
User VDU Functions VUP VUP1 1 VUP2 2 VUP3 3
User Printer
Functions PRT PRT1 2 PRT2 3
Supervisor VDU
Functions SUP SUP1 2 SUP2 3 SUP3 3
MDCO VDU Functions MDO MDO1 3 MDO2 3
MSO VDU Functions MSO MSO1 3 MSO2 3 MSO3 3
Supervisor Prin-
ter Functions SPR SPR1 3 SPR2 3
Message Distribution MDP MDP 1
Traffic Handling THP THP1 3 THP2 3 THP3 3
Logging LOG LOG1 1 LOG2 3 LOG3 3
Storage and Re-
trieval SAR SAR1 2 SAR2 2 SAR3 3
Statistics STP STP1 1 STP2 3 STP3 3
Table Management TMP TMP1 1 TMP2 2 TMP3 3
CAMPS System CSF2a 1
Functions CSF CSF1 1 CSF2b 2 CSF3 3
System Generation SGE SGE 1
Format Gene-
ration VDU FGV FGV 1
Format Genera-
tion Printer FGP FGP 2
Data Base Generation DBG DBG1 1 DBG2 2 DBG3 3
Message Management MMS MMS1 1 MMS2 2 MMS3 3
System Status
and Control SSC SSC1 1 SSC2 2 SSC3 3
Input/Output Control IOC IOC1 1 IOC2 2 IOC3 3
Figure 3.2.1-1
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
VUP1 USER MENU (FORMAT X)
NEW MSG PREP (FORMAT A)
NEW COM PREP (FORMAT G1)
CONT MSG PREP (FORMAT C1)
CONT MSG PREP (FORMAT G3)
COORDINATION (FORMAT B)
OUTGOING MSG (FORMAT E2)
RELEASE (FORMAT D)
INCOMING MSG (FORMAT E1)
COMMENT (FORMAT G2)
REL.NOT. (FORMAT F)
REL MENU 1
REL MENU 2
VUP2 MSG/COM RETR (FORMAT H)
VUP3 APPEND MSG (FORMAT 0)
MSG/COM DEL (FORMAT P1)
OUTG MSG STATUS (FORMAT N)
DELIVERY STATUS (FORMAT R)
DEL.NOT (FORMAT P2)
APPEND NOT
MSG. REL STATUS (FORMAT Q)
SCARS/ACCIS ALL FORMATS.
TABLE 3.2.1-2
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
PRT1 All capabilities but:
- Preemption
- Document accounting (only User VDU increment
1 format can be printed)
PRT2 Remaining capabilities
TABLE 3.2.1-3
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
SUP1 Supervisor Menu (SUPV)
System Control Functions (SYSC)
Device Control Functions (DEVC)
Terminal Position Control (TEPC "TD")
PT/OCR/SATP Control (POSC "DD")
Channel Control (CHAC "CD")
Addressing Scheme Control Functions
SIC-Table Update (SICT "SIC")
SDL-Table Update (SDLT "SDL")
SCD-Table Update (SCDT "SCD")
AIG-Table Update (AIGT "AIG")
Global PLA-Table Update (GPLT "PLAREF")
RI-Table Update (RITA "RI")
Circuit-Table Update (CIRT "CIRCUIT NO")
SCARS/ACCIS Display-Table Update (SCCT
"Display ID")
Operating Signal Table (OPST "MHI")
Local PLA-Table Update (LPLT "PLAREF")
Local RI-Table Update (LORI)
User Profile Update (UPUP "USER ID")
Command Control (CMDC "CMC")
SUP2 Message Handling Functions (MSGH)
Service Message Preparation (SMPR)
New Plaindress Format Preparation (PRPF)
New Abbreviated Plaindress Format Preparation
(PRAP)
New Abbreviated Service Message Format
Preparation (PRAS)
Continue Plaindress Preparation (CPFP)
Continue Abbreviated Plaindress Preparation
(CAPP)
Continue Abbreviated Service Message Preparation
(CASP)
Service Message Deletion (DESM)
Status of Outgoing Service messges (OSMS)
Retrieval for Local Use (RELU)
Key Type Entry
Retrieval Key A
Retrieval Key B
Retrieval Key C
Retrieval key D
Retrieval Key E
TABLE 3.2.1-4
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Validation
Retrieval for Readdressal (READ)
Retrieval for RERUN (RERN)
Retrieval for Redistribution (REDS)
Retrieval for Deletion (REDE)
Response Message Display (RESP)
SUP3 Reorganize All Tables (REOR)
Abandon Reorganization (ABRO)
Block Circuit Queue (BLCQ "CIRCUIT NO")
Unblock Circuit Queue (UBCQ "CIRCUIT NO")
Block Terminal Queue (BLTQ "TD")
Unblock Terminal Queue (UBTQ "TD")
Block Device Queue (BLDQ "DD")
Unblock Device Queue (UBDQ "DD")
Cancel Circuit Queue (CACQ "CIRCUIT NO")
Cancel Terminal Queue (CATQ "TD")
Cancel Device Queue (CADQ "DD")
Cancel System Queue (CASQ)
Cancel All Circuit Queues (CAAC)
Cancel All Terminal Queues (CAAT)
Cancel All Device Queues (CAAD)
Supervisor Print Control (SUPC)
Off Load Data (OFLD "TIME STAMP, VOL-ID")
Abandon Off Load (ABOL)
Copy System Parameter File (COPY)
Off Line Retrieval Off (OROF)
Off Line Retrieval On (ORDN)
Off Line Retrieval Suspend (ORSU)
Currently Used Volume List (VOLI)
Refuse Mount (REMO "VOL-ID")
Volume Mount (VOMO "VOL-ID")
System Volume Mount VSMO "VOL-ID")
Volume Dismount (VODM "VOL-ID")
Volume Name (VONM "VOL-ID")
Volume Delete (VODL "VOL-ID")
Security Control (SECC)
Global no. Series Control Functions (GNSC)
Channel No. Series Control (NOCC "CD")
Transaction No. Series Reset (NOTR "TD/DD")
System Parameter Control Functions
Print/Punch Parameter Control
Channel Parameter Control (CHPC)
ACP127 Parameter Control (ACPC)
Message Distribution Parameter Control
Special Distribution Parameter Control
(SDPC)
TABLE 3.2.1-4 (continued)
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Crisis Indicator On (CION)
Crisis Indicatro Off (CIOF)
Set Quiet Hours (SQGH "TD")
Stop Quiet Hours (SQHO)
Flash Queue Time Out (FLQT "NN")
System Information Extract Functions
Log Trace (LGTR)
Password List (PWLT)
Queue State Print (QSPT)
User Profile Print (UPPT "USER-ID")
Terminal Profile Print (TPPT "TD")
Device Profile Print (DPPT "TD")
Channel Profile Print (CPPT "CD")
Command print (CMPT)
System Parameter Print (SPAP)
Storage Occupancy Request (STOC)
Table Print Functions
Supervisor Engineering
Engineering Functions (SENF)
TABLE 3.2.1-4 (continued)
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
MDO1 Service Message Preparation
Retrieval for Redistribution
MDO2 Message Distribution Assistance
Retrieval Message Display
TABLE 3.2.1-5
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
MSO1 Service Message Preparation
Retrieval for Readdresal and Rerun
MSO2 Incoming Service Message Assistance
Retrieval Message Display
MSO3 Outgoing Message Service Assistance
TABLE 3.2.1-6
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
SPR1 Statistics
Log
Reports
SPR2 Tables
TABLE 3.2.1-7
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
MDP All
TABLE 3.2.1-8
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
THP1 Analysis Subpackage
Analysis of message in ACP127 format and
CCIS E1 format.
THP2 Conversion Subpackage
Transport Subpackage partly
Conversion of Internal formatted message
into ACP127 format and/or CCIS E1 ̲format:
Reception and transmission of messages
on Low speed channels (TRC ̲Point ̲to ̲point)
THP3 Transport Subpackage Complete
Reception and transmission of message to/from
NICS ̲TARE, SCARS and CCIS.
Paper Tape Reader and Punch (PTR and PTP)
TABLE 3.2.1-9
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
LOG1 Capable of collecting log records
LOG1 Append log records to log CIF and store
log CIF using SAR.
LOG3 Capable of doing a complete trace function
TABLE 3.2.1-10
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
SAR1 Able to perform an on-line storage procedure
of messages and transactions. Checkpoint
mechanism excluded.
SAR2 Capable to perform on-line retrieval requests
from TEP.
SAR3 Off-line retrieval capabilities. Supervisor
commands for off-line retrievals. Dump
capabilities.
TABLE 3.2.1-11
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
STP1 Able to perform a complete collection of
statistics records into the main memory
resident shared data area (SDA).
STP2 Capable of dumping SDA to disk, and generate
statistics.
STP3 Capable of delivering the previously generated
statistics to the statistics printer via
CIFs.
TABLE 3.2.1-12
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
TMP1 Search in tables existing in the memory
Read of system parameters
GNS management
TMP2 Update of memory resident tables and system
parameters without recovery or backup
TMP3 Search in tables existing at the disk
Statistics
Recovery
TABLE 3.2.1-13
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CSF1 Coroutines and System Calls
CSF2a Timer Monitor
Queue monitor except recovery and Performance
Monitoring
CSF2b Message Monitor except Storage and Retrieval
and except Checkpoint and Recovery
CSF3 Storage and Retrieval
Checkpoint and recovery
Performance Monitoring
TABLE 3.2.1-14
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
MMS 1 CIF and View creation and deletion
CIF I/O Functions
MMS 2 CIF Storage and Retrieval
MMS 3 CIF Checkpoint and Recovery
Off-line retrieval
TABLE 3.2.1-15
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
SSC1 Reception of commands/reports from SYNC
̲EL/QUEUES (CMD in EHD)
Print of SW/HW reports in hex (COMMON).
Start-up of (CFH)
- CAMPS processes
- Devices
Terminal supervision (TEMCO)
- Sign-on/off
- User subp/queue control
SSC2 Operator Commands (CMI)
(Syntax/semantic validation execution (CFH)
- TDX system
- Disk system
- Soft system
SW errorhandling (EHD)
Terminal Supervision (TEMCO)
- Security interrogation/working
- MSO/MCDO/SUPV supervisor
- Execution of supervisor commands
- Select capability
Device Supervision (DEMCO)
- ROP, OCR, PTR, PTP, LTP supervision
Active HW errorhandling (EHD)
Detailed printout of SW/HW reports (COMMON)
Control WDP ̲VDU (WAMCO)
TABLE 3.2.16-1
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
SSC3 Online diagnostics (OLD, CFH, TEMCO)
- Kernel Sumcheck
- LTUX loop test
- Floppy disk test
- Collect statistics
Execute operator commands (CMI/CFH)
- LTU system
- SW maintenance
- Close down
- Only Modes
- Switchover
- Startup
Watchdog (WDP, WAMCO)
Channel Suspension (CEMCO)
TABLE 3.2.1-16 (cont.)
INCREMENT CAPABILITIES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IOC1 Format Handler VDU
All VDU Handler capabilities except INIT
and CANCEL.
Console interface non-watchdog mode
LTUX functions VDU
IOC2 Format Handler Printer
Printer Handler
Low Speed Line Handler
LTUX Functions Printer
IOC3 Remaining VDU handler capabilities
LTUX Functions low speed line
NICS TARE
SSC Interface
OCR Handler
CCIS/SCARS
TABLE 3.2.1-17
3.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲U̲n̲i̲t̲s̲ ̲I̲n̲c̲l̲u̲d̲e̲d̲ ̲i̲n̲ ̲B̲u̲i̲l̲d̲
The Software Release and Build Identification is established
as a separate document and defines the units making
up an application software package increments (releases)
and what modules are contained in the subpackages.
Modules are numbered sequentially within the subpackages.
Subpackages are those defined in the Software Package
Design Specification.
A unit is made up of software modules from one or more
software subpackages implementing a partial functional
capability of an application software package.
The Software Release and Build Identification document
define package increments (releases) by what subpackages
or parts thereof, that are contained in increment and
what modules from the subpackage are contained in the
unit.
The Software Release and Build Identification document
is controlled by the software configuration managemet
and is structured identically to the configuration
log.
3.2.3 R̲e̲s̲o̲u̲r̲c̲e̲s̲ ̲R̲e̲q̲u̲i̲r̲e̲d̲ ̲b̲y̲ ̲B̲u̲i̲l̲d̲
The section defines the HW resources that have to be
available.
HW resources are described in section 4.1 and the different
configuration are referred as a, b, and c.
HW REQUIRED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BUILD 1 BUILD 2 BUILD 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CAMPS SYSTEM a a a
FUNCTIONS (CSF)
MESSAGE MANAGEMENT a a a
(MMS)
SYSTEM STATUS AND b/c b/c b/c
CONTROL (SSC)
TABLE MANAGEMENT a a a
(TMP)
INPUT/OUTPUT CONTROL b/c b/c b/c
(IOC)
STORAGE AND a a a
RETRIEVAL (SAR)
STATISTICS (STP) a a a
LOGGING (LOG) c c c
MESSAGE DISTRIBUTION a a a
(MDP)
TRAFFIC HANDLING a/b a/b a/b
TERMINAL PACKAGE b/c b/c b/c
TABLE 3.2.3-1
4̲ ̲ ̲R̲E̲S̲O̲U̲R̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
This describes the hardware and software resources
which are required during the performance of the CAMPS
software integration activities.
Furthermore, the resource utilization is estimated
in order to evaluate that sufficient reasources are
available during software integration.
4.1 H̲A̲R̲D̲W̲A̲R̲E̲ ̲F̲A̲C̲I̲L̲I̲T̲I̲E̲S̲
Three computer configurations/facilities will be established
to support software integration which are:
a) a CR80D Software Development System
b) a DSMT (CR80D) system, and
c) a typical CAMPS HW configuration
Each of these hardware configurations are presented
overleaf by a configuration drawing.
4.1.1 S̲W̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Below the software development system configuration
is presented.
4.1.2 D̲S̲M̲T̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Overleaf is presented the DSMT configuration.
Figure 4.1.2-1
Figure 4.1.2-2
Figure 4.1.2-3
Figure 4.1.2-4
Figure 4.1.2-5
4.1.3 T̲y̲p̲i̲c̲a̲l̲ ̲C̲A̲M̲P̲S̲ ̲H̲W̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Below is presented the configuration of a typical CAMPS
site.
4.2 S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
This section presents the system software and support
software which shall be available:
- DAMOS Kernel (Operating System)
- Standard I/O Software
- Standard SCC Software
- Storage & File Management
- Terminal Operating System (Software Development
Tools and Utilities).
4.3 R̲E̲S̲O̲U̲R̲C̲E̲ ̲U̲T̲I̲L̲I̲Z̲A̲T̲I̲O̲N̲
This section presents estimates of the software integration
effort, the manpower planned for the computer resources
available.
The total software integration effort is estimated
to 7.5 man-year and the integration elapse time is
planned to 0.5 year.
Three computer systems are available for software integration.
The software integration effort will be distributed
equally over the three computer systems.
Each software integration effort will in average involve
3 engineers.
Using the above figures, the following resource availability
can be calculated:
(̲S̲W̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲-̲t̲i̲m̲e̲)̲ ̲x̲ ̲(̲E̲n̲g̲i̲n̲e̲e̲r̲s̲ ̲p̲e̲r̲ ̲i̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲)̲ ̲1̲0̲0̲%̲
=
Computer utilization/(per computer)
0̲.̲5̲ ̲y̲e̲a̲r̲ ̲x̲ ̲3̲ ̲m̲a̲n̲ ̲x̲ ̲1̲0̲0̲%̲ = 6̲0̲%̲
2.5 man-years
5̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
As defined in section 2.3.1, the software shall be
tested to verify the functional capabilities of the
software package and to verify interfaces between the
software units which make up the software package.
One set of functional capabilities (external) are derived
from the system requirements while the other set is
derived internally from the design.
The external functional capabilities will be verified
against the following documents using the CAMPS Verification
Control Document CPS/VCD/001.
- CAMPS System Requirements Specification
CPS/210/SYS/0001
- CAMPS Interface Control Documents
CPS/ICD/001-008, as appropriate (Refer section
1.2).
The internal functional capabilities will be verified
from the following documents:
- CAMPS SW Interface Control Document
CPS/ICD/009
- CAMPS Software Package Specification
CPS/SDS/001-012, as appropriate (Refer section
1.2)
Interfaces will be verified against one or more of
the interface control documents CPS/ICD/001-009 (Refer
section 1.2).
