Nothing Special   »   [go: up one dir, main page]

skip to main content
research-article

Investigating the Influence of Formal Methods

Published: 01 February 1997 Publication History

Abstract

Formal methods promise much, but can they deliver? In this project, results are inconclusive, but careful data gathering and analysis helped establish influences on product quality. Practitioners and researchers continue to seek methods and tools for improving software development processes and products. Candidate technologies promise increased productivity, better quality, lower cost, or enhanced customer satisfaction. But we must test these methods and tools empirically and rigorously to determine any significant, quantifiable improvement. We tend to consider evaluation only after using the technology, which makes careful, quantitative analysis difficult if not impossible. However, when an evaluation is designed as part of overall project planning, and then carried out as software development progresses, the result can be a rich record of a tool's or technique's effectiveness. In this study, we investigated the effects of using formal methods to develop an air-traffic-control information system. Because we are studying one project in isolation, we cannot draw conclusions about the suitability of formal methods for all projects. As we describe in the sidebar "Can Formal Methods Always Deliver?" the jury is still out on when and whether formal methods improve products. Nevertheless, the lessons we learned are instructive, not only in showing how formal methods influenced code quality on this project, but also in highlighting the limitations of retrospective studies and their use in planning follow-up investigations. We describe what we did, as well as what we could have done had the study been carried out as the software system was being developed and tested. We also show how this preliminary investigation helps to suggest hypotheses for further studies. Thus, the lessons we learned can be applied not only to gauge the effects of formal methods but also in planning similar studies of other techniques and tools. The procedure we used was not predetermined; the results of one analysis step largely determined where we went next. Indeed, research often involves following one trail and then another, uncovering relationships and unearthing facts, until the picture begins to make sense. However, we did learn many specific lessons, which we hope will enrich future investigations.

References

[1]
J. Anthony Hall, "Using Formal Methods to Develop an ATC Information System," IEEE Software, Mar. 1996, pp. 66-76.
[2]
Les Hatton, Safer C: Developing Software for High-Integrity and Safety-Critical Systems, McGraw-Hill, New York, Dec. 1994.
[3]
B. Nejmeh, "NPATH: A Measure of Execution Path Complexity and Its Applications," Comm. ACM, Feb. 1988, pp. 188-200.
[4]
W. Humphrey, Managing the Software Process, Addison-Wesley, Reading, Mass., 1989.
[5]
L. Hatton, "Programming Languages and Safety-Related Systems," Proc. Safety-Critical Systems Symp., Springer-Verlag, New York, 1995, pp. 48-64.
[6]
E. Adams, "Optimizing Preventive Service of Software Products," IBM J. Research and Development, No. 1, 1984, pp. 2-14.
[7]
S. Gerhart D. Craigen and T. Ralston, "Observation on Industrial Practice Using Formal Methods," Proc. 15th Int'l Conf. Software Eng., IEEE CS Press, Los Alamitos, Calif., 1993, pp. 24-33.
[8]
P. Naur, "Understanding Turing's Universal Machine—Personal Style in Program Description," Computer J., No. 4, 1993, pp. 351-371.
[9]
S. Gerhart D. Craigen and T. Ralston, "Experience with Formal Methods in Critical Systems," IEEE Software, Jan. 1994, pp. 21-28.
[10]
I. Houston and S. King, "CICS Project Report: Experiences and Results from the Use of Z," Proc. VDM '91: Formal Development Methods, Springer-Verlag, New York, 1991.
[11]
J. McDermid, "Safety-Critical Software: A Vignette," IEE Software Eng. J., No. 1, 1993, pp. 2-3.
[12]
J. Bowen and M. Hinchey, "Formal Methods and Safety-Critical Standards," Computer, Aug. 1994, pp. 68-71.
[13]
N. Fenton S. Pfleeger and R. Glass, "Science and Substance: A Challenge to Software Engineers," IEEE Software, July 1994, pp. 86-95.

Cited By

View all

Recommendations

Comments

Please enable JavaScript to view thecomments powered by Disqus.

Information & Contributors

Information

Published In

cover image Computer
Computer  Volume 30, Issue 2
February 1997
100 pages

Publisher

IEEE Computer Society Press

Washington, DC, United States

Publication History

Published: 01 February 1997

Qualifiers

  • Research-article

Contributors

Other Metrics

Bibliometrics & Citations

Bibliometrics

Article Metrics

  • Downloads (Last 12 months)0
  • Downloads (Last 6 weeks)0
Reflects downloads up to 29 Nov 2024

Other Metrics

Citations

Cited By

View all

View Options

View options

Media

Figures

Other

Tables

Share

Share

Share this Publication link

Share on social media