Configuration Management (CM) is important throughout the lifecycle of the project. CM ensures that (1) the identified configuration of items are known throughout the lifecycle; and (2) changes to the configuration of evolving items are correct, controlled, managed, and documented in the Software Configuration Management (SCM) Plan. This plan defines the configuration management policies and procedures required for the project. SCM plan is developed early in the lifecycle to ensure the control of changes as soon as the project requirements are approved.
Configuration Management is a technical and management process applying appropriate resources, processes, and tools to establish and maintain consistency between the product requirements, the product, and associated product configuration information. The SCM plan describes the software configuration management for the project, including functions, responsibilities, and implementation authority. This plan may be part of the software development plan (SDP) / software management plan (SMP), project configuration management plan, or it may be a standalone document. If the plan is a standalone document, part of its content needs to describe the SCM plan’s relationship to other project plans, especially if configuration management activities are referenced or described in those plans.
Both providers and acquirers need to have a SCM plan. The contents of the provider plan are established in the contract.
NASA-GB-8719.13, NASA Software Safety Guidebook, describes the software configuration management (SCM) plan in this manner: "All software products, which includes far more than just code, must be configuration managed. Old files in a software build are a notorious problem, as are lost updates and other problems with changed files. The plan specifies what will be under configuration management (CM), what CM system will be used, and the process for moving an item into or out of the CM system."
Given that CM occurs throughout the project life cycle and is critical to controlling and tracking all elements of the project, having a plan in place ensures that the team is informed of and performs all necessary and required configuration management tasks. Development of the SCM plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned configuration management activities for the project.
"The discipline of CM (configuration management) is vital to the success of any software effort. CM is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life-cycle of the program for information that is shared by more than one individual or organization." (NASA-GB-8719.13, NASA Software Safety Guidebook)
The SCM plan has both internal and external uses. Internally, it is used within the project to guide, monitor, and measure the overall CM process. It describes both the CM activities planned for future acquisition phases and the schedule for implementing those activities. Externally, the SCM plan is used to communicate the CM process to the contractors involved in the program. It establishes consistent CM processes and working relationships. (NASA Systems Engineering Handbook )
The Software Configuration Management (SCM) plan primarily provides a formal method for managing change, but other activities are key to the overall process and are also appropriate to describe in the plan. See the SCMP section of topic 7.18 - Documentation Guidance in this Handbook for guidance on recommended contents, but consider the following topics as well when developing the SCM plan:
- Configuration Management (CM) of deliverable and non-deliverable software development products including the following:
- Documentation (e.g., specifications, design documents, traceability matrices, presentations, project plans).
- Source code.
- Object code.
- Development and test tools (operating systems, compilers, etc.).
- Development and test environments (both hardware and software).
- Testing software (e.g., test cases/scenarios, scripts (manual and automated), reports).
- Flow charts, Unified Modeling Language (UML) or Object Oriented Design (OOD) products, input to automatic code generators.
- Interface control documents, message formats, data formats
- Commercial Off the Shelf (COTS) software.
- Build procedures.
- Defect lists, change requests, problem reports/corrective actions.
- CM of software assurance records.
- CM of safety-critical software requirements and software elements.
- CM of simulators, models, test suites, etc.
- Management of releases.
- CM of routine software configuration changes, such as mission-specific database changes.
- Assessment of changes for their impact on system safety.
- Metrics to be collected from the CM system, such as lines of code, complexity, estimated and actual time for various activities (development, testing, bug fixes, etc.), number of defects.
- Determinations that can be made from configuration metrics, such as defects per lines of code for a team, goodness of effort estimations, need for more time in unit testing, estimates for future updates/maintenance activities, etc.
- Processes for handling classified information and sensitive but unclassified (SBU) information, including export controlled and proprietary information, as applicable.
When writing the SCM plan, consider the following tailoring suggestions:
- Reflect the current project environment by using terms familiar to the planned users and maintaining consistency with project development processes.
- When tailoring leads to the addition of SCM requirements for a particular project (beyond the minimum specified in a template, standard, etc.), conduct a cost-benefit analysis and obtain agreement from stakeholders.
- When tailoring leads to the removal of SCM requirements for a particular project (from the minimum set specified in a template, standard, etc.), include the rationale for the removal (project has limited scope, unusual environment, etc.) and obtain agreement from stakeholders.
When developing the SCM plan, also consider data management activities. Data management (DM) can be defined as the disciplined processes and systems that plan for, acquire, and provide stewardship for product and product-related data, throughout the product and data life cycles. DM processes ensure that data needed by programs and projects (e.g., for milestones, reviews, mission operations, and anomalies or investigations, decisions, and outcomes) are identified, managed and provide traceability of data used in decision making. The biggest distinction between CM and DM is with respect to project work products: CM addresses selected controlled project work products and defines (1) what to configuration manage, (2) how to configuration manage those products, and (3) when configuration management begins/ends. DM addresses all project work products and defines the level of management where the product is controlled. In some cases, the storage location for products is also defined in the DM plan. Even though CM activities are the primary focus of the CM Plan, DM activities could also be defined there so that project work products are maintained and managed to ensure their safety and integrity. If DM activities are not included in the CM plan, they may be described in a separate DM plan.
The SCM plan may also be tailored by software classification. Goddard Space Flight Center (GSFC)'s Requirements for Minimum Contents of Software Documents, available to NASA users in SPAN, provides one suggestion for tailoring an SCM plan based on the required contents and the classification of the software being developed.
Development of the SCM plan, typically by engineering, begins during project formulation. Inputs to developing the project-level plan include the program CM plan, the IEEE Standard for Configuration Management in Systems and Software Engineering (IEEE STD 828-2012) , and any Agency or Center-specific templates and guidance material.
Once the SCM plan is created, it is peer reviewed (SWE-087), coordinated with the project customer and other stakeholders, and reviewed at project milestone reviews, such as the System Requirements Review (SRR), Software Requirements Review (SwRR),
Mission Definition Review (MDR), etc. (see topic 7.8 - Maturity of Life-Cycle Products at Milestone Reviews). The SCM plan needs to be reviewed by software assurance to ensure compliance with applicable standards, procedures, and to ensure the plan is being properly implemented.
NASA-specific configuration management planning information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
Additional guidance related to CM and topics that have to be addressed in the SCM plan may be found in the following related requirements in this Handbook: