best practices (1 Viewer)

[dreamdelerium]

hey everyone. i was wondering if anyone can help me out. ill be starting a larger project in a few months and was wondering if anyone had any good articles i could read. im looking for:
1. something about database design. this project could concievable be used on a very large scale. i want to make sure that the way ive been doing it is right.
2. creating user friendly/intuitive design. im creating software for a polulation of people who have very little experience with computers and software
3. planning out software. i find that alot of time is spent going back and correcting issues that were not accounted for earlier on in the planning stages. i might also be working with other people. measure 6 times, cut once philosophy
thanks
jason

 

[Rabbie]

Hi Jason

This link will give you an overview of database design.

There have been some very good posts on this topic on this forum so do a search. The ones from The_Doc_Man are very good IMHO. basically you want to work out your design with pencil and paper or even Whiteboard and Memo notes so you can change things easily. The more work you can put into the design before you build your DB the better.

 

[David Eagar]

Spend a LOT of time establishing what your database intends to be. Get exactly what users need / would like and what they expect to be able to do.

I have found a lot of these projects start out as one thing and end up as another, which is not necesarily a bad thing, just as users become familiar with it, the 'it would be nice if...' requests start flooding in.

Try and design it in the most efficient manner as possible, not so that it 'replicates' existing spreadsheets etc

 

[The_Doc_Man]

The viewpoint for any major design issue is to take two things:

1. A list of the data you know you will have.

2. A list of the things you must produce (reports, forms, historical reports, maintenance menus, etc. etc.)

Then one requirement at a time, map out how you would get from #1 to #2.

At some points in your process, you will probably find that you need something not in #1 in order to product something in #2. Then you have the question of adding to #1 or subtracting from #2 so that ability and desire remain synchronized.

Simple-minded example: You have a requirement for a report on some actions ordered by the date in which they were done, a "timeline" so to speak. This implies that in your table of things that were done, you must include the date - so that the sort order can be supported.

Now multiply that example by the number of requirements and the number of fields you think you have and double the result. That's how many factors you must consider. You will revisit a lot of things several times each. A few things will be so obvious that you won't need to revisit them. It's always a mix-and-match about revisitation.

 

[Pat Hartman]

Rabbie, your link doesn't work.

 

[Rabbie]

Rabbie, your link doesn't work.

It isn't at the moment. It was working when I posted it. I think that site must be having problems just now.

 

[dreamdelerium]

thanks guys for all your tips

 

[Rabbie]

Glad to say the link now seems to working again. Seems to have been a problem with that site

 

[gemma-the-husky]

a real issue, though, is that users often dont really know what - or maybe another way of looking at it, is that they assume the developer knows what they want.

therefore there are often little design errors which arose out of incomplete explanations -which can make it impossible or extremely difficult for users to use in the way that they need - this is often concerned with uncommon situations that still have to be handled eg special discounts for one customer - special pay arrangements for certain employees

so in big systems, it really is important that the developer REALLY REALLY understands what the clients/users want and need - not in terms of functionality, but in terms of data analaysis and structure - if the data is in there, normalised properly, its easy to use - if its not in there, or not normalised, its real hard. One way of doing this (although it can both put the cost up and slow down development) is to document the design, and get it signed off - that way any subsequent design errors can be clearly traced.

Bear in mind also that there are also so many serendipiitous benefits from access -eg cut and paste into excel, printing forms, saving forms as spreadsheets etc, and stuff like that, that users find ways of using your stuff that you never thought of, or intended - or even realised they COULD do

 

[neileg]

Just to chime in on gemma's observations:
In an ideal world, developers would have smart clients. They would know what they want, realise what requests are simple/cost effective to deliver and have realistic expectations of user input. But they don't.

So what I try to do is create a mockup of my proposed system. This could be a stripped down working database, or it could be a set of dummy screens and reports created in, say, Excel. Now this doesn't eliminate all the problems, but is helps. Plus the client gets to see something early in the process and you can manage expectations from there on.

 

[DCrake]

To continue on this theme, I tend to do a bit of reverse engineering on behalf of the client. First ask them what they want to get out of the system. Then tell them what they need to collect, and how to collect it, in order to acheive their goals. More often than not a good programmer will identify certain tasks or results that the client did not think of. For example, one recent requild of a legacy system the client wanted to send out letters to their clients dynamically from within Access, fine I said, but your system at present does not collect the persons gender or title, so when you come to generate the letter how is going to address the person? To this extent we added the gender to each record, which inturn enabled the client to analyse data by gender. This was pointed out to them and as such gave us, the developers, the upper hand in terms of gap analysis, etc. Let them think they hold all the aces and that they rule the roost, but realistically you control the spec and manipulate the system to best suit your own design and methodology.