home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3216 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.8 KB  |  51 lines

  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!ernest!cmptrc!musa
  3. From: musa@cmptrc.lonestar.org (Jeff Musa)
  4. Subject: Re: What is Software Engineering
  5. Message-ID: <Bsz991.Knr@cmptrc.lonestar.org>
  6. Date: Fri, 14 Aug 1992 14:22:12 GMT
  7. References: <adams.713466914@fanaraaken.Stanford.EDU> <1992Aug11.230629.6592@ennews.eas.asu.edu> <1992Aug12.065800.14202@sserve.cc.adfa.oz.au>
  8. Organization: CompuTrac Inc., Richardson TX
  9. Lines: 40
  10.  
  11. In article <1992Aug12.065800.14202@sserve.cc.adfa.oz.au> ghm@ccadfa.cc.adfa.oz.au (Geoff Miller) writes:
  12. >
  13. >I don't dispute the figures as such, but I wonder if there's some double
  14. >counting going on.  We're looking at a project at the moment for which
  15. >we estimate the development time of a working core system to be 6 months,
  16. >with at least a further 12 months for refinement and further development.
  17. >Now, is that "maintenance"?  By some definitions it is (since it involves
  18. >fixing problems with existing code), so if you analyse our time on that
  19. >basis it will look as though we're spending a lot of time on maintenance.
  20. >However, is that a problem?  I don't think so, because I don't see 
  21. >maintenance and development as necessarily distinct.  In fact, most of
  22. >our software "maintenance" involves additional functionality or altered
  23. >functionality in response to changing user requirements.
  24. >
  25. Maintenace and development are very distinct.  Maintenance is the effort 
  26. spent enhancing a product to meet the needs of customers and fixing bugs in
  27. an already released product.  These included data corruption, run-time errors
  28. implementing new controls, etc...  Development (the development that the     
  29. figures are based on) is the act of creating a new product to then be put
  30. into the maintenance phase.  Classic software engineering stipulates a life
  31. cycle of software that reflects a development phase, maintenance, and
  32. demise. 
  33.  
  34. Those that create hack programs, force maintenance programmers
  35. to write hack fixes and these (one on top of another) cause more time to 
  36. be spent figuring out and rewritting code just to fix or enhance.  An  
  37. engineered approach is more likely to be delivered on time, meet the 
  38. customers needs, be more easily maintainable/enhanceable, and very probably
  39. more robust due to the extensive write-ups and prototyping required before
  40. starting a truly engineered software project.
  41.  
  42. One possible difference in semantics should be pointed out, if you are 
  43. developing shrink wrapped software versus software systems, "development"
  44. probably would encompass enhancements to this existing product.
  45.     
  46. ---
  47. Jeff Musa  (musa@cmptrc.lonestar.org)        | "These opinions are my own
  48. CompuTrac Inc.       (214) 235 - 7161 #3810  |  and do not necessarily         
  49. 222 Municiple Drive                          |  reflect those of my employer"
  50. Richardson, TX  75080
  51.