2. Rationale

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

3. Guidance

The rationale for IV&V on a project is to reduce the risk of failures due to software. IV&V is a comprehensive review, analysis, and testing, (software and/or hardware) performed by an objective third party to confirm (i.e., verify) that the requirements are correctly defined, and to confirm (i.e., validate) that the system correctly implements the required functionality and security requirements. IV&V Project Execution Plans (IPEP) describe the activities and processes that will be carried out and the products produced to fulfill the project’s IV&V requirements for the software. This plan is created to guide the work and increase the expectations of meeting project objectives and goals. 

The purpose of the Independent Verification and Validation (IV&V) Project Execution Plan (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 provides a mechanism for the IV&V provider, including the IV&V Program, to coordinate with a project to identify and describe IV&V activities that apply. Specifically, it includes the basic tenets for an agreement between the IV&V team and the project, including the roles and responsibilities, communications paths, and artifacts anticipated to be shared between the organizations.

The NASA IPEP template ⁰²⁸ states that 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).”

Because the Independent Verification and Validation (IV&V) provider is responsible for developing the IV&V Project Execution Plan (IPEP), this guidance will address coordination efforts needed from projects receiving IV&V to support the development and execution of the IPEP. 

Note that the IPEP is reviewed when initially developed, not at any particular life cycle milestone review.  The milestone review at which the IPEP may be reviewed depends on which milestone the mission is approaching when the IV&V provider gets involved with the mission.  Per the IV&V Program, IPEPs are reviewed every 6-months for applicability or when there are significant changes made on the mission (e.g., a milestone slips out several months) or there is a significant change to IV&V (e.g., a budget cut which forces an IV&V provider to reduce their work on a mission). 

See also Topic 8.06 - IV&V Surveillance. 

3.1 IV&V Responsibilities

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 life cycle. The evaluation of products and processes throughout the life cycle demonstrates whether the software is fit for nominal operations (required functionality, safety, dependability, etc.) and off-nominal conditions (response to faults, responses to hazardous conditions, etc.). The goal of the IV&V effort is to contribute to the assurance conclusions 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.

1. 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.
2. 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 promptly 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.
3. 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 Provider organization, allowing them 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 concerning the development and acceptance of the system and its software.

The activities to be carried out by the IV&V provider are coordinated with the appropriate stakeholders, including the project manager. The IV&V provider captures the following types of information in the IV&V Plan:

• Goals and objectives.
• The high-level description of the IV&V approach.
• IV&V activities to be performed for the project.
• IV&V deliverables.
• Milestones.
• IV&V schedule coordinated with project management reviews and technical reviews.
• The interface among IV&V, Mission Project office, and software developer.
• Data exchange requirements.
• IV&V access to appropriate artifact management systems, issues, risk tracking systems, etc.
• Need for a heritage review to identify relevant products and artifacts from previous projects.
• Heritage review results.
• Preliminary list of processes and products to be evaluated.
• IV&V access rights to proprietary and classified information; related process to obtain those rights.

It is recommended that the scoping of the IV&V effort be driven by risk, or be risk-based given that IV&V of the full software subsystem is not likely to be feasible within financial, schedule, or resource constraints. 

The IV&V provider is expected to capture detailed fiscal year activity information in the appendices as activities, risks and risk assessment results, schedules, IV&V coverage, and required resources may be subject to change over time based on project life cycle progress and other factors.

3.2 Table of Contents for a Typical IPEP

See the IV&V Project Execution Plan (IPEP) Template that’s available from the Templates section of the IV&V Management System (IMS)  ⁴¹¹ site.  It’s available in Word and PDF formats.

See also Topic 8.53 - IV&V Project Execution Plan, SWE-178 - IV&V Artifacts, 

3.3 Additional Guidance

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

3.4 Center Process Asset Libraries

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

4. Small Projects

All projects with a mission- or safety-critical software and receiving IV&V services, are treated the same.  The same process is used for developing an IPEP, regardless of project size, and IPEPs all have the same basic elements (objectives, schedules, interfaces, etc.).  The actual content of each IPEP is, of course, different for each project.  

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lesson learned related to the IV&V plan:

• Independent Verification and Validation of Embedded Software (Use of IV&V Procedures). Lesson Number 723 ⁵¹⁸:  "The use of Independent Verification and Validation (IV&V) processes ensures that computer software is developed following original specifications, that the software performs the functions satisfactorily in the operational mission environment for which it was designed, and that it does not perform unintended functions. Identification and correction of errors early in the development cycle are less costly than identification and correction of errors in later phases, and the quality and reliability of software are significantly improved."

6.2 Other Lessons Learned

• Software IV&V
  • IV&V approaches and resources must align with the program risk posture.
  • A closed-loop, auditable, corrective action toolset and process must be used to manage all IV&V identified issues and risks.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Evidence of confirmation of the IPEP.
• IV&V planning and risk assessment.
• IV&V Program Execution Plan (Done by IV&V).

  
  

  Objective Evidence

  • IV&V Program Execution Plan (IPEP) for the project
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• None identified at this time.

7.4 Guidance

1. Confirm if IV&V is required on the project, see section 4.4 of NASA-STD-8739.8 for the IV&V requirements.

To determine whether IV&V is required on the project, see the requirements in SWE-141 - Software Independent Verification and Validation. If IV&V is required on the project, confirm that the requirements in section 4.4 of NASA-STD-8739.8 ²⁷⁸ are being followed.

The requirements in the IV&V section of NASA-STD-8739.8, section 4.4, apply to all IV&V efforts performed on a software development project. It also serves as the definition of what NASA considers to be IV&V. IV&V as 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.

IV&V is a technical discipline of SA, which employs rigorous analysis and testing methodologies identifying objective evidence and conclusions to provide an independent assessment of products and processes throughout the life cycle. The independent assessment 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 provide assurance conclusions to the Project based on evidence found in software development artifacts and risks associated with the intended behaviors of the 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 seeks to demonstrate that the products of a given development phase satisfy the conditions imposed at the start of or during that phase. Validation tasks, on the other hand, seek to develop 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.), that it fully describes the required capability/functionality needed, and that it solves the right problem.

Software assurance should assess the IV&V activities being planned and performed against the IV&V seven requirements, listed below:

The IV&V Provider shall: (SASS-02)

1. Conduct an initial planning and risk assessment effort to determine the specific system/software behaviors (including the software components responsible for implementing the behaviors) to be analyzed, the IV&V tasks to be performed, and the rigor to be applied to the tasks.
2. Develop an IV&V Execution Plan documenting the activities, methods, level of rigor, environments, 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.
3. Provide analysis results, risks, and assurance statements/data to all the responsible organizations’ Project management, engineering, and assurance personnel.
4. Participate in Project reviews of software activities by providing status and results of software IV&V activities including, but not limited to, upcoming analysis tasks, artifacts needed from the Project, the results of the current or completed analysis, defects, and risks to stakeholders, customers, and development project personnel.
5. Participate in planned software peer reviews or software inspections and record peer review measurements guided by the planning and scoping risk analysis performed by the IV&V Provider and the content of the items being reviewed or inspected.
6. Identify, analyze, plan, track, communicate, and record risks to the software and development project following NPR 8000.4.
7. Track, record, and communicate defects/issues and other results found during the execution of IV&V analysis during the software development effort to include issues and results found during the conducting of independent IV&V testing.

The IV&V Provider shall verify and validate that the concept documentation represents a specific implementation solution to solve the Acquirer’s problem. (SASS-03)

The IV&V Provider shall verify and validate: (SASS-04)

1. That the project implements the requirements for the software listed in NPR 7150.2 (SWE-134 - Safety-Critical Software Design Requirements) and risk-driven assessments determine the types of IV&V analyses.
2. That the in-scope SW requirements and system requirements are, at a minimum, correct, consistent, complete, accurate, readable, traceable, and testable.
3. The 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. That the mitigations for identified security risks are in the software requirements.

The IV&V Provider shall verify and validate: (SASS-05)

1. That the relationship between the in-scope system/software requirements and the associated architectural elements is traceable, consistent, and complete.
2. That the software architecture meets the user’s safety and mission-critical needs as defined in the requirements.
3. That the detailed design products are traceable, consistent, complete, accurate, and testable.
4. 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.
5. That the relationship between the software requirements and the associated detailed design components is correct, consistent, and complete.

The IV&V Provider shall verify and validate: (SASS-06)

1. That the software code products are consistent, complete, accurate, readable, and testable.
2. That the software code meets the project software coding standard.
3. That the security risks in the software code are identified and mitigated as necessary.
4. Analysis to assess the source code for the presence of open-source software.
5. That software problem reports generated by the IV&V provider have been addressed entirely by the project.
6. That the project identifies and plans for the security risks in software systems and the security risk mitigations for these systems.
7. That the project assesses the software systems for possible security vulnerabilities and weaknesses.
8. That the project implements and tests the required software security risk mitigations to ensure that security objectives for software are satisfied.
9. The software code uses analysis tools (including but not limited to static, dynamic, and formal analysis tools) as determined by the IV&V risk analysis process.
10. That the relationship between the software design elements and the associated software units is correct, consistent, and complete.
11. That the relationship between software code components and corresponding requirements is correct, complete, and consistent.

The IV&V Provider shall: (SASS-07)

1. Verify and validate that in-scope test plans, design, cases, and procedures at all levels of testing (unit, integration, system, acceptance, etc.) are correct, complete, and consistent to allow for the verified implementation of software code products as well as system/software capabilities/behaviors.
2. Verify and validate that relationships, between test plans, designs, cases, and procedures and software code products and system/software capabilities/behaviors, are correct, complete, and consistent.
3. Verify that the test plans, designs, cases, and procedures contain objective acceptance criteria that support the verification of the associated requirements for nominal and off-nominal conditions.
4. Validate that the test environment (including simulations) is complete, correct, and accurate concerning the intended testing objectives.
5. Verify that the software code test results meet the associated acceptance criteria to ensure that the software correctly implements the associated requirements.

The IV&V Provider shall assess the software maintenance plan concerning software elements to support the planning of IV&V activities during the maintenance phase. (SASS-08)

Software assurance considers using an audit approach to determine that the IV&V provider performs the IV&V functions defined in the requirements.

2. Develop, if IV&V is required on the project, the IV&V planning, risk assessment, and an IV&V Execution Plan.

If IV&V is required on the project, obtain the IV&V planning, risk assessment, and  IV&V Execution Plan from the IV&V provider.  Review these documents and work with the project and IV&V provider to confirm that the IV&V plan has been negotiated and approved by the project.  Monitor the IV&V activities to ensure the IV&V plan is executed and maintained.  Maintenance is required if the IV&V interactions, interfaces, roles and responsibilities, technical products, or reporting methods change.  Maintenance is also required if the IV&V activities change for any reason; the IV&V Execution Plan reflects the actual work performed by the IV&V provider and, thus, is to be updated, if those activities change.

Confirm that the IV&V plan contains the following items:

See the IV&V Project Execution Plan (IPEP) Template that’s available from the Templates section of the IV&V Management System (IMS)  ⁴¹¹ site.  It’s available in Word and PDF formats.

Guidelines for the content of an IV&V Execution Plan are:

Table of Contents for a Typical IPEP

See the IV&V Project Execution Plan (IPEP) Template that’s available from the Templates section of the IV&V Management System (IMS)  ⁴¹¹ site.  It’s available in Word and PDF formats.

See also 8.53 - IV&V Project Execution Plan

7.5 Additional Guidance

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