From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cba39a866a8e751e,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1993-03-24 00:03:47 PST
Path: 
 sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!ucbvax!MANTA.NOSC.MIL!mshapiro
From: mshapiro@MANTA.NOSC.MIL (Michael D Shapiro)
Newsgroups: comp.lang.ada
Subject: Re: Changing requiremnts
Message-ID: <9303231803.AA23469@manta.nosc.mil>
Date: 23 Mar 93 18:03:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The Internet
Date: 1993-03-23T18:03:48+00:00
List-Id: <comp.lang.ada>

In <1993Mar15.183357.8322@intellistor.com>
wicklund@ucbvax.Berkeley.EDU  (Tom Wicklund) writes:

> In <1993Mar11.204931.7349@mksol.dseg.ti.com> 
> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
> 
> >In <335@fedfil.UUCP> news@fedfil.UUCP (news) writes:
> 
> >>   [..description of design change requirements, midstream] "Over two
> >>   years, there were close to 600 such changes."
> >> 
> >>[..comments about requirements constantly changing in the "real world"]
> 
> >Again, this has nothing to do with language.  If the customer declines
> >to freeze the requirements, you're going to take it in the neck no
> >matter *what* language you are using.  The real failure here was that
> [... continuing discussion on the subject deleted]
> 
> Actually, I think this shows a problem with the software engineering
> discipline as currently envisioned.  We try to make projects fit into
> a "waterfall" model of requirements --> design --> development and
> penalize changes in requirements.
> 
> All engineering projects undergo changes in requirements in mid
> stream.  Software seems to get more than its share, partially from its
> increased complexity and partially because it's easier to argue
> against a hardware change when you explain (and measure in terms of
> hardware build times) that it will take 3 months and scrap the
> existing $1,000,000 in prototype hardware.  Software is harder to
> measure and perceived as easier to change.

Perhaps we're thinking about these problems in the wrong way.
As I point out in my article in the September 1992 IEEE
_Computer_ magazine titled "Software is a product ... NOT!", we
should do a better job of planning, building, and using software
if we think of it as a service.  I believe that the software
engineers would do the same activities.  But management and
customers could better understand the process (for budget,
usefulness, and schedule purposes) if they treated software as a
continuing service rather than as a product that needs continual
"maintenance" over its life.

Amazingly, since Ada really seems destined for projects which
_must_ be "maintained" over many generations of personnel, it
seems a reasonable software service language.

(If you want to read the article but can't find a copy of it,
let me know by email and I may be able to help.)

================================================================
Michael D. Shapiro, Ph.D.              e-mail: mshapiro@nosc.mil
NCCOSC RDT&E Division (NRaD) Code 411    San Diego CA 92152-7560
Voice: (619) 553-4080     FAX: (619) 553-4808      DSN: 553-4080
 [Until January 1992 we were Naval Ocean Systems Center (NOSC)]