title=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
After observing and researching the business I have found out the following:
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!
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.
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.