School of Computer Science
Guidance Notes for
Undergraduate Final Year Projects
and MSc Computer Science projects
1. Aims of the project
1a. Credit weighting of the project
1b. Software Project for the MEng in Computer Science/Software Engineering
2. Selecting a supervisor
3. Dissertation-only projects
4. The proposal
5. Working with your supervisor
6. The project inspection and presentation/demonstration
7. The dissertation
8. The deadline and the assessment
8a. Note on problems of demonstrating software developed elsewhere
9. Note on plagiarism
10. Intellectual Property Rights
The final project is the culmination of your degree programme. It allows you to demonstrate your competence as a computer science professional, and to apply what you have learnt in the other components of your degree course.
These notes cover five different project modules. Consult the module syllabus (linked via the module code below) for the exact aims and learning outcomes of the module you are taking.
See 1b (new) for more on the Software Project M60.
All project modules test your ability to:
Projects can be of two broad kinds: 'software' projects and 'dissertation-only' projects.
Software projects usually consist of designing and writing a substantial piece of software. Such a project will typically include:
However, no specific software design model is required, so that these elements may not appear explicitly in the order given above (e.g. when using rapid application development). Nor need a software project necessarily result in a finished application. However, it must yield some product in a way which involves the main stages of the software life-cycle (i.e. requirements definition, software design and implementation, with validation, documentation and management throughout). The product might, for example, consist of a requirements definition with a demonstration prototype, or a design with a partial implementation to show its validity.
During the project you will need to evaluate alternative approaches and solutions to problems. It is important that you document these decisions as they should form a substantial part of your final Project Report.
A 'dissertation-only' project consists of conducting research other than by designing and writing software. The research might be of academic nature, or could involve analysing the needs of a commercial company, or investigating and comparing existing specialised packages. Such a project is judged only on the dissertation. Please note that dissertation-only projects should not be thought of as an easy alternative to writing software. It is much more difficult to show achievement in a dissertation-only project, and therefore harder to get a good mark. Please read Section 3.
The final year undergraduate project for BSc, BEng and BA degrees is worth 40 credits which is deemed to be about 400 hours of work, including background reading and assessment. (Compare with the amount of effort required for the 20-credit software workshop modules that you have taken.) For the MSc in Computer Science and final year MEng programmes, the project is worth 60 credits and requires correspondingly more effort and quantity and quality of work.
The project for final year MEng in Computer Science/Software Engineering students is different from that for BSc and BEng students. It is at Level 4 (rather than Level 3), is worth 60 credits (rather than 40), and has different learning outcomes. In particular, the first learning outcome is:
"Carry out a substantial individual task set within the context of the software lifecycle, demonstrating good software engineering practice."
Key features of the MEng project are:
60 credits worth of work is expected (nominally 600 learning hours). This extra effort should be reflected in a higher level of achievement, both in quantity and quality. Project examiners will take this factor into account when assigning marks.
Project modules allow you to integrate material from the rest of your degree programme. Examiners will consider whether the project shows evidence that you have assimilated and used prior knowledge and skills learnt from Level 3 as well as other Level 4 modules (as appropriate to the project topic).
At Level 4, you are expected to show more evidence of independent work, in particular in researching any relevant background material to the project and in designing and developing innovative rather than routine solutions.
Although all the School's projects are expected to include appropriate aspects of software engineering practice, the MEng project should show greater breadth and depth in this area. In terms of breadth, although the project does not need to cover the whole of the software lifecycle (taken here to mean requirements analysis and definition, software specification and design, and implementation and testing), it should be firmly located in this context and demonstrate good practice in a range of relevant aspects. In terms of depth, experience gained through previous modules, such as the third year Team Project, should be evident in your approach to project work, with professional standards in areas such as documentation and project management.
Lecturing staff will suggest a variety of project areas. Staff members and some links to their project areas are listed at http://www.cs.bham.ac.uk/internal/courses/projects/2007/projects.html
You should look at these, and discuss any areas that interest you with the relevant lecturer.
Alternatively, you can propose your own project. If you choose this option, you should make sure that what you are proposing is imaginative, and substantial enough to justify about 400 hours of work (600 for MSc and final year MEng). Look at the URL above to find a supervisor who is appropriate, and discuss it with them. Otherwise, discuss it with the Projects Coordinator. If your proposal is not sufficiently substantial, you risk putting a ceiling on the maximum mark you could achieve right from the outset.
During the Project Allocation week, students talk to potential supervisors and try to agree on a project area. When you go to discuss an area with a supervisor, it is in your interest to be well-informed and to appear competent and enthusiastic. Once you and the supervisor have agreed that he or she will supervise you, the supervisor should sign the Project Allocation Form, which you should hand in at the School Office.
It is important that you act fast in order to get the project and supervisor of your choice. If you propose your own project and you don't have a supervisor in mind, you should submit your proposal to the Projects Coordinator by the beginning of the week so that a supervisor can be found for you.
If you do not have a supervisor allocated by the end of the
Project Allocation week, a 'random' one will be assigned to you.
You should avoid this situation if you possibly can, as the one
assigned may not have similar interests to you.
Usually, a project consists of writing a substantial piece of software, and the mark you get is based both on the software you produce and the dissertation you write. In some cases (e.g. the MSc KPMG projects), it is possible to do dissertation-only projects. These can involve carrying out some research, or solving a problem in a way which does not result in a end-product derived from some part of the software life-cycle. It is harder to show tangible results in a dissertation-only project, and therefore harder to gain good marks. You should not think of these projects as a soft option for people who cannot program. Most supervisors are willing to take on a dissertation-only project only for students who have already demonstrated programming ability by gaining 60% or more in the Workshop modules. Please note that your degree course does not exempt you from BCS and IEE membership eligibility examinations if you do a dissertation-only project nor does it meet the requirements for full or partial CEng accreditation. MEng students are not allowed to undertake such projects.
When you have a supervisor and you have identified a topic for your project, the next step is to write as detailed a project proposal as you can. You should have two or three meetings with your supervisor in order to clarify your ideas and home in on a precise description of your project. The project proposal should demonstrate that you know what the project is about, and that you know how you are going to approach it. It should include a timetable showing different phases of the development and when they will be completed, and should give details of the hardware and software you will use.
As part of your project proposal, you should make a feasibility study to make sure that the hardware and software necessary for your project are indeed available in the School. Discuss this with your supervisor. Note that the School might be prepared to purchase special purpose equipment if this is necessary for your project. You should apply for this through your supervisor as soon as possible (to allow for ordering/commissioning delays).
Your project proposal should be ambitious and imaginative, but it should also provide several fall-back positions in case you cannot realise all of it in the available time. Make sure you have specified a substantial and self-contained core, together with several extras which you will do if time permits.
Once your project proposal is completed and approved by your supervisor, you hand it in to the School Office (normally, there will be a pigeonhole for this purpose).
You might have to deviate from your project proposal as your project progresses, because things may not turn out exactly as you planned. This is perfectly acceptable, provided you are quite clear about the reasons for the change. Discuss these reasons and the possible reactions to them with your supervisor. If they entail a substantial change to your project proposal, you should rewrite it.
The extent to which you see your supervisor will depend on many factors, including his or her expertise in the project topic, the amount of help you need, the availability of the supervisor, and the extent to which you get along and interest each other.
However, it is in your interest to make sure you see your supervisor as often as you need to. Whether you have a regular time for your meetings, just turn up, or arrange them by email, depends on the supervisor. As a guideline, you should see your supervisor approximately weekly for the first few weeks of the project, while you are still deciding exactly what you will do and working out how you will do it. Once you have settled into a steady pattern of work, meetings can become less frequent, perhaps just when you have a particular problem you need help with. In any case, no matter what your arrangement with your supervisor is, you are required to provide a regular weekly report on your progress to your supervisor. This can be done in person, when meeting your supervisor, or via email.
At the dissertation-writing phase, it is a good idea to see your supervisor several times to make sure that you are writing at the right level of detail and in an appropriate style. Your supervisor will normally give you verbal comments on drafts of the dissertation, although you cannot expect him or her to read a draft in detail.
Being supervised is a two-way process: you cannot expect help and time from your supervisor if you are not making substantial effort on your own and spending an adequate amount of time on the project. If you have difficulty arranging meetings with your supervisor in spite of your working hard on your project, you should seek advice from your Academic Advisor (where this person is not your supervisor), the Projects Coordinator, or another member of staff.
As well as your supervisor, you can get help and ideas from other people, such as other members of staff or your student colleagues. Use the newsgroup cs.courses.sw3 for discussion of project problems and solutions. Other newsgroups and the WWW can be used to get help.
It is important to acknowledge substantial help you get, no matter what the source. Failure to do this could be interpreted as plagiarism (see Section 9), and is a serious offence. You can use code you find on the internet in your project, but you must acknowledge it. If you pass off other people's work as your own, you will automatically get a zero mark, and more severe disciplinary action will be considered (such as expulsion). There have been several cases of this in the past, and they are always severely dealt with.
It is a good idea to keep a project diary throughout your work, for example in the form of a hard-cover note book in which you write something each day you work on the project. In it, you should document all the decisions you took, detailing the reasons and the alternatives. This will be an enormous help to you when you come to writing the dissertation.
Besides your supervisor, two members of staff will be involved in the assessment of your project. Part of this assessment is in the form of an inspection and a presentation. The inspection is in December (or June, for MSc's), and the presentation is in April (or September, for MSc's). The relevant dates can be found via the projects web page.
The project inspections and presentations take place in the laboratories, and last 15 minutes (inspection) or 30 minutes (presentation). It is vital that you are well-prepared for both events. Normally one member of staff is present at the inspection and two at the presentation, neither of whom is your supervisor. One of the two who attend your demonstration will also normally elect to be the second marker of your dissertation.
The inspection/presentation team is likely to ask how many times you have met with your supervisor. If your answer is unusually high or low, be prepared to give some explanation.
You should be prepared to talk for 5 or 10 minutes about your project proposal and your achievements so far. You should be quite well advanced. The inspection team will want to see what you have done, and to see your design. You may have begun to write source code then. They want to see whether you are making satisfactory progress, whether you are quite clear about what you have to do between then and the end of your project, and whether it is feasible, and whether it will be adequate to be awarded a satisfactory mark. Be prepared for questions along these lines. Be ready to talk about your design, and answer questions about it. The inspection is also an opportunity to ask someone other than your supervisor for advice on how to proceed, or to ask questions about the assessment of your particular project.
By this time, you will have finished all your coding. In the presentation you must present and demonstrate the final product. It is vital that the project is finished several days before the presentation, so that you have the time to iron out any last-minute difficulties. It is your responsibility to make sure that you are able to demonstrate your software on a machine in the laboratories. If you developed your project on your own machine, you can bring in your machine, or port it to one of the School machines. But remember that it can take time to do these things, and the presentation team will not be sympathetic if you have compatibility problems during the demonstration. Note that any special requirements for your project presentation should be discussed with the Computer Officers at least two weeks in advance of the presentation.
You should have a script prepared so that you can demonstrate the software smoothly and convincingly. Naturally, the presentation team will also want to see how robust your software is. When you have finished demonstrating it on pre-prepared input data, invite them to suggest their own data, or to interact with the computer directly. Make sure that they are able to do this; they will not be impressed if you are the only person capable of making your software work, or if it only works on the data that you have tested it with.
For dissertation-only projects, you should prepare a presentation of your work (e.g. PowerPoint slides) and give a 20-minute talk.
Your project will not be awarded a mark unless a presentation has taken place. Hence, if for any reason you miss your presentation, you must arrange a new time for it with your inspectors. The presentation is an essential part of the proof that the project is your own work. You must have your source code available to show to the inspection team, and be prepared to answer questions about it. If you are not able to show the code, it will be impossible for you to convince them that you are the author and that you know it inside-out.
The dissertation you write will will be read by at least two members of staff, and marks are awarded to it rather than to the software you have written. Usually the two markers are your supervisor and one of the members of staff who attended your demonstration (not necessarily the one who also attended your inspection). It is well-worth keeping a note-book or diary throughout the duration of the project, in which you note decisions you have taken (and their reasons), results, ideas, conclusions you reached, etc. This will be very useful when you come to write the dissertation.
The appropriate structure of the dissertation varies according to the kind of project you are doing, the features you have chosen to emphasise, and the degree course you are pursuing. In consultation with your supervisor, you should decide how much emphasis to give to software engineering issues, to artificial intelligence issues, to algorithms and data structures, to the user interface, etc. Different projects concentrate on these to different extents, and it is your responsibility to make sure that you are clear about where your project's contribution lies.
The following dissertation structure should therefore be seen as a guideline only. Probably no dissertation will stick to it rigidly. It is your responsibility to adapt it to suit your particular project.
Title page, including title, author, degree (BEng in Computer Science/Software Engineering, BSc in Artificial Intelligence & Computer Science, MSc in Computer Science, etc.), name of supervisor, name of institution ('School of Computer Science, University of Birmingham'), date.
Preamble, including (a) Table of Contents; (b) Abstract/synopsis (suggested length: half a page); (c) Acknowledgements. The Abstract should be a succinct and self-standing summary of the basis and achievements of the project. Be straightforward and factual and avoid vague statements, confusing details and "hype". Do not be tempted to use acronyms or jargon to keep within the half-page limit. Consider that search engines, librarians and non-computer scientists wishing to classify your dissertation rely on the abstract. You may if you wish provide a short list of keywords (2-6 is reasonable) at the end of the abstract.
Introduction. In this section, you should describe the motivation for the project. Explain whatever background the reader will need in order to understand your contribution. Include a clear and detailed statement of the project aims. Describe the requirement that your software is fulfilling. Explain exactly what your software does; what input or data it requires, and what output or results it delivers, or how it interacts with the user. Concentrate on what your software does; the question of how it does it will be dealt with in later sections.
The introduction is the most important section of the document; everyone who reads your dissertation will read the introduction, and many will read only that section. You have to make it as inviting and compelling as you can. Think carefully about what you want to say, and in what order you should say it. As well as being the most important section, it's also the most difficult one to write, because it is hard to balance the requirements of giving adequate explanation without entering into too much detail.
For these reasons, you should write the abstract and introduction last. It is only when you've written the rest of the dissertation that you know what you have to introduce.
Conventionally, the last part of the introduction outlines the remainder of the dissertation, explaining what comes in each section.
The next three or four sections form the main part of the dissertation, and will normally cover the following topics. How much space you give to these topics is something you should judge carefully. Dissertation-only projects require a different structure. See the important notes in Section 3.
Conclusions. Here you will summarise your achievements and also the deficiencies of your project. You can also say what you would or could have done, if you had had more time or if things had worked out differently. It is important to be completely honest about the deficiencies and inadequacies of your work, such as they are. Part of your aim is to demonstrate your ability to recognise problems that remain.
References and/or bibliography. List any books, articles, lecture notes, conference proceedings, manuals or other documents that you refer to in the dissertation and/or that were important in your work. Look in any published book for how to do this. Cite at least the authors, the title, the date and the publication details of each document.
Appendices. The dissertation must contain an appendix explaining file structure on the data CD submitted with it. The appendix must also contain an information on how the code should be run. Other appendices may include documents such as: the project proposal; a selection of experimental data; schedules; testing strategy; risk management plans; glossary; manual; etc. Don't include the source code as an appendix (submit it on CD; see below). Don't include voluminous appendices (these should also be submitted on a CD).
You will need to submit two copies of your dissertation and two
copies of a CD containing:
- an electronic form of your dissertation
- all codes and files related to the project
Clearly mark each CD with your name and student ID.
The dissertation must contain an attachment explaining file structure on the CD and an information on how to run your software (maximum one page)
Don't forget to set the permissions of project material so that it cannot be read by others.
The dissertation should be a maximum of 60 pages (for both 40-credit and 60-credit projects), including appendices. An excellent dissertation will often be less than this (its author will have said a lot in a small amount of space). There is no need to submit double-spaced. Single-spaced is much better. Double-sided is encouraged.
Voluminous data can be submitted electronically, in your home directory (see above), or on floppy or CDROM.
All parts of your dissertation should be precise and clear. You should think carefully about each section; what do you want to say in it, and what is a good order to say it in? Make sure you use complete sentences. There is plenty of advice available on good technical writing available in the library.
The deadline for finishing coding is the project Presentation (relevant dates can be found via the projects web page). It is your responsibility to ensure that you manage to meet that deadline. Hardware or software failures on your own computer system cannot be accepted as a reason for missing the deadline. You are also expected to keep adequate backups of all computer-based work; loss of work which is not backed up also cannot be accepted as a reason for missing the deadline. Disruptions of the School's computer system are also possible, and you should allow for unavailability of up to 7 working days, occurring at any time during the project lifetime. Also, anything which is your responsibility or for which you could have planned (e.g. family visits, accommodation change, document loss, etc.) cannot be accepted as a reason for missing the deadline. Serious emergency and medical situations, supported by written evidence, may be considered for an extension.
Two unbound copies of your dissertation and two copies of a CD containing (1) an electronic form of your dissertation and (2) all codes and files related to the projects, should be handed in at the School Office by 12 midday on the Dissertation Deadline day (relevant dates can be found via the projects web page), with at least 2.5cm margin on the binding side to allow room for binding. Neither copy will be returned. If you make additional copies for yourself, the School Office will bind them for you. A fee of £2 is charged for the binding.
There is a penalty system for late hand-ins, which works as follows. 5 marks are deducted for lateness of between 0 and 24 hours after the Dissertation Deadline time; thereafter, 2 additional marks are deducted for every ADDITIONAL 3 WORKING days of lateness OR PART THEREOF, until the final Cut-Off Date. No project will be accepted after this cut-off date, and a zero mark will be recorded. Students may apply for extensions according to the procedure described in the Student Handbook.
Because the project is worth a substantial number of credits, the penalty can make a significant difference to your final degree mark. If you are near a borderline, this can make the difference between e.g. a first-class degree and an upper-second (or for MSc, between a Distinction and a Merit). Normally, the Exam Board would not apply a penalty in full if doing so would result in changing a pass mark to a fail mark.Applications for extensions and leaves of absences should be made through the welfare team.
Your project dissertation will be marked independently by your supervisor and one of the members of your assessment team. They each give a mark out of 100. If their marks are in the same degree class band or differ by 10 or less, the average is taken. Otherwise, they meet together to discuss the reasons for the difference, and try to come to an agreement. If they cannot agree, a third marker will be appointed.
The mark given by the markers will be based on the following five considerations:
The project report. Its content, clarity, presentation. How well have you described what you did, and how you did it?
The end product. If software, does it have the required functionality? How good is its user interface? Is it stable and robust?
The process. Have you carried out the processes of analysis, specification, design, implementation and testing, as appropriate to your project? How well have you analysed and justified the decisions you took?
(In the case of the supervisor) How was your performance throughout the year? How well prepared were you for meetings? How successfully did you spread the load throughout the two semesters?
The project demonstration. How clear was your demonstration? Could you answer questions convincingly? (Note that the project demonstration also contributes information relevant to (2) and (5).)
The achievements of the project. What was its scale? How complex was it? What problems did you overcome?
In situations where, for various reasons, it is not possible to make an assessment of the project without further information from the student, a supplementary assessment may be required, possibly with the participation of the External Examiner. This will assess the project as a whole and will normally require the student to give an additional presentation of his or her project. Which students are required to have an supplementary assessment is determined at the Project Assessment Meeting.
In any case, the penalty for late submission, if any, is automatically applied to the final mark.
The marks, together with the markers' reports, are made available to the students after the Examiner's Meeting, at the School Office.
Please note that failure in the project normally means that you will not get an honours degree (or that you will get a Diploma instead of an MSc).
Software that requires internet connections to the outside world may be difficult or impossible to demonstrate within the School, because of the School's firewall and the University's (proposed 2003) firewall. It is your responsibility to adapt your program to be demonstrable within the School, and to address in good time any problems arising from this, with the help of your supervisor and, if necessary, the computing support team. This is a subject that should be covered at the earlier project inspection - don't leave it until the final presentation.
Advice is on http://supportweb.cs.bham.ac.uk/information/projects.php
Most importantly, all incoming and outgoing ports except ssh, ftp, telnet and http, pop and imap are blocked, and even those ports are available only from some machines, or via proxy servers.
Plagiarism is the use of other people's work so that is appears to be your own. 'Other people' includes other students as well as authors of books, papers, documents or programs on the internet, etc. Deliberate plagiarism is a very serious offence that is treated in the same way as cheating in an examination; this could result in expulsion from the University, and as a minimum it results in disqualification from the project module. The University and the School are very strict about plagiarism, and you have signed a contract with the university on that topic.
Be careful to ensure that plagiarism does not occur accidentally. You can quote other people's work, but you must clearly indicate that this is what you are doing, and include the source. Direct quotation of narrative material should always be enclosed in quotation marks and the source of the material referenced either immediately before or immediately after the quotation. The full description of the source can be given in the References at the end of the dissertation. (A guide to one style of referencing will be found at http://www.cs.bham.ac.uk/~pxc/refs/.)
If the material is paraphrased, it should not be enclosed in quotation marks, but the source should still be stated clearly. Tables, diagrams, etc. copied from elsewhere must also be clearly labelled as such, with reference to the source. You may have used other people's programs or source code in producing your software. This is perfectly acceptable provided you make it clear, by acknowledging the source. If you do not, it will be considered plagiarism.
For more detailed information on plagiarism please see: http://www.cs.bham.ac.uk/resources/students/plagiarism.htm.
The University has intellectual property rights over any code that you produce in the course of your project. These rights are specified in the , Section 3, at General Conditions of Use of Computing and Network Facilities which in turn refers to the Conditions of Service of academic staff, Appendix 6 (note this page may not be accessible off-campus), and Regulations, which depend on your year of entry. For students who entered the University in 2002 Regulation 5.3 and Regulation 3.16. For students who entered the University in 2001 Regulation 5.3 and Regulation 3.16. (Regulations may be slightly different for students who entered at different times - see the index).
Page maintained by P. Tiño, D. Ghica and U. Reddy.
Content last updated by P. Coxhead on 7 Nov 2007.