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.
Good configuration control procedures ensure the continuous integrity of the configuration identification. The configuration identification process includes:
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.
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:
A configuration identification process evaluation checklist is provided to assist in this process (see Table 4.1).
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.
Figure 4.2: A WBS for Software Engineering Services
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:
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:
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.
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.
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.
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:
The consequences of having too few CIs include:
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.
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.
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).
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.
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 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).
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.
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.
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.
Process Implementation: Planning
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:
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.
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:
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:
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:
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.
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 following principles in EIA-649 apply to the identification of configuration items:
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).
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.
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.
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:
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:
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:
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.
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.
This chapter is based on the following report: MIL-HDBK-61A(SE), February 7, 2001 , Military Handbook: Configuration Management Guidance .