bannerc

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed SWE table in tab 3
Tabsetup
01. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
67. Software Assurance
Div
idtabs-1

1. Requirements

Excerpt

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

1.2 History

Click here to view the history of this requirement: SWE-178 History

1.3 Applicability Across Classes

Applicable c
a1
b1
csc1
c0
d0
dsc1
e0
f0
g0
h0

Div
idtabs-2

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.


Div
idtabs-3

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

Swerefn
refnum028
) 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:

Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects.

Div
idtabs-5

5. Resources

5.1 References

refstable
Show If
groupconfluence-users
Panel
titleColorred
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted
added SWEREF-028

SWEREFs called out in the text: 028

SWEREFs NOT called out in text but listed as germane: none




5.2 Tools

Include Page
Tools Table Statement
Tools Table Statement

Div
idtabs-6

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.

Div
idtabs-7

7. Software Assurance

Excerpt Include
SWE-178 - IV&V Artifacts
SWE-178 - IV&V Artifacts

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

    Include Page
    Definition of Objective Evidence
    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 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:

    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 defining 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.