<
From version < 3.1 >
edited by Reinhard von Hanxleden
on 2013/09/10 09:19
To version < 5.1 >
edited by cds
on 2013/09/10 15:14
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Hinweise zur Anfertigung und Benotung von Abschlussarbeiten
1 +Writing and Grading Theses
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.rvh
1 +XWiki.cds
Content
... ... @@ -49,7 +49,7 @@
49 49  
50 50  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 Studien-/Diplom-/Bachelor-/Masterarbeiten; die Hinweise können aber auch bei der Anfertigung von Praktikumsberichten - oder auch Promotionsarbeiten - hilfreich sein.
51 51  
52 -== 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"]] ==
52 += 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"]] =
53 53  
54 54  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.
55 55  
... ... @@ -68,9 +68,9 @@
68 68  |(((
69 69  Aktion
70 70  )))|(((
71 -Diplomarbeit/Masterarbeit
71 +Masterarbeit/Diplomarbeit
72 72  )))|(((
73 -Studienarbeit/Bachelorarbeit
73 +Bachelorarbeit/Studienarbeit
74 74  )))|(((
75 75  Idee
76 76  )))
... ... @@ -116,16 +116,14 @@
116 116  
117 117  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.
118 118  
119 -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.
119 +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.
120 120  
121 121  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.
122 122  
123 123  === 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"]] ===
124 124  
125 -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 [[(% class="icon" %) (%%)https:~~/~~/rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Help/SoftwarePractice/Reviews>>url:https://rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Help/SoftwarePractice/Reviews||style="text-decoration: none;" shape="rect" class="ext-link"]].
125 +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.
126 126  
127 -Alle Java-Klassen die Teil der Implementierung sind müssen nach Abschluss der studentischen Arbeit zumindest die Rating Stufe //yellow// erreicht haben. Die Stufe //green// ist wünschenswert, da sie einen Nachweis einiger der im vorigen Abschnitt genannten Anforderungen bietet, aber nicht zwingend erforderlich. Die Stufe //blue// zu erreichen ist innerhalb des Zeitraums der studentischen Arbeit nicht möglich, weil dies eine mittelfristige Bewährung der Implementierung innerhalb des KIELER Projekts voraussetzt.
128 -
129 129  == 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"]] ==
130 130  
131 131  === 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"]] ===
... ... @@ -137,8 +137,10 @@
137 137  
138 138  === 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"]] ===
139 139  
140 -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. Software sollte generell auf Englisch geschrieben werden - d.h., Kommentare, Variablen-/Klassen-/Paketnamen etc. sollten englisch sein.
138 +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.
141 141  
140 +Software sollte generell auf Englisch geschrieben werden - d.h., Kommentare, Variablen-/Klassen-/Paketnamen etc. sollten englisch sein.
141 +
142 142  ==== 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"]] ====
143 143  
144 144  * Lesen und beherzigen Sie Strunk & White (siehe unten).
... ... @@ -186,8 +186,12 @@
186 186  
187 187  === 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"]] ===
188 188  
189 -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. Sollten Sie nicht LaTeX verwenden, bzw. nicht die hier zur Verfügung gestellten Templates, ist eine technische Unterstützung Ihrer Arbeit nur eingeschränkt möglich.
189 +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.
190 190  
191 +Das Layout Ihrer Arbeit sollte der Kiel Computer Science Series (KCSS) entsprechen. Auf der KCSS-Seite sind ein LaTeX-Stylefile und umfangreiche Dokumentation hierzu verfügbar.
192 +
193 +Sollten Sie nicht LaTeX verwenden, bzw. nicht den KCSS-Style, ist eine technische Unterstützung Ihrer Arbeit nur eingeschränkt möglich.
194 +
191 191  Um ggf. elektronischen Zugang auf Ihre sowie anderweitige weitere Nutzung Ihrer Arbeit zu ermöglichen, sollten eine PDF-Version, sowie auch die LaTeX-Sourcen, Graphiken, etc., im Subversion-System der Gruppe eingecheckt werden.
192 192  
193 193  ==== 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"]] ====
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -7700872
1 +7700963
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/7700872/Hinweise zur Anfertigung und Benotung von Abschlussarbeiten
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/7700963/Writing and Grading Theses