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.
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.
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.
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
) 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.
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:
No additional guidance is available for small projects.
Visible to editors only
Enter the necessary modifications to be made in the table below:
SWEREFs to be added
SWEREFS to be deleted
SWEREFs called out in the text: 028
SWEREFs NOT called out in text but listed as germane: none
Tools Table Statement
Tools Table Statement
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
SWE-178 - IV&V Artifacts
SWE-178 - IV&V Artifacts
7.1 Tasking for Software Assurance
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.
Evidence of a confirmation that IV&V has the necessary access.
Definition of objective evidence
SITE:Definition of Objective Evidence
SITE:Definition of Objective Evidence
None identified at this time
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 on 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 actually 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
Software documentation, including data presented during any early design reviews
Software cost data and parameters
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 for includes:
Summary and status of all accepted Change Requests to the baselined Software Requirements Specifications.
Summary and status of all major software capability changes since baselining of the Software Design Documents
Summary and status of all major software tests (including development, verification, and performance testing).
Summary and status of all Problem Report written against the software.
Summary and status of all software requirements deviations and waivers.
Summary and status of all software user notes.
Summary and status of all quality measures historically and for this software.
Definition of openwork, if any.
Software configuration records defining the verified and validated software, including requirements verification data (e.g., requirements verification matrix).
The final version of the software documentation, including the final Software Version Description document(s).
Summary and status of any open software-related risks.