Getting Started

Between lower and upper sixth, A level students will typically begin their A level Computer Science projects. In this guide I will outline my recommended structure for the project and some of the common pitfalls I have encountered in my student's work.

What to work on

Finding an idea can be surprisingly difficult! In part I believe this is because students do not have a good grasp of the sheer breadth of problems that computers can tackle. To help, think about your day and what annoys you. Good problems for your project are those that :

• are tedious to solve by hand
• impossible for a human being to do in a reasonable time
• prone to human error and cause real problems if the task is done incorrectly.

If in doubt, you can always make a game! Here's a list of some ideas :

1. Rogue-like dungeon crawler (Randomly generated map)
2. Sound generator for algorave.
3. Revision/Quiz which uses feedback to suggest areas to improve.
4. Fantasy football tracker

Again if in doubt, the main thing is your implementation of the problem and how you (intelligently) use the computer to make life easier for your end-user. If you end up implementing another flappy bird or Tetris clone the world won't be poorer for it! A good idea will be one that is simple enough to implement but complex enough to expand if requiring more detail.

What to do this Summer

Step 1 : Initial Analysis of Problem

Before we begin coding we should answer (and write out!) the following points. I would recommend doing this in an online editor such as Google Docs or in a Dropbox folder. Losing coursework to a computer failure is not impossible and it is a predictable enough risk to plan for!

Do so now!

1. Main problems of project
2. Bullet point list of any and all problems you may encounter in coding or implementing this idea of yours. More detail the better and endeavour to group related points together.
3. Flow charts and/or pseudocode for main algorithms
4. flow charts should focus on the core of your program not what the user sees. Too often students focus on the visuals and describe how an user will go from login screen, to main menu, to first action, next screen and so on. This is not the correct approach. Consider a game of rock, paper scissors. The flow chart for this game should focus on the user inputs, the comparison of moves and who wins/loses/draws. It should not focus on the design of the login screen!
5. Potential issues you may face
6. At this stage, this will purely be guesswork. Most likely the barrier will be lack of technical expertise. More detail the better here. As we go, we will add to this list!
7. Initial timeline for project
8. I would recommend the following :
   1. Summer - September : Initial Analysis and Design, initial prototypes
   2. September - October : Further prototypes, refinement of design.
   3. October - December : Iterative implementation and testing.
   4. January : Minimal version of program complete.
   5. January - February : User testing and feedback for next version.
   6. March : Final version of program complete.
   7. Remaining time : Redraft notes and submit.
9. Description of your Stakeholders/end-users *. Who are you implementing this project for? They don't have to be real but it can be helpful if they are. Put yourself into their positoin and imagine their needs. How will your program be used? Describe what a successful project will look like from their perspective.
10. Describe the minimum viable product (MVP) for your project.
11. What features must be implemented. List extras that can be worked on once the absolute minimum task is complete.
12. Pare back your idea to the very bone. Ambition is good but you must learn to recognise the main part of your work. In this way you won't run out of time and you will have implemented at least some form of your vision.
13. Define outcomes for success in your work for your MVP as a sliding scale.
14. Why certain goals from stakeholders are too difficult at this time.
15. Why is this problem amenable to being solved by a computer?
16. Perhaps obvious, but why should this problem be solved by computer? List your reasons and identify how you're making life easier for your stakeholder.
17. Similar tools that exist and inspiration taken for your own approach.
18. Borrowing ideas is acceptable in this project (Copying code is most certainly not!!). Look at how others have aimed to complete similar goals and what you can learn from them.
19. Hardware and software requirements.
20. Class structure for code used and why you’re using classes.
21. You will need to use a class-based structure for your code (in Python at least). Alternative approaches are acceptable however you will need to justify that the code is complex enough if done so.

Step 2 : Prototyping parts of your project

Before beginning to write the code for your project in earnest, you should learn what you're doing. To do this, I would recommend prototyping parts of your project. Specifically the parts which are hard or confusing to you. In doing so you can hopefully determine a sensible way forwards and feed this information back into the design.

For example if you are to make a game, you should explore potential libraries to implement graphics. I would recommend doing research online for tutorials relating to the tools you wish to use. Follow these carefully and try to see if you can modify the tutorial code towards your needs.

Write notes as you go!

You're trying to determine if the tool you're looking at can work for your problem,

The other side of prototyping is attempting to actual implement what you need. Maybe you're unsure on specific details on your project. By creating toy versions of your final product you can explore the requirements of your project. You will also gain some ideas about the next (and hopefully first!) version of your actual code.

Finally, you may ask - why throw away your first code base? Why not just build upon what you initially design. The answer to this is twofold. Firstly your code is awful and you know it. Secondly by starting again you should be able to structure your codebase with a better idea of your future requirements. This latter point is an excellent topic to write up in your report.

Finally...

It's worth stating that the projects that score highly are those that are written up as you go. The absolutely worst thing you can do, is focus on the coding blindly ignoring a development model or schedule.

The entire aim of this brief series of posts is to describe how to write the report whilst coding in the most efficient way possible.

In the next post we will discuss the spiral model of development and why this is ideal for A level projects.