Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,comp.client-server
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!in2.uu.net!projtech!daemon
From: steve@projtech.com
Subject: Re: SCRUM and Why the Waterfall Methodology is a Fool's Errand ... 
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <NEWTNews.817067535.430.steve@sallys.projtech.com>
Lines: 172
Sender: daemon@projtech.com
Nntp-Posting-Host: sallys
Organization: Project Technology, Inc.
X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage
References: <30AF370B.1AE@vmark.com> <jzqcvc@bmtech.demon.co.uk> <48spd4$s30@ixnews4.ix.netcom.com>  <30B34179.66AF@oma.com> 
Mime-Version: 1.0
Date: Wed, 22 Nov 1995 15:29:38 GMT
Xref: glinda.oz.cs.cmu.edu comp.object:41137 comp.lang.smalltalk:30954 comp.lang.c++:161373 comp.client-server:14037


In article <30B34179.66AF@oma.com>, <rmartin@oma.com> writes:
> Kent Beck wrote:
> > In <jzqcvc@bmtech.demon.co.uk> <scottw@bmtech.demon.co.uk> writes:
> > >In Article <30AF370B.1AE@vmark.com> Jeff Sutherland  writes:
> > >>... the Waterfall Methodology is fatally
> > >>flawed and doomed to failure....
> > >
> > >Is this news? I was under the impression that this had been generally
> > >accepted for at least 20 years.
> > 
> > Then why do some of my clients (at least initially) think that
> > "iterative development" means "an iteration for analysis, an iteration
> > for design, ..."? Most development organizations still prefer a
> > pile-of-paper-based illusion of control to active management of
> > development risk.
> 
> Indeed, a major methodologist appears to have the same idea, 
> Steve Mellor recently said the following in an article in which he
> answering Booch with respect to the differences between their methods.
> 
> "If you picture the system as a box with the application at the
>  top, divided into subsystems across the top, and the implementation
>  at the bottom, then I see you taking slices vertically (ie each slice
>  covers a piece from top to bottom), and Shlaer-Mellor partitioning
>  the project horizontally."

In another thread, Mr Martin asserts more clearly his incorrect belief
that Shlaer-Mellor proposes a waterfall model.  I quote the post below:

In article <1995Nov21.091941.19800@oma.com>, rmartin@oma.com says...
> Horizontal slicing is essentially the waterfall model, and its
> products are difficult to test for accuracy, robustness or
> completeness.

And I believed (incorrectly, it seems) that the following
post from Paul Johnson effectively despatched Robert's argument: 

In article <48sehk$r05@miranda.gmrc.gecm.com>,<paul.johnson@gecm.com> writes:
> Not neccessarily.  You can regard each layer in the system as an
> application in itself: it offers services at its top interface, and
> uses services from the interface below it.  You can partition the
> system into layers and write the specification for the upper interface
> of each layer (i.e. the services which each layer provides).  This is
> the requirements document for that service.
> 
> If you do this well, you get a nice, reusable library at each layer.

Paul's text above is indeed how we view it: The first step in the 
Shlaer-Mellor method is to identify the layers, by identifying 
subject matters (we call them problem domains), and depicting
the dependencies between the layers in a "domain chart".

Then we analyze each domain (each layer) independently of one another.

Unlike Paul Johnson, we do not define the interface for each layer
at this step, so we cannot regard that (non-existent) interface as
the requirements document.  Instead, we investigate the dependencies
between the domains, and the results of that investigation
become the requirements document.  In other words, the requirements
on a domain X exist because another domain, Y, depends on X,
and so Y assumes that X will provide certain services. 

Example:  Consider a Railroad management system with several domains
including the railroad management application domain and the user
interface domain.  The RR application depends on the existence
of the UI domain, but the UI domain can exist without RailRoads.

What are the dependencies?  Consider the following:
* We (the buyers of this system) want icons 
* Must use shape as well as color (for colour-blind operators)
* Need a schematic rendition of  the "real world", not a geographically
  accurate rendition
* Need to be able to display up to 100 entities with resolution
  over 2000 positions at once
  [the problem here is that the track is divided into 2000 blocks
   and there are 100 trains, and I need to be sure two trains
   are not in the same position at the same time]
* Need to be able to display 2*1000*100 state changes per hour
  [trains moving at 60mph over 60 miles of track with 1000
   blocks in each direction, each block will be turned on and 
   off once as a train passes through]
* Need to be accurate to with 3/4 sec from a change in the world
  to intelligible display
* Must prohibit occlusion of any live data
* blah blah

Three issues here: (1) I can state these requirements _without_
ever mentioning trains.  (I did add in [ ] text with train
words for clarity to you, the reader.)  This means that
I do not need to have an understanding of the _semantics_ of the 
railroad domain in order to understand the UI.  

(2) I do need a quantitative understanding of the RR application
domain to make explicit the performance requirements on the UI
domain.  The Shlaer-Mellor method provides the framework
for eliciting these performance requirements.  That framework extends
to cover behavioral requirements ("don't occlude", "we want icons")
that exist because of the _nature_ of railroad management, as opposed
to the detailed semantics. 

And (3), I can analyze the application and the UI domains 
__concurrently__ because the abstractions in each domain
are independednt of one another. 

I  conclude from the above paragraphs that I can work on the layers 
concurrently and independently of the detailed semantics
of either domain.  To me, this is NOT a waterfall approach.

I believe the confusion comes about because of the use of the words 
"analysis" and "design", as in "an iteration for analysis, an 
iteration for design".  In Shlaer-Mellor, the software architecture 
(the system design, if you prefer) is treated as a separate domain, 
just like the UI, so I can follow exactly the same process that
I described above.  That is, I can understand the subject matter of 
system design using analysis techniques.  In the (approximately quoted) 
words of the "Ovum report on Shlaer-Mellor" by Henk Bekker and 
Mark Stevenson, "The notion that designers exist only as subjects 
for analysis is startling."  But that is what we are suggesting.

This implies that the system developer iterates on the analysis
of the application, on the analysis of the UI, and on the analysis
of the system design, each separately and concurrently.
But that ain't no waterfall.

As an example of the dependencies between the application and the
software architecture, take a look at the following, which parallels-- 
in concept--the list of requirements we built for the UI:

* Must support geographical distrubution over 60 miles.
* Must support (2*1000*100 + xx*yy + aa*zz) state changes/hour
  [state changes for train movement + electrification + ....]
* Events that cause state changes are asychronous and (mostly) independent
* Events may occur in bursts, especially when something goes wrong.
  The worst case we have identified so far is 100 changes/sec
* There is a case where the events are not independent.
  We estimate recomputation of 20 elements per event, on average,
  100 worst case.
  [The case here is electrification.  When a breaker changes state,
  it causes the electrical network's configuration to change and
  we would have to recompute the state of each network element
  that is not directly readable.]
* We need to store XX*yy + ZZ*aa + ... elements for access within
  zz milliseconds and qq*ww*zz elements ....
* blah blah

Note again that there is no need to understand the detailed semantics
of train control, train scheduling, electrification, etc etc.
What you do need to understand are the ways in which the 
application domain depends on the software architecture.
Therefore the application analysis and the system design
(software architecture analysis) can proceed concurrently
and (relatively) independently.  This is just NOT a waterfall.

I quote again the last three lines of the original post:
> >    ...........  Most development organizations still prefer a
> > pile-of-paper-based illusion of control to active management of
> > development risk.

I suggest that a process that:

1. Identifies the domains (layers) in the system, as the first step
2. Immediately moves to understand (and document) the dependencies 
   between the domains
3. Analyzes each domain separately and (relatively) independently

is taking on active management of development risk, through explicit
management of the dependencies between the layers. Further, we
begin this very early on in the development process.  Finally I say
for one last time, that such a process is not a waterfall.

-- steve mellor
   


