home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4426 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  1.6 KB
  1. Path: sparky!uunet!icd.ab.com!iccgcc.decnet.ab.com!kambic
  2. From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Software Designs
  5. Message-ID: <1992Nov20.100555.9317@iccgcc.decnet.ab.com>
  6. Date: 20 Nov 92 10:05:55 EST
  7. References: <1992Nov18.051309.27011@latcs1.lat.oz.au> <1992Nov19.040908.6796@netcom.com>
  8. Lines: 24
  9.  
  10. In article <1992Nov19.040908.6796@netcom.com>, mcgregor@netcom.com (Scott Mcgregor) writes:
  11. [...]
  12.  But in the project databases I have
  13. > looked at this assumption is easy to disprove.  In fact, the duration
  14. > of the previous projects done by the individuals, or authorized by the
  15. > management usually has significantly more explanatory power and thus
  16. > yields better predictive estimates.  A lot of people don't like the
  17. > fact that this is so.  They WANT models that are more dependent on
  18. > things like complexity than on organizational or individual
  19. > history--so they still prefer CoCoMo despite real evidence questioning its
  20. > base assumptions.  
  21. I are confused'.  The largest single factor in the COCOMO (different spelling?
  22. - no wonder) is the personnel and team capability.  It seems that COCOMO agrees
  23. with you rather than disagrees.  Is there something different about the
  24. calibrated databses that you have looked?  COCOMO does nothing for you unless
  25. it is used for a while, calibrated, and improved.
  26.  
  27. BTW, I agree with your point about application domains.  Software must retain 
  28. the real world in its requirements.  What we do it real, and impacts people (
  29. and sometimes the ground!).
  30.  
  31. George Kambic
  32. sd
  33.  
  34.