Lessons from Building High-Assurance Systems

Over time, RELA began to specialize in the development of various types of computer-based medical devices and systems: portable ventilators ( breathing machines), infusion pumps, pacemaker programmers, clinical diagnostic systems, blood pumps, patient-monitoring equipment, and a plethora of other diagnostic and therapeutic devices.

It was early during the ventilator development project that the ultimate accountability for what we were doing really hit us: Whoa, if we screw this up, somebody could die! Our primary concern was for the patient and for the family of the patient who was tethered to the device, a device on which we were executing some of the earliest, most time-critical, resource-limited software the world had yet seen. (Imagine the challenge of alpha and beta testing. You go first!)

Clearly, this high-stakes endeavor caused us to take software very seriously at a fairly early time in the evolution of the embedded-systems industry. It became clear very quickly that sustainable success would require a combination of

• A pragmatic process for defining and managing the requirements for the software

• A solid methodology for the design and development of software

• The application of various proven, innovative techniques for verifying and validating that the software was safe and effective

• Extraordinary skills and commitment on the part of both the software development and software quality assurance teams

I strongly believed at that time, and I am even more convinced today, that all of those elements are required to deliver any reasonably reliable software system of any significant scope . At RELA, Inc., this was to be the only way we could possibly ensure each patient's safety, the very survival of our company, and the economic futures of the employees and their families who depended on the company.

Big Question 2: "How, exactly, will we know when the software does exactly that and nothing else?"

Given our earlier success in the development and application of the various techniques we used to answer Big Question 1, we now moved on to the second fundamental question facing software development teams worldwide. Big Question 2 is

How, exactly, will we know when the software does exactly that and nothing else?

The techniques we used to answer this question form the basis of Team Skill 5, Refining the System Definition, and Team Skill 6, Building the Right System.

So, you can be confident that the techniques presented in this book are road hardened and well proven. Also, even if you are not in the business of developing safety-critical systems, you can rest assured that what follows is useful, practical, and cost-effective advice that you can use to develop software systems of the highest quality.

Although the techniques that we borrowed, modified, developed, and applied at RELA, Inc., to address the two big questions were highly effective, I must also admit to one nagging uncertainty that kept me awake during the most serious crunch times on these projects:

Given the highly manual nature of the requirements process, how long would it be before we made a single, but potentially dangerous, mistake?

And there was also the matter of cost, as manual verification and validation were expensive and error prone. During this period, the discipline of mechanical engineering had advanced from a mechanical drawing arm to 3-D computer-aided design systems. In the same period, our software advances were limited, for all practical purposes, to having increased the level of abstraction in our programming languages: a good thing, for certain, but defect rates, lines-of-code productivity factors, and quality measures were relatively constant. Our experiments with the CASE tools of that period were met with mixed results. Frankly, as a software engineer and entrepreneur, I found the state of the art in "software engineering" to be embarrassing.

Although it was obvious that automation would never eliminate the critical-thinking skills required in software development, I did become convinced that automating some of the manual, record-keeping , and change management aspects of the process would free scarce resources to focus on higher value-added activities. And, of course, we anticipated that development costs would be lower while reliability would be increased!