The tools and methods used for the configuration management of the artifacts (including software and documentation) associated with the Guidance and Control Software (GCS) project are described. The GCS project is part of a software error studies research program. Three implementations of GCS are being produced in order to study the fundamental characteristics of the software failure process. The Code Management System (CMS) is used to track and retrieve versions of the documentation and software. Application of the CMS for this project is described and the numbering scheme is delineated for the versions of the project artifacts

Withers, B. Edward

English

NASA Technical Reports Server

NASA Contractor Report 182044
GCS CONFIGURATION MANAGEMENT PLAN
B. Edward Withers
RESEARCH TRIANGLE INSTITUTE
Research Triangle Park, North Carolina
Contract NAS1-17964
May 1990
(NASA-CR-IBZO_) GSC CPNFIGURATInN
MANAGEMENT PLAN (Research Triangle Inst.)
CSCL OQB
15 p
G3/61
N90-255_7
N/ A
National Aeronautics and
Space Administration
Langley Research Center
Hampton, Virginia 23665-5225
https://ntrs.nasa.gov/search.jsp?R=19900016271 2020-03-19T22:37:41+00:00Z
J
GCS CONFIGURATION
MANAGEMENT PLAN
Guidance and Control Software
RTCA DO-178A Document Number 5A
Release number: 1.0
Prepared for:
NASA-Langley Research Center under contract
NAS1-17964; Task Assignment No. 8.
Prepared by:
Author(s): B. Edward Withers
Reviewer(s): RTI- Janet R. Dunham
Stephen E. Duncan
Anita M. Shagnea
NASA - George Finelli
Software R & D Department
Center for Digital Systems Research
Research Triangle Institute
Research Triangle Parle, North Carolina 27709

Preface
The GCS Configuration Management Plan is document # 5A in a series
of documents which fulfill the Radio Technical Commission for Aeronautics
RTCA/DO-178A guidelines, "Software Considerations in Airborne Systems
and Equipment Certification". These documents were prepared under con-
tract with NASA-Langley Research Center.
This project consists of two complementary goals. First, to develop soft-
ware for use in the Research Triangle Institute (RTI) software error studies
research program sponsored by NASA-Langley Research Center [1]. Sec-
ond, to use and assess the RTCA/DO-178A guidelines for the Federal Avi-
ation Administration (FAA). The two goals are complementary in that the
use of the structured DO-178A guidelines in the development of the software
will ensure that the test specimens of software have been developed accord-
ing to the best standards for critical software. The error studies research
analyses will then be conducted using high quality software specimens. The
implementations will be subjected to two different software testing environ-
ments: verification of each implementation according to RTCA/DO-178A
guidelines and replicated random testing in an n-version configuration. This
research effort involves the gathering of product and process data from ev-
ery phase of software development for later analysis. More information on
the goals of the Guidance and Control Software (GCS) project are available
in the GCS Plan for Software Aspects of Certification (document #14).
The series consists of the following documents:
- GCS Configuration Index Document no. 1
GCS Development Specification Document no. 5
- GCS Design Descriptions One .for each software implementation. Doc-
ument no. 3
- GCS Programmer's Manual Document no. d, includes Software De-
sign Standards, document no. 15.
- GCS Configuration Management Plan Document no. 5A
- Software Quality Assurance Plan for GCS Document no. 5B
-i-
GCS SourceListings One for each $oftware implementation. Docu-
ment no. 6
GCS Source Code One for each software implementation. Not avail-
able on hardcopy. Document no. 7
GCS Executable Object Code One for each _oftware implementation.
Not available on hardcopy. Document no. 8
GCS Support/Development System Configuration Document no. 9
GCS Accomplishment Summary Document no. 10
Software Verification Plan for GCS Document no. 11
Software Requirements Review Description for GCS Document no.
11A
GCS System Requirements Document no. 13
GCS Plan for Software Aspects of Certification Document no. 14
-ii-
Contents
Preface i
1 Management Methods 1
2 Documents Under Configuration Management 2
3 Configuration Procedures 5
4 Version Numbering Scheme 5
A Representatives .8
List of Tables
1 Organization and Authorization for Managed Documents 3
1 Organization and Authorization for Managed Documents (cont.) 4
-iii-

1 Management Methods
This report describes the methods and tools used for the configuration
management of the Guidance and Control Software experiment ( GCS )
project-related documents. The use of configuration management tech-
niques is intended to reduce confusion over multiple versions of the docu-
ments and to increase traceability of changes throughout the lifetime of the
various documents. Configuration management for this project will consist
of defining and using an orderly, structured method of storing, recalling,
and modifying any document (including software) that is produced. By
using a configuration management scheme, compliance with the require-
ments outlined in the RTCA document DO-178A is insured. Configuration
management also has the advantage of encouraging a uniform method of
access to all documents.
To reduce the time, effort, and cost of setting up and using a config-
uration management scheme, tools that are already available at RTI and
AIRLAB will be used. Also, the number of people with direct access to
these documents will be kept to a minimum and the procedure for updating
documents will be kept as simple as possible.
The most important configuration tool will be the Code Management
System (CMS) provided by Digital Equipment Corporation (DEC). CMS
provides a method of tracking and retrieving versions of documents. CMS
uses "libraries" that contain all versions of the documents. The operations
allowed within CMS are as follows:
Fetch A copy of the file is placed in the current directory, but no changes
to the file within the library are made.
Reserve A copy of the file is placed in the current directory. The file is
marked within the library so that no else may make changes to it
during this time. The file will later be returned to the library and
any changes will be made to the library copy.
Replace A file that has been reserved may be replaced and in doing so,
any changes to the file are put into the library for later use.
Unreserve If a file has been reserved, but no changes were made, the file
may be unreserved. This will simply remove the restriction on that
file within the library, so the original operation becomesvery similar
to a fetch.
There will be six CMS libraries to hold the documents. There will
be one library for documents produced by the management team (Doc
Library) and controlled by the on-site Software Quality Assurance repre-
sentative (SQA Rap.) and the Configuration Manager (Cfg. Mgr.). There
will be one library for the GCS specification (Spec Library) and its for-
mal modifications that will be controlled by the SQA Rap. There will be
three libraries for the application programmers (Prog Libraries 1-3). Each
of these libraries will contain all documents produced or modified by the
programmers including their source code. The programmer libraries will
be controlled by the SQA Rep. and Cfg. Mgr. Last, there will be a library
(Test Library) that will contain files of test cases used and test logs gener-
ated during the Verification procedure. 1 This library will be controlled by
the on-site SQA representative. Programmers should have private libraries
to keep their code in during development and module testing. This will
allow old versions/fixes to be restored if necessary.
Because of the form of documentation used for some documents, (e.g.
the design description will be in teamwork 2 format and the problem re-
ports are filled out by hand on paper), these documents will be configured
using hard copies only. Other documents such as the object code can be
reproduced from the source code, thus do not need to be placed under
configuration management directly.
2 Documents Under Configuration
Management
Table 1 below contains a list of the documents under configuration manage-
ment, which libraries contain them, a list of people authorized to request
copies of the documents, and a list of people authorized to update the
library.
1This explanation may be expanded and more libraries may be added depending on
the type of tools used for verification.
2Teamwork is a registered trademark of Cadre Technologies Inc.
-2-
Table 1: Organization and Authorization for ManagedDocuments
Document
Configuration Index
(Doc #1)
GCS Specification
(Doc. #2)
Specification
Modifications
(part of Doc. #2)
Design Description
(Doc. #3)
Programmers' Manual
(Doc. #4)
Library
Doc
Spec
Spec
Hard Copy
Doc
Authorized
Requesters
Mgmt. Team
Mgmt. Team
Mgint. Team
Testers
Mgmt. Team
Authorized
Controllers
SQA Rep.
SQA Rep.
SQA Rep.
SQA Rep.
Cfg. Mgr.
SQA Rep.
Cfg. Mgr.
Programmer Doc Mgmt. Team SQA Rep.
Instructions Cfg. Mgr.
Doc Mgmt. Team SQA Rep.
Cfg. Mgr.
SQA Pep.
Testers
Testers
Cfg. Mgr.
SQA Pep.
Cfg. Mgr.
SQA Pep.
SQA Pep.
(part of Doc. #4)
Configuration
Management. Plan
(Doc. #5A)
SQA Plan
(Doc. #58)
Programmers'
Source Listing/Code
(Doc. #6 and #7)
Object Code
(Do c. #8)
Support/Development
System Configuration
(Doc. #9)
Accomplishment
Summary
(Doe. #10)
Doe
Prog
(1, 2, or 3)
Reproduced
from Doc. #7
Doc Mgmt. Team
Doc Mgmt. Team SQA Rep.
-3-
Table 1: Organization and Authorization for Managed Documents(cont.)
Document Library Authorized Authorized
Requesters Controllers
Verification/ Doc Mgmt. Team NASA Rep.
Validation Plan Testers Cfg. Mgr.
(Doc. #11)
Test Cases/Runs Test Testers NASA Rep.
(part of Doc. #11) Cfg. Mgr.
Design Standards Doc Mgmt. Team SQA Rep.
(Doc. #12, included
in Doc. #4)
System Requirements Doc Mgmt. Team SQA Rep.
(Doc. #13)
Certification Doc Mgmt. Team SQA Rep.
Document Cfg. Mgr.
(Doe. #14)
Problem Reports Hard Copy Testers SQA Rep.
-4-
3 Configuration Procedures
All documents under configuration control will be located in their libraries,
or in binders held by the controller, and after they are put under con-
trol, only the authorized controllers may update the library by reserving,
replacing, adding, or deleting elements within the library. EXTREME
PRUDENCE should be used when deleting elements from libraries. All
authorized requesters should be made aware of the locations of the libraries,
and will be allowed to fetch files from these libraries. By fetching files, no
changes are made to the library, thus the integrity of the experiment is
maintained. VMS access control allows CMS libraries to be set up so that
some people may fetch files from a given library without being able to re-
serve, replace, add, or delete files, In addition, backups are made every
twelve hours of files that have been modified or changed, and once each
month, all files are backed up onto tape media.
Anyone desiring access to files under configuration control should ask
one of the authorized requesters for the files they need. If no changes are
anticipated, the requester may fetch the files. If changes are anticipated,
the requester should send an electronic request to the controller who will
then reserve the files and send them to the person asking for them.
It is the job of the requester and the controller to insure that all trans-
actions in the CMS library are documented using the built-in commenting
ability of CMS. The requester and the controller have the right to refuse
access to files or to require further documented justification for file access.
If the controller sees fit to do so, each document request may be placed into
the libraries for later reference.
4 Version Numbering Scheme
When each document is placed under configuration management, it will be
considered version 1.0 of that document. After that time, any modifications
to the document will increment the counter to 1.1, 1.2, ... For documents,
such as the design description, which require hard copy output, only the
sheets that have been modified should be printed and configured. At major
milestones, the version number will be incremented to 2.0, 3.0, ... and hard
copy documentswill be completely re-printed. Eachversionof a document
u las _'will be organized as a CMS c s for ease in later retrieval of versions. For
documents that require separate versions for each programmer (e.g. design
documents, source code, etc. ) the programmer's identification name will
be added to the beginning of the version number. For example, the first
revision of Jupiter's design document would be: Jupiterl.1. Following is
a list of documents under configuration management and a milestone that
will determine when they are put under configuration control:
Configuration Index (Doc #1) After SQA approval.
GCS Specification (Doc #2) When Venus and Jupiter start Prototypes.
Specification Modifications After SQA approval.
Design Description (Doc #3) After Design Review.
Programmers' Manual (Doc #4) After SQA approval.
Programmer Instructions After SQA approval.
Configuration Management Plan (Doc #SA) After SQA approval.
Software Quality Assurance Plan (Doc #5B) After Mgmt. Team ap-
proval.
Programmers' Source Listing/Code (Doc #6/#7) At first clean com-
pile.
Object Code (Doc #8) At first dean compile.
System Configuration (Doc #9) After SQA approval.
Accomplishment Summary (Doc #10) End of project after SQA ap-
proval.
Verification / Validation Plan (Doc #11) After SQA approval.
Test Cases / Runs As test case is generated.
Design Standards (Doc #12) After SQA approval.
-6-
System Requirements (Doc #13) After SQA approval.
Certification Document (Doc #14) After SQA approval.
Problem Reports When a problem is first reported, a problem report
will becompletedaccordingto the procedureslisted in the SQAPlan.
For example, the major milestonesfor changingversion numbersof the
code will be:
• Clean compile (1.0),
• Code review (2.0),
• End of Module Testing (3.0),
• End of White Box Sub-Frame Testing (W3.x),
• End of Black Box Sub-Frame Testing (B3.x),
• End of Sub-Frame Testing (4.0),
• End of Frame Testing (5.0), and
• End of System Testing (6.0).
-7-
A Representatives
Following are the abbreviations used in this document along with the people
they represent:
Cfg. Mgr. Configuration Manager - B. Edward Withers
Doc. DO-178A Document
Mgmt. Team Management Team - Leslie Dent, Stephen Duncan, Janet
Dunham, Douglas S. Lowman, Anita Shagnea, and B. Edward With-
ers.
NASA Rep. NASA Representative- Kelly Hayhurst.
SQA Rep. On-site Software Quality Assurance Representative - Stephen
Duncan
Testers GCS Testers - Leslie Dent, Anita Shagnea, and Charlotte Scheper
User GCS User- B. Edward Withers
Requester Individual responsible for documenting any changes made to
documents and who may fetch a copy for working purposes or request
that a copy be reserved for updating.
Controller Individual responsible for assuring that all changes have been
documented, and who has the power to reserve and replace docu-
ments. This individual may refuse to allow changes to propogate to
the official versions until appropriate documentation has been com-
pleted.
References
[1] George B. Finelli. Results of software error-data experiments. In
AIAA//AHS//ASEE Aircraft Design, Systems and Operation_ Con]er-
ence, Atlanta, GA, September 1988.
Report Documentation Page
1. Report No.
NASA CR- 182044
2. Government Accession No.
4. Title and Subtitle
GCS Configuration Management Plan
7. Author(s)
B. Edward Withers
9. Performing Organization Name and Address
Research Triangle Institute
P.O. Box 12194
Research Triangle Park, NC 27709-2194
12. Sponsoring Agency Name and Address
National Aeronautics and
Langley Research Center
Hampton, VA 23665-5225
Space Administration
3, Recipient's Catalog No.
5. Report Date
May 1990
6, Performing Organization Code
8. Performing Organization Report No.
10. Work Unit No,
505-66-21-01
11. Contract or Grant No.
NASI-17964
13. Type of Report and Period Covered
Contractor Report
14. Sponsoring Agency Code
15, Supplementary Notes
Technical Monitor:
Task 8 Report
George B. Finelli, Langley Research Center
16. Abstract
This document describes the tools and methods used for the configuration management of the
artifacts (including software and documentation) associated with the Guidance and Control Software
(GCS) project, The GCS project is part of a software error studies research program conducted by the
Research Triangle Institute and the NASA Langley Research Center. For this project, three
implementations of GCS are being produced according to the Radio Technical Commission for
Aeronautics RTCA/DO- 178A guidelines, "Software Considerations in Airbome Systems and
Equipment Certification" in order to study the fundamental characteristics of the software failure
process. The Code Management System (CMS) provided by Digital Equipment Corporation is used to
track and retrieve versions of the documentation and software. This document describes the
application of the CMS for this proJectand delineates the numbering scheme for the versions of the
project artifacts. This document fulfills the requirements for document #5B in the RTCA/DO-178A
guidelines.
17. Key Words (Suggested by Author(s))
Configuration Management
Guidance and Control Software
Configuration Control
-19. Security Classif+ (of this report)
Unclassified
(ccs)
18. Distribution Statement
Unclassified-Unlimited
Subject Category 61
20. Security Classifl (of this page)
Unclassified
21. No+ of pages
13
22+ Price
A0 3
NASA FORM 1626 OCT 86


GSC configuration management plan

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server