Problem Solving: Stages of problem solving

From Wikibooks, open books for an open world
Jump to navigation Jump to search

UNIT 1 - ⇑ Problem Solving ⇑

← Introduction to principles of computation Stages of problem solving Top-down design and Step-wise refinement →

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

Understand the problem[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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.