Software Configuration Management Plan

Overview

The objective of Software Configuration Management to establish and manage the developmental configuration and control procedures for the CSCIs.

NOTE: This plan is a functional part of the 'Software Development Plan'.
A separate SCMP has been produced on the grounds of establishing a common method of identifying, controlling and recording the software baselines and developmental configuration for each CSCI.

1. SCOPE

1.1 Identification.

This 'Software Configuration Management Plan' establishes the plan for the software configuration management activities that shall be performed during the CSCI development phases of the specific project.

1.1 Purpose.

The purpose of this document is to identify and define the overall methods and procedures necessary to perform software configuration management for the stated project.
The purpose of the CSCI being developed shall be defined in the specific CSCI 'Software Development Plan' and will be identified in the SDP (overall).

1.3 Document overview.

This document comprises of the following sections:

• Section 1 identifies, describes the purpose, summarizes the contents and states the relationship to other plans;
• Section 2 lists the documents referenced;
• Section 3 outlines the resources and organizational structure for performing software configuration management;
• Section 4 defines in detail the software configuration management activities;
• Section 5 not applicable;
• Section 6 provides notes and lists the definitions, abbreviations used.

1.4 Relationship to other plans.

The SCMP contains the common activities that must be performed by all suppliers of software being developed for the project.
The SCMP forms a part of the SDP prepared for each CSCI or part-CSCI being developed for the specific system.

2. REFERENCED DOCUMENTS

2.1 Project documents.

List by identifier and title all the pertinent project documents, i.e., Systems Engineering Management Plan, Configuration Management Plan, Technical Documentation Standard, Software Development Plan(s), etc.

2.2 Other documents.

List any other document referenced and pertinent to this document

2.3 Order of precedence.

In the event of conflict between the text of this document and its supporting documentation, the text of this document shall take precedence. E & O.E.

2.4 Source of documents.

Copies of the referenced documents shall be available from project configuration control or the project library.

3. RESOURCES AND ORGANISATION

3.1 Organizational structure.

For an illustration of the Software Configuration Management structure. Under construction

3.2 Personnel.

For a description of the configuration tasks see Job description - configuration control.

3.3 Resources.

Software configuration management should be aided by computing facilities. These facilities shall:

• contain a listing of all documentation being prepared for the system or component part of the system containing software;
• prevent the addition, deletion, or change to software items entered into the developmental configuration without traceability, and the unauthorized change of a baseline specification.
  
• enable the retrieval of change status of baseline and documents entered into the developmental configuration;
• provide a listing of documentation issue status for systems and CSCIs pertinent to this plan.

Suggested areas for partitioning:

• Software Development Library;
• Version Control;
• Library index and issue identification;
• Change (Modification) Control;
• Formally released issues of documentation;
• Formally released versions of software.

Under construction.

4. SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES

4.1 Configuration identification.

4.1.1 Developmental configuration identification.

As the software development life cycle progresses the software design descriptions will be reviewed and entered into the developmental configuration. All changes to these documents shall be controlled by formal change methods.
The following provides a list of documents to be entered into the developmental configuration:

• Software design description;
• Database design description;
• Interface design description;
• Source code listings.
• any other document specifically defined by the acquirer.

The developmental configuration shall be established by the first engineering release of the software design description (top-level) prior to submission to the 'Preliminary Design Review'.
Note: other associated documents (test, management data items) shall be controlled in accordance with the document control procedures defined in the 'System Engineering Management Plan'.

4.1.2 Identification methods.

4.1.2.1 Software documentation.

The system/subsystem level and CSCI level documentation shall be identified using the following type - project - sys/sub/csci code - Issue/revision
Under construction.

4.1.2.2 CSCI software.

Identification of CSCIs shall be provided with a development part number (PIN) or code prior to establishment of a developmental configuration. After final product acceptance the CSCI shall be allocated a production part number (first official version no.) from the design manual if applicable.
Under construction.

4.1.2.3 Software units.

Identification of 'software units' shall be provided by a development part number (PIN) during the development life cycle. After final acceptance the software units may be assigned a production part number.

Under construction.

The type suffix field shall be used to identify the file type associated with the CSCI. The associated file may be source, (.ADA, .FOR, etc.,) data (.dat, .txt, .htm, etc.,) make (.mak) etc.

4.1.2.4 Software development files.

In general, the file name shall reflect the identification of the software file it represents.
The directory structure, filename, extension, and revision identifier shall be used following the naming conventions of VAX/VMS.
The file-name length shall be adapted to the naming conventions of the software tool in use.

4.1.2.5 Software media.

4.1.2.5.1 Software articles.

4.1.2.5.1 Firmware.

4.1.2.5.1 Data carriers (formatted or not).

4.1.2.6 Other software related project documents.

4.1.2.7 Version compatibility matrix.

The 'Software Version Description' and relevant 'Hardware Modification Status' shall

4.1.2.8 Other identification markings.

Programmable Item markings shall conform to the Software Production Release Procedures

4.2 Configuration control.

4.2.1 Flow of configuration control.

Configuration control shall be conducted on three levels:

• Author control;
• project-level control;
• acquirer control;

Initially software items are created and updated by the author. Control of items are passed to configuration control after a successful internal review.

4.2.3 Reporting documentation.

The following reports shall be used to control the configuration:

• Engineering change proposal (ECP);
• Specification change notice (SCN);
• Problem/change report (PCR);
• Document change request (DCR);
• Software version description (SVD);
• Version compatibility matrix.

Under construction.

4.2.4 Review procedures.

There are two configuration review boards:

• Software Configuration Control Board;
• Change Control Board.

4.2.5 Computer-aided Software Configuration Management.

As a minimum software tools shall provide:

• Change status
• Version control

4.3 Configuration status accounting.

4.3.1 Computer software change status report.

The 'Change Status Report' for a CSCI shall be prepared and

4.3.2 Computer software configuration index.

During development of a CSCI

4.3.1 PCR status.

4.3.1 DCR status.

4.3.1 Action item status.

4.4 Configuration audits.

The SCM group shall regularly audit the software baselines and developmental configurations to verify that they conform to the documentation that defines them on a quarter-year basis.
Under construction;

4.5 Packaging, storage, handling, and delivery.

All project software products will be stored in a software library.
The software library shall furnish the necessary facilities for the controlled, secure storage, handling, and release of all software products and media.
The functions of the software library are:

• Provide

5.

6. NOTES

(This section contains information of a general or explanatory nature that may be helpful, but is not mandatory).

6.1 Definitions.

6.1 Abbreviations.

6.1 Changes from previous issue.

This page is under construction

Back to Home page MANAGING STANDARDS Home page

Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk