Vous voulez voir cette page en français ? Cliquez ici.

Have one to sell? Sell yours here
Tell the Publisher!
I'd like to read this book on Kindle

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Toward Zero Defect Programming [Paperback]

Allan M. Stavely
4.0 out of 5 stars  See all reviews (3 customer reviews)

Available from these sellers.



Book Description

Sept. 14 1998 0201385953 978-0201385953 1
Toward Zero-Defect Programming describes current methods for writing (nearly) bug-free programs. These methods are based on practices developed at IBM and elsewhere under the name Cleanroom Software Engineering. The successful application of these methods in commercial projects over the past fifteen years has produced defect rates that are, at least, an order of magnitude lower than industry averages. Remarkably, this reduction in defects comes at no net cost; on the contrary, it is often accompanied by increased productivity and shorter overall development time!
In a concise and well-illustrated presentation, Stavely shows how these methods can be applied in three key areas of software development:

specification
verification
testing.
Requiring formal specifications, and requiring that the code be proved mathematically to agree with the specifications, forces software engineers to program more simply and more clearly, eliminating many defects as a consequence. Performing verification as part of a team process uncovers additional defects and encourages careful examination of the program for efficiency and other quality aspects. Testing the program, to compensate for human fallibility in the preceding steps, catches (nearly) all remaining bugs.

Highlights
Explains Cleanroom methods for developing high-quality software.
Encourages a team process for program verification.
Illustrates the importance of incremental development.
The author departs somewhat from IBM Cleanroom methods in simplifying the procedures that readers must learn. His aim is to make specification and verification readily accessible to any student or practitioner who can write well-structured programs. No great mathematical sophistication is assumed. Although the books examples are written in a number of programming languages to explain different points, the largest number are in C; therefore, a prior knowledge of C is useful.


Product Details


Product Description

From the Inside Flap

This is a book for programmers who want to write programs with no bugs, or at least with as few bugs as is humanly possible with current technology.

Programmers can do this by using a particular kind of specification and verification, which I will present in the book. By verification, I mean proving, mathematically, that a program agrees with its specification.

Don't panic. You will see that this does not require great mathematical sophistication, only knowledge of a few particular techniques and ways of doing things (and then, of course, practice). There is no rigorous mathematical formalism in this book. In fact, the specifications and proofs are usually only semiformal and are sometimes quite informal indeed.

Why verify programs? Because it is a very effective way of detecting bugs. We often find that, as we attempt to verify a program, that our efforts fail because the program is not, in fact, correct. When this happens, we have found a defect. Then, of course, we fix it.

This will be our fundamental assumption: The purpose of verification is to eliminate defects.

This is a very pragmatic view. Others may take the 'all-or-nothing' position that verification is a mathematical exercise that produces mathematically perfect objects and is worthless if it can't do that, but we won't say any such thing here. You won't see any claims in this book that verified programs cannot possibly contain any defects, do not need to be tested, and can be trusted unconditionally. On the contrary, we cannot always detect all defects in a program using verification: we are human, and we make mistakes. Thus, verified programs still need to be tested carefully, and I will present methods for doing this as well.

The methods presented in this book are based on a set of interrelated techniques developed at IBM in the late 1970s and early 1980s, under the name Cleanroom Software Engineering. IBM has used them on a number of substantial projects since then, with impressive success, and since the late 1980s their use has been spreading to other companies and organizations.

These methods work. Cleanroom methods can reduce the number of defects in software by an order of magnitude or more. The extra time spent in specifying and verifying is more than made up in reduced debugging and reworking time, so using these methods costs nothing extra in terms of effort or schedule time. And the methods scale up well to large systems. You don't need to take my word for it: the results have been reported in the open literature. You will see some of the data, with literature citations, in Chapter 1. And I, along with my colleagues and students, get similar results.

There is no magic here. Our methods require programmers to work carefully and systematically, to check their work, and above all to understand their programs very thoroughly. But these are things that they should be doing anyway, even if many donit. You can think of methods as merely tools that help programmers to do these things.

This book presents my adaptation of Cleanroom methods and should not be taken as an official statement of what Cleanroom Software Engineering is. I do not speak for the Cleanroom community, which in any case has dispersed and expanded far beyond the original group at IBM. In my presentation, I have chosen to emphasize the parts of the Cleanroom process that seem to me to be the most valuable (other Cleanroom practitioners may well disagree), and to deemphasize or omit others. I have also introduced a few new ideas of my own.

The book was written with classroom use in mind and is based on a course that I have been teaching since 1993. Besides presenting the fundamentals of specification, programming, verification, and testing in the Cleanroom style, I have included extra explanations, hints, and examples covering parts of the process that students seem to find difficult at first. Mine is a one-semester undergraduate course for computer science students, but a similar course could be taught at the graduate level. The book is also suitable for an intensive short course in an industrial or continuing-education setting.

Programming professionals will also find this book useful for self-study. You will see in Chapter 6, however, that the recommended way to do the verification is in small groups, in review meetings, rather than on your own. Thus, if you intend to study this book outside a course, you will get the best results if you can work with at least two or three other people who already know these methods or who would like to study them with you.

As a minimum, the reader should be familiar with the basics of algorithms and data structures, as taught in the usual first course in the subject, and with the rudiments of discrete mathematics (sets, relations, functions, and so on). The reader should also, of course, have enough experience in programming and debugging to appreciate how valuable zero-defect programming would be if we could do it!

I also assume the ability to read and understand the structure, at least in general terms, of programs written in languages in the Algol family (including Pascal, C, Modula, Icon, and so on). In Section 9.4 I also use the functional languages Scheme and ML, but that section can be omitted by readers who have no familiarity at all with functional languages. Similarly, in Section 8.4 I use the object-oriented features of C++ and Python languages in my examples, but that section can be skipped by readers who have no familiarity at all with object-oriented programming or languages.

The methods of this book can be applied to programs in a wide variety of languages. To demonstrate this, extended examples of programs, parts of programs, and program development will be presented using the following languages: C, C++, Icon, ML, Pascal, Python, and Scheme. Particular features of these languages are explained where they are used, so a detailed knowledge of all these languages is not required. However, more of the examples are written in C than in the other languages, so familiarity with C would be helpful.

In many places in the text, short fragments of programming-language code are used to illustrate the ideas being presented. Most of these fragments are written in a generic, 'ordinary' procedural programming language: except for trivial details such as where the semicolons are, the language of each fragment might be Pascal, or Modula, or Turning, or Icon, or Ada, or any of a dozen others. The syntax may vary, but the meaning should always be apparent. When an example is meant to be in a particular programming language, I will say so.

Literature citations and comments on related work appear in the Notes sections at the end of each chapter.

My most important source does not appear in those citations. I received my first training in Cleanroom methods at a one-week intensive workshop at the Rochester (New York) Institute of Technology in the summer of 1992. The workshop was sponsored by the (U.S.) National Science Foundation. It was a condensed version of IBM's in-house training course and was conducted by Philip Hausler, Mark Pleszkoch, and Steve Rosen, of the IBM Cleanroom Software Technology Center. I am most grateful to them and to IBM, NSF, and RIT for making the workshop possible. Although I do not cite this workshop in the Notes in specific chapters of the book, the workshop was a primary source for much of the material, particularly the material of Chapters 2 through 6 and Chapters 10 and 11.

I am also most grateful to friends and colleagues who have made valuable contributions to this book through consultation, suggestions, and corrections: Michael Deck, John Duncan, Doug Dunston, Suzanne Flandreau, Alex Kent, Ray Piworunas, Steve Powell, John Shipman (for help on more occasions than I can count), and Laurie Williams; also to Peter Gordon at Addison Wesley Longman, for support and suggestions; and to all of the students in my classes over the past five years, for helping me to debug my presentation of this material. Many thanks to all of you.

Cleanroom methods are the best that I have found for producing high-quality software, and experience has shown that they can take us a long way toward the goal of zero defects. I am confident that they will continue to be developed and refined and reasonably sure that different but even better methods will eventually be developed. Meanwhile, Cleanroom methods have proven their worth and are ready for practical use today, and I hope that the presentation in this book of my version of them will help to promote their use.

In any case, we can begin by changing our attitude toward bugs: they are not inevitable, and they are not acceptable. Zero defects is the goal that we should strive for. We will not always be able to achieve it, but we should try.

A. M. S.
Socorro, New Mexico



0201385953P05082001

From the Back Cover

Read a paper by the author describing a course taught using this book.

Toward Zero-Defect Programming describes current methods for writing (nearly) bug-free programs. These methods are based on practices developed at IBM and elsewhere under the name Cleanroom Software Engineering. The successful application of these methods in commercial projects over the past fifteen years has produced defect rates that are, at least, an order of magnitude lower than industry averages. Remarkably, this reduction in defects comes at no net cost; on the contrary, it is often accompanied by increased productivity and shorter overall development time!

In a concise and well-illustrated presentation, Stavely shows how these methods can be applied in three key areas of software development:

  1. specification
  2. verification
  3. testing.

Requiring formal specifications, and requiring that the code be proved mathematically to agree with the specifications, forces software engineers to program more simply and more clearly, eliminating many defects as a consequence. Performing verification as part of a team process uncovers additional defects and encourages careful examination of the program for efficiency and other quality aspects. Testing the program, to compensate for human fallibility in the preceding steps, catches (nearly) all remaining bugs.

Highlights
  • Explains Cleanroom methods for developing high-quality software.
  • Encourages a team process for program verification.
  • Illustrates the importance of incremental development.

The author departs somewhat from IBM Cleanroom methods in simplifying the procedures that readers must learn. His aim is to make specification and verification readily accessible to any student or practitioner who can write well-structured programs. No great mathematical sophistication is assumed. Although the book’s examples are written in a number of programming languages to explain different points, the largest number are in C; therefore, a prior knowledge of C is useful.


Sell a Digital Version of This Book in the Kindle Store

If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store. Learn more

Customer Reviews

4 star
0
3 star
0
1 star
0
4.0 out of 5 stars
4.0 out of 5 stars
Most helpful customer reviews
Format:Paperback
As in the title, this book is for programmers that start programming without thinking first. Although, if you are this kind of programmer, there are better books out there than this one.
In half of the book, Allan M. Stavely explains how to create unreadable comments that specify the intended function of your code. These comments are most of the time copy of the code that they are supposed to explain, making them worthless. All these book chapters prose are wordy and tedious. If you want to write comments that explain the intended function, use plain English, or follow minimum standards as specified in Code Complete by Steve McConnell.
Also, Stavely attempts to take us in a brief and monotonous introduction to code inspections, but he names them verifications. Additionally, he gives an introduction to incremental programming, without providing us with any fresh idea.
These book ideas apply mostly to procedural top-down design programs. It dismisses must of the modern languages structures (exceptions, templates, etc.), and it gives a really low-level introduction on how to apply this to object oriented programming.
Chapter 10 has good ideas about how to implement testing using context-free grammars and percentages.
Implementing this book in an organization is hard and it needs support from management. If you are a single developer or tester, don't even bother reading this book.
Was this review helpful to you?
5.0 out of 5 stars Cleanroom method---distilled! Jan. 19 2000
Format:Paperback
Dr. Allan Stavely has done for the Cleanroom Software Engineering method what Martin Fowler did for the Unified Modeling Language in his book "UML Distilled." He's analyzed the best and most useful parts of the Cleanroom method and found a great way to present them. After reading this book, you'll be controlling defect rates and shortening development times on your own software projects.
For those not in the know, the Cleanroom method is a set of practices pioneered by the late Harlan Mills. The idea is to use some simplified mathematical formalism along with group verifications. The result? You shift time away from hack-and-slash debugging towards review. Often, the entire start-to-finish development time is shortened.
With object-oriented languages and template instantiation times, this is a really good thing: the compile-debug-test cycle is far too painful and too slow to support today's shortened deadlines.
The key to Cleanroom is that the mathematical formalism is simplified and "just enough." Stavely demonstrates the typical structures found in programs and shows how intended function statements (the math part) are used in the group review (the verification part) to discover defects in the code. Later, a testing group exercises the paths through the code that users are most likely to take, giving statistical metrics on mean-time to failure and feedback into the quality of the method's practice.
Stavely's conversational writing style makes grasping the material efficient. Each chapter focus on just one aspect of the method, and exercises at the end test how well you grasped the material. Although Stavely includes hints to the answers for selected questions, I would've preferred complete answers to all the questions.
Read more ›
Was this review helpful to you?
5.0 out of 5 stars Excellent Feb. 9 1999
By A Customer
Format:Paperback
This book is a clear, practical introduction to the Cleanroom method. Though designed as a textbook, it is also suitable for professionals.
It includes a useful bibliography, with suggestions at the end of the chapters for further reading. The final chapter sketches some areas not covered, giving references.
There are some areas intentionally omitted or only sketched, though references are provided. These include: (1) using "black boxes, state boxes, and clear boxes" for top-down development. (2) introducing Cleanroom methods in an organization (3) organizing a Cleanroom team.
Mathematically, the book is very easy going. For example, some methods which, technically, would require proof are not proved. Those of us who easily digest such details can readily fill in gaps, while others are probably happy to be spared.
The book provided an unusually high return of useful content per unit time invested in reading it, and as such I recommend it highly.
Was this review helpful to you?
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com: 4.7 out of 5 stars  3 reviews
9 of 10 people found the following review helpful
5.0 out of 5 stars Cleanroom method---distilled! Jan. 19 2000
By Sean Kelly - Published on Amazon.com
Format:Paperback|Verified Purchase
Dr. Allan Stavely has done for the Cleanroom Software Engineering method what Martin Fowler did for the Unified Modeling Language in his book "UML Distilled." He's analyzed the best and most useful parts of the Cleanroom method and found a great way to present them. After reading this book, you'll be controlling defect rates and shortening development times on your own software projects.
For those not in the know, the Cleanroom method is a set of practices pioneered by the late Harlan Mills. The idea is to use some simplified mathematical formalism along with group verifications. The result? You shift time away from hack-and-slash debugging towards review. Often, the entire start-to-finish development time is shortened.
With object-oriented languages and template instantiation times, this is a really good thing: the compile-debug-test cycle is far too painful and too slow to support today's shortened deadlines.
The key to Cleanroom is that the mathematical formalism is simplified and "just enough." Stavely demonstrates the typical structures found in programs and shows how intended function statements (the math part) are used in the group review (the verification part) to discover defects in the code. Later, a testing group exercises the paths through the code that users are most likely to take, giving statistical metrics on mean-time to failure and feedback into the quality of the method's practice.
Stavely's conversational writing style makes grasping the material efficient. Each chapter focus on just one aspect of the method, and exercises at the end test how well you grasped the material. Although Stavely includes hints to the answers for selected questions, I would've preferred complete answers to all the questions. That'd make the book more useful outside of a classroom setting.
Transcripts of review sessions show how the method succeeds in the group review. Although hypothetical, Stavely based them on actual review sessions taken by his coworkers and students over the years. They help guide newcomers to the method on how to conduct the verification step.
Overall, this is a great introduction to the Cleanroom method and after finishing the book you'll be able to introduce it to your own group in no time. Buy a copy for everyone on your team!
7 of 9 people found the following review helpful
5.0 out of 5 stars Excellent Feb. 9 1999
By A Customer - Published on Amazon.com
Format:Paperback
This book is a clear, practical introduction to the Cleanroom method. Though designed as a textbook, it is also suitable for professionals.
It includes a useful bibliography, with suggestions at the end of the chapters for further reading. The final chapter sketches some areas not covered, giving references.
There are some areas intentionally omitted or only sketched, though references are provided. These include: (1) using "black boxes, state boxes, and clear boxes" for top-down development. (2) introducing Cleanroom methods in an organization (3) organizing a Cleanroom team.
Mathematically, the book is very easy going. For example, some methods which, technically, would require proof are not proved. Those of us who easily digest such details can readily fill in gaps, while others are probably happy to be spared.
The book provided an unusually high return of useful content per unit time invested in reading it, and as such I recommend it highly.
2 of 3 people found the following review helpful
4.0 out of 5 stars Laudable goal, useful thoughts Nov. 20 2009
By Jay P. Vansanten - Published on Amazon.com
Format:Paperback|Verified Purchase
Minimizing defects when writing software is a goal that all programmers seek. Typically, a programmer will reflect and develop strategies after the "heat of the battle." Books that provide a systematic approach to a particular aspect -- that of logical correctness -- are not that common -- particularly those directed towards programmers rather than academicians -- so any addition to the literature is welcomed.

Before reading this book, I was unfamiliar with either Cleanroom Software Engineering or Harlan Mills, who is credited with conceiving the method. It was developed by IBM in the 70s, and adopted more widely in the company in the 80s. Since that time, its influence has spread beyond IBM.

In my reading, the heart of the method is a logical formalism which represents the operation and flow of a program in a language-neutral fashion. This is described straightforwardly in the text, and other aspects of the software development process are described from the CSE point of view.

For the programmer, this approach most basically moves the focus from "what am I doing" to "how am I doing it." Considerations of logical branching and set completeness of operations come to the fore through this analysis. This is an essential step in moving from a coder to a programmer. In a team setting, this provides a "style neutral" approach to identifying the logical structure of each member's program contribution.

I feel somewhat about this formalism they way I felt about flow charts in college. The concept is good. The visual provided by flow charts is helpful as a training approach. But, the formalism simply replicates the logic of the application.

At the same time, well-constructed code with well-chosen function and variable names can pretty much emulate the symbolic representation of CSE. So, I'd go a step further and suggest that one simply model one's coding style on the formalism. That avoids the double work and duplication of the program logic.
Search Customer Reviews
Only search this product's reviews
ARRAY(0xb31d419c)

Look for similar items by category


Feedback