Design

In Review

1. Introduction

Design is very similar to designing a house or a car or a dress. You need to work out what the pieces will be, how each piece will be made, and how they will fit together.

Design is typically done from a "top-down" perspective. The idea is to take the software from the high-level features and break it into pieces where it makes the most sense. Then, break it into smaller pieces until you are down to individual classes. This is best done in a group with a team of more than one developer. Then, have each developer define the classes and functions they will be creating and then the whole team reviews the results. The developers can then worry about the internals of their software on their own.

Deliverables:

• Design documents including what ever makes sense from the list below:
  • User flows - how the user moves through the software
  • Control flows - which objects are in control for complex processes
  • Data flows - how data flows through the software
  • Hierarchy diagrams - the structure of classes in the software

By the end of the design phase you'll also want to have worked out details of how you are going to implement and test the software. This can include:

• Selected development environments
• Source control system - how you are going to control the software files (including backups!)
• Defect tracking system
• Test management

User Interface

A key factor in any software's success is how it looks to the user. Complex applications and even simple tools can present difficult to understand interfaces to the user. It can be hard to implement and test a whole series of interfaces with a bunch of users. One approach is to bring folks into a room with a large table and layout the user interface as "paper prototypes" where each piece of paper represents one window or dialog in the user interface. Then you can change and move the pages around until your target users understand the flow of the interface.

There is an entire discipline dedicated to formal user interface testing methodology While this can be great it can also be time-consuming and expensive. An easy alternative is to get anyone nearby to take a look at what you are doing and see what they think. Just put them in front of a computer with your software running and see what happens. The biggest challenge is to keep from helping them and instead just take notes on what works and what does not - remember that you will not be there to help them in the future. Take your notes and go back and work on the software again and then retest with the person until they can get through it without a problem. Then, try it on someone else.

Additional Resources

Book: Design Patterns

Book: UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)