1. Requirements

5.1.4 The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project.

1.1 Notes

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

1.2 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

In order for Software Configuration Management to be implemented on a project, the project has to identify what software configuration items are to be controlled for the project. Software Configuration Management 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

Per the Department of Defense Configuration Management Guidance Handbook  ³⁵¹, MIL-HDBK-61, "Effective configuration identification is a pre-requisite for the other configuration management activities (configuration control, status accounting, audit), which all use the products of configuration identification. If CIs and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items' configuration, to establish accurate records and reports, or to validate the configuration through audit. Inaccurate or incomplete configuration documentation may result in defective products, schedule delays, and higher maintenance costs after delivery."

One of the main functions of configuration management (CM) is version control, which facilitates identification of all releases.

Configuration identification can be thought of as consisting of four elements. Identifying the items to be controlled.

• Providing unique identifiers for each item.
• Capturing key characteristics of each item.
• Defining the acquisition point for each item (the point in the project where the item first enters configuration control).

The project is responsible for assuring that software safety elements are properly identified and controlled.

When considering items to be controlled, include the following:

• Source code.
• Data that is part of the delivered product.
• Internal software work products and data, such as requirements, interface documents, test data, build scripts, test documents, test scripts, etc.
• Support tools, such as compilers, linkers, build tools, operating systems, documentation tools, test tools, CM tools, templates, modeling tools, simulators, etc.
• Support tool documentation and certifications, licenses, customizations, upgrades, etc.
• Vendor-supplied software.
• Customer-supplied software ( Commercial Off the Shelf (COTS) / Government Off the Shelf (GOTS) / Modified Off the Shelf (MOTS)).
• Marketing materials, such as release notes.
• Databases.
• Training materials.
• Executables.
• Documents, such as quality assurance plans, Verification and Validation (V&V) plans, CM plans, software development/management plans (SDP/SMP), standards, etc.
• Baselines and the identification of all items included in each baseline (see key characteristics discussion below).
• All software safety elements.

When determining the items to be controlled, a second consideration is the granularity of the items, i.e., is it appropriate to simply control the entire document or should each chapter be controlled separately? However, tradeoffs may need to occur since controlling each page of a document likely doesn't provide a lot of benefit versus the overhead required to manage the pages as separate items. Granularity considerations include:

• Frequency of change for the item (i.e., the work breakdown structure (WBS) will likely change more frequently than the SDP/SMP which contains it and so is appropriate to control as a separate item).
• Software architecture structure.
• Plans for reuse (reused items need to be their own item, not part of a larger item).
• Requirements allocation and traceability needs.
• Functionality.
• Item size.
• Host or target computer.
• Criticality.
• Interface considerations.
• Specific need for separate documentation and control.
• Author assignments.
• Supplier.
• Need for change visibility.

When identifying items to be controlled, also consider this activity as part of data management activities.  A basic description of data management is provided in SWE-079.

When establishing the process for generating identifiers, keep in mind that some tools include versioning features and just adding the item to the tool will generate an identifier. However, it is possible that not all configuration items (CIs) are entered into the tool, e.g. physical items, such as hardware or software CDs or DVDs. Also, if a project already has a system for identifying CIs, software can simply be added to that system and the existing identification scheme used. When creating a new identification scheme, consider the following:

• Unique identifiers for each version of each item.
• Matching the identifier to the level where the item is controlled.
• Use data such as the following:

• Revision, version, release number.
• Document name or identifier.
• Module, data name or identifier.
• Baseline identifier.

When capturing key characteristics for each item (including related elements used to describe, define, create, etc. the item), consider the following as appropriate for a particular project:

• Allocated requirements.
• Associated design.
• Associated test cases.
• Associated user documents.
• For baselines, the items and their unique versions that make up the baseline as well as any procedures used to create it.
• Performance, functional, interface and physical attributes, typically for a subsystem or system.
• Information required to assemble the next higher level of the software, e.g., all the modules in a subsystem, subsystems in a system, components in a computer software configuration item (CSCI), chapters in a document, etc.
• Owner of a CI, i.e., who has authority to approve changes to the item, such as a change control board (CCB).

When defining the acquisition point for each item or class of items, it is important to also define acceptance criteria for the item or class of items. Acceptance criteria may be based on risk or other project factors and includes "all issues fixed," "all action items closed," or "signoff." The CI is acquired for control at the acquisition point and if the acceptance criteria are met, e.g., acquire the requirements document after the Software Requirements Review (SwRR) and the document has been signed off.

When defining CI acquisition points, consider the following choices for setting the acquisition point for software:

• Before peer review (might allow all changes after a clean compile to be tracked as formal changes).
• After peer review and approval (could allow all changes made during unit test to be tracked as formal changes).
• After passing unit test (could allow all changes made during integration and system test to be tracked as formal changes).
• When the product is shipped to the field (allows issues found in the field to be tracked formally - this point is likely too late in the life cycle for large projects).

Other acquisition points to consider include:

• For software, after completion of a defined set of components.
• For software, after a baseline is reached.
• For documents after formal review or signoff may be early enough so the captured document is stable, but late enough to provide flexibility to the author.
• For test cases, after peer review vs. Test Readiness Review (TRR).
• For plans, after peer review vs. after formal signoff.
• For design, after formal review.

NASA-specific configuration management 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 identifying software CM items may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

• Galileo Spacecraft Safing Recovery Anomalies. Lesson Number 0391: Issues caused by not keeping software/documentation current: "The Galileo mission twice experienced difficulties with recovery from safing errors due to a lack of a formal safing recovery plan and to software/documentation that had not been kept current on spacecraft states. Maintain and update an anomaly recovery plan, log spacecraft event updates, take care in reusing previously successful command packages, and identify nonstandard ground system configurations." ⁵⁰⁶