The design/development process - Your techniques?

[HockeyNut]

Hopefully this might spark some interesting conversation and comparisons, but I am personally interested too…

I can’t say that I’ve designed enough yet to have a technique which I follow. I know to establish the requirements etc, I have studied Systems Analysis.

But once you’ve collected your information on the requirements, in what process do you then start about the practical element of design & development?

I would be very interested to hear people’s different methods of working.

Do you design everything on paper, and then go for it in Access? Or design some on paper, then a bit in Access, then a bit more on paper & a bit more on Access, etc, etc?

1. Normalisation
2. Enter the tables on Access including field types
3. Storyboard Form Layouts
4. Storyboard Reports
5. Design Queries for reports
6. Create data validation rules and custom errors
7. etc

I know I’ve missed things in the above list, but I just wanted to give you an idea of what I was asking. In what kind of order do you do the Design & Development elements?

Kind regards,

 

[Len Boorman]

Firstly you should understand my position. I never get a written specification so my process tends to be a bit iterative.

Having said that the general process that I use is as follows.
0) Lots of discussion
1) Identify Entities
2) Identify Entity relationships
3) Identify attributes
4) Normalise
5) Identify attribute data types
6) Consideration of default values


I generally do all of this not on paper but next best thing Powerpoint

Interspersed with each task generally is discussion and review.

Only when I have a logical schema with all entities, attributes and data types identified do I actually create in anything in Access

I generally leave reports until after I have built the Enquire, Add, Update interfaces although it can vary a little. If I am creating a quote or invoice then I generally do the report at that time.

As I said my position is that I do not get anything written at all. It is all by discussion and with the best will in the world you never get the full story until just after you think you have finished.

All of my applications are used internally and there is therefore a period of User tailoring as well. Again it is only afterwards that some requirements crawl from the woodwork.

That's life and maintains the interest but does not a lot for the frustration.

HTH

Len B

 

[HockeyNut]

Thank you for your reply Len.

As I'm still learning the processes involved it really helps to hear how other people go about it.

I'm just disappointed that not many people replied to this thread.
I thought it would something of interest to most people, not just myself... maybe I am more unique than I first thought! lol

 

[Jabell]

I don't know of any programmer I know who jumps right into biulding a database without planning first.

For me everything has to be done on paper, i agree with Lee. You have to talk to the user as much as possible, only when you have found the entities you require, what the database will be used for and run through the theory should you start to buid your database on the computer.

Take it from someone who has been the recipient of many problems stemming from poor planning.

I bloody hate normalisation.

 

[neileg]

If I'm developing for my own use, I have a good think and then just go for it.

If I'm developing for someone else, I:
1) Write down in words what the user tells me they want, then get the user to OK or amend this
2) Then mock up the reports and forms, in Access, Excel, Word, whatever. Get the user to confirm that this is what they expect. Users usually care only about the output
3) Work out the data flows, what goes in, and what goes out
4) Sketch out the tables on paper if it's complex, or prototype straight in Access
5) Normalise
6) Develop prototype
7)Test with user
Loop to 6 until user happy or I am fed up
8) Document system
9) Hand over to user
10) Take phone off hook

 

[HockeyNut]

Elaborating slightly on what you've said. I understand the development lifecycle. When you come to the actual "doing" bit in Access.

It's the Access part which really interests me at the moment. Obviously you start with (once normalised):

1. Table names & Field names
2. Field Types, lengths and other properties
3. Relationships
   [/list=1]
   
   Then where do you go, quesries/forms/reports.... I the actual physical doing process that I'm curious about. Hope that makes sense.
   
   thanks for your replies so far

 

[neileg]

Obviously you start with (once normalised):
Table names & Field names

Field Types, lengths and other properties

Relationships

Not really. Like I said, users are really interested in outputs, so I concentrate on the form and report design. When the user says "Where do you show the date of birth", that's when you know you need a date of birth field. Once the apparent design is agreed (ie what it looks like, not how it is constructed) I then proceed to work out what I need to build up the data behind the design.

I know this is completely back to front to the way developers are taught, but I find it the most productive. I hate spending time working out how to do something complex and then have the user say "Oh, that's not important".

 

[Jabell]

I must admit to only having ever designed three databases, the one I'm working on now is collosal, many different tables with postcode territory's, search queries, link tables and filters.

None of this could be done without first making sure you have a stable platorm (for want of a better word) to work on. My database required every table to enforce referential integrity through relationships.

My first mistake, I populated my tables before thinking about the next step I needed to take, ie needed to delete some relationships but couldn't due to data in tables.

 

[mission2java_78]

Ya what she said ^^^^^^^^^

 

[HockeyNut]

Thanks for everyone's replies so far. Especially Pat, you nailed exaclty the kind of thing which I wantedt o find out about.

I've developed a couple of DB's in the past. But I've put them together in a higeldy-pigeldy kind of way. Sot this was the area (which many of you veterans probably take for granted) that I needed some advice on.

Thanks again

 

[Mile-O]

<- bad grammer

It's also bad spelling too. Sorry, couldn't resist. My eyes, this evening, are tuned to misplaced vowels.

 

[Mile-O]

I wish I had a technique like Pat's.

I'm more likely to groan: "what do you want?"

They say, whilst showing me a spreadsheet: "this."

I take the spreadsheet (it's always, in my case, some awful spreadsheet) and listen as they describe it. I ask questions about it, take notes, nod.

I go away and start with tables, building them , and build up the forms and queries, the code, etc..

I show them the prototype, letting them play with a copy of said prototype. They go: "Oh! We also use this spreadsheet."

I groan and listen as they talk me through the spreadsheet. I go away and modify the tables, forms, etc.

Eventually, we get there. They get shown how to use it. I even go so far as to add FAQs into it.

Days pass...

Weeks pass...

I get a phonecall. "Hey, Mile-O-Phile.*"

"Yes?" I reply.

"Why doesn't that database do this? We have a spreadsheet..."

I lose hair.

The End


* not my real name

 

[HockeyNut]

It's also bad spelling too. Sorry, couldn't resist. My eyes, this evening, are tuned to misplaced vowels.

I noticed that one too, but I didn't really want to say anything. Being a relative newbie on here I didn't want to upset Pat, as she has been really helpful in past threads for me. Not knowing people's sense of humour causes me hold back a little on things I'd normally say.

...Well that's unless it's in a language which most don't know. lol

Plus.... I couldn't decide whether it was a deliberate play on the word used

 

[kybb1]

I too..

I too follow the same procedure neileg does....the advantage is that the more the user can visualize the more he/she can better communicate to you what he/she is looking for. Ideally you sit down, talk, talk, talk and talk some more, but the user, more often than not, knows 0 about the capabilities of a database. All he/she knows is what he/she thinks wants (data) to retrieve or store in the db. Once you provide them with visual tools, more often than not, the user will discovers they want much more that he/she was originally. With that said, as things progress, offer visuals, you will thank yourself later for it. (or at least I am) otherwise the user could keep you going back to the drawing board and you will find yourself recreating.

In the past, all the noting, drawing, and charting on whiteboards, proved to be pointless....as the user will no doubt change what he/she is looking for.

So I guess, best said for me...is step by step....create tables and relationships, ect.....then quickly move on to designing the forms....provide them with visual aides. Don't get too far ahead .... once the user says OK...move on....getting too far ahead, can sometimes come back to bite you.

Good luck and happy coding.

 

[RichMorrison]

My 2c.

Ages ago some people were "process" designers and others were "data" designers. These days the distinction is blurred or gone. Any useful application has data and processes.

Most end users see the inputs and outputs of an application so they tend to express new requirements in terms of reports and screens. (Some end users - secretly frustrated programmers - will try to tell the developer what the application should do and how to do it. Discourage these people) Make some rough examples of reports and screen (use Word, Excel, or pen and ink) and review with the end users.

Make some text description of what a screen does - input, update, query. This starts the definition of "processes". Review with the end users and add relevant notes about input editing/validation, error messages, and other process details.

==================================

Based on a discussion of inputs and outputs, the developer can usually see the outline of a data model; the major entities, the attributes of the entities, and the relationships between entities. If you as a developer want to share a paper data model with the end user then do so. Don't expect a lot beyond a smile and polite nod.

Do review your data model and confirm that it has all the stuff you need to accept inputs and generate outputs.

==================================

I think this is sufficient for general-purpose "requirements" and "design". When you start detail design and construction then follow the steps Pat laid out.

RichM

 

[mission2java_78]

Here's a site you'll all appreciate...good aspects into users and the user interface:

www.joelonsoftware.com

very good material...including how specs should be created, how to write good code, how to secure your job...

I am a frequent visitor to joel's site...his insight has helped me create some nice apps.

 

[pcs]

interesting thread indeed!

getting beyond spelling/grammar questions...

i'm feeling way too pleased with myself because my development process is so similar to Pat H's it makes me think i must be doing something right!

mile-o's post struck a particularly responsive chord:

------------
They say, whilst showing me a spreadsheet: "this."
------------

my 'project from hell' (for a very large company) required me to convert a spreadsheet application to Access. this was a cash deposit reconciliation application involving downloading data from the mainframe for many locations and many banks.

the company was doing this with excel. the data was available on a monthly basis and was taking 6 weeks to process. (a lose-lose situation!)

i did (blush) a heroic job with the app. but, it didn't look like a spreadsheet! the department manager simply didn't understand the differance between a spreadsheet and a db. to save my skin, i got the accounting honchos to take a 1 month comparison between the excel version and my version. i guess i won. the monthly process time went from 6 weeks to 2 days.

but take caution... as mile-o pointed out. when you convert an app to a db from a spreadsheet, you are going to have to do a BUNCH of re-education!

so design/development has another side...selling the app to the users.

al

 

[Mile-O]

mile, why don't we just call it a typo and let it go at that

 

[HockeyNut]

I've lost track of the amount of times I've gone to help a user out who has a problem with his "database"... only to find out what they actually mean an excel spreadsheet!

 

[Rich]

That way I have a quick way to back up if I muck it up (see how I pick up the Brit slang).

Great, now if we can just get you to adopt our date system Pat.......