How to design software

Question

I am planning to design software, and I have two questions:

• Do I need to write all the documents before development?
• What else do you do when you are going to develop software?

Answer 1

This is a rather broad question, but you might want to start somewhere like here:

http://en.wikipedia.org/wiki/Software_development_methodology

Answer 2

Plan out as much as you can. Write everything out: what the demands are, what needs to be done, deadline, budget, etc. Then start getting into HOW the project will be done. Map out your objects, design the general pattern of the program. The forethought is sometimes more important than the actual coding. :D

Answer 3

Rule number 1:

• you cannot design software without having experience on how to code software

Rule number 2:

• you cannot design software if you never built a knowledge of typical solutions from others

Rule number 3:

• It is difficult to design a software right the first time, even if you are an experienced designer. Some people claim it is impossible.

Rule number 4:

• 1) try it. 2) fail at it. 3) if (!retired) goto 1

What to do

Designing the GUI

Use pen and paper to write mock ups of the expected interface. Draw one sheet for each "visual state" of your GUI, so that you can "click" from one page to the other.

Let other people interact with the paper interface, ask them if they find it intuitive or not. Check for violations of HIG standards of the target platform.

Designing the code

Loosely, and deemed to be adapted

1. Delineate your high-level objectives
2. Describe a simple network of classes answering to the needs of your high-level objectives.
3. Divide the class network in subsystems, so that similar classes are in the same subsystem
4. Check the dependencies. Too intertwined networks are a sign of bad design.

Applications in general have three layers: the GUI, the "computation part" (business logic), and the storage/IO. You should approximately have these three parts as loosely coupled as possible.

How you actually perform these steps, how much documentation you do, how you organize your work and those of your colleagues, depends on the development strategy you adopt: waterfall, iterative, XP, whatever.

Answer 4

What documents? You make it sound like there's agreed-upon documentation for all projects.

If you must write documentation, start with a paragraph or two that's the 'elevator pitch' for what you're trying to accomplish. If you can't boil it down to something that would make it clear to a customer or another teammate, perhaps you don't understand the problem so well.

Most people will at least sketch out screen shots of a UI, just to have an idea of the flow that users will see.

UML fans will have a class diagram of the objects that you think you'll need to solve your problem.

That might be enough to code the first bit of functionality you want. Get one working, test it until it's solid, move onto the next. Try to do the high-risk items first.

Answer 5

There are many documents that typically need to be written..but not always before software can be written. Things like requirement documents, design documents, implementation details, etc. Depending on your role you may or may not write any of these.

One thing I would say before real development is do some research. Try writing some simple test apps and such to get familiar with technologies, libraries, and possibly languages you have either never dealt with or have limited time with.

Stefano's answer above...rules 1 and 2 are research rules. Read about and learn about possible solutions to the problem at hand. Don't reinvent the wheel...just improve upon it. See what solutions other people may have come up with and see if they fit your problem.

I agree with Stefano in that software can never be designed correctly the first time. In fact even after you code I don't think you can ever be more than 95% complete. There is always room for improvement.

Answer 6

If you have never designed a program, then the simplest approach is to create a user story, http://www.extremeprogramming.org/rules/userstories.html, and allow the developers to figure out the best way to implement your vision.

You may want to take the initial story, and break it down into parts to help them, to get rid of some of the ambiguity.

By using XP programming they can then ask you questions, you should see a mock-up of the UI quickly, and then a prototype, and through repeated iterations you will see what you envision completed.

If you start with a great deal of documentation, then you seem to be going down the waterfall model path. For a nice article on comparing agile to waterfall you can look at Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development#Contrasted_with_the_waterfall_model

You will find that you will generate a great deal of documentation, but, unless you are solving a well-known problem, such as designing a calculator, or something for the life insurance industry, then odds are that what you end up with is not exactly what you want, so time and money is wasted.