1. NASA-STD-8739.8B Title Material| Approved: TBD | Measurement System Identification: Not Measurement Sensitive | NASA TECHNICAL STANDARD National Aeronautics and Space Administration | NASA-STD-8739.8B Approved: TBD
Superseding NASA-STD-8739.8A | SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
APPROVED FOR PUBLIC RELEASE – DISTRIBUTION IS UNLIMITED |
|
DOCUMENT HISTORY LOG
| Status | Document Revision | Approval Date | Description |
|---|
| Baseline | Initial | 2004-07-28 | Initial Release |
| 1 | 2005-05-05 | Administrative changes to the Preface; Paragraphs 1.1, 1.4, 1.5, 2.1.1, 2.2.2, 3, 5.1.2.3, 5.4.1.1; 5.6.2, 5.8.1.2, 6.7.1.a, 7.3.2, 7.3.3, 7.5, 7.5.1; Table 1; Appendix A; Appendix C to reflect NASA Transformation changes, reflect the release of NASA Procedural Requirements (NPR) 7150.2, NASA Software Engineering Requirements and to make minor editorial changes. Note: Some paragraphs have changed pages as a result of these changes. Only pages where content has changed are identified by change indications. |
| A | 2020-06-10 | The revised document addresses the following significant issues: combined the NASA Software Assurance Standard (NASA-STD-8739.8) with the NASA Software Safety Standard (NASA-STD-8719.13), reduction of requirements, bring into alignment with updates to NPR 7150.2, added a section on IV&V requirements to perform IV&V, and moved guidance text to an Electronic Handbook. This change combines the updates to NASA-STD-8739.8 and the content of NASA-STD-8719.13. The update includes the NASA software safety requirements and cancels NASA-STD-8719.13 standard. |
| B | TBD | Brings into alignment with the update to NPR 7150.2D. Update the Appendix A table containing the additional areas to consider when identifying software causes in Hazard Analysis. |
ForwardThis NASA Technical Standard is published by the National Aeronautics and Space Administration (NASA) to provide uniform engineering and technical requirements for processes, procedures, practices, and methods that have been endorsed as standard for NASA facilities, programs, and projects, including requirements for selection, application, and design criteria of an item.
This standard was developed by the NASA Office of Safety and Mission Assurance (OSMA). Requests for information, corrections, or additions to this standard should be submitted to the OSMA by email to Agency-SMA-Policy-Feedback@mail.nasa.gov or via the “Email Feedback” link at https://standards.nasa.gov. Russ Deloach NASA Chief, Safety and Mission Assurance | TBD Approval Date |
|
Software Assurance and Software Safety Requirements Mapping Matrix| NPR 7150.2 Section | SWE # | NPR 7150.2 Requirement | Software Assurance and Software Safety Tasks |
|---|
| 3 |
| Software Management Requirements |
| | 3.1 |
| Software Life-Cycle Planning |
| | 3.1.2 | 033 | | | | 3.1.3 | 013 | | | | 3.1.4 | 024 | | | | 3.1.5 | 034 | | | | 3.1.6 | 036 | | | | 3.1.7 | 037 | | | | 3.1.8 | 039 | | | | 3.1.9 | 040 | | | | 3.1.10 | 042 | | | | 3.1.11 | 139 | | | | 3.1.12 | 121 | | | | 3.1.13 | 125 | | | | 3.1.14 | 027 | | | | 3.2 |
| Software Cost Estimation |
| | 3.2.1 | 015 | | | | 3.2.2 | 151 | | | | 3.2.3 | 174 | | | | 3.3 |
| Software Schedules |
| | 3.3.1 | 016 | | | | 3.3.2 | 018 | | | | 3.3.3 | 046 | | | | 3.4 |
| Software Training | | | 3.4.1 | 017 | | | | 3.5 |
| Software Classification Assessments |
| | 3.5.1 | 020 | | | | 3.5.2 | 176 | | | | 3.6 |
| Software Assurance and Software
Independent Verification & Validation |
| | 3.6.1 | 022 | | | | 3.6.2 | 141 | | | | 3.6.3 | 131 | | | | 3.6.4 | 178 | | | | 3.6.5 | 179 | | | | 3.7 |
| Safety-Critical and Mission Critical Software |
| | 3.7.1 | 205 | | | | 3.7.2 | 023 | | | | 3.7.3 | 134 | | | | 3.7.4 | 219 | | | | 3.7.5 | 220 | | | | 3.8 |
| Automatic Generation of Software Source Code |
| | 3.8.1 | 146 | | | | 3.8.2 | 206 | | | | 3.9 |
| Software Development Processes and Practices |
| | 3.9.2 | 032 | | | | 3.10 |
| Software Reuse |
| | 3.10.1 | 147 | | | | 3.10.2 | 148 | | | | 3.11 |
| Software Cybersecurity |
| | 3.11.2 | 156 | | | | 3.11.3 | 154 | | | | 3.11.4 | 157 | | | | 3.11.5 | 159 | | | | 3.11.6 | 207 | | | | 3.11.7 | 185 | | | | 3.11.8 | 210 | | | | 3.12 |
| Software Bi-Directional Traceability |
| | 3.12.1 | 052 | | | | 4 |
| Software Engineering (Life Cycle) Requirements |
| | 4.1 |
| Software Requirements |
| | 4.1.2 | 050 | | | | 4.1.3 | 051 | | | | 4.1.4 | 184 | | | | 4.1.5 | 053 | | | | 4.1.6 | 054 | | | | 4.1.7 | 055 | | | | 4.2 |
| Software Architecture |
| | 4.2.3 | 057 | | | | 4.2.4 | 143 | | | | 4.3 |
| Software Design | | | 4.3.2 | 058 | | | | 4.4 |
| Software Implementation |
| | 4.4.2 | 060 | | | | 4.4.3 | 061 | | | | 4.4.4 | 135 | | | | 4.4.5 | 062 | | | | 4.4.6 | 186 | | | | 4.4.7 | 063 | | | | 4.4.8 | 136 | | | | 4.5 |
| Software Testing |
| | 4.5.2 | 065a | | | | 4.5.2 | 065b | | | | 4.5.2 | 065c | | | | 4.5.2 | 065d | | | | 4.5.3 | 066 | | | | 4.5.4 | 187 | | | | 4.5.5 | 068 | | | | 4.5.6 | 070 | | | | 4.5.7 | 071 | | | | 4.5.8 | 073 | | | | 4.5.9 | 189 | | | | 4.5.10 | 190 | | | | 4.5.11 | 191 | | | | 4.5.12 | 192 | | | | 4.5.13 | 193 | | | | 4.5.14 | 211 | | | | 4.6 |
| Software Operations, Maintenance, and Retirement |
| | 4.6.2 | 075 | | | | 4.6.3 | 077 | | | | 4.6.4 | 194 | | | | 4.6.5 | 195 | | | | 4.6.6 | 196 | | | | 5 |
| Supporting Software Life Cycle Requirements |
| | 5.1 |
| Software Configuration Management |
| | 5.1.2 | 079 | | | | 5.1.3 | 080 | | | | 5.1.4 | 081 | | | | 5.1.5 | 082 | | | | 5.1.6 | 083 | | | | 5.1.7 | 084 | | | | 5.1.8 | 085 | | | | 5.1.9 | 045 | | | | 5.2 |
| Software Risk Management |
| | 5.2.1 | 086 | | | | 5.3 |
| Software Peer Reviews/Inspections |
| | 5.3.2 | 087 | | | | 5.3.3 | 088 | | | | 5.3.4 | 089 | | | | 5.4 |
| Software Measurements |
| | 5.4.2 | 090 | | | | 5.4.3 | 093 | | | | 5.4.4 | 094 | | | | 5.4.5 | 199 | | | | 5.4.6 | 200 | | 1. Confirm that the project collects, tracks, and reports on the software volatility metrics.
2. Analyze software volatility metrics to evaluate requirements stability as an early indicator of project problems. | | 5.5 |
| Software Non-conformance or Defect Management |
| | 5.5.1 | 201 |  The project manager shall track and maintain software non-conformances (including defects in tools and appropriate ground software).
| 1. Confirm that all software non-conformances are recorded and tracked to resolution.2. Confirm that accepted non-conformances include the rationale for the non-conformance. | | 5.5.2 | 202 | The project manager shall define and implement clear software severity levels for all software non-conformances (including tools, COTS, GOTS, MOTS, OSS, reused software components, and applicable ground systems). | 1. Confirm that all software non-conformances severity levels are defined.
2. Assess the application and accuracy of the defined severity levels to software non-conformances.3. Confirm that the project assigns severity levels to non-conformances associated with tools, COTS, GOTS, MOTS, OSS, and reused software components. 4. Maintain or access the number of software non-conformances at each severity level for each software configuration item. | | 5.5.3 | 203 | The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, and/or reused software components. | 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 project software's safety, quality, and reliability. | | 5.5.4 | 204 | The project manager shall implement process assessments for all high severity software non-conformances (closed loop process). | 1. Perform or confirm that a root cause analysis has been completed on all identified high severity software non-conformances, and that the results are recorded and have been assessed for adequacy. 2. Confirm that the project analyzed the processes identified in the root cause analysis associated with the high severity software non-conformances.
3. Assess opportunities for improvement on the processes identified in the root cause analysis associated with the high severity software non-conformances. 4. Perform or confirm tracking of corrective actions to closure on high severity software non-conformances. |
|
3. Example of Table from Software Assurance PlanThe table below was taken from excerpts from Software Assurance Plan in SWEHBVD. The table is built from SWE excerpts plus SA Tasks using the individual SA tasks from the "SA Tasks from NASA-STD-8739.8B" area of SITE. The advantage of using this technique is that changes to the requirements (from SWEHBVD SWEs) and SA Tasks (from NASA-STD-8739.8B) will be made in one place. Once the updates are made, all of the places where they are repeated (quoted) are automatically updated. It is a little one time work to setup. It saves time as updates are made in documents. |
SWE # | NPR 7150.2 Requirement | NASA-STD-8739.8 Software Assurance and Software Safety Tasks per SA Standard | 013 | | |
|
|
|
|
This example is taken from SWEHBVD: SWE-013 - Software Plans. It uses the excerpt from tab 1 of the SWE and some include pages for appropriate tasks in the NASA-STD-8739.8B page set in SITE. |
7. Software Assurance
7.1 Tasking for Software Assurance |
|