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 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 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 criteria to evaluate a CM program. In describing each CM function and its principles, this standard utilizes neutral Configuration Management terminology, while also providing equivalent terms, that have historically been used in various product environments (see Table 2). There is no intent to express preference for any particular set of terminology. Similarly, this standard uses a neutral set of names for the phases of a product’s life cycle, which are generic enough to be easily mapped to the myriad of different life cycle models in use. Table 1 illustrates some of the aliases for each phase name and identifies characteristics that apply in each one.
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.