Re: [AM] Unfounded assertion

The literature usually distinguishes between "reviews" and
"inspections".

Reviews are less-formal, less-technical exploration/explanation
meetings, aimed at exploring issues. These range from stakeholder
reviews, which typically give stakeholders an opportunity to look at
the proposed solution, check whether it appears to align with their
understanding of the need, and raise issues to test the solution, to
design reviews, which give the broader community a chance to look
at a design in detail and learn how it works, raise questions about
relationships of components, understand the role of their component
in the overall structure, etc.  Reviews typically are larger and
broader, the discussion relatively free-ranging, and usually produce
action items and issues for subsequent reporting to the review team.

Inspections (Basili uses "reading") are narrowly focused on finding
defects in an artifact.  They involve a smaller team (typically 3-6
people), the participants have defined roles, there is a moderator,
managers are not allowed to participate (unless they are also technical
contributors).  Discussion is strictly limited (no exploration of
responses to an issue raised; even discussion of whether an issue is
actually a defect is deferred if there isn't immediate consensus.  In
pure Fagan inspections there is a reader (not the author) who
paraphrases the artifact, line-by-line, to test understanding of the
intent.  Defects are categorized for later root-cause analysis and
cataloged for resolution and verification.  The participant roles may
include representing specific perspectives (user, tester, factory, etc.)
and readers may use checklists of common issues for the given kind of
artifact.  The speed of preparation and inspection are recorded (for
code, 200 lines per hour is a typical target); the organization usually
tracks the rate and has defined control limits validated to maximize
defects found.

Reading the esay that Scott A pointed at a few days ago, what he
described was not a classical inspection, but some kind of cross between
an inspection and a review.  A significant number of his issues would
not occur in a well-run Fagan inspection.

Note inspections are verification, not validation - they're not about
seeing whether you did the right thing, but about seeing whether you did
what you did right.  Also, the emphasis is NOT on defect prevention, it
is on defect removal.  The assumption is that people DO make mistakes.
There is substantial literature demonstrating that it is cheaper to find
defects by inspection than by testing. [As noted previously, most
organizations do still do some testing, so the overall cost needs to be
considered to see whether inspection is justified.]

In an agile methodology, verification would come through testing,
pair programming, collective ownership, and customer involvement.
I don't know of a study specifically looking at the relative merits
of inspection versus those mechanisms, as practice in XP.  The XP
practices lean on each other and leverage each other in subtle ways that
make it hard to look at them in isolation.  Also, agile methods depend
on iteration (and, implicitly, rework) for validation, so it may be
that using that mechanism for verification is another leverage.  Or
not - the field is ripe for study.

scott

| From: Adrian Howard<[email protected]>
| Date: Sun, 1 Feb 2004 20:32:52 +0000
| 
| On Friday, January 30, 2004, at 08:41  pm, Randy Miller wrote:
| [snip]
| > Some activities, like code reviews, are
| > clearly preventative. They keep people from making mistakes. Other
| > activities, like requirements gathering, help people build the right
| > system. Or maybe they prevent people from building the wrong system. I
| > found it interesting to look at an activity as a guidance mechanism
| > (with an enabling side and a prevention side) instead of something to
| > hold you down or prop you up. Your message provoke that line of 
| > thought.
| [snip]
| 
| Interesting point of view. Of course a lot depends on how the activity 
| is done.
| 
| The better code review sessions I've been involved were more about 
| building the right system than they were about preventing mistakes. 
| More "We can refactor that out into a new class" than "That will die 
| horribly on edge case foo".
| 
| I'm sure I'm not alone in having the experience of a large requirements 
| gathering process helping build the wrong system :-)
| 
| It's interesting that agile practices like TDD and pair programming 
| turn find-the-defect activities into drive-the-design activities by 
| tightening the feedback loop much as possible.
| 
| Adrian


-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------