Site Tools


cm3203_guide

This is an old revision of the document!


CM3203 One Semester Individual Project

This is the main page for information about the 40 credit one-semester individual project module CM3203 for third year BSc Computer Science undergraduate students, including all specialisms. Everything related to this module is managed via PATS. Deadlines and general tasks to complete are visible when you log into PATS (once you are set up).

  • CM3203 Guide: The complete guide for CM3203 on a single page for printing/saving as PDF.

Project Coordinator: Frank C Langbein at LangbeinFC@cardiff.ac.uk

Project Selection (Autumn Term)

The setup of the module and project selection takes place in autumn term. This includes setting you up on PATS, creating proposals and selecting a project.

Further video recordings from the lectures are available on learning central/panopto for this module.

Setup

Before project selection starts, you will get an account on PATS linked to your Cardiff University account. You will receive a notification to your university e-mail address when this is done. Once setup:

  • Check your PATS profile. You can edit some fields yourself. Change of e-mail address must be confirmed (check the confirmation e-mail to the new address). You can use the profile field to provide general information about the projects you are interested in and your background. Potential supervisors can view this during project selection with your proposals.
  • If any information you cannot edit is wrong, contact the project coordinator; in particular, check your course/specialism.

Proposals

You can select a staff proposal or propose your own project:

  • You can submit project proposals on PATS as soon as you have been set up. The proposals are only visible to potential supervisors if you make them available and project selection has been opened (you will get a notification by e-mail when this happens; you are also not able to see staff proposals before then).
  • If you propose your own project, you must find a supervisor for it. There is no guarantee that this will be possible, even if we try to support all feasible projects. It depends on the expertise and availability of supervisors, the required resources and the suitability of your proposal. Discussing your proposal with some supervisors and the project coordinator may help.
  • Supervisors may add more proposals during the selection period, and you can also add your own proposals later, edit them, etc., until selection deadline.

See Project Proposals for further details.

Selection

Project selection usually takes place from autumn week 5 to 11. Details will be sent to your e-mail registered in PATS, and there will be a lecture introducing the module, including project selection and suitable project topics at the start of the selection period. You will only be able to see proposals and available supervisors and agree on supervision once selection has been opened, which usually happens during or right after the introduction lecture. You will also receive a notification once this has happened.

  • Project selection runs via PATS, and you must agree on a proposal with a supervisor before deadline (usually by the end of autumn week 11). The selection deadline cannot be extended due to limited supervision slots. Once this has been completed, you will see your project on PATS and cannot select another project anymore. If you do not select a project, you will get a random supervisor and must agree on a project with them.
  • Once you have selected a project with a supervisor, the selection is final. This can only be changed in exceptional circumstances with the help of the project coordinator.
  • Your project must be related to your degree, particularly if you are on one of the specialisms. You only see staff project proposals that they marked as relevant to your specific degree, but if you propose your own project, you have to make sure it is suitable. If you are unsure about the suitability of your own project or a staff project, please discuss this with potential supervisors. If queries remain, get in touch with the project coordinator.

See Project Supervision for further details.

Ethics and Other Issues

Your project may require ethics approval. All projects involving human participants, human material or human data (Human Research), including surveys and user tests, must be subject to ethical review before the work commences. If you are unsure, discuss this with your supervisor and potentially a School Research Ethics Committee member. You cannot proceed with the work on your project without this. Sometimes it may only be an optional part of the work, but some projects crucially depend on it. You must clarify this as early as possible to ensure the project can be done. So this is an issue already to consider during project selection, even if approval may only be possible to obtain later on. The student and supervisor are responsible for ensuring the project can be done under the School's ethics regulations, including alternative project directions, should it not be possible to ensure this during selection.

Please watch the “Ethics for Dissertations” video in the panopto/learning central CM3203 folder [PDF Slides] with further details. If you need ethical approval there are two options:

  • Simplified ethics, i.e. approval by a supervisor:
    • You can use this if you are running one of the approved study types: anonymous survey (to gather requirements for the system you are developing); usability evaluation (questionnaire, interview, think aloud).
    • And you are not meeting the full review criteria (i.e. you are not working with vulnerable participants and your dissertation does not focus on a potentially sensitive topic).
  • Regular ethics application:

The CM3203 ethics framework with the dissertation project ethics form for simplified ethics:

  • CM3203 Ethics Framework (approved until 29/11/2026); supervisors should send the approved form by e-mail back to the student and the module leader.

with the following templates/exemplars for adoption by the students:

Other issues, such as required resources (e.g. special hardware or software) or legal issues (e.g. intellectual property and licensing), must also be considered for the proposal when agreeing to supervision and during execution, with proper risk management in place.

It is the student's and supervisor's responsibility to ensure that the project is, in principle, feasible to execute and suitable for the module/degree scheme.

Project Execution (Spring Term)

The project is executed in spring term, from week 1 to week 12. Regular supervisor meetings will happen in that period and are to be arranged individually with each supervisor. As the student is expected to manage the project, they are also responsible for ensuring these meetings occur. The supervisors may follow up on students not attending, but this is not guaranteed. On average, the meetings are expected to be 30 minutes per term week, but the time can be distributed arbitrarily across the 12 weeks. It may include group sessions as suitable for the project. Specific arrangements should be agreed upon between the student and supervisor. If the student cannot get hold of the supervisor within the agreed schedule, they should contact the project coordinator (considering that usually, it can take up to a week for the supervisor to respond, even if often they are faster).

The work on the project is towards the two assessments for the module:

  • CM3203 Initial Plan: You must submit an initial plan (by the beginning of spring week 2, at most 2,000 words, worth 5%).
  • CM3203 Final Report: A final report must be submitted at the end of the semester (by the end of spring week 12, at most 25,000 words, worth 95%).

You also find the required deliverables with their exact submission deadlines under your PATS project details. The word limits are a maximum for the main body of the report, not a target. Enough information such that a competent computer scientist can understand and reproduce the work should be given in the report, and any appendices or supplementary material (both do not count towards the word limit). More guidance and details about the coursework are in the corresponding sections above.

Extenuating Circumstances

If you have any extenuating circumstances, Cardiff University's rules for undergraduate coursework apply (do not confuse these with the regulations for postgraduate dissertations). You can either obtain an extension or a deferral to the next possible time (usually in the resit period over the summer or the following academic year). Generally you would submit this in the two weeks before deadline.

Repeats

If you do the project in the summer resit period (for any reason), you would usually work on the same project with the same supervisor and moderator. This will automatically be set up, and you will get details on deadlines, etc., after the year exam board. If the supervisor is not available, another supervisor will be found.

If you repeat the project (for any reason) during term, this will not be automatic. It will be an internal repeat of the module (external is not possible), taking you through the complete process. You must select a project/supervisor again in the autumn term to execute the project in the spring term. Still, you can agree on the same/adjusted project with the same supervisor if they are available.

Project Selection

Project Proposals

You can take on a project proposed by a supervisor or propose your own project. The latter gives you the opportunity to work on something you are specifically interested in, but there is no need to propose your own project, and there is otherwise no difference in the requirements or assessment of the project. Note, supervisors must be a member of staff at the School Computer Science and Informatics, and supervisors available for a module are pre-assigned and visible to you when project selection starts. It is sometimes possible to add another member of staff, if they voltuneer.

As soon as you are set up on PATS, you can write your own proposals. They will be visible if they are marked as available and project selection has started (see Project Supervision for how to select a project). Student proposals are only visible to supervisors; staff proposals are visible to students on the degree programmes the proposal is intended for. Here we discuss how to write and submit your own project proposal. The process is the same for students and supervisors, and both kinds of proposals should provide the information outlined here.

You can submit more than one proposal, but please keep the number of proposals reasonable and rather make sure you write one or two excellent proposals. This will make it much more likely that you find a supervisor for your project. You can still choose a staff project later, even if you propose your own project. If you propose your own project, there is no guarantee that there will be a supervisors for it. This will depend on the quality of your proposal, its feasibility to be executed, and the supervisors' interests, availability and expertise.

To a lesser degree, this equally applies to staff proposals: there is no guarantee to find a student who can or wants to do a particular staff project, nor do members of staff have to supervise all their own proposals. However, members of staff are expected to supervise a certain number of projects (PATS indicates this in the supervisor list if the project coordinator uses that feature), and a student who does not select a proposal will be assigned a random supervisor who has project slots left. In this case, the student and supervisor should discuss what the project should be, but it is likely to be taken from the supervisor's or student's (if feasible) proposals.

Deadlines for proposal submission (and selection) are announced via e-mail and visible in the PATS Tasks section.

Projects

The purpose of the project is, in the context of the degree you are studying, to integrate various aspects of the taught material and to demonstrate your (academic) research skills and your (professional) analysis, design and implementation skills. It allows you to conduct in-depth work on a substantial problem to show individual creativity and originality; to apply, where appropriate, knowledge, skills and techniques taught throughout the degree programme; to further oral and written communication skills; and to practise investigative, problem-solving, management and other transferable skills. The management and execution of the project are the student's responsibility, but they should seek and take advantage of advice from their supervisor.

As a general guideline, a good project aims to solve a problem related to your field of study. You can pick a general area you are interested in and try to find a specific problem you could be working on. Instead of solving a complete problem, you can also work on a partial solution or some particular aspect of a larger problem, possibly simplified to make it feasible for the duration of your project and the level of the degree. If you are unsure of the specifics, you can also discuss a rough initial idea for a project with a supervisor to find something suitable that can be executed in the module context. Out of such discussions, often exciting project ideas arise.

When you choose a project, you should do so carefully to reflect the focus of the degree programme you are enrolled in, your interests (the project needs to keep you interested for its duration) and the ability of the academic staff to support you throughout your project. Projects vary widely in the problem they address and the products they deliver at the end. While the main product of some projects is a piece of software or hardware, others produce a systems model or design, and yet others may address some research hypothesis using a theoretical, computational or experimental approach. This means not every project produces a piece of software. If you are addressing a research hypothesis, your main product may be the evaluation of some experiments or a theoretical result. In brief, the better the problem you are addressing is defined, the further through the systems lifecycle you should expect to progress.

For example, a project that seeks to develop a logistics planning system for a small business or voluntary organisation would be expected to provide a fully operational, thoroughly tested program that meets all the identified needs of the client. However, a project that aims to validate a government policy in a particular area might only achieve the development of a model to confidently simulate the main factors influencing that policy and identify the research agenda in terms of specifying precisely the data requirements to allow a full investigation of the relevant factors. A scientifically oriented project may focus on the practical or theoretical evaluation of an algorithmic approach and compare it with other approaches. This may involve some implementation but does not require fully functional software.

Importantly, your project must solve a problem. That means it cannot simply produce a literature review, discuss existing solutions of some form, etc. You should demonstrate you are aware of the background and context of the problem, clearly specify the problem you are aiming to solve, work and report on how you solve the problem and evaluate your solution. Note that you may not necessarily have to achieve a positive result. E.g. if it is not clear at the start that your approach will be successful, but based on the background, it appears to be a suitable direction to explore, then your evaluation producing a negative result is still useful (of course, this is different if you are trying something that is known not to work / where it is hard to find a justification of why to try it). For a specific proposal, it can be very helpful to discuss what you are expected to achieve and how to deal with any risks with a supervisor.

Writing a Proposal

To submit a new project proposal, go to “My proposals” in PATS' navigation bar, which takes you to a section listing your own proposals. There you can add new proposals, edit or delete existing proposals and make them available for selection.

To create a new proposal, go to the “New Proposal” tab and enter a proposal title and description. If you are a student, the proposal will automatically be assigned your degree scheme (check in your profile that your degree scheme there is correct and contact the project coordinator if this needs to be amended). Staff should select the degree schemes for which their proposal is suitable from the list provided. This is important as the project must be related to the degree studied, particularly for any specialisms. Staff and students are advised to check this carefully.

When choosing a title for your proposal, make sure it refers to the core topic of your project. Do not make the title too general (like “A Computer Game” instead of the specific type of game you wish to write) or provide too many details (“A System to Manage the Selection, Allocation, Deliverable Submission and Marking of Final Year Projects”, instead of “Final Year Project Management System”).

Provide the following information in the description of your project. Note that it is expected to be plain text, and any other formatting may not be preserved or even make it hard to read; there is a 4,000 character limit. The idea is to provide a concise description akin to an abstract:

  • Two or three sentences providing the essential context and motivation of the project.
  • One sentence summarising the general problem to be addressed.
  • Two or three sentences explaining the detailed issues to work on.
  • Two or three sentences outlining an approach how to address these issues. You may extend this to include multiple potential approaches here and also indicate expected results.

Take this as a suggestion for what to write in which order. Of course, other formats can also be suitable, but the problem and approach to address it should be apparent.

In addition, the following project-specific issues may have to be addressed:

  • Describe any special resources needed, e.g. non-standard hardware, special software, etc., that are either available via university, some other source or the student may own already. If they are not available, then the project may not be feasible.
  • Indicate if the project requires ethical approval. This affects any project involving human participants, human material or human data (Human Research)
  • Any legal issues, especially intellectual property and licensing, that may apply. Note that the foreground work on the project belongs to the student, but background and sideground or industry involvement can create additional requirements. Cardiff University's research support may have to be involved for further advice, but they cannot legally represent the student.

Student and supervisor are responsible for ensuring that the project can be executed in principle. Make sure you check this with suitable risk management before you agree to do a project.

Staff may also wish to discuss the skills needed to execute the project and the skills that must be acquired during the project. Similarly, students may want to indicate that they have or are willing to acquire any specific skills for their proposed project that would usually not have been covered by the course.

PATS' project archive contains some example projects that may help you write your proposal. Note that you can do similar projects to those there, but not exactly the same.

Obviously, the project proposal must be your own, in your own words, even if there may be overlaps between problems and topics with other work; this includes project proposals from other students and supervisors. Sometimes it is possible that you can work on someone's proposal with a different supervisor. Still, you must ask the proposer for permission (and acknowledge them suitably in the documents as the source of the proposal). Generally, if there is a source for the proposal, parts of it or maybe just a useful related resource, you should cite it (author/location or URL in a compact citation format is sufficient).

Arranging Project Supervision

After proposals have been submitted, they become available for arranging supervision once selection has been opened. This will be announced by e-mail. Supervisors can then view your proposals (that are listed as available), and students can view staff proposals. You can only see proposals that match your degree, but you should question if they are suitable and potentially discuss this with the proposer. It is also still possible to edit your proposals and add additional proposals to the system (until proposal submission has been closed, which is usually done at the same time selection must be completed). Suitable navigation links will then be available in PATS to view proposals and express interest in them. Deadlines for active tasks are visible in your task list in PATS.

Initially, you should express interest in the proposals you are considering on PATS. This indicates to the proposer that you may want to do the project, but it does not mean supervision is agreed upon. Members of staff can see which proposals you are interested in, and you can see who is interested in your proposals. PATS shows a plain list of all proposals but also a list of supervisors (or for supervisors, a list of students) with their proposals and profile information. Students can also see how many project slots a supervisor still has available (if the project coordinator is using this feature). Only the supervisors explicitly listed for the module are available for project supervision; other supervisors can sometimes be brought in, if possible, which is to be arranged via the project coordinator.

Then you should contact supervisors to discuss the proposals to agree on supervision, either for their projects or your own projects, particularly if they have expressed interest. It is better to be proactive and contact supervisors early instead of waiting for them to contact you; that includes supervisors you think may be suitable for your project but have not indicated interest. Also, members of staff have limited supervision slots, and once they are gone, they do not have to take on more projects (they can choose to do more projects, of course, but those with free slots are more likely to agree to supervise you).

You must discuss a proposal with a supervisor before supervision can be agreed upon. This should be done with an in-person or virtual meeting, not an e-mail alone. If you wish to do the project, clearly indicate this to the supervisor during the meeting or later on via e-mail.

Discuss the following during the meeting:

  • The project and any clarifications on the problem or its specific version (in case there are multiple options).
  • Expectations of what should be done to complete the project to a specific standard.
  • Your degree scheme to ensure the project is suitable for you.
  • Supervision arrangements such as regular meetings and communication (project management is the student's responsibility).
  • Any special resources needed, ethics or legal issues related to the problem to ensure it is feasible to execute.
  • If you want to decide later, the likelihood of the proposal and supervisor to remain available (in the time the proposal may be taken by another student or the supervisor may run out of project slots).

The student and supervisor are responsible for the project being executable in principle, including any appropriate risk management. This should be clear before project supervision is agreed upon on PATS.

If a supervisor is happy to take you on for a project and you agree to do the project, they can select to supervise you on PATS directly. Once this happens, you have a project agreed upon and cannot select any other project; if there is a problem, please contact the project coordinator (a change without a well-justified reason is unlikely). You will receive an e-mail from PATS that the project has been created and see the project with details (instead of the proposal/project selection) in the navigation bar. The deadlines also appear in the task list.

Note that supervisors can only choose to supervise you on a project in which you have shown interest. If it is your project, they must show interest before they can select to supervise you. This is to reduce mistakes in agreeing on supervision.

After supervision has been agreed upon, the proposal accepted will become unavailable, and the students' other proposals will also be marked as unavailable. A supervisor can make their own proposals available again if they think there is sufficient scope for more than one student to work on different aspects.

If you do not select a proposal by the deadline, you will be assigned a random supervisor shortly after the selection deadline. You must then agree on a project with this supervisor, which is likely based on one of their projects still available or your project if it is feasible. At that stage, there is no other choice. This is not in your interest, as you may well get the worst possible arrangement. Even if you cannot find a perfect proposal or cannot find a supervisor for your own proposal, it is still better for you to select a proposal than not select anything at all. Note that the deadline cannot be extended as no supervision slots are available after this has been completed.

Changes to Projects

After supervision is agreed supervisor and project cannot easily be changed anymore. Many projects have a range of possible directions or approaches, which you can still select from, and these are often indicated in the proposal/project description.

A major topic change that is not within the remit of the project proposal agreed upon (and potentially refined in the project description once the project has been created) requires agreement between the supervisor and student. Otherwise, even a successfully executed project may result in failure due to working on a different topic. Usually, supervisors are flexible, and projects can be adjusted, particularly if there is a reasonable justification for it. However, they must remain suitable for the module and degree scheme you are on, and you cannot arbitrarily change the project.

A change of supervisor after the deadline of the project selection is generally impossible. It will only be considered if the supervisor becomes unavailable for a long (most/all of the term) period or similar major reasons. If there is any issue, discuss this with the project coordinator.

Deliverables

CM3203 Final Report

You must submit a final report worth 95% of the total project mark, which should cover the background and context of the problem, clearly specify the problem you solved, the methodology and approach of your solution and an evaluation. You also have to submit a complete set of the deliverables developed for the project, including any source code, data and results relevant to your work. This involves the development of some tangible piece of software, hardware, system design or theoretical result. It need not necessarily be a usable finished product. Instead, it could be, for example, an extension of an existing system or a prototype built as part of a feasibility study. Deliverables do not necessarily have to be programs but could be in non-executable form, for example, a theoretical result. This must be submitted at the end of spring week 12 (see the exact deadline for the final report listed in PATS).

Please see your initial plan, in which you should have clearly outlined the aims and objectives and, with that, the deliverables for the final report. Your supervisor and/or moderator may have left additional comments on your plan on PATS to tell you whether these deliverables are suitable and what they expect for the final report. Your deliverables may be adjusted based on your findings since the initial plan and in discussions with your supervisor. Note that you must agree with the supervisor on any significant changes to the original plan/proposal. Generally, discuss carefully with your supervisor what you should include in the final report.

Contents and Structure

The final report should be at most 25,000 words long. The word limit is a maximum for the main body of the report, not a target. Enough information such that a competent computer scientist can understand and reproduce the work should be given in the report, and any appendices or supplementary material (both do not count towards the word limit).

A possible structure for your final report is as follows:

Title Page Support
Abstract
Acknowledgements
Table of Contents
1.Introduction Main body
2.Background
3.Methodology / Approach / Specification, Design and Implementation
4.Results and Evaluation
5.Conclusions and Future Work
6.Reflection on Learning
Appendices Support
References

Note that this is only a suggestion, and you can adjust the chapter headings and structure to suit your project. Especially you may want to consider adapting Chapter 3 to something that more specifically reflects the specification and solution of your problem and potentially even split it into multiple chapters. Please discuss the structure and contents of your report with your supervisor.

Project Report Writing

Here we give you some brief guides and further reading material to help you produce a good project report. A good report presents your project work concisely and effectively. It should contain various materials relevant to your work in respect of your project; it should be organised into a logical framework; it should be supported by written material that follows well-established academic conventions in a consistent fashion.

An important point to remember is that the report should describe your work. Large chunks of bookwork describing standard material are unnecessary. You should refer to such material, assuming that your reader is a competent computer scientist, and a lot of it can be summarised with further details in suitable references. The guidelines here are arranged roughly in the order you need.

Your project supervisor will guide you on what it is reasonable to expect a project in your chosen topic to deliver. However, all projects must justify all decisions made at every research stage and develop appropriate deliverables, including the choice of approach.

Submission

You must submit your report with all supporting material by the deadline on PATS in the final report tab for your project.

Note that the main report file must be a PDF file. Please see the Submission Guide for information about submitting a report via PATS. Also, ensure the project title and the project description on PATS matches the project title and the work in the report (you can use the abstract from the report for the project description).

Also, consider Project Publication details about how to publish (or not) your project online in the PATS archive.

Assessment

Before you submit the final version, you should discuss the report with your supervisor, who can give you general guidance on the structure and what to write as feed-forward towards the final report assessment. Make sure you arrange this well in advance of the submission deadline so that you can agree upon a timeline for this, and there is enough time for your supervisor to look at a draft. You may, for example, discuss an outline of the report with chapter and section headings with your supervisor and later on discuss specific questions you are having on the content.

The final report is worth 95% of the module's total mark. After the submission deadline, your supervisor and moderator assess the final report independently, giving an individual mark out of 95. A combined mark will be agreed upon based on the individual marks between your supervisor and moderator in a separate discussion after the individual marks have been given. A total mark for each assessor will be computed as the sum of their initial plan (out of 5) and final report mark (out of 95). If these two marks differ by more than 10, a third marker will be appointed to decide upon a final mark based on the individual and combined report marks. If the two marks differ by less or equal to 10, the sum of the mark agreed upon by the supervisor and moderator (out of 95) and the average initial plan mark (out of 5) will be the total mark for the module. After this process, an external examiner will check the report marks, and the exam board will confirm the marks. You will then receive your official mark for the module via SIMS. Once you have received your mark via SIMS, you can ask your supervisor for informal feedback on your work (e.g. contact them by e-mail). Before then, your supervisor or anyone else cannot confirm your mark.

The criteria for assessing the final report are listed below. Please read these carefully, as it will help you see what your assessors will look for in your report. Also, take into account what you promised to produce for the final report in your initial plan, your supervisor's and moderator's comments on this on PATS, and any further discussions with your supervisor (as you may have changed the deliverables from the initial plan in discussion with your supervisors, etc).

Assessment Criteria

Your supervisor and moderator will assess your final report according to the following criteria/skills:

  • Problem and background
    • Understanding of the problem and the aims and objectives of the project
    • Awareness of the background of the problem
    • Detailed analysis of the problem, suitability of approach towards solving the problem
  • Solution to the problem
    • Approach and design
    • Solution, implementation
    • Use of and justification for appropriate tools/methods
  • Evaluation
    • Testing and validation
    • Critical appraisal of results
    • Achievement of agreed overall deliverables given in the initial plan for the final report (or a justified modification of these)
  • Communication and project management skills
    • Written communication skills
    • Project planning, control and reflection
    • Interaction and work with the supervisor

The scale for this assessment is:

  • Fail (0-29%) - Incomplete solution: poor understanding or ability to apply the skill; solution is incomplete or irrelevant.
  • Marginal Fail (30-39%) - Needs significant improvement: limited understanding or ability to apply the skill; solution demonstrates some awareness of the problem.
  • Pass (40-49%) - Meets minimum expectations: basic understanding and application of the skill; solution meets minimum requirements.
  • Adequate (50-59%) - Meets expectations with some issues: competent understanding and application of the skill in common situations; solution is good with some issues.
  • Good (60-69%) - Meets expectations: competent understanding and application of the skill; solution is good with only minor issues.
  • First Class (70-79%) - Meets expectations to high standard: demonstrates exceptional proficiency, readily applying the skill in complex scenarios and potentially optimizing its use; solution shows initiative, critical thinking, and a well-developed approach.
  • High First Class (80-100%) - Exceeds expectations: excels in using the skill independently and possesses a deep understanding; solution potentially contributes to the field's advancement through innovation or research.

Project Publication

If you wish to make your project available online after it has been completely submitted and marked, you can specify this in PATS. On the project description page you can check “make project public”. This will generate a publication form that will automatically be added to your project. You can see the way your project (as far as it has been submitted) will appear, once published via PATS, in the “Complete Project” tab. Everything visible there will appear in the PATS archive if you select to make your project public. Examiner reports, marks, etc. will of course not be available there. If you choose to publish your project, make sure it does not contain anything you do not wish to be publicly available on the PATS site. The date by when you must finalise this is shown in the description tab of your project, at the bottom, indicating how long the data can still be modified. A copy of the publication form is here:

Note that we cannot guarantee that your project will be published via PATS or for how long it will remain available. We will also only make projects available that achieve a sufficiently high mark.

You can request to unpublish your project from the archive later on with an e-mail to the project coordinator. Make sure we can identify that it is really you. We may ask some additional questions. Note that unpublishing is permanent and cannot be reversed.

Guides

Gathering Material

This section outlines the kinds of material you need to collect before you can begin writing in earnest. Most of the necessary material will consist of your own ideas and experiences gained while carrying out the project, and your approach to solving the problem you have decided to address. For the background study or literature review you will also need references to various resources such as key books and papers, policy documents, Internet resources, related software, etc.

While working on the project you may find it helpful to keep a notebook handy and record all relevant information. Typically such information will include:

  • references such as papers, books, websites with full bibliography details;
  • lessons learned, for inclusion in the “reflective” part of your report;
  • notes from meetings or interviews with
    • your supervisor,
    • potential end-users and other stakeholders,
    • technical experts;
  • and so on.

Also, we recommend that you keep a diary of all your project-related activities. This will show the progress made during the life of the project and will provide a record of how you spent your time. In particular, when you are validating, testing and debugging your work, keep a running log of your activities and their outcomes. You will then have a record of the unforeseen difficulties you met and, hopefully, how you resolved them. Summaries of these may well be worth including in the project report (see Implementation).

In general you should supplement the material you generate yourself with relevant material from other sources. A good project report will show that you are aware of relevant work that other people have done (see Background). You should include relevant references to such work in your project report. References to work in periodicals, i.e. magazines and journals, and conference proceedings may be more useful than references to textbooks, as periodicals and conferences are usually more specialised and up to date. References to technical manuals and national and international standards should also be included, where appropriate. You may also cite web sites as sources, if suitable. However, keep in mind that web sites may often contain incomplete or wrong information and in general textbooks or papers are a better reference and show that you have done a more extensive literature review than just searching for some keywords on the Internet.

Arranging Material and Structuring the Project Report

You should consider, at the beginning of your project, what you need to do to solve the problem you have chosen to address. This will then inform choices about the structure of your reports; your written reports need to be both a “narrative” (telling the story of your project) and an “argument” (providing a logical justification of the steps you have undertaken to solve your chosen problem). Once you have started to gather material you can begin to arrange it in a form which can then be refined into a report, though the outline chapter headings shown below will serve as a good guide in the early stages of your work.

All good project reports whatever their subject, follow certain well-established conventions and have a similar overall shape. They generally consist of a main body surrounded by other information (presented in appropriate formats) that support it in various ways. Some of these are mandatory, others are optional. You can vary the titles of the sections if these are inappropriate for your project - your supervisor is the best person to guide you on this. Here we concentrate on the main body of the report and generic sections. We recommend for writing the report that you start with an outline of the main and sub-sections (or chapters and sections) as a guide on what you should be writing in detail.

We look at each of the general sections of the report structure in more detail below. You can use this characteristic structure as a rough template for organising the material. However, often it may be of advantage to adjust the suggested structure to your particular project instead of sticking to the template. Consult your supervisor for advice. It is also a good idea to plan roughly how long each part should be before writing the report, to make sure that the length and overall balance are about right. You can then construct each part to produce a first draft of the main body.

The "Introduction"

A good introduction should tell the reader what the project is about without assuming special knowledge and without introducing any specific material that might obscure the overview. It should anticipate and combine main points described in more detail in the rest of the project report. Also, importantly, it should enthuse the reader about the project, to encourage them to read the whole report. Normally it should include such things as:

  • the aim(s) or goal(s) of the project,
  • the intended audience or “beneficiaries” of the work done,
  • the scope of the project,
  • the approach used in carrying out the project,
  • assumptions on which the work is based and
  • a broad summary of important outcomes.

The "Background"

The purpose of the Background section is to provide the typical reader with information that they cannot be expected to know, but which they will need to know in order to fully understand and appreciate the rest of the report. It should explain why the project is addressing the problem described in the report, indicate an awareness of other work relevant to this problem and show clearly that the problem has not been solved by anyone else. This section may describe such things as:

  • the wider context of the project,
  • the problem that has been identified,
  • likely stakeholders within the problem area,
  • any theory associated with the problem area,
  • any constraints on the approach to be adopted,
  • existing solutions relevant to the problem area, and why these are unsuitable or insufficient in this particular case,
  • methods and tools that your solution may be based on or use to solve the problem,
  • and so on.

The wider context of the project includes such things as its non-computing aspects. So, for example, if you are producing software or any other products, including business recommendations, for a specific organisation then you should describe aspects of that organisation’s business that are relevant to the project. If you are doing a research oriented, say on particular algorithms, you should also refer to the general problem for which these algorithms are useful (the application(s) for your techniques).

Relevant existing products, documents or artefacts that you should mention could be ones that, for example,

  • are similar to the one you are proposing,
  • support your project,
  • your project aims to extend or replace,
  • demonstrate the “deficiencies” your project intends to address.

You need only describe things that will be unfamiliar to the potential reader, or are unique to the organisation or topic your project addresses. Your project, if it involves software development, will almost certainly use all kinds of existing software such as language compilers, subroutine libraries, etc., but you can assume that the reader will be fully acquainted with, for example, general purpose programming languages such as Java, C/C++, Fortran, Pascal, Python, PHP, etc,. Also, it may involve the better known specialised packages such as MySQL, ORACLE, OpenGL, etc. You should mention the particular variety and possibly version number, e.g. Java SE 6, but you need say nothing more than that.

If your project depends on any specialist or uncommon software such as specialised subroutine packages or a more obscure or specialised programming language, you should describe them briefly and discuss whatever features are relevant to your project. Often this can be done by comparing it to some well-established piece of software, for example

The Descartes language is like a restricted version of Pascal but with
the following extra features: ...

Again, long descriptions of details are to be avoided and references to suitable sources of detailed information should be given instead.

Other background information could consist of the sequence of events leading up to the present situation or the results of earlier investigations. You could also discuss such things as any cost or time constraints imposed on the project.

Your background section should end with a clear statement of the research questions problem your project is trying to answer. These will reflect the aim of your project, but will be different in that they explain the problem you are attempting to solve, e.g.,

Example 1:

Aim: 
The aim of this project is to develop software for the improved planning
of the routing of delivery vehicles to customer locations, that reflects
the forecast availability of each customer to receive goods.

Research question(s):
In order to demonstrate the achievement of the stated aim, this project 
will identify route planning software currently in use and the
underpinning algorithms, define appropriate performance metrics,
determine how to express constraints on an alternative algorithm, 
develop an improved algorithm and demonstrate on what basis it is judged
an improvement, and implement the improved algorithm in a usable and
robust software package.

Example 2:

Aim:
The aim of this project is to develop a business strategy for organisation
X that will improve the survivability of X in the face of increasing
global competition.

Research question(s):
In order to develop a business strategy it will be necessary to identify
key stakeholders and determine their vision for the organisation at the
end of the strategic planning time frame, assess the likely outcome, in
terms of the organisation's survivability, of maintaining the current
strategy, and develop and assess an alternative set of activities to
achieve the stated vision.

The "Specification, Design and Implementation"

This is one suggestion for the description of how your solution works. In some cases a methodology or approach to solve the problem may be more suitable to present the work. For this part, in particular, you have a lot of freedom of how to structure your report to present your solution.

Specification and Design

The purpose of specification and design is to give the reader a clear picture of the system you plan to create, in terms of the capability required. A specification should tell the reader what the software system is required to do. The design then gives the top-level details of how the software system meets the requirement. It will also identify constraints on the software solution, that are important in guiding decision making throughout the development process.

Describing what a software system does (specification) and how it does so (design) effectively usually means describing it from more than one viewpoint. Each viewpoint will convey some information about the system that other viewpoints omit. (You would use the same technique when describing any complicated construction such as a building, an aircraft, a novel or a painting). Possible viewpoints might be:

  • the business model the software supports,
  • the user interface,
  • the dynamic behaviour of the system,
  • how data flows through the system,
  • what data types are implemented in the system,
  • what algorithms are implemented in the system,
  • the static architecture of the system, i.e. how the code is partitioned into modules, etc.

A common approach is to first define the user or business requirements, then describe the static architecture, identify modules and groups of closely connected modules, and then to apply other views to each of these groups. Fine details, specifically details of code, should be left out.

We strongly recommend that you make extensive use of diagrams, such as entity-relationship diagrams, UML diagrams, state charts, or other pictorial techniques.

As well as describing the system, it is important that you justify its design, for example, by discussing the implications of constraints on your solution and different design choices, and then giving reasons for making the choices you did. Typically these implications will relate to the aims of the project and to aspects of it discussed in the Background section.

The design of the system will almost certainly have evolved while you were developing it. Obviously you should describe its final state but often there are good reasons for describing intermediate states, too; for example, if you want to discuss the details of the design method used or to highlight learning that you later refer to in the Reflection section. If you do this, take special care to make sure the reader does not get confused between different stages of the design.

If you are not designing a system, but testing a hypothesis for a more scientifically oriented project, specification and design sections may not be required in quite the same form. The specification instead becomes a description of the problem and what is required of a solution. The design becomes a description of your approach to solving the problem and your suggested solution(s). For instance, if you are designing an algorithm to solve a particular problem you would have a problem statement section and then a section describing one or more suggested algorithms to solve the problem. Later in the Results and Evaluation section you then describe how to design experiments to test how well the algorithm(s) solve the problem and present your experimental results with an evaluation of your suggested solutions.

Implementation

Implementation is similar to the specification and design in that it describes the system, but it does so at a finer level of detail, down to the code level. This section is about the realisation of the concepts and ideas developed earlier. It can also describe any problems that may have arisen during implementation and how you dealt with them.

Do not attempt to describe all the code in the system, and do not include large pieces of code in this section. Complete source code should be provided separately. Instead, pick out and describe just the pieces of code which, for example:

  • are especially critical to the operation of the system;
  • you feel might be of particular interest to the reader for some reason;
  • illustrate a non-standard or innovative way of implementing an algorithm, data structure, etc.

You should also mention any unforeseen problems you encountered when implementing the system and how and to what extent you overcame them. Common problems are:

  • difficulties involving existing software, because of, e.g.,
    • its complexity,
    • lack of documentation;
  • lack of suitable supporting software;
  • complications with specific hardware or software platforms;
  • over-ambitious project aims.

A seemingly disproportionate amount of project time can be taken up in dealing with such problems. The Implementation section gives you the opportunity to show where that time has gone.

The "Results and Evaluation"

In this section you should describe to what extent you achieved your goals.

You should describe how you demonstrated that the system works as intended (or not, as the case may be). Include comprehensible summaries of the results of all critical tests that were carried out. You might not have had the time to carry out any full rigorous tests - you may not even got as far as producing a testable system. However, you should try to indicate how confident you are about whatever you have produced, and also suggest what tests would be required to gain further confidence.

This is also the place to describe the reasoning behind the tests to evaluate your results, what tests to execute, what the results show and why to execute these tests. It may also contain a discussion of how you are designing your experiments to verify the hypothesis of a more scientifically oriented project. E.g., describe how you compare the performance of your algorithm to other algorithms to indicate better performance and why this is a sound approach. Then summarise the results of the tests or experiments.

You must also critically evaluate your results in the light of these tests, describing its strengths and weaknesses. Ideas for improving it can be carried over into the Future Work section. Remember: no project is perfect, and even a project that has failed to deliver what was intended can achieve a good pass mark, if it is clear that you have learned from the mistakes and difficulties.

This section also gives you an opportunity to present a critical appraisal of the project as a whole. This could include, for example, whether the methodology you have chosen and the programming language used were appropriate.

The "Conclusions and Future Work"

The Conclusions section should be a summary of the aims of project and a restatement of its main results, i.e. what has been learnt and what it has achieved. An effective set of conclusions should not introduce new material. Instead, it should briefly draw out, summarise, combine and reiterate the main points that have been made in the body of the project report and present opinions based on them.

It is quite likely that by the end of your project you will not have achieved all that you planned at the start; and in any case, your ideas will have grown during the course of the project beyond what you could hope to do within the available time. You can include discussion of future work in the conclusions or as a discussion at the end of the evaluation section. It is for expressing your unrealised ideas, focused in particular of what you suggest as next steps (possibly emerging out of your evaluation). It is a way of recording that 'I have thought about this', and it is also a way of stating what you would like to have done if only you had not run out of time (Remember to take into account Hofstadter’s Law: 'Everything takes longer than you think, even when you take into account Hofstadter's Law.'). Ideally it should provide a starting point for someone else to continue your work.

The Conclusions section marks the end of the project report proper. Be honest and objective in your conclusions.

The "Reflection"

We believe in the concept of “lifelong learning”. One of the principles applied throughout the assessment during your studies is that of the value of reflection. We believe that it is important that we reflect upon our performance in order to identify “transferable learning”, that can be carried over into future activities. Reflection should focus on what Argyris calls “double loop learning”; this is where we identify, not relatively “simple skills”, such as the mastery of a new programming language, but the impact of what we have done on the assumptions, concepts and ideas we used to make decisions about our work. For example, a “reflective practitioner” would try to identify the characteristics of the problem that has been addressed, and consider whether assumptions or decisions about the relevant approach to solving that problem had been appropriate, in order to make a better decision in relation to problems that might be encountered in the future.

Writing the Project Report

Once you have gathered and organised enough material you can turn it into written prose. To write effectively requires sustained concentration over long periods of time. Even with the incremental authoring possibilities that word processing offers, writing is best done in long uninterrupted sessions. Most people find it difficult and tiring.

There are rules you can follow which may make the task easier and which will certainly improve the quality of your writing, but unfortunately there are rather a lot of these and in a guide of this size we can only offer a few pieces of general advice:

  • keep your potential readership in mind;
  • identify commonality;
  • use sections and subsections to structure your work and to provide appropriate breaks for the reader;
  • do not include “padding” - include only what is necessary to “tell the story” and justify your work;
  • follow appropriate academic and professional stylistic conventions. We recommend that you read journal papers relevant to the general area of your project, as well as project reports held in the library and online; this is a normal research activity.

The project report's structure does not necessarily dictate the order in which you write it. If you want you can start by writing the Introduction, then the Background section, and so on, but this is up to you. Some people start by writing the Introduction first which gives direction to writing the other sections, but others prefer to leave writing the Introduction until last, as reports rarely turn out as planned. We recommend that you start with the middle sections, then write the Introduction (guiding the reader to what they will find in the report), then the Conclusions (bringing the report together at the end) and Reflection, and finally the Abstract (summing up the entire report). However you tackle the writing up, we recommend that you:

  • write as you go along, rather than leaving all the writing until last (writing takes longer than you think, and is best done when the ideas remain fresh in your mind);
  • leave time for someone you trust to proof-read your work, and for you to correct errors (it is not your supervisor’s responsibility to correct your written English);
  • read your work out loud to yourself. There are many advantages to this, not least the realisation that if you run out of breath your sentences are probably too long. Mainly, however, if you read “silently”, you will tend to read what you meant to write, rather than what you have in fact written, and will run the risk of missing errors.

Potential Readership

Always keep your potential readers in mind and repeatedly review what you have written, putting yourself in their place. Look at the draft, sentence by sentence, and ask yourself: 'Will this make sense to the readers given their existing knowledge and what I have told them up to now?' You can consider the potential readership as

  • your academic supervisor,
  • your project moderator/internal examiner,
  • the external examiner (usually a computing professor from another university),
  • and quite possibly future students and others interested in the topic.

So, as noted earlier, do not explain things which are common knowledge to such readers.

Also, if your project report is of sufficient quality, your supervisor may consider submitting part of it to a journal for publication as a paper, in which case it may eventually be read by a substantial number of computing and other professionals.

Identifying Commonality

You can often both clarify text and reduce its bulk if you can identify generality or commonality among the ideas you are expressing. You can then revise the text so that the common factors are described first, followed by details of how specific individual ideas differ from them.

Sections and Subsections

The main body of the project report should be divided up into sections, along the lines suggested in Arranging Material and Structuring the Project Report or otherwise, as appropriate. Each section should, if necessary, be divided up into subsections, and so on recursively. Such nesting can be used to suggest some kind of hierarchical relationship between sections. This can become obscure though if the nesting gets to more than about three levels deep.

It is important that you start each section and subsection with a summary of the rest of the material in it, i.e. inform the reader of what you are about to tell them. This has the effect of “softening up” the reader so that when they move on to the body of the section they feel confident about the direction in which you are taking them. They are reassured at regular intervals when they encounter ideas that you have told them to expect. Without the overview the overall effect is like a mystery tour of ideas, with each new idea coming as a surprise. It is sometimes difficult to appreciate the need for this when you are the author because you are already intimately familiar with the whole route that the report takes.

Each major section should begin on a new page. All sections and subsections should be numbered and headed. Numbering should be like this: 3.10.7 – for subsubsection 7 in subsection 10, in section 3.

Stylistic Conventions

There are all kinds of stylistic conventions relating to technical writing that you should try to follow. For example:

  • do not use shortened forms such as “don't” for “do not”;
  • avoid colloquialisms and slang words;
  • use British English and write in complete sentences;
  • divide your writing up into paragraphs;
  • generally, you should write in the “third person”. The “first person” can be used, to avoid the report becoming stilted, though it is recommended that its use be limited; for example, it may be appropriate to use “I” when stating an opinion rather than the common “It is the author’s opinion…”.

Writing where the language style or typography, e.g. font or character size, change arbitrarily looks amateurish and can be very distracting for the reader. Use typography to support the content. Other places where consistency should be maintained include:

  • bullet points,
  • use of hyphens,
  • use of capitalisation,
  • technical terms,
  • abbreviations,
  • use of symbols.

To some extent you can use your own judgement about what conventions to follow. Whatever you do though, you must be consistent.

Using Descriptive Devices

Here we mention some well-established descriptive devices which you can use in your project report to improve its quality.

Cross-references

Cross-references are just references to other parts of the same document. For example,

This module contains procedures for operating on variables of type WINDOW (see Section 2.2).

Section numbers will change if sections are added or deleted. Good typesetting or word processing software provides suitable mechanisms to automatically number sections and create such references such that they will always refer to the intended section. Make sure you know how your chosen software does this and select the right software to make this simple. If you use software that does not support cross-references or uses an overly complicated system, it is a good idea to wait until the report is almost complete before putting in any cross-references.

Backward references to sections earlier in the project report can make explicit connections between parts of the document that may not be connected obviously. Forward references can be used, for example, to reassure the reader that you are not going to leave them stranded after you have introduced a new idea without explaining it. For example,

This procedure uses the Volestrangler algorithm (to be described in Section 4.3).

Note that too many forward references are probably an indication that the report could be organised better.

Footnotes

Many word processors have facilities for handling footnotes. By all means use them, in particular when you want to make a comment which is not strictly relevant or which would upset the flow of ideas in the text. If the comment is closely related to the text you may consider including it in parenthesis instead.

Lists

Traditionally, collections of items are listed within the text using the adverbs ‘firstly’, ‘secondly’, etc. Often, though, it is clearer to tabulate these items, particularly if there are many of them. The simplest way of doing this is to use a “bullet” list. Various examples of bullet lists appear on this wiki. Sometimes there is a need to nest one list inside another. To distinguish the two lists, the inner one can be indented and have a different symbol. Lists with more than one degree of nesting tend to appear confusing and therefore we do not generally recommend them.

Listed items can also be keyed using numbers, letters, or other labels. Bibliography entries are an example of keyed items (see References). However, keys should only be used when necessary.

Figures

A project report that uses figures (i.e. diagrams or other pictorial techniques such as tables) to illustrate ideas will probably be easier to digest than one that does not. We therefore recommend that you use figures wherever appropriate (If you have a graphical rather than a textual/verbal kind of mentality, a good way to write text is to express your ideas in diagrams first and then describe these textually).

Be careful though. When drawing diagrams try to keep to a standard graphical notation that has been introduced during your studies, or that you have seen published widely, and use it consistently. Computer Science, unlike most other professions, has few established conventions governing the use of diagrams and this means that diagrams can sometimes make ideas more obscure rather than clarifying them.

If you feel you have to invent your own notation, remember that the best ones are usually the most economical, i.e. they use only a few different kinds of symbols. Also, you must explain the precise meaning of your symbols in a key. A very common mistake is to use arrows to illustrate some kind of relationship between items without declaring what that relationship is.

Graphics editors (i.e. image processors) can be extremely useful, particularly if you have a great deal of drawing to do or if there is a lot if commonality among the drawings (because cut and paste operations can then be used with great effect). However, some artefacts are difficult to produce using standard software applications, and in such cases it is quite acceptable to present hand-drawn diagrams. To include these into your report you may use a scanner or even take a photograph (or multiple partial photographs that you merge afterwards) of the artefact and include it in your report as any other computer generated image (help from staff for this is available).

All figures should be labelled and captioned, for example,

Figure 3.10: Sub-System Architecture.

The label can then be used to refer to the diagram within the text, e.g.

See Figure 3.10.

All diagrams must be explicitly referred to somewhere within the text.

Similar to sections and subsections the labels may change if you insert additional figures or change the structure of the report. Again good typesetting software will support automatic label generation and keeping the references to the figures consistent (see Cross-references).

For some reports it may also be useful to distinguish between figures and tables and use separate labels for them (e.g. Figure 3.1 and Table 3.1 are two separate elements, sometimes also referred to as floats). Figures are diagrams, drawings, images, etc. while tables list information in a tabular layout, e.g. program running times for specific inputs.

Literal Text

It is important when writing about software systems to distinguish in the text between the ordinary natural language you are using and the program code or other literal text. If you are using a word processor which offers both proportionally spaced and fixed width character fonts then there is a straightforward way of doing this. Program code and other literal text can be written in a fixed width font such as “Courier New” while the natural language text can be written with a proportionally spaced font such as “Times New Roman”.

Other similar kinds of text, UNIX commands for example, can be treated in the same way. Some typesetting systems also offer to include “verbatim” text, which you can use to insert small code examples, examples of the output of a program, etc. They are also typeset in a fixed width font. Using a fixed width font means that the code appears in the document much as it would do on a console. If you only have fixed width characters available on your word processor then put program code etc. into italics or bold text.

Note that using more than a few different character fonts, styles or sizes can make text look very untidy. Generally we recommend to use, e.g., a serif font for the main text (or a sans-serif font, if you prefer), a fixed-width font for literal texts as above, and optionally one sans-serif font for headings and captions (this can also be the same font used for the main text). Emphasis can be indicated by italics (or slanted text) or for stronger emphasis use bold text. If you use more fonts you should have a very good reason for this to support the content.

Supporting Material

In Arranging Material and Structuring the Project Report we say that a project report consists of a main body plus other supporting material that surround and support the body. There are well established conventions governing the purpose and format of these supporting structures which we describe here. The structures include, in order of appearance in the project report:

  • the title page,
  • the abstract,
  • the acknowledgements,
  • a table of contents,
  • a table of figures.

Then comes the main body of the report, and this is followed possibly by:

  • a glossary,
  • a list of abbreviations,
  • one or more appendices,

and finally

  • the references and bibliography.

Each of the elements listed above should begin on a new page. All pages should be numbered, with page 1 being the first page of the Introduction. The pages preceding the Introduction should be given Roman numerals (i, ii, iii, iv, etc).

The Title Page

The title page should be the first page of the report and should normally include:

  • the title of the project report,
  • the name of the author,
  • the name of the project supervisor and moderator,
  • the qualification for which the project report is a part,
  • the name of the school and institution, e.g. School of Computer Science and Informatics, Cardiff University,
  • the date of completion of the project report.

The title itself should be short, yet should aim to describe the contents of the project report as accurately as possible.

The Abstract

This is a summary of the report. It must be less than 300 words long. It should give enough information to allow a potential reader to decide whether or not the report will be of interest to them. It should briefly describe the main ideas of the report, including the aims and conclusions. It should be both self-contained and self-explanatory, and it should not say anything not mentioned in the rest of the report (for this reason it is usually written last).

Acknowledgements

This optional section should be used to record indebtedness for the use of facilities or help from particular sources. You should mention any organisations or people who have helped you while you have been carrying out the project.

The Table of Contents and Table of Figures

The table of contents gives the reader a view of the detailed structure of the report, by giving section and subsection headings and associated pages.

If your project report contains many figures or it refers to the same figure many times you should consider listing them along with their page numbers in a table of figures.

The Glossary and Table of Abbreviations

If you use any abbreviations, obscure terms or esoteric acronyms in the project report then their meaning should be explained where they first occur. If you go on to use any of them extensively then it is helpful to list them all in a table at the end so that readers can quickly remind themselves of their meaning.

The Appendices

Appendices are where you present material which you want to include in the report, but which would seriously obstruct the flow of ideas if put anywhere in the main body. This could be extensive technical details or mathematical proofs, derivations of formulae, etc. required to support a point your are making in the report. Other documents you have written, such as user manuals, technical manuals or formal specifications should go here too.

Appendices should be headed by letters in alphabetical order, i.e. Appendix A, Appendix B, etc.

Our Main Recommendations

Here is a summary of our main recommendations for writing reports:

  • Record all relevant information generated by the project:
    • use a notebook,
    • keep a diary,
    • log debugging sessions.
  • Gather further material from publications or other external resources.
  • Organise the material into sections agreed with your supervisor,
    • e.g. “Background”, and so on.
  • Turn this material into written prose to form the project report's main body.
  • When writing the main body
    • keep your readership in mind;
    • identify commonality;
    • use sections and subsections;
    • follow stylistic conventions.
  • Where appropriate use
    • cross-references,
    • references,
    • figures and other descriptive devices.
  • Produce all required supporting structures according to convention, after completing the main body, and include this material in appendices to avoid disrupting the flow of your narrative.
  • For examples to follow, look at textbooks from reputable publishers, etc.
  • Discuss an outline of the project report with your supervisor before you begin to write up; this will help you to plan your project. However, we strongly recommend that you write up your work as much as possible as you carry out your project, rather than leaving the writing to last.

Typesetting Rules for Report Presentation

This is a list of general typesetting rules for the undergraduate final year project reports.

Length

Ensure you stick to the word limit assigned for the specific report, as stated in the module guidelines. The word count does not include the supporting structures, but only the contents of the main report sections, excluding front-matter, figures and tables, and appendices. There is no minimum length but it is mainly through the report that your project will be judged so the report should adequately reflect the work done in the project.

Font Size

Reports should be typeset in a 12pt font.

Line Spacing

Reports should have single line spacing (anything from 1.0 to 1.3 is fine). The report should be economical on paper. It should not, for example, contain excessive amounts of whitespace. Only the major sections need to begin on a new page.

Submission

Reports should be typeset with some word-processing system, e.g. LaTeX, LibreOffice or Word. The final project report should be presented as a PDF file with any other documentation in the appendices of the report. Artefacts produced for the project that are to be processed by other software such as a compiler or interpreter should be submitted as separate file(s). If files are submitted as an archive, it should be in zip format (other formats can be uploaded, but will be converted automatically into zip by PATS). Typically this will be the source code for software developed for the project. For details see the Submission Guide.

Sources of Further Guidance

The guides on this wiki are not complete. Textbooks usually demonstrate good technical writing especially if they are produced by a reputable publisher. They also provide illustrations of the use of descriptive devices, etc.

Below is a list of other books and Internet resources, specifically designed to assist in writing essays and reports.

Finally, there will be specific aspects of your project reports that only your supervisor can advise you on. It is important that you discuss an outline of the reports with your supervisor before you begin to write up.

Bibliography

Cardiff University, Writing at Postgraduate Taught Level [accessed March 2023].
Online writing tutorials for postgraduate taught students, but also relevant to undergraduate projects.

Creme, P, Lea, MR. Writing at University: A Guide for Students. 3rd edition. Open Unniversity Press, 2008.
Contains help for all aspects of writing while at university.

Duprė, L. Bugs in Writing: Guide to Debugging your Prose. 2nd edition. Addison-Welsey, 1998.
Contains tips in small, individual chapters to improve your writing; a good reference book.

Fry, R. Improve Your Writing. 5th edition. Delmar Cengage Learning, 2004.
This is a guide for students producing a written project. Easy to read, full of handy hints, and guides you through the whole process from carrying out research for your report through to producing the final draft.

Strunk Jr, W, White, EB. The Elements of Style. WP Humphrey, Ithaca, NY, 1918. https://www.crockford.com/style.html [accessed March 2023].
Excellent guide to good use of English, a classic reference book, meanwhile updated and republished many times.

Zobel, J. Writing for Computer Science. Springer, 2014. https://link.springer.com/book/10.1007/978-1-4471-6639-9.
Extensive guide on writing and presentations, specifically aimed at computer science work.

Software

Document Foundation, The. LibreOffice Documentation. http://www.libreoffice.org/get-help/documentation/ [accessed March 2023].

LaTeX Project Team. LaTeX - A document preparation system. http://www.latex-project.org/ [accessed March 2023].

Oracle. The OpenOffice.org Documentation Project. http://documentation.openoffice.org/ [accessed March 2023].

Overleaf. https://www.overleaf.com [accessed March 2023]. (subscription available via your Cardiff Uni e-mail/account)

Word MVPs. The Word MVP Site. http://word.mvps.org/ [accessed March 2023].

Submission Guide

This explains how to submit the deliverables for your final year project. For what to submit, check the relevant deliverable section for your project module.

All deliverables must be submitted via PATS, except for physical artefacts. Some larger datasets, videos or similar that are only for general support or context may be provided elsewhere. All submissions must contain at least one PDF file in the document files section, or PATS will not allow you to complete the submission.

Submission generally consists of two main steps: (i) upload and check all files for the submission; (ii) complete submission by clicking the “Complete Submission” button. Do not forget step (ii). You can submit as many times as you wish before the deadline (as long as PATS lets you submit), but only the last submission archive is marked, and at most, the last two submissions are kept (if you do not delete them). Any files left in the submission area are not marked, and it is best not to leave any to avoid confusion. You can keep the submission files in the submission area and keep updating them and only perform the second step once you are sure all files are complete.

After completing step (ii), we suggest downloading and checking the contents of your submission archive. In particular, the files in the PDF section are merged into a single PDF file, protected/encrypted to avoid modification and completed with any missing fonts as far as possible. During upload, PATS provides tools to check the contents of the files and also merge the files. You may want to check the resulting submitted PDF files for any issues which can, for instance, be caused by missing fonts in the original files (this means that even the original files may also not show up correctly on your markers PDF viewers). We are trying to create an archival PDF format (PDF/A) from what you submit to minimise any issues with viewing later on as much as possible.

In a submission on PATS, we usually expect a report with sufficient evidence to back up your claims such that they can be verified and reproduced in principle. Often the report with sources is adequate for this. Sometimes you may have some extra data files, videos or images for demonstrations. You only have to submit files you created yourself. No need to submit any files automatically created, such as compiled object files or binaries. There is also no need to submit files from a framework or development suite or otherwise obtained assets you are using (these can easily be referenced - they do not have to be freely available). Some extra data files may be useful to document computational and analysis results, etc. We do not have to be able to execute your code from what is submitted, as it only serves as evidence of what you have done.

File Submission

For each deliverable, PATS has two sections to submit files:

  • Document files: These must be PDF files, and each submission must have at least one of these files - this section is for the written report, including any appendices. See the PDF Guide for information on creating PDF files.
  • Support files: These are any additional files you wish to submit for your project. They are not part of the main report but form supplementary material or extended appendices. Often these are archives (we try to convert some of them to zip files for compatibility) containing code, data or computational/experimental results. Generally, uploading files here is optional, but check what you should provide with the main report carefully. For final reports, in most cases, we expect to see at least the code. Usually, we do not require any binary files generated from sources, etc.

What is suitable to submit often depends on your project and your report. Please discuss with your supervisor what you should include if you are unsure. Your supervisor and moderator can see any of the files you have in the submission area and your current and previous submission archive.

To add files to these sections, press one of the related upload buttons, which opens a separate file selection dialogue. You have a choice to use the resumable upload function, which allows you to continue interrupted uploads, but may not work with all browsers and is particularly suitable for larger files. Instead, you can use the standard direct upload, which should work with all browsers, but cannot be resumed. Once you have uploaded a file, you can view its type, file size, and checksums (to check if your upload was successful). You can further rename, delete and move the file up or down in the list in each section. You cannot move files between sections.

For the files in the document section, you can check if there could be potential issues with the PDF files. You can also combine all files in this section into a single file (PATS will do this automatically upon submission completion).

After you have uploaded at least one file to the document files section, you can complete the submission. This will generate a zip file containing all the files you have uploaded in all sections, sorted by these sections, and in order they are displayed in the submission area. The document files will be combined into a single PDF file. Your files count as submitted only after you have completed the submission. While files in the content area are visible to your supervisor and moderator, they do not count as submitted nor serve as extensions to the submission; they will be ignored.

You can resubmit at any time before the deadline (all deadlines are by 23:00 on the day shown). A resubmission will completely replace the previously submitted files and not extend the previous submission, so always upload all files into the submission area and then submit them all at once by completing the submission. You can delete the archive at any time before the deadline and also download the archive to verify its contents.

Make sure you check the contents of any files you upload in the file submission area and especially the contents of the final submission archive. Files uploaded via the network may sometimes be corrupted, and downloading them again to verify their content avoids any problems. To verify the files, you may also use the checksums. See Checksums for further information. (Some PDF files and archives are modified for compatibility and so the checksums are not the same as your local files).

Physical Artefacts

Some projects may also produce physical artefacts without any digital versions of them. Hardware or similar physical objects need not be submitted but should be suitably demonstrated via videos, images or similar material showing their function. Your report should contain sufficient information to rebuild these. Any physical documentation necessary for your project should, however, be included in the archive in a digitised format.

Anything that fits on an A4 page or smaller can be scanned and directly included in the report as a figure. For documents larger than A4, we recommend taking photos and submitting the image files via PATS. If a single photo is insufficient due to resolution limitations, you can take multiple overlapping photos of the document and combine these into a single image.

If you have any problems with this, discuss them with your supervisors and potentially with our IT Service Desk.

Extremely Large Files/Archives

We have no strict file size limitations for the submissions. But some projects may produce or use massive data sets (say >50GB) that are unsuitable for submission on PATS for various reasons. We recommend discussing with your supervisor what to do with these and if they are needed. Often it may be more suitable to submit them to a public file sharing/archiving site than keeping them on PATS and reference them from your report instead. In some cases, they may also not be required.

You may make larger files/archives available outside of PATS if they are mainly supporting or optional data. These should be clearly referenced in the report. Make sure your supervisor and moderator can view these files and provide share links as references in the report so that other examiners (e.g. third markers, external examiners) are able to access them. Ideally, of course, they would be provided via publicly accessible storage without any restrictions.

Submission Problems and Peace of Mind

After you complete the submission of your files on PATS, your deliverable counts as submitted, and you do not have to do anything else. You can verify your submission yourself by checking the provided submission archive. We do not expect any problems with the network connection, the server or the integrity of your submitted file. However, to avoid any problems with the integrity of your submission and to deal with any problems arising from the server, Internet connections or anything else that prevents you from submitting the project in time, please follow these instructions:

  • Put all the files you wish to submit into some archive file (similar to the submission archive generated by PATS).
  • Upload the archive on a private online file share, such as your onedrive linked to your university account (this is the best option, if possible), google drive, dropbox, etc. It is important that you cannot change the timestamp of this file yourself on the file-sharing site.
  • Keep this file unmodified with a verifiable timestamp on the site (at least until you get your mark returned). As the timestamp can serve as a verification that you created the file before the deadline, you can later share this with your supervisor, moderator and project coordinator if there is a problem with your submission.
  • If, for some reason, you cannot upload your files onto PATS, you can also share this file immediately (before the deadline) with the project coordinator, who will fix and complete your submission on PATS. Also, send an e-mail to the project coordinator with more information about the project, what happened, etc., so they can properly set up your project files on PATS.

Generally, sharing files with the project coordinator before the deadline works well to resolve any issues. But note that it may take some time until we can get back to you to sort out the problem.

If, for some reason, you are unable to submit your files online anywhere, there is a further offline alternative to this process as a last resort:

  • Put all the files you wish to submit into some archive file (similar to the submission archive generated by PATS). Store this somewhere safe so you can produce this file in person or later on via some file-sharing mechanism online from that storage. Ensure the file is not modified (in particular, after you created the checksum).
  • Create a checksum of this file (see Checksums) and send this checksum to your supervisor, moderator or project coordinator. It must arrive before the deadline. It can be sent by e-mail or given in person with your full name and student id. You can also give this to someone at the COMSC office. Tell them to forward this to the project coordinator. Note that it may be hard to reach anyone in person, so this does not work as a last-minute option (e-mailing the checksum before the deadline would, of course, work).
  • The project coordinator will then be in touch to arrange to receive the actual file from you and get the data onto PATS. The file must have precisely the checksum you submitted before the deadline, or it cannot be accepted.

So far, we have never had to use this approach.

You can use any file type as long as they are suitable in the support file section. However, in general, we recommend the following file formats unless there is a good reason for your project to use a different format:

  • Documents: Whenever possible, use PDF. Note the main report must be in PDF format in the document files section.
  • Sources: Sources, interpreted files, HTML files, etc., should usually be plain text files encoded in ASCII, UTF-8 or ISO 8859-1 (latin1). Other standard text encodings may be used if necessary.
  • Jupyter, matlab, etc. notebooks: consider if these are really suitable for the purpose (e.g. PDF files generated from them may be more suitable for showing analysis results) and make sure you submit them completely, including any separate data needed. They may not be viewable by your markers in any case, so are best treated as optional files for completeness/evidence of your work only.
  • Images: The JPEG or PNG formats are preferred for compatibility. An image quality of 90% is usually sufficient for JPEG.
  • Video: Use MP4, MKV or WEBM container formats. The H.264/AVC and AV1 codecs are preferred for compatibility and quality. Usually the resolution does not have to be greater than 1080p (1920×1080); 720p (1280×720 pixels) is often sufficient; 1440p (1920×1440) or larger only if high resolution is needed. Large videos may be hosted outside of PATS (e.g. on panopto), but make sure they are accessible with the information provided in the report and are not just available to your supervisor and moderator (see extremely large files above).
  • Audio: Use OGG or MP3 for lossy compression or FLAC for lossless compression. For MP3, a sampling rate of 32kbps is sufficient for voice and analogue tape recordings, 128 to 192kbps should be used for CD quality and 192 to 320kbps should be used for complex audio sources (containing a broad spectrum of frequencies). For OGG, a quality 0 is sufficient for voice, quality 6 should give you roughly good CD quality, and higher qualities (up to 10) should be used for complex audio sources only.

PDF Generation Guide

This section describes how to prepare PDF files for submission on PATS. Independent of the program you are using to write the document and create the PDF file, the PDF file must fulfil the following conditions:

  • It must be compatible with Acrobat 5, PDF version 1.4.
  • All typefaces used in your document must be embedded in the PDF file, except for the standard PDF fonts. Embedding the standard PDF fonts is optional. The 14 standard PDF fonts are Times–Roman, Times–Bold, Times–Italic, Times–oldItalic, Helvetica, Helvetica–Bold, Helvetica–Oblique, Helvetica–BoldOblique, Courier, Courier–Bold, Courier–Oblique, Courier–BoldOblique, Symbol, ZapfDingbats.
  • The PDF file must not contain any malicious software. In general, there is no need to embed any scripts at all.
  • Do not encrypt or password-protect the PDF file. PATS will not be able to process this and has its own functions to check, protect and create as close to an archival PDF/A version of the report file as possible.

We also recommend you turn off any additional image compression during the PDF generation to preserve the original image quality. Furthermore, the PDF file should be generated for 300dpi or higher (print or prepress settings are ok). Screen resolutions, etc., may be of insufficient quality to easily read or print your documents.

The method you choose to create your PDF file is up to you, of course. However, there are several methods that most people use, as described below. Following these methods will ensure your document fulfils the above conditions.

Once you created the PDF file, you are highly advised to carefully proofread the resulting PDF file using acroread, available at http://get.adobe.com/reader/ - other software may or may not provide a reliable check, even if quite often they do not cause any problems. In particular, check that the contents displayed by the PDF file do not differ from the contents of the original file in any significant way.

TeX and LaTeX

If you are using TeX or LaTeX, there are two basic options to create a PDF file: directly generate the PDF file with PDFTeX / PDFLaTeX or create the PDF file from a DVI file. For special TeX frontends and implementations for various platforms, commercial versions, etc., you should refer to the documentation of these programs.

PDFTeX and PDFLaTeX

We recommend using PDFTeX / PDFLaTeX directly by calling pdflatex or pdftex command to create a PDF file, which by now is mostly the standard for LaTex/TeX. Note that minor differences exist between these commands and the original LaTeX or TeX commands, which produce DVI files. To avoid problems, choose the version you use before writing the complete document.

TeX and LaTeX with DVI files

The standard version of TeX and LaTeX produce DVI files. To generate acceptable PDF files from these, first convert the DVI file to PostScript with the following command:

dvips -Ppdf -G0 -t a4 -o FILE.ps FILE.dvi

Then you should run the ps2pdf program to create the PDF file from the PostScript file:

ps2pdf  -dPDFSETTINGS=/prepress \
        -dCompatibilityLevel=1.4 \
        -dAutoFilterColorImages=false \
        -dAutoFilterGrayImages=false \
        -dColorImageFilter=/FlateEncode \
        -dGrayImageFilter=/FlateEncode \
        -dMonoImageFilter=/FlateEncode \
        -dDownsampleColorImages=false \
        -dDownsampleGrayImages=false \
         FILE.ps FILE.pdf

This command also works for postscript files generated in different ways.

LibreOffice / OpenOffice

If you are using LibreOffice or any of its variants to write your report, export the file in PDF format using the File → Export As PDF menu. Under the options window, you do not need to select any special options. But make sure you turn off JPEG compression by selecting lossless compression to avoid image quality problems, and we also do not recommend reducing the image resolution.

Microsoft Word

Newer Word programs offer the option to save the file as a PDF under the save menu point. You may have to install a separate option for this to work. In general, this may be the best option to generate a PDF. Make sure you turn off image compression and select at least 300dpi resolution.

If this option does not work for you, there are various more or less free programs and services to convert word files to PDF. They should be easy to find, but we do not recommend any specific ones.

File Checksums

A checksum (or hash) is a datum computed from digital data to verify the integrity of that data. Typically you use a program to calculate the checksum of a file. Then after this file has been transmitted to another location, the same checksum algorithm is used to compute the checksum there. If the two checksums are the same, it is unlikely that the data has been changed during transmission or in other ways.

You should use SHA2 checksums, specifically sha512 (to keep things simple), in case of submission problems, etc., as described in the Submission Guide. Alternatively, you can also use SHA3 or an OpenPGP file signature with your key published to the OpenPGP key servers. For other checksums, please first check with the project coordinator.

PATS at some places still uses MD5 or SHA1 checksums due to legacy reasons. These can be used to verify that there were no accidental transmission errors but are otherwise deprecated. They cannot be used to verify that offline archives have been transmitted before the deadline as they are cryptographically broken. Note that PATS modifies some files after submission (files in the document section are specially processed and changed, and some archive files are converted to zip for compatibility).

Creating SHA2 Checksums

  • Linux shell commands: shasum, openssl, sha512sum
  • Mac OS terminal commands: shasum, openssl
  • Windows command prompt: certUtil

Creating SHA1 Checksums (deprecated)

  • Linux shell commands: sha1sum, openssl
  • Max OS terminal commands: openssl
  • Windows command prompt: certUtil

Creating MD5 Checksums (deprecated)

  • Linux shell commands: md5sum
  • Mac OS terminal commands: md5
  • Windows command prompt: certUtil
cm3203_guide.1526389886.txt.gz · Last modified: 2018/05/15 14:11 by scmfcl