computer science research proposal example

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
CASCADE Computer Architecture & Semiconductor Design Centre
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
EEG Declaration
EEG Publications
EEG Research
EEG Resources
EEG Past Seminars
Learning and Human Intelligence Group overview
Quantum Computing Group
Technical Reports
Admissions information
Undergraduate admissions overview
Open days and events
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 Part II projects archive ➥
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 overview
Policy on dissertation, coursework, and tick 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
Continuing to Part III

Early in Michaelmas Term you need to submit a project proposal that describes what you plan to do and how you plan to evaluate it. In order to help with this process, you are assigned two Project Checkers, who, together with your Supervisor and Director of Studies, will provide advice on your ideas. The deadline for project proposals is a little over one week into term, and is a hard deadline .

Choosing a project

You have a great deal of freedom in the selection of a project, and should start narrowing down the possibilities by identifying starting points or ideas that appeal to you. These initial ideas should be refined to a coherent project plan, which is then submitted as the project proposal. The proposal will be discussed informally with your Project Checkers, but is then submitted to the Head of the Department as a formal statement of intent.

The main sources of inspiration are commonly:

Ideas proposed by candidates.
Suggestions made by Supervisors or Directors of Studies.
The project suggestions on the projects web page .
Past years’ projects. Most recent dissertations are available to read online ,
Proposals put forward by industry, especially companies who have provided vacation employment for students.

When ideas are first suggested or discussed it is good to keep an open mind about them—a topic that initially seems very interesting may prove unreasonable on further consideration, perhaps because it will be too difficult. Equally, many ideas on topics that are unfamiliar to you will need study before you can appreciate what would be involved in following them. Almost all project suggestions should also be seen as starting points rather than fully worked out proposals.

Notes on project choice

Some project ideas can be discarded very quickly as inappropriate. It is almost always best to abandon a doubtful idea early on rather than to struggle to find a slant that will allow the Project Checkers to accept it. Projects are expected to have a significant Computer Science content; for example, writing an application program or game-playing program, where the main intellectual effort relates to the area supported rather than to the computation, are not suitable. Projects must also be about the right size to fit into the time available. The implications of this will best be judged by looking at past years’ projects and by discussing plans with a Supervisor or Project Checker. They should not allow you to waste much time considering either ideas that would prove too slight or ones that are grossly overambitious.

It is important to pick a project that has an achievable core and room for extension. You should pick a suitably challenging project, where you will likely have to learn new things in order to successfully complete it. In addition, it is expected that you will make use of existing libraries and tools (i.e. don’t reinvent the wheel) unless there is a good reason for producing your own implementation.

Re-use of projects that have been attempted in the past

Projects are intended to give you a chance to display your abilities as a computer scientist. You are not required (or indeed expected) to conduct research or produce radically new results. It is thus perfectly proper to carry out a project that has been attempted before, and it is commonplace to have two students in the same year both basing their projects on the same original idea.

In such cases it is not acceptable to run a simple action replay of a previous piece of work. Fortunately all projects of the required scale provide considerable scope for different approaches; producing a new variation on an existing theme will not be hard. Furthermore the report produced at the end of a previous attempt at a project will often identify areas that led to unexpected difficulties, or opportunities for new developments—both these provide good scope for putting a fresh slant on the ideas involved.

Supervision

In some cases the most critical problem will be finding a suitable project Supervisor, somebody whom you will see regularly to report your progress and obtain guidance about project work throughout the year. This might be one of your main course Supervisors or a separate, specialist project Supervisor, but it should not be assumed that a person suggesting a project will be willing to supervise it. Supervisors have to be appointed by your Director of Studies, but in most cases it will be left up to you to identify somebody willing and able to take on the task. The Project Checkers will be interested only in seeing that someone competent has agreed to supervise the project, and that your Director of Studies is content with that arrangement.

Each project will have a number of critical resources associated with its completion. If even one of these fails to materialise then it will not be possible to proceed with a project based on the idea; your Director of Studies can help you judge what might be a limiting issue.

The project proposal must contain as its last section a Resources Declaration. This must explicitly list the resources needed and give contact details for any person (apart from yourself) responsible for ensuring their availability. In particular, you should name the person responsible for you if your work requires access to the Department research area. The signatures of these people should also be present on the project cover sheet before submission.

What qualifies as a critical resource?

In some cases a project may need to use data or build on algorithms described in a technical report or other document known to exist but not immediately available in Cambridge. In this case, this must be considered critical even if work could start without the report or data.

Using any hardware or software other than that available through a normal student account on UIS equipment (e.g. MCS) is considered non-standard. This includes personal machines, other workstations (e.g. research machines in the Department), FPGA boards, or even Raspberry Pis if they belong to someone else. Likewise, use of software written or owned by someone else that is not freely available as open-source will be considered as non-standard and should be declared.

Additional MCS Resources

It is reasonable to suppose that disk space and machine time will be made available in amounts adequate for all but extreme projects. Those who consider they may need more should provide a reasoned estimate of the resources required in the project proposal in consultation with the Supervisor. Additional file space should be requested through a web form , noting that:

you should state in your application that you are Part II CST;
requests for small increases of MCS space will need a very brief justification: please don't send your proposal;
requests for substantial increases should also be accompanied by a brief supporting email to [email protected] from your Supervisor.

Note that some MATLAB toolkits are not available on the MCS but might be available on Department accounts.

Use of your own computer

If you are using your own computer, please state its specifications and also state your contingency plan in case it should fail (such as using MCS or another personal computer). Please also state your file backup plan and the revision control system you plan to use. If using your own computer please include the following text in your declaration:

I accept full responsibility for this machine and I have made contingency plans to protect myself against hardware and/or software failure.

Department Accounts

Access to Departmental computers can be granted if there is a good reason, e.g.

collaboration with a particular research group;
use of software not available on the MCS facility.

If you plan to use a Department account then state this and explain why it is needed in your resources declaration. If relevant, the signature of a sponsoring member of the department (e.g. the owner of the specific resource) is required as an extra signature on the project cover sheet. In addition, your Supervisor should send an email to [email protected] requesting the account with a brief justification.

Some Department resources and the people who can authorise their use:

Requests for resources involving a Department research machine should be authorised by a Lecturer, Reader or Professor who is in charge of managing the equipment.

Access to the Department can be granted if there is a good reason. If you require access to the secure part of the William Gates Building, you should state who will be responsible for you whilst you are on the premises. They should sign your Project Proposal Coversheet as a Special Resource Sponsor.

Third-Party Resources

Resources provided by your College, other University departments or industrial collaborators must be declared. The name and contact details (including email address) of the person in charge of the resource must be stated and their signature must be present on the project cover sheet. Resources from third parties can sometimes disappear unexpectedly, so please state why you believe this is not going to happen or else state your contingency plan in case it does.

In the case of projects that rely on support from outside the University it will be necessary to procure a letter from the sponsors that confirms both that their equipment will remain available right up to the end of the academic year and that they understand that the results of work done by students cannot be viewed as secret or proprietary.

You should bear in mind that the Examiners will require electronic submission of your dissertation and code. Therefore, you should not sign anything, such as a non-disclosure agreement, that would prevent you from submitting them.

Working with human participants

If your project involves collection of data via surveys, interviews or online, release of instrumented software, fieldwork, or experiments with human participants, such as usability trials or asking people to evaluate some aspect of your work, then you must seek approval by submitting a human participants request to the departmental Ethics Committee and record that you are going to do this, by ticking the appropriate box on your cover sheet. This must occur before any of these activities start. Please read the Department's ethics policy .

Your project Supervisor will help you to fill in an online form ( read-only version ) containing two questions:

A brief description of the study you plan to do;
The precautions you will take to avoid any risk.

Simple guidance related to the most common types of study is available on the School of Technology Research Guidance site . You may also find it useful to discuss your plans with the person supervising you for the Part II HCI course.

After submitting the ethics review form, you will receive feedback from the Ethics Committee within a few days. You must not start any study involving human participants without approval from the Ethics Committee.

Planning the project

As part of the project proposal, you should provide a detailed description of the work that needs to be performed, broken down into manageable chunks. You will need to identify the key components that will go to make up your final product. Credit is awarded specifically for showing a professional approach using any relevant management or software engineering methods at all stages of project design, development and testing. Plan an order in which you intend to implement the project components, arranging that both the list of tasks and the implementation order provide you with a sequence of points in the project where you can assess progress. Without a set of milestones it is difficult to pace your work so that the project as a whole gets completed on time.

When you have decomposed your entire project into sub-tasks you can try to identify which of these sub-tasks are going to be hard and which easy, and hence estimate the relative amounts of effort involved in each. These estimates, together with the known date when the dissertation must be submitted, should allow you to prepare a rough timetable for the work. The timetable should clearly make allowance for lecture loads, unit-of-assessment coursework, vacations, revision and writing your dissertation. Looking at the details of such a plan can give you insight into the feasibility of the project. Ideally you should plan to start writing the dissertation at least six weeks before the submission date.

Languages and tools

It will also be necessary to make decisions about operating systems, programming languages, tools and libraries. In many cases there will be nothing to decide, in that the essence of the project forces issues. However, where you do have a choice, then take care to balance out the pros and cons of each option. It is expected that students will be prepared to learn a new language or operating system if that is a natural consequence of the project they select.

Uncommon languages or ones where the implementation is of unknown reliability are not ruled out, but must be treated with care and (if at all possible) fall-back arrangements must be made in case insuperable problems are encountered.

Risk management

Projects are planned at the start of the year, and consequently it can be hard to predict the results of decisions that are made; thus any project proposal involves a degree of risk. Controlling and managing that risk is one of the skills involved in bringing a project to a successful conclusion. It is clear where to start: you should identify the main problem areas early and either allow extra margins of time for coping with them or plan the project so that there are alternative ways of solving key problems. A good example of this latter approach arises if a complete project requires a solution to a sub-problem X and a good solution to X would involve some complicated coding. Then a fall-back position where the project can be completed using a naive (possibly seriously inefficient, but nevertheless workable) solution to X can guard against the risk of you being unable to complete and debug the complicated code within the time limits.

Planning the write-up

As well as balancing your risks, you should also try to plan your work so that writing it up will be easy and will lead to a dissertation in which you can display breadth as well as depth in your understanding. This often goes hand-in-hand with a project structure which is clearly split into sub-tasks, which is, of course, also what you wanted in order that your management of your work on the project could be effective.

A good dissertation will be built around a varied portfolio of code samples, example output, tables of results and other evidence of the project’s successful completion. Planning this evidence right from the start and adjusting the project specification to make documenting it easier can save you a lot of agony later on.

Preparing the Project Proposal and consulting Project Checkers

You should keep in touch with both your Project Checkers from the briefing session until the final draft of your project proposal, making sure that they know what state your planning is in and that they have had a chance to read and comment on your ideas. Project Checkers will generally be reluctant to turn down a project outright, but if you feel that yours sound particularly luke-warm about some particular idea or aspect of what you propose you would do well to think hard (and discuss the issues with your Supervisor) before proceeding. If Project Checkers declare a project plan to be unacceptable, or suggest that they will only accept subject to certain conditions, rapid rearrangement of plans may be called for.

Dealings with your Project Checkers divide into three phases between the briefing session and submitting your proposal. Most of the communications will be best arranged by Moodle comments in the feedback box and all submissions of work are on Moodle. Please be sure to take note of the various deadlines .

Phase 1 report: Selecting a topic

You start by preparing a Phase 1 report which, for 23/24 must be submitted on or before the first day of Michaelmas Full Term in October Please pay careful attention to the points raised in the briefing lectures regarding selection of an appropriate topic. You must certainly choose something that has a defined and achievable success criterion. Note also that the marking scheme explicitly mentions preparation and evaluation, so please select something that will require a corresponding initial research/study phase and a corresponding (preferably systematic) evaluation phase.

You should complete a copy of the “Phase 1 Project Selection Status Report” and upload it to Moodle .

Phase 2: Full proposal draft: Filling out details

The details will include:

Writing a description, running to a few hundred words.
Devising a timetable, dividing the project into about 10 work packages each taking about a fortnight of your effort. The first couple of these might be preparatory work and the last three writing your dissertation, with the practical work in the middle. These should be identifiable deliverables and deadlines leading to submission of your dissertation at the beginning of the Easter Term. You will probably write your progress report as part of the fifth work package.
Determining special resources and checking their availability.
Securing the services of a suitable Supervisor.

Send all this to your Project Checkers and ask them to check the details.

Phase 3: Final proposal

In the light of your Project Checkers’ comments, produce a final copy in PDF format.

You do not secure signatures from your Project Checkers at this stage. Simply submit the proposal.

Shortly after submission the Project Checkers will check your proposal again and, assuming that the foregoing steps have been followed carefully, all should be well and they will sign the proposal to signify formal acceptance. If the proposal is not acceptable you will be summoned for an interview.

Submission and Content of the Project Proposal

Completed project proposals must be submitted via Moodle by noon on the relevant day.

Format of the proposal

A project proposal is expected to be up to 1000 words long. It consists of the following:

Project proposal cover sheet , please fill in all required fields as this information is recorded for the Head of Department.
The body of the proposal (see below).

When emailing drafts of your proposal to Project Checkers, please make sure they contain all of the information required on the final cover sheet.

The body of the proposal should incorporate:

An introduction and description of the work to be undertaken.
A statement of the starting point.
Description of the substance and structure of the project: key concepts, major work items, their relations and relative importance, data structures and algorithms.
A criterion that can later be used to determine whether the project has been a success.
Plan of work, specifying a timetable and milestones.
Resource declaration.

Introduction and description

This text will expand on the title quoted for your project by giving further explanation both of the background to the work you propose to do and of the objectives you expect to achieve. Quite often a project title will do little more than identify a broad area within which you will work: the accompanying description must elaborate on this, giving details of specific goals to be achieved and precise characterisations of the methods that will be used in the process. You should identify the main sub-tasks that make up your complete project and outline the algorithms or techniques to be adopted in completing them. A project description should give criteria that can be used at the end of the year to test whether you have achieved your goals, and should back this up by explaining what form of evidence to this effect you expect to be able to include in your dissertation.

Starting point

A statement of the starting point must be present to ensure that all candidates are judged on the same basis. It should record any significant bodies of code or other material that will form a basis for your project and which exist at project proposal time. Provided a proper declaration is made here, it is in order to build your final project on work you started perhaps even a year earlier, or to create parts of your programs by modifying existing ones written by somebody else. Clearly the larger the input to your project from such sources the more precise and detailed you will have to be in reporting just what baseline you will be starting from. The Examiners will want this section to be such that they can judge all candidates on the basis of that part of work done between project proposal time and the time when dissertations are submitted. The starting point should describe the state of existing software at the point you write your proposal (so work that you may have performed over the summer vacation is counted as preparatory work).

Success criterion

Similarly, a proposal must specify what it means for the project to be a success. It is unacceptable to say “I’ll just keep writing code in this general area and what I deliver is what you get”. It is advisable to choose a reasonably modest, but verifiable, success criterion which you are as certain as possible can be met; this means that your dissertation can claim your project not only satisfies the success criterion but potentially exceeds it. Projects that do not satisfy the success criterion are, as in real life, liable to be seen as failures to some extent.

You will need to describe how your project is split up into two- or three-week chunks of work and milestones, as explained in the planning section .

Resource declaration

You should list resources required, as described in the resources section .

Failure to submit a project proposal on time

Any student who fails to submit a project proposal on time is in breach of a Regulation and will no longer be regarded as a Candidate for Part II of the Computer Science Tripos. The Chairman of Examiners will write to the appropriate Senior Tutor as follows:

Dear Senior Tutor,

XXX has failed to submit a project proposal for Part II of the Computer Science Tripos. The Head of Department was therefore unable to approve the title by the deadline specified in Regulation 17 for the Computer Science Tripos [Ordinances 2005, p268,amended by Notices (Reporter, 2010-11, pp.94 and 352, http://www.admin.cam.ac.uk/univ/so/2011/chapter04-section9.html#heading2-43 )]. XXX is therefore in breach of the regulation and is thus no longer eligible to be a Candidate for Part II of the Computer Science Tripos. Please could you take appropriate action. I am copying this letter to the Secretary of the Applications Committee of the Council.

Yours sincerely,

------------------------- Chair of the Examiners Department of Computer Science and Technology William Gates Building JJ Thomson Avenue Cambridge, CB3 0FD

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...