1. Requirements

5.1.2 The project manager 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

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Software Configuration Management planning encompasses the practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations for all of the software products, tools, data, and components produced by the project.  

3. Guidance

3.1 Configuration Management

Configuration Management (CM) is important throughout the life cycle of the project.  CM ensures that (1) the identified configuration of items is known throughout the life cycle, 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 life cycle to ensure the control of changes as soon as the project requirements are approved. 

See also SWE-187 - Control of Software Items, SWE-080 - Track and Evaluate Changes, SWE-082 - Authorizing Changes, 

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.

3.2 Configuration Management Plan

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. The 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.

3.3 Content Of Released Version

The project must define processes for configuration management that specify the content of each released version of a computing system item. This is the minimum performance requirement for configuration management, but a project may need to use other aspects of configuration management (e.g., hardware supply chain requirements or administrative procedures) to achieve the performance requirement. The development process should produce a record of each version of its resultant software or data and each hardware component on which each software or data component is installed. The applicant should retain a record of the system configuration for each computing system safety item to demonstrate compliance with the regulatory requirements. Changes to the computing system, especially on safety-critical systems, can have significant impacts on safety. This configuration management and control process should be in force during the entire life cycle of the program, from initiation of development through retirement, and should include control of project documentation, source code, object code, data, development tools, test tools, environments (both hardware and software), and test cases. Configuration management processes should be ready when each component reaches an initial baseline configuration and should be applied from that point forward. (See SWE-085 - Release Management.)

3.4 Who Uses the Configuration Management Plan?

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 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 ²⁷³)

3.5 Developing The Plan

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 5.06 - SCMP - Software Configuration Management Plan 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 (SWE-081 - Identify Software CM Items) including the following:

• • 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, Unified Modeling Language (UML) or Object-Oriented Design (OOD) products, input to automatic code generators.
  • Interface control documents, message formats, and data formats.
  • Commercial Off the Shelf (COTS) software.
  • Build procedures.
  • Defect lists, change requests, problem reports/corrective actions.
  • Metrics.

• 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.), and the 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 (the project has a limited scope, unusual environment, etc.) and obtain agreement from stakeholders.

3.6 Data Management 

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 concerning 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. 

3.7 Completing the CM Plan

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 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures), coordinated with the project customer and other stakeholders, and reviewed at project milestone reviews, such as the System Requirements Review (SRR), and the Software Requirements Review (SwRR), See also Topic 7.10 - Peer Review and Inspections Including Checklists

Mission Definition Review (MDR), etc. (see topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews). The SCM plan needs to be reviewed by Software Assurance to ensure compliance with applicable standards, and procedures, and to ensure the plan is being properly implemented.

3.8 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.9 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

CM activities are based on risk, so projects designated small by the size of the team or budget need to ensure that their Software Configuration Management (SCM) plans to consider all the recommended content noted in 7.18 - Documentation Guidance, but only include those processes and the associated structure commensurate with project risk.  This might mean planning to use simpler tools or using personnel to fill 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. 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.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to the importance of configuration management:

• Software Design for Maintainability (Software maintainability). Lesson Number 0838 ⁵²⁶:  "Configuration management of software is probably the single most important management and maintainability concept utilized in software development. The utilization of coding standards, documentation standards, release standards, common languages, and other methods will provide for good configuration management. A plan should be developed very early in the development cycle for managing the configuration of the software under development, and that plan should be followed rigorously. If configuration management breaks down, the code under development is doomed to be extremely troublesome when released for operations."
• Computer Software/Configuration Control/Verification and Validation (V&V) (Auto-generated code). Lesson Number 1023 ⁵³³:  "The use of the ... auto code generator for ISS software can lead to serious problems if the generated code and ... [tool] itself is not subjected to effective configuration control or the products are not subjected to unit-level V&V. These problems can be exacerbated if the code generated ... is modified by hand."
• Take CM Measures to Control the Renaming and Reuse of Old Command Files (2002) (File naming). Lesson Number 1481 ⁵⁵⁶: "The team renamed a file prepared for a previous mission for use on a current mission without changing the file creation time recorded in the file header. This error caused the new file to be repeatedly recognized as an 'old' file, and required operations personnel for several months to manually specify the correct file. Implement Configuration Management (CM) measures to assure adequate oversight when renaming old command sequence resources for reuse."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Assessment of Software Engineering Compliance w/ NPR 7150.2
• Software assurance assessment of the software configuration management plan, including any issues or corrective actions.
• SA concurrence on configuration plan.
• Audit results and findings on software configuration plan.
• Software assurance configuration management plan.

  
  

  Objective Evidence

  • Software configuration management plan
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• # of software work product Non-Conformances identified by life cycle phase over time
• # of Non-Conformances per audit (including findings from process and compliance audits, process maturity)
• # of Non-Conformances identified in the Software Configuration Management Plan
• Trends of # Open vs. # Closed over time
• # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)
• # of Open vs. Closed Audit Non-Conformances over time
• Trends of # of Non-Conformances from audits over time (Include counts from process and standards audits and work product audits.)
• # of Compliance Audits planned vs. # of Compliance Audits performed

See also Topic 8.18 - SA Suggested Metrics. 

7.4 Guidance

The software will need to do a careful assessment of the configuration management plan to check that the requirements for a software configuration plan in NPR 7150.2 and any specific Center requirements for CM are met. The contents for a configuration management plan are listed in this Handbook under 5.06 - SCMP - Software Configuration Management Plan in 7.18 - Documentation Guidance. The configuration management plan may be a part of the software management/development plan or a stand-alone document. Generally, for larger projects, it will be a stand-alone document.

The guidance listed with the SCMP in this Handbook provides details on what each section of the SCMP should address. This information and the additional information listed in the software guidance in SWE-079 (this requirement) are good references to use for guidance. Verify that all the details listed have been covered in the project CM plan or the SCMP. Check to see that the SCMP plan is in the state of maturity listed in topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews. Early versions of the SCMP should provide enough information so even the early documents that need to be controlled can be handled properly.

A few of the items to look for in the plan are listed below:

Verify that there is a list of configuration items identified in the plan. A list of potential configuration items as well as other topics to be covered in the plan is included in the software guidance in SWE-079. Not all documentation and data items need to be CCB-controlled; some may just be version controlled while others are just “stored”. Those data items that are not CCB-controlled are called Data Management items and the processes for handling those should be documented as well. That information can be in a separate plan or part of the Configuration Management plan.

Verify that a configuration control board (CCB) has been established and the appropriate people are listed as members. A Software Assurance representative should be a member of the CCB (See Requirements Mapping Matrix for applicability) and should have a responsibility to concur or sign off on all changes for CCB-controlled items. The roles of other people who have a responsibility in the CM process should be listed, along with their roles. Many projects have multiple levels of CCBs. Verify that the authority of each CCB is listed, along with the hierarchy of the various groups and a definition of their respective authority/responsibility.

Verify that appropriate tool(s) have been chosen and set up properly to manage all the Configuration Management and Data Management needs of the project, considering the needs of both the documentation and the software. The Configuration Management system setup should provide for managing multiple levels of control, providing authorized access to controlled items, storage, and retrieval of controlled items, and creation of Configuration Management report. Processes should be established for creating baselines and releases, and for requesting, tracking, and controlling changes to products or baselines. 

Configuration management records should include records from configuration audits, such as physical configuration audits, functional configuration audits, or configuration management audits (audits conducted to confirm that configuration management records and configuration items are complete, consistent, and accurate.) The CM plan should list who is responsible for conducting each of these types of audits. In some cases, these audits are done by Software Assurance personnel and in other cases, they are performed by SCM personnel. In either case, SA makes sure the planned audits are performed and then they review these records.

See also SWE-084 - Configuration Audits, 

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: