Overview

As part of their studies, all BSc students undertake a substantial Computer Science project in their final year. The projects are guided by at least one supervisor from the School and is typically done over the course of two semesters.

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 year, but marking is holistic. The outcome will be an artefact such as a product, software, or a formal system. Although many projects involve software development, this is not a requirement.

Although projects often create exciting new results, SH projects are not expected to advance the state of the art the way PhD theses are. However, it is important that they are challenging enough and demonstrate your ability to apply CS skills gained throughout the degree to a large, complex problem.

Important people

Please use the appropriate alias and not personal email addresses to avoid unnecessary delays.

SH Project modules

CS4099 - Major project (30 credits) - For single honours students (BSc). This will be the majority. - Spread over two semesters - MSci students should take CS5199 instead

CS4098 - Minor project (15 credits) - For joint honours students doing a separate project with each school - Can be spread over two semesters (more common), or done in a single semester - Very similar to CS4099 other than a smaller scope

CS4796 - Joint project (30 credits) - For joint honours (e.g. BSc in CS and Maths) students doing a single project with both schools - The topic has to be strongly related to both schools and have a supervisor from each school - CS deadlines and marking arrangements apply by default - Requires formal agreement between schools (Letter of Agreement) signed by both supervisors and DoTs - There are equivalent modules offered by other schools (e.g. MT4796)

Project allocation process (CS4099 and CS4098)

The allocation process typically takes place over the summer. Allocation centres around the project blog

Staff advertise projects on the blog 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.

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 blog 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.

Proposing own 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!

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.

Project allocation process (CS4796)

This is very similar, except you will need a supervisor from each school. It is the nature of joint projects that they are less likely to be found on the project blog, so many of these are proposed by the students themselves. If you have an idea, by all means contact the project coordinators in both schools and ask them who to contact in each school about a possible collaboration.

Once the project has been agreed with supervisors and cleared with the project coordinator, you will need to contact the DoT (Director of Teaching) in each school and have them sign the Letter of Agreement (LoA). This letter will define any special arrangements for the project. For example joint projects with Maths will normally involve a separately weighted presentation component instead of a poster presentation.

Once agreed, the LoA needs to be uploaded to MMS in the appropriate slot.

The School of Maths and Stats does their allocation before the summer. Our current agreement is that joint CS/Maths students are allocated a supervisor by Maths this way, but are allowed to switch to a joint project during the summer if they manage to agree one later. Get in touch with the project coordinator if this affects you.

Project deliverables

These are the same for all CS-coded SH projects. The exact deadlines are set separately for each year, and the example deadlines listed below are for orientation only. The dates on MMS are definitive.

  • Description, Objectives, Ethics & Resources (DOER)
  • Around the end of week 2, S1
  • Interim Demo

  • Around the end of week 1, S2
  • Final report & software

  • Around week 9, S2
  • Poster & demo

  • Around week 10, S2 (TBC)•MMS is the definitive source!

All deliverables are mandatory and you may be issued an academic alert if you miss them. Regular meetings with the supervisors are also mandatory. For all SH project students, attendance at the DLS is also mandatory and will result in grade penalty if missed.

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

Here you should discuss any ethical considerations pertaining to your project. Start with the self-assessment form from the Student Handbook (Ethics section). If you can answer “No” to all questions on the self-assessment form, this section of the DOER document will be brief and state that there are no ethical considerations.

If you are planning to work with people (especially children), animals, sensitive private data, or if there are other considerations, you should discuss them here, and explain how you went about obtaining necessary approval (any Ethics applications).

The self-assessment form and any other relevant documents (if applicable) should be scanned and uploaded to the “Ethics” slot on MMS. See the Ethics section below.

Resources

This is a list of any special resources your project will need: hardware, software, licenses, access to infrastructure (e.g. compute servers), drones, etc. Think ahead, but be realistic – the School will not be able to fulfill all requests.

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

Ethics

Many projects will require ethical approval. This may involve sensitive or personal data, medical records, conducting interviews, or similar. The procedure is in the Ethics section of the student handbook:

The basic process is as follows:

  • Fill the self-assessment form
  • If not covered by the self-assessment form, check the CS-specific ethics form
  • If not covered, a full ethics application is needed

In all cases, upload a draft to MMS by deadline. Projects that fail to get ethical approval may endanger the project and the degree so do take this seriously!

Assessment

SH projects are normally evaluated by two CS academics (CS4796 will also have a mark from the other school). Normal coursework descriptors apply. Assessment will be based on the report, any demonstration, and the quality and difficulty of any submitted artefacts. The markers will agree a joint mark and feedback which will be released to the students once all marks are finalised.

Final report

The final report is extremely important!

It will form a major part of your final mark, and a poor report can undo a lot of otherwise good technical work. The report 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.

Reports should be understandable to any of our faculty – 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 reports in the project library in the student handbook and it is good to study them, as well as looking at the report guidance on Students Resources.

A good report 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 SH project report, but conciseness is desirable in your writing. MSc projects have a word limit of 15000, and it will usually not be necessary to go over this for your SH 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 6000, all of which achieved excellent grades.

Submission

There is a 600 MB limit for MMS submissions. Nobody should be uploading anything near this much. Your submission should include your report, and any artefacts developed by you such as 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 machines such as JVM
  • machine learning datasets (especially not sensitive ones, like medical datasets!)

Back to top

Last Published: 25 Nov 2022.