Guide
Book for Completion of
A
Level Computing Project
This booklet contains directions and tips for completing your A Level Project.
As with the AS project, you are advised to read it through before commencing your project and then to refer to it regularly to ensure you are producing work that is appropriate to the coursework requirements.
The project, and hence this guide, is broken down into sections. The work required and the subsequent documentation for each section is given alongside extracts from the Mark Scheme detailing what is required for top marks in the section (we have assumed you will only be aiming for the top marks).
The project is assessed on the quality of the project write-up – indeed the examiner will never see your implementation. It is important to get something working and then to leave time to document it well.
Your project should be handed in with all sections completed, bound in the order listed on the sample Project Contents on page 2. Your content page should look exactly like this – though the page numbers need to be completed by you.
Remember
your A Project is worth 16 2/3% of your A level
Project
Contents
|
Software Design |
|
|
System Specification |
|
|
Detailed Design |
|
|
|
|
Implementation and Testing |
|
|
Software Implementation |
|
|
Software Testing |
|
|
System Testing |
|
|
|
|
Evaluation |
|
|
Evaluation |
|
Further Enhancements
|
|
|
|
|
|
System Documentation |
|
|
Appendix A: Technical Documentation |
|
|
Appendix B: User Documentation |
|
|
|
|
Quality of English
The project report is a technical document – all too often, it can be spoilt
by poor use of English. The quality of English is assessed for some sections
and you will lose marks if you do not take care with spelling and grammar.
These sections are shown with a double border around the extract of the mark
scheme.
In particular, please take note of the following three pieces of
advice:
· Never write the word I in the project write-up.
For instance, do not write:
û I went to the shop and I asked the following questions
or û I think that I will design a system in Access because …
Instead, do write in the third person
ü The end-user was asked the following questions in an interview
or ü The system will be designed using Access, this has the following advantages …
· Never write down definitions of Computing and Information Technology terms you would expect the examiner to understand - do write down definitions of terms that are particular to your project.
For instance do not write:
û Analysis is the process of finding out about the current system
Because the examiner knows this but do write:
ü For each order, the system must produce a Picking List. A Picking List is the list given to a packer in the warehouse telling them what items have are to be collected together into one parcel to complete a customer order.
· Never hand something in that you have not read and corrected yourself first. A spell checker only performs validation checking to spot words that are invalid - data that gets through the spell checkers is not necessarily right. You must read it through and validate - if you ask nicely, a friend or relative might also do this for you, sometimes it is easier for someone else to find errors. Your teacher should never be the first person to read your work.
Section 1. Software
Design
1.1 Confirm [or Modify], with
Justifications, the system specification identified in AS project
Produce a list of
intended outcomes and specify the hardware and software requirements
The A project gets marked and moderated independently of the AS project
so commence by writing an introduction re-introducing the problem and its
context.
Specify (again) your system's requirements, including any modifications
in light of your evaluation of your prototype. Your requirements should be
split into three sections; Input, Processing and Output. Identify (with, say,
bold) the processing requirements that will require algorithmic programming
[which will be the core of the A project].
Give a detailed account of the hardware that will be required for your
completed system (discussing alternatives, costs and justifying your choices).
Similarly, discuss and justify software that will be required (either purchased
or written). This would be a good point to consider/discuss whether you are
going to program stand-alone Access clients and/or PHP based web clients.
In
general, it is a good idea to narrow down the scope from your AS project.
(6 marks) The student has clearly specified and justified, the input, output and processing requirements for the proposed system including the interface with the manual system, if appropriate. Hardware and software requirements are included and justified. There is evidence that alternatives were considered.
1.2 Produce a detailed design
for the software to be implemented
Using appropriate tools
produce a detailed design
Your detailed design should include:
- Data flow
charts presenting an overview of the system design (can re-use diagrams
from AS is appropriate). These diagrams will identify the processes that
need to be implemented.
- Form
designs } can again re-use from AS if
appropriate
- Report
designs }
- Specification
of Normalised tables (clearly showing key
fields, relationship and normalisation to 3NF)
- Table
designs, including Field Types and Validation to be implemented
- Design of
Queries to be implemented (state purpose, where used and SQL definition)
- Design of
Module code (see below)
- Discussion
of alternatives considered throughout (you cannot obtain top marks in this
section without discussing alternatives)
DO NOT use any macros – it
is easier to document if Macros are implemented as Module code.
Module design
- For each
Form, identify the events and associated processing
E.g.
|
Form |
frmCustomers |
|
|
|
|
|
|
Control |
Event |
Processing |
|
form |
Load |
Initialise cboCustCode
to the first CustCode in table Load details of first customer in table Update form display with details |
|
btnClose |
Click |
Save current customer details Close form |
|
cboCustCode |
AfterUpdate |
Determine if CustCode chosen exists if exists then Search for
customer details Update form
display with details |
|
btnInsertCust |
Click |
Validate the new customers details if valid then InsertCust, generating a new CustCode Update form
display with details |
- Identify
the subs and functions required to implement each event handler and
clearly document there inter-dependencies (show values/parameter passed in
to subs/function and values passed as results of functions)
E.g.
- Design the
key algorithms using Jackson Structured Diagrams (consider efficiency of
algorithms)
Throughout
the design, note any alternatives you considered and justify your chosen
solutions
(7 marks) The method of implementation has been specified in detail using appropriate tools and documentation methods. There is evidence that alternative methods of implementation have been considered and that the chosen method is appropriate, justified and matches the outline design.
Section 2. Implementation
and Testing
2.1
Implement the software
Coding
Modify
your prototype to produce a fully working system. Implement all event-handlers,
queries and module code.
Pay
particular attention to using good programming style (object/variable names,
layout/tabbing, comments) and technique (parameters, recursion, error
checking).
(10 marks) Well-structured coding making good use of the facilities of the
chosen software tool. The completed implementation of the method of
solution is effective and contains no obvious defects. Appropriate software
techniques have been employed.
2.2 Test
and evaluate the software components
Testing
of software components
Software
testing involves testing your module code works – in normal, extreme, special
and erroneous conditions.
At
this stage it is not necessary to test your event handlers (this will be dealt
with in system testing) rather software testing can be restricted to the
general module subs and function which should be carrying out the main
processing of data.
Select and
describe initial test data for files – ensure, and make clear that, your data
is representatives (e.g. if customers with more than 20 orders outstanding are
treated differently then ensure you have at least one customer with 20 orders
outstanding).
Plan a sequence of
tests for each sub/function, starting from the bottom up - test routines which
are not dependant on any others first (i.e. test using a post-order traversal
of your function hierarchies). Include tests that demonstrate the correct
interaction of modules (e.g. can you search for a customer after it has been
added, does search return an appropriate results when searching for a customer
who has just been deleted).
NOTE: This is software
testing not system testing – test your processing routines, not your event
handlers (there should not be any interesting code to test in any Event
Handlers).
Example Test Plan:
|
Module |
Test |
Test Type |
Expected Result |
|
modCustomers |
|
|
|
|
genCustCode |
debug.print genCustCode("T") |
Normal |
"T201" |
|
genCustCode |
debug.print genCustCode("X") |
Erroneous |
"" |
|
genCustCode |
debug.print genCustCode("P") |
Extreme (no P custs currently exist) |
"P001" |
|
insertCust |
insertCust ("T", "Chan") fileDump |
Normal |
print out of
file with customer T201 Chan added |
|
insertCust |
insertCust("P", "Aardvark") fileDump |
Extreme |
print out of
file with customer P001 Aardvark added at the beginning |
To carry out
testing, it is a good idea to code your test plan as a test suite – a program
that you can run to produce the expected results and then save/print the output
as evidence to include in your project reports.
All evidence
should be hand annotated to explain its significance.
(8 marks) The student has
produced a clear test plan and has carried this out for all parts of the
software. Full use has been made of appropriate techniques and tools. An
appropriate range of test data has been used. There is clear and systematic
evidence in the report that the test plan has been carried out and the outcomes
evaluated. The functionality of individual components and the effectiveness of
their interaction is demonstrated.
2.3 Test the
implemented system
Design
and implementation of a system testing plan; user testing
Design test data
and tests to check that your system meets your requirements (set out in 1.1). Document each test with evidence
(possibly screen dumps) of success or failure.
Consider performance
testing - your system may work but how effective
a solution is it. Consider how to test performance indicators such as user friendliness and speed of processing. Are there any other
performance indicators for your project?
The best method of getting feedback on performance indicators is to get your end-user to use your system.
(4 marks) A test plan has been
used and justified; test outcomes are clearly stated; all parts of the system
have been tested systematically, including end-user testing if appropriate.
Section 3. Documentation
3.1 Produce
technical documentation for the software produced
Technical
documentation including full maintenance documentation
This is a
stand-alone document which should be submitted as an Appendix to your project
report.
The technical
documentation should detail how your implementation has been put together.
Typically might contain the following:
Introduction
Installation
Details of Components used in
the project (name, purpose, design)
Table, (and their relationships)
Queries,
Forms (controls)
Software documentation
Purpose
of Global variable/constants
Procedure/function
specifications -detailing purpose, variables used and pseudocode
Possible common errors and how to fix them including
perhaps how to reset the system
The maintenance manual should be
comprehensive enough so that another trained programmer could fix bugs in and
further develop your system.
You may use the Access Documenter tools –
so long as you restrict the amount of superfluous information generated – and
subsequently annotate (after exporting to word) with purpose. (Without
explanation of the output produced by the documenter, you are providing no more
information for the technical support than they can generate for themselves!)
(6 marks) The student has provided full documentation for the software produced. This includes the overall structure, in addition to aspects such as the file and data structures. Code is self-documenting, and variable and procedure names are appropriate. Links are apparent and well described. Algorithms are well structured and documented. Sentences and paragraphs follow on from one another smoothly and logically. Arguments are consistently relevant and well structured. There are few, if any, errors of grammar, punctuation and spelling.
3.2 Produce
appropriate user documentation
Production
of a user guide
This stand-alone
document should be submitted as an Appendix to your project report.
Typical contents:
Introduction, Installation,
Tutorial for use, Explanation of error messages,
Possibly known problems and
their solutions
It needs to be
written at a technical level appropriate to the intended end-user. Many screen
shots of the working system should be included – it helps the examiner judge
the quality of your system.
(4 marks) The guide is well
produced and suitable for a typical user of the system. It contains details of
how the system should be used and support for when problems arise. Sentences
and paragraphs follow on from one another smoothly and logically. Arguments are
consistently relevant and well structured. There are few, if any, errors of
grammar, punctuation and spelling.
Section 4. Evaluation
4.1 Evaluation
of implementation
Evaluate
the implemented system against the original system requirements and the
identified problem
(3 marks) The student
demonstrates a clear awareness of the strengths and weaknesses of the system.
Sentences and paragraphs follow on from one another smoothly and logically.
Arguments are consistently relevant and well structured. There are few, if any,
errors of grammar, punctuation and spelling.
4.2
Further enhancements
Suggest
suitable enhancements or improvements to the implemented system
These
can be technical suggestions of your own and/or perhaps less technical
suggesting made by your end-user.
(2 marks) The student has included realistic and appropriate suggestions for extensions or improvements. Arguments are consistently relevant and well structured. There are few, if any, errors of grammar, punctuation and spelling.
Presentation
of the report
Once you have finished all the required sections, you should spend some quality time bringing the sections together into a report.
Remember it is the report that is marked - not your implementation - so the quality of the report needs to be as high as possible. Always leave a couple of days to put the final version of the report together. Your report should be word-processed.
A title page is required - do not spend much time on this and do not use any clip-art since a Coursework Cover Sheet will be given to you be your teacher to attach at the front of the project anyway. The following information should go onto the title page:
The heading: A Level Computing Project
Title of Project:
Candidate Name:
Candidate
Number: (This is not your School student
number)
Centre Name: King George V School, Hong Kong
Centre Number: 92820
Ensure that all pages are numbered (numbering pages by hand is acceptable) and that a contents page has been included.
Complete a Coursework Cover Sheet that will be given to you by your teacher.
The project should be handed in securely held together by a comb binding. Your project will not be accepted bound in any other way.
Final
Checks before having the project bound:
· Have you included all the appropriate sections, including appendices?
· Have you read it and corrected all the silly mistakes?
· Has someone else read through it and corrected all the silly mistakes that you missed when you read it?
· Has it been spell-checked?
· Is it bound properly with a Coursework Cover Sheet as a front page?
· Are pages numbered and a content page included?
· Are all printouts and test sheets properly annotated?