University Homepage School Homepage School Contacts School Search

Guidelines for the Project Dissertation (INF-4-PROJ)

This web page gives some comments concerning the writing of the project report. These comments do not correspond directly to categories of the marking form - they are mainly based on previous experience in marking projects. The details about the marking form are here. Back to Session 2011-12 webpage (or general projects webpage).

Writing the dissertation

Here are a few comments (by Mary Cryan, previous ug4 project supervisor, with some additions by Helen Pain).

1. The project is marked on your report (backed up by your code). If you have done a suberb job of system-building, and submit a bad report, you risk getting a low score. So please make sure you put sufficient effort into delivering a good report.
2. If you absolutely cannot decide how to structure your report, then having the 5 following chapters will usually work out ok: Introduction, Background, Design, Implementation, Evaluation and Conclusions. Your report does not have to have this structure, not at all, but it is a reasonable place to start for most projects.
3. The Introduction chapter should always provide a `roadmap' to the report. Of course it should provide an introduction to the problem being considered, but it should also give some details of what you did (ie, do not leave this to the conclusion). You should give forward references into the rest of the report - eg, "In chapter 2 how algorithms and heuristics are used to deal with approximate counting are discussed", "The design of the system is presented in Chapter 4", "In chapter 3 teh reasons for chosing to focus on the bounded-degree case of this problem are explained".
4. Structure: Please use the environments available in LaTeX (or whatever processing tool you are using) to structure your report. Use "subsection" and "subsubsection" to separate out topics of each chapter. Important points should also be displayed so that they are more visible than ordinary text (eg, using the "itemize" or the "quote" environment). The reader should not have to read deep into a page of text to ``pick out" a key fact.
5. Through the report, spell out what was *done* (past tense). Make clear what was your contribution to the task. If you are building on an existing system, or using libraries that already exist, make clear the division between your work and existing work.
6. Your report will be read by markers throughout the School of Informatics. Do not assume that your marker is an expert in your subfield. Give some basics as well as the details. Also, make sure you point out what was involved in solving certain problems (this can help a non-expert judge the work involved) - eg, "The interpolation algorithm was implemented in C directly (rather than using the routines in Matlab)". "In order to develop a user interface appropriate for the educational system,  4 prototypes were tested on 50 students".
7. Tenses.
   • I know that many of you use your interim report as part of your final report. If you do this, please change the tenses - from "will .. " to "did ...". It is important to be careful with this as not all tasks proposed before Christmas always get completed.
   • Also, try not to use the "generic tense", eg "CoolApp Systems use hatterbash technolgies for preprocessing of rino-data", if you are talking about your own project: be clear what was done in the particular case of your work. Instead write, "As is common in CoolApp systems, hatterbash technologies were used to preprocess the rino-data" (and continue giving details ...). Generic tense is fine for the background chapter.
   It is often recommended that reports  (and research papers in general) are written in the third person, as opposed to the first person, eg, the above, rather than: "As is common in CoolApp systems, I used hatterbash technologies to preprocess my rino-data". The reason for this is that less experienced writers can sometimes find it be harder to be objective when writing in the first person.  However, it is up to you (and the recommendations of your supervisor) whether you prefer to write in the first or third-person (personally I prefer the latter - but others may disagree....)
8. Your source code. It is helpful for the marker to be able to look at your source (or other type of documentation), as a back-up to the dissertation. Starting in 2008/09, you are required to maintain a subdirectory of your DICE account where you store source code, or processed data, or any supporting evidence which is appropriate to your project. You will be required to submit this entire directory along with your dissertation.
9. If there was some technical challenge which you could not resolve during the period of the project, it will still be useful to devote space in your report to discussing a design (for example) which did not get implemented, or an implementation which was not completed.
10. It is ok to get your classmates to read over your work for grammar, punctuation, feedback on clarity, etc.. But they should not contribute in any way to the technical content of the report.