Page History
...
| id | tabs-1 |
|---|
1. Requirements
4.1.1 The project shall develop a Software Configuration Management Plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project.
1.1 Notes
The Software Configuration Management Plan may be a part of the project configuration management plan. The content is defined by the requirement in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, Section 5.1.2].
1.2 Applicability Across Classes
Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.
...
| f | 1 |
|---|---|
| g | p |
| h | 0 |
| ansc | 1 |
| asc | 1 |
| bnsc | 1 |
| csc | 1 |
| bsc | 1 |
| esc | 1 |
| cnsc | 1 |
| dnsc | 1 |
| dsc | 1 |
| ensc | 0 |
...
| id | tabs-2 |
|---|
2. Rationale
...
"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)
...
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.
...
| id | tabs-3 |
|---|
3. Guidance
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) 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.
| Panel |
|---|
Both providers and acquirers need to have a SCM plan. The contents of the provider plan are established in the contract. |
The 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 SWE-103 in this Handbook for guidance on required contents, but consider the following topics as well when developing the SCM plan:
...
- Documentation (e.g., specifications, design documents, traceability matrices, presentations, project plans).
- Source code.
- Object code.
- Executables.
- Data.
- 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, UML (Universal Modeling Language) or OOD (Object Oriented Design) products, input to automatic code generators.
- Interface control documents, message formats, data formats
- COTS (Commercial Off the Shelf) software.
- Build procedures.
- Defect lists, change requests, problem reports/corrective actions.
- Metrics.
...
- 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.
...
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 Software Configuration Management Plans (IEEE STD 828-2005), and any Agency or Center-specific templates and guidance material.
Once the SCM plan is created, it is peer reviewed (SWE-137), 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.
| Note |
|---|
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to CM. |
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:
...
...
Track and Evaluate Changes
...
...
Identify Software Configuration Management Items
...
...
Authorizing Changes
...
...
Status Accounting
...
...
Configuration Audits
...
...
Release Management
...
...
Software Configuration Management Plan
| Div | ||
|---|---|---|
| ||
4. Small ProjectsCM activities are based on risk, so projects designated small by size of the team or budget need to ensure that their SCM (Software Configuration Management) plans consider all the required content noted in SWE-103, but only include those processes and the associated structure commensurate with project risk. This might mean planning to use simpler tools or fewer personnel (filling multiple roles) to carry out the SCM processes. It could also mean planning to use a single tool for multiple purposes to reduce tool management and overhead. Note that waivers may be necessary if any required content is left out of the SCM plan. Small projects may not require the formality of a separate SCM plan; instead SCM planning may be documented as a section of the project's Software Management Plan. Alternatively, one master SCM plan may document CM for multiple small projects. |
...
| id | tabs-5 |
|---|
5. Resources
...
| Toolstable |
|---|
...
| id | tabs-6 |
|---|
6. Lessons Learned
The NASA Lessons Learned database contains the following lessons learned related to the importance of configuration management:
...
