× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



        That was a slip of the tongue and what you have described is exactly
what I was talking about.  The first year was all about paper.  Everybody
would sit down and put every piece of information we could think of on
stickies on the wall.  When everyone was tapped out we would start sorting
it into tables and columns (normalization).  Once the databse was completely
designed we would start the same procedures as far as functionality was
concerned.  Any change requirements to the database due to functionality
requirements and you'd start over again.  I just found it interesting that I
had to further my education with a windows course to learn this.  Once again
I'm not saying this isn't being taught at all with RPG.  It just wasn't
taught to anyone in my RPG courses. 

-----Original Message-----
From: PaulMmn [mailto:PaulMmn@xxxxxxxxxxxxx] 
Sent: Tuesday, May 03, 2005 10:17 PM
To: Eric Graeb
Cc: midrange-l@xxxxxxxxxxxx
Subject: RE: MIDRANGE-L Digest, Vol 4, Issue 851

>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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.