1. Requirements

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

1.1 Notes

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

1.2 Applicability Across Classes

Classes G and H are 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.

2. Rationale

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

"The purpose of configuration identification is to incrementally establish and maintain a definitive basis for control, status accounting, and verification for a [configuration item (CI)] throughout its life cycle." ²⁷⁵

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

3. Guidance

Configuration identification can be thought of as consisting of four elements as noted in the STEP (SMA (Safety and Mission Assurance) Technical Excellence Program) Level 2 Software Configuration Management and Data Management course taught by the Westfall Team ³⁴³:

• 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).

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 ( COTS (Commercial Off the Shelf) / GOTS (Government Off the Shelf) / MOTS (Modified Off the Shelf)).
• Marketing materials, such as release notes.
• Databases.
• Training materials.
• Executables.
• Documents, such as quality assurance plans, V&V (Verification and Validation) 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, e.g., 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 vs. 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 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.

The following diagram from IEEE STD 828-2005, IEEE Standard for Software Configuration Management Plans ²¹⁶, shows a sample process overview for identifying CIs:

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. The community of practice is encouraged to submit guidance candidates for this paragraph.

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." ⁵⁰⁶