Project Report Contents

The dissertation is an extremely important part of the project. It serves to show what you have achieved and should demonstrate that:

 

Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is definitely not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get the balance right you should consider that the aim of the project is to produce a good dissertation and that software, hardware, theory etc. that you develop during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document.

The physical layout and formatting of the report is also important, and yet is very often neglected. A tidy, well laid out and consistently formatted document makes for easier reading and is suggestive of a careful and professional attitude towards its preparation.

Remember that quantity does not automatically guarantee quality. A 150 page dissertation is not twice as good as a 75-page one, nor a 10,000 line implementation twice as good as a 5,000 line one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in programming, and will be rewarded appropriately. Also, it is important to appreciate that the appropriate size and structure of a dissertation can vary significantly from one project to the next. Despite these variations, however, most good dissertations have the following components in common:

Title page
This has the standard form described in the submission information.
Abstract
The abstract is a very brief summary of the dissertation's contents. It should be about half a page long. Somebody unfamiliar with your project should have a good idea of what it is about having read the abstract alone and will know whether it will be of interest to them.
Acknowledgements
It is usual to thank those individuals who have provided particularly useful assistance, technical or otherwise, during your project. Your supervisor will obviously be pleased to be acknowledged as he or she will have invested quite a lot of time overseeing your progress.
Contents page
This should list the main chapters and (sub)sections of your dissertation. Choose self-explanatory chapter and section titles and use double spacing for clarity. If possible you should include page numbers indicating where each chapter/section begins. Try to avoid too many levels of subheading. Try if possible to stick to sections and subsections; sub-subsections are usually avoidable.
Introduction
This is one of the most important components of the dissertation. It should begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by the reader. It should summarise everything you set out to achieve, provide a clear summary of the project's background and relevance to other work and give pointers to the remaining sections of the dissertation which contain the bulk of the technical material.
Background
The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of approaching a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The background section is often included as part of the introduction but can be a separate chapter if the project involved an extensive amount of research. The published work may be in the form of research papers, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Don't be afraid to acknowledge the sources of your inspiration; you are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest; in other words you are cheating. When referring to other pieces of work, cite the sources at the point they are referred to or used, rather than just listing them at the end. The University of London takes a very strict line on plagiarism, and their standard notice on the subject is given in the Appendix. Please read it.
Body of report
The central part of the report usually consists of three of four chapters detailing the technical work undertaken during the project. The structure of these chapters is highly project dependent. Usually they reflect the chronological development of the project, e.g. design, implementation, experimentation, optimisation, although this is not always the best approach. However you choose to structure this part of the report, you should make it clear how you arrived at your chosen approach in preference to the other alternatives documented in the background. For implementation projects you should describe and justify the design of your program at some high level, for example by using any of the design methods taught during the first and second term courses, and should document any interesting problems with, or features of, your implementation. Integration and testing are also important to describe. Your supervisor will advise you on the most suitable structure for these middle sections.
Conclusions and Future Work
All good projects conclude with an objective evaluation of the project's successes and failures and suggestions for future work which can take the project further. It is important to understand that there is no such thing as a perfect project. Even the very best pieces of work have their limitations and you are expected to provide a proper critical appraisal of what you have done. Your assessors are bound to spot the limitations of your work and you are expected to be able to do the same.
Bibliography
This consists of a list of all the books, articles, manuals etc. used in the project and referred to in the report. You should provide enough information to allow the reader to find the source. You should give the full title and author and should state where it is published, including full issue number and date, and page numbers where necessary. In the case of a text book you should quote the name of the publisher as well as the author(s).
Appendix
The appendices contain information which is peripheral to the main body of the report. Information typically included are things like program listings, tables, proofs, graphs or any other material which would break up the theme of the text if it appeared in situ. Large program listings are rarely required, and should be compressed as much as possible, e.g. by printing in multiple columns and by using small font sizes, omitting inessential code etc.
User Guide
For projects which result in a new piece of software you should provide a proper user guide providing easily understood instructions on how to use it. A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your package. Technical details of how the package works are rarely required. Keep it concise and simple. The extensive use of diagrams illustrating the package in action prove particularly helpful. The user guide is sometimes included as a chapter in the main body of the report, but is often better as an appendix to the main report.