|
|
An inspection is one of the most common sorts of review found in
software projects. The goal of the inspection is for all of the
inspectors to reach consensus on a work product and approve it for use
in the project. Commonly inspected work products include software
requirements specifications (see Chapter 6) and test plans (see Chapter
8). In an inspection, a work product is selected for review and a team
is gathered for an inspection meeting to review the work product. A
moderator is chosen to moderate the meeting. Each inspector prepares
for the meeting by reading the work product and noting each defect. In
an inspection, a defect is any part of the work product that will keep
an inspector from approving it. For example, if the team is inspecting
a software requirements specification, each defect will be text in the
document which an inspector disagrees with.
|
|
Read more...
|
|
Reviews in outsourced projects can be highly time-consuming; much more
so, in fact, than in an in-house project. In an in-house project, the
team is already familiar with that particular organization’s standards,
and there are usually plenty of examples to work from. The project
manager doesn’t need to spend nearly as much time making sure that the
team understands the work being accomplished. What’s more, an in-house
team normally understands the mission of the organization and the needs
of its users. Many project managers take this for granted, and don’t
think to communicate these things to the vendor. It requires
constant effort and vigilance on the part of the project manager to
make sure that the needs are properly understood when moving work
outside the organization. In addition to knowledge transfer, reviews
are also important tools for collaboration. It is important to
encourage collaboration between the project team members at the vendor
and the team members within the organization. When an inspection team
is made up of people from both organizations, the only way for them to
reach consensus on a work product in order to approve it is to
collaborate on identifying and fixing the defects in that work product.
After the inspection, everyone has a better understanding of the work
to be done, as well as of how everyone else thinks about that work.
|
|
Read more...
|
|
|
A deskcheck is a simple review in which the author of a work product
distributes it to one or more reviewers. In a deskcheck, 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.
Unlike an inspection, a deskcheck does not produce written logs which
can be archived with the document for later reference. There is no
follow-up meeting or approval process. It is simply a way for one team
member to check another’s work. Deskchecks are not formal reviews
(where “formal” simply means that it generates a written work product
which meets a certain standard and is archived with the rest of the
project documentation); there is no standard for the results of the
deskcheck. The reviewers simply review the work product and return the
results. There is no moderator, and there is not necessarily any
consensus generated.
|
|
Read more...
|
|
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. It typically does not follow a rigid procedure; rather, the
author presents the work product to the audience in a manner that makes
sense. Many walkthroughs present the document using a slide
presentation, where each section of a work product is shown using a set
of slides. Work products that are commonly reviewed using a walkthrough
include design specifications and use cases.
|
|
Read more...
|
|
|
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). In addition to helping teams find and
fix bugs, code reviews are useful for both cross-training programmers
on the code being reviewed and for helping junior developers learn new
programming techniques.
|
|
Read more...
|
|
|
Review Practices 
