Lecture 12: Chapter 15: Review Techniques

Lecture 12: Chapter 15
 Review Techniques
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student
use.
1
Reviews
... there is no particular reason

why your friend and colleague
cannot also be your sternest critic.
Jerry Weinberg
2
What Are Reviews?
 a meeting conducted by technical
people for technical people
 a technical assessment of a work
product created during the software
engineering process
 a software quality assurance
mechanism
 a training ground
3
What Reviews Are Not
 A project summary or progress

assessment
 A meeting intended solely to impart
information
 A mechanism for political or personal
reprisal!
4
What Are Reviews?
 Software reviews are a “filter” for the software process.
 reviews are applied at various points during software
engineering
 serve to uncover errors and defects that can then be
removed.
 Software reviews “purify” software engineering work
products, including requirements and design models,
code, and testing data
5
What Do We Look For?
 Errors and defects
 Error—a quality problem found before the software is released
to end users
 Defect—a quality problem found only after the software has been
released to end-users
 We make this distinction because errors and defects have very
different economic, business, psychological, and human
impact
 However, the temporal distinction made between errors and
defects in this book is not mainstream thinking
6
Cost Impact of Software Defects
 The primary objective of technical reviews is to find errors
during the process so that they do not become defects after
release of the software.
 The obvious benefit of technical reviews is the early discovery

of errors so that they do not propagate to the next step in the
software process.
7
Overall
 Effort expended with and without reviews
with reviews
8
Defect Amplification and Removal
9
Reviews – A formality spectrum
 The formality of a review increases when

(1) distinct roles are explicitly defined for the reviewers,
(2) there is a sufficient amount of planning and preparation for the
review,
(3) a distinct structure for the review (including tasks and internal work
products) is defined, and
(4) follow-up by the reviewers occurs for any corrections that are made 10
Informal Reviews
 Informal reviews include:
 a simple desk check of a software engineering work product with a colleague
 a casual meeting (involving more than 2 people) for the purpose of reviewing a work product, or
 the review-oriented aspects of pair programming
 pair programming encourages continuous review as a work product (design or
code) is created.
 The benefit is immediate discovery of errors and better work product quality as a consequence.
 However, because there is no advance planning or preparation, no agenda or meeting

structure, and no follow-up on the errors that are uncovered, the effectiveness of such
reviews is considerably lower than more formal approaches.
11
Formal Technical Reviews
 The objectives of an FTR are:
 to uncover errors in function, logic, or implementation for
any representation of the software
 to verify that the software under review meets its
requirements
 to ensure that the software has been represented according
to predefined standards
 to achieve software that is developed in a uniform manner
 to make projects more manageable
 The FTR is actually a class of reviews that includes
walkthroughs and inspections.
12
The Review Meeting
 Between three and five people (typically)
should be involved in the review.
 Advance preparation should occur but should
require no more than two hours of work for
each person.
 The duration of the review meeting should be
less than two hours.
 Focus is on a work product (e.g., a portion of a
requirements model, a detailed component design,
source code for a component)
13
The Players
review
leader standards bearer (SQA)
producer
maintenance
oracle
recorder reviewer
user rep
14
The Players
 Producer—the individual who has developed the work
product
 informs the project leader that the work product is
complete and that a review is required
 Review leader—evaluates the product for readiness,
generates copies of product materials, and distributes
them to two or three reviewers for advance preparation.
 Reviewer(s)—expected to spend between one and two
hours reviewing the product, making notes, and
otherwise becoming familiar with the work.
 Recorder—reviewer who records (in writing) all important
issues raised during the review.
15
Review Guidelines
 1. Review the product, not the producer
 2. Set an agenda and maintain it
 3. Limit debate and rebuttal
 4. Enunciate problem areas, but don’t attempt to solve
every problem noted.
 5. Take written notes
 6. Limit the number of participants and insist upon advance
preparation.
 7. Develop a checklist for each product that is likely to be
reviewed.
 8. Allocate resources and schedule time for FTRs
 9. Conduct meaningful training for all reviewers
 10. Review your early reviews.
16
Sample-Driven Reviews
 In the real word of software projects, resources are
limited and time is short.
 a sample-driven review process in which samples of all

software engineering work products are inspected to
determine which work products are most error prone.
Full FTR resources are then focused only on those work
products that are likely (based on data collected during
sampling) to be error prone.
17
Sample-Driven Reviews
 To accomplish this, the following steps are suggested
 1. Inspect a fraction ai of each software work product i.

Record the number of faults fi found within ai .
 2. Develop a gross estimate of the number of faults
within work product i by multiplying fi by 1/ai .
 3. Sort the work products in descending order according
to the gross estimate of the number of faults in each.
 4. Focus available review resources on those work
products that have the highest estimated number of
faults
18

Lecture 12: Chapter 15: Review Techniques

Uploaded by

Copyright:

Available Formats

Lecture 12: Chapter 15: Review Techniques

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 12: Chapter 15: Review Techniques

Uploaded by

Copyright:

Available Formats

Lecture 12: Chapter 15

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

... there is no particular reason

 A project summary or progress

 The obvious benefit of technical reviews is the early discovery

 The formality of a review increases when

 However, because there is no advance planning or preparation, no agenda or meeting

 a sample-driven review process in which samples of all

 1. Inspect a fraction ai of each software work product i.

You might also like