home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / software / 2926 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.3 KB
  1. Xref: sparky comp.software-eng:2926 comp.object:2980
  2. Path: sparky!uunet!cs.utexas.edu!usc!hacgate!valkris!hayes
  3. From: hayes@valkris.aero.org (Brian Hayes 74-35 x65129)
  4. Newsgroups: comp.software-eng,comp.object
  5. Subject: Re: Software costs revisited?
  6. Message-ID: <22493@hacgate.SCG.HAC.COM>
  7. Date: 21 Jul 92 17:12:29 GMT
  8. References: <1992Jul20.120345.26472@cs.tu-berlin.de>
  9. Sender: news@hacgate.SCG.HAC.COM
  10. Followup-To: hayes@hac2arpa.hac.com
  11. Organization: Hughes Aircraft Company, EDSG
  12. Lines: 39
  13.  
  14. In article <1992Jul20.120345.26472@cs.tu-berlin.de> gregor@cs.tu-berlin.de (Gregor Engelmeier) writes:
  15. >In Brad Cox's book: "Object Oriented Programming" from 1986, he
  16. >quotes an inquiery carried through by the U.S. Goverment Accounting
  17. >Office in 1979, in wich a breakdown of software costs versus actual
  18. >results is performed (FGMSD-80-4). The results at that time were:
  19. > 
  20. ...
  21. >This was meant to be a motive the introduction of object oriented 
  22. >techniques in the production of complex software systems.
  23.  
  24. It is always interesting to read about motivation for using OO.  I'm
  25. currently reading Booch's "Object-Oriented Design With Applications"
  26. (1991) and his stated motivation for OO is that previous/other methods 
  27. have failed to master complexity (with regard to "industrial strength
  28. software") which leads to the software crisis were a project is "late,
  29. overbudget and deficient in their stated requirements."
  30.  
  31. I am new to OO, so forgive my ignorance, but, IMHO:  These motivations
  32. are not good enough to justify using OO.  I believe that functional 
  33. oriented analysis and design is as good as OOA and OOD if not better.
  34. The problem in the past (and currently) is that few people/projects
  35. apply a rigorous life-cycle methodology when producing systems.  One 
  36. problem, of course is that there are few methodolgies that are 
  37. rigorous enough (appoligies to Hatley-Pirbahi method, ADARTS, and 
  38. other similar methods and methodologies who fall short of being 
  39. rigorous).
  40.  
  41. As I investage and analyze the OO paradigm, I will be attempting to 
  42. find answers to the following questions:
  43. Are the OO methodologies rigorous enough? 
  44. When I complete my OOA phase, can I be assured that the system will 
  45. work and meet requirements?
  46. When I complete the OOD phase, can I be assured that the system 
  47. will work and will meet requirements?
  48.  
  49. ---
  50.  
  51. -- 
  52. *** Brian Hayes hayes@hac2arpa.hac.com (310) 616-5129 ***
  53.