5 FAH-5 H-520
LIFE CYCLE MANAGEMENT
(CT:ITS-13; 07-03-2024)
(Office of Origin: DT/BMP/SPB/PMD)
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 baseline—Usually 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 user’s concurrence.
(2) System design baseline—Is 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 user’s concurrence.
(3) Allocated baseline—The 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 baseline—The 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 baseline—The 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 baselines—This 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 baselines—The 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
(CT:ITS-13; 07-03-2024)
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 |
ACTIVITY |
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 |
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 |
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 |
ACTIVITY |
BASELINE |
|
System |
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 |
When this document is completed, it establishes the system’s 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 |
ACTIVITY |
BASELINE |
|
Configuration Management Plan |
This plan should be finalized at this time and submitted to the customer for review. |
|
|
System Interface
|
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 developer’s 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 |
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 |
ACTIVITY
|
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 |
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 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 |