Der Code läuft, die Demo funktioniert, und trotzdem kommt die Arbeit mit harter Kritik zurück – das ist die Erfahrung, vor der sich viele Informatik-Studierende am meisten fürchten. Der Grund liegt meist nicht im Code selbst, sondern in fünf wiederkehrenden Lücken zwischen einem funktionierenden System und einer wissenschaftlichen Arbeit darüber. Wer diese fünf Lücken kennt und gezielt schließt, macht aus einem funktionierenden, sauber getestetes und dokumentierten Projekt deutlich verlässlicher eine bestehende Abschlussarbeit – und weiß außerdem, worauf Betreuende schon beim ersten Statusgespräch achten, lange bevor die Arbeit überhaupt beim Zweitgutachten landet. Die folgenden Abschnitte gehen jede der Lücken einzeln durch, mit einem durchgerechneten Beispiel und einer Checkliste am Ende, die sich direkt vor der Abgabe durchgehen lässt.
Warum scheitert eine Informatik-Abschlussarbeit meistens nicht am Code?
Gutachtende in der Informatik bewerten selten die reine Implementierung – sie bewerten, ob aus einem Softwareprojekt eine wissenschaftliche Arbeit geworden ist. Ein technisch sauberes System ohne klare Forschungsfrage, ohne Einordnung in bestehende Arbeit und ohne belastbare Evaluation ist aus Gutachtenden-Sicht ein Praxisprojekt, kein wissenschaftlicher Beitrag. Die folgenden fünf Punkte sind die Stellen, an denen dieser Unterschied besonders oft verloren geht.
Fehler 1: Die Systembeschreibung ersetzt die wissenschaftliche Fragestellung
Viele Arbeiten beschreiben minutiös, was implementiert wurde – Architektur, Technologiestack, Klassendiagramme –, ohne vorher eine prüfbare Forschungsfrage zu stellen, die diese Implementierung überhaupt beantwortet. Eine Systembeschreibung ist notwendig, aber sie ist kein Ersatz für die Frage „Was genau wollte ich herausfinden, und warum reicht dafür nicht einfach eine gute Softwaredokumentation?“. Formuliere die Forschungsfrage so, dass eine Antwort auch „nein, das funktioniert so nicht“ lauten könnte – nur dann ist sie tatsächlich prüfbar und nicht bloß eine Beschreibung des Bauplans. Ein hilfreicher Test: Lies deine Einleitung ohne den Implementierungsteil. Wenn daraus nicht klar wird, welche konkrete Unsicherheit die Arbeit auflöst, fehlt die Forschungsfrage noch, auch wenn die Systembeschreibung schon vollständig ist.
Fehler 2: Kein Vergleich mit existierenden Lösungen
Ein zweiter häufiger Einwand: Die Arbeit stellt das eigene System vor, ohne zu zeigen, was an vergleichbaren, bereits existierenden Ansätzen anders oder besser gemacht wird. Ohne diesen Vergleich lässt sich der eigene Beitrag nicht einordnen – Gutachtende können nicht beurteilen, ob ein Ergebnis neu, eine Wiederholung oder sogar eine Verschlechterung gegenüber dem Stand der Technik ist. Recherchiere mehrere vergleichbare Arbeiten oder Systeme, benenne ihre Stärken und Schwächen konkret, und positioniere dein eigenes System explizit dazu – nicht nur in der Einleitung, sondern auch wieder in der Diskussion. Eine kompakte Vergleichstabelle mit den verwandten Arbeiten in einer Spalte und den relevanten Eigenschaften in den Zeilen macht diese Positionierung für Gutachtende auf einen Blick nachvollziehbar, statt sie über mehrere Fließtextabsätze verteilt suchen zu lassen.
Fehler 3: Fehlende oder unpassende Evaluation
Ein funktionierendes System ist kein Beweis für seine Qualität. Die dritte häufige Lücke: Es fehlt eine Evaluation, die tatsächlich zur Forschungsfrage passt – etwa ein Benchmark-Vergleich, wenn Performance behauptet wird, oder eine Nutzerstudie, wenn Usability behauptet wird. Welches Evaluationsverfahren zu welcher Art von Fragestellung passt, ist im Beitrag Welches Evaluationsverfahren für die Informatik-Abschlussarbeit? ausführlich verglichen. Eine Behauptung wie „das System ist schneller“ ohne Messmethode, Vergleichsbasis und Zahlen ist für Gutachtende ein sofortiger Kritikpunkt, unabhängig davon, wie gut der Code tatsächlich ist.
Fehler 4: Nicht reproduzierbare Ergebnisse
Wenn Gutachtende deine Messungen nicht nachvollziehen können – weil Testdaten, Parameter oder der genaue Versuchsaufbau fehlen –, wird jedes Ergebnis angreifbar, egal wie beeindruckend die Zahl selbst ist. Dokumentiere für jede Messung: welche Daten verwendet wurden, welche Konfiguration, wie oft die Messung wiederholt wurde und wie mit Ausreißern umgegangen wurde. Wie Reproduzierbarkeit systematisch im Methodenteil verankert wird, zeigt exemplarisch der Beitrag zum Methodenkapitel der Data-Science-Abschlussarbeit – die dortigen Prinzipien zu Datensplit und Dokumentation lassen sich direkt auf Softwareprojekte übertragen. Ein praktischer Zusatztipp: Versioniere Testdaten und Konfigurationsdateien zusammen mit dem Code im selben Repository, statt sie getrennt oder nur lokal zu verwalten – das macht die Reproduzierbarkeit auch für dich selbst überprüfbar, wenn Gutachtende Monate später Rückfragen stellen.
Fehler 5: KI-generierter Code ohne Deklaration
Ein zunehmend wichtiger, formaler Kritikpunkt: Code, der mit GitHub Copilot, ChatGPT oder einem ähnlichen Werkzeug erstellt wurde, aber nirgends als solcher gekennzeichnet ist. Viele Fachbereiche verlangen mittlerweile eine explizite Deklaration von KI-Unterstützung, und diese Regeln können auch für Code gelten, nicht nur für den Prosatext. Der vollständige Workflow dazu ist im Beitrag Musst du KI-generierten Code deklarieren? beschrieben. Kläre die Regeln deines Fachbereichs vor Beginn der Implementierung, nicht erst beim Schreiben des Anhangs. Führe parallel zur Implementierung ein kurzes Protokoll, welche Prompts für welchen Codeabschnitt verwendet wurden – das macht die spätere Deklaration im Anhang in wenigen Minuten erledigt, statt am Ende der Bearbeitungszeit rekonstruiert werden zu müssen.
Ein sechster, seltener genannter Grund: Testabdeckung ohne Aussagekraft
Neben den fünf Hauptpunkten fällt in Gutachten gelegentlich ein sechster, eng verwandter Kritikpunkt: eine hohe Testabdeckung (Code Coverage), die als Qualitätsnachweis präsentiert wird, ohne dass die Tests tatsächlich die relevanten Fälle abdecken. Eine Abdeckung von 90 Prozent sagt nichts darüber aus, ob die kritischen Randfälle deiner Forschungsfrage getestet wurden – ein System kann formal hoch abgedeckt und trotzdem an genau der Stelle ungetestet sein, die für die Bewertung deiner Ergebnisse entscheidend ist. Wähle Testfälle gezielt entlang der Fragestellung aus, nicht nur entlang der Codepfade, und mache im Methodenteil transparent, welche Szenarien bewusst getestet wurden und welche bewusst offen blieben.
Wie reagierst du, wenn deine Arbeit mit diesen Einwänden zurückkommt?
Wenn ein Gutachten einen oder mehrere dieser Punkte bemängelt, lohnt es sich, die Kritik zunächst nach Kategorie zu sortieren, statt sofort an einzelnen Sätzen zu arbeiten. Ein fehlender Related-Work-Vergleich und eine fehlende Evaluation sind strukturelle Lücken, die eigene Kapitel oder Abschnitte brauchen – kein Nachschieben in einem Nebensatz. Beginne mit der Forschungsfrage: Wenn sie unscharf war, wirkt sich das auf alle anderen Kapitel aus, und eine Überarbeitung sollte von dort aus rückwärts durch die Arbeit gehen, statt Kapitel für Kapitel isoliert nachzubessern. Plane für eine strukturelle Überarbeitung realistisch mehr Zeit ein, als der erste Blick auf die Anmerkungen vermuten lässt. Nutze zudem das Zwischengespräch mit deiner Betreuungsperson konsequent, um genau diese fünf Punkte schon Wochen vor Abgabe zu prüfen – ein kurzer Statuscheck zur Forschungsfrage und zur geplanten Evaluation ist deutlich günstiger als eine vollständige Überarbeitung nach dem Gutachten.
Ein durchgearbeitetes Beispiel (illustrativ)
Angenommen, du entwickelst ein System zur automatisierten Erkennung doppelter Einträge in einer Datenbank. Eine schwache Arbeit beschreibt ausführlich die Systemarchitektur, zeigt Screenshots der Benutzeroberfläche und behauptet am Ende, das System funktioniere „zuverlässig“. Eine starke Arbeit formuliert stattdessen eine prüfbare Frage – etwa, ob der gewählte Ähnlichkeitsalgorithmus bei einem bestimmten Datentyp eine höhere Präzision erzielt als zwei etablierte Referenzverfahren –, vergleicht das eigene System explizit mit diesen zwei Referenzverfahren auf einem dokumentierten Testdatensatz, berichtet Precision und Recall mit den exakten Parametern der Messung, und legt offen, dass ein Teil der Datenaufbereitungsroutine mit KI-Unterstützung entstand und im Anhang entsprechend gekennzeichnet ist. Beide Arbeiten können denselben funktionierenden Code haben – nur eine davon erfüllt die wissenschaftlichen Mindestanforderungen. Der Unterschied zeigt sich besonders deutlich im Diskussionskapitel: Die schwache Arbeit hat dort nichts zu diskutieren außer der eigenen Implementierung, während die starke Arbeit die eigenen Zahlen gegen die Referenzverfahren einordnen und offene Fragen für weiterführende Arbeiten benennen kann.
Checkliste, bevor du abgibst
- Prüfbare Forschungsfrage formuliert – nicht nur eine Beschreibung dessen, was gebaut wurde.
- Mehrere vergleichbare Arbeiten recherchiert und explizit gegen das eigene System positioniert, idealerweise in einer Vergleichstabelle.
- Evaluationsmethode passend zur Forschungsfrage gewählt – Benchmark, Nutzerstudie, Fallstudie oder Ablationsstudie, nicht nur eine subjektive Einschätzung.
- Messungen vollständig dokumentiert – Daten, Konfiguration, Wiederholungen, Umgang mit Ausreißern, idealerweise versioniert im selben Repository wie der Code.
- Testfälle gezielt entlang der Forschungsfrage gewählt – nicht nur eine hohe, aber beliebige Codeabdeckung.
- KI-Nutzung im Code nach Fachbereichsregeln deklariert – vor Beginn der Implementierung geklärt und laufend protokolliert, nicht nachträglich rekonstruiert.
Mit Tesify planst und strukturierst du deine Informatik-Abschlussarbeit so, dass Forschungsfrage, Related Work und Evaluationskapitel sauber zusammenpassen – die technische Leistung und jeder Satz bleiben zu 100 % von dir geschrieben. Starte jetzt mit Tesify und arbeite deine Informatik-Abschlussarbeit strukturiert durch, bevor sie bei den Gutachtenden landet. Über 9.000 Studierende und mehr als 15.000 Kapitel stehen hinter Tesify.
Häufige Fragen zu Ablehnungsgründen bei der Informatik-Abschlussarbeit
Reicht ein gut funktionierendes System für eine gute Note?
Nein. Gutachtende bewerten die wissenschaftliche Einordnung – Forschungsfrage, Vergleich mit bestehender Arbeit, Evaluation – mindestens so stark wie die technische Umsetzung selbst.
Wie viele verwandte Arbeiten muss ich mindestens vergleichen?
Es gibt keine feste Zahl; eine kleine Auswahl thematisch nah verwandter Arbeiten oder Systeme ist für eine Bachelorarbeit meist realistisch, solange die Auswahl tatsächlich relevant und nicht willkürlich ist. Kläre die Erwartung mit deiner Betreuungsperson.
Was, wenn meine Evaluation kein eindeutig positives Ergebnis zeigt?
Das ist kein Ablehnungsgrund an sich. Eine sauber durchgeführte Evaluation mit einem gemischten oder negativen Ergebnis ist wissenschaftlich wertvoller als eine unkritische Erfolgsbehauptung ohne Beleg.
Muss ich jede einzelne Codezeile mit KI-Unterstützung kennzeichnen?
Meist nicht; häufig reicht eine zusammenfassende Deklaration im Anhang oder Methodenteil, welche Teile mit welchem Werkzeug entstanden sind – die genauen Vorgaben unterscheiden sich je nach Fachbereich.
Zählt eine Nutzerstudie mit wenigen Teilnehmenden überhaupt?
Ja, wenn die geringe Zahl transparent begründet und als Limitation benannt wird. Wichtiger als die Teilnehmerzahl ist, dass die Studie überhaupt zur Forschungsfrage passt.
Ist ein Vergleich mit kommerziellen Systemen zulässig?
Ja, solange die Vergleichsbedingungen fair und dokumentiert sind – etwa gleiche Testdaten und vergleichbare Hardware, soweit zugänglich.
Sagt eine hohe Testabdeckung nicht automatisch etwas über die Qualität aus?
Nein. Eine hohe Codeabdeckung zeigt, dass viele Codepfade ausgeführt wurden, nicht, dass die für deine Forschungsfrage entscheidenden Fälle tatsächlich geprüft wurden. Beides sollte getrennt betrachtet werden.
Wie priorisiere ich, wenn ein Gutachten mehrere dieser Punkte gleichzeitig bemängelt?
Beginne bei der Forschungsfrage, da sie alle anderen Kapitel beeinflusst. Erst wenn sie klar ist, lohnt sich die Überarbeitung von Related Work, Evaluation und Reproduzierbarkeit im Detail.
Wie protokolliere ich KI-Unterstützung am effizientesten während der Implementierung?
Ein einfaches Textdokument oder eine Tabelle mit Datum, betroffener Datei und verwendetem Prompt reicht meist aus. Wichtig ist, das laufend zu pflegen, statt es am Ende der Bearbeitungszeit aus dem Gedächtnis zu rekonstruieren.
Sollte ich das Thema wechseln, wenn ich merke, dass keine gute Evaluation möglich ist?
Nicht unbedingt. Oft lässt sich die Forschungsfrage so anpassen, dass ein realistisch durchführbares Evaluationsverfahren dazu passt, statt das gesamte Thema zu verwerfen. Sprich das früh mit deiner Betreuungsperson ab, statt es erst bei der Abgabe zu bemerken.
Wie unterscheidet sich das von den formalen Fehlern in anderen Fächern?
Die zugrunde liegende Logik – Forschungsfrage vor Umsetzung, Einordnung in den Stand der Technik, nachvollziehbare Belege – gilt fachübergreifend, nimmt in der Informatik aber die konkrete Form von Related Work, Benchmark und Reproduzierbarkeit an, statt etwa Streitständen oder Literaturüberblicken.
Welcher Tool-Stack hilft mir, diese Punkte sauber zu dokumentieren?
Eine strukturierte Übersicht zu Versionskontrolle, Schreibwerkzeugen und Reproduzierbarkeits-Tools findet sich im Beitrag Welcher Tool-Stack für die Informatik-Abschlussarbeit?.
Kurz zusammengefasst
Informatik-Abschlussarbeiten scheitern selten an fehlerhaftem Code, sondern an wiederkehrenden, gut vermeidbaren Lücken: einer fehlenden prüfbaren Forschungsfrage, fehlendem Vergleich mit bestehender Arbeit, unpassender oder fehlender Evaluation, nicht reproduzierbaren Ergebnissen, aussagekraftloser Testabdeckung und undeklarierter KI-Nutzung im Code. Wer diese Punkte vor Abgabe systematisch, Kapitel für Kapitel, prüft, hat die häufigsten Gutachter-Einwände bereits entkräftet, bevor sie überhaupt formuliert werden. Am wirksamsten ist es, die Checkliste nicht erst am Ende, sondern schon beim ersten Statusgespräch mit der Betreuungsperson zu nutzen.