Biomedical Engineering Reference
In-Depth Information
Verification and validation life
cycle activities
subsections describe in more detail anomaly reporting,
metrics collection, and reporting, and they provide some
additional topics that are important to verification and
validation.
In the SVVP, this section typically includes the criteria,
inputs/outputs, reviews, testing approach, and training
for each verification and validation phase. The criteria
describes the goal that each phase is defined to achieve.
The inputs/outputs phase defines what things are needed
as inputs into the phase and what the product of each
phase are.
It is also helpful to add a subsection on the general
functionality that will be tested. The IEEE standard does
not call this out. However, adding this subsection is
helpful to reviewers of the SVVP. It provides information
on the functionality that is scheduled for testing.
Anomaly reporting and resolution
One result of verification and validation is the generation
of anomalies found during testing. A process for
reporting anomalies must be in place to record anomalies.
Some institutions have used a lab notebook to document
anomalies. More frequently, a PC-based database pro-
gram is used to log and to store anomalies electronically.
In addition, a process must be in place for resolution
of anomalies found against the product software. It can
be a committee of people who are responsible for the
product or simply the software test coordinator who is
working with the primary software developer. The
responsible parties determine the risk of each anomaly.
Verification and validation
documentation
Each verification and validation phase has its activities
and documentation that is associated with it. For unit,
integration, and software validation test phases, typically
there are test plans, test procedures, and test results and
reports.
For software validation, there usually are some addi-
tional documents. The Software validation group typi-
cally has a requirements-to-test cross-reference. The
cross reference ensures that all the requirements defined
in the SRS are covered in some test. It is also helpful
in the cross-reference document to include a test-to-
requirement cross-reference. This backward reference
helps to ensure that a requirement has adequate cover-
age. The software validation group also generates
a procedure-response document, which serves as a means
to close out any issues or comments that occurred during
an official validation pass. Finally, the software validation
group has been responsible for writing a final report
called the software verification and validation report
(SVVR), which summarizes the activities from all of the
previous verification and validation phases.
Validation metrics
There are several aspects of verification and validation in
which it is helpful to generate metrics. The first and most
obvious one is anomaly metrics. An example of anomaly
metric tracking is shown in
Figure 5.4-2
. This chart
shows the tracking of open severitized anomalies as
a function of time.
The second aspect of test metrics is those involving
test development. These metrics are used to monitor the
test development process and to monitor overall test
parameters for all projects. Monitoring the test
development process ensures that the test development
is proceeding according to schedule. An example is
shown in
Figure 5.4-3
.
Configuration management
Just as it is important to maintain a configuration for
product development code, it is equally important to
practice configuration management on test protocols.
Configuration of test materials includes:
Script libraries
Test scripts
Manual protocol
Test results
Test plans and procedures
Test system design
Verification and validation administrative
procedures
This section provides additional guidance on ways that
the verification and validation will be conducted. IEEE
Std 1012-1986 defines this section as including anomaly
reporting/resolution, task iteration policy, deviation
policy, control procedures, and standards/practices/
conventions.
It is also useful to include section metrics. IEEE Std
730.1-1989, IEEE Standard for Assurance Plans, in-
cludes metrics as part of a SQAP. The following
Protocol templates
To make the development of tests more uniform and
efficient, it is advisable to have templates for the test
