Writing and Grading Theses

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

3

**Table of Contents**

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.

12

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"]] =

14

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.

16

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".

18

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.

20

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.

22

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.

24

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"]] =

26

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:

|=(((

Aktion

)))|=(((

Masterarbeit/Diplomarbeit

33

)))|=(((

34

Bachelorarbeit/Studienarbeit

)))|=(((

Idee

)))

|(((

Gliederung

)))|(((

3 Monate vor Abgabe

)))|(((

6 Wochen vor Abgabe

)))|(((

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.

)))

|(((

1-2 Probekapitel

)))|(((

4 Wochen vor Abgabe

)))|(((

3 Wochen vor Abgabe

)))|(((

Probekapitel sollen grundsätzliche stilistische Probleme zeigen und verhindern, dass bei der Endkorrektur alles grundsätzlich anders gemacht werden muss.

)))

|(((

Komplette Arbeit

)))|(((

2 Wochen vor Abgabe

)))|(((

10 Tage vor Abgabe

)))|(((

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.

64

)))

65

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.

67

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"]] =

69

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.

71

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"]] =

73

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"]] ==

75

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.

77

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.

79

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.

81

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.

83

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"]] ==

85

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.

87

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"]] ===

89

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"]] ====

91

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}

\usepackage{bibgerm}

.

.

.

\bibliographystyle{gerplain}

}}}

Links zu BibTeX:

* [[(% 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.

|(((

**Merkmal**

)))|(((

)))|(((

)))|(((

)))|(((

)))|(((

**Punkte**

)))

|(((

//Qualität der Lösung//

189

)))|(((

190

Lediglich Lösungsansätze; geringes Vertrauen in die Lösung

191

)))|(((

192

Lösung von Teilproblemen

193

)))|(((

194

Vollständige Lösung; gutes Vertauen in die Lösung

195

)))|(((

196

Vollständige, gute Lösung und Behandlung zusätzlicher Fragestellungen

)))|(((

)))

|(((

Punkte

)))|(((

1 - 7

)))|(((

8 - 14

)))|(((

15 - 21

)))|(((

22 - 28

)))|(((

max. 28

)))

|(((

//Wissenschaftliche Arbeitstechnik//

215

)))|(((

216

Systemlose Durchführung; nur Literatur aus dem engsten Umfeld

217

)))|(((

218

Entwicklung einer Systematik erst nach Drängen des Betreuers; geringes Literaturvolumen

219

)))|(((

220

Selbständige Aufarbeitung der relevanten Literatur; grobe Einordung der Ergebnisse in das wissenschaftliche Umfeld

221

)))|(((

222

Selbständige und strukturierte Erfassung des Standes der Technik und der Literatur; systematische Einordung der Ergebnisse

)))

|(((

Punkte

)))|(((

1 - 6

)))|(((

7 - 12

)))|(((

13 - 18

)))|(((

19 - 24

)))|(((

max. 24

)))

|(((

//Anwesenheit und Interaktion mit Betreuer//

239

)))|(((

240

Selten anwesend, Interaktion nur auf Initiative des Betreuers; schwer erreichbar; weist nicht auf Probleme hin

241

)))|(((

242

Unregelmäßige Interaktion, jedoch generell erreichbar und häufig anwesend

243

)))|(((

244

Regelmäßige, selbst initiierte Interaktion; Stand der Arbeit generell nachvollziehbar

245

)))|(((

246

Informiert Betreuer regelmäßig über Stand der Arbeit; weist umgehend auf aufgetretene Probleme oder erreichte Zwischenziele hin; regelmäßige Anwesenheit

)))

|(((

Punkte

)))|(((

1 - 4

)))|(((

5 - 8

)))|(((

9 - 12

)))|(((

13 - 16

)))|(((

max. 16

)))

|(((

//Eigeninitiative und Zielstrebigkeit//

263

)))|(((

264

Geht schwierigen Problemen aus dem Weg; mangelnder zeitlicher Einsatz; Zeitplan wird deutlich überzogen

265

)))|(((

266

Teilweise Eigeninitiative; Zeitplan im Wesentlichen eingehalten

267

)))|(((

268

Ziel wurde mit großer Eigeninitiative erreicht; Zeitplan wurde eingehalten

269

)))|(((

270

Eigeninitiative bei der Entwicklung der Thematik, auch bei schwierigen Problemen; Zielbewusste Zeiteinteilung

)))

|(((

Punkte

)))|(((

1 - 4

)))|(((

5 - 8

)))|(((

9 - 12

)))|(((

13 - 16

)))|(((

max. 16

)))

|(((

//Qualität der Ausarbeitung//

287

)))|(((

288

Ausarbeitung mit schweren Mängeln: fehlende Systematik, Schreibfehler, schlechtes Deutsch, unübersichtliche Verzeichnisse usw.

289

)))|(((

290

Nur teilweise systematische Darstellung der Ergebnisse; Weitschweifigkeiten oder Knappheiten, aber akzeptable Gestaltung

291

)))|(((

292

Systematische, einleuchtende Gliederung, aber leichte Schwächen in Sprache und Gestaltung

293

)))|(((

294

Systematische Gliederung, flüssige Sprache, Bilder mit klarer Aussage, deutliche Darlegung der Zusammenhänge und Ergebnisse

)))

|(((

Punkte

)))|(((

1 - 4

)))|(((

5 - 8

)))|(((

9 - 12

)))|(((

13 - 16

)))|(((

max. 16

)))

|(((

)))|(((

)))|(((

)))|(((

)))|(((

**Summe**

)))|(((

max. 100

)))

Die Umrechnung einer Punktzahl in eine Zensur ergibt sich unter Anwendung dieses Katalogs aus der folgenden Tabelle.

|(((

Note

)))|(((

1,0

)))|(((

1,3

)))|(((

1,7

)))|(((

2,0

)))|(((

2,3

)))|(((

2,7

)))|(((

3,0

)))|(((

3,3

)))|(((

3,7

)))|(((

4,0

)))

|(((

Mindestpunktzahl

)))|(((

96

)))|(((

88

)))|(((

80

)))|(((

72

)))|(((

64

)))|(((

56

)))|(((

48

)))|(((

40

)))|(((

32

)))|(((

24

)))

== 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"]] ==

373

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.

Wiki source code of Writing and Grading Theses

Navigation

Quick Links