Software Design and Development

Software

Design and Development

Introduction

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. As well as describing what the charts and diagrams are we will also discuss things to consider in terms of creating them effectively and utilising them to their full potential. Just going through the motions and creating them is not enough to create awesome, solid software.

These tools and techniques will also be invaluable to you if you are delving into developing games.

Outline

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.

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. You should be engaged with your charts and diagrams and they should evolve over time. 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. UML (Unified Modelling Language) is another popular suite of charts and diagrams for modelling a system. Using UML is a bit more complex and involved and probably a bit more effective when the system you are attempting to create is larger and more complex. The overall concepts are similar however so making the jump to UML after learning the charts and diagrams here is not too difficult.

The charts and diagrams listed here are only a particular subset and discussed in 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).