Biomedical Engineering Reference
In-Depth Information
reliability to assist developers in preparing a quality
program. The international community has produced
standards that primarily address software safety. In each
case, the standard is a voluntary document that has
been developed to provide guidelines for designing,
developing, testing, and documenting a software program.
In the United States, the FDA is responsible for
ensuring that the device utilizing the software, or the
software as a device, is safe and effective for its intended
use. The FDA has produced several drafts of reviewer
guidelines, auditor guidelines, software policy, and good
manufacturing practices (GMP) regulations addressing
device and process software. In addition, guidelines for
FDA reviewers have been prepared, as have training
programs for inspectors and reviewers. The new version
of the GMP regulation addresses software as part of the
design phase.
The United States is ahead of other countries
in establishing guidelines for medical software de-
velopment. However, there is movement within several
international organizations to develop regulations and
guidelines for software and software-controlled devices.
For example, ISO 9000-3 specifically addresses software
development in addition to what is contained in ISO
9001. CSA addresses software issues in four standards
covering new and previously developed software in crit-
ical and noncritical applications. IEC has a software-
development document currently in development. They
also have a risk analysis document (IEC 601-1-4).
respects. These alternatives are ''traded off,'' one against
the other, in terms of the factors that are important for
the systembeing designed. The design ensues froma series
of technology decisions, which are documented with ar-
chitecture diagrams that combine aspects of data and
control flow. As an iterative component of making tech-
nology decisions, the functionality expressed by the data
flow and control flow diagrams from system requirements
analysis is allocated to the various components of the
system. Although the methods for selection of specific
technology components are not a part of themethodology,
the consequences of the decisions are documented in
internal performance requirements and timing diagrams.
Finally, all factors are taken into account, including
customer desires and political issues to establish the
complete system design. The product of the system
design is called an ''architecture model.'' The architec-
ture includes the components of the system, allocation of
requirements, and topics such as maintenance, reliability,
redundancy, and self-test.
Software architecture
Software architecture is the high-level part of software
design, the frame that holds the more detailed parts of
the design. Typically, the architecture is described in
a single document called the ''architecture specification.''
The architecture must be a prerequisite to the detailed
design, because the quality of the architecture deter-
mines the conceptual integrity of the system. This, in
turn, determines the ultimate quality of the system.
A system architecture first needs an overview that
describes the system in broad terms. It should also
contain evidence that alternatives to the final organiza-
tion have been considered and the reasons why the
organization used was chosen over the alternatives. The
architecture should additionally contain:
Definition of the major modules in a program. What
each module does and its interface should be well
defined
Description of the major files, tables, and data
structures to be used. It should describe
alternatives that were considered and should
justify the choices that were made
Description of specific algorithms or reference
to them
Description of alternative algorithms that were
considered and indicate the reasons why certain
algorithms were chosen
In an object-oriented system, specification of the
major objects to be implemented. It should identify
the responsibilities of each major object and ways in
which the object interacts with other objects. It
Design alternatives and tradeoffs
The determination of the design and the allocation of
requirements is a highly iterative process. Alternative
designs are postulated that could, or are candidates to,
satisfy the requirements. The determination of these
designs is a fundamentally creative activity, a ''cut and
try'' determination of what might work. The specific
techniques used are numerous and call upon a broad
range of skills. They include control theory, optimization,
consideration of man-machine interface, use of modern
control test equipment, queuing theory, communication
and computer engineering, statistics, and other disci-
plines. These techniques are applied to factors such as
performance, reliability, schedule, cost, maintainability,
power consumption, weight, and life expectancy.
Some of the alternative designs will be quickly
discarded, while others will require more careful analy-
sis. The capabilities and quality of each design alternative
is assessed using a set of design factors that are specific to
each application and to the methods of representing the
system design.
Certain design alternatives will be superior in some
respects, while others will be superior in different
