Biomedical Engineering Reference
In-Depth Information
software consistent with the specified requirements
must be selected. To develop accurate estimates, a his-
torical baseline must be established, consisting of data
collected from previous software projects. The data
collected should be reasonably accurate, collected from
as many projects as possible, consistent, and represen-
tative of applications that are similar to work that is to be
estimated. Once the data have been collected, metric
computation is possible.
Metrics that can be used to measure periodic progress
in achieving the improvement goals are then defined. The
metric data collected can be used as indicators of de-
velopment process problem areas, and improvement ac-
tions identified. These actions can be compared and
analyzed with respect to the best return on the business's
investment. The measurement data provide information
for investing wisely in tools for quality and productivity
improvement.
A feedback mechanism must be implemented so that
the metrics data can provide guidance for identifying
actions to improve the software development process.
Continuous improvements to the software development
process result in higher-quality products and increased
development team productivity. The process-improve-
ment actions must be managed and controlled so as to
achieve dynamic process improvement over time.
file names or design-model identifiers to denote that
a requirement is satisfied within a design entity. A RTM
ensures completeness and consistency with the software
specification, which can be accomplished by forming
a table that lists the requirements from the specification
versus the way each is met in each phase of the software-
development process.
Software reviews
Timely and well-defined reviews are integral parts of all
design processes. Each level of design should produce
design-review deliverables. Software project develop-
ment plans should include a list of the design phases, the
expected deliverables for each phase, and a sound defi-
nition of the deliverables to be audited at each review.
Reviews of all design material have several benefits.
First and foremost, authors are more compelled to ele-
vate the quality of their work when they know that their
work is being reviewed. Second, reviews often uncover
design blind spots and alternative design approaches.
Finally, the documentation generated by the reviews is
used to acquire agency approvals for process and product.
Software reviews can take several different forms:
Inspections, design, and code
Code walk-throughs
Code reading
Dog-and-pony shows
An inspection is a specific kind of review that has been
shown to be extremely effective in detecting defects, and
to be relatively economical as compared to testing.
Inspections differ from the usual reviews in several ways:
Checklists focus the reviewer's attention on
areas that have been problems in the past
The emphasis is on defect detection, not correction
Reviewers prepare for the inspection meeting
beforehand and arrive with a list of the problems
they have discovered
Data are collected at each inspection and are fed into
future inspections to improve them
The general experience with inspections has been that
the combination of design and code inspections usually
removes 60-90% of the defects in a product. Inspections
identify error-prone routines early, and reports indicate
that they result in 30% fewer defects per 1000 lines of
code than walkthroughs do. The inspection process is
systematic because of its standard checklists and stan-
dard roles. It is also self-optimizing because it uses
a formal feedback loop to improve the checklists and to
monitor preparation and inspection rates.
A walkthrough usually involves two or more people
discussing a design or code. It might be as informal as an
Requirements traceability
It is becoming increasingly apparent how important
thorough requirements traceability is, during the design
and development stages of a software product, especially
in large projects with requirements that number in the
thousands or tens of thousands. Regardless of the design
and implementation methodology it is important to
ensure that the design is meeting its requirements dur-
ing all phases of design. To ensure that the product is
designed and developed in accordance with its require-
ments throughout the development cycle, individual re-
quirements should be assigned to design components.
Each software requirement, as might appear in a SRS, for
example, should be uniquely identifiable. Requirements
that result from design decisions (i.e., implementation
requirements) should be uniquely identified and tracked
along with product functional requirements. This process
not only ensures that all functional and safety features are
built into the product as specified, but also drastically
reduces the possibility of requirements ''slipping through
the cracks''. Overlooked features can be much more ex-
pensive when they become designmodifications at the tail
end of development.
The RTM is generally a tabular format with re-
quirement identifiers as rows, and design entities as
column headings. Individual matrix cells are marked with
