The design/development process - Your techniques? (1 Viewer)

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

 

[Pat Hartman]

Here's my approach for once I move from mostly requirements gathering/design to building.

During the requirements gathering process, I keep track of entities, attributes, and their properties with Excel. The rows are easy ro rearrange if an attribute needs to be moved from one entity to another and I can keep notes to myself right in the spreadsheet.

Once the data model has jelled sufficiently so that I feel comfortable that it is close to being final, I build Access tables and create relationships.

I usually start with the data input forms because that makes my job easier. It is necessary to test everything that you build thoroughly and having the ability to easily enter data pays off in the end. Also, the data entry forms are among the most critical and so by building them first, they will also be the best tested because they are used constantly throughout the process to enter new data.

To build a form I first build a query and then use the wizard to build a form bound to this query. Once the wizard has done the basics, I move things around and make the form generally pretty although detailled "prettying" I usually save for the end until after the user has had his say on functionallity and general appearance. Don't forget to keep up with the tab order as you move things around.

After the form is functioning to add/change/delete rows, I rename ALL the control names so that they are different from the bound column names. This helps to prevent many problems once you start writing code. Then and only then do I add event code.

Since most of my databases work with ODBC back ends, it is necessary to specify criteria to limit the recordset for a form. To do this, I usually use a small form were the user can enter criteria and then after pressing a button, open the main form, positioned at the speciific record. This form varies from app to app. Sometimes it may control several forms and other times each main update form will have its own criteria-selection pre-form. Using an unbound combo on the form to find records isn't a good solution in this environment because the recordset is not limited by criteria. The combo simply moves through the recordset to the specific record. Building a report is a similar process.

Once I have a few objects built, I create a Menu, usually by using the Switchboard Manager. This way I can give the db to the user without having to explain how to run things. I just set the switchboard as the startup form. I place the db on the network and let him start using it. As each new object is completed, I add it to the switchboard in my db once it has been unit tested. Every couple of days (depending on the speed of object creation), I replace the shared network copy of the db with my current working copy so the user gets to see new objects.

Code modules containing public subs and functions are created as I need them.

Before embarking on making major changes to an object, I copy the original version and add "zz" to the front of the name. That way I have a quick way to back up if I muck it up (see how I pick up the Brit slang). Once I am happy with the new version, I delete the "zz" version. Be neat. Don't clutter your db with old unused objects. Use a consistant naming standard for objects that have been replaced so that you can delete them periodically.

If you need to make a change to a table that is more involved than adding some new fields or changing a data type, you may need to remove the relationshp first. Make the change and then re-establish the relationship.

While you're testing, don't forget to do the stupid things that your user will do so you can find the errors first. Having error trapping code in all modules is a really good idea. I usually start with simple code that just displays the err.number and the err.description. Then as I make specific errors, I add a select case with error trapping code for the errors that I want to handle or give the user custom messages for (<-- bad grammer).

 

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

 

[Pat Hartman]

mile, why don't we just call it a typo and let it go at that At least I know how to spell separate and know the difference between your and you're

edit: that wasn't a specific jab at mile, I don't keep track of who can spell and who can't so I don't know who makes those mistakes only that way too many members do.

 

[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