Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bbn!cc5.bbn.com!denbeste
From: denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste)
Newsgroups: comp.sys.amiga
Subject: Structured Design (Not a marketing analysis)
Message-ID: <469@cc5.bbn.com.BBN.COM>
Date: Sat, 25-Jul-87 10:01:09 EDT
Article-I.D.: cc5.469
Posted: Sat Jul 25 10:01:09 1987
Date-Received: Sun, 26-Jul-87 01:22:18 EDT
Organization: Bolt Beranek and Newman, Cambridge, MA
Lines: 93


OK - I am a great proponent of structured design around here, and have been
proseletyzing about it anyway, so maybe I am a good person to describe just
what it is.

It starts with three axioms:

1. Everyone makes mistakes.

2. The earlier a bug is found, the cheaper it is to correct.

3. Code is easy. Interfaces are hard.


[It is typically a good test of the professional experience of a person whether
they agree with these three statements. There is a good correlation
between years in the industry and how many of them a person agrees with.]

To answer these problems, three answers respectively:

Answer 1: Everything that anyone does is checked by someone else.

Answer 2: This checking is done as early as possible

Answer 3: Design it completely before you code it.


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.

[Note: At this point, 1/2 of total project time has passed. No code has been
written. Project documentation may fill many notebooks.]

D. CODE AND DEBUG

E. SYSTEM INTEGRATION

F. Q/A


After any document is written, everyone on the project team reads it and makes
comments.

After any code module is written, two other project team members read and make
comments, after the first clean assembly/compile but before debugging begins.

The idea is that most projects get into trouble during the system integration
phase, because at that point they have a lot of code modules which are solid
inside, but don't fit to each other - so some gross hack-stuff is put in
between (sort of like mortar) to make them fit - and it never works perfectly,
and catastrophically fails when you least expect it. (Oh, hi there, mister
Guru!)].

With Structured design, you design the interfaces before you do the insides.

Fundamentally, Structured design is top-down: Worry about the interfaces first
and the internals of the modules later.

The traditional approach is bottom-up: Kick into the code, and worry about how
to fit it together later. The usual objection of a traditional programmer to
Structured design is "I'm a programmer - I'm here to code. Why the hell do you
want me to do all that useless documentation?"

A parallel comparison of the two approaches can make Structured design look
bad part way through: Half way through the project the Structured design team
hasn't written a line of code, while the traditionalists may have 80% of the
code written, and even running somewhat.

By project end, the Structured design team is done, on schedule, with low bug
rate. The traditionalists have overrun their Q/A schedule fourfold and are
still chasing integration problems.



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
three year project of 10 people, it is indispensable. (I know - I was on one.)
The same three year project of 10 people done in the traditional approach will
take 4.5 years...
-- 

     Steven C. Den Beste
     Bolt Beranek & Newman, Cambridge MA
     denbeste@bbn.com  (ARPA or CSNET)