computer science thesis length

This page is about how to turn your research (once it's done) into a readable multi-chapter document. You need to figure out what to include, how to organize it, and how to present it.

Following this advice will make me happier about reading your submitted or draft dissertation. You may find it useful even if I'm not going to read your dissertation.

Many others have written usefully on this subject , including someone in the Annals of Improbable Research . There's also advice on writing a thesis proposal . However, this page focuses on what a finished dissertation should look like. You could also skim good dissertations on the web.

What Goes Into a Dissertation?

A typical thesis will motivate why a new idea is needed, present the cool new idea, convince the reader that it's cool and new and might apply to the reader's own problems, and evaluate how well it worked. Just like a paper!

The result must be a substantial, original contribution to scientific knowledge. It signals your official entrance into the community of scholars. Treat it as an chance to make a mark, not as a 900-page-tall memorial to your graduate student life.

Beyond stapling

The cynical view is that if you've written several related papers, you staple them together to get a dissertation. That's a good first-order approximation -- you should incorporate ideas and text from your papers. But what is it missing?

First, a thesis should cohere -- ideally, it should feel like one long paper. Second, it should provide added value: there should be people who would prefer reading it to simply reading your papers. Otherwise writing it would be a meaningless exercise.

Here's what to do after stapling:

Taking Responsibility

Don't expect your advisor to be your co-author. It's your Ph.D.: you are sole author this time and the responsibility is on your shoulders. If your prose is turgid or thoughtless, misspelled or ungrammatical, oblivious or rude to related research, you're the one who looks bad.

You can do it! Your advisor and committee are basically on your side -- they're probably willing to make suggestions about content and style -- but they are not obligated to fix problems for you. They may send your dissertation back and tell you to fix it.

In the following sections, I'll start with advice about the thesis as a whole, and work downward, eventually reaching small details such as typography and citations.

Know Your Audience

First, choose your target audience. That crucial early decision will tell you what to explain, what to emphasize, and how to phrase and organize it. Checking it with your advisor might be wise.

Pretty much everything in your thesis should be relevant to your chosen audience. Think about them as you write. Ask yourself:

What does your audience already know?

You can also safely assume that your readers have some prior familiarity with your research area. Just how much familiarity, and with which topics, is a judgment call -- again, you have to decide who your intended audience is.

In practice, your audience will be somewhat mixed. Up to a point, it is possible to please both beginners and experts -- by covering background material crisply and in the service of your own story . How does that work? As you lay out the motivation for your own work, and provide notation, you'll naturally have to discuss background concepts and related work. But don't give a generic review that someone else could have written! Discuss the background in a way that motivates and clarifies your ideas. Present your detailed perspective on the intellectual landscape and where your own work sits in it -- a fresh (even opinionated) take that keeps tying back to your main themes and will be useful for both experts and beginners.

In short, be as considerate as you can to beginners without interrupting the flow of your main argument to your established colleagues. A good rule of thumb is to write at the level of the most accessible papers in the journals or conference proceedings that you read.

What do you want your audience to learn from the thesis?

You should set clear goals here. Just like a paper or a talk, your dissertation needs a point: it should tell a story. Writing the abstract and chapter 1 at the start will help you work out what that story is.

You may find that you have to do further work to really support your chosen story: more experiments, more theorems, reading more literature, etc.

What does your audience hope to get out of the thesis?

Why does anyone crack open a dissertation, anyway? I sometimes do. Especially for areas that I know less well, a dissertation is often more accessible than shorter, denser papers. It takes a more leisurely pace, provides more explicit motivation and background, and answers more of the questions that I might have.

There are other reasons I might look at your dissertation:

For students, reading high-quality dissertations is a good way to learn an area and to see what a comprehensive treatment of a problem looks like. Noah A. Smith once ran a graduate CS seminar in which the students read 8 dissertations together. Each student was also required to select and summarize yet another dissertation and write a novel research proposal based on it.

Readers with different motivations may read your thesis in different ways. The strong convention is that it's a single document that must read well from start to finish -- your committee will read it that way. But it's worth keeping other readers in mind, too. Some will skim from start to finish. Some will read only the introductory and concluding chapters (so make sure those give a strong impression of what you've done and why it's important). Some will read a single chapter in the middle, going back for definitions as needed. Some will scan or search for what they need: a definition, example, table of results, or literature review. Some will flip through to get a general sense of your work or of how you think, reading whatever catches their eye.

High-Level Organization

Once you've chosen your target audience, you should outline the structure of the thesis. Again, the convention is that the document must read well from start to finish.

The "canonical organization" is sketched by Douglas Comer near the end of his advice . Read that: you'll probably want something like it. A few further tips:

Keep your focus

Keep your focus. Length is not a virtue unless the content is actually interesting. You do have as much space as you need, but the reader doesn't have unlimited time and neither do you.

Get to the good stuff

A newspaper, like a dissertation, is a hefty chunk of reading. So it puts the most important news on page one, and leads each article with the most important part. You should try to do the same when reasonable.

Get to the interesting ideas as soon as possible. A good strategy is to make Chapter 1 an overview of your main arguments and findings. Tell your story there in a compelling way, including a taste of your results. Refer the reader to specific sections in later chapters for the pesky details. Chapter 1 should be especially accessible (use examples): make it the one chapter that everyone should read.

Include a road map

Chapter 1 traditionally ends with a "road map" to the rest of the thesis, which rapidly summarizes what the remaining chapters or sections will contain. That's useful guidance for readers who are looking for something specific and also for those who will read the whole thesis. It also exhibits in one place what an awful lot of work you've done. Here's a detailed example .

Where to put the literature review

I recommend against writing "Chapter 2: Literature Review." Such chapters are usually boring: they're plonked down like the author's obligatory list of what he or she was "supposed" to cite. They block the reader from getting to the new ideas, and can't even be contrasted with the new ideas because those haven't been presented yet.

A better plan is to discuss related literature in conjunction with your own ideas. As you motivate and present your ideas, you'll want to refer to some related work anyway.

Each chapter might have its own related work section or sections, covering work that connects to yours in different ways.

Where to define terminology and notation

Basic terminology, concepts, and notation have to be defined somewhere. But where? You can mix the following strategies:

Retail. You can define some terms or notation individually, when the reader first needs them. Then they will be well-motivated and fresh in the reader's mind. If you use them again later, you can refer back to the section where you first defined them.

Wholesale. On the other hand, there are advantages to aggregating some of your fundamental definitions into a "Definitions" section near the start of the chapter, or a chapter near the start of the dissertation:

The downside is that such sections or chapters can seem boring and full of not-yet-motivated concepts. Unless your definitions are novel and interesting in themselves, they block the reader from getting to the new and interesting ideas. So if you write something like "Chapter 2: Preliminaries," keep it relatively concise -- the point is to get the reader oriented.

Thrift shop. Use well-known notation and terminology whenever you can, either with or without a formal definition in your thesis. The point of your thesis is not to re-invent notation or to re-present well-known material, although sometimes you may find it helpful to do so.

Make Things Easy on Your Poor Readers

Now we get down to the actual writing. A dissertation is a lot to write. But it's also an awful lot to read and digest at once! You can keep us readers turning pages and following your argument. But it's a bigger and more complicated argument than usual, so you have to be more disciplined than usual.

Break it down

Long swaths of text are like quicksand for readers (and writers!). To keep us moving without sinking, use all the devices at your disposal to break the text down into short chunks. Ironically, short chunks are more helpful in a longer document. They keep your argument tightly organized and keep the reader focused and oriented.

If a section or subsection is longer than 1 double-spaced page , consider whether you could break it down further. I'm not joking! This 1-page threshold may seem surprisingly short, but it really makes writing and reading easier. Some devices you can use:

subsectioning Split your section into subsections (or subsubsections) with meaningful titles that keep the reader oriented.

lists If you're writing a paragraph and feel like you're listing anything (e.g., advantages or disadvantages of some approach), then use an explicit bulleted list. Sometimes this might yield a list with only 2 or 3 rather long bullet points, but that's fine -- it breaks things down. ( Note: To replace the bullets with short labels, roughly as in the list you're now reading, LaTeX's itemize environment lets you write \item[my label] .)

labeled paragraphs Label a series of paragraphs within the section, as a kind of lightweight subsectioning. Your experimental design section might look like this (using the LaTeX \paragraph command):

Participants. The participants were 32 undergraduates enrolled in ... Apparatus. Each participant wore a Star Trek suit equipped with a Hasbro-brand Galactic Translator, belt model 3A ... Procedure. The subjects were seated in pairs throughout the laboratory and subjected to Vogon poetry broadcast at 3-minute intervals ... Dataset. The Vogon poetry corpus (available on request) was obtained by passing the later works of T. S. Eliot through the Systran translation system ...

footnotes Move inessential points to footnotes. If they're too long for that, you could move them into appendices or chapters near the end of the thesis. (Here's my take on footnotes .)

captions Move some discussion of figures and tables into their captions. Figures and tables should be clearly structured in the first place: e.g., graphs should have labeled axes with units. But a helpful caption provides guidance on how to interpret the figure or table and what interesting conclusions to draw from it. The figure or table should itself include helpful labels (axis

(In LaTeX, you can write \caption[short version]{long version} . The optional short version argument will be used for the "List of Tables" or "List of Figures" at the start of the thesis.)

theorems Even simple formal results can be stated as a theorem or lemma. The theorem (and proof, if included) form a nice little chunk, using the LaTeX theorem enviroment.

Breaking down equations

Long blocks of equations are even more intimidating than long swaths of text. You can break those apart, too:

Intersperse short bits of text for guidance (perhaps using LaTeX \intertext ). You might introduce line 3 of your formula with

A change of variable from x to log x now allows us to integrate by parts:

Distinguish conceptually important steps from finicky steps that just push symbols around. You can even move finicky steps to a footnote, like this:

Some algebraic manipulation 5 allows us to simplify to the following:

Use visual devices like color, boldface, underlining, boxes, or \underbrace to call attention to significant parts of a formula:

Simplify the formulas in the first place by defining intermediate quantities or adopting notational conventions (e.g., "the t subscript will be dropped when it is clear from context").

Now tie it back together

Now that you've chopped your prose into bite-sized chunks, what binds it together?

Coherent and explicit structure

Your paragraphs and chunks have to tie together into a coherent argument. Do everything you can to highlight the structure of this argument. The structure should jump out at the reader, making it possible to read straight through your text, or skim it. Else the reader will get stuck puzzling out what you meant and lose momentum.

Make sure your readers are never perplexed about the point of the paragraph they're reading. Make them want to keep turning the page because you've set up questions to which they want to know the answers. Don't make them rub their eyes in frustration or boredom and wander off to the fridge or the web browser.

So how exactly do you "highlight the structure" and "set up questions"?

Ask questions explicitly and then answer them, as I just did. This is a great device for breaking up boring prose, communicating your rhetorical goals, and making the reader think.

Explicitly refer back to previous text, as when I wrote, "So how exactly do you 'highlight the structure' and 'set up questions'?"

Use lots of transitional phrases (discourse connectives). Note that it's fine to use these across chunk boundaries; that is, feel free to start a new subsection with "For this reason, ...", picking up where the previous subsection left off.

As you come to the end of a section, remind the reader what the point was. If possible, this should lead naturally into the next section.

If a section is skippable, or chapters can be read out of order, do say so. (But don't use this as an excuse for poor organization or long distractions. Some readers tend to read straight through, and in particular, your advisor or committee may feel that they must do this.)

Lots of internal cross-references

A thesis deals with a lot of ideas at once. Readers can easily lose track. Help them out:

Each figure or table should be mentioned in the main text, so that the reader knows to go look at it. Conversely, the figure's caption may point the reader back to details in the main text (stating the section number). A caption may also refer to other figures or tables that the reader should be sure to compare.

Boldface terms that you are defining, as a textbook would. This makes the definitions easy to spot when needed. You may also want to generate an index of boldfaced terms.

Be very consistent in your terminology. Never use two terms for the same idea; never reuse one term or variable for two ideas.

Be cautious about using pronouns like "it," or other anaphors such as "this" or "this technique." With all the ideas flying around, it won't always be obvious to everyone what you're referring to. Use longer, unambiguous phrases instead, when appropriate.

Try saying "the time t " instead of just " t " or just "the time." Similarly, "the image transformation T ," "the training example x i ," etc. This style reminds the reader of which variables are connected to which concepts. You can further do this for expressions: "the total probability Σ i p i " instead of just "the total probability" or "the sum."

Feel free to lavish space where it confers extra understanding. Don't hesitate to give an example or a caveat, or repeat an earlier equation, or crisply summarize earlier work that the reader needs to understand.

Be concrete

As I read a thesis, or a long argument or construction within a thesis, I often start worrying whether I am keeping the pieces together correctly in my head. Something that has become deeply familiar and natural to you (the world expert) may be rougher going for me. If I can see some concrete demonstration of how your idea works, it helps me check and deepen my understanding.

Examples keep the reader, and you, from getting lost in a morass of abstractions. Example cases figured in your thinking; they can help the reader, too. Invented examples are okay, but using "real" examples will also show off what your methods should or can do.

Running examples greet the reader like old friends. The reader will grasp a point more quickly and completely, and remember it better, when it is applied to a familiar example rather than a new one. So if possible, devise one or two especially nice examples that you can keep revisiting to make a series of points.

Pictures serve much the same role as examples: they're concrete and they share how the ideas really look inside your head. A picture is worth at least a thousand words (= 2.5 double-spaced thesis pages).

Pseudocode is a concrete way to convey an algorithm. It is often more concise, precise, and direct than a prose description, and may be closer to your own thinking. It will also make other people much more likely to understand and adopt your methods.

Theorems , too, are concise and precise. They are also self-contained chunks, because they formally state all their assumptions. A reader sloshing through a long, complicated, contextual argument can always grab onto a theorem as an island of certainty.

Experimental results are also concrete. You don't have to wait for the experimental section: it is okay to foreshadow your experiments before you present them in full. When you are developing the theory, you can say "Indeed, we will find experimentally in section 5.6 that ..." You can even showcase an example from your experiments or give some summary statistics; these might not even show up later in the experimental section.

Commitments keep the reader anchored. As noted earlier, your dissertation should discuss alternative solutions that you rejected or are leaving to future work. That's scholarship. But make it clear from the start what you actually did and didn't do. Don't have section 2.3 chatter on about everything one could do -- that reads like a proposal, not a thesis! -- while waiting till section 4.5 or even 2.5 to reveal what you actually did.

Placing these concrete elements early is best, other things equal. Either embed them early in the section or just tell the reader early on to go look at Figure X. (If you continue the section by discussing Figure X, the reader is more likely to actually go look. Figure X or its caption can refer back to the text in turn.)

For example, consider pseudocode. Some readers prefer code to prose, and it's concise. So you may want to give pseudocode early in the section, before you ramble on about why it works. An alternative is to intersperse fragments of pseudocode with your prose explanation, as in literate programming . Of course, the pseudocode itself should also include some brief comments; where necessary these can just point to the text, as in "implements equation (5)" or "see section 3.2."

Sentences. The previous section dealt with sections and paragraphs, but how about sentences? Yours should read well. The best advice in The Elements of Style : "Omit needless words. Vigorous writing is concise." To learn how to improve your sentences, read Style: Lessons in Clarity and Grace , by Joseph M. Williams, and do the exercises. Another classic is On Writing Well , by William Zinsser.

Computers are getting exponentially faster (Moore, 1965). However, Biddle (1971) showed ...

Bandura's (1977) theory ... ... (e.g., Butcher, 1954; Baker, 1955; Candlestick-Maker, 1957, and others). The work of Minor (2001, pp. 50-75; but see also Adams, 1999; Storandt, 1997) ... According to Manning and Schütze, 1999 (henceforth M&S), ...

(Another option is the apacite package, which precisely follows the style manual of the American Psychological Association. It is nearly as flexible in its citation format, but APA style has some oddities, including lowercasing the titles of proceedings volumes. One nice thing about APA style is that if you have multiple Smiths in your bibliography, it will distinguish them where necessary, using first and middle initials. Another nice thing is the use of "&" rather than "and" in author lists; however, you can easily hack plainnat.bst to mimic this behavior.)

\usepackage[colorlinks]{ hyperref } \usepackage{ url }

\usepackage[usenames,dvipsnames,svgnames,table]{xcolor} \usepackage{soul} \newcommand{\todo}[1]{\hl{[TODO: #1]}} \todo{Either prove this or back away from the claim. I think Fermat's Last Theorem might be the key ...}

\newcommand{\todo}[1]{}

... only 58 words in the dictionary have this property. % to get that count: % perl -ne 'print if blah blah' /usr/share/dict/words | wc -l

Version control. It's probably wise to use git (or CVS or RCS or Subversion or mercurial or darcs) to keep the revision history of your dissertation files. This lets you roll back to an earlier version in case of disaster. Furthermore, if you host the repository on your cs.jhu.edu account, it will be backed up by the department.

Sharing your thesis. When you're willing to open up for comments from fellow students, your advisor, or your committee, give them a secret URL from which they can always download the latest, up-to-date release of your thesis, as well as earlier versions. (This is probably friendlier than just pointing them to your git repository.)

Keep this URL up to date with your changes. Each distinct version should bear a visible date or version number, to avoid confusion. For each new version (or on request), you should probably also supply a PDF that marks up the differences from an appropriate earlier version, using the wonderful latexdiff program (available here or as an Linux package; plays nicely with git via latexdiff-git or other scripts ) or a similar technique . (Note: If you use a makefile to build your document by running latex, gnuplot, etc., then you can also make it run latexdiff and update the URL for you.)

If you use Overleaf , just give your committee a view URL for your project. They will be able to see the PDF, visit different versions, and leave comments in the source file.

Planning Your Dissertation

Every dissertation is a little different. Talk to your advisor to draft a specific, written plan for what the thesis will contain, how it will be organized, and whom it will address. Discuss the plan with each of your committee members, who may suggest changes. They might disagree with advice on this page; find out.

As the dissertation takes shape, your plan may need some revision. Your advisor and committee may be willing to provide early feedback. But no one will want to slog through more than a version or two in detail. So ask them each how many drafts of each chapter they're willing to read, and in what state and on what schedule. Some of them nmay prefer to influence your writeup while it's still in an early, outline form. Others may prefer to wait until your prose is fairly polished and easy to read.

In addition to your advisor's goals and your committee's goals, you may have some goals of your own, e.g.,

GOOD LUCK!!! Now, download that LaTeX template , and take the first step toward filling it in today ...

Time Management

Study at Cambridge

About the university, research at cambridge.

Undergraduate courses
Events and open days
Fees and finance
Postgraduate courses
How to apply
Postgraduate events
Fees and funding
International students
Continuing education
Executive and professional education
Courses in education
How the University and Colleges work
Term dates and calendars
Visiting the University
Annual reports
Equality and diversity
A global university
Public engagement
Give to Cambridge
For Cambridge students
For our researchers
Business and enterprise
Colleges & departments
Email & phone search
Museums & collections
Current students
Part II projects
Department of Computer Science and Technology

People overview
Research staff
PhD students
Professional services staff
Affiliated lecturers
Overview of Professional Services Staff
Seminars overview
Weekly timetable
Wednesday seminars
Wednesday seminar recordings ➥
Wheeler lectures
Computer Laboratory 75th anniversary ➥
women@CL 10th anniversary ➥
Job vacancies ➥
Library resources ➥
How to get here
William Gates Building layout
Contact information
Department calendar ➥
Accelerate Programme for Scientific Discovery overview
Data Trusts Initiative overview
Pilot Funding FAQs
Research Funding FAQs
Cambridge Ring overview
Ring Events
Hall of Fame
Hall of Fame Awards
Hall of Fame - Nominations
The Supporters' Club overview
Industrial Collaboration
Annual Recruitment Fair overview
Graduate Opportunities
Summer internships
Technical Talks
Supporter Events and Competitions
How to join
Collaborate with Us
Cambridge Centre for Carbon Credits (4C)
Equality and Diversity overview
Athena SWAN
E&D Committee
Support and Development
Targeted funding
LGBTQ+@CL overview
Links and resources
Queer Library
women@CL overview
About Us overview
Friends of women@CL overview
Twentieth Anniversary of Women@CL
Tech Events
Students' experiences
Contact overview
Mailing lists
Scholarships
Initiatives
Dignity Policy
Outreach overview
Women in Computer Science Programme
Google DeepMind Research Ready programme overview
Accommodation and Pay
Application
Eligibility
Raspberry Pi Tutorials ➥
Wiseman prize
Research overview
Application areas
Research themes
Algorithms and Complexity
Computer Architecture overview
Creating a new Computer Architecture Research Centre
Graphics, Vision and Imaging Science
Human-Centred Computing
Machine Learning and Artificial Intelligence
Mobile Systems, Robotics and Automation
Natural Language Processing
Programming Languages, Semantics and Verification
Systems and Networking
Research groups overview
Computer Architecture Group overview
Student projects
Energy and Environment Group overview
Declaration
Publications
EEG Research Group
Past seminars
Learning and Human Intelligence Group overview
Quantum Computing Group
Technical Reports
Admissions information
Undergraduate admissions overview
Open days and events
Undergraduate course overview overview
Making your application
Admissions FAQs
Super curricular activities
MPhil in Advanced Computer Science overview
Applications
Course structure
Funding competitions
Prerequisites
PhD in Computer Science overview
Application forms
Research Proposal
Funding competitions and grants
Part-time PhD Degree
Premium Research Studentship
Current students overview
Part IB overview
Part IB group projects overview
Important dates
Design briefs
Moodle course ➥
Learning objectives and assessment
Technical considerations
After the project
Part II overview
Part II projects overview
Project suggestions
Project Checker groups
Project proposal
Advice on running the project
Progress report and presentation
The dissertation
Supervisor briefing notes
Project Checker briefing notes
Past overseer groups ➥
Part II Supervision sign-up
Part II Modules
Part II Supervisions overview
Continuing to Part III overview
Part III of the Computer Science Tripos
Overview overview
Information for current Masters students overview
Special topics
Part III and ACS projects overview
Submission of project reports
ACS projects overview
Guidance for ACS projects
Part III projects overview
Guidance for Part III projects

Preparation

Registration
Induction - Masters students
PhD resources overview
Deadlines for PhD applications
Protocol for Graduate Advisers for PhD students
Guidelines for PhD supervisors
Induction information overview
Important Dates
Who is here to help
Exemption from University Composition Fees
Being a research student
Researcher Development
Research skills programme
First Year Report: the PhD Proposal
Second Year Report: Dissertation Schedule
Third Year Report: Progress Statement
Fourth Year: writing up and completion overview
PhD thesis formatting
Writing up and word count
Submitting your dissertation
Papers and conferences
Leave to work away, holidays, and intermission
List of PhD students ➥
PAT, recycling, and Building Services
Freshers overview
Cambridge University Freshers' Events
Undergraduate teaching information and important dates
Course material 2023/24 ➥
Course material 2024/25 ➥
Exams overview
Examination dates
Examination results ➥
Examiners' reports ➥
Part III Assessment
MPhil Assessment
Past exam papers ➥
Examinations Guidance 2023-24
Marking Scheme and Classing Convention
Guidance on Plagiarism and Academic Misconduct
Purchase of calculators
Examinations Data Retention Policy
Guidance on deadlines and extensions
Mark Check procedure and Examination Review
Lecture timetables overview
Understanding the concise timetable
Supervisions overview
Part II supervisions overview ➥
Part II supervision sign-up ➥
Supervising in Computer Science
Supervisor support
Directors of Studies list
Academic exchanges
Advice for visiting students taking Part IB CST
Summer internship: Optimisation of DNN Accelerators using Bayesian Optimisation
UROP internships
Resources for students overview
Student SSH server
Online services
Managed Cluster Service (MCS)
Microsoft Software for personal use
Installing Linux
Part III and MPhil Machines
Transferable skills
Course feedback and where to find help overview
Providing lecture feedback
Fast feedback hotline
Staff-Student Consultative Forum
Breaking the silence ➥
Student Administration Offices
Intranet overview
New starters and visitors
Forms and templates
Building management
Health and safety
Teaching information
Research admin
Miscellaneous

The Dissertation

Continuing to Part III

The dissertation should be written for a technically competent reader who is not necessarily familiar with the particular aspects of Computer Science involved. Better grades will arise from clarity and ease of reading, good pictures, clear explanation, minimal jargon and appropriate use of equations. Writing a dissertation requires planning and time. You should allow at least four weeks for the task.

Dissertation PDF files must be

formatted for A4 paper;
Typeset in 12-point font with a minimum of 2 cm margins;
less than 15 megabytes in size;
(ideally) use embedded fonts.

The main body of the dissertation, running from the first page of the introduction until the last page of the conclusions, shall not exceed 40 pages nor exceed 12,000 words in length (including tables and footnotes). Students should ensure the main body of their dissertation (page 3 onwards) as well as any appendices do not contain direct personal identifiers (i.e. their name or their CRSID).

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.

To facilitate the assessment process, the Examiners require the top-level structure of the dissertation to be strictly as follows:

Declaration of originality

Table of contents.

Chapter 1: Introduction
Chapter 2: Preparation
Chapter 3: Implementation
Chapter 4: Evaluation
Chapter 5: Conclusions

Bibliography

Project proposal.

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.

The cover page

The single cover page contains

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.

Your project title must be the same as the title approved by your Project Checkers on your project proposal. If you want to change the title you should first discuss this with your supervisor. If your supervisor is in agreement you will need to request a change by contacting the Teaching Administration Manager with a brief explanation for the reasons behind the change ([email protected]). This will be approved by the Teaching Administration Manager and Chair of Examiners.

All dissertations must include an anti-plagiarism declaration immediately before the Proforma. 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. [In preparation of this dissertation I did not use text from AI-assisted platforms generating natural language answers to user queries, including but not limited to ChatGPT. / The project required the use of AI-assisted platform [name] in section [number], and such use is acknowledged in the text.] (use either of these sentences as appropriate) [I am content for my dissertation to be made available to the students and staff of the University.]

Signed [signature]

Date [date]

Further guidance relating to the use of AI-assisted tools can be found on the exams guidance web page .

You may either include a scanned copy of your signature or type your full name in place of a handwritten signature.

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 also intended to cover collaborative projects which are not now permitted in Computer Science. As such this aspect is irrelevant 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 the Implementation section below. Other acknowledgements should be given wherever appropriate.

The Department would like past dissertations to be made available for teaching purposes and for your references. These will be accessed on the Computer Science departmental website under Raven password protection. You should include the last sentence of the declaration if you are willing for your dissertation to be accessed for these purposes; otherwise you may remove it. Note: If in the future you would like your dissertation removed from the departmental website, you can request this by contacting the Student Admin office at [email protected].

The proforma page

The single proforma page is a preface that immediately follows the declaration of originality. The proforma page, as well as all subsequent pages of the dissertation should not include direct personal identifiers such as your name or CRSID. The Proforma must be arranged thus:

Your candidate number.
The Title of your Project.
The Examination and Year.
Word-count for the dissertation.
Code line count: Number of lines of code written by the student in the final version of their software.
Project Originator (if this is the student please state 'The candidate').
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 faced. (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.

Student Administration will ask students to resubmit any dissertation which does not include the relevant cover page, declaration and proforma. If such a resubmission occurs after the deadline this will result in a late submission penalty.

This should list the contents in some sensible way.

Introduction

The introduction should explain the principal motivation for the project and 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 refer to appropriate software engineering techniques used in the dissertation. The chapter will also cite any new programming languages and systems which had to be learnt and will mention complicated theories or algorithms which required understanding.

It is essential to declare the starting point. This states any existing codebase or materials that your project builds on. The text here can commonly be identical to the text in your proposal, but it may enlarge on it or report variations. For instance, the true starting point may have turned out to be different from that declared in the proposal and such discrepancies must be explained.

Implementation

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 should be described in order to demonstrate a professional approach was taken.

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 or detailed steps in a machine-checked proof.

The implementation chapter should include a section labelled "Repository Overview". The repository overview should be around one page in length and should describe the high-level structure of the source code found in your source code repository. It should describe whether the code was written from scratch or if it built on an existing project or tutorial. Making effective use of powerful tools and pre-existing code is often laudable, and will count to your credit if properly reported. Nevertheless, as in the rest of the dissertation, it is essential to draw attention to the parts of the work which are not your own.

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 evaluation. Sample output, tables of timings and photographs of workstation screens, oscilloscope traces or circuit boards may be included. Care should be employed to take a professional approach throughout. For example, a graph that does not indicate confidence intervals will generally leave a professional scientist with a negative impression. 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.

Conclusions

This chapter is likely to be very short and it may well refer back to the Introduction. It might offer a reflection on the lessons learned and 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. Attention should be given to correct and consistent formatting.

It is common, but not mandatory, to have one or more appendices. 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 discuss this with the Chairman of Examiners. 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.

Department of Computer Science and Technology University of Cambridge William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD

About the department

Study here Research News Jobs How to get here About the department

Website privacy policy

Social media

Contact the University
Accessibility
Freedom of information
Privacy policy and cookies
Statement on Modern Slavery
Terms and conditions
University A-Z
Undergraduate
Postgraduate
Research news
About research at Cambridge
Spotlight on...