home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4170 < prev    next >
Encoding:
Text File  |  1992-11-06  |  1.9 KB  |  44 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!cs.uiuc.edu!marick
  3. From: marick@cs.uiuc.edu (Brian Marick)
  4. Subject: Re: Productivity of a C programmer ?
  5. Message-ID: <Bx9y7u.G0t@cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <Bx3KFK.7Er@cdsmn.mn.org> <Bx6zr4.AEC@gabriel.keele.ac.uk> <Bx753E.5qB@cs.uiuc.edu> <1992Nov5.134225.2098@miles.com>
  8. Date: Fri, 6 Nov 1992 03:11:54 GMT
  9. Lines: 33
  10.  
  11. rms@miles.com (Rob Schultz) writes:
  12. >Did you by any chance try to correlate this data to Allan Albrecht's
  13. >Function Points?
  14.  
  15. I did not, though it's on my list of things to do if I ever have the
  16. time to finish analysing the experiment.  (Since the data is almost
  17. two years old already, I wouldn't hold my breath.)
  18.  
  19. Speculation:  a large part of the difficulty/cost of test design is
  20. driven by dependencies.
  21. 1. Dependencies between sections of the code.
  22. 2. Dependencies between areas of the specification.
  23. 3. Dependencies between (for want of a better term) areas in the
  24. "requirements space".
  25.  
  26. If we had perfect code, specifications, and requirements analyses, I
  27. think testing effort would be rather predictable (and pretty
  28. pointless).  But we don't - in fact, a large part of testing is
  29. finding the dependencies that weren't mentioned in any of those
  30. documents.  (That is, finding faults of omission.)
  31.  
  32. There's something unpleasantly circular about using a specification
  33. (or code) to predict the effort needed to find its own omissions --
  34. how different is the estimation effort from the evaluation you're
  35. estimating?  
  36.  
  37. For myself, I use rough-and-ready rules of thumb.  They work well in
  38. practice.
  39.  
  40. Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick, marick@testing.com (pending)
  41. Testing Foundations:  Consulting, Training, Tools.
  42. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  43.  
  44.