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.
Most of the information on the MSci project module is common to other modules: make sure you read carefully the generic projects page.
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. The compulsory elements for the MSci project module include (CS5199) missing no more than two supervision meetings without approval.
Project deliverables
The deadlines are specified on MMS.
- Description, Objectives, Ethics & Resources (DOER)
- Plan & 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
See information on generic projects page.
Plan and context survey
This deliverable consists of a very early draft of your dissertation, as a single PDF document. This should include 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
See information on generic projects page.
Final dissertation
The final dissertation forms 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.
The final dissertation 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 MSci dissertation, 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.