1. Requirements

2.6.2.1 The project shall require the software supplier to track all software changes and non-conformances and provide the data for the project's review.

1.1 Notes

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

1.2 Applicability Across Classes

Class C not Safety Critical and Class G 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.

Classes C through E and Safety Critical are labeled with "P (Center)+SO." This means that this requirement applies to the safety-critical aspects of the software and 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
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

Any requirements to be performed by a supplier (software provider) will need to be incorporated into the contract because the contract is the binding document for contractor performance and deliverables. Therefore, this NPR 7150.2 requirement needs to be considered during the earliest phases of a project when the Request for Proposals (RFPs), the Statement of Work (SOW), and the contract are being developed.

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.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to requiring the software supplier to track software changes and non-conformances and provide the data for the project's review.

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:

SWE-038
Acquisition Planning
SWE-080
Track and Evaluate Changes
SWE-113
Software Change Request/Problem Report
SWE-116
Software Version Description
SWE-118
Software Test Report
SWE-119
Software Documentation Requirements - Software Inspection, Peer Reviews, Inspections.


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

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