A software development journal。

The third document is an example.

Qualification
Accredited
A LEVEL
COMPUTER
SCIENCE
H446
For first teaching in 2015
Project setting guidance
Version 1
www.ocr.org.uk/computerscience
A Level Computer Science
Project setting guidance
A LEVEL
COMPUTER SCIENCE
Introduction
Setting the level for candidates
Choosing a suitable project
Idea generation
Suitable project examples
Appraising initial project ideas
Supporting candidate project choice
Projects with broad scope
Project with limited scope
Project advice from OCR
Suitable Programming Languages
Additional approved languages
Graphical User Interfaces (GUI)
Project choice and language selection
Project and Language combinations
Data Handling
Web-based Data Handling
Mobile Apps/Games
Games
Simulations
Robotics
Advice on undertaking the Programing Project
Using stakeholders
Stakeholders and Analysis
Stakeholders and Design
3
3
3
3
3
3
3
4
4
4
4
4
4
5
5
5
5
5
5
5
6
6
6
6
6
Stakeholders during Testing
Stakeholders during Evaluation
The Iterative process
Preparation of Candidates
Project idea generation
Indicators of projects with sufficient depth
Persistent data storage
Programming Paradigms
Interfacing with hardware
Use of Libraries
Algorithms and Data Structures
Networking and Internet of Things
Scope/Depth check
Indicators of projects with insufficient depth
MS Access and MS Excel
Web Based Projects
Use of visual programming
Sample project ideas
Adaptive quiz games
Mobile Phone Apps
Stealth Game
Scientific Simulations
Scoring Systems
Candidate Sample Work
2
6
6
6
7
7
7
8
8
8
8
8
8
9
9
9
9
9
9
9
10
10
10
10
11
© OCR 2018
A Level Computer Science
Project setting guidance
Introduction
 Complex Games (e.g. may involve play against the computer)
 Simulations
The A Level Programming Project gives candidates the opportunity to go through
the process of developing a substantial piece of software. In order to be able to
access the full range of marks available, candidates need to develop a project with
enough scope and depth to allow them access to the upper mark bands for each
section of the marking criteria.
 Automated scheduling/timetabling
 Online multi-user websites
The following projects give examples that may limit the scope of the solution and
thus the ability to access higher mark bands:
This guide aims to give an overview of what makes a project suitable. This guide
should be used to support and guide project choice, rather than be used as a check
list for projects.
In Computer Science, many projects which may lack initial scope can be reviewed
and developed to enhance this scope. This guide should help to show where and
how early ideas may be developed to create suitable choices for A Level project.

Multiple Choice Quizzes

Simple data storage and retrieval

VBA projects

Simple ‘single player’ games
We would suggest that a candidate tries to create a range of initial ideas for project
titles and then reflects back on which seem the most appropriate and engaging for
them.
Setting the level for candidates
It is important to appreciate that weaker candidates can still score well by
completing projects with a smaller scope.
Appraising initial project ideas
Stronger candidates will probably naturally select larger projects – and should be
encouraged to follow these ideas. It is still possible to obtain the upper mark band
with a project that may not fully address the initial scope.
Once a candidate has defined some project titles, it is worth asking them to create a
short summary of the project. This could include things such as:
•
Stakeholders
•
Potential research avenues
Choosing a suitable project
•
Data processing needed
•
Current problem/initial ideas for a solution
Idea generation
•
Programming Language(s) to be used
Candidates must choose a project individually. Whilst this may initially seem
challenging for a candidate, the scope and flexibility of the specification does not
limit any particular project ideas.
•
Ideas for a suitable GUI
The key to the project is ensuring that the candidate is confident in their ability to
solve the problem. Scope may be refined as the project develops.
Once a candidate has created these summaries, they will be better placed to make
an informed choice as to which project they wish to engage with.
The key to the project is that it allows candidates to create a substantial coded
element as part of the solution created.
Supporting candidate project choice
As a teacher, you are able to support your candidates towards choosing suitable
ideas for their project. You are allowed to facilitate project choice, but should not
give them pre-defined project titles or ideas.
Suitable project examples
The following are examples of suitable projects. It is not meant to be a definitive list,
and we include more ideas later in this guide, but could be used to promote idea
generation by candidates:
3
© OCR 2018
A Level Computer Science
Project setting guidance
It is important that project choice is driven by the candidate.
Suitable Programming Languages
Projects with broad scope
The focus at A level is for candidates to create a substantial coded solution using a
textually-derived high-level programming language.
It may be that a candidate’s project idea has massive scope, in which case you can
suggest limiting the scope, and maybe identifying features which could form part of
a “wish list”.
A list of pre-approved programming languages is included within the Specification
in Section 5e.
OCR allows a wide range of languages, some of which are not listed within the
specification. Where a candidate wishes to use other languages not listed within
the specification or within this document, you must seek confirmation that it will be
accepted by OCR before commencing the project.
It is important that candidates appreciate the time constraints that they will have,
and that the project does not become cumbersome.
Project with limited scope
Additional approved languages
Some candidates may struggle with identifying a project that lends itself to
decomposition and multiple development cycles. However, many of these ideas
may be developed quite easily, which in turn increases the scope of the problem.
The following list of languages have been approved by OCR for use within A Level
projects:
Where possible, try to support candidates in developing the idea that they engage
with most. This supports their motivation as they develop the project.
OCR does not provide project titles. However, we do support teachers in identifying
suitable project scope. OCR will support centres in identifying where project
proposals may need more development, or where a candidate’s proposal appears to
allow full access to the mark bands.








Where a centre wishes to gain feedback, candidate’s proposal(s) should be collated
into one single document.
Graphical User Interfaces (GUI)
Each proposal from a candidate should include:
It is a requirement of the specification that candidates create an appropriate GUI.
However, there are rare circumstances where this might not be appropriate.
•
•
•
•
Should a candidate wish to create a program that is more suited to a command line
interface then you must receive prior authorisation for this from OCR.
Project advice from OCR
Title and brief overview of the project
Programming Language(s) used
Main project objectives/success criteria
Why they think this is a suitable project
Swift
NodeJS
Haskell
Unreal/Unity (via C# and C)
Lua
Robot X
Monkey X
JavaScript (likely to be used in conjunction with HTML/CSS/MySQL/PHP)
Requests should be emailed to: ComputerScience@ocr.org.uk
The file should then be emailed to: ComputerScience@ocr.org.uk
Please note we will only be able to offer guidance on project ideas – and the final choice
of project is the centre’s responsibility.
4
© OCR 2018
A Level Computer Science
Project setting guidance
Project choice and language selection
for client-side and PHP/ASP for the server side, plus CSS for the interface).
Another consideration is the requirement for paid hosting services or getting the
school’s IT departments to run a server.
There is no ‘best’ language to use for A Level projects. The choice of language(s)
used will be dependent on:
Possible languages: HTML5/JavaScript/PHP , VB/ASP, Java, SQL
 The project scope
 Candidate skill level/aptitude
 Level of familiarity
Mobile Apps/Games
Whilst these may initially seem easier to do computationally than desktop
applications, mobile apps require the knowledge of mobile APIs and server
connections.
Some candidates may be confident in attempting a project using a language that
may not be taught within the classroom. Some may wish to choose projects that
solely use the language they are taught.
Candidates will also need to consider testing considerations on the devices that the
app/game is designed for.
Where candidates wish to engage with languages that they are not familiar with –
this should be taken into consideration. Learning a new language is fun, but may
slow a candidate’s progress down.
Possible languages: Objective-C (IOS), Java, Python (via SL4A) for Android, Java for
Blackberry, HTML5 for Windows Phones, Django (based on Python), and SWIFT for
Apple based OS.
There is no requirement for all candidates to use the same language for their
projects. We welcome a diverse range of projects and language use at A Level.
Games
Project and Language combinations
Games tend to be the more popular choice at A Level as they inherently tend to
spark creativity. However, a well created and coded game is a significant challenge.
We would recommend that any games are focused on quality over quantity.
We offer the following suggestions, linking project ideas to suitable languages.
This is suggested guidance only, and not a definitive requirement.
A well-functioning single level game is likely to lead to higher marks than a massive
game which is very simple or has significant flaws. Choice of IDE will be key.
Data Handling
Candidates should be reminded that they are assessed on their coded solution. A
focus on graphics and artistry will not solicit credit. Where possible, sourcing free
graphics for use is a more efficient use of time!
These projects are relatively simple computationally, and often conceptually
similar to traditional ICT database projects. This may be compensated for by a lot
of validation checks and sophisticated data structures. There are lots of resources
for this family of project, but this type of software is going extinct in this connected
world.
Possible languages: C#, Python, C++, Objective-C (MacOS), Java, JavaScript,
Monkey X
Possible languages: VB, Python, C#, C++, C, Objective-C/Cocoa and Delphi (VB and
Python seem to be more popular)
Simulations
Simulations (e.g. Planetary Interactions, Bacteria growth rates, population modelling)
have been growing in popularity at A Level, particularly with those studying maths
or physics at A Level in conjunction with Computer Science.
Web-based Data Handling
Projects of this style tend to be employment-oriented. Web standards change all the
time, and these projects often require knowledge of two languages (e.g. JavaScript
5
© OCR 2018
A Level Computer Science
Project setting guidance
Stakeholders and Design
Whilst these programs can be designed in a wide range of languages, there are also
more focused languages, often specifically designed for this purpose.
Stakeholders can provide valuable interaction during the design process. Stronger
projects tend to seek feedback on initial designs and use the feedback mechanism
to refine the initial ideas to a final set of designs.
Possible languages: MatLab, R, Prolog, Haskell, Python, J
Robotics
Where interactions are limited, designs can often not anticipate problems which
then only become apparent at a later stage which causes issues within the
development of the project.
Robotics programming is becoming very popular. Robotics programming often
includes a level of artificial intelligence with it, and thus can create excellent project
choices. Robotics projects may be carried out physically or virtually dependent on
the resources available to the school.
Stakeholders during Testing
There are many environments which allow candidates to program and simulate
robotics using high-level textually-derived programs.
Stakeholders will provide valuable feedback, both during developmental testing,
and also for the final evaluative testing.
Possible languages: C, C++, Python, Robot X
Projects that do not engage with stakeholders for testing can struggle to generate
realistic testing feedback and thus fail to highlight usability issues or functionality
problems.
Advice on undertaking the Programing Project
Strong interaction with stakeholders during iterative development will increase the
chances of creating a successful end product, and provide significant interaction
evidence which can then be used within the Evaluations.
Using stakeholders
Stakeholders during Evaluation
The move to use stakeholders, rather than finding a ‘real’ end user should help speed
up the process of project identification. However, effective use of stakeholders to
provide feedback and ideas cannot be understated.
Engagement with stakeholders for evaluation of both iterations and the final
product will provide the candidate with much more evidence on which to draw
conclusions.
For instance, a game which interests the candidate may also interest people of
similar age groups. They could then look to expand their stakeholders to include a
wider set of demographics.
Stakeholders are likely to be able to provide a more critical review of each iteration,
or of the final product. This can then be combined with the testing results to build a
far more convincing set of evaluations.
Stakeholders and Analysis
The Iterative process
Stakeholders will be able to guide and provide additional requirements for the
project in the analysis stage. Where stakeholders are not used well, it can lead to a
very blinkered view of the project. This then reduces the amount of discussion that
takes place within the analysis.
A Level projects should require multiple iterations to create a product from
conception to completion.
We provide the following cycle which is likely to take place within the candidate’s
project.
If discussion and exploration is limited, justification of success criteria can become
shallow. The success criteria may then also not be broad enough and explore the
full potential of the project scope.
6
© OCR 2018
A Level Computer Science
Project setting guidance
Preparation of Candidates
We would suggest that candidates are familiar with the following before starting the
A Level Programming Project.
1. The iterative process for creating their projects
2. The programming techniques listed within the specification
3. Understanding the marking criteria and requirements of the Programming
Project
4. Guidance on identifying/selecting a suitable project
For candidates who struggle to identify projects, or for weaker candidates, it is
possible to start with a project which has narrower scope, and develop it as progress
ensues. A less ambitious project can still score well.
Encouraging candidates to document their development failures and corrections is
also encouraged. This will provide much more evidence for justifying the directions
candidates chose during their project.
Project idea generation
One way you can stimulate ideas and discussion around projects ideas is to use the
following method:
•
Success criteria
• What will a successful solution do
Planning and design
• Pseudocode, Flowcharts, DFDs, Class Definitions/UML etc.
Development
• Narrative of steps taken
• Annotated Code
• Discussion of methodology
Testing and remedial actions
• Narrative of changes made
Evaluation
• Link to success criteria
• Evidence of success or not
•
•
•
•
•
•
Have a ‘brainstorm’ session with the group to create generic ideas in conjunction
with this guidance document and the specification
Ask each candidate to then use these ideas to create a list of 10 to 15 projects
The candidate then selects their Top 3 preferred ideas
Develop a short proposal for each of those three ideas
Discuss the final project proposal within the group
Have a vote across the class on each candidate’s Top 3 suitability
Pick the one they feel most confident in and submit to OCR for review.
Indicators of projects with sufficient scope
The following list is not meant to be a checklist of requirements. If a project includes
one or more of these indicators, then it is likely to be able to provide suitable scope
for an A Level project. The more indicators that exist – the stronger the likelihood it
would be suitable.
7
© OCR 2018
A Level Computer Science
Project setting guidance
Persistent data storage
Candidates will not be penalised for the use of libraries as use of libraries to tackle
parts of their problem is best practice. Candidates must still ensure that there is a
significant self-coded element to their project, and this is usually achieved through
the code needed to interact with these libraries within their project.
Most programs will need some form of persistent storage.
This may be as simple as storing user preferences or may be as complex as storing
large amounts of data to be analysed and generate reports. Candidates will be
expected to choose suitable methods of storing this data.
Sensible choice and use of libraries can be an indicator of a good level of scope in a
project.
In some cases, a simple text file or CSV is sufficient whereas in others it may be
appropriate to use storage methodologies such as JSON, XML or SQL. More complex
data storage can be indicative of a project with more scope and depth.
Candidates must be reminded to clearly reference where libraries are used.
Programming Paradigms
There is no requirement for candidates to reinvent the wheel! If a program requires
sorting of a data structure, then a candidate deserves no less credit for using a
language’s built-in sort routine (as a professional programmer likely would) than if
they code their own sorting algorithm.
Algorithms and Data Structures
There is no set paradigm for the project. Candidates may choose a procedural
approach but others are equally acceptable. Some projects may be suited to objectoriented, functional or logical programming paradigms.
Similarly, if a required data structure is offered by a language a candidate would be
well advised to use them, rather than recreating them.
Whilst by no means a requirement, a candidate choosing an object-oriented
paradigm is a good indication that the project has good scope.
Where the project has scope for the candidate to demonstrate programming
techniques or algorithms from the A Level Specification in their chosen
methodology, this too is an indication of a good level of depth and scope. They may
also use techniques specific to the language.
For example, a candidate programming in an object-oriented language may
structure their program using a model-view-controller pattern, a candidate creating
a web-based project may use AJAX for improved responsiveness.
This said there will be the need for algorithms that aren’t available natively. These
might be established algorithms such as Dijkstra’s Shortest Path or MinMax which
the candidate needs to implement or an algorithm the candidate has had to devise
for themselves.
Likewise, existing data structures may need to be adapted to best suit the project.
A project where a candidate shows clear thought into developing their data
structures and algorithms and using them alongside or integrating them with preexisting data structures and algorithms is indicative of good project scope.
Interfacing with hardware
Using the algorithms contained within the specification are a good starting point for
project ideas, were appropriate.
Some candidates may choose to interface with particular hardware such as sensors,
or with features on mobile devices, such as QR scanners or cameras.
Networking and Internet of Things
Projects that do this are likely to need to access libraries/APIs which is a good
indicator that the project has sufficient scope.
Projects can often have their scope broadened through the use of interaction across
a network.
Use of Libraries
For instance, a simple two-player game can be developed by allowing network play.
Similarly, there are many good projects that can be developed using the Internet of
Things (IoT) and beyond.
Libraries allow candidates to add functionality to their projects that they may not
have the time or expertise to code themselves.
8
© OCR 2018
A Level Computer Science
Project setting guidance
Web-Based Projects
Combination and utilisation of differing technologies will often provide great scope
and ideas for a programming project, and be engaging due to the potential for real
life use. For instance, creating an IoT project that affects the candidate’s day-to-day
life.
Web-based projects have the potential to have more than enough scope for A Level
but caution needs to be taken. It is easy for web-based projects to lack depth and
scope.
Scope/Depth check












Static HTML sites will limit a candidate’s access to the full range of marks.
Permanent Data Storage
Potential for OO Paradigm
Interfacing with hardware/Networks
Exporting/Linking with other software
Programs that learn/adapt over time
Games/Physics
Extended Logic Chains
Use of libraries
Use of A Level sorting/searching techniques
Combination of differing technologies
Expert Systems
Simulators
Just because a site is dynamic that does not in itself necessarily allow a candidate to
show the skills necessary for upper mark band access.
A site which just has a login page and simply retrieves and displays content from a
database is not in itself sufficient.
Use of visual programming
Visual drag and drop languages such as Scratch, AppInventor and BYOB are not
suitable to produce a program for an A Level project.
Indicators of projects with insufficient scope
Any IDE which allows pre-generation of the majority of code is not likely to allow
candidates to show enough individuality in code creation. We do not authorise the
use of IDEs where this is the case. If you are in doubt as to the suitability of an IDE,
please do contact us.
This list is not exhaustive, and highlight the most common pitfalls we see when discussing
suitable project proposals from candidates with centres.
Sample project ideas
MS Access and MS Excel
These ideas are not meant to form templates for projects – and candidates should
not just be given a list to choose from. They do however provide stimulus for
discussion and give examples of the level of project scope we look for at A Level.
Using applications such as MS Access or MS Excel and adding scripting will not
offer the depth necessary for an A Level project as they can be overly restrictive and
do not give the candidate the opportunity to demonstrate the required decisionmaking skills.
Adaptive quiz games
A candidate decides to make a revision program for candidates. It will store
the scores each candidate gets when taking a test. The system then adapts the
questions it asks according to previous performance and subject content, graphically
showing the teacher how the candidate progresses over time.
Often too much of the functionality that would be expected to be developed by the
candidate is built into these applications.
Candidates are expected to produce a stand-alone solution; this is not possible
when using these applications.
This style of project has wide scope to demonstrate appropriate skills at A Level.
9
© OCR 2018
A Level Computer Science
Project setting guidance
Key parts to this project could include:
Scientific Simulations
•
•
A candidate creates a program for a company. One of the tasks the company does
is analysing temperature data from boreholes to determine if they have reached the
bottom of the borehole. This is done through a complex set of calculations called
Horner correction.
•
•
Storing the candidate’s performance in a relational database
Devising an algorithm to continually learn which questions the candidate needs
more help with
Using a library to generate graphs for the teacher
Create suggestions/reports as to revision areas for the candidate
Mobile Phone Apps
The candidate wants to write an application to perform this analysis.
The candidate proposes to adhere to the company’s software engineering
guidelines whilst doing so.
Many candidates choose to make apps. One example could be a local council
requiring an app to increase awareness of mental health issues.
The app allows the user to access information regarding mental illness and allows
them to take quizzes to test their awareness of mental health issues. The app also
needs to be useable when the user’s device was ‘offline’. Once internet connection is
established again, the app must sync with the remote database.
The app contains a content management system so the council could
update the information and quizzes when they wanted. Due to its nature, the
app communicates with a central database to keep itself ‘updated’ adding
synchronisation and networking into the scope of the project.
The project is developed using the model-view-controller pattern and set up in such
a way that it could be analysed using the company’s automated testing software.
Whilst the front end of the system is relatively simple there is a great deal of depth
present. The project itself will be coded using an object-oriented approach following
an MVC (Model-View-Controller) pattern.
The calculations require use of matrices and statistical calculations. The proposal is
to integrate the functionality of specialist mathematical libraries into the coding of
the Horner Correction algorithm. A graph library will be used to help produce easily
readable reports.
Stealth Game
Scoring Systems
A candidate has a particular enthusiasm for stealth-based games. Using peers
as a user group they act as their own user and create a game which involves
sneaking past guards. Levels became more complex. The aim of the game is to
recover different objects each level. Each of the guards move around using artificial
intelligence and pathing. Each guard’s sight is affected by things such as lighting and
objects being in the way.
The candidate investigates and adapts existing algorithms to simulate the guards’
field of vision. This involves a significant amount of research and prototyping.
A school wishes to develop a Sports Day recording program.
Records are kept of each year group and event, and trophies awarded to the most
successful of a school’s four ‘Houses’.
In previous years they had used a set of spreadsheets to keep track of the scores but
this was error prone and required a lot of effort to be duplicated.
This school wants a web-based score keeping system. The system is proposed to be
coded in PHP and will run off a computer acting as a webserver on the LAN.
The game was coded in C# using a game engine. The game uses complex libraries
and learning algorithms.
Multiple users will be able to update the scoring system as results for events were
coming in. The system will instantly show whether any school records had been
broken and how each of the school’s ‘Houses’ were performing.
10
© OCR 2018
A Level Computer Science
Project setting guidance
The Sports Day organiser will be able to log onto the system on his tablet and access
automatically updated results.
The results are planned to be stored in a relational database. The front end will
use jQuery libraries in conjunction with JavaScript code. AJAX will be used to help
improve the responsiveness of the application.
The use of synchronous updating and multi-user remote access adds sufficient
depth to this project.
Candidate Sample Work
OCR produces Candidate Sample Work to help centres in both identifying and
assessing A Level projects.
The Candidate Sample Work covers a range of projects from High to Low grades,
giving ideas of how projects have been developed.
Links to Candidate Sample Work (Candidate Exemplars) may be found on the H446
webpage, under the Assessment tab.
Please note that Interchange access is required to access Candidate Sample Work.
11
© OCR 2018
The small print
We’d like to know your view on the resources we produce. By
clicking on the ‘Like’ or ‘Dislike’ button you can help us to ensure
that our resources work for you. When the email template pops
up please add additional comments if you wish and then just click
‘Send’. Thank you.
Whether you already offer OCR qualifications, are new to OCR, or
are considering switching from your current provider/awarding
organisation, you can request more information by completing the
Expression of Interest form which can be found here:
www.ocr.org.uk/expression-of-interest
OCR Resources: the small print
OCR’s resources are provided to support the delivery of OCR
qualifications, but in no way constitute an endorsed teaching
method that is required by OCR. Whilst every effort is made
to ensure the accuracy of the content, OCR cannot be held
responsible for any errors or omissions within these resources.
We update our resources on a regular basis, so please check the
OCR website to ensure you have the most up to date version.
This resource may be freely copied and distributed, as long as
the OCR logo and this small print remain intact and OCR is
acknowledged as the originator of this work.
Our documents are updated over time. Whilst every effort is made
to check all documents, there may be contradictions between
published support and the specification, therefore please use the
information on the latest specification at all times. Where changes
are made to specifications these will be indicated within the
document, there will be a new version number indicated, and a
summary of the changes. If you do notice a discrepancy between
the specification and a resource please contact us at:
resources.feedback@ocr.org.uk.
OCR acknowledges the use of the following content:
Square down and Square up: alexwhite/Shutterstock.com
Please get in touch if you want to discuss the accessibility of
resources we offer to support delivery of our qualifications:
resources.feedback@ocr.org.uk
Looking for a resource?
There is now a quick and easy search tool to help find free resources
for your qualification:
www.ocr.org.uk/i-want-to/find-resources/
www.ocr.org.uk
OCR Customer Contact Centre
General qualifications
Telephone 01223 553998
Facsimile 01223 552627
Email general.qualifications@ocr.org.uk
OCR is part of Cambridge Assessment, a department of the University of
Cambridge. For staff training purposes and as part of our quality assurance
programme your call may be recorded or monitored.
© OCR 2018 Oxford Cambridge and RSA Examinations is a Company
Limited by Guarantee. Registered in England. Registered office
The Triangle Building, Shaftesbury Road, Cambridge, CB2 8EA.
Registered company number 3484466. OCR is an exempt charity.
Module Code:
MAN00078M
Module Title
Contemporary Issues in Management
Module Leader:
Catherine Botting
Open/Closed Assessment:
Open Resit
Maximum Word Count:
3,000 words
Release Date:
TBC
Submission Deadline:
TBC
Weighting:
100% Resit
Important information
A penalty of five marks will be deducted for late submissions that are made within the
first hour after the deadline. Submissions that are more than one hour late but within
the first 24 hours of the deadline will incur a penalty of ten marks. After the first 24
hours have passed, ten marks will be deducted for every 24 hours (or part thereof)
that the submission is late for a total of 5 days. After 5 days it is treated as a nonsubmission and given a mark of zero. The consequences of non-submission are
serious and can include de-registration from the University.
If you are unable to complete your open assessment by the submission date indicated
above because of Exceptional Circumstances you can apply for an extension. If
unforeseeable and exceptional circumstances do occur, you must seek support and
provide evidence as soon as possible at the time of the occurrence. Applications must
be made before the deadline to be considered.
Full details of the Exceptional Circumstances Policy and claim form can be found here:
https://www.york.ac.uk/students/studying/progress/exceptional-circumstances
If you submit your open assessment on time but feel that your performance has been
affected by Exceptional Circumstances you may submit an Exceptional Circumstances
Affecting Assessment claim form by 7 days from the published assessment
submission deadline. If you do not submit by the deadline indicated without good
reason your claim will not be considered.
Please take proper precautions to safeguard your work and remember to make
backup copies of your data. The University provides all its students with storage
space on the University server and you should save and back up any work in
progress on this server on a regular basis. Computer failure and theft of your
equipment or storage media are not considered exceptional circumstances and
extensions cannot be granted for work lost for these reasons.
Page 1 of 4
Word count requirements
The word count for this assignment is 3,000 words
You must state on the front of your assignment the number of words used and this will
be checked.
The main text for this assignment must be word-processed in Arial, font 12, double
spacing, minimum 2cm margins all around.
You must observe the word count specified in this assignment brief. The School has a
policy of accepting variations to the recommended word count of plus or minus 10%.
What does this mean for you?
Markers will mark your work up to the word count maximum plus 10% and then will
stop marking; therefore, all words which are above the word count plus 10% will not be
marked.
Where your word count is more than 10% below that specified, it is likely that this will
result in a lack of analytical depth or relevant content, which will be reflected in the
mark assigned.
What is in the word count?
The word count includes:
–
the main text, including in-text reference citations and quotations.
The word count does not include:
–
–
Executive summary.
Appendices. These may be used to include supporting data, which may be too
detailed or complex to include as a Table. They are not a device to incorporate
material, which would otherwise cause you to exceed the word limit.
Title page
Contents page
Abstract/executive summary
Tables, figures, legends
Reference lists
Acknowledgements
Page 2 of 4
Assignment:
Length 3000 words
Context
You are a senior manager of a multi-national pharmaceutical company which is one of
the world’s most established and pharmaceutical manufacturing organisations.
In its efforts to compete with disruptive rivals in the healthcare and diagnostic sector
such as Neteera and Tempus, the organisation has appointed you to set up a
challenger company which will be an autonomous division of the parent company.
The Task
The Directors have asked you to report on how the new organisation should be set up.
In this report you need to give a comprehensive view of the strategy and management
approaches including at least three of the topics covered in the module. You are not
required to cover all the topic areas featured in the module.
Critically evaluate the concepts and theories that may be appropriate to make your
new division successful from a managerial perspective. You may want to consider a
variety of contemporary issues in management aspects such as leadership, change
management, culture and managing employees. Your selected topics must be
chosen from the module.
Structure
•
•
•
•
•
Executive summary 100 words (plus or minus 10%). Not included in the word
count.
Evaluation of proposed strategy and management approaches by theme.
(Including a brief introduction) 2500 words (approximately)
Conclusions and recommendations 500 words(approximately)
Appendices
References
PLEASE NOTE:
•
Your answers should demonstrate learning from the module and be
appropriately referenced using Harvard system.
•
This is not an evaluation of the health tech or health sector. Read the task
carefully and make sure you answer what is required of you.
•
Use sources recommended in the module. If you do not use sources referred to
in the module YOU WILL LOSE MARKS.
END OF ASSESSMENT TASK
Page 3 of 4
Example Feedback Form
The York Management School
Module code: MAN00078M
Module Title: Contemporary Issues in Management
Generic marking criteria
G1: Argument
G2: Structure
G3: Use of sources
G4: Referencing
G5: Presentation
Module specific learning outcomes relevant to this assessment
[module leader please insert from module specification]
S1: Understand the dynamic of management issues in the contemporary global
organisational environment
S2: Critically evaluate a wide range of contemporary management issues by
synthesizing relevant theories.
S3: Assess and evaluate how contemporary change impacts on strategy, decisions,
behaviours, human capital and organisational performance.
S4: Demonstrate autonomous learning skills, problem solving and the ability to
clearly and appropriately communicate findings and recommendations.
Comments on assessment criteria:
The marker will insert feedback based on the generic marking criteria and module
specific learning outcomes.
Suggestions for improvement:
Date:
Marker:
Page 4 of 4
Qualification
Accredited
A LEVEL
Exemplar Candidate Work
COMPUTER
SCIENCE
H446
For first teaching in 2015
H446/03 Summer 2017
examination series
Set A – Medium
Version 1
www.ocr.org.uk/computerscience
A Level Computer Science
Exemplar Candidate Work
Contents
Introduction
3
Exemplar 2
4
Commentary
109
2
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
Introduction
These exemplar answers have been chosen from the
summer 2017 examination series.
OCR is open to a wide variety of approaches and all
answers are considered on their merits. These exemplars,
therefore, should not be seen as the only way to answer
questions but do illustrate how the mark scheme has
been applied.
Please always refer to the specification (http://www.ocr.
org.uk/Images/170844-specification-accredited-a-levelgce-computer-science-h446.pdf ) for full details of the
assessment for this qualification. These exemplar answers
should also be read in conjunction with the sample
assessment materials and the June 2017 Examiners’
Report to Centres available on the OCR website http://
www.ocr.org.uk/qualifications/.
The question paper, mark scheme and any resource
booklet(s) will be available on the OCR website from
summer 2018. Until then, they are available on OCR
Interchange (school exams officers will have a login for
this).
It is important to note that approaches to question
setting and marking will remain consistent. At the same
time OCR reviews all its qualifications annually and may
make small adjustments to improve the performance of
its assessments. We will let you know of any substantive
changes.
3
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
Exemplar 2 – Set A (Medium)
Programming project (non exam assessment)
Learners will be expected to analyse, design, develop, test, evaluate and document a program written in a suitable
programming language.
4
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
5
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
6
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
7
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
8
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
9
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
10
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
11
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
12
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
13
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
14
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
15
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
16
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
17
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
18
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
19
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
20
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
21
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
22
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
23
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
24
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
25
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
26
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
27
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
28
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
29
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
30
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
31
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
32
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
33
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
34
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
35
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
36
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
37
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
38
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
39
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
40
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
41
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
42
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
43
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
44
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
45
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
46
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
47
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
48
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
49
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
50
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
51
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
52
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
53
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
54
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
55
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
56
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
57
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
58
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
59
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
60
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
61
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
62
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
63
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
64
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
65
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
66
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
67
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
68
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
69
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
70
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
71
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
72
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
73
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
74
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
75
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
76
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
77
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
78
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
79
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
80
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
81
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
82
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
83
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
84
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
85
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
86
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
87
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
88
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
89
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
90
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
91
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
92
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
93
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
94
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
95
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
96
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
97
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
98
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
99
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
100
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
101
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
102
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
103
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
104
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
105
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
106
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
107
© OCR 2017
A Level Computer Science
Exemplar Candidate Work
108
© OCR 2017
OCR Advanced
GCE in Computer Science
H446-03/04
Unit 3
Project Advice
(Designed for use with ALL projects
which are not computer games)
H446-03/04 – PROJECT ADVICE
CONTENTS
Forward by craigndave
4
General Comments
5
Overview
5
Adopting the agile approach to software development
5
Choice of programming language
6
Project ideas
6
Desktop Data handling programs
7
Web based data handling programs
7
The user
7
About this document
8
Analysis (Max 10 marks)
9
Description of the problem
10
An outline of the project
10
Stakeholders
10
Identification of all the stakeholders
10
Justification of how the problem can be solved by computational methods
11
Research
12
Features of your proposed solution
13
Hardware & Software requirements
13
Success criteria
13
H446-03 Project Advice Booklet – Page 2 of 32
Evidence Do’s and don’ts checklist
14
Design (Max 15 marks)
15
Structure of the solution
16
An overview of the structure of the solution (a systems diagram)
Decomposition of the problem
16
17
Proposed screen designs and usability features
17
Detailed summary of the process including key variables and structures
17
Test data for development
18
Algorithms
18
Test data for development and alpha testing
19
Sign off the proposal
19
Evidence Do’s and don’ts checklist
20
Developing a coded solution (Max 25 marks)
21
Iterative development of a coded solution (Max 15 marks)
21
Testing to inform development (Max 10 marks)
22
Evidence Do’s and don’ts checklist
24
Evaluation (Max 20 marks)
25
Testing to inform evaluation (Max 5 marks)
25
Testing
25
Evaluation of solution (Max 15 marks)
27
Evidence Do’s and don’ts checklist
29
project hand in checklist
30
H446-03 Project Advice Booklet – Page 3 of 32
FORWARD BY CRAIGNDAVE
This project advice is designed to be a one-stop-shop for all the guidance you will need to complete your
unit 3 programming project.
We have done the hard work, we have been through all the advice, tips and guidance documents from
OCR, read in detail past examiner reports, looked through numerous text books, read up on clarification
documents and distilled all this information into one handy place: THIS DOCUMENT!
We also bring our many years of personal experience from our own classrooms to this document, we
know what makes a successful project, and we know what advice to give our own students to make sure
they are best equipped to get the top marks.
In the first time through on this new qualification both myself and Dave received very positive praise on
our marking of the projects and the marks we submitted were unaltered:
“The marks were considered to be in line with the national standard. Full credit to the centre for a
professional performance with the first attempt at a new specification.”
(Craig’s moderator feedback)
“The centre have appreciated the requirements and are able to apply them realistically.”
(Dave’s moderator feedback)
We hope these comments gives you confidence in this document, read it all, follow its advice carefully
and you will find yourself fully supported during your project.
In addition, make sure to check out our play list titled “A level: OCR Unit 3 Project Advice” on our
CraignDave YouTube channel which contains a series of videos providing additional advice and guidance.
Note: This document has been written specifically with the aim of helping students who are producing
programming projects which are not game related. If you are producing a computer game of any sorts
please use our other version of the project advice.
Best of luck!
Craig & Dave
H446-03 Project Advice Booklet – Page 4 of 32
GENERAL COMMENTS
OVERVIEW
The programming project is a major part of the A’Level course. It is worth 20% of your final grade.
You are required to demonstrate your ability to analyse, design, develop, test, evaluate and document a
complete program written in a suitable programming language (see below for a list of languages you are
allowed to choose from).
It is important that the nature of the problem you choose to solve allows you to demonstrate the full
range of skills and techniques required in the mark scheme. Trivial problems, regardless of how well you
solve them and write them up will not be able to provide you the right evidence (there is guidance
below on the appropriate project ideas).
ADOPTING THE AGILE APPROACH TO SOFTWARE DEVELOPMENT
It is stated by the exam board that you are expected to “Apply the computational approaches identified
in Unit 2 to a practical coding problem and apply the principles of an agile development approach to the
project development.”
This means that development of a solution is an iterative process. You will tackle each part of your
problem in turn, coding a procedure, module or function, test it, modify it then moving onto the next
part. During the process of development you will regularly get feedback from your client. They will
provide comments on how your solution is developing. It is very important to capture the outcome of
those discussions in your report and show how your ideas are developing as a result over time.
During development, due to problems, issues highlighted from ongoing testing or simply due to
feedback from your user you might discover omissions or problems with your original requirements or
design work. DO NOT go back and alter your requirements or designs to match, this is perfectly natural
during development and the examiner expects to see this. Simply record any changes, new
requirements, new algorithms, new tests in your development section as they appear.
This extended development section thus becomes a narrative on the process of producing your solution.
This is known as “telling the development story”, it is the most natural way to capture evidence and is
exactly what the examiners are expecting to see.
This will mean that evidence to support assessing your project might be found throughout your project
report.
H446-03 Project Advice Booklet – Page 5 of 32
CHOICE OF PROGRAMMING LANGUAGE
The choice of which programming language to choose for your project is not a simple one. It will make
sense to choose a language you are comfortable with, so we would suggest using the one you have been
predominantly learning to program in, or one similar to it. Your teacher / tutor will also be able to guide
you in a choice of language for your project.
Whatever language you choose the exam board state that “All tasks completed in all languages need to
have a suitable graphical interface”.
They go on to specify the programming languages OCR will accept. These are:







Python
C family of languages (C# C+ etc.)
Java
Visual Basic
PHP
Delphi
Monkey-X (Also now approved by OCR and excellent for games development)
This list should allow you to develop most programs you have in mind. For example, if you wanted to
create a mobile phone app for an Android phone this could be done in Java. If you wanted to create it
for an iPhone this could be done in Object C.
If you would like to use a programming language not on the list above, it is essential that your teacher /
tutor contacts OCR and uses the consultancy service to get approval.
Note: Simple programming environments often used to introduce programming at KS3 such as Kodu,
Scratch, Gamemaker are not appropriate for A Level.
PROJECT IDEAS
Your choice of program for your project is one of the most important choices you will have to make.
Essentially you can solve any problem you wish, however it is vitally important that you get the scope
and level of complexity right.
When deciding on your choice of problem think carefully about what data it might need. Most
programs tend to use data in some way, such as a stock control system, booking system, online revision
tool, a testing program, a retro computer game. These types of problems allow you to easily show
evidence of creating, writing, reading, updating and deleting data from a file.
The problem you choose to solve must be sufficiently complex that you will be able to meet all the
requirements of the mark scheme, but not overly ambitious so as to become unachievable. Remember
this is only A’level. It is always better to have a small program well done and well written up than a
huge problem you can’t solve.
H446-03 Project Advice Booklet – Page 6 of 32
Ultimately your teacher / tutor will have to approve your choice of problem to solve. However here are
some suggestions of the sorts of problems which would be appropriate along with the types of
languages you could use to solve them.
DESKTOP DATA HANDLING PROGRAMS
Programs which allow you to manage a database of information via a graphical user interface. Such as a
student’s records system, a car dealership database or theatre booking program. These can often have
limited coding elements, however there is lots of scope to add validation checks and discuss data
structures.
Suggested languages: VB, Python, C#, C++, C, Delphi
WEB BASED DATA HANDLING PROGRAMS
These are often similar problems to the desktop ones except that interface is constructed to run in a
Web-Brower. Although this is a much more common and modern approach in our online connected
world it does come with its problems. Web standards are constantly changing. You will often need to
know more than more language e.g. Javascript for the client-side and PHP/ASP for the server side, and
possible some HTML / CSS for the web based interface! You will also need to think about how your
system will be hosted. If you are not using a paid online hosting provider you will need to get your
schools IT technicians to host it for you.
Suggested languages: HTML5, JavaScript, SQL, Java, jquery, VB/ASP.net
THE USER
Every project needs an identified user or target audience. They play a key role in an OCR Computing
project.
As far as possible you should try to get a real user who will be able to have regular contact with. For
example if you are writing a Chemistry revision program for 15 year olds then you could choose both a
Chemistry teacher at your school and a student 15 years of age. They would be able to give you
feedback and requirements on your solutions from the two required user perspectives and it would be
easy to get hold of them during school.
For the purposes of some project development, your teacher/tutor can be a pseudo-user: someone
acting on behalf of a real user. For example, if you are making a game for young children or a retro
computer game, it may be difficult to have regular contact with a user. Your teacher can be that person
in these cases.
H446-03 Project Advice Booklet – Page 7 of 32
ABOUT THIS DOCUMENT
What follows is the mark scheme for each section of the report write-up taken word for word from the
specification (in red text). Following this is additional advice and guidance from us (in black text).
Also keep a close eye out for this icon in the margin and make sure to read all the advice next to it
carefully (in green text). Without carrying out all of these actions you will be unable to access to highest
marks.
Not all projects will necessarily easily fit the mark scheme so these comments inform you how to tackle
each section.
Each section also comes with an evidence Do’s & Don’ts checklist.
H446-03 Project Advice Booklet – Page 8 of 32
ANALYSIS (MAX 10 MARKS)
1-2 marks
 Identified some features that make the problem solvable by computational methods.
 Identified suitable stakeholders for the project and described them and some of their
requirements.
 Identified some appropriate features to incorporate into their solution.
 Identified some features of the proposed computational solution.
 Identified some limitations of the proposed solution.
 Identified some requirements for the solution.
 Identified some success criteria for the proposed solution.
3-5 marks







Described the features that make the problem solvable by computational methods.
Identified suitable stakeholders for the project and described how they will make use of the proposed
solution.
Researched the problem looking at existing solutions to similar problems identifying some appropriate
features to incorporate into their solution.
Identified the essential features of the proposed computational solution.
Identified and described some limitations of the proposed solution.
Identified most requirements for the solution.
Identified some measurable success criteria for the proposed solution.
6-8 marks
 Described the features that make the problem solvable by computational methods and why it is amenable
to a computational approach.
 Identified suitable stakeholders for the project and described them and how they will make use of the
proposed solution and why it is appropriate to their needs.
 Researched the problem in depth looking at existing solutions to similar problems identifying and
describing suitable approaches based on this research.
 Identified and described the essential features of the proposed computational solution.
 Identified and explained any limitations of the proposed solution.
 Specified the requirements for the solution including (as appropriate) any hardware and software
requirements.
 Identified measurable success criteria for the proposed solution.
9-10 marks
 Described and justified the features that make the problem solvable by computational methods,
explaining why it is amenable to a computational approach.
 Identified suitable stakeholders for the project and described them explaining how they will make use of
the proposed solution and why it is appropriate to their needs.
 Researched the problem in depth looking at existing solutions to similar problems, identifying and
justifying suitable approaches based on this research.
 Identified the essential features of the proposed computational solution explaining these choices.
 Identified and explained with justification any limitations of the proposed solution.
 Specified and justified the requirements for the solution including (as appropriate) any hardware and
software requirements.
 Identified and justified measurable success criteria for the proposed solution.
H446-03 Project Advice Booklet – Page 9 of 32
In this section you are discussing what problem you are solving.
Strongest projects would include:
DESCRIPTION OF THE PROBLEM
AN OUTLINE OF THE PROJECT
Start by giving a brief background to the problem. Answer the questions:
1. What is the company?
2. What does the company do?
STAKEHOLDERS
IDENTIFICATION OF ALL THE STAKEHOLDERS
1. Who are the stakeholders / end users?
2. What problem do they have?
3. How will they make sure of your proposed solution and why is it appropriate to their needs?
Make sure you clearly name all of the stakeholders / users for your system. These must be actual
named individuals that you can have regular contact with as they will be required to give you feedback
and interviews throughout the development of your project. You can have more than one stakeholder /
user. For example if you are creating a Maths revision utility for 11 year olds then you would clearly
have two users, a Maths teacher and an 11 year old students. They will both be able to give you
requirements and feedback from their different perspective.
It is also acceptable to have chosen a “persona”, someone who personifies the typical user for your
chosen system. This will be most likely if you choose to make product which is not designed to be used
by a single person / organisation. In this case decide who your target audience is e.g. “Teenagers into
mobile gaming” and then choose a named person from this target group who you will be able to have
regular contact with to act as your stakeholder / end user.
These initial two sections should be no more than a few paragraphs.
For the highest marks in this section make sure not just simply list our users / stakeholders. Make sure
to explain how they will make use of your proposed solution and explain why it is suitable for their
needs.
H446-03 Project Advice Booklet – Page 10 of 32
JUSTIFICATION OF HOW THE PROBLEM CAN BE SOLVED BY COMPUTATIONAL METHODS
You must fully justify how the solution you wish to program can be solved by computational methods.
These are all the methods you have been studying for Unit 2 and include:





Thinking Abstractly & Visualisation
o How will your problem simplify reality? If you are producing a game, simulation,
training aid, booking system etc what detail IS important and what details from reality
will you ignore or omit?
Thinking Ahead
o What data / inputs will be required for your solution to work?
Thinking Procedurally & Decomposition
o Can your problem be easily broken down and tackled in smaller chunks?
Thinking Logically
o Will your problem have obvious decisions points for branching or repetition (looping)?
Thinking Concurrently
o Will there be any parts of your problem which could be solved or could happen at the
same time?
For the highest marks in this section you MUST make sure to clearly explain why the problem you are
solving is amenable to a computational approach. In other words, you have decided to write a
computer program for your project, and this program solves some kind of problem or meets some need.
Not every problem can be solved computationally, there are problems out there for which a computer
program based solution are not appropriate or indeed possible, yours is, explain this.
H446-03 Project Advice Booklet – Page 11 of 32
RESEARCH
In this section you are describing the problem. Take the following approach to the write up:
1. Initial research: start by identifying similar products (perhaps from the internet) and describe
the mechanics of how they work.
2. Form a set of questions to ask the user about how your product should look and feel. Navigation
/ menus etc. Document the user responses to these questions. (See note 1) E.g.
3. Q: How will the user interact with your product?
4. A: There should be a main menu screen with options which then take the user off to different
screens, each should have its own drop down menu and toolbar with clear and easy to
understand icons.
5. Deliberate on the answers you are given and the initial research. This will inform the proposals.
6. Propose a solution to the problem by describing each element of the product in detail. You can
have mock ups of the graphics / screen designs from a drawing application at this stage.
7. (See notes 2)
8. Get a response from the user about whether this meets their expectation.
9. Get an agreement from the user.
Note 1: You need to conduct an interview and/or observation of at least one existing system to know
the details of what you need to know to make the program later. Keep records of the questions and
observations you make, together with answers to questions.
Note 2: You need to discuss in detail exactly what the system is going to do, but not how it is going to do
it. This is not about design or algorithms, it’s about the requirements. Here we are focusing on the
what, not the how. Detail is very important in this section in your descriptions of the system.
‘Leave no stone unturned’. Your analysis should include sufficient detail so if you were to get a
programmer to read the analysis, there is nothing more they would need to ask before making the
solution. Of course the really fine details may not be entirely known and will be picked up in the
development process. For example, the order in which you move through various menus and screens,
you would need to use the actual product to know what feels right. That is unlikely to be known at the
analysis stage and the necessary dialogue between you and a user will gain you marks in the design
section later.
You should write your analysis as if you were having a discussion with a user. For example, “The
intended audience for my product is…” “I am using my teacher as a representative for that audience.”
“I discussed the requirements of the product with…” “It was suggested to me that…”
Whatever the problem, it will always have a target audience and therefore an identifiable user which
you should be discussing requirements with and keeping records of these discussions.
H446-03 Project Advice Booklet – Page 12 of 32
For the highest marks make sure that at the end of your research you identify AND justify which
approach you are going to take towards your project. The approach you take should be related back to
the research you have just carried out.
FEATURES OF YOUR PROPOSED SOLUTION
In this part you should make sure to clearly explain each of the features of your proposed solution. How
you choose to do this is up to you, however look carefully through your research and analysis and make
sure you have not missed anything.
In this section you should also identify any limitations of your proposed solution. It will, by the nature of
an A’Level project be limited. If it is a game what won’t it do, be realistic. This is a good time to flag up
desirable features that will not be included in the solution (you can revisit this again when you write
your evaluation at the end).
For the highest marks in this section you can’t simply list the features and limitations of your proposed
solution, you must provide an explanation along with each one.
HARDWARE & SOFTWARE REQUIREMENTS
You should discuss the hardware and software required to run your program. E.g. an IBM compatible PC
with x processor, y memory and z hard disk space running the Visual Basic runtime libraries? Find out
the necessary spec to run the development environment i.e. VB or Access on a computer.
If any additional software is required to run your solution or if your solution is only intended to work
with specific versions of software this needs to be identified here.
For the highest marks in this section you need to make sure you have justified the hardware and
software requirements you have listed. It is not sufficient to say your program will require 4Gb of RAM,
a minimum of Windows 10 and 250Mb of hard drive space for example, you must explain why you have
come up with these figures.
SUCCESS CRITERIA
As a summary of the analysis, create a numbered point list or table of the exact and actual success
criteria / requirements. Call this the “Success Criteria / Requirements Specification.” Avoid
requirements that cannot be measured. E.g. “It must be easy to use” is too vague. “The user should be
able to find a product within 20 seconds” is better. “A player scores 50 points for each invader.”
Remember, specific and measurable. It should contain numbers. Numbers of records, users, invaders,
points etc.
For the highest marks in this section you must make sure you justify each of your success criteria /
requirements. You can’t simply make a list of them. Why does your program have this requirement?
H446-03 Project Advice Booklet – Page 13 of 32
Where did it come from? Was it a user interview or another part of your research which made your
come up with this requirement?
H446-03 Project Advice Booklet – Page 14 of 32
EVIDENCE DO’S AND DON’TS CHECKLIST
This section of your project write up must include:
SECTION
A description of the
problem
Identify all stakeholders
Justify why the problem
can be solved by
computational methods
Research
Features of the proposed
solution
Software and hardware
requirements
Success criteria
DO’s
1 Provide an outline of what your problem
is
2 Provide an explanation of features
required in your computer program to
provide a solution to your problem
3 Identify all the stakeholders (users) as
individuals, groups or persona
4 Keep returning to the stakeholders (users)
for input throughout the project
DON’Ts
 Reply on simple
 statements of the
problem
5 Explain why the problem is suited to a
computer program
6 Explain the features of your problem that
are amenable to a programmed solution
7 Explain why the output from the solution
is valuable to the stakeholders (users)
8 Provide detailed research into existing
solutions to similar problems
9 Show that the research identifies features
that can be adapted for use in your
proposed solution
10 Show how the research provides insight
into the proposed solution and how the
features to be used are appropriate
11 Identify the features of your proposed
solution
12 Identify any limitations of your proposed
solution
13 Be realistic about what can be achieved in
the time allowed
14 Specify any hardware requirements for
your solution
15 Specify any software requirements for
your solution
16 Do identify any additional utilities that
will be required to implement your
solution
17 Specify the success criteria
(requirements) for your proposed
solution
18 Do specify success criteria (requirements)
 Simply state that you
are going to create a
 program because it is
needed. You must
 justify decisions
 Identify an end user
who cannot be easily
 contacted throughout
the project
 Rely on your own input
for the solution to your
 problem
Rely on an interview
 with and end user for
all your research into
the problem
 Attempt to solve to
solve problems that
 are too complex in the
time allowed

 List all the software
available simply to
 justify a choice
 Simply identify what
software you are using
 Specify vague
subjective criteria, such
 as colorful interface or
easy or quick to use
H446-03 Project Advice Booklet – Page 15 of 32
that can be demonstrated through testing
H446-03 Project Advice Booklet – Page 16 of 32
DESIGN (MAX 15 MARKS)
1-2 marks




Described elements of the solution using algorithms.
Described some usability features to be included in the solution.
Identified the key variables / data structures / classes (as appropriate to the proposed solution).
Identified some test data to be used during the iterative or post development phase of the process.
5-8 marks







Broken the problem down systematically into a series of smaller problems suitable for computational
solutions describing the process.
Defined the structure of the solution to be developed.
Described the solution fully using appropriate and accurate algorithms.
Described the usability features to be included in the solution.
Identified the key variables / data structures / classes (as appropriate to the proposed solution) and any
necessary validation.
Identified the test data to be used during the iterative development of the solution.
Identified any further data to be used in the post development phase.
9-12 marks







Broken the problem down systematically into a series of smaller problems suitable for computational
solutions explaining the process.
Defined in detail the structure of the solution to be developed.
Described the solution fully using appropriate and accurate algorithms explaining how these algorithms
form a complete solution to the problem.
Described, explaining choices made, the usability features to be included in the solution.
Identified and justified the key variables / data structures / classes (as appropriate to the proposed
solution) explaining any necessary validation.
Identified and justified the test data to be used during the iterative development of the solution.
Identified and justified any further data to be used in the post development phase.
13-15 marks







Broken the problem down systematically into a series of smaller problems suitable for computational
solutions, explaining and justifying the process.
Defined in detail the structure of the solution to be developed.
Described the solution fully using appropriate and accurate algorithms justifying how these algorithms
form a complete solution to the problem.
Described, justifying choices made, the usability features to be included in the solution.
Identified and justified the key variables / data structures / classes (as appropriate to the proposed
solution) justifying and explaining any necessary validation.
Identified and justified the test data to be used during the iterative development of the solution.
Identified and justified any further data to be used in the post development phase.
H446-03 Project Advice Booklet – Page 17 of 32
In this section you are discussing how you are going to solve the problem.
Strongest projects would include:
STRUCTURE OF THE SOLUTION
AN OVERVIEW OF THE STRUCTURE OF THE SOLUTION (A SYSTEMS DIAGRAM)
It should identify the key stages of the solution. See the exemplar below:
Zone Out
Main Game
Intro Scren
Menu Screen
Game Preload
Load main menu
Load graphics,
sound & music
Show
instructions and
controls
Initialise game
variables
Load Screen
End of Game
Game over
screen
Main Game
Loop
Load level
Sound & Music
Difficulty
Life system
Next level
Handle player
inputs
Collision
Load player onto
screen
Play music on
new level, on
repeat
Increase on lvl
complete
Start with 3 lives
Level is
complete
Read level onto
screen
When collide
with enemy
Reset when new
game started
Player fail lvl loss
life and graphic
Player fails lvl,
game over
Bullets on
enemies
Gain life & gain
graphic
Player icon
changes each lvl
Bullets on player
Move the level
down the screen
left and right key
moves ship
Power ups
For the highest marks in this section you should explain AND justify the process you have taken to
breaking your problem down. Why are you using this approach to help you design a solution? Think
about key terminology you have learnt in the course to use here such as “Thinking Logically”, “Thinking
Ahead”, Top-down Module Design”, “Step-wise Refinement”, “Decomposition” etc.
H446-03 Project Advice Booklet – Page 18 of 32
DECOMPOSITION OF THE PROBLEM
PROPOSED SCREEN DESIGNS AND USABILITY FEATURES
Include sketches of what the screens or form designs will look like. These can be ‘mock-ups’ done in a
Word document, Publisher, Excel etc. or hand drawn sketches scanned in. These should include the real
graphics and dimensions of the graphics at this stage.
If there are output reports these should be planned too. Be careful to include all major screen designs.
If you are making a game, each level should be sketched, together with the main menu, help screen,
high score screen etc. .
If your project is a database all the user interface forms and reports should be sketched.
For top marks make sure to justify each of the usability features you are talking about. Why are you
including them? How does there inclusion make your program easier to use?
DETAILED SUMMARY OF THE PROCESS INCLUDING KEY VARIABLES AND STRUCTURES
Under the sub headings a detailed summary should be written of what happens at each stage. This
would include some description of what coding/algorithms would be necessary. This is not algorithms
themselves, but descriptions. Enough for an experienced programmer to derive pseudo code from. E.g.
Update the progress tracker depending on the result of the last test, -10 to the left if wrong, +10 to the
right if correct. If the tracker total has reached a milestone (50, 100, 150 or 200) then increase the users
overall progress score by +1.
Under the relevant sub-heading identify all the ‘objects’ required in the program, student, teacher, class,
booking, show, car, invoice, test etc. You should include class diagrams for these.
For the highest marks it is VERY important in this section that you fully identify any key variables and
data structures you intend to use. Make sure to name the procedures, functions, methods, classes,
arrays, structures, records, files etc. and any key variables/constants along with their datatype.
For example, a high score table may be stored in memory as an array and on a disk in a sequential file.
For games with levels, include one example of a text file that will be read in for the level data.
In a database, the tables, fields, data types and relationships should be identified.
In a database solution under the relevant sub-heading identify all the queries, macros or code elements
needed.
H446-03 Project Advice Booklet – Page 19 of 32
TEST DATA FOR DEVELOPMENT
Identify appropriate data that you will be using during “The Development Story” to test the functionality
of your program as it develops. This shows your ability to Think Ahead, the data you list here should be
used as you develop your solution for the purpose of proving it is evolving as expected.
Note: This is NOT a test plan at this stage. There is no requirement to create a full test plan yet. This is
simply the data you will be using at each stage of the development process.
For the highest marks in this section make sure to justify the test data you plan to use during
development, it is not sufficient simply to state you will be using certain values.
ALGORITHMS
This is where the real thought about the internal workings of your solution begins. This section is often
over looked and performed poorly by candidates.
You may come back to this section later to explain anything complex about your solution. For example,
your collision detection may use a pruning tree technique to speed up the checking process. That sort of
detail ought to be explained here but is likely to be done once you have written the code.
You can produce your algorithms in any format you wish such as pseudo code or flow diagrams.
It is important you show how your various algorithms fit together to form a complete solution to the
problem.
The best candidates will perform some dry-run testing here to prove up front in their design that they
will work as required when coded.
For the highest marks in this section it is important at some point (probably towards the end of your
design) to justify how the set of algorithms you have presented form a complete solution to the your
problem.
H446-03 Project Advice Booklet – Page 20 of 32
TEST DATA FOR DEVELOPMENT AND ALPHA TESTING
Explain you are going to test the program as it is developed, but will have a black box approach to the
final alpha/ beta / acceptance testing.
Identify here, and justify, any test data you intend to use post-development to ensure that your
completed solution meets the success criteria written up in your requirements specification.
The best candidates here will identify not just data that is designed to work but also data that is
designed to break their program. Try to identify valid, borderline and invalid data where possible so
that it can be seen that upfront you are thinking about the robustness of your finished solution, good
test data should attempt to break the system!
Note: Once again, you should NOT be creating a full blown test plan at this stage. The data you specify
here will however be used in a final test plan for the finished product during the post-development
stage after the main bulk of “The Development Story”.
For the highest marks in this section make sure, once again, to justify the test data you plan to use
during the post development testing phase, it is not sufficient simply to state you will be using certain
values.
SIGN OFF THE PROPOSAL
You should show your proposed screen designs to your user as well as talking them through your
solution. Record some feedback from them at the end of your design section and show that they are
agreed in principle, subject to any changes that need to be made before development commences. Get
a dated signature at the bottom of this section to prove you did it.
H446-03 Project Advice Booklet – Page 21 of 32
EVIDENCE DO’S AND DON’TS CHECKLIST
This section of your project write up must include:
SECTION
Decompose the problem
Structure of the solution
Algorithms
Usability features
Key variables and structures
Test data for development
Test data for beta testing
DO’s
19 Provide evidence of decomposing your
problem into smaller problems
20 Provide evidence of a systematic approach,
explaining and justify each step in the process
21 Provide a detailed overview of the structure of
your solution
22 Provide a set of algorithms to describe each of
the sub-problems
23 Show how the algorithms fit together to form a
complete solution to your problem
24 Show how the algorithms have been tested to
show that they worked as required
25 Describe with justification the usability
features of your proposed solution
26 Explain and justify the design of any user
interface / screen designs or interfaces with
other systems
27 Identify and justify the key variables
28 Explain and justify the data structures that are
to be used in your solution
29 Describe and justify any validation required
30 Identify and justify any test data to be used
during development (this is appropriate test
data that can be show to test the functionality
of your program for development testing
purposes)
31 Identify and justify test data to be used postdevelopment to ensure the system meets the
success criteria (requirements)
32 Identify data that is designed to test the
robustness of the solution; good testing should
attempt to break the program


DON’Ts
Simply state the problem as
a single process






Simply provide an outline
data flow
Provide code or reverse
engineered code as an
algorithm
Spend ages creating colorful
diagrams of the user
interface






Create a full test plan for
this stage; this is data to be
used at each stage of the
development process
Create a test plan for this at
this stage; the data will be
used in a final test plan for
the product at the postdevelopment testing stage
H446-03 Project Advice Booklet – Page 22 of 32
DEVELOPING A CODED SOLUTION (MAX 25 MARKS)
ITERATIVE DEVELOPMENT OF A CODED SOLUTION (MAX 15 MARKS)
1-4 marks







Provided evidence of some iterative development for a coded solution.
Solution may be linear.
Code may be inefficient.
Code may not be annotated appropriately.
Variable names may be inappropriate.
There will be little or no evidence of validation.
There will be little evidence of review during the development.
5-8 marks






Provided evidence for most stages of the iterative development process for a coded solution describing
what they did at each stage.
Solution will have some structure.
Code will be briefly annotated to explain key components.
Some variable and/or structure names will be largely appropriate.
There will be evidence of some basic validation.
There will be evidence that the development was reviewed at some stage during the process.
9-12 marks







Provided evidence of each stage of the iterative development process for a coded solution relating this to
the break down of the problem from the analysis stage and explaining what they did at each stage.
Provided evidence of some prototype versions of their solution.
The solution will be modular in nature.
Code will be annotated to explain all key components.
Most variables and structures will be appropriately named.
There will be evidence of validation for most key elements of the solution.
The development will show review at most key stages in the process.
13-15 marks







Provided evidence of each stage of the iterative development process for a coded solution relating this to
the break down of the problem from the analysis stage and explaining what they did and justifying why.
Provided evidence of prototype versions of their solution for each stage of the process.
The solution will be well structured and modular in nature.
Code will be annotated to aid future maintenance of the system.
All variables and structures will be appropriately named.
There will be evidence of validation for all key elements of the solution.
The development will show review at all key stages in the process.
H446-03 Project Advice Booklet – Page 23 of 32
TESTING TO INFORM DEVELOPMENT (MAX 10 MARKS)
1-2 marks

Provided some evidence of testing during the iterative development process.
3-5 marks


Provided some evidence of testing during the iterative development process.
Provided evidence of some failed tests and the remedial actions taken.
6-8 marks


Provided evidence of testing at most stages of the iterative development process.
Provided evidence of some failed tests and the remedial actions taken with some explanation of the
actions taken.
9-10 marks


Provided evidence of testing at each stage of the iterative development process.
Provided evidence of any failed tests and the remedial actions taken with full justification for any actions
taken.
This should NOT be a separate section in your report, this should form an integral part of “The
Development Story”. You can therefore see your development story as providing you with evidence for
all of the 10 marks above. Read the mark scheme carefully above for “Testing to inform development”
and make sure this is covered during “The Development Story”.
To get full marks in this section we should be seeing testing going on throughout the development story
and if any of your tests fail then it is ESSENTIAL their follows evidence of what you had to do next. This
should happen quite often, no one codes perfectly the first time, tests should and will fail. Explain what
happened, show what you did to address this and justify your actions.
H446-03 Project Advice Booklet – Page 24 of 32
In this section you are discussing how you have actually solved the problem.
Now your analysis and design are finished it is time to start development. This will be done in an agile
way, that is to say that you will tackle each part of your problem in turn, coding a procedure, module or
function, testing it, modifying it then moving onto the next part. During the process of development you
will regularly get feedback from your client, they will provide comments on how your solution is
developing. This process is known as telling “The development story”.
During your development section of your report you must make sure to include the following details:






Name of the stage e.g. player movement.
Date of each part of development
Commented, indented and annotated code snippets / segments
Explanation of testing being carried out and modifications to make
Screen shot of output
Regular input and feedback from your stakeholders / users
You will be able to gain marks for many other sections of your report such as “Testing” and “Evaluation”
under this section if you do it well. You MUST NOT simply leave any mention of testing & evaluation
until after you have finished coding, this is an unrealistic way to develop a solution and the examiner will
be aware of this!
Although you will have snippets of code throughout your project report to help you tell the
development story your entire code listing should be printed and fully annotated and should be included
as an Appendix called “Code Listings” at the back of your project report.
It is vital as you tell “The Development Story” to make sure you:






Provide prototyping versions of your program at each stage of the process, make sure to include
annotated code snippets which explain what has been done.
Provide evidence of testing each part as it is developed using the test data you identified back in
your design.
Provide evidence of any validation you are using.
Get your user in at regular points to review how your solution is developing.
Explain any problems / issues that arise as they arise in an honest way.
Explain any changes / modifications which arise to your original design. DO NOT go back and
alter your analysis or design. It is fine to come up with new algorithms, requirements, screen
designs as long as there is justification. Credit will be given in the mark scheme for this.
For the highest marks in this section the key is make sure everything you do is explained AND justified
and that you don’t miss anything out! Each stage of your iterative development should be linked back
to your break down that you did in the analysis & design phase, it must not seem as if your development
and your previous planning work is disconnected. Make sure that any code you write is well annotated
H446-03 Project Advice Booklet – Page 25 of 32
with coder comments, candidates often forget this and make sure that variable, constant, procedure,
function and methods all have sensible and meaningful names.
EVIDENCE DO’S AND DON’TS CHECKLIST
This section of your project write up must include:
SECTION
DO’s
Iterative development
33 Provide evidence of iterative development
showing how the complete program was
developed stage by stage “The development
story”
34 Provide evidence showing how each section of
the program was coded and tested
35 Provide prototype versions of the program at
each stage of the process that show the
annotated and explained code
36 Provide evidence of testing at each stage using
the test data identified in the design section

37 Annotate the code at each stage of the
process
38 Use meaningful names for all variables,
structures and modules
39 Provide code in a modular form
40 Provide the code as separate modules
41 Supply evidence of validation
42 Supply evidence that the validation has
been tested and works as expected
43 Supply evidence that all testing covers a
wide range of valid and invalid inputs
and situations
44 Review each stage of the process in the
development phase, summarizing what
has been done and how it was tested
45 Explain any changes required and any
modifications to the design of the
solution that result from the testing
 Simply supply the
complete code for the
 program as evidence;
the code must be
 developed in suitable
 stages


Prototyping
Annotated modular code
Validation
Reviews
DON’Ts
Simply supply completed
code for the program as
evidence






H446-03 Project Advice Booklet – Page 26 of 32
EVALUATION (MAX 20 MARKS)
TESTING TO INFORM EVALUATION (MAX 5 MARKS)
1 mark

Provided evidence of some post development testing.
2 marks

Provided evidence of final product testing for function.
3-4 marks


Provided annotated evidence of post development testing for function.
Provided annotated evidence for usability testing.
5 marks


Provided annotated evidence of post development testing for function and robustness.
Provided annotated evidence for usability testing.
TESTING
This is the stage now where you create your full test plan and carry out your final set of acceptance
testing with your stakeholders / users.
Create a table showing everything that needs to be tested by your users to be assured the system or
game works as intended.
The tests should include: valid inputs, invalid inputs and extreme cases. It also needs to check all the
‘events’. E.g. “When a timer runs out on a timed test”.
Test No.
1
What is being tested
Does the test
automatically end
when the timer runs
out
Input data or actions
Once a test is started
an automatic 30
second timer should
start
Expected outcome
The test
automatically ends
and a message is
displayed “You are
out of time, your
score is x of x”
Actual Outcome
As expected
2
Record in the actual outcome what actually happens when the test is performed. Ask the user to sign
to confirm the program works as intended.
See this section as the beta-testing phase, carried out by a test team or the user rather than the
programmer. The program should be complete when you tackle this section.
H446-03 Project Advice Booklet – Page 27 of 32
Evidence that the program works to the test table is very important. This evidence can be before and
after screen shots, but could also be a video of the game being played (covering all the tests), captured
using software. If you use a video, submit it together with your write-up.
For the highest marks in this section it is vital there is clear evidence of BOTH post development testing
AND usability testing. Break the two types of testing out and make it explicit which is which. The
usability testing should be done by, or in the presence of, your end user.
H446-03 Project Advice Booklet – Page 28 of 32
EVALUATION OF SOLUTION (MAX 15 MARKS)
1-4 marks


Commented on the success or failure of the solution with some reference to test data.
The information is basic and communicated in an unstructured way. The information is supported by
limited evidence and the relationship to the evidence may not be clear.
5-8 marks




Cross referenced some of the test evidence with the success criteria and commented on the success or
otherwise of the solution.
Provided evidence of usability features.
Identified some limitations on the solution.
The information has some relevance and is presented with limited structure. The information is supported
by limited evidence.
9-12 marks





Used the test evidence to cross reference with the success criteria to evaluate the solution identifying
whether the criteria have been met, partially met or unmet.
Provided comments on how any partially or not met criteria could be addressed in further development.
Provided evidence of the usability features.
Considered maintenance issues and limitations of the solution.
There is a line of reasoning presented with some structure. The information presented is in the most part
relevant and supported by some evidence.
13-15 marks







Used the test evidence to cross reference with the success criteria to evaluate the solution explain how
the evidence shows that the criteria has been fully, partially or not met in each case.
Provided comments on how any partially or unmet criteria could be addressed in further development.
Provided evidence of the usability features justifying their success, partial success or failure as effective
usability features.
Provided comments on how any issues with partially or unmet usability features could be addressed in
further development.
Considered maintenance issues and limitations of the solution.
Described how the program could be developed to deal with limitations of potential improvements /
changes.
There is a well developed line of reasoning which is clear and logically structured. The information
presented is relevant and substantiated.
H446-03 Project Advice Booklet – Page 29 of 32
In this section you are discussing how effective your solution was.
Your evaluation can take many forms. It can be a written report, interviews, tables with cross-reference
links. Video evidence or a combination of these. However you choose to structure your evaluation it
must make sure to cover ALL of the following areas in detail:








Comments on how well the solution matched the original requirements
Comments on any changes that you had to make to the original design during “The
Development Story”
Comments on any unmet criteria / requirements and how these might be tackled in the future
Comments on any additional features that might be useful to your solution and these might be
approached in the future
Comments on your usability features
A discussion on future maintenance of your program
A discussion on any limitations of the current version of your program
Comments on the maintenance features included in your program.
For the highest marks in this section your evaluation should be linked back to your test evidence and
your success criteria / requirements. In other words, there should be a clear story and link between the
three e.g. You came up with a requirement back in the analysis stage, you then tested it in the last
section to see if had been a success or not and now you are evaluating how successful you were in
meeting it, and if it wasn’t met, why not? Again, as with previous sections much of the work here must
be explained AND justified for you to get top marks, it is insufficient to simple make statements or
describe what has happened.
H446-03 Project Advice Booklet – Page 30 of 32
EVIDENCE DO’S AND DON’TS CHECKLIST
This section of your project write up must include:
SECTION
Testing
Usability features
Evaluation
Maintenance
DO’s
46 Provide evidence of testing on the
completed solution
47 Provide evidence that the system
functions as designed
48 Provide evidence that the system is
robust and will not fall over easily
49 Cross-reference the test evidence
against the success criteria
(requirements) from the analysis section
to evaluate how well the solution meets
these criteria
50 Show how the usability features have
been tested to make sure they meet the
stakeholder’s (user’s) needs
51…