Design and Development


Developing software is a rewarding and enjoyable activity. Developing software is also one of the most complex things that humans have ever undertaken. Something as simple as a web browser can contain in excess of 5 million lines of code. To develop software effectively once you get beyond trivial programs requires tools and strategies to help you keep things organised and robust. Even if what you plan to develop is not that ambitious (say, a couple of hundred lines of code), you can still benefit greatly from putting some time into really understanding the problem you are tackling and planning your solution.

If I were given an hour to solve a problem I would spend 40 minutes studying it, 15 minutes reviewing it and 5 minutes solving it. (supposedly Einstein but this has been disputed)

On the following pages we will look at a series of tools and strategies to help you understand the problem and plan the solution.


These are listed in a logical order which roughly follows the way you would implement them when developing your system. In reality however, several of these would be in development in parallel at any given time. Together they aim to help you develop a solid understanding of the problem and then work towards building a complete and effective solution.

How the charts and diagrams overlap

The above diagram is a rather rough representation of how the charts and diagrams relate to the problem and solution and also to each other. As you can see, there is a lot of overlap. Parts of the information represented in one chart or diagram will also be represented as part of another chart of diagram (though usually in a different format). This allows us to analyse and visualise the problem and solution from several different perspectives and also to check the validity and accuracy of the models we are constructing.

As we develop our charts and diagrams it is important that the information they convey matches up and fits in with information conveyed in other charts and diagrams. If you get to a point where you cannot complete a chart or diagram without contradicting or having to add or disregard some of the information present in another model then one of your models is not accurately representing the problem or solution. When this happens this is great. You have discovered something which you have either overlooked or misunderstood or added which needn't be there. You will need to ammend your models to remove the discrepancy but in doing so you are developing a better and fuller understanding of the problem and leading to a better developed solution. This may seem tedious but it is an incredibly valuable and effective way of making sure your solution is the best it can possibly be.

When you start looking at a problem and it seems really simple, you don’t really understand the complexity of the problem. Then you get into the problem, and you see that it’s really complicated, and you come up with all these convoluted solutions. That’s sort of the middle, and that’s where most people stop…

But the really great person will keep on going and find the key, the underlying principle of the problem — and come up with an elegant, really beautiful solution that works. (Steve Jobs)

The Structured Approach

The Structured approach to software development is one of the more traditional approaches. It forms the basis for developing many large products and solutions. Even though there are various other approahces out there such as Agile which are gaining in popularity, they still tend to have some basis in the structured approach. They all implement the basic stages of the Structured approach, typically in less formal ways. The tools and strategies I will discuss here are primarily focused around the Structured Approach and are just as applicable and very easily adaptable to other development approaches. In general, having an understanding of the Structured Approach will make you more effective in undertaking software development using another approach.

The Structured Approach to software development involves five stages:

  • Defining and Understanding the problem
  • Planning and Designing the solution
  • Implementing the solution
  • Testing and Evaluating the solution
  • Maintenance

Data and Information

The reason for the existence of just about every piece of software is to produce information of some sort. To do this it takes data as inputs, processes or manipulates it in some way and then, hopefully, presents the information to us in an appropriate and effective way.

The tools and strategies listed above will help you to more succinctly identify:

  • The output (information) that the system should produce.
  • The inputs (data) required in order to produce it.
  • The processing required to achieve that.
  • Effective and intuitive ways to do all of the above.

Some of that may sound trivial. For many problems you may say that it should be obvious what the inputs, outputs and processing should be. For simple problems that may well be the case but for larger problems it is rarely the case. It is also often the case that our initial impressions prove to be inaccurate. Used properly the charts and diagrams will help you to identify and rectify those inaccuracies.

Alternative Approaches

The charts, diagrams and strategies discussed on these pages have no formal definitive approach. You could walk into 10 different software development companies and find 10 different ways of approaching things both in terms of how they are displayed and also the specifics of how and what they model. The charts and diagrams discussed here are by no means the only charts and diagrams used by software developers either. I have only listed a particular subset and discussed a fairly generic way of implementing them. Your educational institution or organisation may implement them differently and that is perfectly fine. The underlying principles should still apply however. These charts and diagrams ultimately exist to help you better visualise and undertand the problem. As long as they are doing that they are serving their purpose and their particular implementation is largely irrelevant (unless you are implementing these as part of a course or subject in which case you should adhere to their specifications).