Review By: Cathy Bell
05/11/2004

From the back cover of the book: “This is the first systematic guide to defect identification, correction, and prevention in object-oriented software development projects.” This book goes far beyond the scope this sentence implies and explains concepts that are the very core of the object-oriented process, from planning through delivery of the final software product.

Chapter 1 focuses on the basic processes of software engineering and the various ways these processes fit together to produce a quality software product. How do we define quality? How do we go about deciding what steps we need to accomplish our task? The process of constructing quality software using the object-oriented paradigm is the focus of this book. The various object-oriented models are explained, including the limitation of these models. Opening the discussion about views of quality, the author points out that there are many solutions to a problem that seem to work, but the quality of the solution can vary in structure and form. This leads to the discussion of quality and the quality attributes including the many “ilities” of quality: functionality, reliability, maintainability, etc.
If you are not familiar with object-orientated software design, both chapters 1 and 2 explain the many facets. These explanations should make this book your teacher, tutor, and reference guide to object-oriented (OO) terms and methods.

Chapter 2 builds on the OO terminology we learned in chapter 1 and explains how these features impact defect management. This chapter contains many coding examples and diagrams that help explain the ideas being presented. As each OO feature is explained, we are shown its impact on defect management and testing. The testers’ war cry is sounded: If it is possible to introduce bugs at every level of the software process, then defect management can be performed at every level of the software process to detect and prevent these bugs. Defect management techniques in this book are not categorized as preventive or corrective, because depending on where they are introduced they could be either. Many examples are given to support this idea.

Chapter 3 walks through the techniques that contribute to production of high-quality requirements. The RUP workflow diagram and OPEN framework diagrams are presented.

No two people ever see things the same way, so it is very important that the entire process is documented and requirements are available for all involved parties to refer to whenever necessary. This chapter details what should be in those requirements documents, how they should be laid out, and the expected results. The conclusion tells us “Prevention is better than cure. The majority of system defects stem from the requirements stage.” Getting them right gets your project underway with the best chance of success.

But, are we sure those requirements are up to par? Chapter 4 presents the corrective techniques that attempt to identify and remove defects already in our requirements documents.

Chapter 5 discusses preventive approaches to object-oriented design as well as basic elements of good design. There is a table that compares the various architectural styles and lists their unique advantages and disadvantages.
Try as we might, we will not prevent all defects from being introduced into our software. Chapter 6 helps us identify the defects in the design or even in the documentation of the design that would allow defects to appear. Using this approach we construct a list of lessons learned: what caused us to miss these defects in design, and how can we prevent them in future projects?

Chapters 7 and 8 cover the testing of classes through presenting corrective techniques such as code inspection and unit testing.

Chapter 9 covers integration, integration testing, and system testing. Both integration and system techniques are covered with examples that help make sense of all the various types of testing covered.
In the conclusion to chapter 3, the book is summarized in this sentence: “Prevention is better than cure.” This book emphasizes over and over that doing things right the first time is how to ensure quality.

Whenever the book delves into testing, the techniques pertain to OO testing. This is not how to test your OO project using your current test techniques. If your project is object oriented, so should your requirements gathering and testing methods. They are clearly defined in this book. There is a wealth of extremely useful charts, diagrams, tables, and scripts.