home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3231 < prev    next >
Encoding:
Text File  |  1992-08-16  |  3.3 KB  |  67 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!munnari.oz.au!manuel!sserve!ccadfa.cc.adfa.oz.au!ghm
  3. From: ghm@ccadfa.cc.adfa.oz.au (Geoff Miller)
  4. Subject: Re: What is Software Engineering
  5. Message-ID: <1992Aug17.013339.27319@sserve.cc.adfa.oz.au>
  6. Sender: news@sserve.cc.adfa.oz.au
  7. Organization: Australian Defence Force Academy, Canberra, Australia
  8. References: <adams.713466914@fanaraaken.Stanford.EDU> <1992Aug11.230629.6592@ennews.eas.asu.edu> <1992Aug12.065800.14202@sserve.cc.adfa.oz.au> <Bsz991.Knr@cmptrc.lonestar.org>
  9. Date: Mon, 17 Aug 1992 01:33:39 GMT
  10. Lines: 55
  11.  
  12. musa@cmptrc.lonestar.org (Jeff Musa) writes:
  13.  
  14. >Maintenace and development are very distinct.  Maintenance is the effort 
  15. >spent enhancing a product to meet the needs of customers and fixing bugs in
  16. >an already released product.  These included data corruption, run-time errors
  17. >implementing new controls, etc...  Development (the development that the     
  18. >figures are based on) is the act of creating a new product to then be put
  19. >into the maintenance phase.  Classic software engineering stipulates a life
  20. >cycle of software that reflects a development phase, maintenance, and
  21. >demise. 
  22.  
  23. And classical geography taught that the Earth was flat.
  24.  
  25. I would argue with your definitions  -  to me, maintenance involves
  26. current functionality, development involves new functionality.  Often a
  27. given piece of work will involve both.  Certainly, if you consider what
  28. I call "development" as "perfective maintenance" (I've forgotten who
  29. posted that, but thanks) then yes, it's "maintenance", but it's a
  30. different sort of maintenance from the "bug-fix" type.
  31.  
  32. >Those that create hack programs, force maintenance programmers
  33. >to write hack fixes and these (one on top of another) cause more time to 
  34. >be spent figuring out and rewritting code just to fix or enhance.
  35.  
  36. In my environment those who create the systems can expect to maintain
  37. and develop them, usually working directly with the users.  Self-interest
  38. is a powerful incentive to do it right.
  39.  
  40. >An engineered approach is more likely to be delivered on time, meet the 
  41. >customers needs, be more easily maintainable/enhanceable, and very probably
  42. >more robust due to the extensive write-ups and prototyping required before
  43. >starting a truly engineered software project.
  44.  
  45. And some projects are so well and thoroughly "engineered" that they are
  46. obsolete before they are delivered;  perhaps the best example here in 
  47. Australia was the Public Service's "Mandata" system.  I'm talking
  48. about custom information systems here, not off-the-shelf products or
  49. even large transaction-oriented systems, both of which present different
  50. problems.  In my experience the most important part of prototyping is
  51. to get the users working with the system, hence the need to deliver a
  52. core system which in turn provides them with some benefit.  As they use
  53. it, they provide the feedback to drive the development, and (again, in
  54. my experience) this often opens up lines of development that were not
  55. originally foreseen.
  56.  
  57. This, to my mind, brings up the major difference between software
  58. engineering and the sort of engineering that results in bridges, cars
  59. or TVs  -  that we are designing a product which will be developed
  60. while it is in use, whereas in other forms of engineering it is the
  61. replacement product which is being developed.
  62.  
  63. Geoff Miller  (g-miller@adfa.oz.au)
  64. Computer Centre, Australian Defence Force Academy
  65.  
  66.  
  67.