home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5041 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.4 KB  |  61 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!thor!jhull
  3. From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
  4. Subject: Re: Software Inspections.  How many does it
  5. Message-ID: <1992Dec17.180947.3574@den.mmc.com>
  6. Sender: news@den.mmc.com (News)
  7. Nntp-Posting-Host: thor.den.mmc.com
  8. Reply-To: jhull@vulcan-gw.den.mmc.com
  9. Organization: Martin Marietta Astronautics Group
  10. References: <BzB9J2.2q2E@austin.ibm.com>
  11. Date: Thu, 17 Dec 1992 18:09:47 GMT
  12. Lines: 47
  13.  
  14. In article <1992Dec14.192008.15480@gallant.apple.com>, 
  15. neumann.m@applelink.apple.com (mark neumann) writes:
  16. mn>
  17.  
  18.  
  19. In article 2q2E@austin.ibm.com, 
  20. dugal@austin.ibm.com (Doug Gray) writes:
  21. dg>
  22.  
  23. mn>
  24. mn> It seems obvious that having someone check your work is a good idea.  It
  25. mn> also seems that each additional person that checks your work is less
  26. mn> likely to find a problem (on average).
  27. mn>
  28. dg>
  29. dg>Actually, although it does seem obvious, it is probably not the case.  There is an
  30. dg>article in the April '92 issue of ACM Transactions on Software Engineering and
  31. dg>Methodology which addresses that theory (at least for Requirements)  "An Experimental
  32. dg>Study of Fault Detection In User Requirements Documents" (Schneider, Martin & Tsai) 
  33. dg>found that when independent inspection teams reviewed the same requirements document,
  34. dg>they did not duplicate the work of each other.
  35.  
  36. But mn wasn't talking about *independent* review teams.  He was talking about
  37. adding more people to a team.  In this case, I suggest that the amount/number
  38. of errors detected per person added to the team decreases rapidly for team sizes
  39. beyond four or five.
  40.  
  41.  
  42. dg>The same sort of relationship can be developed for a review team as well.  When a
  43. dg>review team signs off that the deliverable is acceptable, ALL members of the team
  44. dg>become responsible for the quality of that product - in some ways more responsible
  45. dg>than the original author.
  46.  
  47. I agree with dg completely.  I do suggest, however, that significantly superior
  48. results will be obtained from 2 completely independent review teams of perhaps
  49. 3 or 4 people than a single review team of 6 to 8.
  50.  
  51.  
  52. -- -- -- --  --
  53.        _   _
  54.     /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
  55.    //_) -/- -/-   1544 S. Vaughn Cir  
  56. /_/ \_/ /   /      Aurora, CO 80012    303-977-1061
  57.  
  58. No matter where you go ... there you are.
  59. #include <standard.disclaimer.h>
  60.  
  61.