02.00. Software Assurance and Software Safety Activity Overview

Many of the SWEs in this activity appear in other Activities where they are used. They are also included here, as sub-activities tabs, to emphasize how they are related to one another. 

The software assurance and software safety activities provide a level of confidence that software is

• free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle,
• functions in an intended manner, and
• does not function in an unintended manner. 

The software assurance process is the planned and systematic set of activities that ensure the conformance of software life cycle processes and products to requirements, standards, and procedures.  Software assurance assures that the software and its related products meet their specified requirements, conform to standards and regulations, are consistent, complete, correct, safe, secure, and reliable as warranted for the system and operating environment, and satisfy customer needs. The objectives of software assurance and software safety activities include the following:

Frequency Of This Activity

This is a continuous activity. 

02.00.1 Related SWEs

• SWE-022 - Software Assurance - 3.6.1 The project manager shall plan and implement software assurance, software safety, and IV&V (if required) per NASA-STD-8739.8, Software Assurance and Software Safety Standard.
• SWE-212 - NASA-STD-8739 Mapping Matrices - 2.1.2.4 The NASA Chief, SMA shall periodically review the project’s requirements mapping matrices.

02.00.2 Related Work Products

• 8.51 - Software Assurance Plan - The Software Assurance (SA) Plan product documents the expected work for the Software Assurance and Software Safety (if applicable) personnel for the project.
• 8.52 - Software Assurance Status Reports - Software Assurance Status Reports product content.
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Plans are good candidates for a Peer Review

02.00.3 Related Topics

• 8.14 - SA Tasking for NPR 7150.2B - Topic retired. See an earlier version of SWEHB for this topic, it does not apply to the current version of the SWEHB. 
• 8.15 - SA Tasking Checklist Tool - Checklist tool that gives SA analysts the ability to tailor the software assurance and software safety tasks in NASA-STD-8739.8B and generate a tailored checklist for the tasks required on a project's software classification and safety-criticality.

02.00.4 Related SPAN Links

02.01. Software Assurance Analysis

Analysis is performed by Software Assurance on a variety of areas on a software development project. Analysis provides additional focus on providing a level of confidence that software is

• free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle,
• functions in an intended manner, and
• does not function in an unintended manner. 

Analysis tasks are related to SWEs in accordance with NASA-STD-8739.8B. These relationships may be found in the topics. 

Frequency Of This Activity

Analysis is performed as needed on the project. It is performed during the activity where the development work is performed. 

02.01.1 Related SWEs

02.01.2 Related Work Products

• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

02.01.2.1 Related Process Asset Templates

• PAT-005 - Software Component Design Analysis Checklist
• PAT-006 - Design Practices for Safety

02.01.3 Related Topics

• 8.01 - Off Nominal Testing - Guidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.
• 8.02 - Software Reliability - The goal of SW reliability and maintainability is to assure that SW performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software reliability.
• 8.05 - SW Failure Modes and Effects Analysis - A "bottoms up" structured analysis method to help determine potential failures or hazards in the software design with guidance and forms.
• 8.07 - Software Fault Tree Analysis - A top-down analysis method to help identify the causes of presupposed hazards.
• 8.09 - Software Safety Analysis - Software Safety Analysis (SSA) is a term that is used to describe a wide range of analyses.  This article provides guidance on performing an SSA to satisfy the NASA-STD-8739.8 requirement associated with NPR 7150.2 SWE-205 - Determination of Safety-Critical Software.  
• 8.54 - Software Requirements Analysis - The Software Requirements Analysis product focuses on analyzing the software requirements that have been developed from the system requirements. 
• 8.55 - Software Design Analysis - The Software Design Analysis product focuses on analyzing the software design that has been developed from the requirements (software, system, and/or interface). This topic describes some of the methods and techniques Software Assurance and Software Safety personnel may use to evaluate the quality of the architecture and design elements that was developed.
• 8.56 - Source Code Quality Analysis - Source Code Analysis methods and techniques.
• 8.57 - Testing Analysis - Testing Analysis product content.
• 8.58 - Software Safety and Hazard Analysis - Software Safety and Hazard Analysis product content.

02.01.4 Related SPAN Links

02.02. Software Assurance Auditing

Auditing is performed by Software Assurance on a variety of areas on a software development project. Auditing provides additional focus on providing a level of confidence that software is

• free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle,
• functions in an intended manner, and
• does not function in an unintended manner. 

Auditing is focused on the performance of the work directed by the guidance in processes selected to do the work. 

Auditing tasks are related to SWEs in accordance with NASA-STD-8739.8B. These relationships may be found in the topics. 

Frequency Of This Activity

Auditing is performed as necessary on work products and processes throughout the project. 

02.02.1 Related SWEs

02.02.2 Related Work Products

• 8.51 - Software Assurance Plan - The Software Assurance (SA) Plan product documents the expected work for the Software Assurance and Software Safety (if applicable) personnel for the project.
• 8.59 - Audit Reports - The Audit Reports topic focuses on the many aspects of software auditing and how to report the results. 
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

02.02.2.1 Related Process Asset Templates

• PAT-033 - TASKS NEEDING OBJECTIVE EVIDENCE

02.02.3 Related Topics

• 8.12 - Basics of Software Auditing - Software audits provide an independent evaluation of the conformance of software products and processes to applicable requirements, standards, guidelines, plans, and procedures.

02.02.4 Related SPAN Links

02.03. Independent Verification & Validation

Independent validation and verification (IV&V) is a part of Software Assurance playing a role in the NASA software risk mitigation strategy. OSMA is responsible for determining which projects have IV&V for NASA in conjunction with the responsible Mission Directorate. The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software and provide assurance that the software will operate as intended, not operate unexpectedly and respond appropriately to adverse conditions. Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs.  IV&V across the project life cycle increases the likelihood of uncovering high-risk errors early in the life cycle.

IV&V is a technical discipline of software assurance that employs rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the software development life cycle. The evaluation of products and processes throughout the life cycle demonstrates whether the software is fit for nominal operations (required functionality, safety, dependability, etc.) and off-nominal conditions (response to faults, responses to hazardous conditions, etc.). The goal of the IV&V effort is to contribute assurance conclusions provided to the project and stakeholders based on evidence found in software development artifacts and risks associated with the intended behaviors of the software.

The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software.  Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs.  IV&V across the project life cycle increases the likelihood of uncovering high-risk errors early in the life cycle.

The IV&V Project Execution Plans (IPEP) documents the activities, methods, level of rigor, environments, tailoring (if any) of the IV&V requirements, and criteria to be used in performing verification and validation of in-scope system/software behaviors (including responsible software components) determined by the planning and scoping effort.

IV&V artifacts and products required to perform the IV&V analysis on NASA projects are to be made available in electronic format in the original format. The electronic availability of the IV&V products and artifacts facilitates post-deliveries that might be necessary with software updates. Electronic access to IV&V artifacts and products reduces NASA's IV&V project costs and accommodates the longer-term needs when performing software maintenance.

 If the project manager does not address the issues and risks found by IV&V and track them to closure, these unaddressed risks and issues could cause the project to fail to meet its objectives (e.g. schedule, planned quality, functionality, etc.) Since IV&V personnel have generally worked across many projects, they are often likely to recognize risks and issues to the project that the project manager may not recognize.

Frequency Of This Activity

02.03.1 Related SWEs

• SWE-141 - Software Independent Verification and Validation - 3.6.2 For projects reaching Key Decision Point A, the program manager shall ensure that software IV&V is performed on the following categories of projects: 

  a. Category 1 projects as defined in NPR 7120.5.
  b. Category 2 projects as defined in NPR 7120.5, that have Class A or Class B payload risk classification per NPR 8705.4, Risk Classification for NASA Payloads.
  c. Projects selected explicitly by the Mission Directorate Associate Administrator (MDAA) to have software IV&V.

• SWE-131 - Independent Verification and Validation Project Execution Plan - 3.6.3 If software IV&V is required for a project, the project manager, in consultation with NASA IV&V, shall ensure an IPEP is developed, approved, maintained, and executed in accordance with IV&V requirements in NASA-STD-8739.8.
• SWE-178 - IV&V Artifacts - 3.6.4 If software IV&V is performed on a project, the project manager shall ensure that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively. 
• SWE-179 - IV&V Submitted Issues and Risks - 3.6.5 If software IV&V is performed on a project, the project manager shall provide responses to IV&V submitted issues and risks and track these issues and risks to closure.
• SWE-223 - Tailoring IV&V project selections - 2.1.2.7 The NASA Chief, SMA shall make the final decision on all proposed tailoring of SWE-141, the Independent Verification and Validation (IV&V) requirement. 
• A.10 Software Peer Reviews and Inspections - Plans are good candidates for a Peer Review

02.03.2 Related Work Products

• 8.53 - IV&V Project Execution Plan - IV&V Project Execution Plan product introduction
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

02.03.2.1 Related Process Asset Templates

02.03.3 Related Topics

• 8.06 - IV&V Surveillance - This guidance will establish the rationale behind the creation of an IV&V Requirements and Surveillance activities. 

02.03.4 Related SPAN Links

02.04. Safety-Critical 

It is important to determine the safety criticality of each software component to identify the most critical software system components and to ensure that the software safety-critical requirements and processes are followed.

The implementation of the safety-critical software requirements and processes helps ensure that a safe product is produced. 

Implementing safety-critical software or mission-critical software design requirements helps ensure that the systems are safe and that the safety-critical software or mission-critical software requirements and processes are followed.

All Safety-critical software decisions must be tested to protect against loss of crew or vehicle.  MCDC testing represents the minimal set of tests necessary to achieve test coverage over decisions that change the behavior/outcome/output of a computer program.   Anything less than MCDC exposes a risk of a safety-critical decision based on a set of conditions not being tested. Aerospace and space guidance prioritizes safety above all else in the software development life cycle. MC/DC represents a compromise that finds a balance between rigor and effort, positioning itself between decision coverage (DC) and multiple condition coverage (MCC). MC/DC requires a much smaller number of test cases than multiple condition coverage (MCC) while retaining a high error-detection probability.  To minimize risk, ensure complete software testing and increase reliability associated with safety-critical software code components. 

Frequency Of This Activity

02.04.1 Related SWEs

• SWE-205 - Determination of Safety-Critical Software - 3.7.1 The project manager, in conjunction with the SMA organization, shall determine if each software component is considered to be safety-critical per the criteria defined in NASA-STD-8739.8. 
• SWE-023 - Software Safety-Critical Requirements - 3.7.2 If a project has safety-critical software, the project manager shall implement the safety-critical software requirements contained in NASA-STD-8739.8.
• SWE-134 - Safety-Critical Software Design Requirements - 3.7.3 If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software: 

  a. The software is initialized, at first start and restarts, to a known safe state.
  b. The software safely transitions between all predefined known states.
  c. Termination performed by software functions is performed to a known safe state.
  d. Operator overrides of software functions require at least two independent actions by an operator.
  e. Software rejects commands received out of sequence when execution of those commands out of sequence can cause a hazard.
  f. The software detects inadvertent memory modification and recovers to a known safe state.
  g. The software performs integrity checks on inputs and outputs to/from the software system.
  h. The software performs prerequisite checks prior to the execution of safety-critical software commands.
  i. No single software event or action is allowed to initiate an identified hazard.
  j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
  k. The software provides error handling.
  l. The software can place the system into a safe state.

• SWE-219 - Code Coverage for Safety Critical Software - 3.7.4 If a project has safety-critical software, the project manager shall ensure that there is 100 percent code test coverage using the Modified Condition/Decision Coverage (MC/DC) criterion for all identified safety-critical software components.
• SWE-220 - Cyclomatic Complexity for Safety-Critical Software - 3.7.5 If a project has safety-critical software, the project manager shall ensure all identified safety-critical software components have a cyclomatic complexity value of 15 or lower. Any exceedance shall be reviewed and waived with rationale by the project manager or technical approval authority.

02.04.2 Related Work Products

• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Requirements and Code are good candidates for a Peer Review

02.04.2.1 Related Process Asset Templates

• PAT-005 - Software Component Design Analysis Checklist
• PAT-006 - Design Practices for Safety
• PAT-007 - Checklist for General Software Safety Requirements
• PAT-008 - Safety Considerations for Design Peer Reviews Checklist

02.04.3 Related Topics

• 6.1 - Design for Safety Checklist - Lists some key practices for software design, particularly when designing safety-critical software.
• 6.2 - Checklist for General Software Safety Requirements -  Provides a list of many of the requirements that should be included in a safety-critical software system.
• 8.01 - Off Nominal Testing - Guidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.
• 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software - Requirements to be considered when you have safety-critical software on a program/project/facility.
• 8.08 - COTS Software Safety Considerations - A discussion on the use of COTS in safety-critical systems.
• 8.09 - Software Safety Analysis - Software Safety Analysis (SSA) is a term that is used to describe a wide range of analyses.  This article provides guidance on performing an SSA to satisfy the NASA-STD-8739.8 requirement associated with NPR 7150.2 SWE-205 - Determination of Safety-Critical Software.  
• 8.10 - Facility Software Safety Considerations - Facility software system safety exists to ensure the safe and continuous operation of software associated with ground-based facilities.
• 8.17 - Software Safety Audit Checklists - Software Safety Analysis (SSA) is a term that is used to describe a wide range of analyses.  This article provides guidance on performing an SSA to satisfy the NASA-STD-8739.8 requirement associated with NPR 7150.2 SWE-205 - Determination of Safety-Critical Software.  
• 8.19 - Dead / Dormant Code and Safety-Critical Software - This topic discusses the issues of having dead or dormant code in software that is safety-critical. 
• 8.20 - Safety Specific Activities in Each Phase - This topic provides a summary of the safety-specific activities that should be performed for any safety-critical software. The activities are grouped into the approximate life cycle phases where they will be performed.
• 8.21 - Software Hazard Causes - This topic provides a list of possible software causes that should be considered when developing hazard analyses.
• 8.22 - Hazardous Commands - This topic provides a list of possible software causes that should be considered when developing hazard analyses.
• 8.58 - Software Safety and Hazard Analysis - Software Safety and Hazard Analysis product content.
• 9.02 Software Safety and Design Principles - This page contains the cross-references between elements of SWE-134 and the Software Design Principles.

02.04.4 Related SPAN Links