School of Computer Science and
Information Systems

MSc Computer Science Projects: Notes for Students, Oct 2005

From 1 Jan 2006, this version of this document is no longer kept up-to-date. For a more up-to-date version, readers should consult

Important Dates

Project proposal submission: Monday 15 May 2006
Project report submission: Monday 25 September 2006

Thinking up a project and arranging supervision

You are expected to come up with your own idea for a project. A wide range of topics is acceptable so long as there is a substantial computing content and the project is predominantly of a practical, problem-solving nature. You might focus on a part of the course that you have found interesting. Conversely, you might use the project as an opportunity to get to grips with a topic which is not covered on the course. You might take an interest which you already have, such as astronomy or music, and develop a computer application for it. If you are a part-time student, you might do a project associated with your full-time employment. If you are a full-time student, you might do some work for a business or other organisation, such as a hospital or a charity. There are some extra notes on "real-world" projects at the end of this document.

Unlike a PhD thesis, an MSc report is not expected to make an original contribution to the subject. The project is, rather, a vehicle for you to demonstrate the required level of competence in computer science. Originality will be appreciated, but it is not essential.

Weaker students are cautioned against choosing a project where they are first required to master a new language or software tool. Such students can easily spend over half of the available time just learning the new utility, with the result that what they manage to achieve in using it is rather small.

Stronger students, especially those who might be hoping for a distinction, should choose a project which gives them a significant challenge. A project that was only moderately demanding, even if carried out to a high standard, would be unlikely to gain a distinction grade.

It occasionally happens that students wish to present, as their project, a substantial piece of work that they are carrying out independently, perhaps with a view to commercial exploitation. The College code of practice governing intellectual property rights states that "if a student in the course of studies produces any original works (including computer software) which may be commercially exploitable, the College shall be entitled to the copyright in such works and shall use its best endeavours to secure royalties." The College has never exercised this right in respect of any MSc Computer Science project, but students should be aware that it has this right, or at least thinks it has. The ownership of the intellectual property which students produce for their employers is presumably covered by the students' contracts of employment.

When you have an idea, even only a tentative one, approach a suitable staff member to discuss it further. If you are not sure whom to approach, discuss it with the Projects Tutor. After these discussions, you will end up with a supervisor who has some interest or expertise in the topic of your project. Students who do not seek out a suitable supervisor in this way are eventually allocated a supervisor more or less at random.

Part-time students normally begin this process at the start of the second year, though there is nothing to stop you starting earlier; full-time students begin it at the start of the second term.

The project spec

Early in the summer term in which you take your final exams, you are required to produce a short specification of the project you intend to carry out. This is not merely for our convenience; it is a requirement in the University regulations. Download the template from

Discuss it with your supervisor and, when he has agreed it, send it as an email attachment to the Projects Tutor (, with a copy to your supervisor. The file name should be msccs_projspec followed by your surname and initial, eg msccs_projspec_SmithJ.doc (Do not submit it to the Projects Tutor before your supervisor has agreed it.) Students who proceed with their projects without having agreed a specification with their supervisor risk having their projects refused for examination.

The project specification enables the examiners to form a judgement about whether the project, if carried out satisfactorily, would meet the requirements of the MSc. It is not expected that your project will necessarily follow the specification word for word, but, unless there is a good reason for doing otherwise, you should carry out substantially what the specification describes. If, for some reason, you change to a different project at a later date, you should submit a new specification, again after consultation with your supervisor.

You are also asked on the form to specify any departmental hardware or software that you hope to use in your project. This is particularly important if you intend to use something out of the ordinary. It enables the Systems Group to estimate the probable demand on their resources and to alert supervisors if there is likely to be a problem with this.

Carrying out the project

On the project specification form, you will put down an outline timetable for the project. This provides a yardstick against which you and your supervisor will monitor your progress. Full-timers usually begin work in early June, soon after the summer exams, though they may begin earlier in the year. Part-timers who intend to submit by the end of September will need to begin well before the summer exams. How you arrange your time from day to day is largely up to you.

Students vary in how often they need to see their supervisor; supervisors vary in how often they want to see their students. Something between fortnightly and monthly should suit both sides. Students should bear in mind that supervisors are often absent over the summer vacation and should ensure that their work can still move forward over these periods.

Even students who are content to carry out their work largely without supervision should keep their supervisor in touch with what they are doing. In particular, a student should not remain silent for months and then appear in late September with a completed report. If the Exam Board feels that the student's conduct has prevented adequate supervision, it may insist on a searching oral examination or it may refuse to accept the project for examination at all.

If the project produces a piece of software, the student will normally be required to give the supervisor a demonstration of the software in action. The Board may require a further demonstration at the examination stage.

The supervisor's role is to provide support and encouragement, to direct the student's attention to relevant literature, occasionally to provide technical assistance, to read and comment on the draft report and to give guidance on the standard and amount of work required.

This last point can be a source of difficulty between student and supervisor. Students naturally look to the supervisor for reassurance that their project merits an MSc. You must bear in mind that the supervisor can only give you his(her) opinion. Whether a project is of MSc standard is a matter for the Examination Board to decide. It can happen, and occasionally does happen, that the supervisor thinks that a project deserves to pass but the other examiners disagree.

The project report: general points

Make sure you allow enough time for writing the report. Some supervisors strongly recommend that you write the report as you carry out the project, rather than leaving the write-up until the end. The total time allocated to the report should be about a month for a full-timer, perhaps two or three months for a part-timer. There has to be time for the supervisor to read and comment on it and for the student to make changes (perhaps extensive changes) on the basis of the comments. Bear in mind that your supervisor is supervising several students and cannot be expected to give you full and prompt attention if you all produce your draft reports at the same time.

Remember that it is mainly the report that gets examined. An external examiner, for instance, is presented with a pile of project reports, written by people he does not know. If a project produced some software, he might be able to see it running, but often this will be impossible. In most cases, he has to form his judgement purely on the basis of the report.

The main purpose of the report is to explain what you did in your project. The reader should be able to see clearly what you set out to do and what you achieved. It should be primarily a descriptive and evaluative assessment of the final project as implemented, rather than a chronological account of how the project developed. It should describe the problems to which you addressed yourself and explain why you tackled them in the way you did. It should include your own assessment of how successful the project was. Your stance should be critical and evaluative. Your project will generally be expected to have achieved its goals, especially if it was relatively unambitious to start with, but a project which falls short – perhaps a system is not fully implemented or perhaps the results are disappointing in some way – can still be acceptable as an MSc project; you can demonstrate your grasp of the topic in the observations you make about the project's shortcomings.

We do not insist on a rigid format for project reports; projects vary considerably and the reports naturally reflect this variation. But reports generally run to five or six chapters, plus appendices. There will be a description of the background to the project, to set it in context, perhaps with a brief review of relevant literature. There would usually be a description of the design, possibly but not necessarily using a formal design methodology, and an account of the implementation, focussing on important points that you want the examiners to pay attention to rather than attempting a detailed description of the whole program. (Program documentation is not a substitute for a project report. Documentation is meant to be consulted as and when necessary; a report is meant to be read.) There might be a user manual. There will usually be an account of the testing and, where appropriate, of the user evaluation. There should be a critical evaluation by the student – strong points and weak points, lessons learnt, design decisions which, looking back, would be made differently, ways in which the project could be improved or extended, and so on.

There is no stipulated minimum length. In practice, the length of the text, not including program listings and the like in appendices, is generally about 8000 to 10000 words, but do not pad out your report to reach this length. The length should be dictated by what you have to say. A much shorter report would be acceptable if the content was good. Length in itself is not a virtue; a 20000 word report would be much too long. Resist the temptation to include general background material – the sort of material you would expect to find in lecture notes or textbooks. The examiners want to know about your project. They have many reports to read in a short period and are not pleased to have their time wasted by waffle.

You should assume that the readers of your report will be academics in computer science. If the project consisted of developing an application in an area with which a computer scientist would not necessarily be familiar – such as chemical testing or dealing in stocks and shares – it might be necessary to include some explanatory background. Keep this as short as possible. Remember that the project is intended to show your abilities in computer science.

The work that is presented for the examiners' consideration should be your own, expressed in your own words. Plagiarism – that is, the presentation of another person's thoughts or words or designs or programs as though they were your own – is a serious examination offence and can result in a candidate being disqualified from ever gaining the degree. Direct quotations from the work of others (published or unpublished, in print or downloaded from the internet) must always be clearly identified as such by being placed in quotation marks, and a full reference to the source must be provided. A series of short quotations from several different sources, if not clearly identified as such, constitutes plagiarism just as much as an unacknowledged long quotation from a single source. All projects are routinely submitted to a plagiarism detection service - see below under "Submission".

These rules apply even to your own work if it was conducted for other purposes. If, for example, you quote from a report you have produced at work or if you draw upon work produced for a previous degree or other qualification, you must make this clear.

If you take a program or part of a program from somewhere and incorporate it in your project, you must make it clear in your report that you are not claiming that this is your own work. If your project was developed in the context of some large system or as an extension to previously existing work, it is essential that the reader should be able to see where the other work ends and your work begins.

Students are advised to pay attention to the quality of their English. All too often, a project containing good work is marred by a report which is turgid, obscure or simply ungrammatical. This criticism does not apply solely, or even primarily, to foreign students. While the project is meant to provide evidence of a student's ability in Computer Science rather than in English, an examiner cannot be expected to look kindly on a report that is badly written.

The project report: details

Reports should be prepared with word-processing or text-formatting software. They should be printed on one side of A4 paper. An adequate margin (say 1 to 1½ inches) must be allowed on the left hand side for the binding. The pages should be numbered, including appendices. They should be printed so as to be clear and legible (point size 11 and vertical spacing 15 are recommended).

The first page should be a title page; the next two should be a contents page and a half-page abstract. The abstract is a brief description – typically one paragraph – of the whole project. Beneath the abstract, you should state who the supervisor was. The title page should contain (in addition to the title) the candidate's name and the words MSc Computer Science project report, School of Computer Science and Information Systems, Birkbeck College, University of London and the year. It should then contain the following sentences:

This report is substantially the result of my own work, expressed in my own words, except where explicitly indicated in the text. I give my permission for it to be submitted to the JISC Plagiarism Detection Service.

The report may be freely copied and distributed provided the source is explicitly acknowledged.

In exceptional cases, if there are strong reasons for restricting circulation of the report, the last sentence may be modified, by agreement with your supervisor and with the Course Director.

Program listings and output (other than brief extracts necessary to the discussion) should not appear in the running text, but should be placed as appendices at the end of the report. You should take some care over the layout of listings; begin each new function (class or whatever) on a new page and provide an index to the functions with page references at the beginning of the program. At the very least, you must ensure that the program listings are legible.

The report should not fill more than one volume, including appendices. If the material in the appendices threatens to fill a great many pages (program code, design documents and the like), consult your supervisor on how much of it actually needs to be included. It may be that you need include only the more important sections, or sufficent to illustrate the general standard. This applies particularly to computer-generated documentation.

Generated code, i.e. program code which is the output from some utility or code generator, should be clearly differentiated from programs which you have actually written yourself; sometimes different coloured paper can be used for this. It is particularly important in such cases for the report to be clear so that the readers understand what they are being asked to look at. Such output can be virtually unreadable and you probably need to include very little of it; consult your supervisor.

Where the project has produced software for a PC, you should include a CD inside the back cover of the report (one with each copy). It should be possible for an examiner to run your software, perhaps by accessing a website or perhaps by taking your CD to, say, one of the PCs in room 128 and running it there; you may need to supply any ancillary software on the CD and give clear instructions about how to run it. If it is not, in fact, possible for an examiner to run it, explain why in your report. You should not assume, however, that the examiners will all have access to the required computers; in particular, a CD is no substitute for program listings, screen shots, illustrations of the output and so on.

References to other people's work should be given in full. For a book, this normally includes the name(s) of the author(s), the title, the publisher and date of publication. For an article, it would include the name(s) of the author(s), the title of the article, the name of the journal, the volume number and date and page numbers, as in these examples:

Bloggs F, Advanced Widget Design, Gargoyle Press, 2002

Hardy O and Laurel S, "A software approach to fine mess avoidance", Journal of Disaster Studies, Vol 4, 2000, pp 123-134

Consult your supervisor if you need more help on the layout of references.

Make sure you have time to attend to details before submitting the report. Use a spellchecker. Check that references in the text, such as "See Figure 3" or "as shown in Table 2", do indeed refer to the intended items. Check any mathematics.

Before you take your project for binding, check that you have all the following:
Cover page with:Title
Your name
"MSc Computer ..." etc
The year
"This report is substantially ..." etc
Contents page
Abstract, followed by supervisor's name

The plastic "comb" method should be used for binding the reports. The College Print Unit (in the Main Building) and the Print Shop in ULU provide this service (and also a photocopying service) at very reasonable rates. Allow a couple of days for this if using the College Print Unit. (ULU and commercial print shops do it while you wait.) Your name should appear (sellotaped or otherwise) along the spine of the binder and your name and the title should be clearly visible from the front, either through a clear plastic cover or through a card cover with a window or printed on the front.


You must submit two copies of the printed report to the Exams Tutor by Mon 25 September. He will record the date on which you submit them. Late submission can affect a project's grade. There is no provision for formal extensions, though you may submit a letter to the Exams Tutor explaining why a project was late and the examiners may take this into account.

You also submit an electronic copy of your report as an email attachment to as plain text, a Word document, Postscript, PDF, HTML or RTF. (If the electronic version is extremely large, for example because of graphics, submit a file containing only the text.) The file name should begin PROJ_ followed by the student's surname and an initial, such as PROJ_SmithJ.doc This will be submitted to the JISC Plagiarism Detection Service, which will compare your report with millions of documents on the web, including projects produced by other students, highlighting any passages that appear to come from an existing source. (As a side-effect of this process, your project will be added to its secure database.) The results of this process will be passed on to the examiners. For more information about this service, see

If you undertake your project on a machine other than one maintained by the School, it is your responsibility to back up your work; software/hardware problems with non-School machines (including last-minute problems with printers) will not be accepted as excuses for missing the submission deadline for the project.

Assessment and feedback

Your report is read and marked by two, three or occasionally four examiners. When marking, they pay attention to the following:

  • Background, research, presentation of problem
  • Design and implementation
  • Testing, results
  • Analysis and critical evaluation
  • Presentation of report, documentation
  • Any other aspect of special relevance for this project

Having considered a project under each of these headings, an examiner then settles on a single grade for the project as a whole. For an A grade, a student would have to attempt a challenging project and to gain a high grade under each of the headings. A B grade might be awarded for a respectable, if only partially successful, attempt at a challenging project or for a less ambitious project carried out, and written up, to a high standard. Projects that fail usually do so because they have achieved very little or have done it badly or are poorly written up.

The separate examiners grade it independently and then meet to arrive at an agreed grade. The significance of the grades is as follows:

A– Distinction standard
AB– Borderline distinction
B– Merit standard (a clear B is required for a Merit, not a B-)
C– Standard pass
E– Borderline fail
F– Fail

In addition you might be called upon to make a presentation of your project to a sub-committee of the Examination Board at which the examiners will ask you questions to assess your grasp of the material in your project.

You are informed by letter whether you have passed or failed immediately after the meeting of the Examination Board, which normally takes place in mid-November. A pass list is pinned on the main noticeboard in the department's reception area. You receive a transcript of your results from the College in January or February. You will also receive a copy of the examiners' comments on your project, some weeks after the Board.

One copy of your project report stays with the Department. You should collect the other copy from your supervisor before the end of the autumn term; we do not guarantee to retain them longer than that.


This section applies to students on the MSc/PGDip Computer Science. Slightly different rules apply to the (relatively few) students remaining from the old MSc Computing Science; any of them wishing to defer their projects should contact the Course Director.

A student wishing to defer submission of the project must apply in writing or by email to the Course Director, explaining the reasons. This should be done by the beginning of September. If permission is granted, the student continues work on the project, submitting it in the course of the following year, by the following year's September deadline at the latest. Regardless of when the project is submitted, it will be assessed with the following year's projects at the November board.

No penalty is imposed on students for deferring their projects, and their projects are assessed in the same way as other projects.

Students who have passed the other elements at MSc level may enrol as project-only students, at one third of the regular fee. They should enrol at least for the terms for which they receive supervision. Students are not allowed to submit a project without supervision, so they have to enrol at least for one term.

A student who has passed the written exam and coursework elements at MSc level and who defers the project but does not submit in the following year will be awarded the PGDip.


A student who has failed the project may make one more attempt. This must be in the following year. The following year's project can be an improved version of the first effort or a brand new project, agreed with the supervisor (or with a new supervisor). Students who have passed everything else at MSc level may enrol as project-only; others would enrol as revision students.

Resit projects are assessed in the same way as other projects, but a resit student who would otherwise have been awarded a Merit will be awarded a Pass, and one who would otherwise have been awarded a Distinction will be awarded a Merit.

Students who have passed the written exam and coursework elements at MSc level and who have failed the project may choose to be awarded the PGDip. If they do not submit in the following year, they will be awarded the PGDip anyway.

Notes on "real-world" projects

"Real-world" projects are those that involve outside organisations, such as industrial or commercial companies (large or small), hospitals, schools, charities and so on. While projects of this kind can provide valuable experience for students, they may carry a greater element of risk than "in-house" projects and need to be approached with more care.

Most of this section applies more to full-time students' projects, but I will say a little first about part-time students.

Part-time students often do projects associated with their full-time employment. These rarely raise any particular difficulties because the relationship of the student to the employer is that of an employee; the rights, responsibilities and obligations of the two sides follow from that; Birkbeck's involvement is relatively incidental. The one complication which sometimes arises is where some aspect of the work is confidential, perhaps for commercial or military reasons. If this is so, it is the student's responsibility to obtain whatever clearance is necessary from the employer. If it is essential for the supervisor to see sensitive material, the supervisor might be prepared to sign some undertaking of confidentiality, but the student and the employer should be aware that the MSc project report itself is normally a public document and should therefore contain nothing of a sensitive nature.

The position of full-time students working for an outside organisation is not so self-evident, and the following points should be made clear to both sides at the outset.

The project element of the MSc gives students an opportunity to demonstrate a level of competence in computing. In a real-world project, an outside organisation is providing the context for this exercise, perhaps out of goodwill, perhaps in hopes of getting some useful work done or of attracting talented graduates as potential employees. Each side should appreciate the fairly limited extent of the commitment being made by the other. The student should not assume that the organisation is under any obligation to provide whatever support is necessary for the completion of the project. Nor should the organisation assume that the student is taking on the duties of a contract programmer, or that the staff of Birkbeck are taking on the duties of consultants.

More specifically, the student does not undertake to produce any deliverables (designs, pieces of software etc). Nor does the supervisor, the department or the College. In practice, students usually work hard on their projects and often produce work that is of some value to the organisation, but there is no guarantee of this. It follows that the student should not receive payment for the work in the sense of a salary or a prearranged fee, since this would imply some sort of contractual obligation to produce the goods.

Similarly, the supervisor cannot be held responsible if something goes wrong. If, for example, a student corrupts a data file or deletes some software, the organisation cannot blame Birkbeck. It is up to the organisation to take precautions (backups etc) before putting students into positions where they could do such things.

Equally, the organisation is under no obligation to provide necessary equipment, advice and the like. It can happen that some promised piece of hardware or software or some crucial file of data fails to appear. Perhaps some key contact people are assigned to other duties, or perhaps they find it difficult under day-to-day pressures to provide as much help as the student would like. These are risks that the student takes with this sort of project. If a project founders, then, depending on the stage the project has reached, the student must either make the best of whatever can be salvaged or perhaps begin a different project. The examiners should be made aware of any such problems and will take account of them in assessing the project.

Real-world projects that go wrong in the ways just described are the exception, not the rule, but some problems could be avoided if both sides were clearer about the above points from the start.

In cases where two or more students are working in the same place, they must have clearly distinct projects. In addition the projects must not be so interdependent that the completion of one student's project depends on the successful completion of another student's project.

A list of some project titles submitted for the MSc in recent years

  • Mobile parliamentary statistical information service
  • A bibliographic data strategy for the British Council's information division
  • Breaking the ENIGMA: two emulators for cryptological machines
  • A parallel text and audio tool for language learning
  • A dynamic load balancer for the Microsoft .Net Framework
  • Modelling digital circuitry using cellular automata
  • Analysis of birdsong patterns
  • Emulator for Motorola 68000 microprocessor
  • Polyomino tiling
  • A secure web-based election and results service
  • Digital audio mixer
  • Buiding and running a Beowulf cluster
  • Literary pastiche evaluator
  • Face recognition using neural networks
  • Applying the computer to environmental impact assessment in highway planning
  • An interactive website for an international disability rights charity
  • Query translation in heterogeneous database environments
  • A parish register reader and analyser
  • A Bayesian technique for spam filtering
  • A typing training aid for dyslexics
  • Direct control of the video hardware in the IBM PC family of computers
  • Producing SQL queries from restricted grammar English sentences
  • XML document editor with graphical interface
  • A program for risk evaluation for the London Underground
  • Motorcycle data logger
  • A web-based expert system for providing tailored HIV information
  • Improving the reliability of static perimetry data for the diagnosis of glaucoma
  • Application of neural networks to the prediction of earthquakes in northern California
  • Visualisation of gene expression data
  • Cryptic crossword compiler
  • A toolkit for interpreting MIDI files
  • A window-based interface for a multi-user dungeon in Java
  • Navigation around a web-based art exhibition
  • A bed use optimisation system for a general hospital
  • Patient haemoglobin type maintenance and enquiry system
  • Speech-enabled cinema booking and information system
  • A program for finding the best line of play in a bridge hand
  • A server application to model the depressuring of a pressure vessel
  • Divers' training aid
  • PC navigational tool using GPS and O.S. mapping
  • A hyperbolic viewer for a taxonomy database
  • A kernel driver for the Connectix Colour Quickcam
  • Predicting the FTSE100 with neural networks
  • Mobile TV playalong
  • An internet protocol for secure, controlled real-time trading
  • An N-body gravitational simulation of the solar system
  • How to query a music database effectively
  • Encryption and digital signature for court documents
  • A force directed graphing algorithm to produce a search trail interface