chapters: Fliesstext auf 57 reine Textseiten kuerzen

Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden
Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze;
Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle
Abbildungen und Tabellen bleiben unveraendert.

Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451).
Gesamt-PDF: 138 -> 116 Seiten.

chapters/closure/evaluation.tex

@@ -3,34 +3,34 @@
 
 \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.
+Die in Abschnitt~\ref{sec:target-situation} beschriebene Zielsituation ist erreicht: Kunden verfügen über einen zentralen, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die zuvor bestehenden Probleme — fehlende Zentralisierung, kein Self-Service, kein strukturierter Überblick, kein 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.
+Eine seit Ende 2023 im Backlog liegende Bedarfsnotiz wurde innerhalb eines Projektzeitraums zur produktiven Funktion. Entscheidend war die Konkretisierung: Erst die Ausarbeitung im Juni machte 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.
+Sämtliche fachlich geforderten Funktionen sind umgesetzt — über den Kern hinaus auch die nachrangigen 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.
+Der Kern — Auflistung mit Mandantentrennung — war nach vier Tagen zusammengeführt, sodass die Folgearbeiten 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 zentrale technische Herausforderung war nicht in der Zielsetzung enthalten, sondern entstand aus der Kombination von Autorisierung über ein Metadatum, lesbaren Ordnernamen und fehlender Metadatensuche des Speichers.
 
-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.
+Die Lösung erfüllt die Anforderung ohne zweite Datenhaltung und heilt bestehende Abweichungen selbsttätig — tragfähiger als die zunächst naheliegenden Ansätze. Dass sie bei Abgabe noch nicht ausgeliefert war, ist 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{Nebenläufigkeit im verändernden Lookup-Pfad} ist analysiert, dokumentiert und mit Lösungsvorschlägen versehen, aber nicht behoben — bewusst abgegrenzt, da die Wahl der Gegenmaßnahme von einer Rückfrage beim Betreiber abhängt.
 
-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.
+Die \textbf{Optimierung der Dokumentensuche} bleibt offen, da der Suchdienst des Speicherherstellers nicht bereitsteht; die 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.
+Der \textbf{Fehlerbericht zur Einheitlichkeit des Suchfeldes} ist erfasst und eingeplant.
 
 \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.
+Das Projektziel ist erreicht. Der Dokumentenbereich ist in seinen Kernfunktionen produktiv, erfüllt die fachlichen Anforderungen, und die verbleibenden Arbeiten sind klar benannt und im Backlog erfasst.
 
-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.
+Der aussagekräftigste Befund ist die Nebenläufigkeit: Sie wurde durch eigenes Nachprüfen des bereits geschriebenen Codes gefunden — nicht durch Test, Fehlerbericht oder Review. Ein Projekt, das eine solche Schwäche selbst findet und einordnet, steht besser da als eines, in dem sie unentdeckt bliebe.

chapters/closure/outlook.tex

@@ -3,46 +3,42 @@
 
 \subsection{Abschluss der begonnenen Arbeiten}
 
-Die nächstliegenden Schritte ergeben sich unmittelbar aus dem in Abschnitt~\ref{sec:target-comparison} beschriebenen Stand.
+Die nächsten Schritte ergeben sich aus Abschnitt~\ref{sec:target-comparison}.
 
-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.
+Zusammenzuführen ist der Pull Request zur Ordnerverwaltung, womit die automatische Ordneranlage und der Lookup mit konstanter Aufrufzahl wirksam werden. Da die Lösung bestehende Ordner selbsttätig umbenennt, entfällt ein Migrationsschritt.
 
-Zu beheben ist ferner der aus der Abnahme hervorgegangene Fehler zur Einheitlichkeit des Suchfeldes, der für den folgenden Sprint eingeplant ist.
+Zu beheben ist der Abnahmefehler zur Einheitlichkeit des Suchfeldes, eingeplant für den folgenden Sprint.
 
 \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.
+Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist das gewichtigste offene Thema. Das Backlog Item ist freigegeben und mit vier bis sechs Stunden veranschlagt.
 
-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.
+Welche Maßnahme umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt.\autocite{aws-conditional-writes} Steht die Funktion bereit, ist die Absicherung einfach; 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.
+Unabhängig davon ließe sich der verändernde Anteil aus dem Anfragepfad in einen eigenen, einmalig ausgeführten Vorgang lösen; der Lookup könnte dann auf reines Lesen zurückgeführt werden.
 
 \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.
+Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt; ein Folgetermin war vorgeschlagen, aber 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.
+Sollte der Dienst verfügbar werden, ließe sich der Kundenordner-Lookup über eine Metadatenabfrage lösen — die eigene Konstruktion bliebe als Rückfallebene. Zudem könnte die Dokumentensuche serverseitig erfolgen statt anwendungsseitig. Beides sind Optimierungen; die bestehende Umsetzung funktioniert, skaliert aber schlechter.
 
 \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.
+In der Feature-Beschreibung sind zwei Erweiterungen genannt, die nicht in Backlog Items überführt wurden.
 
-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 erste betrifft die \textbf{Einbindung in die Übersichtsseite} — etwa eine Kachel mit zuletzt hinzugefügten Dokumenten oder Sicherheitsbewertungen. Für Letztere wäre ein auswertbares Merkmal pro Dokument nötig, das mit der bestehenden Struktur (Typ über den Ordner) nicht abbildbar ist.
 
-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.
+Die zweite betrifft die \textbf{Bereitstellung von Abrechnungsdaten}. Fachlich ist zu klären, ob diese über den Dokumentenbereich oder eine gesonderte Ansicht erfolgen, da sie sich in Herkunft und Aktualisierungsrhythmus 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.
+Die Entscheidung, die Dokumentenpflege über den externen Dateibrowser abzuwickeln, war für den Projektzeitraum richtig, aber bewusst als Zwischenlösung getroffen. Sollte die Pflege häufiger oder von mehr Personen übernommen werden, wäre eine Verwaltungsoberfläche im Portal zu bewerten — sie könnte die Ordnerstruktur erzwingen statt auf manuelle Einhaltung zu setzen.
 
 \subsection{Übertragbarkeit}
 
-Über den Dokumentenbereich hinaus hat das Projekt zwei Bausteine hervorgebracht, die auch in anderem Zusammenhang verwendbar sind.
+Das Projekt hat zwei wiederverwendbare Bausteine hervorgebracht.
 
-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.
+Der \textbf{Zugriff auf den Objektspeicher} ist als eigener Dienst gekapselt und nicht auf Dokumente zugeschnitten; weitere Anwendungsfälle 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.
+Die \textbf{Muster für Freigabelinks und Vorschaubilder} — Pfadkodierung, eingeschränkte Auslieferung auf einem nicht angemeldeten Endpunkt, Bereitstellung in einem von Kommunikationsanwendungen unterstützten Format — lassen sich für andere teilbare Inhalte wiederverwenden.

chapters/closure/reflection.tex

@@ -3,48 +3,46 @@
 
 \subsection{Externe Abhängigkeiten früher klären}
 
-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.
+Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen 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.
+Der Fehler lag im Zeitpunkt: Die fachliche Klärung war seit dem 18.~Juni abgeschlossen; der Antrag folgte über vier Wochen später. Hätte er unmittelbar nach der Feature-Analyse vorgelegen, wäre die Frage nach den Speicherfunktionen früher beantwortet gewesen — die Lookup-Recherche hätte nicht auf eine letztlich negative Antwort warten müssen.
 
-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.
+Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung. Sie kosten keine 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.
+Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts.
 
-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.
+Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — waren technisch tragfähig, wurden aber verworfen, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. Die gewählte Lösung ergab sich aus der genauen Betrachtung der Randbedingungen.
 
-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.
+Ausschlaggebend war die Unterscheidung zwischen Anforderung und vermuteter Umsetzung: Die interne Pflege verlangte eine \emph{Sortierung nach Kundennamen}, nicht zwingend Ordnernamen, die \emph{ausschließlich} aus dem Kundennamen bestehen. Diese Präzisierung machte die Lösung sichtbar; ohne die Rückfrage bei der internen Fachseite wäre der Lösungsraum 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.
+Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt die Prüfung, ob eine Randbedingung genauer formuliert werden kann als zunächst verstanden.
 
 \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.
+Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, 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.
+Der Pull Request war eingereicht. Die Fehlerbehandlung des Umbenennens war geschrieben worden, um Datenverlust zu verhindern — und genau sie verursacht ihn unter Nebenläufigkeit. Ein selbst eingebautes Sicherheitsnetz prüft man nicht ohne Weiteres erneut.
 
-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.
+Ausschlaggebend war ein Perspektivwechsel: nicht „funktioniert das?", sondern „was passiert, wenn das zweimal gleichzeitig läuft?". Diese Frage ist für jeden verändernden Codepfad einer Anwendung mit mehreren Instanzen zu stellen — sie war beim Schreiben unterblieben, weil der Pfad als seltener Sonderfall galt. Genau diese Einordnung ließ die Prüfung unterbleiben.
 
 \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.
+Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung war Folge einer bewussten, im Rückblick falschen Entscheidung: Vier gleichzeitig eröffnete Pull Requests sollten Wartezeiten auf Reviews vermeiden.
 
-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.
+Der erwartete Vorteil trat nicht ein, weil die Arbeiten aufeinander aufbauten: Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor Abnahme und Produktivsetzung verschob. Die Verkettung der Zielbranches brachte eigene Kosten: Jede Umstellung auf den Hauptbranch setzte Freigaben zurück. Bei abhängigen Aufgaben ist sequenzielles Vorgehen vorzuziehen.
 
 \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.
+Der einzige Abnahmefehler betrifft eine Anforderung aus mehreren Backlog Items: Die Bedienung soll sich an den übrigen Seiten 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.
+Sie wurde nicht verletzt, weil sie übersehen wurde, sondern weil sie sich nicht aus einer Beschreibung ableiten lässt. Eine Schaltfläche zum Leeren des Suchfelds widerspricht keiner Vorgabe — erst der 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.
+Für solche Anforderungen ist ein Abnahmetest durch eine Person, die die Anwendung kennt, unersetzbar — und sollte früher angesetzt werden 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.
+Gegenüber den vorangegangenen Praktika lag der Schwerpunkt auf Entwurfsentscheidungen. Der Anteil für Recherche, Abwägung und Begründung war erheblich — die sechs Lösungsansätze für den Lookup und die Nebenläufigkeitsanalyse erzeugten 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.
+Zugleich bestimmten diese Anteile den Projektverlauf. Die Erfahrung, dass eine sauber begründete Abgrenzung mehr wert ist als eine schnelle, unvollständige Behebung, ist die wesentliche Erkenntnis dieses Projekts.

chapters/closure/target-comparison.tex

@@ -30,24 +30,24 @@ 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.
+Die Analyse- und Planungsphase verlief planmäßig; die Abweichungen treten in der zweiten Projekthälfte auf und haben zwei 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.
+Die Beschaffung des Speichers war nicht als eigener Vorgang eingeplant und wurde erst am 22.~Juli beantragt, obwohl die fachliche Klärung seit dem 18.~Juni abgeschlossen war. Die Bereitstellung dauerte fünf Arbeitstage — der Verlust entstand durch den späten Antrag.
 
-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.
+Unmittelbare Verzögerung entstand nicht, da die Umsetzung erst am 27.~Juli begann. Die Klärung der Speicherfunktionen zog sich jedoch vom 30.~Juli bis zum 17.~August und fiel in die Umsetzungsphase; die Lookup-Recherche war währenddessen blockiert.
 
 \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.
+Von den 14 Backlog Items waren acht zu Beginn geschnitten; sechs kamen während der Umsetzung hinzu — Typfilter, Paginierung, Recherche zur Speicherabfrage, neuer Lookup, automatische Ordneranlage und 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.
+Sie entstanden nicht aus fachlicher Ausweitung, sondern aus technischen Problemen, die erst bei der Implementierung sichtbar wurden. Die Schätzung wuchs von 35 auf 46 Aufwandspunkte — rund ein Drittel Zuwachs.
 
 \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.
+Von 13 funktionalen Anforderungen sind zwölf ausgeliefert. Die dreizehnte — automatische Anlage der Ordnerstruktur — ist implementiert, aber im noch nicht zusammengeführten Pull Request.
 
-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.
+Bei den nichtfunktionalen Anforderungen sind fünf von sechs erfüllt. Die Skalierbarkeit des Lookups ist gelöst, aber nicht ausgeliefert; bis dahin gilt das lineare Verfahren — konzeptionell erfüllt, betrieblich 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.
+Hinzu kommt die Nebenläufigkeit (Abschnitt~\ref{sec:race-conditions}) — keine unerfüllte Anforderung, sondern eine neu erkannte Eigenschaft, als eigenes Backlog Item erfasst und freigegeben.