Configuration Management Body of Knowledge

Chapter 6: CM Activities and Schedules

Overview

In this section we will discuss the various activities, schedules with definitions, their sequences in the life cycle, and the nature of the duration for these activities.

6.1 WHAT ARE CRITICAL CM ACTIVITIES?

• Planning
• Acquisition and Support
• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Audits

6.1.1 Planning Activities

• the identification of objectives of the Configuration Management program;
• discussions about the Configuration Management organization and organizational relationships;
• defining responsibilities and authority of Configuration Management managers,
• discussions about CM resources such as tools, techniques and methodologies;
• descriptions of the coordination with internal and external groups like program managers, contractors, government agencies, CCBs, etc.;
• policies, processes, procedures, methods, records, reports and forms
• guidelines about acquisitions and support.

This planning effort will result in the development of a formal Configuration Management Plan, a Work Breakdown Structure (WBS), and technical reviews.

6.1.2 Acquisition and Support

• Access to this information shall be limited in accordance with appropriate distribution statements, as well as by data rights, and Contract Data Requirements List (CDRL), distribution (if used) and security requirements.

• Automated processing and electronic submittal techniques should be used whenever possible.

• This integrated technical information service shall accommodate pre-defined queries and extraction of data.

6.1.3 Configuration Identification

Configuration identification shall include the selection of Configured Items. The determination of the types of configuration documentation required for each configuration item is all made. Configuration Management shall issue numbers and other identifiers affixed to the configured items and to the technical documentation that comprises the configured items configuration documentation.

Other things to be considered are the creation of a documentation/drawing/software/equipment library and associated procedures.

Specific Baselines also need to be defined. The Configuration Manager needs to define and document the content of configuration baselines. This would include creating a list of all items and support items for the product being configured for Functional, Allocated, Approved, and Product Baselines.

Any interface requirements need to be identified, tracked and managed, too.

6.1.3.1 CONFIGURATION IDENTIFICATION ACTIVITY

6.1.3.1.1. Configuration Identification General Concepts and Principles

The basic principles of configuration identification are citing 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

• Document 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 variations

• 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/configuration

• Provides a reference point for defining changes and corrective actions.

6.1.3.1.2. Configuration Identification General Activity Guides

Configuration identification incrementally establishes and maintains the definitive current basis for Configuration Control and Status Accounting of a system and its configuration items (CIs) throughout their life cycle development, production, deployment and operational support, until they are no longer needed and disposed.

The Configuration Identification process ensures that all acquisition and efforts to sustain the project have common sets of documentation as the basis for developing a new system or modifying an existing component. This would include buying a product for operational use, and providing support for the system and its components.

The Configuration Identification process also includes using identifiers that are shorthand references to items and their documentation. Good configuration control procedures assure 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 in an effort 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 logistic support planning for the associated CI
  • Issuing identifiers for the CIs and the configuration documentation
  • Determine the Configuration hierarchy of an End-item.
  • Maintaining the identification of CIs to facilitate effective logistics support of items in service
    • Releasing configuration documentation; and
    • Establishing configuration baselines for the control of CIs.

      Effective configuration identification is a pre-requisite for the other configuration management activities (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

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

6.1.3.2 CONFIGURATION ITEMS

The sections that follow detail some concepts, principles, and activities concerning configuration items as it applies to a government - government contractor environment.

6.1.3.2.1. Configuration Item Concepts

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 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, nor does it mean that the performance requirements for the non-CI components must be under configuration control. It depends on the overall requirements of the project or company configuration plan. If, for instance historical builds are required for the life of the project, ALL aspects of both the operational, test, developmental and production environments must be retained to provide for successful recreation. Albeit this is an extreme part of configuration management, but there are projects, specifically, military projects that require this kind of retention. {Edited.

The requirements to be met by a lower-level component (which is not designated as a CI) are established and controlled via the Contractor’s design and engineering release process.

Control occurs only when changes to the lower level components impact the baselined performance specification for the CI.

Initial CI selection should reflect an optimum management level during early acquisition. Initially, for Engineering and Manufacturing Development (Phase II), CIs usually are the deliverable, and separately installable units of the system and other items requiring, significant management attention at Buyer/Seller interfaces (i.e., Purchaser/Prime Contractor, Prime Contractor/Subcontractor, etc.). During, production, fielding/deployment and operational support (Phase III), individual items required for logistics support and designated for separate procurement are also CIs.

Computer software items, because they typically control the functionality of a system, are almost always designated as CIs. The term CI encompasses hardware, software and firmware. When a statement in this handbook applies only to hardware, or only to software, or only to firmware, the terms HWCI, CSCI and FWCI are used.

Typically the top tier of CIs directly relate to the line items of a contract and the Work Breakdown Structure (WBS). The determination of the need to designate them as CIs is normally simple and straight forward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the project. 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 effectiveness 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 project management, systems engineering, acquisition logistics, and configuration management.

CI selection establishes the level of configuration control throughout the system life cycle. {Edited.

Selecting CIs separates a system into individually identified components for the purpose of managing their development and support. CI designation should reflect the optimum level for both acquisition and support. During acquisition, this is the level at which a contracting activity specifies, contracts for, and accepts individual components of a system, and at which the logistics activities organize, assign responsibility and report modification and maintenance actions during support. {Edited.

During the concept exploration and the project definition and risk reduction phases, the system architecture is established, the project work breakdown structure is developed, and major CIs are selected. These activities provide the basis for the Supportability Plan for the project, which, in turn, dictates the selection of lower-level CIs.

Development, acquisition, retrofit, and hardware and software interfaces are all affected by the breakout of the key system elements into CIs during the early stages of the development effort.

6.1.3.2.2. Configuration Item Activity Guide

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

Developers should participate in the selection process and provide recommendations based upon engineering or other technical considerations.

Either the customer or acquiring organization may make initial recommendations of top-level CI candidates as a result of their system engineering analyses; however the developers are normally tasked to provide the comprehensive recommendations.

CI selection criteria are applied to recommendations to decide on the items to be managed as CIs by the Configuration Management Team.

Decisions to designate specific candidates as CIs and decisions on the time when they will come under CM control normally involve an integrated team of acquisition project management, systems engineering, and acquisition logistics working with configuration management. In addition, the configuration management team determines those items in the system that are not configured CIs, but which will be subject to lower tier configuration management by the CM team.

6.1.3.2.3. Configuration Documentation

The term configuration documentation characterizes the information that defines the performance, functional and physical attributes of a product.

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 software support, and re-procurement.

Usually a Purchaser/Customer/Project Manager specifies performance and, in most cases, leaves design solutions to the engineers. The Purchaser/Customer/Project Manager determines the system product structure level at which to specify, baseline and control item performance and the specification type to be used. Below this level the Project Management Team chooses the types of documentation to use.

6.1.3.3. Documentation Types

6.1.3.3.1. Specification Concepts

The selection of the appropriate specification document types is dependent upon a number of factors such as the maturity of the item, and the context and environment in which it must operate.

The order of precedence defined by policy should strongly indicate preference for the use of existing commercial products, wherever possible, and the choice of products meeting Performance rather than Detail Specifications

Program Unique Specifications, of both a performance and detailed nature, are at the bottom of the preference hierarchy and are used when the other choices are not available or applicable.

Nonetheless, acquisition projects dealing with the development of new systems will continue to see the use of program unique specifications where the specifications are being prepared for a single system or item and have little potential for future use except for repetitive fiscal year production and spares purchases.

Both the Purchaser/Customers/Project Managers and engineers should seize opportunities at lower levels of the specification tree (where developed items, referred to as non-developmental items (NDI) may be used) to select higher preference specification types, and to specify only performance and interface requirements rather than design solutions in those specifications, whenever possible.

6.1.3.3.2. Specification Activity Guides

Industry	Description
Industry	Standards or specifications published by industry associations or societies recognized as standards making bodies by the American National Standards Institute (ANSI), which define minimum acceptable performance and quality, or precise interface requirements for a category of product. Examples of industry associations are DIN, ASME, SAE, EIA; example of performance/quality standard is SAE 50 Motor Oil; examples of standard interfaces are electronic connectors, screw thread sizes.
Commercial	Commercial Item Descriptions (CID) are standard descriptions that by definition, are performance-based because they facilitate competitive bid for products meeting a stated functional requirement. Also commercial product descriptions (such as a manufacturer’s catalog or specification sheet) and commercial purchase descriptions (item descriptions to be spelled out directly in a purchase order) qualify under this category.
Federal	Standards or specifications applicable to all agencies of the federal purchasing for items widely used. (They may be either performance or detail based).
Military	Specifications prepared for standard items with use in many different applications in weapons systems and their support equipment. These specifications are intended mainly for the competitive procurements of identical items for use as spares and for use in new weapons systems. Military Specifications are prepared in accordance with MIL-STD-961 and are listed in the DoD Index of Specifications and Standards (DODISS). They are subject to the requirements of the Defense Standardization Program.
Standard Performance	Standard Performance Specifications (MIL-PRF) are performance specifications for items common to a number of different systems and subsystems. They follow the same guidelines as other performance specifications (see category b. below). They differ from Military specifications in that different, perhaps competing products that are not identical but meet the same form fit and function requirements may satisfy them.
Program Unique	Specifications for a system, item, software, process or material, unique to a specific acquisition program, prepared by either Purchaser/Customer/Project Manager or engineer to define and baseline requirements for development, production (including repetitive fiscal year production and spares purchases), support and re-procurement. Program unique specification format and content are defined in MIL-STD-961D
General, Associated and Specification Sheets	A general specification is one which facilitates the preparation of specifications for a number of items that are common except for specific variables such as size, power, range, etc. The General Specification defines the common requirements; the specific variables of each item are defined in either associated specifications or specification sheets. Associated specifications are used when the variables require a number of pages of specification language to define. Specification sheets are used when the variables can be numerically tabulated. Both are linked by specification number to the related general specification. Typically the general specification number followed by a slash and a serially assigned identifier identifies the associated Specification, or specification sheet. (Example: MIL-PRF-18/25)Where there is ambiguity (conflict) between the General Specification and the Associated Specifications or Specification Sheets, the latter governs because it describes the specifics of a product while the general specification encompasses a family of products.
Generic or Guide	A Generic or Guide Specification is a tool for preparing a number of similar specifications for a class of like end items to be developed. The guide specification is a “template,” which identifies all of the essential performance parameters normally associated with the class of item, but does not provide the specific performance capabilities. The specification is then tailored to fill in the blanks to create a specific system or item specification.
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 inter-operability 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 two 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 inter-operability 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 prepared in accordance with MIL-STD-961. A Software Performance Specification is similar to the Software Requirements Specification (formerly required by MIL-STD-2167A, and MIL-STD-498). A Software Detailed Specification is similar to the Software Requirements Specification plus the set of design documents describing the software, interface and database design.
Material	Material specifications are used where a raw material, mixture, or semi-fabricated material has been developed specifically for use with a particular item or system and is critical to the performance or design of the item. (Example a missile rocket motor solid propellant chemical mixture.) The material specification is called out in the CI(s) design documentation. It therefore becomes part of the product baseline of the CI(s). An item performance (product)specification(essentially the same document)or an item detailed specification(containing specific design requirements)issued to provide the contractual basis for acquisition of production quantities of the CI.
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. (A common Example – the curing process for the missile rocket motor solid propellant.) The process specification forms a part of the product baseline of the CI(s)

Table: Specification Types Categorized by Object

6.1.3.3.3. Design Solution Document Concepts

The requirements of the functional and allocated baseline are basically design constraints on the development contractor.

The design solution evolves from the contractor’s design and development process during the engineering and manufacturing development 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 part lists (e.g. Bill of Material BOM), and 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 data base file. Various models and product modeling tools may 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 (like 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 the contractor employs 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 may 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 documentation to be managed by the development contractor consists of the design and technical data under the contractor's internal control. Some of this data may transition to Purchaser configuration control and be designated as the Purchaser Product Baseline; some of it may remain under Contractor configuration control and be designated as Contractor Product Baseline.

The developmental configuration management process implemented by the development contractor consists of a formal process to control the documentation and repositories containing the elements of the developmental configuration.

The contractor's 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.

6.1.3.3.4. Design Solution and Software Documentation Activity Guide

The below tables provide detailed information concerning the documentation used to document the design solution.

They also contains a complete set of software documents that are used for planning, system and software requirements analysis, software integration and testing, software product definition, operation and maintenance in addition to design description.

Several software design description documents can evolve from earlier versions used to support one or more of these other functions. The Purchaser needs access to some of these documents to the extent necessary for logistic support and software maintenance during the operational support period. This activity guide therefore addresses the documentation that can evolve over the full life cycle of a system/CSCI.

Detailed design documents for the CIs and CSCIs that the Purchaser will support will be made accessible from a Purchaser repository. Meta-data concerning these documents will be available from CM Automated Management Information System (CAIMS) provided that the information that the Purchaser requires the contractor to load into these systems is specified in the contract.

Terminology

Definition	Description
Drawing	A drawing is an engineering document or digital data file that discloses the physical and functional requirements of an item (directly by means of graphic and textual presentations, or by reference). Drawings communicate a variety of information, both textual and graphic. All drawings have certain common elements. Normally several types of engineering drawings combined into sets with associated lists are required to completely define the end-product requirements of an item. Drawings may be categorized into the following MIL-DTL-31000 Technical Data Package(TDP) elements: * Conceptual design drawings * Developmental design drawings * Product drawings * Commercial drawings * Special inspection* equipment drawings * Special tooling drawings.
Drawing Types & Applications	* Detail, assembly, control, installation and diagrammatic drawings, as necessary, provide engineering description and control of product attributes. * Ancillary drawings (drawings supplementing end-product drawings) and special application drawing types aid logistics, configuration management, manufacturing, or other functions. * Additional project-unique types: procurement control, design control, vendor item control, microcircuit drawing set, paint scheme, software, transportability, camouflage basis and pattern, combination of adopted items, kits, package content.
Common Drawing Sheet Sizes and Format	* Drawing sheet sizes, Standard sizes for engineering drawing sheets, e.g., A, B, C, etc. * Title block - Design activity name and address, drawing title, drawing number, drawing size, CAGE Code, drawing scale, drawing sheet size, number of sheets (for a multi-sheet drawing). Most formats include drawing approval authority and angle of projection symbols. * Revisions block – Usually in the upper right hand corner. See Revisions to drawings, below. * Optional blocks – Additional blocks may be included on a drawing format adjacent to the Title Block. Examples: Application Block and Mechanical Properties Block.
Drawing Variables	* Media -Hard copy – Single sheet, multi-sheet, tabulation, book-form, drawings for microcircuits -Digital - Magnetic tape, Raster Image, IGES, PDES/STEP representations. * Format -Contractor – Contractor title block, CAGE code and process -Purchaser - For repetitive re-procurement of identical items, Purchaser title block, CAGE code and release control * Detail options -Mono-detail - Each drawing covers a single part or assembly -Multi-detail - A drawing may cover an assembly and detail parts - Dimensioning and tolerancing - Several conventions may be chosen - Drawing notes – Short, concise statements providing clarification. They may apply to the entire drawing or any portion of the drawing. Notes do not include contractual requirements or Requirements for data submission, approval or distribution. Preferably Notes are located on sheet 1 of the drawing, or direction is included on sheet 1 indicating location of notes, i.e., on parts list, or separate associated list.
Associated Lists	Parts list - a tabulation of all parts and bulk materials (except those materials which support a process) used in the item to which the list applies. Parts Lists may be Integral Parts Lists, prepared and maintained as part of the actual engineering drawing, or Separate Parts Lists, prepared as a document separate from the drawing with which it is associated and maintained independently from that drawing. Data list - a tabulation of all engineering drawings, associated lists, specifications, standards, and subordinate data lists pertaining to the item to which the data list applies - Indentured data list - that is structured by successive assembly level Index list -- a tabulation of data lists and subordinate index lists pertaining to the item to which the list applies Wire list - a tabulation of all the wires in an assembly which indicates their identification and terminations - Application list - a tabulation of parts and the next higher assemblies into which they install. (Commonly referred to as a where used list.)
Drawing revision identification	Any change to a drawing, including a change to Rights-in-Data, must be recorded in the revisions block of the affected drawing. - Record revision status, identification of change authorization documents, or description of changes, and change approvals, and if multi-sheet, revision status of sheets Note: If revision history is maintained in a data base, common practice is to provide it as part of an associated list (e.g. parts list) or via data base access rather than on the field of the drawing
Numbering Coding and Identification	Drawing and part identification rules liberal enough to accommodate a wide variety of industry practices. Any keyboard characters allowed. - Limited to precise drawing and part identification discipline necessary to provide unique identification for military equipment (e.g., use of CAGE codes, part identity keyed to drawing identity) - Original and current design activity; design disclosure, delivery of drawing originals - Drawing title conventions - Special markings, symbols and part/item replacement notations - Marking for shipment and storage - Special items and processes (e.g., system safety, electrostatic discharge) - Type designators
Drawing Requirements Manual (DRM)	Tailoring and Application Guides. -Drawing or Drafting Manuals are a reference defining in-house practices and extent of applicability of Standards. Purchaser activities use tailoring or application guides. -The DRM guides and standardizes drawing form and presentation, facilitate communication (of intent and technical detail), assure consistent quality, simplify training, and provide a basis for improving practices.

Table: Engineering Drawings and Associated Lists

Acronyms and Nomenclature

Software Integration and Qualification Testing As-Built Software Product Definition

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
Process Implementation - Planning
OCD	Operational Concept Document – proposed system; user needs	No MIL-STD-961 Equivalent: These Documents are not Specifications	Not configuration documentation. Data Control Only (i.e., Baseline internal to developer for document, document representation and file management purposes only).
SDP	Software Development Plan - development effort; process, methods, schedules, organization, resources. (Includes or refers to SCM & SQA plans)
STP	Software Test Plan – Qualification testing; SW item; SW system; environment, tests, schedules
SIP	Software Installation Plan - installing SW; user sites; preparations; training; conversion
STP	Software Transition Plan – transitioning to maintenance Organization; HW; SW; resources; life cycle support.
System Requirements Analysis & Architectural Design
SSS	System/Subsystem Specification – Specifies system or subsystem Requirements; requirement verification methods. (May be supplemented with system level IRS)	-Program Unique System Performance specification	- Functional or Allocated Baseline
SSDD	System/Subsystem Design Description – system/subsystem-wide design; architectural design; basis for system development. (May be supplemented with IDD, DBDD)	Part of Program Unique System Detail specification	Design release
Software Requirements Analysis & Design
SRS	Software Requirements Specification - specifies SW requirements; verification methods. May be supplemented with IRS)	Part of Program Unique Software Performance or Detail Specification -Purchaser or Contractor)	Allocated Baseline for CSCI
IRS	Interface Requirements Specification - specifies interface requirements for one or more systems, subsystems, HW items, SW items, operations or other system components; any number of interfaces (Can supplement SSS, SSDD, SRS)	Part of Program Unique Software Performance or Detail Specification	-( Purchaser or Contractor)Allocated Baseline for CSCI
Software Architectural and Detailed Design
SDD	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)	- All are part of Program Unique Software Detail Specification	-All are Config Doc - Design release
IDD	Interface Design Description – interface characteristics; one or more systems, subsystems, HW items, SW items, operations or other system components; any number of interfaces; detail companion to IRS; communicate and control interface design decisions (Can supplement SDD, SDD)	- All are part of Program Unique Software Detail Specification	- All are Config Doc -Design release
DBDD	Data Base Design Description – data base design; related data, files, SW/data base management system for access, basis for implementation and maintenance	- All are part of Program Unique Software Detail Specification	- All are Config Doc -Design release
STD	Software Test Description - test preparations; test cases; test procedures; qualification testing SW item, SW system or subsystem	- No MIL-STD-961 equivalent. These documents are not specifications	-Not configuration documentation. - Data Control - Evaluate change to config docs for impact on these test docs
STR	Software Test Report - record of test performed; assess results.	- No MIL-STD-961 equivalent. These documents are not specifications	-Not configuration documentation. - Data Control - Evaluate change to config docs for impact on these test docs
SPS	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	- Part of complete Program Unique Product Detail specification	- Product baseline; either Purchaser or Contractor
VDD	Version Description Document – identifies and describes a SW version; used to release, track and control each version	- No MIL-STD-961 equivalent: This document is not a spec	- Not baselined. Status Accounting record for released SW Version

Table: Software Documentation

6.1.3.4. DOCUMENT AND ITEM IDENTIFICATION

Identification consists of Numbering and Naming.

The sections that follow detail some concepts, principles, and activities concerning document identification as it applies to a government - government contractor environment.

6.1.3.4.1. Document Identification Concepts

A document identification principle is that 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.

In the principle the following three elements are used to assure the unique identity of any document: source of document, document type and document identifier. In addition, revision identifier and/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; 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 organization which 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.

6.1.3.4.2. Document Identification Activity Guide

Document Artifact	Description
CAGE Code or NSCM (NATO Supply Code for Mfg.)	CAGE (and NSCM) Codes identify the source of the document The codes are affixed to all CIs, and their replaceable subordinate parts and assemblies. They are also part of the identification marking of each item of configuration documentation, software media and software product.
Document Identifier	The document Identifier distinguishes one document produced by the organization referenced by the CAGE code from another. Each document and each revision thereto, requires the document identifier. There are as many schemes for identifying documents as there are organizations producing them, so there is no standard format for all documents. There are however, a few common sense constraints on the numbering content for some specifications, and engineering drawings, as defined in applicable standards
Revision Identifier	Revision Identifier clearly establishes which issue of a particular document is current or applicable.
Version Identifier	Conceptually the same as revision, version is the term typically used for files
Date	Date is an additional discriminator. It is good common sense business practice to date every document and every revision
Restrictive Markings:	These requirements apply to digital data files and digital media as well as to paper documents and are all intended to limit the access to such data to those entitled to access them.
Security Markings	Security markings are required to be clearly marked on all classified data and special handling requirements apply. Each contract contains classification guidance and direction, which must be strictly adhered to.
Distribution Statements	Specific distribution statements and export restrictions must be marked on information subject to secondary distribution limitations as prescribed by law and as indicated by the contract. The purpose of these markings is to inform the secondary distributor, such as a Purchaser repository whether they can legally provide the subject information to third parties, and if the data are allowed to be exported to foreign countries.
Data Rights	Documents which contain data for which the Purchaser or other parties do not have unlimited rights, must be appropriately labeled to indicate the data rights limitations, so that proprietary information disclosed to the Purchaser for specific purposes is protected.

Item Identification Concepts

The following principles apply to the Identification of Configuration Items:

• All products (Configuration Items) are assigned unique identifiers (e.g., Nomenclature, Cage Code, Part/Item Number) 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 (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 (Serial Number) even though 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 (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.

Contractors assign identifiers including serial and lot numbers to CIs and their component parts, as necessary to establish the CI effectiveness of each configuration of each item of hardware, software and firmware.

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 and, when required, in object code and in alterable read-only memory devices (firmware).

Software Identification

The identification of software is performed for Computer Programs, Software Files, File Identifier Fields, Source Files, Object Files, Executable Files, and Patches.

When we speak of Computer Program Identification we recognize that software is identified at two levels. It is identified at the configuration item level and at the file level.

The table below shows the typical identifiers at the computer program level.

Name	Acronym	Identifier
Operation System	OS	Partnumber
Office Package	OP	Partnumber

These identifiers provide common identification for the collection of items that make up the computer program, and serve as an address for all actions and documentation applicable to that computer program.

Software File Identification includes the identification of the code itself. Code is usually identified at the individual file level, and there are three different types of software files to be identified (Source, Object and Executable). Software is identified at the file level, and each file identifier has three fields that can be used:

• the filename number,
• the file type and the
• version number.

Source Files are the input to the code generation process and are uniquely identified using the file name number, file type and version number. Object files result from passing the source code through a compile or assembler, which changes the statements of the source code to machine language. In this transformation:

• The file name number remains the same as the source file name
• The file type is changed
• The version number is changed to the next higher number from the highest version number of the existing object file

An executable file results from the linking of a number of object files and its identified by file name number, file type and version number. Recognizing, that many object files will be merged into one executable file, it is considered best to specify the executable file name at the time of generation. This is usually a name and number meaningful in the computer program’s context.

The use of patches (code introduced into executable files) should be limited to the really necessary extent needed, however there are circumstances in which there is no other choice. If patches are to be used, an identification scheme is required. Patches are identified as executable files, and the identification fields include the filename number, file type and the version number.

Hardware Identification

The other major component that is typically configured is Hardware. Hardware identification includes identifying through the use of Part/Item Identification Numbers (PN) and Additional Identifiers.

The developing contractor assigns a discrete part/item identification number (PN), 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 non-interchangeable condition is created.

The format of the Part number is optional and a wide variety of formats are employed. Some contractors 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.

In combination with the Part Number the manufactures code (Cage Code, NSCM) should be used to clearly identify an item. Manufacturers normally produce items in lots. A lot, is a collection of identically manufactured items that have been treated as a unique entity. If, due to some anomaly in the manufacturing process, items from a particular lot have failures, they can be identified easily by its lot number For this reason items are usually marked with the manufactures lot number and the date of manufacture.

Items that are repairable are usually assigned a serial number. It enables a unique identification of repairable items and allows to track this item through a logistic system. End-items have usually in addition a model-number

Firmware Identification

Firmware is a combination of a hardware device and computer instructions, or data, which resides as read-only software on it, where the software can not readily being modified. Both the hardware as the software needs to be identified as well as the firmware itself.

There are three items that require consideration. First, the basic hardware item, which is identified as any other hardware item. Second, the Software to be embedded in the hardware part. Third, the production of an image file from the previously produced executable file.

Image File considerations

An image file is an structured collection of executables, formatted in accordance with the requirements of the device that places the image file on the hardware.

The formats can vary widely, but there are two items that require configuration management attention. First, the format is a manufacturing interface and must be stated explicitly. Second, there are advantages to some formats in terms of being able to add headers, which include the image file identifier. Should the external markings on the hardware part itself be obscured, the use of the software header provides additional insurance.

Serial and Lot Numbers

CIs are the address for effectiveness of subordinate parts, and for the effectiveness of changes to subordinate parts. This means that the effectiveness of a part is expressed in terms of the range of serial numbers of the CI end item into which it is assembled.

Note: There are other ways of expressing the effectiveness, particularly in commercial industry, but whether lot, block, FY contract, date or other term is used, it must translate as closely as possible to which serial numbered CIs will have the part installed.

There are also several kinds of related serial numbers that are employed in a CI production phase. The Purchaser normally identifies the serial numbers to be affixed by the contractor on Purchaser designated deliverable CIs.

Purchaser serial numbers are in a variety of formats depending upon the type of equipment and the policy of the acquisition command. The issuance of Purchaser serial numbers should be avoided where the contractor has an acceptable process for assigning unique serial numbers. Among other impacts, it increases Purchaser administrative expenses in maintaining serial number block assignment logs for numbers of items (and for multiple suppliers of those items) for the Purchaser inventory.

Contractors assign serial numbers to units in production. All engineering, manufacturing and quality data will refer to the serial numbers.

These serial numbers may or may not correspond directly to the serial numbers to be marked on parts or name plates (delivery numbers), because for various reasons the shop units may not complete the manufacturing process in sequence, or some units in the flow may be sent to another customer.

Where impractical to serialize individual units, because of quantity or composition of the part or material, lot numbers are employed to identify a group of identical parts.

Typically lot numbers are employed for subordinate parts below the CI level, but occasionally, they are appropriate at the CI level, as for example with rounds of ammunition.

The lot numbers are controlled and are subject to the same constraints as the serial numbers.

The important factors, in evaluating a contractor’s system of item identification is that there must be an effective process for controlling the effectiveness of parts by serial number (either shop number or delivery number). A comprehensive cross-reference must be maintained between the shop number of an item and its delivery serial number, or for lot-controlled items, between the manufacturing lot and the delivery lot.

Naming Activity Guide

Naming Conventions are often weak or nonexistent because it is difficult to maintain consistency in the way various items are described.

A physical item should be described after it has been assigned a proper name. A generic noun which best describes the item is the proper name. Consistency is hereby essential.

The first step is to select a noun which may or may not be a preferred noun. It may be an alias of a preferred noun. The system will respond in either case and confirm the preferred noun or identify the preferred noun if the initial entry was an alias.

Once this first step is achieved, the system should provide step-by-step “prompts” for describing key attributes of the item. There may still be uncertainty after selecting a noun from the aliases.

The descriptive attributes must be identified in their describing order of significance for each preferred noun.

The following example shows how one organization chose to describe the attributes of “Bolts” in their descending order of significance.

Preferred Noun	First Attribute	Second Attribute	Third Attribute	Fourth Attribute	Fifth Attribute	Sixth Attribute
Bolt,	Steel,	Hex,	SAE5	CAD	0.50-20	X3.00

Item Identification Activity Guide

The below Table provides details about item identification, including hardware, software and firmware.

Identifier Element	Definition/Requirement
Nomenclature	Contract must specify items or types of items to be assigned nomenclature - Nomenclature requested from Purchaser: in accordance with specified requirements - Contractor assigns nomenclature in accordance with guidelines - Purchaser approves nomenclature - Nomenclature is revised when necessary to account for a non-interchangeable condition
Part/Item Identification Number (PN)	- Uniquely identify the item (when combined with the item's design CAGE code) - All CIs, parts, assemblies, units, sets - PN is the same as, or contains, drawing or other design document number - Assigned by developing contractor - Changed (e.g. new dash number) when part is modified and a non-interchangeable condition is created
Serial and Lot Numbers (Product tracking identifiers)	- Uniquely identify an individual unit or specific group of units of an item (when combined with the manufacturer's identifier, e.g., CAGE Code, and the basis for serialization -- product-tracking base identifier.) - When applied to CIs, are the basis for effectivity of subordinate parts - Purchaser may designate serial numbers for deliverable CIs. If the Purchaser provides no serial numbers, the contractor will serialize each delivery unit according to his own system and convention. - Serial and Lot numbers are unique, consecutive, and non-duplicating for a specific nomenclature or part identifier. - The original serial number of a unit/item/CI is not changed even when a change affecting interchangeability may require rework and re-identification. - Once assigned, serial numbers and lot numbers are never re-used for the same item. This rule applies to all types of serial numbers including delivery serial numbers and shop numbers as well. - It applies to lot numbered items to the extent practicable; if rework occurs by lot, in different lots than original manufacture, this rule is may be broken with the understanding that traceability to the original lot must be recorded.. - There should never be two items with the same part number and the same serial number produced by the same manufacturer. - Serial and Lot Numbers must be assigned against a non-changing base, known as a product tracking base-identifier.
Software Identifier	- Each CSCI shall have an identifier consisting of a name and number. It uniquely identifies the software when combined with the CAGE code or name of the company that developed it. - Each Version of the Software CSCI shall have a version identifier supplementing the software identifier - Software units, at and below the CSCI level, are identified using developing contractor convention, typically the conventions of the software language in which it is written.
Firmware Identifiers	- Where both the hardware device and the embedded code are documented and controlled via the same engineering design document (drawing), the PN for the device with code embedded identifies the firmware - Where the hardware device and the software to be embedded are documented and controlled separately, the device is identified by a PN and serial number; the embedded software is identified as a CSCI
Items with assigned Nomenclature, Nameplated Items	- Contain the following identification information on their name plates: - Nomenclature - Design Activity CAGE code and name - Part Number - Serial Number (Normally applicable; Lot Number if Serial Number is not applicable) - Manufacturer - Acquiring Purchaser Activity - Contract Number under which it is acquired - National Stock Number, if applicable - Bar-coding, if specified, typically containing NSN and selected information above such as part and serial numbers.
All Items large enough to legibly mark	- Design CAGE code (or other industry source identifier, if applicable) - Part Number - Manufacturer (CAGE code or name) - Serial or Lot Number, if applicable - Standard Number (MIL or commercial) if applicable
Small items	- Reference designator (on part or adjacent to it, as on a circuit board) relating the item to a documented record, or as in the case of electronic components, to an element on a schematic diagram - Striping, and or color coding, as on resistors and capacitors and other components, which indicate their values and tolerances according to industry standards
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.
Software media identifiers	- Each software medium (for example, 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. - Media for deliverable CSCIs are labeled with the Purchaser contract number, the CAGE code and CSCI software identifier, the PN (if any), and the media number (for example, 1 of 2, 2 of 2) if there are multiple units per set and copy number (Copy No. 1, 2, etc.) of the medium or media set (if there is more than one copy being delivered).
Non-re-programmable	- PN representing the device with software embedded is marked on device, or if device is too small on an adjacent assembly
Programmable	- PN of device (without software) and serial number of device, if applicable, is marked on the device - For software labeling, see "Software identifier and version identifier" above. Device marking does not change when software is loaded or reprogrammed.

Table: Item Identifier Guideline

Achieving Valid Documentation

Signatures are used to signify that a document has been reviewed and validated. Gathering the required signatures is an important process.

Sometimes it is also a heavy burden to obtain the various signature levels.

Very often the number of signatures on a document is used to demonstrate its integrity.

Documentation Signatures

Signatures are used to signify that a document has been validated. Gathering the required signatures is an important process. The importance sometimes implies the implementation of various signature levels. Very often the number of signatures on a document is used to demonstrate its integrity.

The different types of documentation often include signature blocks.

This signature block is used for validation and release of the document.

Although the signature block may include any number of spaces for signatures, it does not mean that each space must be used.

The adequate level of signatures can be achieved by answering the following questions:

• How many signatures are really required to revise a single document?
• Should separate signatures be required for each affected document regardless of how many documents are affected by the same change?
• Should required signatures be determined on a change-by-change basis or on a document-by-document basis or both?

A general answer can not be given. The required number of signature depends on various issues.

To facilitate and improve the release process the following points could be considered:

• Relatively complex documents (residing at End-Item Level and above) should be validated by each member of a cross-functional team.
• Less complex documents (below End-Item level) should be validated by only two individuals, the “creator” of the document as the first signature and a “user” of the document as the second required signature. The creator is the one who best understands the higher level requirements and is the co-owner.

Once a newly created document or a revised document is ready for validation, an actual user should have that responsibility.

If the document has more than one user, one of those users should be designated representing the user community.

The designated user is responsible for assuring that the document will be free of difficulties for all users.

Such signatures serve as a proof that the document is clear concise and valid for all who use it for its intended purpose.

6.1.3.5. CONFIGURATION HIERARCHIES

The sections that follow detail some concepts, principles, and activities concerning configuration hieracharies as it applies to a government - government contractor environment.

Configuration Hierarchy Concepts

Physical Item Hierarchy

During 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 for the Purchaser to specify and control item performance.

This is typically the lowest level at which CIs are designated during the Engineering and Manufacturing Development Phase of the life cycle.

During acquisition the Engineering environments is using often specification and drawing trees, and work breakdown structures are to display the views of the product structure which are directly related at the CI level.

Project and contract Work Breakdown Structures (WBS) are views of the product family tree structure showing the hardware, software, services, 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. Uniform element terminology, definition, and placement in the upper three levels of a WBS are common for many categories of defense materiel.

The WBS is extended to lower levels by the purchaser component and contractor(s).

Each end item product represents a hierarchy of physical items. Each item has at each level its own unique set of supporting documentation.

Such a hierarchy provides an ideal framework within which all supporting documents and/or data sets can be efficiently managed.

Figure: Physical Item Hierarchy

Hierarchies can be established for products, services, facilities, IT Solutions etc.

The “WHERE-USED” Problem

Lets take an practical example to describe this problem.

1. A computer system fails and causes a major delay in a production line.
2. There is an intense interest in allocating the problem which causes this situation and taking the necessary steps to overcome this problem.
3. After analyzing the situation, it may be determined that lately someone replaced a part in the system with a alternate part. Engineering analysis indicates later that the overall system design is sound, but the system failed because of an unreliable component used.
4. The question immediately arising is, where else is that alternate part used? Identifying all the assemblies where the alternate part is used can only be done if that configuration identification capability has already been implemented in the Configuration Management System.
5. From this where used example you can see also the need to provide additional information on the “as-build” documentation such as the manufactures code, lot number, and date of manufacture.
6. The “WHERE-USED” problem is already very complex, but think about it how difficult it might be in the area of software, when the software reuse grows.
   What happens when:
   • a vendor of a group of mathematical algorithms discovers that, under certain conditions, a particular release of a product produces incorrect results;
   • hardware manufactures have purchased and incorporated those algorithms in their products as either firmware or support software; those products have been used to compute flight data of a missile. Immediate corrective is required, and the first thing to look at is the “Where used”.

Administrative Hierarchy

Above we have seen the Physical Item Hierarchy which describes the parent-child relation from the End-Item to the lower level items.In order to achieve the business objectives, an Enterprise has also to establish a hierarchy of administrative requirements.

Regulations for running the business are the highest level.

The business requirements will be flown-down from a high level mission statement and a Strategic Business Plan into lower-level Standards, Procedures and Work Instructions.

Figure: Administrative Hierarchy

Linkage of Primary Items to Documents

Each item residing at each indenture level in a physical item hierarchy should have its own unique set of supporting documentation and data. Although the type of documents or data sets vary with the type of items, items of the same type usually require the same types of data sets.

Each item, is linked by its Part number to each of its supporting documents by type, identifier and revision level.

Following the CMII concept, Physical items that reside within the hierarchy of the End-item are categorized as primary items.

The supporting documents that are linked directly to a primary item are categorized as primary documents.

Secondary items are represented by equipment and tools used to develop, produce, operate and/or maintain primary items.

There are two types of secondary documents.

• The documentation which support secondary items such as tools and equipment is one type.
• Standard instructions for performing repetitive processes such as painting, soldering, compiling etc. are a second type.

Secondary items should be linked to the process plan for the primary item on which they are used. The process plan describes how the tools and equipment are to be used to accomplish the process.

Administrative Hierarchy and Linkages

The proper structuring and linking of administrative requirements from the mission statement and strategic business plan at the higher levels to the operating standards and supporting procedures at the lower levels, are important.

• Mission Statement and Strategic Business Plan

  A mission statement serves to state the purpose of the organization. It is followed by a Strategic Business Plan, describing how the purpose will be accomplished.

  The plan should consists of, but not limited to:

  • Mission Statement which is a High level statement of the business objectives
  • Relationship to other divisions/sites/partners that discusses interdependencies
  • Organizational Hierarchy and personnel policies
  • Products, services and customers and their perceptions in market-place and market share.
  • Core business processes and operating standards that address how the day-to-day operations are conducted.
  • Financial performance and projections for the past, present and future.
  • Human resource development and training, education and career development.
  • Compensation and incentive plans
  • Internal and external audits, performance measurements.
  • Introduce a CM Controlling and Reporting System
  • Product, process and administrative improvements
• As-Designed versus As-Build Hierarchies
• Logistic Concept Influence Structure
• Bills of Material
• As-Planned Hierarchy for the End-Item
• Re-identification
• Exchangeable Items
• Use of exchangeable items
• Interchangeable Items
• Substitute Items
• Replacement Items
• Considerations in using exchangeable items

CONFIGURATION BASELINES

• Configuration Baseline Concepts
• Configuration Baseline Activity Guides
• As-Planned and As-Released Baseline
• Content, Format and Application

Libraries

The sections that follow detail some concepts, principles, and activities concerning libraries as it applies to a government - government contractor environment.

INTERFACE MANAGEMENT

• Interface Management Concepts
• Interface Control Working Group (ICWG)

6.1.4 Configuration Control

The Configuration Manager shall apply internal configuration control measures to all Configuration Items prior to the time that it is baselined. These control measures shall also be applied to each baselined configuration item as well. This control program should:

• Ensure effective control of all Configured Items and their approved documentation.
• Provide effective means for proposing changes, requesting deviations or waivers, preparing notices of revisions, and preparing change notices.

6.1.4.1. CONFIGURATION CONTROL ACTIVITY

• Configuration Control - General Concepts and Principles
• Configuration Control Authority

6.1.4.2. CONFIGURATION CONTROL BOARD (CCB)

• CCB Authority
• CCB Membership
• CCB Charter
• CCB Operating procedures
• Splitting Responsibilities

6.1.4.3. CHANGE PROCESS AND KEY DECISION POINTS

6.1.4.4. TRACEABILITY

6.1.4.5. CONFIGURATION CONTROL CATEGORIES AND FAST TRACK OPTIONS

6.1.4.6. JOINT PROJECT CONFIGURATION CONTROL CATEGORIES (CCC)

6.1.4.7. CM ADMINISTRATION FUNCTIONS

6.1.4.8. EFFECTIVENESS VERSUS EFFECTIVE DATES

• Effectiveness
• Effective Dates Versus Release Dates

6.1.4.9. ENGINEERING CHANGE PROPOSAL

• ECP Concepts and Principles
  • ECP Initiation
  • Unsolicited ECPs.
  • Change Classification
• ECP Preparation and Submittal
  • Automated Processing of ECPs
  • Unrelated engineering changes.
  • Revisions of ECPs
  • Amendments of ECPs
  • ECP Supporting Data

• Implementing ECPs
  • ECP Activity Guides
  • Class I ECP Types and their function
  • LECP priorities
  • Class I ECP justification codes

6.1.4.10. NOTICE OF REVISION (NOR)

• NOR Concepts and Principles

6.1.4.11. REQUEST FOR DEVIATION/WAIVER (RFD/W)

• RFD/W Classification
• RFD/W effectivity
• RFD/W preparation and submittal
• RFD/W approval/disapproval decisions
• Recurring RFD/Ws.

6.1.4.12. MODIFICATION WORK ORDER

6.1.5 Configuration Status Accounting

The Configuration Manger shall implement a Status Accounting System. This system should:

• identify the current approved configuration documentation and identification number associated with each CI.
• Record and report the status of proposed changes from initiation to final approval/contractual implementation.
• Record and report the results of configuration audits to include the status and final disposition of identified discrepancies.
• Record and report the status of all critical and major requests for deviations and waivers which affect the configuration of any particular configuration item.
• Record and report implementation status of authorized changes.
• Provide the traceability of all changes from the original baselined configuration of each configured item.
• Report the effectiveness and installation status of configuration changes to all Configured Items at all locations.

6.5.1.1 CONFIGURATION STATUS ACCOUNTING ACTIVITY

• CSA CONCEPTS AND PRINCIPLES.
• METRICS MODEL
  • Characteristics of a Good Metric
  • Developing Good Metrics
  • Feedback Loop

6.1.5.2. TECHNICAL DATA MANAGEMENT

• Automated Configuration Management System

6.1.5.3. DATA INTEGRITY AND ACCURACY

• Data Base Audits and Error Removal

6.1.6 Configuration Audits

The objective of the FCA is to verify the product's functionality as defined by specification and change requests is demonstrated via operation and testing. The objective of the PCA is to verify that the physical location of the pieces and parts of the product, where it resides, its versioning, associated tools and documentation, and the 'as-built' are in agreement. FCA/PCA Efforts are very labor intensive.

6.1.6.1. CONFIGURATION VERIFICATION AND AUDIT ACTIVITY

6.1.6.2. CONFIGURATION VERIFICATION AND AUDIT CONCEPTS AND PRINCIPLES

• Configuration Verification
• Configuration Audit
  • Functional Configuration Audit
  • Physical Configuration Audit

6.2 HOW DO THESE ACTIVITIES FIT INTO LIFE CYCLE?

Configuration Control is active over the entire life cycle, as is status accounting and Audits. A day should not go by without an audit of some kind being performed.

6.3 OTHER ACTIVITIES

Problem Reporting Functions include but are not limited to:

• Receiving problems reports
• Document problem reports, number them, record them
• Evaluate level of urgency of new problem reports
• Perform administrative review of problem reports for completeness
• Assign and update the status of problem reports
• Provide copies of problem rpeorts to quality assurance, and programming managers
• Receive and process problem report updates or continuation sheets
• Assist in QA and project evaluation of problem reports getting them scheduled for a CCB.
• Prepare problem reports for CCB
• Problem report filing
• Updating problem reports with CCB and QA dispositions.

CCB Functions include but are not limited to:

• Preparing CCB agendas
• Attending CCB Meetings
• Taking CCB Minutes
• Keep CCB Distribution lists up to date
• Producing CCB Minutes
• Maintain CCB Charter

Change Proposal Functions include by are not limited to:

• Initiating Change Proposal packages and documentation
• Incorporation of User Group Comments into Change Proposals
• Entering Change Proposals and logging them
• Implementing Project funding direction changes in Change Proposals
• Keeping the Change Proposal database current

Document Library Functions include but are not limited to:

• Check in/out documents to/from the Library
• Log new documents into the library and database
• Prepare inventory of recorded material
• Prepare reports as required
• Prepare requests for reproduction of material

Configuration Handling Functions include but are not limited to:

• Compile source code/link/build
• Control configured software
• Create test baseline
• Create approved baseline from test baseline
• Create developmental baseline
• Forward changes and developmental baselines to QA
• Foward copy of preliminary release package to project management and QA
• Create final developmental baseline
• Create final release package
• Identify items for final configuration
• Identify and correct differences between final released item and preliminary versions.
• Make copies and distribute final release package to Project Management
• Perform Baseline Configuration Audits
• Perform PCA
• Replace old products
• Store final released products
• Verify final released product matches preliminary product
• Automate build procedures where possible.

Customer Service Functions include but are not limited to:

• Making copies of production product for various customers.
• Coordinate validation of production copies
• Prepare shipment orders
• Keep list of deliveries
• Service all customers

In-House Functions include but are not limited to:

• Providing input to procedure development
• Develop and follow procedures for day-to-day functions
• Maintain Tools
• Keep CM Data current
• Maintain databases
• Order raw materials for CM productions
• Perform various internal audits
• Provide training to project team for tools
• Maintain CMP