April 2006 93 SOFTWARE TECHNOLOGIES Given the right computer-based tools, the use of formal methods could become widespread and transform software engineering. A common joke among com- puter users is that, for all its extensive documentation, software often behaves in completely surprising ways. The need to reduce a problem to a set of rules that the computer must blindly follow is what makes pro- gramming hard. Components interact and interfere, undesirable properties emerge, and systems fail to satisfy their users’ needs. The inherent difficulty of developing software is responsible for this unpre- dictability: It’s hard to define require- ments, anticipate interactions, and accommodate new functionality. Documentation includes lots of text, pictures, and diagrams that are often imprecise and ambiguous. Important information is often hidden in a mass of irrelevant detail, and design mis- takes are often discovered too late— making it expensive or even impossible to correct them. It’s a tribute to the skill of software engineers that systems work at all. But there is another way. Many industry practitioners and university researchers believe formal methods offer a practical alternative to pro- ducing software—even noncritical software—and that this may turn out to be the cheapest way to do it as well. Given the right computer-based tools, the use of formal methods could become widespread and transform software engineering. The computer science community recently commit- ted itself to making verified software a reality within the next 15 to 20 years when representatives met in Zurich in 2005 to discuss an international grand challenge on verification (vstte.ethz. ch/report.html). WHY NOW? Software has been the subject of academic research for 70 years now. Fundamental results have been stud- ied in theoretical computer science and have been exploited in software development theories studied as for- mal methods of software engineering. A scientific theory has two pur- poses—to explain and predict. Formal methods are intended to explain soft- ware, both to the user and the devel- oper. They produce precise documen- tation, structured and presented at an appropriate level of abstraction. By being amenable to mathematical analysis, formal methods are also intended to predict software behavior. Today, universities around the world routinely teach formal meth- ods. Googling “formal methods edu- cation” returns links to repositories, a virtual library, and surveys of hun- dreds of different courses with online resources. Many key texts can be freely downloaded. Software developers have success- fully used formal methods in avionics and other safety-critical computing domains. But, you might ask, what can formal methods do for the aver- age user? The truth be told, even mainstream commercial software developers are beginning to use such formal logic behind the scenes in the form of program analysis and model- checking tools. Microsoft, the world’s biggest soft- ware developer, provides a good example. Most people use the Win- dows operating system despite its erst- while reputation for frequent crashes. However, a closer examination reveals that faulty device drivers were usually responsible for the crashes, not the OS itself. As a result, Microsoft re- sponded by developing its own model checker—the static driver verifier—to check drivers for conformance against a mathematical specification. If a dri- ver fails the SDV test, it might have a bug. SDV illustrates Kant’s dictum that “there’s nothing so practical as a good theory.” SDV exploits sophisticated theory hidden from the user. This encapsulation is so complete that commercial software developers now use SDV outside Microsoft. SDV’s success relies on a device dri- ver’s conceptual simplicity: Although a driver might appear as complicated code, there is a simple overall struc- ture that can be abstracted. In par- Verified Software: A Grand Challenge Cliff Jones, University of Newcastle Peter O’Hearn, University of London Jim Woodcock, University of York