Changes for page Writing and Grading Theses

Summary

• Page properties (3 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Parent

...	...	@@ -1,1 +1,0 @@
1		-Theses.WebHome

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.als
	1	+XWiki.rvh

Content

...	...	@@ -1,100 +1,176 @@
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:
	1	+//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.//
2	2
3	3	**Table of Contents**
4	4
5		-{{toc/}}
6	6
7		-//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.//
8	8
9		-= Interaction With Your Adviser(s) =
	7	+{{toc/}}
10	10
11		-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.
	9	+
12	12
13		-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.
	11	+Diese Seite gibt Hinweise, welche bei der Anfertigung einer studentischen Arbeit an der AG Echtzeitsysteme und Eingebettete Systeme beachtet werden sollten. Dies betrifft in erster Linie Bachelor-/Master-/Studien-/Diplomarbeiten. Die Hinweise können aber auch bei der Anfertigung von Praktikumsberichten - oder auch Promotionsarbeiten - hilfreich sein.
14	14
15		-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.
	13	+= Interaktion mit dem Betreuer[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#InteraktionmitdemBetreuer||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
16	16
17		-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.
	15	+Eine gute Zusammenarbeit mit Ihrem Betreuer (dies können auch mehrere sein) ist ein wesentlicher Schlüssel für eine erfolgreiche Arbeit. Ihr Betreuer sollte Ihnen an Erfahrung und Fachwissen voraus sein - nutzen Sie dies, um zu lernen und Ihre Arbeit zu verbessern.
18	18
19		-= Thesis Proposal =
	17	+Betreuer sind auch Menschen. Sie helfen Ihnen gerne bei der inhaltlichen Arbeit; weniger gerne spielen sie "Antreiber", oder haben das Gefühl, dass ihre Hinweise/Ratschläge/Informationen (incl. der Hinweise auf dieser Seite) nicht wirklich Gehör finden. Grundsätzlich sollten Sie selbst es sein, welcher Ihre Arbeit vorantreibt, Fragen stellt, Besprechungen initiiert, Ihrem Betreuer unaufgefordert Leseproben zukommen lässt. Kurzum, der Betreuer sollte überzeugt sein, dass Ihre Arbeit "läuft".
20	20
21		-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.
	19	+Grundlage einer guten Kommunikation mit dem Betreuer ist erfahrungsgemäß Ihre Präsenz vor Ort. Wir sind normalerweise in der Lage, Ihnen einen Arbeitsplatz am Lehrstuhl einzuräumen, typischerweise im Labor. Sie sollten diesen Arbeitsplatz für Ihre Arbeit nutzen, und **nicht** den heimischen PC. So ergibt sich ganz von selbst ein regelmäßiger, oft informeller Austausch, z.B. im Rahmen der üblichen "Lehrstuhl-Teerunde", täglich 9:30 im Labor, zu der auch Sie herzlich eingeladen sind.
22	22
23		-* Problem description
24		-* Planned Solutions/Goals
25		-** Hard requirements that have to be fulfilled by the end of your thesis
26		-** Soft requirements that can be solved if time permits
27		-* Schedule outlining your proceeding (this includes writing the thesis, see next section)
	21	+Eine Ausnahme sind Arbeiten, welche in Zusammenarbeit mit einem Industrieunternehmen angefertigt werden. Diese werden in der Regel fachlich primär von dort betreut und Sie sollten Ihren Arbeitsplatz bei dem Unternehmen haben. Hier sollten Sie den universitären Betreuer mit regelmäßigen Fortschrittsberichten (E-Mail alle 4-6 Wochen) über den Fortgang Ihrer Arbeiten informieren.
28	28
29		-You should send your thesis proposal to your advisor and (if he is not already your advisor) the professor. 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.
	23	+Ihre Diplomarbeit ist ein Vollzeitjob; Sie sollten also im Normalfall täglich am Arbeitsplatz sein. Wenn Sie daneben einer regelmäßigen Arbeit nachgehen, sollten Sie mit dem Betreuer absprechen, wie dies mit der Anfertigung Ihrer Abschlussarbeit vereinbart werden kann.
30	30
31		-As part of your final presentation, you should reflect on the schedule in your proposal.
	25	+= Zeitlicher Ablauf[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ZeitlicherAblauf||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
32	32
33		-= Timing is (Almost) Everything =
	27	+Sie sollten insbesondere bei der Anfertigung der schriftlichen Ausfertigung auf die Erfahrungen des Betreuers zugreifen. Sie sollten dem Betreuer also Entwürfe Ihrer Arbeit zukommen lassen, bevor Sie die zu benotende Endversion einreichen. Ihre Entwürfe sollten dabei aus Ihrer Sicht möglichst reif sein, müssen aber noch keineswegs vollständig sein. Eine bewährte Sequenz von abzuliefernden Dokumenten ist:
34	34
35		-Technically, the only hard deadline that you have regarding your thesis submission is the one concerning the submission to the examination office (//Prüfungsamt//), which is at the end of the semester for Bachelor thesis and six months after registering the thesis for master thesis. However, at RTSYS (as with most other groups) we offer to look at your thesis before the official submission. This not only helps to improve your thesis, it also is more satisfying for the advisor to look at a thesis in detail if it's not just to determine a grade but also to help improve the result.
36		-
37		-Thus, in your own interest, we advise //strongly// to send drafts of the chapters of your thesis to your advisor(s) 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, they can help you push it to an okay-ish level; but if the draft is already of high-quality to start with, they 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.
38		-
39		-The process is usually that 1) you send a draft to the doctoral student(s) directly advising you, 2) you get feedback from them, 3) you implement that feedback, 4) you send the revised draft to the Prof. Yes, this pipeline takes time, and often there are holidays and travel plans to take into account as well, in particular for deadlines at the end of the summer semester. Here's a schedule that has proven to work well regarding when to hand in what to your direct advisors. Of course, sticking to that schedule is YOUR responsibility, you should not rely on your advisors to remind you of it.
40		-
41		-(% class="wrapped" %)
42	42	|=(((
43		-What
	30	+Aktion
44	44	)))|=(((
45		-When (AT THE LATEST)
	32	+Masterarbeit/Diplomarbeit
46	46	)))|=(((
47		-Motivation
	34	+Bachelorarbeit/Studienarbeit
	35	+)))|=(((
	36	+Idee
48	48	)))
49	49	|(((
50		-Outline
	39	+Gliederung
51	51	)))|(((
52		-3 months before final submission
	41	+3 Monate vor Abgabe
53	53	)))|(((
54		-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.
	43	+6 Wochen vor Abgabe
	44	+)))|(((
	45	+Zur Halbzeit sollte man schon einen Plan haben, welche Themen in der Arbeit grundsätzlich diskutiert werden sollen. Dies muss rechtzeitig mit dem Betreuer besprochen werden.
55	55	)))
56	56	|(((
57		-1–2 chapters
	48	+1-2 Probekapitel
58	58	)))|(((
59		-4 weeks
	50	+4 Wochen vor Abgabe
60	60	)))|(((
61		-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.
	52	+3 Wochen vor Abgabe
	53	+)))|(((
	54	+Probekapitel sollen grundsätzliche stilistische Probleme zeigen und verhindern, dass bei der Endkorrektur alles grundsätzlich anders gemacht werden muss.
62	62	)))
63	63	|(((
64		-Complete thesis
	57	+Komplette Arbeit
65	65	)))|(((
66		-2 weeks
	59	+2 Wochen vor Abgabe
67	67	)))|(((
68		-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.
	61	+10 Tage vor Abgabe
	62	+)))|(((
	63	+Die Abgabe der kompletten Arbeit **vor** der offiziellen Abgabe dient unter anderem dazu, dass stilistische/orthographische Korrekturen noch in die Arbeit einfließen können, bevor diese offiziell abgegeben/veröffentlicht ist. Das dient nicht nur der Verbesserung der Arbeit, sondern ist auch für den Betreuer befriedigender.
69	69	)))
70	70
71		-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.
	66	+Für Arbeiten, welche in Zusammenarbeit mit einem Industrieunternehmen angefertigt werden, gilt diese Sequenz ebenso; Sie sollten hier jedoch Entwürfe, welche Sie dem universitären Betreuer zukommen lassen, vorher entsprechend von Ihrem Betreuer aus dem Unternehmen durchsehen lassen.
72	72
73		-= Keeping Notes =
	68	+= Notizen[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Notizen||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
74	74
75		-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.
	70	+Machen Sie sich während Ihrer gesamten theoretischen Arbeit Notizen darüber, was Sie gerade tun, wie Sie es tun und insbesondere: warum Sie es tun. Im Moment des Tuns ist alles noch klar, aber sobald es ans Schreiben geht wird es nicht mehr so klar sein. Tun Sie sich also einen Gefallen und schreiben Sie Notizen. Die Arbeit ist auch insofern schon nicht umsonst, als dass die Notizen eine prima Grundlage für Teile Ihrer schriftlichen Ausarbeitung werden.
76	76
77		-= Implementations =
	72	+= Hinweise zu Implementierungen[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#HinweisezuImplementierungen||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
78	78
79		-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.
	74	+== Allgemeines[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Allgemeines||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
80	80
81		-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.
	76	+Erste Regel: **"No Crashes!"** Egal was Ihr System tut und welche Nutzereingaben geschehen, die Implementierung sollte nicht abstürzen oder einfrieren. Wo Annahmen gemacht werden, sollten diese explizit überprüft werden. Im Falle der Nichteinhaltung sollte eine brauchbare Fehlermeldung generiert werden, und der Anwender sollte weiter mit der Implementierung arbeiten können.
82	82
83		-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.
	78	+Generell: Ihre Arbeit wird sehr wahrscheinlich auch einen praktischen Teil enthalten, in welcher Sie Software oder Hardware entwickeln oder erweitern sollen. Das akademische Umfeld Ihrer Arbeit bedeutet in der Regel, dass für diese Entwicklung weniger Ressourcen - insbesondere zeitliche Ressourcen - als in einem kommerziellen Umfeld zur Verfügung stehen, und dass sich Ihre Arbeit nicht am Markt behaupten muss. Die Konsequenz daraus ist, dass Ihre Arbeit in der Regel weniger umfangreich sein sollte und weniger Features bieten sollte als ein kommerzielles Produkt. Die Konsequenz ist nicht, dass Sie ihre Implementierung weniger sorgfältig vornehmen sollen, oder schlechter dokumentieren sollen, als dies in einem professionellem Umfeld der Fall wäre. Im Gegenteil - während bei kommerziellen Produkten der Termindruck, die Notwendigkeit zu ständigen Neuentwicklungen, und zum Teil eine gewisse Ignoranz auf Kunden- und/oder Entwicklerseite den Qualitätsstandard senken können, sollte die von Ihnen hier erstellte Implementierung Ihr „Meisterstück“ sein, welches zeigt, wozu Sie (im positiven Sinne) fähig sind. Es gilt hier zwar, dass Produktfehler keinen erheblichen wirtschaftlichen Schaden verursachen können oder gar Menschenleben gefährden können; jedoch ist auch hier Ihre Arbeit in der Regel nicht isoliert und „nur“ Teil Ihrer Ausarbeitung, sondern etwas, was andere anwenden und weiterentwickeln sollen. Die Qualität (und Benotung) Ihrer Arbeit wird (unter anderem) an der Qualität Ihrer Entwicklung gemessen.
84	84
85		-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.
	80	+Zur Verdeutlichung: wenn Ihre Arbeit eine Machbarkeitsstudie (//proof of concept//) sein soll, bedeutet dies, dass Sie Ihre Arbeit **in Absprache mit dem Betreuer** auf eine wohldefinierte Teilmenge des Gesamtproblems einschränken sollen. Es sollte für den Anwender klar erkennbar und vorhersagbar sein, was Ihre Implementierung leistet und was nicht. Sinnvolle Einschränkungen können zum Beispiel sein: „die Transformation betrachtet nur //pure signals//, keine //valued signals// ... Es können keine hierarchieübergreifenden Transitionen gezeichnet werden“. Keine sinnvolle Einschränkung ist: „Mal funktioniert das Einfügen eines Zustands - mal stürzt das System ab“. Wenn im Laufe Ihrer Implementierungsarbeit ersichtlich wird, dass bestimmte Implementierungsziele nicht erreicht werden können (aufgrund falscher Einschätzung des Problems, oder aufgrund schlechter Ressourcenplanung), sollte sofort mit dem Betreuer abgesprochen werden, wie das Problem sinnvollerweise eingeschränkt werden könnte; es sollte nicht zu einer schlampigen Entwicklung führen. Schließlich gilt: es ist für etwaige Teamkollegen/Nachfolger von Ihnen eine wesentlich dankbarere Aufgabe, auf Ihrer kleinen, sauber entwickelten Arbeit aufzusetzen und diese um neue Features zu erweitern, als zu versuchen, Ihre große, defekte Arbeit auf einen brauchbaren Qualitätsstandard anzuheben - oder diese ganz wegzuschmeißen und von vorne anzufangen.
86	86
87		-== Code Reviews ==
	82	+Grundsätzlich gilt: Die Software ist „sauber“ zu schreiben und zu dokumentieren, unter Beachtung eines evtl. vorhandenen Projekthandbuchs. Die Qualität und Leserlichkeit Ihrer Software sowie der Dokumentation geht in die Bewertung Ihrer Arbeit mit ein.
88	88
89		-To make sure that code is of a certain quality, it must be run through code reviews. For this, create a pull request on GitHub, note which classes and changes are most relevant for the PR and assign your advisor(s) to review it. 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.
	84	+== Reviews und 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"]] ==
90	90
91		-= What Grade Do I Get For All This? =
	86	+Ist die Implementierung Teil des KIELER Projekts, so müssen zur Erhaltung des Qualitätsstandards Design und Code Reviews durchgeführt werden. Wie dies praktisch abläuft und wie die sich daraus ergebenden Ratings aussehen wird auf der KIELER Projektseite erläutert.
92	92
93		-Zur Beurteilung einer Abschlussarbeit 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. § 9(6) der Bachelorprüfungsordnung vor: „Die Note der Bachelorarbeit berücksichtigt die Problembearbeitung, die Bachelorarbeit und den Abschlussvortrag einschließlich der sich anschließenden Aussprache."
	88	+=== Technische Umsetzung[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#TechnischeUmsetzung||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===
94	94
95		-Ein etwas detaillierterer Kriterien-/Bewertungskatalog ist in den beiden folgenden Tabellen angegeben. Diese sind zunächst für Bachelorarbeiten ausgelegt, finden aber - mit entsprechenden Abwandlungen - auch für Masterarbeiten Anwendung.
	90	+==== Editor/IDE[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#EditorIDE||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
96	96
97		-(% class="wrapped" %)
	92	+Prof. von Hanxleden would recommend Emacs as a very flexible and powerful Latex editor. Hauke (haf) recommends [[Texlipse>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Texlipse||style="text-decoration: none;" shape="rect" class="wiki"]] as an easy-to use and also powerful Eclipse plug-in. Christoph Daniel (cds) recommends using Kile, a KDE LaTeX editor that is fast, powerful, and reasonably easy to understand and to use.
	93	+
	94	+==== Using Git[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#UsingGit||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	95	+
	96	+The files associated with the thesis should be kept in the group's [[Git>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Git||style="text-decoration: none;" shape="rect" class="wiki"]] repository. The main purpose is to prevent loss of data. It also facilitates access for fellow group members if needed, and to allow on-line publication.
	97	+
	98	+The main tex file for a thesis should be <name of directory>.tex. See also [[Git/Structure>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Git/Structure||style="text-decoration: none;" shape="rect" class="wiki"]] for the canonical naming scheme. Eg, the bachelor thesis of user xyz can be found in a repository named xyz-bt in the Thesss project of our [[(% class="icon" %) (%%)Gitorious>>url:https://git.rtsys.informatik.uni-kiel.de/projects||style="text-decoration: none;" shape="rect" class="ext-link"]] system, in a file named xyz-bt.tex. If there is a talk to "defend" the thesis (Bachelor-Kolloquium, Disputation), the talk should also be included in this repository, and should be named <name of directory>-talk.tex; eg xyz-bt-talk.tex. In case your thesis should be made available on-line, the same names should be used, eg, xyz.pdf.
	99	+
	100	+See also the notes on [[preparing a paper>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Preparing_a_Paper||style="text-decoration: none;" shape="rect" class="wiki"]], eg regarding which files should be kept in revision management (ie, should be checked into Git) and which shouldn't.
	101	+
	102	+==== Das ToDo-Paket[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#DasToDo-Paket||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	103	+
	104	+Es kommt häufig vor dass man sich während des Schreibens Anmerkungen zum Text machen oder Dinge später hinzufügen möchte. Damit dies einfacher zu verwalten ist, steht ein extra ToDo-Paket zur Verfügung. Mit diesem Paket lassen sich Platzhalter für Grafiken, Anmerkungen zum Text in verschiedenen Farben oder einfache ToDo-Kommentare mit Referenz zum Text schnell und unkompliziert realisieren. Eingebunden wird das Paket wie folgt.
	105	+
	106	+{{{ \usepackage{todonotes}
	107	+}}}
	108	+
	109	+Eine kurze, detaillierte Anleitung kann man hier nachlesen:
	110	+
	111	+>[[(% class="icon" %) (%%)http:~~/~~/www.tex.ac.uk/tex-archive/macros/latex/contrib/todonotes/todonotes.pdf>>url:http://www.tex.ac.uk/tex-archive/macros/latex/contrib/todonotes/todonotes.pdf||style="text-decoration: none;" shape="rect" class="ext-link"]]
	112	+
	113	+==== Die Erstellung einer Bibliographie[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#DieErstellungeinerBibliographie||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	114	+
	115	+Zur Erstellung einer Bibliographie mit LaTeX ist das Beispiel-Dokument zu Rate zu ziehen. Die dort benutzte BibTeX-Datenbank cau-rt.bib wird Lehrstuhl-weit von Mitarbeitern und Studenten gemeinsam benutzt um Literatur-Daten zu sammeln und zu publizieren. Alle Literaturdaten, die in studentischen Arbeiten anfallen, müssen also in dieser Datei verwaltet werden. **Wichtig:** Bitte vermeiden Sie bibtex-Warnungen beim Hinzufügen von neuen Einträgen! Weitere Hinweise zur Beachtung finden sich [[hier>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Preparing_a_Paper#The_Bibliography_-_Guidelines_for_bibtex_Entries||style="text-decoration: none;" shape="rect" class="wiki"]]
	116	+
	117	+Das Erstellen eines deutschsprachigen Literaturverzeichnisses ist mit Hilfe des Paketes //bibgerm// und dem bibliographystyle //gerplain// möglich.
	118	+
	119	+{{{ \usepackage[ngerman]{babel}
	120	+ \usepackage{bibgerm}
	121	+ .
	122	+ .
	123	+ .
	124	+ \bibliographystyle{gerplain}
	125	+
	126	+}}}
	127	+
	128	+Links zu BibTeX:
	129	+
	130	+* [[(% class="icon" %) (%%)BibTeX-Tutorial>>url:http://www.din1505.informationskompetenz.net/||style="text-decoration: none;" shape="rect" class="ext-link"]] (Link ist tot)
	131	+* [[(% class="icon" %) (%%)Tame the BeaST - The B to X of BibTEX (Nicolas Markey)>>url:ftp://dante.ctan.org/tex-archive//info/bibtex/tamethebeast/ttb_en.pdf||style="text-decoration: none;" shape="rect" class="ext-link"]]
	132	+* [[(% class="icon" %) (%%)Eine Auflistung von BibTEX Styles>>url:http://www.reed.edu/cis/help/latex/bibtexstyles.html||style="text-decoration: none;" shape="rect" class="ext-link"]]
	133	+
	134	+==== Arbeit innerhalb des Lehrstuhl-Netzwerkes[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ArbeitinnerhalbdesLehrstuhl-Netzwerkes||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	135	+
	136	+Beim Arbeiten im Lehrstuhl-Netzwerk werden keine zusätzlichen Maßnahmen notwendig; der LaTeX-Zugriff auf die BibTeX-Datenbank ist automatisch über das Netzwerk gewährleistet. Für verändernde Zugriffe auf die Datenbank muss mit [[Subversion >>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Subversion||style="text-decoration: none;" shape="rect" class="wiki"]]gearbeitet werden.
	137	+
	138	+==== Arbeit außerhalb des Lehrstuhl-Netzwerkes[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ArbeitaußerhalbdesLehrstuhl-Netzwerkes||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	139	+
	140	+Beim Arbeiten außerhalb des Lehrstuhl-Netzes wird es notwendig die Datenbank dem lokal installierten LaTeX-System zur Verfügung zu stellen. Eventuell muss die dazugehörige kpse-Datenbank reinitialisiert werden. Für verändernde Zugriffe auf die Datenbank muss mit [[Git>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Git||style="text-decoration: none;" shape="rect" class="wiki"]] gearbeitet werden.
	141	+
	142	+==== Zugriff auf das Git-Repository der BibTeX-Datenbank[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ZugriffaufdasGit-RepositoryderBibTeX-Datenbank||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	143	+
	144	+Für Zugriff auf das [[Git-Repository >>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Git||style="text-decoration: none;" shape="rect" class="wiki"]]der BibTeX-Datenbank ist folgender Befehl zu verwenden
	145	+
	146	+>git clone git@…:resources/bib.git
	147	+
	148	+Nach dem Auschecken des Moduls bib steht die Datei cau-rt.bib zur Verfügung. Hinweise zur genauen Syntax sind dem Kopf der Datei und den Beschreibungen der BibTeX-Sprache zu entnehmen.
	149	+
	150	+==== Publishing the thesis on-line[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Publishingthethesison-line||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ====
	151	+
	152	+If your advisor has agreed that your thesis should be made available on-line, and you have signed your [[(% class="icon" %) (%%)consent>>url:http://www.informatik.uni-kiel.de/fileadmin/arbeitsgruppen/realtime_embedded/misc/Einverstaendniserklaerung.doc||style="text-decoration: none;" shape="rect" class="ext-link"]], then you can publish this as follows. Say your thesis is xyz-bt.pdf. ("bt" for Bachelor theses, "mt" for Master theses, "diss" for dissertations.) To upload this, use the command
	153	+
	154	+>scp xyz-bt.pdf biblio@…:/home/biblio/public_html/downloads/theses
	155	+
	156	+If you don't have the right permissions to do this, ask your advisor or the [[System Administrator >>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/System_Administrator||style="text-decoration: none;" shape="rect" class="wiki"]]to publish this for you.
	157	+
	158	+Then, check that your thesis is indeed available under the URL
	159	+
	160	+>[[(% class="icon" %) (%%)http:~~/~~/rtsys.informatik.uni-kiel.de/~~~~biblio/downloads/theses/xyz-bt.pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/theses/xyz-bt.pdf||style="text-decoration: none;" shape="rect" class="ext-link"]]
	161	+
	162	+Note: The name of this file should follow the canonical naming scheme used in subversion ([[Subversion/Structure >>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Subversion/Structure||style="text-decoration: none;" shape="rect" class="wiki"]]), even if your thesis is for some reason not in the subversion system.
	163	+
	164	+=== Source Code[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#SourceCode||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===
	165	+
	166	+Von Ihnen im Laufe der Arbeit entwickelte Software (oder Hardware-Beschreibungen) sind Teil Ihrer Arbeit. Dies bedeutet: Die Software sollte als Listing in Ihrer Ausarbeitung erscheinen; typischerweise (wenn es sich um mehr als ca. zwei Seiten handelt) als Anhang, mit angemessen kleiner Schriftgröße, evt. zweispaltig. Es sollte eine Übersicht über die Software in geeigneter Form gegeben werden, z.B. in Form von Klassendiagrammen mit Erläuterungen. Hinweise zum Einbinden von Code in LaTeX finden sich in dem[[(% class="icon" %) (%%)Beispieldokument>>url:http://www.informatik.uni-kiel.de/~~rt-kiel/kiel/documents/papers/example.tar.gz||style="text-decoration: none;" shape="rect" class="ext-link"]] (s.o.).
	167	+
	168	+== Hinweise zur Benotung[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#HinweisezurBenotung||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
	169	+
	170	+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.“
	171	+
	172	+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.
	173	+
98	98	|(((
99	99	**Merkmal**
100	100	)))|(((
...	...	@@ -115,7 +115,7 @@
115	115	)))|(((
116	116	Lösung von Teilproblemen
117	117	)))|(((
118		-Vollständige Lösung; gutes Vertrauen in die Lösung
	194	+Vollständige Lösung; gutes Vertauen in die Lösung
119	119	)))|(((
120	120	Vollständige, gute Lösung und Behandlung zusätzlicher Fragestellungen
121	121	)))|(((
...	...	@@ -159,9 +159,9 @@
159	159	max. 24
160	160	)))
161	161	|(((
162		-//Interaktion mit Betreuer//
	238	+//Anwesenheit und Interaktion mit Betreuer//
163	163	)))|(((
164		-Interaktion nur auf Initiative des Betreuers; schwer erreichbar; selten anwesend, weist nicht auf Probleme hin
	240	+Selten anwesend, Interaktion nur auf Initiative des Betreuers; schwer erreichbar; weist nicht auf Probleme hin
165	165	)))|(((
166	166	Unregelmäßige Interaktion, jedoch generell erreichbar und häufig anwesend
167	167	)))|(((
...	...	@@ -207,7 +207,7 @@
207	207	max. 16
208	208	)))
209	209	|(((
210		-//Aufbau und sprachliche Qualität der Ausarbeitung//
	286	+//Qualität der Ausarbeitung//
211	211	)))|(((
212	212	Ausarbeitung mit schweren Mängeln: fehlende Systematik, Schreibfehler, schlechtes Deutsch, unübersichtliche Verzeichnisse usw.
213	213	)))|(((
...	...	@@ -246,7 +246,6 @@
246	246
247	247	Die Umrechnung einer Punktzahl in eine Zensur ergibt sich unter Anwendung dieses Katalogs aus der folgenden Tabelle.
248	248
249		-(% class="wrapped" %)
250	250	|(((
251	251	Note
252	252	)))|(((
...	...	@@ -294,8 +294,10 @@
294	294	24
295	295	)))
296	296
297		-= Further Links =
	372	+== Weiterführende Hinweise[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#WeiterführendeHinweise||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
298	298
299		-* „Einige typographische Grundregeln und ihre Umsetzung in LaTeX“ by [[Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||shape="rect" style="text-decoration: none;" class="ext-link"]] (TU Braunschweig), [[PDF>>https://www2.informatik.hu-berlin.de/sv/lehre/typographie.pdf||shape="rect"]]
300		-* „Anmerkungen zur Rechtschreibung“ by [[Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||shape="rect" style="text-decoration: none;" class="ext-link"]] (TU Braunschweig), [[PDF>>https://silo.tips/download/anmerkungen-zur-rechtschreibung||shape="rect"]]
301		-* 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"]]".
	374	+* Eine sehr zu empfehlende, einführende Veranstaltung zur Präsentation und Erstellung wissenschaftlicher Arbeiten („Dokumentieren und Präsentieren“) bietet regelmäßig (ca. alle zwei Jahre) Prof. Luttenberger am Lehrstuhl für [[(% class="icon" %) (%%)Kommunikationssysteme>>url:http://www.comsys.informatik.uni-kiel.de/||style="text-decoration: none;" shape="rect" class="ext-link"]] an.
	375	+* „Einige typographische Grundregeln und ihre Umsetzung in LaTeX“ von [[(% class="icon" %) (%%)Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||style="text-decoration: none;" shape="rect" class="ext-link"]] (TU Braunschweig), [[(% class="icon" %) (%%)PDF>>url:http://www.cs.tu-bs.de/ips/struck/unitext/typographie.pdf||style="text-decoration: none;" shape="rect" class="ext-link"]]
	376	+* „Anmerkungen zur Rechtschreibung“ von [[(% class="icon" %) (%%)Werner Struckmann>>url:http://www.cs.tu-bs.de/ips/struck/index.html||style="text-decoration: none;" shape="rect" class="ext-link"]] (TU Braunschweig), [[(% class="icon" %) (%%)PDF>>url:http://www.ips.cs.tu-bs.de/struck/unitext/rechtschreibung.pdf||style="text-decoration: none;" shape="rect" class="ext-link"]]
	377	+* Falls Sie die Arbeit auf englisch verfassen: eine Reihe guter Ratschläge und weiterer Querverweise (wie z.B. den klassischen Strunk & White) finden sich auf [[(% class="icon" %) (%%)Henning Schulzrinnes>>url:http://www.cs.columbia.edu/~~hgs/||style="text-decoration: none;" shape="rect" class="ext-link"]] Seite „[[(% class="icon" %) (%%)Writing Technical Articles>>url:http://www.cs.columbia.edu/~~hgs/etc/writing-style.html||style="text-decoration: none;" shape="rect" class="ext-link"]]“.
	378	+* [[(% class="icon" %) (%%)Wie schreibe ich eine gute Diplomarbeit?>>url:http://www.informatik.uni-oldenburg.de/studium/azwa/wie.html||style="text-decoration: none;" shape="rect" class="ext-link"]] - Eine Anleitung der Uni-Oldenburg, z.T. spezifisch für Oldenburg; auch dort gibt es noch weiterführende Links.

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-6160527
	1	+7700982

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/6160527/Writing and Grading Theses
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/7700982/Writing and Grading Theses