1. Projektstart und Zielbild

Projektstart und Zielbild

Dieses Jahr hat 21 Unterrichtswochen, danach kommt die Matura. In diesen 21 Wochen soll eine Anwendung entstehen, die tatsächlich in einer Produktivumgebung läuft, Fremdcode enthält, auf Telefon und Rechner benutzbar ist, rechtlich hält und im Betrieb beobachtet wird.

Das geht, aber nur mit einem Thema, das am Ende der ersten Woche feststeht. Der häufigste Grund, warum ein Maturajahrprojekt nicht in Produktion kommt, ist nicht mangelndes Können. Es ist ein Thema, das in der dritten Woche noch diskutiert wurde, oder eines, das für 21 Wochen um den Faktor drei zu groß war.

Am Ende dieser Woche steht deshalb: ein festgelegtes Thema, ein Zielbild mit prüfbaren Anforderungen, ein Jahresplan mit Terminen, zwei laufende Umgebungen und ein Repository mit Dokumentationsgerüst.

Was dieses Jahr anders macht

In der 4. Klasse haben Sie die Kette einmal ganz gebaut: Server, Webservice, Datenbank, Frontend. Alles darin war Ihr eigener Code, und alles lief auf einer Umgebung.

Dieses Jahr kommen drei Dinge dazu, die den Unterschied zwischen einer Übung und einer Anwendung ausmachen.

Fremdcode. Sie greifen in ein System ein, das Sie nicht geschrieben haben, und Sie binden Dienste ein, die Ihnen nicht gehören. Beides bringt eine neue Fehlerklasse mit: Das fremde System ändert sich, ohne Sie zu fragen.

Reichweite. Dieselbe Anwendung auf Telefon und Rechner, auffindbar über Suchmaschinen, benutzbar für Menschen mit unterschiedlichen Voraussetzungen, rechtlich sauber.

Betrieb. Sie liefern kontrolliert aus, Sie sehen im laufenden Betrieb, was passiert, und Sie bemerken einen Ausfall, bevor jemand anruft.

Der Lehrplan verlangt eine komplexe Anwendung. Das heißt nicht kompliziert und nicht viele Bildschirme. Es heißt: mehrere Systeme, die zusammenspielen, und ein Betrieb, der das aushält.

Das Thema

Fortführen oder neu anfangen

Beides ist erlaubt, und die Entscheidung gehört begründet.

	Projekt der 4. Klasse fortführen	Neues Thema
Vorteil	Datenmodell und Deployment stehen, Zeit fließt in den neuen Stoff	Zuschnitt passt genau auf die Anforderungen dieses Jahres
Nachteil	Der alte Zuschnitt passt selten auf Fremddienste und mobile Nutzung	Zwei bis drei Wochen gehen für den Unterbau drauf
Sinnvoll wenn	das System läuft, sauber gebaut ist und Anknüpfungspunkte hat	das alte Thema keinen Fremddienst und keinen mobilen Anwendungsfall hergibt

Ein häufiger Irrtum: Die Fortführung sei automatisch der schnellere Weg. Sie ist es nur, wenn der alte Stand solide ist. Ein Projekt, das im Juni gerade so durch die Abnahme gekommen ist, kostet mehr Zeit an Aufräumarbeit, als ein neuer Anfang kosten würde.

Pflichtabdeckung

Ihr Thema muss alle Kompetenzbereiche dieses Jahres hergeben. Prüfen Sie es vor der Festlegung gegen diese Liste, und zwar schriftlich.

Anforderung	Wird gebraucht in	Prüffrage an Ihr Thema
Redaktioneller Anteil mit eigener Erweiterung	Kapitel 2	Welche Inhalte pflegt jemand, der nicht programmiert, und was kann das CMS dafür noch nicht?
Mindestens ein Drittanbieter-Service	Kapitel 3	Welcher fremde Dienst liefert echten Nutzen, nicht nur eine Landkarte zur Dekoration?
Personenbezogene Daten	Kapitel 4	Wessen Daten speichern Sie, und wofür?
Öffentlich auffindbarer Teil	Kapitel 5	Was soll über eine Suchmaschine gefunden werden?
Mehrere Bildschirme mit echten Abläufen	Kapitel 6	Gibt es einen Ablauf über mehrere Schritte, oder ist alles ein Formular?
Anmeldung und Rechte	Kapitel 7	Wer darf was, und gibt es mindestens zwei Rollen?
Mobiler Anwendungsfall	Kapitel 8	Wozu holt jemand unterwegs das Telefon heraus?
Betrieb mit Zustand	Kapitel 10, 11	Was tut das System, wenn niemand hinsieht?

Die Zeile zum mobilen Anwendungsfall wird am häufigsten schöngeredet. „Die Seite ist responsiv” ist kein mobiler Anwendungsfall. Ein Anwendungsfall ist: Der Kassier scannt beim Vereinsfest QR-Codes am Eingang. Die Wanderin öffnet die Tourenbeschreibung ohne Netz. Der Werkstattleiter fotografiert einen Schaden und hängt ihn an das Ticket.

Ausschlusskriterien

Ein Thema fällt durch, wenn eines davon zutrifft:

Es kommt kein Fremdsystem vor. Dann fehlt Kapitel 3 das ganze Jahr.
Es gibt keine redaktionellen Inhalte. Dann bleibt Kapitel 2 eine Trockenübung.
Es gibt keine denkbaren Benutzer. Ohne Benutzer kein Bedienbarkeitstest in Kapitel 6.
Es gibt keinen mobilen Anwendungsfall.
Der geplante Fremddienst verlangt eine Firmenprüfung, eine Gewerbeberechtigung oder eine Kreditkarte, die Sie nicht haben. Prüfen Sie das jetzt, nicht im November.
Sie bräuchten Daten, die Sie nicht verarbeiten dürfen. Gesundheitsdaten echter Personen sind kein Schulprojekt.

Themenkatalog

Thema	Fremddienst	Redaktioneller Anteil	Mobiler Anwendungsfall
Vereinsverwaltung	Zahlungsdienst im Testmodus, Mailversand	Vereinsnachrichten, Statuten, Termine	Anwesenheit beim Training erfassen
Veranstaltungen und Tickets	Zahlungsdienst, QR-Erzeugung	Programm, Künstlerseiten	Einlasskontrolle mit Kamera
Wanderrouten-Portal	Kartendienst, Höhendaten	Tourenbeschreibungen mit Bildern	Route unterwegs, auch ohne Netz
Reparaturannahme	Mailversand, Objektspeicher für Fotos	Anleitungen, Öffnungszeiten	Schaden fotografieren und melden
Nachhilfevermittlung	Kalender-Anbindung, Videokonferenz-Link	Fächerseiten, Profile	Termin unterwegs bestätigen
Regionaler Hofladen	Zahlungsdienst, Karte	Produktbeschreibungen, Hofporträts	Bestellung an der Abholstation
Werkstattbuchung, fortgeführt	Kalender-Anbindung, Mailversand	Sicherheitsunterweisungen, Maschinenseiten	Buchung an der Maschine per QR

Die Spalten sind Vorschläge, keine Vorgaben. Was zählt, ist die Skizze, die Sie selbst dazu schreiben.

Abgrenzung zur Diplomarbeit

Wenn Ihr Projekt Ihre Diplomarbeit ist, brauchen Sie in dieser Woche eine schriftliche Abgrenzung in docs/abgrenzung.md, abgestimmt mit der Betreuung.

Dieselbe Leistung wird nicht zweimal gewertet. Der Schnitt lässt sich auf zwei Arten sauber ziehen: nach Bestandteilen (diese Module gehören zur Diplomarbeit, jene zu diesem Gegenstand) oder nach Aspekten (die fachliche Funktionalität ist Diplomarbeit, die CMS-Erweiterung, die Integration, der Betrieb und die Sicherheitsarbeit gehören hierher). Der zweite Schnitt ist meist der klarere und deckt sich besser mit dem Lehrstoff dieses Gegenstands.

Planen Sie außerdem die Termine gegeneinander. Diplomarbeitsabgabe und Präsentationen fallen in dieselben Wochen wie die Kapitel 9 bis 11. Wer das im September einträgt, verliert im April keine Woche.

Zielbild

Funktionale Anforderungen

Nutzergeschichten mit Akzeptanzkriterien, so wie Sie es in SEW machen. Das Verfahren wird hier nicht noch einmal erklärt, sondern angewandt. Wichtig ist nur eines: Akzeptanzkriterien sind prüfbar formuliert, sonst ist am Jahresende strittig, ob etwas fertig ist.

Nichtfunktionale Ziele als Zahlen

Der Abschnitt, der über das halbe Jahr entscheidet. Adjektive kann man nicht prüfen, Zahlen schon, und in den Kapiteln 10 und 11 werden genau diese Zahlen wieder gebraucht.

Ziel	Untauglich	Brauchbar
Antwortzeit	„schnell”	p95 unter 400 ms für die Listenansicht, LCP mobil unter 2,5 s
Verfügbarkeit	„läuft immer”	99 Prozent im Monat, gemessen am Health Check, geplante Wartung ausgenommen
Geräte	„responsiv”	ab 360 Pixel Breite, aktuelle Chrome, Firefox, Safari, iOS ab 17
Datenmenge	„viele Benutzer”	500 Konten, 20.000 Datensätze, 30 gleichzeitige Benutzer
Barrierefreiheit	„barrierefrei”	WCAG 2.2 Stufe AA auf den drei Hauptwegen, geprüft mit Werkzeug und Tastatur
Sprachen	„mehrsprachig”	Oberfläche de-AT und en, Inhalte zweisprachig gepflegt
Wiederherstellung	„wir haben Backups”	Datenverlust höchstens 24 Stunden, Wiederherstellung in höchstens 4 Stunden

Die letzte Zeile hat zwei Fachbegriffe, die Sie ab Kapitel 11 dauernd brauchen: Die zulässige Menge verlorener Daten heißt RPO, die zulässige Ausfalldauer RTO. Beide sind eine Entscheidung und keine technische Eigenschaft. Sie legen sie jetzt fest und bauen später darauf hin.

Muss, Soll, Kann

Drei Körbe, und der erste ist der einzige, der zählt. Das Muss-Set ist der Umfang, der bis Kapitel 12 in Produktion laufen muss. Alles andere ist Zugabe.

Die Faustregel für den Schnitt: Wenn das Muss-Set nicht bis Woche 14 fertig sein kann, ist es zu groß. Streichen Sie jetzt, wo es nichts kostet, und nicht im Mai, wo es die Note kostet.

Vorgehen und Takt

Modell und Rhythmus

Das Vorgehensmodell kommt aus SEW und wird hier nicht durch ein zweites ersetzt. Ein Team, das in SEW in Sprints arbeitet und hier nach Gefühl, führt zwei Projekte statt einem.

Zweiwöchige Iterationen decken sich mit dem Kapitelrhythmus. Dazu eine Definition of Done für dieses Projekt, die für jede Aufgabe gilt:

Code liegt im Hauptzweig, ist durch ein Review gegangen und hat Tests auf der in SEW festgelegten Ebene.
Die Änderung läuft in der Testumgebung, nicht nur lokal.
Die betroffene Dokumentation ist aktualisiert.
Eine getroffene Entscheidung von Gewicht steht in docs/entscheidungen.md.

Der Jahresplan

Er wird rückwärts geplant, vom Abnahmetermin. Der Plan ist keine Prognose, sondern eine Kette von Terminen.

Woche	Thema	Was am Ende steht
1	Projektstart	Thema, Zielbild, zwei Umgebungen
2 bis 3	CMS erweitern	eigene Erweiterung produktiv im Einsatz
4 bis 5	Drittanbieter	fremder Dienst integriert, Ausfall abgefangen
6	Datenschutz	Rechtsgrundlagen, Löschkonzept, Informationspflichten
7	SEO und mobile Auftritte	indexierbar, gemessen
8 bis 9	UI/UX und Designsystem	Designsystem, Bedienbarkeitstest ausgewertet
10 bis 11	Anwendungssicherheit	Bedrohungsmodell, Anmeldung über OIDC
12 bis 14	Desktop und mobil	PWA oder plattformübergreifende App
15 bis 16	Deployment	Pipeline, Produktivinstallation, Rollback
17 bis 18	Logging und Monitoring	Dashboard, funktionierende Alarmierung
19 bis 20	Verfügbarkeit	Health Checks, Notfallplan, Wiederherstellung geübt
21	Projektabschluss	Abnahme, Übergabe, Präsentation
22 bis 24	Matura	Vorbereitung

Zwei Termine ergeben sich daraus zwangsläufig. Ab Woche 15 setzen die Kapitel ein System voraus, das fachlich steht; wer dann noch Funktionen baut, kommt in Verzug. Und Funktionsstopp ist Woche 16, danach gibt es Fehlerbehebung, Betrieb und Dokumentation.

Risiken aufschreiben

Eine Risikoliste zu Jahresbeginn, fünf bis acht Einträge, in docs/risiken.md:

| Risiko | Wahrsch. | Auswirkung | Frühwarnzeichen | Gegenmaßnahme |
|---|---|---|---|---|
| Zahlungsdienst verlangt Gewerbenachweis | mittel | hoch | Konto bleibt im Testmodus | in Woche 2 anlegen, Alternative benennen |
| Kein iOS-Gerät zum Testen | hoch | mittel | erst bei Kapitel 8 sichtbar | Gerät im Team klären, Simulator einplanen |
| Diplomarbeit kollidiert im April | hoch | hoch | Termine überschneiden sich im Kalender | Puffer in Woche 13, Aufgaben vorziehen |
| Server zu klein für Test und Produktion | mittel | mittel | Speicher über 80 Prozent | Bestandsaufnahme Woche 1, Aufrüstung planen |

Diese Liste wird alle zwei Wochen kurz durchgesehen. Ein Risiko, das eingetreten ist, wandert in den Plan; ein Risiko, das weg ist, wird gestrichen.

Umgebungen und Repository

Zwei Umgebungen ab Tag eins

Im Vorjahr gab es eine Umgebung, und jede Änderung ging direkt an die Benutzer. Das ist ab jetzt vorbei.

	Produktion	Test
Adresse	`projekt.example.at`	`test.projekt.example.at`
Daten	echte Daten	erzeugte Testdaten
Geheimnisse	eigene, nur dort	eigene, andere Werte
Fremddienste	Produktivschlüssel	Sandbox oder Testmodus
Zugang	öffentlich	Basisauthentifizierung
Suchmaschinen	indexierbar	`X-Robots-Tag: noindex`
Deployment	bewusst ausgelöst	jederzeit, gern automatisch

Zwei Punkte daran sind keine Formalie. Erstens: Keine Echtdaten in der Testumgebung. Sobald Sie die Produktionsdatenbank kopieren, um „mit realistischen Daten zu testen”, verarbeiten Sie personenbezogene Daten zu einem Zweck, für den Sie keine Grundlage haben. Kapitel 4 wird das im Detail behandeln, die Regel gilt ab heute.

Zweitens: Die Testumgebung darf nicht in den Suchindex. Sonst konkurriert sie mit der Produktion um dieselben Inhalte, und in Kapitel 5 suchen Sie den Fehler.

Bevor Sie zwei Umgebungen auf den Server aus dem Vorjahr legen, sehen Sie nach, was dort noch läuft und was übrig ist:

df -h                 # disk space
free -h               # memory
docker ps -a          # what is running, what is left over
docker system df      # how much space images and volumes take up

Auf 4 GB kommen jetzt Produktion, Test, zwei Datenbanken, das CMS und ab Kapitel 10 ein Monitoring-Stapel. Das wird eng. Entweder Sie räumen die Reste des Vorjahres weg, oder Sie planen eine Aufrüstung ein. Diese Feststellung gehört in die Risikoliste, nicht in den April.

Repository und Dokumentation

Ein Repository, ein Ort für die Dokumentation, von Anfang an angelegt und nicht am Jahresende befüllt:

README.md               Zweck, lokaler Start, Deployment in drei Schritten
docs/
├── architektur.md      Systemskizze, Schnitt, Datenmodell, Schnittstellen
├── betrieb.md          Server, Umgebungen, Domains, Zugänge, Sicherung
├── entscheidungen.md   Entscheidungsprotokolle, fortlaufend
├── sicherheit.md       Bedrohungsmodell, Befunde, Maßnahmen
├── datenschutz.md      Verarbeitungen, Rechtsgrundlagen, Löschfristen
├── risiken.md          Risikoliste
└── abgrenzung.md       nur bei Diplomarbeit

Wer aus der 4. Klasse fortführt, übernimmt sein Entscheidungsprotokoll und schreibt darin weiter. Ein neues Projekt beginnt eines, und der erste Eintrag ist die Themenwahl mitsamt den verworfenen Alternativen.

Häufige Stolperfallen

Thema erst in der dritten Woche festlegen. Der Puffer des Jahres ist damit weg, bevor die erste Zeile geschrieben ist.
Zu groß angelegt. Das Muss-Set ist der Prüfstein, nicht die Vision.
Nichtfunktionale Ziele als Adjektive. „Schnell” und „sicher” lassen sich am Jahresende weder nachweisen noch widerlegen.
Diplomarbeit und Gegenstandsumfang vermischt und die Abgrenzung erst im Mai geschrieben.
Nur eine Umgebung betreiben und alle Experimente in Produktion machen.
Produktionsdaten in die Testumgebung kopieren.
Fremddienst nicht geprüft. Im November stellt sich heraus, dass für den Produktivschlüssel eine Firma nötig gewesen wäre.
Kein mobiler Anwendungsfall im Thema. In Kapitel 8 wird dann drei Wochen lang etwas gebaut, das niemand unterwegs braucht.
Zwei Vorgehensmodelle nebeneinander, eines aus SEW und eines nach Gefühl.
Risikoliste angelegt und nie wieder angesehen.

Lernergebnisse

Erschaffen: ein Projektthema entwickeln, das alle Kompetenzbereiche des Maturajahres abdeckt, und die Abdeckung nachweisen.
Beurteilen: zwischen Fortführung und Neuanfang begründet entscheiden.
Anwenden: funktionale Anforderungen als Nutzergeschichten mit prüfbaren Akzeptanzkriterien formulieren.
Anwenden: nichtfunktionale Ziele als Zahlen festlegen, einschließlich RPO und RTO.
Beurteilen: den eigenen Umfang gegen 21 Wochen abwägen und ein Muss-Set begründen.
Anwenden: einen Jahresplan rückwärts vom Abnahmetermin aufstellen und Risiken schriftlich führen.
Anwenden: getrennte Produktions- und Testumgebungen mit getrennten Daten und Geheimnissen aufsetzen.
Erklären: die eigene Abgrenzung zur Diplomarbeit darstellen und vertreten.

Arbeit am Jahresprojekt

Bis zum Ende der Woche liegt vor:

Projektskizze mit Themenprüfung gegen die Pflichtabdeckung, schriftlich.
Anforderungen mit Muss-, Soll- und Kann-Set.
Nichtfunktionale Ziele in Zahlen, inklusive RPO und RTO.
Jahresplan mit Terminen, rückwärts geplant, mit Funktionsstopp.
Risikoliste mit mindestens fünf Einträgen und Gegenmaßnahmen.
Bei Diplomarbeit: schriftliche Abgrenzung, mit der Betreuung abgestimmt.
Zwei laufende Umgebungen, getrennte Daten, getrennte Geheimnisse, Testumgebung nicht indexierbar.
Repository mit Dokumentationsgerüst und erstem Entscheidungsprotokoll.

Passende Übungen

Aufgabe - Themenprüfung gegen die Pflichtabdeckung
Aufgabe - Nichtfunktionale Ziele in Zahlen
Aufgabe - Jahresplan rückwärts vom Abnahmetermin
Aufgabe - Test- und Produktivumgebung aufsetzen