top - download
⟦66baa675d⟧ Wang Wps File
Length: 20162 (0x4ec2)
Types: Wang Wps File
Notes: CPS/PLN/011
Names: »2188A «
Derivation
└─⟦6d69be3b6⟧ Bits:30006113 8" Wang WCS floppy, CR 0178A
└─ ⟦this⟧ »2188A «
WangText
…05……00……00……00……00…<…0a……00……00…<…0b…< &…00…&…06…%…09…%…0c…%…0d…%…0f…%…00…%…01…% %…86…1 …02… …02… …02…
…02…CPS/PLN/011
…02…LRS/820526…02……02…#
CAMPS SW CONFIGURATION MANAGEMENT PLAN
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 Introduction....................................
5
1.2 Abbreviations ..............................
5
2 Organization and Responsibilities ..............
5
3 Configuration Identification of SW
and Documentation ..............................
6
3.1 Configuration Identification Conventions ...
6
3.1.1 SW Components ..........................
6
3.1.2 SW Components/Documentation
Relationship........................
8
3.2 Baselines ..................................
10
3.2.1 Requirement and Design Baselines .......
10
3.2.2 Development Baselines ..................
12
3.2.2.1 Code and Unit Test .................
12
3.2.2.1.1 Products .......................
12
3.2.2.1.2 Review and Approval Events .....
14
3.2.2.1.3 Establishing the Baseline ......
14
3.2.2.2 Package Integration and Test .......
14
3.2.2.2.1 Products/Packages ..............
14
3.2.2.2.2 Audit and Approval Events ......
16
3.2.2.2.3 Establishing the Baseline ......
16
3.2.2.3 System Integration and Test ........
16
3.2.2.3.1 Products/Builds ................
16
3.2.2.3.2 Audit and Approval Events .....
16
3.2.2.3.3 Establishing the Baseline ......
16
3.3 Additional SW Controlled by SCM ............
16
3.3.1 Firmware and Documentation ............
17
3.3.2 System SW CR80 and Documentation .......
17
3.3.3 M + D SW and Documentation .............
19
4 Software Configuration Control .................
19
4.1 Control Procedures .........................
19
4.1.1 SW Control Library ....................
19
4.1.2 SW Change Process .....................
24
4.1.2.1 Problem Reporting ..................
24
4.1.2.2 Software Configuration Control Board
24
4.1.2.3 Implementation .....................
27
4.1.2.4 Steps for the Change Process. ......
27
4.1.2.5 Problem Categorization .............
27
4.1.2.5.1 Software Development............
27
4.1.2.5.1 System I+T .....................
33
4.2 Back-up and Release ........................
33
4.2.1 Development Library ....................
33
4.2.2 Software Control Library ...............
33
5 Status Accounting ..............................
36
6 Appendices......................................
38
A. Package Description .........................
39
B. Builds ......................................
40
1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The purpose of this plan is to define the specific
procedures and actions which are or shall be implemented
to maintain software configuration control within the
CAMPS software project.
The plan does not preclude any of the requirements
laid down in the System Division Configuration Plan,
SD/PLN/006. This plan merely establishes a more specific
and detailed information on CAMPS software configuration
management procedures.
The plan defines the organizational responsibilities,
software configuration identification and control and
status accounting.
1.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
Abbreviations used are as follows:
SCM Software Configuration Manager
SCL Software Configuration Library
SCCB Software Configuration Control Board
SCC Software Configuration Control
QA Quality Assurance
2 O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
Software Configuration Management is the responsibility
of the Software Configuration Manager. The SCM reports
to the Software Manager and provides services such
as: identification, filing, distribution, status accounting
etc.
SCM personnel, who report to the SCM provide the means
to implement Software Configuration Control. Specific
responsibilities include the following:
a) identification of configuration control components
i.e. SW components and documents.
b) change control procedures.
c) maintenance of configuration control data for status
accounting.
3 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲W̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
3.1 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
3.1.1 S̲W̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The SW can be identified at different levels which
are package level, subpackage level and module level.
A package consists of one or more subpackages. A subpackage
consists of one or more modules.
Figure 1 overleaf shows the different levels and identification
including release numbering. Release numbering is initiated
when a unit has been released to Software Control Library
and is incremented each time a change has been implemented
and released to SCL.
S̲W̲ ̲C̲O̲M̲P̲O̲N̲E̲N̲T̲ ̲L̲E̲V̲E̲L̲S̲ ̲A̲N̲D̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
L̲E̲V̲E̲L̲ I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
SW MODULE: CPS TEP 07 AAAAAA - 06
RELEASE
MODULE ID
SUBPACKAGE ID
PACKAGE ID
PROJECT ID
SW SUBPACKAGE: CPS THP 02 - 07
RELEASE
SUBPACKAGE ID
PACKAGE ID
PROJECT ID
SW PACKAGE CPS STP - 01
RELEASE
PACKAGE ID
PROJECT ID
SW SYSTEM CPS - 01
RELEASE
PROJECT ID
Figure 1.
3.1.2 S̲W̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲/̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
Figure 2 shows the relationship between SW components
and documentation at the different levels of the product.
S̲W̲ ̲P̲R̲O̲D̲U̲C̲T̲/̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
R̲E̲L̲A̲T̲I̲O̲N̲S̲H̲I̲P̲
SW PRODUCT LEVEL SW SPECIFICATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PACKAGE
CPS.AAA CPS/SDS/NNN
SUBPACKAGE
CPS.AAA.NN CPS/SDS/NNN
SECTION 4.2.X
MODULE
CPS.AAA.NN.NAME CPS/SDS/NNN
SECTION 4.2.X.Y.
Figure 2.
3.2 B̲a̲s̲e̲l̲i̲n̲e̲s̲
3.2.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲D̲e̲s̲i̲g̲n̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
Figure 3 shows the baselines for requirement and design
and the documents applicable for these.
Figure 3.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲s̲
Figure 4 shows the baselines for code and unit test,
package integration and test and system integration
and test.
3.2.2.1 C̲o̲d̲e̲ ̲a̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲
3.2.2.1.1 P̲r̲o̲d̲u̲c̲t̲s̲
CPS/CSF-CPS/UDF/01X
CPS/MMS-CPS/UDF/02X
CPS/TMP-CPS/UDF/03X
CPS/IOC-CPS/UDF/04X
CPS/SSC-CPS/UDF/05X
CPS/SAR-CPS/UDF/06X
CPS/STP-CPS/UDF/07X
CPS/LOG-CPS/UDF/08X
CPS/THP-CPS/UDF/09X
CPS/MDP-CPS/UDF/10X
CPS/SUP-CPS/UDF/11X
CPS/SPR-CPS/UDF/12X
CPS/MDC-CPS/UDF/13X
CPS/MSO-CPS/UDF/14X
CPS/VUP-CPS/UDF/15X
CPS/PRT-CPS/UDF/16X
Figure 4.
3.2.2.1.2 R̲e̲v̲i̲e̲w̲ ̲a̲n̲d̲ ̲A̲p̲p̲r̲o̲v̲a̲l̲ ̲E̲v̲e̲n̲t̲s̲
Before package integration of units a Release Review
will be held to ensure that UDF's are complete, that
the units meet their specs., and that the units have
been exhaustively tested.
Units shall be approved by the Work Package Manager,
Software Manager and Quality Assurance. The form COMPLETION
CERTIFICATE will be used for this purpose. See figure
4A.
3.2.2.1.3 E̲s̲t̲a̲b̲l̲i̲s̲h̲i̲n̲g̲ ̲t̲h̲e̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
After approval of the units these make up the baseline
from which package integration and test are initiated.
3.2.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̲
3.2.2.2.1 P̲r̲o̲d̲u̲c̲t̲s̲/̲P̲a̲c̲k̲a̲g̲e̲s̲
P̲a̲c̲k̲a̲g̲e̲ ̲I̲D̲ D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
CPS/CSF CAMPS System Functions
CPS/MMS Message Management
CPS/TMP Table Management
CPS/IOC Input/Output Control
CPS/SSC System Status and Control
CPS/SAR Storage and Retrieval
CPS/STP Statistics
CPS/LOG Logging
CPS/THP Traffic Handling
CPS/MDP Message Distribution
CPS/SUP Supervisor VDU
CPS/SPR Supervisor Printer
CPS/MDC MDCO VDU
CPS/MSO MSO VDU
CPS/VUP User VDU
CPS/PRT Printer
See appendix A for further description of the packages.
Figure 4A.
3.2.2.2.2 A̲u̲d̲i̲t̲ ̲a̲n̲d̲ ̲A̲p̲p̲r̲o̲v̲a̲l̲ ̲E̲v̲e̲n̲t̲s̲
A package test report will be produced by the work
package manager. It will be reviewed or audited and
is subject to approval by Software Manager and Quality
Assurance. COMPLETION CERTIFICATE, Figure 4A, will
be used for approval.
3.2.2.2.3 E̲s̲t̲a̲b̲l̲i̲s̲h̲i̲n̲g̲ ̲t̲h̲e̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
After approval of the report the system integration
and test will be initiated.
3.2.2.3 S̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲
3.2.2.3.1 P̲r̲o̲d̲u̲c̲t̲s̲/̲B̲u̲i̲l̲d̲s̲
Build 1
Build 2
Build 3 - CAMPS SYSTEM
See appendix B for further description of builds.
3.2.2.3.2 A̲u̲d̲i̲t̲ ̲a̲n̲d̲ ̲A̲p̲p̲r̲o̲v̲a̲l̲ ̲E̲v̲e̲n̲t̲s̲ ̲
An integration test report will be produced by the
System Engineering Manager. It will be audited and
is subject to approval by Quality Assurance and Software
Manager. COMPLETION CERTIFICATE, figure 4A, will be
used for approval.
3.2.2.3.3 E̲s̲t̲a̲b̲l̲i̲s̲h̲i̲n̲g̲ ̲t̲h̲e̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
After approval of the system, system acceptance will
be initiated.
3.3 A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲S̲W̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲d̲ ̲b̲y̲ ̲S̲C̲M̲
3.3.1 F̲i̲r̲m̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲
STI (PSP)
LTUX-S System Firmware CSD-MIC/220/PSP/0012, issue
2
TDX Controller CSD-MIC/220/PSP/1000, issue
2
CAMPS Watchdog CSD-MIC/0420/PSP/1010, issue
1
3.3.2 S̲y̲s̲t̲e̲m̲ ̲S̲W̲ ̲C̲R̲8̲0̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
DAMOS Process Manager and Dispatcher
CSS/2000/PSP/0018
DAMOS Page Manager
CSS/2100/PSP/0019
DAMOS Process Communication
CSS/2200/PSP/0020
DAMOS Directory Functions
CSS/2300/PSP/0021
DAMOS PU Management
CSS/2400/PSP/0022
DAMOS Basic Synchronization
CSS/2600/PSP/0023
DAMOS Device Management
CSS/2900/PSP/0024
DAMOS STI HANDLER
CSS/3100/PSP/0025
DAMOS Transfer Module
CSS/3200/PSP/0026
DAMOS Error Processor
CSS/3300/PSP/0027
DAMOS Initialization
CSS/3400/PSP/0028
DAMOS Boot Loader
CSS/3500/PSP/0029
DAMOS Log Module
CSS/3600/PSP/0030
DAMOS Utility Procedures
CSS/3100/PSP/0031
DAMOS Coroutine Monitor
CSS/3900/PSP/0033
DAMOS Real Time Clock Module
CSS/4000/PSP/0034
DAMOS Input/Output System
CSS/4200/PSP/0035
DAMOS File Management System
CSS/3400/PSP/0036
DAMOS Terminal Management System
CSS/4400/PSP/0037
DAMOS Resource Management
CSS/2050/PSP/0045
DAMOS DMA Handler
CSS/3210/PSP/0055
DAMOS Basic Transport Service
CSS/3250/PSP/0056
DAMOS Root Operating System
CSS/3450/PSP/0057
DAMOS OC Handler
CSS/4810/PSP/0058
DAMOS LP Handler
CSS/4820/PSP/0059
DAMOS Disk Handler
CSS/4600/PSP/0039
DAMOS LTU Handler
CSS/4800/PSP/0041
DAMOS PU Service Module
CSS/4100/PSP/0042
DAMOS Terminal Operating System
CSS/703/PSP/0052
3.3.3 M̲ ̲+̲ ̲D̲ ̲S̲W̲ ̲a̲n̲d̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Maintenance and Diagnostic (M+D)
4. S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.1 C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.1 S̲W̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲i̲b̲r̲a̲r̲y̲
During the development process units are incorporated
to the Software Control Library when properly tested
by programmer and examined for completeness by the
Software Configuration Control Board (SCCB). If units
are disapproved an Action Item will be filled in by
SCM and signed by Software Manager. Unit and Action
Item will be returned to the originator. Action Items
will be logged by SCM. See Fig. 5 and 6. Figure 7 shows
Migration of a SW item into the libraries.
Specific files which will be incorporated into and
released from the SCL are as follows:
M̲o̲d̲u̲l̲e̲ ̲f̲i̲l̲e̲s̲
"Module name".S Module source code
"Module name".JC" Compile job file
"Module name".PC Printout from compiler
"Module name".L Link module(relocatable object)
"Module name".I Procedure import declaration
"Module name".TC Test command file
S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲f̲i̲l̲e̲s̲
"Subpackage ID".JL Link job file
"Subpackage ID".PL Printout from linker
"Subpackage ID".T Object subpackage in test-
programs
"Subpackage ID".D Subpackage directory
"Subpackage ID".TS Source subpackage for test
"Subpackage ID"PREFIX.S Subpackage PREFIX
"Subpackage ID" DATA.S Subpackage DATA
P̲a̲c̲k̲a̲g̲e̲ ̲f̲i̲l̲e̲s̲
"Package ID".D Package directory
"Package ID"PREFIX.S Package PREFIX
"Package ID"DATA.S Package DATA
S̲y̲s̲t̲e̲m̲ ̲f̲i̲l̲e̲s̲
"System ID".D System directory
Figure 5.
Figure 6.
Figure 7.
4.1.2 S̲W̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
4.1.2.1 P̲r̲o̲b̲l̲e̲m̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
Software problem reports (see figure 8) shall be generated
as a result of a suspected or existing discrepency,
deficiency or error in a software component and/or
its associated documentation under SCC.
The problem reports are received by SCM personnel and
logged in a separate file, each report identified by
a sequence number to ensure proper status accounting.
See fig. 9.
When a problem report has been logged a proposed solution
shall be generated. This can be done by the originator
of the problem report, the software work package manager
and/or CAMPS system engineering.
4.1.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲o̲a̲r̲d̲
The problem report is processed by SCCB. The SCCB is
composed of representatives from software management,
QA, system engineering, SCM and others who may be called
upon when necessary. The chairman is the software manager.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲o̲a̲r̲d̲
SKEMA
Figure 8.
Figure 9
The SCCB approves/disapproves the problem report and
the proposed solution. The board will meet weekly or
as appropriate to process problem reports/solutions.
If changes/solutions have been approved a change order
will be generated and logged. The forms shown in figure
10 and 11 will be used. If further specification or
another solution than proposed is necessary the form
PROPOSED SOLUTION figure 12 shall be used.
4.1.2.3 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The software manager assigns implementation of the
change to the programmer responsible for the unit affected
by the change.
At completion of code, test and preparation of changes
to affected documentation, changed unit and documentation
is submitted to SCCB to be examined for consistency
and satisfaction of all requirements. When approved
the changed unit is incorporated in the software control
library.
4.1.2.4 S̲t̲e̲p̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲.̲ ̲
In figure 13 is shown the procedural steps from problem
report generation until the issue of an authorized
change order.
4.1.2.5 P̲r̲o̲b̲l̲e̲m̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲z̲a̲t̲i̲o̲n̲.̲
In order to support problem reporting qualitatively
as well as quantitatively, problems will be categorized.
The category will be found in the problem report and
summarized for Software Development and System I+T.
4.1.2.5.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲
The categories from 1-12 will be used. For explanation
see CPS/TSP/002, pages 21 and 22.
Example of summary see figure 14.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
S̲U̲M̲M̲A̲R̲Y̲ ̲C̲H̲A̲N̲G̲E̲ ̲C̲A̲T̲E̲G̲O̲R̲Y̲
S̲W̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲
SW PACKAGE ID:
DESIGN DOC ID:
Figure 14.
4.1.2.5.1 S̲y̲s̲t̲e̲m̲ ̲I̲+̲T̲
The categories from 1-3 will be used. For explanation
see CPS/TSP/005, page 25.
Example of summary see figure 15.
4.2 B̲a̲c̲k̲-̲u̲p̲ ̲a̲n̲d̲ ̲R̲e̲l̲e̲a̲s̲e̲
4.2.1 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲L̲i̲b̲r̲a̲r̲y̲
During development of SW, back-up will be taken every
week to assure no loss of developed SW. A min. of 2
generations/discs will be kept for each development
disc.
1 copy will be kept in Ballerup in a safe cabinet and
1 copy in Herlev in the magnetic storage. The copies
will be interchanged every week.
Release of SW from the back-up will take place if failure
has occurred in use of development group's work disc.
Log of back-up will be kept for the last two weeks.
4.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲i̲b̲r̲a̲r̲y̲
When units are tested and ready for configuration control
they will be copied to a 'tested units' disc. When
approved by SCCB they will be copied to a
'workmaster' disc containing all releases of units.
Furhtermore a 'master disc' containing the latest
release of each unit will be kept.
Two security copies of each of the three discs will
be taken. Copying will take place every week or as
appropriate, i.e. two generations will be kept. The
3 masters and one copy of each will be kept in Ballerup
in a safe cabinet. The 3 further copies will be kept
in Herlev in the magnetic storage (-belt and braces).
The copies in Ballerup and Herlev will be interchanged.
For logical protection of the discs, passwords and
read/write capabilities will be used. See Figure 16.
S̲U̲M̲M̲A̲R̲Y̲ ̲C̲H̲A̲N̲G̲E̲ ̲C̲A̲T̲E̲G̲O̲R̲Y̲
S̲Y̲S̲T̲E̲M̲ ̲I̲ ̲+̲ ̲T̲
SW PACKAGE ID:
DESIGN DOC ID:
Figure 15.
B̲a̲c̲k̲-̲u̲p̲
S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲i̲b̲r̲a̲r̲y̲
̲ ̲ ̲B̲A̲L̲L̲E̲R̲U̲P̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ H̲E̲R̲L̲E̲V̲ ̲ ̲ ̲ ̲ ̲
Figure 16.
Release of units from the master will only take place
when a change order has been issued or integration
and test is to be performed.
Logs and listings for back-up and release will be kept.
For log see Figure 17.
5 S̲t̲a̲t̲u̲s̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
To ensure proper status accounting logs and reports
of the status of documentation and SW components controlled
by SCM will be kept. This include the following:
- Configuration Logs
- Problem Report Log
- Action Item Log
- Change Order Log
- BACK-UP/RELEASE Log
- SUMMARY CHANGE CATEGORY for
SW Development and System I+T.
SCL BACK-UP AND RELEASE
Figure 17.
APPENDICES.
APPENDIX A
APPENDIX B
(will be appended later)
