# A-level Computing 2009/AQA/Problem Solving, Programming, Data Representation and Practical Exercise/Problem Solving/Stages of problem solving

Solving problems is never easy, so you need to break them down into manageable chunks:

## Understand the problem

Before we should start solving a problem, we need to understand exactly what the problem is that we are dealing with. Only then can we start to think of solutions. By doing this we can avoid spending a lot of time on unsuitable solutions that we'd then have to throw away.
Knowing the level of thinking required to solving the problem and having an idea of a solution which is relevant to the problem.

### Define the problem

To fully understand a problem we need to think about the following:
* Given(s): the initial situation
* Goal: desired target situation
* Ownership: who does what
* Resources and constraints: tools, knowledge, skills, materials and rules, regulations, guidelines, boundaries, timing
For example:
* Example: Defining the problem (Football game)
* After observing and researching the business I have found out the following:
* Given(s)
* Electronic Crafts is a small programming house looking to create a football game for the mass market. They have experience making games for the Super MES and are looking for the next hit.
* Goal
* To create a football game for the Super MES.
* Ownership
* Barry is a graphics designer, Mike is the lead programmer, Coral is an AI programmer, Jaya is the boss.
* Resources and constraints
* The Electronic Crafts offices have 4 development machines running Linux and C++, The platform that is being developed for is the Super MES using Visual Basic. Barry, Coral and Jaya have all programmed the Super MES before, but Mike hasn't. Mike is skilled in C++. The game must be complete within 9 months. Electronic Crafts have a game engine already running on the Super MES that you could use. Electronic Crafts specialise in cartoon like games for children and this football game should be branded as such. There should be no violence or swearing.

## Define boundaries

Understanding the limits to coming up with a solution and knowing what can and cannot be done through lateral thinking. These boundaries may also be known as a type of constraint.
It is important to define what your system is not going to do - as important as considering what it should do. Most software projects fail because of specification creep - where the code in development moves away from the requirements because someone (often the developers themselves) feels that it would be good if the application also did <this> and <why not put it in while you can> thinking. You will end up with code that you do not know how to test or fix when it goes wrong - which is a sign of poor development that markers will not be able to ignore!

## Plan solution

Once you have defined the problem, given, goal, ownership and resources you need to start thinking about how you will implement a solution. This might involve using tools such as flow charts, pseudo code, top down design, finite state machines etc. These will allow you to get started with actually making the solution. We will meet all of these methods shortly.

## Check solution

Once you have created a solution you need to check it against the original problem. If it solves the problem then you have a successful solution. If it doesn't then you have failed and will have to go back to the drawing board to try another solution that works.
Note that you can (and should) test your design on paper against the specification (and your test plans) before you code it. This "walk through" approach is often done in team working - which encourages the consideration of abnormal data input, or using work flows that had not been thought of.