home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3177 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  3.3 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!swrinde!cs.utexas.edu!asuvax!ennews!enuxha.eas.asu.edu!kanko
  2. From: kanko@enuxha.eas.asu.edu (Mark Kanko)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: What is Software Engineering
  5. Summary: Yes, Includes Refinements
  6. Message-ID: <1992Aug12.150417.15663@ennews.eas.asu.edu>
  7. Date: 12 Aug 92 15:04:17 GMT
  8. References: <1992Aug3.225335.13213@projtech.com> <1992Aug6.114743@iti.gov.sg> <1992Aug12.065800.14202@sserve.cc.adfa.oz.au>
  9. Sender: news@ennews.eas.asu.edu (USENET News System)
  10. Organization: Arizona State University
  11. Lines: 46
  12.  
  13. >ghm@ccadfa.cc.adfa.oz.au (Geoff Miller) writes:
  14. >
  15. > I don't dispute the figures as such, but I wonder if there's some double
  16. > counting going on.  We're looking at a project at the moment for which
  17. > we estimate the development time of a working core system to be 6 months,
  18. > with at least a further 12 months for refinement and further development.
  19. > Now, is that "maintenance"?  By some definitions it is (since it involves
  20. > fixing problems with existing code), so if you analyse our time on that
  21. > basis it will look as though we're spending a lot of time on maintenance.
  22. > However, is that a problem?  I don't think so, because I don't see 
  23. > maintenance and development as necessarily distinct.  In fact, most of
  24. > our software "maintenance" involves additional functionality or altered
  25. > functionality in response to changing user requirements.
  26.  
  27. I agree with your comments and that is exactly the point:  The issue
  28. is not whether we call a certain effort "development" or "maintenance"
  29. but rather the fact that we don't (usually) build a software system one
  30. time and then never have to touch it again!  That is why it is so important
  31. to design/implement with future maintenance in mind.  One of Lehman's 'Laws of
  32. S/W Evolution' says that any (I'd say most) existing software system 
  33. must either evolve (i.e., be modified for whatever reason) or eventually
  34. become obsolete.
  35.  
  36. I wouldn't call the quoted numbers "double-counted".  Then DO include
  37. the kind of refinement you're talking about.  This is called perfective
  38. maintenance (again, see Pressman book).  Three other kinds are corrective
  39. (to fix bugs or defects), adaptive (to meet changing H/W or data envi-
  40. ronment requirements), and preventive (to enhance future maintainability).
  41.  
  42. Just to put this all in a different light-- Many of the USAF's fighter 
  43. aircraft have been extremely effective in combat.  But when it comes
  44. to maintenance, some of them have been real "bears".  Entire subassemblies
  45. not related to the maintenance task had to be removed in order to get
  46. to the actual maintenance task  (e.g., having to remove the entire ejection
  47. seat so that a battery for the system clock can be replaced).  Well, we
  48. don't build airplanes like that anymore.  Complete Reliability and
  49. Maintainability assessments are done (and redone) on the entire design
  50. before any sheetmetal is bent.  Why?  Because when it comes combat time,
  51. we can't afford a 3-hour turn-around between sorties for a routine
  52. maintenance task.  Are there compromises?  Sure!  But the compromises
  53. are a matter of planned (engineered?) choice, not chance.  
  54.  
  55. I've really appreciated seeing all the viewpoints on this subject.
  56. [I didn't say I agreed with them all!  ;-) ]
  57. --
  58. /*** Mark Kanko   Arizona State University   kanko@asuvax.eas.asu.edu ***/
  59.