bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-043 - Track Change Request

1. Requirements

3.13.1 The project manager shall require the software supplier to track 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 D software is safety critical, this requirement applies to the safety-critical aspects of the software.

Classes F and G are labeled as "X (not OTS)" which means that the project is required to meet this requirement for all software that is not considered off-the-shelf.

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.


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 the change request section of Topic 7.18 – Documentation Guidance 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.1 041, NPR 7120.5 082, NPR 7120.7 264 (IT and Institutional Infrastructure) and NPR 7120.8  269 (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.

NASA users should 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:

SWE-038

Acquisition Planning

SWE-080

Track and Evaluate Changes

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 relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

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." 523
  • 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." 580
  • No labels