Sometimes you run into things that just want you to shake your head and wonder, what is going on here? Case in point the National Highway Traffic Safety Administration outsourced the study of Toyota's Sudden Acceleration problem to NASA because they where perceived to be the best around to study this problem. Now this week we find that NASA wants to outsource their Validation and Verification work. Good enough for cars but not space shots??
Before getting to the NASA solicitation I want to define what Validation and Verification mean. Like many people confuse Weather Watches and Warnings many people are unclear on the difference between Validation and Verification.
- Weather watch is used when the risk of an event has increased, but its occurrence and timing is still uncertain.
- Weather warning is used for conditions posing a threat to life or propert.
The FDA's Glossary of Computerized System and Software Development Terminology, defines many of the terms used on in this blog and our Software Safety site.
Defect: The difference between the expectation and the actual results.
Validation and Verification:
Validation and Verification are a set of terms you find when working with Software Safety. Many people do not understand how they differ from each other.
These are my working definitions for Validation and Verification (V&V):
- Validation: Have we built the correct device? Do we meet the customer's requirements?
- Verification: Have we built the device correctly? Did we find and remove all of the 'bugs'?
Requirements and Specifications:
Clarifying the distinction between the terms "requirement" and "specification" is important.
My working definitions for Requirements and Specifications:
Requirements are a statement of what the customer wants and needs. Requirements are used for validation. Specifications are the documentation of how the customer requirements are met by the system design. Specifications are used for verification.
A requirement can be any need or expectation for a system or for its software. Requirements reflect the stated or implied needs of the customer, and may be market-based, contractual, or statutory, as well as an organization's internal requirements. There can be many different kinds of requirements (e.g., design, functional, implementation, interface, performance, or physical requirements). Software requirements are typically derived from the system requirements for those aspects of system functionality that have been allocated to software. Software requirements are typically stated in functional terms and are defined, refined, and updated as a development project progresses. Success in accurately and completely documenting software requirements is a crucial factor in successful validation of the resulting software, and the project as a whole.
A specification "means any requirement with which a product, process, service, or other activity must conform." (See 21 CFR§820.3(y).) It may refer to or include drawings, patterns, or other relevant documents and usually indicates the means and the criteria whereby conformity with the requirement can be checked. There are many different kinds of written specifications, e.g., system requirements specification, software requirements specification, software design specification, software test specification, software integration specification, etc. All of these documents establish "specified requirements" and are design outputs for which various forms of verification are necessary.
Device failure (21 CFR§821.3(d)). A device failure is the failure of a device to perform or function as intended, including any deviations from the device’s performance specifications or intended use.
Now with that background under our belt we can get a better grasp of what NASA is seeking in their, Proposals For Software Verification And Validation. This contract will provide resources for NASA-directed software verification and validation services; software safety assurance support for agency missions; and potential software development work for other government agencies.
NASA INDEPENDENT VERIFICATION AND VALIDATION SERVICES
Solicitation Number: NNG11310421R
Agency: National Aeronautics and Space Administration
Location: Office of Procurement (HQ)
Added: Sep 21, 2010 3:02 pm Modified: Mar 02, 2011 5:35 pm
NASA/Goddard Space Flight Center announces the release of the final RFP for NASA Independent Verification and Validation Services. Proposals submitted in response to this RFP shall be submitted by April 5, 2011, at 3:00pm Eastern Standard Time.The due date for questions or comments is March 24, 2011 to ensure our timely response. All questions and comments must be submitted in writing via email to the following email addresses: Laura.E.Freeman[-a-t-despaming]nasa.gov. Telephone questions will not be accepted. Technical documents related to this procurement can be obtained from the Procurement Proposal Library at: http://www.nasa.gov/centers/ivv/recompete/index.html. Documents related to this procurement will be available over the Internet. These documents will reside on a World Wide Web (WWW) server, which may be accessed using a WWW browser application. The Internet site, or URL, for the NASA/HQ Business Opportunities home page is http://prod.nais.nasa.gov/cgi-bin/eps/bizops.cgi?gr=D&pin=04 Offerors are responsible for monitoring this site for the release of the solicitation and any amendments. Potential offerors are responsible for downloading their own copy of the solicitation and amendments (if any).
Here is the link to NASA's V&V Facility, and I'll repeat the link I gave last week to NASA's Software Safety Guidebook. NASA has other standards and programs that are worth studying such as their Standards and Technical Assistance Resource Tool, for example the Software Formal Inspections Standards and Langley's Formal Methods.