DISS: Submission

Students must submit their project by the deadline (23/Aug; see the timetable of events). Students need to submit an electronic copy and archive software as detailed below. Paper copies are not required.

Electronic Copy

Students must submit a PDF version of their thesis. These are included in an electronic archive that is accessible to future students. If there are good reasons why a thesis cannot be archived, ensure your supervisor knows the reasons and tick the appropriate box on the submission page.

Generating your thesis in pdf format should be straightforward, using LaTeX (or similar), or a “save to PDF” feature in most word processors. Take care to ensure that all figures, tables and listings are correctly incorporated into the pdf file you plan to submit.

Submit your PDF using this form.

Software

When you submit the electronic copy of your thesis you will also be asked to provide an archive file (tar or zip) containing all the project materials. Students should use this to preserve any software they have generated, source, object and make files, together with any essential data. This material is not marked directly, but may be used to assess the accuracy of claims in the report. It should contain sufficient material for examiners to assess the completion of the project, the quality of the project, and the amount of work required to complete the project.

You should create a directory, for example, named PROJECT, in your file space specifically for the purpose. Please follow the accepted practice of creating a README file which documents your files and their function. This directory should be compressed and then submitted, together with the electronic version of the thesis, via the submission webpage.

Your README should make clear where any data that you used came from, how it was processed, and how any outputs can be generated from the code that you have included. You do not normally need to include large datasets, model outputs, or model checkpoints in your archive. However, sometimes such data might be useful for follow-up projects in future years, or could be important for checking your work. Please discuss with your supervisor what to include.

Demos

While a demonstration is not a compulsory component of your MSc summer project, there are many circumstances in which providing your supervisor and your second marker with a demo will enable them to assess your achievements more accurately.

How to give a good demo

If you do decide to give them a demo, then your examiners will need to be convinced that:

• you actually did something,
• what you did was significant and
• you understand what you did.

You should also try to educate the examiners by clearly presenting:

• what was the problem you were trying to solve,
• how you tried to solve it, and
• what the results were.

As a guide to pitching the level of your explanations, assume that your examiners are ignorant of the particular problem you are investigating, but have a general background in the subject area. Often the second examiner is from outside your project area. So, be sure to introduce your project properly, don't just dive into the middle. What were the aims of the project, how did you go about achieving them, what results did you obtain, what difficulties did you have?

In a typical demo, you might:

• lay down rules about when the audience can ask questions
• explain what the project was about
• explain what you're going to show
• show it, but don't spend lots of time describing low-level implementation detail; stick at the `knowledge level' for the most part
• try to cover as much of the functionality as you reasonably can, so in general don't dwell too long on just one or two aspects
• say what else you might have done if you'd had a bit more time
• wrap up.

Not all projects will follow this outline; modify it to suit your own particular project.

A demo should take about 20 minutes. You will probably find that this is quite a short time, but it is good practice to do it in this time because this is typically the time you will have to demo a system in other scenarios; e.g., at conferences. Given that 20 minutes is not long, you should:

• Plan your demo carefully to cover the relevant details in the allotted time.
• Make an outline of the demo including time to explain the problem, the solution and results.
• Skip minor details if there isn't enough time.
• Practise the demo beforehand, perhaps with another student.
• Consult with your supervisor over your outline.
• Make drawings, charts and tables to clarify the whole context and simplify presentation.
• Pre-store results displays on the computer if it takes a long time to generate them. How long it takes the computer to go through a demo varies by the load; hence, it might be better to avoid too much on-line demonstration if possible.

Two related mistakes that even good students make are: trying to tell the audience EVERYTHING about their project, instead of an overview; and spending too much time giving a lecture about the project instead of using the time to show things working (which is the main reason for the demo).