Peer Reviews in Software A Practical Guide

by Wiegers, Karl E.

• ISBN13: 9780201734850
• ISBN10: 0201734850
• Edition: 1st
• Format: Paperback
• Copyright: 2001-10-23
• Publisher: Addison-Wesley Professional

Summary

Peer review works: it leads to better software. But implementing peer review can be challenging -- for technical, political, social, cultural, and psychological reasons. In this book, best-selling software engineering author Karl Wiegers presents succinct, easy-to-use techniques for formal and informal software peer review, helping project managers and developers choose the right approach and implement it successfully. Wiegers begins by discussing the cultural and social aspects of peer review, and reviewing several formal and informal approaches: their implications, their challenges, and the opportunities they present for quality improvement. The heart of the book is an in-depth look at the "nuts and bolts" of inspection, including the roles of inspectors, planning, examining work products, conducting code review meetings; improving the inspection process, and achieving closure. Wiegers presents a full chapter on metrics, and then addresses the process and political challenges associated with implementing successful software review programs. The book concludes with solutions to special review challenges, including large work products and software created by distributed development teams. For all developers, project managers, business analysts, quality engineers, testers, process improvement leaders, and documentation specialists.

Author Biography

Karl E. Wiegers, Ph.D., is Principal Consultant with Process Impact

Table of Contents

Preface	xi
The Quality Challenge	1	(12)
Looking Over the Shoulder	2	(1)
Quality Isn't Quite Free	3	(3)
Justifying Peer Reviews	6	(2)
Peer Reviews, Testing, and Quality Tools	8	(3)
What Can Be Reviewed	11	(1)
A Personal Commitment to Quality	12	(1)
A Little Help From Your Friends	13	(18)
Scratch Each Other's Backs	13	(2)
Reviews and Team Culture	15	(11)
The Influence of Culture	16	(1)
Reviews and Managers	17	(3)
Why People Don't Do Reviews	20	(2)
Overcoming Resistance to Reviews	22	(4)
Peer Review Sophistication Scale	26	(1)
Planning for Reviews	27	(2)
Guiding Principles for Reviews	29	(2)
Peer Review Formality Spectrum	31	(14)
The Formality Spectrum	31	(10)
Inspection	33	(2)
Team Review	35	(1)
Walkthrough	36	(2)
Pair Programming	38	(1)
Peer Deskcheck	39	(1)
Passaround	40	(1)
Ad Hoc Review	41	(1)
Choosing a Review Approach	41	(4)
The Inspection Process	45	(16)
Inspector Roles	46	(2)
The Author's Role	46	(1)
To Read or Not to Read	47	(1)
Inspection Team Size	48	(2)
Inspection Process Stages	50	(6)
Planning	52	(1)
Overview	52	(1)
Preparation	53	(1)
Meeting	53	(2)
Rework	55	(1)
Follow-up	56	(1)
Causal Analysis	56	(1)
Variations on the Inspection Theme	56	(5)
Gilb/Graham Method	57	(1)
High-Impact Inspection	58	(1)
Phased Inspections	59	(2)
Planning the Inspection	61	(20)
When to Hold Inspections	62	(2)
The Inspection Moderator	64	(2)
Selecting the Material	66	(1)
Inspection Entry Criteria	67	(2)
Assembling the Cast	69	(5)
Inspector Perspectives	70	(3)
Managers and Observers	73	(1)
The Inspection Package	74	(2)
Inspection Rates	76	(2)
Scheduling Inspection Events	78	(3)
Examining the Work Product	81	(14)
The Overview Stage	81	(2)
The Preparation Stage	83	(3)
Preparation Approaches	86	(9)
Defect Checklists	87	(1)
Rule Sets	88	(1)
Other Analysis Techniques	88	(7)
Putting Your Heads Together	95	(22)
The Moderator's Role	95	(5)
Launching the Meeting	100	(2)
Conducting the Meeting	102	(11)
Reading the Work Product	103	(2)
Raising Defects and Issues	105	(2)
Recording Defects and Issues	107	(3)
Watching for Problems	110	(3)
Product Appraisal	113	(1)
Closing the Meeting	114	(1)
Improving the Inspection Process	115	(2)
Bringing Closure	117	(8)
The Rework Stage	117	(2)
The Follow-Up Stage	119	(2)
The Causal Analysis Stage	121	(2)
Inspection Exit Criteria	123	(2)
Analyzing Inspection Data	125	(18)
Why Collect Data?	125	(2)
Some Measurement Caveats	127	(2)
Basic Data Items and Metrics	129	(1)
The Inspection Database	129	(6)
Data Analysis	135	(3)
Measuring the Impact of Inspections	138	(5)
Effectiveness	138	(2)
Efficiency	140	(1)
Return on Investment	140	(3)
Installing a Peer Review Program	143	(16)
The Peer Review Process Owner	143	(1)
Preparing the Organization	144	(5)
Process Assets	149	(2)
The Peer Review Coordinator	151	(1)
Peer Review Training	152	(4)
Piloting the Review Process	156	(3)
Making Peer Reviews Work for You	159	(16)
Critical Success Factors	159	(3)
Review Traps to Avoid	162	(2)
Troubleshooting Review Problems	164	(11)
Special Review Challenges	175	(10)
Large Work Products	175	(2)
Geographical or Time Separation	177	(4)
Distributed Review Meeting	178	(2)
Asynchronous Review	180	(1)
Generated and Nonprocedural Code	181	(1)
Too Many Participants	182	(1)
No Qualified Reviewers Available	183	(2)
Epilogue	185	(2)
Appendix A PEER REVIEWS AND PROCESS IMPROVEMENT MODELS	187	(12)
Capability Maturity Model for Software	187	(6)
Goals of the Peer Reviews Key Process Area	189	(1)
Activities Performed	190	(1)
Commitment to Perform	191	(1)
Ability to Perform	191	(1)
Measurement and Analysis	192	(1)
Verifying Implementation	192	(1)
Systems Engineering Capability Maturity Model	193	(1)
CMMI-SE/SW	194	(3)
Prepare for Peer Reviews	196	(1)
Conduct Peer Reviews	196	(1)
Analyze Peer Review Data	197	(1)
ISO 9000-3	197	(2)
Appendix B SUPPLEMENTAL MATERIALS	199	(2)
Work Aids	199	(1)
Other Peer Review Resources	200	(1)
Glossary of Peer Review Terms	201	(6)
References	207	(10)
Index	217

Excerpts

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 ObjectivesThere 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.Several process assets that can jumpstart your peer review program are available from the website that accompanies this book, http://www.processimpact.com/pr_goodies.shtml . 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 [e-mail]. Feedback on how well you were able to make peer reviews work in your team is also welcome. Intended AudienceThe 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, includin