Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!husc4!hadeishi
From: hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi)
Newsgroups: comp.sys.amiga
Subject: Re: Structured Design (Not a marketing analysis)
Message-ID: <2615@husc6.UUCP>
Date: Thu, 30-Jul-87 18:38:44 EDT
Article-I.D.: husc6.2615
Posted: Thu Jul 30 18:38:44 1987
Date-Received: Sat, 1-Aug-87 11:01:32 EDT
References: <469@cc5.bbn.com.BBN.COM>
Sender: news@husc6.UUCP
Reply-To: hadeishi@husc4.UUCP (mitsuharu hadeishi)
Organization: Harvard Univ. Science Center
Lines: 39
Summary: Elements useful even for one person

In article <469@cc5.bbn.com.BBN.COM> denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste) writes:
>The stages of the project using structured design are as follows:
>
>A. SPECIFICATION: Write the user manual FIRST!! [I'm not kidding! Figure
>   out what you are going to do before you start working on any of it! Not
>   doing this is THE classic novice's mistake.]
>
>B. ARCHITECTURE: Figure out the functional breakdown and DOCUMENT IT.
>
>C. DETAILED DESIGN: FIgure out precisely what every module and data structure
>   is and DOCUMENT IT.

	B. should be expounded upon somewhat.  A common mistake is to
design the data structures before you have designed the logical structure
of the program.  The data structures should ALWAYS BE DESIGNED LAST.
Another way of putting this is "form should follow function," i.e.,
the form of the data should follow the design of the functionality.
A good way to work on this is to generate rough outlines of the code
in psuedocode, and only at the last possible moment design the details
of the data structures.  At that point it should be clear what the
optimal data structure design should be, since it will follow from the
logical structure of the program.  Psuedocoding should precede data
structure design which should precede the final stage of actual coding.
If this procedure is followed it should be possible to write
program modules that are clean, properly documented, and bug-free.
(Yes, BUG-FREE.)

>Understand, this is an extremely brief description of the technique. Also
>understand that as projects get smaller the benefits of the technique get
>less. For a 1-month project with one person, most of it can be skipped. For a

	The essential principles of structured design are still important
and very beneficial even when only one person is involved (although
of course peer review cannot occur.)  In particular the idea of
writing documentation and designing data structures last, after
psuedocoding, is of immense use and if applied rigorously can lead to
wholly bug-free programs, even on the first run.

				-Mitsu