home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4948 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!agate!stanford.edu!apple!cambridge.apple.com!goofy!mumbo.apple.com!gallant.apple.com!news
  2. From: neumann.m@applelink.apple.com (mark neumann)
  3. Newsgroups: comp.software-eng
  4. Subject: Software Inspections.  How many does it take?
  5. Message-ID: <1992Dec14.192008.15480@gallant.apple.com>
  6. Date: 14 Dec 92 19:20:08 GMT
  7. Sender: news@gallant.apple.com
  8. Organization: HomePro Computer Services
  9. Lines: 48
  10.  
  11. Recently I have been reading Capers Jones new book "Applied Software
  12. Measurement", McGraw Hill.   There is a lot of good stuff in it, but one
  13. recommendation he makes on the topic of software inspections does not
  14. match my experience.
  15.  
  16. He presents some statistics showing software inspections (design reviews,
  17. code walkthroughs, etc..) as being the most effective way of removing
  18. defects.  However, the inspection technique he describes  requires a
  19. bunch of people! (he lists the following staff as being present):
  20.  
  21. "  * A moderator (to keep discussions within bounds)
  22.    * A reader (to paraphase the work being inspected)
  23.    * A recorder (to keep records of all defects)
  24.    * An inspector (to identify any problems)
  25.    * An author (whose work is being inspected)
  26.  
  27. All five (or more) may be present for large projects.  For small projects
  28. dual roles can be assigned, so that the minimum number for a true
  29. inspection is three: moderator, author, and one other person. "
  30.  
  31. For high-level architecture/design approach type reviews, everyone
  32. affected needs to be involved.  But what about module level design/code
  33. inspections, where the work being inspected is the result of one persons
  34. effort?
  35.  
  36. In my experience, when the schedule pressure is on, most of the attendees
  37. at large formal code walkthroughs are too busy with their own work to
  38. carefully go over the material being reviewed.  This diminishes the
  39. effectiveness of the review.
  40.  
  41. It seems obvious that having someone check your work is a good idea.  It
  42. also seems that each additional person that checks your work is less
  43. likely to find a problem (on average).
  44.  
  45. My question:  Is one person enough?  Does anybody else use a single
  46. reviewer approach?
  47.  
  48. I believe that there are interpersonal dynamics which make one reviewer
  49. more effective than two of more.  With two or more people, the ego of the
  50. person whose work is being reviewed is more likely to become a factor.
  51.  
  52. Finally, by assigning a single reviewer to inspect someone elses work,
  53. that person is obviously  responsible for any flaws that get through, so
  54. he/she is likely to take the role seriously. (Note: you probably do not
  55. want to assign people to inspect each other's work, since they may agree
  56. to just trust each other completely).
  57. --------------------------------------------
  58. Opinions expressed are solely my own.
  59.