Biomedical Engineering Reference
In-Depth Information
impromptu bull session around a whiteboard; it might be
as formal as a scheduled meeting with overhead trans-
parencies and a formal report sent to management.
Following are some of
Execution estimates for the system interfaces, response
times for external devices, algorithm execution times,
operating system context-switch time, and I/O device
access times in the forefront of the design process pro-
vide essential input into software design specifications.
For single processor designs, mathematical modeling
techniques such as Rate Monotonic Analysis (RMA)
should be applied, to ensure that all required operations
of that processing unit can be performed within the
expected timeframes. System designers often fall into
the trap of selecting processors before the software
design has been considered, only to experience major
disappointment and ''finger pointing'' when the product
is released. It is imperative to a successful project that
the processor selection comes after a processor-loading
study is complete.
In a multiprocessor application, up-front system per-
formance analysis is equally important. System anoma-
lies can be very difficult to diagnose and resolve in
multiprocessor systems with heavy interprocessor com-
munications and functional expectations. Performance
shortcomings that appear to be the fault of one processor
are often the result of a landslide of smaller inadequacies
from one or more of the other processors or subsystems.
Person-years of integration phase defect resolution can be
eliminated by front-end system design analysis and/or
design simulation. Commercial tools are readily available
to help perform network and multiprocessor communi-
cations analysis and execution simulation. Considering
the pyramid of effort that is needed in software design,
defect correction in the forefront of design yields enor-
mous cost savings and increased reliability in the end.
the characteristics of a
walkthrough:
The walkthrough is usually hosted and moderated by
the author of the design or code under review.
The purpose of the walkthrough is to improve the
technical quality of a program, rather that to assess it.
All participants prepare for the walkthrough by
reading design or code documents and by looking for
areas of concern.
The emphasis is on error detection, not correction.
The walkthrough concept is flexible and can be
adapted to the specific needs of the organization
using it.
When used intelligently, a walkthrough can produce
results that are similar to those of an inspection; i.e., it
typically can find between 30-70% of the errors in
a program. Walkthroughs have been shown to be mar-
ginally less effective than inspections, but under some
circumstances they can be preferable.
Code reading is an alternative to inspections and
walkthroughs. In code reading, source code is read for
errors. Readers also comment on qualitative aspects of
the code, such as its design, style, readability, maintain-
ability, and efficiency. A code reading usually involves two
or more people reading code independently and then
meeting with the author of the code to discuss it. To
prepare for a meeting, the author hands out source list-
ings to the code readers. Two or more people read the
code independently. When the reviewers have finished
reading the code, the code-reading meeting is hosted by
the author of the code and focuses on problems that the
reviewers have discovered. Finally, the author of the code
fixes the problems that the reviewers have identified.
''Dog-and-pony shows'' are reviews in which a soft-
ware product is demonstrated to a customer. The pur-
pose of these reviews is to demonstrate to the customer
that the project is viable, so they are management
reviews rather than technical reviews. They should not
be relied upon to improve the technical quality of a pro-
gram. Technical improvement comes from inspections,
walkthroughs, and code reading.
Coding
For many years, the term ''software development'' was
synonymous with coding. Today, for many software-
development groups, coding is now one of the shortest
phases of software development. In fact, in some cases,
although very rare in the world of real-time embedded
software development, coding is actually done automat-
ically from higher-level design (mspecs) documentation
by automated tools called ''code generators.''
With or without automatic code generators, the ef-
fectiveness of the coding stage is dependent on the
quality and completeness of the design documentation
generated in the immediately preceding software de-
velopment phase. The coding process should be a simple
transition from the module specifications, and, in par-
ticular, the pseudocode. Complete mspecs and properly
developed pseudocode leave little to interpretation for
the coding phase, thus reducing the chance of error.
The importance of coding style (how it looks) is not as
great as the rules that facilitate comprehension of the
Performance predictability
and design simulation
The effort to predict the real-time performance of
a system is a key activity of design that some software
developers often overlook. During the integration phase,
software designers often spend countless hours trying to
fine-tune a system that has bottlenecks ''designed in''.
