Configuration Status Accounting

OVERVIEW

Configuration status accounting (CSA) is the process of creating and organizing the knowledge base necessary for the performance of configuration management (CM). In addition to facilitating CM, the purpose of CSA is to provide a highly reliable source of configuration information to support all program/project activities, including program management, systems engineering, manufacturing, software development and maintenance, logistic support, modification, and maintenance.

Figure 6.1 is the activity model for CSA. The inputs, outputs, facilitators, and constraints in this model are simply extracted from the overall CM activity model. CSA receives information from the other CM and related activities as the functions are performed.

Figure 6.1: Configuration Status Accounting Activity Model

In addition to the use of automated configuration management tools, the process is aided or facilitated by the documented CM process and open communications. The outputs from this activity provide visibility into CM document, activity status, and configuration information concerning the product and its documentation. They also include "metrics" developed from the information collected in the CSA system and management "prompts" resulting from analysis of the CM database.

Because the complexion of the objects about which status accounting information is collected changes during the item life cycle, as shown in Figure 6.2, the specific outputs will vary. The inputs and outputs in Figure 6.1 may be thought of as generic categories for which there are different specifics in each phase. The high-level summary of CSA tasks shown in the center of Figure 6.1 reflects the functional performance capabilities of a complete CSA process.

Figure 6.2: Configuration Status Accounting Evolution over the System/CI Life Cycle

Some of these tasks also may not span the entire life cycle. The allocation of responsibilities within these functions (tailoring) must be accomplished during the CM planning activity and should take into account the degree to which the information technology infrastructure has been upgraded.

All of the information required to accomplish the complete CSA function can be captured and supplied using commercial configuration management and product data management tools.

TYPICAL CSA INFORMATION OVER THE ACQUISITION PROGRAM LIFE CYCLE

New and innovative methods of capturing the configuration of installed and spare items and software versions are becoming commonplace. These methods include bar coding and the interrogation of embedded identification via on-equipment data buses and on-board support equipment. The technology for this process is now commonplace in the commercial personal computer industry and the automotive industry.

The information that is loaded into CSA is considered "metadata," that is, information about the data. It provides status and cross-references actual Technical Data Package (TDP) information that is stored digitally in data repositories.

Each design activity establishes a document repository for the CIs developed, produced, or maintained by an Office of Project Responsibility (OPR) under their authority. The data repositories are normally maintained by the inventory control point responsible for the provisioning/supply support of the CI.

CSA records should be maintained in such range and depth as to be responsive to the requirements of the various support activities for access to configuration information. The data repository is the central point for the collection, storage, processing, and promulgation of this data. Configuration information should be available on a request basis, either by hard copy or online computer access. The CSA records are used as "best source" input data for purchasing data packages, design studies, and management analyses requested by the supporting/design activities. In particular, the CSA metadata records must accurately reflect the status of the configuration documents (specifications, drawings, lists, test reports , etc.) maintained in the document repositories.

Concept and Technology Development

Typical information sources include:

• Mission need statements
• Baseline performance, cost, and schedule goals
• System requirements documents for alternative configurations
• Preliminary system performance
• Specifications for selected configuration
• Engineering change proposals or contract change proposals, as applicable

Typical outputs include:

• Current revision of each document
• Current Document Change Authority (CDCA) and approval status for each document

System Development and Demonstration

Typical information sources include:

• System performance specification
• CI performance specifications
• CI detailed specifications
• Engineering drawings and associated lists
• CAD files
• Test plans and procedures, and results
• Audit plans
• Audit reports
• Audit certifications
• Engineering change proposals
• Request for deviation
• Notice of Revision (NORS)
• Engineering orders, change notices, etc.
• Installation and as-built verification
• Removal and reinstallation

Typical outputs include:

• CDCA release and approval status of each document
• Functional, allocated, and product baselines
• Baselines as of any prior date
• As-designed configuration, current, and as of any prior date
• As-built configuration, current up to time of delivery, and any prior date
• As-delivered configuration
• Status of ECPs and RFDs in process
• Effectivity and incorporation status of approved
• ECPs and RFDs, including retrofit effectivity
• Test and certification requirements to be completed prior to milestones, such as reviews, demonstrations , tests, trials, and delivery
• Verification and audit status and action items

Production and Deployment

Typical information sources include:

• All development phase items
• System CI location by serial number (S/N)
• Support equipment and software
• Spares
• Trainers
• Training material
• Operating and maintenance manuals
• CI delivery dates and warranty data
• Shelf life or operating limits on components with limited life or limited activations, etc.
• Operational history (e.g., for aircraft takeoffs and landings)
• Verification/validation of retrofit instructions, retrofit kits
• Incorporation of retrofit kits
• Installation of spares, replacements by maintenance action

Typical outputs include:

• All development phase items
• Current configuration of all systems/CIs in all locations (as-modified/as-maintained)
• Required and on-board configuration of all support equipment, spares, trainers, training, manuals, software, facilities needed to operate and maintain all systems/CIs at all sites
• Status of all requested, in-process, and approved changes and deviation requests
• Authorization and ordering actions required to implement approved changes, including recurring retrofit
• Warranty status of all CIs
• Predicted replacement date for critical components
• Retrofit actions necessary to bring any serial-numbered CI to the current or any prior configuration

Operational Support

Typical information sources include:

• All production and deployment phase items

Typical outputs include:

• All production and deployment phase items

CONFIGURATION STATUS ACCOUNTING PROCESS EVALUATION CHECKLIST

Documented process:

• Is there a documented configuration status accounting (CSA) process?
• Is the documented process followed?
• Are personnel from all disciplines involved in the process informed and knowledgeable about the procedures they are supposed to follow?

CSA information:

• Has an accurate, timely information base concerning the product and its associated product information, appropriate to the applicable phase(s) of the life cycle, been established?
• Is configuration information appropriate to the product systematically recorded and disseminated?
• Is applicable CSA information captured as CM tasks are performed, and is it available for display or retrieval in a timely fashion?

CSA system:

• Is the data collection and information processing system based on, and consistent with, the configuration status accounting information needs of the organization?
• Are the data relationships in the system based on a sound set of business rules?

Metrics:

• Does the status accounting data being collected and the information system enable meaningful metrics to be developed and used to maintain and improve the CM process?

SUMMARY

Configuration management is based on rules. These rules must be codified and deployed to the various members of the development, support, and administrative staffs. This is done through configuration status accounting (CSA) via a knowledge base that is generally automated through the use of a CM toolset.

REFERENCES

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