Applicable_Document_-_ATR_CM_Plan_Rev2.1.doc

ATRDC00001.A Rev 2.0

Atlantic Test Range (ATR)

Configuration Management Plan

Document Number: ATRDC00001.A Revision 2.1 04 August 2016 Prepared by:

Range Architect Office Atlantic Test Range

23013 Cedar Point Road

Patuxent River, MD 20670

NOTICE TO REVIEWERS

This document was submitted for review and approval to the persons and organizations listed below. The date identifies when Approvers gave approval of the document as submitted.

Rob Vargo, Code 520000A ATR Associate Director

Date

Yvonne Davis, Code 522000A Range Operations Division Head

Date

Bill Darden, Code 520000A

ATR Chief Engineer

Date

Ken Clarke, Code 524000A Range Architect, Atlantic Test Range

Date

Revision Record

Replaced Approver Greg Gillingham with Rob Vargo

Replaced Approver Rob Vargo with Kim Darland ii

Changes to 2.0 References:

Replaced EIA-649-A with EIA-649-B

Replaced outdated documents MIL STD 2549, ASME Y14.100 2004, 516 200 with NAVAIR INST 4130.ID, EIA-836-B, NAVAIR 00-25-300, DODI 5000.02

Changes to 3.1.3 Baseline Captures:

The following sentence was modified from:

The information for each CI will be entered into the ATR CI Database.

to:

The information for each CI will be entered into a CI Database.

The following sentence was deleted:

The ATR CI Database is located on the ATR WIKI page under the CM section.

The following sentence was modified from:

The Project Plan is an attachment on the Systems Engineering WIKI Page.

to:

The Project Plan is an attachment on the Systems Engineering SharePoint site.

Changes to 3.4 CM Tools:

Deleted:

Microsoft Visual Source-Safe

Changes to 3.4.1 CI Database:

The following sentence was replaced:

The ATR CI Database is located on the ATR WIKI Page under the CM section.

with the following:

Any appropriate database may be used to store CI’s.

Changes to 3.4.2 CR Database:

The following sentence was replaced:

The ATR CR Database is located on the ATR WIKI Page under the CM section:

with the following:

Any appropriate database may be used to store CRs.

10-11

Changes to 3.4.3 Software Revision Control:

The following sentence was modified:

All versions for each of the CSCIs and CUs for a software build will also be entered into and tracked in the ATR CI Database.

to:

All versions for each of the CSCIs and CUs for a software build will also be entered into and tracked in a CI database.

Changes to 3.5.1 CM Process Audits:

The audit checklist is provided under the CM section on the WIKI.

to:

The audit checklist is provided under the CM section on the ATR SharePoint site.

Changes to 3.6.2 Data Archive:

The unchangeable media will be marked with the release system name, version number and date and stored in a fireproof vault.

to:

The unchangeable media will be marked with the release system name, version number and date and stored in at a fireproof vault, remote backup location, or an off-site location.

The following sentence was deleted:

A second copy of the archive will be stored at an off-site location.

12-13

Changes to 3.6.3 Disaster Recovery:

Disaster recovery will be performed using the copies of the archived system information that were placed in the fireproof safe.

to:

Disaster recovery will be performed using the copies of the archived system information that was placed in the fireproof safe, remote backup location, or off-site location.

The following sentence was modified:

Before restoring a file from the archive, a copy of the unchangeable media will be made and the original will be placed back the fireproof safe.

to:

Before restoring a file from the archive, a copy of the unchangeable media will be made and the original will be placed back into the archive location.

Remove Kim Darland from Approval list ii

TABLE OF CONTENTS

11.0 INTRODUCTION

11.1 SCOPE

12.0 REFERENCE DOCUMENTS

13.0 CM PROCESSES

13.1 SYSTEM BASELINE

23.1.2 CONFIGURATION ITEMS

23.1.2.1 HARDWARE IDENTIFICATION

23.1.2.2 SOFTWARE IDENTIFICATION

33.1.2.3 DOCUMENTATION IDENTIFICATION

33.1.3 BASELINE CAPTURE

33.2 CHANGE MANAGEMENT

33.2.1 CHANGE REQUESTS

33.2.1.1 CUSTOMER REQUIREMENT CRs

43.2.1.3 TROUBLE REPORTS CRs

43.2.1.4 TEST REPORT CRs

43.2.2 MANAGING CRs

43.2.3 CHANGE PROCESS

53.2.3.1 HARDWARE CHANGE

53.2.3.2 SOFTWARE CHANGE

63.2.3.3 DOCUMENTATION CHANGE

63.3 CONFIGURATION CONTROL BOARD

63.3.1 CCB MEMBERS

73.3.1.1 TEAM LEAD

73.3.1.2 CM MANAGER

73.3.1.3 TECHICAL LEAD

83.3.1.4 USER REPRENTATIVE

83.3.1.5 SYSADMIN REPRESENTATIVE

83.3.1.6 SYSTEM TESTER

93.3.1.7 QUALITY MANAGER

93.3.1.8 CUSTOMER REPRESENTATIVE

93.3.1.9 SECURITY REPRESENTATIVE

103.3.2 CCB MEETINGS

103.4 CM TOOLS

103.4.1 CI DATABASE

103.4.2 CR DATABASE

113.4.3 SOFTWARE REVISION CONTROL

113.5 CM AUDITS

113.5.1 CM PROCESS AUDITS

113.5.2 CONFIGURATION AUDITS

113.5.2.1 FUNCTIONAL CONFIGURATION AUDITS

123.5.2.2 PHYSICAL CONFIGURATION AUDITS

123.5.2.3 SOFTWARE BASELINE AUDITS

123.6 DATA MANAGEMENT

123.6.1 DATA BACKUP

123.6.2 DATA ARCHIVE

133.6.3 DISASTER RECOVERY

133.7 TRAINING

134.0 ACRONYMS

LIST OF TABLES

Error! Bookmark not defined.Table 1: CM Training Matrix

1.0 INTRODUCTION

The purpose of the Configuration Management Plan (CMP) is to define specific processes and procedures to perform Configuration Management (CM) of system hardware, software and documentation.

CM is performed using a set of documented activities and processes to perform updates to and version control of hardware, software and documentation. This document defines:

· CM processes, activities and tools for change management.

· The CM requirements, processes and tools for:

· Identification and Management of Configuration Items (CI)

· Composition and Activities of a Configuration Control Board (CCB)

· Tracking of Change Requests (CR) and Trouble Reports (TR)

· Version Control of Hardware, Software and Documentation

· Change Management

1.1 SCOPE

The intent of this document is to define a common set of CM processes and tools that can be used to support the CM of systems across the Atlantic Test Range (ATR).

2.0 REFERENCE DOCUMENTS

EIA-649-B, National Consensus Standard for Configuration Management, 17 June 2011 EIA-836-B, Configuration Management Data Exchange and Interoperability, 01 May 2010

NAVAIR INST 4130.ID, Naval Air Systems Command Configuration Management Process, 20 Dec 2006

NAVAIR 00-25-300, Naval Air Systems Command Configuration Management Process, 19 Dec 2006

DODI 5000.02, Operation of the Defense Acquisition System, 12 May 2003 ATRDC00002, ATR Document Identification Numbering System, 1 Nov 09

ATRDC00003, ATR Drawing and Part Numbering System, 1 Nov 09 ATRDC00009, ATR Software Identification Numbering System, 1 Nov 09

3.0 CM PROCESSES

3.1 SYSTEM BASELINE

A system baseline identifies all of the elements or configuration items including hardware, software and documentation that define the “state” of a system and the processes used to maintain the configuration baseline on the system. A configuration baseline is established by performing the following:

· Identifying All System CIs

· Performing Functional and Physical Configuration Audits

· Recording results of Audit

3.1.1 BASELINE DEFINITION

A system configuration baseline, including hardware, software and documentation, must be identified and documented in order to perform configuration management of a system. A system baseline will be defined by performing the following:

· Decompose the system into subsystems and components.

· Identify the hardware for each subsystem and component and assign each CI a unique number.

· Identify the software on each system, subsystem and component and assign each software configuration item a unique number.

· Identify all of the documentation for the system, subsystems and components and assign each document a unique number.

· Identify all of the Systems Engineering (SE), CM and project documents and assign each a unique number. Documents include the Project Plan, System Requirements Document (SRD), System Design Document (SDD), Interface Control Document (ICD), Test Plan, Acceptance Test Plan (ATP), test reports, meeting minutes, project briefs, users manual and training material.

3.1.2 CONFIGURATION ITEMS

CIs are the lowest level items that comprise a system in which changes will be managed and tracked so that the configuration of the system baseline is known and can be reproduced. CIs used to define the “state” of the system include hardware, software and documentation.

3.1.2.1 HARDWARE IDENTIFICATION

Hardware CIs will be identified by a unique system CI number. Information captured for each hardware CI will include an item description, the manufacturer, model and version of the item as well as, a part number, serial number and, if available, Naval Air Warfare Center Aircraft Division (NAWCAD) Property Number or barcode number.

3.1.2.2 SOFTWARE IDENTIFICATION

Computer Software Configuration Items (CSCIs) will be identified by a unique CSCI number, name, and version number. Each CSCI will be decomposed into Configuration Software Units (CSUs). Each CSU will be identified by a unique CI number, name and version number. Version control software will assign revision numbers to each of the CSU files. A software identification number will be assigned to a software release In Accordance With (IAW) the ATR Software Identification Numbering System, ATRDC00009.

3.1.2.3 DOCUMENTATION IDENTIFICATION

Documentation configuration items will be identified by a document ID number, title, and revision date. A document ID number will be assigned to a document IAW ATR Document Identification Numbering System, ATRDC00002.

3.1.3 BASELINE CAPTURE

The baseline “state” of a system will be captured and maintained by entering all of the information associated with all the identified CI’s, hardware, software and documentation, into a CI database. The information for each CI will be entered into a CI Database.

The baseline “state” for new projects also includes the programmatic baseline which defines the baseline schedule, cost and resources needed to accomplish the project. The programmatic baseline is captured in the Project Plan and will be updated IAW the defined ATR SE process. Meeting minutes are also considered part of the documentation baseline. The Project Plan is an attachment on the Systems Engineering SharePoint Page.

3.2 CHANGE MANAGEMENT

Revisions to a system configuration include any changes to any CI including hardware or software. Updates will be made to the documentation in the areas of the system impacted by the change to reflect the new system baseline.

3.2.1 CHANGE REQUESTS

CRs are defined as any change requested for the system including capability enhancements, user requested changes and identified system bugs. CRs will be captured from:

· Customer Requirements

· User Requirements

· TRs

· Test Reports

3.2.1.1 CUSTOMER REQUIREMENT CRs

Customer requirements will be decomposed into uniquely identifiable requirement elements. Each requirement element will be assigned a unique CR number. The priority of customer change requests will be determined at stakeholder meetings with customers, users and CCB members.

3.2.1.2 USER REQUIREMENT CRs

User requirement CRs are generated to request a change to an existing feature or capability or to request a new system capability. The priority of user change requests will be determined at stakeholder meetings with users and CCB members.

3.2.1.3 TROUBLE REPORTS CRs

TRs identify system bugs or deficiencies that impact the operation of the system. TRs are provided by system users to report errors or deficiencies in the system. TRs will be validated by the team lead and technical lead. The priority of validated TRs will be determined by the user representative and team lead.

3.2.1.4 TEST REPORT CRs

Test reports will be generated during system testing and acceptance testing. As formal documents these will be assigned document numbers and tracked IAW Section 3.1.2.3. Change requests will be entered into the CR Database when bugs or discrepancies are identified during system testing to manage the tracking of identified system deficiencies. The priority of these CR’s will be determined and assigned by the CCB.

3.2.2 MANAGING CRs

Change requests will be captured and managed using the CR Database. Refer to Section 3.4.2. Each CR will be assigned a unique CR number or ID. The following information will be captured for each change request.

· System Name

· Date of Request

· A Description of the Change Request

· Category of Request: New Capability, Upgrade or Deficiency

· Type of Change: Hardware, Software, Documentation

· Assigned Priority

· Name of Person Assigned

· Date Assigned

· Status - Assigned, In-progress, On-hold, Complete

· Release Version

· Release Date

The changes to be implemented in a new software release or made in a system upgrade will be determined at stakeholder meetings with the customer and CCB members. The release version will be updated in the CR database to indicate all of the CRs that will be incorporated in the new baseline or version of the system at the conclusion of the CCB.

3.2.3 CHANGE PROCESS

Changes will be made to the configuration baseline of a system by performing the following process:

· Identify the needed change(s).

· Enter CRs in CR Database.

· Evaluate and assign CR priorities (CCB).

· Identify the CRs to be implemented in the new release (CCB).

· Implement CRs identified in new system release.

· Update the SRD, SDD, ICD, Test Plan, and/or ATP to reflect changes.

· Follow the process defined below in Sections 3.2.3.1 – 3.2.3.3 for executing changes in system hardware, software or documentation.

· Test and prepare Test Report.

· Develop or update a deployment plan and stakeholder list.

· Obtain ATR Change Review Board (CRB) approval to deploy the change in the operational environment.

· Schedule deployment.

· Execute installation and verification IAW deployment plan.

3.2.3.1 HARDWARE CHANGE

Hardware changes to the system configuration baseline will be performed as follows:

· Identify the hardware CI(s) being added or changed.

· Change the drawing that reflects the part number or component in the system.

· Assign the drawing a revision number in accordance with the Drawing and Part Numbering System document.

· Enter version updates for each of the added or modified hardware CI(s) into the ATR CI Database.

· Provide the new drawings to the CM Manager for archival storage.

· Configure hardware for deployment.

· Identify the CI number for the hardware being replaced IAW section 3.1.2.1.

3.2.3.2 SOFTWARE CHANGE

Software changes to the system configuration baseline will be performed as follows:

· Identify the software CI(s) being added or changed.

· Update the version number for each added or changed software CI(s) in the software revision control system.

· Assign a version number to the new system software build IAW the software versioning guidance in Section 3.1.2.2.

· Enter version updates for each of the added or modified software CI(s) into the ATR CI Database.

· Burn one installation copy of the software executable onto unchangeable media e.g. CD or DVD.

· Burn one archive copy of the executable, source code, make files along with all of the documentation that reflects the “new baseline” onto unchangeable media.

· Mark the release version number on each copy of the unchangeable media.

· Provide the copy of the media with the executable on it to Sys Admin for installation.

· Provide the archive copy to the CM Manager for archival.

· Archive the media with the “new baseline” on it IAW Data Management Section 3.6.2.

3.2.3.3 DOCUMENTATION CHANGE

Changes to baseline documentation will be performed as follows:

· Identify all of the documents that need to be updated to reflect the state of the new system baseline.

· Update the identified documents.

· Assign a new version number to each added or modified document IAW Section 3.1.2.3.

· Submit updated documents to CM Manager.

· Enter the version number updates for each of the added or modified document CI(s) in the ATR CI Database.

3.3 CONFIGURATION CONTROL BOARD

The CCB will be responsible for establishing a system configuration baseline and managing changes to the baseline. This includes any changes to hardware, software or documentation.

CCBs are generally at the team or branch level and may manage the configuration of more than one system or capability.

3.3.1 CCB MEMBERS

CCB member roles are listed below. The preference is for each of the roles to be performed by different individuals, but the technical lead can also perform the CM manager role. The system tester and quality assurance manager could be the same individual but should not be the developer of the CI under test (not the person who wrote it). The CCB member roles not listed in italics are required and the members listed in italics are recommended but are not mandatory.

· Team Lead (CCB Manager)

· CM Manager

· Technical Lead(s)

· User Representative

· Sys Admin Representative

· System Tester

· Quality Assurance Manager

· Customer Representative

· Security Representative

3.3.1.1 TEAM LEAD

The team lead is the manager or lead for the CCB and will manage the gathering and prioritization of requirements and their implementation. The team lead will coordinate with the customer and user representatives in setting the priority of system changes and enhancements. The team lead will:

· Chair regularly scheduled CCB meetings.

· Hold stakeholder meetings to define and review requirements.

· Manage the capture of CRs and TRs.

· Hold customer and user stakeholder meetings to prioritize the implementation of system requirements, bug fixes, change requests and system enhancements.

· Coordinate with the technical lead and stakeholders to define which requirements and fixes will be implemented in the next release version of the system.

· Develop a program schedule and manage the development and implementation of system changes.

· Assign personnel tasking for implementing requirements and changes.

· Manage the test, deployment and re-baseline of new versions of the system.

· Ensure the system baseline is controlled and documented.

3.3.1.2 CM MANAGER

The CM manager will ensure that the configuration of the deployed system baseline is known and documented. The CM manager will:

· Capture and publish minutes for each CM meeting.

· Obtain concurrence on minutes and action items from CM attendees.

· Ensure all documentation has been updated to reflect the current system baseline.

· Manage updates to the CR Database.

· For a new release or system baseline:

· Ensure documentation is updated to reflect the new baseline.

· Ensure the new version of the software baseline is identified in the software versioning control system.

· Assign new versions to changed hardware, software and documentation IAW sections 3.1.2.1-3.1.2.3.

· Update the CI database to reflect the new versions of hardware, software or documentation for a new system baseline.

· Maintain a library with an archive of each version of the system baseline including executable(s), source code, make files, hardware configuration and documentation.

· Conduct internal audits in conjunction with the Quality Manager in preparation for formal audit reviews.

3.3.1.3 TECHICAL LEAD

The technical lead will manage the development and implementation of approved requirements and changes in the system. The technical lead will:

· Provide the team lead with a schedule for implementing the new baseline requirements.

· Coordinate tasking of development personnel.

· Provide development progress reports to the team lead.

· Ensure thorough unit level testing of software is performed.

· Review reports of test results with developers and testers.

· Coordinate system level integration testing.

· Develop or update the system test plan.

3.3.1.4 USER REPRENTATIVE

The user representative will provide user requirements for the system. The user representative will:

· Define user requirements.

· Assign user priorities to requirements.

· Provide inputs on the system operation and user interface.

· Provide user input on the system implementation at design reviews and technical interface meetings.

· Identify and report operational problems and deficiencies.

· Attend requirements, stakeholder and CCB meetings.

3.3.1.5 SYSADMIN REPRESENTATIVE

The Sys Admin representative will provide support for the deployment of system changes. The Sys Admin representative will:

· Provide a schedule and status on the deployment of hardware and software.

· Perform, as required, hardware installations and initial setup.

· Install and securitize the Operating System (OS).

· Maintain the system’s upgrade, patch and security posture IAW the System Security Authorization Agreement (SSAA).

· Install Commercial Off The Shelf (COTS) and system application software.

· Fix problems and issues with system computers.

· Attend requirements, stakeholder and CCB meetings.

· Make recommendations for IA/IAVA compliance.

3.3.1.6 SYSTEM TESTER

The system tester will identify and document failures and issues found in the application software. The system tester should not be a system developer. The tester will:

· Execute the system test plan.

· Identify and report discrepancies and shortfalls in the test plan.

· Document failures and the conditions of failure identified during testing.

· Generate a formal report of test results.

· Enter each test failure in the CR database with a unique CR number.

· Coordinate with the technical lead on failed tests.

3.3.1.7 QUALITY MANAGER

The quality assurance manager will ensure that processes are documented and followed and that documentation is accurate and complete. The Quality Manger (QM) will be responsible for ensuring traceability of all design elements to system requirements and also that there is a test for every design element. The quality manager will also evaluate the application source code against coding standards to ensure the code is consistent and documented. The quality assurance manager will:

· Ensure documents are accurate and complete.

· Ensure software adheres to the coding standard.

· Ensure processes are documented and followed.

· Ensure data products are valid.

· Ensure traceability between requirements and design and test elements.

· Ensure testing is thorough and test results are documented.

· Conduct internal audits in conjunction with the CM Manager in preparation for formal audit reviews.

3.3.1.8 CUSTOMER REPRESENTATIVE

The customer representative will provide requirements and in many cases, the funding to implement the requirements. The customer representative, in many cases, also defines the needed timeline or schedule for the implementation of an enhancement or capability. The customer representative will be included in requirements and stakeholder meetings. The customer may attend some or all of the CCB meetings. The customer representative will:

· Provide customer requirements at stakeholder meetings.

· Provide customer input on the system implementation at design reviews and technical interface meetings.

· Attend programmatic status meetings.

· Attend CCB meetings when requested.

3.3.1.9 SECURITY REPRESENTATIVE

The security representative will assess the security impact of proposed system changes and provide guidance on corrective actions to eliminate security issues. The security representative will:

· Provide guidance and direction on security issues.

· Support updates to security accreditation packages.

· Support the Interim Authority to Operate, Interim Authority to Test and Authority to Operate (IATO/IATT/ATO) accreditation process.

· Attend CCB meetings when requested.

3.3.2 CCB MEETINGS

CCB meetings provide the forum where the various individuals who play a role in development and sustainment of a system can discuss the “state” of the system and the changes that are needed or planned for the system.

The following items will be addressed at the CCB meetings.

· Development status and schedule.

· Status of testing; system or ATP.

· Status of hardware or software deployments.

· Review status of document updates.

· Review CI Database to identify needed CI versioning changes.

· Review TRs and CRs.

· Review operational issues.

· Review open action items.

· Identify and document new action items.

Refer to the SharePoint CM Page for the CCB Meeting Agenda and CCB Meeting Minutes templates and the link to CCB action item database.

3.4 CM TOOLS

CM tools are used to help capture the state of the current system baseline and to maintain a record of previous baselines in case the configuration must be “rolled back” to a prior version. The CM tools used for CM include:

· CI Database

· CR Database

· FAM Approved Software Revision Control Systems which include:

· CS-RCS Revision Control System (RCS)

· D-Oxygen

· Lumension Device Control

· Lumension Application Control

· Bug Collector

· TrackIt

3.4.1 CI DATABASE

The CI Database is used to capture and track the state or configuration of a system including hardware, software and documentation. The CI Database contains information on all system CI’s and will be updated each time a new system change or release is performed. Any appropriate database may be used to store CI”s.

3.4.2 CR DATABASE

The CR Database is used to capture requested changes and identified system bugs. The CR Database is used to log change requests and system bugs identified by TRs, customers, user CRs and system testing. Any appropriate database may be used to store CRs.

3.4.3 SOFTWARE REVISION CONTROL

The software revision control system is used to manage the versioning of system software configuration items including CSCIs and CUs. The software revision control system will create a software build based on a “tagged” version of the CSCIs and CUs. All versions for each of the CSCIs and CU’s for a software build will also be entered into and tracked in a CI Database.

3.5 CM AUDITS

CM audits will be performed by personnel that are independent of the system being evaluated. The purpose of CM audits is to periodically verify that a team’s CM process is documented and being followed and that documents and information are being updated to reflect the current state of the system in hardware, software and documentation.

At the conclusion of an audit, an audit report will be produced by the CM Manager to summarize the discrepancies and the corrective actions that will be implemented.

3.5.1 CM PROCESS AUDITS

Audits will be performed on a regular basis. The audit checklist is provided under the CM section on the ATR SharePoint site. Audits will be performed to verify the following:

· CM Processes are documented, current and being followed.

· All required documentation is present.

· Project and SE documentation reflect system baselines.

· CI database entries reflect system baselines.

· CR database entries reflect changes to baselines.

· Software versioning reflects the system baselines.

· Data management processes are being followed.

3.5.2 CONFIGURATION AUDITS

The team lead and CM manager will coordinate the functional, physical and software configuration reviews and audits for their system. Audit results will be documented and archived. Action items identified from reviews and audits will be tracked and resolved.

3.5.2.1 FUNCTIONAL CONFIGURATION AUDITS

Functional Configuration Audits (FCA) will be performed to verify a system baseline implements all of the functional capabilities needed to meet the requirements defined in the SRD and to verify that each function is being validated and tested. A FCA will verify traceability between system requirements, implemented system functions and unit test elements. A FCA is usually performed prior to the establishment of the initial baseline and whenever a new baseline is established.

3.5.2.2 PHYSICAL CONFIGURATION AUDITS

Physical Configuration Audits (PCA) will be performed to verify that the “as built” configuration for all of the system’s hardware CIs corresponds to the information defined in the CI database. An inventory of the system hardware and its configuration will be performed during a PCA. A PCA will be performed at least once every twelve months.

3.5.2.3 SOFTWARE BASELINE AUDITS

Software audits will be performed each time a new baseline is released to verify the new baseline contains the correct versions of all software CIs and that the CI versions correspond to the information documented in the CI database. A review of the test results will be conducted.

3.6 DATA MANAGEMENT

Data management will ensure all information associated with the development and implementation of each system baseline is captured and archived and will allow a particular system baseline to be recovered or reinstalled at any given time. Data management includes:

· Data Back-up

· Data Archive

· Disaster Recovery

3.6.1 DATA BACKUP

Data backup is a process where information is duplicated and stored on media to ensure data and information is not lost.

Data backups should be done at least on a weekly basis or as new configuration items are checked in. Recovery tools will allow the backed up information to be retrieved based on a designated file name and date.

3.6.2 DATA ARCHIVE

The source code, executable, make files, and system documentation including all project and SE documentation will be copied to unchangeable media upon the release of a new system baseline. The unchangeable media will be marked with the release system name, version number and date and stored in a fireproof vault, remote backup location, or at an off-site location. Archived information will be kept for the life of the system.

The developmental source code and system documentation will be copied to unchangeable media at least once a month which will be marked as backup along with the system name and date.

3.6.3 DISASTER RECOVERY

Disaster recovery will be performed using the copies of the archived system information that was placed in the fireproof safe, remote backup location, or off-site location. Before restoring a file from the archive, a copy of the unchangeable media will be made and the original will be placed back into the archive location.

Data recovery will be made from the copy of the archived media. Once the server and storage environment has been restored then the information from the copy of the archived media will loaded on the system.

3.7 TRAINING

CM training is recommended for at least the team CCB and CM manager positions. Training will be provided on the CM practices, procedures, and standards implemented in this CMP and on the effective use of the CM tools. Table 1 below describes the recommended training for the CM and CCB Managers.

Table 1: CM Training Matrix

ATR CM Team

CM Manager

CM Manager

ATR CM Team

ATR CM Team

ATR CM Team

4.0 ACRONYMS

Distribution Statement D: Distribution authorized to Department of Defense and U.S. DoD contractors for Administrative or Operational Use, (12 June, 2005). Other requests for this document shall be referred to NAWCAD Code 524000A, Range Instrumentation Division, 23013 Cedar Point Road, Patuxent River, MD 20670, DSN 342-9609.

Distribution Statement D: Distribution authorized to Department of Defense and U.S. DoD contractors for Administrative or Operational Use, (1 July, 2010). Other requests for this document shall be referred to NAWCAD Code 524000A, Range Instrumentation Division, 23013 Cedar Point Road, Patuxent River, MD 20670, DSN 342-9609.