skip to main content
Skip header Section
Software defect removalAugust 1984
Publisher:
  • McGraw-Hill, Inc.
  • Professional Book Group 11 West 19th Street New York, NY
  • United States
ISBN:978-0-07-018313-1
Published:01 August 1984
Pages:
331
Skip Bibliometrics Section
Bibliometrics
Abstract

No abstract available.

Cited By

  1. ACM
    Clements P, Escalona M, Inverardi P, Malavolta I and Marchetti E Exploiting software architecture to support requirements satisfaction testing Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, (484-487)
  2. Lee E and Lee S Design opportunity tree for schedule management and evaluation by COQUALMO Proceedings of the 2006 international conference on Computational Science and Its Applications - Volume Part IV, (1070-1080)
  3. ACM
    Brykczynski B (2019). A survey of software inspection checklists, ACM SIGSOFT Software Engineering Notes, 24:1, (82), Online publication date: 1-Jan-1999.
  4. Ocker R, Fjermestad J, Hiltz S and Johnson K (1998). Effects of four modes of group communication on the outcomes of software requirements determination, Journal of Management Information Systems, 15:1, (99-118), Online publication date: 1-Jun-1998.
  5. Ocker R, Hiltz S, Turoff M and Fjermestad J (1995). The effects of distributed group support and process structuring on software requirements development teams, Journal of Management Information Systems, 12:3, (127-153), Online publication date: 1-Dec-1995.
  6. ACM
    Brykczynski B and Wheeler D (1993). An annotated bibliography on software inspections, ACM SIGSOFT Software Engineering Notes, 18:1, (81-88), Online publication date: 1-Jan-1993.
  7. ACM
    Olson J, Olson G, Storrøsten M and Carter M How a group-editor changes the character of a design meeting as well as its outcome Proceedings of the 1992 ACM conference on Computer-supported cooperative work, (91-98)
  8. Olson G, Olson J, Carter M and Storrøsten M (2018). Small group design meetings, Human-Computer Interaction, 7:4, (347-374), Online publication date: 1-Dec-1992.
  9. Guindon R (2018). Designing the design process, Human-Computer Interaction, 5:2, (305-344), Online publication date: 1-Jun-1990.
  10. Rosson M and Alpert S (2018). The cognitive consequences of object-oriented design, Human-Computer Interaction, 5:4, (345-379), Online publication date: 1-Dec-1990.
  11. ACM
    Litecky C (1989). An expert system for Cobol program debugging, ACM SIGMIS Database: the DATABASE for Advances in Information Systems, 20:1, (1-6), Online publication date: 1-Apr-1989.
  12. ACM
    Nejmeh B (1988). NPATH: a measure of execution path complexity and its applications, Communications of the ACM, 31:2, (188-200), Online publication date: 1-Feb-1988.
  13. ACM
    Gelperin D and Hetzel B (1988). The growth of software testing, Communications of the ACM, 31:6, (687-695), Online publication date: 1-Jun-1988.
  14. Drake D Reliability theory applied to software testing Proceedings of the 1987 Fall Joint Computer Conference on Exploring technology: today and tomorrow, (116-118)
  15. ACM
    Skibbe R (2019). A practical approach to the evaluation of microcode systems, ACM SIGMICRO Newsletter, 16:4, (47-56), Online publication date: 1-Dec-1985.
  16. ACM
    Skibbe R A practical approach to the evaluation of microcode systems Proceedings of the 18th annual workshop on Microprogramming, (47-56)
Contributors
  • Duquesne University

Recommendations

Reviews

Paul W. Abrahams

In producing a working program that meets a set of requirements, defect removal inevitably is a large part, if not the largest part, of the job. In Software defect removal, Dunn provides a comprehensive, soup-to-nuts (or requirements- to-maintenance) collection of advice on how to prevent and remove defects — that is, bugs — in software. A theme that occurs throughout the book is the importance of getting the bugs out early, since it is far less expensive to remove a bug at the requirements stage than it is to remove the same bug when the progam is under test. The book is divided into four parts: (1) Introduction, (2) Statis Methods, (3) Dynamic Methods, and (4) Operational Phase. The Introduction, in addition to giving an overview of the book describes a number of currently popular development methodologies and relates them to defect removal. The better the quality of a program, the fewer defects it is likely to have and the easier it is to remove those defects that it does have. In addition, a good methodology lens itself to systematic checking and to traceability — that is, to relating requirements to design, and design to code, in such a way that each specification level can be related systematically to its predecessor. Static methods are those that can be applied to a program without actually running it. They include reviews of requirements, design, and code, as well as static analysis tools that can be mechanically applied to programs. I found the discussion of static analysis to be particularly good. Proofs of correctness are also treated within the discussio of static methods. Dynamic methods are those that involve running the program. These include glass box testing, based on the structure of the unit under test, and black box testing, in which only the external requirements of the unit under test are considered. In this part of the book, the author also discusses useful statistics that can be collected as part of the testing process, in the hope of isolating failure-prone modules and predicting the likelihood of failures in the future. The final portio of the book, on the operational phase, is concerned with what happens when a program is finally put to use in its intended environment. Maintenance and modification has its own peculiar difficulties, intensified by the fact that maintenance programmers usually work with fewer tools and less knowledge than development programmers. During maintenance and modification, it is particularly important to keep different parts of a program, including the test cases, properly coordinated. Here lies the role of configuration control. The author of this book is Manager of Programming Quality at the ITT Advanced Technology Center, and he clearly brings a wealth of personal experience to this book. Unfortunately, he sometimes falls into the assumption that all the world is like ITT, where programs which are millions of lines long are produced by hundreds of programmers, aided and abetted by groups such as Software Test and Quality Assurance, and the customer is usually the Federal Government. Defect removal is as important in programming in the small as it is in programming in the large, and different methods of quality control are appropriate in different environments. A few aspects of this book left me feeling less than satisfied. Some of the techniques that Dunn discusses are more practical than others, but he does not sufficiently emphasize the distinction. He treats proofs of correctness as though they are as readily applicable and as much a part of industrial practice as design walkthrughs. His discussion of symbolic execution fails to indicate what sorts of programs it applied to. The discussion of developent methodologies emphasizes procedural abstraction over data abstraction, and thus does not place enough emphasis on how to develop appropriate data structures. Some of the defect removal methods discussed in the book do ot seem to apply too well to compilers, particularly the testing methods; it is difficult to test the back parts of a compiler in isolation because they can only be driven effectively by the front parts. In summary, this is a well-written, well-organized, technically sound, and interesting book that collects a lot of useful information about defect removal in a single place. It does suffer, however, from a failure to acknowledge its implicit assumptions about the kinds of programs being written and from insufficient distinction between methods currently in practice and methods that are still academic. Also, most of Dunn's ideas are conventional wisdom; I found few startling insights that would lead me to different ways of thinking about defects in software.

Access critical reviews of Computing literature here

Become a reviewer for Computing Reviews.