Attachment 29 MIL-STD-3046 Distribution A.pdf

MIL-STD-3046(ARMY)

06 March 2013

DEPARTMENT OF DEFENSE

INTERIM STANDARD PRACTICE

CONFIGURATION MANAGEMENT

AMSC 9275 AREA SESS

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

NOT MEASUREMENT

SENSITIVE

Downloaded from http://www.everyspec.com ii

FOREWORD

1. This standard is approved for interim use by the US Army. The Defense Standardization Council approved this interim standard until a suitable non-government standard is developed or until two years from the date of this standard, at which time, this standard will be canceled.

2. Comments, suggestions, or questions for this document should be addressed to Commander, U S

Army ARDEC, ATTN: RDAR-QES-E, Picatinny Arsenal, NJ 07806-5000 or emailed to usarmy.picatinny.ardec.list.ardec-stdzn-branch@mail.mil. Since contact information can change, the user of the document should verify the currency of this address information using the ASSIST online database at https://assist.dla.mil.

MIL-STD-3046(AR)

iii

CONTENTS

PARAGRAGH PAGE

FOREWORD………………………………………………………………... ii

1. SCOPE ……………………………………………….……………….…

1.1 Scope……………………………………………………………….….…….. 1

1.2 Selective application ……………………………………………..…………. 1

1.3 Tailoring implementation………………….……………………….….…….. 1

2. APPLICABLE DOCUMENTS……………………………………………... 1

2.1 General …………………………………………………………………

2.2 Government documents …………………………………………………

2.2.1 Specifications, standards, and handbooks. ………………………………

2.2.2 Other Government document, drawings, and publications. ………………

2.3 Non-Government publications. ……………………………………………... 2

2.4 Order of precedence. ……………………………………

3. DEFINITIONS. ……………………………………………………………... 3

4. GENERAL REQUIREMENTS……………………………………………... 10

4.1 Configuration Management.…………………………………….…………... 10

4.2 Responsibility of Acquiring and Supplying Activities……………………

4.3 Functions of Configuration Management. 10

4.3.1 Configuration Planning and Management. ………………………………

4.3.2 Configuration Identification. ……………………………………………

4.3.3 Configuration Change Management. ……………………………………

4.3.4 Configuration Status Accounting (CSA) …………………………………… 11

4.3.5 Configuration Verification and Audits. …………………………….…

5. DETAILED REQUIREMENTS……………………………………

5.1 Purpose. ………………………………………………………….…

5.2 Configuration Planning and Management. …………………

5.2.1 Acquiring Activity’s Lifecycle CM Planning and Strategy ………………… 11

5.2.2 Supplying Activity’s CM Plan …………………………………………

5.2.3 Interface Management. …………………………………………….…

5.2.3.1 Requirements for an Interface Control Working Group (ICWG)..……

5.2.4 Product Data Management (PDM). ….………………………………

5.3 Configuration Identification. …….…………………………………….…

iv

5.3.1 Initial Configuration Identification Activities. ………………………

5.3.2 Detailed Configuration Identification Activities. ……………………

5.3.3 Configuration Identification Requirements. …………………………

5.3.4 Configuration Nomenclature and Identifiers ….………………………

5.3.4.1 Enterprise Identifier. ………………………………………..…………

5.3.4.2 Type Identifier and Nomenclature. ……………………………………

5.3.4.3 Document Identifier. ……………………………………………….…

5.3.4.4 Product Identifier. ……………………………………………………

5.3.4.5 Software Identifiers. …………………………………………………

5.3.4.6 Group Identifiers. ………………………………………………….…

5.3.4.7 Unit Identifiers…………………………………………………………

5. 3.4.7.1 Modification of Unit Identifiers. 16

5.3.4.8 Revisions……..……………………………………………………..…

5.3.5 Software Marking and Labeling. ………………………………………

5.3.6 Firmware Labeling. .……………………………………………………

5.3.7 Software Development Library. .…………………………………….…

5.3.8 Classified Data and Other Restrictive Marking ..……………….….…

5.4 Configuration Baselines. .………………………………………………

5.4.1 Configuration Baseline Types. ………………………………………

5.4.1.1 Functional Baseline.……………………………………………………

5.4.1.2 Allocated Baseline. ……………………………………………………

5.4.1.3 Product Baseline. …………………………………………………...…

5.4.1.3.1 Product Instance Configuration ………………………………………

5.4.2.1 Configuration Documentation. ………………………………………

5.4.2.1.1 Functional Configuration Documentation (FCD). …………………….…

5.4.2.1.2 Allocated Configuration Documentation (ACD). ………………………

5.4.2.1.3 Product Configuration Documentation (PCD). …………………………

5.4.3 Engineering Release Process.. ……………………………………………

5.5 Configuration Change Management. ………………………………..…

5.5.1 Configuration Control Status. ……………………………..…

5.5.2 Requirements of Configuration Control. ……………………………

5.5.2.1 Configuration Control of Commercial Items……………………………

5.5.3 Engineering Change Proposals (ECPs). ……………………………..…

5.5.3.1 ECP Requirements ………………………………………………….…

5.5.3.1.1 Classification of Engineering Changes. ……………………………

5.5.3.1.2 Engineering Changes. ………………………….…………………

5.5.3.1.3 Re-Type Identification. ………………………….…………………

5.5.3.1.4 Numbering and Revisions of ECPs..………………………………

5.5.3.1.5 Supporting Data. ……………………………………………………

5.5.3.1.6 Classified Data. ………………………………………………………

5.5.3.1.7 ECP Submittals. ……………………………………………………

5.5.3.1.8 Disposition of ECPs. …………………………………………………

5.5.3.1.9 ECP Types. …………………………………………………………

5.5.3.1.10 ECP Priorities. ………………………………………………………

5.5.3.1.10.1 Routine. ……………………………………………………………

5.5.3.1.10.2 Urgent. …………………………………………………………………

5.5.3.1.10.3 Emergency ………………………………………………………………….. 23

5.5.3.1.11 Expediting Changes with Priority of Emergency or Urgent. ……………….. 24

5.5.3.1.12 ECP Justification Codes. ………………………………………………

5.5.3.1.13 Value Engineering Change Proposals. …………………………………

5.5.4 Requirements for Notices of Revision (NORs). ………………………

5.5.4.1 Tabulated NOR…………………………………………………………

v

5.5.5 Requirements for Engineering Release Records (ERR). ………………

5.5.6 Requirements for Approved, Unincorporated Changes. …………………

5.5.7 Consolidation of ECPS and ERRs. ……………………………………

5.5.8 Requests for Variance (RFV). ………………………

5.5.8.1 Classification of Variances. ……………………………………………

5.5.8.2 Restrictions on Variances………………………………………………

5.5.8.3 Supporting Data for RFVs .……………………………………………

5.5.8.4 Priority of RFVs. …………………………………………………

5.5.8.5 Disposition of RFVs. …………………………………………………

5.5.8.6 Revision of RFVs. ……………………………………………………

5.5.8.7 Format. …………………………………………………………………

5.5.9 Configuration Control Board (CCB) Requirements. ……………………

5.5.10 Configuration Management Officer (CMO) Requirements. ……………

5.5.11 Configuration Change Authority Requirements. ………………………

5.5.12 Alternate Configuration Change Process. ……………………………

5.5.12.1 Approval and Release of Changes ……………………………………

5.6 Configuration Status Accounting (CSA). ……………………………

5.6.1 Retention of Historical Database. ………………………………………

5.6.2 Maintenance of Configuration Documentation………………………

5.6.3 Duplicates of Controlled Documents ……………………………………….. 29

5.6.4 Reporting Accomplishment of Retrofit Changes. ………………………

5.6.5 Problem/Issue/Improvement Report (PIR)………………………………

5.7 Configuration Verification and Audit. …………………………………

5.7.1 Supplying Activity Participation and Responsibilities……………………… 30

5.7.1.1 Sub-contractors and Suppliers. …………………………………………

5.7.1.2 Supplying Activity Requirements. ……………………………………

5.7.2 Types of Audits. ………………………………………………………

5.7.2.1 Functional Configuration Audit (FCA). ………………………………

5.7.2.1.1 Supplying Activity Responsibility During FCA. ………………………

5.7.2.1.2 Post-audit Actions. ……………………………………………………

5.7.2.2 Physical Configuration Audit (PCA) …………………………………

5.7.2.2.1 Supplying Activity Responsibility during PCA ..……………………

5.7.2.2.2 PCA Requirements. ……………………………………………………

5.7.2.2.3 Post-audit Actions. ……………………………………………………

6. NOTES ……………………………………………………………………… 33

6.1 Intended Use. …………………………………………………………

6.2 Acquisition Requirements. ……………………………………………

6.3 Data Requirements. ……………………………………………………

6.4 Supersession History. ………………………………………………

6.5 Subject Term (keyword) Listing. …………………………………………… 34

6.6 Further Guidance …………………………………………………………... 34

APPENDIX A Configuration Management Strategy And Configuration Management Plan . 35 APPENDIX B Instructions For The Preparation Of ECPs Utilizing DD Form 1692………. 39 APPENDIX C Instructions For The Preparation Of NORs Utilizing DD Form 1695……… 57 APPENDIX D Instructions For The Preparation Of ERRs Utilizing DD Form 2617………. 62 APPENDIX E Instructions For The Preparation Of RFVs Utilizing DD Form 1694…….… 66 APPENDIX F Requirements For Configuration Status Accounting (CSA)………………... 70 APPENDIX G Instructions For The Preparation Of Certification Package For FCA/PCA… 79 APPENDIX H Reporting The Accomplishment Of Retrofit Changes……………………… 88

1. SCOPE

1.1 Scope. This standard defines Configuration Management (CM) requirements for US Army acquisition programs which apply throughout the lifecycle of systems and their Configuration Items (CIs) and provides the principles to acquire CM processes and products consistently across the Army. This standard implements the principles of ANSI/EIA-649 (Rev B) Configuration Management Standard and the requirements of DOD Instruction 5000.02 for CM practices.

1.2 Selective application. The ANSI/EIA-649 CM functions and the requirements in this standard are performed throughout the lifecycle of a given system as tailored based on the lifecycle phase, acquisition strategy, systems engineering plan, and lifecycle support plan. Army activities and organizations will give maximum latitude to supplying activity’s processes and procedures, provided those processes and procedures are compliant with the principles of ANSI/EIA-649 and meet the acquiring activities requirements. The principles of ANSI/EIA-649 are identified throughout this document for reference.

1.3 Tailoring implementation. Tailoring of this standard consists of selecting the necessary configuration management requirements based on the product's/item's lifecycle phase, complexity, size, intended use, mission criticality, and logistic support requirements. All requirements herein are subject to tailoring as prescribed by the tasking directive, purchase order, performance work statements or contract statement of work (hereafter collectively referred to as the contract). In case of conflict between the contract and this standard, the contract takes precedence.

2. APPLICABLE DOCUMENTS

2.1 General. The documents listed in this section are specified in Sections 3, 4, and 5 of this standard. This section does not include documents listed in other sections or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned they must meet all specified requirements of documents cited in Sections 3, 4, or 5 of this standard, whether or not they are listed.

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. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.

DEPARTMENT OF DEFENSE STANDARDS

MIL-STD-961 Defense and Program-Unique Specifications Format and Content MIL-STD-31000 Technical Data Packages

DEPARTMENT OF DEFENSE HANDBOOKS

MIL-HDBK-61 Configuration Management Guidance

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

2.2.2 Other Government documents, drawings, and publications. The following other Government documents, drawings, and publications form a part of this standard to the extent specified herein. Unless otherwise specified, the issues of the documents are those cited in the solicitation or contract.

DEPARTMENT OF DEFENSE POLICIES AND DIRECTIVES

DoD Directive 5000.01 The Defense Acquisition System DoD Instruction 5000.02 Operation of the Defense Acquisition System

OTHER DEPARTMENT OF DEFENSE DOCUMENTS

Cataloging Handbook H4/H8 Handbook for Commercial and Government Entity Codes

(Copies of the Cataloging Handbook H4/H8 are available from the Commander, Defense Logistics Services Center, and Battle Creek, MI 49017-3084, or alternately http://www.dlis.dla.mil/cage_welcome.asp) .

2.3 Non-Government publications. The following documents form a part of this standard to the extent specified herein. Unless otherwise specified, the issues of the documents are those cited in the solicitation or contract.

AMERICAN SOCIETY OF MECHANICAL ENGINEERS STANDARDS

ASME Y14.35M Revision of Engineering Drawings and Associated Documents

(Copies of this document are available from www.asme.org or American Society of Mechanical Engineers, 22 Law Dr., Fairfield NJ 07907.)

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO)

ISO 10007 Quality Management Systems — Guidelines for Configuration Management

(Copies of this document are available online at http://www.iso.org/iso/home/standards.htm.)

TECHAMERICA STANDARDS

ANSI/EIA-649 Configuration Management Standard GEIA-HB-649 Configuration Management Guidance

(Copies of this document are available online at www.techamerica.org/ or from TechAmerica, 601 Pennsylvania Ave., NW, North Building, Ste 600, Washington DC 20004-2650.

THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC. (IEEE)

IEEE 12207 Systems and Software Engineering - Software Life Cycle Processes IEEE 828 Standard for Configuration Management in Systems and Software

Engineering

(Copies of this document are available online at www.ieee.org or from IEEE Service Center, 445 Hoes Lane, Piscataway NJ 08855- 1331.)

2.4 Order of precedence. Unless otherwise noted herein or in the contract, 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. This section establishes the definitions for terms used throughout this document and are considered the preferred terminology for Army use. Use of other equivalent terminology as stated in ANSI/EIA-649 Terms, Definitions, Alias, and Related Terms table are acceptable, provided the intent of this standard and ANSI/EIA-649 are met.

3.1 Acquiring Activity. The Government, contractor or any other organization which establishes the requirements for an item, service or set of data, and is responsible for the issuance of a contract or solicitation for these goods or services.

3.2 Allocated Configuration Documentation (ACD). The written requirements for a product, subsystem or component, describing the functional, performance, interoperability, interface and verification requirements, that are allocated from higher-level requirements. Once approved, serves as the official record of the allocated baseline.

3.3 Baseline. The configuration of an item established at a specific point in time and documented in the configuration documentation (e.g., specifications, drawings, Technical Data Packages (TDPs), etc.).

The baseline is a formal, controlled, and maintained set of data that can serve as a point of departure for defining change. When used as a verb, baseline is the act of establishing and approving a set of configuration documentation, typically for purposes of implementing formal configuration change control. A baseline can be established at any time for many different purposes. For purposes of this standard, there are three major baselines (also known as technical baselines) established throughout a product’s life defined as follows:

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

b. Allocated Baseline (ABL). The approved requirements for a product, subsystem or component, describing the functional, performance, interoperability, interface and verification requirements, that are allocated from higher-level requirements, as established at a specific point in time and documented in the allocated configuration documentation.

c. Product Baseline (PBL). The approved detailed design requirements for a product or system established at a specific point in time and documented in the product configuration documentation.

3.4 Block change concept. An engineering change implementation concept that groups a number of ECPs for simultaneous implementation into product instances. Concept designates that a number (i.e., a block) of consecutive production units of the configuration item have 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 Engineering Change Proposal (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.) The concept may require the accumulation and the simultaneous implementation of a number of routine changes (hardware or software) to minimize the number of interim versions and related documentation.

3.5 Commercial and Government Entity (CAGE) Code. A five character, alphanumeric code listed in Cataloging Handbook H4/H8, Commercial and Government Entity Code, which is assigned to commercial and government activities that manufacture or develop items, or provide services or supplies for the government.

3.6 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 are defined via drawings, Model Based Definitions (MBD) datasets, detailed specifications, performance specifications, commercial item definitions, or other means.

3.7 Computer Software Configuration Item (CSCI). A configuration item that is computer software.

3.8 Computer 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 lifecycle.

3.9 Configuration. The functional and physical characteristics of existing or planned hardware, firmware, software or a combination thereof, as detailed in requirements and technical documentation and ultimately achieved in a product.

3.10 Configuration Audit. See "Functional Configuration Audit (FCA)" and "Physical Configuration Audit (PCA)".

3.11 Configuration Change Approval Authority (Configuration Change Authority (CCA)). The organization or individual authorized to approve changes to, or variances from, an approved configuration baseline.

3.12 Configuration Change Management. The configuration management function that provides for the systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes and variances, and the implementation of approved changes to a configuration item and its corresponding configuration baseline documentation; also known as configuration control.

3.13 Configuration Control Board (CCB). An official forum composed of technical, logistics, acquisition, management, and administrative personnel who recommend to the Configuration Change Authority approval or disapproval of proposed changes to, and variances from, an item’s approved configuration documentation.

3.14 Configuration Control Board Directive (CCBD). The document that records the rationale and decision of the CCB and Configuration Change Authority with respect to a configuration change action.

3.15 Configuration Identification. The configuration management function that establishes the configuration items which are to be managed, organizes configuration items into a hierarchical structure, assigns nomenclature and product identifiers to those configuration items and related components, determines the documents and document identifiers which define the items, and establishes baselines for the configuration items.

3.16 Configuration Item (CI). A product or an aggregation of products that accomplishes an end-use function and requires separate identification. An item is designated as a CI for purposes of additional configuration management focus due to its complexity, logistic support requirements, acquisition strategy, or because it is intended to undergo configuration status accounting or verification and audit separately from other items. Configuration items are end items or major components of end items, which typically have performance requirements allocated to them and documented in their own specification.

3.17 Configuration Management (CM). An engineering and management process which ensures the configuration of an item is known and documented and changes to an item are controlled and tracked for purposes of establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information.

3.18 Configuration Management Officer (CMO) The individual assigned to review and coordinate proposed changes and variances, consolidate input, and document the CCB recommendation to the Configuration Change Authority; also referred to as Configuration Management Specialist.

3.19 Configuration Management Plan (CMP). A document, typically prepared by the supplying activity, defining in detail how configuration management will be implemented for a particular acquisition or program.

3.20 Configuration Management Strategy. A document, typically prepared by the acquiring activity, defining the overarching lifecycle requirements for configuration management for a particular acquisition or program.

3.21 Configuration Status Accounting (CSA). The configuration management function that captures, records and reports information needed to effectively manage configuration items, including maintaining a listing of the approved configuration identification, the status of proposed changes to the configuration and the processing and implementation status of approved changes.

3.22 Contract Data Requirements List (CDRL). A list of contract data requirements that are authorized for a specific acquisition and made a part of the contract. CDRLs are specified by DD form 1423-1. Subcontractor Data Requirement List (SDRL) is the subcontractor's version of a CDRL.

The CDRL identifies the data items, establishes the delivery schedules, specifies the recipients and their respective quantity requirements and (by reference to Data Item Descriptions (DIDs)) prescribes the content and format of the deliverable data items.

3.23 Contractor. An individual, partnership, company, corporation, association, or Government agency having a contract for the design, development, manufacture, maintenance, modification, or supply of items under the terms of a contract. For purposes of this standard, the terms contractor and supplying activity are used interchangeably.

3.24 Current Design Activity (CDA). The activity with current design responsibility for an item and is responsible for maintenance of configuration documentation for the item.

3.25 Detail Specification. A specification that specifies design requirements, such as materials to be used, how a requirement is to be achieved, or how an item is to be fabricated or constructed. (Source:

MIL-STD-961)

3.26 Design Release Configuration. The set of design information incrementally released by the developing activity for a product during a product’s definition (development) phase.

3.27 Document. A self-contained set of information or data that can be stored, maintained, and delivered on a single medium. The medium may be paper, digital files, electronic storage, etc. Examples:

drawings, specifications, plans, databases, computer models, software source code, reports, analyses, change proposals, etc.

3.28 Engineering Change. An approved alteration to a product and/or its configuration information.

3.29 Engineering Change Priorities. The priority (emergency, urgent, routine) assigned to ECPs which determines the specified time period during which the change is to be reviewed, evaluated, and, if approved, ordered and implemented.

3.30 Engineering Change Proposal (ECP). A document used to describe, justify, and (if approved), implement a proposed engineering change.

3.31 Engineering Release Record (ERR). A record of the official release of configuration documentation.

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

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

3.34 Form. The shape, size, dimensions, mass, weight, material and visual parameters which uniquely characterize an item. For software, form denotes the language and media.

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

3.36 Functional Configuration Audit (FCA). A formal examination to verify that a configuration item has achieved the functional and performance characteristics specified in its functional and allocated configuration documentation. The FCA verifies the configuration item fulfills the functional and allocated requirements. The system level FCA is similar to the System Verification Review.

3.37 Functional Configuration Documentation (FCD). The written requirements for an end item or system, describing the functional, performance, interoperability, interface and verification requirements.

Once approved, serves as the official record of the functional baseline.

3.38 Identifier. A unique numeric or alphanumeric code applied to documents and products, for the purpose of identification, control, and status accounting. Identifier types include the following:

a. Enterprise Identifier. Uniquely identifies a design or manufacturing organization responsible for a particular product. Example: CAGE CODE, Data Universal Numbering System (DUNS) Number.

b. Group Identifier. Uniquely identifies a group of like units of the same product manufactured under uniform conditions. Examples: lot number/batch number

c. Product Identifier. Unique to the issuing organization, used to designate products of the same configuration, and to differentiate them from other products. Examples: part number, Universal Product Code (UPC), Stock-Keeping Unit (SKU).

d. Document Identifier. Unique to the issuing organization, used to identify configuration documentation. Examples: drawing number, specification number, document control number.

e. Type Identifier. An alphanumeric identifier, unique within the issuing organization, which is used to designate a line of products. Examples: M16 Rifle, MK48 Torpedo, F119 Engine.

f. Unit Identifier. A sequentially issued identifier used to designate a specific instance of a product among like products. Examples: Item Unique IDentification (IUID), serial number, Vehicle Identification Number (VIN).

g. Revision Identifier. A sequentially issued identifier that distinguishes a change to a design or document in order to differentiate one closely related design or document iteration from another.

3.39 Interface. The characteristics required to exist at a common boundary. Interface characteristics may include, but are not limited to, functional, physical, mechanical, visual, thermodynamic, magnetic, electrical, electronic, electromagnetic, software or a combination of these.

3.40 Interface control. The process of identifying, documenting, and controlling product attributes at the common boundary of two or more products provided by one or more organizations.

3.41 Interface Control Document/Drawing (ICD). A document which depicts product attributes at a common boundary of two or more products for purposes of defining and controlling those attributes.

3.42 Interface Control Working Group (ICWG). A group established to control interface activity among the acquiring activity(s), supplying activity(s), or other agencies, including resolution of interface problems, documentation of interface agreements, and evaluation of ECPs affecting interface.

3.43 Model Based Definition (MBD). A dataset containing the exact solid representation, its associated 3-Dimensional (3D) geometry and 3D annotation of the product’s dimensions, tolerances, materials, finishes and other notes to specify a complete product definition.

3.44 Notice of Revision (NOR). A document, submitted as part of an ECP, used to describe changes to drawings, specifications, MBD datasets, associated lists, or other referenced documents.

3.45 Performance Specification. A specification that states requirements in terms of the required results with criteria for verifying compliance, but without stating the methods for achieving the required results. A performance specification defines the functional requirements for the item, the environment in which it must operate, and interface and interchangeability characteristics. (MIL-STD-961)

3.46 Physical Configuration Audit (PCA). A formal examination of the actual (as-built) configuration of an item compared to its product configuration documentation. The PCA verifies the product configuration documentation is a clear, complete, and accurate representation of the configuration item and is necessary to establish the product baseline.

3.47 Problem/Issue/Improvement Report (PIR). A document or procedure used to record, investigate and resolve problems, issues or proposed changes/improvements to a product or process; also referred to as a Problem Report, Trouble Report, Incident Report, Deficiency Report, or Feature Change Request.

3.48 Product. An item or component which is the result of a development process. The result may be hardware, software, firmware, or any combination thereof.

3.49 Product Associated Information. Information generated as part of the product development and lifecycle management process, but isn't clearly definable as either product definition or operation information. Examples: Test Reports, System Evaluation Report, Configuration Control Information, CCB Decisions and Product Configuration Management Status.

3.50 Product Configuration Documentation (PCD). The written performance and detailed design documentation which define an item. The PCD incorporates performance, interoperability, and interface requirements and the verifications required to confirm the achievement of those specified requirements.

The PCD also includes detailed design documentation, ranging from form, fit, and interface information to a complete detailed design disclosure package. Once approved, serves as the official record of the product baseline. (For example, a production level (3) TDP per MIL-STD-31000 would constitute the PCD for an item.)

3.51 Product Definition Information. Information that defines the product's requirements, documents the product's attributes, and is the authoritative source for configuration definition and control. It is the sum total of all information necessary to define the Functional, Allocated, and Product Configuration baselines. Examples: System Requirements Specification (SRS), Integrated Architecture, System Interface Specification, Software Performance Specification, Drawings, MBD datasets, Associated Lists, Software documentation, Interface Control Documents (ICDs), Engineering Product Structure, etc.

3.52 Product Instance Configuration. The configuration of a given item as it transitions throughout its life cycle. For purpose of this standard, the product instance configurations are defined as follows:

a. As-Designed Configuration. The configuration of an item as documented by the design activity in the product definition information.

b. As-Built Configuration. The configuration of an item as actually manufactured. The as-built configuration consists of the as-designed configuration at the time of manufacture as modified by approved variances. In addition, if the as-designed configuration consists of design alternatives, the as-built configuration is the specific configuration chosen from the available alternatives.

c. As-Maintained Configuration. The configuration of an item as currently in-service. The as-maintained configuration consists of the as-built configuration, plus any approved changes, retrofits, maintenance, or modifications implemented after the item is put into service; also referred to as the as-supported, as-installed, or in-service configuration.

3.53 Product Operational Information. Information used to operate, maintain and dispose of the product. Examples: maintenance planning documents, technical manuals and publications, support and test equipment information, and supply support information.

3.54 Product Structure. A hierarchical view of the relationship of products and components.

Examples: bill of materials, indentured drawing list, top-down breakdown product tree.

3.55 Retrofit. The incorporation of new configuration parts or software code, resulting from an approved engineering change, into products previously accepted by the customer, i.e. the update of an existing as-built or as-maintained configuration to the current as-designed configuration.

3.56 Revision. A change to a document’s contents or a modification to an item such that it remains interchangeable with its previous iterations. See also version. (Ref ASME Y14.35M.)

3.57 Specification. A document prepared specifically to support acquisition which accurately describes the essential technical requirements for purchasing a product or materiel, and provides the procedures necessary to determine that the product’s performance meets the defined requirements/attributes. (Source: MIL-STD-961)

3.58 Supplying Activity. The contractor, government agency or other organization responsible for developing or manufacturing an end item, service, or set of data per the requirements of an acquiring activity as established in a contract or solicitation.

3.59 Technical Data Package (TDP). A technical description of an item adequate for supporting an acquisition strategy, production, and engineering and logistics support. The description defines the required design configuration or performance requirements, and procedures required to ensure adequacy of item performance. It consists of applicable technical data such as models, drawings, associated lists, specifications, standards, patterns, performance requirements, Quality Assurance (QA) provisions, software documentation, and packaging details. (Source MIL-STD-31000)

3.60 Value Engineering Change Proposals (VECPs). The VECP is a subcategory of ECP which proposes to reduce cost to manufacture, test, inspect, maintain, or operate the item. The purpose of the VECP is to provide an incentive to propose engineering changes which reduce cost without reducing product performance. Savings resulting from approved VECPs are shared between the supplying and acquiring activities as stipulated by the contract.

3.61 Variance. A written authorization to temporarily depart from one or more requirements of an item's approved configuration documentation for a specific number of units or period of time. Formerly known as waiver or deviation.

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

3.63 Version. An identified and documented body of software. A version identifier is used to distinguish a changed body or set of computer-based data (software) from the previous configuration with the same primary identifier. (NOTE: The term version, revision and iteration are used interchangeably in some contexts and have specific meanings in other contexts. In some cases, two identifiers may be used, for example version may refer to a major modification of software/hardware and revision or iteration may refer to minor modification of the same version.)

4. GENERAL REQUIREMENTS

4.1 Configuration Management. The planning and execution of configuration management is an essential part of the product development and lifecycle management process. Configuration management’s overarching goal is to ensure there is documentation which completely and accurately describes the intended design, the actual product matches the documentation, and there are processes in place so this continues throughout the product’s life. To achieve this purpose, configuration management consists of the following actions:

a. Identifying the functional requirements and physical attributes of an item;

b. Documenting these requirements and attributes;

c. Verifying configuration of the item and its documentation; and

d. Managing changes to an item and its documentation.

4.2 Responsibility of Acquiring and Supplying Activities. Both the acquiring and supplying activities have configuration management responsibilities in the product development lifecycle. The acquiring activity establishes and controls the system’s functional requirements, and has oversight responsibility during the product development, fielding, operation and disposal. The supplying activity is the organization tasked to develop, manufacture, and/or support the item and to implement the configuration management processes per the requirements of this standard and the acquiring activity.

4.3 Functions of Configuration Management. The configuration management process consists of five

(5) functions:

1. Configuration Planning and Management

2. Configuration Identification.

3. Configuration Change Management.

4. Configuration Status Accounting.

5. Configuration Verification and Audit.

4.3.1 Configuration Planning and Management. The acquiring and supplying activities shall plan and execute a configuration management program as required by this standard, tailored appropriately for the particular CI(s), their scope and complexity, and the phase(s) of the lifecycle. The configuration management plan shall be prepared and updated as required by the solicitation or contract.

4.3.2 Configuration Identification. The acquiring and supplying activity shall perform configuration identification activities as required by this standard. For configuration items and subordinate components, the configuration identification process shall select the items, establish structure to the items, issue identifiers and nomenclatures, and determine the types of configuration documentation required for each item.

4.3.3 Configuration Change Management. The acquiring and supplying activity shall apply configuration change management to each configuration item and related components and its associated product definition information as required by this standard. The configuration change management process shall ensure effective release and control procedures for CI(s)/components, shall provide an effective means for proposing engineering changes and variances to such items, provide for thorough and timely evaluation of all proposed engineering changes and variances by the appropriate Configuration

ANSI/EIA-649B Principle CM-1

ANSI/EIA-649B Principle CMP-1

ANSI/EIA-649B Principle CI-1

ANSI/EIA-649B Principle CCM-1

Change Authority. It shall ensure implementation and tracking of approved changes to the configuration documentation and to the product.

4.3.4 Configuration Status Accounting (CSA). The acquiring and supplying activity shall apply CSA to each configuration item and its related components and the associated product definition information as required by this standard. The CSA system shall ensure information about the product and product configuration is captured, correlated, stored, and maintained as the product evolves through the lifecycle and provides an accurate, timely information base concerning the product.

4.3.5 Configuration Verification and Audits. The acquiring and supplying activities shall ensure configuration verification and audits are performed as necessary and required by this standard.

Verifications and audits ensure the item meets the requirements of the functional/allocated configuration documentation and the product configuration documentation is a clear, complete and accurate representation of the intended design. Verification and audit are performed in order to establish a validated product baseline for each configuration item. Configuration verifications are performed by the supplying activity. Configuration audits are performed by the acquiring activity, or as a joint effort between the acquiring and supplying activity. Configuration audits consist of the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA).

5. DETAILED REQUIREMENTS

5.1 Purpose. The purpose of this section is to identify detailed requirements that are to be selectively applied to a configuration management program.

5.2 Configuration Planning and Management. Configuration planning and management shall ensure the configuration management program results in defined and effective CM functions. Comprehensive CM planning and management shall include:

a. Application of the appropriate level of CM functions throughout the product lifecycle;

b. Assignment of CM functional responsibilities to various organizational elements;

c. Determination and application of adequate resources (including CM software tools) and facilities for implementation of CM functions;

d. Identification of metrics which shall be maintained as an indicator of performance and a basis for continuous improvement;

e. Performance of CM by suppliers and sub-contractors as necessary; and

f. Integration of the organization’s product configuration information processes;

5.2.1 Acquiring Activity’s Lifecycle CM Planning and Strategy. The acquiring activity will conduct planning to establish and tailor the configuration management program to meet the lifecycle requirements in accordance with the overarching acquisition strategy and DoD Directive 5000.01 and DoD Instruction 5000.02 (See figure 1 as a guide). The acquiring activity will document and update these requirements in the lifecycle CM Strategy in accordance with appendix A as necessary.

ANSI/EIA-649B Principle CSA-1

ANSI/EIA-649B Principle CVA-1

ANSI/EIA-649B Principle CMP-2 through 8

5.2.2 Supplying Activity’s CM Plan. The supplying activity shall conduct planning to establish the program specific configuration management requirements in accordance with the contract and CM Strategy as applicable. The supplying activity shall document these requirements in the Configuration Management Plan (CMP). The supplying activity shall:

a. Prepare the CMP as required by the contract, using Appendix A (or IEEE 828 for software) as required;

b. Submit the CMP and changes to the CMP IAW the contract;

c. Implement the activities required by this standard and the approved CMP.

FIGURE 1.

Relationship of Key CM (Notional).

5.2.3 Interface Management. The interfaces with other configuration items, both external and internal, shall be identified during the system engineering process. Those interface requirements which must be controlled by the acquiring activity shall be incorporated into the Functional Configuration Documentation (FCD) and Allocated Configuration Documentation (ACD) or through the creation of Interface Control Documents (ICDs) as applicable. Such interface requirements shall be subject to the configuration control requirements of this standard. Prior to establishing the product baseline, the supplying activity shall be responsible for defining and controlling all interfaces below the ACD level.

The supplying activity shall ensure compatibility and interoperability among hardware and software components through creation of ICDs and ICWGs as necessary.

5.2.3.1 Requirements for an Interface Control Working Group (ICWG). An ICWG will be established to control interface characteristics as required. The ICWG shall include members of all activities sharing an interface. The supplying activity shall be responsible for providing a representative to the ICWG empowered to commit to specific interface actions and agreements to create, update, release, and control interface control documentation that reflect the ICWG decisions.

5.2.4 Product Data Management (PDM). In order to effectively accomplish the requirements of configuration identification and status accounting, the supplying activity shall establish a PDM system to

ANSI/EIA-649B Principle CI-13 store, manage and control documents, drawings and MBD datasets, which define the CIs and components.

The supplying activity shall provide access to the data products from this PDM system as required by the contract.

5.3 Configuration Identification. Configuration identification is an iterative process which shall be conducted to identify the configuration items to be managed; establish a structure and hierarchy of the configuration items and related components; establish nomenclature and identifiers for those items; and determine the documents and document identifiers which define the items.

5.3.1 Initial Configuration Identification Activities. Configuration identification shall begin during the requirements definition phase to determine the significant parts of a system that requirements must be allocated against and which must be documented, managed and controlled. During this process, the selection of CIs are addressed (see Figure 2) and the requirements for the allocated baseline are established (e.g. the specification tree is established). The supplying activity shall recommend potential CIs to the acquiring activity if required by the contract. Items shall undergo review as potential CIs if they require logistical support, are designated for separate procurement, require separate qualification, are significantly complex or costly, or for any other reason additional configuration management focus is deemed necessary.

FIGURE 2. Relationship of configuration items and components.

5.3.2 Detailed Configuration Identification Activities. Configuration identification shall continue

ANSI/EIA-649B Principle CI-10

ANSI/EIA-649B Principle CI-2 during the detailed design definition phase to identify components of the product from the end item, through assemblies and subassemblies, down to each piece part as necessary. Configuration identification shall establish the product structure (top down breakdown structure and BOM), establish nomenclatures and identifiers, and determine the document type and format necessary to define the item (i.e. fully defined drawings, MBD, specifications, performance requirements, commercial item definitions, etc).

The product structure shall be created in a logical, consistent manner and shall take into consideration both the manufacturing and logistics supportability aspects of the product, to include ensuring spare or repair parts are adequately identified.

5.3.2.1 Software Configuration Identification Activities. Software configuration identification shall ensure all necessary artifacts of the software development environment are properly identified. The source code, binary/executable, compiler, linker and library settings and any other aspect of the development environment shall be identified for subsequent control, status accounting, verification/audit and archival purposes.

FIGURE 2. Identification of Software Development Artifacts.

5.3.3 Configuration Identification Requirements. As part of the configuration identification process, unless otherwise specified by the contract, the supplying activity shall:

a. Select (or recommend to the acquiring activity) the CIs;

b. Assign enterprise and product identifiers (e.g. CAGE Code and part numbers) and nomenclature to CIs/components and their associated documentation;

c. Establish the structure and hierarchy of the CIs/components;

d. Identify those CIs/components which require unit and group identifiers (e.g. serial and lot numbers) to establish the effectivity of each configuration;

e. Identify type and format of documentation to define each CI/component;

f. Establish a release system and approval process for configuration documentation;

g. Enter each item of configuration documentation into a configuration status accounting system.

h. With acquiring activity approval, establish the functional, allocated, and product baselines at the appropriate points in the system/CI lifecycle;

i. Define and document interfaces; and

j. Ensure applicable identifiers are embedded in the software source and object code, and where contractually specified, electronically embedded in alterable firmware.

5.3.4 Configuration Nomenclature and Identifiers. CIs/components and associated documents shall be assigned nomenclatures and unique identifiers as described below.

5.3.4.1 Enterprise Identifier. An enterprise identifier shall be assigned to each CI/component and affixed to its configuration documentation to designate the organization with design responsibility over the item. The enterprise identifier shall consist of a CAGE Code, or other mutually agreed upon enterprise identifier. When applicable and required by the contract, the enterprise identifier shall be affixed to physical CIs and components, their packaging and software media and products. If the design responsibility for an item changes during its lifecycle, the configuration documentation shall retain the original design activity’s CAGE Code and shall be marked with the new design activity’s CAGE Code identified as the Current Design Activity (CDA) such that traceability of design ownership is maintained.

5.3.4.2 Type Identifier and Nomenclature. A type identifier shall be assigned to each CI as required by the acquiring activity for control, tracking, procurement or logistics purposes. The type identifier shall be re-assigned (e.g. M16A1 to M16A2) when major modifications are implemented, new requirements are imposed on the item, or when such type identification would aid in the management, control and monitoring of the item.

5.3.4.3 Document Identifier. A document identifier shall be assigned and applied to all documents including but not limited to specifications, engineering drawings, MBD datasets, associated lists and ancillary documents. The document identifier, in conjunction with the enterprise identifier, shall uniquely identify a document from other documents.

5.3.4.4 Product Identifier.