Applying Formal Specification in Industry

• Authors: Peter Gorm Larsen;John Fitzgerald;Tom Brookes
• Venue: IEEE Software
• Year: 1996

Industrial software developers confront a bewildering array of software-engineering techniques, each with its own promised benefits. Companies are sometimes reluctant to be the first to enter new territory: Without a sufficiently large public body of evidence, new techniques may be considered too immature for commercial adoption. Many industrial companies have already invested a great deal of effort in their development process, which has normally undergone some form of certification to show that it conforms to acceptable standards, such as the ISO 9000 series. Introducing a new technology into that process is difficult if it requires fundamental change.More acceptable is to introduce an incremental change whose overall effects can be identified and quantified. In this article, we report on the lessons learned during a study of one such change on the software-development process at British Aerospace Systems and Equipment Ltd..At BASE, we were interested in developing a security-critical system to levels of assurance that required the use of formal specification for modeling the security policy. The study itself consisted of the parallel development by two separate engineering teams of a system component known as a trusted gateway: a small but security-critical message-handling device. One team employed what we refer to as the conventional path: The conventional BASE development methodology using structured analysis with CASE-tool support. The other team employed what we refer to as the formal path: Essentially the same design process, but supplemented with formal specification wherever they felt it appropriate.System specifications are usually presented in a mixture of natural language, graphical notations, and pseudocode. A formal specification, by contrast, uses a precisely defined mathematical language to describe the system properties. This leaves less room for ambiguity in the requirements, and also opens the way for automatic checking for errors and inconsistencies in requirements. Formal-specification languages usually provide a variety of abstract, high-level constructs that permit the description of system properties without dealing with implementation details.In addition to the two development teams, a monitoring team acted as central authority and customer, keeping records of the project's queries, problems, and progress. This team recorded observations, including metrics, at different points during the development. The BASE study set out to provide evidence on the effects of introducing formal specification in projects that could benefit from the use of a formal language, such as those that must attain high assurance levels. We now feel that we have some evidence on which to base a modification to BASE's existing development processes that will encourage analysis at early development stages:Formal specification's use in our development process did not impose a significant cost or time overhead across the entire development. Formal specifications can improve the understanding of the system being developed and can prevent errors from being propagated through the development process. Formal specification can be integrated gradually into a traditional, existing development process. Formal specification's benefits are mostly obtained in the early stages of development. Formal techniques can be used by engineers after as little as one week's training, if expert support is available when they first apply the techniques. Formal-specification notation must be supported by industrially applicable computer-based tools that provide specification interpretation, which allows test-case examination.