Compare commits
3
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 0qln
|
e547d3bb18 | ||
|
0qln
|
dd733dc58f | ||
|
0qln
|
a23949bf4c |
@@ -37,7 +37,7 @@ Inhalte aus Notizen sind Primärquelle — keine Projektfakten, Namen oder Daten
|
||||
|
||||
## Formale Anforderungen (PidI 3)
|
||||
|
||||
- 10 ECTS, **24 Manntage / 192 Arbeitsstunden** (doppelt so viel wie PidI 1/2)
|
||||
- 10 ECTS, **24 Manntage / 192 Arbeitsstunden** (doppelt so viel wie PidI 1/2) (In diesem Projekt: etwa 26.07.2026 bis 21.08.2026 für die Implementierung)
|
||||
- **mindestens 40 Seiten** Kerninhalt (Verzeichnisse zählen nicht mit)
|
||||
- Die `\confirmationpage` in `pidi-thesis.cls` nennt in PidI 2 noch „12 Manntage" —
|
||||
für PidI 3 auf 24 anpassen. Ebenso `\course` (Default `Praktikum in der Industrie (PidI 1)`).
|
||||
|
||||
@@ -1 +1,8 @@
|
||||
% TODO: Kapitel aus PidI 2 übernehmen und auf PidI 3 aktualisieren
|
||||
\section{Einordnung in die IT-Landschaft}
|
||||
\label{sec:comp-econ-loc}
|
||||
|
||||
WorkSimple positioniert sich als Full-Service-IT-Dienstleister, der Unternehmen jeder Größe unterstützt. Die Lösungen sind darauf ausgerichtet, die Komplexität der IT zu reduzieren und gleichzeitig die Effizienz und Sicherheit zu erhöhen. Durch die Nutzung moderner Technologien und agiler Methoden ist WorkSimple in der Lage, schnell und flexibel auf die Anforderungen der Kunden einzugehen.
|
||||
|
||||
Die intern genutzten Tools wie Kimai (Zeiterfassung) und Efecte (ITSM) sind Beispiele für die praktische Anwendung von IT-Lösungen, die auch Kunden angeboten werden. Dies unterstreicht den praxisnahen Ansatz von WorkSimple. Das Kundenportal Houston, dessen Erweiterung Gegenstand dieses Projekts ist, verbindet diese Systeme gegenüber dem Kunden zu einer einheitlichen Oberfläche — das genaue Zusammenspiel der Kernsysteme wird in Abschnitt~\ref{sec:system-landscape} erläutert.
|
||||
|
||||
Interne Prozesse und Dokumentation werden im \emph{XWiki} gepflegt, während die Softwareentwicklung nach einem strukturierten DevOps-Prozess mit Azure DevOps erfolgt. Dieser ganzheitliche Ansatz ermöglicht es WorkSimple, sowohl interne als auch kundenseitige IT-Herausforderungen effektiv zu lösen.
|
||||
|
||||
@@ -1 +1,11 @@
|
||||
% TODO: Kapitel aus PidI 2 übernehmen und auf PidI 3 aktualisieren
|
||||
\section{Produkte und Dienstleistungen}
|
||||
\label{sec:comp-products-and-services}
|
||||
|
||||
WorkSimple bietet eine breite Palette von IT-Dienstleistungen an, darunter:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{IT-Beratung und Strategieentwicklung:} Gemeinsame Entwicklung von IT-Strategien, die auf die individuellen Bedürfnisse der Kunden zugeschnitten sind.
|
||||
\item \textbf{Projektmanagement:} Umfassendes Management von IT-Projekten, von der Planung bis zur Implementierung.
|
||||
\item \textbf{Softwareentwicklung:} Entwicklung maßgeschneiderter Softwarelösungen durch die Abteilung „Unicorn Development".
|
||||
\item \textbf{Infrastrukturlösungen:} Bereitstellung und Modernisierung von IT-Infrastrukturen, einschließlich IAAS-Lösungen.
|
||||
\end{itemize}
|
||||
|
||||
@@ -1 +1,10 @@
|
||||
% TODO: Kapitel aus PidI 2 übernehmen und auf PidI 3 aktualisieren
|
||||
\section{WorkSimple}
|
||||
\label{sec:comp-worksimple}
|
||||
|
||||
Die \textbf{WorkSimple GmbH} ist ein IT-Dienstleister, der im Jahr 2019 mit der Mission gegründet wurde, „das wachsende IT-Chaos in der Galaxie zu entwirren und gleichzeitig Unternehmen zukunftsfähige, innovative IT-Lösungen an die Hand zu geben". Das Unternehmen begann mit der Entwicklung von \emph{MIRCO}, einem Mini-Remote-Computer für Kleinunternehmen, und hat sich kontinuierlich weiterentwickelt. Heute bietet WorkSimple vielfältige Lösungen an, darunter umfassende IAAS-Modernisierungen für Hersteller von Energie-Steuersystemen und IT-Projektmanagement für Großunternehmen mit über 14.000 IT-Arbeitsplätzen.
|
||||
|
||||
Mit fast 50 Mitarbeitern, die sich als „IT-Helden" verstehen, geht WorkSimple mit maximaler Energie gegen das herrschende IT-Chaos vor. Die Dienstleistungen und Projekte werden kontinuierlich weiterentwickelt und präzise auf die Bedürfnisse der Kunden abgestimmt, um maßgeschneiderte und zukunftssichere Lösungen zu bieten.
|
||||
|
||||
WorkSimple versteht sich als Partner für Unternehmen, die sich auf den Weg in die digitale Zukunft machen. Die Metapher des „Kolonieschiffs WorkSimple" verdeutlicht diese Rolle: Gemeinsam mit Technik-Schmieden, Datenwächtern und Sicherheitsagenten weist WorkSimple den Weg in ein neues IT-Kapitel und sichert den Fortbestand der Unternehmen von morgen.
|
||||
|
||||
Innovation bedeutet für WorkSimple mehr als nur neue Produkte: Das Handwerk liegt darin, IT-Architekturen, Dienste, Anwendungen und bestehende Betriebsmodelle im Detail zu verstehen. Auf dieser Basis entwickelt WorkSimple gemeinsam mit dem Kunden eine IT-Strategie und plant die notwendigen Schritte zur Transformation.
|
||||
|
||||
@@ -1,5 +1,18 @@
|
||||
\section{Ausgangssituation}
|
||||
\label{sec:initial-situation}
|
||||
|
||||
% TODO: Feature 484 lag 2,5 Jahre im Backlog (Nicole Kimmel, 2023-11-02).
|
||||
% Bisher kein zentraler Dokumentenzugang für Kunden.
|
||||
\section{Ausgangssituation}
|
||||
\label{sec:initial-situation}
|
||||
|
||||
Die Idee, Kunden über Houston Zugang zu ihren Dokumenten zu ermöglichen, besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an — „Vertrag, Betriebshandbuch, Feinkonzepte an zentraler Stelle abgelegt" und „Rechnungen einsehbar". Diese Notiz blieb über zweieinhalb Jahre nahezu unverändert im Backlog und spiegelt die damaligen Bedürfnisse wider, ohne einen konkreten Lösungsansatz zu beschreiben.
|
||||
|
||||
Zum Zeitpunkt des Projektbeginns im Sommer 2026 gab es keinen strukturierten Prozess, über den Kunden selbstständig auf ihre Dokumente zugreifen konnten. Verträge, Berichte und ähnliche Unterlagen wurden punktuell per E‑Mail oder über Dateiablagen bereitgestellt. Daraus ergaben sich mehrere Probleme:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E‑Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
|
||||
\item \textbf{Kein Self-Service für Kunden:} Kunden mussten Dokumente aktiv anfordern, anstatt sie eigenständig abrufen zu können.
|
||||
\item \textbf{Kein strukturierter Überblick:} Eine Übersicht nach Dokumententypen oder zeitlichem Verlauf war nicht vorhanden.
|
||||
\item \textbf{Kein sicherer, mandantengetrennter Zugriff:} Es existierte kein technischer Mechanismus, der sicherstellte, dass ein Kunde ausschließlich seine eigenen Dokumente einsehen konnte.
|
||||
\end{itemize}
|
||||
|
||||
Auf technischer Seite war kein geeigneter S3-Speicher provisioniert und die Houston-Anwendung kannte keine Verbindung zu einem externen Objektspeicher. Die Bereitstellung der notwendigen Infrastruktur — drei S3-Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Laufe des Projekts beantragt und eingerichtet werden.
|
||||
|
||||
@@ -1,4 +1,39 @@
|
||||
\section{Beteiligte und Rollen}
|
||||
\label{sec:participants}
|
||||
|
||||
% TODO: Tabelle aus note-1787657238720 (Beteiligte)
|
||||
\section{Projektbeteiligte}
|
||||
\label{sec:participants}
|
||||
|
||||
Das Projekt wurde durch eine strukturierte Zusammenarbeit verschiedener Beteiligter mit klar definierten Rollen umgesetzt.
|
||||
|
||||
In meiner Rolle als \textbf{Praktikant und Entwickler} (\emph{Linus Nagel}) war ich für die gesamte technische Umsetzung verantwortlich: Anforderungsklärung, Konzeption, Implementierung aller Product Backlog Items, das Verfassen der Akzeptanzkriterien und die Erstellung dieser Dokumentation.
|
||||
|
||||
Die \textbf{betriebliche Betreuung} übernahm \emph{Sarah Hinzmann}. Sie koordinierte die Abstimmungen, begleitete das Projekt von der Themenvergabe bis zur Abgabe und war an Code-Reviews der Abschlussphase beteiligt.
|
||||
|
||||
Als \textbf{Product Owner und fachlicher Ansprechpartner} fungierte \emph{Thomas Drewermann}. Er arbeitete das Feature~484 im Juni 2026 vollständig aus, definierte den Umfang, beantwortete Rückfragen während der Feature-Analyse und begleitete den Projektverlauf fachlich.
|
||||
|
||||
Die \textbf{technische Qualitätssicherung} übernahm das Entwicklerteam der Unicorn Development: \emph{Timo Walter} führte die Code-Reviews der frühen Pull Requests durch und stellte Rückfragen zu Architekturentscheidungen; \emph{Robin Noack} übernahm die Reviews in der Schlussphase. \emph{Hanna Ebner} erarbeitete das UI-Konzept und den Clickdummy. Das gesamte Team war an der Aufwandsschätzung der Product Backlog Items beteiligt.
|
||||
|
||||
Die \textbf{Abnahmetests} wurden durch \emph{Maria-Lena Andersz} durchgeführt.
|
||||
|
||||
Weitere Beteiligte in unterstützenden Rollen: \emph{Stephan Janßen} (Schätzung und Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung), \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\begin{tabularx}{\textwidth}{@{} l X @{}}
|
||||
\toprule
|
||||
\textbf{Person} & \textbf{Rolle} \\
|
||||
\midrule
|
||||
Linus Nagel & Entwicklung, Anforderungsklärung, alle PBIs \\
|
||||
Thomas Drewermann & Product Owner, fachliche Ausarbeitung Feature 484 \\
|
||||
Sarah Hinzmann & Betriebliche Betreuung, PR-Reviews \\
|
||||
Timo Walter & Code-Review (PRs 2154–2164), technische Rückfragen \\
|
||||
Robin Noack & Code-Review (PRs 2180–2196) \\
|
||||
Hanna Ebner & UX/UI, Clickdummy \\
|
||||
Maria-Lena Andersz & Abnahmetest \\
|
||||
Stephan Janßen & Schätzung, Refinement \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\caption{Projektbeteiligte und ihre Rollen}
|
||||
\label{tab:participants}
|
||||
\end{table}
|
||||
|
||||
@@ -1,4 +1,13 @@
|
||||
\section{Projektbeschreibung}
|
||||
\label{sec:project-description}
|
||||
|
||||
% TODO
|
||||
\section{Projektbeschreibung}
|
||||
\label{sec:project-description}
|
||||
|
||||
Das Projekt \emph{Houston Dokumente} hat zum Ziel, Kunden im Kundenportal Houston einen zentralen Bereich bereitzustellen, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente werden in einem S3-Speichersystem abgelegt und gepflegt; den Kunden werden sie über eine neue Houston-Seite zugänglich gemacht.
|
||||
|
||||
Bisher existierte kein einheitlicher, zentraler Zugangspunkt für kundenbezogene Dokumente wie Verträge, Berichte oder Protokolle. Diese wurden punktuell per E‑Mail oder Dateiablage bereitgestellt und waren für Kunden nicht selbstständig abrufbar. Die neue Dokumentenseite in Houston löst diese Situation ab: Mitarbeiter pflegen die Dokumente über ein internes Dateiverwaltungswerkzeug direkt im S3-Speicher, Kunden können sie anschließend strukturiert abrufen.
|
||||
|
||||
Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen — und gliedert die Anzeige anhand dieser Typen. Darüber hinaus umfasst das Projekt eine Suchfunktion, Filter nach Dokumententyp, Paginierung, einen PDF-Viewer, den Download einzelner Dateien sowie das Herunterladen mehrerer Dokumente als ZIP-Archiv. Zusätzlich werden sogenannte URL-Dateien unterstützt, mit denen beliebige Webadressen — etwa Links zu Teams-Kanälen oder SharePoint-Seiten — in der Dokumentenliste verknüpft werden können.
|
||||
|
||||
Das Projekt umfasst die vollständige Integration des Dokumentenbereichs in die bestehende Houston-Webanwendung. Dazu zählen die Anbindung an den S3-Speicher über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Anlage der Ordnerstruktur für neue Kunden beim ersten Seitenaufruf. Nicht Bestandteil des Projekts sind Schreibzugriffe durch Kunden sowie die Anlage oder Bearbeitung von Dokumenten durch den Kunden selbst; dies bleibt Aufgabe der internen Mitarbeiter über das Dateiverwaltungswerkzeug.
|
||||
|
||||
@@ -1,7 +1,14 @@
|
||||
\section{Projektabgrenzung}
|
||||
\label{sec:project-scope}
|
||||
|
||||
% TODO: Out of Scope aus Feature 484:
|
||||
% - Kunde kann Dokumente nicht bearbeiten
|
||||
% - Keine neuen Ordner intern wild anlegen
|
||||
% - Filestash ist externes Admin-UI (kein Houston-Eigenbau)
|
||||
\section{Projektabgrenzung}
|
||||
\label{sec:project-scope}
|
||||
|
||||
Folgende Punkte sind explizit \emph{nicht} Bestandteil des Projekts:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente ausschließlich einsehen und herunterladen. Das Hochladen, Bearbeiten oder Löschen von Dokumenten durch den Kunden ist nicht vorgesehen.
|
||||
\item \textbf{Kein internes Upload-UI in Houston:} Das Hochladen und Verwalten von Dokumenten durch WorkSimple-Mitarbeiter erfolgt ausschließlich über Filestash, einen externen S3-Browser. Eine eigene Upload-Oberfläche in Houston wurde nicht entwickelt.
|
||||
\item \textbf{Keine freie Ordnerstruktur intern:} Interne Mitarbeiter können über Filestash keine beliebigen Ordner anlegen, die dem Kunden angezeigt werden. Nur die sieben definierten Typordner sind für Kunden sichtbar; weitere Ordner werden ignoriert.
|
||||
\item \textbf{Keine Dashboard-Kacheln im PidI-Umfang:} Geplante Erweiterungen wie Dashboard-Kacheln für Tenant-Härtung aus Security-Assessment-Metadaten oder eine Anzeige zuletzt hinzugefügter Dokumente sind als Feature-Creep im Backlog erfasst, aber nicht Teil des PidI-Projekts.
|
||||
\end{itemize}
|
||||
|
||||
@@ -1,12 +1,24 @@
|
||||
\section{Systemlandschaft}
|
||||
\label{sec:system-landscape}
|
||||
|
||||
% TODO: Houston (ASP.NET Core, Razor Pages) — Efecte — Microsoft Entra ID — S3/StorageGRID — Filestash
|
||||
\section{Systemlandschaft}
|
||||
\label{sec:system-landscape}
|
||||
|
||||
% Diagramm:
|
||||
% \begin{figure}[H]
|
||||
% \centering
|
||||
% \includegraphics[width=0.9\textwidth]{figures/diagrams/system-context.pdf}
|
||||
% \caption{Systemkontext}
|
||||
% \label{fig:system-context}
|
||||
% \end{figure}
|
||||
Der Dokumentenbereich ist in die bestehende Systemlandschaft von WorkSimple eingebettet. Abbildung~\ref{fig:system-context} zeigt den Systemkontext und das Zusammenspiel der beteiligten Systeme.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.9\textwidth]{figures/diagrams/system-context.pdf}
|
||||
\caption{Systemkontext Houston Dokumente}
|
||||
\label{fig:system-context}
|
||||
\end{figure}
|
||||
|
||||
\textbf{Houston} ist das Kundenportal von WorkSimple. Es ist als ASP.NET-Core-Webanwendung mit Razor Pages implementiert und aggregiert Informationen aus mehreren internen Systemen zu einer einheitlichen Oberfläche für Kunden. Im Rahmen dieses Projekts wurde Houston um den Dokumentenbereich erweitert.
|
||||
|
||||
\textbf{Efecte} ist das unternehmenseigene ITSM-Tool (IT Service Management). Es dient als zentrale Datenbasis für Kundeninformationen, darunter die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}), die im Rahmen des Projekts als Autorisierungsmerkmal für den Zugriff auf den richtigen S3-Kundenordner verwendet wird.
|
||||
|
||||
\textbf{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt die Authentifizierung und Autorisierung der Benutzer. Nach erfolgreicher Anmeldung erhält Houston ein Token, das unter anderem die Efecte-Organisations-ID und die zugewiesenen Anwendungsrollen des Benutzers enthält. Die neu eingeführte Rolle \texttt{Documents.Read} steuert den Zugriff auf den Dokumentenbereich.
|
||||
|
||||
\textbf{S3-Speicher (NetApp StorageGRID)} ist die Ablage für alle Kundendokumente. Er wird von Advanced Unibyte betrieben und ist S3-kompatibel. Houston greift über das AWS SDK für .NET auf den Speicher zu. Jeder Kunde erhält einen eigenen Ordner im Bucket, der über ein S3-Objekt-Metadatum (\texttt{efecte-org-id}) identifiziert wird.
|
||||
|
||||
\textbf{Filestash} ist ein webbasierter S3-Browser, der intern von WorkSimple-Mitarbeitern genutzt wird, um Dokumente in den S3-Speicher hochzuladen und zu verwalten. Filestash ist eine externe Anwendung und kein Bestandteil der Houston-Entwicklung.
|
||||
|
||||
@@ -1,4 +1,23 @@
|
||||
\section{Zielsituation}
|
||||
\label{sec:target-situation}
|
||||
|
||||
% TODO: Feature 484 Rev 38 — Dokumentenbereich in Houston, 7 Dokumententypen, S3-Ablage, Filestash als Admin-UI
|
||||
\section{Zielsituation}
|
||||
\label{sec:target-situation}
|
||||
|
||||
Mit der Fertigstellung des Dokumentenbereichs erhalten Kunden im Kundenportal Houston erstmals einen strukturierten, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die Zielsituation zeichnet sich durch eine zentrale Ablage im S3-Speicher und eine mandantengetrennte Darstellung in Houston aus.
|
||||
|
||||
Der Dokumentenbereich bietet folgende zentrale Funktionen:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Document Explorer:} Auf der Seite \texttt{/documents} werden alle Dokumente des Kunden als Liste dargestellt, gegliedert nach sieben fachlich definierten Dokumententypen (Service-Protokoll, Abnahme-Dokumente, SLA-Reports Ticketbearbeitung, Monitoring Reports, Security Assessments, Abrechnungsdaten, Vertragsunterlagen). Leere Ordner werden nicht angezeigt.
|
||||
\item \textbf{Typfilter und Suche:} Dokumente können nach Typ gefiltert und titelbasiert serverseitig durchsucht werden.
|
||||
\item \textbf{Paginierung:} Große Dokumentenmengen werden seitenweise dargestellt.
|
||||
\item \textbf{Downloads:} Einzelne Dokumente lassen sich direkt herunterladen; mehrere Dokumente können als ZIP-Archiv gebündelt heruntergeladen werden.
|
||||
\item \textbf{PDF-Vorschau:} PDF-Dokumente können in einem modalen Viewer direkt im Browser angezeigt werden.
|
||||
\item \textbf{Share-Link-Previews:} Für einzelne Dokumente können zeitlich begrenzte Freigabelinks erzeugt werden.
|
||||
\item \textbf{URL-Dateien:} Spezielle \texttt{.url}-Dateien ermöglichen die Verlinkung beliebiger Webadressen — z.\,B. Teams-Kanäle oder SharePoint-Seiten — in der Dokumentenliste.
|
||||
\item \textbf{Mandantentrennung:} Jeder Kunde sieht ausschließlich die Dokumente in seinem eigenen S3-Ordner, der über die \texttt{efecte-org-id} aus dem Authentifizierungstoken identifiziert wird.
|
||||
\item \textbf{Automatische Ordneranlage:} Beim ersten Aufruf der Dokumentenseite wird die vollständige Ordnerstruktur für den Kunden im S3 angelegt, sofern sie noch nicht existiert.
|
||||
\end{itemize}
|
||||
|
||||
Die Pflege der Dokumente erfolgt weiterhin durch WorkSimple-Mitarbeiter über Filestash, den internen S3-Browser. Kunden haben ausschließlich lesenden Zugriff.
|
||||
|
||||
Binary file not shown.
Reference in New Issue
Block a user