Senior Honours Project

Overview

As part of their studies, all BSc students undertake a substantial Computer Science project in their final year. The project is 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 artifact 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, the SH project is not expected to advance the state of the art the way PhD theses are. However, 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

Projects coordinator: project-coord-cs@st-andrews.ac.uk
Honours coordinator: hons-coord-cs@st-andrews.ac.uk
Director of Teaching: dot-cs@st-andrews.ac.uk

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

SH project modules

CS4099 - Major project (30 credits)

For single honours students
Spread over two semesters

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
Similar to CS4099 with correspondingly smaller scope

CS4796 - Joint project (30 credits)

For joint honours 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)

For information on CS5199 see the MSci project page. For information on CS5099 and CS5098 see the MSc project page.

Project allocation process (CS4099 and CS4098)

The allocation process typically takes place over the summer. 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.

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.

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.

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.

Project deliverables

These are the same for all CS-coded SH projects. 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)
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:

Schedule a meeting with your supervisor(s) to flesh out the description, objectives, and any needed resources.
Write this all up in a word processor, following the structure presented above.
Present this to your supervisor(s) and make sure you all agree with the contents (this can be done via email or in person).
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 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 a further 3 or so secondary objectives which allow a successful project to be extended in interesting directions. 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:

No ethical issues: no human subjects are involved in the project, and no personal data is processed.
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.
Amendment: the supervisor already holds ethics approval covering the project, and the student needs to be added to it.
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

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

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, especially if you do not normally demonstrate your work during your regular meeting. This deliverable is mandatory and failure to submit will result in an academic alert.

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 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 reports in the project library in the student handbook and it is good to study them, as well as looking at the report guidance linked below.

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 15,000, 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 6,000, all of which achieved excellent grades.

Submission

There is a 600 MB limit for MMS submissions. Your submission should include your report, and any artifacts 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!)

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