1. Requirements

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 shall be completed and transferred as part of the overall package.

1.2 History

1.3 Applicability Across Classes

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

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.

IV&V is a part of Software Assurance playing a role in the NASA software risk mitigation strategy.  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.

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

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.

Additional guidance related to IV&V may be found in the following related requirement in this Handbook:

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

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

7.2 Software Assurance Products

•  No products identified at this time.

  
  

  Note
  title Objective Evidence
  Evidence of a confirmation that IV&V has the necessary access.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

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.