CS Student Handbook

MSci Project

Overview

As part of their studies, all MSci students undertake a substantial Computer Science project in their final year, resulting in a dissertation. The project is guided by at least one supervisor from the School and is done over the course of one semester.

The development and supervision process is decided by student and supervisor but will involve regular meetings to decide direction and monitor progress. Each student is responsible for managing and completing their project.

There are deliverables due at fixed points through the semester, but marking is holistic. The outcome will be an artifact such as a product, software, or a formal system. Although many projects involve software development, this is not a requirement.

Although many dissertations create exciting new results, the project is not expected to advance the state of the art the way PhD theses are. However, there has to be a novel element to the work, not simply repeating existing work. It is important that it is challenging enough and demonstrates your ability to apply CS skills gained throughout the degree to a large, complex problem.

Important people

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

MSci project module

CS5199 - Individual masters project (60 credits)

  • Taken over one semester (choice of S1 or S2) in the final year.

For information on CS4099, CS4098 and CS4796 see the SH project page. For information on CS5099 and CS5098 see the MSc project page.

Project allocation process

The allocation process typically takes place in late S2 and over the summer, for projects taken in either S1 or S2. Allocation centres around the project proposals list.

Staff advertise projects on the list and students can look for interesting projects. Students should come up with a shortlist of projects and contact the supervisors directly to discuss the project, the requirements (background knowledge and experience, what is expected in terms of programming or maths, supervision style, etc.). Keep in mind that some supervisors get many requests from students and that there is a limit per supervisor. Typically the mean number of students per supervisor is around three.

Once both the supervisor and the student agree, the student should email the project coordinator (and CC all supervisors) to register this choice. The final allocation is done by the project coordinator. The allocation is not finalised until the project coordinator confirms the allocation.

The list allows sorting based on topics, modules, and tags, but these are meant mostly for guidance, so do approach a supervisor if you are interested in a topic even if your module is not explicitly listed.

Self-proposed projects

A small but significant number of students choose to propose their own project. This is fine, but is a bit more involved because the original idea often needs to be refined together with a potential supervisor to make sure that it is relevant, doable, and challenging. Make sure to leave some extra time if you decide to go down this route – don’t leave it to the last moment! There is no automatic right to do a self-proposed project; a project can only be done if a supervisor agrees to supervise it.

In this case, the student writes a 1-2 page summary of what they propose to do, how they propose to do it, and what the outcome will be. Then they can contact a potential supervisor (typically someone with expertise in the topic) asking them to supervise. If you are not sure who would make the best supervisor for a particular topic, contact the project coordinator to make some suggestions.

Once the project is agreed, email the coordinator (and CC the supervisors) as before.

Supervision meetings

You must attend weekly supervision meetings with your supervisor, starting at the beginning of semester 1. At least four of these supervision meetings, well spaced over the semester, must be held in-person, as part of the School’s engagement monitoring process. Beyond this, supervisors have discretion to meet online if they consider it appropriate, or to require students to meet in-person.

Staff sometimes travel for research purposes and other reasons, so it’s possible that your supervisor will be away for parts of the period. If necessary they will arrange for another staff member or a research student to provide informal supervision during their absence.

Supervisors will record meeting attendance in MMS. These records will be monitored and academic alerts will be issued for unapproved absences.

It’s your responsibility to arrange supervision meetings. Failure to do so will be recorded as unapproved absence.

Project deliverables

The deadlines are specified on MMS.

  • Description, Objectives, Ethics & Resources (DOER)
  • Ethics form (ethics category 1/2; see ethics section below)
  • Ethics form (ethics category 3/4; see ethics section below)
  • Context survey
  • Interim demo
  • Final report & materials
  • Final demo

All deliverables are mandatory and you may be issued an academic alert if you miss them. Regular supervision meetings are also mandatory.

DOER

The DOER is a short document you will need to submit as your first deliverable. It is not a form, and has no fixed template, but is a mini report of its own. It generally consists of about two pages of text.

You and your supervisor will have to agree on everything in the DOER document. Typically, the process looks like this:

  1. Schedule a meeting with your supervisor(s) to flesh out the description, objectives, and any needed resources.
  2. Write this all up in a word processor, following the structure presented above.
  3. Present this to your supervisor(s) and make sure you all agree with the contents (this can be done via email or in person).
  4. Submit the DOER to MMS.

In the DOER you must include the following four sections.

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 artefacts 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 for all projects, and one of the following categories selected:

  1. No ethical issues: no human subjects are involved in the project, and no personal data is processed.
  2. Artifact evaluation: the only involvement of human subjects and personal data is a user evalution of the project artifact, limited to members of the university and maximum 60 minutes contact.
  3. Amendment: the supervisor already holds ethics approval covering the project, and the student needs to be added to it.
  4. Full application: if none of the other categories are applicable, a full ethics application must be submitted.

You must indicate which category has been selected in your DOER submission.

If category 1 or 2 is selected, you must also submit the corresponding simple form (signed by supervisor) to the Ethics page on MMS, with the same deadline as the DOER. These forms are linked from the student handbook ethics page.

If category 3 or 4 is selected, you must submit the ethics amendment or full application form to the Ethics page, with a later deadline. This is only for documentation purposes and does not automatically submit the application to the Ethics Committee, so you should also email ethics-cs@st-andrews.ac.uk to say that you have submitted the form. You are very strongly advised to submit applications well before the deadline; this should be considered a final cut-off, after which the project as intended will probably not be viable.

Failure to get ethical approval may endanger your project and hence your degree, so do take this seriously!

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.

Plan and context survey

This deliverable consists of a very early draft of your dissertation – normally as one PDF document. There are three elements:

  • Table of contents with all the chapter and section headings. These will form the skeleton of your dissertation and ensure that it is properly structured;
  • Largely complete review of related work (literature review). This is normally 5-10 pages long and will include citations to most important papers on this topic and explain how they relate to the task;
  • Work plan for the rest of your dissertation period (week-by-week) indicating the main tasks and objectives you will need to tackle and when you will be doing this. This is usually in the form of a table, a Gantt chart, or similar.

Interim demo

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

You should also make arrangements to show your work to your supervisor. This deliverable is mandatory and failure to submit will result in an academic alert.

Final dissertation

The final dissertation is extremely important!

It will form a major part of your final mark, and a poor dissertation can undo a lot of otherwise good technical work. The dissertation should show that you understand your work, show where the design and work went, and convince the markers that it is important and valuable. It should critically reflect on the project and what was achieved.

Dissertations should be understandable to any CS staff – not all markers will be specialists in all fields. Sending a draft to your supervisor for comments is very important and the more time you leave for this, the better the result is likely to be.

There are examples of past dissertations in the project library in the student handbook and it is good to study them, as well as looking at the guidance linked below.

A good dissertation will be well-structured, clear and informative, demonstrate understanding of the topic and related work, and not be overly verbose. Talk to your supervisor for tips and feedback.

There is no explicit word limit for an MSci dissertation, but conciseness is desirable in your writing. MSc projects have a word limit of 15,000, and it will usually not be necessary to go over this for your MSci project. If you show drafts to your supervisor, they will be able to give you guidance on whether you are giving an appropriate level of detail for your particular project. The project library contains projects with word counts as low as 6,000, all of which achieved excellent grades.

See also: MSci dissertation guidance.

Submission

There is a 600 MB limit for each MMS submission.

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

Any project artifacts developed by you should be uploaded as a zip file to the Final Submission - Other Materials slot. This should include original code, scripts and build instructions, configuration files, etc. It should not include:

  • other people’s code, such as libraries
  • copies of repositories (provide a link to the repository instead)
  • python or javascript module trees
  • virtual machine images
  • machine learning datasets (especially not sensitive ones, like medical datasets!)

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

Assessment

MSci projects are normally evaluated by two CS academics. Normal coursework descriptors apply. Assessment will be based on the report, any demonstration, and the quality and difficulty of any submitted artifacts. The markers will agree a joint mark and feedback which will be released to the students once all marks are finalised.

Back to top

Copyright ©2013-2024. All Rights Reserved.

Last Published: 18 Nov 2024.