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