CS Student Handbook

Individual Projects

Overview

This page contains information common to all individual project modules (plus CS5098 Group Dissertation). See also the final section, which contains links to information specific to particular modules.

Important people

Please always use the appropriate alias, not personal email addresses.

DOER deliverable

The first deliverable is a short document referred to as the DOER. There is no fixed template but it must include the sections listed below. Typical length is around two pages of text.

You and your supervisor must agree on everything in the DOER document, so you need to meet to discuss as early as possible. The deadline is the end of week 1. Submission of the DOER is a compulsory module element.

Description

The title and a short description of the project aims, context and background. It should explain the big picture of what you would like to achieve, why it is important, and how you intend to go about doing it (e.g. by using some kind of technology or developing a new algorithm, or following a particular methodology, etc.)

Objectives

This is a list of clearly defined, measurable goals you intend to achieve by the end of your project. This could include any software artifacts you intend to submit in the end, results of an evaluation (for surveys or research algorithms), etc. Your performance will be measured against these objectives.

Typically, you will list about 3–5 primary objectives which are necessary for a project to be deemed successful, and further 3 or so secondary objectives which allow a successful project to be extended in an interesting direction. Occasionally, tertiary objectives may also be listed, but these are comparatively rare.

Ethics

Ethical issues must be considered carefully for all projects. You must complete the CS ethics form as described in the ethics documentation, and include a signed version in the DOER. More detailed guidance is given in the relevant project induction slides, which are linked from each of the year-specific project pages (which are themselves linked at the end of this page).

If you also need to submit a full ethics application or amendment, you are very strongly advised to do so as early as possible.

Resources & risks

This includes a list of any special resources your project will need: hardware, software, licenses, access to infrastructure, external access to School servers, etc. Think ahead, but be realistic – the School will not be able to fulfill all requests. Listing a resource here will not automatically notify the Systems team, so you should also proactively contact them via cs-support@st-andrews.ac.uk.

Most projects can be completed using standard school equipment, in which case this section will contain only a short statement confirming this.

See also: DOER examples.

You must also note any significant risks to the success of the project. This might include reliance on a dataset that you don’t yet have, or failure to receive ethical approval. You must have a backup plan to mitigate any such risks (e.g. using an alternative dataset). If this is not feasible then you need to redesign your project. It is unlikely that any deadline extension will be granted where the request is based on such an identified risk having arisen, or where that risk should reasonably have been identified at the start of the project.

Interim demo

Partway through the project, you must upload your current work to MMS to document your progress. This can include code, any drafts of the report, evaluation scripts, outputs of your algorithms such as graphs, evaluation data, etc.

You must also make arrangements to show your work to your supervisor if you have not already done so during a recent meeting.

The interim demo itself is not assessed, but both elements above are mandatory, and failure to submit and demonstrate will result in an academic alert.

Project submission

There is a 600 MB limit for each MMS submission.

The report itself should be uploaded as a PDF file to the Final Submission - Report slot. Note that this is routed via Turnitin, which imposes a 40MB limit.

Within the restrictions of the file size limit, project artifacts developed by you should be uploaded as a zip file to the Final Submission - Other Materials slot. This should include your own code, scripts and build instructions, configuration files, etc. It should not include:

  • third party code or libraries
  • third party datasets
  • copies of version control repositories (provide a link to the repository instead)
  • virtual machine images
  • large media assets

In particular, note that it is not feasible to upload large multimedia or VR/AR assets to MMS, and that attempted upload may just fail silently without giving a warning of the reason for the failure.

If either report or other materials are submitted late, a lateness penalty corresponding to the later of the submissions will be applied to the overall module grade.

Final demo

You do not have to present your work to other students at the end of the project period, but you do need to give a demonstration to your supervisor and second marker. A demo session is organised in one of the labs a few days after the submission deadline. Most students give their demo then, but if necessary you can negotiate an alternative time with your markers.

The main purpose of the demo is to show what you’ve achieved in addition to the dissertation itself, and the second marker is probably the most important member of the audience (since presumably your supervisor already knows what you’ve done). Don’t assume that the second marker has already read the dissertation; they may not yet have had time, and some people prefer to see the demo first anyway.

So you should think of the demo like an elevator pitch, focusing on the big picture of what you’ve done, and why it was an interesting problem to tackle. Please plan to begin with a very short presentation, delivered at a lab machine, using 3 slides at maximum. This should not be longer than 5 minutes. If you’re not sure what to put on your slides, one approach would be 1) the problem, 2) your objectives, 3) results.

It’s then up to you to decide what aspects you want to demonstrate, and what you want the markers to remember/understand when they leave the session. Immediately after the demo you should submit your slides and other demo materials (if any) to the Materials from Final Demo slot on MMS. The demo isn’t marked separately, but it provides the context for marking the dissertation itself.

Assessment

Projects are independently evaluated by two CS staff. Normal coursework descriptors apply. Assessment is based on the report/dissertation, the demonstration, and the quality and scope of the submitted artifacts. The markers will agree a joint mark and feedback which will be released to students once all marks are finalised.

Further information by year of study

The pages linked below give more information on aspects of individual projects that vary by year:

Back to top

Copyright ©2013-2025. All Rights Reserved.

Last Published: 29 Aug 2025.