Writing a Project Report

This page contains some of the comments that I frequently make when reading students' reports.

Before you start

Before you start writing your thesis, you should make sure that you know what is expected from your thesis.

• I recommend that you look first at "Notes on Presenting Theses" by Aaron Sloman. I recommend reading the first three paragraphs of section 1 ("Introduction"), then sections 3.1, 4.1, 4.2, all of section 6, and then any other sections that are relevant.

• Read the Instructions on how to write the master thesis report on the departmental project pages.

• Read the advice on Thesis writing in the Student Portal.

• The Centre for Language and Communications has produced "Writing guidelines for reports, BSc theses, and MSc theses at Chalmers University of Technology".

• You should look at some previous theses to get an idea of what is expected. Many previous Master's theses are available in the Chalmers Library. For example:

  • Automatic bridge detection in airborne laser scanned data
  • The Identification of Target Proteins from Patents - Mining of biological entities from a full-text patent database
  • Investigating storage solutions for large data - A comparison of well performing and scalable data storage solutions for real time extraction and batch insertion of data

Things to keep in mind

Chapters

1. Start each chapter on a new page.

2. The first chapter is usually the "Introduction" and the last is usually the "Conclusions".

3. Acknowledgements, references, abstract, appendices, etc. are not chapters, and should not be given chapter numbers.

Introduction

1. Section 1.1 often contains the motivation for the project. What is the area of the project? What problems are you addressing?

2. Section 1.2 often contains a summary of your aims for the project. Did you aim to write a program? What is the purpose of this program?

3. It is useful to end the first chapter with an outline of the rest of the report. A single paragraph or half-a-page is usually sufficient. Write about one sentence per chapter, summarising what will be said in each.

Conclusions

1. Summarise what has been achieved in your project. Start with the most important achievements.

2. Consider including a section on "Future Work" within this chapter.

   If you want to describe a lot of possibilities for developing the project further, it might be better to have a separate chapter on "Future Work" before the final concluding chapter.

Credit where it is due

1. All assistance should be acknowledged.

2. If your project builds on earlier work, or has been done as part of a group, make sure that your own contribution can be identified by the reader.

3. You must not claim credit, or give the impression that you are claiming credit, for work that is not your own. Ensure that you do not mislead the reader, even accidentally.

4. If you include a figure that comes from another work, then the original source must be acknowledged in the figure legend, e.g. "(from [22])". If you modify or redraw a figure based on one from another work, then again the original source must be acknowledged, e.g. "(adapted from [22])".

5. You must avoid plagiarism. There are some useful documents on this subject on the web, including "Avoiding Plagiarism - A Guide for Students" (University of Oregon) and "What is Plagiarism?" (Georgetown University).

Figures and Tables

1. All figures and tables should be identified by a figure/table number.

2. You must refer to all figures and tables from the text. These references serve as a cue to the reader, and help to integrate the figures and tables into the report.

3. Use figure and table numbers that consist of the chapter number and the number of the figure/table within the chapter, e.g. Figure 2.1, Table 3.5.

   This is particularly useful when referring to a figure or table that is much earlier or much later in the report, since it helps the reader to locate it more quickly.

   It is also useful if you are managing the figure/table numbers and references manually, since adding or removing a figure only requires that you renumber the other figures in that chapter. Of course, it is better to use a system like LaTeX that manages figure/table numbering and figure/table references for you!

4. The figure legend should explain all of the graphical conventions used in the figure, e.g. What do the boxes and arrow mean? Why are some boxes shaded? What do the different line thicknesses mean? Is it important that something is shown above something else?

5. The figure number and figure legend should be on the same page as the figure.

References

1. All references that are in the reference list must be cited in the report.

2. All references that are cited in the report must be in the reference list.

3. Several different citation styles are commonly used. Use one the styles that is used by a journal or conference series, e.g. "(Kemp et al., 2002)" or "[22]".

4. Think about the order of references in the reference list. It is generally helpful to the reader if these are listed alphabetically according to the authors' names, since this enables the reader to check quickly whether a particular article has been cited.

5. If you use LaTeX and BiBTeX to prepare your report, all of the above points are handled automatically.

6. For more guidance on referencing, see the "Chalmers library reference guide".

Abbreviations and acronyms

1. When introducing an acronym it is usual to give the expansion of the acronym first, and then give the acronym in brackets, e.g. "the Protein Data Bank (PDB)".

2. If there are many acronyms and abbreviations in your report, consider having a glossary or a list of abbreviations as an appendix.

Appendices

1. Give each appendix an identifying label; capital letters work well for this.

2. There should be at least one reference to each appendix somewhere in the main report, e.g. "further screen-shots are shown in the user manual (Appendix G)", "more examples are given in Appendices B-D".

Program source code

1. In most cases, it is not necessary to include your code in your report.

2. I have no objections to part or all of the program source code being presented in an appendix, if you consider it useful to refer to the code when describing your work in the main part of the report.

   If doing this, consider using a small font, and place two or four pages of code on each page.

3. It can be useful to include some code (or pseudocode) fragments in figures in the main part of the report when describing important algorithms or data structures.

4. When presenting code, a fixed-width font (e.g. Courier) is generally more readable than proportional fonts.

5. When presenting code in a figure, it is useful to include line numbers and to refer to parts of the code using these numbers in the text.

6. It is good practice to prepare a tar file with code and data relevant to your project.

   This can be helpful for your supervisor and/or examiner.

   You might want to describe the contents and directory structure in an appendix of your report.

Spelling

1. With programs that can check for spelling errors so widely available, there is no excuse for submitting a report that contains these.

   On Unix, you can use the 'spell' command.

2. If you use LaTeX to prepare your report, it is convenient to use 'detex' before invoking the spelling checker, e.g.

   detex report.tex | spell
   

Writing support

• For Chalmers students: Chalmers Writing Centre

• For University of Gothenburg students: Language Support at the IT Faculty

There are many online writing resources, e.g.

• Unilearning website at the University of Wollongong