home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5092 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.9 KB  |  39 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!agate!dog.ee.lbl.gov!news!vela!cs.uiuc.edu!marick
  3. From: marick@cs.uiuc.edu (Brian Marick)
  4. Subject: Re: Software Inspections. How many does it take?
  5. Message-ID: <BzKCzG.6xB@cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1992Dec14.192008.15480@gallant.apple.com> <BzEqpI.5yp@NeoSoft.com> <1992Dec18.145952.26062@saifr00.cfsat.honeywell.com> <1992Dec19.014719.21577@gallant.apple.com> <tom_van_vleck-181292203924@kip-10.taligent.com>
  8. Date: Sun, 20 Dec 1992 15:14:03 GMT
  9. Lines: 28
  10.  
  11. I like the approach given in David L. Parnas and David M. Weiss,
  12. "Active Design Reviews: Principles and Practices", Proceedings of the
  13. 8th International Conference on Software Engineering, pp. 132-136.  If
  14. I recall correctly, they advocate identifying a group of experts (in
  15. the application area, interfaces to the hardware, maintainability, and
  16. so on).  Rather than collecting all of these people for a meeting,
  17. instead they're given the design and a list of questions to answer.
  18. They answer these alone in their office.  People are convened only to
  19. discuss problems.  When possible, the "questions" are in the form of
  20. tasks, such as "Show how you'd use this design to cause the module to
  21. do task FOO with your module BAR?", rather than just "Does the
  22. module's interface to your BAR module look OK?"
  23.  
  24. (Some of this may be my later distortions of their original idea; read
  25. the paper.) 
  26.  
  27. I try to use this approach in my inspections, and I use much the same
  28. principle in my "question catalog for code inspections", available via
  29. anonymous FTP from cs.uiuc.edu:/pub/testing/question.ps.  It seems to
  30. be a useful adjunct to other tricks of the trade.
  31.  
  32. Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
  33. Testing Foundations:  Consulting, Training, Tools.
  34. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  35.  
  36.  
  37.  
  38.  
  39.