Review By: Cathy Bell
12/20/2011When you step on an elevator or watch an airplane fly overhead, have you ever stopped to think of who tested the software that controls these systems? Was the tester sick or tired the day she signed off on the testing? Was the release date near, and the tester was under pressure and skipped a set of test cases for a scenario that "would never happen"?

This book instructs its readers on how to implement a formal verification structure for systems that are safety critical. The description states that "safety-critical systems—by definition those system whose failure can cause catastrophic results for people, the environment, and the economy—are becoming increasingly complex both in their functionality and their interactions with the environment." How do we make these systems perform the functions for which they are intended and at the same time ensure the safety of those who rely on these systems or who would be affected by their failure? A formal process, as outlined in the material, would lessen the likelihood that either of those scenarios would happen.

The preface states the book can be used as a reference book for students pursuing bachelor’s or master's degrees in engineering and computer science. I see this also as a reference book for software testers who are going to be working on safety-critical systems.

There are many formulas in the book. Some are complex, but the complexity of our systems calls for their use. The authors explain that our dependence on technology brings about systems that can gain improved performance or reduced costs, but we increase the complexity of the system as a tradeoff.

The introduction covers basic concepts of the classifications of failures in a system, what can cause these failures, and how others have dealt with them in the past. As examples, the authors describe failures in aviation and a case study of the Three Mile Island nuclear reactor failure. They define in detail the terms we should use when designing and assessing safety-critical systems, such as "fault tolerance," "fault coverage," "failures," and "reliability." A "hazard," an "accident," and a "fault" are all potentially harmful events, and the book teaches us how to evaluate them by severity and probability of occurrence, to determine the risk of a failure, and to test at various points to help assess that failures have been avoided in the application. Development of these systems relies on accurate assessment of these risks, and the book covers what makes our systems complex, with formulas to help assess the complexity. In one example, IBM applies the formal methods for safety assessment to its Customer Information Control System, built in the 1980s, and is able to reduce development costs for the release of its newest software by 9 percent.

The material in the book champions these formal processes. At times, some may think that the processes add too much time and cost and that short cuts can be taken. But, as examples from the book show, following the procedures can actually result in a reduction in time and a less-fault-tolerant system. Think about this the next time that unmanned subway car is pulling into the station as you disembark the subway car directly in front of it. Aren't you glad that both the developers and software testers were aware that they were working on a safety-critical system, took the time to learn concepts covered in this material, and applied that knowledge to their development and testing?