home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3232 < prev    next >
Encoding:
Text File  |  1992-08-16  |  4.1 KB  |  85 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj
  3. From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
  4. Subject: Re: What is Software Engineering
  5. Message-ID: <1992Aug17.061725.10802@sei.cmu.edu>
  6. Sender: netnews@sei.cmu.edu (Netnews)
  7. Organization: Ada Joint Program Office
  8. References: <1992Aug12.065800.14202@sserve.cc.adfa.oz.au> <Bsz991.Knr@cmptrc.lonestar.org> <1992Aug17.013339.27319@sserve.cc.adfa.oz.au>
  9. Date: Mon, 17 Aug 1992 06:17:25 GMT
  10. Lines: 73
  11.  
  12.  
  13. >>Maintenace and development are very distinct.  Maintenance is the effort
  14. >>spent enhancing a product to meet the needs of customers and fixing bugs in
  15. >>an already released product.  These included data corruption, run-time errors
  16. >>implementing new controls, etc...  Development (the development that the
  17. >>figures are based on) is the act of creating a new product to then be put
  18. >>into the maintenance phase.  Classic software engineering stipulates a life
  19. >>cycle of software that reflects a development phase, maintenance, and
  20. >>demise.
  21. >
  22. >And classical geography taught that the Earth was flat.
  23. >
  24. >I would argue with your definitions  -  to me, maintenance involves
  25. >current functionality, development involves new functionality.  Often a
  26. >given piece of work will involve both.  Certainly, if you consider what
  27. >I call "development" as "perfective maintenance" (I've forgotten who
  28. >posted that, but thanks) then yes, it's "maintenance", but it's a
  29. >different sort of maintenance from the "bug-fix" type.
  30. >
  31.  
  32. The  above discussion is  premised  upon a more  classical  (outdated)
  33. software development lifecycle based upon or  similar to the waterfall
  34. model, which has been  shown  over  and  over again  to  be a  totally
  35. innappropriate model of software development reality.
  36.  
  37. Choosing a more  modern process model  like  the  evolotionary  spiral
  38. process  (ESP)  model,  which is a  much  better model of reality, one
  39. considers maintenance no  differently  than  development.   It's  just
  40. another cycle of development.  The term maintenance might only be used
  41. to help get more money from your customer but you would still model it
  42. in the exact same manner as any other development cycle.
  43.  
  44.  
  45. >>Those that create hack programs, force maintenance programmers
  46. >>to write hack fixes and these (one on top of another) cause more time to
  47. >>be spent figuring out and rewritting code just to fix or enhance.
  48. >
  49. >In my environment those who create the systems can expect to maintain
  50. >and develop them, usually working directly with the users.  Self-interest
  51. >is a powerful incentive to do it right.
  52. >>>An engineered approach is more likely to be delivered on time, meet the
  53. >>customers needs, be more easily maintainable/enhanceable, and very probably
  54. >>more robust due to the extensive write-ups and prototyping required before
  55. >>starting a truly engineered software project.
  56. >
  57. >And some projects are so well and thoroughly "engineered" that they are
  58. >obsolete before they are delivered;  perhaps the best example here in
  59. >Australia was the Public Service's "Mandata" system.  I'm talking
  60. >about custom information systems here, not off-the-shelf products or
  61. >even large transaction-oriented systems, both of which present different
  62. >problems.  In my experience the most important part of prototyping is
  63. >to get the users working with the system, hence the need to deliver a
  64. >core system which in turn provides them with some benefit.  As they use
  65. >it, they provide the feedback to drive the development, and (again, in
  66. >my experience) this often opens up lines of development that were not
  67. >originally foreseen.
  68. >
  69. Once again, I  would point you to the ESP process model  and note that
  70. prototyping is  simply  the  early  development  cycles (of  the  REAL
  71. PRODUCT in most cases).  It's all development and it  all needs to  me
  72. modeled and managed in the same manner.
  73.  
  74.  
  75. John Goodsen
  76. EVB Software Engineering
  77. goodsenj@ajpo.sei.cmu.edu
  78. jgg@evb.com
  79.  
  80. -- 
  81. John Goodsen                   (619) 530-0881
  82. The Dalmatian Group            U.S. PCIS Expert Review Team
  83. User Interface Specialists     Ada Joint Program Office
  84. jgg@dalmatian.com              goodsenj@ajpo.sei.cmu.edu
  85.