1. Introduction

As per SWE-131, “ If software IV&V is required for a project, the project manager shall ensure an IV&V Project Execution Plan (IPEP) is developed, approved, maintained, and executed in accordance with IV&V requirements in NASA-STD-8739.8.” 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.

2. IPEP Table of Contents

The typical IPEP Table of Contents is shown below:

If any process in this document conflicts with any document in the NASA Online Directives Information System (NODIS), this document shall be superseded by the NODIS document.  Any reference document external to NODIS shall be monitored by the Process Owner for current versioning.

1           Introduction

1.1       Document Purpose

1.2       Intended Audience

1.3       Document Organization

2           IV&V Overview

2.1       IV&V Goals and Objectives

2.2       IV&V Approach

2.3       IV&V Focus

3           Roles, Responsibilities, and Interfaces

3.1       IV&V Program

3.1.1    Research Support 

3.1.2    IV&V Metrics Support

3.2       IV&V Team

3.3       Project Personnel

4           IV&V Products and Communication and Reporting Methods

4.1       IV&V Products

4.1.1    Analysis Reports

4.1.2    Lifecycle Review Presentations

4.1.3    Technical Issue Memorandums

4.1.4    Risks

4.1.5    Item Tracking, Monitoring, and Escalation

4.2       IV&V Communication and Reporting Methods

4.2.1    Lifecycle Review Presentations

4.2.2    Agency/Mission Directorate/Center Management Briefings

4.2.3    Routine Tag-ups

Appendix A:  IV&V PBRA Results

Appendix B:  IV&V RBA Results

Appendix D:  Technical Scope & Rigor (TS&R)

Appendix E:  Reference Documentation

Appendix F:  Acronyms

Appendix G:  Fiscal Year <XX> IV&V Summary

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

4. Resources

4.1 References

4.2 Tools