chap 7: Projektabschluss — Soll-Ist, Zielerreichung, Reflexion, Ausblick

2026-08-25 20:50:47 +02:00
parent 8b43abca8a
commit cd3a3e5246
4 changed files with 175 additions and 7 deletions
@@ -1,4 +1,36 @@
 \section{Zielerreichung}
 \label{sec:evaluation}
-% TODO
+\subsection{Bewertung gegen die Zielsituation}
 Die in Abschnitt~\ref{sec:target-situation} beschriebene Zielsituation ist erreicht. Kunden verfügen im Kundenportal über einen zentralen, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die zuvor bestehenden Probleme — fehlende Zentralisierung, kein Self-Service, kein strukturierter Überblick, kein technisch abgesicherter mandantengetrennter Zugriff — sind adressiert.
 Bemerkenswert ist dabei weniger die Menge der umgesetzten Funktionen als der Umstand, dass eine seit Ende 2023 im Backlog liegende Bedarfsnotiz innerhalb eines einzigen Projektzeitraums zu einer produktiv genutzten Funktion wurde. Der entscheidende Schritt war dabei nicht die Implementierung, sondern die Konkretisierung: Erst die Ausarbeitung des Features im Juni und die anschließende Analyse machten aus zwei Stichpunkten eine umsetzbare Anforderung.
 \subsection{Fachliche Ziele}
 Sämtliche fachlich geforderten Funktionen sind umgesetzt. Der Dokumentenbereich bietet über den ursprünglich als Kern definierten Umfang hinaus auch die im Abschnitt \emph{Feature-Creep} der Feature-Beschreibung genannten Komfortfunktionen — Suche, Einzeldownload, Archivdownload, Vorschau, Freigabelinks und Verknüpfungsdateien.
 Dass diese vollständig umgesetzt wurden, war zu Projektbeginn nicht selbstverständlich: Sie waren ausdrücklich als nachrangig eingestuft. Möglich wurde es, weil der Kern — die Auflistung mit Mandantentrennung — bereits nach vier Tagen zusammengeführt war und die darauf aufbauenden Arbeiten dadurch früh beginnen konnten.
 \subsection{Technische Ziele}
 Die zentrale technische Herausforderung des Projekts war nicht in der ursprünglichen Zielsetzung enthalten. Sie entstand aus der Kombination zweier Entscheidungen — Autorisierung über ein Metadatum und lesbare Ordnernamen für die interne Pflege — und der Eigenschaft des Speichers, keine Suche über Metadaten anzubieten.
 Die gefundene Lösung erfüllt die Anforderung, ohne eine zweite Datenhaltung einzuführen, und heilt bestehende Abweichungen selbsttätig. Sie ist damit fachlich wie technisch die tragfähigere Variante gegenüber den zunächst naheliegenden Ansätzen. Dass sie zum Abgabezeitpunkt noch nicht ausgeliefert war, schmälert die konzeptionelle Leistung nicht, ist für die Bewertung des Projektstands aber festzuhalten.
 \subsection{Nicht erreichte Ziele}
 Drei Punkte sind offen geblieben.
 Die \textbf{Nebenläufigkeit im verändernden Teil des Lookups} ist analysiert, dokumentiert und mit Lösungsvorschlägen versehen, aber nicht behoben. Dies ist eine bewusste, abgestimmte Abgrenzung und keine Nachlässigkeit — die Wahl der Gegenmaßnahme hängt von einer Rückfrage beim Betreiber ab, deren Bearbeitungsdauer zuvor mit mehreren Wochen bemessen worden war.
 Die \textbf{Optimierung der Dokumentensuche} bleibt offen. Sie wäre über den Suchdienst des Speicherherstellers lösbar gewesen, der jedoch nicht zur Verfügung steht. Die praktische Auswirkung ist gering, weil die Suche nur mit der Dokumentenzahl eines einzelnen Kunden skaliert.
 Der \textbf{aus der Abnahme hervorgegangene Fehler} zur Einheitlichkeit des Suchfeldes ist erfasst und eingeplant, aber nicht behoben.
 \subsection{Gesamtbewertung}
 Das Projektziel ist erreicht. Der Dokumentenbereich ist in seinen Kernfunktionen produktiv, erfüllt die fachlichen Anforderungen und ist in einem Zustand, in dem die verbleibenden Arbeiten klar benannt, priorisiert und im Backlog erfasst sind.
 Der aussagekräftigste Einzelbefund des Projekts ist dabei nicht eine umgesetzte Funktion, sondern die Erkenntnis über die Nebenläufigkeit. Sie wurde durch eigenes Nachprüfen des bereits geschriebenen Codes gefunden — nicht durch einen Fehlerbericht, nicht durch einen Test und nicht durch ein Review. Ein Projekt, das eine solche Schwäche selbst findet, benennt und einordnet, steht qualitativ besser da als eines, in dem sie unentdeckt bliebe.
@@ -1,6 +1,48 @@
 \section{Ausblick}
 \label{sec:outlook}
-% TODO: PBI 10070 (Race Conditions), Search Integration (von AU noch nicht verfügbar),
+\subsection{Abschluss der begonnenen Arbeiten}
-% Dashboard-Kacheln (Security Assessments, zuletzt hinzugefügte Dokumente),
+
-% Abrechnungsdaten
+Die nächstliegenden Schritte ergeben sich unmittelbar aus dem in Abschnitt~\ref{sec:target-comparison} beschriebenen Stand.
 Zusammenzuführen ist der Pull Request zur Ordnerverwaltung. Damit werden zugleich die automatische Anlage der Ordnerstruktur und der Lookup mit konstanter Aufrufzahl wirksam. Da die Lösung bestehende Ordner selbsttätig auf den kanonischen Namen umbenennt, ist kein gesonderter Migrationsschritt erforderlich — der Bestand wird durch den laufenden Betrieb überführt.
 Zu beheben ist ferner der aus der Abnahme hervorgegangene Fehler zur Einheitlichkeit des Suchfeldes, der für den folgenden Sprint eingeplant ist.
 \subsection{Absicherung des verändernden Lookup-Pfads}
 Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist das inhaltlich gewichtigste offene Thema. Der zugehörige Backlog Item ist freigegeben und mit einem Zeitrahmen von vier bis sechs Stunden versehen.
 Welche der vorgeschlagenen Maßnahmen umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt.\autocite{aws-conditional-writes} Diese Frage ist Teil derselben Rückfrage beim Betreiber, die auch den Suchdienst betrifft. Steht die Funktion zur Verfügung, ist die Absicherung mit geringem Aufwand möglich; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre.
 Unabhängig von dieser Entscheidung ist zu erwägen, den verändernden Anteil aus dem Anfragepfad herauszulösen. Ein eigener Vorgang, der die Ordnerbestände abgleicht, hätte den Vorteil, dass er einmalig und ohne Nebenläufigkeit ausgeführt wird. Der Lookup könnte dann auf reines Lesen zurückgeführt werden — die Selbstheilung entfiele, würde aber auch nicht mehr benötigt.
 \subsection{Suchdienst des Speicherherstellers}
 Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt. Die Anfrage wurde an dessen Produktverantwortliche weitergegeben; ein Folgetermin war zum Ende des Projektzeitraums vorgeschlagen, aber noch nicht durchgeführt.
 Sollte der Dienst künftig verfügbar sein, eröffnet er zwei Möglichkeiten. Zum einen ließe sich der Kundenordner-Lookup unmittelbar über eine Abfrage auf das Metadatum lösen — die aufwendigere eigene Konstruktion würde damit entbehrlich, wäre aber weiterhin funktionsfähig und könnte als Rückfallebene bestehen bleiben. Zum anderen ließe sich die Dokumentensuche serverseitig ausführen, statt wie bisher sämtliche Schlüssel eines Kunden zu laden und anwendungsseitig zu filtern.
 Beide Verbesserungen sind Optimierungen, keine Fehlerbehebungen. Die bestehende Umsetzung funktioniert; sie skaliert lediglich schlechter, als sie es mit dem Dienst täte.
 \subsection{Fachliche Erweiterungen}
 In der Feature-Beschreibung sind zwei Erweiterungen genannt, die nicht in Backlog Items überführt wurden und damit für einen späteren Zeitpunkt offenstehen.
 Die erste betrifft die \textbf{Einbindung in die Übersichtsseite} des Kundenportals. Denkbar sind eine Kachel mit den zuletzt hinzugefügten Dokumenten sowie eine gesonderte Darstellung von Sicherheitsbewertungen. Für Letztere wäre allerdings zusätzliche Information nötig: Um etwa den Zeitpunkt der letzten Bewertung anzuzeigen, müssten die entsprechenden Dokumente ein auswertbares Merkmal tragen. Das ist mit der bestehenden Struktur, die den Typ ausschließlich über den Ordner ausdrückt, nicht abbildbar und würde ein Metadatum pro Dokument erfordern.
 Die zweite betrifft die \textbf{Bereitstellung von Abrechnungsdaten}. Hier ist zunächst fachlich zu klären, ob diese über den Dokumentenbereich oder über eine gesonderte Ansicht bereitgestellt werden sollen, da sie sich in Herkunft und Aktualisierungsrhythmus deutlich von den übrigen Dokumenttypen unterscheiden.
 \subsection{Bedienung durch die interne Fachseite}
 Die Entscheidung, die Dokumentenpflege über den bestehenden externen Dateibrowser abzuwickeln und keine eigene Verwaltungsoberfläche zu bauen, war für den Projektzeitraum richtig: Sie sparte erheblichen Aufwand und ermöglichte die Konzentration auf die Kundensicht.
 Sie ist jedoch bewusst als Zwischenlösung getroffen worden. Sollte sich im Betrieb zeigen, dass die Pflege häufiger erfolgt oder von einem größeren Personenkreis übernommen wird als angenommen, wäre eine Verwaltungsoberfläche innerhalb des Kundenportals neu zu bewerten. Sie hätte zudem den Vorteil, die Ordnerstruktur nicht mehr manuell einhalten zu müssen — die Zuordnung von Kunde und Typ könnte dann durch die Anwendung erzwungen werden, statt sich auf die richtige Ablage durch die pflegende Person zu verlassen.
 \subsection{Übertragbarkeit}
 Über den Dokumentenbereich hinaus hat das Projekt zwei Bausteine hervorgebracht, die auch in anderem Zusammenhang verwendbar sind.
 Der \textbf{Zugriff auf den Objektspeicher} ist als eigener Dienst gekapselt und nicht auf Dokumente zugeschnitten. Weitere Anwendungsfälle, die größere Dateien außerhalb der Datenbank ablegen müssen, können darauf aufsetzen.
 Die \textbf{Muster für Freigabelinks und Vorschaubilder} — die Kodierung des relativen Pfades, die bewusst eingeschränkte Auslieferung von Vorschaubildern auf einem nicht angemeldeten Endpunkt und die Bereitstellung in einem von Kommunikationsanwendungen unterstützten Bildformat — sind ebenfalls unabhängig vom Dokumentenbereich und lassen sich für andere teilbare Inhalte des Kundenportals wiederverwenden.
@@ -1,5 +1,50 @@
 \section{Reflexion}
 \label{sec:reflection}
-% TODO: Lessons Learned — S3-Lookup-Entscheidung, Race Conditions als offenes Thema,
+\subsection{Externe Abhängigkeiten früher klären}
-% Infrastruktur-Vorlauf unterschätzt (AU-Kommunikation 2026-07-22 bis 2026-08-07)
+
 Die deutlichste Lehre betrifft den Umgang mit Abhängigkeiten außerhalb des eigenen Einflussbereichs. Zwischen dem Antrag auf den Speicher und der abschließenden Auskunft über die verfügbaren Funktionen lagen vier Wochen — bei einem Projektzeitraum von wenigen Wochen ein erheblicher Anteil.
 Der Fehler lag nicht in der Bearbeitungsdauer, die für einen Vorgang über einen externen Betreiber nicht ungewöhnlich ist, sondern im Zeitpunkt der Anfrage. Die fachliche Klärung war seit dem 18.~Juni abgeschlossen; dass ein Speicher benötigt wird, stand damit fest. Der Antrag folgte erst über vier Wochen später. Hätte er unmittelbar nach der Feature-Analyse vorgelegen, wäre auch die Frage nach den verfügbaren Funktionen früher beantwortet gewesen — und die Recherche zum Lookup hätte nicht auf eine Antwort warten müssen, die schließlich negativ ausfiel.
 Die Lehre daraus ist allgemeiner Natur: Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung, unabhängig davon, wann ihr Ergebnis benötigt wird. Sie kosten in der Regel keine eigene Arbeitszeit, aber Wartezeit — und Wartezeit lässt sich nur durch frühes Beginnen verkürzen.
 \subsection{Eine Architekturentscheidung ist die Summe ihrer Randbedingungen}
 Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts. Aufschlussreich ist weniger die Lösung als der Weg dorthin.
 Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — waren alle technisch tragfähig und hätten das Problem messbar entschärft. Verworfen wurden sie, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. Die schließlich gewählte Lösung ist nicht die naheliegendste; sie ergab sich erst aus der genauen Betrachtung der eigentlichen Randbedingung.
 Ausschlaggebend war die Unterscheidung zwischen der Anforderung und ihrer vermuteten Umsetzung: Die interne Pflege verlangte eine \emph{Sortierung nach Kundennamen}, nicht zwingend Ordnernamen, die \emph{ausschließlich} aus dem Kundennamen bestehen. Erst diese Präzisierung machte die Lösung sichtbar. Ohne die Rückfrage bei der internen Fachseite wäre die Anforderung als „Ordnername = Kundenname" verstanden und der Lösungsraum entsprechend enger geblieben.
 Die Erkenntnis: Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt sich die Prüfung, ob eine der Randbedingungen genauer formuliert werden kann, als sie zunächst verstanden wurde.
 \subsection{Eigene Arbeit gegenlesen}
 Die Nebenläufigkeitsproblematik wurde nicht durch einen Test, ein Review oder einen Fehlerbericht gefunden, sondern durch das erneute Durchgehen des eigenen, bereits fertiggestellten Codes.
 Das ist insofern bemerkenswert, als der betreffende Pull Request zu diesem Zeitpunkt geschrieben und eingereicht war. Die Fehlerbehandlung des Umbenennens war ausdrücklich geschrieben worden, um Datenverlust zu verhindern — und genau sie verursacht ihn unter Nebenläufigkeit. Ein Sicherheitsnetz, das man selbst eingebaut hat, prüft man nicht ohne Weiteres erneut; die Annahme, dass es wirkt, ist die eigene.
 Ausschlaggebend war ein Perspektivwechsel: nicht zu fragen „funktioniert das?", sondern „was passiert, wenn das hier zweimal gleichzeitig läuft?". Diese Frage ist an einer Anwendung, die in mehreren Instanzen betrieben wird, für jeden verändernden Codepfad zu stellen — und sie war beim Schreiben des Codes nicht gestellt worden, weil der Pfad als seltener Sonderfall galt. Genau diese Einordnung als Sonderfall ist es, die die Prüfung unterbleiben lässt.
 \subsection{Pull Requests kleiner und sequenziell schneiden}
 Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung der Zusammenführungen war die Folge einer bewussten, im Rückblick aber falschen Entscheidung. Vier gleichzeitig eröffnete Pull Requests sollten verhindern, dass Arbeitszeit mit Warten auf Reviews vergeht.
 Der erwartete Vorteil trat nicht ein, weil die Arbeiten inhaltlich aufeinander aufbauten. Ein Reviewer konnte den zweiten Pull Request nicht sinnvoll abschließen, solange der erste offen war. Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor Abnahme und Produktivsetzung verschob.
 Die Verkettung der Zielbranches, die das Reviewproblem löste, brachte zudem eigene Kosten mit sich: Jede Umstellung auf den Hauptbranch setzte abgegebene Freigaben zurück. Für künftige Arbeiten wäre der Schluss, bei inhaltlich abhängigen Aufgaben sequenziell vorzugehen und Parallelität nur dort zu suchen, wo tatsächliche Unabhängigkeit besteht.
 \subsection{Konsistenz braucht einen Vergleich, keine Beschreibung}
 Der einzige aus der Abnahme hervorgegangene Fehler betrifft eine Anforderung, die in mehreren Backlog Items sinngemäß enthalten war: Die Bedienung soll sich an den übrigen Seiten der Anwendung orientieren.
 Diese Anforderung wurde nicht verletzt, weil sie übersehen worden wäre, sondern weil sie sich nicht vollständig aus einer Beschreibung ableiten lässt. Eine Schaltfläche zum Leeren des Suchfelds ist eine sinnvolle Ergänzung — sie widerspricht keiner Vorgabe. Erst der unmittelbare Vergleich mit den bestehenden Seiten macht die Abweichung sichtbar.
 Für Anforderungen dieser Art ist ein Abnahmetest durch eine Person, die die übrige Anwendung kennt, nicht durch vorgelagerte Prüfstufen ersetzbar. Das ist zugleich ein Argument dafür, solche Tests früher anzusetzen als hier geschehen.
 \subsection{Persönliche Einordnung}
 Gegenüber den vorangegangenen Praktika lag der Schwerpunkt dieses Projekts deutlicher auf Entwurfsentscheidungen als auf der Implementierung. Der Anteil der Zeit, der auf Recherche, Abwägung und Begründung entfiel, war erheblich — die Bewertung von sechs Lösungsansätzen für den Lookup und die Analyse der Nebenläufigkeit erzeugten für sich genommen keine einzige Zeile ausgelieferten Codes.
 Zugleich waren es genau diese Anteile, die den Verlauf des Projekts bestimmten. Die Erfahrung, dass eine sauber begründete und dokumentierte Abgrenzung — etwa die eines erkannten Problems in ein eigenes Backlog Item — fachlich mehr wert ist als eine schnelle, unvollständige Behebung, ist die wesentliche persönliche Erkenntnis aus diesem Projekt.
@@ -1,4 +1,53 @@
 \section{Soll-Ist-Vergleich}
 \label{sec:target-comparison}
-% TODO: Tabelle Soll-Ist (Zeitplan, Features)
+\subsection{Zeitlicher Verlauf}
 Tabelle~\ref{tab:soll-ist} stellt die geplanten den tatsächlichen Zeitpunkten gegenüber.
 \begin{longtable}{@{} p{45mm} l l p{40mm} @{}}
 \caption{Soll-Ist-Vergleich der Projektphasen}
 \label{tab:soll-ist} \\
 \toprule
 \textbf{Phase} & \textbf{Soll} & \textbf{Ist} & \textbf{Abweichung} \\
 \midrule
 \endfirsthead
 \toprule
 \textbf{Phase} & \textbf{Soll} & \textbf{Ist} & \textbf{Abweichung} \\
 \midrule
 \endhead
 \bottomrule
 \endfoot
 Feature-Analyse            & 18.06. & 18.06. & keine \\
 Backlog-Schnitt            & 18.06.--08.07. & 18.06.--08.07. & keine \\
 Infrastruktur beantragt    & --- & 22.07. & nicht eingeplant \\
 Infrastruktur verfügbar    & --- & 27.07. & nicht eingeplant \\
 Umsetzung Sprint 15.2026   & 27.07.--12.08. & 27.07.--19.08. & +1 Woche \\
 Umsetzung Sprint 16.2026   & 13.08.--25.08. & 12.08.--offen & Lookup nicht gemergt \\
 Abnahmetest                & ab 13.08. & 13.08.--25.08. & Zugriffsprobleme \\
 Produktivsetzung Kern      & --- & 20.08. & --- \\
 Nebenläufigkeit (10070)    & --- & offen & nach Projektzeitraum \\
 Bugfix aus Abnahme (10134) & --- & Sprint 17.2026 & nach Projektzeitraum \\
 \end{longtable}
 Die Analyse- und Planungsphase verlief planmäßig. Die Abweichungen treten ausschließlich in der zweiten Projekthälfte auf und haben zwei klar benennbare Ursachen.
 \subsection{Ursache 1: Nicht eingeplanter Infrastrukturvorlauf}
 Die Beschaffung des Speichers war in der ursprünglichen Planung nicht als eigener Vorgang enthalten. Sie wurde erst am 22.~Juli beantragt, obwohl die fachliche Klärung bereits seit dem 18.~Juni abgeschlossen war. Die eigentliche Bereitstellung dauerte dann mit fünf Arbeitstagen nicht ungewöhnlich lange — der Verlust entstand dadurch, dass der Antrag erst spät gestellt wurde.
 Unmittelbare Verzögerung entstand daraus nicht, weil die Umsetzung ohnehin erst am 27.~Juli begann. Anders verhielt es sich mit der Klärung, welche Speicherfunktionen zur Verfügung stehen: Diese zog sich vom 30.~Juli bis zum 17.~August, also über zweieinhalb Wochen, und fiel damit mitten in die Umsetzungsphase. Die Recherche zum Kundenordner-Lookup war während dieser Zeit blockiert, soweit sie von der Antwort abhing.
 \subsection{Ursache 2: Nachgeschobene Backlog Items}
 Die zweite Abweichung ergibt sich aus dem Umfang. Von den 14 Backlog Items waren acht zu Beginn geschnitten; sechs kamen erst während der Umsetzung hinzu — Typfilter, Paginierung, die Recherche zur Speicherabfrage, der neue Lookup, die automatische Ordneranlage und die Nebenläufigkeit.
 Diese Items entstanden nicht aus einer Ausweitung des fachlichen Umfangs. Sie entstanden aus technischen Problemen, die erst bei der Implementierung sichtbar wurden, sowie aus der Zuarbeit des Entwurfs im Juli. Die ursprüngliche Schätzung von 35 Aufwandspunkten wuchs damit auf 46 Punkte — ein Zuwachs von rund einem Drittel.
 \subsection{Abgleich mit den Anforderungen}
 Von den 13 funktionalen Anforderungen sind zwölf ausgeliefert und im Betrieb. Die dreizehnte — die automatische Anlage der Ordnerstruktur — ist implementiert, aber Bestandteil des noch nicht zusammengeführten Pull Requests.
 Bei den nichtfunktionalen Anforderungen ist das Bild ähnlich. Fünf der sechs sind erfüllt. Die Skalierbarkeit des Lookups ist gelöst, die Lösung aber ebenfalls noch nicht ausgeliefert; bis dahin gilt weiterhin das lineare Verfahren. Die Anforderung ist damit konzeptionell und implementatorisch erfüllt, betrieblich jedoch noch nicht wirksam.
 Hinzu kommt eine Einschränkung, die zu Projektbeginn nicht bekannt war: die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit im verändernden Teil des Lookups. Sie ist keine unerfüllte Anforderung, sondern eine im Zuge der Umsetzung neu erkannte Eigenschaft, die als eigenes Backlog Item erfasst und freigegeben ist.