MIL-STD-973.pdf

MIL-STD-973

17 April 1992

SUPERSEDING

(See section 6.4)

MILITARY STANDARD

CONFIGURATION MANAGEMENT

AMSC No. D6728 AREA CMAN

Distribution Statement A: Approved for public release; distribution is unlimited

NOT MEASUREMENT

SENSITIVE

Downloaded from http://www.everyspec.com

FOREWORD

1. This Military Standard is approved for use by all Departments and Agencies of the Department of Defense (DoD) .

2. MIL-STD-973 is jointly sponsored by the Office of the Secretary of Defense and the Joint Logistics Commanders. The primary purpose of this standard is to consolidate configuration management requirements which were previously scattered throughout several configuration management standardization documents. As a result of this consolidation effort, MIL-STD-973 significantly reduces the number of configuration management standards in the DoD inventory. Those standards that are superseded by MIL-STD-973 are identified in Section 6. Although consolidation is the primary purpose of this initiative, MIL-STD-973 does contain new material. Some requirements from superseded standards have been modified to clarify ambiguities or to resolve inconsistencies. Some obsolete or redundant requirements from superseded standards have been modified or deleted entirely. Computer-aided Acquisition and Logistic Support (CALS) has been addressed in this issue to the extent practicable. Alsot some new requirements have been identified and included.

3. This standard has been developed for use by both contractors and Government activities. Toward this end, the term “contractor” has been used throughout to denote an activity performing any of the requirements of this standard. A “contractor” can be either a contractor or Government activity.

Wherever it is necessary to differentiate between the contractor and the tasking activity (i.e. , the Government Contracting Activity which awards a contract to a contractor, the Government Program Management Office which tasks another Government activity, or a contractor which tasks a subcontractor) , the term “Government” has been used throughout to denote the activity imposing the requirements of this standard on the other.

4. This standard defines the ~equirements of configuration management as they apply to defense materiel items.

Configuration management is a management discipline applied to configuration items (CIS) over their life cycle to ensure that the characteristics of CIS meet defined user requirements.

5. configuration management requirements for software have been included in this standard. Where requirements are common to both hardware and software items, they are shown as requirements for CIS. Where requirements are not common to both hardware and ii

-- software items, they are shown as requirements for computer software configuration items (CSCIS) or hardware configuration items (HWCIS) , as applicable.

6. Beneficial comments (recommendations, additions, deletions) and any pertinent data which may be of use in improving this document should be addressed to: Chief, Plans and Policy Division, CALS Evaluation and Integration Office, 5203 Leesburg Pike, Suite 1403, Falls Church, VA 22041-3466, by using the self-addressed Standardization Document Improvement Proposal (DD Form 1426) appearing at the end of this document or by letter.

iii

CONTENTS

PARAGRAPH PAGE

1.

1.1

1.2 1.3

2.

2.1 2.1.1 2.1.2 2.2

3.

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31

SCOPE

Scope Applicability Tailoring of requirements

APPLICABLE DOCUMENTS

Government documents Specifications, standards, and handbooks Other Government documents Order of precedence

DEFINITIONS . . . . . . . . . . . . . . . . . . ● .

Acronyms used in this standard Advance Change Study Notice (ACSN) Allocated Baseline (ABL) Allocated Configuration Documentation (ACD) . . .

Approval/contractual implementation Configuration Baseline Block change concept Classification of defects Commercial and Government Entity (CAGE) Code . . .

Computer database Computer data definition Computer software Computer Software Component (CSC) Computer Software Configuration Item (CSCI) . . .

Computer software documentation Computer Software Unit (CSU) Configuration Configuration audit Configuration control Configuration Control B;a;d.(;CB). 1 Configuration documentation Configuration identification Configuration Item (CI) Configuration Management (CM) Configuration Management Plan (CMP) Configuration Status Accounting (CSA) Contractor Critical item Data. . . . . . . . . . . . . . . . . . . . . ● .

Defect. . . . . . . . . , Deficiencies

7 _.

iv

PARAGRAPH

3.32 3.33 3*34 3.35 3.36 3.37 3.38 3.39 3.40 3*41 3.42 3*43 3.44 3.45 3.46 3.47 3.48 3.49 3.50 3.51 3.52 3.53 3.54 3.55 3.56 3.57 3.58 3.59 3.60 3.61 3.62 3.63 3.64 3.65 3.66 3.67 3.68 3.69 3.70 3.71 3.72 3.73 3.74 3.75 3.76

MIL-STD-973

CONTENTS

PAGE

Design change Developmental configuration Deviation Engineering change Engineering change justification code Engineering change priorities Engineering Change Proposal (ECP) Engineering Change Proposal types Engineering release Engineering Release Record (ERR) Evaluation Exchangeability of items Firmware Fit Form Function Functional area Functional Baseline (FBL) Functional characteristics Functional Configuration Audit (FCA) Functional Configuration Documentation (FCD) . .

Hardware Hardware Configuration Item (HWCI) Integrated Logistics Support (ILS) Interchangeable item Interface Interface control Interface Control Drawing (ICD) Interface Control Working Group (ICWG) Interoperability Item Life cycle Lifecyclecost Manufacturer’s code Material Non-conformance Non-developmental Item (NDI) Non-recurring costs Notice of Revision (NOR) Original . . . . . . , Physical characteristics Physical Configuration Aud;t.(~C~)” 1 1 1 R I I R Product Baseline (PBL) Product Configuration Documentation (PCD) Recurring costs v

PARAGRAPH

3.77 3.78 3.79 3.80 3.81 3.82 3.83 3.84 3.85 3.86 3.87 3.88 3.89 3.90 3.91 3.92 3.93 3.94 3.95 3.96 3.97 3.98

4.

4.1 4.2 4.3

4.3.1 4.3.2 4.3.3 4.4 4.5 4.6 4.7

5.

5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2

PAGE

Release. . . . . . . . . . . . . . . . . . . . 0 .15 Repair Replacement item Retrofit Rework Software Specification Specification Change Notice (SCN) . . .

Substitute item Support equipment Survivability System Technical data Technical data package Technical documentation Technical reviews Training equipment Unit Version Waiver Work Breakdown Structure (WBS) Work breakdown structure element . . .

GENERAL REQUIREMENTS

Basic requirements Planning Computer-aided Acquisition and Logistic

(CABS )

Data distribution/access

Support

Automated processing and submittal of data .

Interactive access to digital data . . .

Configuration identification Configuration control Configuration Status Accounting (CSA) . .

Configuration audits

DETAILED REQUIREMENTS

Purpose Configuration management administration .

Contractor’s CM Plan Work Breakdown Structure (WBS) Technical reviews Configuration identification Purpose of configuration identification .

Configuration Item selection vi

. . 26

PA RAGRAPH

5. 3.3

5. 3.3.1

5. 3.3.2

5. 3.3.3

5. 3.4

5. 3.4.1

5.3.4. 1.1 5.3.4.1.2 5.3.4.1.3 5.3.4.2 5.3.5

5.3.5.1 5.3.5.2

5.3.5.2.1 5.3.5.2.2 5.3.5.2.3 5.3.5.2.4

5.3.6‘-.._.

5.3.6.1 5.3.6.2 5.3.6.3 5.3.6.4 5.3.6.5 5.3.6.6 5.3.6.6.1 5.3.6.6.2 5.3.6.7 5.3.6.7.1 5.3.6.7.2 5.3.6.7.3 5.3.7 5.3.7.1 5.3.7.2

5.3.7.2.1 5.3.7.2.2 5.4 5.4.1 5.4.2 5.4.2.1 5.4.2.2

MIL-STD-973

CONTENTS

PAGE

Developmental configuration Documentation libra;y Drawing library Software Development Library Configuration baselines Configuration baselines and their configuration documentation Functional Configuration Documentation (FCD) . .

Allocated Configuration Documentation Product Configuration Documentation Maintenance of configuration documentation . . .

Engineering release and correlation of manufactured products Specification release and approval Requirements for Engineering Release Records (ERRs) UseofERRs Initial release Change release Consolidation of multiple changes into a single

ERR. . ...’

Configuration identifiers CAGE Code Government type designators and nomenclature . .

Document numbers Part/item identification numbers Software identifiers Serial/lot numbers Government serial numbers Reuse of serial numbers Product identification/marking Software marking and labeling Firmware labeling NDI , COTS, and PDI labeling Interface management Interface requirements Requirements for an Interface Control Working Group (ICWG) ICWGmembership ICWGChairmanship Configuration control Purpose of configuration control Requirements for Engineering Changes The engineering change process Administrative requirements vii

PARAGRAPH

5.4.2.2.1 5.4.2.2.2

5.4.2.2.3

5.4.2.2.3.1 5.4.2.2.3.2 5.4.2.2.3.3

5.4.2.2. 3.4 5.4.2.3 5.4.2.3.1

5.4.2.3. 1.1

5.4.2.3. 1.2

5.4.2.3. 1.3

5.4.2.3. 1.4 5.4.2.3.2 5.4.2.3.3 5.4.2.3.3.1

5.4.2.3.3. 1.1

5.4.2.3.3. 1.2 5.4.2.3.3.2 5.4.2.3.4 5.4.2.3.4.1

5.4.2.3.5 5.4.2.3.5.1

5.4.2.3.5.2

5.4.2.3.5.3

5.4.2.3.6 5.4.2.3.6.1 5.4.2.3.6.2

5.4.2.3.6.3

5.4.2.3.6.4

5.4.2.3.6.5

5.4.2.4 5.4.2.4.1 5.4.2.4.2

MIL-STD-973

CONTENT -

PAGE

Classification of engineering changes . . .

Classifying engineering changes to a privately developed item Content of Engineering Change Proposals

(ECPS)

Unrelated engineering changes Revisionsof ECPS Supporting data Classified data Class I Engineering Change Proposals Class I ECP decisions Target for technical decision on Class I

ECPS

ECP authorization Class I compatibility engineering changes .

Disapproval of ECPS Class I ECP justification codes Class I ECPtypes Preliminary change proposal Use of preliminary ECPS (Type P) Use of Advance Change Study Notice (ACSN) .

Use of Formal ECP (Type F) Class I engineering change priorities . . .

Expediting Class I engineering changes with priority of emergency or urgent Format for Class I engineering changes . . .

Class I engineering changes during concept exploration, demonstration and validation .

Class I engineering changes during engineering and manufacturing development .

Class I engineering changes during production and support Related engineering changes Related engineering changes - single prime .

Related engineering changes - single prime multiple procuring activities Related engineering changes - separate primes Same engineering change - prime/ subcontractor coordination Same engineering change - several contractors Class II engineering changes Class II engineering change format Class 11 justification codes

43 — viii

PARAGRAPH

5.4.2.4.3 5.4.2.4.4 5.4.2.4.5 5.4.3

5.4.3.1 5.4.3.2 5.4.3.3 5.4.3.3.1 5.4.3.3.2 5.4.3.3.3 5.4.3.4 5.4.3.5 5.4.3.5.1 5.4.3.5.2 5.4.4 5.4.4.1 5.4.4.2 5.4.4.3 5.4.4.3.1

L 5.4.4.3.2 5.4.4.3.3 5.4.4.4 5.4.4.5 5.4.4.5.1 5.4.4.5.2 5.4.5 5.4.6

5.4.6.1 5.4.6.2 5.4.6.3 5.4.6.4 5.4.6.5 5.4.7

5.4.8

5.4.8.1 5.4.8.2 5.4.8.2.1 5.4.8.2.2 5.4.8.2.3 5.4.8.2.4

Concurrence in Class II changes Approval of Class 11 changes Non-custody of the original drawings Requirements for Requests for Deviation

(RFD)

Restrictions on deviations Recurring deviations Classification of deviations Minor Major Critical Format Disposition of deviations Minor deviations Critical and major deviations Requirements for Requests for W~iver (RFW) .

Restrictions on waivers Recurring waivers Classification of waivers Minor Major Critical Format Disposition of WZtiVerS Minor waivers Critical and major waivers Parts substitutions Requirements for Specification Change Notices (SCNs) SCNcoverpage Attachments to proposed SCN Supersession ApprovedSCN Changed pages Requirements for Notices of Revision

(NORS)

Configuration control (short form procedure) Purpose Requirements for ECPS ECPformat

,Expediting ECPS Revisions ECPcoverage

,PAGE

ix

PARAGRAPH

5.4.8.2.5 5.4.8.2.6 5.4.8.2.7 5.4.8.3 5.4.8.3.1 5.4.8.3.2 5.4.8.3.3 5.4.8.3.4 5.4.8.3.5 5.4.8.4 5.4.8.4.1 5.4.8.4.2 5.4.8.4.3 5.4.8.4.4 5.4.8.4.5 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.5.5 5.5.6 5.5.7 5.5.8

5.6 5.6.1

5.6.1.1 5.6.1.2 5.6.1.3 5.6.1.4 5.6.2 5.6.2.1 5.6.2.2 5.6.2.3 5.6.2.4 5.6.2.5 5.6.3 5.6.3.1 5.6.3.2 5.6.3.3 5.6.3.4 5.6.3.5

ECP supporting data ECPapproval Disapproval . . . . . . . . . . . . ● . . .

Requirements for deviations Restrictions on deviations Recurring deviations . . . . . . . . . . . ●

Deviation format Deviation significant factors Deviation review and approval Requirements for waivers Restrictions on waivers Recurring waivers . . . . . . . . . . . ● .

Waiver format . . . . . . . . . . . . . . ●

Waiver significant factors Waiver review and approval Configuration Status Accounting (CSA) . . .

Purposeof CSA. . . . . . . . . . . 0 ● . .

CSA requirements . . . . . . . ● Preferred information system Retention of historical data base CSAdata elements . . . . - Contractor focal point CSA analysis requirements Reporting accomplishment of retrofit changes Configuration audits Contractor participation and responsibilities Subcontractors and suppliers Location. . . . . . . . . . . . ● . ● . . s Contractor requirements Government participation Functional Configuration Audit (FCA) Contract requirements Contractor responsibility Verification procedures and requirements . .

Post-audit actions . . . . . . . . . . . . “ FCA Certification Package Physical Configuration Audit (PCA) Contract requirements Contractor responsibility PCA procedures and requirements Post-audit actions PCA Certification Package x

PARAGRAPH

6.

6.1 6.2

6.2.1 6.2.1.1 6.2.1.2 6.2.1.2.1 6.2.1.2.2 6.2.1.2.3

6.2.1.3 6.2.2 6.2.2.1 6.2.2.2 6.2.2.3 6.3 6.4 6.5

G- FIGURE

Figure 1.

Figure 2.

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

3a. -3b.

4.

5a. -5g.

6.

7a. -7k.

8a.

8b.

9a.

9b.

9C.

9d .

9e.

9f.

9g .

10.

11.

12.

PAGE

NOTES

Intended use Tailoring guidance for contractual application Useof.Table II Explanation of codes Sample wording for contractual tasking . . . 107 Invoking a complete set of requirements . . 107 Tailoring out specific requirements Identifying specific applicable requirements Specific tailoring notes UseofTableIII Explanation of codes Sample wording for contractual tasking . . . 117 Specific tailoring notes Data requirements Supersession data Subject term (key word) listing

Advance change Study Notice Sample Engineering Change Proposal Message Format Sample Audit Action Items List . . . . . . 68-69 Sample FCA Checklist Sample FCA Certification Package . . . . . 75-81 Sample PCA Checklist Sample PCA Certification Package . . . . . 90-100 Engineering Release Record Engineering Release Record Continuation Page. .140 Engineering Change Proposal - Page 1 Engineering Change Proposal - Page 2 Engineering Change Proposal - Page 3 Engineering Change Proposal - Page 4 Engineering Change Proposal - Page 5 Engineering Change Proposal - Page 6 Engineering Change Proposal - Page 7 Request for Deviation/Waiver Specification Change Notice Notice of Revision xi

MI L- STD-973

TABLE

I Life cycle applications of DD Form 1692 II Tailoring guide for use with MIL-STD-973 III Application of CSA tasks

Appendixes

A B c

D

E

F

G

H

I J

CONTRACTOR’S CONFIGURATION MANAGEMENT (CM) PLAN . . 122

ENGINEERING RELEASE RECORDS AND CORRELATION OF

MANUFACTURED PRODUCTS

INSTRUCTIONS FOR THE PREPAW4TION OF AN ENGINEERING

RELEASE RECORD (ERR) UTILIZING DD FORMS 2617

AND2617C

INSTRUCTIONS FOR THE PREPA~TION OF AN ECP

UTILIZING DD FORMS 1692 THROUGH 1692/6

INSTRUCTIONS FOR THE PREPAIU+TION OF REQUEST FOR

DEVIATION/WAIVER UTILIZING DD FORM 1694

INSTRUCTIONS FOR THE PREPA~TION OF SPECIFICATION

CHANGE NOTICE UTILIZING DD FORM 1696

INSTRUCTIONS FOR THE PREPARATION OF NOTICE OF

REVISION UTILIZING DD FORM 1695

CONFIGURATION STATUS ACCOUNTING (CSA) REQUIREMENTS

AND RECORDS

CSADATAELEMENTS

REPORTING THE ACCOMPLISHMENT OF RETROFIT CHANGES . 225

xii —

1. SCOPE

1.1 Scope. This standard defines configuration management

requirements which are to be selectively applied, as required, throughout the life cycle of any configuration item (CI):

a. Developed wholly or partially with Government funds, including non-developmental items when the development of tec~ical data is required to support off-the-shelf equipment or software, or

b. Designated for configuration management for reason of integration, logistics support, or interface control.

1.2 ADDlicabilitv. This standard applies to Department of

Defense activities and contractors who are tasked with the application of configuration management.

1.3 Yailorinq of requirements. This standard is applicable

only to the extent specified in the tasking directive or contract Statement of Work (SOW). Contracts invoking this standard will specifically identify the appropriate applicable paragraphs and Appendices, or portions thereof, in the tasking directive or contract SOW. (See 6.2 for specific tailoring guidance.) The---selection of necessary configuration management requirements from this standard to be applied to a specific program will be tailored to suit the life-cycle phase, complexity, size, intended use (including joint and combined interoperability) , mission criticality, and logistics support of the CIS.

2. APPLICABLE DOCUMENTS

2.1 Government documents.

2.1.1 Specifications, standards, and handbooks. The

following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) and supplement thereto, cited in the solicitation. (See 6.2)

MILITARY SPECIFICATIONS

MIL-Q-9858 Quality Program Requirements MIL-P-15024 Plates, Tags and Bands for

Identification of Equipment MIL-T-31OOO Technical Data Packages, General

Specification for MIL-I-45208 Inspection System Requirements

MILITARY STANDARDS

MIL-STD-12

MIL-STD-1OO

MIL-STD-109

MIL-STD-129

MIL-STD-130

MIL-STD-280

MIL-STD-490

MIL-STD-499

MIL-STD-881

MIL-STD-882

MIL-STD-961

MIL-STD-965

MIL-STD-970

Abbreviations for Use on Drawings, and on Specifications, Standards and Technical Documents Engineering Drawing Practices Quality Assurance Terms and Definitions Marking for Shipment and Storage Identification Marking of US Military Property Definitions of Item Levels, Item Exchangeability, Models, and Related Terms (Notice of Validation) Specification Practices Engineering Management Work Breakdown Structures for Defense Material Items System Safety Program Requirements Military Specifications and Associated Documents, Preparation of Parts Control Program Standards and Specifications, Order of Preference for the Selection of

MIL-STD-1167

MIL-STD-1168

MIL-STD-1388-1

MIL-STD-1388-2

DOD-STD-1467

MIL-STD-1520

MIL-STD-1559

MIL-STD-1806

DOD-STD-2167

DOD-STD-2168

DOD-STD-7935

Ammunition Data Card Lot Numbering of Ammunition (Validated) Logistic Support Analysis DoD Requirements for a Logistic Support Analysis Record Software Support Environment Corrective Action and Disposition System for Nonconforming Material Numbers, Serial, Aircraft, Gas Turbine Engine, and Engine Module Assignment of Marking Technical Data Prepared By or For the Department of Defense Defense System Software Development Defense System Software Quality Program DoD Automated Information Systems (AIS) Documentation Standards

(Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available from the Standardization Documents Order Desk, Building 4D, 700 Robbins Avenue, Philadelphia, PA 19111-5094. )

2.1.2 Other Government documents. The following other

Government document ferns a part of this document to the extent specified herein. Unless otherwise specified, the issues are those cited in the solicitation.

CATALOGING Handbook for Commercial and HANDBOOK H4/H8 Government Entity Codes

(Copies of Cataloging Handbook H4/H8 are available from the Commander, Defense Logistics Services Center, Battle Creek, MI 49017-3084.)

2.2 Order of ~recedence. In the event of a conflict

between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained, in which case the exception will be identified in the text and cited in the solicitation.

3. DEFINITIONS

3.1 Acronyms used in this standard. The acronyms used in

this standard are defined as follows:

a.

b.

c.

d.

e.

f.

9.

h.

i.

j.

k.

1.

m.

n.

o.

P“ q“ r.

s.

t.

ABL

ACD

ACSN

AIS

AMSDL

CAGE

CAO

CCB

CDR

CDRL

CI

CM

CSA

Csc

CSAR

CSCI

DID

DLA

DOD

DODAAC-

Allocated Baseline

Allocated Configuration Documentation

Advance Change Study Notice

Automated Information System

Acquisition Management Systems and Data Requirements Control List

Commercial and Government Entity

Contract Administration Office

Configuration Control Board

Critical Design Review

Contract Data Requirements List

Configuration Item

Configuration Management

Configuration Status Accounting

Computer Software Component

Configuration Status Accounting Report

Computer Software Configuration Item

Data Item Description

Defense Logistics Agency

Department of Defense

Department of Defense Activity Address Code

L.

u.

v.

w.

x.

Y“ z.

aa.

ab.

ac.

ad.

ae.

af.

ag.

ah.

ai.

aj .

ak.

al.

am.

an.

ao.

ap.

aq.

ar.

DODISS-

DUI

ECP

EMD

FBL

FCA

FCD

GFD

GFE

HWCI

1 CD

I CWG

IDD

ILS

IRS

LSA

MRB

MTS

NDI

NOR

NSN

PBL

PCA

PCD

MIL-STD-973

Department of Defense Index of Specifications and Standards

Data Use Identifier

Engineering Change Proposal

Engineering and Manufacturing Development

Functional Baseline

Functional Configuration Audit

Functional Configuration Documentation

Government Furnished Data

Government Furnished Equipment

Hardware Configuration Item

Interface Control Drawing

Interface Control Working Group

Interface Design Document

Integrated Logistics Support

Interface Requirements Specification

Logistics Support Analysis

Material Review Board

Mobile Training Sets

Non-Developmental Item

Notice of Revision

National Stock Number

Product Baseline

Physical Configuration Audit

Product Configuration Documentation

as. PDI

at. PDR

au. PPSL

av. RFD

aw. RFW

ax. SPS

ay. SDL

az. SCN

ba. sow

bb. TCTO bc . TRR

bd. VDD

be. VE

bf. VECP bg . WBS

MIL-STD-973

Privately Developed Item

Preliminary Design Review

Program Parts Selection List

Request For Deviation

Request For Waiver

Software Product Specification

Software Development Library

Specification Change Notice

Statement of Work

Time Compliance Technical Order

Test Readiness Review

Version Description Document

Value Engineering

Value Engineering Change Proposal

Work Breakdown Structure

3.2 Advance Chanae Studv Notice (ACSN) . A document which

mav be used, instead of a preliminary Engineering Change Proposal (D~ Form 1692), to identify an idea or problem in order to obtain authorization to submit a formal routine Engineering Change Proposal.

3.3 Allocated Baseline (ABL) . The initially approved

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

3.4 Allocated Configuration Documentation (ACD) . The

approved allocated baseline plus approved changes.

>. 3.5 A~~roval/contractual implementation. The acceptance by the Government of a document as complete and suitable for its intended use. Approval/contractual implementation of configuration documentation means that the approved documentation is subject to the Government’s configuration control procedures.

3.6 Block chanqe conce~t. For hardware configuration

items, an engineering change implementation concept that designates a number (i.e., a block) of consecutive production units of the configuration item to have an identical configuration on delivery and in operation. (Using this concept, the production run is divided into “blocks” of units. The production line incorporation point for a proposed ECP is delayed to coincide with the first unit of the next block, or retrofit is required at least for all already-delivered units of the current block. ) For computer software configuration items, once the product baseline has been established, the concept requires the accumulation and the simultaneous implementation of a number of routine software changes to minimize the number of interim versions and related documentation.

3*7 Classification of defects. See MIL-STD-109.

3.8 Commercial and Government Entitv (CAGE) Code. A five-

position alphanumeric code with a numeric in the first and last

--- positions (e.g., 27340, 2A345, 2AA45, 2AAA5), assigned to United States and Canadian organizations which manufacture and/or control the design of items supplied to a Government Military or Civil Agency or assigned to United States and foreign organizations, primarily for identifying contractors in the mechanical interchange of data required by MILSCAP and the Service/Agency Automated Data Processing (ADP) systems. The CAGE data provides the data base for the Cataloging Handbook H4/H8 Series.

3.9 Computer data base. A collection of data in a form

capable of being processed by a computer.

3.10 Commter data definition. See DoD-STD-2167,

3.11 Com~uter software. See DoD-STD-2167.

3.12 Computer Software Component (Csc) . See DoD-STD-2167.

3.13 Computer Software Configuration Item (CSCI). A

configuration item that is computer software.

3.14 Com~uter software documentation. Technical data or

information, including computer listings, regardless of media, which documents the requirements, design, or details of computer software; explains the capabilities and limitations of the software; or provides operating instructions for using or supporting computer software during the software’s operational life cycle.

3.15 Com~uter Software Unit (Csu) . See DoD-STD-2167.

3.16 Configuration. For purposes of this standard, the

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

3.17 Configuration audit. See “Functional configuration

audit” and “Physical configuration audit”.

3.18 Conficiuration baseline. Configuration documentation

formally designated by the Government at a specific time during a CI’s life cycle. Configuration baselines, plus approved changes from those baselines, constitute the current approved configuration documentation. There are three formally designated configuration baselines in the life cycle of a configuration item, namely the functional, allocated, and product baselines.

3.19 Confiu uration control. 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.

3.20 Configuration Control Board (CCB) . A board composed

of technical and administrative representatives who recommend approval or disapproval of proposed engineering changes to a CI’S current approved configuration documentation. The board also recommends approval or disapproval of proposed waivers and deviations from a CI’S current approved configuration documentation.

3.21 Configuration documentation. The technical

documentation that identifies and defines the item’s functional and physical characteristics. The configuration documentation is developed, approved, and maintained through three distinct evolutionary increasing levels of detail. The three levels of configuration documentation are the functional configuration documentation, the allocated configuration documentation, and the product configuration documentation.

3.22 Configuration identification.

identification includes the’ selection of

Configuration CIS; the determination of the types of configuration documentation required for each CI;

the issuance of numbers and other identifiers affixed to the CIS and to the technical documentation that defines the CI’S configuration, including internal and external interfaces; the release of CIS and their associated configuration documentation;

and the establishment of configuration ba;elines for CIS.

3.23 Configuration Item (CI~. A configuration item

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

3.24 Conficluration Management (CM) .

a. As applied to configuration items, a discipline applying technical and administrative direction surveillance over the life cycle of items to:

is an use and

(1)

(2)

(3)

(4)

Identify and document the functional and physical characteristics of configuration items. - -

Control changes to configuration items and their related documentation.

Record and report information needed to manage configuration items effectively, including the status of proposed changes and implementation status of approved changes.

Audit configuration items to verify conformance to specifications, drawings, interfac~ control documents, and other contract requirements.

b. As applied to digital data files (See MIL-HDBK-59), the application of selected configuration identification and configuration status accounting principles to:

(1) Uniquely identify the digital data files, including versions of the files and their status (e.g., working, released, submitted, approved).

(2) Record and report information needed to manage the data files effectively, including the status of updated versions of files.

3.25 Configuration Management Plan (CMP) . The document

defining how configuration management will be implemented (including policies and procedures) for a particular acquisition or program.

3.26 Configuration Status Accounting (CSA~. The recording

and reporting of information needed to manage configuration items effectively, including:

a. A record of the approved configuration documentation and identification numbers.

b. The status of proposed changes, deviations, and waivers to the configuration.

c. The implementation status of approved changes,

d. The configuration of all units of the configuration item in the operational inventory.

3.27 Contractor. 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 contractor for configuration management purposes.

3.28 Critical item. See MIL-STD-490.

3.29 Data. Recorded information, regardless of medium or

characteristics, of any nature, including administrative, managerial, financial, and technical.

3.30 Defect. See MIL-STD-109.

3.31 Deficiencies. Deficiencies consist of two types;

a. Conditions or characteristics in any item which are not in accordance with the item’s current approved configuration documentation; or

b. Inadequate (or erroneous) item configuration documentation which has resulted, or may result, in units of the item that do not meet the requirements for the item.

3.32 Deslcln chanqe. See “engineering change”.

10 .-

3.33 Develo~mental configuration. The contractor’s design

and associated technical documentation that defines the evolving configuration of a configuration item during development. It is under the developing contractor’s configuration control and describes the design definition and implementation. The developmental configuration for a configuration item consists of the contractor’s internally released hardware and software designs and associated .technical documentation until establishment of the formal product baseline.

3.34 Deviation. A specific written authorization, granted

prior to the manufacture of an item, to depart from a particular requirement(s) of an item’s current approved configuration documentation for a specific number of units or a specified period of time. (A deviation differs from an engineering change in that an approved engineering change requires corresponding revision of the item’s current approved configuration documentation, whereas a deviation does not.)

3.35 Enqineerinq chanqe. A change to the current approved

configuration documentation of a configuration item at any point in the life cycle of the item.

3.36 Enaineerinu chanue justification code. A code which

. indicates the reason for a Class I engineering change.

3.37 Enqineerinq Chanqe priorities. The priority

(emergency, urgent, routine) assigned to a Class I engineering change which determines the relative speed at which the Engineering Change Proposal is to be reviewed, evaluated, and, if approved, ordered and implemented.

3.38 Enqineerinq Chanqe Proposal (ECP~. A proposed

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

3.39 Enqineerinq Chanqe Proposal types. A term covering

the subdivision of Class I Engineering Change Proposals on the basis of the completeness of the available information delineating and defining the engineering change. They will be identified as preliminary or formal.

3.40 Enqineerinq release. An action whereby configuration

documentation or an item is officially made available for its intended use.

3.41 q q Release Record ( )_En ineerin ERR . A record used to release configuration documentation.

3.42 Evaluation. See DoD-STD-2168.

3.43 Exchangeability of items. See MIL-STD-280.

3.44 Firmware. See DoD-STD-2167.

3.45 ~. The ability of an item to physically interface or interconnect with or become an integral part of another item.

3.46 Form. The shape, size, dimensions, mass, weight, and

other visual parameters which uniquely characterize an item. For software, form denotes the language and media.

3.47 Function. The action or actions which an item is

designed to perform.

3.48 Functional area. A distinct group of system

performance requirements which, together with all other such groupings, forms the next lower-level breakdown of the system on the basis of function.

3.49 Functional Baseline (FBL) . The initially approved

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

3.50 Functional characteristics. Quantitative performance

parameters and design constraints, including operational and logistic parameters and their respective tolerances. Functional characteristics include all performance parameters, such as range, speed, lethality, reliability, maintainability, and safety.

3.51 Yunct ional Configuration Audit (FCA)_. The formal

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

3.52 Functional Configuration Documentation .(FCD1 . The

approved functional baseline plus approved changes.

3.53 Hardware. Items made of material, such as weapons, aircraft, ships, tools, computers, vehicles, and their components (mechanical, electrical, electronic, hydraulic, pneumatic).

Computer software and technical documentation are excluded.

3.54 Hardware Configuration Item (HWCI) . A configuration

item that is hardware.

3.55 Integrated Loqistics sum ort (ILS}. See

MIL-STD-1388-1.

3.56 Interchangeable item. See MIL-STD-280.

3.57 Interface. The functional and physical

characteristics required to exist at a common boundary.

3.58 Interface control. The process of identifying, documenting, and controlling all functional and physical characteristics relevant to the interfacing of two or more items provided by one or more organizations.

3.59 Interface Control Documentation (ICD) . Interface

control drawing or other documentation which depicts physical and functional interfaces of related or co-functioning items.

3.60 Interface Control Workinq Grou~ (ICWG1. For programs

which encompass a system, configuration item, or a computer software configuration item design cycle, an ICWG is established to control interface activity among the Government, contractors, or other agencies, including resolution of interface problems and documentation of interface agreements.

3.61 Intero~erabilitv. The ability of the defense services

and agencies to exchange information with each other (joint operations) or with an allied system (combined operations) to enable them to operate effectively together.

3.62 Item. See MIL-STD-280.

3.63 Life cvcle. A generic term covering all phases of

acquisition, operation, and logistics support of an item, beginning with concept definition and continuing through disposal of the item.

3.64 Life cvcle cost. The total cost to the Government of

acquisition and ownership of that system over its life cycle. It includes the cost of development, acquisition, support, and where applicable, disposal.

3.65 Manufacturer’s code. See “Commercial and Government

Entity (CAGE) code”.

3.66 Material. A generic term covering systems, equipment, _

stores, supplies, and spares, including related documentation, manuals, computer hardware, and software.

3.67 Non-conformance. The failure of a unit or product to

conform to specified requirements.

3.68 Non-develo~mental Item (NDI)_. Non-developmental item

is a broad generic term that covers material available from a wide variety of sources with little or no development effort required by the Government. NDIs include:

a. Items obtained from a domestic or foreign commercial marketplace.

b. Items already developed and in use by the Services, other Defense activities, and Government agencies.

c. Items already developed by foreign governments which can be supplied in accordance with mutual defense cooperation agreements and Federal and DoD acquisition regulations. (SD-2)

3.69 Non-recurrinu costs. As applied to ECPS, these are

one time costs, which will be incurred if an engineering change is approved and which are independent of the quantity of items changed, such as cost of redesign, special tooling, or t@.Sting.

3.70 Notice of Revision (NOR) . A document used to define

revisions to drawings, associated lists, or other referenced documents which require revision after Engineering Change Proposal approval.

3.71 Oriqinal. The current design activity document or

digital data file(s) of record.

3.72 Physical characteristics. Quantitative and

qualitative expressions of material features, such as composition, dimensions, finishes, form, fit, and their respective tolerances.

3.73 Phvsical Configuration Audit ( )PCA . The formal

examination of the “as-built” configuration of a configuration item against its technical documentation to establish or verify the configuration item’s product baseline.

3.74 Product Baseline (PBL] . The initially approved

documentation describing all of the necessary functional and physical characteristics of the configuration item and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the configuration item. In addition to this documentation, the product baseline of a configuration item may consist of the actual equipment and software.

3.75 Product Conficiuration Documentation (PCD) . The

approved product baseline plus approved changes.

3.76 Recurrinu costs . Costs which are incurred for each

item changed or for each service or document ordered.

3.77 Release. The designation by the contractor that a

document is complete and suitable for use. Release means that the document is subject to the contractor’s configuration control procedures.

3.78 Repair. See MIL-STD-1520.

3.79 Re~lacement item. See MIL-STD-280.

3.80 Retrofit. The incorporation of new design partsL. resulting from an approved engineering change to an item’s current approved product configuration documentation into already accepted and/or operational items.

3.81 Rework. See MIL-STD-1520.

3.82 Software. See “Computer software” in DoD-STD-2167.

3.83 Specification. See MIL-STD-961.

3.84 S~ecification Chanqe Notice (SCN) . A document used to

propose, transmit, and record changes to a specification.

3.85 Substitute item. See MIL-STD-280.

3.86 SUE)port euui~ment. Equipment and computer software

required to maintain, test, or operate an item or facility in its intended environment.

3.87 Survivability. The capability of a system to avoid or

withstand a hostile environment without suffering an abortive impairment of its ability to accomplish its designated mission.

3.88 System. See MIL-STD-280.

3.89 Technical data. Technical data is recorded

information (regardless of the form or method of recording) of a scientific or technical nature (including computer software documentation) relating to supplies procured by an agency.

Technical data does not include computer software or financial, administrative, cost or pricing, or management data or other information incidental to contract administration.

a.

b.

c.

Technical data is required to define and document an engineering design or product configuration (sufficient to allow duplication of the original items) and is used to support production, engineering, and logistics activities.

A technical data package should include all engineering drawings, associated lists, process descriptions, and other documents which define the physical geometry, material composition, performance characteristics, manufacture, assembly, and acceptance test procedures.

Technical data which provides instructions for the installation, operation, maintenance, training, and support of a system or equipment can be formatted into a technical manual.

(1) A technical manual normally includes operation and maintenance instructions, parts lists or parts breakdown, and related technical information or procedures exclusive of administrative procedures.

(2) This data may be presented in any form (e.g., hard copy, audio and visual displays, magnetic tape, disks, or other electronic devices) .

(3) Technical orders that meet the criteria of this definition may also be classified as technical manuals. (Title 10, United States Code, Section 2302, “Definitions”)

3.90 Technical data packaue. See “Technical data”.

3.91 Technical documentation. See “Technical data”.

3.92 Technical reviews. A series of system engineering

activities by which the technical progress on a project is assessed relative to its technical or contractual requirements.

The reviews are conducted at logical transition points in the development effort to identify and correct problems resulting from the work completed thus far before the problems can disrupt or delay the technical progress. The reviews provide a method for the contractor and Government to determine that the development of a configuration item and its documentation have met contract requirements.

3.93 Traininq euuipment. All types of maintenance and

operator training hardware, devices, audio-visual training aids, and related software which:

a. Are used to train maintenance and operator personnel by depicting, simulating, or portraying the operational or maintenance characteristics of an item or facility.

b. Are kept consistent in design, construction, and configuration with such items in order to provide required training capability.

3.94 Unit. See MIL-STD-280.

3.95 Version. An identified and documented body of

software. Modifications to a version of software (resulting in a new version) require configuration management actions by either the contractor, the Government, or both.

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

3.97 Work Breakdown Structure (WBS). See MIL-STD-881.

3.98 Work breakdown structure element. See MIL-STD-881.

4. GENERAL REQUIREMENTS

4.1 Basic requirements. The contractor shall implement an

internal configuration management system for the control of all configuration documentation, physical media, and physical parts representing or comprising the product. For software, the system shall address the evolving developmental configuration and support environments (engineering, implementation and test) used to generate and test the product. The contractor’s configuration management system shall consist of the following elements:

a. Configuration identification.

b. Configuration control.

c. Configuration status accounting.

d. Configuration audits.

Contractors shall implement the requirements of this standard as identified in the contract statement of work (SOW) to CIS and shall insure compliance with those requirements by subcontractors.

4.2 Planninq. The contractor shall plan a configuration

management program in accordance with the requirements of this standard, tailored appropriately for the particular CI(S), their scope and complexity, and the contracted phase(s) of the life cycle. Planning shall be consistent with the objectives of a continuous improvement program which includes the analysis of identified problem areas and correction of procedures as necessary to prevent reoccurrence. The contractor’s configuration management planning shall include:

a. The objectives of the configuration management program and of each applicable configuration management element;

b. The configuration management organization and organizational relationships;

c. Responsibilities and authority of configuration management managers;

d. Configuration management resources (tools, techniques, and methodologies) ;

e. Coordination with internal and external agencies (e.g., program managers, other contractors, other Government agencies, CCBS, foreign governments) ;

f. Configuration management policies, processes, procedures, methods, records, reports and forms; and

9. Computer-aided Acquisition and Logistics Support (CALS) configuration management in accordance with paragraph 4.3.

4.3 Computer-aided Acquisition and Louistic SUP Port (CALS~.

Configuration documentation shall be provided in either hard copy data transfer, transfer of processable data files, interactive access to data through contractor integrated technical information services, or a combination of the above, 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 Government, as applicable and in accordance with the changes clause of the contract, any requirements that may be imposed on the Government that will require associated contractor effort to maintain the security and integrity of shared data.

4.3.1 Data distribution/access. The contractor shall

assign distribution codes in accordance with MIL-STD-1806.

Access to data shall be limited in accordance with the applicable distribution codes, 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). (See MIL-HDBK-59)

4.3.2 Automated Rrocessinff 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 a form (e.g., DD Form 1692 for an ECP), the contractor may provide the data on an electronic version of the form or may sequentially address the essential and applicable data elements of the submitted data by block number or title, as applicable. 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.

a. When data are submitted by electronically transferring (e.g., modem) by the contractor to the Government, acknowledgement of receipt will be generated at the end of the transmission. When data is electronically transferred by the Government 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.

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

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

(1) Identification of data files submitted to the Government for review, annotation, comment and approval/disapproval, as applicable in accordance with Government 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.

(2) How data and changes are transmitted.

(3) How changes from previous versions are indicated.

(4) Notification/acknowledgement of receipt, return, or acceptance.

(5) Indication of time constraints, if any, for automatic data acceptance; and

(6) Data status accounting.

4.3.3 Interactive access to diqital data. In addition to

the above requirements, the contractor’s 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 data bases and files during the Government’s and contractor’s interactive review and update cycles. As a minimum, the following shall be defined:

a.

b.

c.

d.

e.

f.

9“ h.

i.

4.4

How data is to be accessed;

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

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

Means of indicating…