Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Die Note für das Modul wird über die eingereichte Hausarbeit gebildet. Dazu wurde vorab eine Projektskizze eingesammelt und die Hausarbeit besteht aus einem Programmierprojekt (Quelltext) sowie einem Projektbericht (PDF).

Geplanter Bearbeitungszeitraum: 4 Wochen, z.B. ca. 28.7. bis 25.8. oder auch 1-2 Wochen später.

Abgabedatum: wird zu Semesterbeginn festgelegt und hier eingetragen. Verbindlich ist der Termin, der in ILIAS und im LSF steht.

Teamgröße: maximal zwei Personen. Eine Abgabe zu zweit ist erlaubt und muss vorher angekündigt werden, damit die Projektskizze entsprechend zugeschnitten werden kann — ein Zweierprojekt darf und soll mehr Umfang haben als ein Einzelprojekt. Beide Matrikelnummern gehören in den Dateinamen des Berichts (siehe formale Kriterien unten), und der Bericht benennt, wer welchen Teil verantwortet hat. Bewertet wird die Arbeit gemeinsam; wenn die Eigenanteile im Bericht nicht erkennbar sind, ist das ein Mangel des Berichts.

Wir bewerten den Programmcode und den Bericht anhand formaler Kriterien und bewerten außerdem, wie viel, wie gut der Plan inhaltlich umgesetzt und beschrieben wurde.

Dabei bekommt eine 2,0 wer die formalen Kriterien im Wesentlichen knapp umgesetzt hat und die in der Projektskizze beschriebene Minimalanforderung ebefalls knapp umgesetzt hat. Wer Teile des ursprünglichen Plans nicht umsetzt, obwohl das möglich gewesen wäre, oder auch gröbere Fehler in der Programmlogik o.ä. hat, kann entsprechend auch leicht eine 3,0 bekommen auch wenn die formalen Kriterien erfüllt sind. Bei Nichterfüllen der formalen Kriterien ist es leicht möglich, durchzufallen, oder aber (bei nur geringen Verstößen und einer sonst guten Arbeit) nur eine 4,0 zu bekommen. Wenn das Projekt die Minimalanforderungen, die geplant waren, erfüllt, aber insgesamt einen sehr geringen Umfang aufweist, kann auch das zu einer 4,0 führen (wenngleich wir das im Vorfeld durch unsere intensive Diskussion der Projektskizzen weitgehend vermieden haben sollten).

Eine 1,0 gibt es, wenn über die Erfüllung der formalen Kriterien und der selbst gesetzten Mindestanforderungen hinaus erfolgreich gearbeitet wurde.

Formale Kriterien Code

Nice-to-have

Formale Kriterien Bericht

Leicht vermeidbare Fehler

Die Kriterien oben sind keine Geschmacksfragen, sondern Prüfpunkte — und genau deshalb ist es schade, wie oft sie an Kleinigkeiten scheitern. Die folgenden acht Punkte sind nach Häufigkeit geordnet, mit der sie in vergangenen Jahrgängen aufgetreten sind. Alle acht kosten weniger als eine halbe Stunde, wenn man sie vor der Abgabe prüft, und alle acht kosten eine Note, wenn man es nicht tut.

  1. Kein Git-Repository. Das ist mit Abstand der häufigste Einzelbefund — rund ein Drittel der Abgaben kam als Ordner oder ZIP ohne Versionsgeschichte. Der Punkt steht als erster in den formalen Kriterien, und er ist der einzige, den man nicht nachträglich erfüllen kann: Eine Commit-Historie lässt sich am Abgabetag nicht erfinden. Legen Sie das Repository am ersten Tag an (Übung 0, Aufgabe 3) und committen Sie in kleinen Schritten weiter.

  2. Tests, die fehlschlagen. Das Kriterium lautet „mindestens ein Unit Test und mindestens ein Doctest (die auch nicht fehlschlagen)". Ein einziger Aufruf von uv run pytest vor der Abgabe hätte das gezeigt. Wenn ein Test aus einem bekannten Grund scheitert, den Sie nicht beheben können, schreiben Sie diesen Grund in den Bericht — ein erklärter roter Test ist etwas ganz anderes als ein unerwähnter.

  3. Mypy-Fehler. Das Kriterium erlaubt höchstens einen. Häufige Ursachen sind nicht Ihre Schuld: eine Bibliothek ohne Typinformationen, oder eine Python-Version, die neuer ist als das Paket-Ökosystem. Genau dann gehört aber beides in die Arbeit — ein [[tool.mypy.overrides]]-Eintrag mit Begründung in der pyproject.toml (siehe Code-Qualität) und ein Satz im Bericht. Ohne das sieht es aus, als hätten Sie den Checker nie laufen lassen.

  4. Ruff-Befunde, die sich selbst beheben. Die tatsächlich gefundenen waren überwiegend Import-Reihenfolge (I001) und Zeilenlänge (E501) — beides behebt uv run ruff check --fix . in einem Aufruf, gefolgt von uv run ruff format ..

  5. Docstring-Coverage unter der Grenze. 20 % sind Pflicht, und uv run interrogate -v . sagt Ihnen die Zahl in einer Sekunde. Wer darunter liegt, hat meist gar nicht nachgesehen.

  6. Das Projekt läuft nicht aus einem frischen Klon. Typische Ursachen: eine Abhängigkeit fehlt in der pyproject.toml, ein absoluter Pfad aus dem eigenen Dateisystem, eine Datendatei, die nie eingecheckt wurde. Testen Sie das wirklich — in einem neuen Verzeichnis, nicht in Ihrem Arbeitsordner:

    git clone <ihr-repo> /tmp/abgabetest && cd /tmp/abgabetest
uv sync && uv run <ihr-programm>

  7. Bericht ohne Funktionsnachweis. Abschnitt 4 der Gliederung verlangt ihn, und er ist billig: ein Screenshot, ein Terminal-Mitschnitt, die Ausgabe eines Beispieldurchlaufs. Ohne ihn bleibt beim Lesen die Frage offen, ob das Programm überhaupt läuft — und diese Frage schlägt auf die Note durch, auch wenn es in Wahrheit läuft.

  8. Unerklärte Abweichung von der Projektskizze. Von der Skizze abzuweichen ist ausdrücklich erlaubt und oft vernünftig — sie ist nicht verbindlich. Es nicht zu erwähnen ist der Fehler. Ein Absatz in Abschnitt 5 („Abweichung vom ursprünglichen Plan") genügt, und er wird positiv gelesen, wenn er begründet ist.

Die Prüfung, die alles davon abdeckt

Führen Sie das am Tag vor der Abgabe aus, nicht am Abgabetag:

git log --oneline | wc -l      # gibt es eine Historie, und ist sie plausibel?
uv run ruff check . && uv run ruff format --check .
uv run mypy .
uv run pytest
uv run interrogate -v .

Fünf Befehle, zwei Minuten. Sie decken die Punkte 1 bis 5 vollständig ab; Punkt 6 braucht den frischen Klon von oben, und 7 und 8 sind zwei Absätze im Bericht.

Ein Hinweis zur Einordnung: Diese Liste ist kein Katalog von Kleinigkeiten, an denen Arbeiten scheitern sollen. Sie ist das Gegenteil — die formalen Kriterien sind absichtlich mechanisch prüfbar formuliert, damit Sie sie selbst abhaken können, bevor jemand anderes es tut. Der inhaltliche Teil der Bewertung ist der schwierigere, und dort wollen Sie Ihre Zeit verbringen.

Tipps zum Schreiben des Projektberichts:

Mögliche Gliederung

  1. Einleitung

    • Motivation,

    • Zielsetzung (Variante der Projektskizze)

  2. Theoretische Grundlagen & Werkzeuge

    • Technologien,

    • Bibliotheken,

    • Welche Pakete/Bibliotheken kamen zum Einsatz?

    • Mensch vs. KI: Die Rolle von AI Assistance

  3. Konzept & Implementierung

    • Programmstruktur,

    • Kernlogik,

    • Datenverarbeitung

    • Warum so?

    • Warum wurde die Software genau so strukturiert (z. B. Wahl bestimmter Entwurfsmuster, OOP-Strukturen oder funktionaler Ansätze)? Welche Alternativen wurden verworfen und warum?

    • KI-Konsultation bei Design-Entscheidungen: Wurde die KI bereits bei der Planung und Architektur des Projekts um Rat gefragt? Wenn ja, welche Vorschläge der KI wurden übernommen und wo wurde bewusst von der KI-Empfehlung abgewichen, weil menschliche Intuition/Logik besser passte?

    • Code-Generierung (Was wurde wie programmiert?):

    • KI-generiert: Welche Module, Funktionen oder Tests wurden maßgeblich mit KI-Unterstützung (z. B. ChatGPT, Copilot) erstellt? Warum war hier der KI-Einsatz sinnvoll (z. B. Boilerplate-Code, Standard-Algorithmen, Regex)?

    • Selbst programmiert: Welche Kernlogiken, komplexen Workarounds oder spezifischen Features wurden komplett selbst geschrieben? Warum war hier die eigene Programmierleistung notwendig (z. B. weil die KI den Kontext nicht verstand oder zu fehlerhaftem Code neigte)?

    • Prompt-Engineering & Iteration: Wie sah die Zusammenarbeit mit der KI aus? Wurde Code blind übernommen oder gab es kritische Iterationsschleifen, in denen KI-Fehler (Halluzinationen, veraltete Syntax) manuell korrigiert werden mussten?

  4. Ergebnisse

    • Funktionsnachweis,

    • Beispiel-Durchlauf

  5. Diskussion & Fazit

    • Inwiefern wurde das Ziel erreicht?

    • Herausforderungen,

    • Kritische Reflexion,

    • Abweichung vom ursprünglichen (Implementierungs)Plan?

    • Kritische Würdigung: Was lief gut, wo gab es unerwartete Probleme (entweder technischer Natur oder in der Zusammenarbeit mit der KI)? Was würde man beim nächsten Mal anders machen?

    • Ausblick (darf auch subjektiv sein)

  6. Literatur- & Quellenverzeichnis

    • falls etwas zitierfähiges genutzt wurde (sonst kann das weg)

  7. Anhang (wenn etwas zu lang für den Haupttext ist)

    • Ggf. Bedienungsanleitung,

    • ausgewählte Code-Snippets (nichts länger als eine Seite)

Übungsaufgaben
Übung 12