No matter how skilled or experienced I am as a software developer, requirements writer, project planner, tester, or book author, I'm going to make mistakes. There's nothing wrong with making mistakes; it is part of what makes me human. Because I err, it makes sense to catch the errors early, before they become difficult to find and expensive to correct.

It's often hard for me to find my own errors because I am too close to the work. Many years ago I learned the value of having some colleagues look over my work and point out my mistakes. I always feel a bit sheepish when they do, but I prefer to have them find the mistakes now than to have customers find them much later. Such examinations are called peer reviews. There are several different types of peer reviews, including inspections, walkthroughs, and others. However, most of the points I make in this book apply to any activity in which someone other than the creator of a work product examines it in order to improve its quality.

I began performing software peer reviews in 1987; today I would never consider a work product complete unless someone else has carefully examined it. You might never find all of the errors, but you will find many more with help from other people than you possibly can on your own. The manuscript for this book and my previous books all underwent extensive peer review, which contributed immeasurably to their quality.My Objectives

There is no "one true way" to conduct a peer review, so the principal goal of this book is to help you effectively perform appropriate reviews of deliverables that people in your organization create. I also address the cultural and practical aspects of implementing an effective peer review program in a software organization. Inspection is emphasized as the most formal and effective type of peer review, but I also describe several other methods that span a spectrum of formality and rigor. Many references point you to the extensive literature on software reviews and inspections.

Inspection is both one of the great success stories of software development and something of a failure. It's a grand success because it works! Since it was developed by Michael Fagan at IBM in the 1970s, inspection has become one of the most powerful methods available for finding software errors Fagan, 1976. You don't have to just take my word for it, either. Experiences cited from the software literature describe how inspections have improved the quality and productivity of many software organizations. However, only a fraction of the software development community understands the inspection process and even fewer people practice inspections properly and effectively. To help you implement inspections and other peer reviews in your team, the book emphasizes pragmatic approaches that any organization can apply.These resources include review forms, defect checklists, a sample peer review process description, spreadsheets for collecting inspection data, sources of training on inspections, and more, as described in Appendix B. You are welcome to download these documents and adapt them to meet your own needs. Please send your comments and suggestions to me at kwiegers@acm.org. Feedback on how well you were able to make peer reviews work in your team is also welcome.Intended Audience

The material presented here will be useful to people performing many project functions, including: work product authors, including analysts, designers, programmers, maintainers, test engineers, project managers, marketing staff, product managers, technical writers, and process developers work product evaluators, including quality engineers, customer representatives, customer service staff, and all those listed above as authors process improvement leaders managers of any of these individuals, who need to know how to instill peer reviews into their cultures and also should have some of their own deliverables reviewed

This book will help people who realize that their software product's quality falls short of their goals and those who want to tune up their current review practices, establish and maintain good communications on their projects, or ship high-quality software on schedule. Organizations that are using the Capability Maturity Model for Software" or the CMMI for Systems Engineering/Software Engineering will find the book valuable, as peer reviews are components of those process improvement frameworks (see Appendix A).

The techniques described here are not limited to the deliverables and documents created on software projects. Indeed, you can apply them to technical work products from any engineering project, including design specifications, schematics, assembly instructions, and user manuals. In addition to technical domains, any business that has documented task procedures or quality control processes will find that careful peer review will discover errors that the author simply cannot find on his own.Reading Suggestions

To gain a detailed understanding of peer reviews in general and inspections in particular, you can simply read the book from front to back. The cultural and social aspects of peer reviews are discussed in Chapters 1 and 2. Chapter 3 provides an overview of several different types of reviews and suggests when each is appropriate. Chapters 4 through 8 address the nuts and bolts of inspection, while Chapter 9 describes important inspection data items and metrics. If you're attempting to implement a successful review program in an organization, focus on Chapters 10 and 11. For suggestions on ways to deal with special review challenges, such as large work products or distributed development teams, see Chapter 12. Refer to the Glossary for definitions of many terms used in the book. 0201734850P07232001