top - download
⟦2cc02724f⟧ Wang Wps File
Length: 28578 (0x6fa2)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN70.00«
Derivation
└─⟦89b9efcb1⟧ Bits:30006072 8" Wang WCS floppy, CR 0029A
└─ ⟦this⟧ »~ORPHAN70.00«
WangText
E…0a…E…02…E…06…D…0c…D…02…C…86…1
…02…
…02…
…02…
…02…CPS/TSP/002
…02…KNN/810609…02……02…#
SOFTWARE
INTEGRATION
PLAN
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ..................................
1.1 PURPOSE ...............................
1.2 PROJECT REFERENCES .....................
1.3 TERMS ..................................
2 SOFTWARE INTEGRATION MANAGEMENT ..........
2.1 MANAGEMENT ORGANIZATIONS ...............
2.1.1 Test Specification and Procdure
Work Package .......................
2.1.2 Test Execution Work Package ........
2.1.3 Software Test Control Board ........
2.2 INTEGRATION MASTER SCHEDULE ............
2.3 INTEGRATION SPECIFICATION AND POCEDURES
.............................
2.3.1 Integration Test Specifications ....
2.3.2 Integration Test Procedures ........
2.4 PRODUCT CONTROL ........................
2.4.1 Software Problem Reporting .........
2.4.2Software Status Accounting .........
2.4.3 Library Control ....................
…02…3 SOFTWARE INTEGRATION DEFINITION AND
STRUCTURE ................................
3.1 INTEGRATION APPROACH ...................
3.2 RELEASE PRODCTS/BUILDS IDENTIFICATION .
3.2.1 Functional Capabilities of Build ...
3.2.2 Software Units Included in Build ...
3.2.3 Sequence of Integration ............
…02…4 RESOURCE REQUIREMENTS ....................
4.1 HARDWAR FACILITIES ....................
4.2 INTERFACE/SUPPORT SOFTWARE .............
4.3 RESOURCE UTILIZATION ...................
5 SOFTWARE INTEGRATION REQUIREMENTS ........
6 SCHEDULE ................................. …86…1
…02… …02… …02… …02…
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 tea 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 willconduct 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 imosed 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 wihin a higher level of integration.
Integration testing will be conducted in two major
phases, which are software and system integration
testing respectively. Softwasre integration consists
of integrating application software units into major
sftware 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.
) 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 reuirements 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/ICD70001
- Supervisor Command and Procedures
CPS/230/ICD0002
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 Conection 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 CAMS 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 ETRIEVAL 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 sofware
components, which represent a significant partial functional
capability of a CAMPS application software package.
Software Unit:
For integration purposes, a software unit is defined
as a piece of software which has relatively few interfacesto
other pieces of software and which can be developed
by maximum one engineer.…86…1 …02… …02… …02… …02…
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 orgnization
- 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 aplication 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
him authorized software integraion manager. 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 contrl 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 (W 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 responsibilitie, 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̲ ̲W̲o̲r̲k̲ ̲P̲a̲c̲k̲a̲g̲e̲
This work package is responsible for generation of
test specifications and procedures required for integration
of application software units into application software
packages (refer section 3).
These specifications and procedureswill be established
per application software package.
In relation to the above work package, the software
manager or one by him authorized software integration
manager has the following responsibilities.
- establish work package activities prioities 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 poduction 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 chedule updated
weekly.
- keep SW manager continuously advised of activities
and any problems encountered which could adversely
affect the document production schedule.
- coordinate with technical supprt 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 is responsible for the integration
and verification proceure 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.
- defne 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 perfrmed under the direction
of the SW manager or by one of him authorized SW integration
manager. His responsibilities include the following:
- establish work package activity priorities and
schedules.
- perform day-to-day supervision of the workpackage.
- 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 procdures.
- 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 poposed
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 inclde 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 docment 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 Veification
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 al 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 librar 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 intgration 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 speciications 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
pase.
- 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
- Representaives 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 ation items will
be produced.
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̲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 iterfaces 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 subsetmust 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 beingtested.
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
ection 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 inimum 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 mdifications 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 structue 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 dirct
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 ile 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 shal 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 roblem 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
whic 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 problemreports 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 HandlingStandard 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 f 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 bya label (seq.
number). The software problem report file is controlled
by CAMPS software configuration management.
After a report has been logged, a proprosed solution
shall be generated. This can be performed by the originator
of the problem reort, 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 eet 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…86…1 …02… …02… …02… …02…
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 logicpath
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
anothr.
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 poblem 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 Sorce code comment
is incorrect. program
says DO I=1,5 while
comment says "loop
4 times."
8 IF statement too simple Not all all conditions
necessary for an
IF statement are
present.
IF A B should be
IF A B and B C.
9 Referenced wrong datavariable 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
daa
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 assignd.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
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̲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.41).
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 hange 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 Softwaresubsystems can be
identified at different levels, which are package level,
unit level, and module level. A software package consists
of one or more software units and a software unit consists
of one or more modules. Software items shall be identiied
as follows:
Package Id. Module Id.
3 characters 2 digits
XXX YY ZZ
Unit Id.
2 digits
Examples:
a) A software package with all its associated units
and modules has the following identification:
TEP identification used for SW
terinal package.
b) A software unit with all its associated modules
in the software terminal package has the following
identification.
unit is contained in the software
TEP03 package TEP and has the unit
no. 03.
c) A software module in the software terminal package
has the following identification:
module X is contained in unit
no.
TEPO117 01 and has the module no. 17.
The software library has a structure wich 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 are being unit tested
and not yet released for software integraion.
cat. 2: Software items which are being integrated to
software packages and not yet released for
system integration.
cat. 3: Software items which are being integrated to
a system and not yet released for formal acceptance.
cat. 4: Softwar items released for formal acceptance
at system level.
Category 2, 3, and 4 are all under CR configuration
management control.
Each software module shall be supplied information:
- version number ( 0 - 99)
- latest issue date
Version numbering is initiated when a module has been
released to category 2.
The version number is incremented each time the module
has been modified and released again.
The atest issue date is related to the date of the
latest released version number.
Each software unit shall contain the information as
above, but in addition contain the following information:
- modules contained in the unit (module id.)
- test bds (drives) established for the unit (test
bed id.)
The version number is incremented each time a unit
is released to category 2.
Test beds/drivers shall be identified as follows:
Test driver Unit id.
indicator 2 digits)
T/XXX ZZ
SW
package id.
(3 characters)
Software packages shall contain the same information
as above with the following modifications.
The version number is incremented each tim a package
is released to category 3.
The software package shall contain a reference to all
software units contained in the package.
All software units and packages shall contain the status
they are in i.e., which category 2, 3 or 4 they belongin…86…1
…02… …02… …02… …02…
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 ntegrated, 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
s 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 testedexhaustively 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 integrtion 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 functinal 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
possbility for concurrent testing.
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 f 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 wll 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 sof
