From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
Subject: Re: What is Software Engineering
Organization: Ada Joint Program Office
Date: Mon, 17 Aug 1992 06:17:25 GMT


>>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.
>
>And classical geography taught that the Earth was flat.
>
>I would argue with your definitions  -  to me, maintenance involves
>current functionality, development involves new functionality.  Often a
>given piece of work will involve both.  Certainly, if you consider what
>I call "development" as "perfective maintenance" (I've forgotten who
>posted that, but thanks) then yes, it's "maintenance", but it's a
>different sort of maintenance from the "bug-fix" type.
>

The  above discussion is  premised  upon a more  classical  (outdated)
software development lifecycle based upon or  similar to the waterfall
model, which has been  shown  over  and  over again  to  be a  totally
innappropriate model of software development reality.

Choosing a more  modern process model  like  the  evolotionary  spiral
process  (ESP)  model,  which is a  much  better model of reality, one
considers maintenance no  differently  than  development.   It's  just
another cycle of development.  The term maintenance might only be used
to help get more money from your customer but you would still model it
in the exact same manner as any other development cycle.


>>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.
>
>In my environment those who create the systems can expect to maintain
>and develop them, usually working directly with the users.  Self-interest
>is a powerful incentive to do it right.
>>>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.
>
>And some projects are so well and thoroughly "engineered" that they are
>obsolete before they are delivered;  perhaps the best example here in
>Australia was the Public Service's "Mandata" system.  I'm talking
>about custom information systems here, not off-the-shelf products or
>even large transaction-oriented systems, both of which present different
>problems.  In my experience the most important part of prototyping is
>to get the users working with the system, hence the need to deliver a
>core system which in turn provides them with some benefit.  As they use
>it, they provide the feedback to drive the development, and (again, in
>my experience) this often opens up lines of development that were not
>originally foreseen.
>
Once again, I  would point you to the ESP process model  and note that
prototyping is  simply  the  early  development  cycles (of  the  REAL
PRODUCT in most cases).  It's all development and it  all needs to  me
modeled and managed in the same manner.


John Goodsen
EVB Software Engineering
goodsenj@ajpo.sei.cmu.edu
jgg@evb.com

-- 
John Goodsen                   (619) 530-0881
The Dalmatian Group            U.S. PCIS Expert Review Team
User Interface Specialists     Ada Joint Program Office
jgg@dalmatian.com              goodsenj@ajpo.sei.cmu.edu
Newsgroups: comp.software-eng