bump versino

appendix/interview-jochen.tex

@@ -1,4 +1,84 @@
 \chapter{Stakeholder-Interview}
 \label{app:stakeholder-interview}
 
-\textbf{!!!TODO TODO TODO ADD APPENDIX INTERVIEW!!!}
+\textbf{Anforderungserfassung 1Password-Berechtigungsverwaltung}\\
+\textbf{und -Schnittstelle} \\
+\textbf{16.10.2024 und 23.10.2024, Bad Dürkheim} \\
+\textbf{Teilnehmer: Leon Etienne, Jochen Stange} \\
+
+\textbf{Frage:} Was sind die Aufgabenbereiche von externen Entwickler*innen?
+\begin{quote}
+Externe steigen z.B. für die Umsetzung großer Projekte ein und arbeiten in diesem Umfang mit uns in agilen Entwicklungsprozessen wie z.B. Scrum.
+Je nach dem Projekt braucht man da schon einige Zugänge.
+Es kommt aber auch vor, dass Entwickler wie \emph{<Name geschwärzt>} selbstständig Projekte umsetzen, gegebenfalls auch kleine Projekte.
+Die brauchen dann eigentlich nur den Backend-Login. Den können wir auch auch mailen.
+Es war aber auch schon im Diskurs TYPO3-Upgrades outzusourcen. Das ist sowieso undankbare Arbeit und wir wären froh, das aus den Füßen zu haben.
+Da müssten wir schon einige Zugänge übermitteln.
+\end{quote}
+
+\textbf{Frage:} Und wieso lagern wir solche Upgrades nicht schon aus?
+\begin{quote}
+Naja die dafür zuständigen Dienstleister brauchen dafür unser Docker-Ansible. Das können wir aber nicht rausgeben, das ist ja voll mit Email und Datenbankzugängen.
+Wir sind ja schon lange dran das zu fixen, nur wir kommen wir nie so wirklich dazu.
+\end{quote}
+
+
+\textbf{Frage:} Könntest du dir vorstellen, diese Zugänge in unseren Passwortmanager auszulagern? Damit könnten wir die Berechtigungsverwaltung an 1Password abgeben.
+\begin{quote}
+Sicher, wenn Ansible dann noch drankommt, klingt das gangbar. Wie funktioniert die Berechtigungsverwaltung da überhaupt?
+\clearpage
+\emph{<Es wird gemeinsam durch die administrative 1Password-Oberfläche gestöbert>}
+\\
+\\
+Mh. Ich finde nur Berechtigungen, um Vaults freizugeben, nicht aber für einzelne Einträge.
+Wir haben doch eigentlich durch unseren relativ teuren Tarif Zugang zu Live-Support.
+Ich stelle nachher mal eine Support-Anfrage. Die sollen mir erklären, wie das geht. Muss ja gehen.
+\\
+\\
+\emph{<Das Interview wird bis nach dem Support-Zoom-Call mit 1Password pausiert>}
+\\
+\\
+Leon, das glaubst du nicht. Das geht wirklich nicht. Man kann nur ganze Vaults freigeben.
+Man kann noch nicht mal Verknüpfungen auf einzelne Einträge in diesen erstellen. Wenn wir jetzt \emph{<Name geschwärzt>} Zugang auf 2 oder 3 Einträge geben wollten, müssten wir die von Hand kopieren und ab dann
+doppelt Pflegen. Das ist ja unglaublich.
+\end{quote}
+
+\textbf{Frage:} Ich verstehe. Und wenn wir je Projekt einen Vault erstellen würden?
+\begin{quote}
+    Dann müssten wir ja den ganzen Passwortmanager umbauen. Außerdem haben wir über 200 Projekte. Mit so vielen Vaults würde sich
+    niemand mehr zurecht finden. Lass das mal lieber sein.
+\end{quote}
+
+\textbf{Frage:} Ich lasse mir etwas einfallen. Klingt, als müssten wir etwas eigenes bauen. Wäre es OK, wenn wir Zugänge in YAML definieren?
+\begin{quote}
+Solange es mit etwas technischem Know-How nicht zu aufwändig zu pflegen ist, gerne.
+Ich will aber nicht, dass wir nachher für jedes Projekt 20 Einträge einzeln jedem Entwickler zuweisen müssen. Das muss projektbasiert gehen.
+Trotzdem muss es aber funktionieren, dass wir projektunabhängige Einträge so zuweisen können. Für interne Werkzeuge z.B.
+\end{quote}
+
+\textbf{Frage:} Vlt. könnten wir Wildcards verwenden, um die Eintragstitel zu durchsuchen? Die sind bei uns ja sehr einheitlich.
+\begin{quote}
+Klingt pragmatisch. Da kann man dann notfalls auch komplette Eintragstitel reinschreiben, oder?
+Die Einträge, auf die so eine Wildcard passt, werden dann der Entwicklerin zugewiesen.
+\end{quote}
+
+\textbf{Frage:} Ja, das würde gehen. Vlt wären aber 1Password-IDs eindeutiger. Das wäre auch kein nennenswerter Mehraufwand
+\begin{quote}
+Ok, dann nimm das noch mit dazu. Aber nicht anstatt.
+Äh und noch was. Das ist ja nicht nur für Ansible. Wie würden damit ja auch Accountzugänge verteilen. Wie sollen die Entwickler das dann einsehen? Über das Terminal wäre das sehr unhandlich.
+\end{quote}
+
+\textbf{Frage:} Wenn wir Entwicklern eigene Vaults geben würden, in die Einträge hinenkopiert werden, könnten sie die Einträge in der 1P App einsehen.
+\begin{quote}
+Klingt gut. Aber müssen wir die dann nicht doch wieder doppelt pflegen?
+\end{quote}
+
+\textbf{Frage:} Nein, ich würde einen Mechanismus bauen, der sich darum kümmert, diese Vaults aktuell zu halten. Wenn überhaupt müssen wir einen Sync-Prozess anstoßen. Passt das?
+\begin{quote}
+Wenn du das so hinkriegst, wäre das gut. Zwar nicht ideal, aber 1P scheint ja nicht mehr herzugeben.
+\end{quote}
+
+\textbf{Frage:} Super. Wenn du sonst keine Fragen oder Anregungen mehr hast, würde ich gleich damit loslegen :)
+\begin{quote}
+Im Moment nicht. Ich melde mich wenn doch.
+\end{quote}

chapters/anforderungen.tex

@@ -7,7 +7,7 @@
 \section{Anforderungserfassung}
 Obwohl bereits vor Beginn des Projektes einige Anforderungen bekannt sind,
 müssen manche Details nachträglich in Erfahrung gebracht werden.
-Hierfür wurde ein semistrukturiertes Interview mit dem Stakeholder durchgeführt.
+Hierfür wurde ein informales Interview mit dem Stakeholder durchgeführt.
 Im Rahmen dieses Interviews wurden vorbereitete Fragen gestellt, dem Stakeholder aber auch die Möglichkeit
 gegeben frei heraus zu sprechen und Wünsche zu äußern.
 Notizen zu diesem Interview befinden sich im Anhang unter
@@ -17,6 +17,7 @@ Notizen zu diesem Interview befinden sich im Anhang unter
 Das Ergenis der Anforderungserfassung ist ein Lastenheft, das in constraints, funktionale und
 nicht-funktioniale Anforderungen unterteilt ist. Im Zuge des Interviews und diversen anderen, informalen Gespräche,
 hat sich der Autor ein tiefes Verständnis für das vorliegende Problem des Auftraggebers anggeignet.
+Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt.
 
 \begin{table}[ht]
     \centering

config.tex

@@ -10,10 +10,10 @@
 \newcommand{\cfgDocClassification}{Projektbericht}
 
 % Document version
-\newcommand{\cfgDocVersion}{1.0}
+\newcommand{\cfgDocVersion}{1.1}
 
 % Last modification date
-\newcommand{\cfgDateLastModification}{21. Februar 2025}
+\newcommand{\cfgDateLastModification}{14. Februar 2025}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%