Project

PRESENTATION OF THE REPORT

There are certain stipulations concerning the format of reports. These are:

• The text is to be of consistent size (either 11 or 12 point) in Times or Times New Romanor similar font (except for mathematical formulae, where you may use whichever font is most appropriate, and program code examples, where you should use a non-proportional font such as Courier).

• Each page from the contents page onwards, including any appendices, should be numbered in sequence from 1 using Arabic numerals. The only exceptions to this might be any self-contained documents (such as user guide) and program listings: each self-contained document or program listing should form a separate appendix and can have its own numbering.

Do not underestimate the time it takes to produce a report. You have to decide on its structure and contents and should discuss this with your tutor. Once the structure has been decided, you have the opportunity to submit a chapter in draft to your tutor and to receive feedback.

You must complete the report independently of your tutor, check and correct it and then submit it as described.

STRUCTURE OF THE REPORT

The final project report should have the following structure:
Title page
Abstract
Acknowledgements (if any)
Contents page
Introduction
Literature Survey and Research (may be included in Main Chapters)
Main chapters
Discussion and evaluation
Bibliography
Appendices

LENGTH
As guidance, the introduction, main chapters, discussion and evaluation should be about 8,000 - 10,000 words in length. This is NOT a word limit, merely an indicative value indication the expected level of work required.

TITLE PAGE AND ABSTRACT
The title page must be provided, and should be laid out including ALL the details given in the sample title page [available for download from CANVAS].

The abstract should be a statement up to half a page in length describing the subject matter of the project report and the main findings and conclusions presented in the report. It is not just an introduction: a reader should be able to determine the main points of the report by reading the abstract alone.

THE INTRODUCTION
This chapter should introduce the project
Say what it was about, give some brief background information (sufficient to ‘set the scene') and list your project objectives. These should be as stated in your DPP; any changes to your objectives should be explained later in the report, probably in the overall evaluation of the work.
This chapter should also introduce the report
Give a very brief statement of how your report is structured, including what is in each chapter (and the most important appendices) just to help the reader gain an idea of how you are going to present your work.

LITERATURE REVIEW AND RESEARCH
This chapter should lay out the tasks undertaken in determining the current body of knowledge relevant to undertaking the project. The chapter should be organised to reflect the tasks you have undertaken and should provide the reader with a guide to the subject areas within which your project operates. The literature review must be balanced, including enough information and sources to show that you have researched the subject area adequately, but also selective in its narrative to ensure that the clarity of thought applied to the research is maintained in the report.
This chapter will act as a starting point for many of the main chapters and it is likely that there will be some significant cross-referencing with this chapter from within the main chapters.
Much of your literature review can reflect the work carried out in the Project Planning Module, however the expectation is that this will be modified based on changes made to the plan of the project during its undertaking.

MAIN CHAPTERS
How to present these will depend largely on the subject of the project, but here are a few points of advice:
• You may assume that your readership has the level of knowledge of a good Computer Science student who has taken the same modules as you. Bear this in mind when writing about background technical information and do not present large amounts of information that such a reader would already know or that could be read in a standard textbook. Simply reference the textbook in your bibliography and keep the information you present specific to your own work. Explain how any background material you present has been used in your project.
• The main chapters of your report are where you describe your achievements. Instead of just listing the tasks that you carried out diary-style, in the order you did them, it is better to organize the chapters around topics.
In these chapters you should tell the reader what you have done, why you did it, what results you obtained, what you think you have achieved (including the problems you have overcome) and how you went about evaluating your work (criteria applied, tests performed, and so on). Be sure to present the results of your project work properly, especially when the main task of the project was a software development.
• It is important to present information about your development work, not just the finished product. As an example, depending on the nature of your project and the way you approached your work, this might include:
- Discussion of database analysis and design decisions, system structure or program design issues;
- Commentary on any uncertainties in the project specification or requirements and how you resolved them;
- Discussion of design decisions that were considered and the reasons for choosing one method over another;
- Use of software tools (what inputs you supplied, how you configured them, what outputs were produced);
- Presentation and discussion of intermediate results, for instance of a program which was progressively refined or extended;
- Consideration of HCI issues and how they influenced your design;
- Your strategy for testing your software. This might include some user evaluation of your software and if so, you should report on the outcomes.

DISCUSSION AND EVALUATION CHAPTER
The extent to which you demonstrate the ability to reflect upon your work is very important. In this chapter you should summarise your main findings/results and evaluate what you have achieved and how you went about it. You may find it more convenient to include an evaluation of each aspect of your work in the chapter where it is presented and summarise that evaluation here. What is crucial is to have a critical self-evaluation of the extent to which you have achieved the things you set out to do.
For example, you may find it assists you to evaluate the development approach you pursued and the quality of your development work on each task that you undertook. In an investigative project, with an outcome that is unknown in advance, you may put up an hypothesis that turns out to be wrong, but still get a top mark for a thorough, methodical investigation that is properly evaluated.
Also assess the extent to which you met your objectives. You will not be penalised for acknowledging that you failed to achieve everything you set out to do, and especially not the more advanced things, but you certainly would be criticised if you give the impression of not having noticed that you had failed to meet an objective.
You should have a short section on management of the project (usually half to one page, but possibly longer), including how you planned to allocate time at the start of the year and how it actually worked out in practice.

REFERENCING AND THE BIBLIOGRAPHY

The University provides an online SkillUP tutorial on citing sources and referencing that you can work through.

3.11 APPENDICES
The appendices to your report provide supporting evidence of the quality and quantity of the work you have done. Your appendices should contain any requirements documents, specifications, design documents, survey forms and results, screen shots, and other documentation produced as part of your project. Without this supporting evidence it is possible that the markers will take the view that you have not done everything you claim to have done.
However, the appendices are only there to back up the claims made in your report. Markers can only be expected to look at those parts of the appendices you draw their attention to in the main body of the report. They are not obliged to read the appendices in detail, though they may do so. If you think it is important to draw the markers' attention to a particular point, tell them where to find it. Don't just say "the code for this is in appendix 3", give a page number, or better include the appropriate fragment in the body of your report.
All program code written by you must be presented for submission to the project website (Final Report - Additional Files). Do not include code that is machine generated, or that comes from a different author, unless it is necessary in order for the reader to understand the work you have done. If you do include code that you did not write yourself, it is your responsibility to make clear which parts of the program are your own and which parts are not. If you present automatically generated code, or the code of another programmer, as if it were your own, you may be accused of plagiarism.
Do not include copies of any web pages that you have referred to, unless it is absolutely necessary for the reader to see them in order to make your point: just put the citation details in your bibliography.
Samples of the work that is presented in the appendices should be transcribed in the body of your report in order to illuminate a particular point or for discussion purposes.

THE DEMONSTRATION
All students are required to give a demonstration or other presentation of the products they have produced for their projects. If you have produced a software system and you claim in your report that it works, then we expect to see it working, and we expect you to be able to explain your system and to answer questions about it. The assessment will be carried out by your supervisor and the second marker for your project, who should both be invited to your demonstration / presentation.
In all instances there is the necessity to demonstrate / present what you have produced:
• If you have produced a software system that works, focus on the key elements of the system in your demonstration
• If you aimed to produce a working system, but your system does not fully work, use the partially working system to explain the challenges you overcame and those that proved insurmountable, and why.
• If the aim of your project was to produce something other than a working software system (for example, you set out to create detailed analysis and design documents for a real-world problem, or you conducted a set of experimental observations), then build a presentation or demonstration around these artefacts.
Please DO NOT attempt to do a Powerpoint presentation telling us about what you did, you need to show us the actual work based around the artefact and how it exemplifies and provides evidence of the knowledge you have gained in undertaking the project.