I am sorry put a spanner in the works but I have to criticize the ideas being presented in this unit as, 'Problem Solving' in Computer Science.
As a scientist this looks very much like teaching the 'scientific method' rather than being to do with what is called 'problem solving' in computer science. (As in the use of the term, 'abstraction', the meaning of words in other walks-of-life is quite different to the meaning adopted in CS. )
I have to ask how finding out how to build a boat actually relates to the 'problem solving' that is required in computer science?
Problem solving in computer science does not mean the same as in maths or science i.e. it is not, 'How do I build the best boat?' or 'How do I add 2 plus 2 and give the answer?' The problems that computer scientists solve are ones that the humans already know how to do. Drive a car, make an invoice, open a door when someone arrives. Work out what the weather will be like tomorrow.
Problem solving in CS is taking a known problem, e.g. building a boat or adding two numbers together and then 'solving' it by creating a valid set of instructions that the computer can follow in order to build that boat.
The problem = the job to be done, something that we already know how to do but would like a computer to perform. most of the time there is nothing remarkable about the job/problem to be solved - it is just that we want a machine to do it for nothing, over and again and in double-quick time.
Solving = analyse that problem i.e. break it down into its parts, find the algorithm that describes the flow of control and then write a valid set of correctly structured instructions that the machine can follow.
So 'problem solving' in computer science does not mean finding out how best to do the task - it simply means finding out how to automate the task for the dumb machine.
I would suggest that a more useful formulation of the algorithm for problem solving in computer science is:
- Do the task yourself so that you can see what it is made of
- Write down the steps you took
- Look for data inputs and information outputs
4a. Draw a flowchart / structure diagram and as you do so
4b. Apply abstraction, grouping the parts as sub-problems, so that you don't get overwhelmed with too much stuff.
- Translate this algorithm into whatever code language you like.
There is a tendency to think that computers are like human brains and that we are learning how to do really clever things with computers - like doing science or having insight. That is not the case. We are learning how to get computers to do really simple things that we can do. That is plenty hard enough! Okay, we know that they can be made to do really complex things like flying a plane or predicting the weather but it wasn't that computers were used to 'solve' those problems - they just do the cleverly worked out steps found by human brains. So, I would suggest that kids need to start by finding success in getting the machine to do really simple things - solving simple problems. How do I make the best boat? Whooa! Hold on there, that really is rocket science.
Try starting with, 'How do you put on your shoes and socks?' In this you will find most of the necessary stages of sequence, selection, repetition, data input (which shoes?), outputs (actions in this case) and abstraction (picking up a sock is made from many steps that are best dealt with as a sub-problem in its own right.
Okay, that then becomes too hard a problem for a kid to solve completely - there is far too much abstraction (layering) to get the robot to complete all of that.
So, go with, 'How do I get the machine to find out if a pupil can add two numbers together correctly?' There is enough in that to keep a class busy for several lessons. I've just done it. And then, 3 goes etc.
Tunbridge Wells, UK
P.S. Note the misuse of 'abstraction' in your lesson plan - abstraction, as you rightly describe elsewhere, is about the use of subroutines to keep code intellectually manageable. It is not about losing/neglecting stuff as is so often erroneously stated.