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)