RE: MIDRANGE-L Digest, Vol 4, Issue 851 -- MIDRANGE-L

When I took VB the first thing they taught was Microsoft's Lifecycle...
...they teach that you don't start coding until the entire database is
completely built.  That's how you get a normalized database.

I think it's interesting that you speak of 'building' a database, not 'designing' one. (:

The whole issue is that all too often there is no design done at all-- it's the old "grab the coding sheets and if you haven't designed things by the time you're back to your desk" you're not a -real- programmer!

I was part of a project that redesigned an order entry / invoicing / inventory control system from scratch.

The early stage was totally informal and was more of an "If I could do it all over again" kind of dreaming. We started by papering a wall in the programmer's area. We divided the paper into sections for each major part of our existing application. For about a year (he says, looking back over 20 years) we wrote notes about stupid things we'd never do again, or nifty things we wanted to include, and stuck them to the wall. [things like "All numeric fields will be an odd number of digits, a minimum of 13.5"]

When we had a wall full of stickies I think it dawned on the upper management that we had some good ideas. We also had some serious problems with the existing systems, so we were given the go ahead to design a new system.

We started bydrawing a data flow diagram of the entire existing system following Gane and Sarson's methodology. We fed the diagram by interviewing everyone in the company who touched an order. We tracked each copy of a packing set ("We file this copy in this drawer. Why? Because I was told to.") The diagram grew and flourished.

Once we finished the 'as is' diagram, we started 'improving' things-- the duplications were removed, the missing things we'd created on stickies were added. Some layers of the diagram were overlaid with several layers of fresh paper as we redesigned sections of the processes.

While there are other methodologies, I like G&S (mainly because I've read the book and used it at least that once) because you aren't designing a computer system, you're designing a process. It won't matter if it's implemented on index cards in a file, or bits in a computer.

I think the biggest roadblock to using a design methodology is that the up front work takes time! We took (guessing here) close to a year before we started coding--- gee! Isn't that what Microsoft is teaching???

-0--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx