Software Configuration Management (SCM) Process and Procedure

What is Configuration Management

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.

Purpose of Configuration Management

The purpose of Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items.

Scope of Configuration Management

This applies to all IT activities and IT assets owned or controlled by you, including those of your agents, contractors or other business partners when acquired or supported by your funding. As such, this process applies to all hardware, software, supporting infrastructure (e.g., equipment, networks, and operating systems), services, and associated documentation regardless of origin, nature, or location (e.g., contractor, in-house, development, operations, all hosting data centers, internal and external systems) unless otherwise specified.

Policy

The purpose of Software Configuration Management (SCM) Policies at your organization is to establish and maintain the integrity of software work products throughout the project’s software life cycle. This involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration through the use of version control and check-in/check-out processes, and maintaining the integrity and traceability of the configuration throughout the software life cycle

Configuration Management Procedure

Configuration Management Planning Process:

CMP is used to identify the configuration of the CIs at any given point of time, systematically control changes to them, and maintain their integrity and traceability throughout the software life cycle. Depending upon the scope of the project, CMP may form a part of the Project Management Plan. This also includes Configuration Control

Entry Criteria:

• Project kick-off meeting conducted.
• Receipt of a change request.

Input

• Project Management Plan Document with some minimal details

Output

• Project Management Plan consisting of the CMP
• CMP includes CM Identification Scheme, CM Labeling Scheme, descriptions

Exit Criteria

• Approval of PMP

Change Control

Change having controls in place to ensure the integrity of the product by controlling changes to and release of approved baseline throughout the life of the product.

Procedure:

• Select, identify, and classify the components/items to be placed under CM control
• Creation of an identification scheme that reflects the software hierarchy (e.g.,
• represents the architecture of the product)
• Identifying and maintaining relationships between components
• Identifying baselines for a product
• Defining a standard labelling scheme for work product and module files
• Mechanism to uniquely identify the various revisions of the work products

Configuration Change Control Process

The purpose of ‘CM Change Control’ process is to ascertain that the changes to configuration items are controlled. It reduces the possibility of making inadvertent changes that may later adversely affect the functionality.

This process will also facilitate communication of the changes requested, to the configuration management team, provide a common process for resolving the changes and reduce the uncertainty about the outcome of a change that has been requested in a work product.

The Configuration Change Control includes the following types of changes to the Project Repository:

• Add/Remove/Edit Configuration Items
• Add/Edit/Remove User and Permissions

Change control process begins with a Configuration change for an approved change request in the project repository. The process ends with a controlled update of the CI’s

Entry Criteria

• Configuration Change request received.

Inputs

• Change request information.

Output

• Updated Configuration Change Log
• Result of configuration audits, collated in a Report, and corrective actions specified. The process and project teams will ensure that these points are tracked to closure.

Exit Criteria

• Change request closed

Software Release Process

The purpose of Software Release process is to ensure releases are done as per the project planned with proper approvals. All the items are released with the proper versions and all the change requests for that releases are implemented.

Entry Criteria

• Completion of Testing and Verification of software work-products to be released.

Input

• Software work-products (Software and Documentation) to be released.
• Software Release Notes

Outputs

• Packaged work-products
• Result of configuration audits, collated in a Report, and corrective actions specified. The process and project teams will ensure that these points are tracked to closure.

Exit Criteria

• Delivery of an approved version of work products

CM Audits and Reviews Process

The goal of Configuration Audit is to verify that all software products have been produced, correctly identified and described, and that change requests have been resolved. Informal audits are conducted at key phases of the software life cycle.

Two types of formal audits need to be conducted before the software is delivered to the customer:

Functional Configuration Audit (FCA) verifies that the software actually satisfies the specified software requirements Physical Configuration Audit (PCA) determines whether or not the design and reference documents represent the software that was built

Entry Criteria

• Completed work products

Input

• Approved CMP Work Products

Outputs

• Reviewed Work Products

Exit Criteria

• Delivery of an verified version of work products.

Output and Exit Criteria

Please refer to Sub process/Activities for Output and Exit Criteria

Metrics of CM Audit

• Time spent on CM planning and reviews
• Number of changes processed
• Number of changes to requirements (types of changes)
• Number of Configuration Items
• Number of PRs/CRs and their status
• Number of Action Items and their status
• Number of hours used to generate the CSAR
• Number of items (e.g., requirements, design component) checked
• Number of defects by product type and by item

The review & verification of Configuration Management is achieved by Configuration Audit. A Configuration Audit verifies that the product is built according to requirements, standards, and/or contractual agreement. Test reports and documentation (such as the Requirements Traceability Matrix) are used to verify that the system, hardware or software meets the stated requirements. The goal of a Configuration Audit is to verify that all work products have been produced, correctly identified and described, and that all change requests have been resolved in accordance with the Configuration Management (CM) Plan. Informal audits are conducted at key phases of the life cycle. There are two types of formal audits that should be conducted before the product is delivered to the customer: Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA). FCA verifies that the system actually satisfies the system requirements and interfaces as stated in the System Requirements Specification. PCA determines whether or not the design and reference documents represent the software/hardware that was built. This procedure combines the FCA and PCA along with a traceability audit into a single procedure.