Αρχική » 6. evaluation
Αρχείο κατηγορίας 6. evaluation
BBC Evaluating solutions test
Visit BBC site to take the test Evaluating solutions test
BBC Evaluation of a solution
How do we evaluate our solution?
- does the solution make sense?
Do you now fully understand how to solve the problem? If you still don’t clearly know how to do something to solve our problem, go back and make sure everything has been properly decomposed. Once you know how to do everything, then our problem is thoroughly decomposed.
- does the solution cover all parts of the problem?
For example, if drawing a cat, does the solution describe everything needed to draw a cat, not just eyes, a tail and fur? If not, go back and keeping adding steps to the solution until it is complete.
- does the solution ask for tasks to be repeated?
If so, is there a way to reduce repetition? Go back and remove unnecessary repetition until the solution is efficient.
Once you’re happy with a solution, ask a friend to look through it. A fresh eye is often good for spotting errors.
Dry runs
One of the best ways to test a solution is to perform what’s known as a ‘dry run’. With pen and paper, work through the algorithm and trace a path through it.
For example, in Algorithms, a simple algorith was created to ask someone their name and age, and to make a comment based on these. You could try out this algorithm – give it a dry run. Try two ages, 15 and 75. When using age 75, where does the algorithm go? Does it give the right output? If you use age 15, does it take you down a different path? Does it still give the correct output?
If the dry run doesn’t give the right answer, there is something wrong that needs fixing. Recording the path through the algorithm will help show where the error occurs.
BBC Problems with solutions
Solutions that are not properly decomposed
- what kind of cake to bake
- what ingredients are needed, how much of each ingredient, and when to add it
- how many people the cake is for
- how long to bake the cake for
- what equipment is needed
A diagram of a further decomposition of ingredients would look like this:
At the moment, a diagram of the further decomposition of equipment would look like this:
The ‘Equipment’ part is not properly broken down (or decomposed). Therefore, if the solution – or algorithm – were created from this, baking the cake would run into problems. The algorithm would say what equipment is needed, but not how to use it, so a person could end up trying to use a knife to measure out the flour and a whisk to cut a lump of butter, for example. This would be wrong and would, of course, not work.
Ideally, then, ‘Equipment’ should be decomposed further, to state which equipment is needed and which ingredients each item is used with.
The problem occurred here because the problem of which equipment to use and which ingredients to use it with hadn’t been fully decomposed.
Solutions that are incomplete
- what kind of cake to bake
- what ingredients are needed, how much of each ingredient, and when to add it
- how many people the cake is for
- how long to bake the cake for
- what equipment is needed
However, this is incomplete – part of the problem has been left out. We still need to know:
- where to bake the cake
- what temperature to bake the cake at
Therefore, if this information was used to create the solution, the algorithm would say how long the cake should be baked for but it would not state that the cake should be placed in the oven, or the temperature that the oven should be. Even if the cake made it to the oven, it could end up undercooked or burnt to a cinder.
Very important factors have been left out, so the chances of making a great cake are slim.
The problem occurred here because placing the cake in the oven and specifying the oven temperature had not been included, making the solution incomplete.
Solutions that are inefficient
It would be more efficient to fetch all the ingredients in one go, and the program would be shorter as a result:
The solution is now simpler and more efficient, and has reduced from nine steps to five.
The problem occurred here because some steps were repeated unnecessarily, making the solution inefficient and overly long.
Solutions that do not meet the original design criteria
- what kind of cake to bake
- what ingredients are needed, how much of each ingredient, and when to add it
- how many people the cake is for
- how long to bake the cake for
- what equipment is needed
The first point considers what kind of cake to bake. Often, when devising solutions to problems, a specification for the design is given. For example, the cake may have to be a chocolate cake, which is still quite general, or a chocolate fudge cake with chocolate icing and flakes on top, which is more specific.
To meet the design criteria, it is important to ensure that the exactly right kind of cake is baked. Otherwise the solution may not be fit for purpose.
The problem occurred here because the solution did not meet the original design criteria – it was not exactly what was requested.
Dimensions of Computational Thinking in COMPUT project
When we started working on the project Computational Thinking at School, our plan was to study the following dimensions of Computational Thinking
- creative problem solving
- algorithmic approach to problem-solving
- problem solution transfer
- logical reasoning
- abstraction
- generalization
- representation and organization of data
- systemic thinking
- evaluation
- social impact of computation
While working on the dimensions, it proved that we had to follow a different categorization. The dimensions 1. creative problem solving, 8. systemic thinking and 10. social impact of computation are studied together with Computational Thinking and approaches to Computational Thinking. The dimensions 3. problem solution transfer and 6. Generalization were included in the new dimension pattern. A new dimension, decomposition was added.
The dimensions of Computational Thinking that will be studied are the following
- algorithms
- pattern
- logical reasoning
- abstraction
- decomposition
- evaluation
The categorization follows Barefoot Computing at school
Barefoot Evaluation
What is evaluation?
Evaluation is about making judgements, where possible in an objective and systematic way. Every day, we make judgements about what to do and what we think, based on a range of factors.
When considering a new digital device for the classroom, there are a number of criteria: operating system, portability, memory size, screen size, ease of use, warranty, etc.
After evaluating the options, laptops might be judged as the digital device most suitable for a classroom.
Why is evaluation important?
Evaluation is about judging the quality, effectiveness and efficiency of products, solutions, processes and systems. We ascertain whether they’re fit for purpose.
One approach could be to consider specific criteria, e.g. a design goal or specification, or user needs. In computer science, evaluation is systematic and rigorous.
What does evaluation look like in the curriculum?
Evaluation is something that occurs daily across schools. Pupils evaluate their work; teachers evaluate lessons, learning and progress. Self- and peer-assessment can help to develop children’s evaluation skills, as they make judgements using success criteria and consider potential improvements.
Gymnasts may have a list of ‘good’ things to aspire to – perhaps certain moves in a routine, perhaps landing on two feet. In Language, the success criteria for a pupil’s written work might be the correct use of capitals and full stops, or the inclusion of adjectives and adverbs. Children express preferences more readily and clearly. They may recommend a book to a friend, explaining why they think it will be enjoyed, having made a judgement about what type of books might be favoured. The design and technology curriculum makes use of evaluation as pupils work through the design–make–evaluate cycle.
An example of peer evaluation, using stars, a wish, “what went well” and “even better if”.
More resources on Evaluation by BBC
BBC Evaluating
Evaluating solutions
Before solutions can be programmed, it is important to make sure that it properly satisfies the problem, and that it does so efficiently. This is done through evaluation.
What is evaluation?
- is easily understood – is it fully decomposed?
- is complete – does it solve every aspect of the problem?
- is efficient – does it solve the problem, making best use of the available resources (eg as quickly as possible/using least space)?
- meets any design criteria we have been given
If an algorithm meets these four criteria it is likely to work well. The algorithm can then be programmed.
Failure to evaluate can make it difficult to write a program. Evaluation helps to make sure that as few difficulties as possible are faced when programming the solution.
Why do we need to evaluate our solutions?
What happens if we don’t evaluate our solutions?
Once a solution has been decided and the algorithm designed, it can be tempting to miss out the evaluating stage and to start programming immediately. However, without evaluation any faults in the algorithm will not be picked up, and the program may not correctly solve the problem, or may not solve it in the best way.
Faults may be minor and not very important. For example, if a solution to the question ‘how to draw a cat?’ was created and this had faults, all that would be wrong is that the cat drawn might not look like a cat. However, faults can have huge – and terrible – effects, eg if the solution for an aeroplane autopilot had faults.
Ways that solutions can be faulty
We may find that solutions fail because:
- it is not fully understood – we may not have properly decomposed the problem
- it is incomplete – some parts of the problem may have been left out accidentally
- it is inefficient – it may be too complicated or too long
- it does not meet the original design criteria – so it is not fit for purpose
A faulty solution may include one or more of these errors.
Visit the website by LTEE
Learning Technology and Educational Engineering Lab, University of Aegean
Σύνδεσμος Moodle
eTwinning
