In der Informatik liegt ein typischer Rückweisungsgrund nicht im falschen Code, sondern in einer Arbeit, die nie klar sagt, was eigentlich gebaut und wie es geprüft wurde. Gutachtende in der Informatik lesen anders als in geisteswissenschaftlichen Fächern: Sie suchen zuerst das Artefakt, dann die Evaluation, dann erst den Text darum herum. Die folgenden Einwände können bei einem Webprojekt, einer mobilen App, einem Machine-Learning-Modell oder einer Systemkomponente gleichermassen auftreten; je nach Teilgebiet verschiebt sich nur der Schwerpunkt, etwa bei Data Science eher zur Evaluation und bei verteilten Systemen eher zu den Leistungsaussagen. Dieser Beitrag ordnet die wichtigsten inhaltlichen Einwände bei Informatik-Bachelorarbeiten systematisch und zeigt, wie du sie von Anfang an vermeidest, statt sie erst im fertigen Gutachten zu lesen, wenn eine Korrektur nicht mehr möglich ist. Eine offizielle Statistik zu Rückweisungsgründen veröffentlichen Schweizer Hochschulen nicht; die acht Einwände unten beruhen auf den methodischen Anforderungen des Fachs, nicht auf Quoten.
Warum diese Einwände in Softwareprojekten besonders oft auftreten
Ein Grund, warum diese Einwände in der Informatik immer wieder auftauchen: Programmieren fühlt sich wie Fortschritt an, auch wenn die eigentliche wissenschaftliche Arbeit noch nicht begonnen hat. Wer Wochen mit der Implementierung verbringt, hat oft das Gefühl, «schon viel gemacht» zu haben – dabei bleibt die Evaluation, die Abgrenzung vom Related Work und die saubere Dokumentation der Forschungsfrage liegen, weil sie sich weniger nach sichtbarem Fortschritt anfühlen als ein neues Feature. Ein realistischer Zeitplan reserviert deshalb von Anfang an einen festen, spürbaren Anteil der Gesamtzeit für Evaluation, Related-Work-Recherche und Dokumentation, nicht nur für die Implementierung selbst; wie gross dieser Anteil sein soll, klärst du am besten früh mit der Betreuungsperson.
Einwand 1: Kein klar abgegrenztes Artefakt
Viele Informatik-Bachelorarbeiten folgen implizit dem Design-Science-Zyklus: Problem, Anforderungen, Artefakt, Evaluation. Ein häufiger struktureller Einwand entsteht, wenn unklar bleibt, was genau das Artefakt ist – eine Bibliothek, eine Webanwendung, ein Algorithmus, eine Systemarchitektur, ein Datensatz? Eine Arbeit, die zwischen mehreren Teilartefakten hin- und herspringt, ohne eines davon als zentralen Beitrag zu benennen, wirkt unfokussiert. Schon im ersten Kapitel sollte in einem Satz stehen: «Das Artefakt dieser Arbeit ist X, das Problem Y löst.» Alles Weitere – Architektur, Implementierungsdetails, Evaluation – lässt sich dann konsequent auf diesen einen Satz zurückbeziehen, und jedes Kapitel, das nicht erkennbar auf diesen Satz einzahlt, gehört auf den Prüfstand.
Einwand 2: Fehlende oder unzureichende Evaluation
Ein Artefakt zu bauen ist die halbe Arbeit; zu zeigen, dass es funktioniert, die andere Hälfte. Ein ebenso typischer Einwand: Die Evaluation fehlt komplett, oder sie besteht aus der blossen Behauptung «das System funktioniert wie erwartet» ohne nachvollziehbare Methode. Eine belastbare Evaluation braucht ein Verfahren (Test, Benchmark, Nutzerstudie, Experteninterview, Vergleich mit einem Baseline-System), konkrete Kriterien, an denen Erfolg gemessen wird, und eine ehrliche Diskussion der Ergebnisse – inklusive dem, was nicht funktioniert hat. Gutachtende misstrauen Evaluationen, die ausschliesslich positive Ergebnisse zeigen und keine Grenzen benennen; eine Arbeit, die offen einräumt, unter welchen Bedingungen das Artefakt an seine Grenzen stösst, wirkt wissenschaftlich reifer als eine, die nur Erfolge auflistet.
Einwand 3: Oberflächliches Related Work
Ein Related-Work-Kapitel, das existierende Arbeiten nur auflistet, ohne den eigenen Beitrag davon abzugrenzen, beantwortet nicht die Frage, die Gutachtende stellen: Was macht diese Arbeit anders oder besser als das, was es schon gibt? Es gibt keine feste Anzahl an Referenzen, die «genügt» – massgeblich ist, ob die wirklich einschlägigen Arbeiten zur konkreten Fragestellung abgedeckt sind. Eine kurze Vergleichstabelle am Ende des Related-Work-Kapitels, die zeigt, welche Eigenschaft welche verwandte Arbeit abdeckt und wo die eigene Arbeit die Lücke schliesst, macht diesen Beitrag für Gutachtende sofort sichtbar. Hilfreich ist dabei, die Auswahl der verwandten Arbeiten kurz zu begründen, also zu sagen, in welchen Quellen und mit welchen Suchbegriffen gesucht wurde.
Einwand 4: Forschungsfrage, die kein Artefakt beantworten kann
Manche Forschungsfragen sind zu breit oder zu allgemein formuliert, um durch ein konkretes Artefakt und dessen Evaluation beantwortet zu werden – etwa «Wie verbessert Künstliche Intelligenz die Softwareentwicklung?» statt einer eng gefassten Frage wie «Reduziert ein KI-gestütztes Codereview-Tool die Zahl übersehener Nullpointer-Fehler in einem definierten Testkorpus?». Eine zu weite Frage führt fast zwangsläufig zu einer zu dünnen Evaluation, weil sich die breite Frage gar nicht vollständig beantworten lässt. Wer merkt, dass die eigene Frage zu breit ist, sollte sie vor Beginn der Implementierung eingrenzen, nicht erst beim Schreiben der Diskussion – eine nachträgliche Eingrenzung bedeutet meist, dass Teile der bereits gebauten Lösung nicht mehr zur Frage passen.
Einwand 5: Reproduzierbarkeit nicht gegeben
Ein Artefakt, das niemand ausser der Autorin oder dem Autor selbst zum Laufen bringen kann, erschwert die Bewertung erheblich. Fehlende Angaben zu Versionen von Bibliotheken und Laufzeitumgebung, keine Installationsanleitung, kein Zugriff auf den verwendeten Datensatz oder Testkorpus: All das zwingt Gutachtende, der Beschreibung zu vertrauen, statt sie nachzuvollziehen. Ein kurzer Anhang mit Systemvoraussetzungen, Versionen und – wo Vertraulichkeit es zulässt – einem Repository-Link erhöht die Glaubwürdigkeit der gesamten Arbeit deutlich. Selbst wenn der Code selbst aus vertraglichen Gründen nicht veröffentlicht werden darf, lässt sich die Umgebung (Programmiersprache, Framework-Version, Betriebssystem) fast immer offenlegen, ohne Vertraulichkeit zu verletzen.
Einwand 6: Fremder Code nicht korrekt deklariert
Übernommene Bibliotheken, aus Stack Overflow kopierte Codeschnipsel und KI-generierte Funktionen müssen als solche kenntlich gemacht werden – welche Lizenz eine Abhängigkeit trägt, welcher Anteil eines Moduls generiert und welcher selbst geschrieben wurde. Nur der Teil, den du selbst verstehst, anpasst und verantworten kannst, zählt als eigene Leistung. Wie diese Deklaration im Detail aussieht, welche Lizenzarten es gibt und wie Gutachtende Fremdanteile erkennen, ist eine eigene, ausführliche Frage – hier reicht der Hinweis, dass unvollständig deklarierter Code besonders schwer wiegt, weil er die wissenschaftliche Integrität der ganzen Arbeit infrage stellen kann.
Einwand 7: Leistungsaussagen ohne Messung
Ein Einwand, der vor allem bei technischen Arbeiten mit Performance-Anspruch naheliegt: Aussagen wie «das System ist deutlich schneller» oder «skaliert gut» stehen im Text, ohne dass eine Messung dahintersteht – kein Benchmark, keine Zeitmessung unter definierten Bedingungen, kein Vergleichswert. Jede quantitative oder qualitative Leistungsaussage muss durch eine konkrete, nachvollziehbare Messung gedeckt sein: mit welcher Hardware, welcher Eingabegrösse, wie oft wiederholt, mit welcher Streuung. Ohne diese Angaben ist die Aussage nicht überprüfbar und wird von Gutachtenden entsprechend zurückhaltend bewertet, selbst wenn sie im Kern zutreffen mag.
Einwand 8: Sicherheits- oder Datenschutzaspekte übergangen
Bei Arbeiten, die mit echten oder realitätsnahen Daten arbeiten – Nutzerkonten, Standortdaten, medizinische oder finanzielle Datensätze –, erwarten Gutachtende einen expliziten Abschnitt zu Datenschutz und, wo relevant, zu Sicherheitsaspekten der Implementierung. Ein Prototyp, der offensichtliche Sicherheitslücken enthält (Klartext-Passwörter, fehlende Zugriffskontrolle), ohne dass das Kapitel dies zumindest als bekannte Einschränkung benennt, wirkt unreflektiert – auch wenn eine produktionsreife Absicherung für eine Bachelorarbeit nicht erwartet wird. Oft genügt schon ein kurzer Absatz, der festhält, welche Daten das Artefakt verarbeitet, wo und wie lange sie gespeichert werden und wer darauf Zugriff hat, um diesen Einwand vorwegzunehmen.
Das Betreuungsgespräch als Frühwarnsystem nutzen
Die meisten dieser Einwände lassen sich vermeiden, wenn du das Betreuungsgespräch aktiv dafür nutzt, statt nur einen Statusbericht zum Implementierungsfortschritt zu liefern. Bring zu jedem Gespräch eine konkrete Frage mit: «Reicht diese Evaluation als Nachweis?», «Ist mein Related Work vollständig genug für dieses Teilgebiet?», «Ist meine Forschungsfrage eng genug für die geplante Implementierung?» Ein Demo des laufenden Artefakts im Gespräch – auch unfertig – liefert der Betreuungsperson mehr Grundlage für konkretes Feedback als eine rein textliche Statusbeschreibung. Manche Institute sehen dafür einen Zwischenbericht oder eine Zwischenpräsentation vor, die genau diesen Zweck erfüllt: nicht Bürokratie, sondern eine eingebaute Gelegenheit, die Einwände frühzeitig abzufangen, statt sie erst im fertigen Gutachten zu lesen. Ein GitHub-Repository mit regelmässigen Commits erfüllt für Betreuungspersonen zudem oft eine ähnliche Funktion wie ein Fortschrittsprotokoll – es zeigt, wann welcher Teil entstanden ist, ohne dass du extra Buch führen musst.
Eine durchgerechnete Selbstprüfung vor der Abgabe (fiktiv)
Angenommen, eine Bachelorarbeit entwickelt ein Browser-Plugin, das barrierearme Alt-Texte für Bilder auf Webseiten vorschlägt. Vor der Abgabe prüft der Studierende: Ist in einem Satz klar, was das Artefakt ist und welches Problem es löst? Gibt es eine Evaluation mit klaren Kriterien – etwa eine Nutzerstudie mit einer definierten Anzahl Testpersonen, die Vorschläge nach Relevanz bewerten – statt nur der Aussage «das Plugin funktioniert»? Grenzt das Related-Work-Kapitel die eigene Lösung klar von bestehenden Alt-Text-Generatoren ab? Ist die Forschungsfrage eng genug, um durch genau diese Evaluation beantwortet zu werden? Lässt sich das Plugin anhand der Anhänge nachinstallieren? Sind alle übernommenen Bibliotheken und KI-generierten Codeteile deklariert? Wird kurz benannt, welche Daten das Plugin verarbeitet und wie sie behandelt werden? Ist jede Aussage zur Verarbeitungsgeschwindigkeit durch eine Messung mit Angabe der Testbedingungen gedeckt? Bei dieser Prüfung fällt auf, dass die Evaluation bisher nur eine informelle Selbsteinschätzung war – der Studierende ergänzt vor der Abgabe eine kleine Nutzerstudie mit einer klar definierten Bewertungsskala, misst zusätzlich die Verarbeitungszeit pro Bild über zwanzig Testläufe, und stellt fest, dass die verwendete Bilderkennungsbibliothek bisher nirgends mit Versionsnummer genannt war. Dieses Beispiel ist illustrativ; die eigenen Kriterien richten sich nach den Vorgaben des jeweiligen Instituts.
Übersicht der acht Einwände
| Einwand | Was ihn behebt |
|---|---|
| Kein klar abgegrenztes Artefakt | Artefakt in einem Satz benennen, früh im Text |
| Fehlende Evaluation | Methode, Kriterien, ehrliche Diskussion der Ergebnisse |
| Oberflächliches Related Work | Vergleichstabelle mit klarer eigener Abgrenzung |
| Zu breite Forschungsfrage | Frage vor Implementierungsbeginn eingrenzen |
| Reproduzierbarkeit fehlt | Versionen, Anleitung, wo möglich Repository-Link |
| Fremder Code nicht deklariert | Herkunft und Lizenz jeder Abhängigkeit dokumentieren |
| Leistungsaussagen ohne Messung | Benchmark mit Bedingungen und Wiederholungen |
| Sicherheit/Datenschutz übergangen | Kurzer Abschnitt zu Datenbehandlung und bekannten Grenzen |
FAQ
Reicht eine reine Literaturarbeit in der Informatik?
Nur, wenn dein Institut diesen Typ explizit erlaubt. Viele Informatik-Studiengänge erwarten ein eigenes Artefakt – Software, Prototyp oder Systemkomponente – plus dessen Evaluation; massgeblich ist das Reglement deines Studiengangs.
Was zählt als ausreichende Evaluation eines Artefakts?
Eine nachvollziehbare Methode (Test, Benchmark, Nutzerstudie oder Experteninterview), die konkrete Kriterien prüft und deren Ergebnis diskutiert wird – nicht nur die Aussage, dass das Artefakt funktioniert.
Wie viele verwandte Arbeiten muss ich im Related Work behandeln?
Es gibt keine feste Zahl. Massgeblich ist, ob die wirklich einschlägigen Arbeiten zu deiner konkreten Fragestellung abgedeckt sind und du deinen Beitrag klar davon abgrenzt – nicht die Anzahl der Referenzen.
Muss ich meinen Code offenlegen?
Das hängt von den Vorgaben deines Instituts und von Vertraulichkeitsauflagen eines Praxispartners ab. Wo möglich, verbessert ein zugänglicher Code-Anhang oder ein Repository-Link die Reproduzierbarkeit deutlich.
Wird generierter Code als eigene Leistung gewertet?
Nur der Teil, den du selbst verstehst, anpasst und verantworten kannst. KI-generierte oder aus Stack Overflow übernommene Fragmente musst du gemäss den Integritätsregeln deiner Hochschule deklarieren.
Was, wenn meine Forschungsfrage zu vage ist, um sie mit einem Artefakt zu beantworten?
Dann eng sie ein, bis klar ist, welches konkrete Artefakt und welche Evaluation die Frage beantworten würden – notfalls in Rücksprache mit der Betreuungsperson, bevor die Implementierung beginnt.
Wie belege ich eine Leistungsaussage wie «läuft schneller»?
Mit einem Benchmark unter klar dokumentierten Bedingungen: Hardware, Eingabegrösse, Anzahl Wiederholungen und ein Vergleichswert. Ohne diese Angaben ist die Aussage für Gutachtende nicht überprüfbar.
Diese acht Einwände lassen sich fast alle vermeiden, indem du dein Artefakt und dessen Evaluation von Anfang an gemeinsam planst, sodass beide zusammen die Forschungsfrage beantworten – statt zuerst zu implementieren und erst am Ende zu überlegen, wie sich das Ergebnis wissenschaftlich einordnen lässt und welche Methode dafür überhaupt noch passt.
Beim Gliedern von Artefakt, Evaluation und Related Work hilft eine klare Kapitelstruktur: Tesify nutzen über 9’000 Studierende, die damit bereits über 15’000 Kapitel strukturiert haben – deine Arbeit bleibt dabei zu 100 % von dir geschrieben.
Wie du Software, Datensätze und Code als Quelle korrekt belegst, zeigt Datensätze, Software und Code zitieren. Wie das Methodikkapitel einer technischen Arbeit generell aufgebaut wird, erklärt Bachelorarbeit Beispiel. Was in eine saubere Abgrenzung des Themas gehört, zeigt Abgrenzung der Bachelorarbeit. Wie du den Forschungsstand sauber darstellst, erklärt Forschungsstand darstellen.