First the basics – the topics covered at school – GCSE computer science

looking at exam body OCR (Oxford Cambridge and RSA) syllabus

1. Computer Systems
2. Computational thinking, algorithms and programming

1 Content of Computer Systems

1.1 Systems Architecture

1.1.1 Architecture of the CPU
1.1.2 CPU Performance
1.1.3 Embedded systems

1.2 Memory and storage

1.2.1 Primary Storage
1.2.2 Secondary Storage
1.2.3 Units
1.2.4 Data Storage
1.2.5 Compression

1.3 Computer networks, connections and protocols

1.3.1 Networks and topologies
1.3.2 Wired and wireless networks, protocols and layers

1.4 Network security

1.4.1 Threats to computer systems and networks
1.4.2 Identifying and preventing vulnerabilities

1.5 Systems software

1.5.1 Operating systems
1.5.2 Utility software

1.6 Ethical, legal, cultural and environmental impacts of digital technology

1.6.1 Ethical, legal, cultural and environmental impact

2 Content of Computational thinking, algorithms and programming

2.1 Algorithms

2.1.1 Computational thinking
2.1.2 Designing, creating and refining algorithms
2.1.3 Searching and sorting algorithms

2.2 Programming fundamentals

2.2.1 Programming fundamentals
2.2.2 Data types
2.2.3 Additional programming techniques

2.3 Producing robust programs

2.3.1 Defensive design
2.3.2 Testing

2.4 Boolean logic

2.4.1 Boolean logic

2.5 Programming languages and integrated development environments

2.5.1 Languages
2.5.2 The integrated development environment (IDE)

This is the tested material. There is also a computer project they have to write which assesses computer science skills. This is broken into 2 sections: A) structure answer a problem that a computer could solve logically – pseudocode, flowcharts; B) design a solution: design, write, test, refine. In here there are some key techniques that need to known: pseudocode and trace tables in testing plus flow diagrams. These techniques can be used in systems engineering or any engineering when it comes to testing requirements.

That is the total course. So to get a good grade at GCSE level computer science you need to know the theory (part 1) and be able to produce some sort of computer program (part 2). Therefore if I were to sit the GCSE what does the exam look like and what level of programming is needed in the GCSE project.

I’ve found an example case which is the impressive project of build a snake game (https://www.ocr.org.uk/Images/77802-unit-f454-exemplar-candidate-work.pdf) – yeah snake! I would have thought this may too hard but shows how good some students are and how much I have to learn. Based on this excellent example I can see how a student leaving school with a GCSE in computing would expect to be a computer scientist/ software developer

The structure the project is 5 parts

1. Definition, Investigation and analysis
2. Design – nature of the solution
3. Software development and testing
4. Additional documentation
5. Evaluation

Totally 104 odd pages. Let’s break it down. Remember – a 14 year old did this!

Part 1: Definition, Investigation and Analysis

First, things first – Problem Definition

To be blunt – there isn’t one. The student just wanted to build the Snake game as a project. This part gives a background to the game in the form of it’s history and how it work. I love the fact he (of the sake of readability I’m going to say he but recognise it could be a brilliant she) straight of the bat – first sentence says what he’s going to and with with what coding language in this case Visual Basic 6. Once he’s covered how it works he adds a flow diagram of how snake works which is really simply summarised as a loop which continues as long as the snake head doesn’t touch the border of the screen. There is one exit which can be reached through either the snake head touching the body or the border. The importance of clearly describing how the program starts and finishes is really well done and I can imagine the examiner really pleased to see such clarity of thinking. He shows

Summary – game description -> game flow diagram

He then goes about setting up a user group which he defines as 6th formers in his school. He defines an interview questionnaire and quickly gets to the interview responses (I love the fact he write “I shall compile all the sensible responses” suggesting that all the responses weren’t sensible which you can imagine when asking 17-18 year old their opinion on Snake – a game. Importantly this piece highlights the importance of having a group of people that you can get information from to test ideas. This is crucial when developing a product even if the student purely wants to copy a game he likes a group of people to share and check ideas are essential to checking the system.

The student then presents an analysis of the interview and after considering all the feedback comes up with a set of basic wants described as requirements. From these requirements he reinterview the user group with more detailed questions about each basic requirement to gain more clarity. He shows screen shots to help the user group give more feedback. Producing visuals really helps to change the words into designs that can then be built and cut down on misunderstandings.

Now, it’s important to just stop at this point and have a think about what has been achieved so far. He has got an idea – rewrite the Snake game with new features that he has got from the user group expressing the generic game with a flow diagram. All of these points don’t involve any knowledge of programming. What is being setup here is a complicated bit of work to build. The importance here is the clarity of thought and capture.

The next part is specifying the hardware and software requirements which in this case are Windows 95, Visual Basic and a standard PC machine from around 1995 by the looks of it.

Section 2 – Design – nature of the solution.

Design objectives

The design is broken down into 1) aesthetic considerations, 2) input considerations, 3) Processing considerations, and 4) output considerations. These 4 parts describe in detail how the program will work. Again there is clarity in how it would work. It’s really good design. Design is not about drawing but about expressing things for understanding. He gets the user group to sign off the detail, system requirements. Now, clearly getting users to sign requirements doesn’t really happen in real life but it’s a really good example of getting users (stakeholders).

The student then writes an Interface Design 1: Level Selection Screen. As he’s using Visual Basic he’s describing the form and its content where boxes and labels are objects in the program. After this design he goes back to the users and get their feedback on the screen – this is really good development practice.

The next stage is the Test strategy – Test plan and the student talks about white-box testing and black box testing. The test plan really helps to think how about each component will interact with buttons, objects on the screen to the point through the end point. This is something that I think I’m not very good at as I want to just get with things and I’ll work out the details as I develop the system a bit like having a block of marble starting with an idea and then seeing how it goes. Being disciplined to create these documents and create the visibility of how it may work is a crucial aspect