Wiki source code of Writing and Grading Theses

Version 28.1 by cds on 2015/04/08 11:20
Show last authors
1 This page is the collected wisdom and advice after supervising about 100 theses, from short study reports to dissertations. We recommend to study it **before** you start with your thesis work. Some topics are discussed on these separate pages:
2
3
4
5 {{children/}}
6
7 **Table of Contents**
8
9
10
11 {{toc/}}
12
13 //Note: Most of this page is in German. Future additions should be done in English. At some point, some good soul might translate the German "legacy documentation" to English as well.//**
14 **
15
16 = Interaction With Your Adviser(s) =
17
18 A good interaction with your adviser(s) is key to success. Unless you happen to have substantial work experience and to already be an expert in your field, your adviser is ahead of you in terms of experience and expertise. Take advantage of this to improve your own work.
19
20 Advisers are humans. They like to help you with your thesis topic; they don't like to have to "drive" it, or to get the feeling that their advice (including the hints on this page) is ignored. You, and not your adviser, should be the one who is pushing your work, asking questions, initiating discussions, and handing over thesis/chapter drafts without having to be explicitly asked for it. In short, your adviser should be convinced that your work is on track.
21
22 Even in the age of modern communication devices, the basis of a good communication with your adviser is regular physical presence. Most of the time, we are in the fortunate position that we can provide you with a full-time desk, typically in the lab (1114/1115). Use this desk for doing your thesis work, and not your PC at home. A key communication instrument in the RTSYS group is the 9:30am tea, which you should participate in as well. One exception are theses that are done in collaboration with industry and where the industry partner provides the work space. In that case, you should keep your adviser here on track with regular progress reports. Usually, an E-mail every 2 to 4 weeks suffices for that.
23
24 Usually, your thesis is a full-time job, also meaning **full-time presence at your desk**. In case you also have other regular work to do, discuss this with your adviser at the beginning of your thesis work.
25
26 = Thesis Proposal =
27
28 The first thing to do after you familiarized yourself with the topic and problem of your thesis is to write a short proposal (~~2-4 pages). The proposal should be prepared as early as possible (within the first or second week) and should show your adviser that you understood the problem and have a rough idea how to solve it. It may be structured as follows.
29
30 * Problem description
31 * Planned Solutions/Goals
32 ** Hard requirements that have to be fulfilled by the end of your thesis
33 ** Soft requirements that can be solved if time permits
34 * Schedule outlining your proceeding (this includes writing the thesis, see next section)
35
36 After you finished the proposal, you should give a short (informal) talk of about 15 minutes during our daily tea meeting presenting your topic to all members of our group.
37
38 = Timing is (Almost) Everything =
39
40 Chances are your adviser has already supervised one or more theses. Take advantage of his or her experience! Send him drafts of the chapters of your thesis before submitting the final thesis. Of course, the drafts should be as good as possible from your point of view. Your adviser can only improve your drafts so much. If your draft is of low quality, (s)he can help you push it to an okay-ish level; but if the draft is already of high-quality to start with, (s)he can help you elevate it to pure awesomeness. Note that your drafts need not be complete yet: you can always hand in missing bits and pieces later on. Here's a schedule that has proven to work well regarding when to hand in what.
41
42 |=(((
43 What
44 )))|=(((
45 Master's Thesis
46 )))|=(((
47 Bachelor's Thesis
48 )))|=(((
49 Motivation
50 )))
51 |(((
52 Outline
53 )))|(((
54 3 months before final submission
55 )))|(((
56 6 weeks
57 )))|(((
58 Once you are halfway through your thesis, you should have a basic idea of which topics you want to cover in your thesis. This must be discussed with your adviser.
59 )))
60 |(((
61 1–2 chapters
62 )))|(((
63 4 weeks
64 )))|(((
65 3 weeks
66 )))|(((
67 The first drafts you submit are used to make you aware of basic problems of your writing style. Getting this feedback as early as possible in your writing process means that you won't have to change the whole thesis after you submit your final draft.
68 )))
69 |(((
70 Complete thesis
71 )))|(((
72 2 weeks
73 )))|(((
74 10 days
75 )))|(((
76 Submitting a draft of your complete thesis **before** the final submission gives your adviser enough time to find problems and gives you enough time to incorporate corrections into your final thesis. This doesn't only improve the quality of your thesis, but also satisfies your adviser.
77 )))
78
79 Theses done in collaboration with industry partners follow the same schedule. The drafts you submit to your adviser at the university, however, should previously be run past your industry adviser.
80
81 = Keeping Notes =
82
83 A common experience: while you do your investigative/implementation work, everything is clear — until you try to write things up, weeks or months later. Thus we highly recommend to take notes along the way, eg, as part of a chapter draft of your thesis.
84
85 = Implementations =
86
87 The first rule of your implementation is: **"No Crashes!"** The second rule of your implementation is: **"No crashes!"** Regardless of what your code does and regardless of what the user does, your implementation should neither crash nor freeze. Whenever you make assumptions, be sure to explicitly check them. If they are not met, your code should generate (useful!) error messages instead of crashing and the user should be able to continue working with it.
88
89 Since you're working in an academic context, you will have less resources (less time, in particular) available than in a commercial setting. Also, your work probably won't have to compete with commercial applications. It follows that everything you develop will be less comprehensive and will have less features than a commercial product. What doesn't follow is that your implementation should be less meticulous or less documented than in a professional setting. Quite the contrary, in fact: commercially developed code often suffers from tight deadlines, the need to add new features, and at times a certain ignorance. You implementation, on the other hand, is supposed to be your masterpiece. It should reflect what you're currently capable of. Even though your software won't cause considerable economical damage or kill people, it probably won't exist in isolation. It will much rather be part of the KIELER project, which other people are supposed to use or develop further. The quality (and grade) of your thesis will be judged in part based on your implementation. Since this is the case, make use of the fact that your adviser probably has much more experience writing code than you do. Ask him or her to review your code and to give you feedback on how to improve.
90
91 Let's look at an example. Suppose your thesis is a proof of concept. This means that you should constrain the goals of your thesis (**in accordance with your adviser**) to a well-defined subset of the problem you're tackling. The end user should be well aware of what your implementation can do and what it cannot do. A reasonable constraint could for instance be: "The transformation only works for //pure signals//, not for //valued signals//. Hierarchy-crossing transitions cannot be drawn." An unreasonable constraint could be: "Sometimes, adding a state works; other times, the software crashes." If you notice while working on your implementation that you won't be able to make certain goals, talk to your adviser. Together, you will constrain the problem further. This will allow you to solve the more constrained problem properly instead of not solving the more general problem at all. You colleagues or successors will be glad to be able to start from a smaller, but well-developed code base and add features to it instead of having to try to get your code to a reasonable quality standard — or throwing it away and starting over.
92
93 The bottom line: write clean and proper code that adheres to our coding guidelines and document it. The quality and the readability of your code and of your documentation will influence your grade.
94
95 == Reviews and Ratings[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ReviewsundRatings||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
96
97 To make sure that code is of a certain quality, it must be run through design and code reviews. The way this works is explained [[on this page>>doc:KIELER.Review Process]]. The reviews are not only intended to improve the quality of your code, but also to give feedback to you as a programmer to help you improve.
98
99 = What Grade Do I Get For All This? =
100
101 Die Benotung studentischer Arbeiten richtet sich zunächst nach der jeweils anzuwendenen Studienordnung; für eine Diplomarbeit im Diplomstudiengang Informatik sieht z.B. §20(2) der Diplomprüfungsordnung vor: „Die Diplomarbeit ist von der Lehrkraft, die sie ausgegeben hat und einer oder einem weiteren Prüfungsberechtigten zu beurteilen.“
102
103 Zur Beurteilung einer Diplomarbeit wird generell ein schriftliches Gutachten erstellt, welches die jeweilige Arbeit individuell würdigt (incl. Note) und an das Prüfungsamt weitergeleitet wird. Es hängt dabei von der jeweiligen Aufgabenstellung ab, welche Leistungen im Einzelfall erwartet werden; so sind z.B. die Anforderungen hinsichtlich der konkreten Umsetzung bei einer stark anwendungsbezogenen Arbeit anders als bei einer eher theoretischen Arbeit. Gewisse Anforderungen und Erwartungen hinsichtlich der Qualität der Arbeit und der Vorgehensweise des Studierenden sind jedoch allgemein gültig, und z.T. auch bereits in der jeweiligen Prüfungsordnung konkret genannt. So sieht z.B. §19(1) der Diplomprüfungsordnung vor: „Die Diplomarbeit [...] soll zeigen, dass die Kandidatin oder der Kandidat in der Lage ist, innerhalb einer vorgegebenen Frist ein Problem aus dem Fach Informatik selbständig nach wissenschaftlichen Methoden zu bearbeiten.“ Hier sind also bereits drei Kriterien genannt (Fristeinhaltung, Selbständigkeit, Wissenschaftlichkeit). Ein etwas detaillierterer Kriterien-/Bewertungskatalog ist in den beiden folgenden Tabellen angegeben. Diese sind zunächst für Diplomarbeiten ausgelegt, finden aber - mit entsprechenden Abwandlungen - auch für Studien-, Bachelor- und Masterarbeiten Anwendung.
104
105 |(((
106 **Merkmal**
107 )))|(((
108
109 )))|(((
110
111 )))|(((
112
113 )))|(((
114
115 )))|(((
116 **Punkte**
117 )))
118 |(((
119 //Qualität der Lösung//
120 )))|(((
121 Lediglich Lösungsansätze; geringes Vertrauen in die Lösung
122 )))|(((
123 Lösung von Teilproblemen
124 )))|(((
125 Vollständige Lösung; gutes Vertrauen in die Lösung
126 )))|(((
127 Vollständige, gute Lösung und Behandlung zusätzlicher Fragestellungen
128 )))|(((
129
130 )))
131 |(((
132 Punkte
133 )))|(((
134 1 - 7
135 )))|(((
136 8 - 14
137 )))|(((
138 15 - 21
139 )))|(((
140 22 - 28
141 )))|(((
142 max. 28
143 )))
144 |(((
145 //Wissenschaftliche Arbeitstechnik//
146 )))|(((
147 Systemlose Durchführung; nur Literatur aus dem engsten Umfeld
148 )))|(((
149 Entwicklung einer Systematik erst nach Drängen des Betreuers; geringes Literaturvolumen
150 )))|(((
151 Selbständige Aufarbeitung der relevanten Literatur; grobe Einordung der Ergebnisse in das wissenschaftliche Umfeld
152 )))|(((
153 Selbständige und strukturierte Erfassung des Standes der Technik und der Literatur; systematische Einordung der Ergebnisse
154 )))
155 |(((
156 Punkte
157 )))|(((
158 1 - 6
159 )))|(((
160 7 - 12
161 )))|(((
162 13 - 18
163 )))|(((
164 19 - 24
165 )))|(((
166 max. 24
167 )))
168 |(((
169 //Anwesenheit und Interaktion mit Betreuer//
170 )))|(((
171 Selten anwesend, Interaktion nur auf Initiative des Betreuers; schwer erreichbar; weist nicht auf Probleme hin
172 )))|(((
173 Unregelmäßige Interaktion, jedoch generell erreichbar und häufig anwesend
174 )))|(((
175 Regelmäßige, selbst initiierte Interaktion; Stand der Arbeit generell nachvollziehbar
176 )))|(((
177 Informiert Betreuer regelmäßig über Stand der Arbeit; weist umgehend auf aufgetretene Probleme oder erreichte Zwischenziele hin; regelmäßige Anwesenheit
178 )))
179 |(((
180 Punkte
181 )))|(((
182 1 - 4
183 )))|(((
184 5 - 8
185 )))|(((
186 9 - 12
187 )))|(((
188 13 - 16
189 )))|(((
190 max. 16
191 )))
192 |(((
193 //Eigeninitiative und Zielstrebigkeit//
194 )))|(((
195 Geht schwierigen Problemen aus dem Weg; mangelnder zeitlicher Einsatz; Zeitplan wird deutlich überzogen
196 )))|(((
197 Teilweise Eigeninitiative; Zeitplan im Wesentlichen eingehalten
198 )))|(((
199 Ziel wurde mit großer Eigeninitiative erreicht; Zeitplan wurde eingehalten
200 )))|(((
201 Eigeninitiative bei der Entwicklung der Thematik, auch bei schwierigen Problemen; Zielbewusste Zeiteinteilung
202 )))
203 |(((
204 Punkte
205 )))|(((
206 1 - 4
207 )))|(((
208 5 - 8
209 )))|(((
210 9 - 12
211 )))|(((
212 13 - 16
213 )))|(((
214 max. 16
215 )))
216 |(((
217 //Qualität der Ausarbeitung//
218 )))|(((
219 Ausarbeitung mit schweren Mängeln: fehlende Systematik, Schreibfehler, schlechtes Deutsch, unübersichtliche Verzeichnisse usw.
220 )))|(((
221 Nur teilweise systematische Darstellung der Ergebnisse; Weitschweifigkeiten oder Knappheiten, aber akzeptable Gestaltung
222 )))|(((
223 Systematische, einleuchtende Gliederung, aber leichte Schwächen in Sprache und Gestaltung
224 )))|(((
225 Systematische Gliederung, flüssige Sprache, Bilder mit klarer Aussage, deutliche Darlegung der Zusammenhänge und Ergebnisse
226 )))
227 |(((
228 Punkte
229 )))|(((
230 1 - 4
231 )))|(((
232 5 - 8
233 )))|(((
234 9 - 12
235 )))|(((
236 13 - 16
237 )))|(((
238 max. 16
239 )))
240 |(((
241
242 )))|(((
243
244 )))|(((
245
246 )))|(((
247
248 )))|(((
249 **Summe**
250 )))|(((
251 max. 100
252 )))
253
254 Die Umrechnung einer Punktzahl in eine Zensur ergibt sich unter Anwendung dieses Katalogs aus der folgenden Tabelle.
255
256 |(((
257 Note
258 )))|(((
259 1,0
260 )))|(((
261 1,3
262 )))|(((
263 1,7
264 )))|(((
265 2,0
266 )))|(((
267 2,3
268 )))|(((
269 2,7
270 )))|(((
271 3,0
272 )))|(((
273 3,3
274 )))|(((
275 3,7
276 )))|(((
277 4,0
278 )))
279 |(((
280 Mindestpunktzahl
281 )))|(((
282 96
283 )))|(((
284 88
285 )))|(((
286 80
287 )))|(((
288 72
289 )))|(((
290 64
291 )))|(((
292 56
293 )))|(((
294 48
295 )))|(((
296 40
297 )))|(((
298 32
299 )))|(((
300 24
301 )))
302
303 = Further Links =
304
305 * Prof. Luttenberger at the [[Communication Systems Group>>url:http://www.comsys.informatik.uni-kiel.de/||shape="rect"]] regularly offers a very good course on writing and presenting scientific work.
306 * „Einige typographische Grundregeln und ihre Umsetzung in LaTeX“ by [[Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||style="text-decoration: none;" shape="rect" class="ext-link"]] (TU Braunschweig), [[PDF>>url:http://www.ips.tu-braunschweig.de/struckmann/unitext/typographie.pdf||shape="rect"]]
307 * „Anmerkungen zur Rechtschreibung“ by [[Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||style="text-decoration: none;" shape="rect" class="ext-link"]] (TU Braunschweig), [[PDF>>url:http://www.ips.tu-braunschweig.de/struckmann/unitext/rechtschreibung.pdf||shape="rect"]]
308 * If you write your thesis in English, you can find advice and further links (among them the classic "Strunk & White" on good writing style) on [[Henning Schulzrinne's>>url:http://www.cs.columbia.edu/~~hgs/||shape="rect"]] page "[[Writing Technical Articles>>url:http://www.cs.columbia.edu/~~hgs/etc/writing-style.html||shape="rect" class="icon"]]".
309 * "[[Wie schreibe ich eine gute Diplomarbeit?>>url:http://www.informatik.uni-oldenburg.de/studium/azwa/wie.html||shape="rect" class="icon"]]" — a guide written at Oldenburg University. This is in part specific to that university, but also contains further links.

Navigation

Quick Links

KIELER on GitHub
RTSYS Homepage