|
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 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.