BN.com Gift Guide

Peer Reviews in Software: A Practical Guide / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $9.01
Usually ships in 1-2 business days
(Save 87%)
Other sellers (Paperback)
  • All (13) from $9.01   
  • New (8) from $51.08   
  • Used (5) from $9.01   

Overview

"I will tell my friends and other folks in quality assurance and process management roles to RUN (don't walk) and buy Peer Reviews in Software. In fact, my organization could use this book RIGHT NOW." —Brad Appleton

Karl's writing is nicely motivational, reasonably detailed, and covers the range of issues that are important." —Mark Paulk

There is nothing wrong with making mistakes; it is part of what makes us human. Catching the errors early, however, before they become difficult to find and expensive to correct, is very important. A peer review program is a vital component of any quality software development effort, yet too few software professionals have had the experience or training necessary to implement peer reviews successfully.

Concise, readable, and pragmatic, Peer Reviews in Software walks you through the peer review process and gives you the specific methods and techniques you need to help ensure a quality software release. Comprehensively covering both formal and informal processes, the book describes various peer review methods and offers advice on their appropriate use under a variety of circumstances.

This book focuses on—but is not limited to—the technique of inspection. This is the most formal, rigorous, and effective type of peer review. The various stages of inspection—including planning, individual preparation, conducting inspection meetings, and follow-up—are discussed in detail. In addition, Peer Reviews in Software explores the cultural and social nuances involved in critiquing the work of others, and reveals

Specific topics include:

  • Overcoming resistance to reviews
  • Inspection teams and roles
  • Inspection process stages
  • Scheduling inspection events
  • Analyzing inspection data
  • Peer review training
  • Critical success factors and pitfalls
  • Relating peer reviews to process improvement models

Karl Wiegers closes with a look at special review challenges, including peer review of large work products and geographically dispersed development teams. He provides many practical resources to help you jump-start your review program, enhance communications on your projects, and ultimately ship high-quality software on schedule.

0201734850B10052001

Read More Show Less

Product Details

  • ISBN-13: 9780201734850
  • Publisher: Addison-Wesley
  • Publication date: 10/28/2001
  • Series: Addison-Wesley Information Technology Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 256
  • Product dimensions: 7.20 (w) x 9.00 (h) x 0.70 (d)

Meet the Author

Karl E. Wiegers, Ph.D., is Principal Consultant with Process Impact, a software process consulting and education company. He previously spent eighteen years at Eastman Kodak Company, where he held positions as a software applications developer, software manager, and software process and quality improvement leader. Karl has been participating in and leading software peer reviews throughout his extensive career.

0201734850AB11162001

Read More Show Less

Read an Excerpt

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 aneffective 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 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.

Read More Show Less

Table of Contents

Preface.

My Objectives.

Intended Audience.

Reading Suggestions.

Acknowledgments.

1. The Quality Challenge.

Looking Over the Shoulder.

Quality Isn't Quite Free.

Justifying Peer Reviews.

Peer Reviews, Testing, and Quality Tools.

What Can Be Reviewed.

A Personal Commitment to Quality.

2. A Little Help from Your Friends.

Scratch Each Other's Back.

Reviews and Team Culture.

The Influence of Culture.

Reviews and Managers.

Why People Don't Do Reviews.

Overcoming Resistance to Reviews.

Peer Review Sophistication Scale.

Planning for Reviews.

Guiding Principles for Reviews.

3. Peer Review Formality Spectrum.

The Formality Spectrum.

Inspection.

Team Review.

Walkthrough.

Pair Programming.

Peer Deskcheck.

Passaround.

Ad Hoc Review.

Choosing a Review Approach.

4. The Inspection Process.

Inspector Roles.

The Author's Role.

To Read or Not To Read.

Inspection Team Size.

Inspection Process Stages.

Planning.

Overview.

Preparation.

Meeting.

Rework.

Follow-up.

Causal Analysis.

Variations on the Inspection Theme.

Gilb/Graham Method.

High-Impact Inspection.

Phased Inspections.

5. Planning the Inspection.

When to Hold Inspections.

The Inspection Moderator.

Selecting the Material.

Inspection Entry Criteria.

Assembling the Cast.

Inspector Perspectives.

Managers and Observers.

The Inspection Package.

Inspection Rates.

Scheduling Inspection Events.

6. Examining the Work Product.

The Overview Stage.

The Preparation Stage.

Preparation Approaches.

Defect Checklists.

Other Analysis Techniques.

7. Putting Your Heads Together.

The Moderator's Role.

Launching the Meeting.

Conducting the Meeting.

Reading the Work Product.

Raising Defects and Issues.

Recording Defects and Issues.

Watching for Problems.

Product Appraisal.

Closing the Meeting.

Improving the Inspection Process.

8. Bringing Closure.

The Rework Stage.

The Follow-Up Stage.

The Causal Analysis Stage.

Inspection Exit Criteria.

9. Analyzing Inspection Data.

Why Collect Data?

Some Measurement Caveats.

Basic Data Items and Metrics.

The Inspection Database.

Data Analysis.

Measuring the Impact of Inspections.

Effectiveness.

Efficiency.

Return on Investment.

10. Installing a Peer Review Program.

The Peer Review Process Owner.

Preparing the Organization.

Process Assets.

The Peer Review Coordinator.

Peer Review Training.

Piloting the Review Process.

11. Making Peer Reviews Work for You.

Critical Success Factors.

Review Traps to Avoid.

Troubleshooting Review Problems.

12. Special Review Challenges.

Large Work Products.

Geographical or Time Separation.

Distributed Review Meeting.

Asynchronous Review.

Generated and Nonprocedural Code.

Too Many Participants.

No Qualified Reviewers Available.

Epilogue.

Appendix A: Peer Reviews and Process Improvement Models.

Capability Maturity Model for Software.

Goals of the Peer Reviews Key Process Area.

Activities Performed.

Commitment to Perform.

Ability to Perform.

Measurement and Analysis.

Verifying Implementation.

Systems Engineering Capability Maturity Model.

CMMI-SE/SW.

Prepare for Peer Reviews.

Conduct Peer Reviews.

Analyze Peer Review Data.

ISO 9000-3.

Appendix B: Supplemental Materials.

Work Aids.

Other Peer Review Resources.

Glossary.

Index.

Read More Show Less

Preface

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.

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 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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)