College of Engineering
Department of Computer Engineering
SWE 401 – Software Quality Assurance
Dr. Khaled Almakadmeh
1
Chapter 5
Software Reviews
2
Introduction
A common product of the software development process, especially
in its analysis and design phases, is a document, in which progress
of development work performed is recorded.
The system analyst or designer who prepares the document reviews
repeatedly to detect any possible errors that might have been
introduced.
Development team leaders are expected to examine this document
and its details to reveal any remaining errors before granting their
approval.
3
Introduction
As professionals involved in producing this document, they are
unlikely to detect their own errors irrespective of extent and number
of reviews they conduct.
Therefore, only others – such as peers, superiors, experts, and
customer representatives – who have different experience and
points of view and are not directly involved in creating the document,
are capable of detecting errors unnoticed by the development team.
A review is probably the best method to detect existing errors that
remained undetected in a software project document.
4
Reviews
A process for evaluating a documented software project product in
which a group of professionals and stakeholders raise comments
regarding contents of a document presented to them beforehand.
The reviewers may have the authority to approve the contents of the
document and to approve the project advancing to the next stage.
Technical reviews and other reviews are organized by project teams
and the development departments.
5
Reviews
The various review methods differ in the emphasis attributed to the
different objectives.
The “filtering out” of errors achieved in different review techniques
depends primarily on the optimization of the review procedure.
An improved “filtering out” of errors is achieved by selection of an
appropriate review team member and a professional review team
leader, who knows how to lead the review session efficiently and
effectively.
6
Reviews
As the documents are products of the project’s initial phases,
reviews acquire special importance in the SQA process, as they
provide early detection and prevent passing analysis and design
errors where error detection and correction are much more complex,
cumbersome, and therefore also costly.
Several methodologies can be used to review documents such as:
o Formal technical reviews
o Peer reviews – inspections and walkthroughs
o Expert opinions
7
Reviews
Procedural order and teamwork lie at the heart of formal design
reviews, inspections, and walk throughs.
Each participant is expected to focus on his or her area of
responsibility or specialization when making comments. At each
review session, the mutually agreed-upon remarks are recorded.
The subsequent list of items should include full details of defect
location and description, documented in a way that will later enable
their full retrieval by the development team.
To ensure fruitful review sessions, a coordinator is required to
supervise the discussion and keep it on track.
8
Reviews
The review activities are frequently termed “static software quality
assurance techniques” and should be distinguished from “dynamic
software quality assurance techniques” which relate to testing that
involves running the software.
It should be noted that inspections and walkthroughs are also widely
successfully used to detect defects in the coding phase, where the
appropriate document reviewed is the code printout.
The knowledge that an analysis, design development products will
be reviewed stimulates the development team to do their best work.
This represents a further contribution of reviews to the improved
product quality.
9
Reviews: Direct objectives
✓ Detect analysis, design, and other document functional, logical, and
implementation errors.
✓ Identify changes, deviations, and omissions with respect to the
original specifications and approved changes.
✓ Locate deviations from templates, style procedures, and
conventions which might cause difficulties to development and
maintenance teams.
✓ Identify new risks that are likely to affect completion of the project.
✓ Approve the analysis, design, or other respective development stage
of the product.
10
Reviews: Indirect Objectives
Provide an informal meeting place for the exchange of professional
knowledge about development methods, tools, and techniques.
Record analysis and design errors that will serve as a basis for
future corrective actions implemented among other development
teams.
11
Formal Reviews
Formal reviews, also called formal technical reviews (FTR), differ
from all other review methods as they are the only type of review
that is a requisite for approving the development product.
With out this approval, the development team cannot continue to the
next phase of development.
Formal technical reviews may be conducted at any development
milestone requiring completion of document, whether the document
is a requirement specification or an installation plan.
12
Formal Reviews: Examples
13
Participants in Formal Reviews
All formal reviews are conducted by a review leader and review
team. The choice of appropriate participants is of special importance
because of their authority to approve or disapprove the development
product.
Candidates for review team leadership include development
department manager, chief software engineer, software quality
assurance unit head or customer’s chief software engineer.
Appointment of the review leader is expected to be performed by a
person of higher seniority than the project leader.
14
Participants in Formal Reviews
The review team can be selected from among the senior members
of the project team, together with appropriate senior professionals
assigned to other projects and departments. It is desirable that non-
project staff make up most of the review team.
A review team of 3–5 members is expected to be an efficient team,
given that the proper diversity of experience and approaches among
the participants is assured.
An excessively large team tends to create coordination problems,
wastes review session time and decreases overall level of review.
15
Formal Reviews: Infrastructure
Develop checklists for typical reviewed documents or at least for the
most common ones.
Train senior professionals to serve as review leaders and technical
review team members.
Periodically analyze the effectiveness of past technical reviews
regarding defect detection to improve technical review methodology.
16
Formal Review: Contents
Participants in a review are required to review a document (the
entire document). In cases of large volumes or complex documents,
which no review session can effectively cover, the review leader
may consider splitting the review material into two or more parts.
It can be decided to review only part of a document, the more critical
part or part expected to be “richer” in defects. A decision regarding
additional reviews may depend on the number and type of defects
found in the document reviewed.
There are three main review participant groups –review leader,
review team, and development team.
17
Formal Review: Preparations
The review session be scheduled shortly after the document to be
reviewed has been distributed to the review team members.
Timely sessions prevent an unreasonable length of time from
elapsing before the project team can commence to the next
development phase and thus reduce the risk of going off schedule.
Team members are expected to review the review document and list
their comments prior to the review session. In cases where the
documents are of a substantial size, the review leader may ease the
load by assigning each team member with only parts in documents.
18
Formal Review: Preparations
An important tool for ensuring the review’s completeness is the
checklist. Checklists dedicated to the more typical development
documents are available and can be constructed when necessary.
Checklists contribute to the review effectiveness by reminding the
reviewer of all the primary and secondary issues requiring attention.
The main obligation of the development team is to prepare a short
presentation of the design document. The presentation should focus
on main professional issues awaiting approval rather than (wasting
time) on a general description of the project.
19
Formal Review: Review Session
A. A short presentation of the design document.
B. Comments made by members of the review team.
C. Verification and validation of each of the comments discussed to
deter mine the required action items (corrections, changes and
additions) that the project team must perform.
D. A team member assigned as a scribe is responsible to document
each action item that relates to the required corrections, changes,
and additions.
E. Decisions about the product (document), determine the project’s
progress.
20
Formal Review: Post Review Report
One of the review leader’s responsibilities is to issue the review
report immediately after the review session.
Early distribution of the report enables the development team to
perform corrections earlier and minimize delays to project schedule.
The review leader determine whether action items are accomplished
as a condition for allowing the project to progress to next phase.
The follow-up is fully documented to enable future clarification of
corrections.
21
Formal Review: Guidelines
22
Peer Reviews (Inspections and Walkthroughs)
The major difference between formal technical reviews and peer
review methods is rooted in the level of authority of the participants.
While most participants in formal technical reviews hold superior
positions to the project leader, participants in peer reviews are, as
expected, the project leader’s equals, members of the leader’s
department and other units.
Formal technical reviews are authorized to approve the document so
that work on the next stage of the project may begin. This authority
is not granted to the peer reviews, whose main objectives lie in
detecting errors and deviations from standards.
23
Peer Reviews (Inspections and Walkthroughs)
Level of formality differentiates a walkthrough from an inspection.
While the members of an inspection team are required to prepare for
inspection session, walkthrough participants are not requested to
make any meaningful preparations.
Walkthroughs are limited to comments on the document reviewed,
the findings of inspections are incorporated into the efforts invested
to improve development methods using corrective action processes.
Inspections are considered to be more significant contributors to the
general level of SQA.
24
Peer Reviews (Inspections and Walkthroughs)
An inspection is usually based on a comprehensive infrastructure,
including:
A. Inspection checklists is periodically updated for each type of document,
coding language, and tools.
B. Typical defect frequency tables based on past findings to direct
inspectors to potential “defect concentration areas”.
C. Training of competent professionals in inspection process issues. This
process makes it possible for them to serve as inspection leaders
(moderators) or inspection team members.
D. Periodic analysis of effectiveness of past inspections to improve the
inspection methodology.
25
Peer Reviews (Inspections and Walkthroughs)
26
Expert Opinions
Expert opinions, prepared by outside experts, support quality
evaluation by introducing additional capabilities to internal review
staff, and thus reinforcing organization’s internal quality assurance
activities.
Outside experts transmit their expertise either by:
o Preparing an expert judgment about a document or a code section, or
o Participating as a member of an internal review, inspection, or
o Walkthrough team
27
Expert Opinions
An outside expert judgment, as well as her/his participation as an
external member of a review team, is most beneficial in the following
situations:
o Insufficient in-house professional capabilities in a specialized area.
o Temporary lack of in-house professionals for review team participation
due to intense workload pressures.
o Indecisiveness caused by disagreements among organization’s senior
professionals.
o In small organizations where number of suitable candidates for a review
team is insufficient.
28
A Comparison of Review Methods
29
