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
- 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
- Director of Postgraduate Teaching: dopgt-cs@st-andrews.ac.uk
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. Submission of the DOER by the advertised deadline 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.
Final report/dissertation
The final report or dissertation 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 structure and discuss this with your supervisor before writing large parts of the report. Keep in mind when reading reports from previous years that these guidelines may have changed over time.
| Section | Content |
|---|---|
| Title page | Containing the title of the project, your name, student ID, “University of St Andrews”, the title of your degree programme, 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 hereby certify that this dissertation, which is approximately [insert word count] words in length, has been composed by me, that it is the record of work carried out by me and that it has not been submitted in any previous application for a degree. This project was conducted by me at the University of St Andrews from [insert month/year] to [insert month/year] towards fulfilment of the requirements of the University of St Andrews for the degree of [insert degree title] under the supervision of [insert name]. In submitting this project report to the University of St Andrews, I give permission for it to be published online. I retain the copyright in this work.” [insert date] [insert signature] If there is a strong case for the protection of confidential data, the parts of the declaration giving permission for its 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.
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. The timestamp recorded by MMS is the time that the upload completes, not the time when it starts. As usual, it is your responsibility to re-download and check your MMS submissions immediately after submitting.
Extension requests
Some people may need to request an extension for the final submission deadline. The usual process applies: submit a self-certificate and complete the extension request form, taking care to select the Dissertation option for the first question. If a different option is selected, the request will not be routed to the Projects Coordinator, and a delay in processing is likely.
Requests should be made in good time: last-minute requests made on the deadline day are unlikely to be granted. Retrospective extension requests submitted after the deadline will not be approved.
Extensions are not granted for for deliverables with zero credit weighting, i.e. all deliverables before the final deadline. Since they carry no credit, they have no lateness penalties. If you are late with a zero-weighted deliverable, do not submit an extension request, but expect follow up via email and academic alerts.
A request for an extension longer than five days will not normally be approved without supporting medical evidence or input from Student Services. If you are experiencing mental health issues and are not already in contact with Student Services, you should do so now. Remember that the CS Welfare Officers (student-welfare-cs@st-andrews.ac.uk) are also available if you need support.
Good academic practice
It is, obviously, particularly important to be careful in observing Good Academic Practice in your project writing, since your degree is likely to depend on passing the project module. Note that:
- Unauthorised use of AI is considered a very serious form of academic misconduct.
- Project/dissertation submissions will be processed via the Turnitin plagiarism checking tool.
- The likely penalty for academic misconduct in the project/dissertation is a mark of zero, leading to the Honours or Masters degree not being awarded.
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. You should begin with a very short presentation, 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 final module grades are published.
Further information by year of study
The pages linked below give more information on aspects of individual projects that vary by year: