Configuration Management Plan

Configuration Management Plan

(Version 3.0) Touchpoints November 3, 2019

Table of Contents

Revision History - (see this repository's git history)

Executive Summary iii

1 Overview 1 1.1 Purpose 2 1.2 Scope 2 1.3 Program Description 2 1.4 Reference Documents 2 1.5 Glossary 2 2 Configuration Management Roles and Responsibilities 3 2.1 CM Responsibilities 3 3 CM Activities 4 3.1 Configuration Identification 4 3.1.1 Configuration Item Identification 4 3.1.2 Configuration Documentation 5 3.1.3 Product Structure 5 3.1.4 Product Identification 6 3.1.5 Naming Conventions 6 3.1.6 Labeling 6 3.1.7 Classification Requirements 6 3.2 Configuration Baseline Management 6 3.2.1 Functional Baseline 7 3.2.2 Allocated Baseline 7 3.2.3 Developmental Baseline 7 3.2.4 Production/Operational Baseline 8 3.3 Change Control 8 3.3.1 Change Management 8 3.3.2 Communications 9 3.4 Configuration Status Accounting 9 3.5 Configuration Auditing 10 4 Build and Release Management 11 4.1 Libraries 11 4.2 Automated Tools 11 4.3 Version Control 11 4.4 Build Management 11 4.5 Version Description Document 11 5 Reviews 12 6 Configuration Management Measures 13

Revision History Version Number Description Date Version 1.0 Initial Configuration Management Plan

Version 2.0 Updated template

Version 3.0 Updated template to ensure NIST SP 800-53 security controls are addressed.

Executive Summary

[Italicized text is guidance and reference only and should be deleted prior to completing the document. All sections identified in the Table of Contents must remain in the document. Additional subsections may be added as required]. Configuration Management (CM) is a uniform practice for managing changes in software, hardware and documentation throughout the acquisition or development project. The CM plan should be produced as part of the project planning phase of the Solutions Lifecycle (SLC). The CM activities should continue throughout the life of the delivered end-product, and therefore, at the project’s end, the adopted approach should be transferable to the organization responsible for operational maintenance. The executive summary should be an overview of the CM plan, highlighting the major points of each section in the plan.

Overview

Provide a statement that introduces the CM plan and describes, in general terms, its use in managing the configuration of the specific project, or system. Also, briefly discuss the roles and responsibilities of key participants and how CM will be applied. Below are representative paragraphs that can supplement the overview statement(s): CM Concepts – CM is an integral part of acquisition, development and program management for all that constitutes a system: Documentation, Hardware and Software. That is, a system’s configuration represents its functional (performance) and physical (form and fit) characteristics. These characteristics are described in technical documentation, assessed and [dis]approved/verified in technical reviews and configuration audits, and achieved in the delivered and accepted product. The CM processes span all Solutions Lifecycle (SLC) phases and are driven more by program technical and CM events rather than fiscal periodic events. All configuration changes must be controlled to ensure that they are cost effective, necessary, safe, secure, and are properly documented so that all producers, users, and support personnel are aware of their current configuration status. The Program Manager (PM) is responsible for the overall conduct of CM and technical data management for the program and will ensure that the following CM objectives are incorporated in business planning, and program planning, execution and support: Functional and physical characteristics of components designated as configuration items (CIs) and associated work products throughout the Solutions Lifecycle (SLC), must be identified and documented. The product attributes should be defined, product configurations documented and a basis for making configuration changes established via the usage of configuration baselines. Products are labeled and correlated with their associated requirements, design and product information. Changes to CIs and their related technical documentation should be controlled. Proposed configuration changes should be identified and evaluated for impact, including security impact, prior to making change decisions. Configuration change activity should be managed by a formally chartered Change Control Board (CCB) and a defined process for review and approval or disapproval. The PM is typically designated as the CCB Chair, responsible for approval or disapproval of all proposed configuration changes during the acquisition/development and implementation. CCB chair responsibility and authority may be transferred to another activity after the acquisition, development and full deployment completion. Information needed to manage configuration items effectively, including the status of proposed configuration changes and implementation status of approved configuration changes, must be recorded and reported. The configuration information captured during product definition, configuration change management, product build, distribution and deployment, operation and sustainment, and disposal processes shall be organized for retrieval of key information and relationships, as needed. Configuration information should provide continuous traceability and status of all proposed configuration changes from initiation to implementation or rejection. The complex aggregate of configuration items must meet the system specified and operational requirements. Actual product configuration should be verified against the required attributes and configuration documentation through functional and physical configuration audits. Incorporation of configuration changes should be verified and recorded throughout the life cycle. Purpose Describe why this CM plan was created, what it accomplishes, and how it is used. Explain, in simple straightforward terms, the processes required to ensure that the inevitable changes do occur within an identifiable and controlled environment. Mention that the CM plan is intended to be a living document. Consequently, its final version will, itself, be placed under CM control and the respective changes managed accordingly. Scope Define the scope of CM planning. Define the scope of control – Is this a System/Project/Program level artifact? Provide a high description of the types of artifact that will be placed under CM Control, referencing the CI list. Identify the systems that are covered under CM control. Identify the process for adding or removing systems from CM control. Unique system characteristics or unique support concepts that require special CM attention. Program Description Describe the system, its history and the enterprise architecture (EA) under which it operates. Identify interface(s) with other legacy or new systems. List the sites that are using the system. Reference Documents The documents listed below are referenced in this CM plan and provide guidance or additional information. The documents may also include additional standards to be followed for CM processes. Required Documents: Project Management Plan (PMP) Configuration Item List (CI List) Optional Documents: Configuration Management Handbook Change Control Working instructions CCB Charter Glossary Provide definitions for any unique or unusual terms and acronyms that appear in the CM plan. Configuration Management Roles/Responsibilities Provide a list of the specific groups or individuals involved in the program/project’s configuration management activities, and then describe their respective tasks and responsibilities. In some cases, the same individual may perform multiple roles across the organization. Identify the organization where the CM resides and all other organizational units. Define the functional roles of these organizational units within the project. Describe any internal review and/or Change Control Board. For each board discuss membership (and their functional representatives) and the responsibilities of the board and that of each member. CM Responsibilities Table 2-1 identifies the various CM roles and their corresponding responsibilities. Role Responsibility / Task Government Project Manager Participates in and oversees the configuration management process

Contractor Project Manager

Coordinates CM activities in the project schedule as part of regular project management

Project Team

Follows CM Procedures for document management Implements the required solution for changing and updating code Updates change control records as part of the documented processes

CM Lead

Production and Maintenance of the project’s CMP; Management of CM organization (responsibilities, authorities, applicable policies, directives and procedures); Performance of the CM-specific Activities (configuration identification, Change Control, Security, etc.); Handling of the CM Schedules (coordination with other project activities); Management of the CM Resources (tools, physical, and human resources) Maintains change control records as part of the documented processes

Configuration Control Board

Administering the CM process and approval of software and document baselines Approving and disapproving change requests to the approved baseline Prioritizing approved changes for implementation Ensuring that all requested changes are consistent with current GSA guidance and requirements Table 2-1. CM Roles and Responsibilities CM Activities Identify CM activities. Following is a sample listing of CM activities: Configuration Identification; Governance and Management of the CM processes; Change Control; Configuration Status Accounting; Configuration Auditing; Build and Release Management. Configuration Identification Configuration Identification is the basis on which the CIs are defined and verified; CIs and documents are labeled; changes are managed; and accountability is maintained. The sections below define the tools that will be used to track and control the configuration baselines. This section will also describe the methods for controlling, tracking, implementing and reporting changes. Configuration Item Identification A CI is an aggregation of software, hardware, database, documentation, interface, or discrete portion of hardware or software that satisfies an end-user function and that is designed for control by CM. The selection of CIs is closely coupled with the design process and is determined by the need to control an item’s characteristics and its interface with other items. Some of the primary criteria for designating separate CIs include: Independent end use functions Critical, new, or modified design Previously identified as a CI Required tracking to the exact configuration and status of changes to the item Interface with other systems, equipment, software, or Cis Interface with software/hardware developed under another effort Separate definition of functionality, performance and test requirements High risk and critical components Separate delivery or installation requirement The process of selecting CIs requires good systems engineering judgment supported by cost trade-off considerations. There are no fixed rules for selecting or deciding the optimum number of CIs for a particular system. The following identifies some of the problems with identifying too many CIs: Excessive development activities including design and verification demonstrations, system integration and testing, technical reviews and budget allocations; Unnecessary design constraints requiring formal test and technical reviews, beyond what is required to achieve reasonable assurance of the system’s performance and security; Numerous inter-CI interfaces with little functional impact on the overall system; Increased overall number of requirements disproportionate to the overall functionality of the system; Excessive fragmentation of the system which may decrease the visibility and understanding of system performance. On the other hand, having too few CIs introduces another set of problems including: Increased development, maintenance, and installation costs because of the increased complexity; Increased complexity of each CI resulting in decreased insight and ability to monitor progress; Potential reuse of the CI is diminished; Formal testing of critical capabilities are made more difficult or require increased time to complete the tests; Difficulty in addressing the effectiveness of changes. Configuration Item (CI) selection separates system components into identifiable subsets for the purpose of managing further development. It specifies all the components, sub-components, and CIs of an IT system. The most basic function it serves is to identify what comprises the IT system. A CI can be a database, a software module, a specific HW component, an interface, a COTS product, or a system related document. Configuration Documentation As part of Configuration Identification, the project team must define the specific technical documentation that will be part of each baseline. The baseline definition is provided in this plan. The documentation required for each successive baseline may be an independent grouping of design information. In some cases, it may be confined to updates to the previous baseline document. Baseline documentation is maintained and archived in the CM Library (CML). A list of baseline documentation will be maintained to ensure requirements traceability to CIs, baseline specifications, requirements documentation, and acceptance criteria. Documents will be indexed to facilitate retrieval for use, reference, or reproduction. The project classification schema identifies the minimum required documentation for each project size. A partial list of typical documentation includes: CM Plan Quality Assurance Plan Operations Plan System Security Plan Project Management Plan Test Plan Systems Engineering Management Plan Functional Requirements Document Interface Control Document System Software System Design Document Maintenance Manual Operations Manual or Systems Administration Manual. Training Plan User Manual Test Analysis Report Product Structure Product structure, also referred to as system architecture, defines what constitutes the CI. It refers to the identifiers, internal structure, and relationship of CIs and associated documentation. The product structure may be depicted graphically as a tree structure or as an indented list. Product Identification The following principles apply to the identification of CIs: All CIs are assigned unique identifiers so that one CI can be distinguished from other CIs; one version of a CI can be distinguished from another; the source (e.g., software, hardware, database, documentation) of a CI can be determined; correct CI information can be retrieved; and the owning system can be determined; Individual components (e.g., software files, database files, hardware components) of a CI are assigned unique identifiers when there is a need to distinguish one unit of a CI from another unit of a CI. These individual components are connected to the owning CI; When a CI is modified, it retains its original CI identifier even though its part identifying number is altered to reflect a new configuration; A series of like components of a CI is assigned a unique CI group identifier when it is unnecessary or impractical to identify individual units but necessary to correlate units to a process, date, event, or test. The following list identifies the CIs for this <Program/Project> and the corresponding level of Control. Identify the CIs to be controlled and specify a means of identifying changes to the CIs and related baselines. Identify the rules for including items as CI’s. Naming Conventions Provide details of the file naming convention to be used on the project and how file configuration integrity will be maintained. Labeling Describe the procedures and format for labeling all items under CM control, including code, documentation, and physical media. Classification Requirements Describe the rules and documentation standards for classification guidance. Configuration Baseline Management A baseline is a comprehensive set of CIs (products, deliverables) developed during a specific phase of the development process that has been formally accepted. The baseline, usually tracked through a label or version, should incorporate all artifacts at that stage in the Solutions Lifecycle (SLC), to include, documents, code, and plans. Once the baseline is established, changes to the CIs can only be done through a formal change process, as documented in this plan. Baselines may also be established to signify the progress of work through passage of time. In this case, a baseline is a visible stake through an endured collective effort, e.g., a developmental baseline. Define the baselines that will be created, the required artifacts/elements for each baseline and the trigger for the creation. The following sections describe typical baselines in a system’s life cycle. Functional Baseline The functional baseline is established by the system specification or equivalent. It describes a system’s or top level CI’s functional, inter-operability, and interface characteristics and the verification required to demonstrate the system or CI meets these characteristics. The functional baseline is normally established at the end of the system concept development phase. This initial baseline will be developed based upon the functional requirements. After system requirements review, additional information may be added. This baseline is subject to CM control. The functional baseline is established by the system specification or equivalent. It describes a system’s or top level CI’s functional, inter-operability, and interface characteristics and the verification required to demonstrate the system or CI meets these characteristics. The functional baseline is normally established at the end of the system concept development phase. This initial baseline will be developed based upon the functional requirements. After system requirements review, additional information may be added. This baseline is subject to CM control. Allocated Baseline The allocated baseline describes the functional and interface characteristics that are allocated from those of the higher lever CI and the verification required to demonstrate the CI meets these characteristics. The allocated baseline is established when a new development specification is authenticated. Authentication should take place before the preliminary design review. The allocated baseline is normally established at the end of the validation phase or at the beginning of the full-scale development phase. Developmental Baseline The development configuration is the design and associated technical documentation that defines the evolving design solution during development of the CI. The development configuration for a CI consists of internally released technical documentation for hardware and software that is under configuration control. The Developmental Configuration may be subdivided into additional environments as required including Development, Integration Test, and Quality Assurance Test. Production/Operational Baseline The production/operational baseline is the approved technical documentation which describes the configuration of a CI during the production, fielding/deployment and operational support phases of its life cycle. The product baseline for a CI consists of all necessary physical or functional characteristics of a CI; selected functional characteristics for production acceptance testing; and production acceptance test requirements. This section should be updated as more detailed information becomes available during the development and deployment of a new or modified system/equipment. Describe what baselines are to be established. Explain when and how they will be defined and controlled. Change Control Change control is systematic proposal, justification, evaluation, coordination, approval and implementation of changes after the formal establishment of a configuration baseline. The process ensures that all changes are authorized, documented, and coordinated. Here, you can identify any provisions for establishing and maintaining configuration traceability to requirements. Describe the change control process. Reference the governing body that approves changes to the baselines. Change Management The goal of a change management process is to: Predict and recognize changes Evaluate and understand the consequences of implementing the proposed changes Ensure that every propose change is evaluated, reviewed and [dis]approved at the proper authority level Control the consequences of the approved changes Prevent unauthorized and unintended deviations from approved baselines Ensure that every approved change is documented, tested, verified and, then implemented Define the mechanism(s) for initiation (proposal) and the processes for controlling, changes to the system baselines and for tracking the implementation of those changes. Provide a table listing the roles of the CCB the membership and the way it deals with change initiation, application and control. If appropriate, a separate CCB charter may be referenced. If a program is a larger size, there may be a need for additional CCB layers to review and approve changes for individual projects and project phases. For example, the program CCB may be responsible for approving all scheduled work while a project level CCB is only responsible for reviewing and approving development/test cycle issues. For the largest programs, an additional layer may be required to review and prioritize issues that cross organizational boundaries or have cross-cutting impacts. Table 3-1 shows the CCB roles and corresponding responsibilities. Role Responsibility / Task CCB Chair Schedules the CCB meetings in accordance with organizational policy and schedule requirements

CCB Member – Contractor Document all proposed changes, ensuring sufficient information and analysis is available for review and approval Provide technical analysis and review of proposed changes, including security impact analyses

CCB Member – Government (CIO and Business Line Representatives) Attend meetings to review proposed changes Provide advice and approval for documented changes Ensuring that all requested changes are consistent with current GSA guidance and requirements Prioritize approved changes for implementation

CCB Recorder May be any designated team member, responsible for recording and documenting decisions of the CCB meeting; May be authorized to update the SCR repository with the approved changes

CM Manager Ensures that SCR data can be provided consistently to the CCB membership Verifies that the approved changes are properly recorded

Contractor Project Manager Advisory member of the CCB

Government Project Manager Voting member of the CCB

Project Team Advisory members of CCB (as needed) Information System Security Manager/Information System Security Officer (when analysis indicates a change has a security impact) Should include members from all phases of the Solutions Life Cycle (SLC) Updates and retains change control records (SCR) as part of the documented processes Table 3-1. CCB Roles and Responsibilities Communications Document the communication channels and responsibilities. Table 3-2 lists the communication needs, purpose, frequency, and the audience. Pay particular attention to teams and organizations outside of the project/program. Communications Purpose Frequency Audience Communications Mechanism Describe its purpose Weekly / Biweekly / Monthly Project Team, Project Board, Client Report Name Describe its purpose Weekly / Biweekly / Monthly Project Team, Project Board, Client Report Name Describe its purpose Weekly / Biweekly / Monthly Project Team, Project Board, Client Table 3-2. Communications Description Configuration Status Accounting Configuration Status Accounting (CSA) is the process of recording, storing, maintaining, coordinating and reporting the information necessary for the CM performance and the status of its associated CIs. All software and related documentation are tracked from initial development to request for change, through the [dis]approval of changes, to the implementation of changes. Results and decisions of the Change Management process are a key input to a CSA Report (CSAR). Identify what CSA tools will be used and who will maintain them. Whenever possible, automate the CSA process. Configuration Auditing Configuration audits are comparisons of a product’s actual functional and physical characteristics with the characteristics identified in configuration baseline documentation. They verify that the configuration identification for a configured item is accurate, complete, and will meet the specified program needs. There are two types of audits and they both must be satisfactorily completed as a prerequisite to establishing the product baseline: Functional Configuration Audit (FCA) – To be conducted on the first prototype item produced to compare the functional characteristics with the Functional and Allocated baseline information. Physical Configuration Audit (PCA) – To be conducted on the first production representative item to compare the physical characteristics with the Product baseline. Discrepancies between the actual configuration and baseline documentation need to be resolved. Identify the plans and mechanics to accomplish these audits. Describe how the peer reviews and formal audits will be accomplished. These formal audits may include baseline, functional, physical, software and hardware physical configuration, and subcontractor configuration audits. Build and Release Management Dedicated to the release of an executable version of a software product, this CM activity orchestrates the complex assembly, verification and packaging processes that produce the executable. To achieve this, the correct baseline, composed of baseline versions of CIs, is compiled (built) into an executable. Since the executable represents the only true record of what development delivers to customers, build and release management provides the essential link between development output and what is ultimately deployed into production. Once an executable is created, it should be delivered for testing or distribution to the customer. Specific build instructions are needed to guarantee that the build steps are taken and that they are performed in the correct sequence. Sometimes different versions of the same product should be built (for platform, customer, functionality, etc.). Libraries Identify the documentation control parameters (including the responsibility for them), control libraries and media (if applicable) and how the access control is to be managed. Automated Tools Describe any automated case tools used and the processes used for their source control. Version Control Describe the processes for controlling the amount and number of versions documented by this CMP. Build Management Describe the controls in place to manage the building of executable code. Version Description Document The VDD is the primary configuration control document output of the build process. It is used to track and control versions of software being released to testing or to final implementation, The VDD provides a summary of the features and contents for a specific software build or release, and facilitates product implementation, testing, operations and maintenance. The VDD identifies and describes the version of the configuration items (CIs) that comprise the software build or release, including all changes to the CIs since the last VDD was issued, as well as installation and operating information unique to the version described. The VDD applies to any release of a product revision, and includes software, hardware, and firmware. Reviews All baseline operational components (including the support documentation), are subject to a final review (i.e., Users’ Manual, Computer Operations Manual, etc.) for conformance to the initial design. Describe how the technical reviews relate to the establishment of baselines and explain the role of CM in these reviews. Configuration Management Measures Describe the metrics that will be used to measure CM activities. Sample metrics include: Planned vs Actual builds Number of maintenance or emergency releases Number and size of repositories under control Number of approved and unapproved changes by the CCB