Configuration Identification

Table of contents:

Configuration identification incrementally establishes and maintains the definitive current basis for control and status accounting of a system and its configuration items (CIs) throughout their life cycle (development, production, deployment, and operational support, until demilitarization and disposal). The configuration identification process ensures that all processes have common sets of documentation as the basis for developing a new system, modifying an existing component, buying a product for operational use, and providing support for the system and its components . The configuration identification process also includes identifiers that are shorthand references to items and their documentation.

HOW CONFIGURATION IDENTIFICATION WORKS

Good configuration control procedures ensure the continuous integrity of the configuration identification. The configuration identification process includes:

Selecting configuration items at appropriate levels of the product structure to facilitate the documentation, control, and support of the items and their documentation
Determining the types of configuration documentation required for each CI to define its performance, functional, and physical attributes, including internal and external interfaces; configuration documentation provides the basis to develop and procure software/parts/material, fabricate and assemble parts , inspect and test items, and maintain systems
Determining the appropriate configuration control authority for each configuration document consistent with logistics support planning for the associated CI
Issuing identifiers for the CIs and the configuration documentation
Maintaining the configuration identification of CIs to facilitate effective logistics support of items in service
Releasing configuration documentation
Establishing configuration baselines for the configuration control of CIs

Effective configuration identification is a prerequisite for the other configuration management activities (i.e., configuration control, status accounting, audit), which all use the products of configuration identification. If CIs and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items' configuration, to establish accurate records and reports , or to validate the configuration through audit.

Figure 4.1 is an activity model of the configuration identification process. The boxes represent activities. The arrows entering at the left of each box are inputs; those entering the top are constraints; those entering the bottom are facilitators or mechanisms; and those leaving each box from the right are outputs.

click to expand
Figure 4.1: Configuration Identification Process Activity Model

Inaccurate or incomplete configuration documentation can result in defective products, schedule delays, and higher maintenance costs after delivery.

The basic principles of configuration identification are articulated in EIA Standard 649. It cites the following purposes and benefits of configuration identification:

Determines the structure (hierarchy) of a product and the organization and relationships of its configuration documentation and other product information
Documents the performance, interface, and other attributes of a product
Determines the appropriate level of identification marking of product and documentation
Provides unique identity to a product or to a component part of a product
Provides unique identity to the technical documents describing a product
Modifies identification of product and documents to reflect incorporation of major changes
Maintains release control of documents for baseline management
Enables a user or a service person to distinguish between product versions
Enables a user or a service person to correlate a product to related user or maintenance instructions
Facilitates management of information, including that in digital format
Correlates individual product units to warranties and service life obligations
Enables correlation of document revision level to product version or configuration
Provides a reference point for defining changes and corrective actions

CONFIGURATION IDENTIFICATION GENERAL ACTIVITY GUIDES

A configuration identification process evaluation checklist is provided to assist in this process (see Table 4.1).

Table 4.1: Configuration Identification Process Evaluation Checklist
Documented process: Is there a documented configuration identification process? Is the documented process followed? Are personnel from all disciplines and teams involved in the process informed and knowledgeable about the procedures they are supposed to follow? Product structure: Is the product (system/CIs) structured into a rational hierarchy? Are subordinate CIs identified at a reasonable level for: Specification of and measurement of performance? Management of the effectivity of changes? Obtaining spare parts using performance or design documents? Can the composition of each system/CI be determined from the configuration documentation? Configuration documentation: Does the configuration documentation define the performance, functional, interface, and physical attributes of each system/CI ? Do the performance requirements of the system and/or top-level configuration item specifications meet or exceed threshold performance of the acquisition program baseline? Are all configuration documents uniquely identified? Does the identification reflect the source of the preparing original design activity and current design activity, the type of document, and an alphanumeric identifier? Can each document be easily associated with the CI configuration to which it relates and, where applicable , the range of CI serial numbers to which it applies? Product identification: Are all CIs and subordinate parts down to the level of nonreparability assigned individual unique part/item identifiers? Do the assigned identifiers enable: Each part/item to be distinguished from all other parts/items? Each configuration of an item to be distinguished from earlier and later configurations? Can the next higher assembly application of each part be determined from the design documentation (including associated lists/records)? Does the documentation indicate whether CIs are serialized (or lot controlled)? Is the common base identifier for serialization/lot numbering always a non-changing identifier? Is part/item effectivity to be defined in a manner appropriate for the product type? When an item is changed to a new configuration, is its identifier altered in both the configuration documentation and on the item itself to reflect the new configuration? Configuration baselines: Are appropriate configuration baselines established and maintained as a basis for configuration control? Is the current configuration baseline for the system and for each CI easily determinable? Is an adequate system of release control in place and used for the release of all configuration documents? Can the as-released configuration of each CI be determined? Can past configurations be determined? (applies to both the engineering design configuration and the product configuration) Do release records reflect the authority for changing from one configuration to the next? Do they reference the ECP identifier and contract modification (where applicable)? Does the release system prevent unauthorized changes to released documents? Interface control: For external interfaces, are interface agreements established where necessary to document and agree to performance, functional, and physical interfaces? Do CIs being developed by different contractors for the program have well-defined interfaces? Metrics: Are statistical records of document release and other measurable configuration identification actions maintained? Is the data reduced to meaningful measurement useful in maintaining and improving the process?

PRODUCT STRUCTURE

Product structure, also referred to as system architecture, refers to the identifiers, internal structure, and relationship of system components and associated configuration documentation. Product structure, derived from the functional analysis and allocation process of systems engineering, can be depicted graphically as a tree structure or as an indentured listing.

As a program matures through its early phases, the systems engineering process produces the optimized functional and physical composition of the system architecture to the level that it is necessary to specify and control item performance. This is the lowest level at which CIs are designated during the Engineering and Manufacturing Development phase of the life cycle. Management tools such as specification and drawing trees, and work breakdown structures are all views of the product structure that are directly relatable at the CI level.

Program and contract work breakdown structures (WBSs) are views of the product family tree structure showing the hardware, software, services (see Figure 4.2), data, and facilities against which costs are collected. The WBS relates the elements of work to be accomplished to each other and to the end product. CIs are identified as work breakdown structure elements.

click to expand
Figure 4.2: A WBS for Software Engineering Services

CONFIGURATION ITEMS

Selected items of system hardware or software (or combinations of hardware and software) are designated as configuration items (CIs).

CIs are the basic units of configuration management. They may vary widely in complexity, size , and type, from an aircraft, ship, tank, electronic system, or software program to a test meter or a round of ammunition . Regardless of form, size, or complexity, the configuration of a CI is documented and controlled. CI selection separates system components into identifiable subsets for the purpose of managing further development.

For each CI:

There will be associated configuration documentation (which may range from a performance specification to a detailed drawing to a commercial item description).
Configuration changes will be controlled.
Configuration status accounting records will be maintained .
Configuration audits will be conducted to verify performance and product configuration (unless the CI has an already established product baseline).

To define and control the performance of a system or CI does not mean that all of its hardware and software components must be designated as CIs.

Computer software items, because they typically control the functionality of a system, are almost always designated as CIs. The term "CI" encompasses both hardware and software; when a statement applies only to hardware, or only to software, the terms "HWCI" and "CSCI," respectively, are used.

The determination of the need to designate items as CIs is normally simple and straightforward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the program. Some of the primary reasons for designating separate CIs are:

Critical, new, or modified design
Independent end-use functions
Sub-assembly factors, such as the need for separate configuration control or a separate address for the effectivity of changes
Components common to several systems
Interface with other systems, equipment, or software
Level at which interchangeability must be maintained
Separate delivery or installation requirement
Separate definition of performance and test requirements
High risk and critical components

Although the initial CI selection generally occurs early in the acquisition process, its consequences are lasting and affect many aspects of program management, systems engineering, acquisition logistics, and configuration management. CI selection establishes the level of configuration control throughout the system life cycle. Selecting CIs separates a system into individually identified components for the purpose of managing their development and support.

Many engineering requirements or considerations can influence the selection of CIs. Throughout development and support, the allocation of engineering effort and organization are rooted in the selection of CIs.

CONFIGURATION ITEM SELECTION CRITERIA

The process of selecting configuration items requires the exercise of good systems engineering judgment based on experience, and supported by cost trade-off considerations. No fixed rules govern CI selection or dictate the optimum number of CIs for a particular system. Rather, guidelines for making the appropriate judgments are provided in the "General Guidance," "CI Selection Checklist," and "Additional Factors" sub-sections of this section.

General Guidance

Designating a system component as a CI increases visibility and management control throughout the development and support phases. For system-critical or high technical risk components , added visibility can help in meeting specified requirements and maintaining schedules.
For each development contract, there should be at least one CI designated.
For complex systems, major functional design components are usually designated as CIs. The initial selection is normally limited to the major component level of the work breakdown structure.
As system design evolves during development and complex items are further subdivided into their components, additional CIs may be identified.
Each CI should represent a separable entity that implements at least one end-use function.
The selection of CIs should reflect a high degree of independence among the CIs at the same level. Subordinate components of a CI, which are recommended as CIs during the detail design process, should all be functionally interrelated.
Operational software should always be differentiated from support software by designating each as a separate CI.
The complexity of CI interfaces in a system should be minimized. Complexity often results in increased risk and cost.
All subassemblies of a CI should have common mission, installation, and deployment requirements.
For systems with common components, sub-systems, or support equipment, each common item should be separately designated as a CI at an assembly level common to both systems.
A unique component that is peculiar to only one of multiple similar systems should be identified as a separate CI of that system.
Off-the-shelf, privately developed items generally should not be designated as CIs. However, commercially available items that have been modified should not necessarily be excluded from CI selection. (Factors to consider include the extent of the modification; the criticality of the modified CI to the mission of the system; and the extent of ownership, data rights, and configuration documentation required and available.)

CI Selection Checklist

If most of the answers to the following questions are "yes," the item should be considered for designation as a separate CI. If most answers are "no," it probably should not be designated as a CI. However, a single overriding "yes" may be sufficient to require an item to be separately identified as a CI.

Is the item's schedule critical or high risk? Would failure of the item have a significant financial impact?
Does the item implement critical capabilities (e.g., security protection, human safety, etc.)? Would CI designation enhance the required level of control and verification of these capabilities?
Will the item require development of a new design or a significant modification to an existing design?
Is the item computer hardware or software?
Does the item incorporate unproven technologies?
Does the item have an interface with a CI developed under another contract?
Can the item be readily marked to identify it as a separate, controlled item?
Does the item interface with a CI controlled by another design activity?
Will it be necessary to have an accurate record of the item's exact configuration and the status of changes to it during its life cycle?
Can (or must) the item be independently tested ?
Is the item required for logistic support?
Is it, or does it have the potential to be, designated for separate procurement?
Have different activities have been identified to logistically support various parts of the system?
Does the item have separate mission, training, test, maintenance, and support functions, or require separately designated versions for such purposes?
Do all sub-assemblies of the item have common mission, installation, and deployment requirements, common testing and acceptance?

ADDITIONAL FACTORS

Many development and support planning milestones are related to CIs. Activities such as performance or design verification demonstration, system integration and testing, technical reviews and audits , and budget allocations are usually accomplished for each of the CIs selected. The number of CIs selected will determine the number of separate meetings related to the overall activity. A large number of CIs may lead to delays in completing critical milestones.

Existing CIs can be modified and designated as a separate and different configuration of that CI, thus saving time and money. Factors to be traded off include complexity, the use of new materials, processes, and the insertion of new technology.

There are no rules to dictate the optimum number of CIs for a given system. In general, however, the fewer CIs, the better. Selecting too many CIs increases development and support costs.

Each CI to be developed, especially CSCIs, comes with an associated set of technical reviews, audits, performance or design verification demonstrations , formal unit and integration tests, and documentation requirements. Each of these activities adds an increment of development cost and also adds costs for storage and upkeep of information related to the activities and the documentation.

The consequences of designating too many CIs include:

Numerous inter-CI interfaces to be defined, and documented, which, if they are all baselined early in the EMD phase, will inhibit the freedom to evolve the design solution, solve problems expeditiously, and implement advantageous changes without contractual consequence
CI functionality defined at too low a level or including unnecessary design constraints requiring formal test, and technical reviews, beyond what is required to achieve reasonable assurance of system performance (this is also a concern if performance specifications for the lower-level CIs are baselined too early in the EMD phase)
Increased overall number of requirements in the documentation disproportionate to the unique technical content of the requirements
Excessive fragmentation, which may actually decrease understanding of system performance; fragmented description of functionality increases the overall volume of requirements, is more difficult to understand, and complicates the document review, approval, and control process
Increased cost

The consequences of having too few CIs include:

Increased complexity of each CI, resulting in decreasing management insight and ability to assess progress
Where the lowest -level designated CI is a complex item (implementing unrelated functions, containing both hardware and software components , etc.):
- The potential for reuse of the CI, or portions of the CI, is diminished
- Re-procurement of the CI and components is complicated
- Potential re-procurement sources are limited
- Formal testing of critical capabilities may be delayed or made more difficult
- The inability to account for the deployment of a CI, whose component parts are disbursed to different locations
- Difficulty in addressing the effectivity of changes and retrofit actions, particularly when there are different quantities or separately deliverable components
- Increased complexity in managing and accounting for common assemblies and components

CONFIGURATION DOCUMENTATION

The term "configuration documentation" characterizes the information that defines the performance and functional and physical attributes of a product. As described in EIA Standard 649, all other product documentation (such as operation and maintenance manuals, illustrated parts breakdowns, test plans and procedures) are based on and relate to information in the configuration documentation. The configuration documentation associated with each CI provides the basis for configuration control, logistics support, post-deployment, and software support.

Specification Types Categorized by Object

This section describes the type of CI "objects" that a specification is intended to define. This category is part of a string of categories that comprise the specification type.

System

A system specification defines the overall performance and mission requirements for a system, allocates requirements to lower-level components of the system, and identifies system interface and interoperability constraints. It is the top-level functional requirements specification for the system. A system specification is used to establish a functional baseline for the system.

Large systems are usually decomposed; Level 2 system components are often complex enough to be called "systems" themselves (although, for configuration management purposes, they are designated as subsystems or CIs).

Item

The item specification for a CI defines the performance and interface requirements and design and interoperability constraints that have been allocated to the CI from a system or higher-level CI.

Item specifications provide the contractual basis for the development and verification of CI performance. The item performance (development) specification(s) will normally be used to establish the allocated baseline for the CI.

Software

Computer software configuration items (CSCIs) are documented with software specifications. A software detailed specification is similar to the software requirements specification plus the set of design documents describing the software, interface, and database design.

Process

Process specifications are used where a process (or service) has been developed specifically for use with a particular system/item and is critical to its performance or design. The process specification forms part of the product baseline of the CI(s).

Specification Types Categorized by Purpose

Performance

A performance specification provides requirements for a system, item, software, process, or material in terms of the required results and the criteria for verifying compliance. It defines the functional requirements, the operational environment, and interface and interchangeability requirements, but does not state how the requirements are to be achieved, require the use of specific materials or parts, or give design or construction requirements beyond those design constraints necessary to unambiguously define interface and interchangeability requirements.

The intent of a performance specification is to allow more than one design solution for the requirements specified so that interchangeable competitive products can be evaluated, and new technology can be inserted.

Detail

A detail specification may consist of all detail requirements or a blend of performance and detail requirements. The preference is for one specification to convey all the performance and detail requirements for an item.

One intent of the detail specification, as a revision of the performance specification, is to provide sufficient detail to distinguish the features of one design solution for an item from other competing design solutions. Another intent is to specify details of the design solution, such as the use of specific parts and materials, that are essential for critical safety or economic reasons, but to state as many requirements in performance terms as possible.

What makes a stated requirement a design requirement and not a performance requirement is that it prescribes design, construction, material, or quality control solutions, rather than allow for development flexibility.

Design Solution Document Concepts

The requirements of the functional and allocated baselines are basically design constraints. The design solution evolves from the design and development process during the engineering and manufacturing development (EMD) phase of the life cycle. This process essentially converts the performance requirements of the baseline specification into a specific product definition that can be manufactured to produce a hardware item or compiled to produce a software item.

It is documented in design documentation for the hardware and the software comprising each CI. For hardware, the design documentation may be in the form of engineering drawings and associated lists, as well as the material and process documents that are referenced by the drawings. In the current information environment, the primary design documentation source may be in the form of two- or three-dimensional engineering models. In that case, a drawing is simply a two-dimensional view of a model that exists in a database file. Various models and product modeling tools can be employed. Engineering drawings may or may not exist as a central part of the product manufacturing process, depending on the product and the degree of automation technology employed.

In an automated development and production environment, an item is designed on the engineer's workstation, manufacturing instructions are added at the manufacturing planner's workstation, and the results are fed directly to automated machinery that produces the item. Commonly, items are designed using computer-aided design tools (CADAM, CATIA, AUTOCAD, etc.) and engineering drawings are plotted for human checking and review. Where engineering drawings are required as a contract deliverable , they should be delivered in place, in a CALS-compliant format.

For software, the design evolves through a software engineering process, using a variety of integrated tools, often called the software engineering environment (e.g., computer-aided software engineering [CASE]). The process results in computer-based versions of documentation, source, and executable code for every CSCI. The process employed to manage the automated software documentation (e.g., software library management and archiving) is similar to the process used to manage automated hardware documentation, although different tools can be employed. Upon close examination, it is fundamentally the same process used to manage the files, which contain software code. The same business rules apply to both software and documents in terms of their identification and relationships to other entities.

The developmental configuration management process consists of a formal process to control the documentation and repositories containing the elements of the developmental configuration. The engineering release system and engineering release records are an important part of this management process.

Each and every version of all elements of the developmental configuration released, for whatever purpose, should be maintained , along with the reasons the version was released and the rationale for superseding the previous version.

Software Documentation List

Process Implementation: Planning

Operational Concept Document: proposed system; user needs
Software Development Plan: development effort; process, methods , schedules, organization, resources (includes or refers to SCM and SQA plans)
Software Test Plan: qualification testing; SW item; SW system; environment, tests, schedules
Software Installation Plan: installing SW; user sites; preparations ; training; conversion
Software Transition Plan: transitioning to maintenance organization; HW; SW; resources; life-cycle support

System Requirements Analysis and Architectural Design

System/ Sub-system Specification: specifies system or sub-system requirements; requirement verification methods (may be supplemented with system-level IRS)
System/Sub-system Design Description: system/sub-system-wide design; architectural design; basis for system development (may be supplemented with IDD, DBDD)

Software Requirements Analysis and Design

Software Requirements Specification: specifies SW requirements; verification methods (may be supplemented with IRS)
Interface Requirements Specification: specifies interface requirements for one or more systems, sub-systems, HW items, SW items, operations or other system components; any number of interfaces (can supplement SSS, SSDD, SRS)

Software Architectural and Detailed Design

Software Design Description: SW item-wide design decisions; SW item architectural design; detailed design, basis for implementing; information for maintenance (may be supplemented by IDD, DBDD)
Interface Design Description: interface characteristics; one or more systems, sub-systems, HW items, SW items, operations or other system components; any number of interfaces; detail companion to IRS; communicate and control interface design decisions
Database Design Description: database design; related data, files, SW/database management system for access, basis for implementation and maintenance

Software Integration and Qualification Testing

Software Test Description: test preparations; test cases; test procedures; qualification testing SW item, SW system or sub-system
Software Test Report: record of test performed; assess results

As Built Software Product Definition

Software Product Specification: contains or references executable SW, source files; SW maintenance information; "as-built" design information, compilation, build, modification procedures; primary SW maintenance document
Software Version Description: identifies and describes an SW version; used to release, track, and control each version

System Operation

Software User Manual: hands-on software user; how to install and use SW, SW item group , SW system or sub-system
Software Input/Output Manual: computer center; centralized or networked installation; how to access, input, and interpret output; batch or interactive (with SCOM as alternative to SUM)
Software Center Operator Manual: computer center; centralized or networked installation; how to install and operate an SW system (with SIOM as alternative to SUM)
Computer Operator Manual: information needed to operate a given computer and its peripherals

System Software Maintenance

Computer Programming Manual: information needed by programmer to program for a given computer; newly developed; special purpose; focus on computer, not on specific SW
Firmware Support Manual: information to program and re-program firmware devices in a system; ROMs, PROMs, EPROMs, etc.

CONFIGURATION BASELINES

The concept of baselines is central to an effective configuration management program; it is, however, not a unique configuration management concept. The idea of using a known and defined point of reference is commonplace and is central to an effective management process. The essential idea of baselines is that in order to reach a destination, it is necessary to know one's starting point. To plan for, approve, or implement a configuration change, it is necessary to have a definition of the current configuration that is to be changed. To manage a program effectively, it is necessary to baseline the objectives for cost, schedule, and performance.

In configuration management, a configuration baseline is a fixed reference configuration established by defining and recording the approved configuration documentation for a system or CI at a milestone event or at a specified time.

Configuration baselines represent:

Snapshots that capture the configuration or partial configuration of a CI at specific points in time
Commitment points representing approval of a CI at a particular milestone in its development
Control points that serve to focus management attention

Configuration Baseline Concepts

Major configuration baselines, known as the functional, allocated, and product baselines as well as the developmental configuration, are associated with milestones in the CI life cycle. Each of these major configuration baselines is designated when the given level of the CI's configuration documentation is deemed complete and correct, and needs to be formally protected from unwarranted and uncontrolled change from that point forward in its life cycle.

Functional baseline: the approved configuration documentation describing a system's or top-level configuration item's performance (functional, interoperability, and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics
Allocated baseline: the current approved performance-oriented documentation for a CI to be developed, which describes the functional and interface characteristics that are allocated from those of the higher-level CI and the verification required to demonstrate achievement of those specified characteristics
Development configuration: the design and associated technical documentation that defines the evolving design solution during development of a CI; the developmental configuration for a CI consists of internally released technical documentation for hardware and software design
Product baseline: the approved technical documentation that describes the configuration of a CI during the production, fielding/deployment, and operational support phases of its life cycle; the product baseline prescribes:
- All necessary physical or form, fit, and function characteristics of a CI
- The selected functional characteristics designated for production acceptance testing
- The production acceptance test requirements

When used for reprocurement of a CI, the product baseline documentation also includes the allocated configuration documentation to ensure that performance requirements are not compromised.

Each configuration baseline serves as a point of departure for future CI changes. The current approved configuration documentation constitutes the current configuration baseline. Incremental configuration baselines occur sequentially over the life cycle of a CI as each new change is approved. Each change from the previous baseline to the current baseline occurs through a configuration control process.

The audit trail of the configuration control activity from the CI's original requirements documentation to the current baseline is maintained as part of configuration status accounting.

The functional baseline is established when its associated functional configuration documentation is approved. This baseline is always subject to configuration control. The functional baseline consists of the functional configuration documentation (FCD), which is the initial approved technical documentation for a system or top-level CI as set forth in a system specification prescribing:

All necessary functional characteristics
The verification required to demonstrate achievement of the specified functional characteristics
The necessary interface and interoperability characteristics with associated CIs, other system elements, and other systems
Identification of lower-level CIs, if any, and the configuration documentation for items (such as items separately developed or currently in the inventory) that are to be integrated or interfaced with the CI
Design constraints, such as envelope dimensions, component standardization, use of inventory items, and integrated logistics support policies

The functional baseline is usually defined as a result of the Concept and Technology Development phase, when that phase is included in the acquisition strategy. In the absence of a concept phase, the functional baseline is established during System Development and Demonstration. A functional baseline, whether formally established or not, is always in place at the inception of each phase. It is represented by whatever documentation is included or referenced by the contract to define the technical/performance requirements that the product must meet.

The allocated baseline is, in reality, a composite of a series of allocated baselines. Each allocated baseline consists of the allocated configuration documentation (ACD), which is the current approved performance-oriented documentation governing the development of a CI, in which each specification:

Defines the functional and interface characteristics allocated from those of the system or higher-level CI
Establishes the verification required to demonstrate achievement of its functional characteristics
Delineates necessary interface requirements with other associated CIs
Establishes design constraints, if any, such as component standardization, use of inventory items, and integrated logistics support requirements

The requirements in the specification are the basis for the design of the CI; the quality assurance provisions in the specification form the framework for the qualification testing program for the CI. The initial allocated baseline is established during System Development and Demonstration. The allocated baseline for each CI is documented in an item performance (or detail) specification, generally referred to as a development specification.

The product baseline is the approved documentation that completely describes the functional and physical characteristics of the CI, any required joint and combined operations interoperability characteristics of a CI (including a comprehensive summary of the other environment(s) and allied interfacing CIs or systems and equipment). It consists of the Product Configuration Documentation (PCD), which is the current approved technical documentation describing the configuration of a CI during the Production and Deployment, and Operational Support phases of its life cycle. The product baseline prescribes:

All necessary physical or form, fit, and function characteristics of a CI
The selected functional characteristics designated for production acceptance testing
The production acceptance test requirements
All allocated configuration documentation pertaining to the item, so that if the item were to be reprocured, the performance requirements for the item would also be included

The product baseline documentation includes the complete set of released and approved engineering design documents, such as the engineering models, engineering drawings, and associated lists for hardware, as well as the software, interface, and database design documents for software.

The functional, allocated, and product configuration documentation must be mutually consistent and compatible. Each succeeding level of configuration identification is a logical and detailed extension of its predecessor(s).

When viewed on a system basis, care must be exercised to ensure that all of the top-level requirements are accounted for in individual lower-level documents. This is a key function of such reviews as system, preliminary, and critical design reviews, but is greatly facilitated by the use of automated requirements allocation and traceability tools.

DOCUMENT AND ITEM IDENTIFICATION

This section describes the concepts for the assignment of identifiers to CIs, component parts , and their associated configuration documentation. Clearly identified items and documentation are essential to effective configuration management throughout the life cycle, particularly during the deployment and operational support period when the marking on a part is the key to installing a correct replacement part and finding the proper installation, operation, and maintenance instructions.

Each configuration document (as well as other documents) must have a unique identifier so that it can be associated correctly with the configuration of the item to which it relates . The DoD and all military components use the following three elements to ensure the unique identity of any document: CAGE code, document type, and document identifier. In addition, a revision identifier or date clearly specifies a specific issue of a document.

A document can have many representations, as, for example, a word processor file and a paper copy, or a CAD file and a representation of that CAD file inserted in a document. In addition to the identification assigned to each document, the digital files for each version of each representation of the document, and its component files, must be identified and managed.

It is the responsibility of each individual assigned to manage an item of configuration documentation to employ the appropriate procedures of his or her organization so as to ensure:

The assignment of identifiers to the configuration documentation, including revision and version identifiers, when appropriate, and procedures to control the engineering release of new/revised data
The application of applicable restrictive markings

The following principles in EIA-649 apply to the identification of configuration items:

All products (configuration items) are assigned unique identifiers so that one product can be distinguished from other products; one configuration of a product can be distinguished from another; the source of a product can be determined; and the correct product information can be retrieved.
Individual units of a product are assigned a unique product unit identifier (e.g., serial number) when there is a need to distinguish one unit of the product from another unit of the product.
When a product is modified, it retains its original product unit identifier (e.g., serial number) although its part identifying number is altered to reflect a new configuration.
A series of like units of a product is assigned a unique product group identifier (e.g., lot number or date code) when it is unnecessary or impracticable to identify individual units but, nonetheless, necessary to correlate units to a process, date, event, or test.

Items are marked or labeled with their applicable identifiers to enable correlation between the item, its configuration documentation, and other associated data, and to track maintenance and modification actions performed. Thus, serial and lot numbers are also known as tracking identifiers. For software, applicable identifiers are embedded in source code and, when required, in object code and in alterable read-only memory devices (firmware).

Item Identification Numbers (PIN)

The developer assigns a discrete part/item identification number (PIN), generally referred to as a part number, to each CI and its subordinate parts and assemblies. The part number of a given part is changed whenever a noninterchangeable condition is created.

Part number format is at the developer's option and a wide variety of formats are employed. The standard constraint within the defense industry had been a limitation to no more than 15 characters including dash numbers. However, with the increasing use of commercial items that are not so limited, many current systems accommodate 52 characters . Some developers employ a mono-detail system in which one part is detailed on one drawing, and the drawing and the part number is the same. For practical reasons, some employ a multi-detailing system in which the drawing number may detail several parts and assemblies. Others use tabulated mono-detail drawings in which a drawing includes several iterations of a part. In the latter two cases, the drawing number is a base to which dash numbers are assigned for discrete parts controlled by that drawing.

The significant criteria are as expressed in the principles above: the part number must uniquely identify the specific part and unless otherwise specified, all CIs including parts, assemblies, units, sets, and other pieces of military property are marked with their identifiers.

Software Identifiers

Each CSCI shall have an identifier consisting of a name or number. It uniquely identifies the software. Each version of the software CSCI shall have a version identifier supplementing the software identifier.

The software identifier and version identifier are embedded in the source code for the CSCI.
Means are provided to display identifiers for installed software to user upon software initiation or upon specific command.
In mission-critical situations, identification of the correct software version may be verified as part of system self-check, as well as during system test following equipment repair or maintenance.
Each software medium (e.g., magnetic tape, disk) containing copies of tested and verified software entities is marked with a label containing, or providing cross-reference to, a listing of the applicable software identifiers of the entities it contains.

ENGINEERING RELEASE

Engineering release is an action that makes configuration documentation available for its intended use and subject to the developer's configuration control procedures.

All software engineering activities should follow engineering release procedures, which record the release and retain records of approved configuration documentation (engineering release records). These records provide:

An audit trail of CI documentation status and history
Verification that engineering documentation has been changed to reflect the incorporation of approved changes and to satisfy the requirements for traceability of deviations and engineering changes
A means to reconcile engineering and manufacturing data to ensure that engineering changes have been accomplished and incorporated into deliverable units of the CIs

INTERFACE MANAGEMENT

Another aspect of configuration identification to be considered during development is interface management, also referred to as interface control. Systems may have interfaces with other systems.

These interfaces constitute design constraints imposed on the programs. As the system is defined, other interfaces between system components become apparent. All of the interfaces between co-functioning items should be identified and documented so that their integrity can be maintained through a disciplined configuration control process. In some cases, a formal interface management process must be employed to define and document the interface.

Interfaces are the functional and physical characteristics that exist at a common boundary with co-functioning items and allow systems, equipment, software, and data to be compatible. The purpose of all interface management activity is that:

The detailed design of each of the co-functioning items contains the necessary information to ensure that the items, when individually designed and produced, will work together (as the 115-volt plug to the 115-volt electrical outlet).
If either item needs to be changed for any reason, its performance, functional, or physical attributes that are involved in the interface act as constraints on the design change.

During development, part of the design effort is to arrive at and document external interface agreements, as well as to identify, define, control, and integrate all lower-level (i.e., detailed design) interfaces.

Interfaces include external interfaces with other systems, internal interfaces between CIs that comprise the system, and internal interfaces between CIs and other components of the system.

To understand how a particular interface should be defined and managed, it is necessary to categorize the interface in a number of ways:

Contractual relationship. Are the items supplied by the same contractor or by different contractors? If different contractors, is there, or will there be, a contractual relationship (such as a sub-contract or purchase order) between the parties to the interface?
Customer relationship (acquisition activity(ies)). Is the same acquisition activity responsible for both interfacing entities, or are different activities or even services involved?
Hierarchical relationship. Is the interface at the system, CI, assembly, or part level?
Type(s) and complexity of technical interface attribute(s) involved. Is the interface mechanical, electrical, electronic, installation, data, language, power, hydraulic, pneumatic, space, operating range, frequency, transmission rate, capacity, etc. (to name a few)?
Developmental status. Is (are) one, both, or none of the interfacing items a nondevelopmental item (NDI)? Do the interfacing items require parallel design and development?

Categorizing the interface in this manner defines the context and environment of the interface, and enables the appropriate measures to be taken to define and control it. Each interface must be defined and documented; the documentation varies from performance or detailed specifications to item, assembly, or installation drawings, to interface control documents/drawings. Some interfaces are completely managed within the design process; others require specific types of formal interface management activity. The simplest and most straightforward approach that will satisfy the above objective should always be chosen . Extravagant and complex interface management activity should only be undertaken when other methods are inappropriate.

Whether formal or informal interface management is employed, it is necessary that there be a legal responsibility on the part of the interfacing parties because even the best-intentioned technical agreements can break down in the face of fiscal pressure. If there is a contractual relationship, including a teaming arrangement, between two or more parties to an interface, there is already a vehicle for definition and control. However, where there is no contractual relationship, a separate interface agreement may be necessary to define the interface process and provide for the protection of proprietary information.

Within an organization, integrated product teams can be used to establish interfaces. Some interfaces must be defined through a formal interface management process involving interface control working groups (ICWGs). An ICWG is a specialized integrated product team comprised of appropriate technical representatives from the interfacing activities. Its sole purpose is to solve interface issues that surface and cannot be resolved through simple engineer-to-engineer interaction.

Once interfaces have been agreed-to by the parties concerned , they must be detailed at the appropriate level to constrain the design of each item and baseline the configuration documentation so that the normal configuration control process will maintain the integrity of the interface.

SUMMARY

If CM is the framework around which software engineering lives, then configuration identification is its foundation. One cannot control what one cannot name . By providing detailed identification information for each and every component of a system (i.e., programs, databases, forms, manuals), an infinite level of control is achievable.

REFERENCES

This chapter is based on the following report: MIL-HDBK-61A(SE), February 7, 2001 , Military Handbook: Configuration Management Guidance .

Preface