Thesis Structure

Preamble

(C) 2014, Ralf Lämmel

This advice is under construction.

It is meant to apply to BSc and MSc students of the software languages team.

Every thesis is different, but some reusable wisdom of structuring is provided here.

Examples theses are provided as well (even though they don't necessarily comply completely).

Advice on how to structure a thesis

  • Title
  • Abstract
  • Acknowledgement (Thank supervisor, fellow students, and others who have helped with the work.)
  • Chapter Introduction: This is always the first chapter of the thesis. The chapter should be short (up to 5 pages). The chapter should feature sections as follows (where applicable):
    • Problem context (What is the broader context of this work?)
    • Problem description (What is the specific problem or challenge addressed by this work?)
    • Research question(s) (What are the actual questions that should be answered by this research? Why are they interesting? To whom? Why is there no obvious answer? If this is getting too much, then details of discussion can be deferred until later, e.g., to the methodology section.)
    • Summary of results and contributions (What is the outcome of this work in simple terms?)
    • Structure of the thesis (Introduce briefly the remaining chapters.)
  • Chapter Background: This chapter is needed, if the thesis requires background material on less established concepts, technologies, etc. or if the existing resources are not easily applicable to the problem of the thesis or need to integrated in one place. The chapter should be concise and refer to existing resources (publications, textbooks, etc.), whenever appropriate.
  • Chapter Related work: This chapter is needed, if the thesis is somewhat research-oriented. (This should be usually the case.) In some cases though, the thesis may also be more application- or implementation-oriented, in which case a designated related work chapter may not be necessary, but instead citations are just used appropriately throughout the thesis, but specifically in the chapters Introduction and Background. Literature search could be based on DBLP.
  • Chapter Methodology: This chapter is needed specifically, if the work includes significant elements of empirical research. Most likely, the thesis would employ some methodology of empirical software engineering, e.g., an explorative study, a benchmarking study, a literature survey, or a controlled experiment. The specific details are to be described in the chapter so that the reported research becomes falsifiable, reproducible, and it can be eventually reviewed in terms of threats to validity. The methodology needs to be connected to the research questions, of course.
  • Chapter Requirements: This chapter is needed specifically, if the work is meant to design or implement some sort of software system. In good alignment with basic software engineering practice, the requirements for this system have to be developed systematically. Each requirement should have a short name, a short description, and some illustration. Additional elements are priorities (must, should, can), pointers to related work, and a discussion of the challenges involved.
  • Chapter Design: This chapter is needed specifically, if the work is meant to design or implement some sort of software system. In good alignment with basic software engineering practice, the system's design is to be presented at a reasonable level of abstraction. Appropriate notations are to be identified, e.g., UML diagrams, pseudocode, formal specifications, or declarative programs may be appropriate.
  • Chapter Implementation: This chapter is needed specifically, if the work is meant to deliver an actual implementation of some software system. No low level details or extensive code fragments should be included, but non-trivial implementation issues are to be explained, if they could not be reasonable covered at the design level; see Chapter Design. Many thesis do not need an Implementation Chapter because implementation details can be deferred to software documentation or the appendix. Also, some illustrative details of implementation may be placed in other chapters.
  • Chapter Case study: This chapter is needed, if the work performs a case study in the sense of empirical software engineering. In this case, the chapter describes the design of the case study (if this was not already done in Chapter Methodology) as well as the execution of the case study.
  • Chapter Experiment: This chapter is needed, if the work performs an experiment in the sense of empirical software engineering. In this case, the chapter describes the detailed experiment design and its execution.
  • Chapter Analysis/Results: This chapter is needed, when results from the previous chapters need to be systematically discussed. This is the case, when an implementation needs to be assessed, or the results of a case study or an experiment need to be interpreted.
  • Chapter Concluding remarks: This is always the first chapter of the thesis. The chapter should be short (up to 5 pages). The chapter should feature sections as follows (where applicable):
    • Summary (Summarize this work in an insightful manner, assuming that the reader has seen the rest.)
    • Limitations or threats to validity (Point out the limitations of this work. In the case of empirical research, discuss threats to validity in a systematic manner.)
    • Future work (Provide insightful advice on where this research should be taken next.)

Examples of completed theses

  • Thomas Schmorleiz' Master thesis (2015): "An Annotation-centric Approach to Similarity Management" (.pdf)
  • Philipp Schuster's Master thesis (2015): "Dependencies between Haskell code fragments" (.pdf)
  • Martin Leinberger's Master thesis (2014): "Enhancement of a software chrestomathy for open linked data" (.pdf)
  • Arkadi Schmidt and Olexiy Lashyn's Master thesis (2014): "Contributor and administrator support for a software chrestomathy" (.pdf)
  • Carl Corea's Bachelor thesis (2014): "101consulting - Machbarkeitsanalyse eines universitären Startups im Bereich der IT-Beratung" (.pdf)
  • Erwin Schens' Bachelor thesis (2014): "Konzeption und Implementation einer Multimedia Datenbank mithilfe von Megamodellierung" (.pdf)
  • Dmitry Nikonov's Bachelor thesis (2014): "Aspekt-orientierte Programmierung im Projekt 101companies" (.pdf)
  • Pascal Schuler's Bachelor thesis (2014): "The role of annotation and XML in framework usage" (.pdf)
  • Thomas Bernau's Bachelor thesis (2013): "Build management for a software chrestomathy" (.pdf)
  • Andreas Brandt's Bachelor thesis (2010): "Algebraic Analysis of MapReduce Samples" (.pdf)