Wiki source code of Writing and Grading Theses
Version 8.1 by Reinhard von Hanxleden on 2013/09/12 15:53
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 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** | ||
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | {{toc/}} | ||
| 8 | |||
| 9 | |||
| 10 | |||
| 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. | ||
| 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: | ||
| 28 | |||
| 29 | |=((( | ||
| 30 | Aktion | ||
| 31 | )))|=((( | ||
| 32 | Masterarbeit/Diplomarbeit | ||
| 33 | )))|=((( | ||
| 34 | Bachelorarbeit/Studienarbeit | ||
| 35 | )))|=((( | ||
| 36 | Idee | ||
| 37 | ))) | ||
| 38 | |((( | ||
| 39 | Gliederung | ||
| 40 | )))|((( | ||
| 41 | 3 Monate vor Abgabe | ||
| 42 | )))|((( | ||
| 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. | ||
| 46 | ))) | ||
| 47 | |((( | ||
| 48 | 1-2 Probekapitel | ||
| 49 | )))|((( | ||
| 50 | 4 Wochen vor Abgabe | ||
| 51 | )))|((( | ||
| 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. | ||
| 55 | ))) | ||
| 56 | |((( | ||
| 57 | Komplette Arbeit | ||
| 58 | )))|((( | ||
| 59 | 2 Wochen vor Abgabe | ||
| 60 | )))|((( | ||
| 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. | ||
| 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 | = Hinweise zur Ausarbeitung[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#HinweisezurAusarbeitung||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] = | ||
| 89 | |||
| 90 | == Umfang[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Umfang||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] == | ||
| 91 | |||
| 92 | Folgendes sind grobe Richtwerte für den Umfang der Arbeit, ohne Titelseite, Inhalts-/Abbildungsverzeichnis, leere Seiten, Bibliographie, Anhänge, etc. | ||
| 93 | |||
| 94 | * Studien-/Bachelorarbeit: 30-50 Seiten. | ||
| 95 | * Diplom-/Masterarbeit: 70-120 Seiten. | ||
| 96 | |||
| 97 | == Sprache der Arbeit[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#SprachederArbeit||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] == | ||
| 98 | |||
| 99 | Sie können die Arbeit auf Deutsch oder Englisch verfassen. Falls Sie die Arbeit nicht in Ihrer Muttersprache schreiben, wäre es hilfreich, wenn ein muttersprachlicher (oder ähnlich qualifizierter) Korrekturleser Ihre Arbeit auf sprachliche Richtigkeit korrigieren könnte, bevor Sie die Arbeit Ihrem Betreuer geben. | ||
| 100 | |||
| 101 | Software sollte generell auf Englisch geschrieben werden - d.h., Kommentare, Variablen-/Klassen-/Paketnamen etc. sollten englisch sein. | ||
| 102 | |||
| 103 | === Hinweise für englischsprachige Arbeiten[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#HinweisefürenglischsprachigeArbeiten||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] === | ||
| 104 | |||
| 105 | * Lesen und beherzigen Sie Strunk & White (siehe unten). | ||
| 106 | * Lesen und beherzigen Sie Strunk & White (siehe unten). | ||
| 107 | * Lesen und beherzigen Sie Strunk & White (siehe unten). Außerdem: | ||
| 108 | * Sätze sollten nicht mit „But“ oder „And“ anfangen. Stattdessen: „However, ...“ bzw. „Furthermore, ...“. | ||
| 109 | |||
| 110 | (% style="margin-left: 60.0px;" %) | ||
| 111 | Schlecht: | ||
| 112 | |||
| 113 | (% style="margin-left: 60.0px;" %) | ||
| 114 | >„But this is of exponential complexity. And there is no known alternative.“ | ||
| 115 | |||
| 116 | (% style="margin-left: 60.0px;" %) | ||
| 117 | Gut: | ||
| 118 | |||
| 119 | (% style="margin-left: 60.0px;" %) | ||
| 120 | >„However, this is of exponential complexity. Furthermore, there is no known alternative.“ | ||
| 121 | |||
| 122 | * Die Verwendung des Wortes „like“ im Sinne von „such as“ ist umgangssprachlich und sollte vermieden werden. In noch stärkerem Maße gilt dies für die Bedeutung „as if“. | ||
| 123 | |||
| 124 | (% style="margin-left: 60.0px;" %) | ||
| 125 | Schlecht: | ||
| 126 | |||
| 127 | (% style="margin-left: 60.0px;" %) | ||
| 128 | >„I, like you, like fast algorithms, like Tarjan's algorithm, ... He uses a sorting algorithm of quadratic complexity, like there is no alternative.“ | ||
| 129 | |||
| 130 | (% style="margin-left: 60.0px;" %) | ||
| 131 | Gut: | ||
| 132 | |||
| 133 | (% style="margin-left: 60.0px;" %) | ||
| 134 | >„I, like you, like fast algorithms, such as Tarjan's algorithm, ... He uses a sorting algorithm of quadratic complexity, as if there were no alternative.“ | ||
| 135 | |||
| 136 | * Mit „which“ wird eine Ergänzung gekennzeichnet, welche in Kommata eingeschlossen wird und deren Streichung nicht sinnentstellend wirkt. Mit „that“ wird eine nähere Identifizierung gekennzeichnet, welche nicht gestrichen werden kann. Und: vor „that“ steht kein Komma! | ||
| 137 | |||
| 138 | (% style="margin-left: 60.0px;" %) | ||
| 139 | Schlecht: | ||
| 140 | |||
| 141 | (% style="margin-left: 60.0px;" %) | ||
| 142 | >„I told him, that the quicksort algorithm that is very fast is used by the program, which I installed yesterday.“ | ||
| 143 | |||
| 144 | (% style="margin-left: 60.0px;" %) | ||
| 145 | Gut: | ||
| 146 | |||
| 147 | (% style="margin-left: 60.0px;" %) | ||
| 148 | >„I told him that the quicksort algorithm, which is very fast, is used by the program that I installed yesterday.“ | ||
| 149 | |||
| 150 | * Im allgemeinen werden die Wörter „section“, „figure“ etc. klein geschrieben, falls sie nicht am Satzanfang stehen. Falls jedoch eine spezifische Einheit gemeint und durch eine Nummerierung kenntlich gemacht ist, werden diese Wörter groß geschrieben. | ||
| 151 | |||
| 152 | (% style="margin-left: 60.0px;" %) | ||
| 153 | Schlecht: | ||
| 154 | |||
| 155 | (% style="margin-left: 60.0px;" %) | ||
| 156 | >„The following Section illustrates .... In section 2.3, we describe .... This Chapter includes too many Sections.“ | ||
| 157 | |||
| 158 | (% style="margin-left: 60.0px;" %) | ||
| 159 | Gut: | ||
| 160 | |||
| 161 | (% style="margin-left: 60.0px;" %) | ||
| 162 | >„The following section illustrates .... In Section 2.3, we describe .... This chapter includes too many sections.“ | ||
| 163 | |||
| 164 | == Allgemeine Hinweise[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AllgemeineHinweise||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] == | ||
| 165 | |||
| 166 | Grundsätzlich steht es Ihnen frei, wie Sie Ihre Arbeit erstellen - mit [[(% class="icon" %) (%%)LaTeX>>url:http://de.wikipedia.org/wiki/LaTeX||style="text-decoration: none;" shape="rect" class="ext-link"]] oder einem Office-Paket (oder auch handschriftlich). Es wird jedoch dringend nahe gelegt, LaTeX zu verwenden, da hiermit auch größere Arbeiten mit umfangreichen Querverweisen etc. (relativ) problemlos zu erstellen sind und ein konsistent gutes Layout erzeugt werden kann. Auch gibt es hierzu eine recht umfassende technische Unterstützung, incl. Templates und einer gemeinsam gepflegten Bibliographie-Datenbank. In folgenden Hinweisen wird deswegen angenommen, dass Sie LaTeX verwenden, sowie BibTeX für die Bibliographie. Beides wird weiter unten erläutert. | ||
| 167 | |||
| 168 | Das Layout Ihrer Arbeit sollte der Kiel Computer Science Series (KCSS) entsprechen. Auf der [[KCSS-Seite>>url:http://www.informatik.uni-kiel.de/kcss/||shape="rect"]] sind ein LaTeX-Stylefile und umfangreiche Dokumentation hierzu verfügbar. | ||
| 169 | |||
| 170 | Sollten Sie nicht LaTeX verwenden, bzw. nicht den KCSS-Style, ist eine technische Unterstützung Ihrer Arbeit nur eingeschränkt möglich. | ||
| 171 | |||
| 172 | ==== Rechtschreibprüfung[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Rechtschreibprüfung||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 173 | |||
| 174 | Lassen Sie von Zeit zu Zeit eine Rechtschreibprüfung über ihren Text laufen; dies ist auch für .tex-Dateien möglich. Insbesondere sollte dies geschehen bevor Sie Ihre Arbeit jemand anderem zum Lesen/Korrigieren/Bewerten geben. Ein möglicher Spellchecker ist aspell. | ||
| 175 | |||
| 176 | [[Texlipse>>url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Texlipse||style="text-decoration: none;" shape="rect" class="wiki"]] unterstützt auch on-the-fly spell checking. | ||
| 177 | |||
| 178 | In Emacs (oder Xemacs - generell wird hier nicht zwischen diesen Editoren unterschieden) wird die Rechtschreibprüfung eines Buffers, welcher eine .tex-Datei enthalten kann, mit dem Befehl ispell-buffer gestartet. Der zu verwendende Spellchecker wird durch die Variable ispell-program-name definiert (Default: aspell). Das zu verwendende Wörterbuch wird durch die Variable ispell-dictionary definiert (z.B. deutsch8 oder american), welche durch den Befehl ispell-change-dictionary gesetzt werden kann. | ||
| 179 | |||
| 180 | Emacs kann das zu verwendende Wörterbuch auch automatisch für eine .tex-Datei festlegen, wenn die Datei die Variable ispell-dictionary über einen //Local Variables//-Kommentar definiert, welcher vom Emacs beim Einlesen einer Datei ausgewertet wird. Ein Beispiel für einen solchen Kommentar: | ||
| 181 | |||
| 182 | {{{ % Local Variables: | ||
| 183 | % mode: latex | ||
| 184 | % compile-command: "make cases2005.pdfv" | ||
| 185 | % ispell-dictionary: "american" | ||
| 186 | % End: | ||
| 187 | }}} | ||
| 188 | |||
| 189 | * Gründliches manuelles Lesen bleibt einem aufgrund Grammatik oder Zeichensetzungsfehlern nicht erspart. | ||
| 190 | * Möglichst auch einen zweiten, unabhängigen Korrekturleser heranziehen. | ||
| 191 | * Bei englischer Sprache ist möglichst ein //native speaker// als Korrekturleser heranzuziehen. | ||
| 192 | |||
| 193 | ==== Auszeichnungen - Allgemeines[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Auszeichnungen-Allgemeines||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 194 | |||
| 195 | Einzelne Textpassagen können //ausgezeichnet// werden. Grundsätzlich sollten Auszeichnungen in folgenden Gegebenheiten eingesetzt werden: | ||
| 196 | |||
| 197 | * Einführung/Definition neuer Begriffe - wie zum Beispiel „auszeichnen“ (und damit auch „Auszeichnung“) in obigem Absatz. | ||
| 198 | * Zitate. | ||
| 199 | * Teilüberschriften, evt. in den Fließtext integriert. | ||
| 200 | * Titel von Büchern, Zeitschriften //etc//. | ||
| 201 | * Beispiele, wenn diese - wie hier - in Form von (wenn auch fiktiven) Zitaten erscheinen. | ||
| 202 | * Hervorhebung von Kernpunkten. | ||
| 203 | * Fremdsprachige Textfragmente (siehe unten). | ||
| 204 | * Symbole, physikalische Größen usw. (siehe unten). | ||
| 205 | * Programme, Funktionsname usw. (siehe unten). | ||
| 206 | |||
| 207 | Man sollte sich beim Gebrauch von Auszeichnungen bewusst sein, dass diese ein besonderer Hinweis für den Leser sind und ihn zu besonderer Aufmerksamkeit veranlassen sollen. Sie bewirken stets eine - wenn auch minimale - Unterbrechung des Leseflusses. Auszeichnungen sollten systematisch und im Zweifelsfall eher sparsam eingesetzt werden. Zu //viele//Auszeichnungen //verhindern// das //flüssige Lesen// (und können auch etwas //akademisch// wirken). Es ist dann //schwierig// für den Leser zu //erkennen//, was //denn nun wirklich wichtig ist - insbesondere bei geschachtelten Auszeichnungen, möglicherweise mehrfach **überlagert**// !!!! | ||
| 208 | |||
| 209 | Bei Auszeichnungen sollte der //Scope// eingehalten werden. Wenn z.B. Begriffe und sowie deren Abkürzungen eingeführt werden, sollten diese einzeln ausgezeichnet werden - Klammerungen selbst sollten nicht ausgezeichnet werden. | ||
| 210 | |||
| 211 | Schlecht: | ||
| 212 | |||
| 213 | >„Die Message Sequence Charts (MSCs) sind ein Formalismus ...“ | ||
| 214 | |||
| 215 | Gut: | ||
| 216 | |||
| 217 | >„Die Message Sequence Charts (//MSCs//) sind ein Formalismus ...“ | ||
| 218 | |||
| 219 | In LaTeX werden Auszeichnungen mit dem Befehl \emph vorgenommen, welche dann normalerweise //kursiv// erscheinen. //In einem kursiv gesetzten Kontext - wie in den Beispielen hier - sind Auszeichnungen jedoch //nicht-kursiv//, um diese vom Kontext abzuheben.// | ||
| 220 | |||
| 221 | ===== Auszeichnung fremdsprachiger Ausdrücke[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AuszeichnungfremdsprachigerAusdrücke||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===== | ||
| 222 | |||
| 223 | Zunächst ein Beispiel für ein englischsprachiges Dokument: | ||
| 224 | |||
| 225 | Schlecht: | ||
| 226 | |||
| 227 | >„As Schmidt et al. have documented, this agreement today is a de-facto standard for layout etc.“ | ||
| 228 | |||
| 229 | Gut: | ||
| 230 | |||
| 231 | >„As Schmidt //et al//. have documented, this agreement today is a //de-facto// standard for layout //etc//.“ | ||
| 232 | |||
| 233 | Bei deutschsprachigen Dokumenten gilt: es sind grundsätzlich Begriffe ausgenommen, welche im Duden stehen (wie zum Beispiel „Layout“). Weiterhin wird bei Auszeichnungen die Groß-/Kleinschreibung der Fremdsprache übernommen. | ||
| 234 | |||
| 235 | Schlecht: | ||
| 236 | |||
| 237 | >„Wie Schmidt et al. dokumentiert haben, ist dieses Agreement heute de-facto ein Standard in layout etc.“ | ||
| 238 | |||
| 239 | Gut: | ||
| 240 | |||
| 241 | >„Wie Schmidt et al. dokumentiert haben, ist diese Vereinbarung heute de-facto ein Standard in Layout etc.“ | ||
| 242 | |||
| 243 | Eine spezielle Problematik bei deutschsprachigen Dokumenten in der Informatik ist, dass hier viele Begriffe aus dem Englischen kommen, und als Teil des deutschen Informatik-Fachvokabulars angesehen werden können, auch wenn diese noch nicht im Duden erscheinen. Diese Begriffe sollten dann nicht ausgezeichnet werden, damit die Lesbarkeit des Dokuments nicht durch übermäßige Auszeichnungen leidet. Im Zweifelsfall gilt: Wenn es für einen englischen Begriff keinen äquivalenten deutschen Begriff gibt, oder der deutsche Begriff in der Praxis seltener eingesetzt wird als der englische Begriff, sollte der englische Begriff als Teil des deutschen Fachvokabulars angesehen werden und auf eine Auszeichnung verzichtet werden. Dies betrifft auch Begriffe, welche nicht wirklich Fachbegriffe sind (wie z.B. „Feature“). Ebenso sollten Eigennamen von Formalismen, Programmiersprachen, Werkzeugen usw. nicht ausgezeichnet werden. In jedem Fall sollten Sie sich konsistent für oder gegen die Auszeichnung eines Begriffs im gesamten Dokument entscheiden; einzige Ausnahme ist die einmalige Auszeichnung eines Begriffes bei einer Begriffsdefinition. Zusammenfassend gilt: es ist oft im Ermessen des Autors, ob eine Auszeichnung verwendet werden soll oder nicht; im Zweifelsfall gilt das Gebot der Sparsamkeit, insbesondere, falls Sie einen einzelnen Begriff sehr häufig verwenden. | ||
| 244 | |||
| 245 | Schlecht: | ||
| 246 | |||
| 247 | >„Die Synthese von Statecharts nach Java .... Der Kellerspeicher vom Übersetzer ist hierfür standardmäßig zu klein. Diese software hat viele features und noch mehr bugs. [Aber:] Die Mental Map des Betrachters ....“ | ||
| 248 | |||
| 249 | Gut: | ||
| 250 | |||
| 251 | >„Die Synthese von Statecharts nach Java .... Der Stack des Compilers ist hierfür standardmäßig zu klein. Diese Software hat viele Features und noch mehr Bugs. [Aber:] Die mental map des Betrachters ....“ | ||
| 252 | |||
| 253 | Nach diesem Plädoyer für die sparsame Verwendung von Auszeichnungen bei originär englischen Ausdrücken noch ein Plädoyer für sparsame Verwendung englischer Ausdrücke, wenn es hierfür gängige und präzise Äquivalente im Deutschen gibt: | ||
| 254 | |||
| 255 | Schlecht: | ||
| 256 | |||
| 257 | >„Das Agreement war, die Action Items und die Schedule des nächsten Meetings in die Minutes zu pasten, und sich zum Matchen der Deadlines zu committen.“ | ||
| 258 | |||
| 259 | Gut: | ||
| 260 | |||
| 261 | >„Die Vereinbarung war, die Aktionspunkte und die Zeitplanung der nächsten Besprechung in das Protokoll zu übernehmen, und sich zur Einhaltung der Termine zu verpflichten.“ | ||
| 262 | |||
| 263 | In der Informatik ist dies oft eine schwierige Balance zwischen zu viel und zu wenig deutsch, welche letztlich eine Sache des persönlichen Geschmacks ist. So scheint „Übersetzer“ ebenso akzeptabel wie „Compiler“, „Betriebssystem“ mehr verbreitet als „Operating System“, jedoch wirkt „Kellerspeicher“ eher verschroben im Vergleich zu „Stack“. | ||
| 264 | |||
| 265 | ===== Auszeichnung von Symbolen, physikalischen Größen usw.[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AuszeichnungvonSymbolenphysikalischenGrößenusw.||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===== | ||
| 266 | |||
| 267 | Neben den bereits erwähnten Fällen, in welchen Textbestandteile ausgezeichnet werden sollten, sollten auch Mathematische Symbole, Mengenbezeichner, physikalische Größen etc. ausgezeichnet werden. In LaTeX kann man hierfür, wie bereits erwähnt, den Befehl \emph{...} verwenden - oder alternativ den Begriff mit „$...$“ auszeichnen. Letzterer Mechanismus ist jedoch mit etwas Vorsicht zu verwenden, falls die Begriffe mehr als ein Zeichen lang sind, da dieser Mechanismus den Begriff als mathematische Formel interpretiert und spezielle Richtlinien für dessen Layout verwendet. Insbesondere wird der Buchstabe f als eigenständiger Funktionsname interpretiert und ein entsprechender Zwischenraum produziert, was generell nicht erwünscht ist. | ||
| 268 | |||
| 269 | Schlecht: | ||
| 270 | |||
| 271 | >„Sei $Koffer$ die Menge der Koffer ...“ | ||
| 272 | |||
| 273 | Gut: | ||
| 274 | |||
| 275 | >„Sei \emph{Koffer} die Menge der Koffer ...“ | ||
| 276 | |||
| 277 | ===== Auszeichnung von Programmen, Funktionsnamen usw.[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AuszeichnungvonProgrammenFunktionsnamenusw.||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===== | ||
| 278 | |||
| 279 | Namen von Programmen sowie von Funktionsnamen, Variablennamen etc. sollten ebenfalls ausgezeichnet werden. Jedoch sollte man hierfür eine andere Auszeichnung verwenden, nämlich diejenige, welche auch in Programmlistings verwendet wird. Typischerweise ist dies typewriter (erzeugt mit \texttt{...}) oder SansSerif (erzeugt mit \textsf{...}). Ein Beispiel hierfür sind die in diesem Text erwähnten LaTeX-Befehle. | ||
| 280 | |||
| 281 | ==== Referenzierungen[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Referenzierungen||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 282 | |||
| 283 | Verwenden Sie Referenzierungen im Ihrer Arbeit so, dass sie kein grammatikalischer Bestandteil des Satzes sind - der Text sollte auch nach Eliminieren aller geklammerten Bestandteile, einschließlich der in eckigen Klammern befindlichen Referenzen, noch grammatikalisch korrekt sein. Üblicherweise erreicht man dies durch die Nennung der Autoren eines Werkes, gefolgt von der Referenz. Im Text sollten Autoren typischerweise ohne Vornamen genannt werden (jedoch sollten Autorenvornamen bei den Referenzen selbst vollständig genannt werden, siehe unten). Bei mehreren Autoren sollten entweder alle genannt werden, oder es sollte die Existenz weiterer Autoren durch „et al.“ kenntlich gemacht werden. | ||
| 284 | |||
| 285 | Schlecht: | ||
| 286 | |||
| 287 | >„Wie in [42] beschrieben, ...“ | ||
| 288 | |||
| 289 | Gut: | ||
| 290 | |||
| 291 | >„Wie von Harel //et al//. [42] beschrieben, ...“ | ||
| 292 | |||
| 293 | Die Referenzen selbst sollten vollständig sein - also mehr sein als eine Sammlung von Suchbegriffen für google. Grundsätzlich sollten Angaben so vollständig wie möglich sein. So gehören z.B. zu einer Artikelreferenz nicht nur Autoren und Titel des Artikels, sondern auch bei Jahr/Monat des Erscheinens, bei Journalartikeln auch Name des Journals und gegebenenfalls Nummer und Herausgeber, sowie bei Tagungs-/Workshopartikeln der Name und Ort der Tagung. Vermeiden Sie Abkürzungen. Tagungsnamen sollten sowohl in ausgeschriebener Form als auch mit ihrem Kürzel genannt werden. | ||
| 294 | |||
| 295 | Schlecht: | ||
| 296 | |||
| 297 | >„A. Mooij and N. Goga and J. Romijn. Non-local Choice and Beyond: Intricacies of MSC Choice Nodes. FASE'05, pages 273-288, 2005.“ „A. Mooij and N. Goga and J. Romijn. Non-local Choice and Beyond: Intricacies of MSC Choice Nodes. In Fundamental Approaches to Software Engineering, pages 273-288, April 2005.“ | ||
| 298 | |||
| 299 | Gut: | ||
| 300 | |||
| 301 | >„Arjan J. Mooij and Nicolae Goga and Judi Romijn. Non-local Choice and Beyond: Intricacies of MSC Choice Nodes. In Fundamental Approaches to Software Engineering (FASE '05), pages 273-288, Edinburgh, Scotland, April 2005.“ | ||
| 302 | |||
| 303 | Achten Sie auf die **Konsistenz** der Einträge. So sollten z.B. alle Referenzen für ein Journal dieses Journal gleich referenzieren. Autoren sollten so referenziert werden, wie sie in der referenzierten Arbeit erscheinen; so sollten Vornamen nicht abgekürzt werden, wenn sie in der Arbeit selbst ausgeschrieben sind, ebenso sollten angegebene Mittelinitialen übernommen werden. Bei der Verwendung von URLs sollten Sie darauf achten, dass diese nicht über den Satzspiegel hinausragen; das Paket breakurl sorgt für den entsprechenden Zeilenumbruch von URLs. | ||
| 304 | |||
| 305 | Schlecht: | ||
| 306 | |||
| 307 | >[1] Alur, Etessami, and Yannakakis. Inference of message sequence charts. //IEEETSE: IEEE Transactions on Software Engineering//, 29, 2003. | ||
| 308 | |||
| 309 | >[2] Alan W. Biermann and Ramachandran Krishnaswamy. Constructing programs from example computations. IEEE Transactions on Software Engineering, 2(3):141-153, September 1976. | ||
| 310 | |||
| 311 | Gut: | ||
| 312 | |||
| 313 | >[1] Rajeev Alur, Kousha Etessami, and Mihalis Yannakakis. Inference of message sequence charts. //IEEE Transactions on Software Engineering//, 29:304NAK313, 2003. | ||
| 314 | |||
| 315 | >[2] Alan W. Biermann and Ramachandran Krishnaswamy. Constructing programs from example computations. //IEEE Transactions on Software Engineering//, 2(3):141-153, September 1976. | ||
| 316 | |||
| 317 | Die Bibliographie sollte nach Nachnamen des Erstautors sortiert sein. Bei der (stark empfohlenen) Verwendung von BibTeX sollten Sie für jede Referenz den richtigen, möglichst spezifischen Referenztyp verwenden (z.B. @InProceedings statt @Misc). Die für den jeweiligen Referenztyp vorgesehenen Pflichtfelder geben bereits einen ersten Hinweis für die Mindestinformationen; die weiteren optionalen Eintragsfelder sollten aber auch so weit wie möglich verwendet werden. Falls bibtex bei Erzeugung der Referenzen einen Fehler meldet, z.B. aufgrund eines fehlenden Pflichtfeldes, sollte dieses auf alle Fälle korrigiert werden. Für Ihre Arbeitserleichterung sollten Sie ein konsistentes Schema für die Indizierung verwenden, so dass Sie den Index möglichst aus Autoren & Erscheinungsjahr erschließen können, und Referenzierungen in Ihren Text einfügen können, ohne den Index in der BibTeX-Datei nachsehen zu müssen. Die Verwendung eines bestimmten Schemas ist insbesondere dann erforderlich, falls Sie eine gemeinsam genutzte BibTeX-Datei bearbeiten. So gibt z.B. die am Lehrstuhl genutzte cau-rt.bib-Datei ein Schema vor, welches am Anfang dieser Datei beschrieben ist. | ||
| 318 | |||
| 319 | * Literaturangaben möglichst als integrierten Teil des Satzes (nicht außerhalb des Satzes anbringen). | ||
| 320 | * Literaturangaben keinesfalls hinter das Satzendzeichen (z.B. nach dem Punkt). | ||
| 321 | * Auch in Abbildungen, die nicht selbst/selbständig erstellt wurden darf die Literaturangabe nicht fehlen (z.B. //(nach Schmidt [3])//). | ||
| 322 | * Für URLs, Verweise auf Webseiten (z.B. [[www.eclipse.org>>url:http://www.eclipse.org||shape="rect"]]) eignen sich am besten Fußnoten. | ||
| 323 | * Bib-Eintränge kontrollieren (Titel, Autoren (durch and getrennt, nicht kommasepariert!), Datum, Ort!). | ||
| 324 | * Bib-Einträge: Wörter, die groß geschrieben werden sollten in geschweifte Klammern setzen. | ||
| 325 | * Bib-Einträge auf Englisch oder Deutsch (je nach Arbeit!). | ||
| 326 | * Literaturangaben nicht als Nomen in den Satz einbetten. | ||
| 327 | Merkregel: Der Satz sollte sich auch ohne die Literaturangabe sinnvoll lesen lassen. | ||
| 328 | * Nur Primärliteratur oder (bewährte) Fachbücher: Z.B. keine Foliensätze/Lectures referenzieren. | ||
| 329 | |||
| 330 | ==== Aufbau und Inhalt[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AufbauundInhalt||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 331 | |||
| 332 | * //Ziel der Arbeit// wirklich auf den Punkt bringen (ca. 1/2 bis 3/4 Seite). | ||
| 333 | * Neue Begriffe (die einem Informatiker nicht allgemein bekannt sind) an geeigneter Stelle einführen, bevor man sie verwendet (z.B. Definitionen). | ||
| 334 | * Jedes Kapitel sollte eine Einleitung haben. | ||
| 335 | * Überleitungen von jedem Teil in den anderen, eine sinnvolle Reihenfolge ist notwendig und erleichtert dies. | ||
| 336 | * Schwammige Begriffe und Füllwörter vermeiden bzw. weglassen. | ||
| 337 | ** Füllsätze ebenfalls vermeiden. | ||
| 338 | * Einheitliche/konsistente Begriffe verwenden, bei neu eingeführten Begriffen auf Synonyme verzichten. | ||
| 339 | * Keine Umgangssprache verwenden, möglichst auf Fachbegriffe zurückgreifen. | ||
| 340 | * Von Strukturierungselementen wie \itemize, \enumerate, \description sinnvoll Gebrauch machen. | ||
| 341 | * Grafiken zur Veranschaulichung nutzen (z.B. Aktivitätsdiagramme, Klassendiagramme, Tabellen). | ||
| 342 | ** Diese können auch für evtl. Präsentationen wiederverwendet werden. | ||
| 343 | * Beim Erklären von Zusammenhängen zunächst abstrahieren und erst später konkret werden. | ||
| 344 | |||
| 345 | ===== Kapitel[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Kapitel||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ===== | ||
| 346 | |||
| 347 | 1. **Abstract**: Beschreibt den Inhalt Arbeit abstrakt und kompakt, soll einem Leser eine Entscheidungshilfe dabei sein, ob die Arbeit für ihn lesenswert ist oder nicht. | ||
| 348 | 1. **Einleitung**: In das Thema einführen, Ziele der Arbeit beschreiben, Ausblick/Kapitelübersicht geben. | ||
| 349 | 1. **Verwandte Arbeiten**: Arbeiten mit ähnlichen/angrenzenden Themen in Bezug zur Arbeit setzen. | ||
| 350 | 1. **Verwendete Technologien**: Optional, Techniken und Technologien soweit für das Verständnis nötig beschreiben. | ||
| 351 | 1. **Ideen**: Vom Ist-Zustand ausgehend die Probleme erörtern, Lösungsansätze auch mit Verweis auf verwandte Arbeiten diskutieren und den eigenen Lösungsweg stichhaltig begründen, hier zunächst die nötige Abstraktion wahren und erst im Verlauf konkreter werden, Implementierungsdetails sind hier irrelevant. | ||
| 352 | 1. **Implementierung**: Mit Verweis auf den eigenen Lösungsweg, soll hier die Implementierung zunächst mit der Struktur beginnend (Begründung!) und an sinnvollen Stellen auch mit konkretem Anwendungscode/Beispielen beschrieben werden. | ||
| 353 | 1. **Evaluation**: Optional, Vergleich der Implementierung oder des Lösungsweges mit anderen Ansätzen, Experimente, Auswertung, Bewertung. | ||
| 354 | 1. **Zusammenfassung, Fazit, Ausblick**: Fasst die Probleme und vor allem die aufgezeigten Lösungen/Ergebnisse zusammen und beschreibt als Ausblick auch Erweiterungsmöglichkeiten, Schließt mit einem knappen und für die Arbeit aussagekräftigen Fazit. | ||
| 355 | |||
| 356 | |||
| 357 | |||
| 358 | ==== Akronyme[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Akronyme||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 359 | |||
| 360 | * Das Akronympaket ist zu verwenden (z.B. \ac{kieler}). | ||
| 361 | * Indentierung bei Akronymverzeichnis ist einheitlich und linksbündig zu gestalten. | ||
| 362 | * In Überschriften (gilt auch für Bildunterschriften) explizit die Langform verwenden (\acl). Achtung: Hier darauf achten, daß das Akronym im Text dennoch eingeführt wird! | ||
| 363 | * Ausnahmeregelung: Allgemein bekannte Abkürzungen wie GUI. Hier die Langform gar nicht verwenden. | ||
| 364 | * Akronyme konsistent halten. | ||
| 365 | * Allgemein übliche Akronyme nicht so üblichen Akronymen vorziehen. | ||
| 366 | * Akronyme niemals trennen. | ||
| 367 | |||
| 368 | ==== Abbildungen und Listings[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AbbildungenundListings||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 369 | |||
| 370 | |||
| 371 | |||
| 372 | * Größe: Nicht unter 80% der Seitenbreite, möglichst 100% (Textbreite ausnutzen!) | ||
| 373 | * Ähnliche Abbildungen sollten auch vergleichbar/gleich groß sein. | ||
| 374 | * Schriftgröße in Abbildungen sollte ca. der Schriftgröße des Textes entsprechen. | ||
| 375 | * Wenn Textteile der Abbildung im Text zitiert werden, ist auf ein konsistentes Schriftbild zu achten, ggf. \sf verwenden. | ||
| 376 | * Abbildungen immer mit Nummer und sinnvoller Überschrift versehen. | ||
| 377 | * Überschrift abstrakt und so kurz wie möglich, so lang wie nötig halten (es sollte ohne Lesen des Textes verständlich sein, was die Abbildung zeigt). | ||
| 378 | * Diagramme sollten i.d.R. eine Legende haben (Bedeutung von Farben/Formen nicht nur im Text erläutern). | ||
| 379 | * Abbildungen immer in der selben Reihenfolge im Dokument anordnen, in welcher sie im Text referenziert werden. | ||
| 380 | * Abbildungen möglichst immer in der Nähe des erklärenden Textes anordnen. | ||
| 381 | * Jede Abbildung muss auch beschrieben werden. | ||
| 382 | * Autolayout einsetzen für entsprechende Diagrammtypen (z.B. Klassendiagramm). | ||
| 383 | * Einheitliche Schriftgröße für alle Listings verwenden. | ||
| 384 | * Akronyme in Bildunterschriften s.o. | ||
| 385 | * Listings in Figures vermeiden (dies kann zu speziellen Latex-Problemen führen) | ||
| 386 | * Für Listings gilt allgemein entsprechendes. | ||
| 387 | |||
| 388 | |||
| 389 | |||
| 390 | ==== Verweise[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Verweise||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 391 | |||
| 392 | * Bezeichnung sollte korrekt sein: z.B. Kapitel 2, Unterkapitel 2.1, Abschnitt 2.3.4, Absatz | ||
| 393 | ** Nicht: z.B. Kapitel 2.1 | ||
| 394 | * Rückwärtsverweise sind ok, Vorwärtsverweise sind zu vermeiden. | ||
| 395 | * Zu viele Verweise stören den Lesefluss, wichtige Dinge sollten an geeigneter Stelle auch (evtl. kürzer) wiederholt werden. | ||
| 396 | * Abbildungen/Tabellen immer konkret benennen. | ||
| 397 | |||
| 398 | |||
| 399 | |||
| 400 | ==== Allgemeine Syntax[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#AllgemeineSyntax||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 401 | |||
| 402 | * Doppelpunkt als Teil des Satzes auffassen; nach //~:// sollte kein neuer Absatz beginnen. | ||
| 403 | * Hervorheben von Wörtern (\emph{}) möglichst selten einsetzen (s.o.). | ||
| 404 | * Fremdsprachenwörter kursiv hervorheben. | ||
| 405 | * Klammern vermeiden, sie stören den Lesefluss. | ||
| 406 | * Fußnoten vermeiden, sie stören den Lesefluss. | ||
| 407 | * Fußnoten für URLs sind ok. | ||
| 408 | * Möglichst auf Querseiten verzichten, sie stören den Lesefluss. | ||
| 409 | * Keine Einzelzeilen oder Überschriften vor oder nach einem Seitenumbruch stehen lassen. | ||
| 410 | * Es sollten keine Zeilen oder Abbildungen/Tabellen über den Rand hinausragen. | ||
| 411 | * Auf unnötigen Whitespace verzichten. | ||
| 412 | * Codefont für Funktionsnamen/Prozeduren/... verwenden und auch hier auf Konsistenz achten. | ||
| 413 | * LaTeX kennt keine Abkürzungs-Punkte. Z.B. Bei "e.g." oder "et al." ein xspace hinter dem letzten Punkt verwenden, da ansonsten ein zu großer Abstand zum nächsten Wort erzeugt wird (wie beim Satzende). | ||
| 414 | |||
| 415 | |||
| 416 | |||
| 417 | ==== Inhaltliches und Stilistisches[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#InhaltlichesundStilistisches||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 418 | |||
| 419 | * Füllwörter, Füllphrasen und Füllsätze vermeiden, z.B. | ||
| 420 | ** due to the fact that | ||
| 421 | ** in order to | ||
| 422 | * Zusammenhänge: "It" oder "This" vermeiden, wenn der Zusammenhang nicht wirklich eindeutig klar ist. In der Regel lieber den Bezug noch einmal explizit zum Ausdruck bringen. | ||
| 423 | * Passiv in Sätzen nach Möglichkeit vermeiden: | ||
| 424 | ** Schlecht: „The syntax is explained in Chapter 5“ | ||
| 425 | ** Gut: „Chapter 5 explains the syntax“ | ||
| 426 | * Wir/Ich-Sätze vermeiden. Ausnahme: Es geht um den inhaltlichen Kernbeitrag. | ||
| 427 | |||
| 428 | |||
| 429 | |||
| 430 | ==== Anhang[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#Anhang||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==== | ||
| 431 | |||
| 432 | * Wesentliche Teile, die im Text wichtig sind, nicht im Anhang verstecken. | ||
| 433 | * Anleitungen (z.B. //How-To//s) gehören in den Anhang. | ||
| 434 | |||
| 435 | === 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"]] === | ||
| 436 | |||
| 437 | ==== 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"]] ==== | ||
| 438 | |||
| 439 | 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. | ||
| 440 | |||
| 441 | ==== 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"]] ==== | ||
| 442 | |||
| 443 | 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. | ||
| 444 | |||
| 445 | 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. | ||
| 446 | |||
| 447 | 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. | ||
| 448 | |||
| 449 | ==== 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"]] ==== | ||
| 450 | |||
| 451 | 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. | ||
| 452 | |||
| 453 | {{{ \usepackage{todonotes} | ||
| 454 | }}} | ||
| 455 | |||
| 456 | Eine kurze, detaillierte Anleitung kann man hier nachlesen: | ||
| 457 | |||
| 458 | >[[(% 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"]] | ||
| 459 | |||
| 460 | ==== 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"]] ==== | ||
| 461 | |||
| 462 | 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"]] | ||
| 463 | |||
| 464 | Das Erstellen eines deutschsprachigen Literaturverzeichnisses ist mit Hilfe des Paketes //bibgerm// und dem bibliographystyle //gerplain// möglich. | ||
| 465 | |||
| 466 | {{{ \usepackage[ngerman]{babel} | ||
| 467 | \usepackage{bibgerm} | ||
| 468 | . | ||
| 469 | . | ||
| 470 | . | ||
| 471 | \bibliographystyle{gerplain} | ||
| 472 | |||
| 473 | }}} | ||
| 474 | |||
| 475 | Links zu BibTeX: | ||
| 476 | |||
| 477 | * [[(% class="icon" %) (%%)BibTeX-Tutorial>>url:http://www.din1505.informationskompetenz.net/||style="text-decoration: none;" shape="rect" class="ext-link"]] (Link ist tot) | ||
| 478 | * [[(% 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"]] | ||
| 479 | * [[(% 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"]] | ||
| 480 | |||
| 481 | ==== 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"]] ==== | ||
| 482 | |||
| 483 | 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. | ||
| 484 | |||
| 485 | ==== 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"]] ==== | ||
| 486 | |||
| 487 | 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. | ||
| 488 | |||
| 489 | ==== 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"]] ==== | ||
| 490 | |||
| 491 | 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 | ||
| 492 | |||
| 493 | >git clone git@…:resources/bib.git | ||
| 494 | |||
| 495 | 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. | ||
| 496 | |||
| 497 | ==== 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"]] ==== | ||
| 498 | |||
| 499 | 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 | ||
| 500 | |||
| 501 | >scp xyz-bt.pdf biblio@…:/home/biblio/public_html/downloads/theses | ||
| 502 | |||
| 503 | 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. | ||
| 504 | |||
| 505 | Then, check that your thesis is indeed available under the URL | ||
| 506 | |||
| 507 | >[[(% 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"]] | ||
| 508 | |||
| 509 | 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. | ||
| 510 | |||
| 511 | === 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"]] === | ||
| 512 | |||
| 513 | 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.). | ||
| 514 | |||
| 515 | == 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"]] == | ||
| 516 | |||
| 517 | 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.“ | ||
| 518 | |||
| 519 | 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. | ||
| 520 | |||
| 521 | |((( | ||
| 522 | **Merkmal** | ||
| 523 | )))|((( | ||
| 524 | |||
| 525 | )))|((( | ||
| 526 | |||
| 527 | )))|((( | ||
| 528 | |||
| 529 | )))|((( | ||
| 530 | |||
| 531 | )))|((( | ||
| 532 | **Punkte** | ||
| 533 | ))) | ||
| 534 | |((( | ||
| 535 | //Qualität der Lösung// | ||
| 536 | )))|((( | ||
| 537 | Lediglich Lösungsansätze; geringes Vertrauen in die Lösung | ||
| 538 | )))|((( | ||
| 539 | Lösung von Teilproblemen | ||
| 540 | )))|((( | ||
| 541 | Vollständige Lösung; gutes Vertauen in die Lösung | ||
| 542 | )))|((( | ||
| 543 | Vollständige, gute Lösung und Behandlung zusätzlicher Fragestellungen | ||
| 544 | )))|((( | ||
| 545 | |||
| 546 | ))) | ||
| 547 | |((( | ||
| 548 | Punkte | ||
| 549 | )))|((( | ||
| 550 | 1 - 7 | ||
| 551 | )))|((( | ||
| 552 | 8 - 14 | ||
| 553 | )))|((( | ||
| 554 | 15 - 21 | ||
| 555 | )))|((( | ||
| 556 | 22 - 28 | ||
| 557 | )))|((( | ||
| 558 | max. 28 | ||
| 559 | ))) | ||
| 560 | |((( | ||
| 561 | //Wissenschaftliche Arbeitstechnik// | ||
| 562 | )))|((( | ||
| 563 | Systemlose Durchführung; nur Literatur aus dem engsten Umfeld | ||
| 564 | )))|((( | ||
| 565 | Entwicklung einer Systematik erst nach Drängen des Betreuers; geringes Literaturvolumen | ||
| 566 | )))|((( | ||
| 567 | Selbständige Aufarbeitung der relevanten Literatur; grobe Einordung der Ergebnisse in das wissenschaftliche Umfeld | ||
| 568 | )))|((( | ||
| 569 | Selbständige und strukturierte Erfassung des Standes der Technik und der Literatur; systematische Einordung der Ergebnisse | ||
| 570 | ))) | ||
| 571 | |((( | ||
| 572 | Punkte | ||
| 573 | )))|((( | ||
| 574 | 1 - 6 | ||
| 575 | )))|((( | ||
| 576 | 7 - 12 | ||
| 577 | )))|((( | ||
| 578 | 13 - 18 | ||
| 579 | )))|((( | ||
| 580 | 19 - 24 | ||
| 581 | )))|((( | ||
| 582 | max. 24 | ||
| 583 | ))) | ||
| 584 | |((( | ||
| 585 | //Anwesenheit und Interaktion mit Betreuer// | ||
| 586 | )))|((( | ||
| 587 | Selten anwesend, Interaktion nur auf Initiative des Betreuers; schwer erreichbar; weist nicht auf Probleme hin | ||
| 588 | )))|((( | ||
| 589 | Unregelmäßige Interaktion, jedoch generell erreichbar und häufig anwesend | ||
| 590 | )))|((( | ||
| 591 | Regelmäßige, selbst initiierte Interaktion; Stand der Arbeit generell nachvollziehbar | ||
| 592 | )))|((( | ||
| 593 | Informiert Betreuer regelmäßig über Stand der Arbeit; weist umgehend auf aufgetretene Probleme oder erreichte Zwischenziele hin; regelmäßige Anwesenheit | ||
| 594 | ))) | ||
| 595 | |((( | ||
| 596 | Punkte | ||
| 597 | )))|((( | ||
| 598 | 1 - 4 | ||
| 599 | )))|((( | ||
| 600 | 5 - 8 | ||
| 601 | )))|((( | ||
| 602 | 9 - 12 | ||
| 603 | )))|((( | ||
| 604 | 13 - 16 | ||
| 605 | )))|((( | ||
| 606 | max. 16 | ||
| 607 | ))) | ||
| 608 | |((( | ||
| 609 | //Eigeninitiative und Zielstrebigkeit// | ||
| 610 | )))|((( | ||
| 611 | Geht schwierigen Problemen aus dem Weg; mangelnder zeitlicher Einsatz; Zeitplan wird deutlich überzogen | ||
| 612 | )))|((( | ||
| 613 | Teilweise Eigeninitiative; Zeitplan im Wesentlichen eingehalten | ||
| 614 | )))|((( | ||
| 615 | Ziel wurde mit großer Eigeninitiative erreicht; Zeitplan wurde eingehalten | ||
| 616 | )))|((( | ||
| 617 | Eigeninitiative bei der Entwicklung der Thematik, auch bei schwierigen Problemen; Zielbewusste Zeiteinteilung | ||
| 618 | ))) | ||
| 619 | |((( | ||
| 620 | Punkte | ||
| 621 | )))|((( | ||
| 622 | 1 - 4 | ||
| 623 | )))|((( | ||
| 624 | 5 - 8 | ||
| 625 | )))|((( | ||
| 626 | 9 - 12 | ||
| 627 | )))|((( | ||
| 628 | 13 - 16 | ||
| 629 | )))|((( | ||
| 630 | max. 16 | ||
| 631 | ))) | ||
| 632 | |((( | ||
| 633 | //Qualität der Ausarbeitung// | ||
| 634 | )))|((( | ||
| 635 | Ausarbeitung mit schweren Mängeln: fehlende Systematik, Schreibfehler, schlechtes Deutsch, unübersichtliche Verzeichnisse usw. | ||
| 636 | )))|((( | ||
| 637 | Nur teilweise systematische Darstellung der Ergebnisse; Weitschweifigkeiten oder Knappheiten, aber akzeptable Gestaltung | ||
| 638 | )))|((( | ||
| 639 | Systematische, einleuchtende Gliederung, aber leichte Schwächen in Sprache und Gestaltung | ||
| 640 | )))|((( | ||
| 641 | Systematische Gliederung, flüssige Sprache, Bilder mit klarer Aussage, deutliche Darlegung der Zusammenhänge und Ergebnisse | ||
| 642 | ))) | ||
| 643 | |((( | ||
| 644 | Punkte | ||
| 645 | )))|((( | ||
| 646 | 1 - 4 | ||
| 647 | )))|((( | ||
| 648 | 5 - 8 | ||
| 649 | )))|((( | ||
| 650 | 9 - 12 | ||
| 651 | )))|((( | ||
| 652 | 13 - 16 | ||
| 653 | )))|((( | ||
| 654 | max. 16 | ||
| 655 | ))) | ||
| 656 | |((( | ||
| 657 | |||
| 658 | )))|((( | ||
| 659 | |||
| 660 | )))|((( | ||
| 661 | |||
| 662 | )))|((( | ||
| 663 | |||
| 664 | )))|((( | ||
| 665 | **Summe** | ||
| 666 | )))|((( | ||
| 667 | max. 100 | ||
| 668 | ))) | ||
| 669 | |||
| 670 | Die Umrechnung einer Punktzahl in eine Zensur ergibt sich unter Anwendung dieses Katalogs aus der folgenden Tabelle. | ||
| 671 | |||
| 672 | |((( | ||
| 673 | Note | ||
| 674 | )))|((( | ||
| 675 | 1,0 | ||
| 676 | )))|((( | ||
| 677 | 1,3 | ||
| 678 | )))|((( | ||
| 679 | 1,7 | ||
| 680 | )))|((( | ||
| 681 | 2,0 | ||
| 682 | )))|((( | ||
| 683 | 2,3 | ||
| 684 | )))|((( | ||
| 685 | 2,7 | ||
| 686 | )))|((( | ||
| 687 | 3,0 | ||
| 688 | )))|((( | ||
| 689 | 3,3 | ||
| 690 | )))|((( | ||
| 691 | 3,7 | ||
| 692 | )))|((( | ||
| 693 | 4,0 | ||
| 694 | ))) | ||
| 695 | |((( | ||
| 696 | Mindestpunktzahl | ||
| 697 | )))|((( | ||
| 698 | 96 | ||
| 699 | )))|((( | ||
| 700 | 88 | ||
| 701 | )))|((( | ||
| 702 | 80 | ||
| 703 | )))|((( | ||
| 704 | 72 | ||
| 705 | )))|((( | ||
| 706 | 64 | ||
| 707 | )))|((( | ||
| 708 | 56 | ||
| 709 | )))|((( | ||
| 710 | 48 | ||
| 711 | )))|((( | ||
| 712 | 40 | ||
| 713 | )))|((( | ||
| 714 | 32 | ||
| 715 | )))|((( | ||
| 716 | 24 | ||
| 717 | ))) | ||
| 718 | |||
| 719 | == 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"]] == | ||
| 720 | |||
| 721 | * 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. | ||
| 722 | * „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"]] | ||
| 723 | * „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"]] | ||
| 724 | * 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"]]“. | ||
| 725 | * [[(% 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. |