This Bulletin provides a comprehensive list of Terms and Definitions used in or related to TechAmerica prepared standards/documents. The information in these listings was extracted from standards and documents prepared by the Systems Engineering (G47), Configuration Management (G33), Life Cycle Logistics Supportability and Enterprise Information Management Interoperability Committees along with other pertinent international, industry and government standards. It is intended that this bulletin be used as a resource to help with harmonization of terms and definitions across standards. One should be cognizant of the release date of this Bulletin and understand that updates to the included standards and handbooks after this Bulletin was released may affect its accuracy.
This Bulletin is intended for use as a guide and defines the terms and definitions to be used during the development, documentation, verification, and delivery cycles of new and modified computer software. It lists and defines the most common terms currently used in the world of computer software configuration management. There has been no attempt to compete with some of the more formal documents in use within the software programming community.
The role of CM, within any one company's organization, on the development and production of a product has been established by internal company needs or imposed by customer dictum. (As used hereinafter, in order to reduce any confusion, computer programs, components, software, hardware, firmware, etc., are included in the designation "PRODUCT".) The primary focus of this Bulletin is directed toward the Buyer and Supplier personnel who will be managing hardware products in the production phase and software products in the full-scale development phase. The trend in DoD is toward expanded use of standardized components and subassemblies, using competitive reprocurement. The DoD needs to know the full span of CM requirements which should be included in the production contract and the management tasks that will have to be accomplished.
This Interface Control Plan establishes a program for interface control among the major segments/equipments of a DoD program. This could be an airborne weapon system, Medium Launch Vehicle System, Space Launch Complex System, etc. The program is based on formal agreements between participating organizations, and includes (1) documentation to establish, define and control interface requirements and to detail interface design definition between system segments, (2) interface management under the purview of the Interface Management Boards (IMB) and (3) interface control, through Interface Control Working Groups (ICWGs). The plan establishes the IMB and ICWG policy and procedures. Furthermore, it sets forth the Government Agencies Program Offices, associate contractors and participating Government Agency responsibilities in support of the Interface Control Program and the conduct of interface management/control through the IMBs, and ICWGs.
This guide clearly defines the purpose, goals, and objectives of an IBR. It also describes the attributes of an effective IBR and discusses a baseline review process that will lead to a better understanding of program risks. It provides a common definition and framework for the IBR Process. This process harmonizes, and to the extent possible, unifies the management objectives for all PMs. The IBR Process enables managers to effectively utilize the project Performance Measurement Baseline (PMB) to assess performance, and to better understand inherent risks. The IBR Process should continue throughout the life of a project.
This handbook provides guidance about the use of CM and about CM's interface with other management systems and procedures. The paragraph numbers in this handbook map directly to the paragraph numbers in ANSI/EIA-649. It is applicable to the support of projects throughout all phases of a product's life cycle. Generic CM examples are included which may be tailored, taking into account the complexity and nature of the work and the product. It is applicable to the support of projects throughout all phases of a products life cycle. Generic CM examples are included and may be tailored to suit the complexity and nature of the work and the product. This handbook establishes a common framework for generic product life cycle CM. It addresses tailored implementation based on differences that may exist in organization policies and procedures, in the phase of the product life cycle, in the acquisition method, in the project size and complexity, and in the system requirements and development.
This document applies to hardware and software and provides CM requirements to be placed on contracts after being tailored by the Acquirer. The requirements have been organized by the following five CM functions: a Configuration Planning and Management b Configuration Identification c Configuration Change Management d Configuration Status Accounting e Configuration Verification and Audit
This standard defines five CM functions and their underlying principles. The functions are detailed in Section 5. The principles, highlighted in text boxes, are designed to individually identify the essence of the related CM function and can be used to collectively create a checklist of “best practice” criteria to evaluate a CM program. The CM principles defined in this standard apply equally to internally focused enterprise information, processes, and supporting systems (i.e., Enterprise CM - policy driven, supporting the internal goals needed to achieve an efficient, effective and lean enterprise), as well as to the working relationships supported by the enterprise (i.e., Acquirer/Supplier CM - contracted relationship to support external trusted interaction with suppliers).