Assessment and Submission Guidelines for Final Project Report

Weighting Of The Final Project Submission And Breakdown Of Marks

Weighting Of The Final Project Submission And Breakdown Of Marks
The final project submission is worth 90% of the total marks for the module, and must be passed independently.
Your work will be marked by two assessors independently; each will award a mark out of 100.  The marks given by the two assessors will be averaged and must pass (reach 40%). Your grade will be calculated by scaling this averaged mark out of 90, to which will be added to the marks you got for your Interim Report (10%). This value must also achieve a pass grade.

The quality and quantity of work done (analysis, design, coding, testing, research, evaluation, and so on) is assessed chiefly through what we read in your project report, supported by what we see at the presentation and/or demonstration, and by the material included in the appendices to your report.  Your communication skills (grammar, structure, layout, and so on of the written report and the way you explain your work in the presentation and/or demonstration) will be taken into consideration as part of the assessment exercise.

Important dates and times
Electronic copy submission of the report only is required.
The Final Report (incl. Appendices + electronic support material, code, multimedia artefacts) should be submitted via the relevant assignment points on CANVAS by 16:00 on Tuesday, 27th April 2021.
NOTE: The electronic submission of the Final Report MUST BE in PDF format.

You must also give a presentation/demonstration of your project work to your supervisor and second marker and answer questions from them about your work. Details on how this will be achieved are yet to be finalised and will be issued separately during the first week of April.  

Some students may be selected to have an Oral Examination at a later stage.  The final date will be published as soon as possible. You MUST make sure you are available for this.  A timetable for any orals will be published by the end of the previous week.

BE WARNED: the Board of Examiners may treat failure to attend an oral examination as if you had failed to submit a project at all. 

Late Submissions 
Standard penalties will apply to late submissions conforming to the standard increasing penalty up to a basic pass.  If you submit more than a week late you will get ZERO for your final submission.

If you wish to put forward extenuating circumstances in mitigation of late submission, or failure to make a demonstration of your work, or failure to attend an oral examination panel, then you must complete apply for Serious Adverse Circumstances Form at [email protected] or using a Short Term Extension Form which can be requested from the Module Leader and returned to him for approval, with documentary evidence of the circumstances.  This should be done as soon as possible, and in any case before the meeting of the Board of Examiners who will consider the matter.  

Important dates and times

Even if your extenuating circumstances are accepted, your project cannot be marked according to the schedule described here unless we receive the report in time; if it is submitted too late, demonstrations and orals will probably be dealt with at the same time as any referred projects. 

Final Report
Submit TWO electronic copies of your final report, including appendices to the Assignment points
• Final Report – Supervisors Copy
• Final Report – Second Markers Copy

Program source code and executables, and any other supporting material can also be submitted via CANVAS using the Assignment Point:
•  Final Report – Additional Files

This ensures the independence of the marking as one copy will be seen by each of your two markers. The Final Reports must be in PDF format, unzipped.

Additional files can be in any format.

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 Roman or 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.
The bibliography and appendices are NOT included for this purpose.  

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].

Late Submissions

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 table of contents must show the chapters of the report, with the title of each and the page number on which each chapter begins.  If your chapters are organised in sections, with a title for each, show these sections on the contents page as well.  Do not go to greater detail than sections, as the table of contents should fit on a single page or at most two. 

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.