NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4984

Text File | 1992-12-15 | 4.5 KB | 92 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!dugal
From: [e-mail] (Doug Gray)
Subject: Re: Software Inspections.  How many does it take?
Originator: [e-mail]
Sender: [e-mail] (News id)
Message-ID: <[e-mail]>
Date: Tue, 15 Dec 1992 17:21:00 GMT
References:  <[e-mail]>
Organization: IBM Austin
Lines: 79


In article <[e-mail]>, [e-mail] (mark neumann) writes:
> Recently I have been reading Capers Jones new book "Applied Software
> Measurement", McGraw Hill.   There is a lot of good stuff in it, but one
> recommendation he makes on the topic of software inspections does not
> match my experience.
>
> He presents some statistics showing software inspections (design reviews,
> code walkthroughs, etc..) as being the most effective way of removing
> defects.  However, the inspection technique he describes  requires a
> bunch of people! (he lists the following staff as being present):
>
> "  * A moderator (to keep discussions within bounds)
>    * A reader (to paraphase the work being inspected)
>    * A recorder (to keep records of all defects)
>    * An inspector (to identify any problems)
>    * An author (whose work is being inspected)
>
> All five (or more) may be present for large projects.  For small projects
> dual roles can be assigned, so that the minimum number for a true
> inspection is three: moderator, author, and one other person. "
>
> For high-level architecture/design approach type reviews, everyone
> affected needs to be involved.  But what about module level design/code
> inspections, where the work being inspected is the result of one persons
> effort?
>

I'd like to direct you to Freedman & Weinberg's, Handbook of Walkthroughs,
Inspections and Technical Reviews.  The book has a lot of good things to say about
just the topic above.  From what I can recall, it is important that the review team
be kept relatively small, probably less than 7, and that the amount of time to review
any one particular chunk should be no more than 2 hours.  If it takes longer than
that, there is probably something broken in your architecture.   As you pointed out,
you should vary the size of the group based not only on the size of the work being
inspected/reviewed, but also on the interfaces that the deliverable has.


> It seems obvious that having someone check your work is a good idea.  It
> also seems that each additional person that checks your work is less
> likely to find a problem (on average).

Actually, although it does seem obvious, it is probably not the case.  There is an
article in the April '92 issue of ACM Transactions on Software Engineering and
Methodology which addresses that theory (at least for Requirements)  "An Experimental
Study of Fault Detection In User Requirements Documents" (Schneider, Martin & Tsai)
found that when independent inspection teams reviewed the same requirements document,
they did not duplicate the work of each other.

> I believe that there are interpersonal dynamics which make one reviewer
> more effective than two of more.  With two or more people, the ego of the
> person whose work is being reviewed is more likely to become a factor.

I'm not sure I see how that holds.  I would think that the author's ego would be a
factor whether reviewed by 1 or by 20.  Their work is still being put on the line.  I
can see how having the author be a part of the review can be a problem, though.
Generally, it seems that having the author as distanced as possible from the review
is the best idea.

> Finally, by assigning a single reviewer to inspect someone elses work,
> that person is obviously  responsible for any flaws that get through, so
> he/she is likely to take the role seriously. (Note: you probably do not
> want to assign people to inspect each other's work, since they may agree
> to just trust each other completely).

The same sort of relationship can be developed for a review team as well.  When a
review team signs off that the deliverable is acceptable, ALL members of the team
become responsible for the quality of that product - in some ways more responsible
than the original author.


-Doug Gray
***************
These opinions are mine and are in no way related to those of IBM.
--
Doug Gray               Phone: [phone]
IBM AWSD  Zip 9260      T/L: 678-2366
11400 Burnet Rd.        Internet: [e-mail]
Austin, Tx 78750        vnet: dugal@ausvm6