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

The items to be controlled include tools, items or settings, used to develop the software, which could impact the software. Examples of such items include compiler/assembler versions, makefiles, batch files, and specific environment settings.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

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, establish accurate records and reports, or validate the configuration through the 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 the 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 the 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, such as certifications, licenses, customizations, upgrades, etc.
• Vendor-supplied software.
• Customer-supplied software ( e.g., 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 Software Assurance Plans, Verification, and Validation (V&V) plans, CM plans, Data Management 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., such as hazard analyses and reports, safety analyses, etc.
• Software Classification determination, Safety Criticality Determination
• Other software assurance products such as analyses, reports
• Software Requirements Mapping Matrix with approved tailoring, SA Tasking table with approved tailoring, Tailored Project and SA Processes and procedures

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 item, not part of a larger item).
• Requirements allocation and traceability needs.
• Functionality.
• Item size.
• Host or target computer.
• Criticality.
• Interface considerations.
• The 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, not all configuration items (CIs) may be 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, the 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 the 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 include "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 have 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 the unit test to be tracked as formal changes).
• After passing the 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 a 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 References

5.2 Tools

6. Lessons Learned

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

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

1. Confirm that the project has identified the configuration items and their versions to be controlled.
2. Assess that the software safety-critical items are configuration managed, including hazard reports and safety analysis.

7.2 Software Assurance Products

• Software Design Analysis
• Assessment of Hazard Analyses and Reports
• Source Code Analysis
• Verification Activities Analysis

• SA assessment of CM for safety-critical items, including risks and issues.

• Hazard Analyses (under CM -See Task 2).

  
  

  Objective Evidence

  • Software configuration management plan
  • Software configuration management system data
   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 safety-related non-conformances identified by life-cycle phase over time.

7.4 Guidance

For the assurance on this requirement, the software assurance personnel need to confirm that the project has identified those items that need to be configuration controlled and has reviewed the list for completeness. The software guidance for this requirement (SWE-081) provides a list of the types of items that are typically kept under configuration management that can be used for reference. 

Another important task for this requirement is to assess the list of safety-critical components, and the associated hazard reports, and any safety analysis and check that these safety items are included on the list of configuration items.