Thesis Structure

It has proven to be a good idea to follow a generic structure/procedure when preparing a large document or thesis. One of the most important advantages is that this structure can be used to collect keywords as an outline even before the final phase of the thesis, which makes writing it together much easier.

Chapter 1: Introduction

The introduction is written last, when the work is already finished to a great extent. (If you start with the introduction - a common mistake - it takes much longer and you throw it away later). Its main task is to provide the context for the different classes of readers. You have to win the readers over. The problem the paper deals with should at least be clear in its basic features and appear interesting to the reader. The chapter closes with an overview of the rest of the work. Usually you need at least 4 pages for it, nobody reads more than 10 pages.

Chapter 2: Basics and state of the art

Two essential tasks are performed here:

• The reader must be taught everything he needs to understand the later chapters. In particular, the system requirements that will be used later on must be clarified in our subject. It is also allowed to refer to tutorials or similar, which are available here on the net.
• It must be clear what is being worked on elsewhere. Especially the gaps of the others should be made clear. Why is your own work, your own approach important in order to advance the state of the art? This chapter is ignored by many readers (but not by the reviewer ;-), also later in publications "Related Work" is an important thing.

Many readers later realize that they need some of the basics and turn back. That's why it's good to have backward links in later chapters, so that you can read the sections referred to for yourself. These chapters can be relatively long, the greater the context of the work, the longer. It is also worth it! The text can be reused under certain circumstances by making it available to the net as a "tutorial" for a field.

In this way, you sometimes gain valuable tips from colleagues. This chapter is usually written first and is the easiest (or the most difficult because it is the first).

Chapter 3: Design

Is the central chapter of the work. Here the goal as well as the own ideas, evaluations, design decisions are presented. It can be worthwhile to play through different possibilities and then explicitly justify why one has chosen a particular one. This chapter should - at least in keywords - already be sketched out and written in keywords when a design is first defined. However, in a normal course of work, something will constantly change. The chapter must not become too detailed, otherwise the reader will be bored. It is very important to find the right level of abstraction. When writing, one should pay attention to the reusability of the text.

If one plans to make a publication out of the work, parts of this chapter can be taken out. Usually the chapter will have at least 8 pages, more than 20 can be an indication that the level of abstraction has been missed.

Chapter 4: Implementation

Here we pick out a few interesting aspects of implementation. The chapter should not be confused with documentation or even program comments. It can happen that many aspects have to be taken up, but this is not very common. The purpose of this chapter is, on the one hand, to make it credible that you are not dealing with a "paper tiger" but with a real existing system. It is certainly also a very important text for someone who will continue the work later. The third aspect is to give the reader a deeper impression of the technology that is being dealt with here. Nice examples are "War Stories", i.e. things you had to struggle with in particular, or a concrete, exemplary refinement of one of the ideas presented in chapter 3. Again, nobody reads more than 20 pages, but that's not so bad, because you can just stop reading without losing the thread. Complete source programs have no place in a work, not even in the appendix, but belong on computers where you can view them.

Chapter 5: Performance evaluation

Every job in our field includes a performance evaluation. This chapter should show which methods have been used to evaluate performance and what results have been achieved. It is important not only to provide the reader with some figures, but also to discuss the results. It is very good if you first discuss and make plausible what results you expect and then discuss possible deviations.

Chapter 6: Conclusions, questions and outlook

This chapter is certainly the most difficult to write. It is a concise summary of what you have learned, possibly peppered with backward references to the text, to give the lazy but interested reader (as a rule) the chance to learn something more profound. Some good works raise more problems than they solve. One may admit and discuss this. If necessary, you can also write what you still intend to do in this matter or give your successors a few tips. But one should not at all costs raise questions that are not there by force and suggest to the reader how far-sighted one is. This chapter must be short in order to be read.

Chapter 7: Summary

A round paper also includes a summary, which independently gives a short outline of the work. A half to whole DINA4 page is appropriate. No instructions for use can be given for this (the supervisors have to be there for something). Now some more general hints shall be given:

Grinding a few parts

As with programming, it is a popular mistake in scientific writing to grind around 5% of the total text while neglecting to maintain or even create the rest. The best thing is really to write it down in the respective phase of the text first without any consideration of losses and only then to make it clean.

Length

Many of the works I have seen are too long! At the beginning of their work, many students have the irrational fear that their work will be too short, so that they first have to inflate and then - noticing the wrinkled forehead of their supervisor - shorten it again. A guideline of about 50 pages for diploma theses has proved to be very useful.

The subjunctive

In principle one could actually do the thing once, this or that would then have to be done (preferably by someone who would then do the dirty work) ... I think we all know these texts.

Some general information about diploma theses in the Dresden OS group can be found here

Framework

For writing the diploma thesis there is a small TeX framework.

Abstract

An abstract must be prepared for all theses. It serves to give potential readers of the thesis a quick overview of the content of the thesis.