Excerpt

hidden	true

NASA Technical Standard 8739.8B - Approved 2004-27-08 - SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD. Full text of this NPR as taken from NODIS. Assembled from component pieces beneath this page.

...

Tabsetup

0	1. NASA-STD-8739.8B
1	2. Applicable and Reference Documents
2	3. Acronyms and Definitions
3	4. Software Assurance and Software Safety Requirements
4	5. Appendix A Guidelines For The Hazard Development Involving Software

NASA TECHNICAL STANDARD

National Aeronautics and Space Administration

Div

id	tabs-1

1. NASA-STD-8739.8B Title Material

Approved: TBD

Measurement System Identification: Not Measurement Sensitive

Include Page

	NASA-STD-8739.

8BApproved: 2022-09-08
Superseding

8 - Title Material
	NASA-STD-8739.

8A

SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
APPROVED FOR PUBLIC RELEASE – DISTRIBUTION IS UNLIMITED

8 - Title Material

1. SCOPE

1.1 Document Purpose

1.1.1 The purpose of the Software Assurance and Software Safety Standard is to define the requirements to implement a systematic approach to software assurance, software safety, and Independent Verification and Validation (IV&V) for software created, acquired, provided, used, or maintained by or for NASA. Various personnel in the program, project, engineering, facility, or Safety and Mission Assurance (SMA) organizations can perform the activities required to satisfy these requirements. The Software Assurance and Software Safety Standard provides a basis for personnel to perform software assurance, software safety, and IV&V activities consistently throughout the life of the software.

1.1.2 The Software Assurance and Software Safety Standard, in accordance with NPR

DOCUMENT HISTORY LOGStatusDocument RevisionApproval DateDescriptionBaselineInitial2004-07-28Initial Release12005-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.B2022-09-08Brings 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.

William Deloach

NASA Chief, Safety and Mission Assurance

TBD

Approval Date

1. SCOPE

1.1 Document Purpose

1.1.1 The purpose of the Software Assurance and Software Safety Standard is to define the requirements to implement a systematic approach to software assurance, software safety, and Independent Verification and Validation (IV&V) for software created, acquired, provided, used, or maintained by or for NASA. Various personnel in the program, project, engineering, facility, or Safety and Mission Assurance (SMA) organizations can perform the activities required to satisfy these requirements. The Software Assurance and Software Safety Standard provides a basis for personnel to perform software assurance, software safety, and IV&V activities consistently throughout the life of the software.

1.1.2 The Software Assurance and Software Safety Standard, in accordance with NPR 7150.2, NASA Software Engineering Requirements, supports the implementation of the software assurance, software safety, and IV&V sub-disciplines. The application and approach to meeting the Software Assurance and Software Safety Standard vary based on the system and software products and processes to which they are applied. The Software Assurance and Software Safety Standard stresses coordination between the software assurance sub-disciplines and system safety, system reliability, hardware quality, system security, and software engineering to maintain the system perspective and minimize duplication of effort.

1.1.3 The objectives of the Software Assurance and Software Safety Standard include the following:

a. Ensuring that the processes, procedures, and products used to produce and sustain the software conform to all specified requirements and standards that govern those processes, procedures, and products.

(1) A set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products.
(2) A set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes.

b. Determining the degree of software quality obtained by the software products.
c. Ensuring that the software systems are safe and that the software safety-critical requirements are followed.
d. Ensuring that the software systems are secure.
e. Employing rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the life cycle.

1.1.4 The Software Assurance and Software Safety Standard is compatible with all software life cycle models. The Software Assurance and Software Safety Standard does not impose a particular life cycle model on a software project.

1.1.5 In this standard, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall.” The terms “may” denote a discretionary privilege or permission; “can” denotes statements of possibility or capability; “should” denotes a good practice and is recommended; but not required, “will” denotes expected outcome; and “are/is” denotes descriptive material.

1.2 Applicability

1.2.1 This standard is approved for use by NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers. This NASA Technical Standard applies to the assurance of software created by or for NASA projects, programs, facilities, and activities and defines the requirements for those activities. This directive is applicable to the Jet Propulsion Laboratory, a Federally Funded Research and Development Center, only to the extent specified in the NASA/Caltech Prime Contract. This standard may also apply to other contractors, grant recipients, or parties to agreements to the extent specified or referenced in their contracts, grants, or agreements.

1.3 Documentation and Deliverables

1.3.1 The Software Assurance and Software Safety Standard is not intended to designate the format of program/project/facility documentation and deliverables. The software assurance and software safety data, information, and plans may be considered to be quality records with a retention period as specified in NRRS 1441.1. The format of the documentation is a program/project/facility decision. The software assurance and software safety organizations should keep records, reports, metrics, analyses, and trending results and should keep copies of their project plans for future reference and improvements. The software assurance and software safety plans (e.g., the Software Assurance Plan) can be standalone documents or incorporated within other documents (e.g., part of a Software Management Plan, a Software Development Plan or part of a Program or Project Safety and Mission Assurance (SMA) plan).

1.4 Request for Relief

1.4.1 Tailoring of this standard for application to a specific program or project is documented as part of program or project requirements and approved by the responsible Center Technical Authority (TA) in accordance with NPR 8715.3, NASA General Safety Program Requirements. Section 4.5 of this standard contains the principles related to tailoring this standard’s requirements.

, supports the implementation of the software assurance, software safety, and IV&V sub-disciplines. The application and approach to meeting the Software Assurance and Software Safety Standard vary based on the system and software products and processes to which they are applied. The Software Assurance and Software Safety Standard stresses coordination between the software assurance sub-disciplines and system safety, system reliability, hardware quality, system security, and software engineering to maintain the system perspective and minimize duplication of effort.

1.1.3 The objectives of the Software Assurance and Software Safety Standard include the following:

a. Ensuring that the processes, procedures, and products used to produce and sustain the software conform to all specified requirements and standards that govern those processes, procedures, and products.

(1) A set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products.
(2) A set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes.

b. Determining the degree of software quality obtained by the software products.
c. Ensuring that the software systems are safe and that the software safety-critical requirements are followed.
d. Ensuring that the software systems are secure.
e. Employing rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the life cycle.

1.1.4 The Software Assurance and Software Safety Standard is compatible with all software life cycle models. The Software Assurance and Software Safety Standard does not impose a particular life cycle model on a software project.

1.1.5 In this standard, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall.” The terms “may” denote a discretionary privilege or permission; “can” denotes statements of possibility or capability; “should” denotes a good practice and is recommended; but not required, “will” denotes expected outcome; and “are/is” denotes descriptive material.

1.2 Applicability

1.2.1 This standard is approved for use by NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers. This NASA Technical Standard applies to the assurance of software created by or for NASA projects, programs, facilities, and activities and defines the requirements for those activities. This directive is applicable to the Jet Propulsion Laboratory, a Federally Funded Research and Development Center, only to the extent specified in the NASA/Caltech Prime Contract. This standard may also apply to other contractors, grant recipients, or parties to agreements to the extent specified or referenced in their contracts, grants, or agreements.

1.3 Documentation and Deliverables

1.3.1 The Software Assurance and Software Safety Standard is not intended to designate the format of program/project/facility documentation and deliverables. The software assurance and software safety data, information, and plans may be considered to be quality records with a retention period as specified in NRRS 1441.1. The format of the documentation is a program/project/facility decision. The software assurance and software safety organizations should keep records, reports, metrics, analyses, and trending results and should keep copies of their project plans for future reference and improvements. The software assurance and software safety plans (e.g., the Software Assurance Plan) can be standalone documents or incorporated within other documents (e.g., part of a Software Management Plan, a Software Development Plan or part of a Program or Project Safety and Mission Assurance (SMA) plan).

1.4 Request for Relief

1.4.1 Tailoring of this standard for application to a specific program or project is documented as part of program or project requirements and approved by the responsible Center Technical Authority (TA) in accordance with NPR 8715.3, NASA General Safety Program Requirements. Section 4.5 of this standard contains the principles related to tailoring this standard’s requirements.

Div

id	tabs-2

2. APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

The applicable documents are accessible via the NASA Technical Standards System at https://standards.nasa.gov, or the NASA Online Directives Information System https://nodis3.gsfc.nasa.gov/main_lib.cfm or may be obtained directly from the Standards Developing Organizations.

NPR 1400.1 NASA Directives and Charters Procedural Requirements
NPR 7120.5 NASA Space Flight Program and Project Management Requirements
NPR 7120.10 Technical Standards for NASA Programs and Projects
PR 7150.2 NASA Software Engineering Requirements
PR 8000.4 Agency Risk Management Procedural Requirements
NPR 8715.3 NASA General Safety Program Requirements
NASA-HDBK-2203 NASA Software Engineering Handbook
NASA-HDBK-4008 Programmable Logic Devices Handbook
NRRS 1441.1 NASA Records Retention Schedules

2.2 Reference Documents

The reference documents listed in this section are not incorporated by reference within this standard but may provide further clarification and guidance.

2.2.1 Government Documents

NPD 2810.1 NASA Information Security Policy
NPD 8720.1 NASA Reliability and Maintainability Program Policy
NPR 1441.1 NASA Records Management Program Requirements
NPR 2210.1 Release of NASA Software
NPR 2810.1 Security of Information and Information Systems
NPR 2830.1 NASA Enterprise Architecture Procedures
NPR 2841.1 Identity, Credential, and Access Management
NPR 7120.7 NASA Information Technology Program and Project Management Requirements
NPR 7120.8 NASA Research and Technology

Div

id	tabs-2

2. APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

The applicable documents are accessible via the NASA Technical Standards System at https://standards.nasa.gov, or the NASA Online Directives Information System https://nodis3.gsfc.nasa.gov/main_lib.cfm or may be obtained directly from the Standards Developing Organizations.

NPR 1400.1 NASA Directives and Charters Procedural Requirements
NPR 7120.5 NASA Space Flight Program and Project Management Requirements
NPR 7120.10 Technical Standards for NASA Programs and Projects
PR 7150.2 NASA Software Engineering Requirements
NPR 7120.11 Health and Medical Technical Authority Implementation
NPR 7123.1 NASA Systems Engineering Processes and Requirements.
NPR PR 8000.4 Agency Risk Management Procedural Requirements
NPR 87157123.3 NASA General Safety Program 1 NASA Systems Engineering Processes and Requirements
NASA-HDBK-2203 NASA Software Engineering HandbookSTD-1006 Space System Protection Standard
NASA-HDBK-4008 Programmable Logic Devices Handbook
NRRS 1441.1 NASA Records Retention Schedules

2.2 Reference Documents

STD-2601 Minimum Cybersecurity Requirements for Computing Systems
NASA-STD-7009 Standard for Models and Simulations
NASA-STD-8729.1 NASA Reliability And Maintainability Standard For Spaceflight And Support Systems
NASA-HDBK-7009 NASA Handbook for Models and Simulations: An Implementation Guide for NASA-STD-7009
NASA-HDBK-8709.22 Safety and Mission Assurance Acronyms, Abbreviations, and Definitions
NASA-HDBK-8739.23 NASA Complex Electronics Handbook for Assurance Professionals
NIST SP 800-37 Risk Management Framework
NIST SP 800-40 Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations
NIST SP 800-70 National Checklist Program for Information Technology products: Guidelines for Checklist Users and Developers
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment
NFS 1813.301-79 Supporting Federal Policies, Regulations, and NASA Procedural Requirements
NFS 1852.237-72 Access to Sensitive Information
NFS 1852.237-73 Release of Sensitive Information

2.2.2 Non-Government Documents

CMMI-DEV, V2.0 CMMI® for Development, Version 2.0
IEEE 730 Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Quality Assurance Processes
IEEE 828 IEEE Standard for Configuration Management in Systems and Software Engineering.
IEEE 982.1 IEEE Standard Measures of the Software Aspects of Dependability
IEEE 1012 IEEE Standard for System, Software, and Hardware Verification and Validation
IEEE 1028 IEEE Standard for Software Reviews and Audits
IEEE 1633 IEEE Recommended Practice on Software Reliability
IEEE 15026-1 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary
IEEE 29119-4 Software and systems engineering -- Software testing -- Part 4: Test techniques
ISO 26514 Systems and software engineering–requirements for designers and developers of user documentation
ISO 24765 System and Software Engineering – Vocabulary

2.3 Order of Precedence

2.3.1 This standard establishes requirements to implement a systematic approach to Software Assurance, Software Safety, and IV&V for software created, acquired, provided, or

The reference documents listed in this section are not incorporated by reference within this standard but may provide further clarification and guidance.

2.2.1 Government Documents

NPD 2810.1 NASA Information Security Policy
NPD 8720.1 NASA Reliability and Maintainability Program Policy
NPR 1441.1 NASA Records Management Program Requirements
NPR 2210.1 Release of NASA Software
NPR 2810.1 Security of Information and Information Systems
NPR 2830.1 NASA Enterprise Architecture Procedures
NPR 2841.1 Identity, Credential, and Access Management
NPR 7120.7 NASA Information Technology Program and Project Management Requirements
NPR 7120.8 NASA Research and Technology Program and Project Management Requirements
NPR 7120.10 Technical Standards for NASA Programs and Projects
NPR 7120.11 Health and Medical Technical Authority Implementation
NPR 7123.1 NASA Systems Engineering Processes and Requirements.
NPR 8000.4 Agency Risk Management Procedural Requirements
NPR 7123.1 NASA Systems Engineering Processes and Requirements
NASA-STD-1006 Space System Protection Standard
NASA-STD-2601 Minimum Cybersecurity Requirements for Computing Systems
NASA-STD-7009 Standard for Models and Simulations
NASA-STD-8729.1 NASA Reliability And Maintainability Standard For Spaceflight And Support Systems
NASA-HDBK-7009 NASA Handbook for Models and Simulations: An Implementation Guide for NASA-STD-7009
NASA-HDBK-8709.22 Safety and Mission Assurance Acronyms, Abbreviations, and Definitions
NASA-HDBK-8739.23 NASA Complex Electronics Handbook for Assurance Professionals
NIST SP 800-37 Risk Management Framework
NIST SP 800-40 Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations
NIST SP 800-70 National Checklist Program for Information Technology products: Guidelines for Checklist Users and Developers
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment
NFS 1813.301-79 Supporting Federal Policies, Regulations, and NASA Procedural Requirements
NFS 1852.237-72 Access to Sensitive Information
NFS 1852.237-73 Release of Sensitive Information

2.2.2 Non-Government Documents

CMMI-DEV, V2.0 CMMI® for Development, Version 2.0
IEEE 730 Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Quality Assurance Processes
IEEE 828 IEEE Standard for Configuration Management in Systems and Software Engineering.
IEEE 982.1 IEEE Standard Measures of the Software Aspects of Dependability
IEEE 1012 IEEE Standard for System, Software, and Hardware Verification and Validation
IEEE 1028 IEEE Standard for Software Reviews and Audits
IEEE 1633 IEEE Recommended Practice on Software Reliability
IEEE 15026-1 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary
IEEE 29119-4 Software and systems engineering -- Software testing -- Part 4: Test techniques
ISO 26514 Systems and software engineering–requirements for designers and developers of user documentation
ISO 24765 System and Software Engineering – Vocabulary

2.3 Order of Precedence

2.3.1 This standard establishes requirements to implement a systematic approach to Software Assurance, Software Safety, and IV&V for software created, acquired, provided, or maintained by or for NASA but does not supersede nor waive established Agency requirements found in other documentation.

2.3.2 Conflicts between the Software Assurance and Software Safety Standard and other requirements documents are resolved by the responsible SMA and engineering TA(s), per NPR1400.1, NASA Directives and Charters Procedural Requirements, and NPR 7120.10, Technical Standards for NASA Programs and Projects.

Div

id	tabs-3

3. ACRONYMS AND DEFINITIONS

3.1 Acronyms and Abbreviations

CMMI®

CMMI®? Capability Maturity Model Integration
COTS Commercial-Off-The-Shelf
GOTS Government-Off-The-Shelf
HDBK Handbook
IEEE Institute of Electrical and Electronics Engineers
IPEP IV&V Project Execution Plan
IV&V Independent Verification and Validation
MC/DC Modified Condition/Decision Coverage
MOTS Modified-Off-The-Shelf
NASA National Aeronautics and Space Administration
NIST National Institute of Standards and Technology
NPD NASA Policy Directive
NPR NASA Procedural Requirements
NRRS NASA Records Retention Schedule
OSMA NASA Headquarters Office, Safety and Mission Assurance
OSS Open Source Software
PLC Programmable Logic Controller
PROM Programmable Read-Only Memory
RTOS Real-Time Operating System
SMA Safety and Mission Assurance
SP Special Publication
SWE Software Engineering
TA Technical Authority

NASA-STD-8739.8B
12 of 70

3.2 Definitions

Accredit. The official acceptance of a software development tool, model, or simulation, including associated data, to use for a specific purpose.
Acquirer. The entity or individual who specifies the requirements and accepts the resulting software products. The Acquirer is usually NASA or an organization within the Agency but can also refer to the prime contractor-subcontractor relationship.

Analyze. Review results in-depth, look at relationships of activities, examine methodologies in detail, and follow methodologies such as Failure Mode and Effects Analysis, Fault Tree Analysis, trending, and metrics analysis. Examine processes, plans, products, and task lists for completeness, consistency, accuracy, reasonableness, and compliance with requirements. The analysis may include identifying missing, incomplete, or inaccurate products, relationships, deliverables, activities, required actions, etc.

Approve. When the responsible originating official, or designated decision authority, of a document, report, condition, etc., has agreed, via their signature, to the content and indicates the document is ready for release, baselining, distribution, etc. Usually, one “approver” and several stakeholders need to “concur” for official acceptance of a document, report, etc. For example, the project manager would approve the Software Development Plan, but SMA would concur on it.

Assess. Judge results against plans or work product requirements. Assess includes judging for practicality, timeliness, correctness, completeness, compliance, evaluation of rationale, etc., reviewing activities performed, and independently tracking corrective actions to closure.
Assure. When software assurance personnel make certain that others have performed the specified software assurance, management, and engineering activities.

Audit. Formal review to assess compliance with hardware or software requirements, specifications, baselines, safety standards, procedures, instructions, codes, and contractual and licensing requirements. (Source NPR 8715.3)

Bi-directional Traceability. Association among two or more logical entities that are discernible in either direction (to and from an entity). (Source IEEE Definition)

Concur. A documented agreement that a proposed course of action is acceptable.

Condition. (1) measurable qualitative or quantitative attribute that is stipulated for a requirement and that indicates a circumstance or event under which a requirement applies (2) description of a contingency to be considered in the representation of a problem, or a reference to other procedures to be considered as part of the condition (3) true or false logical predicate (4) logical predicate involving one or more behavior model elements (5) Boolean expression containing no Boolean operators.

Configuration Item. (1)item or aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process (2)component of an infrastructure or an item which is or will be under control of
NASA-STD-8739.8B
13 of 70
configuration of configuration management (3) aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process (4) any system element or aggregation of system elements that satisfies an end use function and is designated by the acquirer for separate configuration control (5) item or aggregation of software that is designed to be managed as a single entity and its underlying components, such as documentation, data structures, scripts. (Source IEEE Definition)

Note

Note:

Configuration items can vary widely in complexity, size, and type, ranging from an entire system including all hardware, software, and documentation, to a single module or a minor hardware component. CIs have four common characteristics: defined functionality; replaceable as an entity; unique specification; formal control of form, fit, and function. See Also: hardware configuration item, computer software configuration item, configuration identification, and critical item.

Confirm. Check to see that activities specified in the software engineering requirements are adequately done and evidence of the activities exists as proof. Confirm includes ensuring activities are done completely and correctly and have expected content according to approved tailoring.

Critical. A condition that may cause severe injury or occupational illness, or major property damage to facilities, systems, or flight hardware.
Deliverable. Product or item that has to be completed and delivered under the terms of an agreement or contract. Products may also be deliverables, e.g., software requirements specifications, and detailed design documents. Develop. To produce or create a product or document and mature or advance the product or document content.

Ensure. When software assurance or software safety personnel perform the specified software assurance and software safety activities themselves.
Event. (1) occurrence of a particular set of circumstances (2) external or internal stimulus used for synchronization purposes (3) change detectable by the subject software (4) fact that an action has taken place (5) singular moment in time at which some perceptible phenomenological change (energy, matter, or information) occurs at the port of a unit.

Failure. Inability of a system, subsystem, component, or part to perform its required function within specified limits. (Source NPR 8715.3)

Hazard. A state or a set of conditions, internal or external to a system that has the potential to cause harm. (Source NPR 8715.3)
Hazard Analysis. Identifying and evaluating existing and potential hazards and the recommended mitigation for the hazard sources found.
Hazard Control. Means of reducing the risk of exposure to a hazard. (Source NPR 8715.3)
NASA-STD-8739.8B
14 of 70

Hazardous Operation/Work Activity. Any operation or other work activity that, without the implementation of proper mitigations, has a high potential to result in loss of life, serious injury to personnel or public, or damage to property due to the material or equipment involved or the nature of the operation/activity itself.

Independent Verification and Validation. Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization. (Source IEEE Definition)

Inhibit. Design feature that prevents the operation of a function.

Insight. An element of Government surveillance that monitors contractor compliance using Government-identified metrics and contracted milestones. Insight is a continuum that can range from low intensity such as reviewing quarterly reports to high intensity such as performing surveys and reviews. (Source NPR 7123.1)

Maintain. To continue to have; to keep in existence, to stay up-to-date and correct.

Mission Critical. [1] Item or function that must retain its operational capability to assure no mission failure (i.e., for mission success). [2] An item or function, the failure of which may result in the inability to retain operational capability for mission continuation if corrective action is not successfully performed. (Source NASA-STD-8729.1)

Mission Success. Meeting all mission objectives and requirements for performance and safety. (Source NPR 8715.3)

Monitor. (1) software tool or hardware device that operates concurrently with a system or component and supervises, records, analyzes, or verifies the operation of the system or component; (2) collect project performance data with respect to a plan, process, produce performance measures, and report and disseminate performance information.

Participate. To be a part of the activity, audit, review, meeting, or assessment.

Perform. Software assurance does the action specified. Perform may include making comparisons of independent results with similar activities performed by engineering; performing audits; and reporting results to engineering.

Product. A result of a physical, analytical, or another process. The item delivered to the customer (e.g., hardware, software, test reports, data) and the processes (e.g., system engineering, design, test, logistics) that make the product possible. (Source NASA-HDBK-8709.22)

Program. A strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and technical approach, requirements, funding level, and management structure that initiates and directs one or more projects. A program implements a strategic direction that the Agency has identified as needed to accomplish Agency goals and objectives. (Source NPR 7120.5)NASA-STD-8739.8B
15 of 70

Program Manager. A generic term for the person who is formally assigned to be in charge of the program. A program manager could be designated as a program lead, program director, or some other term, as defined in the program's governing document. A program manager is responsible for the formulation and implementation of the program, per the governing document with the sponsoring MDAA.

Project. A specific investment having defined goals, objectives, requirements, life cycle cost, a beginning, and an end. A project yields new or revised products or services that directly address NASA’s strategic needs. They may be performed wholly in-house; by Government, industry, academia partnerships; or through contracts with private industry. (Source NPR 7150.2)

Project Manager. The entity or individual who accepts the resulting software products. Project managers are responsible and accountable for the safe conduct and successful outcome of their program or project in conformance with governing programmatic requirements. The project manager is usually NASA but can also refer to the prime contractor-subcontractor relationship as well.
Provider. A Provider is a NASA or contractor organization that is tasked by an accountable organization (i.e., the Acquirer) to produce a product or service. (Source NASA-HDBK-8709.22)

Regression testing. (1) selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements (2) testing following modifications to a test item or its operational environment, to identify whether regression failures occur. (Source IEEE Definition)

Risk. The combination of (1) the probability (qualitative or quantitative) of experiencing an undesired event, (2) the consequences, impact, or severity that would occur if the undesired event were to occur, and (3) the uncertainties associated with the probability and consequences. (Source NPR 8715.3)

Note

Note:

A risk is an uncertain future event, or combination of events, that could threaten the achievement of performance objectives or requirements. A "problem," on the other hand, describes an issue that is certain or near certain to exist now, or an event that has been determined with certainty or near certainty to have occurred and is threatening the achievement of an objective or requirement. It is generally at the discretion of the decision authority to define at what level of certainty (i.e., likelihood) an event may be classified and addressed as a “problem” rather than as a “risk.” A risk may be conditional upon a problem, i.e., an existing issue may or may not develop into performance-objective consequences or the extent to which it may be at present uncertain.

Risk Posture. A characterization of risk based on conditions (e.g., criticality, complexity, environments, performance, cost, schedule) and a set of identified risks, taken as a whole which allows an understanding of the overall risk or provides a target risk range or level, which can then be used to support decisions being made.

Safe State. A system state in which hazards are inhibited, and all hazardous actuators are in a non-hazardous state. The system can have more than one Safe State.
NASA-STD-8739.8B
16 of 70

Safety. Freedom from those conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. In a risk-informed context, safety is an overall mission and program condition that provides sufficient assurance that accidents will not result from the mission execution or program implementation, or, if they occur, their consequences will be mitigated. This assurance is established by means of the satisfaction of a combination of deterministic criteria and risk criteria. (Source NPR 8715.3)

Safety Analysis. Generic term for a family of analyses, which includes but is not limited to, preliminary hazard analysis, system (subsystem) hazard analysis, operating hazard analysis, software hazard analysis, sneak circuit, and others. Software safety analysis consists of a number of tools and techniques to identify safety risks and formulate effective controls. These techniques are used to help identify the hazards during the Hazard Analysis process, which in turn identifies the safety-critical software. The Safety Analysis techniques often used to support the Hazard Analysis are the Software Fault Tree Analysis and the Software Failure Modes and Effects Analysis. The Software Fault Tree Analysis and the Software Failure Modes and Effects Analysis are used to help identify hazards, hazard causes, and potential failure modes.

Safety-Critical. A term describing any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improperly or allowed to remain uncorrected. (Source NPR 8715.3)

Include Page

	8739.8B Para 3.2 Def - Safety-Critical Software
	8739.8B Para 3.

Software is classified as safety-critical if the software is determined by and traceable to a hazard analysis. Software is classified as safety-critical if it meets at least 2 Def - Safety-Critical Software

Software. defined as (1) computer programs, procedures, and associated documentation and data pertaining to the operation of a computer system (2) all or a one of the following criteria:
a. Causes or contributes to a system hazardous condition/event,
b. Controls functions identified in a system hazard,
c. Provides mitigation for a system hazardous condition/event,
d. Mitigates damage if a hazardous condition/event occurs,
e. Detects, reports, and takes corrective action if the system reaches a potentially hazardous state.
Software. defined as (1) computer programs, procedures, and associated documentation and data pertaining to the operation of a computer system (2) all or a part of the programs, procedures, rules, and associated documentation of an information processing (3) program or set of programs used to run a computer (4) all or part of the programs which process or support the processing of digital information (5) part of a product that is the computer program or the set of computer programs. This definition applies to software developed by NASA, software developed for NASA, software maintained by or for NASA, Commercial-Off-The-Shelf (COTS), Government-Off-The-Shelf (GOTS), Modified-Off-The-Shelf (MOTS), Open Source Software (OSS), reused software components, auto-generated code, embedded software, the software executed on processors embedded in programmable logic devices (see NASA-HDBK-4008), legacy, heritage, applications, freeware, shareware, trial or demonstration software, and OSS components. (Source NPR 7150.2)
NASA-STD-8739.8B
17 of 70

Software Assurance. (1) a set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products. Software assurance also determines the degree to which the desired results from software quality control are being obtained. (2) set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes. (Source IEEE Definition)Note:

Note
A key attribute of software assurance is the objectivity of the software assurance function with respect to the project.

Software Developer. A person, organization, or system that develops software based on program/project requirements.

Software Life Cycle. The period that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase.

Software Peer Review. An examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications. (Source IEEE Definition)

Software Safety. The aspects of software engineering, system safety, and software assurance, that provide a systematic approach to identifying, analyzing, tracking, mitigating, and controlling hazards and hazardous functions of a system where software may contribute either to the hazard(s) or to its detection, mitigation or control, to ensure safe operation of the system.

Software Validation. (1)confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled (2) process of providing evidence that the system, software, or hardware and its associated products satisfy requirements allocated to it at the end of each life cycle activity, solve the right problem (e.g., correctly model physical laws, implement business rules, and use the proper system assumptions), and satisfy intended use and user needs (3) the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders (4) process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements (5) confirmation in a timely manner, through automated techniques where possible, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled. (Source IEEE Definition)

Note: Validation in a system life cycle context is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals, and objectives (meet stakeholder requirements) in the intended operational environment. The right system has been built or is operating to meet business objectives. Validation demonstrates that the system can be used by the users for their specific tasks. "Validated" is used to designate the corresponding status. Multiple Validation can be carried out if there are different intended uses.

NASA-STD-8739.8B
18 of 70
Software Verification. Confirmation that products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.” (Source IEEE Definition)

Supplier. Any organization which provides a product or service to a customer. By this definition, suppliers may include vendors, subcontractors, contractors, flight programs/projects, and the NASA organization supplying science data to a principal investigator. The classical definition of a supplier is a subcontractor, at any tier, performing contract services or producing the contract articles for a contractor. (Source NASA-HDBK-8709.22)
System Safety. Application of engineering and management principles, criteria, and techniques to optimize safety and reduce risks within the constraints of operational effectiveness, time, and cost.

Tailoring. The process used to adjust a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). Tailoring may result in changes, subtractions, or additions to a typical implementation of the requirement. (Source NPR 7150.2)

Track. To follow and note the course or progress of the product.

3. Independent Verification & Validation Requirements

3.1 IV&V Overview

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

Three parameters define the independence of IV&V: technical independence, managerial independence, and financial independence.

Technical independence requires that the personnel performing the IV&V analysis are not involved in the development of the system or its elements. The IV&V team establishes an understanding of the problem and how the system addresses the problem. Through technical independence, the IV&V team’s different perspective allows it to detect subtle errors overlooked by personnel focused on developing the system.
Managerial independence requires that the personnel performing the IV&V analysis are not in the same organization as the development and program management team. Managerial independence also means that the IV&V team makes its own decisions about which segments of the system and its software to analyze and test, chooses the IV&V analysis methods to apply, and defines the IV&V schedule of activities. While independent from the development and program management organization, the IV&V team provides its findings in a timely manner to both of those organizations. The submission of findings to the program management organization should not include any restrictions (e.g., requiring the approval of the development organization) or any other adverse pressures from the development group.
Financial independence requires that the control of the IV&V budget be vested in a group independent of the software development organization. Financial independence does not necessarily mean that the IV&V team controls the budget but that the finances should be structured so that funding is available for the IV&V team to complete its analysis or test work. No adverse financial pressure or influence is applied.

The IV&V process starts early in the software development life cycle, providing feedback to the IV&V provider organization, allowing the IV&V team to modify products at optimal timeframes and in a timely fashion, thereby reducing overall project risk. The feedback also answers project stakeholders’ questions about system properties (correctness, robustness, safety, security, etc.) to make informed decisions with respect to the development and acceptance of the system and its software.

The IV&V provider performs two primary activities, often concurrently: verification and validation. Each of the activities provides a different perspective on the system/software.

Verification is the process of evaluating a system and its software to provide objective evidence as to whether or not a product conforms to the build-to requirements and design specifications. Verification holds from the requirements through the design and code and into testing. Verification demonstrates that the products of a given development phase satisfy the conditions imposed at the start of or during that phase.Validation develops objective evidence that shows that the content of the engineering artifact is the right content for the developed system/software.

The content is accurate and correct if the objective evidence demonstrates that it satisfies the system requirements (e.g., user needs, stakeholder needs, etc.), fully describes the required capability/functionality needed, and solves the right problem.

The main goal of the IV&V effort is to identify and generate objective evidence that supports the correct operation of the system or refutes the correct operation of the system. The IV&V provider typically works with the development team to understand this objective evidence, which provides artifacts such as concept studies, operations concepts, and requirements that define the overall project. The IV&V provider uses these materials to develop an independent understanding of the project’s commitment to NASA, which forms the basis for validating lower-level technical artifacts.

Two principles help guide the development and use of objective evidence.

Performing IV&V throughout the entire development lifetime is the first principle; potential problems should be detected as early as possible in the development life Performing IV&V throughout the entire development lifetime provides the IV&V team with sufficient information to establish a basis for the analysis results and provides early objective evidence to the development and program management groups to help keep the development effort on track early in the life cycle.
The second principle is “appropriate assurance.” Given that it is not possible to provide IV&V on all aspects of a project’s software, the IV&V provider and project should balance risks against available resources to define an IV&V program for each project that provides IV&V so that the software will operate correctly, safely, reliably, and securely throughout its operational lifetime. The IPEP documents this tailored approach and summarizes the cost/benefit trade-offs made in the scoping process.

The IV&V requirements are analyzed and partitioned according to the type of artifact. The requirements do not imply or require the use of any specific life cycle model. It is also important to understand that IV&V applies to any life cycle development process. The IV&V requirements document the potential scope of analysis performed by the IV&V provider and the key responsibility of the software project to provide the information needed to perform that analysis. Additionally, the risk assessment is used to scope the IV&V analysis to help determine the prioritization of activities and the level of rigor associated with performing those activities. The scoping exercise results are captured in the IV&V Project Execution Plan, as documented below.

3.2 IV&V Requirements

The responsible project manager shall ensure the performance of the IV&V requirements, as defined in section 4.4.2 of this standard. The IV&V requirements in this section of the standard apply to any project required to have IV&V per the criteria defined in the NASA Software Engineering Requirements, NPR 7150.2. The IV&V requirements apply to all IV&V efforts performed on a software development project, as tailored by the IV&V Project Execution Plan. The IV&V requirements also serve as the definition of what NASA considers IV&V. IV&V is a risk mitigation activity, and as such, the application of IV&V analysis and the rigor of that analysis is driven by the IV&V provider’s assessment of software risk.

4.4.2.1 The IV&V provider shall conduct planning and risk assessments to determine the specific system/software behaviors (including the software components responsible for implementing the behaviors) to be analyzed.

Div

id	tabs-4

4. SOFTWARE ASSURANCE AND SOFTWARE SAFETY REQUIREMENTS

Include Page

	8739.8B Para 4.1
	8739.8B Para 4.1

Include Page

	8739.8B Para 4.2
	8739.8B Para 4.2

Note
See Appendix A for guidelines associated with addressing software in hazard definitions. See Table 1, 3.7.1, SWE-205 for more details. Consideration for other independent means of protection (software, hardware, barriers, or administrative) should be a part of the system hazard definition process.

4.3 Software Assurance and Software Safety Requirements

4.3.1 The responsible project manager shall ensure the performance of the software assurance, software safety, and IV&V activities, the applicable requirements are defined in Table 1.

Show If

spacePermission	edit

Panel

borderColor	red
titleColor	red
title	Visible to editors only

Requirements content from NPR 7150.2D
Tasking content from NASA-STD-8739.8B

Software Assurance and Software Safety Requirements

The responsible project manager shall ensure the performance of the software assurance, software safety, and IV&V activities, the applicable requirements are defined in Table 1. In this document, the phrase “Software Assurance and Software Safety Tasks” means that the roles and responsibilities for completing these requirements may be delegated within the project consistent with the scope and scale of the project. The Center SMA Director designates SMA TA(s) for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency software assurance, software safety, and IV&V activities.

Table 1. Software Assurance and Software Safety Requirements Mapping Matrix

NPR 7150.2 Section

SWE #

NPR 7150.2 Requirement

NASA-STD-8729.8 Software Assurance and Software Safety Tasks

3 Software Management Requirements

3.1 Software Life-Cycle Planning

3.1.2

033

Excerpt Include

SWEHBVD:SWE-033 - Acquisition vs. Development Assessment

nopanel

true

Include Page

SWEHBVD:SWE-033 - Notes

Include Page

SWE-033 - SA Task1

Include Page

SWE-033 - SA Task2

Include Page

SWE-033 - SA Task3

3.1.3

013

Excerpt Include

SWEHBVD:SWE-013 - Software Plans

nopanel

true

Include Page

SWE-013 - SA Task1

Include Page

SWE-013 - SA Task2

3.1.4

024

Excerpt Include

SWEHBVD:SWE-024 - Plan Tracking

nopanel

true

Include Page

SWE-024 - SA Task1

Include Page

SWE-024 - SA Task2

Include Page

SWE-024 - SA Task3

3.1.5

034

Excerpt Include

SWEHBVD:SWE-034 - Acceptance Criteria

nopanel

true

Include Page

SWE-034 - SA Task1

3.1.6

036

Excerpt Include

SWEHBVD:SWE-036 - Software Process Determination

nopanel

true

Include Page

SWE-036 - SA Task1

Include Page

SWE-036 - SA Task2

3.1.7

037

Excerpt Include

SWEHBVD:SWE-037 - Software Milestones

nopanel

true

Include Page

SWE-037 - SA Task1

Include Page

SWE-037 - SA Task2

3.1.8

039

Excerpt Include

SWEHBVD:SWE-039 - Software Supplier Insight

nopanel

true

Include Page

SWE-039 - SA Task1

Include Page

SWE-039 - SA Task2

Include Page

SWE-039 - SA Task3

Include Page

SWE-039 - SA Task4

Include Page

SWE-039 - SA Task5

Include Page

SWE-039 - SA Task6

Include Page

SWE-039 - SA Task7

Include Page

SWE-039 - SA Task8

3.1.9

040

Excerpt Include

SWEHBVD:SWE-040 - Access to Software Products

nopanel

true

Include Page

SWE-040 - SA Task1

3.1.10

042

Excerpt Include

SWEHBVD:SWE-042 - Source Code Electronic Access

nopanel

true

Include Page

SWE-042 - SA Task1

3.1.11

139

Excerpt Include

SWEHBVD:SWE-139 - Shall Statements

nopanel

true

Include Page

SWE-139 - SA Task1

3.1.12

121

Excerpt Include

SWEHBVD:SWE-121 - Document Tailored Requirements

nopanel

true

Include Page

SWE-121 - SA Task1

Include Page

SWE-121 - SA Task2

3.1.13

125

Excerpt Include

SWEHBVD:SWE-125 - Requirements Compliance Matrix

nopanel

true

Include Page

SWE-125 - SA Task1

Include Page

SWE-125 - SA Task2

3.1.14

027

Excerpt Include

SWEHBVD:SWE-027 - Use of Commercial, Government, and Legacy Software

nopanel

true

Include Page

SWE-027 - SA Task1

3.2 Software Cost Estimation

3.2.1

015

Excerpt Include

SWEHBVD:SWE-015 - Cost Estimation

nopanel

true

Include Page

SWE-015 - SA Task1

3.2.2

151

Excerpt Include

SWEHBVD:SWE-151 - Cost Estimate Conditions

nopanel

true

Include Page

SWE-151 - SA Task1

3.2.3

174

Excerpt Include

SWEHBVD:SWE-174 - Software Planning Parameters

nopanel

true

Include Page

SWE-174 - SA Task1

Include Page

SWE-174 - SA Task2

3.3 Software Schedules

3.3.1

016

Excerpt Include

SWEHBVD:SWE-016 - Software Schedule

nopanel

true

Include Page

SWE-016 - SA Task1

Include Page

SWE-016 - SA Task2

3.3.2

018

Excerpt Include

SWEHBVD:SWE-018 - Software Activities Review

nopanel

true

Include Page

SWE-018 - SA Task1

Include Page

SWE-018 - SA Task2

3.3.3

046

Excerpt Include

SWEHBVD:SWE-046 - Supplier Software Schedule

nopanel

true

Include Page

SWE-046 - SA Task1

3.4 Software Training

3.4.1

017

Excerpt Include

SWEHBVD:SWE-017 - Project and Software Training

nopanel

true

Include Page

SWE-017 - SA Task1

Include Page

SWE-017 - SA Task2

3.5 Software Classification Assessments

3.5.1

020

Excerpt Include

SWEHBVD:SWE-020 - Software Classification

nopanel

true

Include Page

SWE-020 - SA Task1

3.5.2

176

Excerpt Include

SWEHBVD:SWE-176 - Software Records

nopanel

true

Include Page

SWE-176 - SA Task1

3.6 Software Assurance and Software
Independent Verification & Validation

3.6.1

022

Excerpt Include

SWEHBVD:SWE-022 - Software Assurance

nopanel

true

Include Page

SWE-022 - SA Task1

3.6.2

141

Excerpt Include

SWEHBVD:SWE-141 - Software Independent Verification and Validation

nopanel

true

Include Page

SWE-141 - SA Task1

3.6.3

131

Excerpt Include

SWEHBVD:SWE-131 - Independent Verification and Validation Project Execution Plan

nopanel

true

Include Page

SWE-131 - SA Task1

3.6.4

178

Excerpt Include

SWEHBVD:SWE-178 - IV&V Artifacts

nopanel

true

Include Page

SWE-178 - SA Task1

3.6.5

179

Excerpt Include

SWEHBVD:SWE-179 - IV&V Submitted Issues and Risks

nopanel

true

Include Page

SWE-179 - SA Task1

3.7 Safety-Critical and Mission Critical Software

3.7.1

205

Excerpt Include

SWEHBVD:SWE-205 - Determination of Safety-Critical Software

nopanel

true

Include Page

SWE-205 - SA Task1

Include Page

SWE-205 - SA Task2

Include Page

SWE-205 - SA Task3

Include Page

SWE-205 - SA Task4

Include Page

SWE-205 - SA Task5

3.7.2

023

Excerpt Include

SWEHBVD:SWE-023 - Software Safety-Critical Requirements

nopanel

true

Include Page

SWE-023 - SA Task1

3.7.3

134

Excerpt Include

SWEHBVD:SWE-134 - Safety-Critical Software Design Requirements

nopanel

true

Include Page

SWE-134 - SA Task1

Include Page

SWE-134 - SA Task2

Include Page

SWE-134 - SA Task3

Include Page

SWE-134 - SA Task4

Include Page

SWE-134 - SA Task5

Include Page

SWE-134 - SA Task6

3.7.4

219

Excerpt Include

SWEHBVD:SWE-219 - Code Coverage for Safety Critical Software

nopanel

true

Include Page

SWE-219 - SA Task1

3.7.5

220

Excerpt Include

SWEHBVD:SWE-220 - Cyclomatic Complexity for Safety-Critical Software

nopanel

true

Include Page

SWE-220 - SA Task1

Include Page

SWE-220 - SA Task2

3.8 Automatic Generation of Software Source Code

3.8.1

146

Excerpt Include

SWEHBVD:SWE-146 - Auto-generated Source Code

nopanel

true

Include Page

SWE-146 - SA Task1

3.8.2

206

Excerpt Include

SWEHBVD:SWE-206 - Auto-Generation Software Inputs

nopanel

true

Include Page

SWE-206 - SA Task1

3.9 Software Development Processes and Practices

3.9.2

032

Excerpt Include

SWEHBVD:SWE-032 - CMMI Levels for Class A and B Software

nopanel

true

Include Page

SWE-032 - SA Task1

Include Page

SWE-032 - SA Task2

Include Page

SWE-032 - SA Task3

3.10 Software Reuse

3.10.1

147

Excerpt Include

SWEHBVD:SWE-147 - Specify Reusability Requirements

nopanel

true

Include Page

SWE-147 - SA Task1

3.10.2

148

Excerpt Include

SWEHBVD:SWE-148 - Contribute to Agency Software Catalog

nopanel

true

Include Page

SWE-148 - SA Task1

3.11 Software Cybersecurity

3.11.2

156

Excerpt Include

SWEHBVD:SWE-156 - Evaluate Systems for Security Risks

nopanel

true

Include Page

SWE-156 - SA Task1

3.11.3

154

Excerpt Include

SWEHBVD:SWE-154 - Identify Security Risks

nopanel

true

Include Page

SWE-154 - SA Task1

3.11.4

157

Excerpt Include

SWEHBVD:SWE-157 - Protect Against Unauthorized Access

nopanel

true

Include Page

SWE-157 - SA Task1

3.11.5

159

Excerpt Include

SWEHBVD:SWE-159 - Verify and Validate Risk Mitigations

nopanel

true

Include Page

SWE-159 - SA Task1

Include Page

SWE-159 - SA Task2

3.11.6

207

Excerpt Include

SWEHBVD:SWE-207 - Secure Coding Practices

nopanel

true

Include Page

SWE-207 - SA Task1

3.11.7

185

Excerpt Include

SWEHBVD:SWE-185 - Secure Coding Standards Verification

nopanel

true

Include Page

SWE-185 - SA Task1

3.11.8

210

Excerpt Include

SWEHBVD:SWE-210 - Detection of Adversarial Actions

nopanel

true

Include Page

SWE-210 - SA Task1

3.12 Software Bi-Directional Traceability

3.12.1

052

Excerpt Include

SWEHBVD:SWE-052 - Bidirectional Traceability

nopanel

true

Include Page

SWE-052 - SA Task1

Include Page

SWE-052 - SA Task2

4 Software Engineering (Life Cycle) Requirements

4.1 Software Requirements

4.1.2

050

Excerpt Include

SWEHBVD:SWE-050 - Software Requirements

nopanel

true

Include Page

SWE-050 - SA Task1

4.1.3

051

Excerpt Include

SWEHBVD:SWE-051 - Software Requirements Analysis

nopanel

true

Include Page

SWE-051 - SA Task1

4.1.4

184

Excerpt Include

SWEHBVD:SWE-184 - Software-related Constraints and Assumptions

nopanel

true

Include Page

SWE-184 - SA Task1

4.1.5

053

Excerpt Include

SWEHBVD:SWE-053 - Manage Requirements Changes

nopanel

true

Include Page

SWE-053 - SA Task1

4.1.6

054

Excerpt Include

SWEHBVD:SWE-054 - Corrective Action for Inconsistencies

nopanel

true

Include Page

SWE-054 - SA Task1

4.1.7

055

Excerpt Include

SWEHBVD:SWE-055 - Requirements Validation

nopanel

true

Include Page

SWE-055 - SA Task1

4.2 Software Architecture

4.2.3

057

Excerpt Include

SWEHBVD:SWE-057 - Software Architecture

nopanel

true

Include Page

SWE-057 - SA Task1

Include Page

SWE-057 - SA Task2

4.2.4

143

Excerpt Include

SWEHBVD:SWE-143 - Software Architecture Review

nopanel

true

Include Page

SWE-143 - SA Task1

4.3 Software Design

4.3.2

058

Excerpt Include

SWEHBVD:SWE-058 - Detailed Design

nopanel

true

Include Page

SWE-058 - SA Task1

Include Page

SWE-058 - SA Task2

Include Page

SWE-058 - SA Task3

Include Page

SWE-058 - SA Task4

Include Page

SWE-058 - SA Task5

4.4 Software Implementation

4.4.2

060

Excerpt Include

SWEHBVD:SWE-060 - Coding Software

nopanel

true

Include Page

SWE-060 - SA Task1

Include Page

SWE-060 - SA Task2

4.4.3

061

Excerpt Include

SWEHBVD:SWE-061 - Coding Standards

nopanel

true

Include Page

SWE-061 - SA Task1

Include Page

SWE-061 - SA Task2

4.4.4

135

Excerpt Include

SWEHBVD:SWE-135 - Static Analysis

nopanel

true

Include Page

SWE-135 - SA Task1

Include Page

SWE-135 - SA Task2

Include Page

SWE-135 - SA Task3

Include Page

SWE-135 - SA Task4

Include Page

SWE-135 - SA Task5

Include Page

SWE-135 - SA Task6

Include Page

SWE-135 - SA Task7

4.4.5

062

Excerpt Include

SWEHBVD:SWE-062 - Unit Test

nopanel

true

Include Page

SWE-062 - SA Task1

Include Page

SWE-062 - SA Task2

4.4.6

186

Excerpt Include

SWEHBVD:SWE-186 - Unit Test Repeatability

nopanel

true

Include Page

SWE-186 - SA Task1

4.4.7

063

Excerpt Include

SWEHBVD:SWE-063 - Release Version Description

nopanel

true

Include Page

SWE-063 - SA Task1

Include Page

SWE-063 - SA Task2

4.4.8

136

Excerpt Include

SWEHBVD:SWE-136 - Software Tool Accreditation

nopanel

true

Include Page

SWE-136 - SA Task1

4.5 Software Testing

4.5.2

065a

Include Page

SWEHBVD:SWE-065a

Include Page

SWE-065a - SA Task1

Include Page

SWE-065a - SA Task2

4.5.2

065b

Include Page

SWEHBVD:SWE-065b

Include Page

SWE-065b - SA Task1

Include Page

SWE-065b - SA Task2

4.5.2

065c

Include Page

SWEHBVD:SWE-065c

Include Page

SWE-065c - SA Task1

Include Page

SWE-065c - SA Task2

Include Page

SWE-065c - SA Task3

4.5.2

065d

Include Page

SWEHBVD:SWE-065d

Include Page

SWE-065d - SA Task1

Include Page

SWE-065d - SA Task2

Include Page

SWE-065d - SA Task3

Include Page

SWE-065d - SA Task4

4.5.3

066

Excerpt Include

SWEHBVD:SWE-066 - Perform Testing

nopanel

true

Include Page

SWE-066 - SA Task1

Include Page

SWE-066 - SA Task2

Include Page

SWE-066 - SA Task3

4.5.4

187

Excerpt Include

SWEHBVD:SWE-187 - Control of Software Items

nopanel

true

Include Page

SWE-187 - SA Task1

Include Page

SWE-187 - SA Task2

4.5.5

068

Excerpt Include

SWEHBVD:SWE-068 - Evaluate Test Results

nopanel

true

Include Page

SWE-068 - SA Task1

Include Page

SWE-068 - SA Task2

Include Page

SWE-068 - SA Task3

4.5.6

070

Excerpt Include

SWEHBVD:SWE-070 - Models, Simulations, Tools

nopanel

true

Include Page

SWE-070 - SA Task1

4.5.7

071

Excerpt Include

SWEHBVD:SWE-071 - Update Test Plans and Procedures

nopanel

true

Include Page

SWE-071 - SA Task1

4.5.8

073

Excerpt Include

SWEHBVD:SWE-073 - Platform or Hi-Fidelity Simulations

nopanel

true

Include Page

SWE-073 - SA Task1

4.5.9

189

Excerpt Include

SWEHBVD:SWE-189 - Code Coverage Measurements

nopanel

true

Include Page

SWE-189 - SA Task1

4.5.10

190

Excerpt Include

SWEHBVD:SWE-190 - Verify Code Coverage

nopanel

true

Include Page

SWE-190 - SA Task1

Include Page

SWE-190 - SA Task2

Include Page

SWE-190 - SA Task3

4.5.11

191

Excerpt Include

SWEHBVD:SWE-191 - Software Regression Testing

nopanel

true

Include Page

SWE-191 - SA Task1

Include Page

SWE-191 - SA Task2

Include Page

SWE-191 - SA Task3

Include Page

SWE-191 - SA Task4

4.5.12

192

Excerpt Include

SWEHBVD:SWE-192 - Software Hazardous Requirements

nopanel

true

Include Page

SWE-192 - SA Task1

4.5.13

193

Excerpt Include

SWEHBVD:SWE-193 - Acceptance Testing for Affected System and Software Behavior

nopanel

true

Include Page

SWE-193 - SA Task1

Include Page

SWE-193 - SA Task2

Include Page

SWE-193 - SA Task3

4.5.14

211

Excerpt Include

SWEHBVD:SWE-211 - Test Levels of Non-Custom Developed Software

nopanel

true

Include Page

SWE-211 - SA Task1

4.6 Software Operations, Maintenance, and Retirement

4.6.2

075

Excerpt Include

SWEHBVD:SWE-075 - Plan Operations, Maintenance, Retirement

nopanel

true

Include Page

SWE-075 - SA Task1

Include Page

SWE-075 - SA Task2

4.6.3

077

Excerpt Include

SWEHBVD:SWE-077 - Deliver Software Products

nopanel

true

Include Page

SWE-077 - SA Task1

Include Page

SWE-077 - SA Task2

4.6.4

194

Excerpt Include

SWEHBVD:SWE-194 - Delivery Requirements Verification

nopanel

true

Include Page

SWE-194 - SA Task1

Include Page

SWE-194 - SA Task2

Include Page

SWE-194 - SA Task3

Include Page

SWE-194 - SA Task4

Include Page

SWE-194 - SA Task5

Include Page

SWE-194 - SA Task6

4.6.5

195

Excerpt Include

SWEHBVD:SWE-195 - Software Maintenance Phase

nopanel

true

Include Page

SWE-195 - SA Task1

4.6.6

196

Excerpt Include

SWEHBVD:SWE-196 - Software Retirement Archival

nopanel

true

Include Page

SWE-196 - SA Task1

Include Page

SWE-196 - SA Task2

5 Supporting Software Life Cycle Requirements

5.1 Software Configuration Management

5.1.2

079

Excerpt Include

SWEHBVD:SWE-079 - Develop CM Plan

nopanel

true

Include Page

SWE-079 - SA Task1

5.1.3

080

Excerpt Include

SWEHBVD:SWE-080 - Track and Evaluate Changes

nopanel

true

Include Page

SWE-080 - SA Task1

Include Page

SWE-080 - SA Task2

Include Page

SWE-080 - SA Task3

5.1.4

081

Excerpt Include

SWEHBVD:SWE-081 - Identify Software CM Items

nopanel

true

Include Page

SWE-081 - SA Task1

Include Page

SWE-081 - SA Task2

5.1.5

082

Excerpt Include

SWEHBVD:SWE-082 - Authorizing Changes

nopanel

true

Include Page

SWE-082 - SA Task1

Include Page

SWE-082 - SA Task2

5.1.6

083

Excerpt Include

SWEHBVD:SWE-083 - Status Accounting

nopanel

true

Include Page

SWE-083 - SA Task1

5.1.7

084

Excerpt Include

SWEHBVD:SWE-084 - Configuration Audits

nopanel

true

Include Page

SWE-084 - SA Task1

5.1.8

085

Excerpt Include

SWEHBVD:SWE-085 - Release Management

nopanel

true

Include Page

SWE-085 - SA Task1

Include Page

SWE-085 - SA Task2

5.1.9

045

Excerpt Include

SWEHBVD:SWE-045 - Project Participation in Audits

nopanel

true

Include Page

SWE-045 - SA Task1

5.2 Software Risk Management

5.2.1

086

Excerpt Include

SWEHBVD:SWE-086 - Continuous Risk Management

nopanel

true

Include Page

SWE-086 - SA Task1

Include Page

SWE-086 - SA Task2

5.3 Software Peer Reviews/Inspections

5.3.2

087

Excerpt Include

SWEHBVD:SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures

nopanel

true

Include Page

SWE-087 - SA Task1

Include Page

SWE-087 - SA Task2

Include Page

SWE-087 - SA Task3

Include Page

SWE-087 - SA Task4

5.3.3

088

Excerpt Include

SWEHBVD:SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking

nopanel

true

Include Page

SWE-088 - SA Task1

Include Page

SWE-088 - SA Task2

Include Page

SWE-088 - SA Task3

5.3.4

089

Excerpt Include

SWEHBVD:SWE-089 - Software Peer Reviews and Inspections - Basic Measurements

nopanel

true

Include Page

SWE-089 - SA Task1

5.4 Software Measurements

5.4.2

090

Excerpt Include

SWEHBVD:SWE-090 - Management and Technical Measurements

nopanel

true

Include Page

SWE-090 - SA Task1

Include Page

SWE-090 - SA Task2

Include Page

SWE-090 - SA Task3

5.4.3

093

Excerpt Include

SWEHBVD:SWE-093 - Analysis of Measurement Data

nopanel

true

Include Page

SWE-093 - SA Task1

Include Page

SWE-093 - SA Task2

5.4.4

094

Excerpt Include

SWEHBVD:SWE-094 - Reporting of Measurement Analysis

nopanel

true

Include Page

SWE-094 - SA Task1

5.4.5

199

Excerpt Include

SWEHBVD:SWE-199 - Performance Measures

nopanel

true

Include Page

SWE-199 - SA Task1

Include Page

SWE-199 - SA Task2

5.4.6

200

Excerpt Include

SWEHBVD:SWE-200 - Software Requirements Volatility Metrics

nopanel

true

Include Page

SWE-200 - SA Task1

Include Page

SWE-200 - SA Task2

5.5 Software Non-conformance or Defect Management

5.5.1

201

Excerpt Include

SWEHBVD:SWE-201 - Software Non-Conformances

nopanel

true

Include Page

SWE-201 - SA Task1

Include Page

SWE-201 - SA Task2

5.5.2

202

Excerpt Include

SWEHBVD:SWE-202 - Software Severity Levels

nopanel

true

Include Page

SWE-202 - SA Task1

Include Page

SWE-202 - SA Task2

Include Page

SWE-202 - SA Task3

Include Page

SWE-202 - SA Task4

5.5.3

203

Excerpt Include

SWEHBVD:SWE-203 - Mandatory Assessments for Non-Conformances

nopanel

true

Include Page

SWE-203 - SA Task1

Include Page

SWE-203 - SA Task2

5.5.4

204

Excerpt Include

SWEHBVD:SWE-204 - Process Assessments

nopanel

true

Include Page

SWE-204 - SA Task1

Include Page

SWE-204 - SA Task2

Include Page

SWE-204 - SA Task3

Include Page

SWE-204 - SA Task4

Div

id	tabs-5

Note

IV&V is a focused activity that prioritizes IV&V analysis to address the highest developmental and operational software risks. IV&V priority is based on the combination of the potential for software impacts on safety and mission success and the probability factors for latent defects. IV&V analysis activities provide coverage with a degree of rigor that reflects the priority level. The initial planning and scoping effort based on the risk assessment define the starting point for the IV&V analysis. During the life cycle of each IV&V project, continuous and iterative feedback, through the execution of analysis, identification of issues and risks, and the collection of deeper mission understanding, allows IV&V projects to “Follow The Risk” and adjust plans. The planning and scoping effort also aid in establishing the initial relationships between the IV&V provider, the Acquirer, and the Provider.

4.4.2.2 The IV&V provider shall develop and negotiate an IV&V IPEP with the project.

Note

The 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. A Provider should use a documented analysis approach to track and manage the IV&V effort aligned with ongoing development project efforts. The IPEP documents which software products are subject to which analyses and which analysis requirements are wholly, partially, or not applied following the risk assessment and resource constraints. The IPEP also serves as a communication tool between the project and IV&V to set expectations for the IV&V products produced throughout the life The IPEP may require updating throughout the life cycle.

4.4.2.3 The Project SMA Technical Authority (TA) shall review and concur with the IPEP.

4.4.2.4 The IV&V provider shall provide analysis results, risks, and assurance statements and data to the responsible organizations’ project management, engineering, and software assurance personnel.

Note

While independent, the IV&V provider is still a part of a project's overall safety and risk mitigation software assurance strategy. The results of IV&V analysis need to be incorporated into the overall software assurance assessment of the project and provided to the project management. The IV&V provider should support project milestone reviews and provide the project with an evaluation of the life cycle review artifacts to assist development management decisions on whether the review criteria have been met and how to proceed going forward.

4.4.2.5 The IV&V provider shall participate in project reviews of software activities. Participation includes providing status and results of software IV&V activities including, but not limited to, upcoming analysis activities, artifacts needed from the project, the results of the current or completed analysis, defects, and risks to stakeholders, customers, and development project personnel.

Note

The most significant positive impact of IV&V analysis is when the analysis results are in phase with the development effort. Communicating defects after development artifacts are baselined increases the cost to make the changes. Additionally, the inclusion of the IV&V provider in ongoing technical meetings keeps the IV&V provider informed of possible changes that may affect future IV&V tasking. Supporting the ongoing technical meetings allows the IV&V Provider an opportunity to provide real-time feedback on these changes.

4.4.2.6 The IV&V provider shall provide the responsible organizations’ project management, engineering, and software assurance personnel insight into the software IV&V and IV&V test activities. As a minimum, the IV&V provider will be required to allow the responsible organizations’ project management, engineering, and software assurance personnel to perform the following activities:

Monitor the IV&V activities and plans.

Review the verification activities to ensure adequacy.

Review IV&V studies and source data.

Audit the software IV&V processes and practices.

Participate in IV&V software reviews and technical interchange meetings

4.4.2.7 The IV&V provider shall participate in planned software peer reviews or software inspections guided by the planning and scoping risk analysis documented in the IPEP and NASA-HDBK-2203.

Note
The IV&V provider should be involved in the review/inspection process for all system/software items within the scope of their analysis.

4.4.2.8 The IV&V provider shall establish, record, maintain, report, and utilize IV&V management and technical measurements.

Note
The IV&V provider gathers and analyzes metrics on a periodic basis to perform continuous improvement of IV&V processes and identify indicators of IV&V and project risks.

4.4.2.9 The IV&V provider shall assess and track software activities' actual results and performance against the software plans and identify and report any risks or findings to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.10 The IV&V provider shall track and evaluate changes to software products to evaluate for possible changes in the IV&V provider’s risk analysis and potential adverse impacts to the software system and the development effort.

4.4.2.11 The IV&V provider shall assess the software development life cycle for suitability for the problem to be solved and identify and communicate any risks associated with the chosen life cycle to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.12 The IV&V provider shall identify, analyze, track, and record risks to the software and development project in accordance with NPR 8000.4, Agency Risk Management Procedural Requirements, and communicate the risks to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.13 The IV&V provider shall verify the project implements the requirements for software listed in NPR 7150.2 and communicate any risks to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.14 The IV&V provider shall track, record, and communicate defects/issues and other results found during the execution of IV&V analysis and independent IV&V testing to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.15 The IV&V provider shall ensure that the identified defects and issues are addressed by the project.

4.4.2.16 The IV&V provider shall ensure that software planned for reuse meets the fit, form, and function as a component within the new application.

4.4.2.17 The IV&V provider shall ensure that the system architecture contains the computing-related items (subsystems, components, etc.) to carry out the system's mission and satisfy user needs and operational scenarios or use cases.

4.4.2.18 The IV&V provider shall ensure that the basis for the computing-related functions reflects the planned operations and mission objectives.

4.4.2.19 The IV&V provider shall ensure that feasibility and trade studies provide the results to support the critical decisions that drove the need for the study.

4.4.2.20 The IV&V provider shall ensure that known software-based hazard causes, contributors, and controls are identified, documented, and traced to the project requirements.

4.4.2.21 The IV&V provider shall ensure that known security threats and risks are identified, appropriately documented, and updated throughout the software development life cycle and communicated to the responsible organizations’ project management, engineering, and software assurance personnel.

4.4.2.22 The IV&V provider shall verify and validate that the software requirements and system requirements are, as a minimum, correct, consistent, complete, accurate, readable, traceable, and testable.

Note
Software usually provides the interface between the user and the system hardware and the interface between system hardware components and other systems. These interfaces are critical to the successful operation and use of the system.

4.4.2.23 The IV&V provider shall verify and validate that the mitigations for identified security risks are in the software requirements.

Note
Security is an essential aspect of any system development effort. In most systems, software provides the primary user interface. The user interface is an element of the system that can provide undesired access. A system concept design should address known security risks through various features in the system.

4.4.2.24 The IV&V provider shall ensure that software requirements meet the dependability and fault tolerance required by the system.

4.4.2.25 The IV&V provider shall ensure that software requirements provide the capability of controlling identified hazards and do not create hazardous conditions.

4.4.2.26 The IV&V provider shall verify and validate that the relationship between the in-scope system/software requirements and the associated architectural elements is traceable, correct, consistent, and complete.

Note
Architectural elements are responsible for implementing specific behaviors within the software and the overall system. The interactions between these architectural elements result in the realization of the desired behaviors as well as possible undesired behaviors.

4.4.2.27 The IV&V provider shall verify and validate that the software architecture meets the user’s safety and mission-critical needs as defined in the requirements.

Note
The architecture provides the foundation for the development of the software. It also significantly impacts how the software deals with faults and failures and how the software interfaces with the user and system components. Analysis of the architecture provides early insight into how the software is structured and how that structure can implement the requirements.

4.4.2.28 The IV&V provider shall verify and validate that the detailed design products are traceable, consistent, complete, accurate, and testable.

Note

Detailed design is the implementation of the algorithms that control and monitor the different parts of the system and allow for interaction between the system and the user and other systems. The detailed design defines how the architectural components behave to support the interactions defined in the architecture. Analysis of the detailed design includes looking at the low-level software components in the software system.

4.4.2.29 The IV&V provider shall verify and validate that the interfaces between the detailed design components and the hardware, users, operators, other software, and external systems are correct, consistent, complete, accurate, and testable.

Note
While the architecture defines the interactions between the architectural elements, each element is generally composed of lower-level components defined by the detailed design. The interfaces between these components are important in ensuring that the architectural element meets its assigned responsibilities.

4.4.2.30 The IV&V provider shall verify and validate that the relationship between the software requirements and the associated detailed design components is correct, consistent, and complete.

Note
The detailed design components capture the approach to implementing the software requirements, including the requirements associated with fault management, security, and safety. Analysis of the relationship between the detailed design and the software requirements provides evidence that all requirements are in the detailed design.

4.4.2.31 The IV&V provider shall verify and validate that the software code and data products are consistent with architecture, complete with respect to requirements, and testable.

4.4.2.32 The IV&V provider shall verify and validate that the software code meets the industry best practices and software coding standards.

4.4.2.33 The IV&V provider shall verify and validate that the security risks in the software code are identified and mitigated.

Note
Note: This includes software developed by NASA, software developed for NASA, software maintained by or for NASA, COTS, GOTS, MOTS, OSS, reused software components, auto-generated code, embedded software, the software executed on processors embedded in programmable logic devices, legacy, heritage, applications, freeware, shareware, trial or demonstration software.

4.4.2.34 The IV&V provider shall verify and validate the appropriate use of off-the-shelf software, including ensuring that the project has identified all OSS used and that the security risks are identified and mitigated by the use of the off-the-shelf

4.4.2.35 The IV&V provider shall verify and validate that the project assesses the software systems for possible security vulnerabilities and weaknesses.

4.4.2.36 The IV&V provider shall verify and validate that the project implements the required software security risk mitigations to ensure that security objectives for software are satisfied.

4.4.2.37 The IV&V provider shall verify and validate the source code through the use of analysis tools (including but not limited to static, dynamic, composition, and formal analysis tools).

Note
The use of analysis tools may include the verification and validation of the analysis tools used by the development project in the process of developing the software. The results may be from static code analysis, software composition analysis, dynamic code analysis, cyclomatic complexity, or other code quality analysis tools.

4.4.2.38 The IV&V provider shall verify and validate that the relationship between the software design elements and the associated software units is correct, consistent, and complete.

4.4.2.39 The IV&V provider shall verify and validate that the relationship between software code components and corresponding requirements is correct, complete, and consistent.

Note

For all of the implementation requirements, it is with code that the development of software reaches its lowest level of abstraction and that the software capabilities are implemented. Evaluating the relationship between the source code and the design components and requirements provides evidence that only the specified requirements and components are in the system. Evaluating the relationship between the source code and the design components and requirements helps minimize one aspect of the emergence of unexpected behaviors: the inclusion of behaviors not specified in the requirements. The overall analysis of the code is essential in assuring that the code does implement the required software behaviors. From a safety perspective, it is important to evaluate the code and assure that known software safety and security issues such as buffer overflows and type mismatches, among many others, are not used in safety-critical aspects of the software.

4.4.2.40 The IV&V provider shall verify and validate that test plans, test procedures, test cases, test environment (including simulations), and test design at all levels of testing (unit, integration, system, acceptance, etc.) are correct, complete, and consistent for verification and validation of the source code and system functions allocated to the software.

4.4.2.41 The IV&V provider shall verify and validate the relationships between the test plans, test procedures, test cases, test design, source code. and system functions allocated to the software are correct, complete, and consistent.

4.4.2.42 The IV&V provider shall verify that the test plans, test cases, test design, and test procedures contain objective acceptance criteria that support the verification of the associated requirements for both nominal and off-nominal conditions.

4.4.2.43 The IV&V provider shall verify that the software test results meet the associated acceptance criteria to ensure that the software correctly implements the associated requirements.

Note

The IV&V provider assesses the testing artifacts with respect to the desired capabilities and expected operational system environment. The assessment includes an examination of testing at system boundary conditions to include unexpected conditions. The testing analysis assures that the project tests all requirements and that the system does what the requirements state it should do. The testing analysis also includes an analysis of the traceability information between the tests and the requirements.

4.4.2.44 The IV&V provider shall verify that the project tests the required software security risk mitigations to ensure that the security objectives for the software are satisfied.

4.4.2.45 The IV&V provider shall verify that code coverage is measured by analysis of the results of the execution of tests.

4.4.2.46 The IV&V provider shall verify through independent testing each of the software requirements that trace to a hazardous event, cause, or mitigation technique.

4.4.2.47 The IV&V provider shall verify the project’s acceptance tests for loaded or uplinked data, rules, and code that affects software and software system behavior.

4.4.2.48 The IV&V provider shall participate in all NASA quality audits, assessments, and reviews associated with the project.

4.4.2.49 The IV&V provider shall assess the software maintenance and operational risks concerning software elements to support the planning of IV&V activities during the maintenance phase.

Note
The approach to software development on some projects results in different parts of the software going into operation at different times in the overall project life For example, a lander mission to Mars may complete the software needed for the cruise phase to Mars while continuing to work on the entry, descent, landing, and surface operations software.

Note
In some cases, software anomalies cause changes to the software. IV&V is important because software changes can often have ripple effects throughout the system and cause emergent behaviors. The IV&V analysis provides insight into these possible effects and provides an overall assessment of the impact of the change.

Div

id	tabs-2

Include Page

	8739.8B-T1-Requirements Mapping Matrix
	8739.8B-T1-Requirements Mapping Matrix

4.4 Independent Verification & Validation Requirements

4.4.1 IV&V Overview

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

4.4.1.2 Three parameters define the independence of IV&V: technical independence, managerial independence, and financial independence.

a. Technical independence requires that the personnel performing the IV&V analysis are not involved in the development of the system or its elements. The IV&V team establishes an understanding of the problem and how the system addresses the problem. Through technical independence, the IV&V team’s different perspective allows it to detect subtle errors overlooked by personnel focused on developing the system.

b. Managerial independence requires that the personnel performing the IV&V analysis are not in the same organization as the development and program management team. Managerial independence also means that the IV&V team makes its own decisions about which segments of the system and its software to analyze and test, chooses the IV&V analysis methods to apply, and defines the IV&V schedule of activities. While independent from the development and program management organization, the IV&V team provides its findings in a timely manner to both of those organizations. The submission of findings to the program management organization should not include any restrictions (e.g., requiring the approval of the development organization) or any other adverse pressures from the development group.

c. Financial independence requires that the control of the IV&V budget be vested in a group independent of the software development organization. Financial independence does not necessarily mean that the IV&V team controls the budget but that the finances should be structured so that funding is available for the IV&V team to complete its analysis or test work. No adverse financial pressure or influence is applied.

4.4.1.3 The IV&V process starts early in the software development life cycle, providing feedback to the IV&V provider organization, allowing the IV&V team to modify products at optimal timeframes and in a timely fashion, thereby reducing overall project risk. The feedback also answers project stakeholders’ questions about system properties (correctness, robustness, safety, security, etc.) to make informed decisions with respect to the development and acceptance of the system and its software.

4.4.1.4 The IV&V provider performs two primary activities, often concurrently: verification and validation. Each of the activities provides a different perspective on the system/software.

a. Verification is the process of evaluating a system and its software to provide objective evidence as to whether or not a product conforms to the build-to requirements and design specifications. Verification holds from the requirements through the design and code and into testing. Verification demonstrates that the products of a given development phase satisfy the conditions imposed at the start of or during that phase.

b. Validation develops objective evidence that shows that the content of the engineering artifact is the right content for the developed system/software.

The content is accurate and correct if the objective evidence demonstrates that it satisfies the system requirements (e.g., user needs, stakeholder needs, etc.), fully describes the required capability/functionality needed, and solves the right problem.

4.4.1.5 The main goal of the IV&V effort is to identify and generate objective evidence that supports the correct operation of the system or refutes the correct operation of the system. The IV&V provider typically works with the development team to understand this objective evidence, which provides artifacts such as concept studies, operations concepts, and requirements that define the overall project. The IV&V provider uses these materials to develop an independent understanding of the project’s commitment to NASA, which forms the basis for validating lower-level technical artifacts.

4.4.1.6 Two principles help guide the development and use of objective evidence.

a. Performing IV&V throughout the entire development lifetime is the first principle; potential problems should be detected as early as possible in the development life Performing IV&V throughout the entire development lifetime provides the IV&V team with sufficient information to establish a basis for the analysis results and provides early objective evidence to the development and program management groups to help keep the development effort on track early in the life cycle.

b. The second principle is “appropriate assurance.” Given that it is not possible to provide IV&V on all aspects of a project’s software, the IV&V provider and project should balance risks against available resources to define an IV&V program for each project that provides IV&V so that the software will operate correctly, safely, reliably, and securely throughout its operational lifetime. The IPEP documents this tailored approach and summarizes the cost/benefit trade-offs made in the scoping process.

4.4.1.7 The IV&V requirements are analyzed and partitioned according to the type of artifact. The requirements do not imply or require the use of any specific life cycle model. It is also important to understand that IV&V applies to any life cycle development process. The IV&V requirements document the potential scope of analysis performed by the IV&V provider and the key responsibility of the software project to provide the information needed to perform that analysis. Additionally, the risk assessment is used to scope the IV&V analysis to help determine the prioritization of activities and the level of rigor associated with performing those activities. The scoping exercise results are captured in the IV&V Project Execution Plan, as documented below.

Include Page

	8739.8B 4.4.2 IV&V Requirements
	8739.8B 4.4.2 IV&V Requirements

Include Page

	8739.8B 4.5 Principles Related to Tailoring the Standard Requirements
	8739.8B 4.5 Principles Related to Tailoring the Standard Requirements

Div

id	tabs-5

Include Page

	8739.8B AppxA Text
	8739.8B AppxA Text

Include Page
8739.8B AppxA Table
8739.8B AppxA Table

Show If

spacePermission	edit

Panel

borderColor	red
titleColor	red
title	Visible to editors only

Requirements content from NPR 7150.2D
Tasking content from NASA-STD-8739.8B

Software Assurance and Software Safety Requirements

The responsible project manager shall ensure the performance of the software assurance, software safety, and IV&V activities, the applicable requirements are defined in Table 1. In this document, the phrase “Software Assurance and Software Safety Tasks” means that the roles and responsibilities for completing these requirements may be delegated within the project consistent with the scope and scale of the project. The Center SMA Director designates SMA TA(s) for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency software assurance, software safety, and IV&V

Software Assurance and Software Safety Requirements Mapping Matrix

NPR 7150.2 SectionSWE #NPR 7150.2 RequirementNASA-STD-8729.8 Software Assurance and Software Safety Tasks

3 Software Management Requirements

3.1 Software Life-Cycle Planning

3.1.2033 Excerpt IncludeSWEHBVD:SWE-033 - Acquisition vs. Development AssessmentSWEHBVD:SWE-033 - Acquisition vs. Development Assessmentnopaneltrue Include PageSWEHBVD:SWE-033 - NotesSWEHBVD:SWE-033 - Notes Include PageSWE-033 - SA Task1SWE-033 - SA Task1 Include PageSWE-033 - SA Task2SWE-033 - SA Task2 Include PageSWE-033 - SA Task3SWE-033 - SA Task33.1.3013 Excerpt IncludeSWEHBVD:SWE-013 - Software PlansSWEHBVD:SWE-013 - Software Plansnopaneltrue Include PageSWE-013 - SA Task1SWE-013 - SA Task1 Include PageSWE-013 - SA Task2SWE-013 - SA Task23.1.4024 Excerpt IncludeSWEHBVD:SWE-024 - Plan TrackingSWEHBVD:SWE-024 - Plan Trackingnopaneltrue Include PageSWE-024 - SA Task1SWE-024 - SA Task1 Include PageSWE-024 - SA Task2SWE-024 - SA Task2 Include PageSWE-024 - SA Task3SWE-024 - SA Task33.1.5034 Excerpt IncludeSWEHBVD:SWE-034 - Acceptance CriteriaSWEHBVD:SWE-034 - Acceptance Criterianopaneltrue Include PageSWE-034 - SA Task1SWE-034 - SA Task13.1.6036 Excerpt IncludeSWEHBVD:SWE-036 - Software Process DeterminationSWEHBVD:SWE-036 - Software Process Determinationnopaneltrue Include PageSWE-036 - SA Task1SWE-036 - SA Task1 Include PageSWE-036 - SA Task2SWE-036 - SA Task23.1.7037 Excerpt IncludeSWEHBVD:SWE-037 - Software MilestonesSWEHBVD:SWE-037 - Software Milestonesnopaneltrue Include PageSWE-037 - SA Task1SWE-037 - SA Task1 Include PageSWE-037 - SA Task2SWE-037 - SA Task23.1.8039 Excerpt IncludeSWEHBVD:SWE-039 - Software Supplier InsightSWEHBVD:SWE-039 - Software Supplier Insightnopaneltrue Include PageSWE-039 - SA Task1SWE-039 - SA Task1 Include PageSWE-039 - SA Task2SWE-039 - SA Task2 Include PageSWE-039 - SA Task3SWE-039 - SA Task3 Include PageSWE-039 - SA Task4SWE-039 - SA Task4 Include PageSWE-039 - SA Task5SWE-039 - SA Task5 Include PageSWE-039 - SA Task6SWE-039 - SA Task6 Include PageSWE-039 - SA Task7SWE-039 - SA Task7 Include PageSWE-039 - SA Task8SWE-039 - SA Task83.1.9040 Excerpt IncludeSWEHBVD:SWE-040 - Access to Software ProductsSWEHBVD:SWE-040 - Access to Software Productsnopaneltrue Include PageSWE-040 - SA Task1SWE-040 - SA Task13.1.10042 Excerpt IncludeSWEHBVD:SWE-042 - Source Code Electronic AccessSWEHBVD:SWE-042 - Source Code Electronic Accessnopaneltrue Include PageSWE-042 - SA Task1SWE-042 - SA Task13.1.11139 Excerpt IncludeSWEHBVD:SWE-139 - Shall StatementsSWEHBVD:SWE-139 - Shall Statementsnopaneltrue Include PageSWE-139 - SA Task1SWE-139 - SA Task13.1.12121 Excerpt IncludeSWEHBVD:SWE-121 - Document Tailored RequirementsSWEHBVD:SWE-121 - Document Tailored Requirementsnopaneltrue Include PageSWE-121 - SA Task1SWE-121 - SA Task1 Include PageSWE-121 - SA Task2SWE-121 - SA Task23.1.13125 Excerpt IncludeSWEHBVD:SWE-125 - Requirements Compliance MatrixSWEHBVD:SWE-125 - Requirements Compliance Matrixnopaneltrue Include PageSWE-125 - SA Task1SWE-125 - SA Task1 Include PageSWE-125 - SA Task2SWE-125 - SA Task23.1.14027 Excerpt IncludeSWEHBVD:SWE-027 - Use of Commercial, Government, and Legacy SoftwareSWEHBVD:SWE-027 - Use of Commercial, Government, and Legacy Softwarenopaneltrue Include PageSWE-027 - SA Task1SWE-027 - SA Task1

3.2 Software Cost Estimation

3.2.1015 Excerpt IncludeSWEHBVD:SWE-015 - Cost EstimationSWEHBVD:SWE-015 - Cost Estimationnopaneltrue Include PageSWE-015 - SA Task1SWE-015 - SA Task13.2.2151 Excerpt IncludeSWEHBVD:SWE-151 - Cost Estimate ConditionsSWEHBVD:SWE-151 - Cost Estimate Conditionsnopaneltrue Include PageSWE-151 - SA Task1SWE-151 - SA Task13.2.3174 Excerpt IncludeSWEHBVD:SWE-174 - Software Planning ParametersSWEHBVD:SWE-174 - Software Planning Parametersnopaneltrue Include PageSWE-174 - SA Task1SWE-174 - SA Task1 Include PageSWE-174 - SA Task2SWE-174 - SA Task2

3.3 Software Schedules

3.3.1016 Excerpt IncludeSWEHBVD:SWE-016 - Software ScheduleSWEHBVD:SWE-016 - Software Schedulenopaneltrue Include PageSWE-016 - SA Task1SWE-016 - SA Task1 Include PageSWE-016 - SA Task2SWE-016 - SA Task23.3.2018 Excerpt IncludeSWEHBVD:SWE-018 - Software Activities ReviewSWEHBVD:SWE-018 - Software Activities Reviewnopaneltrue Include PageSWE-018 - SA Task1SWE-018 - SA Task1 Include PageSWE-018 - SA Task2SWE-018 - SA Task23.3.3046 Excerpt IncludeSWEHBVD:SWE-046 - Supplier Software ScheduleSWEHBVD:SWE-046 - Supplier Software Schedulenopaneltrue Include PageSWE-046 - SA Task1SWE-046 - SA Task1

3.4 Software Training

3.4.1017 Excerpt IncludeSWEHBVD:SWE-017 - Project and Software TrainingSWEHBVD:SWE-017 - Project and Software Trainingnopaneltrue Include PageSWE-017 - SA Task1SWE-017 - SA Task1 Include PageSWE-017 - SA Task2SWE-017 - SA Task2

3.5 Software Classification Assessments

3.5.1020 Excerpt IncludeSWEHBVD:SWE-020 - Software Classification SWEHBVD:SWE-020 - Software Classification nopaneltrue Include PageSWE-020 - SA Task1SWE-020 - SA Task13.5.2176 Excerpt IncludeSWEHBVD:SWE-176 - Software RecordsSWEHBVD:SWE-176 - Software Recordsnopaneltrue Include PageSWE-176 - SA Task1SWE-176 - SA Task1

3.6 Software Assurance and Software
Independent Verification & Validation

3.6.1022 Excerpt IncludeSWEHBVD:SWE-022 - Software AssuranceSWEHBVD:SWE-022 - Software Assurancenopaneltrue Include PageSWE-022 - SA Task1SWE-022 - SA Task13.6.2141 Excerpt IncludeSWEHBVD:SWE-141 - Software Independent Verification and ValidationSWEHBVD:SWE-141 - Software Independent Verification and Validationnopaneltrue Include PageSWE-141 - SA Task1SWE-141 - SA Task13.6.3131 Excerpt IncludeSWEHBVD:SWE-131 - Independent Verification and Validation Project Execution PlanSWEHBVD:SWE-131 - Independent Verification and Validation Project Execution Plannopaneltrue Include PageSWE-131 - SA Task1SWE-131 - SA Task13.6.4178 Excerpt IncludeSWEHBVD:SWE-178 - IV&V ArtifactsSWEHBVD:SWE-178 - IV&V Artifactsnopaneltrue Include PageSWE-178 - SA Task1SWE-178 - SA Task13.6.5179 Excerpt IncludeSWEHBVD:SWE-179 - IV&V Submitted Issues and RisksSWEHBVD:SWE-179 - IV&V Submitted Issues and Risksnopaneltrue Include PageSWE-179 - SA Task1SWE-179 - SA Task1

3.7 Safety-Critical and Mission Critical Software

3.7.1205 Excerpt IncludeSWEHBVD:SWE-205 - Determination of Safety-Critical SoftwareSWEHBVD:SWE-205 - Determination of Safety-Critical Softwarenopaneltrue Include PageSWE-205 - SA Task1SWE-205 - SA Task1 Include PageSWE-205 - SA Task2SWE-205 - SA Task2 Include PageSWE-205 - SA Task3SWE-205 - SA Task3 Include PageSWE-205 - SA Task4SWE-205 - SA Task4 Include PageSWE-205 - SA Task5SWE-205 - SA Task53.7.2023 Excerpt IncludeSWEHBVD:SWE-023 - Software Safety-Critical RequirementsSWEHBVD:SWE-023 - Software Safety-Critical Requirementsnopaneltrue Include PageSWE-023 - SA Task1SWE-023 - SA Task13.7.3134 Excerpt IncludeSWEHBVD:SWE-134 - Safety-Critical Software Design RequirementsSWEHBVD:SWE-134 - Safety-Critical Software Design Requirementsnopaneltrue Include PageSWE-134 - SA Task1SWE-134 - SA Task1 Include PageSWE-134 - SA Task2SWE-134 - SA Task2 Include PageSWE-134 - SA Task3SWE-134 - SA Task3 Include PageSWE-134 - SA Task4SWE-134 - SA Task4 Include PageSWE-134 - SA Task5SWE-134 - SA Task5 Include PageSWE-134 - SA Task6SWE-134 - SA Task63.7.4219 Excerpt IncludeSWEHBVD:SWE-219 - Code Coverage for Safety Critical SoftwareSWEHBVD:SWE-219 - Code Coverage for Safety Critical Softwarenopaneltrue Include PageSWE-219 - SA Task1SWE-219 - SA Task13.7.5220 Excerpt IncludeSWEHBVD:SWE-220 - Cyclomatic Complexity for Safety-Critical SoftwareSWEHBVD:SWE-220 - Cyclomatic Complexity for Safety-Critical Softwarenopaneltrue Include PageSWE-220 - SA Task1SWE-220 - SA Task1 Include PageSWE-220 - SA Task2SWE-220 - SA Task2

3.8 Automatic Generation of Software Source Code

3.8.1146 Excerpt IncludeSWEHBVD:SWE-146 - Auto-generated Source CodeSWEHBVD:SWE-146 - Auto-generated Source Codenopaneltrue Include PageSWE-146 - SA Task1SWE-146 - SA Task13.8.2206 Excerpt IncludeSWEHBVD:SWE-206 - Auto-Generation Software InputsSWEHBVD:SWE-206 - Auto-Generation Software Inputsnopaneltrue Include PageSWE-206 - SA Task1SWE-206 - SA Task1

3.9 Software Development Processes and Practices

3.9.2032 Excerpt IncludeSWEHBVD:SWE-032 - CMMI Levels for Class A and B SoftwareSWEHBVD:SWE-032 - CMMI Levels for Class A and B Softwarenopaneltrue Include PageSWE-032 - SA Task1SWE-032 - SA Task1 Include PageSWE-032 - SA Task2SWE-032 - SA Task2 Include PageSWE-032 - SA Task3SWE-032 - SA Task3

3.10 Software Reuse

3.10.1147 Excerpt IncludeSWEHBVD:SWE-147 - Specify Reusability RequirementsSWEHBVD:SWE-147 - Specify Reusability Requirementsnopaneltrue Include PageSWE-147 - SA Task1SWE-147 - SA Task13.10.2148 Excerpt IncludeSWEHBVD:SWE-148 - Contribute to Agency Software CatalogSWEHBVD:SWE-148 - Contribute to Agency Software Catalognopaneltrue Include PageSWE-148 - SA Task1SWE-148 - SA Task1

3.11 Software Cybersecurity

3.11.2156 Excerpt IncludeSWEHBVD:SWE-156 - Evaluate Systems for Security RisksSWEHBVD:SWE-156 - Evaluate Systems for Security Risksnopaneltrue Include PageSWE-156 - SA Task1SWE-156 - SA Task13.11.3154 Excerpt IncludeSWEHBVD:SWE-154 - Identify Security RisksSWEHBVD:SWE-154 - Identify Security Risksnopaneltrue Include PageSWE-154 - SA Task1SWE-154 - SA Task13.11.4157 Excerpt IncludeSWEHBVD:SWE-157 - Protect Against Unauthorized AccessSWEHBVD:SWE-157 - Protect Against Unauthorized Accessnopaneltrue Include PageSWE-157 - SA Task1SWE-157 - SA Task13.11.5159 Excerpt IncludeSWEHBVD:SWE-159 - Verify and Validate Risk MitigationsSWEHBVD:SWE-159 - Verify and Validate Risk Mitigationsnopaneltrue Include PageSWE-159 - SA Task1SWE-159 - SA Task1 Include PageSWE-159 - SA Task2SWE-159 - SA Task23.11.6207 Excerpt IncludeSWEHBVD:SWE-207 - Secure Coding PracticesSWEHBVD:SWE-207 - Secure Coding Practicesnopaneltrue Include PageSWE-207 - SA Task1SWE-207 - SA Task13.11.7185 Excerpt IncludeSWEHBVD:SWE-185 - Secure Coding Standards VerificationSWEHBVD:SWE-185 - Secure Coding Standards Verificationnopaneltrue Include PageSWE-185 - SA Task1SWE-185 - SA Task13.11.8210 Excerpt IncludeSWEHBVD:SWE-210 - Detection of Adversarial ActionsSWEHBVD:SWE-210 - Detection of Adversarial Actionsnopaneltrue Include PageSWE-210 - SA Task1SWE-210 - SA Task1

3.12 Software Bi-Directional Traceability

3.12.1052 Excerpt IncludeSWEHBVD:SWE-052 - Bidirectional TraceabilitySWEHBVD:SWE-052 - Bidirectional Traceabilitynopaneltrue Include PageSWE-052 - SA Task1SWE-052 - SA Task1 Include PageSWE-052 - SA Task2SWE-052 - SA Task2

4 Software Engineering (Life Cycle) Requirements

4.1 Software Requirements

4.1.2050 Excerpt IncludeSWEHBVD:SWE-050 - Software RequirementsSWEHBVD:SWE-050 - Software Requirementsnopaneltrue Include PageSWE-050 - SA Task1SWE-050 - SA Task14.1.3051 Excerpt IncludeSWEHBVD:SWE-051 - Software Requirements AnalysisSWEHBVD:SWE-051 - Software Requirements Analysisnopaneltrue Include PageSWE-051 - SA Task1SWE-051 - SA Task14.1.4184 Excerpt IncludeSWEHBVD:SWE-184 - Software-related Constraints and AssumptionsSWEHBVD:SWE-184 - Software-related Constraints and Assumptionsnopaneltrue Include PageSWE-184 - SA Task1SWE-184 - SA Task14.1.5053 Excerpt IncludeSWEHBVD:SWE-053 - Manage Requirements ChangesSWEHBVD:SWE-053 - Manage Requirements Changesnopaneltrue Include PageSWE-053 - SA Task1SWE-053 - SA Task14.1.6054 Excerpt IncludeSWEHBVD:SWE-054 - Corrective Action for InconsistenciesSWEHBVD:SWE-054 - Corrective Action for Inconsistenciesnopaneltrue Include PageSWE-054 - SA Task1SWE-054 - SA Task14.1.7055 Excerpt IncludeSWEHBVD:SWE-055 - Requirements ValidationSWEHBVD:SWE-055 - Requirements Validationnopaneltrue Include PageSWE-055 - SA Task1SWE-055 - SA Task1

4.2 Software Architecture

4.2.3057 Excerpt IncludeSWEHBVD:SWE-057 - Software ArchitectureSWEHBVD:SWE-057 - Software Architecturenopaneltrue Include PageSWE-057 - SA Task1SWE-057 - SA Task1 Include PageSWE-057 - SA Task2SWE-057 - SA Task24.2.4143 Excerpt IncludeSWEHBVD:SWE-143 - Software Architecture ReviewSWEHBVD:SWE-143 - Software Architecture Reviewnopaneltrue Include PageSWE-143 - SA Task1SWE-143 - SA Task1

4.3 Software Design

4.3.2058 Excerpt IncludeSWEHBVD:SWE-058 - Detailed DesignSWEHBVD:SWE-058 - Detailed Designnopaneltrue Include PageSWE-058 - SA Task1SWE-058 - SA Task1 Include PageSWE-058 - SA Task2SWE-058 - SA Task2 Include PageSWE-058 - SA Task3SWE-058 - SA Task3 Include PageSWE-058 - SA Task4SWE-058 - SA Task4 Include PageSWE-058 - SA Task5SWE-058 - SA Task5

4.4 Software Implementation

4.4.2060 Excerpt IncludeSWEHBVD:SWE-060 - Coding SoftwareSWEHBVD:SWE-060 - Coding Softwarenopaneltrue Include PageSWE-060 - SA Task1SWE-060 - SA Task1 Include PageSWE-060 - SA Task2SWE-060 - SA Task24.4.3061 Excerpt IncludeSWEHBVD:SWE-061 - Coding StandardsSWEHBVD:SWE-061 - Coding Standardsnopaneltrue Include PageSWE-061 - SA Task1SWE-061 - SA Task1 Include PageSWE-061 - SA Task2SWE-061 - SA Task24.4.4135 Excerpt IncludeSWEHBVD:SWE-135 - Static AnalysisSWEHBVD:SWE-135 - Static Analysisnopaneltrue Include PageSWE-135 - SA Task1SWE-135 - SA Task1 Include PageSWE-135 - SA Task2SWE-135 - SA Task2 Include PageSWE-135 - SA Task3SWE-135 - SA Task3 Include PageSWE-135 - SA Task4SWE-135 - SA Task4 Include PageSWE-135 - SA Task5SWE-135 - SA Task5 Include PageSWE-135 - SA Task6SWE-135 - SA Task6 Include PageSWE-135 - SA Task7SWE-135 - SA Task74.4.5062 Excerpt IncludeSWEHBVD:SWE-062 - Unit TestSWEHBVD:SWE-062 - Unit Testnopaneltrue Include PageSWE-062 - SA Task1SWE-062 - SA Task1 Include PageSWE-062 - SA Task2SWE-062 - SA Task24.4.6186 Excerpt IncludeSWEHBVD:SWE-186 - Unit Test RepeatabilitySWEHBVD:SWE-186 - Unit Test Repeatabilitynopaneltrue Include PageSWE-186 - SA Task1SWE-186 - SA Task14.4.7063 Excerpt IncludeSWEHBVD:SWE-063 - Release Version DescriptionSWEHBVD:SWE-063 - Release Version Descriptionnopaneltrue Include PageSWE-063 - SA Task1SWE-063 - SA Task1 Include PageSWE-063 - SA Task2SWE-063 - SA Task24.4.8136 Excerpt IncludeSWEHBVD:SWE-136 - Software Tool Accreditation SWEHBVD:SWE-136 - Software Tool Accreditation nopaneltrue Include PageSWE-136 - SA Task1SWE-136 - SA Task1

4.5 Software Testing

4.5.2065a Include PageSWEHBVD:SWE-065aSWEHBVD:SWE-065a Include PageSWE-065a - SA Task1SWE-065a - SA Task1 Include PageSWE-065a - SA Task2SWE-065a - SA Task24.5.2065b Include PageSWEHBVD:SWE-065bSWEHBVD:SWE-065b Include PageSWE-065b - SA Task1SWE-065b - SA Task1 Include PageSWE-065b - SA Task2SWE-065b - SA Task24.5.2065c Include PageSWEHBVD:SWE-065cSWEHBVD:SWE-065c Include PageSWE-065c - SA Task1SWE-065c - SA Task1 Include PageSWE-065c - SA Task2SWE-065c - SA Task2 Include PageSWE-065c - SA Task3SWE-065c - SA Task34.5.2065d Include PageSWEHBVD:SWE-065dSWEHBVD:SWE-065d Include PageSWE-065d - SA Task1SWE-065d - SA Task1 Include PageSWE-065d - SA Task2SWE-065d - SA Task2 Include PageSWE-065d - SA Task3SWE-065d - SA Task3 Include PageSWE-065d - SA Task4SWE-065d - SA Task44.5.3066 Excerpt IncludeSWEHBVD:SWE-066 - Perform TestingSWEHBVD:SWE-066 - Perform Testingnopaneltrue Include PageSWE-066 - SA Task1SWE-066 - SA Task1 Include PageSWE-066 - SA Task2SWE-066 - SA Task2 Include PageSWE-066 - SA Task3SWE-066 - SA Task34.5.4187 Excerpt IncludeSWEHBVD:SWE-187 - Control of Software ItemsSWEHBVD:SWE-187 - Control of Software Itemsnopaneltrue Include PageSWE-187 - SA Task1SWE-187 - SA Task1 Include PageSWE-187 - SA Task2SWE-187 - SA Task24.5.5068 Excerpt IncludeSWEHBVD:SWE-068 - Evaluate Test ResultsSWEHBVD:SWE-068 - Evaluate Test Resultsnopaneltrue Include PageSWE-068 - SA Task1SWE-068 - SA Task1 Include PageSWE-068 - SA Task2SWE-068 - SA Task2 Include PageSWE-068 - SA Task3SWE-068 - SA Task34.5.6070 Excerpt IncludeSWEHBVD:SWE-070 - Models, Simulations, ToolsSWEHBVD:SWE-070 - Models, Simulations, Toolsnopaneltrue Include PageSWE-070 - SA Task1SWE-070 - SA Task14.5.7071 Excerpt IncludeSWEHBVD:SWE-071 - Update Test Plans and ProceduresSWEHBVD:SWE-071 - Update Test Plans and Proceduresnopaneltrue Include PageSWE-071 - SA Task1SWE-071 - SA Task14.5.8073 Excerpt IncludeSWEHBVD:SWE-073 - Platform or Hi-Fidelity SimulationsSWEHBVD:SWE-073 - Platform or Hi-Fidelity Simulationsnopaneltrue Include PageSWE-073 - SA Task1SWE-073 - SA Task14.5.9189 Excerpt IncludeSWEHBVD:SWE-189 - Code Coverage MeasurementsSWEHBVD:SWE-189 - Code Coverage Measurementsnopaneltrue Include PageSWE-189 - SA Task1SWE-189 - SA Task14.5.10190 Excerpt IncludeSWEHBVD:SWE-190 - Verify Code CoverageSWEHBVD:SWE-190 - Verify Code Coveragenopaneltrue Include PageSWE-190 - SA Task1SWE-190 - SA Task1 Include PageSWE-190 - SA Task2SWE-190 - SA Task2 Include PageSWE-190 - SA Task3SWE-190 - SA Task34.5.11191 Excerpt IncludeSWEHBVD:SWE-191 - Software Regression TestingSWEHBVD:SWE-191 - Software Regression Testingnopaneltrue Include PageSWE-191 - SA Task1SWE-191 - SA Task1 Include PageSWE-191 - SA Task2SWE-191 - SA Task2 Include PageSWE-191 - SA Task3SWE-191 - SA Task3 Include PageSWE-191 - SA Task4SWE-191 - SA Task44.5.12192 Excerpt IncludeSWEHBVD:SWE-192 - Software Hazardous RequirementsSWEHBVD:SWE-192 - Software Hazardous Requirementsnopaneltrue Include PageSWE-192 - SA Task1SWE-192 - SA Task14.5.13193 Excerpt IncludeSWEHBVD:SWE-193 - Acceptance Testing for Affected System and Software BehaviorSWEHBVD:SWE-193 - Acceptance Testing for Affected System and Software Behaviornopaneltrue Include PageSWE-193 - SA Task1SWE-193 - SA Task1 Include PageSWE-193 - SA Task2SWE-193 - SA Task2 Include PageSWE-193 - SA Task3SWE-193 - SA Task34.5.14211 Excerpt IncludeSWEHBVD:SWE-211 - Test Levels of Non-Custom Developed SoftwareSWEHBVD:SWE-211 - Test Levels of Non-Custom Developed Softwarenopaneltrue Include PageSWE-211 - SA Task1SWE-211 - SA Task1

4.6 Software Operations, Maintenance, and Retirement

4.6.2075 Excerpt IncludeSWEHBVD:SWE-075 - Plan Operations, Maintenance, RetirementSWEHBVD:SWE-075 - Plan Operations, Maintenance, Retirementnopaneltrue Include PageSWE-075 - SA Task1SWE-075 - SA Task1 Include PageSWE-075 - SA Task2SWE-075 - SA Task24.6.3077 Excerpt IncludeSWEHBVD:SWE-077 - Deliver Software ProductsSWEHBVD:SWE-077 - Deliver Software Productsnopaneltrue Include PageSWE-077 - SA Task1SWE-077 - SA Task1 Include PageSWE-077 - SA Task2SWE-077 - SA Task24.6.4194 Excerpt IncludeSWEHBVD:SWE-194 - Delivery Requirements VerificationSWEHBVD:SWE-194 - Delivery Requirements Verificationnopaneltrue Include PageSWE-194 - SA Task1SWE-194 - SA Task1 Include PageSWE-194 - SA Task2SWE-194 - SA Task2 Include PageSWE-194 - SA Task3SWE-194 - SA Task3 Include PageSWE-194 - SA Task4SWE-194 - SA Task4 Include PageSWE-194 - SA Task5SWE-194 - SA Task5 Include PageSWE-194 - SA Task6SWE-194 - SA Task64.6.5195 Excerpt IncludeSWEHBVD:SWE-195 - Software Maintenance PhaseSWEHBVD:SWE-195 - Software Maintenance Phasenopaneltrue Include PageSWE-195 - SA Task1SWE-195 - SA Task14.6.6196 Excerpt IncludeSWEHBVD:SWE-196 - Software Retirement ArchivalSWEHBVD:SWE-196 - Software Retirement Archivalnopaneltrue Include PageSWE-196 - SA Task1SWE-196 - SA Task1 Include PageSWE-196 - SA Task2SWE-196 - SA Task2

5 Supporting Software Life Cycle Requirements

5.1 Software Configuration Management

5.1.2079 Excerpt IncludeSWEHBVD:SWE-079 - Develop CM PlanSWEHBVD:SWE-079 - Develop CM Plannopaneltrue Include PageSWE-079 - SA Task1SWE-079 - SA Task15.1.3080 Excerpt IncludeSWEHBVD:SWE-080 - Track and Evaluate ChangesSWEHBVD:SWE-080 - Track and Evaluate Changesnopaneltrue Include PageSWE-080 - SA Task1SWE-080 - SA Task1 Include PageSWE-080 - SA Task2SWE-080 - SA Task2 Include PageSWE-080 - SA Task3SWE-080 - SA Task35.1.4081 Excerpt IncludeSWEHBVD:SWE-081 - Identify Software CM ItemsSWEHBVD:SWE-081 - Identify Software CM Itemsnopaneltrue Include PageSWE-081 - SA Task1SWE-081 - SA Task1 Include PageSWE-081 - SA Task2SWE-081 - SA Task25.1.5082 Excerpt IncludeSWEHBVD:SWE-082 - Authorizing ChangesSWEHBVD:SWE-082 - Authorizing Changesnopaneltrue Include PageSWE-082 - SA Task1SWE-082 - SA Task1 Include PageSWE-082 - SA Task2SWE-082 - SA Task25.1.6083 Excerpt IncludeSWEHBVD:SWE-083 - Status AccountingSWEHBVD:SWE-083 - Status Accountingnopaneltrue Include PageSWE-083 - SA Task1SWE-083 - SA Task15.1.7084 Excerpt IncludeSWEHBVD:SWE-084 - Configuration AuditsSWEHBVD:SWE-084 - Configuration Auditsnopaneltrue Include PageSWE-084 - SA Task1SWE-084 - SA Task15.1.8085 Excerpt IncludeSWEHBVD:SWE-085 - Release ManagementSWEHBVD:SWE-085 - Release Managementnopaneltrue Include PageSWE-085 - SA Task1SWE-085 - SA Task1 Include PageSWE-085 - SA Task2SWE-085 - SA Task25.1.9045 Excerpt IncludeSWEHBVD:SWE-045 - Project Participation in AuditsSWEHBVD:SWE-045 - Project Participation in Auditsnopaneltrue Include PageSWE-045 - SA Task1SWE-045 - SA Task1

5.2 Software Risk Management

5.2.1086 Excerpt IncludeSWEHBVD:SWE-086 - Continuous Risk ManagementSWEHBVD:SWE-086 - Continuous Risk Managementnopaneltrue Include PageSWE-086 - SA Task1SWE-086 - SA Task1 Include PageSWE-086 - SA Task2SWE-086 - SA Task2

5.3 Software Peer Reviews/Inspections

5.3.2087 Excerpt IncludeSWEHBVD:SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test ProceduresSWEHBVD:SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Proceduresnopaneltrue Include PageSWE-087 - SA Task1SWE-087 - SA Task1 Include PageSWE-087 - SA Task2SWE-087 - SA Task2 Include PageSWE-087 - SA Task3SWE-087 - SA Task3 Include PageSWE-087 - SA Task4SWE-087 - SA Task45.3.3088 Excerpt IncludeSWEHBVD:SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and TrackingSWEHBVD:SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Trackingnopaneltrue Include PageSWE-088 - SA Task1SWE-088 - SA Task1 Include PageSWE-088 - SA Task2SWE-088 - SA Task2 Include PageSWE-088 - SA Task3SWE-088 - SA Task35.3.4089 Excerpt IncludeSWEHBVD:SWE-089 - Software Peer Reviews and Inspections - Basic MeasurementsSWEHBVD:SWE-089 - Software Peer Reviews and Inspections - Basic Measurementsnopaneltrue Include PageSWE-089 - SA Task1SWE-089 - SA Task1

5.4 Software Measurements

5.4.2090 Excerpt IncludeSWEHBVD:SWE-090 - Management and Technical MeasurementsSWEHBVD:SWE-090 - Management and Technical Measurementsnopaneltrue Include PageSWE-090 - SA Task1SWE-090 - SA Task1 Include PageSWE-090 - SA Task2SWE-090 - SA Task2 Include PageSWE-090 - SA Task3SWE-090 - SA Task35.4.3093 Excerpt IncludeSWEHBVD:SWE-093 - Analysis of Measurement DataSWEHBVD:SWE-093 - Analysis of Measurement Datanopaneltrue Include PageSWE-093 - SA Task1SWE-093 - SA Task1 Include PageSWE-093 - SA Task2SWE-093 - SA Task25.4.4094 Excerpt IncludeSWEHBVD:SWE-094 - Reporting of Measurement AnalysisSWEHBVD:SWE-094 - Reporting of Measurement Analysisnopaneltrue Include PageSWE-094 - SA Task1SWE-094 - SA Task15.4.5199 Excerpt IncludeSWEHBVD:SWE-199 - Performance MeasuresSWEHBVD:SWE-199 - Performance Measuresnopaneltrue Include PageSWE-199 - SA Task1SWE-199 - SA Task1 Include PageSWE-199 - SA Task2SWE-199 - SA Task25.4.6200 Excerpt IncludeSWEHBVD:SWE-200 - Software Requirements Volatility MetricsSWEHBVD:SWE-200 - Software Requirements Volatility Metricsnopaneltrue Include PageSWE-200 - SA Task1SWE-200 - SA Task1 Include PageSWE-200 - SA Task2SWE-200 - SA Task2

5.5 Software Non-conformance or Defect Management

5.5.1201 Excerpt IncludeSWEHBVD:SWE-201 - Software Non-ConformancesSWEHBVD:SWE-201 - Software Non-Conformancesnopaneltrue Include PageSWE-201 - SA Task1SWE-201 - SA Task1 Include PageSWE-201 - SA Task2SWE-201 - SA Task25.5.2202 Excerpt IncludeSWEHBVD:SWE-202 - Software Severity LevelsSWEHBVD:SWE-202 - Software Severity Levelsnopaneltrue Include PageSWE-202 - SA Task1SWE-202 - SA Task1 Include PageSWE-202 - SA Task2SWE-202 - SA Task2 Include PageSWE-202 - SA Task3SWE-202 - SA Task3 Include PageSWE-202 - SA Task4SWE-202 - SA Task45.5.3203 Excerpt IncludeSWEHBVD:SWE-203 - Mandatory Assessments for Non-ConformancesSWEHBVD:SWE-203 - Mandatory Assessments for Non-Conformancesnopaneltrue Include PageSWE-203 - SA Task1SWE-203 - SA Task1 Include PageSWE-203 - SA Task2SWE-203 - SA Task25.5.4204 Excerpt IncludeSWEHBVD:SWE-204 - Process AssessmentsSWEHBVD:SWE-204 - Process Assessmentsnopaneltrue Include PageSWE-204 - SA Task1SWE-204 - SA Task1 Include PageSWE-204 - SA Task2SWE-204 - SA Task2 Include PageSWE-204 - SA Task3SWE-204 - SA Task3 Include PageSWE-204 - SA Task4SWE-204 - SA Task4

Content

Space Tools

Page History

Versions Compared

Old Version 63

New Version Current

Key

1. NASA-STD-8739.8B Title Material

1. SCOPE

1.1 Document Purpose

Forward

1. SCOPE

1.1 Document Purpose

1.2 Applicability

1.3 Documentation and Deliverables

1.4 Request for Relief

1.2 Applicability

1.3 Documentation and Deliverables

1.4 Request for Relief

2. APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

2.2 Reference Documents

2.2.1 Government Documents

2. APPLICABLE AND REFERENCE DOCUMENTS

2.2.2 Non-Government Documents

2.3 Order of Precedence

2.2.1 Government Documents

2.2.2 Non-Government Documents

2.3 Order of Precedence

3. ACRONYMS AND DEFINITIONS

3.1 Acronyms and Abbreviations

3.2 Definitions

4. SOFTWARE ASSURANCE AND SOFTWARE SAFETY REQUIREMENTS

4.3 Software Assurance and Software Safety Requirements

Software Assurance and Software Safety Requirements

3

Software Management Requirements

3.1

Software Life-Cycle Planning

3.2

Software Cost Estimation

3.3

Software Schedules

3.4

Software Training

3.5

Software Classification Assessments

3.6

Software Assurance and SoftwareIndependent Verification & Validation

3.7

Safety-Critical and Mission Critical Software

3.8

Automatic Generation of Software Source Code

3.9

Software Development Processes and Practices

3.10

Software Reuse

3.11

Software Cybersecurity

3.12

Software Bi-Directional Traceability

4

Software Engineering (Life Cycle) Requirements

4.1

Software Requirements

4.2

Software Architecture

4.3

Software Design

4.4

Software Implementation

4.5

Software Testing

4.6

Software Operations, Maintenance, and Retirement

5

Supporting Software Life Cycle Requirements

5.1

Software Configuration Management

5.2

Software Assurance and Software
Independent Verification & Validation

Software Assurance and Software
Independent Verification & Validation