In der Informatik verlaufen Abschlussarbeiten oft nach demselben Muster: Drei Viertel der Zeit fließen in die Implementierung, dann bleiben zwei Wochen für ein Kapitel, das „Evaluation“ heißt und in der Bewertung überproportional zählt. Denn die Implementierung zeigt, dass du bauen kannst. Die Evaluation zeigt, dass du wissenschaftlich arbeiten kannst — und genau das ist der Unterschied zwischen einer Projektarbeit und einer Abschlussarbeit.
Dieser Vergleich stellt die fünf realistischen Evaluationsverfahren gegenüber, ordnet sie nach Aufwand und Aussagekraft und nennt für jedes das passende statistische Auswertungsverfahren.
Die Verfahren im direkten Vergleich
| Verfahren | Beantwortet die Frage | Zeitaufwand | Ethikvotum nötig | Aussagekraft |
|---|---|---|---|---|
| Benchmark / Performance-Messung | Ist es schneller, genauer, sparsamer als der Vergleichsansatz? | 1–2 Wochen | Nein | Hoch bei klarer Baseline |
| Ablationsstudie | Welche Komponente trägt wie viel zum Ergebnis bei? | 1 Woche zusätzlich | Nein | Sehr hoch, oft unterschätzt |
| Nutzerstudie | Kommen Menschen mit dem System zurecht? | 3–5 Wochen | Meist ja | Hoch, aber teuer |
| Fallstudie im Unternehmen | Funktioniert es unter realen Bedingungen? | 4–8 Wochen | Situationsabhängig | Hoch für Praxisrelevanz, gering für Generalisierung |
| Expertenreview / heuristische Evaluation | Verstößt das Design gegen bekannte Prinzipien? | 1 Woche | Nein | Mittel, gute Ergänzung |
Platz 1: Benchmark mit sauberer Baseline
Für die meisten Informatik-Abschlussarbeiten ist der Benchmark die richtige Wahl — vorausgesetzt, du machst ihn richtig. Der entscheidende Punkt ist nicht die Messung, sondern die Baseline.
Eine Baseline muss drei Bedingungen erfüllen: Sie ist in der Literatur etabliert, sie läuft auf denselben Daten und derselben Hardware wie dein Verfahren, und sie ist fair konfiguriert. Der häufigste Kritikpunkt in Gutachten lautet, dass die Vergleichsmethode in der Standardkonfiguration lief, während das eigene Verfahren sorgfältig optimiert wurde. Dokumentiere deshalb für jede verglichene Methode die Hyperparameter und wie du sie bestimmt hast.
Zur Messumgebung gehört ein Absatz, der oft fehlt: CPU- und GPU-Modell, RAM, Betriebssystem, Framework-Versionen, Anzahl der Wiederholungsläufe und der verwendete Zufalls-Seed. Ohne diese Angaben ist dein Ergebnis nicht reproduzierbar, und Reproduzierbarkeit ist in der Informatik seit einigen Jahren ein explizites Bewertungskriterium.
Metriken nach Aufgabentyp:
- Klassifikation: Accuracy allein reicht nicht. Bei unbalancierten Klassen brauchst du Precision, Recall, F1 und die Konfusionsmatrix; ROC-AUC nur, wenn du Wahrscheinlichkeiten ausgibst.
- Regression: RMSE, MAE und R², jeweils mit Angabe der Zielgrößeneinheit.
- Information Retrieval: Precision@k, Recall@k, MAP, nDCG.
- Generierung: BLEU, ROUGE oder BERTScore, ergänzt um eine kleine manuelle Bewertung — automatische Metriken allein gelten hier als unzureichend.
- Systeme: Latenz als Median und 95. Perzentil statt Mittelwert, Durchsatz, Speicherverbrauch, Energieaufnahme.
Welcher statistische Test gehört zu einem Benchmark?
Ein einzelner Durchlauf pro Verfahren ist kein Ergebnis, sondern eine Anekdote. Wiederhole jede Messung mindestens fünf-, besser zehnmal mit unterschiedlichen Seeds und prüfe dann statistisch.
- Zwei Verfahren, dieselben Testfälle: Wilcoxon-Vorzeichen-Rang-Test. Er ist der Standard in der Software-Engineering-Forschung, weil Laufzeit- und Fehlerverteilungen fast nie normalverteilt sind.
- Mehr als zwei Verfahren über mehrere Datensätze: Friedman-Test mit anschließendem Nemenyi-Post-hoc-Test. Das ist das etablierte Vorgehen für den Vergleich mehrerer Klassifikatoren.
- Zwei Klassifikatoren auf demselben Testset: McNemar-Test auf den Fehlerpaaren.
- Effektstärke: Cliffs Delta oder Vargha-Delaney A12 — beide sind nichtparametrisch und in der Informatik gebräuchlicher als Cohens d.
Wenn du viele Verfahren paarweise vergleichst, kumuliert der Alphafehler. Welches Korrekturverfahren dafür angemessen ist, klärt der Vergleich von Bonferroni, Holm und Benjamini-Hochberg beim multiplen Testen. Und ob du überhaupt parametrisch rechnen darfst, entscheidest du anhand der Verteilungsprüfung, die im Beitrag zum Prüfen der Normalverteilung mit Shapiro-Wilk und Q-Q-Plot beschrieben ist.
Platz 2: Ablationsstudie — der unterschätzte Aufwertungshebel
Wenn dein Ansatz aus mehreren Komponenten besteht — Preprocessing, Feature-Auswahl, Modellarchitektur, Postprocessing — dann ist die Ablationsstudie das Verfahren mit dem besten Verhältnis von Aufwand zu Wirkung. Du entfernst systematisch je eine Komponente und misst, wie stark das Ergebnis einbricht.
Der Gewinn ist doppelt: Erstens beweist du, dass deine Beiträge tatsächlich wirken, statt nur vorhanden zu sein. Zweitens produzierst du eine Tabelle, die eine echte Erkenntnis transportiert — etwa, dass das aufwendige Attention-Modul nur 0,4 Prozentpunkte bringt, während die simple Normalisierung 6 Prozentpunkte ausmacht. Solche Befunde heben eine Arbeit über den Durchschnitt.
Praktisch kostet eine Ablation meist nur zusätzliche Rechenzeit, keine zusätzliche Implementierung, weil du die Komponenten ohnehin modular gebaut hast. Wer bereits einen Benchmark aufgesetzt hat, bekommt die Ablation fast geschenkt.
Platz 3: Nutzerstudie — wenn Menschen mit dem System arbeiten sollen
Sobald deine Arbeit ein Interface, ein Werkzeug oder eine Interaktionsform hervorbringt, ist eine reine Performance-Messung nicht ausreichend. Dann brauchst du Menschen.
Für Abschlussarbeiten sind zwölf bis zwanzig Teilnehmende realistisch. Das reicht für aussagekräftige Ergebnisse, wenn du ein Within-Subject-Design wählst: Jede Person bearbeitet dieselben Aufgaben mit beiden Systemen, wobei du die Reihenfolge ausbalancierst, um Lerneffekte zu kontrollieren.
Etablierte Messinstrumente statt selbstgebauter Fragebögen:
- SUS (System Usability Scale): zehn Items, Score von 0 bis 100, umfangreiche Vergleichswerte in der Literatur. Ein Wert um 68 gilt als Durchschnitt.
- UEQ (User Experience Questionnaire): 26 Items, sechs Dimensionen von Attraktivität bis Originalität, kostenlos mit Auswertungsvorlage.
- NASA-TLX: misst kognitive Beanspruchung in sechs Dimensionen, unverzichtbar bei komplexen Werkzeugen.
- TAM-Konstrukte: wahrgenommene Nützlichkeit und Benutzerfreundlichkeit, wenn du Akzeptanz theoretisch modellieren willst.
Ergänze subjektive Maße immer um objektive: Bearbeitungszeit pro Aufgabe, Erfolgsquote, Fehleranzahl, Anzahl der Hilfeaufrufe. Ausgewertet wird ein Within-Subject-Vergleich mit gepaartem t-Test oder Wilcoxon-Test — welcher, entscheidest du wie im allgemeinen Leitfaden zur Frage beschrieben, welchen statistischen Test du für deine Daten brauchst.
Rechne bei Nutzerstudien mit dem Ethikverfahren deiner Hochschule und mit Datenschutzanforderungen: Einwilligungserklärung, Pseudonymisierung, Löschkonzept. Viele Informatik-Fakultäten haben inzwischen eigene Ethikkommissionen mit Vorlaufzeiten von mehreren Wochen.
Platz 4: Fallstudie im Unternehmenskontext
Wenn du deine Abschlussarbeit in einem Unternehmen schreibst und dein System dort produktiv eingesetzt wird, ist die Fallstudie das naheliegende Verfahren. Sie beantwortet die Frage, ob etwas unter realen Randbedingungen funktioniert — mit echten Daten, echter Last und echten Nutzenden.
Die methodische Schwäche ist die fehlende Generalisierbarkeit: Ein Unternehmen ist eine Stichprobe der Größe eins. Kompensiere das, indem du die Fallstudie mit einem Benchmark auf öffentlichen Daten kombinierst. Diese Kombination — allgemeine Leistungsfähigkeit plus Praxisnachweis — ist in Bachelorarbeiten mit Praxispartner die stärkste Konstruktion.
Zum sauberen Aufbau einer Fallstudie mit Fallauswahl, Datenquellen und Auswertungslogik hilft die Anleitung zur Fallstudie als Methode in der Bachelorarbeit. Klare Vorher-Nachher-Kennzahlen sind hier Pflicht: Durchlaufzeit vorher, Durchlaufzeit nachher, Fehlerquote, Aufwand in Personenstunden.
Platz 5: Expertenreview und heuristische Evaluation
Drei bis fünf Personen mit Fachhintergrund bewerten dein System anhand definierter Kriterien — etwa der zehn Usability-Heuristiken von Nielsen oder eines selbst hergeleiteten Kriterienkatalogs aus der Literatur. Der Aufwand ist gering, die Aussagekraft begrenzt, aber als Ergänzung neben einem Benchmark ist das Verfahren sinnvoll, besonders wenn dein Zeitbudget für eine echte Nutzerstudie nicht reicht.
Wichtig: Beschreibe die Auswahl der Expertinnen und Experten nachvollziehbar, gib den Kriterienkatalog im Anhang vollständig wieder und berichte die Übereinstimmung zwischen den Bewertenden.
Drei Fehler, die im Gutachten immer auffallen
Der unfaire Vergleich. Das eigene Verfahren wurde über Wochen getunt, die Baseline lief einmal mit Standardparametern. Das erkennt jede Gutachterin sofort, und es entwertet das gesamte Kapitel. Die Gegenmaßnahme kostet wenig: Beschreibe für jede Methode dasselbe Optimierungsbudget — etwa „für beide Verfahren wurden 50 Konfigurationen per Zufallssuche auf dem Validierungsset geprüft“ — und dokumentiere die gewählten Werte.
Das Testset als Entwicklungsset. Wer während der Entwicklung wiederholt auf dem Testset misst und daraufhin Anpassungen vornimmt, hat das Testset kontaminiert. Die gemessene Leistung ist dann optimistisch verzerrt. Trenne von Anfang an in Trainings-, Validierungs- und Testdaten und rühre das Testset erst am Ende an. Wenn du diesen Fehler bereits gemacht hast, ist die ehrliche Lösung, das im Text zu benennen — nicht, ihn zu verschweigen.
Die Metrik ohne Bezugsgröße. „Das System erreicht eine Accuracy von 0,87″ ist ohne Kontext bedeutungslos. Bei einem Datensatz mit 85 Prozent Mehrheitsklasse ist das ein schlechtes Ergebnis. Nenne deshalb immer die triviale Baseline — Mehrheitsklasse, Zufall, aktueller manueller Prozess — als unterste Vergleichslinie. Dieser eine Satz verhindert die häufigste inhaltliche Rückfrage im Kolloquium.
Wie du das Evaluationskapitel in fünf Arbeitstagen schreibst
Wenn die Messungen laufen, ist das Kapitel selbst planbar. Eine bewährte Aufteilung:
- Tag 1 — Aufbau beschreiben. Datensätze, Splits, Hardware, Software-Versionen, Hyperparameter, Wiederholungen, Seeds. Rein deskriptiv, keine Ergebnisse. Dieser Abschnitt entsteht am schnellsten, weil du alle Angaben bereits hast.
- Tag 2 — Metriken und Verfahren begründen. Warum diese Metriken, warum diese Baselines, welcher statistische Test und warum. Ein bis zwei Seiten.
- Tag 3 — Haupttabelle und Haupttext. Die zentrale Ergebnistabelle sauber bauen, dann im Text die zwei bis drei Zahlen benennen, die deine Aussage tragen. Nicht die ganze Tabelle in Prosa wiederholen.
- Tag 4 — Ablation und Detailanalysen. Zusätzliche Tabellen und Diagramme, jeweils mit einem Absatz, der den Befund benennt.
- Tag 5 — Fehleranalyse und Grenzen. Wo versagt das Verfahren, an welchen Fällen, mit welcher plausiblen Erklärung? Dieser Abschnitt kostet am wenigsten Rechenzeit und bringt in der Bewertung am meisten.
Ergebnisse und Deutung bleiben dabei getrennt: Im Evaluationskapitel steht, was gemessen wurde, in der Diskussion, was daraus folgt.
Code läuft, Kapitel fehlt
Die Evaluation ist gerechnet, aber der Text dazu existiert nur als Notizen und Screenshots? Tesify hilft dir, deine Abschlussarbeit Kapitel für Kapitel aufzubauen, deine Quellen zusammenzuhalten und Methoden- wie Ergebnisabschnitte in eine Form zu bringen, die wissenschaftlichen Ansprüchen genügt.
Die Empfehlung
Für eine Informatik-Bachelorarbeit ohne Nutzerbezug lautet die Empfehlung klar: Benchmark gegen mindestens zwei etablierte Baselines plus Ablationsstudie, ausgewertet mit Wilcoxon oder Friedman und ergänzt um Effektstärken. Dieses Paket kostet etwa zwei bis drei Wochen, ist methodisch nicht angreifbar und liefert ein Kapitel mit echtem Erkenntnisgewinn.
Bringt deine Arbeit ein Werkzeug oder Interface hervor, ergänzt du eine Nutzerstudie mit zwölf bis zwanzig Personen im Within-Subject-Design und SUS plus objektiven Aufgabenmaßen.
Entsteht in deiner Arbeit ein Artefakt, für das du Problem, Entwurf, Umsetzung und Evaluation als geschlossenen Zyklus dokumentieren willst, ist der übergeordnete Rahmen das Design-Science-Research-Paradigma — der Beitrag zu Design Science Research vom Problem zum evaluierten Artefakt beschreibt, wie sich die hier genannten Verfahren in diesen Rahmen einfügen. Weitere Themenzuschnitte und Aufbauvarianten für dein Fach findest du im Überblick zur Bachelorarbeit Informatik mit Themen, Aufbau und technischer Praxis.
Häufige Fragen zur Evaluation in der Informatik
Reicht es, wenn ich zeige, dass mein System funktioniert?
Nein. Ein funktionierender Prototyp ist eine Projektleistung, keine wissenschaftliche Aussage. Eine Abschlussarbeit braucht einen Vergleich: gegen einen etablierten Ansatz, gegen eine frühere Version, gegen den manuellen Prozess oder gegen definierte Anforderungen. Ohne Vergleichsmaßstab gibt es keine bewertbare Erkenntnis.
Wie viele Teilnehmende braucht eine Nutzerstudie in einer Bachelorarbeit?
Zwölf bis zwanzig sind in einem Within-Subject-Design realistisch und ausreichend. Für ein Between-Subject-Design mit zwei Gruppen bräuchtest du eher 30 pro Gruppe, was in der verfügbaren Zeit selten machbar ist. Für rein qualitative Usability-Tests ohne statistischen Vergleich genügen fünf bis acht Personen, weil dort die meisten schwerwiegenden Probleme bereits sichtbar werden.
Muss ich meinen Code veröffentlichen?
Vorgeschrieben ist es selten, erwartet wird es zunehmend. Ein Repository mit README, Abhängigkeitsliste, Seeds und Anleitung zur Reproduktion der Ergebnisse wird in Gutachten positiv gewertet. Bei Arbeiten mit Unternehmenspartner klärst du vorher die Freigabe und arbeitest gegebenenfalls mit einem Sperrvermerk.
Wie oft muss ich eine Messung wiederholen?
Mindestens fünf Läufe mit unterschiedlichen Zufalls-Seeds, bei stark schwankenden Systemmessungen eher zehn bis dreißig. Berichte anschließend nicht nur den Mittelwert, sondern auch Standardabweichung oder Interquartilsabstand — die Streuung ist oft der interessantere Befund als der Zentralwert.
Was mache ich, wenn mein Verfahren schlechter abschneidet als die Baseline?
Du berichtest es und analysierst es. Ein negatives Ergebnis mit einer sauberen Fehleranalyse — auf welchen Fällen versagt der Ansatz und warum — ist wissenschaftlich wertvoller als ein geschöntes positives Ergebnis und wird in der Bewertung nicht bestraft. Was bestraft wird, ist das Verschweigen ungünstiger Läufe.
Brauche ich einen eigenen Datensatz?
In der Regel nicht. Etablierte öffentliche Datensätze machen deine Ergebnisse vergleichbar und ersparen dir die Diskussion über Datenqualität. Ein eigener Datensatz ist nur dann sinnvoll, wenn dein Problem in keinem vorhandenen Datensatz abgebildet ist — dann wird die Erstellung selbst zu einem dokumentierten Beitrag deiner Arbeit.
Wie lang sollte das Evaluationskapitel sein?
In einer Bachelorarbeit von 50 bis 70 Seiten sind 12 bis 18 Seiten üblich, in Masterarbeiten entsprechend mehr. Als Faustregel sollte die Evaluation nicht deutlich kürzer sein als die Beschreibung der Implementierung — ein Verhältnis von 3:1 zugunsten der Implementierung ist ein sicheres Zeichen für eine unterentwickelte Evaluation.
Kann ich mehrere Evaluationsverfahren kombinieren?
Ja, und in vielen Fällen ist das die stärkste Lösung. Benchmark plus Ablation ist die häufigste sinnvolle Kombination, Benchmark plus Fallstudie die überzeugendste bei Arbeiten mit Praxispartner. Achte darauf, dass jedes Verfahren eine eigene Teilfrage beantwortet — zwei Verfahren für dieselbe Frage kosten Zeit ohne Erkenntnisgewinn.