For module 17418 only
Andrew Howes
Final Year Project Coordinator
Email HowesA at Birmingham
June 2013
Contents
The final year project is the culmination of your degree programme. It allows you to work on a substantial problem in Computer Science for an extended period of time. 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.
These guidance notes are for the following modules only. Consult the module syllabus (linked via the module code below) for the exact aims and learning outcomes of the module you are taking.
Unlike the 40-credit Computer Science project 17419, this 60-credit project demands that you demonstrate a broader range of the most advanced skills required at MSc level. Further, the 60-credit module requires the submission of additional assessment material. This project is suitable for exceptionally independent and self-motivated students.
For other degree programmes and project modules please return to the Project Web Page.
All project modules test your ability to:
It is your responsibility to lead your project, to arrange your supervision meetings and to ask for the advice that you need.
The project is an opportunity to demonstrate problem solving skills. It must include a substantial piece of scientific or engineering work.
The project can be in any area of Computer Science including Artificial Intelligence, Robotics, Software Engineering, Theory, Human-Computer Interaction, Mobile, Security, or Natural Computation. The project will involve programming, software or hardware development, mathematical proof, empirical investigation, or some other scientific or engineering method, as applied to Computer Science.
The project will NOT consist of only a literature review.
This 60 credit project allows a student to conduct an in-depth exploration of advanced computional concepts (that would not be possible in a 40 credit module). In addition, this module has an additional assessment criteria. The student must present a literature review and preliminary results in the style of a scientific magazine article, e.g. Communications of the ACM, as directed by the supervisor.
Many projects consist of designing and writing a substantial piece of software (software development projects). Such a project will typically include:
Projects that use other engineering methods will have other requirements.
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 Project Report.
This project module is worth 60 credits which requires about 600 hours of work, including background reading and assessment.
This document is structured as a timeline. The sections are ordered according to the major events that you will face as you prepare for and conduct your final year project.
You are usually assigned to a Supervisor in the March prior to the start of your final year. We try to give you a role in finding a Supervisor who has project proposals that fit with your interests. However, it is not always possible for us to assign you your choice. Further details about the process will be given via the website.
Lecturing staff will suggest a variety of project areas. These will be listed on the Final Year project web site. You should look at the topics, 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 the amount of work required). Look at the web site to find a Supervisor who is appropriate, and discuss it with them. If your proposal is not sufficiently substantial then it will not allow you to fulfill the requirements of the module.
To find out whether a Supervisor is available, log in to the Project Management System. Select the correct academic year for your project (below "Historical data"). By clicking on "Supervisor availability" you'll get a table of current project supervision assignments of staff members. The table should help you to target potential Supervisors with available slots. Members of staff NOT available for supervision either have zero in the "Expected load" column, or have a positive value in the "Balance" column.
During the Project Allocation period, 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 about potential projects and motivated. Once you and the Supervisor have agreed that he or she will supervise you, the Supervisor should register the project on the Project Management System.
It is important that you act fast if you want the project and Supervisor of your choice. If you are not able to find a Supervisor then one will be assigned to you. In addition, the topic will be assigned for you. Unfortunately, we cannot guarantee that assigned Supervisors will have similar interests to you.
Meet with your Supervisor in the first or second week of the autumn semester and, subsequently, meet in person or electronically every week during the semesters. Meet with your Supervisor in person at least every other week.
Start your logbook. Email your logbook to your Supervisor weekly. Contact your Supervisor every week of the semester to report your progress. If your progress was slow then try and identify why and write some notes on your goals for the coming week. Use the logbook to document all of the decisions that you took, detailing the reasons and the alternatives. This will be an enormous help to you when you come to write the Report.
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. At a minimum it is required that you meet with your Supervisor in-person at least every two weeks during term time. 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 is to be submitted to your Supervisor by email. It may only contain a few lines of progress summary.
At the Report 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 Report, 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. It is up to you to set the agenda for meetings with your Supervisor and to keep a record of notes. 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.
Other Sources of HelpAs 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 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.
When you have a Supervisor and you have identified a topic for your project, the next step is to write a Proposal. You should have one or two meetings with your Supervisor in order to clarify your ideas and determine a precise description of your project. The project proposal should demonstrate that you know what problem the project will address and that you know how you are going to solve, and evaluate it. It should include a timetable showing different phases of the development and when they will be completed, and should give details of the resources that you will require. For software development projects, it should give details of the hardware and software that 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 may 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 must submit it to the School's online submission system. Further details will be made available.).
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.
Prior your project work, it is required that a self assessment of the ethical issues arising from all proposed work is undertaken (see below for a link to the form). All undergraduate and MSc students must complete a form for each project that they undertake. The form will normally be completed at about the same time as the Proposal.
The purpose of the form is to identify those projects which may raise ethical issues. All forms will be submitted to the Project Coordinators via the online School submission system. Once the form has been submitted:
Specifying the problem to be solved requires more than writing some anecdotal notes on the experiences that motivated your software. For example, it is not enough to write about your love of working as a Disc jockey and your desire to build a website that supports a local community of Disc jockeys. While this may be a reasonable starting point for a self-motivated project you should do some reading to ascertain the nature of the Computer Science that would be required to solve this problem.
A key part of finding out about the underlying problem will involve reading books and research articles. In the above case, for example, you should read academic articles on software systems designed to support local communitites. What kinds of functionality do they typical support? What are the difficulties in setting them up, maintaining them, and building them? What choices are there for the software frameworks that might be used? What has been used before and what issues did they raise?
A good starting point for this background research is to use Google Scholar. Make notes on what you have read keep a record of the references that you find useful. These will be useful in your Report.
Besides your Supervisor, other members of staff will be involved in the assessment of your project. Part of this assessment is in the form of an Inspection. The Inspection is in December.
The project Inspection takes place in the laboratories, and lasts 15 minutes. If your oral presentation of your work takes more than 10 minutes then you will be asked to stop immediately. It is vital that you are well-prepared for both events. Normally one member of staff, not your Supervisor, is present at the Inspection.
At the Inspection you will be asked whether you have met regularly with your Supervisor. You will also be asked to show your log book.
You should be prepared to talk for between 8 and 10 minutes about your project proposal and your progress to date. You should be quite well advanced. The Inspection team will want to see what you have done, and to see your design. If you are developing software then you may have begun to write source code. The team will 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 substantive. 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.
You will write an article about your project that includes a literature review and a description of the preliminary report. This article will be in the style of a scientific article such as, for example, the articles published in Communications of the ACM. Journals and conferences typically provide quite detailed instructions on how an article is to be presented. You will work with your supervisor to determine a suitable journal, or conference, format for your article.
Your article will have to be carefully written so that it can be understood by the particular journal or conference readership. Again using Communications of the ACM as an example, an article suitable for this journal would need to be written for readers who have advanced degrees but who will be unlikely to be experts in the particular field. It is worth looking at a few Communications of the ACM articles as examples of what you should aim for. Some guidance on types of article can be found at: http://cacm.acm.org/system/assets/0000/6052/CACM_Author-Guidelines.pdf
For the majority of the time that you spend on your project you will be working alone developing your solution. If it is a software development project then you will spend a considerable amount of time programming the solution to the problem that you are addressing.
If you are writing software then it is a requirement that you keep backups using the School's version control system. Details can be found here: Subversion
Evaluating your solution is not optional. Whatever the method that you have used, then you must conduct an evaluation of the work that you have conducted. Critically, the evaluation will provide objective evidence of the extent to which the solution that you have produced solves the problem that you set out to solve.
For a software project the evaluation may, when appropriate, consist of user tests using a recognised HCI methodology, or it may consist of a systematic exploration of the parameter space of the program to ensure that it is bug free. All software and manuals should be exhaustively tested in the full range of circumstances in which they might be used.
The Report will be read by at least two members of staff, and marks are awarded for the Report independently of any other work that you submit, whether that is software, data, or proofs. 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 required that you keep a logbook 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 Report.
The appropriate structure of the Report varies according to the scientific or engineering method that you have used, the features you have chosen to emphasise, and the degree you are pursuing. It is your responsibility to make sure that you are clear about where your project's contribution lies and that all work is explained clearly and in the correct format.
The following Report structure should therefore be seen as a guide only. Further, it is a guide that is specifically for software development type projects. It is probably the case that few Reports will stick to it rigidly. It is your responsibility to consult with your Supervisor and adapt it to suit your particular project. Types of problem solving project other than software development projects are likely to need a different structure.
Title page, including title, author, student ID, 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.
Abstract should be a succinct and self-standing summary of the basis and achievements of the project. Minimally an abstract does three things: (1) it states the problem that you set out to solve, (2) it describes your solution and method, (3) it states a conclusion about the success of the solution. 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 Report 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 problem that you set out to solve with the project. An introduction might, for example, begin by stating, "The aim of the work described in this Report was to provide a software tool with which people can arrange meetings." Avoid starting a Report with an irrelevant history of information technology. For example, the following would not be a good introductory sentence, "Since Bill Gates launched Outlook people have been using technology to arrange meetings."
Explain whatever background the reader will need in order to understand the problem. The background might refer to previous work in the academic literature that provides evidence that the problem is a real and significant problem worth solving. Include a clear and detailed statement of the project aims and provide an overview of the structure of the solution.
Conventionally, the last part of the introduction outlines the remainder of the Report, explaining what comes in each section.
The next set of sections form the main part of the Report, and will normally cover the following topics.
Discussion. 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.
Conclusion. Give a brief statement of how the solution that you have provided addresses the problem stated in the introduction. Provide an evaluative statement based on the results. You should not introduce new material.
References List any books, articles, lecture notes, conference proceedings, manuals or other documents that you refer to in the Report 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 Report 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).
Data CD submitted with the Report
You will need to submit two copies of your Report and two
copies of a CD containing:
- an electronic form of your Report
- all code and files related to the project
Clearly mark each CD with your name and student ID.
The Report must contain an attachment explaining file structure on the CD and an information on how to run your software (maximum one page)
Length
The Report must be a maximum of 60 pages, including appendices. An excellent Report 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), on a DVD or CDROM.
Style
All parts of your Report 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.
By the time of the Demonstration, you will have finished all your coding, mathematical analysis, or data collection. In the Demonstration you must present and demonstrate the work that you have done. You must give a single, articulate, 20 minute presentation that describes the problem that you have been working on, your solution and its evaluation. Your software Demonstration must also be within this 20 minutes. The Demonstration will take place in the Laboratories in the Computer Science building.
If it is a software development project then you must demonstrate the working software and be prepared for the Inspection of your code. It is vital that the project is finished several days before the Demonstration, so that you have the time to iron out any last-minute difficulties. If you are demonstrating software then 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 Demonstration team will not be sympathetic if you have compatibility problems during the Demonstration. Be prepared. Note that any special requirements for your project Demonstration should be discussed with the Computer Officers at least two weeks in advance of the Demonstration.
You should have a script prepared so that you can present your project work smoothly and convincingly. Naturally, the Demonstration 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.
If you wish then you may make use of slides but if you are demonstrating software then the majority of time should spent on showing how this software works.
You present / demonstrate your project to two members of academic staff (neither of whom is your Supervisor). They complete a relevant part of the Project Assessment Form. Have a look at the form to ensure that you cover all the relevant points in your Demonstration.
Your project will not be awarded a mark unless a Demonstration has taken place. Hence, if for any reason you miss your Demonstration, you must arrange a new time for it. Contact the Support Office on the ground floor. The Demonstration is an essential part of the proof that the project is your own work. If your project is a software development project then you must have your source code available to show to the Demonstration 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 understand it.
The project Demonstration is an essential part of the project assessment. Students who do not turn up for their Demonstration will receive a fail mark (unless there are mitigating circumstances confirmed by the Welfare Team).
Software that requires internet connections to the outside world may be difficult or impossible to demonstrate within the School, because of firewalls. 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 Demonstration.
The deadline for finishing coding is the project Demonstration (relevant dates can be found via the Project Web Page). It is your responsibility to ensure that you manage to meet the deadline. Hardware or software failures on your own computer system cannot be accepted as a reason for missing the deadline. It is required that you keep adequate backups of all computer-based work using the School's SVN revision control system; 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 Report and two copies of a CD containing (1) an electronic form of your Report and (2) all code and files related to the projects, should be handed in at the Support Office by 12 midday on the Report Deadline day (relevant dates can be found via the Project Web Page), The printed copies must have 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 Support Office will bind them for you. A fee of 1 pound is charged for the binding of each additional copy.
There is a penalty system for late hand-ins: 5 penalty points per working day are deducted up to a final Cut-Off Date for handing in the Report (see Important Dates at the Project Web Page). If the application of the penalty takes the project below the pass mark, the project will fail. No project will be accepted after the Cut-Off Date, and a zero mark will be recorded in such case. 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. Applications for extensions and leaves of absences should be made through the Welfare Team.
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, pages, 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 Report. (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.
Intellectual Property RightsThe 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 - see the index).
| Project Management System. | You will use this web site so as to check for Supervisor availability when you first start to think about your project in the year before your final year. |
| Ethics Self-Assessment Form. | It is required that you conduct an Ethics self-assessment. This form must be completed by a deadline that can be found on the Final Year Project page. |
| Subversion | If you are writing software then it is a requirement that you keep backups using the School's version control system. Details can be found here. |
| Project Assessment Form | This is the form that your Assessment Team use to assess your project. |
| Welfare Team. | If you experience problems that prevent you from conducting the work required for your project then you must contact the Welfare Team. |