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.
Most of the information on Senior Honours project modules is common to other modules: make sure you read carefully the generic projects page.
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. Once agreed, the letter needs to be uploaded to MMS in the appropriate slot.
The School of Maths and Statistics does project allocation before the summer. Our current agreement is that joint CS/Maths students are allocated a supervisor by Maths in 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.
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 each semester, 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. The compulsory elements for Senior Honours project modules include (CS4098, CS4099, CS4796) missing no more than two supervision meetings without approval.
Project deliverables
The deadlines for these are specified on MMS:
- Description, Objectives, Ethics & Resources (DOER)
- 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
See information on generic projects page.
Interim demo
See information on generic projects page.
Final report
The final report forms 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.
The final project report will normally take the following form, although this may be varied if you and your supervisor feel it appropriate. It is always a good idea to produce an early outline of the thesis structure and discuss this with your supervisor before writing large parts of the thesis. Please bear in mind when reading reports from previous years that these guidelines may have changed over recent years.
| Section | Content |
|---|---|
| Title page | Containing the title of the project, your name, “University of St Andrews” and the date of submission. You may add the name of your supervisor if you wish. |
| Abstract | Outline of the project using at most 250 words. |
| Declaration | “I declare that the material submitted for assessment is my own work except where credit is explicitly given to others by citation or acknowledgement. This work was performed during the current academic year except where otherwise stated. The main text of this project report is [insert word count] words long, including project specification and plan. In submitting this project report to the University of St Andrews, I give permission for it to be made available for use in accordance with the regulations of the University Library. I also give permission for the title and abstract to be published and for copies of the report to be made and supplied at cost to any bona fide library or research worker, and to be made available on the World Wide Web. I retain the copyright in this work.” If there is a strong case for the protection of confidential data, the parts of the declaration giving permission for its use and publication may be omitted by prior permission of the Projects Coordinator. |
| Contents page | Table of contents. |
| Introduction | Describe the problem you set out to solve and the extent of your success in solving it. You should include the aims and objectives of the project in order of importance and try to outline key aspects of your project for the reader to look for in the rest of your report. |
| Context survey | Surveying the context, the background literature and any recent work with similar aims. The context survey describes the work already done in this area, either as described in textbooks, research papers, or in publicly available software. You may also describe potentially useful tools and technologies here but do not go into project-specific decisions. |
| Requirements specification | Capturing the properties the software solution must have in the form of requirements specification. You may wish to specify different types of requirements and given them priorities if applicable. |
| Software engineering process | The development approach taken and justification for its adoption. |
| Ethics | Any ethical considerations for the project. Your initial ethics form, and full ethics ‘favourable opinion’ letter if applicable, should be included as an appendix. |
| Design | Indicating the structure of the system, with particular focus on main ideas of the design, unusual design features, etc. |
| Implementation | How the implementation was done and tested, with particular focus on important / novel algorithms and/or data structures, unusual implementation decisions, novel user interface features, etc. |
| Evaluation and critical appraisal | You should evaluate your own work with respect to your original objectives. You should also critically evaluate your work with respect to related work done by others. You should compare and contrast the project to similar work in the public domain, for example as written about in published papers, or as distributed in software available to you. |
| Conclusions | You should summarise your project, emphasising your key achievements and significant drawbacks to your work, and discuss future directions your work could be taken in. |
| Appendix: testing summary | This should describe the steps taken to debug, test, verify or otherwise confirm the correctness of the various modules and their combination. |
| Appendix: user manual | Instructions on installing, executing and using the system where appropriate. |
| Optional: further appendices | If appropriate, you may include other material in appendices which are not suitable for inclusion in the main body of your report, such as mathematical proofs. |
Appendices should be used for material that documents your work, is relevant, but does not need to be in the main body of the report. The main body should stand on its own. You should not include software listings in your project report, unless it is appropriate to discuss small sections in the main body of your report. Code and associated material will be submitted separately to MMS.
While there is no explicit word limit for an SH report, conciseness is desirable, and it will usually not be necessary to go over 15,000 words. If you show a draft 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
See information on generic projects page.
Final demo
See information on generic projects page.
Assessment
See information on generic projects page.
CS4796 projects will also have a marker from the other school.