COMP3000 Computing Project 2021/2022

Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

COMP3000

Computing Project

2021/2022

1 Report Structure

This document is to provide support and guidance for writing your report. It is provided as guidance not as an indication of essential content. You must reflect and consider whether this guidance fits with your project. Only you can make that decision.

Please also carefully read the COMP3000 Assignment Brief which provides the essential criteria relating to the content of your final report.  You must conform to the expectations outlined by the COMP3000 Assignment Brief whereas what is provided here is optional for you.  

You can use this document as an MS Word template

The report documents your project’s products and the processes that supported their development. It will normally conform to the following structure:

· Start of the report

· Main Body of the report

· Appendices

Each of these sections are discussed in detail in the remainder of this document.

1.1 Start of the Report 

The start of your report should also include the following documents, in this order:

· Front Cover

o The first page should always be the front cover.

o Please use the template at the start of this document to generate your front cover.

· Acknowledgements

· Abstract

o See section 1.1.1 for more details

· Table of Contents

o Note that If you use the styles in word (Heading 1, Heading 2 etc.), MS Word will generate a contents page for you.

· Word Count

o See section 1.1.2 for more details

· Code Link

o A link to your code repo should be placed immediately after your word count

1.1.1 Writing your abstract\introduction

The abstract and the introduction should both be self-contained; they should be able to stand-alone as independent documents. Therefore, you will undoubtedly find yourself repeating some of the material from your abstract in your introduction (don’t worry about this).

Think carefully about your reader:  they know nothing about your project, so don’t dive straight into the details. In general terms think about

· Who is the client (if you have one)

· What are their needs/objectives?   

· What are your primary objectives of the project? How do these relate to the objectives of the client? This is not intended to be your definitive, precise statement of needs and objectives: you can give these in a subsequent chapter.

Note that project scope relates to both what you will do and what you will produce; so you’ll have some objectives based upon what you will do (for example; carry out requirements elicitation) as well as what you will produce.

NOTE: Your abstract IS included in your word count.

1.1.2 The word count

· The Table of Contents, Reference List, Bibliography and the Appendices are not included in your word count.

· Everything else – absolutely everything else - is included in your word count.  Headings count as everything else!

· You should include a statement of your word count immediately after your table of contents.

· Your word count must be ≤ 10000.   Standard university rules apply to allow for +/- 10%.

· Informally we suggest that your word count should be no lower than 7000.

· Do not agonise over your word count.  The word count is a just one of many indicators for quality.  We know that generally a good report will come in at around 10,000 words.  Much more over that amount usually indicates that the student has not applied rational thought to how they are communicating and are probably including things “just in case”.  Go back over what you have said and question yourself – could you express this in a more concise manner.  Does what I am saying here really add to the reader’s understanding?  If you have much lower than 7,000 this usually indicates that you have not given enough depth of thought to all the aspects of the software development lifecycle and the majority of reports at this level have indicated a failing project.

1.2 Main body of the report

The main body of your report should include the following sections:

· Introduction

o See section 1.1.1 for more details

· Chapters

· End-project report (and Recommendations, if applicable)

o See section 1.2.2 for more details

· Reflections

o See section 1.2.3 for more details

· Conclusions

o These are the final, brief, summarising conclusions of the project

· References/Bibliography

o Please note that, whilst we do not demand the use of any particular referencing style, we do expect to see a properly formatted reference list: Please refer to the essay writing guide on the DLE for guidance if necessary.

o Needless to say we also expect to see appropriate citations (in the report’s main body) to the articles in your reference list.  

1.2.1 See this example 

The variety of projects precludes a definitive statement on the content of a project report, but here’s one suggestion for the main body:

· Introduction

· Background, objectives & deliverables

· Literature review (if applicable.  Most usually found in a research project)

· Method of approach (or Methodology if a research project)

· Legal, social, ethical and professional issues

· Project management

· End-project report

· Project reflections

· Conclusions

· Reference list and bibliography

These are only suggestions and the contents of your particular report should be discussed with your supervisor.

1.2.2 About reflection

In relation to both the end-Project report and the reflections, student reflection sometimes tends to be too shallow. Therefore, before attempting some reflective writing, you should undertake some reflective thinking. Take time to consider the intended purpose and benefits of ‘the core aspects of the project’ under consideration and the choices you made in relation to it.

In relation to each of the core aspects of the project, ask yourself:

· What went well and what went badly?  

· Why was this the case?  

· To what extent was the aspect under consideration responsible (vs. other contributing factors, e.g., your own performance).

· Was your experience in line with what might have been expected given the body of knowledge within the literature?

· To what extent does the above cause you to reconsider the choices that you made in relation to the given aspect?

1.2.3 End-project report 

An end-project report is produced (say for a Project Board or Client) as part of (and towards the end of) a project. It is a brief summary of the project and its achievements. Therefore, you should relist your project’s objectives and critically (and ruthlessly) evaluate whether you met the objectives.

Note that projects rarely go perfectly, and an inability to find any real criticism will possibly be met with some suspicion. If your work is for a real client, try to involve them in this evaluation (and include details of their feedback).

· Describe the realisation of business objectives (either to-date or planned).

· Describe changes made during the project, their reasons and effects.

1.2.4 The reflection

A reflection is often carried out shortly after a project is over. Here you critically evaluate aspects of the project (although you do not need to repeat any evaluations that were made as part of the project/end-project report). Aspects considered might include Business objectives, Project objectives, Product specification, Client interaction, Development process, Project management approach, Technologies, and your own performance.  You should have an action plan to indicate how you would change things going forward.

1.3 Appendices

The appropriate use of appendices is important. Please do not use the appendices as a dumping ground for miscellaneous material. The thickness of the final report is not indicative of the mark it will be awarded. Note that the reader may not read your appendices. Thus, you must make sure that the main body of the report is a self-contained description of your project (at least at some level of abstraction). If the reader ‘needs’ to read something in order to understand your project, then at the very least put a summary of the material in the main body.

1.3.1 Suggested Appendices

The quality of presentation in the appendices should be as good as in the main body.

Please add the following Appendices to your report if they are appropriate, in this order.

· Appendix 1: User Guide

o NOTE: The User Guide is only required for software development projects that have not been hosted somewhere.

o As a minimum this should indicate how the product can be installed for demonstration, including details of the (minimum) required platform specification.

o If necessary, there may also be information on how the system can be used or operated.

· Appendix 2: Project management

o Planner boards showing sprints

o Requirements, plans and sprint reviews

o Exception reports/plans

1.3.2 Typical Use of Appendices

All appendices must be referenced/cited in the main body of the report so that the reader is directed to them as appropriate.

· Use an appendix when materials you need to include are too voluminous or detailed to put in the main body, even though they may be important to the reader’s understanding. Put a summary in the main body, and the full text in an appendix.

o For example the reader does not want to read pages of test results. Instead, put a summary of the testing processes and results in the main body. Then add the details of the test results in an appendix.

· Use an appendix when you want to include materials that relate to the wider context; particularly if it is voluminous

o For example your choice of software development process. You may write a chapter discussing the pros and cons of the different processes available, but this again relates to the wider context. It is not final stage work. Therefore, put it in an appendix. Then in the main body briefly state the options and then describe/justify your chosen process.

o This also applies to discussions relating to your choice of technologies.

· Use an appendix when the material you want to include is too low level for the report, it should be put in an appendix.

o For example the details of your DB normalisation would normally be in an appendix, with the final schema presented (perhaps as an ERD/LDS) in the main body of the report.

· Use an appendix when you want to include earlier versions of system designs.

o For example initial screen shots, even ones drawn by hand. These can be useful in your description of your process.

1.4 Overview of the Report

Front Cover

Acknowledgements

Abstract

Table of Contents

Word Count

Code Link

Introduction

Chapters

End-project report

Post-mortem

Conclusions

References/Bibliography

Appendices 

2 General advice

Most importantly of all, allow yourself plenty of time to write your report and then allow 50% extra on top of that. Polish, polish, polish and then polish some more. The quality is important. Don’t hand in the first draft (or even the tenth!). Many first/second/third drafts are often dreadful.      

Avoid leaving all the report writing to the end. Aim to write up as you proceed.

2.1 Descriptions

Describe your work at a suitable level. The standard advice is that it should be written at a level that could be read by a (good) final stage student. The best reports display author maturity, and demand it from their reader.      

Please put some screen shots in your main body; but too many can be tedious.

You can gain credit for what you did as well as what you produced. The report should therefore describe both your deliverables and the processes by which they were created. Especially consider the activities you carried out that are not obviously visible from the final product.

For example, consider requirements elicitation

· Which methods did you use? Show the reader that you are aware of recognised techniques rather than making it up as you go along:

· Why did you choose them? Describe their enactment and record their findings.

· What particular problems/challenges did you encounter, and how did you solve them?   

· What parts of your work do you think are particularly worthy of credit: bring these out in your report.

Do not include significant chunks of code in your report … instead make the code available to us via your code link

2.2 Style

The report should be professionally presented and word processed with approximately 1.15 line spacing.

Pages should be numbered consecutively except for the title page. Please use the Arial font is a size of 12pt.

Sections and sub-sections should employ nested numbering. For example, Section 1, sub-sections 1.1, 1.2, and sub-sub-sections 1.1.1, 1.1.2. This is really important in helping the reader to follow the structure of your report.   

Use good grammar, and make sure that you understand the proper uses of punctuation symbols such as: comma, semi-colon, colon, and apostrophe. Avoid overly long sentences. In general, the meaning of your text gets lost when you go over 30 words.

Avoid unnecessary repetition.

Try to be formal in style; avoid slang and colloquial language. Avoid being conversational in style.

The standard academic style (to which you should conform) is past tense, third-person. Use passive forms when possible. For example, use ‘the software was tested’ rather than ‘I tested the software’. Try to avoid personal pronouns such as ‘I’, ‘me’, ‘my’, ‘we’, ‘you’, ‘he’, ‘she’ and try to avoid other personalisations such as ‘the author’, and ‘the student’. However do also use your common sense … otherwise following a given prescription when it becomes inappropriate can result in writing that feels artificial. Do use phrases such as ‘this project’, ‘the program’, ‘the respondents’ (and do use ‘it’ or ‘they’ to avoid excessive repetitions of these). Refer to yourself as ‘the author’; possibly followed by ‘I’ or ‘my’ when you are clearly stating your own personal opinion. This is primarily applicable to the reflection. 

2.3 Professional Considerations

These are very important matters to consider when writing up the work you have carried out for your final year project.

2.3.1 Ethical considerations

You should ensure that your report conforms to the University Ethics policy. For example, if the results of user-testing are included, then participants should not be identifiable.

2.3.2 Plagiarism and referencing

You should adhere to accepted norms regarding referencing, paraphrasing, and plagiarism. See Section 3.7 of the University guide to Essay Writing. Please note that we may submit project products (e.g., code, report) to plagiarism detection devices.

2.3.3 LSEP

Legal, social, ethical and professional issues are one of the core assessment categories. Therefore, we recommend that you write about 600 words within your final report on this issue.

3 Queries

If you have any queries about writing up your own report for your specific project, please email your project supervisor.