The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to 8.53 - IV&V Project Execution Plan. If you do not get there in 2 seconds, click the link to go there.



Return to 8.16 - SA Products
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.
See also SWE-178 - IV&V Artifacts for the plan and other IV&V artifacts. See also SWE-179 - IV&V Submitted Issues and Risks.
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
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.
- Introduction
- Document Purpose - Describe the overall IV&V project and define the basic agreements for the partnership between the IV&V Team and the Project.
- Intended Audience - Describe the intended audience of the document.
- Document Organization - Describe the document’s organization and structure.
- IV&V Overview
- IV&V Goals and Objectives - Describe at a high level what the IV&V efforts are trying to accomplish overall for the mission.
- IV&V Approach - Describe the IV&V approach that will be used for validation- and verification-related analyses. Include the artifact types generally required for specific analysis objectives.
- IV&V Scope and Focus - Provide the scope and focus of the project. Scope is the parts of the project that should be considered for IV&V assurance services. Focus is the set of in-scope items that will receive IV&V assurance services.
- Roles, Responsibilities, and Interfaces
- Roles, Responsibilities, and Interfaces - Describe the various roles, responsibilities, and interfaces for the project. These roles and responsibilities may be described in terms of personnel within the IV&V Program and personnel within the Project. Include formal and informal lines of communication.
- IV&V Team - Describe the IV&V team with their associated roles and responsibilities. At a minimum, there should be an IV&V Project Manager and IV&V analysts. Provide contact information for the IV&V leadership team.
- Project Personnel - Establish that the project will provide an IV&V Point of Contact (POC) for formal interactions between the IV&V Team and the Project. At a minimum, there should be a Project Manager, IV&V POC, and Chief SMA Officer (CSO). Provide contact information for the Project leadership team.
- IV&V Products and Communication and Reporting Methods - The IV&V Team generates various products and utilizes various communication and reporting methods/processes throughout the lifecycle. Describe the IV&V products and associated communication and reporting methods/processes.
- IV&V Products
- Analysis Conclusions - Briefly describe the process for documenting and communicating Assurance Conclusions. Provide a summary of the content to be included in the Assurance Conclusions. Assurance Conclusions should describe the analysis(es) performed and the results, including the associated assurance objectives, technical issues, risks, assumptions, forward work, and other caveats and limitations found or understood during the analysis(es).
- Analysis Reports - Briefly describe the process for documenting and communicating Analysis Reports. Provide a summary of the content to be included in the Analysis Reports. Analysis Reports should document the results of the analysis(es) performed and describe the Project artifacts used, a high-level description of the process, approach, tools used, results, and conclusions.)
- Technical Issue Memorandums - A TIM is the formal mechanism the IV&V Team uses to document one or more instances of defects (i.e., issues) identified within a development artifact, and subsequently formally communicates defects to the Project. Describe the processes for documenting, reviewing, and tracking TIMs to resolution. Include Impact and Severity Ratings with descriptions. See S3105: Guidelines for Writing IV&V TIMs 613.
- Risks - Describe how the IV&V Team documents and tracks risks to resolution. Include how the Risks are formally communicated to the Project.
- IV&V Communication and Reporting Methods - Briefly describe the communication and reporting methods / processes (formal and informal) between the IV&V Team and the Project.
- Item Tracking, Monitoring, and Escalation - Briefly describe the IV&V team’s process for tracking, monitoring, and escalating all data (including issues, risks, presentations, reports) to the Project.
- Lifecycle Review Presentations - Briefly describe the IV&V team’s approach to supporting formal Project milestone reviews and communicating the status of IV&V assurance efforts. Include the reviews to be supported and the responsible IV&V POC.
- Agency/Mission Directorate/Center Management Briefings - Briefly describe the IV&V team’s approach for providing status to the Project Stakeholders. Include the reviews and boards to be supported and the responsible IV&V POC.
- Routine Tag-ups - Briefly describe the IV&V team’s approach for supporting tag-ups (e.g., status, task requests, analysis results).
- Development Reviews and Working Groups Support - Briefly describe the IV&V team’s approach for supporting Project working groups or development reviews. Include how analysis results will be communicated through these forums.
- NASA Audit, Assessment, and Review Support - Briefly describe the IV&V team’s approach for supporting any NASA led review or audit functions.
- IV&V Products
- IV&V Capability-Level Software Risk Assessment Results - Based on the mission objectives, provide the results and rationale of the capability-level risk assessment. For each Capability, include the Impact Score, Likelihood Score, and Risk Score.
- IV&V Entity-Level Software Risk Assessment Results - Based on the Capability-Level Software Risk Assessment, provide the results of the software entity-level risk assessment, which extends the risk assessment to the software components (i.e., entities) that implement the system behaviors necessary to accomplish mission capabilities. For each Entity, include the Impact Score, Likelihood Score, and Risk Score.
- IV&V Heritage Review & Applicable Lessons Learned - Briefly describe the process for completing a heritage review and communicating the results. Provide a summary of the content to be included. An IV&V heritage review is intended to survey prior IV&V projects for applicability of their results to the current project and to document references to applicable project results for use in planning and scoping activities, along with early IV&V analysis activities. The process for completing an IV&V heritage review should include an assessment of the current project’s assertion of mission heritage, a survey of former IV&V projects for those missions and listing of missions with similar characteristics, and a survey of previous IV&V risk assessments, issues, risks, and lessons learned documented for each of these missions, where available, to determine their applicability to the current project.
The purpose of the Heritage Review (HR) process is to learn from our collective experiences to maximize the value of IV&V’s contributions to NASA and other stakeholders. It also ensures that a promotion of faults do not cascade from one project to another through inherited or reuse of hardware interfaces and software. IV&V’s promotion of due diligence necessitates this review in an effort to promote knowledge that understanding may be gained of previous faults, past developer assumptions and on-orbit anomaly impacts. It is with this foundational visage a more complete system understanding of the new project can be obtained, leading to higher fidelity planning and scoping, analysis and ultimately assurance provided to the mission and Agency. A Heritage Review template is available at: https://www.nasa.gov/wp-content/uploads/2023/08/ivv-t2104-ver-basic-07-28-2022.docx?emrc=6e4e35 - Assurance Design - Define the assurance design. Include Assurance Objectives, an outline of focus areas, and the approaches considered for performing technical tasks. Provide a summary of each IV&V activity to be performed. The content for this section may be in a separate document or embedded directly into this one. Identify the relevant document(s) and include a link to the location.
- Reference Documentation - Identify titles, numbers, locations, and/or versions of documentation specified in the plan. Also, include any other relevant Project documentation.
- Acronyms - In alphabetic order, define all abbreviations and acronyms used in the plan.
- Fiscal Year <XX> IV&V Summary - Recommended.
- FY <XX> Assurance Goals and Objectives - Identify at a high level the assurance goals and objectives of the IV&V efforts for the applicable FY.
- FY <XX> Targeted External Milestones - List the key development project milestones. Depending on the development project, this may include milestones such as SRR, PDR, CDR, MRR, ORR, Launch Date, etc.
- FY<XX> Internal Milestones - List key internal milestones for the IV&V efforts. These will vary depending on the project, but may include mid-year risk assessment update, IV&V kickoff meeting, next year planning meeting with development Project, etc.
- FY <XX> Schedule - Provide a snapshot or summary of the IV&V Schedule for the applicable FY efforts.
- FY <XX> Risks - Provide a listing of perceived risks associated with the execution of the plan for the applicable year. This data only needs to be at the summary level as these risks will be managed via the IV&V Risk Review Board.
- FY <XX> IV&V Technical Reports - List specific technical reports planned for the fiscal year. These should be included in the FY <XX> Schedule. For relative dates, use working days unless there is a true requirement for calendar days to be used, e.g., a contractual or legal requirement. Regardless, be specific as to the type of days intended.
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) NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
- (SWEREF-613) S3105, Version: K, Effective Date: March 20, 2017 The official version of this document is maintained in IV&V's internal IV&V Management System Website (https://confluence.ivv.nasa.gov:8445/display/IMS).
4.2 Tools
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
4.3 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
Related Links |
---|
4.4 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
SPAN Links |
---|