Applied Software Project Management

Reviews

http://www.stellman-greene.com 1
Applied Software Project Management

When are reviews needed?

 A review is any activity in which a work product is
distributed to reviewers who examine it and give feedback.
 Reviews are useful not only for finding and eliminating defects, but
also for gaining consensus among the project team, securing
approval from stakeholders, and aiding in professional
development for team members.
 Reviews help teams find defects soon after they are injected making
them cost less to fix than they would cost if they were found in test.
 All work products in a software project should be either reviewed or
tested.
 Software requirements specifications, schedules, design documents,
code, test plans, test cases, and defect reports should all be reviewed.

http://www.stellman-greene.com 2
Applied Software Project Management

Types of Review:
Inspections
 Inspections are moderated meetings in which
reviewers list all issues and defects they have found
in the document and log them so that they can be
addressed by the author.
 The goal of the inspection is to repair all of the
defects so that everyone on the inspection team
can approve the work product.
 Commonly inspected work products include software
requirements specifications and test plans.

http://www.stellman-greene.com 3
Applied Software Project Management

Types of Review:
Inspections
 Running an inspection meeting:
1. A work product is selected for review and a team is gathered for an
inspection meeting to review the work product.
2. A moderator is chosen to moderate the meeting.
3. Each inspector prepares for the meeting by reading the work
product and noting each defect.
4. In an inspection, a defect is any part of the work product that will
keep an inspector from approving it.
5. Discussion is focused on each defect, and coming up with a
specific resolution.
 It’s the job of the inspection team to do more than just identify the
problems; they must also come up with the solutions.
6. The moderator compiles all of the defect resolutions into an
inspection log

http://www.stellman-greene.com 4
Applied Software Project Management

Inspection Log Example

http://www.stellman-greene.com 5
Applied Software Project Management

Types of Review:
Deskchecks
 A deskcheck is a simple review in which the author of a
work product distributes it to one or more reviewers.
 The author sends a copy of the work product to selected
project team members. The team members read it, and
then write up defects and comments to send back to the
author.

http://www.stellman-greene.com 6
Applied Software Project Management

Types of Review:
Deskchecks
 Unlike an inspection, a deskcheck does not
produce written logs which can be archived with
the document for later reference.
 Deskchecks can be used as predecessors to
inspections.
 In many cases, having an author of a work product pass
his work to a peer for an informal review will
significantly reduce the amount of effort involved in the
inspection.

http://www.stellman-greene.com 7
Applied Software Project Management

Types of Review:
Walkthroughs
 A walkthrough is an informal way of presenting a
technical document in a meeting.
 Unlike other kinds of reviews, the author runs the
walkthrough: calling the meeting, inviting the
reviewers, soliciting comments and ensuring that
everyone present understands the work product.
 Walkthroughs are used when the author of a work
product needs to take into account the perspective of
someone who does not have the technical expertise to
review the document.
 After the meeting, the author should follow up with
individual attendees who may have had additional
information or insights. The document should then be
corrected to reflect any issues that were raised.
http://www.stellman-greene.com 8
Applied Software Project Management

Types of Review:
Code Review
 A code review is a special kind of inspection in
which the team examines a sample of code and
fixes any defects in it.
 In a code review, a defect is a block of code which does
not properly implement its requirements, which does
not function as the programmer intended, or which is
not incorrect but could be improved
 For example, it could be made more readable or its performance
could be improved

http://www.stellman-greene.com 9
Applied Software Project Management

Types of Review:
Code Review
 It’s important to review the code which is most likely to have
defects. This will generally be the most complex, tricky or involved
code.
 Good candidates for code review include:
 A portion of the software that only one person has the expertise to
maintain
 Code that implements a highly abstract or tricky algorithm
 An object, library or API that is particularly difficult to work with
 Code written by someone who is inexperienced or has not written that
kind of code before, or written in an unfamiliar language
 Code which employs a new programming technique
 An area of the code that will be especially catastrophic if there are
defects

http://www.stellman-greene.com 10
Applied Software Project Management

Types of Review:
Pair Programming
 Pair programming is a technique in which two
programmers work simultaneously at a single computer
and continuously review each others’ work.
 Although many programmers were introduced to pair
programming as a part of Extreme Programming, it is a
practice that can be valuable in any development
environment.
 Pair programming improves the organization by ensuring
that at least two programmers are able to maintain any
piece of the software.

http://www.stellman-greene.com 11
Applied Software Project Management

Types of Review:
Pair Programming
 In pair programming, two programmers sit at one computer to write
code. Generally, one programmer will take control and write code,
while the other watches and advises.
 Some teams have found that pair programming works best for them if the
pairs are constantly rotated; this helps diffuse the shared knowledge
throughout the organization. Others prefer to pair a more junior person
with a more senior for knowledge sharing.
 The project manager should not try to force pair programming on the
team; it helps to introduce the change slowly, and where it will meet
the least resistance.
 It is difficult to implement pair programming in an organization where the
programmers do not share the same nine-to-five (or ten-to-six) work
schedule.
 Some people do not work well in pairs, and some pairs do not work well
together.

http://www.stellman-greene.com 12
Applied Software Project Management

Diagnose and fix Review

Problems

http://www.stellman-greene.com 13
Applied Software Project Management

Problems Are Found Too Late

 There are preventable defects in the software that
aren’t caught until late in the project
 The team may misunderstand a need, but that’s not
discovered until delivery
 Requirements may be missed or incorrect
 The design may be difficult to use or fail to take all of the
features into account

http://www.stellman-greene.com 14
Applied Software Project Management

Big, Useless Meetings

 A project manager who has previously been
burned by problems that were found too late is
determined to avoid falling into the same trap
 He calls a big meeting with everyone who could possibly
have input
 The meeting drags on for hours, without making any
real progress
 Eventually, everyone gives up and goes back to the way
they did things before

http://www.stellman-greene.com 15
Applied Software Project Management

The Indispensable “Hero”

 One “critical” person is seen as the clear top
programmer, and all important work is sent through
him
 He may have a unique skill or experience
 Sometimes he hoardes information so all tasks that rely
on it must go through him
 He is always working long hours – and causing
bottlenecks

http://www.stellman-greene.com 16
Applied Software Project Management

Fixing Review Problems

 Problems that are found too late, big useless
meetings, and the indispensable “hero” are
problems which can be solved with reviews
 Reviews can catch defects early, when they are cheaper
to fix
 A review meeting only includes the people necessary for
the work to be done
 Reviews – especially code reviews – can help the “hero”
spread his expertise and knowledge

http://www.stellman-greene.com 17