1. Requirements

3.6.4 If software IV&V is performed on a project, the project manager shall ensure that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively. 

1.1 Notes

The artifacts and products should be provided electronically in original format (i.e., non-pdf) and, where possible, direct read-only electronic access to project document repositories and data stores should be provided. Appropriate security products should be completed and transferred as part of the overall package.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software.  Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs.  IV&V across the project life cycle increases the likelihood of uncovering high-risk errors early in the life cycle.

IV&V artifacts and products required to perform the IV&V analysis on NASA projects are to be made available in electronic format in the original format. The electronic availability of the IV&V products and artifacts facilitates post-deliveries that might be necessary with software updates. Electronic access to IV&V artifacts and products reduces NASA's IV&V project costs and accommodates the longer-term needs when performing software maintenance.

3. Guidance

3.1 IV&V Artifact Availability

All Independent Validation and Verification (IV&V) artifacts, products, source code, and data required to perform the IV&V analysis on NASA projects are to be made available in electronic format in the original format (i.e., non-pdf) and, where possible, direct read-only electronic access to project document repositories and data stores should be provided. The electronic availability of the IV&V products and artifacts facilitates post-deliveries that might be necessary with software updates. Electronic access to IV&V artifacts and products reduces NASA's IV&V project costs and accommodates the longer-term needs when performing software maintenance. IV&V providers also need access to project personnel and systems. See also SWE-141 - Software Independent Verification and Validation. 

3.2 Risk Mitigation Strategy

IV&V is a part of Software Assurance playing a role in the NASA software risk mitigation strategy.  See also SWE-179 - IV&V Submitted Issues and Risks.  IV&V is an objective examination of safety and mission-critical software processes and products.  The key parameters for independence are technical independence, managerial independence, and financial independence.  The goal of IV&V is to determine if the right system has been built and that it has been built correctly.  From that perspective IV&V strives to answer the questions:  will the system’s software do what it is supposed to do, will the system’s software not do what it is not supposed to do and will the system’s software respond as expected under adverse conditions.

3.3 Additional Value Added By IV&V

IV&V leads to higher quality products, reduced risk, greater insight, reduced cost and knowledge transfer.  IV&V also facilitates the transfer of system and software engineering best practices. IV&V status reports provide another status indicator and performance report to decision-makers (program managers). The scope of IV&V services is determined by the IV&V provider, documented in the IV&V Project Execution Plan (IPEP) (see NASA IPEP template ⁰²⁸) and approved by the NASA IV&V Program. The IPEP is developed by the IV&V provider and serves as the operational document that will be shared with the project receiving IV&V support.  

3.4 IPEP - IV&V Project Execution Plan

The coordination of the activities for the IV&V can be documented in the IPEP which 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. See 8.53 - IV&V Project Execution Plan and SWE-131 - Independent Verification and Validation Project Execution Plan.

3.5 Additional Guidance

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

3.6 Center Process Asset Libraries

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

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

•  No products identified at this time.

  
  

  Objective Evidence

  • Evidence of a confirmation that IV&V has the necessary access.
   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

Confirm that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively. 

All software products acquired for NASA projects are to be made available in electronic format so they can be delivered accurately and used efficiently as part of the project. The electronic availability of the software work products, and associated process information, facilitates post-delivery testing that is necessary for assessing as-built work product quality, and for the porting of products to the appropriate hosts. Electronic access to software projects reduces NASA's project costs.

This access also accommodates the longer-term needs for performing IV&V, including defect repairs and software component augmentations, assessing operation or system errors, addressing hardware and software workarounds, and allowing for the potential reuse of the software in the future NASA projects.

Electronic access is needed during all phases of the software development life cycle. This enables software supplier activities to be monitored to ensure the software work products are being developed efficiently and that the end products that are called for in the project and software requirements are produced.

What Needs To Be Accessible?

• Software, executable, and source code
• Models and simulations
• Programmable Logic Device logic and software
• Trade study data, including software tools, used to help formulate an analysis of alternative results if any scenarios need to be re-run later
• Prototype software, including prototype architectures/designs
• Data definitions and data sets
• Software ground products
• Software build products
• Build tools
• Software documentation, including data presented during any early design reviews
• Metric data
• Software cost data and parameters
• Software database(s)
• Software development environment
• Software Test Scripts and the results of software testing
• Results of software static analysis activities
• Bi-directional traceability for the software products
• Software analyses and compliance data
• Software configuration data and software rule sets

Other documentation and products to consider includes:

1. 1. Summary and status of all accepted Change Requests to the baselined Software Requirements Specifications.
   2. Summary and status of all major software capability changes since baselining of the Software Design Documents
   3. Summary and status of all major software tests (including development, verification, and performance testing).
   4. Summary and status of all Problem Report written against the software.
   5. Summary and status of all software requirements deviations and waivers.
   6. Summary and status of all software user notes.
   7. Summary and status of all quality measures historically and for this software.
   8. Definition of openwork, if any.
   9. Software configuration records define the verified and validated software, including requirements verification data (e.g., requirements verification matrix).
   10. The final version of the software documentation, including the final Software Version Description document(s).
   11. Summary and status of any open software-related risks.

7.5 Additional Guidance

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