MIL-HDBK-61A: Configuration Identification

< Previous | Contents | Next >

5.5 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 your starting point. In order 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. In order to manage a program effectively it is necessary to baseline the objectives for cost, schedule, and performance.

The Acquisition Program Baseline (APB), established at Milestone A, B and C [Ref: DOD Instruction 5000.2; Recall Fig. 4-5], provides the Program manager with key cost, schedule, and performance objectives and thresholds, which if not met, would require a re-evaluation of alternative concepts or design approaches. This baseline bears a close relationship with the configuration baselines described in this section. The performance thresholds must be reflected in the system or top level CI specification that constitutes the functional baseline for the program for those thresholds to be achieved.

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 which capture the configuration or partial configuration of a CI at specific points in time
  • Commitment points representing approval of a CI at a particular milestones in its development
  • Control points that serve to focus management attention.

Major configuration baselines known as the functional, allocated, and product baselines as well as the developmental configuration, are associated with milestones in the life cycle of a CI. Each of these major configuration baselines is designated when the given level of the CI's configuration documentation is deemed to be complete and correct, and needs to be formally protected from unwarranted and uncontrolled change from that point forward in its life cycle. Under MIL-STD-975 and earlier configuration management standards, these baselines all signified departure points for Government configuration control; they must now be redefined for post acquisition reform application because either Government or Contractor configuration control may apply. The new definitions reflect the same purpose for each baseline, however the configuration control activity (which approves of changes to the baseline) is treated as a separate variable. [Details: Activity Guidelines: Fig. 5-4a through e.]

  • Functional baseline - The approved configuration documentation describing a system's or top level configuration item's performance (functional, inter-operability, 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 contractor's design and associated technical documentation that defines the contractor's evolving design solution during development of a CI. The developmental configuration for a CI consists of that contractor internally released technical documentation for hardware and software design that is under the developing contractor's configuration control.
  • Product baseline - The product baseline is the approved technical documentation which 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, and
    • The production acceptance test requirements

When used for re-procurement of a CI, the product baseline documentation also includes the allocated configuration documentation to insure 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 [Details: Section 6]. 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. [Detail: Section 7]

From a government acquisition program perspective, the functional baseline is established when its associated functional configuration documentation is approved by the Government. This baseline is always subject to Government 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 inter-operability 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) which 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 Government's 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. From a contractor's point of view, 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 contractor's product is obligated by the contract to 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 that are 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, and
  • 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 contractor's 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 specification(s) defining each allocated baseline is subject to configuration control by either the Government or by the contractor. The configuration control activity determination is very simply made as follows:

  • The Government is the configuration control authority for those allocated specifications/baselines that have been issued, or approved by the Government. The Government will control the specifications for CIs that it will organically provide logistic support
  • The contractor will be the configuration control authority for the allocated specifications for CIs at a lower level that it will logistically support.

Based on the definition of the functional, allocated and product baselines as Government baselines, there has always been considerable confusion as to what to call the baseline established between a contractor and a sub-contractor. From the contractor's point of view, it is an allocated baseline. From the sub-contractor's view, it is a functional baseline since it constitutes the top-level requirement that the sub-contractor must meet, and which the sub-contractor may need to allocate further down the CI tree [Fig. 5-2]. Whether this baseline is considered a functional baseline, an allocated baseline, or a functional/allocated baseline, is immaterial so long as the configuration control requirements for the related configuration documentation are clearly established.

Interface control documents [See 5.8] are considered part of the functional and/or allocated baselines to the extent that they are referenced in and supplement the performance specifications that constitute the applicable baselines.

Contractor implementation of the functional and allocated baseline requirements involves the creation, and release of engineering documentation that incrementally defines the configuration of the specific product. It represents the contractors detailed design solution. It may or may not include a detail specification for the product. The contractor is responsible for the configuration control of the developmental configuration and may iteratively design, release, prototype and test until the functional and allocated requirements are satisfied. The developmental configuration will ultimately include the complete set of released and approved engineering design documents, such as the engineering drawings and associated lists for hardware and the software, interface and database design documents for software. By reference within this documentation, it also includes test and verification documents

The product baseline is the approved documentation which 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, and
  • The production acceptance test requirements,
  • All allocated configuration documentation pertaining to the item, so that if the item were to be re-procured, 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; and the software, interface and database design documents for software. These are the then current configuration of the documents that were considered the developmental configuration. The product baseline may include the 2-D or 3-D engineering model of a hardware product, and for software, it includes a representation of the CSCI source code. It also includes by reference, the material and process specifications invoked by the engineering documentation.

The configuration control authority for the product baseline for each CI is determined with the same supportability test as the allocated requirements, described above. The Government needs to take delivery of and control product configuration documentation at a level of detail commensurate with the operational, support and re-procurement strategies for the given program. For repairable CIs developed wholly or partly with Government funding, design disclosure documentation is required to the lowest level at which the CI will be operated, maintained, repaired, trained, supported and re-procured. A significant factor in this determination is data that is properly established as "Contractor proprietary." The Government shall determine if it is necessary and cost effective to buy rights to the data, do without it, develop new data and CIs, or return to the original contractor whenever re-procurement or support of the CI is needed. When a CI is wholly developed with private funding and is acquired by the Government, the data normally available for the item (typically form, fit and function documentation) is evaluated and included in the appropriate baselines.

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). The specification structure of MIL-STD-961D, Appendix A, facilitates this congruence since a separate specification is not created when a performance specification transitions to a detailed specification. [5.4.1, 5.4.2]. Redundant documentation should be avoided to minimize the possibility of conflicts. If a conflict arises between levels of configuration documentation, the order of precedence is always FCD, then ACD, then PCD.

When viewed on a system basis, care must be exercised to assure 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.

As can be seen from the above discussion, performance oriented acquisition strategy has introduced considerable flexibility into the configuration baseline process. There will however be a long period of transition as pre-existing programs either phase into the new methodology or complete their life cycle under prior acquisition strategy. In many programs there will continue to be a mix of philosophy, as dictated by the results of cost trade-offs. Therefore the application guides in this section reflect a variety of the baseline methodologies that may be contractually in place.

Figures 5-4a and b reflect the two latest Change Notices to MIL-STD-973. Fig. 5-4a also reflects the baseline concept of MIL-STD-480B, MIL-STD-483, etc, which preceded MIL-STD-973. All of these standards have been cancelled but continue to effect follow-on legacy system contracts where it is not cost effective to upgrade to new standards. Fig. 5-4c reflects the baseline concept of ANSI/EIA -649, the National Consensus Standard for Configuration Management. It is viewed from the industry perspective as the baselines that a contractor would establish for himself to manage his product. It is compatible with and maps easily to any of the other baseline concepts. Figs 5-4d and 5-4e illustrate the performance based acquisition baseline concepts described in 5.5.1. They show several of the flexible options the Government may exercise based on acquisition strategy, logistic support planning and sound management judgment.

Handbook image Handbook image Handbook image Handbook image Handbook image  

For correct application of this information, see NOTE on Contents page