Attachment 9 - OST Configuration Management Plan.pdf

Configuration Management Plan

(CMP)

For Office of Security Capabilities / Integrated Logistics Support

Version D

July 23, 2013

Plan

CHANGE HISTORY PAGE

The following table records changes to the Configuration Management Plan.

DATE REVISION PREPARED

BY

COMMENTS/TYPE OF CHANGE

August 07, 2013 D M. McElyea Included language for Developmental CM requirements and processes.

May 19, 2011 C M. McElyea Added language that is applicable for the developmental processes required for TSIF qualification and evaluation.

January 10, 2011

C

M. McElyea

Replaced CMIS with TSA approved electronic database, added roles for CM Functional Lead and CCB Stakeholders, and updated CO’s role.

June 15, 2009

B

G. White

Changes required to support CM planning, the addition of CMIS, TSIF, AD-102 and to address government comments.

24 January 2008 Draft Revision

G. White

5 November 2007 A All This plan supersedes any and all documents of a CM planning nature previously in place for OSC.

12 January 2007 Draft Revision

All

3 November 2005 Initial Release All This plan supersedes any and all documents of a CM planning nature previously in place for OSC.

Configuration Management Plan July 23, 2013

TABLE OF CONTENTS

Change History Page

Table of Contents

List of Table

List of Figures

1.0 PURPOSE

2.0 Introduction

3.0 Scope

4.0 References

5.0 Configuration Management Processes

5.1 Configuration Management Planning

5.1.1 Background

5.1.2 Planning

5.1.3 Configuration Management in the TSA OSC TSIF Developmental Test and Evaluation Processes

5.1.3.1 Scope of Test and Evaluation Activities Applicable to the TSIF

5.1.3.2 Developmental CM Audit Requirements from Vendors

5.1.3.3 Developmental CM Control

5.1.4 Configuration Control Board (CCB) Stakeholders and Process

5.1.5 CCB Responsibilities

5.1.6 Implementation Procedures

5.1.7 Training

5.1.8 OSC Performance Measures

5.1.9 Configuration Management by OEMs

5.1.10 Information and Records Management

5.1.11 Data Preservation

5.2 Configuration Identification

5.2.1 Documentation of Product Configuration

5.2.2 Configuration Item (CI) Definition

5.2.3 CI Characteristics

5.2.4 Identifying Products and Product Configuration Information

5.2.5 Configuration Baselines

5.3 Configuration Change Management

5.3.1 Change Request Process

5.3.2 Types of CRs

5.3.2.1 Engineering Change Proposal

5.3.2.2 Request for Deviation

5.3.2.3 Request for Waiver

5.3.2.4 Developmental Deviation

5.3.3 Initiation of Change

5.3.4 Evaluation of CRs

5.3.5 Change Implementation and Verification

5.4 Configuration Status Accounting

5.4.1 CSA Information

5.4.2 CSA System

5.5 Configuration Verification and Audits

5.5.1 Quality Conformance Verification Audits

5.5.2 Configuration Management Process Surveillance

5.6 Configuration Management in the Equipment Qualification Process

5.6.1 Qualification

5.6.2 Developmental CM Control

Appendix A – Acronyms

Appendix B – Definitions

Appendix C – Vendor CDRLs

List of Table

Table 1 – Types of CRs

List of Figures

Figure 1 – Basic Configuration Management Processes …………….………………………………………………………….…6

Figure 2 – TSA / OSC Product Life cycle ............................................................................................... ……….8

Figure 3 – Change Request Process

1.0 PURPOSE

This Configuration Management Plan (CMP) defines the Configuration Management (CM) processes and procedures used throughout the life cycle of Transportation Security Equipment (TSE) developed, integrated, acquired, deployed, and maintained by the Transportation Security Administration (TSA) Office of Security Capabilities (OSC). The processes and procedures covered in this CMP apply to internal OSC CM activities as well as CM activities performed by Original Equipment Manufacturers (OEMs).

2.0 INTRODUCTION

The mission of the TSA is to protect the nation’s transportation systems to ensure freedom of movement for people and commerce. The Office of Security Capabilities contributes to the TSA mission through development, certification, qualification, approval, integration, acquirement, deployment, and maintaining security technologies to ensure the safety and security of the nation’s transportation system.

The challenge from a CM perspective is to ensure effective integration of the CM activities performed by the security technologies developers (generally referred to as “vendors” or “OEMs” in this document), the Transportation Security Laboratory (TSL), the OSC TSA Systems Integration Facility (TSIF), and the other CM activities managed and overseen by OSC. This CMP defines the OSC’s CM program and establishes the framework to manage an effective integration.

3.0 SCOPE

This CMP applies to all TSE hardware, firmware, software, documentation, testing, and design artifacts that are produced throughout the OSC product life cycle. Integrated Logistics Support (ILS) has total life cycle responsibilities and receives certain assistance (threat/detection impacts) from the TSL and/or the TSIF.

The objectives of CM are: to identify and document the functional and physical characteristics of selected system components designated as Configuration Items (CIs), control changes to CIs and their related technical documentation, record and report information needed to manage CIs effectively, ensure that the complex aggregate of CIs meets the system specified and operational requirements, and verify actual product configuration against required attributes.

4.0 REFERENCES

MIL-STD-973, Military Standard Configuration Management, Notice 3, 13 January 1995

OSC Test and Evaluation Guidebook (Version 2.0, March 28, 2011)

OSC Configuration Audit Procedure, (Version C, August 07, 2013)

OSC Configuration Control Board Procedure, (Version C, August 18, 2013)

5.0 CONFIGURATION MANAGEMENT PROCESSES

CM is a management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design and operational information throughout its life.

Each of the processes depicted in Figure 1 is covered in the sections that follow. Detailed procedures required to carry-out CM processes are referenced in the appropriate sections. The intent of this section is to provide the overall framework for how CM will be performed across the entire life cycle regardless of the technology.

OST

Processes

Configuration Identification

CM Planning

Management

Configuration Status Accounting

(CSA)

Configuration Verification

& Audit

Configuration Change

Management

• CM Policy & Procedures

• Establish Baselines

• CCB Charter & Operating Procedures

• CM Plans

• Functional (FCA)

• Physical (PCA)

• Certified/ Qualified

• Product

• Configuration Control Board

• OEM Change Requests

• Stakeholder Distribution

• CCB Disposition

• Contract Officer Approval

• OEM & Stakeholder Notification

• Product Configuration Information & related CM information

• Product Configuration Verification

• Product Configuration Information Verification

• Baseline performance attributes

• Design Attributes

Configuration Management Plan

• Capture

• Record

• Safeguard

• Validate

• Disseminate

• Protect

Figure 1 – Basic Configuration Management Processes

5.1 Configuration Management Planning

Configuration management planning activities include planning for and selecting key actions to implement and measure the effectiveness of configuration identification, control, status accounting and audits, throughout the program life cycle.

This section defines the CM program for the TSA OSC, its support staff and affiliated TSA organizations. Monitoring the performance of CM activities against this CMP identifies opportunities for improving OSC CM processes.

Effective configuration management planning over the product life cycle is essential to effective CM functions.

5.1.1 Background

OSC provides for the acquisition, deployment, integration, control, training and maintenance of TSE for current and future Department of Homeland Security (DHS) requirements. Within the OSC organization, CM manages, tracks, and controls the configuration of TSE, including hardware and software inventories. This is primarily done through the establishment and control of configuration baselines that begins during the developmental or qualification test phases of the acquisitions process. A baseline is a controlled set of products and/or components (for example, hardware, software, firmware, engineering data, and documentation) that describes a system or configurable elements of that system. In addition to the technologies and programs implemented by the OSC, Configuration Management Plan

CM Processes

CM Planning

Management

Configuration Identification

Configuration Change

Management

Configuration Status Accounting

Configuration Verification &

Audit other systems and products used in installation, integration, testing, and life cycle support of security technologies may be subject to CM practices outlined in this CMP. OSC oversees and manages CM activities performed internally and by a variety of OEMs over the course of the product life cycle. CM planning begins immediately following program authorization. Figure 2 illustrates TSA OSC Acquisition Life Cycle processes. OSC also has a role in integrating, testing, and evaluating technologies, processes, and applications prior to airport deployment utilizing the Transportation Security Integration Facility (TSIF). This requires involvement of TSA personnel early on in the CM life cycle.

* Programs have the option to tailor acquisitions phases per program requirements.

Figure 2 - Acquisition Life Cycle Processes

The acquisition management process of DHS is the means by which the Department and its subordinate entities execute each phase of the acquisition life cycle:

• Identify a capability Need of the Department, including Components

• Analyze and Select the means to provide that capability

• Obtain the capability

• Produce, Deploy and Support the capability through its useful life until disposal

Only products that are deemed production and deployment ready via Certification, Qualification or successful operational testing are purchased and deployed by OSC. Achieving this Certification or Qualification Baseline, both of which are considered Developmental Product Baselines (DPBs), can be an iterative process. A Developmental CM Audit is required to adequately characterize a candidate system before TSA testing is permitted. For this reason, the TSL and the TSIF each maintain Developmental CM processes to ensure the validity of their certification and/or test and evaluation results. After establishing a DPB, vendors may not make changes to systems under test without government approval of their submitted Developmental Deviations (DEPs), which describe their proposed change requests. The DPB supports AD-102 milestone decisions, such as entry to Operational Test and Evaluation (OT&E) and the eventual procurement decision. When a product is Certified or Qualified and successful OT&E has been completed, a procurement contract with the vendor may be executed by OSC. The first production unit resulting from this contract represents the First Article Unit. A First Article Test &

Evaluation (FAT&E) is conducted by OSC. Upon successful completion of the FAT&E, Functional and Physical Configuration Audits are performed by LCS to establish the Product Baseline. Vendor Change Requests (CRs) in the form of Engineering Change Proposals (ECPs), if approved by OSC, may modify the baseline to create a new Product Baseline over the course of execution of the contract. Throughout the course of this process, the vendor has responsibility for CM execution for their product in accordance with contractual requirements.

Key characteristics for the OSC CM environment are:

• Baselines include Certification or Qualification Baseline and Product Baseline

• Multiple OEMs and contracts

• Dispersed equipment locations

5.1.2 Planning

This section defines the OSC CM program that will be followed by its employees, support staff, and affiliated TSA organizations. This CMP shall serve as a guideline for Vendor’s CM process development. Any exception to this plan must be through the use of a waiver reviewed by the OSC Configuration Control Board (CCB) and approved by the OSC CM Functional Lead or designee.

Figure 2 – Developmental CM Processes

5.1.3 Configuration Management in the TSA OSC TSIF Developmental Test and Evaluation Processes

1) The Configuration Management Specialist will collaborate with TSIF and TSL test leads and the OEM to select CIs and establish baseline for testing. The Configuration Management Specialist will maintain this baseline throughout the developmental process and all future Developmental

OSC Developmental CM

O&M ECPs

FAT&E

FCA/

PCA

DEPs

TSL testing

TSIF testing OT&E DEPs

New System

1 2 3

FOT&E

Change Requests will be processed against it. Differences between “as built” and “as documented” configurations are noted and provided to technology COR to resolve with OEM.

2) SRR conducted to determine readiness for OT&E. If a go, ILS CM conducts audit to establish testing baseline using TSIF baseline as modified by approved DEPs. Configuration audits will take place at OT&E location. Differences between “as built” and “as documented” configurations are noted and provided to technology COR to resolve with OEM.

3) ILS CM coordinates with TSIF, OT&E and all stakeholders to establish CIs for the production baseline (PBL). The PBL may contain different CIs than previous testing baselines. Following FAT&E, ILS CM conducts FCA/ PCA to establish the PBL using the OT&E baseline as modified by approved DEPs. Differences between “as built” and “as documented” are noted and provided to technology COR to resolve with OEM. All subsequent configuration change requests are processed as ECPs through the OSC CCB. Differences found with the PBL may result in a failed PCA. The PMO will be notified of the results of the PCA via the OSC Physical Configuration Audit Certification Package.

5.1.3.1 Scope of Test and Evaluation Activities Applicable to the TSIF

The OSC Test and Evaluation Guidebook (Version 2.0, March 28, 2011) describes the overall activities that comprise Integrated Test and Evaluation (IT&E) at TSA. TSL and other contracted laboratories typically conduct qualification of explosive detection systems for TSA, which are then certified or qualified by TSL if successful. The TSIF was established by the TSA to cover a broad and growing array of testing needs to support current and potential future TSA Mission Requirements. The overall term to cover this variety of activities to be carried out at the TSL, TSIF, and other contracted laboratories falls under the general category of Developmental Test and Evaluation (DT&E) and are fully described in Section 4.0 of the OSC Test and Evaluation Guidebook. Many larger acquisitions require coordination between the TSL, the TSIF, and possibly additional laboratories to complete the full range of DT&E, but acquisitions for technologies that do not include TSL explosives detection Certification are primarily completed at the TSIF.

Regardless of the nature of specific test and evaluation activity, the DT&E process requirements will be completed by qualified personnel at the TSIF. Another requirement for TSIF DT&E is that some form of configuration audit, as applicable to the system’s stage of developmental maturity, must be conducted prior to the start of DT&E record testing. In the case of experimental equipment still in early stages of development or a special non-procurement contract, a more limited Test Characterization Check (TCC) may be performed according to the TSIF CM process in lieu of the full configuration audit, until the equipment reaches the appropriate stage of maturity.

5.1.3.2 Developmental CM Audit Requirements from Vendors

Vendor requirements for developmental test and related activities like CM are typically outlined in Requests for Proposals (RFPs) or other contractual vehicles. The Contracting Officer or other designee coordinates with the OSC developmental CM team for applicable CM requirements and guidance to be communicated in the RFP (or other contractual vehicle). Initial CM coordination for contractual inputs begins shortly after successful completion of AD-102 ADE 1. This requirement is also supported in the Test and Evaluation Master Plan (TEMP) and the SET processes. The vendors of submitted equipment will be held responsible for submitting the following documentation prior to conducting the pre-audit review process:

* Vendor Suggested Developmental Configuration Item List

* Drawing Tree or Index Drawing

High-level Engineering Drawing of the System Under Test Sufficient Engineering Drawings to identify all Configuration Items See OSC Configuration Audit Procedure, (Version C, August 07, 2013) for detailed information.

* Bill of Materials

All drawings will be uniquely identified and follow the vendor's controlled Configuration Management and Quality standards. The government CM Auditor should be able to identify each configuration item based on the drawings provided by the vendor.

During the pre-audit review, vendor suggested CILs are compared against expected lists of functional requirements or parts recommended by government subject matter experts. The final list is agreed to between the developmental CM auditors and the vendor, and is then converted into a Developmental Product Baseline Configuration Audit (DPBCA) list by the OSC CM lead. The audit is then conducted against this developmental baseline.

Any changes to the system under test, configuration items from the baseline, or associated drawings after the initial Developmental CM Audit shall be documented in a DEP and submitted to the Contracting Officer or designee who forwards the documentation to the OSC Developmental CM Team for approval before the change is made to the system.

5.1.3.3 Developmental CM Control

Development CM is controlled by the Development Configuration Control Board (DCCB). Developmental Change Requests will be sent out to the stakeholders for review and a recommendation for disposition. All stakeholder comments will be consolidated and a disposition from the DCCB will be made. When extensive test programs require test activities at more than one lab, the DCCB will be coordinated between the participating labs. The OSC Developmental CM Group will maintain a history of approved changes for each system under test. The history of change against the DPBCA list will be the basis used to construct the production Master Configuration Item List

(MCIL).

The change history should maintain the details of:

* All parts that were changed during the review process.

* When the parts were changed.

* Disposition of the change request

* Relevant information concerning evaluation and findings of approved changes.

5.1.4 Configuration Control Board (CCB) Stakeholders and Process

The CCB is responsible for evaluating and approving changes affecting any hardware, firmware or software system baseline of acquired and deployed TSE. The CCB ensures the system configuration remains in agreement with the approved configuration baseline, the Configuration Status Accounting (CSA) database is current, and configuration control is being exercised effectively. The CCB oversees implementing the CMP according to government and industry standards. Agendas and minutes are documented and published for all CCB meetings, and all issues will be tracked to closure. Detailed responsibilities for CCB activities may be found in the 2600.3.1-l.2 CCB Charter and 2600.3.1-l.3 CCB Procedure.

The CCB is chaired by the CM Functional Lead within LCS and is responsible for maintaining the CCB Charter and CCB Procedure. The CCB membership should consist of (positions or organizational representatives) as indicated below:

• Chairperson

• Contracting Officer

• TSIF

• Integration/Testing

• Product COTR

• Safety

• TSL

• Quality Assurance

• Integrated Logistics Support (ILS)

• Training (OTT)

• Engineering

• Office of Security Operations (OSO)

Comments against routine CRs are to be provided within 10 business days to the CCB Chairperson and two business days for urgent CRs. The Product COTR must receive approval from the CCB Chairperson to conduct an urgent walk-through process. Administrative or minor revisions to CRs are not re-distributed, but discussed at the CCB meeting.

In addition to CCBs held for all security technologies under acquisition contracts, TSL holds Engineering Review Boards (ERBs) to address changes proposed by vendors under Research and Development contracts. The TSIF also holds ERBs for Qualification and Developmental testing activities prior to Acquisition contract award. Both labs also help OSC CM determine whether regression testing is required on CRs presented to the CCB, before the CR is approved. Also, TSL and/or the TSIF provide the necessary documentation to OSC CM developed during the developmental/certification/qualification processes, such as the Developmental Product Baseline, as a starting point for ILS to develop the final Product Baseline.

The DCCB is chaired by the Development CM Specialist within ILS. The DCCB membership consists of (positions or organizational representatives) as indicated below:

• Chairperson

• Contracting Officer

• TSIF

• Integration/Testing

• Product COTR

• Safety

• PMO Portfolio Manager

• Acceptance Test Team

• TSL

• Quality Assurance

• Operational Test Section

• Training (OTT)

• Engineering

• Office of Security Operations (OSO)

• PMO Engineering Representative

5.1.5 CCB Responsibilities

CM responsibility is divided among the following roles:

• OSC Integrated Logistics Support Manager

This individual is responsible for establishing CM guidance consistent with DHS and TSA policy.

• OSC Integrated Logistics Support CM Functional Lead

As the CCB chairperson, the OSC CM Functional Lead is responsible for coordinating CCB activities and acting as the signatory for the disposition of each CR provided by the CCB. At the recommendation of the CCB, the CM Functional Lead signs and provides the official disposition on CRs that do not impact contract cost or scope.

• Configuration Management Specialist. This individual is responsible for creating and maintaining the configuration baselines used during the developmental process. The CM Specialist will process all developmental change requests, distribute to stakeholders, act as the developmental configuration control board chairman, and provide final disposition for all changes.

• Contracting Officer (CO)

Class I ECPs, Requests for Deviations (RFDs) and Requests for Waivers (RFWs) that impact contract cost or scope that have been approved by the CCB will be provided to the CO for contractual implementation.

The CO will notify the OEM of the official disposition of CRs and, if applicable, authorize the Vendor to take action.

• CCB Stakeholders

The stakeholders are a group of individuals that serve as subject matter experts from various disciplines (engineering, safety, integration, testing, quality assurance, logistics and training) who review and evaluate CRs from a technical perspective and provide their recommendations to the CCB Chairperson.

The CCB provides the final disposition for all CRs submitted to OSC.

• Contracting Officer Representative (COR)

Product CORs are responsible for conducting a technical review of CRs, presenting a description of CRs at the CCB, and providing disposition recommendations to the CCB. The Product COTR is the interface between the Program Management Office (PMO), Office of Acquisition, CCB, OEMs and the Integrated Product Team (IPT). The COTR is responsible for providing the PMO decision whether or not to proceed with CRs that require contract costs.

• ILS CM Support Staff

The CM support staff is responsible for coordinating and implementing CM activities under the guidance of the CM Functional Lead and the CCB.

• TSA Original Equipment Manufacturers (OEMs)

OEMs are responsible for following and implementing CM activities per their contracts. It is the responsibility of the project IPTs to document CM activities into Request for Proposals (RFP), Statement of Works (SOW) and specifications for TSE.

The ILS CM support staff interfaces with CCB members to conduct CM activities throughout the life cycle of the TSA-OSC program. CM activities related to configuration identification, baseline and change control are performed by all members of OSC under the guidance and support of CM.

5.1.6 Implementation Procedures

OSC Standard Operating Procedures (SOPs) have been developed to define how CM activities will be accomplished.

Current SOPs are listed below. Others will be added as necessary.

• 2600.3.1-l.1 Configuration Audit Procedure

This procedure defines the formal process for examination of the as-built configuration of a configuration item against its configuration item’s product baseline. The purpose of a configuration audit is to confirm that the as-delivered unit is compliant with its design documentation, Bill of Materials and engineering drawings.

• 2600.3.1-l.2 Configuration Control Board Charter

This procedure establishes the CCB that oversees the implementation of the OSC CMP according to government and industry standards.

• 2600.3.1-l.3 Configuration Control Board Procedure

This procedure defines the CCB membership and assigns process responsibilities. The CCB board is composed of technical and administrative representatives who recommend approval or disapproval of proposed ECPs to current approved configuration documentation. The CCB is also responsible for determining the disposition of RFDs and RFWs.

• 2600.3.1-l.4 Configuration Status Accounting Procedure

This document defines the procedure for CSA. CSA is the process of creating and organizing the knowledge base necessary for CM. The purpose of a Configuration Status Accounting Report (CSAR) is to provide a highly reliable source of configuration information and metrics to support TSA-OSC project activities. Such as:

o Configuration Change Status o Track Configuration Items o Install and removal History o Effectivity Status

5.1.7 Training

Training for Government and CM support staff personnel can be scheduled through the CCB Chairperson on CM procedures and the use of the TSA approved electronic database.

5.1.8 OSC Performance Measures

OSC performance measures are developed by the ILS office to assess the effectiveness of CM functions. Examples of CM metrics include:

• Configuration Change Management o CCB processing times o Number of CRs (ECPs, RFDs and RFWs) o Number of CRs by OEM, Technology, COTR o Number of urgent vs. routine CRs by OEM, Technology, COTR o Number of initial vs. revised CRs by OEM, Technology, COTR o Number of revisions by revision rationale

• TSA approved electronic database o Number of records entered into the database (note, one transaction in the database could trigger multiple records)

5.1.9 Configuration Management by OEMs

OSC will include CM guidance in all contracts for acquisition of systems or for contracts involving CM responsibility.

This will include CM activities in developmental and qualification phases of the acquisition process, in addition to post award phase activities. Each contract deliverable shall be in compliance with the SOW and Contract Data Requirements List (CDRL). Document deliverables shall also have Data Item Description (DID) guidance. OEMs are responsible for following CM guidance in their contracts, which could include, but not be limited to:

• CM Plan (CMP)

• Master Configuration Item Listing (MCIL)

• Developmental Deviations (DEP)

• Engineering Change Proposal (ECP)

• Request for Deviation (RFD)

• Request for Waiver (RFW)

• Configuration Status Accounting Report (CSAR)

• Configuration Audit Plan (CAP)

• Configuration Audit Summary Report (CASR)

OEMs implement configuration management in accordance with the requirements of the contract SOW and CDRLs (see Appendix C). OEMs are not permitted to change or update established product baselines without CCB approval. The OSC LCS CM Functional Lead, COTRs and CM support staff will monitor vendor CM activities. OSC will include CM Guidance and provisions for developmental/qualification phase CM in the Request for Proposal (RFP) or applicable contract vehicle, since the SOW and CDRLs are written for post contract award CM deliverables.

5.1.10 Information and Records Management

The TSA approved electronic database is the information management system established to satisfy OSC CM requirements. This database supports the configuration, engineering, and data management functions of the OSC community through the OSC Configuration Management portal on the TSA iShare intranet platform. The database supports CSA activities such as recording and reporting on Product Baselines (PBL) and CR processing status. This database also provides for real-time data collection and reporting.

The TSA approved electronic database also serves as a repository for the following:

• All CRs

• CR retrofit and production effectivities

• CR implementation status

• RFD expiration information

• Baseline status

• CM policies and procedures

The OSC ILS CM Functional Lead establishes user privileges for the database.

The iShare platform provides all the security required for recording and processing Sensitive Security Information (SSI). SSI shall be controlled and marked in accordance with government guidance.

5.1.11 Data Preservation

CM information management will comply with TSA records management and National Archives and Records Administration (NARA) guidelines for federal records disposition. All CM data resides within the TSA approved electronic database. A backup of all applicable CM data is maintained.

5.2 Configuration Identification

Configuration Identification is the activity that encompasses 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 with equipment options; the release of CIs and their associated configuration documentation; and the establishment of configuration baselines for CIs.

5.2.1 Documentation of Product Configuration

Configuration documentation (for example product specifications) defines the functional, performance, and physical attributes of a product. The product composition, i.e., relationship and quantity of parts that comprise the product, can be determined from its configuration documentation.

5.2.2 Configuration Item (CI) Definition

Once a product is declared a CI initially in the Developmental CM stage, it will be identified, controlled, and tracked throughout its product lifecycle by TSL and TSA OSC. OSC maintains the two levels of CI control:

• System-level – e.g. CTX-9800

• Component level – hardware, software and system documentation groupings

5.2.3 CI Characteristics

CI characteristics will be documented in sufficient detail so that the content, status and previous revisions or versions of each CI are maintained.

5.2.4 Identifying Products and Product Configuration Information

OEMs assign unique identifiers in which:

• One product can be distinguished from other products

• One configuration of a product can be distinguished from another

• The source of a product can be determined

• The correct product information can be retrieved

OEMs assign unique unit identifiers (for example, serial numbers) to individual units of a product when there is a need to distinguish one unit of the product from another. Unique product group identifiers (for example, manufacturers’ part numbers) will be assigned to a series of like units of a product when it is unnecessary to identify individual units. Standard identification information will be placed on all product-related documentation. Standard procedures will be followed for file names, accession numbers, and other topics as developed.

5.2.5 Configuration Baselines

A baseline is a description of the attributes of a product which is established at a point in time. It provides a known configuration to which changes are addressed. The configuration of any product, or any document, plus the approved changes to be incorporated is the current baseline. A baseline establishes a standard configuration to which, barring an approved variance, products must adhere to. A DBP is established prior to TSA Developmental and Qualification Testing, and controls the baseline of each system under test prior to contract award. A PBL is established after contract award and following the completion of functional and physical configuration audits. In some specialized acquisitions, it may be necessary to establish additional, more limited baselines. Once established, baselines may only be changed with appropriate government approval.

5.3 Configuration Change Management

Configuration Change Management is:

• A systematic process that ensures that changes to released configuration documentation are properly identified, documented, evaluated for impact, approved by an appropriate level of authority, incorporated, and verified.

• The systematic proposal, justification, evaluation, coordination, and disposition of proposed changes; and the implementation of all approved and released changes into (a) the applicable configurations of a product, (b) associated product information, and (c) supporting and interfacing products and their associated product information.

The CCB manages the control and processing of changes to a CI, regardless of the type of product. Baselines may be changed only with an approved ECP. Each ECP is uniquely identified and is processed by the CCB and is maintained within TSA’s database.

5.3.1 Change Request Process

OSC CRs follow the established change request process as illustrated in Figure 3.

CR

Submission

Screening & Distrib. for Comment

Analysis Responses

CM Support StakeholdersSupplier

CCB

Review & Decision

CO Approval/ Disapproval

Letter

On Hold

CCB

Decision Notification Distribution

CM Support

Approved.

Chg. Imple-mentation

Status Notification

SupplierSupplier CO

DEP

Submission

ERB

Technical Evaluation

ERBSupplier (Dev. Deviation)

Yes

No

No

Figure 3 – Change Request Process

5.3.2 Types of CRs

Table 1 below provides the definition of the various types of CRs.

• Engineering Change Proposal (ECP)

• Request for Deviation (RFD)

• Request for Waiver (RFW)

• Developmental Deviation (DEP)

Table 1 – Types of CRs

5.3.2.1 Engineering Change Proposal

ECPs are requests to incorporate a permanent change to product configuration, which may produce an updated baseline. The TSA approved electronic database is used as the CM control vehicle to capture information needed to process the proposed change to a baselined CI. ECPs provide supporting data, where necessary, to support the change description and justify the need for the change. This can include references to test data, analyses and other technical documentation providing supporting rationale for assertions made in the change request. ECPs will be classified as Class I or Class II. ECPs should be reviewed and either approved, disapproved or deferred by the CCB.

Class I Engineering Change Proposals definition:

• DD Form 1692 filled out in its entirety

• Correct deficiencies

• Add or modify interface or interoperability requirements

• Make a significant and measureable effectiveness change in the operational capabilities or logistics supportability of the system or item

• Effect substantial life cycle costs /savings

• Minimize slippage in an approved production schedule

Class II Engineering Change Proposals definition:

• DD Form 1692, minimum first page

• Does not affect form, fit or function

• Does not affect cost, schedule or performance

• Impacts none of the Class I factors

5.3.2.2 Request for Deviation

RFDs are requests to temporarily incorporate a known departure from product requirements. Authorized deviations are a temporary departure from requirements and do not constitute a permanent change. RFDs must

Engineering Change Proposal (ECP)

Request for Deviation

(RFD)

Request for Waiver

(RFW)

Developmental Deviation (DEP)

• Permanent change to the product configuration.

• Creates a new baseline configuration.

• Temporary known departure from product requirements w/actions to restore to original configuration.

• Does not constitute a permanent change to the system.

• Does not constitute a change to the baseline configuration.

• Known departure from product requirements for specific quantities of product.

• Can constitute a change to the baseline configuration.

• Request for product evaluation and change prior to establishment of the product baseline.

state actions to be taken at the end of the temporary deviation (e.g., restoration to original configuration). RFDs may also be utilized for a permanent one-time variance. An example would be extending a power cord from 10 feet to 20 feet at one location and not for all deployed systems. Training simulators shall utilize the walk-through CCB process, Section 3.1.4 of this Plan, in order to grant expedited approval.

RFDs will be classified as Minor, Major, or Critical. RFDs should be reviewed and either approved or disapproved by the CCB in a timely manner.

Minor - A deviation shall be designated as minor when:

• The deviation consists of a departure which does not involve any of the factors listed in 5.4.3.3.3 or

5.4.3.3.2 of MIL-STD-973.

• When the configuration documentation defining the requirements for the item classifies defects in requirements and the deviations consist of a departure from a requirement classified as minor.

Major - A deviation shall be designated as major when:

• The deviation consists of a departure involving health, performance, interchangeability, reliability, survivability, maintainability, or durability of the item or its repair parts, effective use or operation, weight and size appearance (when a factor).

• When the configuration documentation defining the requirements for the item classifies defects in requirements and the deviations consist of a departure from a requirement classified as major.

Critical - A deviation shall be designated as critical when:

• The deviation consists of a departure involving safety.

• When the configuration documentation defining the requirements for the item classifies defects in requirements the deviations consist of a departure from a requirement classified as critical.

5.3.2.3 Request for Waiver

RFWs are requests to incorporate a known departure from product requirements. Authorized waivers are for specific quantities of a product and constitute a change to the baseline configuration or its documentation.

RFWs will be classified as Minor, Major, or Critical. RFWs should be reviewed and either approved or disapproved by the CCB in a timely manner.

Minor - A waiver shall be designated as minor when:

• The waiver consists of acceptance of an item having a nonconformance with contract or configuration documentation which does not involve any of the factors listed in 5.4.4.3.3 or 5.4.4.3.2 in MIL-STD 973.

• When the configuration documentation defining the requirements for the item classifies defects in requirements and the waivers consist of a departure from a requirement classified as minor.

Major - A waiver shall be designated as major when:

• The waiver consists of acceptance of an item having a nonconformance with contract or configuration documentation requirements involving health, performance, interchangeability, reliability, survivability, or maintainability of the item or its repair parts effective use or operation, weight, appearance (when a factor).

• When the configuration documentation defining the requirements for the item classifies defects in requirements and the waivers consist of a departure from a requirement classified as major.

Critical - A waiver shall be designated as critical when:

• The waiver consists of acceptance of an item having a nonconformance with contract or configuration documentation involving safety.

• When the configuration documentation defining the requirements for the item classifies defects in requirements and the waivers consist of a departure from a requirement classified as critical.

5.3.2.4 Developmental Deviation

CM principles must also be applied early in the development phase. DEPs are used to evaluate a Developmental Product Baseline (DPBL) change prior to the establishment of the PBL. Approved DEPs update the DPBL as it changes through testing and product qualification at the TSL, the TSIF, and OT&E.

5.3.3 Initiation of Change

Change initiation is the process of creating and classifying CRs. It consists of two steps: documenting the change and determining the classification of the change.

Changes represent opportunities for improvement. Desired changes are documented in the form of ECPs, RFDs, RFWs, or DEPs (reference Table 1), which are uniquely identified.

5.3.4 Evaluation of CRs

The CCB shall evaluate each CR and render a decision or disposition. Technical, support, schedule, and cost impacts of a CR shall be considered by each CCB Stakeholder before making a judgment as to whether the CR should be approved for implementation and incorporation in the product and its documentation. Change implementation does not take place without an approved CR. CRs that have a cost impact must have funding available by the Product COTR and facilitated by the CO.

5.3.5 Change Implementation and Verification

Change implementation involves the update and verification of all items and baseline documentation affected by an approved change. CRs will provide technical and planning information to support the implementation and verification of the proposed change. OSC will ensure the completion of all actions required for the implementation and verification of approved changes. This will include ensuring the consistency between the product, its documentation and its support elements. In cases where change implementation is approved for a CI that is already in the operational inventory, the coordination of additional management or logistical requirements may be needed. OSC will also ensure that all affected units of a CI and its associated configuration information are properly updated.

5.4 Configuration Status Accounting

CSA is the configuration management activity concerning capture and storage of, and access to, configuration information needed to manage products and product information effectively.

CSA is the process of creating and organizing the knowledge base necessary for the performance of CM. CSA provides an accurate and timely information base concerning a CI and its associated product configuration. CSA data will be consistent with needs of the users. CSA provides availability and retrievability of data consistent with the needs of the various users. CSA activities shall be performed in accordance with the best practices and guidance provided in 2600.3.1-l.4 Configuration Status Accounting Procedure.

Configuration information, appropriate to the product, is systematically recorded, safeguarded, validated, and disseminated. Configuration information content evolves and is captured over the product life cycle as tasks occur.

Standard, custom, and ad-hoc queries and reports may be generated from the TSA approved electronic database.

5.4.1 CSA Information

The CCB will ensure that configuration information is systematically recorded, safeguarded, validated, and disseminated. OSC will also ensure that access to CSA information is controlled. OSC will ensure that all system OEMs will maintain configuration data and provide CSA report and status reports in accordance with contractual requirements for all system implementations.

5.4.2 CSA System

OSC will determine requirements for an information system to collect and process CM information such that:

• OEMs will provide information regarding implementation of proposed and approved changes.

• LCS CM support staff will record and organize information about CM activity and will maintain change processing status information.

5.5 Configuration Verification and Audits

Configuration Verification and Audits ensure:

• A product’s requirements have been met through conduct of formal functional and physical configuration audits.

• The product design meeting those requirements is accurately documented before a product configuration is baselined.

The Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA) are performed using, 2600.3.1-l.1 Configuration Audit Procedure, to ensure that the developed product meets its requirements and that the developed product is adequately reflected in its configuration documentation. FCA and PCA are performed after a successful FAT&E. OSC LCS will approve the Product Baseline upon successful completion of the FCA and PCA.

Additional audits may be performed when significant changes result in Product Version Baselines.

5.5.1 Quality Conformance Verification Audits

LCS CM staff performs verification audits to determine that consistency between the product definition, the product’s configuration, and the CM records is being maintained throughout the product’s life cycle.

OSC will conduct a Quality Conformance Verification Audit on selected operational units, as necessary, to determine that a product’s design attributes are accurately reflected in the product definition information.

5.5.2 Configuration Management Process Surveillance

OSC will ensure that it maintains surveillance over the configuration management process in order to ensure that:

• The process is adequately documented.

• The process documentation is being followed.

• The process execution is in compliance with requirements.

5.6 Configuration Management in the Equipment Qualification Process

5.6.1 Qualification

Equipment that is purchased must be qualified for use by the TSA. The equipment qualification process will be completed by qualified personnel at the TSA Systems Integration Facility or the Transportation Security Laboratory.

Part of the system qualification process is to ensure that proper configuration management is being maintained on the equipment submitted to the TSA.

The vendors of submitted equipment should be held responsible for submitting the following documentation during the review process:

• Vendor Developmental Master Configuration Item List

• Drawings of Configuration Items

• Bill of Materials for serialized asset

• Request for Developmental Deviation (DEP)

All drawings should be uniquely identified and follow the vendor’s preselected Configuration Management and Quality standards. The qualifying party should be able to identify each configuration item based on the drawings provided by the vendor. Any changes to the serialized asset, configuration items, or associated drawings should be submitted to the qualifying party as a DEP, by the way of the Product COTR, before the change is made to the serialized asset.

5.6.2 Developmental CM Control

The qualifying party will be responsible to maintain a history of change for each product under review. The history of change against the Vendor Developmental Master Configuration Item List will be the basis that is used to construct the Production Master Configuration Item List (MCIL).

The change history should maintain the details of:

• All parts that were changed during the review process.

• When the parts were changed.

• Who reviewed and approved the change.

• All information concerning evaluation and findings of approved changes.

APPENDIX A – Acronyms

CAP Configuration Audit Plan CCB Configuration Control Board CDRL Contract Data Requirements List CI Configuration Item CM Configuration Management CMP Configuration Management Plan CO Contracting Officer COR Contracting Officer’s Representative CR Change Request CSA Configuration Status Accounting CSAR Configuration Status Accounting Report DEP Development Deviation (TSL only) DHS Department of Homeland Security DID Data Item Description ECP Engineering Change Proposal ERB Engineering Review Board FCA Functional Configuration Audit FAT&E First Article Test and Evaluation ILS Integrated Logistics Support IPT Integrated Product Team MCIL Master Configuration Item List NARA National Archives and Records Administration OEM Original Equipment Manufacturer OSC Office of Security Capabilities OT&E Operational Test and Evaluation PBL Product Baseline PCA Physical Configuration Audit PMO Program Management Office RFD Request for Deviation RFP Request for Proposal RFW Request for Waiver SOW Statement of Work SSI Security Sensitive Information TDP Technical Data Package TSA Transportation Security Administration TSE Transportation Security Equipment TSIF Transportation Security Integration Facility TSL Transportation Security Laboratory

APPENDIX B – Definitions

CCB Configuration Control Board. A board composed of technical and administrative representatives who approve or disapprove proposed engineering changes to a Configuration Item's (CI) current approved configuration documentation. The board also approves or disapproves proposed waivers and deviations from a CI's current approved configuration documentation.

CI Configuration Item. An aggregation of hardware or software that satisfies an end use function and is designated by the Government for separate configuration management.

LCS CM Staff Configuration Management Support. Consists of Government and Contractor personnel performing CM activities.

ERB Engineering Review Board. Performs technical review, evaluation, and recommendation of changes for submission to the ERB.

OEM Original Equipment Manufacturer. An individual, partnership, company, corporation, association, or other service, having a contract with the Government for the design, development, manufacture, maintenance, modification, or supply of items under the terms of a contract. A Government activity performing any or all of the above functions is considered to be a vendor for CM purposes.

APPENDIX C – VENDOR CDRLS

• Configuration Management Plan (CMP)

• Master Configuration Item Listing (MCIL)

• Request for Developmental Deviation (DEP) (TSL/TSIF only)

• Engineering Change Proposal (ECP)

• Request for Deviation (RFD)

• Request for Waiver (RFW)

• Configuration Status Accounting Report (CSAR)

• Configuration Audit Plan (CAP)

• Configuration Audit Summary Report (CASR)