Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!mtxinu!unisoft!hoptoad!hsfmsh!dumbcat!marc
From: marc@dumbcat.UUCP (Marco S Hyman)
Newsgroups: comp.object
Subject: Re: Object-Oriented Requirements Analysis: An Introduction
Summary: Growing a system
Message-ID: <132@dumbcat.UUCP>
Date: 10 Dec 89 21:37:23 GMT
References: <628@ajpo.sei.cmu.edu> <DWIGGINS.89Dec4143109@atsun.a-t.com>
Reply-To: marc@dumbcat.UUCP (Marco S Hyman)
Organization: MH Software, Hayward, Ca.
Lines: 43

In article <DWIGGINS.89Dec4143109@atsun.a-t.com> dwiggins@atsun.a-t.com (Don Dwiggins) writes:
    In article <628@ajpo.sei.cmu.edu> eberard (Edward Berard) writes:
       development part of the object-oriented life-cycle is best
       accomplished using a recursive/parallel approach, i.e., "analyze a
       little, design a little, implement a little, and test a little."
    
    I must admit that the name leaves me a "little" uneasy
    (:-); read naively, there doesn't seem to be much structure to it.  How does
    one know when to do which, and when to stop and do something else?  How is
    progress to be measured in this model?  etc...
    
Let me turn things around a bit.  With any large project, large being more
than one calendar year, the analyze -> design -> implement -> test
structure eventually delivers code that can be a year or more out of date.
While the programmers were doing the design -> implement -> test phases of
the project the requirements may have changed.

As to when it's time to change phases: I prefer to do it as soon as possible.
That is, as soon as an outline of the requirement are done a *prototype*
design is started.  The design will, of course, point out areas where the
requirements have to be modified or added to. Once a design is sketched out
it's time to do a *prototype* implementation.  Of course, the implementation
will point out shortcoming of the design.  As soon as there is something
to show the end user the better.  Until a prototype of the product gets in
to the end users hands feedback loop isn't complete (my opinion).  I don't
see test as a separate step.  Call it validation.  The design validates the
requirements, the implementation validates the design and the user ultimately
validates the implementation.  Programmers test their code as it is
written.

By bringing the ultimate user into the process as soon a as possible the
chances of delivering a usable program/system are much improved.  I think
this is what Brooks called 'growing a program' in his _No Silver Bullet_
article.  When developing a generic product the hard part is finding the
appropriate user surrogate.  

None of this has much to do with objects or OO anything.  Every successful
large project I've worked on has used this method.  (You can easily tell if
this method is used:  The requirements document isn't signed off until just
before the product ships.)  But: it's no panacea.  Not every large project
I've worked on using this method has been successful.
-- 
// marc				{ames,pyramid,sun}!pacbell!dumbcat!marc