Guidelines for the Project Report (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.
Writing the report
Here are a few comments by Mary Cryan, former UG4 project
supervisor, with some additions by Helen Pain and Don Sannella.
- The project is marked on your report, backed up by your code.
If you have done a superb 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.
- If you absolutely cannot decide how to structure your
report, then having the following five chapters will usually
work out okay: 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
- 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 - do not leave this to the conclusion.
You should give forward references into the rest of the report -
e.g., "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 the reasons for
to focus on the bounded-degree case of this problem are explained".
- Structure: Please use the environments available in
LaTeX (or whatever word processing tool you are using) to structure
your report. Use "subsection" and "subsubsection" to separate
out the topics of each chapter. Important points should also be
displayed so that they are more visible than ordinary text (e.g., 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.
- 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.
- 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. For instance:
"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".
It is often recommended that reports (and research papers in
general) are written in the passive voice, as opposed to active voice, e.g., 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 active voice. However, it is up to you (and the
recommendations of your supervisor)
whether you prefer to write in the active or passive voice. Personally I
prefer the latter - but others may disagree....
- I know that many of you use your interim report as part of
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
- Also, try not to use the "generic tense", e.g. "CoolApp
Systems use hatterbash technologies 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.
- 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
report. 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 report.
If there was some technical challenge that 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) that did not get implemented, or an
implementation that was not completed.
- It is okay to get your classmates to read over your work
for grammar, punctuation, feedback on clarity, etc. But they should
in any way to the technical content of the report.
|Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail:
Please contact our webadmin with
any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright ©
The University of Edinburgh