Date: Fri, 29 Mar 2024 12:23:57 +0000 (UTC) Message-ID: <972537602.6501.1711715037148@2f9704fbf185> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6500_845603825.1711715037148" ------=_Part_6500_845603825.1711715037148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is the collected wisdom and advice after supervising a= bout 100 theses, from short study reports to dissertations. We recommend to= study it before you start with your thesis work. Some top= ics are discussed on these separate pages:
Table of Contents
Note: Most of this page is in German. Future additions should be don=
e in English. At some point, some good soul might translate the German "leg=
acy documentation" to English as well.
A good interaction with your adviser(s) is key to success. Unless you ha= ppen to have substantial work experience and to already be an expert in you= r field, your adviser is ahead of you in terms of experience and expertise.= Take advantage of this to improve your own work.
Advisers are humans. They like to help you with your thesis topic; they = don't like to have to "drive" it, or to get the feeling that their advice (= including the hints on this page) is ignored. You, and not your adviser, sh= ould be the one who is pushing your work, asking questions, initiating disc= ussions, and handing over thesis/chapter drafts without having to be explic= itly asked for it. In short, your adviser should be convinced that your wor= k is on track.
Even in the age of modern communication devices, the basis of a good com= munication with your adviser is regular physical presence. Most of the time= , we are in the fortunate position that we can provide you with a full-time= desk, typically in the lab (1114/1115). Use this desk for doing your thesi= s work, and not your PC at home. A key communication instrument in the RTSY= S group is the 9:30am tea, which you should participate in as well. One exc= eption are theses that are done in collaboration with industry and where th= e industry partner provides the work space. In that case, you should keep y= our adviser here on track with regular progress reports. Usually, an E-mail= every 2 to 4 weeks suffices for that.
Usually, your thesis is a full-time job, also meaning full-time = presence at your desk. In case you also have other regular work to= do, discuss this with your adviser at the beginning of your thesis work.= p>
The first thing to do after you familiarized yourself with the topic and= problem of your thesis is to write a short proposal (~2-4 pages). The prop= osal should be prepared as early as possible (within the first or second we= ek) and should show your adviser that you understood the problem and have a= rough idea how to solve it. It may be structured as follows.
You should send your thesis proposal to your advisor and (if he is not a= lready your advisor) the professor. After you finished the proposal, you sh= ould give a short (informal) talk of about 15 minutes during our daily tea = meeting presenting your topic to all members of our group.
Technically, the only hard deadline that you have regarding your thesis = submission is the one concerning the submission to the examination office (= Pr=C3=BCfungsamt), which is at the end of the semester for Bachelo= r thesis and six months after registering the thesis for master thesis. How= ever, at RTSYS (as with most other groups) we offer to look at your thesis = before the official submission. This not only helps to improve your thesis,= it also is more satisfying for the advisor to look at a thesis in detail i= f it's not just to determine a grade but also to help improve the result.= p>
Thus, in your own interest, we advise strongly to send drafts o= f the chapters of your thesis to your advisor(s) before submitting the fina= l thesis. Of course, the drafts should be as good as possible from your poi= nt of view. Your adviser can only improve your drafts so much. If your draf= t is of low quality, they can help you push it to an okay-ish level; but if= the draft is already of high-quality to start with, they can help you elev= ate it to pure awesomeness. Note that your drafts need not be complete yet:= you can always hand in missing bits and pieces later on.
The process is usually that 1) you send a draft to the doctoral student(= s) directly advising you, 2) you get feedback from them, 3) you implement t= hat feedback, 4) you send the revised draft to the Prof. Yes, this pipeline= takes time, and often there are holidays and travel plans to take into acc= ount as well, in particular for deadlines at the end of the summer semester= . Here's a schedule that has proven to work well regarding when to hand in = what to your direct advisors. Of course, sticking to that schedule is YOUR = responsibility, you should not rely on your advisors to remind you of it.= p>
What | When (AT THE LATEST) | Motivation |
---|---|---|
Outline | 3 months before final submission | Once you are halfway through your thesis, you= should have a basic idea of which topics you want to cover in your thesis.= This must be discussed with your adviser. |
1=E2=80=932 chapters | 4 weeks | The first drafts you submit are used to make = you aware of basic problems of your writing style. Getting this feedback as= early as possible in your writing process means that you won't have to cha= nge the whole thesis after you submit your final draft. |
Complete thesis | 2 weeks | Submitting a draft of your complete thesis |
Theses done in collaboration with industry partners follow the same sche= dule. The drafts you submit to your adviser at the university, however, sho= uld previously be run past your industry adviser.
A common experience: while you do your investigative/implementation work= , everything is clear =E2=80=94 until you try to write things up, week= s or months later. Thus we highly recommend to take notes along the way, eg= , as part of a chapter draft of your thesis.
The first rule of your implementation is: "No Crashes!"= The second rule of your implementation is: "No crashes!" = Regardless of what your code does and regardless of what the user does, you= r implementation should neither crash nor freeze. Whenever you make assumpt= ions, be sure to explicitly check them. If they are not met, your code shou= ld generate (useful!) error messages instead of crashing and the user shoul= d be able to continue working with it.
Since you're working in an academic context, you will have less resource= s (less time, in particular) available than in a commercial setting. Also, = your work probably won't have to compete with commercial applications. It f= ollows that everything you develop will be less comprehensive and will have= less features than a commercial product. What doesn't follow is that your = implementation should be less meticulous or less documented than in a profe= ssional setting. Quite the contrary, in fact: commercially developed code o= ften suffers from tight deadlines, the need to add new features, and at tim= es a certain ignorance. You implementation, on the other hand, is supposed = to be your masterpiece. It should reflect what you're currently capable of.= Even though your software won't cause considerable economical damage or ki= ll people, it probably won't exist in isolation. It will much rather be par= t of the KIELER project, which other people are supposed to use or develop = further. The quality (and grade) of your thesis will be judged in part base= d on your implementation. Since this is the case, make use of the fact that= your adviser probably has much more experience writing code than you do. A= sk him or her to review your code and to give you feedback on how to improv= e.
Let's look at an example. Suppose your thesis is a proof of concept. Thi= s means that you should constrain the goals of your thesis (in acco= rdance with your adviser) to a well-defined subset of the problem = you're tackling. The end user should be well aware of what your implementat= ion can do and what it cannot do. A reasonable constraint could for instanc= e be: "The transformation only works for pure signals, not for valued signals. Hierarchy-crossing transitions cannot be drawn." An u= nreasonable constraint could be: "Sometimes, adding a state works; other ti= mes, the software crashes." If you notice while working on your implementat= ion that you won't be able to make certain goals, talk to your adviser. Tog= ether, you will constrain the problem further. This will allow you to solve= the more constrained problem properly instead of not solving the more gene= ral problem at all. You colleagues or successors will be glad to be able to= start from a smaller, but well-developed code base and add features to it = instead of having to try to get your code to a reasonable quality standard&= nbsp;=E2=80=94 or throwing it away and starting over.
The bottom line: write clean and proper code that adheres to our coding = guidelines and document it. The quality and the readability of your code an= d of your documentation will influence your grade.
To make sure that code is of a certain quality, it must be run through d= esign and code reviews. The way this works is explained on this page. The reviews are not on= ly intended to improve the quality of your code, but also to give feedback = to you as a programmer to help you improve.
Zur Beurteilung einer Abschlussarbeit wird generell ein schriftliches Gu= tachten erstellt, welches die jeweilige Arbeit individuell w=C3=BCrdigt (in= cl. Note) und an das Pr=C3=BCfungsamt weitergeleitet wird. Es h=C3=A4ngt da= bei 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 hinsichtli= ch der Qualit=C3=A4t der Arbeit und der Vorgehensweise des Studierenden sin= d jedoch allgemein g=C3=BCltig, und z.T. auch bereits in der jeweiligen Pr= =C3=BCfungsordnung konkret genannt. So sieht z.B. =C2=A711(5) der Bachelorp= r=C3=BCfungsordnung vor: =E2=80=9EDie Note der Bachelorarbeit ber=C3=BCcksi= chtigt die Problembearbeitung, die Bachelorarbeit und den Abschlussvortrag = einschlie=C3=9Flich der sich anschlie=C3=9Fenden Aussprache."
Ein etwas detaillierterer Kriterien-/Bewertungskatalog ist in den beiden= folgenden Tabellen angegeben. Diese sind zun=C3=A4chst f=C3=BCr Bachelorar= beiten ausgelegt, finden aber - mit entsprechenden Abwandlungen - auch f=C3= =BCr Masterarbeiten Anwendung.
Merkmal | Punkte | ||||
Qualit=C3=A4t der L=C3=B6sung | Lediglich L=C3=B6sungsans=C3=A4tze; geringes Ver= trauen in die L=C3=B6sung | L=C3=B6sung von Teilproblemen | Vollst=C3=A4ndige L=C3=B6sung; gutes Vertrauen i= n die L=C3=B6sung | Vollst=C3=A4ndige, gute L=C3=B6sung und Behandlu= ng zus=C3=A4tzlicher Fragestellungen | |
Punkte | 1 - 7 | 8 - 14 | 15 - 21 | 22 - 28 | max. 28 |
Wissenschaftliche Arbeitstechnik | Systemlose Durchf=C3=BChrung; nur Literatur aus = dem engsten Umfeld | Entwicklung einer Systematik erst nach Dr=C3=A4n= gen des Betreuers; geringes Literaturvolumen | Selbst=C3=A4ndige Aufarbeitung der relevanten Li= teratur; grobe Einordung der Ergebnisse in das wissenschaftliche Umfeld | Selbst=C3=A4ndige und strukturierte Erfassung de= s Standes der Technik und der Literatur; systematische Einordung der Ergebn= isse | |
Punkte | 1 - 6 | 7 - 12 | 13 - 18 | 19 - 24 | max. 24 |
Interaktion mit Betreuer | Interaktion nur auf Initiative des Betreuers; sc= hwer erreichbar; selten anwesend, weist nicht auf Probleme hin= | Unregelm=C3=A4=C3=9Fige Interaktion, jedoch gene= rell erreichbar und h=C3=A4ufig anwesend | Regelm=C3=A4=C3=9Fige, selbst initiierte Interak= tion; Stand der Arbeit generell nachvollziehbar | Informiert Betreuer regelm=C3=A4=C3=9Fig =C3=BCb= er Stand der Arbeit; weist umgehend auf aufgetretene Probleme oder erreicht= e Zwischenziele hin; regelm=C3=A4=C3=9Fige Anwesenheit | |
Punkte | 1 - 4 | 5 - 8 | 9 - 12 | 13 - 16 | max. 16 |
Eigeninitiative und Zielstrebigkeit | Geht schwierigen Problemen aus dem Weg; mangelnd= er zeitlicher Einsatz; Zeitplan wird deutlich =C3=BCberzogen | Teilweise Eigeninitiative; Zeitplan im Wesentlic= hen eingehalten | Ziel wurde mit gro=C3=9Fer Eigeninitiative errei= cht; Zeitplan wurde eingehalten | Eigeninitiative bei der Entwicklung der Thematik= , auch bei schwierigen Problemen; Zielbewusste Zeiteinteilung | |
Punkte | 1 - 4 | 5 - 8 | 9 - 12 | 13 - 16 | max. 16 |
Aufbau und sprachliche Qualit=C3=A4t der Aus= arbeitung | Ausarbeitung mit schweren M=C3=A4ngeln: fehlende= Systematik, Schreibfehler, schlechtes Deutsch, un=C3=BCbersichtliche Verze= ichnisse usw. | Nur teilweise systematische Darstellung der Erge= bnisse; Weitschweifigkeiten oder Knappheiten, aber akzeptable Gestaltung | Systematische, einleuchtende Gliederung, aber le= ichte Schw=C3=A4chen in Sprache und Gestaltung | Systematische Gliederung, fl=C3=BCssige Sprache,= Bilder mit klarer Aussage, deutliche Darlegung der Zusammenh=C3=A4nge 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 Anwendun= g 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 |
Every student who is going to write a thesis and hence is considered an = integral part of our group is more than welcome to join our RtSys Stammtisch. We will meet = monthly in different restaurants in Kiel to have dinner and a good time tog= ether. Please ask your advisor or other students to invite you