Independent software verification and validation
This redirect may meet Wikipedia's criteria for speedy deletion because in its current form it serves only to promote or publicise an entity, person, product, or idea, and would require a fundamental rewrite in order to become encyclopedic. However, the mere fact that a company, organization, or product is a page's subject does not, on its own, qualify that page for deletion under this criterion. This criterion also does not apply where substantial encyclopedic content would remain after removing the promotional material as deletion is not cleanup; in this case please remove the promotional material yourself, or add the {{advert}} tag to alert others to do so. See CSD G11.
If this redirect does not meet the criteria for speedy deletion, or you intend to fix it, please remove this notice, but do not remove this notice from pages that you have created yourself. If you created this page and you disagree with the given reason for deletion, you can click the button below and leave a message explaining why you believe it should not be deleted. You can also visit the talk page to check if you have received a response to your message. Note that this redirect may be deleted at any time if it unquestionably meets the speedy deletion criteria, or if an explanation posted to the talk page is found to be insufficient.
Note to administrators: this redirect has content on its talk page which should be checked before deletion. Administrators: check links, talk, history (last), and logs before deletion. Consider checking Google.This page was last edited by Npsilva (contribs | logs) at 10:56, 27 August 2008 (UTC) (16 years ago) |
ISVV stands for Independent Software Verification and Validation. ISVV is targeted at safety-critical software systems and aims to increase the quality of software products, thereby reducing risks and costs through the operational life of the software. ISVV provides assurance that software performs to the specified level of confidence and within its designed parameters and defined requirements.
ISVV activities are performed by independent engineering teams, not involved in the software development process, to assess the processes and the resulting products. The ISVV team independency is performed at three different levels: financial, managerial and technical.
ISVV goes far beyond “traditional” verification and validation techniques, applied by development teams. While the latter aim to ensure that the software performs well against the nominal requirements, ISVV is focused on non-functional requirements such as robustness and reliability, and on conditions that can lead the software to fail. ISVV results and findings are fed back to the development teams for correction and improvement.
ISVV History
ISVV derives from the application of IV&V (Independent Verification and Validation) to the software. Early ISVV application (as known today) dates back to the early 1970s when the U.S. Army sponsored the first significant program related to IV&V for the Safeguard Anti-Ballistic Missile System.
By the end of the 1970s IV&V was rapidly becoming popular. The constant increase in complexity, size and importance of the software lead to an increasing demand on IV&V applied to software (ISVV).
Meanwhile IV&V (and ISVV for software systems) gets consolidated and is now widely used by organisations such as the DoD, FAA, NASA[1] and ESA[2]. IV&V is mentioned in [DO-178B], [ISO/IEC 12207] and formalised in [IEEE 1012].
Recently, an European consortium lead by the European Space Agency, and composed by DNV(N)[3], Critical Software SA(P)[4], Terma(DK)[5] and CODA Scisys(UK)[6] has created a guide devoted to ISVV, called "ESA Guide for Independent Verification and Validation". This guide covers the methodologies applicable to all the software engineering phases in what concerns ISVV.
ISVV Methodology
ISVV is usually composed by five principal phases, these phases can be executed sequentially or as results of a tailoring process.
ISVV Planning
- Planning of ISVV Activities
- System Criticality Analysis: Identification of Critical Components through a set of RAMS activities (Value for Money)
- Selection of the appropriate Methods and Tools
Requirements Verification
- Traceability between Software and System requirements
- Verification for: Completeness, Correctness, Testability
Design Verification
- Design adequacy and conformance to Software Requirements and Interfaces
- Internal and External Consistency
- Verification of Feasibility and Maintenance
Code Verification
- Traceability between Design and Code phase
- Verification for: Completeness, Correctness, Consistency
- Code Metrics Analysis
- Coding Standards Compliance Verification
Validation
- Identification of unstable components/functionalities
- Validation focused on Error-Handling: complementary (not concurrent!) validation regarding the one performed by the Development team (More for the Money, More for the Time)
- Compliance with Software and System Requirements
- Black box testing and White box testing techniques
- Experience based techniques