home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4393 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.0 KB  |  68 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!csus.edu!netcom.com!mcgregor
  3. From: mcgregor@netcom.com (Scott Mcgregor)
  4. Subject: Re: Software Designs
  5. Message-ID: <1992Nov19.040908.6796@netcom.com>
  6. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  7. References: <1992Nov18.051309.27011@latcs1.lat.oz.au>
  8. Date: Thu, 19 Nov 1992 04:09:08 GMT
  9. Lines: 57
  10.  
  11. In article <1992Nov18.051309.27011@latcs1.lat.oz.au> baragry@latcs1.lat.OZ.AU (Jason M Baragry) writes:
  12.  
  13. >    I would like to be able to analyse some real-life designs and 
  14. >determine some way of representing design knowledge or simply generalize the
  15. >design so it can be understood independantly of the application domain it is
  16. >used in.
  17.  
  18. I sympathize with the desire to have understand things in this way,
  19. but I would caution Jason and others to be careful for what they wish
  20. for. For the most part software exists to solve a problem in an
  21. application domain. Common software horror stories revolve around
  22. inadequate understanding of the application domain by the developers.
  23. In such situations, methodologies and techniques that help you do the
  24. application domain independent stuff, i.e. "doing things right" (as
  25. opposed to "doing the right things" the application domain specific
  26. part) just ensure that you skewer your jet plane into the ground more
  27. surely and swiftly. The needs of the application domain MUST impinge
  28. and affect the development if the project is to achieve the desired
  29. results.  Analysis of information that strips out this crucial
  30. dependency may undermine the very assumption of independence which
  31. would be the basis for any extrapolations or conclusions when you try
  32. tor apply the results. 
  33.  
  34. I found this same situation in the CoCoMo prediction models.  The
  35. predictive power of the CoCoMo model is based upon the assumption that
  36. project durations are independent of each other, and that the major
  37. determinants of duration are organizationally independent: complexity,
  38. amount of functionality, etc.  But in the project databases I have
  39. looked at this assumption is easy to disprove.  In fact, the duration
  40. of the previous projects done by the individuals, or authorized by the
  41. management usually has significantly more explanatory power and thus
  42. yields better predictive estimates.  A lot of people don't like the
  43. fact that this is so.  They WANT models that are more dependent on
  44. things like complexity than on organizational or individual
  45. history--so they still prefer CoCoMo despite real evidence questioning its
  46. base assumptions.  
  47.  
  48. This is the same danger that an application domain independent
  49. analysis of methods may have: it may ignore the most significant
  50. contributor to success or failure.  I don't know that it will, but
  51. given the CoCoMo case, I would suggest that this be carefully
  52. scruitinized, and not just assumed.
  53.  
  54. I'd be very interested in the results whatever turns out.
  55.  
  56.  
  57.  
  58. -- 
  59.  
  60. Scott L. McGregor        mcgregor@netcom.com
  61. President            tel: 408-985-1824
  62. Prescient Software, Inc.    fax: 408-985-1936
  63. 3494 Yuba Avenue
  64. San Jose, CA 95117-2967
  65.  
  66.  
  67.  
  68.