APC-SW007 Software Configuration Management Plan (SCMP) Amend 6.docx

SIR 693KA8-21-RFI-XXXX

Section J4 – CDRLs and DIDs

CONTRACT DATA REQUIREMENTS LIST (CDRL)

1. CDRL #

APC-SW007

2. Title

Software Configuration Management Plan (SCMP)

6. Requiring Office

FAA

10. Frequency

As Required

12. First Submission

10 business days prior to initial FAA Audit

14. Distribution

COR

CO

0/1

LT

4. DID #

SW007

5. Contract Reference

J.1.2, VoICE APC System Software Requirements Document - 2.2.1.8 Software Configuration Management Plan (SCMP) J.1.2, VoICE APC System Software Requirements Document - 6.1 Summary of Software CDRLs 7.

8. Approval Code

Block 16

16. REMARKS:

Block 13: 20 business days prior to PDR

Block 14, 15: CO Letter of Transmittal only

The Contractor must mark the plan in accordance with FAA Order 1600.75: Protecting Sensitive Unclassified Information (SUI).

15. TOTAL 0/1

DATA ITEM DESCRIPTION

1. CDRL TITLE

Software Configuration Management Plan (SCMP)

2. CDRL NUMBER

APC-SW007

3. DESCRIPTION/PURPOSE

The Software Configuration Management Plan (SCMP) must establish the methods to be used to achieve the objectives of the SCM process throughout the software life cycle.

4. DATA REQUIREMENTS

Reference:

J.1.2, VoICE APC System Software Requirements Document - 2.2.1.8 Software Configuration Management Plan (SCMP) J.1.2, VoICE APC System Software Requirements Document - 6.1 Summary of Software CDRLs

General:

The Contractor must mark the plan in accordance with FAA Order 1600.75: Protecting Sensitive Unclassified Information (SUI). Software Configuration Management Plan (SCMP) must, at a minimum, include the following information:

1. Scope. This section must contain the following sub-sections.

1.1. System overview. This sub-section must provide an overview of the system, including a description of its functions and the allocation of functions to the hardware and software, the architecture, processor(s) used, hardware/software interfaces, and safety features.

1.2. Software overview. This section briefly describes the software functions with emphasis on the proposed safety and partitioning concepts. Examples include resource sharing, redundancy, fault tolerance, mitigation of single event upset, and timing and scheduling strategies.

1.3. Document overview. This sub-section must summarize the purpose and contents of this document and describe any security or privacy considerations associated with its use.

1.4. Relationship to other plans. This sub-section must describe the relationship, if any, of the SCMP to other project management plans.

2. Reference Documents. This section must list the number, title, revision, and date of all documents referenced in the SCMP. This section must also identify the source for all documents not available through normal Government stocking activities

3. Environment. This section must describe the SCM environment to be used. This must include procedures, tools, methods, standards, organizational responsibilities, and interfaces.

4. Activities. This section must contain the following information.

4.1. Configuration Identification. This section must identify the following for all Configuration Items:

4.1.1. Name;

4.1.2. Identification methods for software lifecycle data (e.g. version numbering);

4.1.3. Relationship of software identification and system, documentation, or equipment identification.

4.2. Baseline and Traceability. This section must establish baselines, what baselines will be established, when these baselines will be established, the software library controls, and the configuration item and baseline traceability.

4.3. Problem Reporting. This section must include the content and identification of Problem Reports for the software product and software life cycle process, when they will be written, the method of closing Problem Reports, and the relationship to the change control activity.

4.4. Change Control. This section must identify the configuration items and baselines to be controlled, when they will be controlled, the problem/change control activities that control them, pre-approval controls, post-approval controls, and the means of preserving the integrity of baselines and configuration items.

4.5. Change Review. This section must identify the method of handling feedback from and to the software life cycle process; the method of assessing and prioritizing problems, approving changes, and handling their resolution or change implementation; and the relationship of these methods to the problem reporting and change control activities.

4.6. Configuration Status Accounting. This section must identify the data to be recorded to enable reporting configuration management status (e.g. Status Accounting Reports - CSAR, DSAR), definition of where that data will be kept, how it will be retrieved for reporting, and when it will be available.

4.7. Archive, Retrieval, and Release. This section must identify the integrity controls, the release method and authority, and data retention.

4.8. Software Load Control. This section must describe the software load control safeguards and records.

4.9. Software Life Cycle Environment Controls. This section must identify the controls for the tools used to develop, build, verify and load the software, addressing section 4.1 through section 4.7. This includes control of tools to be qualified.

4.10. Software Life Cycle Data Controls. This section must identify the control categories, controls for the categories, and the relationship between the categories and data controlled. The identification must show what control is applicable to what level.

5. Transition Criteria. This section must identify the transition criteria for entering the SCM process.

6. SCM Data. A definition of the software life cycle data produced by the SCM process, including SCM Records, the Software Configuration Index (CDRL APC-SW004) and the Software Life Cycle Environment Configuration Index (CDRL APC-SW010).

7. Supplier Control. This section must identify the means of applying SCM process requirements to suppliers.

A. Appendices. Appendices may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix must be referenced in the main body of the document where the data would normally have been provided. Appendixes must be lettered alphabetically (A, B, etc.).