126.96.36.199 The project shall require the software supplier to track all software changes and non-conformances and provide the data for the project's review.
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.
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.
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:
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 Topic 7.3 - 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:
Track and Evaluate Changes
Software Change Request/Problem Report
Software Version Description
Software Test Report
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.
6. Lessons Learned
The NASA Lesson Learned database contains the following lessons learned related to software change and non-conformance tracking and evaluation: