You must submit three unbound paper copies of the final report ("Honours Dissertation"). See the separate note about formatting and printing reports. The Division will bind the copies you submit. In addition, you must submit a digital copy of your report and your code to the project repository.
You may borrow past reports from the Division's library as a guide to what reports look like. If you borrow a report, please leave a note that you have done so. Past reports are apt to vanish accidentally!
If you use Microsoft Word to prepare your dissertation, it is recommended that you use the dissertation template. For more technical dissertations, you may prefer to use the LaTeX dissertation template
The final report should be roughly 15,000 words including appendixes (i.e. about 60 pages). Note that you should not artificially pad your report because it seems to be too small. In the past, dissertations have ranged from 12,000 to 20,000 words. The size of a report is rather project-dependent. Your report should cover the project adequately without being too terse or too verbose. Ask your supervisor for guidance if you are not sure whether the report is sufficient. The structure of the final report will vary according to the project, but will look something like the following.
The following structure is suggested for the final report. This structure is not mandatory, but significant deviations should be agreed with your supervisor:
Work which is submitted for assessment must be your own work. All students should note that the University has a formal policy on plagiarism. Plagiarism means presenting the work of others as though it were your own. The University takes a very serious view of plagiarism, and the penalties can be severe. Specific guidance on computing assignments may be found in the Computing Science Student Handbook.
You are recommended to make a check for unintended plagiarism. Go to the Succeed module page, login using your University username and password, then click Final Report. Now choose Submit Paper and provide a Microsoft Word or PDF version of your report. Check the TurnItIn response for anything that needs attention. For example you might quote from other sources when discussing state-of-the-art but forget to cite these, or you might use a diagram without acknowledging the source. Even if TurnItIn says the report is OK, check for other potential issues (e.g. using third-party code but forgetting to acknowledge this).
You should show a draft of the final report to your supervisor before submitting it. The final work is formally assessed and counts as 80% of the overall project mark. Two aspects of the final work are assessed: the technical content of the work (weighted 70%) and its presentational standard (weighted 30%). One copy of the report will be returned to you after assessment, one will be retained by your supervisor, and one will be lodged in the Division's library.
The Division may select the best reports for entry into competitions such as the "Young Software Engineer" award organised by the Scottish Software Federation.
Along with the final report you are required to submit the original of your project diary. The diary is not assessed in itself, but is taken into account when the technical aspects of your work are graded. The diary will be returned to you after assessment.
You are also required to submit to the project repository one copy of all programs, specifications and data that you developed during the project. This is usually bulky archival material that is not appropriate for the final report. Your supervisor is also likely to appreciate a copy of your files.
You are required to demonstrate your final "system" to your supervisor and second marker before the end of the Spring semester. The demonstration is not assessed in itself, but is taken into account when the technical aspects of your work are graded.
You are required to give an oral presentation of your project results. Presentations are given to your fellow class-mates and staff. A presentation lasts 10 minutes, including a few minutes for questions. The presentation is not assessed in itself, but is taken into account when the presentational aspects of your work are graded. The schedule of presentations is as follows.
| Student | Title |
|---|---|
| A Laurenson | Intuitive Shopping Assistant |
| J Adair | Item Recognition and Tracking in The Home using The Kinect |
| LC Blair | Engaging Potential CS Students |
| MC Borkowski | Comparison of Languages and SDKs for Platform Game Development on Android |
| T Brown | Robotic Model of Bee Foraging based on Hebbian Learning |
| Student | Title |
|---|---|
| S Ali | Collective Decisions 1: Specification and Analysis of Natural Dynamics using Process Algebra |
| M Busby | Collective Decisions 2: Specification and Analysis of P2P using Process Algebra |
| AT Robertson | A Source-To-Source Transpiler using ANTLR |
| K Graham | Evolving Artificial Camouflage |
| RS MacDonald | Sports Statistics Generator |
| GHM Raynor | Evolving A Market Trader |
| Student | Title |
|---|---|
| GJ Queen | Android Home System Interface |
| SJ Watson | Android Tablet App for Configuring and Controlling An Automated Home |
| D Kidd | A Java Application Code Summariser |
| M Docherty | A Comparison of Functional vs. Procedural Languages in Network Programming |
| N Mutch | Automated ID3 Tag Completion System |
| KN Reid | iOS Gesture-Based File Transfer |
| Student | Title |
|---|---|
| S Cairns | Data Logger using Raspberry Pi |
| D Collins | iOS vs. Android Application Development |
| NM Emsley | iPad/iPod Touch/iPhone Development |
| R Maximyuk | iPad/iPod Touch/iPhone Development |
| D Pratt | Developing A Game for The iPhone |
| AJ Rafferty | P2PSIP: P2P Voice over IP |
| Student | Title |
|---|---|
| RJ Mitchell | A Mobile App for Football Referees |
| A Nisbet | On-Line Colour Matching |
| M Wright | A Simulation Program using NetLogo to predict Outcomes of Decisions made by Land Owners with regard to An Agglomeration Bonus |
Up one level to
CSC9Z* (Honours Project)