(English translation below)
Grundlegende Informationen zu Abschlussarbeiten finden sich auf der Webseite des IfI.
Student:innen sollen in ihrer Bachelor- oder Masterarbeit ein Problem aus der Informatik selbständig nach wissenschaftlichen Methoden bearbeiten und dokumentieren. Für Masterarbeiten müssen die Probleme nichttrivial sein; das heisst die Arbeit muss ein bisher ungelöstes Problem wissenschaftlich erschließen.
Meine Abschlussarbeiten haben immer einen starken Fokus auf die Implementierung von neuen Tools oder neuer Funktionalität in bestehenden Tools. Ich erwarte dabei eine stark inkrementelle Softwareentwicklung, mit häufigen, möglichst kleinen (aber sinnvollen) Merge Requests. Jede Abschlussarbeit besteht aus den folgenden Teilen:
Ich erwarte, dass verfügbare LLM-Werkzeuge effektiv verwendet werden, doch Student:innen müssen zu jedem Zeitpunkt bewusst und methodisch arbeiten, sind für die Qualität und Korrektheit ihrer Arbeit verantwortlich, und müssen sicherstellen, dass alle produzierten Inhalte ihren eigenen Ideen entspringen. Plagiate werden nicht toleriert.
Erstes Meeting → 2 Wochen Einführungsaufgabe → 1 Woche Vorbereitung Antrittsvortrag → Anmeldung und Beginn der Abschlussarbeit.
Ich erwarte dass Student:innen kontinuierlich und intensiv an der Arbeit arbeiten. Die Arbeit beginnt mit dem ersten Treffen, mit einer Einführungsaufgabe, in der Student:innen sich mit ersten Problemen des Themas auseinandersetzen und die Ziele ausarbeiten, die sie in ihrer Arbeit erreichen wollen. Wenn die Einführungsaufgabe erfolgreich bearbeitet wurde und wir zuversichtlich sind, dass die Arbeit erfolgreich bearbeitet werden kann, haben Student:innen 1 Woche Zeit, einen 5-minütigen Antrittsvortrag vorzubereiten, in dem sie die Motivation des Themas und ihre Ziele präsentieren. Der Antrittsvortrag wird im Oberseminar des Lehrstuhls gehalten (typischerweise ein Publikum von 5-10 Leuten). Das Ziel des Antrittsvortrags ist frühes Feedback von einem größeren Publikum und dass die Leute am Lehrstuhl über aktuell laufende Abschlussarbeiten informiert sind. Die Abschlussarbeit wird zum Dienstag nach dem Antrittsvortrag registriert.
Das Oberseminar findet Mittwoch Nachmittag statt und ist öffentlich. Es lohnt sich, vor dem eigenen Antrittsvortrag am Oberseminar teilzunehmen, um andere Vorträge zu sehen. Das aktuelle Programm ist hier verfügbar.
Wir treffen uns einmal die Woche zu zweit für maximal 30 Minuten, in Präsenz oder via Zoom. Das Meeting leitet die Student:in. Ziel ist dass die Student:in ein Update über den aktuellen Fortschritt gibt und offene Fragen oder Probleme besprochen werden können. Hier sollten auch Vorschläge für die nächsten, möglichst kleinen Inkremente in der Entwicklung gemacht werden. Die Abschlussarbeit ist das Projekt der Student:in. Ich berate, leite und bewerte.
Es ist wichtig, dass Student:innen methodisch und strukturiert arbeiten. Dies sollte auch in den Meetings sichtbar sein.
Student:innen wird für ihre Softwareentwicklung ein GitLab-Repository vom Lehrstuhl zur Verfügung gestellt. Ich erwarte eine Planung der Architektur des Tools und der grundlegenden Prozesse oder Algorithmen, bevor mit der Implementierung begonnen wird.
Alle Arbeit passiert in Feature Branches. Sobald die Arbeit begonnen wird, wird direkt ein Draft-Merge-Request erstellt, so dass die Arbeit gut sichtbar ist. Wenn die Arbeit erledigt ist, wird der Merge Request als “ready” markiert und ich werde als Reviewer hinzugefügt, so dass ich weiß, dass die Arbeit abgeschlossen ist.
Jedes Feature sollte ein möglichst kleines Inkrement sein. Siehe GitLab Handbook: Make small merge requests. Ich erwarte automatisierte Tests und eine kurze Dokumentation für Nutzer:innen. ## Tools
Tools, die ich verwende: Zoom, LaTeX, IntelliJ IDEA, VS Code, GitLab, Obsidian, LucidChart, Zulip, GitHub Copilot, OpenCode.
Basic information on theses can be found on the IfI website.
Students should work on a problem in computer science independently using scientific methods and document it. For master’s theses, the problems must be non-trivial; that is, the thesis must scientifically address a previously unsolved problem.
My theses always have a strong focus on implementing new tools or new functionality in existing tools. I expect strongly incremental software development, with frequent, as small as possible (but meaningful) merge requests. Every thesis consists of:
I expect that available LLM tools are used effectively, but students must work consciously and methodically at all times, are responsible for the quality and correctness of their work, and must ensure that all produced content originates from their own ideas. Plagiarism will not be tolerated.
First meeting → 2 weeks introductory task → 1 week preparation for introductory talk → Registration and start of thesis.
I expect students to work continuously and intensively on the thesis. The work begins with the first meeting, with an introductory task in which students engage with initial problems of the topic and work out the goals they want to achieve in their thesis. When the introductory task has been successfully completed and we are confident that the thesis can be successfully completed, students have 1 week to prepare a 5-minute introductory talk in which they present the motivation of the topic and their goals. The introductory talk is held in the chair’s “Obserseminar” (typically an audience of 5-10 people). The goal of the introductory talk is early feedback from a larger audience and that people at the chair are informed about currently ongoing theses. The thesis is registered on the Tuesday after the introductory talk.
The main seminar takes place Wednesday afternoon and is public. It is worthwhile to attend the main seminar before your own introductory talk to see other presentations. The current program is available here.
We meet once a week for a maximum of 30 minutes, in person or via Zoom. The student leads the meeting. The goal is for the student to give an update on current progress and to discuss open questions or problems. Proposals for the next increments in development should also be made here. The thesis is the student’s project. I advise, guide, and grade.
It is important that students work methodically and in a structured way. This should also be visible in the meetings.
Students are provided with a GitLab repository from the chair for their software development. I expect planning of the tool’s architecture and the fundamental processes or algorithms before implementation begins.
All work happens in feature branches. As soon as work is started, a draft merge request is created immediately so that the work is clearly visible. When the work is done, the merge request is marked as “ready” and I am added as a reviewer so that I know the work is complete.
Each feature should be as small an increment as possible. See GitLab Handbook: Make small merge requests. I expect automated tests and brief documentation for users.
Tools I use: Zoom, LaTeX, IntelliJ IDEA, VS Code, GitLab, Obsidian, LucidChart, Zulip, GitHub Copilot, OpenCode.