12. Projektabschluss

Projektabschluss

Eine Woche, vier Ergebnisse: Das System wird abgenommen, übergeben, vorgeführt und rückblickend bewertet.

Der Maßstab steht seit September fest und wird jetzt nicht mehr verhandelt. Es ist das Muss-Set aus Kapitel 1 samt den nichtfunktionalen Zielen, die Sie dort in Zahlen aufgeschrieben haben. Der Unterschied zum Vorjahr liegt genau dort: Damals war die Frage, ob es läuft. Heuer ist die Frage, ob es die Werte einhält, die Sie sich selbst gesetzt haben, und Sie haben seit Kapitel 10 und 11 die Werkzeuge, um das zu messen statt zu behaupten.

Abnahme

Gegen das eigene Zielbild

Das Abnahmeprotokoll ist eine Tabelle, keine Erzählung. Jede Zeile hat einen Nachweis, und der Nachweis ist eine Messung, ein Bildschirmfoto oder ein Testlauf.

| Ziel (Kapitel 1) | Gefordert | Gemessen | Nachweis | Status |
|---|---|---|---|---|
| Antwortzeit Liste | p95 < 400 ms | 310 ms | Dashboard 21.05., 08-18 Uhr | erfüllt |
| Verfügbarkeit | 99 % im Monat | 99,4 % | Prüfung von außen, Mai | erfüllt |
| LCP mobil | < 2,5 s | 2,9 s | Lighthouse gedrosselt | teilweise |
| Barrierefreiheit | WCAG 2.2 AA, Hauptwege | 2 Befunde offen | docs/bedienbarkeit.md | teilweise |
| Wiederherstellung | RTO 4 h, RPO 24 h | 2 h 40, 1 h | Protokoll 14.05. | erfüllt |
| Drittanbieter-Ausfall | Betrieb eingeschränkt möglich | vorgeführt | Video, docs/entscheidungen.md | erfüllt |

Drei Status genügen: erfüllt, teilweise, offen. Teilweise und offen sind keine Schande, solange der Nachweis stimmt und daneben steht, was fehlen würde. Was in der Bewertung wirklich zählt, ist die Übereinstimmung zwischen Protokoll und Wirklichkeit.

Womit gemessen wird

Für jedes Zahlenziel aus Kapitel 1 gibt es ein Werkzeug, das Sie im Lauf des Jahres eingerichtet haben. Nichts davon wird jetzt geschätzt.

Ziel	Womit gemessen	Zeitraum
Antwortzeit p50 und p95	Dashboard aus Kapitel 10	letzte zwei Wochen, Nutzungszeiten
Verfügbarkeit	Prüfung von außen aus Kapitel 10	letzter Monat
Core Web Vitals mobil	Lighthouse gedrosselt, Kapitel 5	Messung am Abnahmetag
Unterstützte Geräte	Testtabelle aus Kapitel 8	über das Jahr geführt
Barrierefreiheit	Werkzeug und Tastaturdurchgang, Kapitel 6	Messung am Abnahmetag
RPO und RTO	Wiederherstellungsprotokoll, Kapitel 11	letzte Übung
Verhalten bei Ausfall fremder Dienste	provozierter Ausfall, Kapitel 3	vorgeführt

Wo Ziel und Messwert auseinandergehen, gehört beides ins Protokoll, und dazu ein Satz, woran es liegt. Ein Ziel im Nachhinein auf den gemessenen Wert zu senken, ist der eine Fehler, der in der Bewertung sicher auffällt, weil die ursprüngliche Fassung in der Git-Historie steht.

Der letzte Durchlauf

1. Funktionsstopp ist längst gesetzt (Woche 16). Diese Woche gibt es nur noch Fehlerbehebung.

2. Halbfertiges entfernen oder als offen kennzeichnen. Ein Knopf, der nichts tut, wird in der Vorführung angeklickt.

3. Release erstellen über die Pipeline: Markierung, Änderungsprotokoll, Freigabe, Rauchtest.

4. Rauchtest und Dashboard ansehen, 15 Minuten nach dem Ausrollen.

5. Prüfliste abarbeiten: Zertifikat, Sicherung der letzten Nacht, Alarme aktiv, Testumgebung nicht indexiert, Datenschutzerklärung passt zur tatsächlichen Verarbeitung.

Übergabe

Die Mappe

Alles, was über das Jahr entstanden ist, an einem Ort und in lesbarem Zustand. Nichts davon wird jetzt geschrieben; jetzt wird geprüft, ob es stimmt.

Datei	Kapitel
README.md	1, 9
docs/architektur.md	1, 3, 8
docs/betrieb.md	9, 10, 11
docs/entscheidungen.md	alle
docs/datenschutz.md	4
docs/sicherheit.md	7
docs/designsystem.md und docs/bedienbarkeit.md	6
docs/sichtbarkeit.md	5
docs/notfallplan.md und Handlungsanweisungen	11
docs/risiken.md, docs/offene_punkte.md	1, 12

Zugänge

Server, Registry, GitLab, Dokploy, CMS, Domain, DNS, Sicherungsablage, Konten bei fremden Diensten, Monitoring. Übergeben wird über den Passwortspeicher mit einer Liste, wer was hat, und nicht über eine Chatnachricht. Wer aus dem Projekt ausscheidet, löst eine Rotation aus, so wie in Kapitel 7 festgelegt.

Wiederherstellbarkeit

Der eigentliche Prüfstein der Übergabe, und er geht diesmal weiter als im Vorjahr: Nicht nur die Sicherung wird eingespielt, sondern das System wird aus der Dokumentation neu aufgebaut. Frischer Server, Anleitung aus docs/betrieb.md, Sicherung von außer Haus, danach ein Rauchtest.

Die Prüffrage, wieder

Könnte eine fremde Person dieses System nächste Woche übernehmen?

Testen Sie es wie im Vorjahr: Ein anderes Team baut nach Ihrer Dokumentation auf, ohne Rückfragen. Was es fragen möchte, notiert es. Diese Liste ist Ihre letzte Aufgabenliste, und sie ist kurz, wenn Sie das Jahr über mitgeschrieben haben.

Präsentation

Aufbau

Fünfzehn Minuten, derselbe Zuschnitt wie im Vorjahr: Problem, Lösung, Vorführung am laufenden System, eine technische Vertiefung, Erkenntnisse und Grenzen.

Neu ist der Anspruch an die Vertiefung. Nehmen Sie etwas, das dieses Jahr ausmacht und das man nicht in zwei Sätzen erklärt: den Anmeldeablauf mit PKCE und der Token-Prüfung, die Vier-Schritte-Migration ohne Ausfall, den Offline-Weg mit Warteschlange und Konfliktbehandlung, das Verhalten beim Ausfall des fremden Dienstes, oder den Vorfall vom April samt Nachbetrachtung. Zeigen Sie das Problem, die Entscheidung, die Messung.

Ein Vorfall, sauber aufgearbeitet, ist übrigens ein besserer Vortragsstoff als eine Funktion, die immer funktioniert hat. Er zeigt, dass Sie ein System betreiben und nicht nur gebaut haben.

Ersatzplan und Fachgespräch

Die Regeln von voriges Jahr gelten unverändert: am Vortag prüfen, Aufzeichnung des Vorführwegs im Gepäck, lokale Instanz ohne Internet, Bildschirmfotos in den Folien, einmal mit Uhr durchgespielt.

Rechnen Sie mit diesen Fragen, und rechnen Sie damit, dass sie genau dorthin zielen, wo Ihr Protokoll dünn ist:

• Warum dieser fremde Dienst, und was passiert, wenn er ausfällt?
• Woher wissen Sie, dass die Anwendung schnell genug ist?
• Welche personenbezogenen Daten verarbeiten Sie, auf welcher Grundlage, wie lange?
• Wie lange dauert eine Wiederherstellung, und wann haben Sie das zuletzt gemessen?
• Was war Ihr größter Fehler in diesem Jahr, und was haben Sie geändert?

Auf jede dieser Fragen gibt es in Ihrem Repository eine Datei mit der Antwort. Genau dafür wurde sie geschrieben.

Diese Präsentation ist zugleich die Generalprobe für die Reife- und Diplomprüfung: gleiche Struktur, gleicher Zeitrahmen, gleiche Erwartung an Begründung statt Aufzählung.

Retrospektive

Über das Jahr

Dieselben drei Fragen wie im Vorjahr, jetzt über ein Projekt mit Fremdcode, Recht, mehreren Plattformen und Betrieb: Was hat getragen, was hat aufgehalten, was würden Sie anders anlegen. Dazu die Prüfung der Entscheidungen aus Kapitel 1: War das Thema richtig geschnitten? War die Plattformstrategie richtig? Hätten Sie den fremden Dienst wieder genommen?

Über den Schwerpunkt

Vor zwei Jahren	Heute
erste SSH-Verbindung auf einen leeren Server	zwei Umgebungen, Pipeline, Rollback
eine Datei ausliefern	versioniertes Artefakt mit Freigabeprotokoll
„läuft bei mir”	gemessene Antwortzeiten und Verfügbarkeit
Angriffe nachstellen	Bedrohungsmodell vor dem Bauen
eine Anwendung	Anwendung, CMS-Erweiterung, App, fremde Dienste
Fehler bemerken, wenn jemand anruft	Alarm, bevor jemand anruft

Diese Tabelle ist keine Zierde. Wenn Sie sie für Ihr eigenes Projekt füllen können, haben Sie eine belastbare Antwort auf die Frage, was Sie eigentlich können, und die brauchen Sie im Sommer bei jedem Bewerbungsgespräch.

Was mitgeht

Für die Diplomarbeit: Entscheidungsprotokolle, Messungen und Nachweise sind genau die Belege, die dort verlangt werden. Für den Berufseinstieg: Der Unterschied zwischen jemandem, der Webseiten baut, und jemandem, der Webanwendungen betreibt, ist genau das, was in diesem Jahr dazugekommen ist.

Häufige Stolperfallen

1. In der letzten Woche noch eine Funktion beginnen.
2. Abnahme ohne Messung. „Fühlt sich schnell an” ist kein Nachweis.
3. Zielwerte nachträglich angepasst, damit alles grün aussieht.
4. Übergabemappe aus dem Gedächtnis statt aus dem laufenden Protokoll.
5. Zugänge per Chatnachricht übergeben.
6. Wiederherstellbarkeit behauptet, aber nie aus der Dokumentation aufgebaut.
7. Präsentation ohne Ersatzplan.
8. Nur zeigen, was funktioniert. Die eigenen Grenzen zu kennen ist Teil der Leistung und wird bewertet.
9. Server sofort nach der Präsentation gekündigt, obwohl die Beurteilung noch läuft.

Lernergebnisse

• Beurteilen: die Zielerreichung gegen die eigenen funktionalen und nichtfunktionalen Anforderungen bewerten und belegen.
• Erschaffen: ein komplexes System in einer Produktivumgebung abnehmen und übergeben.
• Anwenden: die Wiederherstellbarkeit durch Neuaufbau aus Dokumentation und Sicherung nachweisen.
• Erklären: Aufbau, Entscheidungen und Grenzen vor Fachpublikum vertreten und Nachfragen standhalten.
• Beurteilen: den eigenen Jahres- und Ausbildungsverlauf rückblickend einordnen.

Arbeit am Jahresprojekt

• Abnahmeprotokoll gegen Muss-Set und Zahlenziele, jede Zeile mit Nachweis und Status.
• Vollständige Übergabemappe nach der Tabelle oben, geprüft durch ein anderes Team.
• Nachweis der Wiederherstellbarkeit durch Neuaufbau, mit Protokoll und Zeiten.
• Übergebene Zugänge mit Liste, wer was hat.
• Abschlusspräsentation mit Vorführung, Vertiefung und Fachgespräch.
• Schriftliche Retrospektive über Jahr und Schwerpunkt.

Passende Übungen

• Aufgabe - Abnahme gegen das eigene Zielbild
• Aufgabe - Übergabemappe zusammenstellen
• Aufgabe - Abschlusspräsentation und Fachgespräch