Documenting Programming Projects

OCR A Level Computer Science H446

D Hillyard
C Sargent

Published by
CRAIGNDAVE LTD
12 Tweenbrook Avenue
Gloucester
Gloucestershire
GL1 5JY
United Kingdom

[email protected]
www.craigndave.org

Craig 'n' Dave

Every effort has been made to trace copyright holders and obtain their permission for the use of
copyrighted material. We apologise if any have been overlooked. The authors and publisher will gladly
receive information enabling them to rectify any reference or credit in future editions.

Text © D. Hillyard and C. Sargent 2020

Original illustrations © D. Hillyard and C. Sargent 2020

Edited by A. Fenn
Graphics and typesetting by CraignDave Ltd
Second edition 2020

ISBN:

Copyright © D. Hillyard and C. Sargent 2020

A copy of this book is held in the British Library.

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means without the prior written permission of the copyright owner.

ii
About the authors
David Hillyard
David is a postgraduate-qualified teacher with a Bachelor of Science (Honours) in Computing with
Business Information Technology. David has over twenty years’ teaching experience in ICT and
computing in four comprehensive schools and one grammar school in Cheltenham, Gloucestershire.
He has been an assistant headteacher, head of department, chair of governors and founding member
of a multi-academy trust of primary schools.

Formerly subject leader for the Gloucestershire Initial Teacher Education Partnership (GITEP) at the
University of Gloucestershire, David has successfully led a team of PGCE/GTP mentors across the
county. His industry experience includes programming for the Ministry of Defence. A self-taught
programmer, he wrote his first computer program at ten years old.

Craig Sargent
Craig is a postgraduate-qualified teacher with a Bachelor of Science (Honours) in Computer Science
with Geography. Craig has over fourteen years’ teaching experience in ICT and computing in a large
comprehensive school in Stroud, Gloucestershire, at a grammar school and as a private tutor. A head
of department, examiner and moderator for awarding bodies in England, Craig has authored many
teaching resources for major publishers.

He also previously held roles as a Computing at School (CAS) Master Teacher and regional coordinator
for the Computing Network of Excellence. His industry experience includes freelance contracting for a
large high street bank and programming for the Ministry of Defence. He also wrote his first computer
program in primary school.

iii
Foreword
We have compiled all the latest advice, tips and guidance documents from OCR, cross-referenced the
clarification documents, including moderator suggestions and examiner reports from past series. We
have taken all this information and distilled it into one comprehensive guide to help you in
documenting your Unit 3 programming project.

We have also brought our many years of personal classroom experience to this guide. We understand
what makes a successful project, recognise the pitfalls and mistakes students make and, as a result,
know how to advise students to ensure they are equipped to achieve top marks.

Every year, the projects we submit receive high praise from moderators. Consistently since the
introduction of the 2015 specification, none of our marking has been adjusted. We have also been
commended for the approach our students have taken using this guide.

Make sure you go to the Craig ‘n’ Dave YouTube channel and watch the playlist titled A Level: OCR
Unit 3 Project Advice, a series of videos that provide additional advice and guidance.

This guide has been written specifically for students who are producing projects that are not game-
based. If you are producing a computer game, please use our Documenting Defold Programming
Projects OCR H446 book instead. Examples in that book are based on Defold, but the guide is suitable
for any language you might use.

Craig & Dave

iv
Contents
INITIAL IDEAS 6

Choosing a project 7
Programming paradigms 10
Working on your project 10

ANALYSIS 12

What to include 13
Project definition 13
Identifying suitable stakeholders 15
Researching the problem in-depth 16
Identifying essential features of the proposed solution 18
Identifying and explaining any limitations 19
Computational methods 20
Specifying hardware and software requirements 21
Identifying and justifying measurable success criteria 22

DESIGN 26

What to include 27
Breaking the problem down systematically 27
Defining the structure of the solution to be developed 29
Algorithms 32
Identifying the data structures and validation 37
Identifying test data to be used during iterative development 40
Identifying further data to be used post-development 42

DEVELOPING A CODED SOLUTION 44

What to include 45
An agile approach to development 45

EVALUATION 51

What to include 52
Testing to inform the evaluation 52
Evaluating your program 56

v
INITIAL IDEAS
There are specific examination board requirements you should be aware of before you start your
project. It is also important to scope your project to ensure it is manageable in the time you have
available.
Choosing a project

One of the considerations when embarking on a programming project is ensuring you choose a
project with sufficient scope to be of A Level standard; this is not easy to define, but it must be more
advanced than typical GCSE work. As a minimum, it must include:

• a graphical user interface; and

• a substantial coded element.

Trivial problems – regardless of how well you solve them and write them up – will not provide you with
the evidence you need to meet the top mark band criteria across the whole project.

Consider the complexity of the algorithms you study on the A Level Computer Science course as a
benchmark. These include linear search, binary search, hashing functions, bubble sort, insertion sort,
merge sort, quick sort, PageRank, Dijkstra and A* algorithm.

Consider the data structures. These include arrays, lists, graphs, hash tables and trees. A project that
does not make use of at least one of these will not attract higher marks. HTML, CSS and SQL are not
considered programming languages, so although you might need them for your project, there are no
marks awarded for that aspect of the work.

INITIAL IDEAS
Small applications, teaching tools and simulations are good project ideas. You should avoid multiple-
choice quizzes, simple data retrieval systems and projects written in Microsoft Access or Excel with
VBA.

Approved programming languages

You also need to consider the programming language you intend to use. There is a list of approved
languages, and your teacher will need to seek permission from the examination board for you to use
any language not on the list. Approved languages include Python, C#, C++, Objective-C, Java, Visual
Basic, PHP, Dephi, Robot-x, Monkey-x, Swift, NodeJS, Haskell, Unreal, Unity, Lua and JavaScript.

Remember, you will only have a limited amount of time, so it is inadvisable to attempt to learn a new
language while completing the project. It is better to use one you have learned or been taught before
commencing this work.

Rather than attempting a project that is too

simplistic, take on a challenge instead. It is
acceptable not to complete every aspect of
the work, providing it is written up well.

7
 Getting the scope right
Students must choose their own project. You cannot ask your teacher for ideas, although they can help
you select from a list you have made. Theoretically, it could be a large group project with each student
contributing a significant part, but this is unlikely to be successful and not recommended.

Your choice of program for your project is one of the most important choices you will make. The size
of the problem you undertake is known as its “scope”. Some features will fall within the scope; others,
outside it. Essentially, you can solve almost any problem you wish, but you need to get the scope right.
Too little scope and the project becomes trivial; too much, and it becomes unachievable. Your teacher
can help you scope the project once you present them with an idea. It is usually possible to take simple
ideas and expand them through a series of iterations to arrive at an appropriate scope.

Many of the best projects manipulate data. Stock control systems, booking systems, expert systems,
revision tools and simulations all make use of data sets. Programs that create, read, edit, write and
delete data – especially from files – usually have a good scope.

Robotics projects and programs that interface with hardware such as sensors are likely to require the
use of APIs or hardware-specific functions and can make excellent computer science projects. Using
Raspberry Pi or Arduino computers can provide for interesting projects, providing you can write plenty
of original code and not use drag-and-drop script builders. Raspberry Pi uses Python (that’s what the
INITIAL IDEAS

Pi means), and Arduino uses C, so both are approved.

Networking projects can also be extremely fun, making use of interaction across a network.

Examiner’s advice
“The best projects tend to be more ambitious. A project that a candidate can complete
without encountering any challenges will give them little to write about. A candidate can
still receive high marks for an ambitious project that does not achieve all its aims.”

8
Questions to think about
• Is it easy for me to research the problem?

• Does my project include substantial algorithms?

• Will my project require me to use arrays, lists or other data structures beyond variables?

• Does my project use external data sets that must be searched or stored in a database
management system (DBMS), serial, CSV, XML or JSON?

• Do I have enough experience using the language I intend to use?

• Will I be able to complete the work independently without asking for help?

Before you embark on your project, you need to have had plenty of practice solving problems and
writing algorithms. Although the coursework is only worth 20% of your final grade, it is a significant
undertaking that will require a lot of your time.

Writing code is fun, but it is only worth 15 out

of the 70 marks available. Being good at
programming helps a lot, but it does not

INITIAL IDEAS
guarantee success – a good write-up does!

Stakeholders
In the past, it was a requirement that computer science projects had a real user with a real-world
problem that you were attempting to solve. Those were the days when there were few off-the-shelf and
online apps, so bespoke solutions were the norm. Today, A Level projects do not require you to have
a single, identified user who needs your program. Instead, you will need to identify stakeholders; a
target audience who would have an interest in using your product.

That said, it is extremely useful to have at least one person who can represent your stakeholders with
whom you have regular contact. For example, if you were writing a chemistry revision program for 15-
year olds, it would be useful to talk to both a chemistry teacher and a 15-year-old chemistry student.

Your stakeholders will be able to provide you with additional success criteria at the analysis stage,
insights at the design stage, feedback during development and an evaluation at the end. Not having
suitable stakeholders will severely limit your discussion, resulting in a weak project.

9
 Programming paradigms

You may choose any programming paradigm that your chosen language supports, including
procedural, object-oriented or functional. There is no requirement to use object-oriented techniques.
It is a misconception that OOP provides substantial algorithms; however, it often makes coding simpler
and usually indicates that a project has sufficient scope.

There may be language-specific techniques you can make use of to increase functionality, including
external libraries. For example, the program must have a graphical user interface, so if you are planning
to use Python, you may want to use Tkinter to provide this functionality.

There is no need to reinvent the wheel unnecessarily. If the language supports built-in algorithms and
data structures, you should make use of them. Why write a sorting algorithm in Java when it already
provides a Tim sort, which is extremely efficient? You will gain credit for using appropriate features.

Working on your project

It is sensible to structure your work into the four sections that match the mark scheme outlined in this
guide, although evidence to support assessment can be found anywhere within your submission. For
INITIAL IDEAS

example, if you include something in the design that should, strictly speaking, be included in the
analysis, you will not be penalised. The sub-sections in this guide provide you with a handy explanation
of how marks are awarded, but you should use your own sub-headings.

You are permitted to work on your project outside of lesson time, including for homework. However,
your teacher will need to authenticate your work as your own, so they will want to see a significant
proportion being completed in class too.

Your project report should be a word-processed document with a suitable cover page, including your
name, candidate number, centre name and centre number. Ensure each page is numbered so your
teacher can cross-reference when marking. You must also include a bibliography or page of
references. There is no requirement to adhere to a specific referencing standard.

10
An initial proposal
Before embarking on your project, it is a good idea to submit an initial proposal to your teacher; this
will enable them to assess the scope and complexity of your project before you do too much work.

It is important to choose a project you will be interested in developing; this is a substantial piece of
work – you need to enjoy it!

Your project proposal should include:

• A title.

• A brief overview of your idea.

• An outline of what you want to achieve as an outcome.

You do not need to submit your proposal in your final project. However, your teacher may decide to
submit it to the examination board before you seek their guidance on scope, complexity and viability.

The role of your teacher

The Joint Council for Qualifications sets rigorous expectations on the completion of internally assessed

INITIAL IDEAS
work and clear guidelines for the role of the teachers assisting you.

Teachers are permitted to:

• Support you in choosing an appropriate project without giving you a specific idea. For example,
your teacher could advise and help you choose from a list of your own ideas.

• Provide you with the mark scheme.

• Review your work and provide oral and written feedback at a general level.

• Allow you to redraft your work in response to this feedback.

Teachers are not permitted to:

• Provide you with writing frames or paragraph/section headings.

• Provide detailed, specific advice on how to improve drafts to meet the assessment criteria.*

• Give detailed feedback on errors and omissions.*

• Intervene to improve the presentation or content of your work.*

• Provisionally mark your work and then allow you to revise it.

*Unless they record the assistance and adjust marks accordingly.

11
ANALYSIS
Here, you will be outlining the genre of your project, identifying your target audience’s needs
and exploring ideas to scope your success criteria.

In this section, you are discussing what problem you are solving.

10 marks
What to include

• An introduction to your project.

• Your stakeholders.
• Detailed research.
• Features to be included in your solution.
• Limitations of your development.
• Computational methods.
• Hardware and software requirements for development and deployment.
• Specific and measurable success criteria.

Project definition

You should start your project by providing a brief introduction to it. Set the scene so the examiner
knows what your project is about; this is not detailed research but simply a brief overview limited to a
few short paragraphs. It is not an essential section, but it will help give you the impetus to write more
detailed research later. Getting started with the report is often the hardest part. Once you get going,

ANALYSIS
it seems less daunting. It is important you do not use a template or simply copy the headings from
another student. How you structure your writing is completely up to you. However, you should use a
logical structure to make it easy for your teacher to mark and an examiner to moderate.

Things to consider:

• The background to the problem.

• What is the specific problem you are trying to solve?

• Why is the solution needed?

• Outline your intentions.

• Your next steps, outlining how you will conduct further research.

Do not forget to include a references or

bibliography page in your report and keep a
note of all your sources. You can only claim
credit for original material.

13
 An example of a project definition
In a multitasking operating system, processes that are ready for execution are held
Background
in a ready queue awaiting availability of the central processing unit. When the CPU
becomes available, a process from the ready queue is executed. Several factors
determine which process is chosen, how much processing time it is given and what
happens to it when it requires data to continue or an interrupt occurs.

With modern processors and operating systems, the process of scheduling is

The problem
complex. In the past, there were just five simple scheduling algorithms, but today’s
A Level students still need to learn about these operations.

To assist students’ understanding of how these scheduling algorithms work, I

Intentions
intend to create a simulation of the five known as first come first serve, shortest job
first, round robin, shortest remaining time and multi-level feedback queues.

It is much easier for teachers to explain and students to understand if they can see
Why the
a pictorial abstraction of process scheduling and what is happening at each stage. solution is
needed
My program will enable the user to create new processes and see their impact on
the simulation. It will also generate data that can be used to plot the efficiency of
the algorithm and allow comparisons to be made.
ANALYSIS

Next, I will research the five algorithms in-depth to fully understand how they work.
Next steps
I will also discuss with a computer science teacher what is important for the
simulation to achieve its aim and what the scope of the development will be.

Examiner’s advice
“Well-structured projects in a single document with contents pages, page numbering and
sub-headings are much easier to navigate and help ensure nothing gets overlooked.”

14
Identifying suitable stakeholders

Make sure you identify all the stakeholders of your system. Each stakeholder is likely to have a different
set of needs. In the previous example, we identified two broad stakeholders – the teacher and the
students. While it is not necessary to name individual users, you should have regular contact with
someone representing each group of stakeholders who can work with you throughout the project.

Do not simply state who your stakeholders are.

Explain how they make use of your proposed
solution and why it is suitable for their needs.

The weakest projects are often those that do not engage sufficiently with a stakeholder. It is a mistake
to be both the developer and the end-user of your system. While it is possible, it makes it much harder
to look at a problem objectively and not make assumptions when you conduct your research. Being
“inside the problem” is not a good idea, but it can be easily overcome. For example, if you are the
student who requires the solution, surely your other classmates do too – perhaps you can have another
student in your class represent the stakeholder.

Describing your stakeholders and some of their requirements is essential for all projects. To gain higher

ANALYSIS
marks, you will need to explain how they will make use of your proposed solution. For top marks, you
also need to explain why it is appropriate for their needs. Much of this detail will need to come after
your research when you decide on the features of your proposed solution; you could easily forget this
if your stakeholder is not an integral part of each stage of your project.

Suitable projects allow a student to make

meaningful decisions in the development
process using stakeholders to direct future
iterations.

15
 Researching the problem in-depth

As the examiner reads your project, it should become increasingly more detailed. In your introduction,
you simply outlined the nature of your project and stakeholders. In this section, you must forensically
analyse the problem to derive a set of proposals. This section of your analysis will likely be the most
extensive. Many projects fail to achieve their potential because they lack detail in the research.

Things to consider:

• Underpinning knowledge and calculations

• Existing systems

• Stakeholder and user needs

• Your own ideas and approaches

Underpinning knowledge and calculations

If your project has a knowledge base that must be understood to design a solution, you should explain
that in as much detail as you can. For example, in the example project definition, we outlined that our
ANALYSIS

project would simulate the five scheduling algorithms, so in this section, it would be essential to explain
what these five algorithms are and how they work in detail. Diagrams and illustrations should be used
to make this easier to explain. Remember, your teacher and examiner will not necessarily have an
underlying knowledge of the context of your project.

Another example may be a planetary orbit simulation project. In this example, you would want to
explain the Newtonian physics and calculations necessary to design your solution later.

Existing systems
If there are existing systems already available, it would be useful to examine how they work in depth.
What are the features? What are the issues? Why doesn’t this system provide a solution to your
problem? You may be able to think creatively about what constitutes an existing system. In our project
example, there may be videos on YouTube that explain the concept of scheduling algorithms or
exercises you completed in class that our solution aims to improve upon.

If there is documentation such as data sets, import files or hardcopy outputs, you should collect these
and document or scan them into your work.

16
Stakeholder and user needs
Having a detailed discussion with a stakeholder to ascertain their needs is a very good idea. Think in
advance about the questions you will ask about all aspects of the system. There is no need to provide
transcripts of these meetings – just an outline of the discussion and its outcomes. The discussion should
focus on what the system needs to do rather than how it is going to do it; this isn’t about the algorithms
but, rather, gathering the requirements.

Typical questions you might ask include:

• What are the main problems we are trying to solve?

• What are the stages of the process?

• What happens at each stage?

• What input and output screens will be required?

• Are there any specific requirements for the graphical interface?

• How will the user interact with the product?

• What data needs to be input into the system, and how will this happen?

ANALYSIS
• What data needs to be output from the system and in what format?

The above is not an exhaustive list but provides you with a framework to structure your discussion. You
may also find that some of these questions are not appropriate to your project. What is important is
that you include enough detail so that an experienced programmer wouldn’t need to ask any questions
before designing the solution; this is incredibly hard to achieve and not expected to be perfect.

During the design and coding stages, it is almost certain you will need to ask further questions as things
you did not initially consider come to light. The really fine details may not be entirely clear in the
beginning and will be picked up in the development process.

Examiner’s advice
“Interviews are not essential. Typing out interview transcripts is an unnecessary use of
candidates’ time. A summary of the interview’s key points is sufficient.”

17
 Your ideas and approaches
You will also have several ideas about what you would like to achieve. Your stakeholders are unlikely
to think of everything, and they may not know what is possible either; this is where you can bring your
creativity and knowledge of computer science to the process by making suggestions.

As with all aspects of the project, there is no set format you should follow in your report, providing you
meet the requirements of the mark scheme. You could include your ideas within a discussion of existing
systems or stakeholder needs.

Remember, as a developer, you are making your solution for someone else – your users’ needs must
be met as well as your own.

To gain marks in the top mark band at this stage, you will want to outline the suitable approaches you
could take to achieve your aims without providing too much information relating to the design.

Identifying essential features of the proposed solution

Having concluded your research, there will be several features you have identified that must be
implemented to solve the problem. There may also be some ideas you reject because they’re too time-
consuming or complex and fall outside the scope of the solution.
ANALYSIS

Look back carefully through your research and provide a summary of each feature of your proposed
solution, explaining and justifying your choice for including it in your project.

For the highest marks, you cannot simply list

the features of your proposed solution. You must
also explain and justify each one.

18
This diagram is a useful way to visualise what you are trying to achieve when identifying essential
features:
Analysis means breaking down

Your ideas

features

Ideas from Existing

your user systems

Decisions…
Synthesis means building up

Proposed
solution

Features to include with justifications

ANALYSIS
Features rejected with justifications

Identifying and explaining any limitations

Although the project should be a challenge and it is acceptable to not fully complete the work, it is
often better to have a smaller number of features implemented well than a large number unfinished;
this demonstrates you can scope a solution well. You should identify the limitations imposed on the
project with a justification for not including these features.

For example, you may be limited by your hardware and available libraries. You may have to simulate
the input and output of your target device during development, especially if you are targeting the
tablet or mobile market. There may be limitations on the accuracy of your model due to the complexity
of the calculations. For example, in a planetary orbit simulation, it would be more accurate if the sun or
a planet wobbled on its orbit due to the barycentre; however, this may be considered an acceptable
limitation because it has little bearing on the purpose of the simulator.

19
 Computational methods

A problem is defined as being amenable to a computational approach if there are algorithms that can
solve it within a finite number of steps. Problems exist that can theoretically be solved in a finite number
of steps but would take far too long to solve with today’s technology, so they are not considered
amenable to computation. Cracking 256-bit encryption is an example; it is possible but would take at
least 3 x 1052 years. Given infinite time and computing power, you cannot detect all metamorphic
malware. The halting problem is a perfect illustration of a problem that is not amenable to a
computational approach – a computer can never know if it is stuck in an infinite loop.

In this section, you must explain the features of your problem that make it suitable to be solved by a
computer as opposed to other methods.

Consider that computers:

• Are suited to problems with sequential, logical steps.

• Can perform operations extremely quickly compared to humans.

• Eliminate human error (other than logic errors).

• Can store and retrieve large amounts of data.

ANALYSIS

• Are efficient at finding patterns in data.

Other considerations might include:

• Abstraction removes unnecessary details to reduce the complexity of the problem.

• Backtracking allows an algorithm to explore other possibilities to arrive at a solution.

• Heuristics allow for a best-fit rather than an absolute result.

• Pipelining is the result of one process being the input to another.

• Concurrency allows more than one process to happen at the same time.

• Visualisation allows us to view the problem from a different perspective.

• Caching allows for the storage of previously calculated results.

•
It is important that this does not become a
•
written account of the theory from Component
2 of the course. You must apply the principles of
•
what you have learned to your project.

20
Specifying hardware and software requirements

You need to discuss the hardware and software requirements for both development and deployment.

• State what IDE and programming language you will be using and the key features that make it
suitable for your development – e.g., event-driven, object-oriented, runs in a browser, etc.

• State any additional libraries you intend to use and discuss why they are needed.

• State which operating system are you using – e.g., Windows, macOS or Linux.

• State the hardware required; this may simply be a keyboard, mouse, monitor and secondary
storage. Robotics projects may also include actuators and sensors.

Examiner’s advice
“Some projects lend themselves more to discussion of hardware and software requirements.
As such, some candidates will have little to write on this aspect.”

ANALYSIS
Remember, it is important to justify your
choices for top marks. Why is the language
suitable? Why do you need to include library
functions?

21
 Identifying and justifying measurable success criteria

In the concluding section of the analysis, you are summarising what you intend to achieve. It is
important your criteria are specific, measurable and numbered for easy identification.

The success criteria serve three purposes:

1. An agreement about the scope of the solution – exactly what will be included in the program.

2. A framework to test the solution against.

3. A reference for the evaluation.

Statements such as “must be easy to use” are too subjective. For it to be a proper success criterion, you
need to detail how it would be achieved rather than writing broad statements.

Examiner’s advice
“Candidates with vague objectives like, “My interface must be attractive,” tend to not only
ANALYSIS

drop marks in the analysis but also later in the project. Time spent on good-quality,
measurable objectives pays dividends further down the line, as these objectives form the
backbone of strong testing and evaluation sections.”

Analysts consider volumetrics, which means “how many and how often”. Using numbers makes your
objectives specific and easily measurable. For example, “The simulation will only include four process
states: ready, running, blocked and finished.”

There is no need to state what you will not include in your program. You considered this in the
limitations section. The success criteria are a simplistic reference point for the rest of the project.

You should briefly justify each of your choices. You are not completely rewriting the features of the
proposed solution section but summarising the key reason for including each feature in the scope.

A good approach is to number each of your criteria so you can use the same number system later when
discussing them in the testing and evaluation section. Aim for between 12 and 30 criteria. Too few, and
you probably do not have sufficient scope and complexity for an A Level project. Too many, and you
risk giving yourself too much work to do in the time available.

The example below is presented in a table, simply to illustrate the numbering of the criteria and how
they can be justified more easily. There is no requirement for you to present your criteria in this way.

22
An example of success criteria for the scheduling simulator

No. Criteria Justification

1 Allow the user to select between five The data produced by the program should
scheduling algorithms – FCFS, SJF, RR, SRT and allow for a fair comparison between algorithms
MLFQ. using the same simulation. These are the
algorithms studied on the course.

2 Show the user a visual representation of four Understanding how the algorithms work
process states – ready, running, blocked and requires the user to see how a process is
finished. managed by the operating system.

3 Allow the user to manually enter processes into Allows the simulation to be set up in a specific
the ready queue, including a time to execute of way to simulate certain scenarios.
between 1 and 100 cycles.

ANALYSIS
4 The user can choose an automatic simulation Will provide larger, more interesting data sets
where processes are randomly added to the for comparison that would be too time-
ready queue with a time to execute of between consuming for the user to generate manually.
1 and 20 cycles.

5 For automatic simulations, a seed can be saved Allows the same random sequence to be used
by the user. again in the future.

6 The number of CPU cycles required for the Allows the student to see what happens with
currently executing process is updated during time slicing more easily.
execution and displayed.

7 The simulation can be stopped at any time. Allows the user to easily restart the simulation,
which is useful if the simulation is continuing for
too long.

8 Processes move from the ready state to the Allows the simulation to accurately illustrate the
running state according to the rules of each algorithm.
scheduling algorithm.

23
 9 Processes move from the running state to the Allows the simulation to accurately illustrate the
blocked state randomly but in a predetermined algorithm.
way using the seed.

10 Processes move from the blocked state to the Allows the simulation to accurately illustrate the
ready state after 2–5 cycles but in a algorithm.
predetermined way using the seed.

11 Processes move from the running state to the Allows the simulation to accurately illustrate the
ready state if the time slice expires when algorithm.
simulating the RR algorithm.

12 Processes move from the running state to the Allows the simulation to accurately illustrate the
ready state if a new process requires fewer algorithm.
cycles of execution than the running process
when simulating the SRT algorithm.
ANALYSIS

13 The user can set the time slice for processes Allows the user to see the effect of different
when the RR simulation is chosen. time slices on the throughput.

14 The user can speed up, slow down and pause Allows the teacher to explain what is happening
the simulation. more easily.

15 The simulation should output a CSV data set – Allows comparisons between the algorithms
algorithm, number of cycles, number of and different data sets to be made.
finished processes and average wait time.

Examiner’s advice
“The requirements and success criteria are key to a good project. An ideal set of requirements
should be detailed enough to pass onto a third party to design the system.”

24
Section Do Don’t

Project 1 Set the scene for the examiner.  Assume the examiner will
definition understand your problem.
2 Outline why the program is needed. 
Identifying 3 Identify the user groups or individuals  Be both the developer and
suitable who will use your program. user of your product – it is
stakeholders unlikely that you will be able
4 Involve a representative from your 
to give yourself truly
stakeholders throughout your project,
objective feedback.
using a RAD approach to development.
Research 5 Provide detailed research into existing  Rely solely on your own
solutions to similar problems. input for the solution to your
problem.
6 Include any related knowledge and 
calculations necessary to understand Rely on an interview with an
the problem. end-user for all your
research into the problem.
7 Include a summary of the discussion 
with a stakeholder. Write up interviews as a
Q&A session.
8 Include a reference or bibliography 
section at the end of your report. Forget you need a
bibliography.
Features of the 9 Identify the features you are going to  Attempt to solve a problem
proposed include in your program. that is too complex in the
solution time allowed.
10 Identify any limitations of your 
proposed solution. Settle for a problem that
doesn’t pose challenges you
11 Be realistic about what can be achieved 
can discuss later.
in the time allowed.
Computational 12 Explain why the problem is suited to  Explain the theory of
methods being solved by a computer. computational methods
from Unit 2.
Hardware and 13 Specify the hardware requirements for  Forget there are
software your solution. requirements for both
requirements development and
14 Specify the software requirements for 
deployment.
your solution, including the operating
system. Simply identify the
programming language you
15 Identify any additional utilities or 
are using without
libraries that will be required to
justification.
implement your solution.
Success criteria 16 Specify the measurable requirements  State vague, subjective
of what your program needs to do. criteria that are difficult to
measure.
17 Justify why each requirement is 
necessary.
DESIGN
The plan for your development.

In this section, you are discussing how you are going to solve the problem.

15 marks.
What to include

• A structure diagram illustrating the problem decomposition.

• Explanation of the components of the solution.
• Algorithms in pseudocode.
• Usability features.
• Data structures to be used.
• Input validation.
• Test data to be used during the development of the coded solution.
• Test data to be used post-development.

Breaking the problem down systematically

This section of your report explains the structure of your intended solution. In the analysis section, you
explored ideas and described your intentions; that was about what you were going to do. In the design
section, you are writing about how you are going to realise these intentions.

DESIGN
Start with a structure diagram, which will illustrate the subroutines you intend to develop. Below is an
example of a structure diagram for the scheduling simulator.

Schedulng
simulator

Run
Title screen Settings Reports
simulation

Load Start, stop, New Process Update Output Create

settings pause, speed process states display logs chart

Save Add to ready Executing Reset

settings queue processes output log

Algorithm Prioritise Blocked Generate

select ready queue processes CSV

Change Finished
settings processes

Change
process state

27
 Notice how the number of boxes increases as you follow the diagram; this shows the problem being
broken down into increasingly smaller parts. There is no right answer to producing this diagram – it
depends on how you visualise the program you are going to make.

You need to balance the level of detail you

decide to include on your structure diagram.
If it does not fit on the page or is unreadable,
you have included too much detail.

• The yellow box is the name of your program.

• The green boxes underneath identify the key interface screens the user will see.

• The blue boxes identify the main modules or components of the solution, each associated with
an interface.

• The orange boxes identify the processes and subroutines for a module. These are the routines
you are likely to need to pseudocode later in the design section.

The colours are not important. Choose your own style, providing it is easy to read. Using SmartArt
DESIGN

hierarchy objects in your word processing application is acceptable. Avoid using 3D shapes, as these
are often difficult to read.

Top-down design diagrams, JSP diagrams and UML diagrams are all good examples of how you can
demonstrate problem decomposition. You do not need to adhere to a certain standard – use the
diagram that best fits your type of project.

This diagram becomes a handy reference because the examiner should be able to follow each box to
later sections of your report – e.g., algorithms, coded solution and testing.

Although it is possible to combine the design

and code sections of your report in an iterative
way, make sure your work still meets all the mark
scheme criteria for design.

28
Defining the structure of the solution to be developed

Take each box from your structure diagram and explain what is happening at each stage.

Interfaces
You should draw a technical sketch of what your interfaces will look like. You can either hand-draw this
with a pencil and ruler and scan or photograph it into your work or use the shape tools provided in
your word processing software. While it is possible to also create a non-working form design in your
chosen IDE and crop it into this section, take care that it does not look like a screenshot from your
coded solution. The examiner must be in no doubt that this is a design.

Providing annotations on your proposed interface designs will be useful to highlight key features. You
should discuss the usability features you have included, explaining why they are necessary.

An example of an interface design

Algorithm

DESIGN
Ready Queue
Speed
5 3 6 2
Time Slice

Running Blocked

Add process 3 3

Randomise

Completed
Reports
D C B A

It is obvious that this is not a screenshot from the development but a concept design. You can see how
a few annotations would be helpful to explain aspects of the interface and usability conventions such
as the play, pause and stop buttons. This concept is unlikely to be the final implemented design, and
it is acceptable to change your mind when coding the solution without updating your design sketches.

29
 Validation of inputs
If your interface includes text entry boxes, combo boxes, list boxes, file selection boxes or sliders, you
should explain the validation you are applying to them. Typical validation checks include:

Validation check How it works Example

Format check The data is the correct data If an integer is expected,

type and follows an expected characters should be rejected.
pattern. Date of birth is DD/MM/YYYY.

Ensuring an @ symbol is
present in an email address.

Length check The number of characters isn’t A password that needs to be

too long or too short. eight characters or more.

A credit card is 16 numbers.

Presence check Data has been entered into a In most situations, it is unlikely
field. that no input is a valid input.
DESIGN

Username must be entered

before continuing.

Range check Data must be within a valid The month cannot be less than
range. one or more than twelve.

Lookup table Combo boxes and list boxes Choosing from a list of options.
restrict the input to valid inputs.

Check digit/checksum Checks the input is an Credit card number is valid –

acceptable entry before this doesn’t mean it exists, just
that it is a valid number.
attempting to look up in a
database.

Giving the user buttons to click instead of commands to enter not only makes the interface more user-
friendly but also ensures only valid actions can be taken.

Sanitisation is the process of taking what otherwise might be an invalid input and converting it into a
valid input before it is processed. For example, if the data entry must be in upper case, rather than
rejecting lowercase characters, you could simply convert them after they are input. Data sanitisation
provides a better user experience and more for you to write about.

30
Modules and processes
If the box on your structure diagram is a module or process, you should describe the purpose of the
routine and explain what the code in that section will achieve. Remember to justify the approaches you
are taking. You may not need to describe every box on the diagram if many routines on the same
branch can be discussed together.

An example of a paragraph for this section

New process

The user can add a new process to the ready queue at any time by clicking the Explaining
“Add process” button; this will show a simple pop-up box asking the user how what
many cycles the process will require. Once the user has selected the required happens in
detail
number of cycles, the process will be added to the queue.

If the randomise option has been selected, the program will create 2–6 random
processes for the queue before the simulation starts using a for loop. The number
of cycles to execute will also be randomised from 1–20. While the simulation is
running, one random process per cycle may also be added to the queue. Although
the simulation will be random from the user’s perspective, the numbers generated

DESIGN
will be based on a seed generated from another random number from 1–10,000
to ensure they are deterministic.

This feature will allow the user to save the seed in a text file and run the program
Justification
again with the same settings to generate the same output. The processes in the
ready queue will be stored in an array and will largely operate as a queue, as this
data structure is the best fit for the operation. Depending on the chosen
scheduling algorithm, the queue may need to be prioritised – e.g., for SJF and SRT
algorithms. In these situations, I will use an insertion sort to sort the processes by
the number of cycles remaining in the array. The insertion sort is easy to program,
and because the data set is small, there is no need for it to be more efficient.

Achieving top marks

It is important to remember that the design section is not so much about what you are going to do (this
was discussed in the analysis) but more about how you are going to do it. Be careful not to repeat too
much of what you have already written in your analysis. If you get this section right, you should be able
to write basic pseudocode from it in the next section of your report.

For top marks, you will need to justify your design decisions, not the inclusion of features – you already
did this in the analysis section. You are justifying how these features will be implemented.

31
 Algorithms

This section of your report is not the actual code but, instead, the algorithms you intend to write. It is a
decomposition of the subroutines you identified in your structure diagram.

Although you can use flowcharts, they can get unwieldy very quickly when algorithms become more
complex and are time-consuming to produce. It is advised that you use pseudocode in this section.

Algorithms are represented with pseudocode so they can be interpreted by programmers, irrespective
of the programming languages they are familiar with. Pseudocode, as the name suggests, is a false
code or a representation of code that can be understood by most people.

The differences between algorithms, pseudocode and source code

Algorithm: A logical sequence of the actions of a process. A programmer implements an algorithm
using source code. They then express it in a language-independent way using pseudocode.

Pseudocode: Has no defined syntax, so it cannot be compiled or interpreted by the computer.

However, it is written in a way that makes it easy to produce real code for most languages.
DESIGN

Plain English Pseudocode Source code Machine

code

Describing your Proposed algorithms for The real Binary the

solution procedures/functions/methods programming code computer
(the previous part of your report) (this part of your report) (developing a coded solution) executes

At this stage, you might feel you do not have the confidence to write your algorithms. Perhaps you’re
not entirely sure what you are going to do – in which case, your analysis and the first part of your project
may be weak – or you’re not sure how to write the code because of insufficient experience with your
chosen language. If you hit a brick wall here, go back and make sure you have been decisive about
what your program needs to achieve in the previous section.

Remember, pseudocode is not real code. Have a go at identifying the logical steps, invent commands
as you need to and use variables as you write the commands.

32
Pseudocode
There is no requirement to use the examination board reference language. These are for writing
examination questions only.

You should use indenting with pseudocode, just like with real code.

It may not be obvious why you have approached a specific routine in the way you have. There are often
hundreds of different ways to write an algorithm, each delivering the same output. Therefore, you
should justify your approach where appropriate. Consider space and time complexity, readability and
maintainability of the code and thinking ahead as areas that could lead to good justifications.

Example pseudocode

Pseudocode Justification

FUNCTION sort_processes () This routine sorts the ready

queue for the SJF and SRT
FOR index1 = 1 TO queue.LENGTH
algorithms.
index2 = index1 – 1
It is an insertion sort, which

DESIGN
WHILE index2 > 0 AND queue[index2 -1] > queue[index1]
queue[index2] = queue[index2 -1] is efficient with a small data
index2 = index2 -1 set of less than 64 items.
END WHILE
It will be needed to
queue[index2] = queue[index1]
prioritise processes in the
END FOR
ready queue.
RETURN queue

END FUNCTION

Note how this routine is not written in any specific programming language, although it has clear
similarities with BASIC; this allows you to use commands that may not exist in your target language to
make it easier to produce the pseudocode. You do not need to adhere to the standard illustrated. Use
a pseudocode approach you are familiar with.

Students usually struggle at this point of the project, so if you are feeling overwhelmed, do not worry.
Consider everything you have learned about programming and have a go using the list of simple
commands on the next page. It is acceptable for your real code not to match this algorithm design. If
it looks like you have copied and pasted real code, you will not gain any credit in this section.

33
 Commands you could use in pseudocode

Command Purpose

FUNCTION name (parameter1, parameter2) Functions create a reusable program component

that accepts parameters and returns a value or
RETURN value
structure. They are used to avoid the duplication
END FUNCTION of code that may be used multiple times.

Code should be indented inside functions.

SUBROUTINE name (parameter1, parameter2) Subroutines structure your program into logical
sections. Use one for each major part of your
END SUBROUTINE
code so you do not have one long code listing.

Code should be indented inside subroutines.

variable = value Assign a variable a value – it could be the value

of another variable, a constant or the result of a
function.
DESIGN

IF variable operator value THEN IF is a selection statement that compares the

value of a variable. Remember the operators:
ELSE IF

ELSE = equals
< less than
ENDIF <= less than or equal to
> greater than
>= greater than or equal to
DIV integer division
MOD modulus

Code should be indented inside selections.

FOR variable = 0 TO value FOR is used to repeat lines of code.

END FOR Use a for loop when you know how many
iterations need to be performed.

34
 WHILE variable operator value WHILE is used to repeat lines of code.

END WHILE Use a while loop when the number of iterations

could be variable. For example, with validation,
when you don’t know if the user will enter a
correct value, or when you want a code routine
to end before it is finished.

Many students use IF when they should be using

WHILE and use WHILE when they should be
using FOR.

OPEN FILE filename Files are used to read and write data from
secondary storage. All files need to be opened
WHILE NOT filename.EOF
and closed before data can be read from and
READLINE string written to them.

END WHILE It is common to use a “while the end of file is not

reached” loop to read data until the end of the
CLOSE FILE file, although this may not be necessary.

DESIGN
The linear search iterating over an array is one of the most common algorithms:

value = “what we are looking for”

found = FALSE
index = 0

WHILE NOT found and index < array.LENGTH -1

IF array(index) = value THEN

found = TRUE
ELSE
index = index + 1

END WHILE

Note, you can use either parentheses or square brackets for indexes.

Remember, you can invent commands in pseudocode. For example, if you were stuck writing this
algorithm, you could simplify it to:

IF value IN array THEN

Try to avoid simplifying your algorithms too much because you want to gain some credit for your logical
thinking – only do it when necessary.

35
 Have a pseudocode routine for each major module or algorithm in your program. There is no need to
design trivial algorithms for pressing buttons on GUIs. For example, you may have an interface where
the user clicks a button to open another interface. The pseudocode to achieve this could be:

SUBROUTINE BUTTON on_click()

OPENFORM “frm_Scheduler”
END SUBROUTINE

It is not necessary to include these minor algorithms. Equally, if you are likely to have many repeating
code elements, it would be appropriate to show these only once, but remember, if this is the case, you
would be better off using a subroutine anyway.

Justifications are the key to achieving the

highest grade. Justify why you need the
algorithms you have designed.

It is not essential to justify every line of code; instead, it is acceptable to justify blocks of code. For
example, if you decide to implement a linear search, a sorting algorithm or hashing, you can justify the
algorithm itself and why the alternatives are not suitable.
DESIGN

You will know you have written a good report if the examiner can “follow the thread” of your project
from the initial proposal through the success criteria to a description of the modular nature of the
solution and, finally, the actual algorithm design. Your report needs to be coherent and easy to follow.

Examiner’s advice
“Reverse-engineered code is given no credit.”

36
Identifying the data structures and validation

Now that you have written your algorithms, you should be able to identify all the constants, variables,
data structures and files you need. If you are taking an object-oriented approach, you will need to
include class diagrams.

Class diagrams
There are three rectangular sections to each class diagram.
Name of the class
1. The name of the class.

2. Attributes: the variables and constants.

3. Methods: the subroutines. Attributes

You will have several small class diagrams. If you are using
inheritance, remember to illustrate this with an arrow between
the classes. Child classes point to their parent class.
Methods
Remember, to achieve the top mark band, you need to justify

DESIGN
your choices. If you are using an array, perhaps this is because
you want to iterate through the structure with a loop or maybe you have chosen a list because it is
dynamic and items can easily be added and removed at run-time.

Boolean data types have two states, making them an ideal choice for when situations need to be stored
as “true or false” or “on or off”. In modern developments, programmers often avoid using a Boolean
so a third and fourth state can be introduced later if a future iteration of the project requires it.

Remember, if your program’s values do not change, using constants is more efficient, as the compiler
can use immediate instead of relative addressing, speeding up the execution of your program.

In addition to the classic data structures, you should consider the need for higher-order data structures
such as graphs and trees.

Examiner’s advice
“Candidates who opt to take an object-oriented approach tend to fare particularly well in
the design section, having a clear idea as to how their project can be decomposed.”

37
 An example class diagram

Ready_queue

queue: array of integers

head: integer
tail: integer

Add_process
Sort_processes
Execute_next
IsFull
IsEmpty

If you have adequately described each subroutine and produced pseudocode for it, the purpose of
the methods should be clear.

Each variable, constant and attribute should now be identified; a table is a useful way to do this.
DESIGN

An example of a variable table with justifications

Variable Data type Purpose, justification and validation

queue Array of integers Stores the processes in the ready queue. As

the size of the ready queue is fixed in my
implementation, an array is suitable. The
element holds the number of cycles the
process needs to execute.

head Integer The next process to enter the running state is

at this index position in the queue array.

tail Integer The position of the last process in the ready

queue.

Do not forget to justify any decisions you make about the data structures here.

38
 It may seem odd to justify your variables,
especially if you name them appropriately.
However, justifications are a key requirement of
achieving marks in the top mark band.

As programmers, we are making lots of decisions about how to code the algorithms. For example,
should you use an array or would a list be better? Do you need to store all the data in memory, or
would it be better to use a file? These justifications are important to achieve a mark in the top mark
band because they demonstrate your thinking process.

Files
If your program uses external files, it is important to illustrate the structure of
7318523
how the data is being stored because the relationship between the data and the
4
program will not be immediately obvious.
120
For example, consider the data file to the right, “sim1.txt”. It is not obvious what
the values represent. What is the number “7318523”? Why is it needed?

DESIGN
Using structured files like JSON can help alleviate this. However, if you are using
files to load and save data, you should describe one record of the structure.

An example of an annotated file

sim1.txt

7318523 The seed used to generate the random number sequence.

4 The time slice used for the RR algorithm.
120 The number of cycles to run the simulation for.

Encoding
Using characters or values to represent string data is common in programming. For example, in our
scheduling algorithms program, we could choose the four characters “FCFS” to represent “first come
first serve” or simply assign it the number 1, with the shortest job first algorithm being number 2. You
must explain all the encoding you are using so it is obvious what the values in your code represent.

39
 Identifying test data to be used during iterative
development

At this point, it is worth reflecting on your structure diagram and algorithms and identifying 6–10 key
milestones you will need to achieve. You will use these later in the coded solution.

Example milestones
1. Creating the main interfaces.

2. Adding items to the ready queue.

3. Moving items from the ready queue to the running state.

4. Handling executing processes in the running state.

5. Handling completed processes.

6. Handling blocked processes.

7. Saving and loading results and simulation data.

DESIGN

8. UI features: pause, stop, reset, speed up, slow down.

9. Charting results data.

For each of these key milestones, identify the test conditions you will need for that milestone and
present them in a table.

40
A development test example

Milestone 2: Adding items to the ready queue

Test number What is being tested and inputs Expected output

1 The user selects the “Add A number from 1–100 is accepted. Clicking
process” button, and a pop-up cancel aborts the operation. All other
box prompts them to enter the inputs are rejected.
number of cycles.
The process is added to the ready queue.
Test: -5, 0, 1, 12, 100, 230, H, #

2 If the FCFS or RR algorithm is The processes enter the queue in the

selected, the new process is put at order in which they were input.
the back of the queue.
Queue contains: 5, 12, 8, 9, 4.
Test queue: 5, 12, 8, 9 - input 4.

3 New random processes are added New processes are always added to the

DESIGN
at the correct position in the back of the queue.
queue for FCFS and RR.

4 If the SJR or SRT algorithm is The processes are in the correct order by
selected, the queue is sorted. The the number of cycles.
process with the lowest number of
Queue contains: 6, 8, 8, 9, 12.
cycles is placed at the front.

Test queue: 6, 8, 9, 12 - input 8.

5 New, random processes are New processes always cause the ready
added at the correct position in queue to be sorted.
the queue for SJF and SRT.

Note how it is necessary to test valid, invalid and boundary inputs. Test data should consider a wide
range of input possibilities. The test data here is far from comprehensive, even for this small part of the
program. Developers also perform white-box tests where each of the program paths are explored. For
example, an IF statement has two possible outcomes. The chosen test data chosen may not explore
this sufficiently, so further tests might be required when you know how the algorithms are working.

41
 Identifying further data to be used post-development

Post-development testing includes alpha, beta and integration testing.

Alpha testing involves looking at the success criteria to determine if the solution works as intended
before releasing it to your stakeholders.

Remember to justify the tests you are going to

perform later to achieve top marks.

You may also decide to offer your stakeholders a beta test opportunity so they can suggest any final
refinements and see if it meets their needs.

In the post-development phase, you will be able to test if all the individual modules work together,
known as integration testing. You should prepare scenarios in advance to check the output from the
entire program meets your expectations and those of your stakeholders.

A post-development test example

DESIGN

Post-development test Justification

The FCFS algorithm with the processes 5, 12, 8, 4 should The program should correctly illustrate
execute in 29 cycles. Processes should be output to a a process moving from the ready
finished state in the same order they arrived. queue to running to finished states and
calculate the average wait time.
The average wait time should be calculated as 11.75:
(5 + 17 + 25) / 4

42
Section Do Don’t

Structure of the 18 Provide an overview of the structure of  Be concerned about using a

solution your solution using a diagram to JSP/UML standard.
illustrate how it breaks the problem
down into smaller parts.
Breaking the 19 Provide evidence of problem  Reverse-engineer your
problem down decomposition by explaining each completed program. Your
systematically component of your intended program. code will likely deviate from
these initial design ideas.
20 Include sketches of interface designs. 
Include screenshots from
21 Explain the validation and input 
your finished program.
sanitisation that will be necessary.
Spend too much time on
22 Consider the usability features of your 
graphics and colourful
program and expected UI
illustrations.
conventions.
23 Justify your approaches. 
Algorithms 24 Provide a set of language-  Use flowcharts – they are too
independent algorithms to describe cumbersome for large
each of the subroutines and methods. problems.
25 Use your own pseudocode standard if  Provide code or reverse-
you need to use commands you are engineered code as an
not familiar with. algorithm.
Data structures 26 Provide class diagrams if you are  Forget to include
taking an object-oriented approach. descriptions of any
encoding.
27 Explain and justify the variables and 
data structures you will be using. Forget to include a file
structure reference.
28 Explain and justify the use of any 
external files.
Test data for 29 Identify 6–10 development milestones.  Do this retrospectively – test
development data should be drawn up in
30 Identify the tests that need to be 
advance of development.
performed for each milestone before it
can be considered complete. Forget that good testing
includes a variety of valid,
invalid and boundary tests.
Post- 31 Identify and justify the tests that need  Avoid issues where your
development test to be performed when all the modules program fails – these are
data have been developed. good to talk about, even if
they are not resolved.
32 Identify data that tests the robustness 
of the solution; good testing should Forget that this phase
attempt to break the program. includes integration, alpha
and beta testing.
DEVELOPING A CODED
SOLUTION
The iterative development process.

In this section, you are discussing how you have made a solution to the problem.

15 marks Coded solution

10 marks Testing to inform development

What to include

• Evidence of developing each milestone.

• Explanations of what you did and why.
• Annotated code with suitably named variables and routines.
• Evidence of input validation.
• Review of each milestone.

An agile approach to development

At the end of the design section, you identified six to ten key milestones. In this section, you need to
provide evidence of developing each of those milestones. The development must be an iterative
process; that means you cannot just provide a code listing of your finished product. Instead, you must
document the story of how the development evolved as it was being coded.

DEVELOPING A CODED SOLUTION

It is expected that your development will change from your initial design ideas. Rarely do programs
become exactly what was initially proposed. When you do change your mind, you do not need to go
back and change your analysis and design. Instead, document your changes and the reasons behind
them in this section of your report. If the change is so fundamental that the design no longer resembles
the development, you may want to go back and make your report more coherent, but this should rarely
be necessary unless your analysis was very weak.

In this section of your report, you will be including parts of your code. If practical to do so, it is helpful
to include a full code listing in an appendix at the end of your project. In this section, you will provide
only parts of the code that are relevant to each milestone.

When developing a milestone, you will frequently need to return to previous aspects of the code to
make changes or add new routines. Do not include code sections you have already covered in your
report previously – just the new parts.

Examiner’s advice
“At the top end, candidates have clear and discrete iterations. Each iteration has stated
objectives that were tested and evaluated at the end of the iteration.”

45
 Documenting the milestones
For each milestone, include the following:

1. Objective: In one or two sentences, describe what this milestone achieves.

2. Code listing: Provide a listing of the code for this milestone. Code must be commented with
appropriate variable and data structure names.

3. Explanation of the code: Explain what the code section does and justify algorithms or
approaches. It might not be immediately obvious to an examiner how the code works or why
problems have been solved in the way they have. Remember, the examiner may not be familiar
with the language you are using. If input validation is required, explain that too.

4. Module testing: Explain the tests you performed for this section of code and the outcome of
those tests. You must provide evidence of this process. A few simple screenshots for each
milestone will be enough.

5. User feedback: Your user should tell you what they like and dislike about this aspect of the
development so far, with ideas for future development. Your user must be an integral part of
DEVELOPING A CODED SOLUTION

the iterative development process.

6. Reflections: Discuss what needs to be changed as a result of testing and user feedback.

The very best projects tell the story of the

development. You do not need to comment on
resolving every single error, but you should
explain the challenges you faced.

Rapid application development (RAD) – where a series of evolutionary prototypes are developed,
shown to the user and further developed until the final product is delivered – is how your project should
be documented. Try to avoid a simplistic life-cycle approach. Instead, describe your journey of
development; this should be more like a dev diary and less like a linear explanation of achievements.

Do not forget to justify the approaches you

have taken in the explanation of the code –
especially if they are different to your original
design intentions.

46
Example of part of one milestone
Adding items to the ready queue – sorting the queue for SJF/SRT.

Code I wrote to achieve this milestone:

Sub sort()

'Sort the ready queue using an insertion sort

Dim n As Integer = queue.Count

Dim index, index2, current As Integer

'Iterate over all the processes in the ready queue

For index = 1 To n - 1

current = queue(index)

index2 = index

DEVELOPING A CODED SOLUTION

'Find the place for the process

While index2 > 0 AndAlso queue(index2 - 1) > current

queue(index2) = queue(index2 - 1)

index2 = index2 – 1

'Insert the process in the correct place

queue(index2) = current

End While

Next

End Sub

Examiner’s advice
“Care must be taken that code shown in screenshots is big enough and of a high enough
resolution. Ideally, syntax highlighting should be preserved. It is the responsibility of
candidates to ensure their final PDF or printed copy is readable. Credit cannot be given for
code that cannot be read.”

47
 Explanation of the code

When an item is added to the ready queue, it is appended to the end of the array at the position
pointed to by the tail pointer. The tail pointer is then incremented. I could have inserted the new
process directly into its correct position using a linear search to find the position and then move all the
other items up one index, which would have worked fine. However, I wanted to create a routine that
would sort the ready queue no matter what state it was in. For example, processes that arrived back
from a blocked state can be handled at the same time as new processes. That would enable the
simulation to show the ready queue being evaluated before a process is chosen for execution, which
seemed like a better way to teach how the algorithms work.

I did consider using a few sorting algorithms because they would all work, but I know how to code an
insertion sort, and because the number of items to sort is small, efficiency wasn’t a concern.

When I ran the code, it would fail in the line that finds the correct position for the process.

While index2 > 0 And queue(index2 - 1) > current

The reason for this is because “index2 – 1” could be reading past the bounds of the array. I needed the
execution of the condition to stop if the index was less than two without evaluating the second part of
DEVELOPING A CODED SOLUTION

the expression. I noticed this seemed to happen automatically in other languages I used.

After researching the while loop, I found you could use “AndAlso” to prevent the second part of the
statement being executed if the first part was not met; this solved my problem.

Module testing

I manually added some processes to the array before executing the routine to check it was working. I
tested the following data sets:

• 2, 12, 7, 14, 6 – a random set of data.

• 2, 2, 3, 4, 6, 8 – a sorted set of data with duplicate values.

• 15, 7, 4 – a reverse-sorted set of data.

• 6 – only one item in the array.

• No items in the array.

Once the program is written, I will need to test this routine again without using manual inputs to check
it still functions.

48
Evidence

Examiner’s advice
“There is no need to exhaustively demonstrate each test, but there should be enough evidence
to convince the reader that substantial testing took place. The best projects focus on the more
unusual problems that cropped up during developmental testing (getting libraries to work,

DEVELOPING A CODED SOLUTION

nuances of programming language, issues with file types) rather than trivial syntax errors.”

User feedback

I showed one of my stakeholders the implementation of this algorithm on the interface form. She
commented that the ordering happened so quickly, it was hard to tell what had actually happened.
She suggested that maybe a log feature would be useful to output what was happening at each stage
but also agreed that the simulation speed slider (to be implemented later) might also help.

Reflections

I researched exactly how and when the order of new processes was handled within the scheduling
algorithms to gauge the importance of the visual aspect in understanding the scheduling process. The
results indicate that it is important whether the ordering of processes occurs dynamically as soon as a
process arrives in the queue or before the operating system chooses the process to execute.

It is expected that your coded solution will

deviate from your design. There is no need to
rewrite the design section – this gives you plenty
to write about when documenting a milestone.

49
 Section Do Don’t

Agile 33 Provide evidence of developing each  Provide one code listing as

development milestone using a development diary evidence of the coded
approach. solution without a discussion
of the development process.
34 Include a code listing for the milestone 
and highlight interesting routines. Go back and change your
design section.
35 Explain how the milestone was 
implemented, discussing approaches
you took, as well as how and why they
deviate from the original design.
Code 36 Produce modular code using  Assume that a data structure
procedures, functions and methods. or approach you used is
obvious to the examiner.
37 Use comments at the beginning of 
routines for selection and iterations as Create code for the sake of
a minimum. it if there are suitable library
functions you can use.
38 Use sensible variable and data 
structure names. Copy and paste code
DEVELOPING A CODED SOLUTION

without references.
Development 39 Test the function of each module,  Forget the full range of
testing including possible program paths. validation techniques you
could use.
40 Test a wide range of valid and invalid
inputs and situations. Forget that input sanitisation
is an appropriate technique.
41 Provide evidence of the testing, 
perhaps using a limited number of Forget that drop-down
screenshots. boxes, list boxes and sliders
are validation techniques.
Stakeholders 42 Show your completed milestone to a  Forget to include your
stakeholder for review and capture stakeholder in the
their comments. development process.
Remember, this is an agile
approach, not a software
development life cycle.
Reflection 43 Review each milestone and discuss  Be subjective in your review.
what needs to be changed.
Hide weaknesses in your
44 Explain any changes and modifications  code – discuss them instead.
to the design of the solution that result
from stakeholder feedback.

50
EVALUATION
Reviewing the project.

In this section, you are discussing how effective your project was.

5 marks Testing to inform the evaluation

15 marks Evaluation
 What to include

• Evidence of your program being tested for both function and robustness, ideally
with a video.
• Discussion of each of the success criteria and whether they were full, partially or
not met, including how unmet criteria could be addressed.
• Discussion of the usability features and whether they were successful, a partial
success or a failure, including how any issues could be addressed.
• Consideration of the limitations and improvements that could be made.

Testing to inform the evaluation

In the coded solution section, you performed what is known as “bottom-up testing”. Each module or
milestone was tested independently for functionality as it was being developed. However, at that stage,
you did not test the program as a complete product. Towards the end of a project, a post-development
testing phase takes place before the product is shipped.
EVALUATION

• Integration testing checks all the individual components work together as a whole.

• Alpha testing assesses to what extent the final product achieves the success criteria.

• Beta testing allows the user to test the program for usability before release.

Your testing to inform the evaluation should consider all these types of tests.

You must include both integration testing

and alpha/beta testing to properly test your
program’s interfaces and user experience.

Evidence
It is important to provide evidence of fully testing your program beyond the simple screenshots you
have produced to evidence the completion of a milestone. The examiner will not run your project code.
The only evidence they will see of your program being used is what you present here. The best way to
evidence your solution is to create a video of your program being used.

52
Windows 10 has a built-in feature called Game Bar that will allow you to record your screen. Go to
Settings > Gaming on your PC to control the settings for the Game Bar and see the keyboard shortcuts.
Alternatively, there are plenty of other products you can use too.

It is important your video evidence is methodical and demonstrates:

• Function: The program being used with a comprehensive selection of its features.

• Robustness: Demonstrating that most syntax, logic and run-time errors are handled – this
includes validation checks and error messages.

• Usability: That the product can be used with the interfaces you have designed and that the on-
screen text and messages are useful.

A good approach is to copy your test tables from the design section and add two extra columns to the
end of each table; one to record a timestamp of where the test is performed in the video and a second
to indicate whether the test was passed or failed. Your product does not need to pass every test. What
matters more is that you have good evidence of tests being carried out.

The best evidence covers many eventualities.

Just because an algorithm works for one data
set does not mean it works for others.

EVALUATION
Providing a voice-over that explains what is being tested will help the examiner follow what they are
being shown in your video. There is no need to include a script in your project.

Although this section is only worth five marks, it is the evidence of testing for the coded solution and
the basis of the evaluation, so its importance should not be under-estimated.

53
 Example of a test table

Milestone 1: Adding a new process Evidence

Test no. What is being tested and inputs Expected output Timestamp Pass/Fail

1 The user selects the “Add A number from 1–100 0:30 Pass
process” button, and a pop-up is accepted. Clicking
box prompts them to enter the cancel aborts the
number of cycles. operation. All other
inputs are rejected.
Test: -5, 0, 1, 12, 100, 230, H, #
The process is added
to the ready queue.

2 If the FCFS or RR algorithm is The processes enter 0:31-1:20 Pass

selected, the new process is put the queue in the
at the back of the queue. order in which they
were input.
Test queue: 5, 12, 8, 9 - input 4.
EVALUATION

Queue contains: 5,
12, 8, 9, 4.

3 New random processes are New processes are 1:21-1:40 Pass

added at the correct position in always added to the
the queue for FCFS and RR. back of the queue.

Examiner’s advice
“It is important that evidence of tests is provided. Where there are several similar tests, it is
not necessary to provide a screenshot of all of them, but there should be sufficient evidence
to demonstrate the extent to which the system functions.”

54
There is no “correct” number of tests to perform – it will vary hugely from project to project – but your
testing needs to be comprehensive. For example, you should be testing valid, invalid and boundary
data at the very least. Invalid data can also include invalid characters, no data and data out of range.
Consider some of the more unusual actions that could crash your program, known as “extreme tests”.

Examiner’s advice
“Many candidates provide video evidence of their testing, giving appropriate time codes for
each test in their documentation; this worked extremely well and left the moderator in no
doubt that the system worked as claimed.”

Remember, as is the case with all sections of the project, how you evidence your work is up to you.
There is no requirement to produce a video. You could choose to use a series of screenshots instead,
but that may make it more difficult to illustrate some of the tests you are performing.

For top marks, you should explain how your

EVALUATION
evidence shows that the success criteria have
been met.

Examiner’s advice
“Candidates should aim to take each objective listed in their analysis, cross-reference it with
the tests they have carried out and discuss how successfully the objective has been met.”

55
 Evaluating your program

It is very easy to overlook the importance of the evaluation. Remember, it is worth more marks than the
analysis, equal to the design and, combined with the testing, almost as much as the coded solution.
Therefore, you need to leave yourself enough time to do this section justice.

At this point, all your development and testing work is complete. It may not be 100% how you
envisaged it at the analysis and design stage, but the program is ready to ship! Software developers
are often subject to tight deadlines that they need to meet to get a product to market. Sometimes,
features need to be held back to be released later in patches and updates.

Consider asking a stakeholder to provide you with a review. That will often give you more to write
about because they will see your project from a different perspective. It can be hard to be truly
objective about your project when you have poured your heart and soul into its development.

A user review is not essential but, if done

properly, can provide you with a lot to write
about in this section to achieve higher marks.
EVALUATION

You should copy your success criteria from the analysis section and provide commentary on how
successful you were in achieving each of those goals. For each criterion, state whether it was fully met,
partially met or not met at all. Also, explain how well the criteria was achieved in each case.

Consider the criticisms from your stakeholders. How could you address them if you had more time?
What approaches would be required? Consider the usability and interface of your product. How could
you make the user experience even better? Ideas might include enabling a responsive form design on
a variety of device resolutions. Would your product be better as an app or a web app to make better
use of that platform or increase interoperability?

Include a discussion about how the usability

of the program could be improved.

56
Limitations
You should discuss your limitations in detail. In addition to the time limitations you have already
discussed that impact on the features you can include, there may also be limitations of the language
you are using. For example, in the scheduling simulator, we might conclude that it is a reasonable
compromise to output the data to a text file and allow a spreadsheet to produce the charts, as there is
only limited charting support in our chosen programming language. Had we developed our program
in JavaScript, we could have made use of JS Charts to achieve this.

It is acceptable not to have met criteria and even to state that you do not know how to approach coding
something that proved to be too difficult.

Example of a small section of the evaluation

Criteria Success Evaluation

1 Allow the user to choose Partially met The user can choose between FCFS, SJF, RR
between five scheduling and SRT. The program accurately simulates
algorithms: FCFS, SJF, RR, these algorithms with a wide range of data

EVALUATION
SRT & MLFQ. sets. MLFQ was not implemented because of
the requirement to have multiple queues.
Since I implemented the ready queue as a
class, it would be easy to create multiple
instances of the class to overcome this.

2 Show the user a visual Fully met The interface shows the four process states on
representation of four the screen in four different-coloured areas.
process states: ready, The user can see the processes changing
running, blocked and between these states.
finished.

14 The user can speed up, slow Not met The user can stop and reset but not speed up,
down and pause the slow down or pause. I could implement pause
simulation. using a Boolean flag that prevents the next
stage in the process being executed until the
pause flag is false. I could slow the simulation
using a for loop to make it wait until the loop
finishes, but this will execute at different
speeds on different machines, so it is not ideal.

57
Section Do Don’t

Post- 45 Provide evidence of testing against the  Produce pages and pages
development test plans you created in the design of screenshots – find a more
testing section. efficient way of presenting
your evidence.
46 Use efficient ways of evidencing the 
testing. A video is an ideal alternative Forget that robustness is as
to screenshots. important as function.
47 Provide evidence that the system is  Forget to cross-reference
robust and does not crash too easily. your success criteria – this is
known as “alpha testing”.
48 Consider using a beta test and asking 
your stakeholder for a review.
49 Cross-reference the test evidence 
against the success criteria from the
analysis section to evaluate how well
the solution meets these criteria.
Usability features 50 Show how the usability features have  Use evaluative comments
been tested to make sure they meet that are subjective.
your stakeholders’ needs.
Evaluation 51 Comment on how well the solution  Use a simple tick list to state
matches each of the success criteria. that each criterion was met.
52 Comment on any unmet criteria and  Make comments about how
how these might be approached. much you enjoyed the
project.
53 Comment on any limitations and 
insurmountable problems you faced. Forget to say how you
might address any of the
weaknesses identified in
your evaluation.