Welcome to part 3 in a series about your AQA Computer Science A Level project. In the first two parts of this article, we’ve looked at how to get started, how to pick a project and how to go about scoring decent marks.
In this final part of the series we look at all the things that you will need to put into your write-up to help you get a good mark.
You will not be handing in your working program, simply because too many people will be doing too many different things. The only thing you have to prove your program works is your write up, so getting this right is really important.
Fortunately, AQA have a good, clear requirement specification, and they want to see your write up broken down into several sections.
Section 1 - Analysis
Official AQA guidance states that the Analysis should:
•• produce a clear statement that describes the problem area and specific problem that is being solved/investigated
•• outline how they researched the problem
•• state for whom the problem is being solved/investigated
•• provide background in sufficient detail for a third party to understand the problem being solved/ investigated
•• produce a numbered list of measurable, "appropriate" specific objectives, covering all required functionality of the solution or areas of investigation (Appropriate means that the specific objectives are single purpose and at a level of detail that is without ambiguity)
•• report any modelling of the problem that will inform the Design stage, for example a graph/network model of Facebook connections or an E-R model.
In order to achieve this your analysis should contain the following sections:
Part 1 Introduction – Problem Statement
1.1 Description of the Problem area
This means what is the field where your program is eventually going to be working? Is it in maths, geography, hotel booking, lesson scheduling, networking? What is the subject area where you program is going to be used.
1.2 Problem Definition
This means what is your program trying to do? What problem exists that needs your program to solve it.
Part 2 Research into the Problem
2.2 Description of Existing Systems
Here I would fully document two existing systems that do roughly what your program does. Document them from a computing point of view, get as may screenshots as you can and try and determine any inputs, outputs, variables, any processing that can be done from a good, educated guess at the screenshot.
For example, if a screenshot is drawing a graph, this is the output, but what was the input? Can you identify the datatypes of the input
Don’t forget to include the name of the program as well as the URL of the program, so your examiner knows it’s real.
2.3 Identification of Prospective users
Who is going to end up using the program? Are they old, young, computer literate or not? This will determine how your user interface is going to look – if you have someone who has never used a computer, your interface will need to guide them through your program step by step.
3. Client interviews.
The important bit, here is where you record all of your interviews, either as emails or as a transcript.
Part 4 Objectives of the new System
4.1 Specific Objectives
Here is where you put your numbered, specific objectives of your system. I would use some form of grid like this:
Where you give each objective an ID, and make sure they are specific (i.e. one thing only) and you have assessed whether you can measure success (does it work or not), is it achievable (can you do it) and is it relevant (is it what the user has actually asked for)
These objectives, as we have seen, are critical for completeness and for scoring high marks, so consult with your teacher when you get a list of objectives as soon as possible. If it looks like you can’t achieve some, then delete them from this list as your examiner will use this to determine your testing, your evaluation and how complete your project is.
4.2 Identification of Key Requirements
In other words, what does your program absolutely need to do, which will form the basis of your objectives
4.2 Identification of User Limitations
What can the user do without, in the time available? Users will want lots of things, which you will simply not have time to do, so here is where you list the ‘nice to have’s’ and this will come out in your interviews.
Part 5 - Models
5.1 OOAD Analysis
Here is where you start to think about any objects you might have at this stage and how they fit together, looking something like this:
5.3 ERD Model
Here is where you start to think about any database tables you might have at this stage and how they fit together and is very much ‘big picture’ looking something like this:
5.4 L0 DFD of Proposed System
The level 0 will give a rough idea of what bits of a system you will need – will you need a database, a website, a text file and how will they stick together. This is a big picture idea and will look something like this:
The level 1 DFD will look something like this and can either go here or in the design
5.5 Graph Model
If you are going to be using any graphs, then you can start to plot the edges and vertexes.
The key thing about your models is that you only include what you will be using. If you are not using a database, don’t include an ERD. I would definitely say that your program doesn’t have a database though.
Section 2 - Design
Again, the official AQA documentation states that the design should:
“communicate the design; therefore it is acceptable to provide a description of the design in a combination of diagrams and prose as appropriate, as well as a description of algorithms, SQL, datastructures, database relations as appropriate, and using relevant technical description languages,such as pseudo-code.”
In practice I would include the following sections to cover all bases:
Part 1 - Overall System Design
Tell your examiner what this section is about
1.2 Modules Used
This would be any namespaces or programming modules eg IO or SQL that you have used in your language of choice
1.3 System Flowchart
Show how the logic of your system flows OR …
1.4 DFD to level 2 of Proposed System
You need either a flowchart of a DFD to level 2 for your system. You will have done a level 0, now you need a level 1 and 2. Either this OR a flowchart – NOT BOTH.
The one thing AQA agree on is that your marks come from your program NOT your write up.
Part 2 - Data Requirements
2.2 Data Items
These are your database tables, as well as any fields, keys and datatypes.
2.3 Data Structures
These are any records, arrays, dictionaries, hashtables 2D arrays or structs that you create in your code. What are they, what do they store, what are the fields and datatypes
2.4 File Structure
If you are storing any data as files, what does the file look like. You can use an actual file if you need.
Part 3 - Programming Constructs
Tell your examiner what this section is about
3.2 Identification of Standard Data Processing Algorithms
If you are using any standard algorithms , e.g. linear search, binary search, merge sort, Dijkstra's Algorithm etc, then they go here as pseudocode.
Also any standard database algorithms eg insert, update and delete as pseudocode SQL
3.3 Identification of Custom Data Processing Algorithms
This is where you list if you are doing something clever, as your own algorithm, as pseudocode
3.3 Class or Object Definitions
If you have an OO project (and you should) then your class definitions go here – constructor definition and class scope variables only. Do not do any local variables, otherwise you’ll be writing this until the end of time.
3.3 Class or Object Diagrams
A proper OOAD diagram now, with inheritance, polymorphism, aggregation and composition. You can put this together nearer the end of your project when you have a better idea of your objects and how they work.
3.4 Class or Object Behaviour
Any methods in your classes, public, private or protected and especially if you have overloaded polymorphic methods.
4 – User Interface
Now here’s where AQA got it right. Rather than produce designs in word of what your UI is going to look like, you can now use screen captures of you actual program to show the designs. This means that this section should be one of the last to be completed.
Tell your examiner what this section is about.
4.1 Planned Data Capture Designs
Any design where users can put data into your program eg the login screen.
4.2 Planned Data Output Designs
Any section where your program is doing something and producing an output eg connecting to a database and returning the results of an SQL query.
Section 3 - Testing
This section is where you prove your program works.
You don’t need to include different tests for different types of data (normal, erroneous and extreme)
You don’t need to show test failing and fixing things
You simply need to prove that your program works.
To do this, I would use two tables:
A test plan table – that states the tests you are going to carry out, for example:
A test run table, that shows the tests being performed as well as your evidence, for example:
This is the main menu user prompt. This has displayed successfully
If you have 15 objectives, I would expect to have at least 15 tests proving each one works.
Check with your teacher to see what they want and how many tests they think you should do, remember this is proving that your program works, so testing is not only 8 marks for testing it's part of the 15 marks for completeness!
Section 4 - Evaluation
This is an awkward one. You need the following sections:
Part 1 - Evaluation of objectives
You need to go through each of your objectives and then say HOW WELL you have met your objective.
I would keep it simple and lock it down to:
MET VERY WELL – it works, all good.
MET FAIRLY WELL – it mostly works, but is a bit clunky, or bits of it don’t do what you expect
MET NOT WELL – it doesn’t work.
Again, I would use a table format like this, but check with your teacher.
Evaluation of user feedback
Next you need to get your user to evaluate your program.
You then need to evaluate their evaluation.
You need to go through their feedback and then say whether you agree or disagree with their evaluation.
It is absolutely fine to disagree with your user – they might have changed their mind, or forgotten about what they asked you do to. This project will have been running for about 8 months or so.
Finally, you have a section called future developments which is based on the evaluation of your objectives and user feedback
Analysis of objectives:
What would you do to improve the program?
How would you go about doing this?
Analysis of User Feedback:
What would you do to improve the program?
How would you go about doing this?
Section 5 - Technical Guide
Now this is not part of the specification, but AQA need to have some way of identifying if you have met all the programming requirements that will put you into Band 1, 2 or 3.
In fact the spec says this:
Students should present their work in a way that will enable a third party to discern the quality and purpose of the coding. This could take the form of:
•• an overview guide which amongst other things includes the names of entities such as executables,data filenames/urls, database names, pathnames so that a third party can, if they so desire, run the solution/investigation
•• explanations of particularly difficult-to-understand code sections; a careful division of the presentation of the code listing into appropriately labelled sections to make navigation as easy as possible for a third party reading the code listing.
So basically they want to be able to find the clever stuff that you have done so they can mark it without wading through pages of code.
They could do this by reading through your code line by line until they find evidence of polymorphism, or recursion, or dynamic queue implementation.
They would prefer you provided a section though that covers just this.
This is what I call the Technical guide and you can do two things:
Include your custom pseudocode algorithms and then provide a copy of your actual source code showing how you built the algorithm
Go through the AQA table 1, which your teacher will have, and find as many examples of code that they want and past them here.
In both cases, you need to link this to your appendices and the page numbers containing the source code.
Talk with your teacher about how they want you to present your work for marking. DO NOT leave it to the examiner to wade through.
What are these? Well this is the most important document as it will contain the following:
Appendices – part 1 Interviews
A copy of all interviews, handwritten, emails etc. You will only be using a sample of these in your analysis.
Appendices – part 2 Source Code
Every scrap of code goes here. It all needs commenting – to class and method level at least, and if you are doing something clever it will need commenting line by line, because your examiner will be looking at this.
Check with your teacher on how to present and comment your code.
Appendices – part 3 references
This is where you include any websites, forums or books that you used for help in your program, you should have the URL’s of the other programs you looked at in your analysis, your textbook, and any websites you looked at.