Biomedical Engineering Reference
In-Depth Information
logical flow (how it relates). In the same light, in-line
code documentation (comments) should most often
address ''why'' rather than ''how'' functionality is imple-
mented. These two focuses help the code reader to
understand the context in which a given segment of
code is used. With precious few exceptions (e.g., high-
performance-device drivers) quality source code should
be recognized by its readability, and not by its raw size
(i.e., the number of lines) or its ability to take advantage
of processor features.
verification process ingrained
d
they naturally go hand-
in-hand.
Software project management plans (or software
quality assurance plans (SQAP)) should specify all design
reviews. Each level of design will generate documentation
to be reviewed or deliverables to verify against the de-
mands of the previous stage. For each type of review, the
software-management plans should describe the purpose,
materials required, scheduling rules, scope of review, at-
tendance expectations, review responsibilities, what the
minutes should look like, follow-up activities, and any
other requirements that relate to company expectations.
At the code level, code reviews should ensure that the
functionality implemented within a routine satisfies all
expectations documented in the ''mspecs.'' Code also
should be inspected, to satisfy all coding rules.
The output of good software designs also includes
implementation requirements. At a minimum, imple-
mentation requirements include the rules and expecta-
tions placed on the designers to ensure design uniformity
as well as constraints, controls, and expectations placed
on designs to ensure that upper-level requirements are
met. General examples of implementation requirements
might include rules for accessing I/O ports, timing re-
quirements for memory accesses, semaphore arbitration,
inter-task communication schemes, memory-addressing
assignments, and sensor- or device-control rules. The
software-verification and -validation process must ad-
dress implementation requirements as well as the upper-
level software requirements to ensure that the product
works as it was designed to.
Design support tools
Software development is very labor-intensive and, is
therefore, prone to human error. In recent years, com-
mercial software-development support packages have
become increasingly more powerful, less expensive, and
more available to reduce the time spent doing things that
computers do. Although selection of the right tools can
mean up-front dedication of some of the most talented
resources in a development team, it also can bring about
significant long-term increase in group productivity.
Good software-development houses have taken
advantage of CASE tools that reduce the time spent
generating clear and thorough design documentation.
The advantages of automated software-design packages
are many. Formal documentation can be used as proof of
product development procedure conformance for agency
approvals. Clear and up-to-date design documents facil-
itate improved communications between engineers, thus
lending to more effective and reliable designs. Standard
documentation formats reduce learning curves that are
associated with unique design depictions among software
designers, thus leading to better and more timely design
formulation. Total software life cycle costs are reduced
(especially during maintenance) due to reduced ramp-up
time and more efficient and reliable modifications.
Finally, electronic forms of documentation can be easily
backed up and stored off-site, thus eliminating a crisis in
the event of an environmental disaster. In summary, the
adaptation of CASE tools has an associated up-front cost
that is recovered by significant improvements in software
quality and development-time predictability.
Verification and validation
life cycle
An SVVP lays out the framework from which the veri-
fication and validation activities proceed. IEEE 1012-
1986 is very detailed about development life cycle and
the verification and validation products that are gener-
ated at each phase. Specifically, the standard calls out the
following phases:
Concept phase
Requirements phase
Design phase
Implementation phase
Test phase
Installation phase
Operation and maintenance phase
In industry, it is more typical for software verification and
validation to follow a simpler model, as shown in the
Figure 5.4-1
.
This model is simpler in that it focuses verification and
validation activities on the software that is generated,
Design as the basis for verification
and validation
Verification is the process of ensuring that all products of
a given development phase satisfy given expectations.
Prior to proceeding to the next-lower level or phase of
design, the product (or outputs) of the current phase
should be verified against the inputs of the previous stage.
A design process cannot be a ''good'' process without the
