Department of Computer Science

MSc Project (COMP702), summer 2023

Table of Contents

Important Links

Preliminaries - DOs and DON'Ts

The project system goes live on the date shown in the provisional timetable below. This does not mean you have to wait until then to start some preliminary groundwork on the module. As has been emphasized you are not bound to choose from the options that will be given. You are perfectly free (indeed, subject to the caveats outlined, encouraged) to develop your own project idea and solicit a suitable academic to act as the main supervisor.

Before ANYTHING AT ALL:

DO

  1. CAREFULLY READ all of the information provided in this document (yes, I know it's lengthy do you think reading it is more onerous than writing it in the first place?).
  2. Even though you will not be able to see much, make sure you can access the Central Project site for COMP702
  3. If you have an idea of your own that you would like to develop, prepare a brief (100-200 word) description outlining it.
  4. Identify possible supervisors who may have an interest in working with you on your project.
  5. Be realistic about what is feasible and what is expected.
  6. Make sure you are fully aware of all assessment stages, when these are and what you are expected to have done.
  7. Familiarise yourself with the Ethical Use of Data and the processes involved.

DO NOT

  1. Mail bomb academics with your proposal in the hope that one has just been waiting to supervise exactly the sort of project you have devised.
  2. Ask if you can see the list of options already provided. (No you can't. There will be no advance previews: even if the system is unfair it must, at least, try to preserve an appearance of fairness.)
  3. Ask when the list of projects will become available.
  4. Ask questions which have already been answered here.
  5. Ask what the word "provisional" means.
  6. Ask if there is an exam at the end.
  7. Assume that just because an individual has given a tentative agreement to supervise/assign a project offered (by word of mouth, email, on purchase of alcoholic refreshments etc.) that you have, ipso facto definitely been allocated that choice. No choice is final until the relevant supervisor has entered your name as the assignee in the system (and even then things may change).
  8. Add a preference to your list of options unless you are fully prepared for that preference to be assigned to you if necessary.
  9. Assume that ethical approval is automatic/unnecessary. If you have any doubts check. Approval cannot (and will not) be granted retrospectively.

Your Project - Your Responsibility

You can either propose a project by yourself or you select a project that is proposed by a member of staff. In either case, you are expected to show initiative and personal responsibility for your project.

Types and Scope of the Projects

The main aim of an MSc dissertation project is for a student to develop and demonstrate autonomy in the management and development of a realistic project in Computer science, either research- or application-oriented. Although new technical skills may be acquired, this is not the main aim. At the end of the project a student should have demonstrated the ability to initiate, plan, manage, and deliver a complete IT project for a customer or research supervisor. The delivery of the project will include giving interim presentations describing important stages of the project, and a final dissertation describing the project as a whole.


What do you mean by realistic?
COMP702 is a 60 credit continuously assessed (ie no final written examination) module. This is an equivalent loading to four normal taught modules which form the basis of most of your studies between September and May. This is a considerable undertaking and there are consequential expectations that must be considered in planning and time management, Please take the advertized timetable seriously. The Official Start date is immediately after the end of the 3 exam and assessment period, i.e. at the start of June. This will be before the outcome of Second Semester exams has been formally ratified. The fact you may not know your final results does not mean you should delay engagement with the project. This is even (especially?) if you suspect that you may have (further) resits accruing. The Specification and Proposed Design is a crucial element that sets the tone and nature of the project work you will be undertaking over the ensuing months: it must be prepared by the end of June, barely a month into the formal start.

Projects often fail to be realistic in one of two contrasting ways: they are too trivial or too ambitious. Careful development of the Specification and Proposed Design will help identify, at an early stage, whether either of these are a risk.


Examples of Unrealistic Projects

According to the learning outcomes, the project must be a project in the domain of Computer Science that deals with a substantial IT problem for which solutions are implemented and tested. This does not automatically mean that the focus of the project is on the programming part, but it restricts the set of possible projects.

MSc projects are not necessarily expected to involve original research in the sense of making new scientific discoveries (this would be unrealistic). However, there should be some degree of scholarly added value attached to the project. Not in the sense of "what new subject a student may have learned from undertaking the project", but "what contribution does the project make to the knowledge of others", regardless of whether the project is a practical one or a research-oriented one, and whether or not is involves a large amount of programming or not.

Thus, MSc projects are not required to be fully-fledged research projects in their own right, but should add some seed of original thinking, innovative approach, interesting or beneficial contribution to the existing body of knowledge. The aim is not necessarily "to do something that has never been done before", but to present a new "angle" or "view point" on something that has been done before. For example:

Supervisor Selection Process

Each project will be handled by a team of two academics:

Both supervisors assess the project (the second supervisor only assesses the second and third deliverable), monitor progress and give formative feedback.

Students are encouraged to propose their own projects. This is done by contacting a potential first supervisor directly via e-mail or MS Teams or a visit in person. All supervisors who list projects in the E-project system are potential first supervisors for student-proposed projects. Some other staff members not listed in the system could also be potential first supervisors. The list of potential supervisors is as follows.


IMPORTANT Please be aware that potential supervisors may be taking on different loads in terms of project offered/agreed. Should you have a particular individual you would like to work with you are strongly encouraged to contact quickly. If you are proposing your own project please provide as much detail as possible and be realistic about what can be feasibly accomplished within the project timescale. (Equally, recalling that the project accounts for a significant contribution, try and ensure that any proposal involves an amount of work commensurate with expectations).


Key
(*) 50% Loading
(**) 25% Loading

A suitable supervisor can usually be found by having a look at staff members' websites available at https://www.liverpool.ac.uk/computer-science/staff. You should pay special attention to the topics of the person's recent publications and that they have at least some slight thematic overlap with your project. It is possible to have a first supervisor without having a thematic overlap, but this means that inevitably there will be less guidance available. If you cannot find a supervisor for your project, then you have to change the project.

Generally, projects are allocated on a first-come, first-served basis, but it is the discretion of the supervisor to make the final decision. It is expected that the number of MSc projects supervised/co-supervised by each academic is relatively balanced, so it is possible that a supervisor might turn down your request if they already have a sufficient number of projects taken up. If a first supervisor decides to supervise a project, they should enter the project into the E-Project System and record there (in the drop-down menu) that the student is allocated to that project. The second supervisor will be assigned automatically later, but staff members can also register themselves for being the second supervisor for specific projects once a project is in the E-Project System.

Whether the supervisory meetings are held in person or online and whether the assessments are held in person or online is decided by the supervisors and the student in agreement and is decided before the project starts.

A list of project suggestions will also be made available on the E-Project System in April during the current academic year. All students that have no project assigned at the deadline (see timetable) are assigned a random project from the list of remaining proposed projects, while taking into account their preference list that they set in the E-project system. Students are encouraged to finalise their project assignment before this step, so that they are guaranteed to have a suitable project. If you end up with a project that not suitable to your skill set, it will be very challenging for you to reach the learning outcomes.

Using Technical Skills Acquired Elsewhere in the Programme

One educational goal is to give the students the opportunity of making practical use of principles, techniques and methodologies acquired elsewhere in the programme. Although new technical skills may be acquired during the project duration, this is not the main aim.

If you select a project that is very far out of your area of expertise, for example if you select a project that involves a heavy programming load and you cannot program confidently in the required language, or if you select an AI project and this is your first contact with the technical details of AI, or if you select a networking research project without having the necessary background, then it will be very challenging to reach the learning outcomes, because there is not enough time in the project duration to acquire new complex technical skills on the required high level.

On the other hand, if you have the necessary technical background, then you are encouraged to propose (or choose from the list) a project that lets you apply your skillset in an area that you might be unfamiliar with, and pick up the necessary context during the early project weeks.

Timetable

IMPORTANT: Students who are on the PLACEMENT YEAR in INDUSTRY who have NOT succeeded in securing a placement by 30 July 2023 have a slightly different schedule. Affected assessment deadlines are in boldface italics in the plan below.
before Apr-24 (week 10 Semester 2) You can already contact potential supervisors if you have an idea for your project
Apr-24 - Apr-28 (week 10) Apr-24: Project topics are made available in the E-Project System
Contact potential supervisors and propose a project to them or choose a project from the list
May-01 - May-05 (week 11) Contact potential supervisors and propose a project to them or choose a project from the list
May-08 - May-12 (week 12; final teaching week of semester 2) Contact potential supervisors and propose a project to them or choose a project from the list
May-15 - May-19 (Exam Period Week 1) Contact potential supervisors and propose a project to them or choose a project from the list
May-22 - May-26 (Exam Period Week 2) Contact potential supervisors and propose a project to them or choose a project from the list
May-29 - Jun-02 (Exam Period Final week) Last week to select a project. All other students are assigned a random project, taking into account their preference list (no guarantee).
Jun-05 - Jun-09 (first week following end of Semester 2) Official project start: Jun-05
Background reading and literature review
EXCEPTION: 31st July YinI students without secured placement.
Jun-12 - Jun-16 Background reading and literature review
Jun-19 - Jun-23 Development of project specification and proposed design
Jun-26 - Jun-30 Development of project specification and proposed design
Jul-03 - Jul-14 Development of project specification and proposed design
Specification and Design report and presentation slides deadline: Jul-14, 5:00pm
10 minute oral presentation of the specification and proposed design must be uploaded by this date

EXCEPTION: 1st Sept 2023 17:00 YinI students without secured placement.
    
Software implementation and testing
EXCEPTION: 4th-8th Sept 2023 YinI students without secured placement.
Jul-17 - Jul-21 Software implementation and testing
Jul-24 - Jul-28 Software implementation and testing
Jul-31 - Aug-04 Software implementation and testing
Aug-07 - Aug-11 Software implementation and testing
Aug-14 - Aug-18 Software implementation and testing
Aug-21 - Aug-25 Software implementation and testing
Final presentation slides and demonstration video deadline: Sep-01, 5:00pm
STATEMENT OF THE OBVIOUS
Make sure you have uploaded BOTH slides and presentation video in advance of your scheduled meeting time.
EXCEPTION: 3rd Nov. 2023 17:00 YinI students without secured placement.
Aug-28 - Sep-01     
To include
  1. Brief (5 page) report on the project.
  2. Video demonstration and presentation (10 minutes) (must be uploaded)
  3. Overheads of slides.
  4. 5-10 minute Q<&>A live discussion and walkthrough with supervisors (normally in the following week. Please contact your first and second supervisor to arrange a time.)
    Write-up of dissertation

EXCEPTION: 6-10th Nov. 2023 YinI students without secured placement.
Sep-04 - Sep-08 Write-up of dissertation
Sep-11 - Sep-15 Write-up of dissertation
Sep-18 - Sep-22 Write-up of dissertation
Dissertation deadline: Sep-22, 5:00pm
EXCEPTION: 1st Dec. 2023 5:00 pm YinI students without secured placement.

Extended deadlines for students who failed 30 credits (or more)

If students fail one or more modules in the first and second semester examinations, then the following rules apply:

If you have failed 30 credits or more you will please need to confirm your intentions by completing an online form by Friday, 2023-Jul-14 (if you have failed 15 credits then you do not need to complete the form) and you must inform the COMP702 Module Co-ordinator, Prof. Paul Dunne (sq12@liverpool.ac.uk) and your supervisors of your decision for the project.

The extended deadlines are as follows.

Delayed projects Deferred projects
Final presentation slides deadline Sep-08, 5:00pm Nov-03, 5:00pm
Dissertation deadline Oct-06, 5:00pm Dec-01, 5:00pm

Assessments


PLEASE NOTE

Several of the components being assessed involve written reports.
The Specification and Proposed Design, Final Presentation, and Final Dissertation.
Guidelines on the number of pages are given.
Templates (in Word and Latex) have also been provided for the dissertation.

When preparing such reports use a font size of at least 10pt and at most 12pt for the main body of the text (i.e. excluding section and chapter headings). The line spacing should be 1 or 1.5. Both of the dissertation templates have been configured to observe these. If you choose to use one of these do not alter the settings.

Although there are no proscriptions on font styles (by default this will not be a problem in LaTeX), if you choose to prepare written material using Word, you are very strongly advised to typeset in either Times New Roman or a sans serif font such as Calibri.


11pt, 1.5 spaced, Calibri/roman is readable with not too much discomfort (allowing for "standard" vision).

6pt, 0.5 space, Gothic is not.

`

The following three components will be assessed (each submitted through the Coursework Submission System https://sam.csc.liv.ac.uk/COMP/Submissions.pl?strModule=COMP702):

Marking Descriptors

Each of the components of assessment will be graded using the CS Department's standard MSc grade descriptors:

GradeClassificationPercentage Qualitative Description
A*Outstanding80-100 Outstanding work. Factually almost faultless; clearly directed; logical; comprehensive coverage of topic; strong evidence of reading/research outside the material presented in the programme; substantial elements of originality and independent thought; very well written.
AExcellent70-79 Excellent work. Logical; enlightening; originality of thought or approach; good coverage of topic; clear, in-depth understanding of material; good evidence of outside reading/research; very well written and directed.
BVery Good60-69 Very Good work. Logical; thorough; factually sound (no serious errors); good understanding of material; evidence of outside reading/research; exercise of critical judgement; some originality of thought or approach; well written and directed.
CGood50-59 Good work. Worthy effort, but undistinguished outcome. Essentially correct, but possibly missing important points. Largely derived from material delivered in the programme, but with some evidence of outside reading/research; some evidence of critical judgement; some weaknesses in expression/presentation.
DMarginal Fail40-49 Inadequate work. Incomplete coverage of topic; evidence of poor understanding of material; poor presentation; lack of coherent argument. Very basic approach to a narrow or misguided selection of material. Lacking in background and/or flawed in structure.
FFail< 40 Unsatisfactory work: Serious omissions; significant errors/misconceptions; poorly directed at targets; evidence of inadequate effort. Shallow and poorly presented work showing failure in understanding.

Proficiency in English

In accordance with Appendix A, 2.1--2.3 of the Code of Practice on Assessment, a good knowledge of written English use must be demonstrated. This includes, minimally, correct spelling and grammar. You should also avoid over (and inaccurate) use of technical jargon (e.g. ``exponential increase'', ``decimate'') and the substitution of exotic polysyllabic constructions where simpler alternatives are available (e.g. ``do quickly'' is better than ``realise expeditiously'', use ``use'' not ``utilize''. In general, short simple words are better than involved lengthy equivalents. Similarly avoid cliche and hackneyed expressions where possible (e.g. ``state-of-the-art'', ``hot topic'', ''user friendly''

Basic proficiency in English will be a point considered in assessing written components of the project and misuse of English may have an effect on the mark given.

Late Submission Policy and Other Penalties

The University's standard policy on lateness penalties will be applied to the submission of any assessed coursework. See Section 6 of the Code of Practice on Assessment for further details.

For the Specification and Design oral presentation and for the Final Presentation the same rule is applied: the marker(s) may decide to penalise the student with 5 marks out of 100 if the presentation is in excess of the reserved time (excluding any time spent on questions from the markers).

Penalties will not reduce the mark below the pass mark for the assessment. Work assessed below the pass mark will not be further penalized for exceeding a presentation time limit or the electronic submission in an incorrect format.

The use of a compression format other than ZIP poses a serious risk that your work may not be marked at all. If we cannot decompress it, then we cannot read it!

Specification and Proposed Design (15%)

By this stage of the project students should have completed the preliminary research and analysis required for the project and so have a clear (preliminary) idea of how they will carry out their project. Typically, this understanding will be recorded in a design using some standard methodology. The purpose of the two deliverables for this stage, a specification and design document, and a presentation, is to present this information both in written form and orally.

Your task is

A recommended structure for the document is as follows. The presentation should follow the same structure as the document, but focus on the most important elements of the design.

Title Page
On the first page you should clearly state the title of the project, your name and student ID, and the names of your supervisor and second marker.
Project Description
A brief statement of what the project is about (likely both a non-technical summary and a more detailed technical summary could be appropriate). This should be a high-level overview of your project, suitable for a reader who is not an expert in the topic area. It should provide enough context so that the reader can understand the following sections. It should also give a clear answer to the question "what contribution does the project make to the knowledge of others".
Aims and Objectives
The aims of your project are broad statements of intent. In other words, what you expect to have achieved after completing the work. Objectives are measurable (i.e., for each objective at the end of the project you can easily test whether or not you achieved the objective) and include the steps needed to achieve the aims. Your aims and objectives should be presented as a bulleted list to help readability.
Key Literature and Background Reading
During the first few weeks of the project you will be conducting background reading and looking at various sources of information. In this section you should demonstrate a good knowledge of the topic area, discussing, citing and summarising key literature, and using it to justify your design and development decisions. This section should also contain a brief summary of your activities since the project began.
Development and Implementation Summary
Provide the most high-level overview design diagrams first that explain your design, for example a use case diagram and maybe a system context diagram or a block diagram. If an important algorithm is part of the project, provide its pseudocode. Provide a brief overview of your proposed development environment and implementation language, and the reasons why you chose them. Also explain how you will implement (realise) your project, including how your workflow will be organised. For key software components include more in-depth UML diagrams. If you intend to run experiments, include an experiment design: the experiments to be performed, a description of how the results will be analysed, including any statistical techniques that will be used.
Your design should cover all important aspects of the system, at an appropriate level of detail. It should clearly show that the design has been carried out with sufficient attention to detail to inspire confidence that it can be realised, tested, and evaluated in the time remaining for the project.
User Interface Mockup
Include a mockup of the user interface, either as a wireframe drawing or a pencil sketch that you scanned in.
Data Sources
If you are using datasets from the public domain, accessing or processing publicly available text, or generating your own data as part of the project, mention it in this section. You should describe the data you will be using, state how it will be obtained, confirm you are using it with permission, and explain how you will ensure confidentiality of any personal information. If you are not using any data in your project then include a statement to that effect, but check with your supervisor that there is genuinely no data use. Remember that evaluation questionnaires will generate data.
Testing
Explain how you will test your project. Include a test design stating which components should be tested and how. If you intend to use other people as beta testers, you should confirm that this will be done ethically.
Evaluation
In this section you should state what criteria will be used to evaluate whether the system is successful; how these criteria will be assessed; who will be involved in the evaluation; what kind of conclusion you expect from the evaluation. If you use other people as beta testers with evaluation questionnaires, you should confirm that this will be done ethically.
Ethical Considerations
In this section you should mention anything that might require you to act ethically. You should state that you have read our ethical guidelines and will follow them. This will include the use of data in the public domain, the generation of new data, and the results of testing and evaluation. There could be other ethical considerations that are specific to your project. If so, discuss them with your supervisor and explain them briefly here.
Project Plan
Include a Gantt chart (or similar project plan) with enough detail to show each stage of your project and your estimates for their duration. Show aspects that can overlap, activities that have dependencies, and so on. Remember to include time for presenting the project and writing the dissertation. Identify what you think will be the most time-consuming parts.
Risks and Contingency Plans
This section should be presented as a table with four columns: Risks, Contingencies, Likelihood and Impact. Common risks for all projects include hardware failure, software failure, running out of time, and programming problems. List possible risks in the first column, and your plans for preventing or handling them in the second column. The third column should state how likely you think the risk is (low, medium or high) and the final column should state the impact.
References
List references to articles, websites, videos, datasets, journals, and any other background reading you carried out while writing the document and planning your project. References should be cited properly in the main body of the document. You should a common referencing style for your field. Guidance is available on the university library website.

The following points also influence your mark:

The submission instructions are at the top of the assessments section.

Final Presentation (15%)

This stage is intended to provide an overview of what has been achieved in the project. The purpose of the two deliverables for this stage, a short report and a presentation, is to summarise the main outcomes of the project. You should prepare (video using your presentation slides) a software demonstration illustrating the primary function(s) of the software.

Your task is

A recommended structure for the document is as follows.

Title Page
On the first page you should clearly state the title of the project, your name and student ID, and the names of your supervisor and second marker.
Project Description
A brief statement of what the project is about (likely both a non-technical summary and a more detailed technical summary could be appropriate). This should be a high-level overview of your project, suitable for a reader who is not an expert in the topic area. It should provide enough context so that the reader can understand the following sections. It should also give a clear answer to the question "what contribution does the project make to the knowledge of others".
Your project description might have been changed following the design stage. Compare it to the corresponding section in your Specification and Proposed Design and indicate what has been changed.
Aims and Objectives
Recall the aims and objectives from your Specification and Proposed Design document. Indicate briefly which goals you achieved and which you have not achieved. Your aims and objectives should be presented as a bulleted list to help readability.
Outputs
A description of what was produced in the project, including any software that was developed, along with a summary of any interesting aspects of the implementation (where appropriate). The report should clearly show the main outcomes/achievements of the project so as to inspire confidence that the project has been completed successfully (to the satisfaction of the supervisors).
Evaluation
An evaluation of what has been achieved, as well as any shortfalls from the original proposal. List the changes that have been made to the original proposal following the design stage. Explain why these changes have been made.
References
List the references used in this document. This can be shorter than for the Specification and Design document.

The following points also influence your mark:

The submission instructions are at the top of the assessments section.

Dissertation (70%)

The purpose of the project dissertation is to provide a complete record of the work carried out by you during the course of the project. The dissertation is a record of what happened during the course of your project. It should detail (at an appropriate level) what was the purpose of your project, what was achieved, what software was designed (if applicable), what hypothesis was being tested (if applicable), experiments performed, data gathered, etc.

Your task is

A great deal of the background material in your introduction will have already been covered in your Proposed Specification and Design. It is okay to copy text and reuse your own material in the dissertation, although you might want to expand on it and discuss things in more depth.

The typical structure of the dissertation is outlined below (the exact content of these sections should not be consider "fixed", nor do they necessarily need to be in this order. This is just a suggestion of aspects of the project that you want to address in some manner in your dissertation).

Title Page
On the first page you should clearly state the title of the project, your name and student ID, and the names of your supervisor and second marker.
Abstract
The abstract should be a clear, informative and concise 350 word summary of your project. Two or three paragraphs is the norm. You should describe what you did and how you did it, including any major recommendations or conclusions. The purpose of the abstract is to allow any future readers to decide whether your dissertation would be useful without having to read the entire document.
Student Declaration
The student declaration covering academic integrity, ethics, and plagiarism, see the templates above.
Acknowledgments
You could have an acknowledgements section where you thank people.
Table of Contents
The table of contents should list all the chapters and major sections in your dissertation to one level of nesting. Include the page number for each section.
A table of figures is also useful if you have lots of diagrams and illustrations, but it isn't compulsory. Number your figures consecutively, even if they are different types. Screenshots, diagrams, illustrations, tables and code snippets are all 'figures' in this context.
Introduction
This is an expanded version of the "Project Description" of the previous documents. The reader should be able to understand what you have done, and why you have done it, without referring to any other documents or submissions for previous assessments. It should provide enough context so that the reader can understand the following sections. It should also give a clear answer to the question "what contribution does the project make to the knowledge of others". It should contain the solution that was produced and remark on its effectiveness.
Aims and Objectives
Recall the aims and objectives from your Specification and Proposed Design document and from the Final Presentation. Indicate briefly which goals you achieved and which you have not achieved. Your aims and objectives should be presented as a bulleted list to help readability.
Background
Reading and research done to acquire the necessary information and skills to carry out the project.
Ethical Use of Data (including human data and/or human participants)
Comment about what data was needed for the project, and how that data was obtained. If human data was used for the project, note that this data should be information that is freely available in the public domain, or anonymised records and data sets that exist in the public domain. Otherwise, human data could only be used if ethical approval was obtained for gathering that data (prior to the acquisition of the data, and for the explicit use in this project).
Note that data obtained through the use of the Twitter API (paying attention to the Terms and Conditions of use) is ok and does not need university ethical approval.
If human data was used that does not fall under the "freely available" categories above, you must state (and demonstrate) that you (or, more likely, your supervisor) followed the university procedure to obtain ethical approval.
The only exception to this rule requiring ethical approval is that the use of human data acquired through the type of questionnaires allowed to students and/or others to evaluate the software you developed, provided you followed the guidelines in requesting this data. See the Ethical Use of Human Data webpage as a reminder.
Design
Documentation of the design; while the organisation should be similar to the design presentation, full detail of the design is required. The components of the system and how they are organised; the data structures and algorithms used by the system; the design of the user interface, including screen mockups, sketches and screenshots; the flow of navigation from one part of the UI to another (particularly important for mobile apps and websites), etc. You will probably want to use UML diagrams or some other design notation. Provide enough detail to show that your system is well-designed and built on solid foundations.
If your project contains experiments, this section should cover the design of your experimental process, including how you controlled for variables (in a non-coding sense), how your results were measured, and how you can be sure the research is robust and replicable. You might have developed your own software to carry out the research, in which case you'll also need to cover its design (as explained above).
All original design documentation should be supplied (possibly as an appendix).
Implementation (Realisation)
Talk about the implementation of your software (or the realisation of the experimental plan). If your software is particularly complex or has multiple parts, you might use more chapters. How the design was implemented. Changes made to the design in the course of implementation. You should also describe the steps you took to test your software components as they were developed. This might include a schedule of unit tests and their results. Any technical implementation achievements you want to highlight or problems you encountered. You should clearly describe what you have developed and how it all works. Include the things that did not work, and any dead ends you encountered, as well as things that went well, to demonstrate the the reality of the development process. Typically, (short) code listings, screen shots, and test runs will appear as appendices.
Evaluation
A critical evaluation of the strengths and weaknesses of the implemented project. This may include customer feedback, if appropriate. The evaluation is a separate activity that involves looking at the software as a whole to see which of your original objectives it meets. You will probably ask other people to use the software and give you feedback, so you should describe how you conducted the evaluation, what questions you asked, and a summary of their comments. If you changed your design as a result of feedback, explain what you did.
Learning Points
At least one page summary of the key learning points in the project. Learning points could include (but are not necessarily limited to) the skills and knowledge that has been acquired or improved by the project, actions that you consider to have been crucial to the success of the project, and things that you would do differently in the future in order to avoid pitfalls, drawbacks, or failures in a similar piece of work.
Professional Issues
Appropriate discussion of how your project related to the British Computer Society (BCS) Code of Conduct. You could also address any issues around the use of human-supplied/human-derived data and/or human participants in this section if you wish (if not done elsewhere in the dissertation).
Conclusion
Summary, main findings, directions for further work. The introduction and conclusion are two halves of the same thing. Together they establish what you have done, why you have done it, and whether or not you were successful. Think of them as a pair of brackets. Whatever you opened in the introduction you should close in the conclusion. List again your aims and objectives, and show how you met them, referring back to sections from your main chapters.
Bibliography
A properly cited list of books, articles, videos, datasets, journals, online resources, and other materials consulted during the project and/or referred to in the dissertation. References should be cited properly in the main body of the document. You should a common referencing style for your field. Guidance is available on the university library website.
Appendices
Appendices are meant to contain detailed material, required for completeness, but which are too detailed to include in the main body of the text. Typically these include details of test data, screen shots of sample runs, a user guide to installation (e.g. "I used Python 3.6, together with the sci-kit learn and pandas modules") and usage of the software (as appropriate), full design diagrams, and similar material. There is no need to include the project code in the pdf, since you submit it with the dissertation anyway. One appendix should be a project log, which will list important dates in the projects: including completion of major stages, release of versions of the software, review meetings, and other quality assurance activities.

The following points also influence your mark:

The submission instructions are at the top of the assessments section.

Details

Time Investment

Module Aims, Learning Outcomes

Module Aims

The main aims of this MSc-level module (from the module specification) are:

Learning Outcomes

After completing the module students should be able to (from the module specification):

LO1
Investigate and specify a substantial problem in the domain of Computer Science, to place it in the context of related work including, as appropriate, Computer Science research, and to produce a plan to address this problem;
LO2
Make use of the qualities and transferable skills necessary for the conduct of a Computer Science project: (i) the exercise of initiative and personal responsibility; (ii) decision making in complex situations; (iii) risk identification (including, as appropriate, commercial and scientific risk), assessment, and control; and (iv) the independent learning ability required for continuing professional development;
LO3
Demonstrate effective time management, self-direction and originality in carrying out a project in the domain of Computer Science;
LO4
Locate and make use of information relevant to a given IT project;
LO5
Design a solution to a substantial IT problem;
LO6
Implement and test potential solutions to IT problems;
LO7
Evaluate critically, as relevant to the project, current research and advanced scholarship in Computer Science, and evaluate their own work;
LO8
Conduct and evaluate critically the project within the professional, legal, social, and ethical framework in Computer Science and Software Engineering;
LO9
Prepare and deliver formal presentations;
LO10
Prepare and deliver a demonstration of software;
LO11
Structure and write a dissertation describing their project.

Conduct of a Project

Reading

An excellent general book on how to tackle Computer Science projects is: Dr Christian Dawson, Loughborough University
Projects in Computing and Information Systems: A Student's Guide, 3rd Edition
Pearson Higher Education, 2015.
ISBN 9781292081120 We have full-text as an online-ressource (but not for download) in the library.

Writing Style

There are many valuable writing guides, either in book form or on the WWW, one example is Postgrad.com. There, you can find information on: (i) study strategies, (ii) writing up your research, (iii) citing and documenting your sources, (iv) grammar and usage, and (v) theses and dissertations. You are encouraged to also use other sources --- look at computer science published journal and conference papers to get an idea of the required style. Remember that you are writing a scientific work and not an extended essay so do not be afraid of using lists, tables, diagrams, etc. --- whatever best gets your ideas across to the reader. However, try to be consistent in your approach to your project, and writing your dissertation.

Log books

It is good practice when undertaking a project to keep a log of your activities. This should provide a record of what you were doing and when, and record all key events in the project. A log book can also be valuable to help record potential ideas/avenues of exploration should time allow it (and when you are writing your dissertation, you can discuss these ideas as possible future work).

Regular Backups

If you are conducting your project using your own computing facilities make sure you back up your work regularly. The Department cannot be held responsible if you lose all your work as the result of, for example, your laptop being lost or stolen, or a hard disk failure. Files on Departmental machines are backed up regularly by our technical staff and are therefore much safer.

Please familiarise yourself with University of Liverpool IT regulations and policies before utilizing any cloud-based repository for storage of programs and data.

Tech support

If you have a technical question or request (like whether you can run specific software from the labs, or whether it is possible to use two seemingly incompatible applications) you are advised to contact the Computer Science Helpdesk (George Holt Building, 2nd floor, near the "blast door" between the Ashton and Holt Buildings). Please bear in mind that the Helpdesk has a busy schedule, so try to clarify your requirements in advance, so that time and resources allow to look for alternatives.

Professional Issues

You need to conduct your project in compliance with the British Computer Society (BCS) Code of Conduct. As part of your dissertation, you will need to discuss how your project and its conduct relate to this Code.

Please bear in mind that for projects that involve the collection of data from people, this must be done in an ethical manner. Collection of such data must be approved before any collection is performed. See the secion on Ethical Use of Human Data. The use or collection of human data (not in the public domain) without ethics approval could constitute research misconduct.

Related project information can be also found here.

Academic Integrity

All students should be aware that they are responsible for what they write. One of the pillars of progress in research is that authors can benefit from each other's earlier work. Arguments made in a dissertation should be supported by facts. One way of doing this is to refer to the existing body of work. For example one can argue that X is true because Y and Z demonstrated it was true in a number of articles published in reputable journals (and then give references to the publications in question). If readers want to disagree with you they also have to take issue with X and Y!

However, it is important for students to make clear, when writing their dissertation, what their original contribution is and what is not. If a student is unable to make a point more clearly than a source that they have found (a book, a paper, or a document on the web), they should use quotations: put the quoted sentence(s) in between quotes " and ", and make clear in the running text where the reference is taken from. Then, cite that source in your bibliography and/or list of references. There are many standards to do citation, students are free to use any style, but should make sure that they make citations in a consistent way.

It does not make sense to quote more than 3 or 4 sentences at one occasion. If readers really have to literally read another source, students should tell them in their introduction, and say that they assume that the reader has read that source before starting reading the student's dissertation.

Apart from using somebody else's text, students may also come across figures, pictures, and diagrams which they think illustrate their point better than they could do otherwise. Again, if this is the case (and students should first check that they are not acting against any copyright law), students should state that the figure/picture/diagram is taken from a particular source, and give the full details of that source in their bibliography.

For projects that utilize data (e.g. to formulate or test hypotheses), data must not be fabricated to conceal a paucity of legitimate data, nor should legitimate data be altered, enhanced or exagerrated to mislead the reader.

For more information, see the University's Code of Practice on Assessment. See also Appendix L of the Code of Practice on Assessment for definitions of plagiarism and collusion, and the penalties for those actions.

Students are expected to read, understand, and follow this Code of Practice on Assessment. Note that when you submit your assessments through the Departmental Submission Server, you are also making a Declaration on Plagiarism, Collusion, and Fabrication of Data (i.e. that the work you submit is your own work, or properly attributed where appropriate, and the data you supply has not been improperly fabricated or altered).

Ethical Use of Data

Some MSc projects could make use of human subjects and/or data about people. When conducting research involving human participants or personal information, it is important that the research is conducted in line with ethical research principles. Under the University's policy on research ethics, all research projects which involve human participants, human tissues, or personal information should receive formal ethical approval before they commence, unless:

The first supervisor of the project should obtain ethical approval prior to the use of human subjects or human data. Using human subjects/human data without ethics approval could constitute research misconduct. Here is the flow chart for the University Ethics Approval Process. This approval process is performed online.

Ethical approval is not required to use data from Twitter as long as the Twitter data is available in the "public domain". Twitter ids should be anonymised (e.g. hash Twitter handles to some other string) when doing so will not violate Twitter's Terms and Conditions.

Note that if ethical approval is necessary, this must be obtained before collection of data begins. Without approval, inappropriate collection/use of data could constitute research misconduct.

The use of artificial data (say, for testing purposes) is allowed, provided that practice is explicitly declared. (It is often common practice to generate data according to a probilistic distribution for testing algorithms/software.) In the case that you do this, you should clearly state how the data was generated, which tests were performed using this artificial data, etc.

Testing Software with Human Participants

Almost all software needs to be tested and evaluated by human participants. Usually this will be family and friends, but if you need a larger pool of people, make sure you recruit and treat them ethically.

Protecting Participant Data

Participant data includes the details of people who test and evaluate your software, questionnaire results, interview transcripts, photos of people, and audio/video recordings of the evaluation. Such data should always be treated according to the following rules.

When you write your dissertation you will probably want to include text and comments from participants. In all cases this should be anonymised, and you should make sure you have their permission to use what they said. You should not use any comments that could inadvertently identify anyone.

Extensions

Since the project module spans such a long time and since time management is one of the module's learning outcomes, running out of time is not an acceptable reason to request an extension. You should be having regular progress meetings with your supervisor. Plan ahead to make sure you submit on time. Supervisors cannot grant extensions. If you have extenuating circumstances you can request an Exemption from Late Penalties. Please contact the Student Experience Team for help and advice.