University Regulations require that dissertations be no longer than 12,000 words (including tables and footnotes, but excluding appendices, bibliography, photographs and diagrams). There is no advantage to be gained from writing up to the maximum, and first class dissertations are often around 10,000 words. The dissertation should be written for a technically competent reader who is not necessarily familiar with the particular aspects of Computer Science involved.
Writing a dissertation requires planning and time. It is prudent to allow three or four weeks for the task. It is particularly important not to rely on printers being in working order during the week before the deadline for submission!
Dissertations must be
- submitted in duplicate;
- on A4 paper;
- in 12-point font.
At least one of the two copies must be printed double-sided (although any colour plates may be printed single-sided in both copies). Each copy must be bound between flexible covers and must lie flat when opened. The Computing Service provides bindings that are particularly suitable: comb binding (which is cheaper and easier to deal with) and metal spiral binding (more expensive).
A PDF version of your dissertation is also required.
Examiners and Assessors are permitted to judge your work only through study of your dissertation, although they will require your original source code to be available for them to refer to in cases where clarification is needed. You will be notified of the process by which you should upload your code (and the PDF copy of your dissertation) shortly before the deadline for the submission of the paper copies of your dissertation. Information about the process can be found at http://www.cl.cam.ac.uk/teaching/projects/submission.htmland some hints on using the MCS for producing PDF files can be found at
To facilitate the assessment process, the Examiners require the top-level structure of the dissertation to be strictly as shown below.
|Declaration of Originality|
|Table of Contents|
It is not the intention of the Examiners to constrain writers too greatly. Although the layout of the Cover Sheet and the arrangement of the Proforma are tightly specified the organisation and length of each of the five chapters are allowed to vary considerably from one dissertation to another.
Further details are given below, and at the end of this document there is a copy of the Guidelines issued to Assessors. The marking scheme is included. Study these Guidelines carefully.
The Cover Sheet
When the dissertation is lying flat and unopened on a table the following information must be immediately visible:
- Your Name, in the extreme top right-hand corner.
- The Title of your Dissertation.
- The Examination for which you are a candidate.
- Your College and the Year in which you are submitting the Dissertation.
Outside the cover sheet there may be a transparent acetate sheet but this is not mandatory.
The Proforma is a preface, which is to be written on a single (right-hand) page, immediately following the cover sheet. The Proforma must be arranged thus:
- Your Name and College.
- The Title of your Project.
- The Examination and Year.
- Approximate word-count for the dissertation.
- Project Originator.
- Project Supervisor.
- At most 100 words describing the original aims of the project.
- At most 100 words summarising the work completed.
- At most 100 words describing any special difficulties that you
(In most cases the special difficulties entry will say “None”.)
It is quite in order for the Proforma to point out how ambitious the original aims were and how the work completed represents the triumphant consequence of considerable effort against a background of unpredictable disasters. The substantiation of these claims will follow in the rest of the dissertation.
Declaration of Originality
All dissertations must include an anti-plagiarism declaration immediately after the Proforma, preferably on the same page if there is room. The declaration must have exactly the following syntax:
I [Name] of [College] , being a candidate for Part II of the Computer Science Tripos, hereby declare that this dissertation and the work described in it are my own work, unaided except as may be specified below, and that the dissertation does not contain material that has already been used to any substantial extent for a comparable purpose.
The University drafted the wording, which is similar to that relating to dissertations in a wide range of subjects; thus the “unaided except as may be specified below” clause merits some explanation:
- The clause does not require acknowledgement of the project supervision or informal conversations with peers.
- The clause is believed to be about collaborative projects which are not now permitted in Computer Science. As such it is not relevant to Computer Science dissertations.
- This clause aside and notwithstanding 1 and 2, candidates are required to draw attention, in the Implementation chapter, to the parts of the work which are not their own, in accordance with section 12.7 of this document. Other acknowledgements should be given wherever appropriate.
When the dissertations are submitted the Student Administrator is required to check that the declaration has been properly included and it will be helpful if each dissertation can be open at the relevant page on submission.
Table of contents
This should list the contents in some sensible way.
The Introduction should explain the principal motivation for the project. Show how the work fits into the broad area of surrounding Computer Science and give a brief survey of previous related work. It should generally be unnecessary to quote at length from technical papers or textbooks. If a simple bibliographic reference is insufficient, consign any lengthy quotation to an appendix.
Principally, this chapter should describe the work which was undertaken before code was written, hardware built or theories worked on. It should show how the project proposal was further refined and clarified, so that the Implementation stage could go smoothly rather than by trial and error.
Throughout this chapter and indeed the whole dissertation, it is essential to demonstrate that a proper professional approach was employed.
The nature of this chapter will vary greatly from one dissertation to another but, underlining the professional approach, this chapter will very likely include a section headed “Requirements Analysis” and incorporate other references to the techniques of Software Engineering.
The chapter will cite any new programming languages and systems which had to be learnt and will mention complicated theories or algorithms which required understanding.
It is important to include a summary of the state of any existing code base or materials that your project builds on. This will commonly be the same information given as the ‘starting point’ in the project proposal (see section 7) with a few additional clarifications.
This chapter should describe what was actually produced: the programs which were written, the hardware which was built or the theory which was developed. Any design strategies that looked ahead to the testing stage might profitably be referred to (the professional approach again).
Descriptions of programs may include fragments of high-level code but large chunks of code are usually best left to appendices or omitted altogether. Analogous advice applies to circuit diagrams.
Draw attention to the parts of the work which are not your own. Making effective use of powerful tools and pre-existing code is often laudable, and will count to your credit if properly reported.
It should not be necessary to give a day-by-day account of the progress of the work but major milestones may sometimes be highlighted with advantage.
This is where Assessors will be looking for signs of success and for evidence of thorough and systematic testing. Sample output, tables of timings and photographs of workstation screens, oscilloscope traces or circuit boards may be included.
As with code, voluminous examples of sample output are usually best left to appendices or omitted altogether.
There are some obvious questions which this chapter will address. How many of the original goals were achieved? Were they proved to have been achieved? Did the program, hardware, or theory really work?
Assessors are well aware that large programs will very likely include some residual bugs. It should always be possible to demonstrate that a program works in simple cases and it is instructive to demonstrate how close it is to working in a really ambitious case.
This chapter is likely to be very short and it may well refer back to the Introduction. It might properly explain how you would have planned the project if starting again with the benefit of hindsight.
It is common, but not mandatory, to have a Bibliography.
Assessors like to see some sample code or example circuit diagrams, and appendices are the sensible places to include such items. Accordingly, software and hardware projects should incorporate appropriate appendices. Note that the 12,000 word limit does not include material in the appendices, but only in extremely unusual circumstances may appendices exceed 10-15 pages - if you feel that such unusual circumstances might apply to you you should ask your Director of Studies and Supervisor to apply to the Chairman of Examiners. It is quite in order to have no appendices. Appendices should appear between the bibliography and the project proposal.
An Index is optional.
A copy of the original project proposal must be included at the very end of the dissertation.
Supervisor’s Report form
A report form, signed by the student’s project Supervisor and Director of Studies and to be found at http://www.cl.cam.ac.uk/teaching/projects/SupervisorForm.pdfmust be submitted to the Student Administrator, preferably at the same time as (but not bound in with) the dissertation, and in any case by 4pm on the following Wednesday.