The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

whats the best way to build application/system/program/software?

What are your methods or methodology or ways when you build application start from gathering info till the final output of the application? So the finish application would be a quality/no security/loopholes etc...


I was asked to build an application from scratch till a finish product. The thing is the person in charge of giving me information/input/functions like to work this way :

He gave me info of basic information(items in the input area) on what should I build and what the result would be. But along the way, he asked to add/change something here there.And we have feedback session, he said something missing/or this should be removed etc.

So I want to know whats the best way to do regarding this?

And next time how/what should I do before start a project?
Mie Send private email
Thursday, November 29, 2007
 
 
1. Know what you need to do and what is your end result.

2. Use a systems design methodology (UML, SSADM, etc) - draw at a conceptual level what your program should do. Then convert your concepts into individual specific functions. Finally do your database design and start with heavily commented code that forms a solid basic structure of what your application will do.

3. Have a maintainable list in black and white, of the latest "complete" list of features your app must have and update regularly. Make sure your client agree to this list (ask them to sign) so that they can't say I want this NEW feature which wasn't there in the first place. FINALIZE this list before you start any design and coding.

4. Do a project time line and resource requirements.

5. Select a suitable OS, platform, hardware, database and programming language.
Ezani Send private email
Thursday, November 29, 2007
 
 
And never finish and piss off the client because what you eventually deliver bears no resemblance to what he wants now.
Chris Tavares Send private email
Thursday, November 29, 2007
 
 
You either:

1. Charge a flat fee and develop exactly what is described in his written specification. If he wants changes after the project starts, you tell him what other features you will have to remove to keep it the same cost. This is called "Firm Fixed Price."

or 2. Charge him by the hour. He can change it all he wants, you just get paid more. This is called "Time and Materials."
Bob
Thursday, November 29, 2007
 
 
The best way to build software is pick the most appropriate activities according to your individual circumstances ;-)
IanH. Send private email
Thursday, November 29, 2007
 
 
Thanks for the suggestions.
Mie Send private email
Thursday, November 29, 2007
 
 
More comments are welcome.
Mie Send private email
Thursday, November 29, 2007
 
 
Spend some time with the users. Understand what they do as deeply as you can in the time available. If you are writing a  POS system, go run stuff through the existing cash registers for a few hours, etc. See how often they do refunds. See what happens when someone gives them money in a foreign currency.

IMO, for most business apps, understanding of the business itself is the thing that separates the truly productive from the guys who just screw around with class hierarchies and indentation all day long.
Greg Send private email
Thursday, November 29, 2007
 
 
That's one heck of a question!
Though more appropriate for managing a team of developers working on a larger project, you may find this useful:
Top-Ten List of Tips and Suggestions for Effective Software Project Management - http://ericomguy.blogspot.com/2007/07/top-ten-list-of-tips-and-suggestions_31.html
Dan Shappir Send private email
Friday, November 30, 2007
 
 
If you haven't done it read "Software Project Survival Guide" by Steve McConnell. Or a similar book by someone else.

You talk about "the guy in charge". Are you doing this as his employee, or as someone contracted to do the work? It makes a big difference.

If he's your boss, then working the way he wants to is a good idea. What you should be aiming to do is build iterative proptotypes - i.e. something that does roughly what he says he wants, as quickly as you can (without necessarily actually working) and take it to him and say "is this what you meant?" That way you get his actual requirements as soon as possible.

I would also suggest keeping each thing you show to him, and also keeping notes of what he says. Just in case you have to go back and say "no you told me you wanted this".
DJ Clayworth
Friday, November 30, 2007
 
 
DJ Clayworth,
\
I like this approach. Thanks for the suggestion.
Mie
Sunday, December 02, 2007
 
 
Build the smallest end-to-end part of the system you can manage and deliver it in "done" status. That gets you the earliest possible feedback on whether it's right or not, and gives the client feedback on whether you can do the job or not. As you deliver small chunks every day or week you can both see whether the whole thing is on schedule and worth continuing.

"Part" and "done" might seem to be in conflict. If there is a screen with 4 business functions on it, define one function as a part, and one function working as done. Then start the next function.

All that is one element of Agile stuff. Read up on XP and Scrum for much more.
Stan James Send private email
Tuesday, December 04, 2007
 
 
Thank you very very much for the adivices.
Mie Send private email
Thursday, December 06, 2007
 
 
*advices and suggestions.
Mie Send private email
Thursday, December 06, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz