- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
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.
Click here to view the history of this requirement: SWE-178 History
1.3 Applicability Across Classes
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.
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 028) 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:
4. Small Projects
No additional guidance is available for small projects.
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
- 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.
Definition of objective evidence
- Evidence of a confirmation that IV&V has the necessary access.
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 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.
- 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
- 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 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.