Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!usenet.ins.cwru.edu!abvax!iccgcc!kambic
From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.)
Newsgroups: comp.software-eng
Subject: Re: Art vs. Engineering
Message-ID: <4637.28380639@iccgcc.decnet.ab.com>
Date: 20 May 91 22:24:09 GMT
Article-I.D.: iccgcc.4637.28380639
References: <1991May6.165902.2116@ssd.kodak.com> <35177@athertn.Atherton.COM> <1991May9.155632.29277@mcs.kent.edu> <4565.282e85bd@iccgcc.decnet.ab.com> <1991May13.185411.7253@netcom.COM>
Distribution: usa
Lines: 19

In article <1991May13.185411.7253@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
[...]
> Indeed, and the sad thing is that traditional methodologies completely ignore
> this simple reality--the classic "waterfall" model of software development
> assumes what I call a "top-down omniscient" process, which would work great
> if we could just find some omniscient engineers. In reality, either feedback
> is accomodated in an ad hoc manner during development (with consequent penalties
> in terms of efficiency, since the process is not explicitly set up to plan
> for such feedback) or, as is often the case, feedback is folded in during the
> inappropriately named "maintenance" phase.
[..good stuff omitted to focus on waterfall for the moment..]
OK - next comment.  IMHO all "life cycles" contain the waterfall model at
their most microscopic level: one engineer, one problem, short time scale
(minutes), good knowledge base, etc.  All other life cycles are constructed of
the waterfall + feedback with varied deliverables at different time scales.  


GXKambic
standard disclaimer