The Dissertation/Reports
The dissertation/reports is/are extremely important. We give advice
below on how to structure and present your
dissertation/reports. Regulations will be found on the University
website. Please also refer to the relevant section for the requirements of the
group report in case you are doing a group-based project. The
dissertation/reports serves to show what you have achieved and should
demonstrate that:
- You understand the wider context of computing by relating your choice of project, and the approach you take, to existing products or research.
- You can apply the theoretical and practical techniques taught in the course to the problem you are addressing, and that you understand their relevance to the wider world of computing.
- You are capable of criticising your own work objectively and making constructive suggestions for improvements or further work based on your experiences so far.
- You can explain your thinking and working processes clearly and
concisely to third parties who may not be experts in the field in
which you are working.
Remember that second markers, and other readers, will not have
followed the project throughout. Make the presentation reasonably
self-contained. State the objectives clearly; provide sufficient
background material.
Many students underestimate the importance of the dissertation/reports. You should consider that the aim of the project is to produce a good dissertation and that software, hardware, theory etc. that you develop during the project are merely a means to this end. Do not make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last month or two to bring it together into a coherent document.
A typical length for individual project dissertation is 60-100 pages, double spaced. In the case of a group based project a typical length of a group report is 24-40 pages x n, where n is the number of group members, and a typical length of the individual report is 36-60 pages, double spaced. These specifications are guidelines only.
Remember that quantity does not automatically guarantee quality. A 150 page report is not twice as good as a 75-page one, nor a 10,000 line implementation twice as good as a 5,000 line one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in programming, and will be rewarded appropriately. Also, it is important to appreciate that the appropriate size and structure of a report can vary significantly from one project to the next. Despite these variations, however, most good reports have the components below in common.
Below we give an outline of how the dissertation/reports should be
presented. This is for guidance only: University regulations
for the dissertation can be found on the University's policies
webpage These regulations should be followed exactly. The
dissertation/reports must be bound in the university approved
manner. The University Library offers a binding service, as do other
local binderies.
This must be in the standard form described in University regulations.
It is usual to thank those individuals who have provided particularly useful assistance, technical or otherwise, during your project. Your supervisor will obviously be pleased to be acknowledged as he or she will have invested quite a lot of time overseeing your progress.
This should list the main chapters and
(sub) sections of your report. Choose self-explanatory chapter and
section titles and use double spacing for clarity. If possible you
should include page numbers indicating where each chapter/section
begins. The table of contents should not have more than two levels of
headings (say chapters and sections within chapters).
The abstract is a very brief summary of the
report's contents. It should be about half a page long. Somebody
unfamiliar with your project should have a good idea of what it is
about having read the abstract alone and will know whether it will be
of interest to them.
This is one of the most important components of the report. It should begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by the reader. It should summarise everything you set out to achieve, provide a clear summary of the project's background and relevance to other work and give pointers to the remaining sections of the report which contain the bulk of the technical material.
In the case of a group based project, both the group report and the individual report must include details about the contribution of the different group members to the project.
The background section of the report should
set the project into context by relating it to existing published work
(or unpublished work) on which the project builds. The background
section is sometimes included as part of the introduction but more
usually is a separate chapter, or collection of chapters if the
project involved an extensive amount of research. The published work
may be in the form of research papers, articles, text books, technical
manuals, or even existing software or hardware of which you have had
experience. You must acknowledge the sources of your inspiration; you
are expected to have seen and thought about other people's ideas; your
contribution will be putting them into practice or developing them in
some new direction. One rule is clear: if you present another person's
work as your own and do not cite your sources of
information/inspiration you are cheating. When referring to other
pieces of work, cite the sources at the point they are referred to or
used, rather than just listing them at the end. The University takes a
very strict line on plagiarism, and its standard notice on the subject
is included in this Handbook (and is available on the University
website).
The central part of the report usually
consists of three of four chapters detailing the technical work
undertaken during the project. The structure of these chapters is
highly project dependent. Usually they reflect the chronological
development of the project, e.g. design, implementation,
experimentation, optimisation, although this is not always the best
approach. However you choose to structure this part of the report, you
should make it clear how you arrived at your chosen approach in
preference to the other alternatives documented in the background. For
implementation projects you should describe and justify the design of
your program at some high level, e.g. using dataflow diagrams,
pseudocode, ADT specifications, Z, VDL, etc., and should document any
interesting problems with, or features of, your
implementation. Integration and testing are also important to
describe. Your supervisor will advise you on the most suitable
structure for these middle sections.
All projects should conclude with an objective evaluation of the project's successes and failures and suggestions for future work which can take the project further. Even the very best pieces of work have their limitations. You will not have time, and you should not try, to tie up every loose end. You are expected to provide a proper critical appraisal of what you have done. Your assessors are bound to spot the limitations of your work and you are expected to be able to do the same.
Bibliography. This consists of a list of all the books, articles,
manuals etc. used in the project and referred to in the report. You
should provide enough information to allow the reader to find the
source. You should give the full title and author and should state
where it is published, including full issue number and date, and page
numbers where necessary. In the case of a text book you should quote
the name of the publisher as well as the author(s).
The appendices contain information which is
peripheral to the main body of the report. Information typically
included are things like program listings, tables, proofs, graphs or
any other material which would break up the flow of the text if it
appeared. Large program listings are rarely required, and should be
compressed as much as possible, e.g. by printing in multiple columns
and by using small font sizes, omitting inessential code etc.
For projects which result in a new piece of
software you should provide a proper User Guide providing easily
understood instructions on how to use it. A particularly useful
approach is to treat the User Guide as a walk-through of a typical
session, or set of sessions, which collectively display all the
features of your package. Technical details of how the package works
are rarely required. Keep it concise and simple. Do not bother
including instructions at the level of `Turn on the machine, and then
insert disk'. The use of diagrams illustrating the package in action
can often be effective. A user guide is sometimes included as a
chapter in the main body of the report, but is often better as an
appendix to the main report. Do not include user guides for trivial
pieces of code where these are not the main subject of the
dissertation.
Each chapter should have an introduction stating its purpose within
the dissertation and why it is placed at that point, and outlining
what is to be covered in the chapter and why.
Each chapter should finish with a summary describing what it has presented and what is to follow.
Chapters should not be overly long – it is important to show summaries
of ideas and not simply repeat everything that has been read. A
chapter of longer than 20 pages should usually be avoided. When a
chapter is more than 30 pages it should generally be split into two
(or more) chapters.
It is extremely important that you carefully proof read your
work. This should catch most typing errors that are not spelling
errors, for example “form” instead of “from”.
Proof reading means also checking for inconsistencies, disparities,
missing paragraphs, unintelligible sentences, bad formatting of text,
graph and drawings, etc.
The dissertation/reports is/are expected to be written in English as
practised by a native speaker. If English is not your first tongue
then you should consult your supervisor to determine if you need
additional help in this regard. This may involve outside help.
Note: the quality of the English in your
dissertation/reports is solely your responsibility. If you require,
the English Language Teaching Centre organises classes in academic
writing.
You must spell check all parts
of the dissertation/diploma report. A number of tools are available
for spell checking, for example in MS WORD. Such tools should be used
where available.
Note: this is not instead of proof-reading but as well as!
Additional guidelines include: In general, the text should be left and
right justified; All chapter/(sub)section headings should be in
bold-font – with increasingly less eye-catching presentation; All
figures/tables should be numbered and included in the table of
contents; All tables/figures must be referenced in the text; The
author should not normally refer to him/herself explicitly by using
the first person, i.e. we should read the “author”, “s/he”,
etc. instead of “I”, “my”, etc.
