Formal Methods When Money is Tight

Formal methods have been shown to improve the quality of software, but they are seldom if ever used outside the safety-critical system domain. Typically, the initial cost of creating formal requirements speci cations is perceived to be prohibitively large while not necessarily guaranteeing future bene ts. In this paper we discuss ways of tailoring formal methods to suit current economic realities.

[1]  Cliff B. Jones,et al.  A Rigorous Approach to Formal Methods , 1996 .

[2]  Ben L. Di Vito,et al.  Formalizing space shuttle software requirements: four case studies , 1998, TSEM.

[3]  Andre Wong,et al.  Formalizing requirements in a commercial setting, a case study , 1999 .

[4]  Anthony Hall,et al.  Seven myths of formal methods , 1990, IEEE Software.

[5]  Ruth Davis,et al.  Practically formal methods , 1996, Proceedings 1996 International Conference Software Engineering: Education and Practice.

[6]  A. Pnueli,et al.  STATEMATE: a working environment for the development of complex reactive systems , 1988, [1988] Proceedings. The Third Israel Conference on Computer Systems and Software Engineering.

[7]  K. K. Sandhu,et al.  Specification and description language (SDL) , 1992 .

[8]  M. Buchi The B Bank: a complete case study , 1998, Proceedings Second International Conference on Formal Engineering Methods (Cat.No.98EX241).

[9]  UML Semantics version 1.0 , 1997 .

[10]  Mark T. Norris,et al.  Industrialising Formal Methods for Telecommunications , 1989, ESEC.

[11]  David R. Brownbridge Using Z to Develop a CASE Toolset , 1989, Z User Workshop.

[12]  Marsha Chechik,et al.  Formal modeling in a commercial setting: A case study , 1999, J. Syst. Softw..