The following is a general template for a project report under my supervision (and software based). This is not necessarily the structure other members of staff would recommend but it works for me!

First of all, don't bother with the abstract, introduction, and conclusions - they are the last things you write. Next, if you have a lot of code (being supervised by me probably means "yes") then put it on GitHub (or equivalent) as a private repository and include a link to that. Don't fill up appendices with lots of code listings - think of the trees.

So, here is the outline:

  • Title
  • Disclaimer (stating your own work etc. - usual plagarism requirements)
  • Abstract
  • Acknowledgements (optional)
  • Contents
  • Chapter 1 - Introduction
    • State the problem you are trying to solve
    • Why is it worth tackling?
    • What approaches are available (briefly)?
    • What approach have you choosen?
    • Any special knowledge you presume of the reader
    • Any special typography or terms
    • A "road map" of the report..... "In Chapter Two we describe xxxx. In Chapter Three we describe yyyy..."
  • Chapter 2 - Background
    • Any information the reader requires in terms of techniques/technology that isn't part of the programme you have studied.
      Please note: if you are submitting an MSc project report then this should not contain the material from the proposal - one cannot get credit twice for the same piece of work.
  • Chapter 3 - Analysis, Requirements, and Design
    • What it says on the title
    • Should include appropriate formal design diagrams/notation as necessary
  • Chapter 4 - Implementation
    • Describe how the implementation maps onto the design you have already discussed.
    • You should use "code snippets" to illustrate special features of your work or difficult (awkward) bits of coding. Don't make any of these snippets longer than half a page (and include line numbers if possible). If the code fragment is longer than half a page then break it up into smaller bits.
    • Describe the code, both in terms of the overall architecture and in terms of the snippets. Make sure the reader understands what you have done and why!
  • Chapter 5 - Experimentation & Evaluation
    • Again, what it says on the tin!
    • If you haven't done too much testing (for instance it is GUI based) then include a "walk-through" of the application with screenshots showing the scenarios in which the application can be used. After all, the examiners may not be near a computer to actually "run" your code.
    • You also need to clearly show how you have evaluated your work and show how it meets the original aims and objectives.
  • Chapter 6 - Conclusions
    • Restate the problem.
    • Say how successful (or not) you have been in solving/tackling the problem.
    • What would you have done differently?
    • What have you learnt?
    • Basically, "reflect" on the work you have done.
    • What additional features/extensions can be done to the work and/or what would you have done if you had more time.
  • Appendices
    • Include design diagrams, data formats, etc.
    • Basically, don't overfill the report.
    • Link to the GitHub repository (if appropriate).

Now, "one size does not fit all" - this structure is meant to be a starting point; you may have more, or less, chapters. You may need a background chapter, you might not, etc. Be flexible and check with me about what you are writing.

I prefer to see the report a chapter at a time (or even just a few pages at the start). A whole report sent to me to read at the end, with no chapters submitted prior to that, is a recipe for problems. It really doesn't give me any time to say, "No, change the style", or "No, I suggest you do it this way".