Biomedical Engineering Reference
In-Depth Information
problems during the test, he will document the issue on
the test procedures.
It is important that the handwritten notes on the
paper procedures be addressed. The notes on the
procedures could be problems found or procedure
deviations. All of these markings must have closure. This
closure is formally documented in the procedures
response document. The procedures response document
is covered later in this chapter.
results. This ensures that the tests are executed as
expected. Other analysis might need to occur, such as
when a large amount of data are generated during the
test, after which data reduction and analysis must be
performed to assess correctness.
Test results must be managed along with the other
test documentation. The results from the manual test
procedures must be included with the other paper
documentation and stored in the formalized location.
The electronic results files also must be put under
configuration control. This is done with a configuration-
management tool or a process of backing up the files to
controlled media.
Executing automated protocol
Typically, executing automated protocol amounts to
setting up a batch job to submit a series of tests to be
run. A test engineer fills out a test configuration form to
have a piece of paper to start off the test. The batch job
is then run overnight, and the results are analyzed the
following day.
Experience has shown that a test in the batch occa-
sionally can fail. This failure usually has been attributable
either to timing issues or to the target-device feature
having changed but the test not having changed. When
this happens, it is usually a practical matter simply to
correct the test script and to rerun it. However, in
instances where correcting the test script would consume
a large amount of time, it is sometimes more efficient to
run that test manually to complete the test pass.
Test reports
Software validation test report
The key items in this report are a summary of what was
tested, how it was tested, any problems that were
encountered, and a recommendation for release.
Requirements to test cross reference
This document covers the ways in which the require-
ments were allocated to tests.
Procedures response document
As mentioned earlier, all handwritten marks on the
manual test procedures must be reviewed and provided
a closure. The results of this closure are documented in
the procedures response document. Typically, each mark-
up in a test procedure is a software problem, a procedure
error, a procedure deviation, or a comment.
Test results
Once test results have been generated, they must be
analyzed. The results from the automated tests are
reviewed by running searches for keywords that indicate
whether the test had problems. Additional analysis is
performed by reviewing samples of the automated test
Further information
Bass L, Clements P, Kazman R.
Software
Architecture in Practice
. Reading,
MA, Addison Wesley Longman,
1998.
Bloesch A. Overview of Verification and
Validation for Embedded Software in
Medical Devices.
Handbook of Medical
Device Design
. New York, Marcel
Dekker, 2001.
Boehm BW. A Spiral Model of Software
Development and Enhancement.
Computer
5, 1988.
Boehm BW.
Software Engineering
Economics.
Englewood Cliffs, NJ,
Prentice Hall, 1981.
Booch G.
Object-Oriented Analysis and
Design with Applications, 2nd Edition.
Food and Drug Administration,
21 CFR
Part 820.
Washington, DC, U.S.
Government Printing Office, 1997.
Fries RC.
Reliable Design of Medical
Devices
. New York, Marcel Dekker,
1997.
Fries RC, Pienkowski P, Jorgens J. Safe,
Effective, and Reliable Software Design
and Development for Medical Devices.
Med Instrum
30(2), 1996.
Hatley DJ, Pirbhai IA.
Strategies for Real-
Time System Specification.
New York,
Dorset House, 1987.
Humphrey WS.
Managing the Software
Process
. Reading, MA, Addison-Wesley,
1989.
Redwood City, CA, Benjamin
Cummings, 1994.
Booch G, Jacobson I, Rumbaugh J.
The
Unified Modeling Language User Guide
.
Reading, MA, Addison Wesley
Longman, 1998.
Deutsch MS, Willis RR.
Software Quality
Engineering
d
A Total Technical and
Management Approach.
Englewood
Cliffs, NJ, Prentice Hall, 1988.
Dyer M. The
Cleanroom Approach to
Quality Software Development
. New
York, Wiley, 1992.
Fairley RE.
Software Engineering Concepts
.
New York, McGraw-Hill, 1985.
