Developing software is a risky business. That's why so
many software support and testing companies exist. For most industries,
it's an unregulated activity. You can basically develop software any way
you like.
In the medical device business, however, there are
stringent FDA software validation guidelines. These guidelines help
steer medical device manufacturers in the processes and techniques they
use to build high quality software. As you can imagine, having a
software failure in an implantable medical device is undesirable, to say
the least, for both the patient and the manufacturer.
According to
FDA reports, between 1992 and 1998, 7.7 percent of medical device
product recalls were attributable to software failures. Of these
failures, 79 percent were caused by software problems that occurred as a
result of software changes after the initial product was released. This
implies that there are process issues that must be addressed when
updating software. This is also a major area of concern in the larger
software development industry.
Software, by nature, is designed
to be upgraded and enhanced over time. While this is certainly a major
advantage of this technology, it can also be a massive liability. If
solid development and change processes are not in place, or are not
accurately followed, errors are likely to surface at a later date, as
evidenced by the FDA numbers and data from a host of other non-medical
software projects.
The FDA knows that implementing a few
fundamental best practices is the key to consistently developing high
quality, reliable software. One of the principle tenets of world-class
software development is that you cannot "test quality into" the software
after it's built. Most testing will only find defects, and while this is
entirely necessary, more testing needs to be done up front to actually
prevent defects in the first place.
There are several proven
steps that can and should be taken by all software manufacturers to
prevent defects and deliver higher quality software
products:
Quality planning from the outset: Good quality doesn't
just happen. It needs to be planned. This includes buy-in from relevant
stakeholders up front, with a documented plan that requires signatures
from these key stakeholders.
Thorough documentation of all
software requirements: The key to all good software development is to
start with great requirements. They must be both specific and
testable.
Design and code reviews with peers and business line
owners: This is an area that many times is overlooked, but the benefits
gained for the amount of time spent can be significant.
Ironclad
change management: Having a well-defined testing process for setting new
feature priorities is critical. The method I prefer is to weigh the
business benefits against the technical complexity of the feature,
coupled with costs and timelines. A big part of change management is
keeping control of schedules. Remember that every new feature must have
requirements defined--designed, coded, tested and integrated with other
features appropriately. In many cases it can be very difficult to even
add what seems to be a simple new feature.
Get a commitment from
senior management to deliver high quality software: If you don't have
real backing, then all of these points are probably
meaningless.
In the long run, software manufacturers that follow
these principles will actually cut costs and improve their product. That
is why the FDA mandates certain processes and controls. There is plenty
of public data available, from the Software Engineering Institute at
Carnegie Melon University, for example, to support the claims of cost
savings from strict adherence to proven software quality processes.
It's never really been about having the necessary knowledge to
build software correctly, but figuring out how to institutionalize it
within the organization in an effective way. This is where independent
software quality firms offer an advantage by leveraging their
independence and experience to rally development groups and management
to embrace the quality processes and tools they need to be
successful.
If more software organizations adopted the general
approaches defined by the FDA for medical device manufacturers, there
would be far fewer software horror stories making headlines. These
organizations would also save time and money on recalls and customer
support. And, of course, the goodwill they earn with their customers is
immeasurable.
John R. Fox is vice president of SWAT
Solutions (jfox@swatsolutions.com).
