Textreduktion
This commit is contained in:
@@ -3,7 +3,7 @@
|
||||
|
||||
\subsection{Entwicklungsprozess}
|
||||
|
||||
Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Der dabei verbindliche Softwareprozess ist im internen XWiki dokumentiert und in Abbildung~\ref{fig:unicorn-process} wiedergegeben. Er beschreibt den vollständigen Weg von der Kundenidee bis zur Abrechnung und ordnet jedem Schritt den Zustand zu, den das zugehörige Work Item in Azure DevOps annimmt.
|
||||
Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Der verbindliche Softwareprozess — im internen XWiki dokumentiert und in Abbildung~\ref{fig:unicorn-process} wiedergegeben — beschreibt den Weg von der Kundenidee bis zur Abrechnung und ordnet jedem Schritt den Zustand des Work Items zu.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -12,20 +12,12 @@ Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps.
|
||||
\label{fig:unicorn-process}
|
||||
\end{figure}
|
||||
|
||||
Am Anfang steht eine Idee, die als Product Backlog Item ausformuliert wird (\texttt{New}). Nach Prüfung von Machbarkeit und kaufmännischer Abwicklung geht es in die Freigabe (\texttt{To Approve}); im Approval-Termin prüft das Team die \emph{Definition of Ready} und schätzt den Aufwand (\texttt{Approved}). Mit der Sprintplanung wechselt es auf \texttt{Committed} und wird umgesetzt; nach Übernahme in den Hauptbranch steht es auf \texttt{Dev Completed}. Es folgen Release ins Testsystem, Review und Tests (\texttt{Test Completed}), danach Release ins Produktivsystem, Abnahme und die abschließenden kaufmännischen Schritte bis \texttt{Done}.
|
||||
|
||||
Das Dokumentenfeature wurde ohne Abweichung nach diesem Prozess bearbeitet. Da es sich um eine Erweiterung des eigenen Produkts Houston und nicht um einen Einzelauftrag handelt, entfielen lediglich die auftragsbezogenen Schritte; alle Freigabe-, Test- und Abnahmestufen wurden regulär durchlaufen.
|
||||
|
||||
Die Freigabestufe erwies sich dabei als wirksam: Rückfragen im Approval-Termin — insbesondere durch \emph{Timo Walter} — deckten mehrfach Lücken in den Akzeptanzkriterien auf, etwa zur Häufigkeit der Ordnerstrukturprüfung oder zu Namensbeschränkungen.
|
||||
Das Dokumentenfeature durchlief den Prozess ohne Abweichung; da es eine Erweiterung des eigenen Produkts Houston ist, entfielen nur die auftragsbezogenen Schritte. Die Freigabestufe erwies sich als wirksam — Rückfragen im Approval-Termin, insbesondere durch \emph{Timo Walter}, deckten mehrfach Lücken in den Akzeptanzkriterien auf.
|
||||
|
||||
\subsection{Schnitt der Product Backlog Items}
|
||||
|
||||
Alle Arbeiten hängen als Product Backlog Items am Feature~484. Tabelle~\ref{tab:backlog} im Anhang listet sie mit Kennung, Titel, geschätztem Aufwand, Sprint und Zustand auf; Tabelle~\ref{tab:requirements} ordnet ihnen die Anforderungen aus Abschnitt~\ref{sec:requirements} zu.
|
||||
Alle Arbeiten hängen als Product Backlog Items am Feature~484. Tabelle~\ref{tab:backlog} im Anhang listet sie mit Kennung, Titel, Aufwand, Sprint und Zustand auf; Tabelle~\ref{tab:requirements} ordnet ihnen die Anforderungen aus Abschnitt~\ref{sec:requirements} zu.
|
||||
|
||||
Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 wurden acht Kern-Items angelegt, orientiert an der Feature-Beschreibung: Document Explorer als Basis, die \emph{Feature-Creep}-Punkte (Suche, Einzeldownload, ZIP-Download, PDF-Modal, URL-Dateien) als eigene Items. Am 7.~Juli kam die Typisierung über Icons hinzu, am 8.~Juli die automatische Ordneranlage.
|
||||
Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 wurden acht Kern-Items angelegt (Document Explorer als Basis, die \emph{Feature-Creep}-Punkte Suche, Einzeldownload, ZIP-Download, PDF-Modal und URL-Dateien als eigene Items); am 7.~Juli kam die Typisierung über Icons hinzu, am 8.~Juli die automatische Ordneranlage. Während der Umsetzung folgten am 22.~Juli Paginierung und Typfilter aus der UI-Zuarbeit, am 28.~Juli die Recherche zur S3-Abfrage (Ergebnis am 12.~August im Kundenordner-Lookup-Item) und am 17.~August das Item zu Race Conditions (siehe Abschnitt~\ref{sec:race-conditions}).
|
||||
|
||||
Eine zweite Gruppe entstand während der Umsetzung: Am 22.~Juli ergänzte die UI-Zuarbeit Paginierung und Typfilter. Am 28.~Juli wurde die Recherche zur Optimierung der S3-Abfrage angelegt, deren Ergebnis am 12.~August in das Kundenordner-Lookup-Item mündete. Am 17.~August kam das Item zu Race Conditions hinzu (siehe Abschnitt~\ref{sec:race-conditions}).
|
||||
|
||||
Insgesamt sind es 15 Product Backlog Items und ein Bug. Die geschätzten Aufwände summieren sich auf 46 Story Points: 35 in Sprint~15.2026, 11 in Sprint~16.2026.
|
||||
|
||||
Die vorgeschnittenen Items betreffen ausschließlich fachliche Funktionen; alle nachgeschobenen entstanden aus technischen Problemen bei der Implementierung — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.
|
||||
Insgesamt sind es 15 Product Backlog Items und ein Bug; die Aufwände summieren sich auf 46 Story Points (35 in Sprint~15.2026, 11 in Sprint~16.2026). Alle vorgeschnittenen Items betreffen fachliche Funktionen, alle nachgeschobenen entstanden aus technischen Problemen — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.
|
||||
|
||||
@@ -3,13 +3,13 @@
|
||||
|
||||
Das Feature~484 „Dokumente" existierte seit November 2023 als zweizeilige Bedarfsnotiz. Am 10.~Juni 2026 arbeitete \emph{Thomas Drewermann} es zu einer vollständigen Feature-Beschreibung aus — einschließlich S3, Filestash als Verwaltungswerkzeug, den sieben Dokumententypen sowie den Abschnitten \emph{Feature-Creep} und \emph{Out of Scope}.
|
||||
|
||||
Am 18.~Juni 2026 führte ich die Feature-Analyse durch. Vier Rückfragen wurden als Kommentare gestellt und am selben Tag beantwortet; drei entschieden Architekturfragen:
|
||||
Am 18.~Juni 2026 führte ich die Feature-Analyse durch; vier am selben Tag beantwortete Rückfragen entschieden Architekturfragen:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Autorisierung über Metadaten:} Die Efecte-Organisations-ID wird als Metadatum am Kundenordner gespeichert; die Berechtigung wird darüber aufgelöst (siehe Abschnitt~\ref{sec:authorization}).
|
||||
\item \textbf{Filestash als externes Werkzeug:} Filestash dient unverändert als Verwaltungsoberfläche, \emph{nicht} als Referenz für einen Nachbau in Houston.
|
||||
\item \textbf{Typisierung über Ordner statt Metadaten:} Der Dokumententyp wird über den Unterordner bestimmt, nicht als Metafeld an der Datei.
|
||||
\item \textbf{Bedeutung der URL-Dateien:} Gemeint ist das Einbetten \emph{externer} Ressourcen in den Dokumentenbereich, nicht das Teilen von Houston-Dokumenten nach außen.
|
||||
\item \textbf{Autorisierung über Metadaten:} Die Efecte-Organisations-ID wird als Metadatum am Kundenordner gespeichert und löst die Berechtigung auf (siehe Abschnitt~\ref{sec:authorization}).
|
||||
\item \textbf{Filestash als externes Werkzeug:} Filestash dient als Verwaltungsoberfläche, \emph{nicht} als Vorlage für einen Nachbau in Houston.
|
||||
\item \textbf{Typisierung über Ordner statt Metadaten:} Der Dokumententyp wird über den Unterordner bestimmt.
|
||||
\item \textbf{Bedeutung der URL-Dateien:} Gemeint ist das Einbetten \emph{externer} Ressourcen, nicht das Teilen von Houston-Dokumenten nach außen.
|
||||
\end{enumerate}
|
||||
|
||||
Die dritte Entscheidung erwies sich als die folgenreichste: Die Typabbildung über Ordner macht die Filterung günstig (Präfix-Listing), erzwingt aber die automatische Anlage der Ordnerstruktur und erschwert die typübergreifende Suche.
|
||||
Die dritte Entscheidung war die folgenreichste: Die Typabbildung über Ordner macht die Filterung günstig (Präfix-Listing), erzwingt aber die automatische Ordneranlage und erschwert die typübergreifende Suche.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
\section{Beschaffung der S3-Infrastruktur}
|
||||
\label{sec:infrastructure}
|
||||
|
||||
Der S3-Speicher stand zu Projektbeginn nicht bereit und musste über den Service-Desk beantragt werden. Da Advanced Unibyte ihn betreibt, war ein mehrstufiger Abstimmungsweg nötig. Abbildung~\ref{fig:timeline-infra} zeigt den Verlauf.
|
||||
Der S3-Speicher stand zu Projektbeginn nicht bereit und musste über den Service-Desk beantragt werden. Da Advanced Unibyte ihn betreibt, war ein mehrstufiger Abstimmungsweg nötig; Abbildung~\ref{fig:timeline-infra} zeigt den Verlauf.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -12,14 +12,10 @@ Der S3-Speicher stand zu Projektbeginn nicht bereit und musste über den Service
|
||||
|
||||
\subsection{Bereitstellung der Buckets}
|
||||
|
||||
Am 22.~Juli 2026 stellte ich den Service Request. Er wurde am 23.~Juli \emph{Alexander Wagner} zugewiesen und am 27.~Juli abgeschlossen: drei Buckets (DEV, TEST, PROD) waren angelegt, die Zugangsdaten in Passbolt hinterlegt.
|
||||
|
||||
Da der Document Explorer ohnehin erst am 27.~Juli in die Umsetzung ging, entstand keine Verzögerung.
|
||||
Am 22.~Juli 2026 stellte ich den Service Request; er wurde am 23.~Juli \emph{Alexander Wagner} zugewiesen und am 27.~Juli abgeschlossen — drei Buckets (DEV, TEST, PROD) angelegt, Zugangsdaten in Passbolt hinterlegt. Da der Document Explorer ohnehin erst am 27.~Juli begann, entstand keine Verzögerung.
|
||||
|
||||
\subsection{Freischaltung zusätzlicher Funktionen}
|
||||
|
||||
Im Rahmen der Lookup-Recherche (siehe Abschnitt~\ref{sec:lookup-research}) kamen zwei S3-Funktionen in Betracht: \textbf{S3 Select} (\texttt{SelectObjectContent}), das Objektinhalte serverseitig per SQL-ähnlicher Abfrage filtert \autocite{aws-s3-select, storagegrid-s3-select}, und der \textbf{Search Integration Service} von StorageGRID, der Objektmetadaten in einen Elasticsearch-Index spiegelt \autocite{storagegrid-search-integration}.
|
||||
|
||||
Am 30.~Juli beantragte ich die Freischaltung beider Funktionen. \emph{Lennart Meinert} kontaktierte am 4.~August Advanced Unibyte; am 7.~August wurde S3 Select für alle drei Umgebungen aktiviert. Für den Search Integration Service teilte Advanced Unibyte am 17.~August mit, dass die Funktion derzeit nicht angeboten werde. Da bereits eine Lösung ohne serverseitige Suche umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Request geschlossen.
|
||||
|
||||
Zwischen erstem Antrag und abschließender Klärung lagen vier Wochen — ein Lösungsansatz, der auf einer noch zu beschaffenden Fremdleistung beruht, ist innerhalb eines solchen Projektzeitraums nicht belastbar.
|
||||
Am 30.~Juli beantragte ich beide Funktionen; \emph{Lennart Meinert} kontaktierte am 4.~August Advanced Unibyte, am 7.~August wurde S3 Select für alle drei Umgebungen aktiviert. Den Search Integration Service bot Advanced Unibyte laut Mitteilung vom 17.~August nicht an; da bereits eine Lösung ohne serverseitige Suche umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Request geschlossen. Zwischen Antrag und Klärung lagen vier Wochen — ein Ansatz, der auf einer erst zu beschaffenden Fremdleistung beruht, ist in einem solchen Projektzeitraum nicht belastbar.
|
||||
|
||||
@@ -1,13 +1,9 @@
|
||||
\section{Einarbeitung}
|
||||
\label{sec:onboarding}
|
||||
|
||||
Vor der Implementierung war eine Einarbeitung in die projektrelevanten Technologien erforderlich, insbesondere S3.
|
||||
|
||||
\subsection{S3 als Objektspeicher}
|
||||
|
||||
S3 (\emph{Simple Storage Service}) ist ein Objektspeicher, kein Dateisystem. Objekte werden über einen flachen Schlüsselraum adressiert; was als Ordner erscheint, ist ein Präfix im Objektschlüssel, das per \texttt{Delimiter} hierarchisch interpretiert wird \autocite{aws-listobjectsv2}. Diese Eigenschaft prägt das Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}) und war für mehrere Architekturentscheidungen ausschlaggebend.
|
||||
|
||||
S3 bietet zudem \emph{keine} Suche über benutzerdefinierte Metadaten. Ein Lookup erfordert das Auflisten aller Objekte mit clientseitiger Filterung — das zentrale technische Problem des Projekts (siehe Abschnitt~\ref{sec:lookup-research}).
|
||||
S3 (\emph{Simple Storage Service}) ist ein Objektspeicher, kein Dateisystem: Objekte werden über einen flachen Schlüsselraum adressiert, und was als Ordner erscheint, ist ein per \texttt{Delimiter} hierarchisch interpretiertes Präfix \autocite{aws-listobjectsv2}. Das prägt das Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}). S3 bietet zudem \emph{keine} Suche über benutzerdefinierte Metadaten; ein Lookup erfordert das Auflisten aller Objekte mit clientseitiger Filterung — das zentrale technische Problem des Projekts (siehe Abschnitt~\ref{sec:lookup-research}).
|
||||
|
||||
\subsection{AWS SDK für .NET}
|
||||
|
||||
@@ -15,4 +11,4 @@ Der Zugriff erfolgt über \texttt{IAmazonS3} aus dem AWS SDK für .NET (\texttt{
|
||||
|
||||
\subsection{NetApp StorageGRID}
|
||||
|
||||
Der Speicher wird von Advanced Unibyte auf Basis von NetApp StorageGRID betrieben. StorageGRID ist S3-kompatibel, implementiert die API jedoch nicht vollständig. Dies betraf im Projektverlauf \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} und den \emph{Search Integration Service} \autocite{storagegrid-search-integration} und führte zu den in Abschnitt~\ref{sec:infrastructure} beschriebenen Abstimmungen.
|
||||
Der Speicher wird von Advanced Unibyte auf Basis von NetApp StorageGRID betrieben. StorageGRID ist S3-kompatibel, implementiert die API aber nicht vollständig; dies betraf \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} und den \emph{Search Integration Service} \autocite{storagegrid-search-integration} (siehe Abschnitt~\ref{sec:infrastructure}).
|
||||
|
||||
@@ -8,25 +8,25 @@ Aus Feature-Beschreibung und Analyse ergaben sich die folgenden Anforderungen (Z
|
||||
\begin{itemize}
|
||||
\item \textbf{FA-1 — Dokumentenliste:} Auf \texttt{/documents} werden alle Dokumente der Organisation aufgelistet; leere Typordner erscheinen nicht.
|
||||
\item \textbf{FA-2 — Mandantentrennung:} Ein Benutzer sieht ausschließlich Dokumente seiner Organisation, zugeordnet über die \texttt{efecte-org-id}.
|
||||
\item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei vorhandener Berechtigung sichtbar; Aufruf ohne Berechtigung ergibt 403.
|
||||
\item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument wird mit einem aus dem Unterordner abgeleiteten Icon dargestellt.
|
||||
\item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei Berechtigung sichtbar; Aufruf ohne Berechtigung ergibt 403.
|
||||
\item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument erhält ein aus dem Unterordner abgeleitetes Icon.
|
||||
\item \textbf{FA-5 — Suche:} Serverseitige Titelsuche mit Teiltreffern.
|
||||
\item \textbf{FA-6 — Typfilter:} Filterelemente je Dokumententyp zum Ein- und Ausblenden.
|
||||
\item \textbf{FA-7 — Paginierung:} Seitenweise Darstellung mit benutzerdefinierter Seitengröße, analog zu den übrigen Houston-Seiten.
|
||||
\item \textbf{FA-8 — Einzeldownload:} Download über eine zeitlich begrenzte Pre-Signed URL \autocite{aws-presigned-urls} unter Beibehaltung des Dateinamens.
|
||||
\item \textbf{FA-9 — ZIP-Download:} Ausgewählte Dokumente werden als ZIP-Archiv heruntergeladen; die Ordnerstruktur entspricht der S3-Struktur.
|
||||
\item \textbf{FA-9 — ZIP-Download:} Ausgewählte Dokumente werden als ZIP-Archiv mit S3-analoger Ordnerstruktur heruntergeladen.
|
||||
\item \textbf{FA-10 — PDF-Vorschau:} PDF-Anzeige im Modal ohne vorherigen Download.
|
||||
\item \textbf{FA-11 — Share-Links:} Freigabelink mit OpenGraph-Meta-Tags für Linkvorschau und Weiterleitung auf den Document Explorer.
|
||||
\item \textbf{FA-12 — URL-Dateien:} \texttt{.url}-Dateien werden nach INI-Format ausgewertet und leiten auf die hinterlegte Adresse weiter; fehlt eine gültige URL, wird die Datei normal behandelt.
|
||||
\item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf wird die Typordnerstruktur für die Organisation angelegt, sofern sie fehlt.
|
||||
\item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf wird die Typordnerstruktur der Organisation angelegt, sofern sie fehlt.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Nichtfunktionale Anforderungen}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{NFA-1 — Skalierbarkeit des Lookups:} Die Auflösung des Kundenordners darf nicht linear mit der Kundenanzahl wachsen.
|
||||
\item \textbf{NFA-2 — Fehlerbehandlung:} Bei Ladefehlern wird eine verständliche Meldung angezeigt; eine stillschweigend leere Seite ist unzulässig.
|
||||
\item \textbf{NFA-3 — Leerer Zustand:} Existieren keine Dokumente, wird ein Hinweis angezeigt.
|
||||
\item \textbf{NFA-2 — Fehlerbehandlung:} Bei Ladefehlern wird eine verständliche Meldung angezeigt, keine stillschweigend leere Seite.
|
||||
\item \textbf{NFA-3 — Leerer Zustand:} Ohne Dokumente wird ein Hinweis angezeigt.
|
||||
\item \textbf{NFA-4 — Konsistenz:} Bedienelemente orientieren sich an den übrigen Houston-Seiten.
|
||||
\item \textbf{NFA-5 — Testbarkeit:} Der Kundenordner-Lookup ist durch Unit-Tests mit gemocktem \texttt{IAmazonS3} abgedeckt.
|
||||
\item \textbf{NFA-6 — Pfadsicherheit:} Beim Download wird geprüft, dass der Schlüssel innerhalb des Kundenordners liegt.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
\section{Zeit- und Aufwandsplanung}
|
||||
\label{sec:schedule}
|
||||
|
||||
Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der Projektzeitraum reicht von Ende Mai 2026 bis zur Produktivsetzung Anfang September; die Umsetzung verteilt sich auf die Sprints 15–17.2026. Abbildung~\ref{fig:gantt} zeigt die Zeitplanung.
|
||||
Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der Projektzeitraum reicht von Ende Mai 2026 bis zur Produktivsetzung Anfang September, die Umsetzung verteilt sich auf die Sprints 15–17.2026. Abbildung~\ref{fig:gantt} zeigt die Zeitplanung.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -10,8 +10,6 @@ Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der Projektzeitrau
|
||||
\label{fig:gantt}
|
||||
\end{figure}
|
||||
|
||||
Vier Phasen gliedern die Planung: Die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli) umfasste Themenfindung, Feature-Analyse und Backlog-Schnitt. Die \textbf{Implementierungsphase} begann am 27.~Juli über die Sprints 15 und 16. Parallel lief die \textbf{Qualitätssicherung} (Code-Reviews, Abnahmetest ab 13.~August). Die \textbf{Abschlussphase} in Sprint 17.2026 umfasste die Behebung des Abnahmefehlers, die Benutzerdokumentation, die Produktivsetzung am 3.~September sowie Dokumentation und Präsentation.
|
||||
|
||||
Die Planung hing von der Infrastrukturbereitstellung ab: Der Document Explorer konnte erst nach Verfügbarkeit des S3-Speichers umgesetzt werden. \emph{Stephan Janßen} vermerkte diese Abhängigkeit am 8.~Juli als Voraussetzung am Item.
|
||||
Vier Phasen gliedern die Planung: die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli) mit Themenfindung, Feature-Analyse und Backlog-Schnitt; die \textbf{Implementierungsphase} ab 27.~Juli über die Sprints 15 und 16; die parallele \textbf{Qualitätssicherung} (Code-Reviews, Abnahmetest ab 13.~August); und die \textbf{Abschlussphase} in Sprint 17.2026 mit Fehlerbehebung, Benutzerdokumentation und Produktivsetzung am 3.~September. Die Planung hing von der Infrastrukturbereitstellung ab — der Document Explorer konnte erst nach Verfügbarkeit des S3-Speichers umgesetzt werden; \emph{Stephan Janßen} vermerkte diese Abhängigkeit am 8.~Juli am Item.
|
||||
|
||||
Der Soll-Ist-Vergleich der Zeitplanung findet sich in Abschnitt~\ref{sec:target-comparison}.
|
||||
|
||||
Reference in New Issue
Block a user