FYPR Structure Guide PDF

Final Year Project Report Chapter Guide the software used to run simulations is intended to be Front Matter................................................................ 1 of use to others. That is of...

Final Year Project Report Chapter Guide the software used to run simulations is intended to be Front Matter................................................................ 1 of use to others. That is often but not always the case. Acknowledgments........................................................ 1 Where linked material is distributed throughout the report it is very important to make explicit forward or Abstract........................................................................ 1 backward references to the relevant sections. This Introduction................................................................. 1 enables a reader to understand your argument Background.................................................................. 2 without the burden of repeated material. Requirements Capture................................................. 2 Analysis and Design...................................................... 2 Front Matter The first page of your report should be a standard Implementation........................................................... 3 format Cover Page. The second page should be the Testing.......................................................................... 3 mandatory Plagiarism Statement. Signature is not Results.......................................................................... 3 required – its presence will imply signature. Evaluation.................................................................... 4 Between the Abstract and the Introduction there will Conclusions and Further Work.................................... 4 normally be a Contents page (or more than one if required). User Guide................................................................... 4 Bibliography................................................................. 5 Acknowledgments Appendices................................................................... 5 This section is optional, but customary. This note covers in detail the normal report structure. You must also comply with previously taught guidelines on clear labelling of figures, graphs, use of Abstract tables instead of lists in text, plagiarism, etc. The abstract should (very concisely) summarise the topic, content and conclusions of the project. The advice given here will apply to many projects. Abstracts can vary in length from 50 words up to at However each project is unique, and you should most 200 words. They are more concise than without fail get advice from your supervisor about executive summaries. They do not need to be how to structure your report, and its content, well identical to any previously submitted abstract. Note before writing starts. that abstracts have no explicit marking in the final Where the advice given here and that of your report scheme, so keep them short and clear. supervisor differ, you should follow your supervisor's advice as they will be taking into account the individual nature of your project. Introduction The introduction should set the scene and give a high- Your report should, without fail, contain the sections level problem statement/specification, so that after specified in the Project Guide. In addition, the reading the introduction the reader understands structure and content of the internal chapters is roughly what the problem is and what you intend to typically as below. do about it. Is the idea to write software, or develop Some variation in structure is possible for the internal an algorithm, or produce hardware, or something Chapters, however omitting relevant content is not. else? For example, the project Evaluation Chapter could be You should then highlight and summarise the most a subsection of the Conclusions, or the Results. An interesting or important questions or problems that analytical project would not have a User Guide unless your project addresses, and the broader context in which those questions or problems are situated. TJWC Final Year Projects 1 Finally, you must briefly introduce the structure of use is investigated and a brief more detailed than the report (what you will cover in which chapters and how specification is constructed. This would include what these relate to each other). You don’t need to go into is necessary, what is desirable, etc in the final any detail, the aim is to make sure the reader has an deliverable. The results of requirements capture idea about what will be discussed and in what order. determine project objectives and are used to inform project evaluation. Background Requirements capture is important in all projects with real-world deliverables, and is often a significant You should provide enough background to the reader amount of work in software projects. Where for them to understand what the project is all about, requirements capture is less relevant (for example in and what is the relevant prior work. an analytical ‘research-style’ project) this may be Examiners like to know that you have done the replaced by a detailed description of the project aims appropriate background research and it is important and objectives in the Introduction or the Background that you review either what has been done previously sections. to tackle related problems, or perhaps what other products exist related to your deliverable. Clear references are important here, and much of this Analysis and Design section will typically already have been written in your If your project involves designing a system, give a Interim Report. You may use feedback from that good high-level overview of your design. report to improve what you write in your Final Report, In many projects, the final design is different from and should note that self-plagiarism between the two that originally envisaged. If the differences are reports is not possible, so no citation is needed of interesting, write about them, and why the changes your own earlier writing. were made. Discoveries during the project may have  What does the reader need to know in order changed the direction of work, or invalidated prior to understand the rest of the report? What work, in which case you get credit for the design problem are you solving? process, if it is principled, as well as the end product.  Why is this problem interesting or worthwhile If your design was not implemented fully, describe to solve? which parts you did implement, and which you didn't.  Who cares if you solve it? If the reason you didn't implement everything is  How does this relate to other work in this interesting (eg it turned out to be difficult for area? unexpected reasons), write about it.  What work does it build on? Note that the Project Report is written at the end of  For 'research-style' projects involving the project work and must describe the project work, but design and analysis of specific algorithms need not do this chronologically. Often the best there is a large amount of relevant description of design, in retrospect, is far from the background both of general theory, and very way in which you developed it. Where the evolution specific to the algorithm you investigate. of ideas is interesting or relevant it can be described, Supervisors will help you to see what is most as above, but otherwise the order in which things important here, but the general rule is that were done need not be documented. you must both provide overall context and note work close to what you do that The Examiners are just as interested in the influences your work or is in some way engineering process you went through in performing comparable to your work. your project work as the results you finally produced. So make sure your report identifies when design choices have to be made, what were the possibilities, Requirements Capture and why you made the particular choices and Projects with a deliverable that serves a specific decisions that you did. They are looking for principled function often have an initial phase in which expected rational arguments and for critical assessment. TJWC Final Year Projects 2 Engineering involves trade-offs and the reasons for a conveying your design than source code, whether that design decision may be various, and may in some is a data-structure, a client-server interaction, a cases be out of your control. Explicit understanding of design-flow, or a circuit hierarchy. For example, a this, and the ability to communicate it, is important. diagram of a block-diagram of digital circuit can be used to communicate to the reader most of the important high-level decisions you have made, then Implementation VHDL fragments (or another diagram) could be used In projects with a software element give code details to focus on specific parts and demonstrate any (not a complete listing, but descriptions of key parts). interesting local details. Discuss the most important or interesting aspects, and Complete listings may be included as appendices of anything that was surprising or difficult. It probably your report but this is not normally appropriate, won't be possible or relevant to discuss everything – unless the appendix is documentation, or describes an state clearly what you leave out. API. Software may be provided on a CD-ROM given to Pasting verbatim code from your project into the your supervisor or in a cloud repositories such as report is rarely a good idea; usually it should be edited Github. No marks are awarded for the mass or page- down to remove extraneous details and often count of a report, and reports which contain 50 pages annotated to help the reader understand what they of printed code are more likely to be seen as showing are looking at. Good reasons for including code could poor judgement. be to illustrate algorithmic flow, or highlight an interesting optimisation, demonstrate interactions with a data-structure, or give an example of input for Testing a tool that has been designed. If you cannot explain Describe your Test Plan -- how the program or system what message or point a code fragment is conveying, was verified. Put the actual test results in an Appendix it probably should not be in the report, and if you if they are repetitive but relevant. Detailed test data cannot justify why a line of code in the fragment helps may be omitted from the report if not relevant, convey that point, it maybe it shouldn’t be in the code however an accurate summary of tests should be fragment. included in the Report itself. Sometimes non-working designs are described in project reports as though For similar reasons, pasting screen-shots is unlikely to they work, when in reality they don’t, or only partially be a good use of space, unless it serves a particular work. Therefore a precise description of what works purpose. Screen-shots are sometimes used instead of and how this has been established is important. drawing a picture (for example as a “cheap” way of Examiners may try to compile, use, or test showing wave-forms or state machines), or in order to deliverables themselves (even after your report is capture the results of running a tool (which will often submitted), and your report should accurately reflect be text anyway), and tend to look unprofessional and the state of the project. lazy. They are also sometimes used as page filler, or as “proof” that a tool was launched and something This section is normally useful for software or compiled, which is not necessary: your marker’s hardware deliverables and less relevant in analytical default position will be to believe your claims. Use a projects. screen-shot if it is demonstrating a particular point, such as a failure mode in a tool, or a particular interaction that is difficult/impossible to highlight, but Results make sure you edit and annotate the figure to show This covers an area different from the 'Testing' and highlight the important parts. chapter, and relates to the understanding and analysis of the algorithm, program, or hardware behaviour. When discussing the implementation, it is generally Where the deliverable is a product with easily best to focus on the conceptual and logical design, quantified performance then the previous Chapter and only then dive into details for interesting parts or shows how functional correctness is established, to highlight important decisions. Well thought-out while this Chapter shows qualitatively or figures and diagrams are often much more effective at TJWC Final Year Projects 3 quantitatively how well the product works. The list between final and initial objectives should be below shows typical content, not all of this will be explained in a self-contained manner. applicable to all projects. Note that here you will reference and summarise,  An empirical relationship between rather than repeat, your description of Requirements parameters and results may be investigated, Capture earlier in the Final Report. typically through the use of appropriate graphs.  Where theory predicts aspects of Conclusions and Further Work performance the results can be compared How successful have you been? What have you with expectation and differences noted and (if achieved? How could the work be taken further given possible) explained. more time (perhaps by another student next year)? It  Semi-empirical models of behaviour may be is important here to identify positively what is developed, justified, and tested. worthwhile in your work. At the same time, honesty, and a clear description of the limits of your work, is  The types of experiments/simulations that equally important. It is often most appropriate to were carried out should be described. Why describe work you did not have time to complete as were certain experiments carried out but not further work. others? What were the important parameters in the simulation and how did they affect the Your readers will not be clear where, in your long results? If there are very many graphs and report, are your most significant achievements. In the tables associated with this chapter they may conclusions you must summarise this, referring as be put in the Appendix, but it is generally necessary to other sections for more detail. better to keep these close to the text they  What design choices did you have along the illustrate, as this is easier for the reader. way, and why did you make the choices you made? Evaluation  What was the most difficult and/or clever part This Chapter (or possibly section of the conclusions) is of the project? distinct from your results. It must contain your critical  Why was it difficult? evaluation of your work as compared to previous  How did you overcome the difficulties? analysis, algorithms, products, and when related to  Did you discover or invent anything novel? your original objectives. To what extent have your  What did you learn? original objectives been fulfilled? If they have Note that “difficult” does not necessarily mean the changed, what is your rationale for this? What are the thing that took you the longest amount of time. Note advantages, disadvantages of your approach also that the conclusions must concisely summarise compared with related work? How does the scope of this material, and refer to other sections for the your work differ from related work? Examiners expect details. your project report to show evidence of your ability to think as an engineer, and that includes the ability to critically reflect on your own work and evaluate its significance. User Guide Material here will compare project outcomes with When the deliverable is software or hardware initial objectives and requirements captured. Usually intended to be useful to others, this Chapter provides your Interim Report will contain these. Where these details on how to install/configure/use it. Otherwise it have changed significantly over the course of the can be omitted. project this should be explained and reasons given. This section should not require examiners to read your Interim Report, and will not reference it. Changes TJWC Final Year Projects 4 Bibliography concise summaries of the test data in a Give publication details for all the citations you have human readable form. made in the report. Internet URLs are allowed and in  Raw results. Tables of results in unreadable many cases necessary, however published material form should not be put in the main report, but should if possible be given in standard form with if needed may be put in an Appendix. publishing body, date, and author(s). Open URLs to  Related material possibly but not directly published material, where these exist, may also be relevant to the project work. E.g. manuals of given for a reader's convenience. test equipment used. (There is no requirement to include such, but in some Bibliographic format: the recommended format for cases, where they have some tangential simplicity (using latex and bibtex) is numeric, with relevance, it might be appropriate). hyperref allowing hyperlink references (which you will almost certainly need). For example: \usepackage[backend=biber,style=numeric, sortcites,sorting=nty,backref,natbib, hyperref]{biblatex} Exact blibliographic format is not mandated but uniformity across the cohort is helpful: let me know if you think the above does not work for you. Appendices Please use appendices as necessary for material that is tangentially relevant, or necessary to preserve project value, but that you do not expect Examiners to read. Note that software projects with significant code should normally provide electronic versions of the code on USB stick, CDROM, or cloud repository. In that case the Appendix should state where the code may be found. The Appendix should normally include, or refer to, all the technical details needed for another user to continue code development. Typical items that should not be in the main report, but should (possibly - since Appendices are not normally read this is a matter of judgement) be in appendices:  Source code. Note that code (if long) should also be available in some electronic form, e.g. a github repository, CD, or USB stick. Software projects must provide access to the source code in some form. The Appendix will then reference this.  Test data sets (again, for large volumes of data an electronic form would be more appropriate). The report itself will contain TJWC Final Year Projects 5