1. Introduction

As per SWE-131 - Independent Verification and Validation Project Execution Plan,

If software IV&V is performed on a project, the project manager shall ensure an IV&V Project Execution Plan (IPEP) is developed, negotiated, approved, maintained, and executed. The IPEP is prepared and maintained by the IV&V Project Manager (PM).  The IV&V PM coordinates the creation and maintenance of this document with affected individuals and organizations (within the NASA IV&V Program as well as with the Project).

The purpose of the IPEP is two-fold.  First, it is to communicate IV&V interactions, interfaces, roles and responsibilities, technical products, and reporting methods with the Project.  Second, the IPEP serves as the operational document for the IV&V efforts. The IPEP should be available not only to the Project Manager, but also to the Software Manager, Software Assurance Lead, and software team to enhance communication among the groups.

When IV&V is performed by the NASA IV&V Facility, the IPEP is divided into two major parts:  the document body and the appendices.  The document body describes the overall IV&V project and defines the basic agreements for the partnership between the IV&V Team and the Project. Once coordinated and approved, the basic agreements in the document body are not expected to change. The second part of the document, the appendices, focuses on the fiscal year activities for the IV&V efforts.  The appendices contain data that are more dynamic in nature and are expected to change over the course of the Project.  The appendices include the results of, or a reference to, the IV&V Heritage Review, IV&V Portfolio Based Risk Assessment (PBRA) data and subsequent Risk Based Assessments (RBA), and detailed information for each planned execution year, including items such as IV&V goals and objectives, schedule, and risks.

More information on performing IV&V and the requirements for IV&V can be found in Topic 8.06 - IV&V Surveillance in this Handbook.

1.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

2. IPEP Table of Contents

3. RBA, PBRA

 Independent Verification and Validation (IV&V), which is a part of Software Assurance, works to improve the safety and quality of software systems by focusing on an overall NASA software risk mitigation strategy applied throughout the lifecycle. In order to understand the software risk profile within NASA, NASA IV&V performs assessments of risk on Mission Projects. These assessments are primarily intended to create a mission-specific view of software risk to support planning and scoping of NASA IV&V Project work on each individual IV&V Project that also supports the IV&V Program’s portfolio-level prioritization determinations. The IPEP contains a two-phase process for performing these assessments. Phase One is a Mission-level assessment, referred to as the Portfolio-Based Risks Assessment (PBRA), that is focused on the development and assessment of Mission-level capabilities necessary for the achievement of mission success. Phase Two is a lower-level assessment that is performed on the software entities within the system that are necessary for the performance of the defined Mission-level capabilities. Phase Two is commonly referred to as the Risk Based Assessment (RBA).

The PBRA process results in a risk score for each Mission-level capability derived from evaluating each capability against categories of risk. The RBA process results in a risk score for each Mission-specific system/software entity. An outcome of the PBRA is an initial set of Mission-level Assurance Objectives that help refine the IV&V Project’s area of focus from a system-level perspective. The RBA begins to further refine the focus of those Assurance Objectives to the system/software level. The Assurance Objectives will then be used by the IV&V Project team to help determine what analysis activities should be performed with a goal of providing evidence that can turn those Assurance Objectives into positive Assurance Conclusions as IV&V is executed on the Project. Generally, with the very large projects, it is not possible to focus on all of the identified Assurance Objectives, so the RBA process results are used to prioritize the Assurance Objectives into an optimal set. Some example Assurance Objectives may be found in tab 8 of Topic 8.06 - IV&V Surveillance..

Both of the processes are to be evaluated iteratively during the IV&V Project lifecycle, as additional information about the mission and software becomes available.

3.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

4. Resources

4.1 References

• (SWEREF-278)
  SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
  NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,

4.2 Tools

4.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

4.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).