Attachement B- SOW Attachments-1-14.pdf

TABLE OF ATTACHMENTS

Attachment Attachment No.

Configuration Management Plan 1 Master Configuration Item List 2 Engineering Change Proposal 3 Request for Deviation 4 Request for Deviation Waiver 5 Configuration Status Accounting Report 6 Configuration Audit Plan 7 Configuration Audit Summary Report 8 Transportation Security Equipment Database 9 Transportation Security Equipment Reliability, Maintainability & Availability Metrics Report

TSA Form 1412 Media Sanitization Certificate 11 Airport Operating Hours and Listing 12 Checkpoint Property Screening System (CPSS) – Specification Sheet 13 Checkpoint Sloped-Floor Study 14

DATA ITEM DESCRIPTION

1. TITLE 2. IDENTIFICATION NUMBER

Configuration Management Plan DI-L-001

3. DESCRIPTION/PURPOSE

3.1 The Configuration Management Plan (CMP) describes the organizational structure of the configuration management organization; the procedures for identifying and documenting the functional and physical characteristics of hardware and software configuration items; procedures for controlling changes to those characteristics; and procedures for recording and reporting change processing implementation status.

4. APPROVAL DATE (YYMMDD) 5. OFFICE OF PRIMARY RESPONSIBILITY (OPR) 6a. DTC APPLICABLE 6b. GIDEP APPLICABLE

7. APPLICATION/INTERRELATIONSHIP

7.1 The CMP shall describe the Contractor's efforts to implement the configuration management as specified in the contract or request for proposal.

7.2 The CMP is closely related to and shall integrate with other program plans such as the Program Management Plan, System Engineering Management Plan, Quality Management System, Data Management Plan.

8. APPROVAL LIMITATION 9a. REFERENCES 9b. AMSC NUMBER

10. PREPARATION INSTRUCTIONS

10.1 Format. Contractor format is acceptable.

10.2 Content. The Plan shall be organized as follows:

10.2.1 General

10.2.1.1 Scope. This guide contains the format and content preparation instructions for the Contractor’s CM Plan. This guide describes the task of preparing a CM plan.

10.2.1.2 Applicability. The provisions of this guide apply whenever the contractor is required to prepare a CM plan for a TSA acquisition program.

10.2.2 Acronyms

10.2.2.1 Acronyms used in this guide. For the purpose of this guide, refer to the definitions contained in Appendix A.

10.2.3 General Requirements

DATA ITEM DESCRIPTION DI-L-001

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.3.1 Content and Format Instructions. The plan shall be prepared on bound 8 1/2 x 11 inch 20 pound copier paper (hard copy) and a form of electronic media as specified in the contract. Each page prior to Section 1 shall be numbered in lower-case roman numerals beginning with Page ii for the Table of Contents. Each page from section 1 through the end of the document shall be numbered consecutively in Arabic numerals. For hard copy format, the document may be printed on one or both sides of each page (single-sided/double-sided). For single-sided documents, all pages shall contain the document control number in the top right-hand corner. For double-sided documents, all even numbered pages shall have the page number on the lower left-hand side of the document and all odd-numbered pages shall have the page number on the lower right-hand side of the document.

For double-sided documents, the control number shall be placed in the top right-hand corner for each odd-numbered page, and in the top left-hand corner for each even-numbered page. All paragraph and subparagraph headings listed shall be included in the plan. In the event that a paragraph or subparagraph is tailored out, the following statement shall be added directly following the heading: “This section (or paragraph or subparagraph, as applicable) has been tailored out.”

10.2.3.2 Organization of the CM Plan. The plan shall consist of the following:

Cover Page

Record of Reviews and History Page

Table of Contents

Section 1. Introduction

Section 2. Reference Documents

Section 3. Organization

Section 4. Configuration management phasing and milestones

Section 5. Data management

Section 6. Configuration identification

Section 7. Interface management

Section 8. Configuration change management (configuration control)

Section 9. Configuration status accounting

Section 10. Configuration audits

Section 11. Subcontractor/vendor control

10.2.4 Detailed Requirements.

The content and format of the plan shall conform to the following paragraphs.

10. PREPARATION INSTRUCTIONS (CONTINUED)

Cover Page. This page shall contain the document control number in the upper right-hand corner in the center of the page, these words shall appear in the following format:

Configuration Management Plan for the

[Project Name or CI nomenclature and number]

CONTRACT NO. [contract number]

CDRL SEQUENCE NO. [CDRL number]

[Date of document - day month year]

Prepared for:

[Contracting Agency Name, Department Code]

Prepared by:

[Contractor name and address]

[CAGE code]

Record of Review and History Page. This page shall include the review and approval dates of all changes to the plan.

Table of Contents. The Table of Contents shall list the title and page number of all titled paragraphs and subparagraphs. The Table of Contents shall then list the title and page number of all Figures, Tables, and Appendices, in that order.

10.2.4.1 Section 1. Introduction. This section shall include:

10.2.4.1.1 The purpose, scope and specific contractual applicability of the configuration management plan and the program phase(s) to which it applies,

10.2.4.1.2 A brief description of the system or top level configuration item (CI), and of the component lower level CIs, using approved CI nomenclature when available, to which the CM Plan pertains,

10.2.4.1.3 Reference to applicable directives or glossaries containing definitions of terminology and acronyms used in the plan, and

10.2.4.1.4 A description of the plans major features and objectives and a concise summary of the contractor’s approach to CM, including any special conditions (such as large number of organizations, security constraints, interoperability constraints, unique contracting methods, non-developmental items, etc.) upon which the approach is based.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.2 Section 2. Reference Documents. This section shall list the specifications, standards, manuals and other documents, including contractor policy directives, referenced in the Plan by title, document number, issuing authority, revision, and when applicable, change notice, amendment number, and date of issue.

10.2.4.3 Section 3. Organization. This section shall describe and graphically portray the contractor’s organization with emphasis on the CM activities, and which shall include:

10.2.4.3.1 The relationships and integration of the contractor’s project organization and functional organization;

10.2.4.3.2 Responsibility and authority for CM of all participating groups and organizations including their role in configuration control boards, and the integration of CM functions with other program activities such as technical reviews;

10.2.4.3.3 Identification of the contractor’s CM organization and its responsibilities; and

10.2.4.3.4 Interfaces between the contractors CM organization and the TSA, subcontractors, and associate contractors.

10.2.4.4 Section 4. Configuration Management Phasing and Milestones. This section shall describe and graphically portray the sequence of events and milestones for implementation of CM in phase with major program milestones and events, including as a minimum:

10.2.4.4.1 Release and submittal of configuration documentation in relation to program events (e.g., technical reviews);

10.2.4.4.2 Establishment of internal developmental configuration and contractual baselines;

10.2.4.4.3 Implementation of internal and TSA configuration control;

10.2.4.4.4 Establishment of configuration control boards;

10.2.4.4.5 Implementation of a status accounting information system and provision of reports/or access to the status accounting information; and

10.2.4.4.6 Conduct of configuration audits.

10.2.4.5 Section 5. Data Management. This section shall describe the methods for meeting the configuration management technical data requirements. Configuration documentation shall be provided in hard copy format and soft copy data transfer, as specified in the contract. The contractor’s planning shall address all configuration management technical data requirements of the contract as far as data handling, processing, storage, integrity, transfer, security, and maintenance are concerned, over the performance period of the contract. The contractor shall propose to the TSA, as applicable and in accordance with the changes clause of the contract, any requirements that may be imposed on the TSA that will require associated contractor effort to maintain the security and integrity of shared data.

10.2.4.5.1 Data Distribution/Access. The contractor shall affix distribution statements to technical data in accordance with the contract. Access to data shall be limited in accordance with the applicable distribution statements, as well as by data rights, Contract Data Requirements List (CDRL) distribution, security requirements, and data status level (released, submitted or approved unless otherwise specified).

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.5.2 Automated Processing and Submittal of Data. To facilitate processing of submitted data, the contractor shall use automated processing and electronic submittal techniques, when specified in the contract. Where the data requirement is for data that is illustrated, for reference purposes, the contractor may sequentially address the essential and applicable data elements of the submitted data by block number and title, or may provide the data on an electronic version of the form as desired.

Textual data in electronic form shall be by paragraph number, or topic heading, as applicable, in accordance with the format and content requirements for the data specified in the contract.

10.2.4.5.2.1 When data are submitted by electronically transferring (e.g. modem) by the contractor to the TSA, acknowledgement of receipt will be generated at the end of the transmission. When data is electronically transferred by the TSA to the contractor, acknowledgement of receipt by the contractor shall be generated at the end of the transmission. The contractor shall implement a method of error detection for data transfer to insure deliverable data products are capable of being recreated in human readable format.

10.2.4.5 2.2 The contractor shall maintain the current status (working, released, submitted, approved) of all digital technical data in the database at all times. Any data electronically transferred by the contractor to the TSA shall be so identified.

10.2.4.5.2.3 The contractor shall implement procedures to identify and control data during the contractor and TSA review and update cycle. As a minimum, these procedures shall address:

a. Identification of data files submitted to the TSA for review, annotation, comment and approval/disapproval, as applicable in accordance with TSA specified review and approval requirements. Each submitted digital data file shall have a unique identifier (e.g., file name), which shall indicate file version, and “submitted” status. To assure file integrity, the file naming convention shall distinguish an altered (annotated, redlined) file version from the originally submitted file version by renaming it as a separate working status file.

b. How data and changes are transmitted.

c. How changes from previous versions are indicated.

d. Notification/ acknowledgement of receipt, return, or acceptance.

e. Indication of time constraints, if any, for automatic data acceptance, and

f. Data status accounting.

10.2.4.5.3 Interactive Access to Digital Data. In addition to the above requirements, the contractors integrated technical information service shall, where contractually specified, accommodate pre-defined query and extraction of data and shall implement procedures that define the control of databases and files during the TSA’s and contractor’s interactive review and update cycles. As a minimum, the following shall be defined:

10.2.4.5.3.1 How data is to be accessed;

10.2.4.5 3.2 Request for access and logging of access for read-only or annotation;

10.2.4.5.3 3 Naming of temporary working version of the file(s) for purpose of annotation/mark up;

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.5.3.4 Means of indicating whether a comment/annotation is essential/suggested;

10.2.4.5.3.5 Re-identification of marked up versions, as required;

10.2.4.5.3.6 Method of indicating acceptance, provisional acceptance, approval, or rejection, as applicable;

10.2.4.5.3.7 Time constraints, if any, on data acceptance (e.g. automatic approval) by any links in the contractors or the TSA’s review and approval chains;

10.2.4.5.3.8 Automated status accounting, including tracking of disposition of required changes; and

10.2.4.5.3.9 Reidentification of changed files.

10.2.4.6 Section 6. Configuration Identification. This section shall describe the contractor’s procedures for meeting the requirements configuration identification. The purpose of configuration identification shall be to incrementally establish and maintain a definitive basis for control and status accounting for a configuration item (CI) throughout its life cycle. To accomplish configuration identification, the contractor shall, for both hardware and software:

10.2.4.6.1 Selection of CIs. The contractor shall select and recommend potential CIs to the TSA. Any item requiring logistics support and designated for separate procurement is a CI. However, all CIs associated with any given development program are not necessarily designated as CIs at the same point in time. Computer hardware will be treated as CIs. Computer software will be treated as CSCIs throughout the life of the program regardless of how the software will be stored. The final CI selection will be made by the TSA.

10.2.4.6.2 Establishment and Management of Developmental Configuration Including Document Drawing and Software Development Libraries and Corrective Action Process. The contractor shall establish and implement a developmental configuration management process for both hardware and software. This process shall be used to control the documentation and repositories containing the elements of the developmental configuration. The contractor shall prepare a problem/change report to describe each problem detected in software or documentation that has been placed under internal configuration control. The problem/change report shall describe the corrective action needed and the actions taken to resolve the problem These reports shall serve as input to the corrective action process The contractor shall implement a corrective action process for handling all problems detected in the products under internal configuration control. The corrective action process shall ensure that all detected problems are promptly reported, 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 contract.

10.2.4.6.2.1 Documentation Library. The contractor shall establish a documentation library and implement procedures for controlling the documents residing within the documentation library.

10.2.4.6.2.2 Drawing Library. The contractor shall establish a drawing library and implement procedures for controlling the drawings, computer aided design (CAD), and computer aided manufacturing (CAM) instructions residing within the drawing library.

10.2.4.6.2.3 Software Development Library. The contractor shall establish a software development library (SDL) and implement procedures for controlling the software residing within the SDL.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.6.3 Configuration Baselines. Configuration management shall employ three types of configuration baselines, the functional, the product, and the operational baselines, to provide for the progressive definition and documentation of the requirements and design information describing the various CIs designated for a system. The contractor shall recommend to the TSA the types of specifications and associated documentation to a level of detail commensurate with logistic support requirements and procurement strategies that can be used to define each CI; however, the actual specifications provided shall be those ultimately ordered in the contract. Those specifications are subject to review and approval/ contractual implementation by the TSA. The appropriate baseline for each CI shall be established with the approval/ contractual implementation of that specification as defined in the contract.

10.2.4.6.3.1 Configuration Baselines and Their Configuration Documentation. The contractor shall generate the configuration documentation required for the configuration baselines being established by the TSA.

The Functional Configuration Documentation (FCD), Product Configuration Documentation (PCD), and Operational Configuration Documentation (OCD) defining the configuration baselines shall be mutually consistent and compatible. Each succeeding level of configuration documentation from FCD to PCD to OCD shall be traceable to, and be a detailed extension of, its predecessor(s).

If a conflict arises between levels of documentation, the order of precedence shall be (1) FCD, (2) PCD, and (3) OCD.

10.2.4.6.3.1.1 Functional Configuration Documentation. The contractor shall generate the documentation required for the functional baseline. The FCD shall define requirements allocated from the FCD or from a higher level CI to a lower level CI. The FCD for the CI shall be in the form of an item or software requirements specification, and other referenced documentation (for example Interface Control Documents, Interface Requirements Specifications and item or software requirements specifications for lower-level CI(s), if any). The FCD shall also identify the configuration documentation for selected items that are to be integrated or interfaced with the CI, such as items separately developed or currently in the inventory.

10.2.4.6.3.1.2 Product Configuration Documentation. The contractor shall generate the documentation required for the product baseline in accordance with the requirements of the contract. The PCD shall be in the form of item, software, material, and process specifications, engineering drawings, software listings, software design documentation, military specifications, and other technical documentation comprising a complete technical data package for the CI. The PCD may also be in the form of the actual equipment and/or software media. The PCD shall prescribe the necessary physical and functional characteristics of the CI and the verifications required to demonstrate required performance.

10.2.4.6.3.1.3 Operational Configuration Documentation. The product baseline will become the operational baseline once the system has been fielded successfully. In the event that the system does not meet the product baseline in the field, the contractor shall generate the documentation required for the operational baseline in accordance with the requirements of the contract. The OCD shall be in the form of item, software, material, and process specifications, engineering drawings, software listings, software design documentation, military specifications, and other technical documentation comprising a complete technical data package for the CI. The OCD may also be in the form of the actual equipment and/or software media. The OCD shall prescribe the necessary physical and functional characteristics of the CI and the verifications required to demonstrate required performance.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.6.3.2 Maintenance of Configuration Documentation. Once the related configuration baseline has been established, the contractor shall control and maintain the originals of the current approved configuration documentation for all configuration items specified in the contract.

10.2.4.6.4 Engineering Release and Correlation of Manufactured Products. The contractor shall establish/maintain an engineering release system and shall use the system to issue configuration documentation to functional activities (e.g., manufacturing, logistics, quality assurance, acquisition) and to authorize the use of configuration documentation associated with an approved configuration. The contractor shall maintain current and historical engineering release information for all configuration documentation of all configuration items and their component parts. The engineering release system shall interrelate with the contractor’s internal system of controls to assure that all engineering changes have been incorporated in production items as specified. The contractor’s engineering release and control system shall meet the minimum information content requirements and tracking capabilities for verifying that manufactured products correlate with the released engineering data.

10.2.4.6.4 1 Specification Release and Approval. The contractor shall include on each CI specification a contractor’s release signature indicating that the document has been reviewed and is suitable for its intended use. In addition, the contractor shall submit each such specification to the TSA for an approval signature. Approval by the TSA will normally be accomplished on the version of the specification submitted for a baseline. Completion of the release and approval activities indicates mutual acceptance by the TSA and the contractor of the CI’s requirements, as defined in the specification and referenced documents. After approval the specification establishes the appropriate baseline.

10.2.4.6.4.2 Establish Configuration Baselines. Configuration documentation comprising a baseline shall be initially entered into the TSA’s configuration status accounting information system, by means of a TSA-approved ERR. Such documentation, software or combinations thereof shall only be submitted as a complete package, except under extraordinary circumstances as approved by the TSA.

10.2.4.6.4.3 Changes. Revised configuration documentation shall be entered into the TSA’s configuration status accounting information system by means of a TSA-approved ERR. Such documentation, software, or combinations thereof shall only be submitted as a complete package, except under extraordinary circumstances as approved by the TSA.

10.2.4.6.4.4 Consolidation of Multiple Changes into a Single ERR. Unrelated ECPs may be combined into a single ERR if they were incorporated as a single revision to a document.

10.2.4.6.5 Assignment and Application of Configuration Identifiers Including Document Numbers, Nomenclature, Serial Numbers and Part Number to Hardware, and Software Identifiers to Software and Firmware. CIs and their configuration documentation shall be assigned unique identifiers as described below.

10.2.4.6.5.1 CAGE Code. The design activities and the manufacturers of CIs shall be identified by the TSA assigned CAGE Code, which shall be affixed to all CIs, their subordinate parts and assemblies, configuration documentation, software media and products.

10.2.4.6.5.2 TSA Type Designators and Nomenclature. Each CI that is designated by the TSA for control, tracking and logistics purposes shall be assigned TSA type designators and nomenclature in accordance with the requirements of the contract.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.6.5.3 Document Numbers. An identification number shall be assigned and applied to specifications and all revisions thereto; and to engineering drawings, associated lists and ancillary documents and to all revisions thereto.

10.2.4.6.5.4 Part/Item Identification Numbers. A discrete part/item identification number shall be assigned to each CI and its subordinate parts and assemblies and be changed whenever a non-interchangeable condition is created.

10.2.4.6.5.5 Software Identifiers. For each CSCI, the contractor shall identify its corresponding software units.

For each CSCI and associated software units the contractor shall issue/obtain a software identifier, which shall consist of a name or number, and a version identifier, and shall relate the software to its associated software design documentation; revision; and release date. The contractor shall embed the software and version identifiers within the source code, and provide a method for display of the software and version identifier data to the user upon command.

10.2.4.6.5.6 Serial/Lot Numbers. The contractor shall assign serial/lot numbers to like items, or to groups (lots) of like items, identified with a specific TSA nomenclature, unless otherwise specified in the contract.

10.2.4.6.5.7 TSA Serial Numbers. The TSA will identify the serial numbers that shall be affixed to SEPT designated deliverable CIs by the contractor.

10.2.4.6.5.8 Reuse of Serial Numbers. The original serial number of a unit/item/CI shall not be changed even when a change affecting interchangeability may require rework and re-identification. Once assigned, serial numbers shall not be reused for the same item/unit/CI.

10.2.4.6.5.9 Product Identification/Marking. Unless otherwise specified in the contract, all CIs including parts, assemblies, units, sets and other pieces of government property shall be marked with identification plates/ nameplates.

10.2.4.6.5.9.1 Software Marking and Labeling. The marking and labeling of software shall be as follows:

10.2.4.6.5.9.1.1 Software identifier and version and Computer Program Identification Number (CPIN), where applicable, shall be embedded in the source code header.

10.2.4.6.5.9.1.2 Each software medium (e.g., magnetic tape, disk) containing copies of tested and verified software entities shall be marked with a label containing, or providing cross-reference to, a listing of the applicable software identifiers of the entities it contains.

10.2.4.6.5.9.1.3 Media for deliverable CSCIs shall be labeled with the TSA Contract number, CSCI Number, CPIN or other government identifier (if applicable), design activity CAGE Code, Media Number (e.g., 1 of 2, 2 of 2) if there are multiple units per set and copy number of the medium or media set (if there is more than one copy being delivered).

10.2.4.6.5.9.1.4 Media copy numbers shall distinguish each copy of the software media from its identical copies.

Each time a new version of software is issued, new copy numbers, starting from 1, shall be assigned.

10.2.4.6.5.9.2 Firmware Labeling. Firmware shall be labeled on the device or, if the device is too small, on the next higher assembly, as follows:

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.6.5.9.2.1 Where both the hardware device and the embedded code are controlled via a single engineering drawing, the part number representing the device with the code embedded shall comprise the label.

10.2.4.6.5.9.2.2 Where the PCD for the source code consists of a software product specification, both the unloaded device part number and the software identifier of the embedded code, including version number, shall comprise the label. In addition, the software identification(s) shall be labeled on an identification plate or decal located adjacent to the nameplate on the equipment containing the firmware.

10.2.4.6.5.9.3 NDI, COTS, and PDI Labeling. When a CI is wholly developed with private funding and modified to satisfy TSA requirements, the CI shall be re-identified as a TSA modified CI, and documented and controlled in accordance with the requirements of the contract.

10.2.4.7 Interface Management. This section shall describe the procedures for identification of interface requirements, establishment of interface agreements and participation in interface control working groups (ICWG) when required by contract. The interface requirements for the system and its configuration items shall be identified as a part of the system engineering process. Those interface requirements which must be controlled by the TSA during the development of the system shall be incorporated into the FCD. Such interface requirements defined in baselined specifications shall be subject to the configuration control requirements of this standard. Prior to the PBL, the contractor shall be responsible for defining and controlling all interfaces below the PCD level. The contractor shall ensure the compatibility and interoperability among the various hardware and software components for which he is the design activity and between those components and the interfaces/components specified in the baselined configuration documentation.

10.2.4.7.1 Requirements for an Interface Control Working Group (ICWG). When required, the use of an ICWG will be specified by the contract and the interface control contractor will be identified. The contractor shall establish associate contractor agreements with interfacing contractors governing the conduct of interface control.

10.2.4.7.1.1 ICWG Membership. The contractor shall be responsible for providing a representative to the ICWG who is empowered to commit the contractor to specific interface actions and agreements; for assuring that the representative is present at all ICWG meetings; for providing draft interface control documentation at a specified period prior to the ICWG meeting where it will be discussed;

for updating, releasing, and controlling interface control documentation reflecting the ICWG decisions; and for distributing copies of such released interface control documentation to other ICWG participants.

10.2.4.7.1.2 ICWG Chairmanship. The contractor designated as the interface control contractor shall act as the chair for the ICWG and shall be accountable to the TSA to report interface problems as they are surfaced by the ICWG. The contractor shall be responsible for scheduling ICWG meetings; for providing the meeting space and administrative support; for distributing interface control documentation to be addressed at the upcoming ICWG, for conducting the ICWG meetings; for making interface decisions when they can be implemented within the current scope of the contracts of the participants; for coordinating ECPs as required; for recording and distributing the minutes of the ICWG meetings; and for ensuring that updated interface control documentation reflecting the ICWG decisions is distributed within the time frame agreed to by the affected participants.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8 Section 8. Configuration Control. This section shall describe the contractor’s procedures for meeting the requirements of configuration control. Configuration control is the systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a CI after establishment of the configuration baseline(s) for the CI. Configuration control begins with the establishment of the functional baseline and continues as further configuration baselines are established for the CIs, using the FCA, and the PCAs contractually invoked by the TSA. Configuration control continues throughout the life cycle of the CI.

10.2.4.8.1 Purpose of Configuration Control. The contractor shall implement a configuration control function that ensures regulation of the flow of proposed changes, documentation of the complete impact of the proposed changes, and release only of approved configuration changes into CIs and their related configuration documentation. Configuration control begins with the establishment of the functional baseline and continues as further configuration baselines are established for the CIs, using the FCD, the PCDs, and the OCDs contractually invoked by the TSA. Configuration control continues throughout the life cycle of the CI. The following requirements shall apply only to the FCD, the PCDs, and the OCDs that have been approved/contractually implemented by the TSA.

10.2.4.8.2 Classification of Changes and the Level of Authority for Change Approval/Concurrence. An Engineering Change Proposal (ECP) shall be required for any changes to the current approved configuration documentation. The contractor shall include the following elements in the configuration control process:

10.2.4.8.2.1 Determination of a need for the change;

10.2.4.8.2.2 Establishment by the contractor of a classification of the engineering change as Class I or Class II;

10.2.4.8.2.3 Review and evaluation of the change;

10.2.4.8.2.4 Disposition of the change;

10.2.4.8.2.5 Preparation of an ECP;

10.2.4.8.2.6 Submittal of the ECP to the TSA;

10.2.4.8.2.7 Incorporation of approved (or concurred in) engineering changes in the documentation, including, when applicable, negotiation into the contract; and

10.2.4.8.2.8 Implementation of the change in accordance with the contract.

Note: Similar steps shall apply to requests for deviations and waivers.

An engineering change shall be classified as Class I or Class II by the preparing contractor in accordance with this document. Class I ECPs shall be referred to the TSA for approval or disapproval. Classification disagreements shall be referred to the TSA for final decision.

10.2.4.8.3 Processing of Class I Engineering Change Proposals (ECPs). See Contractor’s Engineering Change Proposal Guidelines for guidance.

10.2.4.8.4 Processing of Class II ECPs. See Contractor’s Engineering Change Proposal Guidelines for guidance.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8.5 Processing of Requests for Deviations.

10.2.4.8.5.1 Requirements for Deviations. Prior to manufacture of an item, if a contractor considers it necessary to temporarily depart from the mandatory requirements of the specification or drawings, the contractor may request that a deviation be authorized. Authorized deviations are a temporary departure from requirements and do not constitute a change to the baselines. Deviations do not apply to software code listings. Where it is determined that a change should be permanent, a Class I or Class II engineering change must be processed in accordance with this guideline.

10.2.4.8.5.2 Restrictions on Deviations. Unless unusual circumstances exist, critical deviations and deviations which would affect service operation, logistic interoperability, or maintenance (e.g., repair parts, operation or maintenance procedures, or compatibility with trainers or test sets) shall not be requested. The effectivity of the request for deviation normally should not include the entire remaining number of deliverable units on the contract; if that is the case, an engineering change should be submitted.

10.2.4.8.5.3 Recurring Deviations. If it is necessary for a contractor to request a deviation for the same situation with the same item more than two times, then the need for an engineering change, rather than a deviation, shall be addressed between the TSA and the contractor.

10.2.4.8.5.4 Deviation Format. Contractor format for the Request for Deviation (RFD) is acceptable.

10.2.4.8.5.5 Classifications. RFDs shall be designated as critical, major, or minor by the originator in accordance with this standard. Classification disagreements shall be referred to the TSA for decision.

10.2.4.8.5.5.1 Minor. A deviation shall be designated as minor when:

10.2.4.8.5.5.1.1 The deviation consists of a departure, which does not involve any of the factors listed in Major or Critical criteria; or

10.2.4.8.5.5.1.2 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.

10.2.4.8.5.5.2 Major. A deviation shall be designated as major when:

10.2.4.8.5.5.2.1 The deviation consists of a departure involving: (1) health; (2) performance; (3) interchangeability, reliability, survivability, maintainability, or durability of the item or its repair parts, (4) effective use or operation; (5) weight; or (6) appearance (when a factor); or

10.2.4.8.5.5.2.2 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.

10.2.4.8.5.5.3 Critical. A deviation shall be designated as critical when:

10.2.4.8.5.5.3.1 The deviation consists of a departure involving safety; or

10.2.4.8.5.5.3.2 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 critical.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8.5.6 Disposition. RFDs will be dispositioned by the TSA. Contracts will include the RFD submittal instructions, classification authority, approval authority, and turn-around-time for notification of approval/disapproval. When there are differing disposition requirements for critical, major, and minor RFDs, the contract will so specify. Unless otherwise specified in the contract, requests for critical or major deviations should be approved or disapproved within 30 calendar days of receipt by the TSA, and minor deviations should be approved or disapproved within 15 calendar days of receipt by the TSA. Unless otherwise specified by the TSA, minor deviations shall be authorized (or disapproved) for the TSA by the activity authorized to approve or concur in classification of Class Il changes. Critical and major deviations shall only be approved in accordance with the terms of the contract.

10.2.4.8.6 Processing of Requests for Waivers.

10.2.4.8.6.1 Requirements for Waivers. The contractor shall not offer, for acceptance by the TSA, items that incorporate a known departure from requirements, unless a request for waiver has been approved in accordance with this standard. Authorized waivers apply to a specific quantity of manufactured items and do not constitute change to the FCD, PCD, or OCD. The contractor may process a request for waiver if, during or after manufacture of an item which incorporates a known departure from requirements, it is determined that the item is considered suitable for use as is or after repair by an approved method. Waivers do not apply to software code listings. Where it is determined that a change should be permanent, a Class I or Class II engineering change must be processed in accordance with this standard.

10.2.4.8.6.2 Restrictions on Waivers. Unless unusual circumstances exist, critical waivers and waivers which would affect service operation, logistic interoperability, or maintenance (e.g., repair parts, operation or maintenance procedures, or compatibility with trainers or test sets) shall not be requested. ECPs shall be used for such deficiencies. The effectivity of the request for waiver normally should not include the entire remaining number of deliverable units on the contract; if that is the case, an engineering change should be submitted.

10.2.4.8.6.3 Recurring Waivers. If it is necessary for a contractor to request a waiver for the same situation with the same item more than two times (or for the remainder of the contracted quantity of deliverable units), then the need for an engineering change, rather than a waiver, shall be addressed between the TSA and the contractor.

10.2.4.8.6.5.1.1 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 Major or Critical criteria.

10.2.4.8.6.5.1.2 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.

10.2.4.8.6.5.2 Major. A waiver shall be designated as major when:

10.2.4.8.6.5.2.1 The waiver consists of acceptance of an item having a nonconformance with contract or configuration documentation requirements involving: (1) health; (2) performance; (3) interchangeability, reliability, survivability, or maintainability of the item or its repair parts; (4) effective use or operation; (5) weight; or (6) appearance (when a factor); or

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8.6.5.2.2 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.

10.2.4.8.6.5.3 Critical. A waiver shall be designated as critical when:

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

10.2.4.8.6.5.3.2 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.

Disposition. RFWs will be dispositioned by the TSA. Contracts will include the RFW submittal instructions, classification authority, approval authority, and turn-around-time for notification of approval/disapproval. When there are differing disposition requirements for critical, major, and minor RFWs, the contract will so specify. Unless otherwise specified in the contract, requests for critical or major waivers should be approved or disapproved within 30 calendar days of receipt by the TSA, and minor waivers should be approved or disapproved within fifteen calendar days of receipt by the TSA.

10.2.4.8.7 Parts Substitutions. Unless otherwise specified by contract, part substitution for parts identified in the current approved configuration documentation of an item from the product baseline through the remainder of the item’s life cycle shall conform as follows:

10.2.4.8.7.1 Substitution of a non-repairable part for an item for which the contractor has configuration documentation custody shall not require a Class I or Class II engineering change or a request for deviation or waiver when:

10.2.4.8.7.1.1 The part is identified as an authorized substitute or superseding part in a military specification or standard; and

10.2.4.8.7.1.2 The part will not be installed in equipment to be submitted for verification and reliability demonstration tests.

10.2.4.8.7.2 Substitution of a non-repairable part shall require a Class II engineering change when:

10.2.4.8.7.2.1 The part substituted is determined, by the contractor having configuration documentation custody over the item, to be a preferred part over the original; or

10.2.4.8.7.2.2 The contractor does not have configuration documentation custody.

10.2.4.8.7.3 Part substitutions which do not meet the requirements of 8.7a or 8.7b and for which a permanent change is not desired shall require submission of a Request for Deviation (RFD) or Request for Waiver (RFW).

10.2.4.8.7.4 All other parts substitutions shall be subject to the Class I or Class II engineering change as applicable.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8.8 Processing of Specification Change Notices (SCNs). In accordance with the requirements of the contract, the contractor shall, concurrent with the preparation of an ECP, prepare a separate proposed “SCN”, for each specification which would require revision if the ECP were approved.

The SCN(s) shall be submitted to the TSA with the ECP for approval and authorization, or disapproval. The originating contractor shall prepare and coordinate the SCN(s) with other prime contractors along with the ECP. Errors of a minor nature (such as typographical errors, punctuation, etc.) shall not be corrected, except as an incidental part of the next technically required ECP and accompanying proposed SCN effecting that CI specification.

10.2.4.8.8.1 SCN Cover Page. SCNs for a specification are sequentially numbered beginning with SCN 1;

SCNs for a newly revised specification are also sequentially numbered starting again with SCN 1.

The SCN number shall be placed on the cover sheet of the SCN submittal package. The proposed SCN or any revisions thereto, and the approved SCN shall carry the same number. Once an SCN has been submitted to the TSA along with an ECP, its SCN sequence number related to that revision of the specification shall not thereafter be changed or assigned to another ECP/SCN package. (SCN numbers associated with disapproved ECPs are not reused.) However, due to differing change processing/approval time periods, SCNs may be approved by the TSA out of sequence. If this occurs, the SCN shall be changed to reflect the other SCNs approved since it was proposed; likewise, some of the attached change pages might have to be revised to reflect the current wording as of the approval date.

10.2.4.8.8.2 Attachments to Proposed SCN. The attachments to the proposed SCN shall be:

10.2.4.8.8.2.1 Pages containing detailed information about the exact proposed changes to the specification by reference to the paragraph, page, Figure, or Table and by citing the words/information to be changed in “From/To’ format; or

10.2.4.8.8.2.2 Replacement new specification pages in format suitable to be substituted for existing pages, identified with the specification number and SCN approval date, numbered with the same numbers of the pages they replace plus a suffix letter where additional pages are needed to replace a page (e.g., new Pages 5 and 5a replace old Page 5), and all portions affected indicated by symbols (e.g., change bars, asterisks, etc.) in the margin; or

10.2.4.8.8.2.3 A proposed specification revision, where more practical, identified with the same number as the specification to be superseded with a new revision letter, prepared to the same format, and all portions affected identified with symbols in the margin or containing a note explaining that the changes are too extensive to be identified.

10.2.4.8.8.3 Supersession. When a proposed SCN must be revised and resubmitted, the resubmitted SCN shall retain the same basic SCN number but must be re-identified as a superseding revision (starting with R1 for each SCN) to avoid confusion with any previous submittals of the SCN.

10.2.4.8.8.4 Approved SCN. The contractor will receive approved SCNs from the TSA concurrent with contractual authorization, and shall use the approved SCNs as authorization to update the specifications in accordance with the approved SCNs. An approved SCN also provides a summary listing of pages affected by all previously approved changes to that particular revision of the specification. SCNs are not cumulative insofar as transmittal of change pages from previous change is concerned, and changes distributed with previous SCNs remain in effect unless changed or canceled by an SCN of later issue. However, the summary of current changes shall be a cumulative summary as of the date of approval of the latest SCN.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.8.8.5 Changed Pages. Updated and reissued pages shall be complete reprints of pages suitable for incorporation by removal of old pages and insertion of new pages. All portions affected by the change shall be indicated by a symbol in the margin adjacent to the change and encompassing all changed portions. When changed pages are issued for specifications with pages printed on both sides of a sheet, and only the page on one side of a sheet is affected by the change, both sides of the sheet shall be reissued. The unchanged side shall be reprinted without change and shall not carry the date of the change or be included in the change summary as being affected by the change.

10.2.4.8.9 Processing of Notices of Revision (NORs). The “NOR”, shall be utilized to describe the exact change(s) to be made to each drawing, associated list, or other affected document when specified as a data requirement in the contract. NORs shall be prepared in contractor format. (NORs are normally applicable where documents affected by the ECP are not controlled by the ECP preparing activity).

10.2.4.9 Configuration Status Accounting (CSA). The purpose of CSA is to assure accurate identification of each CI and delivered unit so that the necessary logistics support elements can be correctly programmed and made available in time to support the CI. An adequate and accurate CSA will enhance program and functional manager’s capabilities to identify, produce, inspect, deliver, operate, maintain, repair, refurbish, etc., CIs in a timely, efficient, and economical manner in satisfying their assigned responsibilities. This section shall describe the contractor’s procedures for meeting the requirements of configuration status accounting, including:

10.2.4.9.1 Preferred Information System. The contractor shall provide CSA information from the contractor’s information system to the maximum extent possible. The information system shall provide methods for collecting, recording, processing and maintaining data necessary to provide contractual status accounting information via reports and/or data base access.

10.2.4.9.2 Description of reports/information system content related to, as applicable.

10.2.4.9.2.1 Identification of current approved configuration documentation and configuration identifiers associated with each CI;

10.2.4.9.2.2 Status of proposed engineering changes from initiation to implementation;

10.2.4.9.2.3 Results of configuration audits; status and disposition of discrepancies;

10.2.4.9.2.4 Status of requests for critical and major deviations and waivers;

10.2.4.9.2.5 Traceability of changes from baselined documentation of each CI, and

10.2.4.9.2.6 Effectivity and installation status of configuration changes to all CIs at all locations.

10.2.4.9.3 Methods of access to information in status accounting information systems and/or frequency of reporting and distribution.

10.2.4.9.4 Retention of Historical Database. The contractor shall retain a complete historical record of all the information required by the TSA to be stored in the system. Such historical information shall be formatted and maintained in such a manner that it can readily be copied, in total or by specific elements identified by the TSA, for transfer in a format specified in the contract.

10. PREPARATION INSTRUCTIONS (CONTINUED)

10.2.4.9.5…