bannerc

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tabsetup
01. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
67. Software Assurance
Div
idtabs-1

1. Requirements

Excerpt

5.5.3 The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, or reused software components. 

1.1 Notes

This includes operating systems, run-time systems, device drivers, code generators, compilers, math libraries, and build and Configuration Management (CM) tools. It should be performed pre-flight, with mandatory code audits for critical defects.

1.2 History

Click here to view the history of this requirement: SWE-203 History

1.3 Applicability Across Classes

 

Applicable c
a1
b1
csc1
c1
d0
dsc1
e0
f0
g0
h0

Div
idtabs-2

2. Rationale

Software components that are used to build the software product (e.g., compilers) or become a part of the software (e.g., Operating Systems) can introduce unexpected defects in the delivered product.  Whenever non-conformances in these products are discovered, a thorough assessment is required to identify any other potential impacts.    

Div
idtabs-3

3. Guidance

Non-conformances discovered in COTS, GOTS, MOTS, OSS, and reused software components are particularly difficult to diagnose.  Determining the risk to the overall system, due to errors in these acquired software components is challenging.  Most COTS, OSS, and some GOTS, MOTS, and reused software components share lists of known defects and non-conformances.  The intent of the requirement is for the user of the software to verify if a site or list of non-conformances or reported bugs is maintained by the developing organization and to review the list of known non-conformances or report bugs to see if the non-conformances or reported bugs could or do impact the software component.  Most commercial products and open-source software have a site that shows a list of well know bugs or non-conformances. The requirement is to research the information and see if any of the known bugs impact the software component being used by the project. Thorough assessments, including qualified software and systems engineers, of all reported non-conformances in these products, is essential for Project Managers.  Additionally, non-conformances in these products should be reported back to the supplier for analysis and potential corrections in future versions.

Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects.

Div
idtabs-5

5. Resources

5.1 References

refstable
Show If
groupconfluence-users
Panel
titleColorred
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted


SWEREFs NOT called out in text but listed as germane: none

SWEREFs called out in text: none

5.2 Tools

Include Page
Tools Table Statement
Tools Table Statement

Div
idtabs-6

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

Div
idtabs-7

7. Software Assurance

Excerpt Include
SWE-203 - Mandatory Assessments for Non-Conformances
SWE-203 - Mandatory Assessments for Non-Conformances

7.1 Tasking for Software Assurance

  1. Confirm the evaluations of reported non-conformances for all COTS, GOTS, MOTS, OSS, or reused software components are occurring throughout the project life-cycle.

  2. Assess the impact of non-conformances on the safety, quality, and reliability of the project software.

7.2 Software Assurance Products

  • Software Design Analysis
  • Source Code Analysis
  • Verification Activities Analysis
  • Evidence that confirmation of Task 1 has occurred.
  • SA impact assessment of non-conformances on software quality (safety, quality, reliability.)


    Note
    titleObjective Evidence
    • Evidence that confirmation of Task 1 has occurred.
    Expand
    titleDefinition of objective evidence

    Include Page
    Definition of Objective Evidence
    Definition of Objective Evidence

7.3 Metrics

  • Total # of Non-Conformances over time (Open, Closed, # of days Open, and Severity of Open)
  • # of Non-Conformances in current reporting period (Open, Closed, Severity)
  • # of Non-Conformances identified in source code products used (Open, Closed)
  • # of safety-related Non-Conformances
  • # of Non-Conformances identified in embedded COTS, GOT, MOTS, OSS, or reused components in ground or flight software vs. # of Non-Conformances successfully closed


7.4 Guidance

Software Assurance will verify that the project is actually receiving the report of non-conformances for all of the COTS, GOTS, MOTS, OSS, or reused software that is being used by the project. Check that these reported non-conformances reports are being received on a periodic basis and that the project is reviewing them to see if there are any impacts to their project. If fixes to any of the COTS, GOTS, MOTS, OSS, or reused software that might impact the project, the project should be implementing these changes. Verify that any necessary changes are recorded in the project discrepancy database and track these entries to closure.

Review the lists of COTS, GOTS, MOTS, OSS, or reused software non-conformances and determine whether there might be any impacts on the software’s safety, quality, or reliability. If the non-conformance is in an area of safety-critical software, review the associated hazard analysis to determine the impact of the non-conformance. In non-safety critical areas of the code, assess what impact the non-conformance would have—Would it cause an incorrect value to be computed? Or prevent critical functionality from working properly? Or severely impact performance? Or is it something like spelling on a display? Reviewing the functionality of the code in the area of the non-conformance, thinking through the operational scenarios, or looking at redundancy for the code area can help in determining the impacts of the non-conformance. If the source code is available, it may also be helpful to run code analyzers to see if the known problems are discovered and how the analyzer classifies the non-conformances. If there are non-trivial impacts, verify that these non-conformances have been added to the project discrepancy database and track them to closure.