Ergebnisse der Prüfung vom 17.02.2022

Die Prüfung musste leider aufgrund der Pandemie online als elektronische schriftliche Ausarbeitung und nicht als “normale”Klausur stattfinden. Und so sperrig wie dieser Begriff ist, so vergleichsweise aufwendig gestaltet sich die Korrektur. Dazu unten mehr. Zuerst zu den Ergebnissen…

Ergebnisse

Wir haben einen Schnitt von 3.33. Dieser Durchschnitt ist immer problematisch, weil jedes Nichtbestehen (5.0) übergewichtet wird. (Es gibt weder die Note 4.3 noch 4.7, und Diskretisierung vor der Mittelwertbildung ist ebenfalls problematisch.)

Wenn wir nur die bestandenen Prüfungen betrachten, dann liegt der Durchschnitt bei 2.85.

Insgesamt haben 133 Leute die Prüfung bestanden.

Kann ich sehen, wie viele Punkte ich auf welche Teilaufgabe bekommen habe?

Wenn Du wissen willst, wie viele Teilpunkte Du auf welche Aufgabe bekommen hast, kannst Du das wie folgt abfragen:

Ersetze in der folgenden URL HOST durch vccourses3.cs.ovgu.de und code durch Deinen Prüfungscode (wie in exam.pdf bzw. answers.pdf aber in Kleinbuchstaben):

https://HOST/pubdoc/einfinf-220217-83g5m7amg5xg/code

Der Link liefert Dir dann eine Übersicht als JSON-Objekt. Das ist zwar nicht aufwendig formatiert aber leicht lesbar. Ein Wert null bedeutet, dass für eine Aufgabe nichts eingereicht bzw. bewertet wurde. Wer nichts außer die Erklärung ok.md eingereicht hat, taucht hier nicht auf.

Wir werden im Lauf des Sommersemesters die Möglichkeit zur Einsicht geben. Bitte bereite Dich mit Hilfe der Übersicht darauf vor, so dass Du gezielt fragen kannst.

Prüfung und Korrektur in Zahlen

Wir hatten 175 Abgaben von 204 Anmeldungen. Insgesamt waren 5361 Teilaufgaben (einzelne Fragen oder Abgabe einer Datei) zu bewerten.

Davon entfallen 4473 auf Antworten zu Fragen (answers.pdf), von denen wurden 2828 automatisch – d.h. nach algorithmischen Regeln – korrigiert, die restlichen 1645 manuell.

Von den 888 eingereichten Dateien waren 783 editiert worden, die anderen waren identisch mit den Vorgaben. Für Java-Code wurden Unit-Tests ausgeführt. Jede einzelne Datei wurde gesichtet und individuell bewertet. Selbst wenn man nur gut drei Minuten pro Datei ansetzen müsste, wären das alleine schon 40 Stunden bzw. eine Woche für eine Person.

Warum dauert die Korrektur länger als sonst?

Wir bemühen uns grundsätzlich, Prüfungen flott zu korrigieren. Für eine “normale” Klausur auf Papier heißt das, dass wir uns mit $n$ Leuten in einem Raum setzen, korrigieren und nach $m$ Tagen wieder rauskommen. Im Schnitt rechnen wir dabei mit ca. 40 Stunden für 100 Klausuren. Damit liegen wir für eine typische EinfInf-Klausur mit $n=6$ bei (knapp) $m=2$ Tagen. Das ist unser Anspruch… nur leider klapp das für die elektronische Variante nicht!

Intuitiv muss “digital” effizienter sein als “Papier-analog”. In der Praxis ist es das leider nicht – zumindest nicht für unseren Rahmen und unsere Größenordnungen:

Es ist vergleichsweise einfach, einen Stapel Klausuren auf $n$ Leute aufzuteilen. Es ist schnell mit dem Stift ein Haken gesetzt oder ein paar Worte an eine bestimmte Stelle(!) geschrieben. Wir korrigieren immer nach Aufgaben: Es ist schneller oder zumindest intuitiver, einen Papierbogen zu durchblättern als in einem Verzeichnisbaum eine Datei zu finden und zu öffnen (hier hilft fzf, s.u.). Es ist ein deutlich nüchterneres Arbeiten vor dem Rechner ohne Interaktion mit anderen, kurzen Diskussionen, Rückfragen oder nur ein paar Worte zu sprechen.

Die entscheidenden Faktoren waren am Ende:

  • Wir sind nur $n=2$ potentielle Korrektoren (Christian & Christian; Thomas ist in Elternzeit), weil es wenig Sinn hat, andere in den elektronischen Workflow einzuweisen.
  • Die Pandemie hat leider dafür gesorgt, dass wir beide ausfielen…
  • Die Vorverarbeitung der Daten kann nur eine Person übernehmen, das war ich selbst. Das beinhaltet die Implementierung von Regeln zur (semi-)automatischen Bewertung, wo sinnvoll und möglich. Erst wenn das geschehen ist, ist es sinnvoll “manuell” zu korrigieren. Ab dann galt $n=2$.
  • Der Workflow für die eigentliche Korrektur ist zwar eintönig aber hinreichend effizient.

Tatsächlich hat die “digitale Korrektur” auch Vorteile. Ein Beispiel ist, dass wir komplett anonym korrigiert haben: wir sehen jeweils nur den Code aber keinen Namen, den wir zuordnen könnten. Das ist für uns sehr viel angenehmer. Auf Papier lässt sich das so stringent nicht umsetzen.

Zu unserem Workflow

Die Programmieraufgaben wurden entweder in einem lokalen Verzeichnisbaum ($(CODE)/$(AUFGABE)) oder in einer hier gehosteten(!) Gitlab-Instanz bewertet. In beiden Fällen so, dass konkrete Stellen im Quellcode mit (Teil-)Punkten/Kommentaren annotiert wurden. Für die Web-Instanz wurden die Kommentare dann mittles Gitlab API exportiert.

Für die lokale Korrektur halfen zum schnellen Einsehen und Editieren von Dateien eine Reihe von eigenen Ruby-Skripten, die im Kern fzf zur Auswahl von Alternativen verwenden. Dazu kommen bat und glow zur schnellen “Vorschau”.

Auswertung mit mit Julia und DataFrames war robuster als Tabellenkalkulation (die hatte an einigen Stellen ein “Eigenleben”).

Wer es nicht kennt: fzf ist Kommandozeilen-Tool zur schnellen Auswahl aus potentiell vielen Alternativen und sehr cool!

Noch cooler gepaart mit GNU Emacs – dazu vterm mit emacsclient und with-editor, sowie pdf-tools) – alles in einem Fenster/Frame!