Are there any standards for designing an application?

Question

I'm interested in creating my own project in my spare time to learn some more about development, I have several ideas of what I want to create, and what technologies to use (java, stripes framework) but I don't know where to begin on the actual design.

I understand that design and planning is a key objective to a sucessful application, but I'm not sure where to start.

Are there any guidelines or standards for this?

Thanks

Answer 1

For the Windows world, the Application Architecture Guide from the patterns & practices group may be helpful. See http://www.codeplex.com/AppArchGuide.

It also explains some general principles that are valid beyond the MS world.

Answer 2

I'm not 100% sure what you mean by "design", but if you're talking about deciding which classes to define and how they'll interact, CRC Cards are a good tool to use.

Answer 3

A student had been sitting motionless behind his computer for hours, frowning darkly. He was trying to write a beautiful solution to a difficult problem, but could not find the right approach. Fu-Tzu hit him on the back of his head and shouted 'Type something!' The student started writing an ugly solution. After he had finished, he suddenly understood the beautiful solution.

-- taken from http://eloquentjavascript.net/chapter6.html

I took a similar path to what you are describing when I began learning software development, and I also read about how important upstream design is to a project. I tried and tried for 2 years to completely design a program before building it, and every time I failed. Things never really worked out according to the assumptions I made in my designs. Adding to my high failure rate was the fact that I would often change my requirements in the middle of software construction, making the design invalid.

I recently began using a better approach with much more success (and more fun too). The basic idea is to create working versions of your program in very short iterative periods (agile development). It is very likely that your first whack at a new feature is going to be ugly, but then you get it built, and come back to it later, making it more elegant because your thoroughly understand it the second time around. So instead of rewriting my projects over and over again, I now just refactor the code whenever I revisit it. It is a much more rewarding experience.

Answer 4

There are many "Methods" and "Processes". You could read about RUP and contrast it with XP

One common feature tends to be that a key task is agreeing with the "customer" what is to be built. If you are doing this for yourself, that is one aspect that will be a little different.

Another thing to bear in mind is that processes such as these are addessing issues of communication: between customer and developer and between the developers themselves. Some work products are created explicitly for that purpose. Hence when you are working by yourself you may find some of this quite heavyweight.

I suspect that a key thing you will come to is how to design your system, decomposition and allocation of responsibilities to components. Getting this right tends to bea major challenge. Again if your working by yourself on small systems this also may not seem quite so important.

So my message is that you need to try to imaging the "scaling" of wha you are doing to bigger problems.

Answer 5

Depending on the size and scope of your project, you can get a sense of how much time you should spend designing it. Make a rough estimate of how long the project will take and try to spend 10-20% of that time doing upfront design. Don't worry about getting this estimate wrong.

Design Activities

• Gather Requirements - Make a list of what the end user will need out of this app. If you are making an application for yourself, spend some time writing down what you want out of the program. Including what you DON'T want the program to do will help as well.
• Functional Design Spec - Based on the requirements, start mapping out the exact functionality you want in the application. This includes laying out the user interface and the rest of the user experience. Doing this at the beginning will help your application have a consistent feel. Don't include too much detail of how you will implement this function.
• Technical Design Spec - Depending on the size of your project, the technical spec can often be replaced by source code itself without too many problems. This is a breakdown of how you will implement the functionality specified. Making this document will force you to think about how the classes of the application will fit together.
• Implementation - During the implementation, you will inevitably realize there was a flaw in your specs or requirements. If you misunderstood what the end user wanted, return to the requirements document and update it. Then work through the Functional and Technical specs to make an changes needed. If it is just a whole with how the classes are meant to interact, you should only need to change the technical spec.

Alternatives

You don't have to do a large amount of design. There are existing software development methodologies you can use that allow you to avoid much of this work.

• Extreme Programming -
• Agile Programming

These approaches, focus on making the simplest possible app that will work, then iterating the app to slowly add new functionality. This allows for flexible design. Writing a lot of unit tests will allow you to refactor existing code without great risk of breaking the existing functionality of the code.

Resources

• Code Complete - Has several chapters on gathering requirements and doing design. This book is just great overall if you are looking to improve your programming practices.
• The Pragmatic Programmer - If you've ever sat down to code and don't know where to start, this book has lots of general advice you can use.