17. Projektabschluss

Projektabschluss

Ein Softwareprojekt wird nicht fertig. Es wird übergeben, und zwar in einem Zustand, in dem jemand anderer damit weiterarbeiten kann. Das ist ein anderer Maßstab als „läuft bei uns”, und er entscheidet in diesen zwei Wochen über Ihre Note.

Drei Eigenschaften machen ein übergebenes System aus. Es läuft, auf dem eigenen Server, unter der eigenen Domain, mit gültigem Zertifikat. Es ist dokumentiert, so weit, dass eine fremde Person es übernehmen könnte. Und es ist erklärbar: Sie können begründen, warum es so gebaut ist und wo seine Grenzen liegen.

Der Maßstab für den Umfang steht seit Kapitel 1 fest. Es ist das Muss-Set, das Sie im September aufgeschrieben haben, und nicht die Wunschliste, die im Lauf des Jahres gewachsen ist.

Restarbeiten und Einfrieren

Der Funktionsstopp

Ab einem festgelegten Tag, zwei Wochen vor der Abnahme, kommt nichts Neues mehr dazu. Ab dann gibt es nur noch Fehlerbehebung, Dokumentation und Vorbereitung.

Der Grund ist arithmetisch. Eine neue Funktion in der letzten Woche bringt Code, der nicht geprüft wurde, keine Tests hat, in keiner Dokumentation steht und im Sicherheitsreview aus Kapitel 16 nicht enthalten war. Sie riskieren ein laufendes System für eine Sache, die in der Vorführung ohnehin niemand vermisst hätte.

Schreiben Sie das Datum in die Projektunterlagen und halten Sie es ein. Der Reflex, in der letzten Woche noch die Kalenderansicht mit Drag-and-drop nachzurüsten, ist erstaunlich stark und hat schon viele Vorführungen zerstört.

Halbfertiges behandeln

Für jeden offenen Punkt gibt es drei Möglichkeiten, und die mittlere ist die, die niemand wählen will.

• Fertigstellen, wenn er im Muss-Set steht und in der verbleibenden Zeit sicher machbar ist.
• Entfernen, wenn er halbfertig ist. Ein Knopf, der nichts tut, ein Menüpunkt, der auf eine leere Seite führt, ein Formular, das speichert, aber nichts anzeigt: Das ist schlechter als eine fehlende Funktion, weil es beim Benutzer Vertrauen kostet und in der Vorführung garantiert angeklickt wird.
• Als offen kennzeichnen, in docs/offene_punkte.md, mit einem Satz dazu, warum es offen ist und was fehlen würde.

Diese Datei ist kein Eingeständnis, sondern Teil der Leistung. Ein Projekt ohne offene Punkte gibt es nicht; es gibt nur Projekte, die ihre offenen Punkte kennen, und solche, die sie nicht kennen.

Der letzte Durchlauf

Bevor die Dokumentation geschrieben wird, läuft das System einmal von vorne durch. Nicht auf dem Rechner, auf dem alles schon eingerichtet ist.

1. Frisches Deployment. Neuen Stand bauen und ausrollen, wie in Kapitel 3. Die Dauer stoppen und aufschreiben.

2. Migrationen. prisma migrate deploy gegen die echte Datenbank, ohne Handgriffe daneben. Wenn hier etwas händisch nachgezogen werden muss, ist das ein Befund und gehört behoben.

3. Grunddaten. Ein Seed-Skript legt Rollen, Testkonten und Beispieldaten an, damit ein leeres System vorführbar ist.

4. Rauchtest. Eine feste Liste, die Sie abhaken: anmelden, Liste öffnen, Objekt anlegen, ändern, löschen, abmelden, eine Inhaltsseite aus dem CMS aufrufen, Zertifikat prüfen, mobile Ansicht prüfen. Zehn Punkte, fünf Minuten, jedes Mal dieselben.

5. Sicherung. Einmal ziehen, einmal einspielen, Zeitbedarf notieren. Falls Kapitel 16 das bereits erbracht hat, reicht der Verweis.

Die Dokumentationsmappe

Alles, was das Jahr über entstanden ist, kommt jetzt an einen Ort und in einen lesbaren Zustand.

Datei	Inhalt	Aus Kapitel
README.md	Zweck, Aufbau, lokaler Start, Deployment in drei Schritten	1, 3
docs/architektur.md	Systemskizze, Schnitt, Datenmodell, Schnittstellenvertrag	1, 4, 6
docs/betrieb.md	Server, Domains, Dienste, Zugänge, Eingriffe, Sicherung	2, 3
docs/haertung.md	Härtungsmaßnahmen mit Nachweis	2
docs/sicherheitsbericht.md	Prüfung, Befunde, Behebung, Restrisiken	16
docs/performance.md	Messungen, Maßnahmen, Ergebnisse	13
docs/bedienbarkeit.md	Befunde, Behebungen, Barrierefreiheit	15
docs/entscheidungen.md	Entscheidungsprotokolle des ganzen Jahres	1
docs/redaktion.md	Leitfaden für die Redaktion	14
docs/offene_punkte.md	Was offen ist und warum	17

Das README

Die erste Seite, die jemand sieht, und die einzige, die viele lesen. Sie beantwortet vier Fragen in dieser Reihenfolge: Was macht das Projekt? Wie starte ich es lokal? Wie liefere ich es aus? Wo finde ich den Rest?

Der lokale Start gehört auf eine Länge, die niemanden abschreckt:

cp .env.example .env         # fill in the values, see docs/betrieb.md
docker compose up -d db      # start the database
npm ci
npx prisma migrate dev
npm run seed
npm run dev                  # http://localhost:3000

Testen Sie das auf einem Rechner, auf dem das Projekt noch nie lief. Der häufigste Fehler ist ein fehlender Schritt, den alle im Team im Februar einmal gemacht und danach vergessen haben.

Die Betriebsdokumentation

Der Teil, den Entwicklerteams am liebsten auslassen, und der in der Übergabe am meisten gebraucht wird. Hinein gehören:

• Welcher Server, welcher Anbieter, welche IP, wer hat Zugang.
• Welche Domains und Subdomains zeigen wohin, wo liegt der DNS-Eintrag.
• Welche Dienste laufen in welchen Containern, welche Volumes gibt es.
• Wo liegen die Geheimnisse. Die Werte selbst kommen nicht hinein, nur der Ort: Passwortspeicher, Umgebungsvariablen in Dokploy.
• Wie man ein Deployment auslöst und wie man zurückrollt.
• Wie Sicherung und Wiederherstellung laufen, mit Zeitbedarf.
• Die Eingriffstabelle des Jahres: Was ist ausgefallen, was war die Ursache, was hat geholfen.

Die Prüffrage

Für jede Datei in der Mappe gilt eine einzige Frage: Könnte eine fremde Person das System damit übernehmen?

Und diese Frage lässt sich testen. Geben Sie Ihre Dokumentation einem anderen Team und lassen Sie es damit einen Server neu aufsetzen, ohne zu helfen und ohne Rückfragen zu beantworten. Was das Team fragen möchte, notiert es; diese Liste ist Ihre Aufgabenliste für den letzten Tag.

Es ist unangenehm und dauert einen Nachmittag. Es ist die wirksamste Dokumentationsprüfung, die es gibt.

Übergabe

Das Gespräch

Vierzig Minuten, mit einer festen Reihenfolge:

1. Das laufende System zeigen, kurz, entlang des Rauchtests.
2. Die Mappe durchgehen und zeigen, wo was steht.
3. Zugänge übergeben: Server, Dokploy, CMS, Domain, Sicherungsablage. Über den Passwortspeicher, nicht über einen Chat und nicht auf einem Zettel.
4. Offene Punkte und Restrisiken benennen, aus docs/offene_punkte.md und dem Sicherheitsbericht.
5. Wiederherstellbarkeit nachweisen.

Punkt 5 ist der Kern der Abnahme. Entweder Sie spielen eine Sicherung ein und zeigen, dass die Daten wieder da sind, oder Sie setzen den Server nach Ihrer eigenen Betriebsdokumentation neu auf. Ein System, das man nicht wiederherstellen kann, ist kein übergebenes System, sondern eine laufende Instanz mit begrenzter Haltbarkeit.

Individuelle Beiträge

Die Beurteilung sieht die Gruppe und die Einzelperson (Grundsatz 6 der Beurteilung). Der Nachweis dafür entsteht nicht am letzten Tag, sondern liegt bereits vor: in der Git-Historie, in den Reviews, in den Entscheidungsprotokollen, in den Befunden mit Ihrem Namen.

Legen Sie eine knappe Übersicht dazu, wer welche Bereiche verantwortet hat und wo das im Repository sichtbar ist. Wenn jemand im Team hauptsächlich Betrieb, Dokumentation und Review gemacht hat, gehört das genauso hinein wie Codezeilen. Was nirgends steht, kann nicht bewertet werden.

Die Präsentation

Aufbau

Fünfzehn Minuten, grob so aufgeteilt:

Teil	Zeit	Inhalt
Problem	2 min	Wer hat welches Problem, und woran merkt man es
Lösung	2 min	Was Ihr System tut, in Sätzen ohne Fachwörter
Vorführung	5 min	Am laufenden System, entlang einer echten Aufgabe
Vertiefung	4 min	Ein technischer Aspekt Ihrer Wahl, in der Tiefe
Erkenntnisse	2 min	Was Sie gelernt haben, was offen ist

Die Vorführung folgt einer Aufgabe, nicht dem Menü. „Frau Berger will morgen die Fräse für zwei Stunden” führt durch das System und zeigt nebenbei alles, was zählt. Ein Rundgang durch alle Menüpunkte zeigt nichts und dauert länger.

Die Vertiefung ist der Teil, an dem sich die Note entscheidet. Nehmen Sie etwas, das tatsächlich schwierig war: die optimistische Sperre gegen Doppelbuchungen, die Content-Security-Policy mit Nonces, den Umbau, der aus dem Sicherheitsreview kam, den Index, der die Belegungsansicht von 800 auf 40 Millisekunden gebracht hat. Zeigen Sie das Problem, den Weg und die Messung. Was Sie hier nicht brauchen: eine Folie mit den Logos aller verwendeten Technologien.

Der Ersatzplan

Live-Vorführungen fallen aus. Das WLAN in der Aula, ein abgelaufenes Zertifikat, ein Container, der genau heute nicht startet, ein Beamer, der 4:3 will.

1. Am Vortag prüfen: Deployment, Zertifikatslaufzeit, Testkonten, Beispieldaten. Zertifikate laufen gerne genau dann ab, wenn niemand hinsieht.

2. Aufzeichnung anlegen. Der komplette Vorführungsweg als Bildschirmaufnahme mit zwei bis drei Minuten Länge, lokal auf dem Notebook.

3. Lokale Instanz vorbereiten, die ohne Internet läuft. Damit überlebt die Vorführung auch einen Netzausfall.

4. Bildschirmfotos in die Folien, an den Stellen, die Sie vorführen wollen. Wenn nichts mehr geht, präsentieren Sie eben daran.

5. Vorab durchspielen, einmal vollständig, mit Uhr. Die meisten Vorträge sind beim ersten Mal um die Hälfte zu lang.

Fachfragen

Rechnen Sie mit drei Sorten. „Warum haben Sie X genommen und nicht Y?” beantwortet Ihr Entscheidungsprotokoll, deshalb gibt es das. „Was passiert, wenn zwei Personen gleichzeitig buchen?” beantwortet Kapitel 6. „Wie sicher ist das?” beantwortet Ihr Sicherheitsbericht, samt der Restrisiken, die Sie kennen und benennen können.

Auf eine Frage, die Sie nicht beantworten können, gibt es genau eine gute Antwort: „Das haben wir nicht geprüft.” Sie ist besser als jede Erfindung, weil die nächste Nachfrage sie ohnehin aufdeckt. Zu den bewerteten Punkten gehört neben Nachvollziehbarkeit und technischer Tiefe auch der Umgang mit den eigenen Grenzen. Wer sagt, was er nicht weiß, wirkt sicherer als jemand, der um die Frage herumredet.

Retrospektive

Zum Schluss eine schriftliche Rückschau, die drei Fragen beantwortet.

Was hat getragen? Welche Entscheidung, welches Werkzeug, welche Absprache hat sich über das Jahr bewährt. Konkret, mit Beispiel.

Was hat aufgehalten? Wo ist Zeit verloren gegangen, und woran lag es tatsächlich. „Docker war kompliziert” ist keine Antwort. „Wir haben Umgebungsvariablen zur Bauzeit und zur Laufzeit verwechselt und drei Abende gesucht” ist eine.

Was würden Sie anders anlegen? Bezogen auf das nächste Projekt, nicht auf dieses.

Dazu kommt der Rückblick auf die Architekturentscheidung aus Kapitel 1: Fullstack in Next.js oder getrennte Systeme. War das richtig? Was hat die Entscheidung im Betrieb gekostet, was hat sie gebracht? Eine Entscheidung im Nachhinein als falsch zu erkennen, ist ein Ergebnis und kein Fehler. Nur wer sie nicht überprüft, lernt nichts.

Regeln für die Rückschau

Die Rückschau bewertet Arbeitsweisen, nicht Personen. „Wir haben Reviews liegen lassen, wenn es eilig wurde” ist eine Erkenntnis. „Er hat nie reviewt” ist ein Vorwurf und bringt niemanden weiter.

Und: Zwei Punkte, die Sie im nächsten Projekt tatsächlich ändern, sind mehr wert als zwölf gute Vorsätze.

Der Blick auf die 5. Klasse

Was Sie heuer gebaut haben, läuft. Was fehlt, ist alles, was aus einem laufenden System einen Betrieb macht: Sie merken einen Ausfall bisher, wenn jemand anruft. Sie liefern von Hand aus. Sie wissen nicht, wie viele Menschen das System benutzen. Und die rechtliche Seite Ihrer Datenspeicherung haben Sie bisher nur benannt.

Genau dort setzt das nächste Jahr an: Logging und Monitoring, Verfügbarkeit und Zuverlässigkeit, CI/CD, Datenschutz, Designsysteme, Desktop und Mobile, dazu die Vorbereitung auf die Reife- und Diplomprüfung. Das Fundament dafür steht seit dieser Woche.

Häufige Stolperfallen

1. In der letzten Woche eine neue Funktion beginnen. Der teuerste Fehler des ganzen Jahres.
2. Halbfertiges stehen lassen. In der Vorführung wird es angeklickt, verlässlich.
3. Dokumentation am Schluss aus dem Gedächtnis schreiben. Man erkennt es am Ergebnis.
4. Geheimnisse in die Betriebsdokumentation schreiben, die dann im Repository landet.
5. Wiederherstellung nur behaupten. Ohne Nachweis ist die Abnahme unvollständig.
6. Vorführung ohne Ersatzplan.
7. Auf einem System vorführen, das gerade neu deployt wurde. Der Vortag ist der richtige Zeitpunkt.
8. Alle reden ein bisschen. Verteilen Sie Abschnitte, nicht Sätze.
9. Nur die geglückten Teile zeigen. Die eigenen Grenzen zu kennen ist eine Leistung und wird als solche bewertet.
10. Den Server sofort nach der Vorführung kündigen. Er wird bis zum Abschluss der Beurteilung gebraucht.

Lernergebnisse

• Anwenden: einen Funktionsstopp einhalten und Restarbeiten zwischen Fertigstellen, Entfernen und Offenlassen einteilen.
• Erschaffen: ein lauffähiges System vollständig dokumentiert übergeben.
• Anwenden: eine Dokumentationsmappe erstellen, die eine fremde Person zur Übernahme befähigt.
• Anwenden: die Wiederherstellbarkeit des Systems nachweisen.
• Erklären: Aufbau, Entscheidungen und Grenzen des eigenen Systems vor Publikum vertreten.
• Anwenden: eine Vorführung am laufenden System durchführen, samt Ersatzplan.
• Beurteilen: den eigenen Jahresverlauf und die Architekturentscheidung aus Kapitel 1 rückblickend bewerten.

Arbeit am Jahresprojekt

Der Abschluss besteht aus vier Teilen:

• Abnahme des laufenden Systems: erreichbar unter eigener Domain, Rauchtest bestanden, Wiederherstellung nachgewiesen.
• Dokumentationsmappe im Repository, vollständig nach der Tabelle oben, geprüft durch ein anderes Team.
• Abschlusspräsentation von fünfzehn Minuten mit Vorführung, technischer Vertiefung und Fachgespräch.
• Schriftliche Retrospektive samt Rückblick auf die Architekturentscheidung.

Passende Übungen

• Aufgabe - Übergabemappe zusammenstellen
• Aufgabe - Server aus der eigenen Dokumentation neu aufsetzen
• Aufgabe - Abschlusspräsentation und Fachgespräch