This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Lessons from Using Z to Specify a Software Tool
January 1998 (vol. 24 no. 1)
pp. 15-23

Abstract—The authors were recently involved in the development of a COBOL parser, specified formally in Z. The type of problem tackled was well suited to a formal language. The specification process was part of a life-cycle characterized by the front-loading of effort in the specification stage and the inclusion of a statistical testing stage. The specification was found to be error dense and difficult to comprehend. The Z was used to specify inappropriate procedural rather than declarative detail. Modularity and style problems in the Z specification made it difficult to review. In this sense, the application of formal methods was not successful. Despite these problems the estimated fault density for the product was 1.3 faults per KLOC, before delivery, which compares favorably with IBM's Cleanroom method. This was achieved, despite the low quality of the Z specification, through meticulous and effort-intensive reviews. However, because the faults were in critical locations, the reliability of the product was assessed to be unacceptably low. This demonstrates the necessity of assessing reliability as well as "correctness" during system testing. Overall, the experiences reported in this paper suggest a range of important lessons for anyone contemplating the practical application of formal methods.

[1] J.M. Spivey, The Z Notation: A Reference Manual, Prentice-Hall, Englewood Cliffs, N.J., 1992.
[2] D. Rann, J. Turner, and J. Whitworth, Z: A Beginner's Guide. Chapman and Hall, 1994.
[3] SREDM project proposal, UK DTI IED/4/1/3029, 1992.
[4] Applications of Formal Methods, M.G. Hinchey and J.P. Bowen, eds., series in computer science, Prentice Hall International, 1995.
[5] M. Dyer, The Cleanroom Approach to Quality Software Development.New York: John Wiley&Sons, 1992.
[6] E. Yourdon, Modern Structured Analysis, Prentice Hall, Englewood Cliffs, N.J., 1989.
[7] IPSYS Limited. TBK Version 2.5.2 Manual (3 volumes), 1992.
[8] G. Ostrolenk, M. Southworth, M. Tobin, and M. Neil, "Cost-Effective Evaluation of a COBOL Parser Using an Operational Profile," Software Evolution: Models and Metrics. Proc. 11th Ann. Conf. Centre for Software Reliability, 1994.
[9] D. Homan, "The Matthews Ratio and the 4% Rule," contribution to the AMI e-mail group, Jan. 1995.
[10] M. Jackson, Software Requirements and Specifications, Addison-Wesley, Reading, Mass., 1995.
[11] B. Littlewood, M. Neil, and G. Ostrolenk, "The Role of Models in Managing the Uncertainty of Software-Intensive Systems," Reliability and Engineering System Safety, vol. 50, no.1, 1995.
[12] P.A. Hausler, R.C. Linger, and C.J. Trammel, "Adopting Cleanroom Software Engineering With a Phased Approach," IBM Systems J., Vol. 33, No. 1, 1994.
[13] N. Fenton and L. Pfleeger, Software Metrics–A Rigorous and Practical Approach, second ed. Boston, PWS-Publishing, 1997.

Index Terms:
Formal methods, statistical testing, practical experience, reliability, fault density.
Citation:
Martin Neil, Gary Ostrolenk, Mary Tobin, Mark Southworth, "Lessons from Using Z to Specify a Software Tool," IEEE Transactions on Software Engineering, vol. 24, no. 1, pp. 15-23, Jan. 1998, doi:10.1109/32.663995
Usage of this product signifies your acceptance of the Terms of Use.