How do YOU go about designing your program
As i learnt VB when i was younger, i pretty much dived in and started typing things out and pressing F1 for MSDN and 'learnt as i went along'.
So when it comes to creating software, its generally a case of "Right i need to load a file first"...type type. "Now i need to add contents to a listbox" type type.
However im constantly retyping code "ah i need to add hidden ID numbers to these so i can remove them" etc etc.
So i wondered, whats the general "format" or 'check list' you go through when designing and then coding your applications to save time?
Although my way "feels faster" its often a case of "All haste and no speed" after i retype each function. :ehh:
Looking forward to replys :)
Re: How do YOU go about designing your program
Personally, I use a whiteboard to sketch out the general flow, important structural arguments/requirements etc. There's a thousand ways to skin a cat so I stay away from specifics in the design phase. Once you have a general flow/structure, it makes the design that much faster (less undoing thing).
That's me. Check this out (Software Development Lifecycle - SDLC) for an idea to see how professionals handle this. I'm a software engineer by trade but I personally stay away from the 'pro' tag. :)
Re: How do YOU go about designing your program
Generally, you start with the output - i.e., what is it that your program is supposed to do or produce; and what are your users asking for? To go along with this, if this is a database-oriented app, the database design should be in place before you start coding, as that will be the foundation of your app.
Given the database design and user requirements, sketch out what needs to be on each screen, and how will each screen be navigated to (i.e., what is the "flow" of the app)?
Once you know what needs to be on each screen, I would say you can start coding.
If there are any parts of the requirements that are new to you (e.g. "how do I drag and drop within a treeview?"), do the necessary research, and maybe look at/build a sample app as a "proof of concept" to make sure you see how to do it before incorporating it into your app.
Those are the basics, IMHO. Then of course, you give your users the "first cut" of the app, they come back with changes, and the process repeats itself (generally, application development is an interative process between you and the users).
I hope this has helped.
Re: How do YOU go about designing your program
Biggest delay are the users... typically they also have a general idea of what they want (same as you) but when presented with the software they suddenly become obsessive-compulsive about it... that is why creating a prototype with important features is better than the traditional waterfall SDLC approach... in the traditional approach, review and testing is scheduled at the end... when changes need to be effected your schedule is already packed hence delays... with a prototype, you can experiment and present users with a sample they can criticize to their hearts content while there is still time to do so... then after a certain period you stop entertaining additions and focus on development and testing of what was already agreed upon.
Re: How do YOU go about designing your program
Quote:
Originally Posted by leinad31
Biggest delay are the users... typically they also have a general idea of what they want (same as you) but when presented with the software they suddenly become obsessive-compulsive about it... that is why creating a prototype with important features is better than the traditional waterfall SDLC approach...
This is so very true. I'm a strong believer in creating prototypes. Users seem to be visual people. If you can actually show them something, then often the "flood gates" will open, and all the specs you are been trying to get out of them for the past three months will come pouring out so fast you will actually have to slow them down.
Re: How do YOU go about designing your program
Quote:
So i wondered, whats the general "format" or 'check list' you go through when designing and then coding your applications to save time?
I think the start point is Analysis
Its debateble to follow which model in Software Development, but before all the other phases, you need to know what you should develop.
I always tend to start with Requirements Gathering. Collect information about the bussiness process. Do background research, etc ...
And I think this has so many aspects if you consider the types of software you need to develop
1. Bussines
2. Entertainment
3. Scientific
4. Real Time
etc ...
Its always good to know the functionality you need in that software.
When you have got the functionality, then you can start designing.
In this you can use the traditional Water Fall Model, or adopted version of it - Iterative Development Model ???
Prototyping is another method.
Here are some resources for you
http://en.wikipedia.org/wiki/Systems...ent_Life_Cycle
http://www.pragmaticsw.com/SE_SP_sdlc.asp
http://qualityvista.blogspot.com/200...ive-model.html
And some books I've used
http://www.rspa.com/about/sepa.html
http://www.amazon.com/Software-Engin.../dp/020139815X
Hope these helps you.
:wave:
Re: How do YOU go about designing your program
Flowcharting and having some kind of basic logic will save you from major issues in design. Just code the basics of the program and if you finish under budget then place in more added features.
Thread Moved
Re: How do YOU go about designing your program
An excellent question Chris :)
It's good to get the professional opinions on this.
Re: How do YOU go about designing your program
Quote:
Originally Posted by RobDog888
Flowcharting and having some kind of basic logic will save you from major issues in design.
This is a very true statement, however, in my shop, if I got caught mucking about with charts I would asked why I was wasting my time drawing pictures and not busy writing code. :sick:
My IT people are a couple of fries short of a happy meal! :D
Re: How do YOU go about designing your program
I walk alot.
I suspect that my user base has both more and less experience than most, which is a bit odd. Since I work with a bunch of scientists, they generally expect software to produce very specific products, but otherwise be poorly documented and difficult to use, as so much specialized scientific software is. We use stuff that makes the old DOS command prompt look user friendly, so people have VERY low expectations for an interface. I have yet to hear a single visionary idea about interface from any of the scientists. They have big ideas about the data, but are totally tolerant of miserable interfaces. Therefore, any easy to use interface design is greeted with astonished delight.
Because of this, I get lots of input on data, data organization, output products, and things like that. However, as to how the program should act, I get no input of any sort, which means that I spend a fair amount of time watching how people go about their jobs, look at the data they are taking and the patterns in which they take the data, then spend lots of time wandering around thinking over how an interface would fit into their routines.
