Re: Changing requiremnts

Re: Changing requiremnts

[Michael D Shapiro]

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)]