MIL-HDBK-61B DoD Configuration Management Guidance.pdf

AMSC N/A AREA SESS

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

NOT MEASURMENT

SENSITIVE

MIL-HDBK-61B

7 April 2020

SUPERSEDING

MIL-HDBK-61A(SE)

7 February 2001

DEPARTMENT OF DEFENSE

HANDBOOK

CONFIGURATION MANAGEMENT GUIDANCE

This handbook is for guidance only.

Do not cite this document as a requirement.

Source: http://assist.dla.mil -- Downloaded: 2023-08-03T15:47Z Check the source to verify that this is the current version before use.

MIL-HDBK-61B

ii

FOREWORD

1. This handbook is approved for use by all Departments and Agencies of the Department of Defense.

2. Configuration Management (CM) is a technical discipline that ensures requirements, development, and operational information remains consistent throughout the program life cycle. This handbook provides guidance to personnel assigned the responsibility of executing hardware and software configuration management processes in the design, procurement, installation, operation, maintenance, and modification of acquired products. As such, it outlines and discusses the principles of CM: configuration management planning, configuration identification, configuration change control, configuration audits, and configuration status accounting. In addition, this handbook addresses application of these principles in areas such as data management, hardware versus software configuration items, and digital versus non-digital artifacts.

3. Major changes to this document include the removal of duplicative information now contained in

GEIA-HB-649A, except where clarity is required.

4. Public Law 104-113, “National Technology Transfer and Advancement Act”, stipulates that Federal

Agencies shall use technical standards developed or adopted by voluntary consensus standards bodies unless impractical or inconsistent with law. In accordance with P.L. 104-113, Department of Defense (DoD) standardization for Configuration Management has evolved from the use of military standards to include the use of industry standards many of which are referenced herein. While the use of industry standards on DoD acquisition contracts is not mandatory unless stipulated by statute or policy, program managers should consider whether the use of standards on their program is beneficial in establishing and maintaining an efficient and effective CM process. In order to mitigate program cost, schedule, and technical risk, this revision to MIL-HDBK-61 is being issued to provide up-to-date guidance on applying CM requirements on DoD acquisition contracts. Appendix C provides recommendations for selection and tailoring of CM elements to be applied by program type.

5. Comments, suggestions, or questions on this document should be addressed to Commander, Naval Sea

Systems Command, ATTN: SEA 05S, 1333 Isaac Hull Avenue, SE, Stop 5160, Washington Navy Yard DC

20376-5160 or emailed to CommandStandards@navy.mil, with the subject line “Document Comment”. Since contact information can change, you may want to verify the currency of this address information using the ASSIST Online database at https://assist.dla.mil.

mailto:CommandStandards@navy.mil https://assist.dla.mil/ iii

CONTENTS

PARAGRAPH PAGE

1. SCOPE

1.1 Scope

1.1.1 Background

1.1.2 CM functions

1.1.3 CM Benefits, risks, and cost impact

2. APPLICABLE DOCUMENTS

2.1 General

2.2 Government documents

2.2.1 Specifications, standards, and handbooks

2.2.2 Other Government documents, drawings, and publications

2.3 Non-Government publications

2.4 Order of precedence

3. DEFINITIONS

3.1 Definitions and terminology

3.2 Acronyms

3.3 Definitions

4. CM LIFE CYCLE MANAGEMENT AND PLANNING

4.1 General

4.1.1 Configuration documentation

4.1.2 Industry standards

4.2 Management and planning concepts

4.2.1 CM functional activity

4.2.1.1 Management and planning

4.2.1.1.1 Management and planning constraints

4.2.1.1.2 Management and planning outputs

4.2.1.2 Configuration identification

4.2.1.3 Configuration control

4.2.1.3.1 Configuration control constraints

4.2.1.3.2 Configuration control documentation

4.2.1.4 CSA

4.2.1.4.1 CSA information

4.2.1.4.2 Metrics

4.2.1.5 Configuration verification and audit

4.2.1.5.1 Configuration inputs and outputs

4.2.1.5.2 Verification and audit

4.2.2 Relation to systems engineering process

4.2.2.1 Systems engineering and CM

iv

CONTENTS

PARAGRAPH PAGE

4.2.2.2 Systems engineering process

4.2.3 Relation to logistics process

4.2.3.1 Maintenance plan

4.2.3.2 Logistics support

4.3 Government management and planning activities

4.3.1 Preparing for the next phase

4.3.1.1 CM Planning

4.3.1.2 CM roles and responsibilities

4.3.1.3 Request for proposal (RFP)

4.3.1.4 CM analysis and justification

4.3.2 Implementing the government CM process

4.3.3 Measuring/evaluating government/contractor CM process

4.3.3.1 DCMA

4.3.3.2 Continuous improvement metrics

4.3.3.3 CM cross functionality

5. CONFIGURATION IDENTIFICATION

5.1 Configuration identification activity

5.1.1 Basic principles of configuration identification

5.2 Configuration identification practices

5.3 CIs

5.3.1 CI concepts

5.3.1.1 CI control

5.3.1.2 CI selection

5.3.1.3 CIs for hardware and software

5.3.1.4 Designating separate CIs

5.3.1.5 Importance of CI selection

5.4 Configuration documentation

5.4.1 Specification types

5.4.2 Design constraints

5.4.2.1 Drawings and models

5.4.2.2 Digital thread

5.4.2.3 CSCI

5.4.2.4 Efficient design solutions

5.4.2.5 Defining configuration control

5.5 Configuration baselines

5.5.1 Baseline concepts

5.5.1.1 Acquisition program baseline (APB)

v

CONTENTS

PARAGRAPH PAGE

5.5.1.2 Baseline representations

5.5.2 Major configuration baselines

5.5.2.1 Incremental baselines

5.5.2.2 Elements of an FBL

5.5.2.3 Elements of an ABL

5.5.2.4 ABL configuration control

5.5.2.5 Established baselines

5.5.2.6 Interface control documents

5.5.2.7 Contractor design responsibilities

5.5.2.8 PBL

5.5.2.9 PBL configuration control

5.5.2.10 Document order of precedence

5.6 Document and item identification

5.6.1 Document identification

5.6.1.1 Document representations

5.6.1.2 Document responsibilities

5.6.2 Item identification concepts

5.6.2.1 Tracking identifiers

5.6.2.1.1 Military nomenclature and nameplates

5.6.2.1.2 Part or identifying numbers (PIN)

5.6.2.1.3 Software identifiers

5.6.2.1.4 Serial and lot numbers

5.6.2.1.4.1 Serial numbers

5.6.2.1.4.2 Shop numbers

5.6.2.1.4.3 Lot numbers

5.7 Engineering release

5.7.1 Class I changes

5.7.2 Engineering release records

5.7.3 Revision traceability

5.7.4 Release records

5.7.5 Engineering change process

5.7.6 Design disclosure

5.7.7 Government data repository

5.8 Interface management

5.8.1 Interface management activities

5.8.1.1 Interface categorization

5.8.1.2 Contractual relationships

vi

CONTENTS

PARAGRAPH PAGE

5.8.1.3 IPTs

6. CONFIGURATION CONTROL

6.1 Configuration control activity

6.1.1 Configuration control objectives

6.1.1.1 Span of configuration control

6.1.1.2 Configuration control changes

6.1.1.3 Government change approval

6.1.1.4 Contractor change approval

6.1.1.5 Configuration control risks

6.1.2 Configuration control general concepts and principles

6.1.2.1 Configuration control process evolution

6.1.2.2 TMRR phase

6.1.2.3 EMD, production and deployment, and operation and support phases

6.1.3 Configuration approval authority

6.1.3.1 Government configuration control

6.1.3.2 Contractual configuration approval authority

6.1.4 Change classification

6.1.5 CCB

6.2 RFV

6.2.1 RFV concepts and principles

6.2.1.1 RFV classification

6.2.1.2 RFV approval

6.3 NOR

7. CONFIGURATION STATUS ACCOUNTING (CSA)

7.1 CSA activity

7.2 CSA inputs and outputs

7.2.1 CSA process

7.2.2 CSA tools

7.2.3 CSA data

8. CONFIGURATION VERIFICATION AND AUDIT

8.1 Configuration verification and audit activity

8.1.1 Configuration verification and audit activity inputs

8.1.2 Configuration verification and audit activity completion

8.2 Configuration verification and audit concepts and principles

8.2.1 Configuration verification process

8.2.1.1 Change verification

8.2.1.2 Change implementation

vii

CONTENTS

PARAGRAPH PAGE

8.2.2 Configuration audits

8.2.2.1 Configuration audit activity

8.2.2.1.1 Configuration audit phase

8.2.2.1.2 Configuration audit process

8.2.2.2 FCA

8.2.2.3 PCA

8.2.2.4 Application of audits during life cycle

8.2.2.5 Auditing in the performance-based acquisition environment

8.2.2.5.1 Audit certifications

8.2.2.5.2 Audit certifications before acquisition reform

9. DATA MANAGEMENT (DM)

9.1 Description of DM

9.2 Relationship to CM

9.3 DM activities

9.3.1 DM cost drives

9.3.1.1 Key DM activities

9.3.1.2 Key DM points

9.3.2 Data acquisition

9.3.3 Data/IP rights

9.3.4 Data access vs. data delivery

9.3.5 Data storage

9.3.5.1 Master data sources

9.3.6 DM and use

9.3.7 Master DM

10. EMERGING TECHNOLOGIES

10.1 Introduction of emerging technology influencing CM and DM

10.2 Need for updating engineering practice

10.3 CM for digital environment

10.3.1 Digital environments

10.3.2 Modeling in a digital environment

10.3.4 Inserting changes

10.3.5 Digital twin

10.4 CM for digital artifacts (tracking digital views [prepared deliverables for the customer])

10.5 CM for processes, algorithms, and computations (data)

10.6 MOSA

10.6.1 MOSA in DoD defense systems

10.6.2 Consideration of commercial-off-the-shelf (COTS) for MOSA solutions viii

CONTENTS

PARAGRAPH PAGE

10.6.3 MOSA hardware and software reuse considerations

10.6.4 MOSA architecture considerations

10.6.4.1 MOSA interface management

10.6.4.2 MOSA systems dependencies and interdependencies

10.6.4.3 DM access

11. NOTES

11.1 Intended use

11.2 Subject term (key word) listing

11.3 Changes from previous issue

APPENDIX A. CONFIGURATION MANAGEMENT DOCUMENTATION

A.1 SCOPE

A.1.1 Scope

A.1.2 Configuration management considerations for international acquisition and exportability

APPENDIX B. SAE EIA-649-1 TAILORING GUIDANCE

B.1 SCOPE

B.1.1 Scope

B.2 GUIDANCE CRITERIA

B.2.1 CM for DoD contracts

B.2.2 Tailoring guidance

B.2.3 Copyright guidance

B.2.4 Statement of work guidance

B.2.5 Life cycle applicability guidance

B.3 CM REQUIREMENTS

B.3.1 CM lifecycle requirements

B.3.2 CM requirements selection process

APPENDIX C. CM TEMPLATES

C.1 SCOPE

C.1.1 Scope ix

CONTENTS

LIST OF FIGURES

FIGURE PAGE

FIGURE 1 Configuration management standards

FIGURE 2. Configuration management process implementation view

FIGURE 3. Top level configuration management activity model

FIGURE 4. How CM relates to systems engineering

FIGURE 5. How CM relates to logistics

FIGURE 6. Implementations of “global” Government CM management activity

FIGURE 7. Status accounting objects

FIGURE 8. Configuration status accounting tasks

FIGURE 9. DM life cycle costs

FIGURE B-1 Configuration management for DoD Contracts

FIGURE B-2. CM lifecycle requirements flow chart

FIGURE C-1. TMRR phase

FIGURE C-2. EMD phase

FIGURE C-3. Production and deployment phase

FIGURE C-4. Operations and support phase

CONTENTS

LIST OF TABLES

TABLE PAGE

TABLE I. Typical CSA information over the acquisition program life cycle

TABLE A-1. Configuration management documents (not exhaustive)

1. SCOPE

1.1 Scope. This military handbook provides guidance and best practices on how Program Managers (PM), systems engineers, logistics managers, and other individuals assigned responsibility for Configuration Management

(CM) perform and contract for CM. Its purpose is to provide for guidance in planning and implementing effective

Department of Defense (DoD) CM activities and practices during the life cycle of the defense systems. This handbook is intended to cover the DoD specific management activities related to acquisition and sustainment throughout the system’s lifecycle. This handbook is for guidance only and cannot be cited as a requirement.

1.1.1 Background. DoD has adopted EIA-649, Configuration Management Standard, and its suite of documents. In a collaborated effort, the DoD and industry have worked to update, consolidate, and reduce unnecessary duplication as pertaining to DoD and Industry CM standards and handbooks. This handbook refers the reader to the suite of EIA-649 standards and handbook for more in-depth descriptions of CM application. The full

CM portfolio of standards is shown in figure 1. This handbook also provides tailoring recommendations when putting EIA-649-1 requirements on contract. DoD Configuration Managers, in order to interpret MIL-HDBK-61 to the fullest extent and utilize examples of how to implement each function of CM, will need to incorporate the following in their CM toolkit:

a. SAE-EIA-649

b. SAE-EIA-649-1

c. GEIA-HB-649

Appendix A provides a listing of CM references by policy, standards, and guidance.

FIGURE 1. Configuration management standards.

1.1.2 CM functions. The CM process is comprised of five CM functions and the underlying CM principles that together provide a flexible implementation structure. The CM process provides consistency among the various elements of product configuration information. The five CM functions are:

a. Configuration Management and Planning

b. Configuration Identification

c. Configuration Control/Change Management

d. Configuration Status Accounting

e. Configuration Verification and Audit

The underlying CM principles are explained in detail to illustrate how they might be implemented for a configuration item (CI) (e.g., hardware, software, firmware, and associated documentation). Specific implementation examples are provided for most CM principles. The CM practitioner should determine the appropriate level of implementation.

1.1.3 CM Benefits, risks, and cost impact. CM provides knowledge of the correct current configuration of defense assets and the relationship of those assets to associated documents. The CM process efficiently manages necessary changes, ensuring that all impacts to operation and support are addressed. CM provides the following benefits:

a. Product attributes are defined. Measurable performance parameters are provided. Both buyer and seller have a common basis for acquisition and use of the product.

b. Product configuration is documented and a known basis for making changes is established. Decisions are based on correct, current information. Production repeatability is enhanced.

c. Products are labeled and correlated with their associated requirements, design, and product information.

The applicable data (such as for procurement, design, or servicing the product) is accessible, avoiding guesswork and trial and error.

d. Proposed changes are identified and evaluated for impact prior to making change decisions. Downstream surprises are avoided. Cost and schedule savings are realized.

e. Change activity is managed using a defined process. Costly errors of ad hoc, erratic change management are avoided.

f. Configuration information, captured during the product definition, change management, product build, distribution, operation, and disposal processes (the equivalent of the DoD acquisition life cycle) is organized for retrieval of key information and relationships, as needed. Timely, accurate information avoids costly delays and product down time, ensures proper replacement and repair, and decreases maintenance costs.

g. Actual product configuration is verified against the required attributes. Incorporation of changes to the product is verified and recorded throughout the product life. A high level of confidence in the product information is established.

These benefits are equally applicable to Government and industry. Additionally, the effective application of CM principles to defense products contributes to and enhances the partnering environment desired between the DoD and its suppliers. In the absence of CM, or where it is ineffectual, there may be equipment failures due to incorrect part installation or replacement; schedule delays and increased cost due to unanticipated changes; operational delays due to mismatches with support assets; maintenance problems, down-time, and increased maintenance cost due to inconsistencies between equipment and its maintenance instructions; and numerous other circumstances which decrease operational effectiveness and add cost.

The severest consequence is catastrophic loss of expensive equipment and human life. However, these failures may be attributed to causes other than poor CM. The intent of CM is to avoid cost and minimize risk. Those who consider the small investment in the CM process a cost-driver may not be considering the compensating benefits of

CM and may be ignoring or underestimating the cost, schedule, and technical risk of an inadequate or delayed CM process. Throughout this handbook, selection criteria are provided to aid in making choices concerning implementation of various CM activities and functions. In each applicable instance, the means to complete a benefit/risk analysis is provided.

2. APPLICABLE DOCUMENTS

2.1 General. The documents listed below are not necessarily all of the documents referenced herein, but are those needed to understand the information provided by this handbook.

2.2 Government documents.

2.2.1 Specifications, standards, and handbooks. The following specifications, standards, and handbooks form a part of this document to the extent specified herein.

DEPARTMENT OF DEFENSE STANDARDS

MIL-STD-961 - Defense and Program-Unique Specifications Format and Content

MIL-STD-31000 - Technical Data Packages

(Copies of these documents are available online at https://quicksearch.dla.mil/.)

2.2.2 Other Government documents, drawings, and publications. The following other Government documents, drawings, and publications form a part of this document to the extent specified herein.

DATA ITEM DESCRIPTIONS

DI-MGMT-82099 - Open Systems Management Plan

(Copies of this document are available online at https://quicksearch.dla.mil/.)

DEPARTMENT OF DEFENSE ISSUANCES

DoD Instruction 5000.02 - Operation of the Defense Acquisition System

DoD 5010.12-M - Procedures for the Acquisition and Management of Technical Data

(Copies of these documents are available online at www.esd.whs.mil/DD/.)

FEDERAL ACQUISITION REGULATION (FAR)

FAR Part 7 - Acquisition Planning

FAR Part 46 - Quality Assurance

(Copies of the Federal Acquisition Regulation (FAR) are available online at https://www.acquisition.gov/far.)

2.3 Non-Government publications. The following documents form a part of this document to the extent specified herein.

SAE INTERNATIONAL

SAE EIA-649 - Configuration Management Standard

SAE EIA-649-1 - Configuration Management Requirements for Defense Contracts

GEIA-HB-649 - Configuration Management Standard Implementation Guide

GEIA-859 - Data Management

(Copies of these documents are available online at www.sae.org.)

IEEE

IEEE 828 - Configuration Management in Systems and Software Engineering

(Copies of this document are available online at www.ieee.org.)

Source: http://assist.dla.mil -- Downloaded: 2023-08-03T15:47Z Check the source to verify that this is the current version before use.

https://quicksearch.dla.mil/ https://quicksearch.dla.mil/ http://www.esd.whs.mil/DD/ https://www.acquisition.gov/far http://www.sae.org/ http://www.ieee.org/

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION

ISO 9000 - Quality Management Systems - Fundamentals and Vocabulary

ISO 10007 - Quality Management – Guidelines for Configuration Management

ISO/IEC/IEEE 12207 - Systems and Software Engineering – Software Life Cycle Processes

(Copies of these documents are available online at www.iso.org.)

2.4 Order of precedence. 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.

3. DEFINITIONS

3.1 Definitions and terminology. Since a major goal of acquisition streamlining is to use commercial and industry practices to the greatest extent possible, there is no single correct set of CM terminology that must be rigidly adhered to. SAE EIA-649 illustrates many aliases that are commonly used in different industrial environments. It is appropriate to allow the use of terms common (local) to a given industry when dealing with that industry. The acronyms and definitions in this section are provided for reference:

3.2 Acronyms.

ACRONYM TERM

AA Application Activity

ABL Allocated Baseline

ACD Allocated Configuration Documentation

ACO Administrative Contracting Officer

AECMA Association Européenne des Constructeurs de Matériel Aérospatial (European

Association of Aerospace Industries)

AIS Automated Information System

AMSDL Acquisition Management Systems and Data Requirements Control List

APB Acquisition Program Baseline

CAGE Commercial and Government Entity

CASE Computer-Aided Software Engineering

CCB Configuration Control Board

CDCA Current Document Change Authority

CDR Critical Design Review

CDRL Contract Data Requirements List

CI Configuration Item

CM Configuration Management

COTS Commercial-Off-the-Shelf

CSA Configuration Status Accounting

CSCI Computer Software Configuration Item

DCMA [U.S.] Defense Contract Management Agency

DFARS [U.S.] Defense Department Supplement to the Federal Acquisition Regulation

DID Data Item Description

Source: http://assist.dla.mil -- Downloaded: 2023-08-03T15:47Z http://www.iso.org/

ACRONYM TERM

DM Data Management

DoD [U.S.] Department of Defense

ECP Engineering Change Proposal

EIA Electronic Industries Association

EMD Engineering and Manufacturing Development

FBL Functional Baseline

FCA Functional Configuration Audit

FCD Functional Configuration Documentation

FRP Full-Rate Production

HWCI Hardware Configuration Item

ICD Interface Control Documentation

ICWG Interface Control Working Group

IEEE Institute of Electrical and Electronics Engineering

IPT Integrated Product Team

ISO International Standardization Organization

LRIP Low-Rate Initial Production

MIL-STD Military Standard

MOSA Modular Open Systems Approach

MSA Material Solution Analysis

NATO North Atlantic Treaty Organization

NDI Non-Developmental Items

NIST [U.S.] National Institute of Standards and Technology

NOR Notice of Revision

OEM Original Equipment Manufacturer

PBL Product Baseline

PCA Physical Configuration Audit

PCD Product Configuration Documentation

PDM Product Data Management [System]

PIN Part or Identifying Number

RFV Request for Variance

SAE Society of Automotive Engineers

SOW Statement of Work

STANAG Standard NATO Agreement

TDP Technical Data Package

TMRR Technology Maturation and Risk Reduction

3.3 Definitions. Definitions for CM terms used in this standard are consistent with Government terminology found in the Defense Acquisition Guidebook (DAG), Defense Acquisition University (DAU), and SAE EIA-649-1.

TERM DEFINITION

Allocated Baseline

(ABL)

Documentation that designates the CIs making up a system and then allocates the system function and performance requirements across the CIs. It includes all functional and interface characteristics that are allocated from those of a higher-level CI or from the system itself, derived requirements, interface requirements with other CIs, design restraints, and the verification required to demonstrate the achievement of specified functional and interface characteristics. The performance of each CI in the ABL is described in its item performance specification.

Allocated Configuration

Documentation (ACD)

The documentation describing a CI’s functional, performance, and interoperability requirements that are allocated from those of a system or higher-level CIs; interface requirements with interfacing CIs; and the verifications required to confirm the achievement of those specified requirements.

Application Activity

(AA)

An activity that has selected an item or a document for use on programs under its control. However, it is not the current document change authority for the document(s).

Approved Document

(or Data)

A document that has been approved by an appropriate authority and is the official

(identified) version of the document until replaced by another approved version.

Assembly A number of basic parts or subassemblies, or any combination thereof, joined together to perform a specific function. Typical examples include electric generators, audio-frequency amplifiers, and power supplies.

Change, Major (Class I) An engineering change proposal (ECP) proposing a change to approved configuration documentation for which the Government is the current document change authority

(CDCA) or that has been included in the contractor SOW by the tasking activity and:

a. Affects any physical or functional requirement in approved functional or allocated configuration documentation.

b. Affects any approved functional, allocated, or product configuration documentation and cost, warranties or contract milestones, or affects approved product configuration documentation.

Change, Minor (Class II) An ECP proposing a change to approved configuration documentation for which the

Government is the CDCA or that has been included in the contractor SOW by the tasking activity and which is not a Class I.

Component A part, subassembly, or assembly that comprises a composite part of a higher-level CI.

Components are identified in the product hierarchy, assigned nomenclature and identifiers, and defined via drawings, detailed specifications, performance specifications, commercial item definitions, or other means.

Computer Software

Configuration Item

(CSCI)

A CI that is computer software.

Computer Software

Documentation

Technical data or information, including computer listings, regardless of media, that document the requirements, design, or details of software, explain the capabilities and limitations of the software, or provide operating instructions for using or supporting software.

TERM DEFINITION

Configuration A collection of an item’s descriptive and governing characteristics that can be expressed in functional terms (i.e., what performance the item is expected to achieve) and in physical terms (i.e., what the item should look like and consist of when it is built).

Configuration represents the requirements, architecture, design, and implementation that define a particular version of a system or system component.

Configuration Baseline

(Baseline)

a. An agreed-to description of the attributes of a product, at a point in time, which serves as a basis for defining change.

b. An approved and released document, or a set of documents, each of a specific revision; the purpose of which is to provide a defined basis for managing change.

c. The currently approved and released configuration documentation.

d. A released set of files comprising a software version and associated configuration documentation.

See also: Allocated Baseline (ABL), Functional Baseline (FBL), and Product Baseline

(PBL).

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

b. The CM activity concerning the systematic proposal, justification, evaluation, coordination, and disposition of proposed changes and the implementation of all approved and released changes into:

(1) The applicable configurations of a product.

(2) Associated product information.

(3) Supporting and interfacing products and their associated product information.

Configuration Control

Board (CCB)

An official forum composed of technical, logistics, acquisition, management, and administrative personnel who recommend approval or disapproval of proposed changes to, and variances from, an item’s approved configuration documentation.

Configuration Control

Board Directive (CCBD)

The document that records the ECP approval (or disapproval) decision of the CCB and provides the direction to the contracting activity either to incorporate the ECP into the contract for performing activity implementation or communicate the disapproval to the performing activity.

Configuration

Documentation

Technical documentation that identifies and defines a product’s performance, functional, and physical attributes (e.g., specifications, drawings). See also: allocated

Configuration Documentation (ACD), Functional Configuration Documentation (FCD), and Product Configuration Documentation (PCD).

Configuration

Identification

a. The systematic process of selecting the product attributes, organizing associated information about the attributes, and stating the attributes.

b. Unique identifiers for a product and its configuration documents.

c. The CM activity that encompasses the selection of CIs, the determination of the types of configuration documentation required for each CI, the issuance of numbers and other identifiers affixed to the CIs and to the technical documentation that defines the CI’s configuration, the release of CIs and their associated configuration documentation, and the establishment of configuration baselines for CIs.

Configuration Item (CI) a. An aggregation of hardware, software, or both that is designated for CM and treated as a single entity in the CM process.

b. The entity within a configuration that satisfies an end use function and that can be uniquely identified at a given reference point.

TERM DEFINITION

Configuration

Management (CM)

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

Configuration Manager The Government activity responsible for buying, managing, and sustaining the systems and items of hardware and software. The person(s) responsible for ensuring that the

CM process is successfully executed for those systems and items is hereinafter referred to as the configuration manager.

Configuration

Management Plan

(CMP)

The document that defines how CM will be implemented (including policies and procedures) for a particular acquisition or program.

Configuration Status

Accounting (CSA)

The CM function that formalizes the recording and reporting of the established product configuration information (including historical information), the status of proposed changes, and the implementation of approved changes and changes occurring to product units due to operation and maintenance. CSA implementation includes assurances that the information is current, accurate, and retrievable.

Contract As used herein, denotes the document (e.g., contract, memorandum of agreement or understanding, purchase order) used to implement an agreement between a tasking activity (i.e., buyer) and a performing activity (i.e., seller).

Current Document

Change Authority

(CDCA)

The authority currently responsible for the content of a drawing, specification, or other document that is the sole authority for approval of changes to that document. See also:

Application Activity (AA) and Approval.

Data Information (e.g., concepts, thoughts, administrative, managerial, financial, and technical) that has been recorded in a form that is convenient to move or process regardless of medium or characteristics. Data can be tables of values of various types, numbers, characteristics, etc. See also: Data Item and Document.

Database A collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system.

Data Item A document or collection of documents that must be submitted by the performing activity to the procuring or tasking activity to fulfill a contract or tasking directive requirement for the delivery of information.

Defect Any nonconformance of a characteristic with specified requirements.

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.

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

Design Change See Engineering Change.

Digital Artifact An artifact produced within, or generated from, the digital engineering ecosystem.

These artifacts provide data for alternative views to visualize, communicate, and deliver data, information, and knowledge to stakeholders.

Digital Engineering Information prepared by electronic means and made available to users by electronic data access, interchange, transfer, or on electronic/magnetic media.

Digital Twin An integrated multiphysics, multiscale, probabilistic simulation of an as-built system, enabled by digital thread, that uses the best available models, sensor information, and input data to mirror and predict activities/performance over the life of its corresponding physical twin.

TERM DEFINITION

Document A self-contained body of information or data that can be packaged for delivery on a single medium. Examples of documents include drawings, reports, standards, databases, application software, engineering designs, and virtual part-models.

Document

Representation

a. A set of digital files that, when viewed or printed together, collectively represent the entire document (e.g., a set of raster files or a set of initial graphics exchange specification files). A document may have more than one document representation.

b. A document in a non-digital form (e.g., example, paper, punched card set, or stable-base drawing).

Engineering Change a. A change to the current approved configuration documentation of a CI.

b. Any alteration to a product or its released configuration documentation.

Effecting an engineering change may involve modification of the product, product information, and associated interfacing products.

Engineering Change

Proposal (ECP)

A proposed engineering change to the product and its configuration documentation, by which the change is described, justified, and submitted to a Configuration Approval

Authority for approval/disapproval or deferral.

Firmware The combination of a hardware device and computer instructions or computer data that reside as read only software on the hardware.

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

Form The shape, size, dimensions, mass, weight, and other physical parameters that uniquely characterize an item. For software, form denotes the language and media.

Function The action or actions that an item is designed to perform.

Functional Baseline

(FBL)

The approved functional requirements for a product or system describing the functional, performance, interoperability, interface, and verification requirements established at a specific point in time and documented in the functional configuration documentation.

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.

Functional Configuration

Audit (FCA)

The formal examination of functional characteristics of a CI or system to verify that the item has achieved the requirements specified in its FCD or ACD.

Functional Configuration

Documentation (FCD)

The documentation describing the system’s functional, performance, interoperability, and interface requirements and the verifications required to demonstrate the achievement of those specified requirements.

Hardware Products made of material and their components (mechanical, electrical, electronic, hydraulic, and pneumatic). Computer software and technical documentation are excluded.

Hardware Configuration

Item (HWCI)

See Configuration Item (CI).

Interchangeable Item A product which possesses such functional and physical attributes as to be equivalent in performance to another product of similar or identical purposes; and is capable of being exchanged for the other product without selection for fit or performance, and without alteration of the products themselves or of adjoining products, except for adjustment.

TERM DEFINITION

Interface The performance, functional, and physical characteristics required to exist at a common boundary between two or more systems. An interface is a system external to the system being analyzed that provides a common boundary or service that is necessary for the other system to perform its mission. Interface characteristics may include, but are not limited to, functional, physical, mechanical, visual, thermodynamic, magnetic, electrical, electronic, electromagnetic, software, or a combination of these characteristics.

Interface Control The process of identifying, documenting, and controlling all performance, functional and physical attributes relevant to the interfacing of two or more products provided by one or more organizations.

Interface Control

Documentation (ICD)

Interface control drawing or other documentation that depicts physical, functional, performance, and test interfaces of related or co-functioning products.

Interface Control

Working Group (ICWG)

For programs that encompass a system, CI, or a CSCI design cycle, an ICWG is established to control interface activity among the tasking activity, performing activities, or other agencies, including resolution of interface problems and documentation of interface agreements.

Interoperability The ability to exchange information and operate effectively together.

Item A nonspecific term used to denote any product, including systems, materiel, parts, subassemblies, sets, accessories, etc.

Life cycle cost The total cost to the tasking activity of acquisition and ownership of an item over its life cycle. As applicable, it includes the cost of development, acquisition, support, and disposal.

Lot number An identifying number consisting of alpha and numeric characters that, in conjunction with a manufacturer’s identifying Commercial and Government Entity (CAGE) code and a product-tracking base-identifier, uniquely identifies a group of units of the same item which are manufactured or assembled by one producer under uniform conditions and which are expected to function in a uniform manner.

Materiel A generic term covering military systems, equipment, stores, supplies, and spares, including related documentation, manuals, computer hardware, and software.

Modular Open Systems

Approach (MOSA)

An integrated business and technical strategy that:

a. Employs a modular design that uses major system interfaces between a major system platform and a major system component, between major system components, or between major system platforms.

b. Is subjected to verification to ensure major system interfaces comply with, if available and suitable, widely supported and consensus-based standards.

c. Uses a system architecture that allows severable major system components at the appropriate level to be incrementally added, removed, or replaced throughout the life cycle of a major system platform to afford opportunities for enhanced competition and innovation while yielding significant cost savings or avoidance; schedule reduction;

opportunities for technical upgrades; increased interoperability, including system of systems interoperability and mission integration; or other benefits during the sustainment phase of a major system.

d. Complies with the technical data rights set forth in Sec 2320, title 10.

TERM DEFINITION

Nomenclature a. The combination of a Government-assigned designation and an approved item name. In certain cases, the designation root serves as the basis for assignment of serial or lot numbers.

b. Names assigned to kinds and groups of products.

c. Formal designations assigned to products by customer or supplier (such as model number or model type, design differentiation, specific design series, or configuration.)

Nonconformance The failure of a unit or product to meet a specified requirement.

Notice of Revision

(NOR)

A document used to define revisions to configuration documentation that require revision after ECP approval. See also Engineering Change Proposal (ECP).

Performing activity An activity performing any of the requirements contained in a contract or tasking directive. A performing activity can be either a contractor or Government activity.

Physical characteristics

(attributes)

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

Physical Configuration

Audit (PCA)

The physical examination is the actual configuration of the item being produced. It verifies that the related design documentation matches the item as specified in the contract. The system product baseline is finalized and validated at the PCA.

Product Baseline (PBL) Documentation describing all of the necessary functional and physical characteristics of the CI, the selected functional and physical characteristics designated for production acceptance testing, and tests necessary for deployment/installation, operation, support, training, and disposal of the CI. The initial PBL is usually established and put under configuration control at each CI’s critical design review (CDR), culminating in an initial PBL at the system-level CDR. The system PBL is finalized and validated at the

PCA.

Product Configuration

Documentation (PCD)

A CI’s detail design documentation including those verifications necessary for accepting product deliveries (first article and acceptance inspections.) Based on program production/procurement strategies, the design information contained in the

PCD can be as simple as identifying a specific part number or as complex as full design disclosure.

Product Definition

Information

Information that defines the product’s requirements, documents the product attributes, including the process information, and is the authoritative source for configuration management of the product.

Product-Tracking

Base-Identifier

An unchanging identifier used as a base for the assignment of serial numbers to uniquely identify individual units of an item or lot numbers to uniquely identify groups of units of an item. The product-tracking identifier is used rather than the Part or

Identifying Number (PIN) because the PIN is altered to reflect a new configuration when the item it identifies is modified. The same product-tracking base-identifier may be used for several similar items (usually defined by a common document) and requires that each such item is assigned serial or lot numbers distinct from each other such item.

Release The designation by the originating activity that a document representation or software version is approved by the appropriate authority and is subject to configuration change management procedures.

Released Document

(Data)

a. Document that has been released after review and internal approvals.

b. Document that has been provided to others outside the originating group or team for use (as opposed to for comment).

TERM DEFINITION

Repair A procedure which reduces, but does not completely eliminate, a nonconformance.

Repair is distinguished from rework in that the characteristic after repair still does not completely conform to the applicable drawings, specifications, or contract requirements.

Repairable item Any part or assembly which, upon failure or malfunction, is intended to be repaired or reworked.

Replacement item An item which is interchangeable with another item, but which differs physically from the original item in that the installation of the replacement item requires operations such as drilling, reaming, cutting, filing, shimming, etc., in addition to the normal application and methods of attachment.

Request for Variance

(RFV)

The means by which a manufacturer or supplier requests permission to depart from the product definition information for a specific unit, a specific number of units, or a specific period of time without requiring revision of the product definition information.

Retrofit The incorporation of new design parts or software code, resulting from an approved engineering change, to a product’s current approved PCD and into products already delivered to and accepted by customers.

Retrofit Instruction The document that provides specific, step-by-step instructions about the installation of the replacement parts to be installed in delivered units to bring their configuration up to that approved by an ECP. (Sometimes referred to as an alteration instruction, modification work order, technical directive, or time compliance technical order.)

Rework A procedure applied to a product to eliminate a nonconformance to the drawings, specifications, or contract requirements that will completely eliminate the nonconformance and result in a characteristic that conforms completely.

Serial Number A numeric or alphanumeric (except for ammunition which only uses numeric characters) sequentially issued identifier used to designate a specific instance of a product among like products. An identifying number consisting of alpha and numeric characters that is assigned sequentially in the order of manufacture or final test and that, in conjunction with a manufacturer’s identifying CAGE code, uniquely identifies a single item within a group of similar items identified by a common product-tracking base-identifier.

Software Computer programs and computer databases.

Specification A document that explicitly states essential technical attributes and requirements for a product and procedures to determine that the product’s performance meets its requirements and attributes.

Submitted Document

(Data)

Released document that has been made available to customers.

Support Equipment Equipment and computer software required to maintain, test, or operate a product or facility in its intended environment.

System A self-sufficient unit in its intended operational environment, including all equipment, related facilities, material, software, services, and personnel required for its operation and support.

Tasking Activity An organization that imposes the requirements contained in a contract or tasking directive on a performing activity (e.g., a Government contracting activity that awards a contract to a contractor, a Government program management office that tasks another

Government activity, or a contractor that tasks a subcontractor).

Technical Data Recorded information (regardless of the form or method of recording) of a scientific or technical nature (including computer software documentation).

TERM DEFINITION

Technical Data Package

(TDP)

The authoritative technical description of an item. This technical description supports an acquisition strategy and production, inspection, engineering, and logistics support for the item. The description defines the required design configuration, performance requirements, and procedures required to ensure adequacy of item performance. It consists of all applicable technical data such as models, engineering design data, associated lists, specifications, standards, performance requirements, quality assurance provisions, software documentation, and packaging details.

Technical

Documentation

See Technical Data.

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 performing activity and tasking activity to determine that the development of a CI and its documentation have a high probability of meeting contract requirements.

Training Equipment All types of maintenance and operator training hardware, devices, audio-visual training aids, and related software that:

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.

Verification All examinations, tests, and inspections necessary to verify that an item meets the physical and functional requirements for which it was designed; that a component, part, or subassembly will perform satisfactorily in its intended application; or that an item conforms to specified requirements.

Version a. One of several sequentially created configurations of a data product.

b. A supplementary identifier used to distinguish a changed body or set of computer-based data (software) from the previous configuration with the same primary identifier. Version identifiers are usually associated with data (such as files, databases, and software) used by, or maintained in, computers.

Working Document

(Data)

Document that has not been released; any document that is currently controlled solely by the originator including new versions of the document that were previously released, submitted, or approved.

4. CM LIFE CYCLE MANAGEMENT AND PLANNING

4.1 General. A basic principle of management is that responsibility, unlike authority, cannot be delegated. The

Government PM, supported by the configuration managers, has the responsibility to ensure that the operating forces are provided with correctly “configured” hardware and software and the information necessary to operate and maintain the end item effectively. Regardless of the acquisition life cycle phase, this responsibility cannot be delegated, nor can it be taken lightly (see figure 2).

CM program strategy

Plan CM

Program

Establish CM

Program

Manage CM

Program

Improve CM

Program

CM requirements and planning

CM Development and implementation

CM Implementation and maintenance

CM Maintenance and

Disposal

Configuration management tasks and activities

(Iterative)

Develop CMP: Implement CMP: Update CMP: Evaluate/review CMP:

CM Strategy Plan CM professional onboard

Budget requirement Continuous process improvement edits

CM budget requirement

Allocated baseline Initial product baseline

Budget requirements

CM performance metrics

Training provided Performance metric collection

Final product baseline

CM training plan Continuous process improvement

Training updated Performance metrics

CM process improvement metrics

Supplier and acquirer coordinate CM plans

Contract deliverables Request for change

CM Contract requirements strategy

Design review Trace requirements Configuration control board

Functional baseline Label configuration items

Request for change Accounting reports

Configuration item selection criteria

Configuration control…