ICT Engineering

Heuristics: is a method of solving problems by finding practical ways of dealing with them, learning from past experience

IDEAL

A simple yet powerful method for solving problems is IDEAL. Each letter of IDEAL stands for a step (Identify, Define, Explore, Act and Look back) in solving problems. It is worth mentioning that IDEAL should not be confused with the English word “ideal” which means “perfect”. While this approach is excellent to master and practise, it is by no means perfect. A complete example is provided at the end of the section.

Identify the Problem

If we look around us and notice the artefacts that have already been designed and used, we realise that not all of them are perfect. Some might do the job but may still need improvements. Identifying problems starts with looking for problems with the existing systems that we already utilise in our everyday life. People generally tend to accept unpleasant, bothering systems or artefacts. Engineers, on the other hand, should not. They should identify the sources of problems and, if possible, fix them right or propose new solutions.

Define and Represent the Problem

To identify a problem is to recognise its existence. Defining a problem, on the other hand, is describing and representing a problem. While different people may define a problem in different ways, they recognise the problem the same way. And that is the fundamental difference between identification and definition of problems. To properly define a problem, a clear conceptual representation should be developed. While simple problems may not require diagrammatical representation, some complex problems cannot be represented without detailed graphs and even physical representation or models. Some solutions can only be developed through observation of models before implementation.

In complex problems, diagrammatical representations, or graphs, are needed because of the limits of our short-term memory (refer to 'A Problem Solving Mind').

Explore

At this stage, exploring methods and approaches to a solution is necessary. The first step at this stage is looking for ways to break down the problem into separate, easier parts. Then chaining forward, chaining backward, or tackling the problem from middle should be considered (chaining is explained in 'A Problem Solving Mind'). These options can also be diagrammatically drawn for further insight and imagination. Another strategy would be to imagine a specific case related to the problem or its solution.

Act and Look Back

If we do not act, we do not get anywhere. Planning sometimes need immediate feedback. This is why we act, we look back and examine the result of our actions. The final two stages, therefore, are implementing and testing repeatedly until we reach a satisfying solution.

To illustrate the steps above, we introduce a practical problem as an example and use IDEAL approach to reach a conclusion.

The desktop noise problem

Imagine the noise from your desktop computer. You have recently realised that your desktop PC developed an annoying noise. Most people accept this problem and see it as a normal sound that PCs make during operation. But some may start to examine the problem and possibly fix it. Either way, the problem is recognised, or identified.

For those who do not accept the noise and think of a solution still need to define the problem before they can fix it. This is because the noise could come from different sources in a desktop PC. It could be from the cooling fans of the chassis or the cooling system of the microprocessor. Noise could also be generated from vibrations and echoing sound waves from the hollowness of some computer desks. This is usually caused by the moving parts of a computer. Definition of the noise problem, therefore, is a necessary step after recognition or identification. Only after defining the problem we can search for solutions. Figure 1 is a hierarchical graph that illustrates the possible sources of the noise problem.

Figure 1. A hierarchical representation of the noise problem

Suppose that after careful examination and elimination of the potential sources that did not make any noise, we finally found out that a cooling fan was the source of the noise. Now we need to explore possible solutions and strategies to solve the problem. After enough search and exploration, we realised that there were a number of different ways to minimize noise from cooling fans. For example, we could change the fan with one that has special, noiseless blades. But we could also reduce the speed of the fan with potentiometer circuits that are specially designed for that purpose. We still had another option which was to use a water-based cooling system.

Act and look back is still required if we choose a potentiometer circuit for the problem. Potentiometer circuits need adjustment and that in turn needs “act and look” steps; change the potentiometer a little and listen to the noise. Repeat that until acceptable level of noise has been attained.

Albeit this problem is simple and does not require complex diagrammatical representations, but we can still build a complete concept map describing all possible pathways and nodes of the problem. To begin, we first formulate our central concept, or domain, by asking: what are the possible causes of noise in a desktop computer? We can immediately realise that the central concept is “cause of noise” or “source of noise”. We then list as many concepts as we can and draw them around the domain. Figure 2 shows the step.

Figure 2. A central concept together with a list of related concepts of the noise problem

Next step is to add initial links or relationships between the central and the rest of the concepts. Figure 3 depicts the links.

Figure 3. Initial relationships between the concepts of the noise problem

Note that a few other possible sources of noise now have been listed to cover most of the sources. Next step is to group concepts that have closer relationships between each other. While the number of concepts from figure 3 are within the capacity limit of our short-term memory but, grouping is still very important since it further simplifies the problem. To do that, we need to introduce concepts that properly represent the groups. Figure 4 illustrates this grouping.

Figure 4. A concept map of the noise problem before cross-links

The final step of the concept map is to add possible cross-relationships. In this case, there are two necessary links that will lead to a better identification of the noise problem. Figure 5 shows the final concept map with these cross-relationships.

Figure 5. A complete concept map describing the noise problem

Similar maps and flow of thoughts can be applied on the solution. A hierarchical diagram can represent possible solutions and levels at which decisions have to be made. Decision hierarchy is always part of representations of open-ended problems. Open-ended problems have more than a solution and hence the existence of more than a pathway to choose from.

Heuristics Practised by Engineers

Below are some of the most common heuristics that are practiced by scientists and engineers.

Back-of-the-envelope calculation

Because of the limited capacity of short-term memory, using a pen-paper system is the best tool available to engineers. As the name of this heuristics implies, rough yet critical calculations may even be performed on the back of an old, discarded envelope. This heuristics encourages engineering students to use paper and pen or pencil to write down numbers and sketches to assist their short-term memory.

Chaining in different directions

Chaining forward, backward, or from middle is essential and often applied in complex problems. Chaining is explained in 'A Problem Solving Mind', section: 'Chaining'.

Divide and conquer

This is probably the most fundamental heuristics that engineers use to solve complex design problems. To apply this method, a problem must be divisible into independent, sub-problems that can be tackled severally.

Think out of the box

When we are presented with a problem or design, our mind subconsciously draw an invisible boundary around the problem in such a way that it limits the possibilities of a solution within that boundary. In the problem of the strings hanged in an empty room, our mind involuntary puts the pliers in a box in that it limits its use to cutting and grabbing. However, with a bit of experience, we think out of the box and use the pliers as a pendulum.

Diagrammatically represent the problem

Diagrams are the only way to represent complex problems since the short-term memory cannot cope with more than 9 entities at the same time. Diagrammatical representations, therefore, is at the heart of engineering discipline.

Solve a simplified version of the problem

In complex problems, it is possible that there might be parts of the problem that don’t have major effect on the overall problem and that they could be ignored. In such a case, the problem can be simplified by eliminating the less important parts. If the problem could not be simplified further, then, starting to solve the easier parts will almost always have similar results.

Try to explain the problem to your colleagues

One good way to fully understand a problem is by explaining it to others. Similar results might be attained by explaining the problem aloud to oneself. Explaining the problem to colleagues is like an internal dialogue with oneself.

Model the problem and examine it

Design problems that lead to solutions of large structures can be solved by designing a model solution. Examining the model will produce clues and ideas that can later be used in tackling the original problem.

Look at the problem from a different angle

Sometimes conventional thinking is not the best way to a solution. Seatbelt vs. airbag is an example. Conventional thinking must have been to fasten a person to a car seat in order to restrict movement and minimise or prevent severe injuries during accidents. With a different perspective, viewing the problem from a different angle, engineers invented airbags.

Take a break!

Learning new concepts, ideas, and problem solving skills physically changes the links between brain cells or neurons. However, not all parts of the brain are ready for change at the same time. This is why taking a short break and doing something different other than problem solving is recommended.

Wankat Problem Solving Strategy

Another strategy which is similar to IDEAL is developed by Phillip C. Wankat. The strategy has these steps:

0- I want to and, I can
1- Define it
2- Explore it
3- Plan it
4- Implement it
5- Check it
6- Generalise it
7- Present it to others

Below is a brief explanation of each step:

I want to and, I can

The very first step is preparation. It is important to be both mentally and physically ready before you start solving a design problem. Adjusting your internal dialogue to “I can” and accept the challenge to the end; don't give up easily.

Define it

To define a problem is to fully understand its known and unknowns. Information from the problem statement can either be explicit or implicit. Explicit information is what is directly given in the statement of the problem. A clear example of explicit information is numerical data such as width, length, or size. Implicit information, on the other hand, can be obtained indirectly. For example, volume is a quantity that can be calculated from width, length, and height. Other implicit information could be in the form of implication of some other properties. A design problem of a system in a hot environment, for example, implies materials that stand high temperatures; the hot environment is the implicit information.

Restating the problem statement in simpler or clearer manner is also sometimes helpful. Represent the different aspects of the problem with concept maps and other schematic diagrams to have a clear, overall picture of the environment in which the problem is to be synthesized.

Explore it

This is the stage where you really have to re-examine the problem within its boundary and environment. Is there a part of the problem that doesn’t make sense? Do all pieces of the given information make sense and compatible with the unknowns? Further examination can be whether there are already solutions that could be applied to solve the problem. Or, should a complete solution be developed from scratch?

Exploring also involves necessary assumptions for filling out the missing gaps in the problem statement. What are the concepts that make up the problem and what is the approach that should be used to attain a solution.

Plan it

A complete plan before implementation is necessary since without such plan time and recourses might be wasted. Also, debugging or identifying design defects at a later time would be difficult. Starting a plan with a concept map of initial and goal states, with the middle stages drawn later one step at a time based on paths and available choices, would be perfect at this point. Concept maps are excellent diagrams for tracking and following the plan steps at any stage. They also serve as a clear documentation of the solution that can be presented to other involved parties. Different heuristics should be applied during the planning; chaining backward or forward, divide and conquer, tackle a simpler, similar problem, take a break, etc.

Implement it

Applying the steps of the plan is pursued at this stage. Some parts of the implementation may require going back to the plan for modification. While this iteration may occur a number of times, a good plan usually reduces this number.

Check it

Results of each step should be thoroughly checked for unexpected results such as a number that is larger than it should be or an unexpected, negative result, etc. Checking results is harder when the solution to be developed is a complex piece of software. Software test cases can be anywhere between a few cases to millions or hundreds of millions of cases. Software testing is an extensive and complex field.

Generalise it

Can the solution of the problem be generalised and applied to other, perhaps similar, situations? What has been learnt in terms of lessons, obstacles in the way, etc. from this problem? Is there room for improving the results or outputs? A generalised assessment of the overall solution is the aim of this stage.

Present it to others

The ability to present designs, solutions, ideas, and produce necessary documentation is an important skill for engineers to master. Engineers should also be able to communicate with lay parties or audiences and be able to present results in a clear, perhaps non-technical manner.