UNCLASSIFIED (U)

5 FAH-5 H-520

LIFE CYCLE MANAGEMENT

(CT:ITS-7; 03-09-2017)
(Office of Origin: IRM/BMP/SPO/PM)

5 FAH-5 H-521 CONFIGURATION MANAGEMENT REQUIREMENTS

(TL:ITS-1; 02-13-2002)

Configuration management (CM) is a function deployed throughout all phases of the life cycle. At each phase, the configuration management team controls products and monitors change to these products. In general, the Department of State products progress through the listed phases are:

(1) Project initiation and/or planning, requirements analysis, design;

(2) Preliminary and detailed, implementation;

(3) Construction and/or development, installation; and

(4) Release and/or delivery and operations and maintenance support.

5 FAH-5 H-522 BASELINES

(CT:ITS-7; 03-09-2017)

a. At the initiation of a project, anticipated life-cycle deliverables will identified and scheduled as shown in 5 FAH-5 Exhibit H-522 Configuration Management Life Cycle Management. These deliverables become the configuration items (CIs) which constitute the system baseline as it evolves through the development process.

b. There are four categories of items that should be considered for placement under CM control:

(1) Documentation;

(2) Software;

(3) Hardware; and

(4) Data.

NOTE: CM, with QA concurrence and project manager, will determine which categories are appropriate for a project. Documentation includes all plans, specifications, manuals, and reports associated with the project. Software includes all system software, which operates in the hardware to accomplish the system requirements. Hardware includes all data processing, office automation, and telecommunications equipment utilized to support system requirements. Data includes all data structures (such as database items) and definitions which are utilized to fulfill system requirements.

c. A baseline is a specification or product that has been formerly reviewed and agreed upon, and serves as a basis for further development, which can be changed only through change management procedures. Baselines can be defined at various parts of the development lifecycle. Approval of this CR must be granted before CM will accept any changes to any configuration item.

d. Baselines establish a common point of reference for system development within the project and with the user. Each baseline should have an internal agreement from the project manager, the project staff, and the review, concurrence, or approval from the user. For MSP projects, the following types of baselines will be kept:

(1) Functional baselineUsually called the system requirements baseline, the functional baseline is the main technical product of the system requirements definition effort. After making the changes needed to resolve problems found during the SRR, this baseline is formally established upon receipt of the project manager and the users concurrence.

(2) System design baselineIs a system-level design document. It is the main technical product of a system design effort and is normally evaluated at a system design review (SDR). After making the changes needed to resolve problems found during the SDR, this baseline is formally established upon receipt of the project manager and the users concurrence.

(3) Allocated baselineThe first configuration item level baseline of the system development life cycle. It is the main technical product of a configuration item requirement definition effort. One allocated baseline normally exists for each configuration item in the system. Refer to 5 FAH-5 H-532, Configuration Identification (CI), for more details. An allocated baseline is formally established after receipt by the project manager and user approval of the changes needed to resolve problems found during the applicable review (i.e., SSR).

(4) Developmental baselineThe second configuration item level baseline in the system development life cycle. It is the main technical product of a configuration item design effort. One development baseline exists for each configuration item being developed. The initial version a development baseline is evaluated at a preliminary design review (PDR).

(5) Product baselineThe third and final configuration item level baseline of the system development life cycle. A product baseline exists for each configuration item. One of the major elements of this baseline is the configuration item development baseline, updated to reflect the as-built configuration item product. A second major element of a product baseline is embodied in a set of approved software requirements specifications (SRS) and is formally established after the successful completion of the configuration audit.

(6) Operational baselinesThis is the final system-level baseline. It consists of technical documentation describing the operational system and its characteristics. It contains the current functional baseline, the allocated and product baselines for the configuration items comprising the system and other system-level technical documentation generated during the system development life cycle. This baseline may be evaluated during a configuration audit.

(7) COTS and GOTS baselinesThe policy for base lining a commercial-off-the-shelf (COTS) or a Government-off-the-shelf (GOTS) baseline requires that the baseline CIs retained are a copy of the product, its documentation, its version, and which development product requires it as an integral part of its system requirements.

5 FAH-5 H-523 ACTIVITIES AND MILESTONES

5 FAH-5 H-523.1 Study Period

(TL:ITS-1; 02-13-2002)

a. For the study period, CM will be involved to the extent that products created during this period will be placed under CM control once they have obtained QA signoff. During the study period, the acquirer should place under CM the configuration management plan, procedures to carry out sections of the plan, and the system level requirements passed to the provider.

b. The major planning activities and procedures performed during the study period include, but are not limited to those listed in 5 FAH-5 Table H-523.1 Configuration Management Planning Activities. The primary purpose of the study period is to develop, maintain, and implement a configuration management plan, and, at each period, deliverables are placed under configuration control.

5 FAH-5 Table H-523.1
Configuration Management Planning Activities

PURPOSE (Study Period)	ACTIVITY (Project Initiation)	BASELINE
Configuration Management Plan (CMP)	The first step in managing a collection of items is to plan the activities that should be done. This is expressed in written form in a configuration management plan. This plan must be augmented throughout the life cycle. See 5 FAH-5 H-515 for more information on the configuration management plan. See 5 FAH-5 Exhibit H-515 Model Configuration Management Plan (Sample).	Functional
System Requirements Review (SRR)	The SRR is a handshake between customer and developer to signify that: Each side knows what the other plans to do and is in agreement; Important questions or issues have been raised and resolved; Scheduled requirements are realistic; and Documentation requirements are understood and fully budgeted and control procedures have been prepared by CM.
System Design Review (SDR)	The SDR occurs when the contractual or customer specification, such as the system specification, has been modified to meet current contract requirements and the customer desires that were brought out during the SRR have been accommodated. This review and acceptance of the system requirements establishes the functional baseline.
PURPOSE (Study Period)	ACTIVITY (Requirements Analysis)	BASELINE
System Specification Review (SSR)	Configuration item identification begins during this phase and applies to developed software, hardware and documentation. CIs are defined at this time by technical, system engineering, and project management personnel based on system requirements and on the amount of control needed to develop system elements as separate entities.	Allocated
Initial Test Plan	An initial test plan for each configuration item is required. CM will place these items under control.
System Requirement Review (SRR)	When this document is completed, it establishes the systems allocated baseline. What this means is that the systems functions have been allocated to one or more configuration items and the requirement for each function has been described, and their accuracy and trustworthiness have been agreed to. The allocated baseline for the final system will not be established until all the configuration item documents have been reviewed and accepted and/or authenticated. If this turns out to be a lengthy process, work can still progress for those documents that have been accepted, and the preliminary design phase can begin.
PURPOSE (Study Period)	ACTIVITY (Preliminary Design Phase)	BASELINE
Configuration Management Plan	This plan should be finalized at this time and submitted to the customer for review.
System Requirements Specification (SRS) Interface Requirements Specification (IRS)	This is the design of the software and/or hardware will be described to satisfy the requirements of the specified SRS and the interface requirements specification (IRS). This activity enables CM to maintain configuration control of the approved documentation and code produced between the allocated baseline and the product baseline. The customer is not involved in the change review and approval activity during the developmental configuration but should have the right to review the status and integrity of the elements under control.	Developmental
Preliminary Design Review (PDR)	This activity enables CM to maintain configuration control of the approved documentation and code produced between the allocated baseline point and the product baseline. The customer is not involved in the change review and approval activity during developmental configuration but should have the right to review the status and integrity of the elements under the developers control.

5 FAH-5 H-523.2 Acquisition Period

(TL:ITS-1; 02-13-2002)

a. For this period, CM will be involved to the extent that products created during this period will be placed under CM control. During the acquisition period, the acquirer should place under CM the management plan, procedures to carry out sections of the plan, and the system level requirements passed to the provider.

b. The major planning activities and procedures performed during the acquisition period include, but are not limited to those listed in 5 FAH-5 Table H-523.2. This table lists the major planning activities and procedures during the acquisition period.

5 FAH-5 Table H-523.2
Configuration Management Planning Activities

PURPOSE (Acquisition)	ACTIVITY (Detailed Design Phase)	BASELINE
Preliminary Design Specification (PDS)	Progress to the detailed design phase is by using a copy of the PDS.	Developmental
Configuration Audit	An in-process configuration audit should be held at this time to verify the consistency of the design as it evolves through the development process. See 5 FAH-5 H-535 Configuration Audit.

5 FAH-5 H-523.3 Operations and Maintenance Period

(TL:ITS-1; 02-13-2002)

a. For this period, CM will be involved to the extent that the procedures and records established during the acquisition period are carried forward to ensure integrity of software/hardware/documentation until phase out.

b. Activities during the study period include, but are not limited to the following: 5 FAH-5 Table H-523.3 lists the major planning activities and procedures during the operations & maintenance period.

5 FAH-5 Table H-523.3
Operating and Maintenance Period

PURPOSE (Operations and Maintenance Period)	ACTIVITY (Implementation )	BASELINE
System Testing	The CM process continues into the operational environment. The procedures and records established during the developmental period are carried forward by the designated support activity to ensure the integrity of such software and/or hardware until phased out of its assigned environment.	Operational
Physical Configuration Audit (PCA)	The objective of the PCA is to provide an independent evaluation of the system configuration items to confirm that each item that makes up the as built system maps to its specifications. This audit is held to verify that the products are internally consistent and ready for delivery to the customer or end user.

5 FAH-5 H-524 THROUGH H-529 UNASSIGNED

 

5 FAH-1 Exhibit H-522
Configuration Management Life Cycle Management

(TL:ITS-1; 02-13-2002)

 

MSP/PERIOD	TRADITIONAL SYSTEM LIFE CYCLE PHASE	PRODUCTS
Study	Project Initiation	CM plan and/or Standards
	Requirements Analysis	Functional Requirements Acceptance Criteria Programming and/or Screen Standards
	Preliminary Design	Systems and/or Subsystem Specification System and/or Subsystem Specification QA Report
Acquisition	Detailed Design	Data Specification Data Specification QA Report Program Specification Program Specification QA Report System Test Plan System test plan QA Report Conversion Plan Conversion Plan QA Report Acceptance and/or Regression test Plan Training Plan Training Plan QA Report Contingency Planning Component Document Contingency Planning Component QA Report Installation Plan Installation Plan QA Report
Operations and Maintenance	Implementation	User proposes any changes

 

UNCLASSIFIED (U)