OVERVIEW

This Software Configuration Management (SCM) Plan (SCMP) describes the SCM organization and practices applied consistently and uniformly throughout the life cycle for Computer Software Configuration Items (CSCIs) that are developed or maintained by [originating organization].

SCM is the process used during software development and maintenance to identify, control, and report functional and physical configurations of software products (e.g., source code, executable code, databases, test scenarios and data, and documentation).

Purpose

The purpose of this document is to define SCM responsibilities (requirements), resources, and processes used during the development and maintenance of the [system title] system. Figure T1 provides an overview of the SCM functions. In the figure, Data Management (DM) is shown connected to SCM with a broken line. DM is a sub-function of SCM with SCM having overall cognizant responsibility. Section 5 describes the DM responsibilities. Software Quality Assurance (SQA) is a separate function that works closely with SCM to ensure the integrity of the product (i.e., SCM controls the product; SQA certifies the integrity of the product).

Figure T1: Overview of SCM Functions

Scope

This plan establishes the SCM methods used during the development and maintenance of the [system title] system.

Approach

The SCM discipline is applied to those Configuration Items (CIs) for which the project organization has development and/or maintenance responsibilities. The SCM organization implements the processes described within this plan to ensure that products developed are correct, consistent, complete, and compliant with governing policies.

System Overview

Project Defined CSCIs

Table T1 shows the CSCIs that this plan applies to.

Listed below is a brief description of each of the CSCIs developed and maintained by [originating organization].

• CSCI #1 ” Include a brief description of the CSCI and its purpose.
• CSCI #2 ” Include a brief description of the CSCI and its purpose.
• CSCI #3 ” Include a brief description of the CSCI and its purpose.

The system includes entering the number of sub-systems within the system. Figure T2 identifies the CSCIs within each sub-system and highlights those that this SCMP applies. The current [system title] Software Development Plan (SDP) contains a detailed description of the software.

Figure T2: [system title] Software

Document Overview

This SCMP establishes the plan for the configuration management of software and related documents produced by the [software development] organization. The processes developed in this SCMP are applicable to all personnel responsible for the analysis, design, development, maintenance, and testing of software embedded in or impacting on the operational capabilities of [system title].

This plan follows the process defined in the SCM Process Definition.

1. Section 1 ” provides the scope, the purpose, and a summary of the contents of the SCMP and a list of common configuration management terms and definitions.
2. Section 2 ” lists the standards and other publications referenced in this document and used in its preparation.
3. Section 3 ” outlines the project organization and responsibilities.
4. Section 4 ” describes the CM phasing and milestones.
5. Section 5 ” describes the activities associated with DM.
6. Section 6 ” describes the process of configuration identification of CSCIs, associated technical documentation, code, and media.
7. Section 7 ” describes the approach for identification and maintenance of system interfaces.
8. Section 8 ” describes the process for maintaining configuration control of CSCIs and their associated technical data.
9. Section 9 ” describes the Configuration Status Accounting (CSA) process used to record and report CSCI information.
10. Section 10 ” describes the approach used for performing physical and functional configuration audits and reviews of SCM activities and products.
11. Section 11 ” describes the methods used to ensure subcontractor and vendor compliance with SCM requirements.
12. Appendix T1 ” contains a list of all acronyms and abbreviations and their definitions used in this document.
13. Appendix T2 ” contains the format and preparation instructions for forms used by the SCM organization.
14. Appendix T3 ” describes the CM phasing and milestones.

SCM Terms and Definitions

The terms and definitions listed below are provided as an aid to understanding and applying the SCM principles and processes used to manage software development and testing efforts.

A F

Allocated Baseline (ABL)

The initially approved documentation that describes an item's functional, interoperability, and interface characteristics that are allocated from those of a system or a higher level configuration item, interface requirements with interfacing configuration items, additional design constraints, and the verification required to demonstrate the achievement of those specified characteristics.

Allocated Configuration Documentation (ACD)

The approved Allocated Baseline plus approved changes.

As-Built

Defines the initial software, hardware, or system configuration as it actually has been built.

Audit

An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or criteria.

Baseline

A configuration identification document or set of such documents formally designated and fixed at a specific time during the configuration item's life cycle. Baselines, plus approved changes from those baselines, constitute the current configuration identification.

Change Request (CR) Form

A vehicle used to report deficiencies or enhancements generated against CIs or technical data; a document that requests a correction or change to the baselined documentation and software.

Computer Software (or Software)

A combination of associated computer instructions and computer data definitions required to enable the computer hardware to perform computational or control functions.

Computer Software Configuration Item (CSCI)

A configuration item that is software.

Configuration

The functional and physical characteristics of existing or planned hardware, firmware, or software or a combination thereof as set forth in technical documentation and achieved in a product.

Configuration Audit

A formal examination of a CSCI. Two types of configuration audits exist: the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA).

Configuration Control

The systematic proposal, justification, evaluation, coordination, and approval or disapproval of proposed changes, and the implementation of all approved changes in the configuration of a Configuration Item (CI) after establishment of the baseline(s) for the CI.

Configuration Identification

The selection of CIs; the determination of the types of configuration documentation required for each CI; the issuance of numbers and other identifiers affixed to the CIs and to the technical documentation that defines the CI's configuration, including internal and external interfaces; the release of CI's and their associated configuration documentation; and the establishment of configuration baselines for CIs.

Configuration Item (CI)

An aggregation of hardware or software that satisfies an end-use function and is designated for separate configuration management.

Configuration Status Accounting (CSA)

The recording and reporting of information needed to manage configuration items (CI) effectively, including:

• A record of the approved configuration documentation and identification numbers
• The status of proposed changes, deviations, and waivers to the configuration
• The implementation status of approved changes
• The configuration of all units of the CI in the operational inventory

Deliverable

A system or component that is obligated contractually to a customer or intended user .

Developmental Configuration

The software and associated technical documentation that define the evolving configuration of a CSCI during development. The Developmental Configuration may be stored on electronic media.

Deviation

A specific written authorization to depart from a particular requirement(s) of an item's current approved configuration documentation for a specific number of units or a specified period of time.

Engineering Change Proposal (ECP)

A proposed engineering change and the documentation by which the change is described, justified, and submitted to the government for approval or disapproval.

Firmware

The combination of a hardware device and computer instructions or computer data that reside as read-only software on the hardware device. The software cannot be readily modified under program control.

Functional Baseline (FBL)

The initially approved documentation describing a system's or item's functional, interoperability, and interface characteristics and the verification required to demonstrate the achievement of those specified characteristics.

Functional Configuration Audit (FCA)

The formal examination of functional characteristics of a CI, prior to acceptance, to verify that the CI has achieved the requirements specified in its functional and allocated configuration documentation.

Functional Configuration Documentation (FCD)

The approved FBL plus approved changes.

N T

Nondevelopmental Software (NDS)

Deliverable software that is not developed under the contract but is provided by the contractor, the government, or a third party. NDS may be referred to as reusable software, government-furnished software, or commercially available software, depending on its source.

Notice Of Revision (NOR)

A document used to define revisions to drawings, associated lists, or other referenced documents that require revision after ECP approval.

Physical Configuration Audit (PCA)

The formal examination of the "as-built" configuration of a CI against its technical documentation to establish or verify the CI's product baseline.

Product Baseline (PBL)

The initially approved documentation describing all of the necessary functional and physical characteristics of the CI and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the CI.

Product Configuration DocumentatioN (PCD)

The approved product baseline plus approved changes.

Program Management

The organization sponsoring the field activity project office.

Project Management

The designated government organization from the field activity project office responsible for the overall management of specific projects.

Release

A configuration management action whereby a particular version of software is made available for a specific purpose (e.g., released to test).

Reusable Software

Software developed in response to the requirements for one application that can be used, in whole or in part, to satisfy the requirements for another application.

Resources

The totality of computer hardware, software, personnel, documentation, supplies , and services applied to a given effort.

Software

See Computer Software (or Software).

Software Configuration Management (SCM)

A discipline that applies technical and administrative direction and surveillance to perform the functions listed below:

• Identify and document the functional and physical characteristics of CSCIs.
• Control the changes to CSCIs and their related documentation.
• Record and report information needed to manage CSCIs effectively, including the status of proposed changes and the implementation status of approved changes.
• Audit the CSCIs to verify conformance to specifications, interface control documents, and other contract requirements.

Software Development Library (SDL)

A controlled collection of software, documentation, and other intermediate and final software development products, and associated tools and procedures used to facilitate the orderly development and subsequent support of software.

Software-Related Group

Project members responsible for generating requirements, design, development, validation, verification, documentation, maintenance, and logistics of software.

Software Support

The sum of all activities that take place to ensure that implemented and fielded software continues to fully support the operational mission of the software.

Software Unit

An element in the design of a software item; for example, a major subdivision of a software item, a component of that subdivision, a class, object, module, function, routine, or database. Software units may occur at different levels of a hierarchy and may consist of other software units. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines, procedures, databases, data files, etc.) that implement them or with the computer files containing those entities.

Software Test Environment

A set of automated tools, firmware devices, and hardware necessary to test software. The automated tools may include but are not limited to test tools such as simulation software, code analyzers, test case generators, path analyzers, etc. and may also include the tools used in the software engineering environment.

Specification Change Notice (SCN)

A document used to propose, transmit, and record changes to a specification.

Technical Review

An activity by which the technical progress of a project is assessed relative to its technical or contractual requirements. The review is conducted at logical transition points in the development effort to identify and correct problems resulting from the work completed thus far before the problems can disrupt or delay the technical progress. The review provides a method for the contractor and government to determine that the development of a CSCI and its documentation have met contract requirements.

V W

Version

An identified and documented body of software. Modifications to a version of software (resulting in a new version) require configuration management actions, by either the contractor, the government, or both.

Waiver

A written authorization to accept an item, which during manufacture, or after having been submitted for government inspection or acceptance, is found to depart from specified requirements, but nevertheless is considered suitable for use "as is" or after repair by an approved method.

SCMP Updates

This document will be periodically reviewed to ensure that all SCM functions are accurately described. Audit and review reports or changes to available resources may require this document to be updated. All changes will be incorporated in either change pages or a document revision. Updates to this document are recorded on the Record of Changes and List of Effective Pages sheets located at the front of this document.

SECTION 2 ORGANIZATION

This section describes the SCM organization in relation to the program and project organization structure.

Organizational Structure

Figure T3 is a graphic representation of the program and project organizational structure with respect to the SCM organization. Although SCM takes direction from the Project Manager, it operates within the policies and procedures established by [ name of the organization establishing policies]. Listed below are the responsibilities of each of the organizations as related to [system title] development.

Figure T3: Structure Organization

SCM interfaces with the functions listed below to control software configuration and release activities.

• Program Management (Code Number) ” Responsible for and has the authority to ensure complete fulfillment of all program requirements. The Program Manager has the overall responsibility for acquisition, funding, and transitioning of the project.
• Project Management (Code Number) ” Responsible for the technical aspects of the project. The Project Manager has the responsibility for local funding, allocations , scheduling, tasking, and reporting to program management.
• Software Systems Engineering (Code Number) ” Responsible for systems design (and associated documentation) overview and guidance; detailed design and coding; test plans, procedures, and reports ; software unit testing; and preliminary CSCI testing.
• Software Design and Development (Code Number) ” Responsible for software design (and associated documentation) overview and guidance; detailed design and coding; test plans, procedures, and reports; software unit testing; and preliminary CSCI testing.
• Software Test (Code Number) ” Responsible for the conduct of software testing, including preparation of test plan, description, procedures, and reports. The Software Test Group ensures that the correct configuration is undergoing test and incorporates approved changes into released test documentation based on change request baselining data from SCM. The Software Test Group confirms verification of change request corrective measures prior to change request closure. SCM identifies all change requests included in an Engineering Master (EM) that is to be tested . Test personnel then provide SCM a copy of the test report.
• Software Quality Assurance (SQA) (Code Number) ” Responsible for auditing the software development activities and products (FCA and PCA) and certifying of SCM compliance with this plan and DTPs.
• System Test (Code Number) ” Responsible for administering the verification and validation (V&V) testing prior to release of the software. The System Test Group is a separate organization from the Software Development Group (i.e., the Software Systems Engineering Group and the Software Design and Development Group).
• Logistics (Code Number) ” Responsible for ensuring that changes made to a system are supportable. SCM provides CSCI and associated technical data for logistics evaluation.
• Data Management (DM) (Code Number) ” Responsible for the receipt, distribution, and tracking of technical data associated with the project. DM also ensures compliance with contract requirements as defined in the Contract Data Requirements List (CDRL).

2.1.1 SCM Responsibilities

SCM is responsible for maintaining configuration control over software Developmental Configurations and Baselines and for processing changes to the software configuration. SCM functions include Software Development Library (SDL) operation, software product release coordination, and change request processing and tracking.

The responsibilities of each SCM function are listed in the paragraphs below.

2.1.1.1 Configuration Identification

1. Establish methods and procedures for unique identification of CSCIs.
2. Establish and maintain Functional, Allocated, and Product Baselines and the Developmental Configuration (identify, document, archive, and track changes to system releases).
3. Establish and follow release procedures to obtain Product Baselines for new version releases.
4. Coordinate assignment of identifying numbers for CSCIs and documents.
5. Provide documentation that reflects the release software package.
6. Coordinate release of software and associated documentation to release organizations.
7. Maintain records and prepare reports on release coordination activities.

2.1.1.2 Configuration Control

1. Serve as a member of the Software Configuration Control Board (SCCB). SCM is responsible for preparing and distributing the meeting agenda and minutes and for recording action items and their resolution.
2. Establish and document configuration change control procedures.
3. Establish and follow configuration controls for software and documentation.
4. Place contents of baseline and Developmental Configurations under configuration control in the SDL.
5. Generate executable load modules from controlled source code.
6. Ensure that the contents of the SDL are changed by SCM personnel and only upon receipt of the appropriate paperwork signed by the SCM Manager.
7. Prepare and maintain master(s) of the currently active version of each CI until superseded by a new version. Retain superseded versions of the master(s) in the SDL archive files.
8. Maintain records and prepare reports on SDL activities and software products.
9. Perform nontechnical check of software documentation.
10. Interface with the Software Change Review Board (SCRB) Chairperson to schedule SCRB meetings, prepare SCRB agendas , and record SCRB meeting minutes.

2.1.1.3 Configuration Status Accounting (CSA)

1. Provide CSA recording and reporting.
2. Maintain accounting of software changes by tracking change requests, ensuring traceability to a formal change proposal (i.e., ECP) from initiation through resolution and disposition.
3. Prepare status reports on change requests, formal change proposals (i.e., ECPs), and changes.

2.1.1.4 Configuration Audits

1. Support requests for audit and certification of software systems by SQA or the independent auditor .
2. Perform reviews of SCM activities and products.
3. Review and update SCM documentation as required to ensure that current applicability is maintained .

2.1.1.5 Training

The SCM Manager is responsible for identifying, establishing, coordinating, and revising training as required to ensure effective performance of SCM activity by the SCM organization and software-related groups.

Boards

The paragraphs below provide an overview of the functions, responsibilities, and authority of the CCBs.

2.2.1 Software Change Review Board (SCRB)

The SCRB functions in a technical advisory capacity to the Program Manager. The SCRB considers the recommendations of the project's SCCB for final approval or disapproval of proposed engineering changes to a CSCI's current approved configuration and its documentation. The board also approves or disapproves proposed waivers and deviations.

SCM provides status accounting reports to the program's SCRB and updates the status accounting database to reflect SCRB decisions. [SCM or designate ] serves as secretariat to the board.

2.2.2 Software Configuration Control Board (SCCB)

The SCCB supports the Project Manager and is composed of technical and administrative representatives who recommend approval or disapproval of proposed engineering changes to a CSCI's current approved configuration and its documentation. The board also recommends approval or disapproval of proposed waivers and deviations from a CSCI's current approved configuration and its documentation.

Issues that the project's SCCB is unable to resolve or that involve a change in scheduling or fiscal costs are initially addressed by the SCCB and forwarded to the program's SCRB for final approval or disapproval and recommendations.

SCM provides status accounting reports to the project's SCCB and updates the status accounting database to reflect SCCB decisions. SCM or designate serves as secretariat to the board.

SECTION 3 CM PHASING AND MILESTONES

This section describes the software development activity for software-related groups and the SCM responsibilities in relation to this activity and program events. These activities occur within the Engineering and Manufacturing Development phase of the software life cycle. The software life cycle includes five phases: Concept Exploration and Definition, Demonstration and Validation, Engineering and Manufacturing Development, Production and Deployment, and Operations and Support. Some of the Engineering and Manufacturing Development activities may be applicable to and overlap with other life-cycle phases. For this reason, the objectives of each life-cycle phase are presented. Table T2 defines the SCM milestones in relation to software- related group activity for [project name ].

Concept Exploration and Definition

Objectives of the Concept Exploration and Definition phase are to:

1. Explore various material alternatives to satisfying the documented mission need.
2. Define the most promising system concept(s).
3. Develop supporting analyses and information to include identifying high-risk areas and risk management approaches to support project decisions.
4. Develop a proposed acquisition strategy and initial program objectives for cost, schedule, and performance for the most promising system concept(s).

SCM responsibilities are to:

1. Develop a CM Plan for the Acquirer, if tasked.
2. Charter the SCCB.
3. Document the Functional and Physical Characteristics (FPC).
4. Ensure contractor control and accounting of the FPC.
5. Participate in System Requirements Review.

Demonstration and Validation

Objectives of the Demonstration and Validation phase are to:

1. Define critical design characteristics and expected capabilities of system concept(s).
2. Demonstrate that the technologies critical to the most promising concept(s) can be incorporated into system design(s) with confidence.
3. Prove that the processes critical to the most promising system concept(s) are understood and attainable.
4. Develop the analysis/information needed to support project decisions.
5. Establish a proposed Development Baseline containing refined program cost, schedule, and performance objectives for the most promising design approach.

SCM responsibilities are to:

1. Update the CCB charter and CM Plan.
2. Continue documentation of the FPC.
3. Ensure contractor control and accounting of the FPC.
4. Ensure government control and accounting of the FPC.
5. Participate in System Design Review.

Engineering and Manufacturing Development

Table T2 shows SCM milestones for the Engineering and Manufacturing Development phase of a software life cycle.

3.3.1 Concept and Exploration

During concept and exploration, software-related groups are concerned with the following activities:

1. Provide sponsors with estimates of cost, schedule, risk items, etc.
2. Assist with generation of an action plan to include initial estimates for cost, schedule, risk, and system size .
3. Involve Software Quality Assurance in planning.

SCM responsibilities are to:

1. Plan how this project will affect other program products and the configuration management of them.
2. Baseline the product identification.

3.3.2 Project Planning and Oversight

During project planning and oversight, software-related groups are concerned with the following activities:

1. Software development planning: development and documentation of plans to conduct software development process activities identified in the following sections; development of program and project plans including a Software Development Plan (SDP) and development and implementation of a CM policy.
2. CSCI test planning: development and documentation of plans for conducting CSCI qualification testing and the generation of a Software Test Plan (STP).
3. System test planning: participation in developing and documenting plans to conduct system qualification testing.
4. Software installation planning: development and documentation of plans to perform software installation and training at user sites and generation of a Software Installation Plan (SIP).
5. Software transition planning: identification of all software development resources needed by the support agency to fulfill support concept, and development and documentation of a Software Transition Plan (STrP).
6. Following and updating plans: conduct of relevant activities in accordance with approved plans, supporting management reviews of the software development process, and updating plans as needed.
7. Establishment of the SCRB and SCCB.

SCM responsibilities are to:

1. Create a draft SCMP or update an SCMP for existing system.
2. Establish and staff the project SCM functional organization.
3. Apply and maintain the identification scheme for project products.
4. Place planning documents (SDP, STP, SIP, STrP, SCMP) under configuration control.
5. Participate in joint management and technical reviews.

3.3.3 Establishment of Software Development Environment

During establishment of a software development environment, software-related groups are concerned with the following activities:

1. Software engineering environment: establishment, control, and maintenance of the environment.
2. Software test environment: establishment, control, and maintenance of the environment.
3. Software Development Library (SDL): establish, control, and maintain an SDL to facilitate the orderly development and subsequent support of software.
4. Software Development Files (SDFs): establishment, control, and maintenance of an SDF for each software unit or logically related group of software units.
5. Nondeliverable software: verification that the nondeliverable software performs the intended functions.

SCM responsibilities are to:

1. Train staff on the SCM processes.
2. Establish and maintain the SDL and SDFs.
3. Participate in joint management and technical reviews.

3.3.4 System Requirements Analysis

During system requirements analysis, software-related groups are concerned with the following activities:

1. Analysis of user input: analysis provided by acquirer and generation of need surveys, problem/change reports , feedback on prototypes , interviews, or other user input.
2. Operational concept: participation in the definition and documentation of the operational concept for the system and generation of an Operational Concept Description (OCD).
3. System requirements: participation in the definition and documentation of system requirements and methods used to ensure that each requirement has been met; and, depending on CDRL provisions, generation of a System/Sub-system Specification (SSS) or an Interface Requirements Specifications (IRSs).
4. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Participate in joint management and technical reviews to provide status on SCM activities.
2. Place system requirements documents (OCD, SSS, IRSs) under configuration control.
3. Support the SCCB and SCRB.

3.3.5 System Design

During system design, software-related groups are concerned with the following activities:

1. System-wide design decisions: participation in definition and documentation of system-wide design decisions, and generation of a System/Sub-system Design Description (SSDD), Interface Design Descriptions (IDDs), or Database Design Descriptions (DBDDs), depending upon CDRL requirements.
2. Architectural design:. participation in definition and documentation of architectural design and traceability between system components and system requirements.
3. Convene the SCCB to establish the Functional Baseline.
4. Convene the SCRB, when required, to exercise software configuration control upon establishment of the Functional Baseline.
5. Participation in joint management and technical reviews.
6. Approve project plans: Program and Project Plans, Software Development Plan, and SCMP.

SCM responsibilities are to:

1. Implement the approved SCMP.
2. Identify tasks stated in SCMP.
3. Create or update DTPs.
4. Participate in joint management and technical reviews.
5. Place system design documents (SSDD, IDDs, DBDDs) under configuration control.
6. Maintain configuration control of the Functional Baseline.
7. Support the SCCB and SCRB.
8. Establish and maintain the CSA system.
9. Provide access procedures to project personnel on use of CSA system.
10. Generate and distribute CSA reports.
11. Establish and maintain the CM Document Library.

3.3.6 Software Requirements Analysis

During software requirements analysis, software-related groups are concerned with the following activities:

1. Software requirements. Participate in the definition and documentation of CSCI software requirements in Software Requirements Specifications (SRSs) or the IRSs, methods used to ensure requirements have been met, and traceability between CSCI requirements and system requirements.
2. Convene the SCCB to establish the Allocated Baseline.
3. Convene the SCRB, when required, to exercise software configuration control upon establishment of the Allocated Baseline.
4. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Place software requirements documents (SRSs, IRSs) under configuration control.
2. Maintain configuration control of the Functional and Allocated Baselines.
3. Participate in joint management and technical reviews.
4. Support the SCCB and SCRB. 5. Maintain the CSA system.
5. Generate and distribute CSA reports.
6. Maintain the CM Document Library.
7. Establish and maintain the CM Drawing Library.

3.3.7 Software Design

During software design, software-related groups are concerned with the following activities:

1. CSCI-wide design decisions: participation in definition and documentation of CSCI-wide design decisions in design documentation.
2. CSCI architectural design: participation in definition and documentation of CSCI architectural design in SDDs or IDDs and traceability between software units and CSCI requirements.
3. CSCI detailed design: participation in development and documentation of descriptions for each software unit in design documentation.
4. Convene the SCCB to establish Developmental Configuration.
5. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Establish and maintain corrective action process for Developmental Configuration.
2. Place software design documents (SDDs, IDDs, DBDDs) under developmental configuration control.
3. Maintain configuration control of developmental configuration products.
4. Maintain configuration control of Functional and Allocated Baselines.
5. Participate in joint management and technical reviews.
6. Support the SCCB and SCRB.
7. Maintain the CSA system and distribute CSA reports.
8. Maintain the CM Document and Drawing Libraries.

3.3.8 Software Implementation and Unit Testing

During software implementation and unit testing, software-related groups are concerned with the following activities:

1. Software implementation:. development and documentation of software corresponding to each software unit in the CSCI design.
2. Preparation for unit testing: establishment of test cases, test procedures, and test data for testing the software corresponding to each software unit, and documentation of test case information in SDFs.
3. Performance of unit testing: testing the software corresponding to each software unit in accordance with unit test cases and procedures.
4. Revision and retesting: software revision, retesting, and SDF update based on unit testing results.
5. Analyzing and recording unit testing results: analyzing unit testing results and documentation of test and analysis results in appropriate SDFs.
6. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Maintain corrective action process and provide status reports.
2. Maintain configuration control of developmental configuration products (including source code and source code listings).
3. Maintain configuration control of the Functional and Allocated Baselines.
4. Participate in joint management and technical reviews.
5. Support the SCCB and SCRB.
6. Maintain the CSA system and distribute CSA reports.
7. Maintain the CM Document and Drawing Libraries.
8. Maintain the SDL and SDFs.

3.3.9 Unit Integration and Testing

During unit integration and testing, software-related groups are concerned with the following activities:

1. Preparation for unit integration and testing: establishment of test cases, test procedures, and test data to conduct unit integration and testing, and documentation of information in appropriate SDFs.
2. Performance of unit integration and testing: performance of unit integration and test in accordance with unit integration test cases and procedures.
3. Revision and retesting: revision of software, retesting, and updating of SDFs and other software products based on results of unit integration and testing.
4. Analysis and recording unit integration and test results: analysis of unit integration and testing results and documentation of these results in appropriate SDFs.
5. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Maintain corrective action process and provide status reports.
2. Maintain configuration control of developmental configuration products.
3. Maintain configuration control of the Functional and Allocated Baselines.
4. Participate in joint management and technical reviews.
5. Support the SCCB and SCRB.
6. Maintain the CSA system and distribute CSA reports.
7. Maintain the CM Document and Drawing Libraries.
8. Maintain the SDL and SDFs.

3.3.10 CSCI Qualification Testing

During CSCI qualification testing, software-related groups are concerned with the following activities:

1. Independence in CSCI qualification testing: assurance that qualification testing is performed by nonparticipant in the CSCI detailed design and implementation.
2. Testing on target computer system: inclusion of CSCI qualification testing on target computer system or approved alternative system.
3. Preparation for CSCI qualification testing: definition and documentation of test preparations , cases, and procedures for CSCI qualification testing, traceability between test cases and the CSCI requirements, and generation of a Software Test Description (STD).
4. Dry run of CSCI qualification testing: testing in preparation for witnessing by the acquirer, documentation of results in SDFs, and update of CSCI test cases and procedures.
5. CSCI qualification testing: performance of CSCI qualification testing in accordance with the CSCI test cases and procedures.
6. Revision and retesting: revision of software, perform all necessary retesting, and update of SDFs and other software products, based on results of CSCI qualification testing.
7. Analysis and recording of CSCI qualification test results: analysis and documentation of test results in a Software Test Report (STR).
8. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Maintain corrective action process and provide status reports.
2. Place testing documents (STD, STR) under developmental configuration control.
3. Maintain configuration control of developmental configuration products.
4. Maintain configuration control of the Functional and Allocated Baselines.
5. Participate in joint management and technical reviews.
6. Support the SCCB and SCRB.
7. Maintain the CSA system and distribute CSA reports.
8. Maintain the CM Document and Drawing Libraries.
9. Maintain the SDL and SDFs.

3.3.11 CSCI/Hardware Configuration Item (HWCI) Integration and Testing

During CSCI/HWCI integration and testing, software-related groups are concerned with the following activities:

1. Preparation for CSCI/HWCI integration and testing: participation in development and documentation of test cases, test procedures, and test data for conduct of CSCI/HWCI integration and testing, and documentation of software-related information in the appropriate SDFs.
2. Performance of CSCI/HWCI integration and testing: participation in CSCI/HWCI integration and testing in accordance with the CSCI/HWCI integration test cases and procedures.
3. Revision and retesting: revisions to software, participation in all necessary retesting, and update of appropriate SDFs and other software products, based on CSCI/HWCI integration and testing results.
4. Analysis and recording CSCI/HWCI integration and test results: participation in analysis of CSCI/HWCI integration and testing results, and documentation in appropriate SDFs.
5. Participation in joint management and technical reviews.
6. Conduct of FCA and PCA.

SCM responsibilities are to:

1. Maintain corrective action process and provide status reports.
2. Maintain configuration control of developmental configuration products.
3. Maintain configuration control of the Functional and Allocated Baselines.
4. Participate in joint management and technical reviews.
5. Support the FCA and PCA.
6. Support the SCCB and SCRB.
7. Maintain the CSA system and distribute CSA reports.
8. Maintain the CM Document and Drawing Libraries.
9. Maintain the SDL and SDFs.

3.3.12 System Qualification Testing

During system qualification testing, software-related groups are concerned with the following activities:

1. Independence in system qualification testing: assurance that system qualification testing is performed by nonparticipant in the detailed design and implementation of system software.
2. Testing on target computer system: qualification testing on target computer system or approved alternative system.
3. Preparation for system qualification testing: participation in development and documentation of test preparations, test cases, and test procedures to be used for system qualification testing, traceability between test cases and system requirements, and documentation of all applicable items in the Software Test Description (STD).
4. Dry run of system qualification testing: testing in preparation for witnessing by the acquirer, documentation of results in SDFs, and update of system test cases and procedures.
5. Performance of system qualification testing: participation in system qualification testing in accordance with the system test cases and procedures.
6. Revision and retesting: participation in all software revision, retesting, and update of appropriate SDFs and other software products, based on results of system qualification testing.
7. Analysis and recording of system qualification test results: participation in analysis and documentation of system qualification test results.
8. Participation in joint management and technical reviews.

SCM responsibilities are to:

1. Maintain corrective action process and provide status reports.
2. Maintain configuration control of Functional and Allocated Baselines.
3. Participate in joint management and technical reviews.
4. Support the SCCB and SCRB.
5. Maintain the CSA system and distribute CSA reports.
6. Maintain the CM Document and Drawing Libraries.
7. Maintain the SDL and SDFs.

3.3.13 Software Use Preparation

During software use preparation, software-related groups are concerned with the following activities:

1. Preparation of executable software: preparation of executable software for each user site and documentation of all applicable items in the Software Product Specification (SPS).
2. Preparation of version descriptions for user sites: identify and document the exact version of software prepared for each user site in a Software Version Description (SVD).
3. Preparation of user manuals: user manuals may include System User Manual (SUM), Software Input/Output Manual (SIOM), Software Center Operator Manual (SCOM), and Computer Operation Manual (COM).
4. Installation at user sites: installation, check-out of executable software at specified user sites, training, and other specified assistance.
5. Convene the SCCB to establish the Product Baseline.
6. Convene the SCRB to exercise software configuration control upon establishment of the Product Baseline.

SCM responsibilities are to:

1. Place software user documents (SPS, SVD) and user manuals (SUM, SIOM, SCOM, COM) under configuration control.
2. Maintain corrective action process and provide status reports.
3. Maintain configuration control of Functional, Allocated, and Product Baselines.
4. Participate in joint management and technical reviews.
5. Support the SCCB and SCRB.
6. Maintain the CSA system and distribute CSA reports.
7. Maintain the CM Document and Drawing Libraries.
8. Maintain the SDL and SDFs.

3.3.14 Software Transition Preparation

During software transition preparation, software-related groups are concerned with the following activities:

1. Preparation of executable software: preparation of executable software for transition to support site and documentation of applicable items in the SPS.
2. Preparation of source files: preparation of source files for transition to the support site and documentation of applicable items in the SPS.
3. Preparation of version descriptions for support site: identification and documentation of the exact version of software prepared for the support site in the SVD.
4. Preparation of the "as-built" CSCI design and related information: update of each CSCI design description to match the "as-built" software. Definition and documentation of all information (in the SPS) needed to support the software, and traceability between the CSCI's source files and software units and between the computer hardware resource utilization measurements and the CSCI requirements concerning them.
5. Update of system design description: participation in updating system design description to match the "as-built" system in the SSDD.
6. Preparation of support manuals: support manuals may include Computer Programming Manuals (CPMs) and Firmware Support Manuals (FSMs).
7. Transition to designated support site: installation and check-out of deliverable software in the support environment, training, and miscellaneous assistance to support agency.

SCM responsibilities are to:

1. Archive Product Baseline.
2. Transfer Product Baseline to support site.

Production and Deployment

Objectives of the Production and Deployment phase of the software life cycle are to:

1. Establish a stable, efficient production and support base.
2. Achieve an operational capability that satisfies the mission need.
3. Conduct follow-on operational and production verification testing to confirm and monitor performance and quality and verify the correction of deficiencies.

SCM responsibilities are to:

1. Update CCB charter, CM Plan(s), Functional, Allocated, and Product Baselines.
2. Ensure contractor and government control of FPC, Functional, Allocated, and Product Baselines.
3. Provide training in the CM process to the operating forces.

Operations and Support

Objectives of the Operations and Support phase of the software life cycle are to:

1. Ensure that the fielded system continues to provide the capabilities required to meet the identified mission need.
2. Identify shortcomings or deficiencies that must be corrected to improve performance.

SCM responsibilities are to:

1. Update CCB charter, CM Plan(s), Functional, Allocated, and Product Baselines.
2. Continue control and accounting of FPC, Functional, Allocated, and Product Baselines.
3. Participate in conduct of audits as required.
4. Provide training in the CM process to the operating forces.

SECTION 4 DATA MANAGEMENT

The section describes the data handling, processing, storage, integrity, transfer, security, and maintenance of configuration management technical data.

Data management responsibilities are to:

1. Receive/obtain CDRL documents, software, or project technical data.
2. Implement and apply the configuration identification scheme in accordance with Section 6 of this plan.
3. Catalog the CDRL documents, software, or project technical data.
4. Maintain status records or database of CDRL documents, software, or project technical data.
5. Perform security access and control.
6. Provide change control.
7. Provide distribution copies for project personnel or for outside distribution.
8. Maintain review comments or files, and forward comments to document originators.
9. Prepare and distribute status and inventory reports .
10. Archive CDRL documents, software, or project technical data.
11. Track CDRL documents, software, or project technical data requiring response or action.

Data Distribution and Access

Access to project technical data is limited in accordance with the applicable distribution statements defined by the contract or Project Manager and by data rights, CDRL distribution security requirements, and data status level (released or submitted for approval unless otherwise specified). Distribution lists of projects technical data are maintained as part of the data status reporting function. Requests for project technical data by activities outside this project require approval by the Project Manager or designated authority.

Automated Processing and Submittal of Data

The following requirements are used to identify and control data during the review and update cycle:

1. Data files are uniquely identified and include file version and "submitted" status (e.g., "working," "released," etc.). File-naming conventions are used to indicate changes from previous versions or to distinguish an altered (annotated, redlined) file version from the originally submitted file version (e.g., filename.srs;2, or filename_srs.ann;6).
2. Data and changes are transmitted in accordance with the submittal date specified in the contract.
3. An acknowledgment of receipt from the receiving party is required when electronic data is being sent. The required time to respond is 24 hours. A follow-up is made after the 24- hour period.
4. Data that is electronically transferred is identified and defined as follows :
   • "Working": work in progress, not formally submitted or made accessible; provided for information or communication; subject to internal CM (version control).
   • "Released": CM controlled version released or made accessible after internal interview and approval.
   • "Submitted": CM controlled master version formally submitted or made accessible.
   • "Approved": CM controlled master version approved.

5. Records are kept for each data transaction.

Interactive Access to Digital Data

Define the following processes:

1. How data is to be accessed
2. Request for access and logging of access for read-only or annotations
3. Naming of temporary working version of files for the purpose of annotation or mark-up
4. Means of indicating whether a comment or annotation is essential or suggested
5. Reidentification of marked -up versions, as required
6. Method of indicating acceptance, provisional acceptance, approval, or rejection
7. Automated status accounting, including tracking the disposition of required changes
8. Reidentification of changed files

Status Reporting

Data requirements defined by the CDRL are incorporated into the [ name of the database used to track CDRLs] database. The database is used to identify all CDRL data, to prepare status reports, and to track approval history. The database contains each contractually required data item and information on data submission. In addition to the CDRL item, the title of the data item and source references (e.g., Data Item Description [DID] number, paragraph number of applicable addendum) are included. Listed below are the main areas addressed in the status reports.

1. Data deliveries completed in the previous period
2. Data scheduled for submission
3. Data due but not yet delivered
4. Status of delinquent data

Data Security and Classification Management

Data security and classification management are an integral part of data management. Security requirements are considered during all areas of data management control.

SECTION 5 CONFIGURATION IDENTIFICATION

This section describes the process for configuration identification.

Selection of CSCIs

The selection of CSCIs is the responsibility of project management or the developer. CSCIs are placed under configuration management in accordance with this plan. Once the CSCI has been identified and provided to the SCM organization, the SCMP will be updated.

Formal Baseline Establishment

For each CSCI, configuration identification is established for software technical documentation, code, and media. The initially approved configuration identifications establish baselines from which subsequent changes are controlled. The configuration identifications and baselines to be established for [system title] CSCIs are defined as shown below.

1. Functional Baseline. Listed below are the documents that comprise the Functional Baseline for [system title].
   • Document 1
   • Document 2
   • Document 3

2. Allocated Baseline. Listed below are the documents that comprise the Allocated Baseline for [system title].
   • Document 1
   • Document 2
   • Document 3

3. Product Baseline. Listed below are the documents that comprise the Product Baseline for [system title].
   • Document 1
   • Document 2
   • Document 3

Identification Methods

The paragraphs below describe the methods used in identifying the CSCI and associated technical data and project-developed support software required for development, test, and maintenance.

5.3.1 Document Identification

SCM assigns unique numbers to CSCI documents. Each page of the document contains the identification number with the applicable revision letter.

5.3.1.1 Document Revision

SCM assigns identifiers to document revisions.

5.3.1.2 Document Change Pages

SCM assigns numbers to document change pages.

5.3.2 Drawing Identification

SCM assigns unique numbers to drawings.

5.3.3 Software Identification

SCM assigns unique numbers to drawings.

5.3.3.1 Copy Number

Each accountable copy of a software product (e.g., source code tape), with the exception of the EM and listings, is assigned a unique copy number, both externally and embedded within the software.

5.3.3.2 Volume Number

For software products that require more than one unit of physical storage per copy, a volume number is assigned to each unit of storage, both externally and embedded on the software.

5.3.3.3 Labels

[system title] software is labeled for ease in identification. Describe the specific labeling practices being used.

Listed below is the minimum information necessary to adequately identify software media.

1. Identify each of the elements required on a label.

5.3.4 Firmware Identification

The components of firmware, the hardware device, and the computer instructions or computer data that reside as read-only software on the hardware device are each uniquely identified. Firmware identification includes the top-level document/drawing that defines how these components fit together for the firmware assembly. Firmware is assigned a unique identifier.

5.3.5 Change Request Form Identification

Each change request form received by SCM is assigned a unique identifier.

5.3.6 Engineering Release

The software release process begins at the start of system integration and testing. At the initiation of this phase, the software Product Baseline is established by the project's SCCB. The software release identified as part of the Product Baseline is provided for integration with the operational hardware. Final testing is accomplished by Operational Test and Evaluation (OT&E). Issues found by OT&E are resolved using the baseline change process. Upon satisfactory completion of OT&E, the software release is approved as the Product Baseline Configuration. Approval for service use initiates distribution to Fleet users. CM/DM is responsible for making and distributing copies of software products. The copies are made from the EM. SCM is responsible for ensuring that the correct software product and release documentation are distributed through DM.

Developmental Configuration Corrective Action Process

Anomalies or discrepancies against the Developmental Configuration are resolved through a corrective action process. The corrective action process is a closed-loop process, ensuring that all detected problems are promptly reported and entered into the process, action is initiated on them, resolution is achieved, status is tracked and reported , and records of the problems are maintained for the life of the product.

The corrective action process is the development team's internal control over software that is evolving from requirements and being developed through design, code and unit test, integration test, and software system test.

The Development Group is responsible for the Developmental Configuration and therefore provides status of implementing change proposals and closing out the change request form. The paragraphs below describe the steps in processing a change request form.

1. The initiator reports a problem using a change request form and submits it to the SCM organization.
2. SCM assigns a change request form tracking number, updates the change request form tracking database, and provides a copy to the development team for problem analysis and proposed solution. A master copy of the change request form is maintained by the library.
3. The approval authority determines the corrective action to be taken and the priority of the action. Corrective actions may be returned to the Development Group for implementation or sent to another group for review or action.
4. The Development Group implements the approved solution and provides status of the implementation and completion to the SCM organization. Implementation includes updating the software and configuration documents. Implementation is considered complete when the integration and testing of the change request " passes " test criteria.

Configuration Management Libraries

The Developmental Configuration management process includes the responsibility to control documentation and repositories containing elements of the Developmental Configuration. The [project organization], in response to this requirement, has established the following libraries: Software Development Library, Documentation Library, and Drawing Library. The following paragraphs describe the functions of each of the libraries.

Project management authorizes access to each of the [project organization] libraries. Access includes types of user privileges granted (e.g., for software: read, write, execute; for documentation: loan copy, distribution copy).

5.5.1 Software Development Library

The SDL is the controlled collection of documentation, intermediate software development products, associated tools, and procedures that comprise a Developmental Configuration CSCI. The SDL provides storage of and controlled access to software development products in human-readable form, machine-readable form, or both. SDL components are initially documented in an identification list for the Allocated Baseline.

• Figure T4: Sample Product Development Evolution

The [project organization] SDL consists of a series of phases through which the software is developed. Before software is released from one development phase to the next , it must be validated by a Quality Assurance function and verified by SCM. SCM uses the [ name the tool or briefly explain the process] to perform this verification. SCM verifies that approved software changes have been incorporated into the proper phase of the SDL, reports status to the SCCB, and performs the release function upon SCCB authorization.

5.5.2 Documentation Library

The [project organization] Documentation Library contains the controlled collection of all the project's document inventory, in any media, for both released and development versions; it houses both deliverable and nondeliverable products (e.g., preliminary versions of baseline documents, specifications on commercial off-the-shelf [COTS] tools). The Documentation Library for a newly designated baseline is established at the same time as its Developmental Configuration, and its components are initially documented in an identification list for the Allocated Baseline. SCM verifies that new documents that are entered into the library as CSCIs have been approved by the SCCB and that only approved document changes have been incorporated into all controlled documents. SCM activates the release process upon SCCB authorization.

5.5.3 Drawing Library

The [project organization] Drawing Library contains the controlled collection of all of the project's drawings, Computer-Aided Design (CAD), and Computer-Aided Manufacturing (CAM) instructions. The Drawing Library for a newly designated baseline is established at the same time as its Developmental Configuration, and its components are initially documented in an identification list for the Allocated Baseline. SCM verifies that approved changes have been incorporated into drawings originated by and under control of the [project organization].

SECTION 6 INTERFACE MANAGEMENT

This section identifies the interface requirements and establishes the Interface Control Working Group . Interface management is performed to ensure compatibility and interoperability among various hardware and software components in a system as specified in the baselined configuration documentation.

Interface Requirements

Listed below are the interface requirements for [system title].

1. Interface Requirement number 1
2. Interface Requirement number 2
3. Interface Requirement number 3

Interface Control Working Group (ICWG)

The ICWG is chartered to ensure the compatibility of the software and hardware components. The ICWG is composed of members of the systems outlined above and representatives from the system design group. The ICWG meetings will include discussions of the interface control documentation.

SCM may be required to generate and distribute CSA reports and technical data.

SECTION 7 CONFIGURATION CONTROL

This section describes the process for maintaining configuration control of all identified CSCIs developed or maintained by [originating organization].

The purpose of configuration control is to maintain the integrity of baselined CSCIs and their associated documentation by ensuring that only authorized changes are incorporated. This requires the systematic evaluation, processing, and approval or disapproval of all proposed changes. Configuration control begins when a CSCI is baselined and continues as further baselines are established.

SCM is responsible for maintaining software configuration control over software products in the Functional, Allocated, Developmental Configuration, and Product Baselines. In addition, SCM is responsible for administering the process by which a request for change to products under control is submitted, reviewed, and approved or disapproved.

Boards

The [originating organization] is subject to a hierarchy of control boards for baseline integrity. A description of each of these boards, along with their functions and responsibilities, is presented in the paragraphs below.

7.1.1 SCCB

A Software Configuration Control Board (SCCB) has been established to authorize changes to baselined documentation and software for delivered products and for in-development products. The specific procedures for conducting an SCCB meeting are detailed in [document name ].

7.1.1.1 SCCB Responsibilities

The SCCB has authority for managing the project's software through the performance of the functions listed below.

1. Authorize establishment of software baselines and identification of CSCIs.
2. Represent interests of project management and all groups who may be affected by software changes to the baselines.
3. Assign, review, and provide for disposition of action items.
4. Provide required staff coordination on all proposed or reviewed changes or modifications.
5. Serve as a source for the coordination of software technical expertise for the project.
6. Determine or review the availability of resources required to complete the proposed change or modification, assess the impact of the proposed change upon the system, examine cost considerations, and determine the impact of the change on development and test schedules.
7. Monitor the design, production, and validation process for approved modifications, and initiate, when required, the corrective actions necessary to ensure design compatibility and integrity, cost-effectiveness , and conformance to scheduled milestones.
8. Direct software change implementation on changes approved by the SCCB.
9. Exercise interface management support and control for project software.

7.1.1.2 SCCB Composition

The SCCB is chaired by an SCCB Chairperson or a designated representative. Board members include representatives of the functions designated below:

1. SCM
2. Software Requirements
3. Software Design/Development
4. Software Test
5. SQA
6. Software Systems Engineering
7. Logistics
8. System Test
9. Technical personnel directly associated with problems or proposed changes to be reviewed

SCM schedules and coordinates SCCB meetings, including the creation and distribution of meeting agenda and minutes. For time-critical software problems, an emergency SCCB meeting may be convened. The required attendees are listed below.

1. SCCB Chairperson
2. SCM Manager
3. Software Requirements Manager
4. Software Design Manager
5. If applicable , the manager of the group that documented the problem

7.1.1.3 Roles of SCCB Members

The paragraphs below describe the roles of SCCB members.

7.1.1.3.1 SCCB Chairperson

Ultimate authority for the SCCB rests with project management. An SCCB Chairperson is appointed by the Project Manager to serve as Project Manager agent for SCCB functions. The SCCB Chairperson reports all SCCB functions to the Project Manager. The responsibilities of the SCCB Chairperson are listed below.

1. Schedule and conduct SCCB meetings.
2. Ensure that notice of each SCCB meeting is furnished sufficiently in advance so that representatives may attend completely prepared.
3. Evaluate and act on proposed changes.
4. Present recommended changes to the Project Manager to assist in determining which change requests will be processed for implementation.
5. Coordinate implementation of software changes approved by the Project Manager.
6. Sign the written synopsis of matters considered and recommendations made by the SCCB. (The synopsis is made a permanent part of the proceedings of the SCCB, and copies of the synopsis are distributed to all SCCB members.)

7.1.1.3.2 SCCB Secretariat

The [originating organization] provides a secretariat (i.e., the SCM Manager) to perform the administrative functions listed below.

1. Prepare, coordinate, and distribute the SCCB meeting agenda.
2. Act as recording secretary during SCCB meetings.
3. Prepare and distribute the SCCB meeting minutes.
4. Perform additional staffing functions as directed by the SCCB Chairperson.
5. Prepare the written synopsis of matters considered and recommendations made by the SCCB.
6. Distribute copies of signed synopsis to all SCCB members.

7.1.1.3.3 Other SCCB Members

All SCCB members represent their respective activities regarding all proposed software changes brought before the SCCB. Their duties include those listed below.

1. Receive copies of all proposed changes submitted for SCCB consideration.
2. Review, evaluate, and coordinate with other offices as required to determine impact of all proposed changes.
3. Attend meetings of the SCCB to present position statement on proposed changes.
4. Assist in the preparation of composite ECP or local form.
5. Assist the [originating organization] in the analysis of the impact of proposed changes in their area of expertise.
6. Perform other tasks as assigned by the SCCB Chairperson.

7.1.2 Other Local Boards

7.1.3 Other Boards

7.1.4 SCRB

The management team required to establish and maintain configuration control of software consists of the sponsor and an established SCRB.

7.1.4.1 SCRB Responsibilities

The SCRB is responsible for evaluating and approving or disapproving proposed software changes. The evaluation of proposed changes must consider, as a minimum, such factors as documentation, equipment interfaces, training equipment, implementation costs, and performance requirements.

Proposed changes submitted for SCRB action must be complete with respect to technical requirements, justification, cost information, logistic requirements, interface requirements, retrofit requirements, and other applicable information. When a proposed change affects any system or item under the cognizance of another SCRB, joint SCRB meetings will be held as required.

7.1.4.2 SCRB Composition

The organization of the SCRB consists of the members listed below.

1. Program Manager (PM) or Acquisition Manager (AM)
2. SCRB Chairperson (designated by the PM or AM)
3. Sponsor Representative
4. Representatives of participating Navy field activities
5. Representatives of the [originating organization]

In addition, advisory personnel from each of the areas listed below are included in the SCRB as required.

1. Fleet users
2. Test and evaluation personnel
3. Contractor and Navy developer
4. Interfacing systems SCRB representatives

In specific cases, representatives of other divisions and offices of NAVAIR TEAM may be required to serve as advisors to the board. Participation of these divisions is coordinated by the SCRB Chairperson.

7.1.4.3 Roles of SCRB Members

The following paragraphs describe the roles of SCRB members.

7.1.4.3.1 SCRB Chairperson

Ultimate authority for the SCRB rests with the [SCRB program management]. An SCRB Chairperson is appointed by the Program Manager to serve as the program management agent for SCRB functions. The SCRB Chairperson reports all SCRB functions to the Program Manager. The responsibilities of the SCRB Chairperson include:

1. Schedule and conduct SCRB meetings.
2. Ensure that notice of each SCRB meeting is furnished sufficiently in advance so that representatives may attend completely prepared.
3. Ensure that task statements, work unit assignments, and contract changes are issued to fund SCRB members for direct SCRB participation.
4. Evaluate budgetary estimates of SCRB members for proposed software changes.
5. Evaluate and act on proposed changes (i.e., approve/disapprove).
6. Present recommended changes to the PM and AM to assist them in determining which change requests will be processed for implementation.
7. Coordinate implementation of software changes approved by the PM and AM.
8. Present composite ECPs for new baseline to the appropriate SCCB.
9. Sign the written synopsis of matters considered and recommendations made by the SCRB. (The synopsis is made a permanent part of the proceedings of the SCRB, and copies of the synopsis are distributed to all SCRB members.)

7.1.4.3.2 SCRB Secretariat

The [originating organization] provides a secretariat (i.e., the SCM Manager) to perform the administrative functions listed below.

1. Prepare, coordinate, and distribute the SCRB meeting agenda.
2. Act as recording secretary during SCRB meetings.
3. Prepare and distribute SCRB meeting minutes.
4. Prepare the composite ECP or local form.
5. Perform additional staffing functions as directed by the SCRB Chairperson.
6. Prepare written synopsis of matters considered and recommendations made by the SCRB.
7. Distribute copies of signed synopsis to all SCRB members.

7.1.4.3.3 Other SCRB Members

All SCRB members represent their respective activities regarding all proposed software changes brought before the SCRB. Their duties include:

1. Receive copies of all proposed changes submitted for SCRB consideration.
2. Review, evaluate, and coordinate with other offices as required to determine impact of all proposed changes.
3. Attend SCRB meetings to present position statement on proposed changes.
4. Assist with the analysis of the impact of proposed changes.
5. Perform other tasks as assigned by the SCRB Chairperson.

Baseline Change Process

The [project organization] baseline change process is a continuous function that involves the preparation, implementation, and distribution of CSCI and associated documentation changes. It has been approved by the [sponsor organization] and involves activity at both the project and program levels.

The assigned responsibilities and approval authority for accomplishing changes to baselines are detailed in a project-originated SCCB charter documented in [list the document name]. This charter interfaces with the [sponsor organization] charter. The charter establishes the processing of change requests and their resolution by local and [sponsor organization] boards.

Changes to a [project organization] baseline configuration are initiated through a change request process that involves the preparation of a defined series of documents (change forms) whose status is determined by a hierarchy of control boards. Change requests are used to report problems and propose changes or enhancements to software or documentation. A change request must be documented, submitted, reviewed, and approved prior to implementation. Change requests against developmental baselines are resolved by the [project organization] SCCB the SCCB, identify the board> . Change requests against established baselines require approval of the [sponsor organization] SCRB.

7.2.1 Change Request Forms

The [project organization] uses the following change forms for control of its software baselines:

1. Engineering Change Proposals (ECPs)
2. Specification Change Notices (SCNs)
3. Notices of Revisions (NORs)
4. Deviation and Waiver
5. Local change requests ” insert title of local change request

7.2.1.1 Engineering Change Proposal

The ECP is used to document all proposed changes to established baselines. The completed ECP must include detailed descriptions, justifications, and costs for the proposed change.

7.2.1.2 Specification Change Notice

The SCN is used to correct or update specifications. The SCN identifies the document to be changed, the SCN number, its status (proposed or approved), the related ECP, and other [project organization] identifying data.

7.2.1.3 Notice of Revision

The NOR is primarily intended for use when the master drawing list and other documents comprising the configuration identification are not held by the originator of the ECP. NORs permit the ECP previewing or approving activity to direct the custodian of an applicable document to make specific revisions in affected documents. A separate NOR is prepared for each drawing, associated list, or other referenced document that requires revision when the related ECP is approved. The description of the revision consists of a detailed statement covering each required correction, addition, or deletion.

7.2.1.4 Deviation and Waiver

A request for deviation or waiver is designated as minor, major, or critical.

7.2.1.5 Local Change Request

Table T3 describes the baseline change process used by the [project organization]. Table T4 displays problem priorities.

Table T5 shows categories to be used for classifying problems in software products.

•  

  SECTION 8 CONFIGURATION STATUS ACCOUNTING

  This section describes the process used to provide configuration status accounting (CSA). CSA is the recording and reporting of information needed to manage CSCIs effectively, including the items listed below.

  1. A record of the approved configuration documentation and identification numbers
  2. The status of proposed changes, deviations, and waivers to the configuration
  3. The implementation status of approved changes
  4. The configuration of all units of the CSCI in the operational inventory
  5. Results of audits

  CSA documentation is the means through which actions affecting CSCIs are recorded and reported to the Software Systems Engineering Manager of the [system title] system. It principally records the "approved configuration" (baseline) and the implementation status of changes to the baseline. It is the bookkeeping part of SCM that provides managers with feedback information to determine whether decisions of the SCCB are being implemented as directed.

  To automate CSA, SCM uses [identify the software tool], a relational database management system, to define the data content and format. [Identify the software tool] is an approved, baselined CSCI, so any proposed change to it requires a change request and SCCB approval for implementation.

  Input data includes SCCB decisions, such as approving or disapproving change requests, establishing configuration baselines, and approving the release of software for distribution. Input data also includes status information of CSCIs and change requests . Output data is formatted as CSA reports .

  8 1 Records

  The records maintained by SCM contain detailed data that documents that the as-built software conforms to its technical description and specified configuration. They include the information listed below.

  1. Approved technical documentation for each CSCI
  2. Status of proposed changes
  3. Implementation status of approved changes
  4. Status of software problems
  5. A record of change request status

  8.1.1 Change Request Table

  The change request table contains a record of all change requests and related information. It includes, but is not limited to, the data listed below.

  1. Change request number
  2. Title
  3. Date
  4. Software product name or acronym
  5. Part number or revision in error
  6. Originator
  7. Change source (e.g., ECP), if applicable
  8. Current change request status
  9. Change request disposition

  8.1.2 Library(ies) Inventory Table

  The library inventory table contains a record of each software product stored in the library(ies). It includes, but is not limited to, the data listed below.

  1. Product name

  2. Part or document number and revision

  3. Date of creation, last modification, and last access
  4. "Master" or "Copy" designation
  5. Authorizing paperwork type and number
  6. Type of media
  7. Location
  8. Classification

  8.1.3 Data Distribution Table

  The data distribution table contains a record of all data (e.g., documents and drawings, including CDRL items) distributed by the software organization through DM. The table includes, but is not limited to, the information listed below.

  1. Type and identification number of distribution request
  2. Date of submittal
  3. Media identification
  4. Reason for distribution
  5. Classification

  8.1.4 Release Table

  The release table contains a record of all releases made by the software organization (e.g., drawings, documents, software documents, tape). It includes, but is not limited to, the information listed below.

  1. Date of release
  2. Type of release
  3. Software product released
  4. Changes incorporated into the release
  5. Approval signatures
  6. Location of masters

  8.1.5 Archive Records Table

  SCM maintains a record of all archived material. Archived material includes obsolete material and data not required for current use and off-site stored backup data in case of loss of online data.

  8 2 Reports

  SCM has the prime responsibility for managing, compiling, maintaining, and publishing the [system title] detailed software CSA reports. These reports provide the status to management that all changes between the software technical description and the software itself are being accounted for on a one-to-one relationship. This status information, together with the CSA reports maintained by the SCM organization, is an input for the final review for product acceptance.

  Project management determines the frequency of distribution and recipients of the CSA reports. These reports include the information listed below.

  1. Identification of currently approved configuration documentation and configuration identifiers associated with each CSCI
  2. Status of proposed change requests from initiation to implementation
  3. Results of configuration audits; status and disposition of discrepancies
  4. Traceability of changes from baselined documentation of each CSCI
  5. Effectivity and installation status of configuration changes to all CSCIs at all locations

  The above reports answer basic questions regarding the approved configuration (baseline) and the implementation status of changes to the baseline.

  8 3 Requests for CSA Reports

  Requests for CSA reports originating outside the project are directed for approval to Project Management, which authorizes need-to-know access.

  SECTION 9 CONFIGURATION AUDITS

  This section describes the approach used in performing configuration audits.

  Configuration audits validate that the design and the final product conform to approved functional requirements defined in specifications and drawings and that the changes to the initially approved specifications and drawings have been incorporated.

  The SCM assists in the conduct of two audits for developed baselines prior to their release: the FCA and PCA. These audits ensure that baseline changes are validated and the new baseline meets new requirements and specifications.

  SCM personnel provide assistance through the specific activities listed below, as required by the project.

  1. Assist in the audit.
  2. Review audit checklists.
  3. Prepare SCM reports , logs, or records required to support the audit.
  4. Establish and maintain baseline specification and product files.
  5. Follow up on audit reports to assess possible SCM impact.
  6. Provide storage for audit documentation, records, and products.
  7. Ensure audit report action items are resolved.

  9 1 Functional Configuration Audit (FCA)

  SCM ensures that the released version of the software products is available for the audit so that the inspectors can verify that the software performs as required by its allocated configuration.

  FCAs are usually conducted after a major change or a significant number of minor changes have occurred or before the establishment of the Product Baseline. The SCM Manager is responsible for assisting SQA in the preparation of the FCA plan. The FCA plan identifies specific tasks and procedures to accomplish those tasks . The FCA plan identifies documents, hardware, software, test sets, etc. required for performing the audit. The SCM Manager records differences between the SRS and the CSCI under audit for incorporation into the minutes of the FCA for postaudit action.

  9 2 Physical Configuration Audit (PCA)

  This audit ensures that the as-built configuration is accurately reflected by the released documentation to establish the Product Baseline. SCM audits the released engineering documentation and quality control records to make sure the as-built or as-coded configuration is reflected by this documentation.

  PCAs are usually conducted concurrently with FCAs or immediately following an FCA. The SCM Manager is responsible for assisting SQA in the preparation of the PCA plan. The PCA plan identifies specific tasks and procedures to accomplish those tasks. The PCA plan also identifies the software and technical documentation to be examined.

  9 3 Audits and Reviews of SCM

  To ensure that SCM efforts are adequate and completed as detailed in this document, audits and reviews of SCM processes and products are performed as described in the following paragraphs.

  9.3.1 SCM Audits

  To ensure that the SCM program complies with the requirements specified in this plan, an independent audit of SCM processes, procedures, and products is required. Normally, this type of audit is performed by a QA representative. Products generated or tracked by SCM are listed below.

  1. CSA reports
  2. Identified CSCIs
  3. Change requests
  4. Software version releases
  5. Libraries
  6. Documented SCM processes and procedures
  7. SCM review reports

  The audit findings are documented in an audit report and provided to the SCM Manager. The audit report is used by the SCM Manager to correct deficiencies or identify changes in the SCM requirements. Correcting deficiencies would include updating SCM processes and procedures, records, configuration documents, software, or tools. Identifying changes in the SCM requirements would result in adding, modifying, or deleting a requirement in this SCMP.

  9.3.2 SCM Reviews

  The SCM Manager periodically performs internal reviews of SCM processes, procedures, and products. An SCM review serves as a method to determine how effectively and efficiently the SCM processes and procedures fulfill the SCM requirements as defined in this plan. SCM reviews also include verification of the products generated by SCM. Verification is the process of evaluating the products to ensure correctness and consistency with respect to the SCMP, tasks, processes, and procedures. The review findings are documented in a report that is used by the SCM Manager to correct deficiencies or identify changes in SCM requirements.

  It is the SCM Manager's responsibility to perform or assign SCM personnel to perform the SCM reviews and to specify the SCM processes or procedures to be reviewed. The review report includes what actions were taken to resolve the deficiency or requirements change. The review report is filed with the appropriate DTP and serves as a record to show that an internal SCM review was performed and corrective action was taken as required. Review reports may be audited .

  SECTION 10 SUBCONTRACTOR VENDOR CONTROL

  This section describes the methods used to ensure subcontractor/vendor compliance with configuration management requirements.

  Each contractor working on this system is required to develop a configuration management plan that is in conformance to this document. The development contractor ensures that nondeliverable software will functionally meet the requirements of the system.

  Vendors' products are inspected at delivery to ensure that their products meet the requirements as specified. The vendors ' quality control procedures may be obtained to aid in the evaluation of the COTS software by the system developer.

  Configuration management personnel are acquired as a team through competitive contract negotiation. The SCM staff has responsibility for conducting the SCM function under the management of [ name of the supervising organization or function assigned by the program]. The staff is required to be fully knowledgeable in all aspects of the program's configuration management function and to maintain and upgrade the SCM program whenever they can.

  APPENDIX T1 ACRONYMS AND ABBREVIATIONS

  This appendix includes an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document.

  • ABL ” Allocated Baseline
  • ACD ” Allocated Configuration Documentation
  • AM ” Acquisition Manager
  • CAD ” Computer-Aided Design
  • CALS ” Continuous Acquisition and Life-Cycle Support
  • CAM ” Computer-Aided Manufacturing
  • CCB ” Configuration Control Board
  • CDR ” Critical Design Review
  • CDRL ” Contract Data Requirements List
  • CI ” Configuration Item
  • CITIS ” Contractor Integrated Technical Information Service
  • CM ” Configuration Management
  • CMU ” Carnegie Mellon University
  • COM ” Computer Operation Manual
  • COTS ” Commercial Off-The-Shelf
  • CPM ” Computer Programming Manual
  • CSA ” Configuration Status Accounting
  • CSC ” Computer Software Component
  • CSCI ” Computer Software Configuration Item
  • CSU ” Computer Software Unit
  • DBDD ” Database Design Description
  • DID ” Data Item Description
  • DM ” Data Management
  • DoD ” Department of Defense
  • DTP ” Desktop Procedure
  • ECP ” Engineering Change Proposal
  • EM ” Engineering Master
  • FBL ” Functional Baseline
  • FCA ” Functional Configuration Audit
  • FCD ” Functional Configuration Documentation
  • FPC ” Functional and Physical Characteristics
  • FQT ” Functional Qualification Testing
  • FSM ” Firmware Support Manual
  • HWCI ” Hardware Configuration Item
  • ICWG ” Interface Control Working Group
  • ID ” Identification
  • IDD ” Interface Design Document
  • IRS ” Interface Requirements Specification
  • MAG ” Maintenance Advisory Group
  • MCCR ” Mission Critical Computer Resources
  • NAVAIR ” Naval Air Systems
  • NDS ” Non-Developmental Software
  • NOR ” Notice of Revision

  • OAG ” Operational Advisory Group

  • OCD ” Operational Concept Description
  • OT&E ” Operational Testing and Evaluation
  • PBL ” Product Baseline
  • PCA ” Physical Configuration Audit
  • PCD ” Product Configuration Documentation
  • PDR ” Preliminary Design Review
  • PM ” Program Manager
  • QA ” Quality Assurance
  • SCCB ” Software Configuration Control Board
  • SCM ” Software Configuration Management
  • SCMP ” Software Configuration Management Plan
  • SCN ” Specification Change Notice
  • SCOM ” Software Center Operator Manual
  • SCP ” Software Change Proposal
  • SCR ” Software Change Request
  • SCRB ” Software Change Review Board
  • SDD ” Software Design Document
  • SDF ” Software Development File
  • SDL ” Software Development Library
  • SDP ” Software Development Plan
  • SDR ” System Design Review
  • SEI ” Software Engineering Institute
  • SEP ” Software Enhancement Proposal
  • SIOM ” Software Input/Output Manual
  • SIP ” Software Installation Plan
  • SPS ” Software Product Specification
  • SQA ” Software Quality Assurance
  • SRR ” Software Requirements Review
  • SRS ” Software Requirements Specification
  • SSA ” Software Support Activity
  • SSDD ” System/Segment Design Document
  • SSR ” Software Specification Review
  • SSS ” System/Sub-system Specification
  • STD ” Standard
  • STP ” Software Test Plan
  • STR ” Software Test Report
  • STR Form ” System Trouble Report Form
  • STrP ” Software Transition Plan
  • SUM ” Software User's Manual
  • SVD ” Software Version Description
  • TRR ” Test Readiness Review
  • V&V ” Verification and Validation
  • VDD ” Version Description Document

  APPENDIX T2 FORMS

  Software Change/Software Enhancement Proposal

  Software Trouble/Change Request (STR/SCR)

   

  DOCUMENT CHANGE REQUEST

  Submitting Organization: _________________		Tracking No.: _________________
  Contact Person: _________________________		Telephone: ___________________
  Mailing Address:	_______________________________________
  	_______________________________________
  	_______________________________________
  Date: ______________________	Short Title: _____________________________
  Change Location Tag: __________________________________________________
  (Section No., Figure No., Table No., Page No., etc.)
  Proposed Change:
  Reason for Change:

  APPENDIX T3 SOFTWARE CONFIGURATION MANAGEMENT PHASING AND MILESTONES

  This section describes the sequence of events and milestones for implementation of SCM in phase with major software and development milestones and events. SCM milestones are achieved upon completion of individual SCM activities.

  T3 1 System Requirements Analysis Phase

  This is the first phase of system-level planning. During the system requirements analysis phase, the top-level (system) requirements are established, analyzed , and approved. The requirements describe the major functions that the system must fulfill.

  The outputs of this phase consist of one preliminary product (Preliminary System Specification) and a program review (System Requirements Review [SRR]). No baselines are established at this point. The SCRB and SCCB are established.

  SCM activities during this phase are listed below.

  1. Establish project SCM.
  2. Train staff.
  3. Create draft SCMP or update SCMP for existing system.
  4. Attend SRR as required.

  T3 2 System Design Phase

  This is the second phase of the system-level planning. During the system design phase, a top-level (system) design is formulated and documented. The outputs of this phase consist of four final deliverable products (System Specification, System/Segment Design Document, Software Development Plan, and Software Configuration Management Plan); two preliminary deliverable products (Preliminary Software Requirements Specification and Preliminary Interface Requirements Specification); one program review (System Design Review); and the establishment of the first of three baselines (Functional Baseline).

  The SCCB meets to establish the Functional Baseline. The SCRB meets to exercise software configuration control upon establishment of the Functional Baseline.

  SCM activities during this phase are listed below.

  1. Implement approved SCMP:
     • Identify the tasks stated in SCMP.
     • Identify processes from the tasks in the SCMP.
     • Create or update DTPs from the processes.

  2. Establish complete number scheme for project-defined version identification (ID).
  3. Exercise configuration control of the functional configuration documentation.
  4. Attend System Design Review.
  5. Establish and maintain CSA system.
  6. Establish and maintain CM library(ies).
  7. Support SCCB throughout the software life cycle.

  T3 3 Software Requirements Analysis Phase

  During the software requirements analysis phase, the software performance and interface requirements that must be met are formulated and analyzed. This phase is similar to the system requirements analysis phase except that it focuses on the software requirements derived from the system requirements.

  The outputs from this phase consist of two final deliverable products (Software Requirements Specification and Interface Requirements Specification), one program review (Software Specification Review), and the establishment of the second of three baselines (Allocated Baseline).

  SCM activities during this phase are listed below.

  1. Attend Software Specification Review (SSR).
  2. Exercise control of allocated configuration documentation.

  T3 4 Preliminary Design Phase

  During the preliminary design phase, the system-level architecture, interfaces, and design are developed. A Preliminary Design Review (PDR) is held, and approval is obtained before proceeding with the detailed (low-level) design phase.

  The outputs from this phase consist of one final deliverable product (Software Test Plan [Test Ids]), two preliminary deliverable products (Preliminary Software Design Documents and Preliminary Interface Design Document), one program review (Preliminary Design Review), and the establishment of the Developmental Configuration.

  SCM activities during this phase are listed below.

  1. Establish and maintain SDL.

  2. Establish corrective action process for Developmental Configuration.

  3. Attend PDR.
  4. Exercise configuration control of Developmental Configuration Products.

  T3 5 Detailed Design Phase

  During the detailed design phase, the design team develops the detailed design, and a Critical Design Review (CDR) is held for review and approval of the total design. The design is completed and approved at the CDR. By the time the CDR occurs, the software constituting the system has been decomposed into a hierarchical structure of CSCIs, Computer Software Components (CSCs), and CSUs.

  The preceding phases ensure that design requirements have been identified, validated , and allocated to the approved design and to their respective baselines.

  The outputs from this phase consist of three final deliverable products (detailed Software Design Documents, Software Test Descriptions [Cases[, and Interface Design Document); one program review (Critical Design Review); and the continuance of the Developmental Configuration.

  SCM activities during this phase are listed below.

  1. Attend CDR.
  2. Exercise configuration control of Developmental Configuration Products.

  T3 6 Coding and CSU Testing Phase

  During the coding and CSU testing phase, coding and unit (CSU) testing is accomplished. All design data, programmer notes, and CSU test results are kept in the Software Development Files (SDFs). This is for programmer and peer review only. SQA can perform audits of the SDFs.

  The outputs from this phase result in completed CSU development and testing evidenced by source code and source code listings. The Developmental Configuration continues.

  SCM activities during this phase are listed below.

  1. Exercise configuration control of Developmental Configuration Products.

  T3 7 CSC Integration and Testing Phase

  During the CSC integration and testing phase, coding and testing of CSCs is accomplished. CSUs are integrated into their next -higher structures and tested to ensure proper processing. Test drivers and stubs are written to perform these tests. All design data, programming notes, and test results are added to the SDFs. This is for programmer and peer review only. SQA can perform audits of the SDFs.

  The outputs from this phase consist of one final deliverable product (Software Test Description (Procedures)), one program review (Test Readiness Review [TRR]), plus updated source code, source code listings, and command files. Successful completion of these activities indicates the conclusion of the Developmental Configuration.

  SCM activities during this phase are listed below.

  1. Support TRR by providing the items listed below:
     • CSCI and associated technical data
     • Status of reported software and documentation anomalies

  2. Exercise configuration control of Developmental Configuration products.

  T3 8 CSCI Testing Phase

  During the CSCI testing phase, testing of CSCIs is accomplished to demonstrate that the software system is reliable and maintainable . All lower-level (CSU and CSC) coding and testing have been completed. This final software testing ensures that each CSCI functions as designed.

  The V&V process is a software quality check to ensure that the design is complete and that the software fulfills all approved requirements and may be performed by the Systems Test Group.

  Formal Qualification Testing (FQT) is performed in this phase. The CSCI testing is basically the FQT, whereby the customer accepts the tested integrity of the developed system. The completed Software Test Plan includes tests of user identification and access to the system, as well as test plans for any identified safety issues.

  The outputs from this phase consist of the following final deliverable products (Software Test Reports, Operation and Support Documents, Version Description Documents, Software Product Specifications, and updated source code and listings); two audits (PCA and FCA); and establishment of the last of the three baselines (Product Baseline).

  When the FCA/PCA is approved, the customer accepts the Product Baseline.

  SCM activities during this phase are listed below.

  1. Support FCA and PCA. These audits may be deferred until after system integration and testing.
  2. Release product configuration documentation.
  3. Exercise configuration control of product configuration documentation.

  T3 9 System Integration and Testing Phase

  During the system integration and testing phase, the software is integrated into the operational hardware and tested. DOD-STD-2167A development activities end with CSCI testing and the establishment of the software Product Baseline. After software Product Baseline, the software must be integrated into the operational hardware and final testing (Operational Testing and Evaluation [OT&E]) accomplished by the customer before placing the system into operation.

  REFERENCES

  This document is an adaptation of a document developed at the request of Naval Air Systems Command (NAVAIR) TEAM. The original document can be found at http://sepo.nosc.mil/sepo/GenSCMP/GenSCMP.html .

  SPAWAR Systems Center San Diego, Systems Engineering Process Office, http://sepo.spawar.navy.mil/sepo/index2.htm .

  APPENDIX T4 CONFIGURATION MANAGEMENT PHASING AND MILESTONES

  Development Phase	SCM Activity	SCM Control	Milestones	Product
  System Requirements Analysis	Establish project SCM Train staff Create draft or update SCMP for existing system Attend SRR as required		SRR SCM established Program SCRB established Project SCCB established	Preliminary System Specification Preliminary SCMP
  System Design	Implement approved SCMP Identify tasks stated in SCMP Identify processes from tasks Create/update DTPs Establish complete number scheme for project-defined version ID Attend SDR Establish and maintain CSA system Establish and maintain CM library(ies) Support SCCB throughout software life cycle	System Specification SSDD SDP SCMP	SDR Functional Baseline	System Specification SSDD SDP SCMP Preliminary SRS Preliminary IRS
  Software Requirements Analysis	Attend SSR	SRS IRS	SSR Allocated Baseline	SRS IRS
  Preliminary Design	Establish and maintain Software Development Library Establish corrective action process Attend PDR Exercise configuration control of Developmental Configuration products	STP (Test IDs)	PDR Developmental Configuration	Preliminary SDD Preliminary IDD STP
  Detailed Design	Attend CDR Exercise configuration control of Developmental Configuration Products	SDD IDD STD (Test Cases)	CDR	Detailed SDD IDD STD (Test Cases)
  Coding and CSU Testing	Exercise configuration control of Developmental Configuration Products	Tested Source Code (CSUs) Source Code Source Code Listings		Source Code Source Code Listings
  CSC Integration and Testing	Exercise configuration control of Developmental Configuration Products Support TRR by providing CSCI and associated technical data and status of reported software and documentation anomalies Exercise configuration control of developmental configuration products	STD (Test Procedures) Updated Source Code Updated Source Code Listings Command Files	TRR	STD (Procedures) Updated Source Code Source Code Listings Command Files
  CSCI Testing	Exercise configuration control of product configuration documentation Support FCA and PCA Release product configuration documentation	Updated Source Code Updated Source Code Listings Command Files STR Operation and Support Documents VDD SPS	FCA PCA Product Baseline	Updated Source Code Command Files Software Test Report Operation and Support Documents VDD SPS

  Appendix U Acronyms and Glossary