SQA Reviews

Lecture # 12

1
What is a Review?
• A process or meeting during which a work
product, or a set of work products, is presented
to project personnel, managers, users, or other
interested parties for comment or approval.
• Types include code review, design review, formal
qualification review, requirements review, test
readiness review
• IEEE Std. 610.12-1990

2
Objectives
Reviews
• Identify required improvements in a product
• Assure that the deliverable is complete
• Assure that the deliverable is technically correct
• Measure the progress of the project

3
Objectives
Reviews
• Identify any defects early, thus resulting in cost
and time savings
• Assure the quality of deliverable before the
development process is allowed to continue
• In construction industry: if the review the foundation it
does not meet the necessary quality requirements, or
legal requirements then further constructions should
be stop
• Once a deliverable has been reviewed, revised as
necessary, and approved, it can be safely used as
a basis for further development 4
Colleagues as Critics
• There is no particular reason why your friend
and colleague cannot also be your sternest critic
• Jerry Weinberg

5
Benefits of Review
• A number of team members get an opportunity
to provide their input
• At that time you can incorporate their feedback into
work product
• Ownership of the work product is transferred
from an individual to a group
• If the review was not held the ownership of the
product would belong to one or two who are the
author of the product
• A (limited) training ground 6
Kinds of Reviews
• Business reviews
• Technical reviews
• Management reviews
• Inspections
• Walk-throughs
• Expert opinion

7
Kinds of Reviews
Business reviews: Objectives of Business Reviews
• The deliverable is complete
• The deliverable provides the information
required for the next phase
• The deliverable is correct
• There is adherence to the procedures and
policies of the company

8
Kinds of Reviews
Technical reviews: Objectives of Technical Reviews
• Point out needed improvements in the product
of a single person or a team
• Confirm those parts of a product in which
improvement is either not desired or not needed
• Achieve technical work or more uniform, or at
least more predictable, quality than can be
achieved without reviews, in order to make
technical work more management

9
Kinds of Reviews
Technical reviews: Objectives of Technical Reviews
• Software reviews are a “filter” for software
engineering process
• Reviews are applied at several points during
software development and serve to uncover
errors and defects that can then be removed
• Software reviews “purify” the software
engineering activities

10
Kinds of Reviews
Technical reviews: Objectives of Technical Reviews
• Technical work needs reviewing for the same
reason that pencils need erasers: To err is human
• Another reason we need technical reviews is
that although people are good at catching some
of their own errors, large classes of errors escape
the originator more easily than they escape
anyone else

11
Kinds of Reviews
Technical reviews: Objectives of Technical Reviews
• They also ensure that any changes to the
software are implemented according to pre-
defined procedures and standards

12
Kinds of Reviews
Technical reviews: What Technical Reviews Are Not!
• A project budget summary
• A scheduling assessment
• An overall progress report
• A mechanism for reprisal or political intrigue!!

13
Kinds of Reviews
Management Reviews: Objectives of Management Reviews
• Validate from a management perspective that
the project is making progress according to the
project plan
• Ensure a deliverable is ready for management
approval
• Resolve issues that require management’s
attention

14
Kinds of Reviews
Management Reviews: Objectives of Management Reviews
• Identify if the project needs a change of
direction
• Control the project through adequate allocation
of resources

15
Kinds of Reviews
Inspection Reviews: Objectives of Inspection Reviews
• Inspection emphasizes the objective of
corrective action.
• An inspection’s findings are incorporated into
efforts to improve development methods per se.
Inspections

16
Kinds of Reviews
Walkthrough Reviews: Objectives of Walkthrough Reviews
• A walkthrough’s findings are limited to
comments on the document reviewed
• walkthroughs, considered to contribute more
significantly to the general level of SQA

17
Kinds of Reviews
Expert Reviews: Objectives of Expert Reviews
• Expert opinions, prepared by outside experts,
support quality evaluation by introducing
additional capabilities to the internal review staff
• The organization’s internal quality assurance
activities are thereby reinforced. Outside experts
transmit their expertise by either:
• Preparing an expert’s judgment about a document or a
code section
• Participating as a member of an internal design review,
inspection or walkthrough team 18
Review Roles
• Facilitator/ Review Leader/ Moderator /
Coordinator (DD Manger, Chief Software Eng.)
• Author (Designer, A Cod or Implementer, Tester
• Recorder
• Reviewer
• Observer

19
Responsibilities of
Roles
20
Review Roles
Responsibilities of Facilitator
• Responsible for providing the background of the
work and assigning roles to attendees
• Encourages all attendees to participate
• Keeps the meeting focused and moving
• Responsible for gaining consensus on problems

21
Review Roles
Responsibilities of Author
• Responsible for the readiness and distribution of
material to be reviewed
• During the meeting, the author paraphrases the
document a section at a time
• Responsible for
• scheduling the review
• selecting the review participants
• determining if the entry criteria for the review are met

22
Review Roles
Responsibilities of Author
• providing information about the product
during all stages
• clarifying any unclear issues
• correcting any problems identified
• providing dates for rework and resolution

23
Review Roles
Responsibilities of Recorder
• Collects and records each defect uncovered
during the review meeting
• Develops an issues list and identifies whose
responsibility it is to resolve each issue
• Records meeting decisions on issues; prepares
the minutes; and publishes the minutes, and
continually tracks the action items

24
Review Roles
Responsibilities of Reviewer
• Spends time prior to the meeting reviewing
information
• Makes notes of defects and becomes familiar
with the product to be reviewed
• Identifies strengths of the product
• Verifies that the rework is done
• Insists upon clarifying any issues that are not
clear

25
Review Roles
Responsibilities of Observer
• A new member to the project team, who learns
the product and observes the review techniques

26
Review Guidelines
• Preparation
• Discussions
• Respect
• Agenda
• Review Records
• Resources
• Attendees

27
Review Frequency
• At the beginning/end of the requirements phase
• At the beginning/end of the design phase
• At the beginning/end of the code phase
• At the beginning/end of the test phase
• Approval of the test plan

28
Review Planning - 1
• Distribute review package one week in advance
• Document to be reviewed
• Review agenda
• Identification of the individual who will manage the
agenda and schedule
• Exit and entrance criteria for the review
• Objective of the review

29
Review Planning - 2
• Names of attendees, their roles and responsibilities
• Review location
• Date and time of review
• List of classifications that will be used for defects
discovered (defect type, defect origin, and defect
severity)
• Procedures for handling issues raised during the
review and escalation phase

30
Review Meeting - 1
• Facilitator begins the meeting with an
introduction of agenda, people, and description
of their roles
• Author of the document proceeds to explain the
materials, while reviewers raise issues based on
advance preparation

31
Review Meeting - 2
• When valid problems, issues, or defects are
discovered, they are classified according to their
origin or severity and then recorded
• These are accompanied with the names of
individuals who are responsible for resolution
and the time frame during which the item will be
resolved
• Related recommendations are also recorded

32
Guidelines for Reviewers
• Be prepared - evaluate product before the review
meeting
• Review the product, not the producer
• Keep your tone mild, ask questions instead of
making accusations
• Stick to the review agenda
• Raise issues, don’t resolve them
• Avoid discussions of style - stick to technical
correctness
33
Decisions at the End of a
Review Meeting
• All attendees must decide whether to
• Accept the product without further modification
• Reject the product due to severe errors
• Accept the product provisionally
• Hold a follow-up review session

34
Review Report
• Published by the recorder, with approval from all
attendees, after a week of the review meeting
• Review report consists of
• Elements reviewed
• Names of individuals who participated in the review
• Specific inputs to the review
• List of unresolved items
• List of issues that need to be escalated to management
• Action items/ownership/status
• Suggested recommendations 35
Rework
• It is the responsibility of project manager to
ensure that all defects identified in the review
are fixed and retested

36
Follow-Up
• During the follow-up, that all discrepancies identified are
resolved and the exit criteria for the review have been met
• Document lessons learned during the final report also

37
38
39
40
41
42
43
44
Summary
• Discussed different kinds of reviews: business, technical, and
management
• Introduced the review process, meeting, and post-review
process

45
References
• Inroads to Software Quality by Alka Jarvis and Vern Crandall,
PH 1997 (Ch. 7)
• Software Engineering: A Practioner’s Approach by Roger S.
Pressman (Ch. 8)

46