UNDER CONSTRUCTION

1. NASA-STD-8739.8B Title Material

Approved: TBDMeasurement 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

StatusDocument RevisionApproval DateDescription
BaselineInitial2004-07-28Initial Release

12005-05-05Administrative 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.

A2020-06-10The 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.

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

Forward

This 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 SectionSWE #NPR 7150.2 RequirementSoftware Assurance and Software Safety Tasks
3
Software Management Requirements
3.1
Software Life-Cycle Planning
3.1.2033


3.1.3013

3.1.4024

3.1.5034

3.1.6036

3.1.7037

3.1.8039

3.1.9040

3.1.10042

3.1.11139

3.1.12121

3.1.13125

3.1.14027

3.2
Software Cost Estimation
3.2.1015

3.2.2151

3.2.3174

3.3
Software Schedules
3.3.1016

3.3.2018

3.3.3046

3.4
Software Training


3.4.1017

3.5
Software Classification Assessments
3.5.1020

3.5.2176

3.6
Software Assurance and Software
Independent Verification & Validation

3.6.1022

3.6.2141

3.6.3131

3.6.4178

3.6.5179

3.7
Safety-Critical  and Mission Critical Software
3.7.1205

3.7.2023

3.7.3134

3.7.4219

3.7.5220

3.8
Automatic Generation of Software Source Code
3.8.1146

3.8.2206

3.9
Software Development Processes and Practices
3.9.2032

3.10
Software Reuse
3.10.1147

3.10.2148

3.11
Software Cybersecurity
3.11.2156

3.11.3154

3.11.4157

3.11.5159

3.11.6207

3.11.7185

3.11.8210

3.12
Software Bi-Directional Traceability
3.12.1052

4
Software Engineering (Life Cycle) Requirements
4.1
Software Requirements
4.1.2050

4.1.3051

4.1.4184

4.1.5053

4.1.6054

4.1.7055

4.2
Software Architecture
4.2.3057

4.2.4143

4.3
Software Design 
4.3.2058

4.4
Software Implementation
4.4.2060

4.4.3061

4.4.4135

4.4.5062

4.4.6186

4.4.7063

4.4.8136

4.5
Software Testing
4.5.2065a

4.5.2065b

4.5.2065c

4.5.2065d

4.5.3066

4.5.4187

4.5.5068

4.5.6070

4.5.7071

4.5.8073

4.5.9189

4.5.10190

4.5.11191

4.5.12192

4.5.13193

4.5.14211

4.6
Software Operations, Maintenance, and Retirement
4.6.2075

4.6.3077

4.6.4194

4.6.5195

4.6.6196

5
Supporting Software Life Cycle Requirements
5.1
Software Configuration Management
5.1.2079

5.1.3080

5.1.4081

The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project.

1. Confirm that the project has identified the configuration items and their versions to be controlled.2. Assess that the software safety-critical items are configuration-managed, including hazard reports and safety analysis.
5.1.5082

The project manager shall establish and implement procedures to:
a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.

1. Confirm that software assurance has participation in software control activities.2. Perform an audit against the configuration management procedures to confirm that the project follows the established procedures.
5.1.6083

The project manager shall prepare and maintain records of the configuration status of software configuration items.

1. Confirm that the project maintains records of the configuration status of the configuration items.
5.1.7084

The project manager shall perform software configuration audits to determine the correct version of the software configuration items and verify that they conform to the records that define them.

1. Confirm that the project manager performed software configuration audits to determine the correct version of the software configuration items and verify that the results of the audit conform to the records that define them.
5.1.8085

The project manager shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.

1. Confirm that the project establishes procedures for storage, processing, distribution, release, and support of deliverable software products.2. Perform audits on the project to ensure that the project follows defined procedures for deliverable software products.
5.1.9045

The project manager shall participate in any joint NASA/developer audits.

1. Participate in or assess the results from any joint NASA/developer audits. Track any findings to closure.
5.2
Software Risk Management
5.2.1086

The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans.

1. Confirm and assess that a risk management process includes recording, analyzing, planning, tracking, controlling, and communicating all software risks and mitigation plans. 2. Perform audits on the risk management process for the software activities.
5.3
Software Peer Reviews/Inspections
5.3.2087

The project manager shall perform and report the results of software peer reviews or software inspections for:
a. Software requirements.
b. Software plans, including cybersecurity.
c. Any design items that the project identified for software peer review or software inspections according to the software development plans.
d. Software code as defined in the software and or project plans.
e. Software test procedures.

1. Confirm that software peer reviews are performed and reported on for project activities. 2. Confirm that the project addresses the accepted software peer review findings.3. Perform peer reviews on software assurance and software safety plans.4. Confirm that the source code satisfies the conditions in the NPR 7150.2 requirement SWE-134, "a" through "l," based upon the software functionality for the applicable safety-critical requirements at each code inspection/review.
5.3.3088

The project manager shall, for each planned software peer review or software inspection:
a. Use a checklist or formal reading technique (e.g., perspective-based reading) to evaluate the work products.
b. Use established readiness and completion criteria.
c. Track actions identified in the reviews until they are resolved.
d. Identify the required participants.

1. Confirm that the project meets the NPR 7150.2 criteria in "a" through "d" for each software peer review.2. Confirm that the project resolves the actions identified from the software peer reviews.3. Perform audits on the peer-review process.
5.3.4089

The project manager shall, for each planned software peer review or software inspection, record necessary measurements.

1. Confirm that the project records the software peer reviews and results of software inspection measurements.
5.4
Software Measurements
5.4.2090

The project manager shall establish, record, maintain, report, and utilize software management and technical measurements.

1. Confirm that a measurement program establishes, records, maintains, reports, and uses software assurance, management, and technical measures. 2. Perform trending analyses on metrics (quality metrics, defect metrics) and report. 3. Collect any identified organizational metrics and submit them to the organizational repository.
5.4.3093

The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures.

1. Confirm software measurement data analysis conforms to documented analysis procedures.
2. Analyze software assurance measurement data.
5.4.4094

The project manager shall provide access to the software measurement data, measurement analyses, and software development status as requested to the sponsoring Mission Directorate, the NASA Chief Engineer, the Center Technical Authorities, HQ SMA, and other organizations as appropriate.

1. Confirm access to software measurement data, analysis, and status as requested to the following entities, at a minimum:
- Sponsoring Mission Directorate
- NASA Chief Engineer
- Center Technical Authorities
- Headquarters SMA
5.4.5199

The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints.

1. Confirm that the project monitors and updates planned measurements to ensure the software meets or exceeds performance and functionality requirements, including satisfying constraints.
2. Monitor and track any performance or functionality requirements that are not being met or are at risk of not being met.
5.4.6200

The project manager shall collect, track, and report software requirements volatility metrics.

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

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

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

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

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 Plan

The 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