|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What is Verification and Validation?
IEEE Definition
Verification "Confirmation by examination and provisions of
objective evidence that specified requirements have been fulfilled." Validation "Confirmation by examination and provisions of
objective evidence that the particular requirements for a specific intended
use are fulfilled." Using the above definitions in software
development
Verification is the
activity that ensures the work products of a given phase fully implement the
inputs to that phase, or "the product was built right." Validation,
in its simplest terms, is the demonstration that the software implements each
of the software requirements correctly and completely. In other words, the "right
product was built." Levels of Verification
There are four levels of
verification:
Methods of Verification
There are four methods of
verification that can be applied to the various levels outlined above:
Explanation
The four methods for
verification can be used at any of the levels although some work better than
others for a given level of verification. As an example, the most effective
way to find anomalies at the component level is inspection. On the other
hand, inspection is not applicable at the system level (you don't look at the
details of code when performing system level testing). A logical approach to
testing is to utilize techniques and methods that are most effective at a
given level. Component level verification
can easily get very expensive. Companies need to avoid making statements like
"all paths and branches will be executed during component testing."
These statements make for a very expensive test program, as all code
developed is required to have one of the most labor-intensive types of
testing performed on it. To minimize the costs of component verification, the
V&V group develops rules for determining the type of verification
method(s) needed for each of the software functions. As an example, very low
complexity software function, which is not on the safety critical list, may
only need informal inspection (walkthrough) performed. Other complicated
functions typically require white box testing since the functions become
difficult to determine how they work. We recommend performing inspections
before doing the white box testing for a given module as it is less expensive
to find the errors earlier in the development. Large organizations are
embracing V&V as the primary way of proving your system does what you
intended and also meets the needs of the people using it. The resulting
V&V effort has become a significant part of the software development
effort for a medical device. One of the key pieces to demonstrate that the
system is implemented completely is a Requirements Traceability Matrix (RTM),
which documents each of the requirements traced to design items, code, unit,
integration and system test cases. The RTM is an easy and effective way for
documenting your implementation in a manner to which the FDA is familiar -
what are the requirements, where are they implemented, and how have you
tested them. |
|
|
|
|
|
|
