2. Rationale

Tracking and reviewing supplier software changes and non-conformances are useful for a variety of reasons, including evaluation of the source and resolution of those problems and changes.  Requiring a supplier to track and make available records of software changes and non-conformances provides insight into the supplier's processes and allows the acquirer to assess or contribute to the impact assessment of those software changes and non-conformances on the overall project.

3. Guidance

The specific software change and non-conformance information to be provided by the supplier needs to be sufficient for the acquirer to assess the impact on the overall project. The guidance in this Handbook for SWE-080 and SWE-113 is helpful in determining the type of information to require of the software supplier.

Suppliers may capture information in various formats depending on the tools, processes, and procedures they use to track software changes and non-conformances. Negotiate records access and/or delivery format with the software supplier to ensure useful, timely, accurate, and complete information is available for monitoring by the acquirer. Electronic access to the supplier's configuration management system or the non-conformance tracking system allows continuous monitoring of these activities to be able to assess progress.

The method and frequency for providing these records for project review are also included in the contract. Consider the following, non-exhaustive list of options:

• As needed by the acquirer via direct electronic access.
• At or before formal reviews, such as those found in NPR 7123.1A ⁰⁴¹, NPR 7120.5 ⁰⁸², NPR 7120.7 ²⁶⁴ (IT and Institutional Infrastructure) and NPR 7120.8 ²⁶⁹ (Research and Technology).
• At the request of the acquirer.
• At regularly scheduled status, progress, and/or technical meetings.
• At acceptance reviews.
• During acquirer audits of the supplier.

Another item to consider when levying this requirement is that software suppliers typically start formally capturing software changes and non-conformances after the software has been baselined the first time. However, suppliers may delay creating that initial baseline to avoid the overhead of formal tracking which requires formal reviews and approvals before software changes can be implemented. It is recommended that the supplier formally track software changes and non-conformances once formal requirement verification activities have begun.

See 7.03 - Acquisition Guidance in this Handbook for additional guidance.  Additionally, guidance related to supplier requirements and software change tracking may be found in the following related requirements in this Handbook:

4. Small Projects

Projects deemed small due to limited personnel or budgets may maintain a list of software changes and non-conformances in a simple database or spreadsheet rather than using a more costly tool. If this method is chosen, assign a configuration number to each software change or non-conformance to facilitate tracking and discussion of these items within a team.

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

The NASA Lesson Learned database contains the following lessons learned related to software change and non-conformance tracking and evaluation:

• Problem/Failure (P/F) Report Independent Review/Approval. Lesson Number 0790: "The utilization of a P/F reporting system that has an effective independent P/F closure process is a major factor in the elimination of in-flight hardware/software failures attributed to preflight P/F that were not resolved adequately prior to launch." ⁵²³
• COTS Change Processing. Lesson Number 3457: "Change processing/configuration management practices designed for a custom environment are often not appropriate to the management of COTS assets. Specifically, the requirement for more rapid and more frequent configuration changes in a dynamic COTS environment may not be effectively addressed, which could lead to a reduction in the capability, security, and overall value of the COTS products. Examples include the application of routine security patches and vendor updates/upgrades of both software and hardware products." ⁵⁸⁰