Textreduktion
This commit is contained in:
@@ -3,32 +3,16 @@
|
||||
|
||||
\subsection{Bewertung gegen die Zielsituation}
|
||||
|
||||
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.
|
||||
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. Eine seit Ende 2023 im Backlog liegende Bedarfsnotiz wurde innerhalb eines Projektzeitraums zur produktiven Funktion; entscheidend war die Konkretisierung im Juni, die aus zwei Stichpunkten eine umsetzbare Anforderung machte.
|
||||
|
||||
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 und technische Ziele}
|
||||
|
||||
\subsection{Fachliche Ziele}
|
||||
|
||||
Sämtliche fachlich geforderten Funktionen sind umgesetzt — über den Kern hinaus auch die nachrangigen Komfortfunktionen: Suche, Einzeldownload, Archivdownload, Vorschau, Freigabelinks und Verknüpfungsdateien.
|
||||
|
||||
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 war nicht in der Zielsetzung enthalten, sondern entstand aus der Kombination von Autorisierung über ein Metadatum, lesbaren Ordnernamen und fehlender Metadatensuche des Speichers.
|
||||
|
||||
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. Seit dem 3.~September ist sie produktiv.
|
||||
Sämtliche fachlich geforderten Funktionen sind umgesetzt, über den Kern hinaus auch die Komfortfunktionen Suche, Einzel- und Archivdownload, Vorschau, Freigabelinks und Verknüpfungsdateien. Der Kern — Auflistung mit Mandantentrennung — war nach vier Tagen zusammengeführt, sodass die Folgearbeiten früh beginnen konnten. 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 gewählte Lösung erfüllt die Anforderung ohne zweite Datenhaltung, heilt bestehende Abweichungen selbsttätig und ist seit dem 3.~September produktiv.
|
||||
|
||||
\subsection{Nicht erreichte Ziele}
|
||||
|
||||
Ein Punkt ist offen geblieben, ein weiterer liegt außerhalb des eigenen Einflusses.
|
||||
|
||||
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, da der Suchdienst des Speicherherstellers nicht bereitsteht; die Auswirkung ist gering, weil die Suche nur mit der Dokumentenzahl eines einzelnen Kunden skaliert.
|
||||
Ein Punkt ist offen geblieben, ein weiterer liegt außerhalb des eigenen Einflusses. 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 Gegenmaßnahme von einer Rückfrage beim Betreiber abhängt (Abschnitt~\ref{sec:race-conditions}). 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.
|
||||
|
||||
\subsection{Gesamtbewertung}
|
||||
|
||||
Das Projektziel ist erreicht. Der Dokumentenbereich ist seit dem 3.~September vollständig produktiv, erfüllt sämtliche funktionalen Anforderungen, und die verbleibende Arbeit ist klar benannt und im Backlog erfasst.
|
||||
|
||||
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.
|
||||
Das Projektziel ist erreicht: Der Dokumentenbereich ist seit dem 3.~September vollständig produktiv, erfüllt sämtliche funktionalen Anforderungen, und die verbleibende Arbeit ist klar benannt und im Backlog erfasst. Dass die Nebenläufigkeit durch eigenes Nachprüfen des Codes gefunden wurde, ist dabei bezeichnend (Abschnitt~\ref{sec:reflection}).
|
||||
|
||||
@@ -3,34 +3,16 @@
|
||||
|
||||
\subsection{Absicherung des verändernden Lookup-Pfads}
|
||||
|
||||
Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist nach der Produktivsetzung das einzige offene Thema des Features. Das Backlog Item ist freigegeben und mit vier bis sechs Stunden veranschlagt.
|
||||
|
||||
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 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.
|
||||
Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist nach der Produktivsetzung das einzige offene Thema des Features; das Backlog Item ist freigegeben und mit vier bis sechs Stunden veranschlagt. Welche Maßnahme umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt\autocite{aws-conditional-writes}; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre. Alternativ ließe sich der verändernde Anteil aus dem Anfragepfad in einen eigenen, einmalig ausgeführten Vorgang lösen, sodass der Lookup auf reines Lesen zurückgeführt würde.
|
||||
|
||||
\subsection{Suchdienst des Speicherherstellers}
|
||||
|
||||
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 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.
|
||||
Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt. Sollte er verfügbar werden, ließe sich der Kundenordner-Lookup über eine Metadatenabfrage lösen — die eigene Konstruktion bliebe als Rückfallebene — und die Dokumentensuche serverseitig ausführen. 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.
|
||||
In der Feature-Beschreibung sind zwei nicht in Backlog Items überführte Erweiterungen genannt: 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 nicht abbildbar ist — und die \textbf{Bereitstellung von Abrechnungsdaten}, bei der zu klären ist, ob sie über den Dokumentenbereich oder eine gesonderte Ansicht erfolgt, da sie sich in Herkunft und Aktualisierungsrhythmus unterscheiden.
|
||||
|
||||
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.
|
||||
\subsection{Bedienung und Übertragbarkeit}
|
||||
|
||||
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 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}
|
||||
|
||||
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 können darauf aufsetzen.
|
||||
|
||||
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.
|
||||
Die Dokumentenpflege über den externen Dateibrowser war für den Projektzeitraum richtig, aber bewusst als Zwischenlösung getroffen; bei häufigerer Pflege wäre eine Verwaltungsoberfläche im Portal zu bewerten, die die Ordnerstruktur erzwingen könnte. Zwei Bausteine sind wiederverwendbar: der als eigener Dienst gekapselte \textbf{Zugriff auf den Objektspeicher} sowie 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.
|
||||
|
||||
@@ -3,46 +3,24 @@
|
||||
|
||||
\subsection{Externe Abhängigkeiten früher klären}
|
||||
|
||||
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 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.
|
||||
|
||||
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.
|
||||
Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen lagen vier Wochen. Der Fehler lag im Zeitpunkt: Die fachliche Klärung war seit dem 18.~Juni abgeschlossen, der Antrag folgte über vier Wochen später; früher gestellt, hätte die Lookup-Recherche nicht auf eine letztlich negative Antwort warten müssen. Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung.
|
||||
|
||||
\subsection{Eine Architekturentscheidung ist die Summe ihrer Randbedingungen}
|
||||
|
||||
Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts.
|
||||
|
||||
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 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.
|
||||
|
||||
Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt die Prüfung, ob eine Randbedingung genauer formuliert werden kann als zunächst verstanden.
|
||||
Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts. Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — wurden verworfen, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. 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. Ohne diese Rückfrage bei der internen Fachseite wäre der Lösungsraum enger geblieben.
|
||||
|
||||
\subsection{Eigene Arbeit gegenlesen}
|
||||
|
||||
Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, fertiggestellten Codes.
|
||||
|
||||
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 „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.
|
||||
Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, fertiggestellten Codes. 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 der Perspektivwechsel von „funktioniert das?" zu „was passiert, wenn das zweimal gleichzeitig läuft?" — eine Frage, die für jeden verändernden Codepfad einer Anwendung mit mehreren Instanzen zu stellen ist.
|
||||
|
||||
\subsection{Pull Requests kleiner und sequenziell schneiden}
|
||||
|
||||
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 aufeinander aufbauten: Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor der Abnahme 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.
|
||||
Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung war Folge einer im Rückblick falschen Entscheidung: Vier gleichzeitig eröffnete Pull Requests sollten Wartezeiten auf Reviews vermeiden. Der Vorteil trat nicht ein, weil die Arbeiten aufeinander aufbauten — statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor der Abnahme verschob; zusätzlich setzte jede Umstellung der verketteten Zielbranches auf den Hauptbranch Freigaben zurück. Bei abhängigen Aufgaben ist sequenzielles Vorgehen vorzuziehen.
|
||||
|
||||
\subsection{Konsistenz braucht einen Vergleich, keine Beschreibung}
|
||||
|
||||
Der einzige Abnahmefehler betrifft eine Anforderung aus mehreren Backlog Items: Die Bedienung soll sich an den übrigen Seiten orientieren.
|
||||
|
||||
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 solche Anforderungen ist ein Abnahmetest durch eine Person, die die Anwendung kennt, unersetzbar — und sollte früher angesetzt werden als hier geschehen.
|
||||
Der einzige Abnahmefehler betrifft die Anforderung, dass sich die Bedienung an den übrigen Seiten orientieren soll. Sie wurde nicht übersehen, sondern lässt sich nicht aus einer Beschreibung ableiten: Eine Schaltfläche zum Leeren des Suchfelds widerspricht keiner Vorgabe, erst der Vergleich mit den bestehenden Seiten macht die Abweichung sichtbar. Für solche Anforderungen ist ein Abnahmetest durch eine mit der Anwendung vertraute Person unersetzbar und sollte früher angesetzt werden als hier geschehen.
|
||||
|
||||
\subsection{Persönliche Einordnung}
|
||||
|
||||
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 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.
|
||||
Gegenüber den vorangegangenen Praktika lag der Schwerpunkt auf Entwurfsentscheidungen: Die sechs Lösungsansätze für den Lookup und die Nebenläufigkeitsanalyse erzeugten keine einzige Zeile ausgelieferten Codes, bestimmten aber 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.
|
||||
|
||||
@@ -31,24 +31,14 @@ Produktivsetzung & --- & 03.09. & --- \\
|
||||
Nebenläufigkeit (10070) & --- & offen & nach Projektzeitraum \\
|
||||
\end{longtable}
|
||||
|
||||
Die Analyse- und Planungsphase verlief planmäßig; die Abweichungen treten in der zweiten Projekthälfte auf und haben zwei Ursachen.
|
||||
Die Analyse- und Planungsphase verlief planmäßig; die Abweichungen der zweiten Projekthälfte haben zwei Ursachen.
|
||||
|
||||
\subsection{Ursache 1: Nicht eingeplanter Infrastrukturvorlauf}
|
||||
\subsection{Ursachen der Abweichungen}
|
||||
|
||||
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.
|
||||
\textbf{Nicht eingeplanter Infrastrukturvorlauf.} 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 Klärung der Speicherfunktionen zog sich vom 30.~Juli bis zum 17.~August und blockierte währenddessen die Lookup-Recherche (Abschnitt~\ref{sec:reflection}).
|
||||
|
||||
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}
|
||||
|
||||
Von den 15 Backlog Items waren acht zu Beginn geschnitten; sieben kamen während der Umsetzung hinzu — Typfilter, Paginierung, Recherche zur Speicherabfrage, neuer Lookup, automatische Ordneranlage, Nebenläufigkeit und Benutzerhandbuch.
|
||||
|
||||
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.
|
||||
\textbf{Nachgeschobene Backlog Items.} Von den 15 Backlog Items waren acht zu Beginn geschnitten; sieben kamen während der Umsetzung hinzu — Typfilter, Paginierung, Recherche zur Speicherabfrage, neuer Lookup, automatische Ordneranlage, Nebenläufigkeit und Benutzerhandbuch. 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.
|
||||
|
||||
\subsection{Abgleich mit den Anforderungen}
|
||||
|
||||
Alle 13 funktionalen Anforderungen sind ausgeliefert, einschließlich der automatischen Anlage der Ordnerstruktur.
|
||||
|
||||
Bei den nichtfunktionalen Anforderungen sind fünf von sechs erfüllt. Nicht erfüllt ist allein die Zusicherung gegen gleichzeitige verändernde Zugriffe.
|
||||
|
||||
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.
|
||||
Alle 13 funktionalen Anforderungen sind ausgeliefert, einschließlich der automatischen Anlage der Ordnerstruktur. Bei den nichtfunktionalen Anforderungen sind fünf von sechs erfüllt; nicht erfüllt ist allein die Zusicherung gegen gleichzeitige verändernde Zugriffe. Diese Nebenläufigkeit (Abschnitt~\ref{sec:race-conditions}) ist keine unerfüllte Anforderung, sondern eine neu erkannte Eigenschaft, als eigenes Backlog Item erfasst und freigegeben.
|
||||
|
||||
Reference in New Issue
Block a user