Problem Solving
Firstly an acknowledgment: this series of pages are very much based upon, and sometimes completely stolen from, what, at the time of writing, is a work in progress by a colleague here at the university - Paul Vickers. The title of the work, buy it as soon as you see it in the shops, is currently Programming for the bewildered.
Obviously, distilling into a few web pages what takes chapters of a book to explain in a clear and lucid fashion is somewhat difficult. So, the moments of clarity and understanding you might experience in what follows are thanks to Paul, the confusion and muddiness are all my fault.
You might have noticed that the title of this module is "Software Development", and what have you done so far? Some diagramming using DFDs, and perhaps some more diagramming using ERDs, last week you looked briefly at Structured English, aka pseudocode, aka PDL or Program Description Language, and this week we're looking at problem solving. Perhaps not what you were expecting in a module called "Software Development". But there's a reason for that. I would imagine that everyone who has ever tried to teach programming, or more generally software development, can't help but have noticed that students all too frequently jump in and start trying to code before they've really understood the problem. Paul Vickers observes:
When they (students) ask for help it is often the case that their difficulty lies not with manipulating the programming language syntax (C, Pascal, Java, or whatever) but in understanding what it is they're trying to solve. In fact, many times they confuse their syntax-handling difficulties with their problem-solving difficulties and blame their frustration on programming itself or on the chosen programming language. Some of them then become so downhearted that they decide they cannot do computer programming and transfer to a course that doesn't require them to study it.
Heaven forbid that you think of transferring course, so that's why we're spending so much time on trying to help you understand and explain a problem before we jump in to writing programming code. In fact, the actual programming part comes last, and by then should be relatively easy since the solution to the problem should be well understood.