flo v1

Praxisbericht.tex

@@ -104,25 +104,10 @@
 
 Die Praxisphase ist ein Zeitraum innerhalb des Studiums, um eine Brücke zwischen dem theoretischen Unterricht und der praktischen Umsetzung in der Realität zu bilden. Planmäßig findet diese im sechsten Semester in den ersten 12 Wochen statt. Meine Praxisphase begann am 01.04 bei der psb intralogistics GmbH in Pirmasens, und dauert bis zum 30.06.
 
-Innerhalb diesem Zeitraum wird mir Einblick in die Unternehmensstrutkur, deren Softwareschöpfungsprozess und eine eigene Projektarbeit gewährt. Auch werden extracurriculare Inhalte und Soft Skills vermittelt. Somit wird fachliche, sowie persönliche Entwicklung gefördert.
+Innerhalb diesem Zeitraum wurden mir Einblicke in die Unternehmensstrutkur, deren Softwareschöpfungsprozess und eine eigene Projektarbeit gewährt. Auch werden extracurriculare Inhalte und Soft Skills vermittelt. Somit wird fachliche, sowie persönliche Entwicklung gefördert.
 
 Der Praxisbericht ist eines der resultierenden Elemente, in welchem das Unternehmen, der Arbeitsplatz, dessen Stellung, durchgeführte Aufgaben, gewonnene Erkenntnise und die unterliegende theoretische Basis dokumentiert, evaluiert und bewertet wird. 
 
-\vfill
-\begin{minipage}[c]{0.49\textwidth}
-	\begin{center}
-		\noindent\rule{6cm}{0.3pt}\\
-		Unterschrift Student
-	\end{center}
-\end{minipage}
-\hfill
-\begin{minipage}[c]{0.49\textwidth}
-	\begin{center}
-		\noindent\rule{6cm}{0.3pt}\\
-		Unterschrift Unternehmen
-	\end{center}
-\end{minipage}
-\vspace{1cm}
 
 \newpage
 
@@ -138,36 +123,40 @@ psb ist ein familiengeführtes Unternehmen, aktuell in der 4. Generation durch W
 
 Lösungen sind auf jeden Kunden maßgeschneidert und verbinden Lagerung, Transport, Kommissionierung, Sortierung und Software zu einem einheitlichen Komplettsystem.
 
-Je nach Größe der zu lagernden Elemente und des gewünschten Systems bietet psb vorgefertige Baukastensysteme, die individuell zugeschnitten werden. Als klassische Regalbediengeräte existieren der sprinter, gedacht für leichte Kartons, Kleinbehälter und Tablare, der runloader, gedacht für Kassetten oder Hängeware bis 300 kg Zuladung und der maxloader, gedacht für Paletten bis 1250 kg. Aber auch Shuttlesysteme wie der vario.sprinter, Paletten-Shuttles oder Mischsysteme wie Hängewaren-Shuttles werden zum Lagern angeboten.
+Je nach Größe der zu lagernden Elemente und des gewünschten Systems bietet psb vorgefertige Baukastensysteme, die individuell zugeschnitten werden. Als klassische Regalbediengeräte werden der \textit{sprinter}, gedacht für leichte Kartons, Kleinbehälter und Tablare, der \textit{runloader}, gedacht für Kassetten oder Hängeware bis 300 kg Zuladung und der \textit{maxloader}, gedacht für Paletten bis 1250 kg Zuladung, angeboten. Aber auch Shuttlesysteme wie der \textit{vario.sprinter}, Paletten-Shuttles oder Mischsysteme wie Hängewaren-Shuttles werden zum Lagern angeboten.
+
 Der Transport wird durch Rollbahnen, Mehrstrangförderern und einer breiten Auswahl an Verbindungsstücken realisiert.
-Automatische Kommisionerung wird von autopick, einem KI-geführten, mit Vakuumsaugern ausgestatteten Roboterarm übernommen. Manuelle Kommisionerung erfolgt auftragsgerecht sequenziert durch rotapick-Systeme, im Gleichteilüberfluss durch Multi-Order-Stationen, Auftragsbasiert in 1-zu-1-Kommissionierung oder Flächendeckend mit Durchlaufregalen.\\
+Automatische Kommisionerung wird von \textit{autopick}, einem KI-geführten, mit Vakuumsaugern ausgestatteten Roboterarm übernommen. Manuelle Kommisionerung erfolgt auftragsgerecht sequenziert durch \textit{rotapick}-Systeme, im Gleichteilüberfluss durch Multi-Order-Stationen, Auftragsbasiert in 1-zu-1-Kommissionierung oder Flächendeckend mit Durchlaufregalen.\\
-Die Orchestration der zuvor genannten Systeme und Module erfolgt durch eine in-house entwickelte Software-Suite mit dem Namen selektron, bestehend aus Warehouse Management System (WMS), Materialflusssteuerung (MFC), Anlagensteuerung (FLC), Visualisierung (SCADA), Produktionssteuerung und Anbindung an bestehende Kundensysteme, z.B. Enterprise Resource Planning (ERP), Produktionsplanung (PPS), Inventurverwaltung (WWS). Diese Suite wird mit einem 24/365 Service abgerundet, welcher durch Fernwartung schnelle Störungsbeseitung ermöglicht.
+Die Orchestration der zuvor genannten Systeme und Module erfolgt durch eine in-house entwickelte Software-Suite mit dem Namen \textit{selektron}, bestehend aus Warehouse Management System (WMS), Materialflusssteuerung (MFC), Anlagensteuerung (FLC), Visualisierung (SCADA), Produktionssteuerung und Anbindung an bestehende Kundensysteme, z.B. Enterprise Resource Planning (ERP), Produktionsplanung (PPS), Inventurverwaltung (WWS). Diese Suite wird mit einem 24/365 Service abgerundet, welcher durch Fernwartung schnelle Störungsbeseitung ermöglicht.
 
 Im globalen Intralogistik-Markt hebt sich psb gegenüber anderen Anbietern mit dem hohen Manufakturgrad, und maximaler vertikaler Intergration und persöhnlicher Kundebetreuung ab.
 
 \section{Arbeitsplatz}
 
-Der Firmenbereich besteht aus einem Verwaltungsgebäude und zwei Fabrikhallen. Ein weiteres Gebäude, das Zentrallager, befindet sich aktuell im Bau. Das dreistöckige Verwaltungsgebäude besitzt im Erdgeschoss den Kundenempfang, Human Resources, SPS-Entwicklung, Entwurf des Firmeninternen Verwaltungssystems UCM als auch Gesprächsräume für Kundentermine. Der erste Stock besteht aus dem IT-Bereich und der Projektabwicklung. Innerhalb der Projektabwicklung wird zwischen Steuerung, SCADA, Fördertechnik, Hängefördertechnik, Lagertechnik, Mechanischer Konstruktion, Elektrischer Konstruktion, Produktdesign, Service, Projektmanager, Dokumentation und den Software-Ingenieuren bestehend aus Warehouse Management, Material Flow, Nutzeroberfläche, Softwarewartung, unterschieden. Das oberste Stockwerk ist für den Vertrieb, Betriebsrat und Management vorgesehen.
+Das Firmengelände besteht aus einem Verwaltungsgebäude und zwei Fabrikhallen. Ein weiteres Gebäude, das Zentrallager, befindet sich aktuell im Bau. Das dreistöckige Verwaltungsgebäude besitzt im Erdgeschoss den Kundenempfang, Human Resources, SPS-Entwicklung, Entwurf des Firmeninternen Verwaltungssystems UCM als auch Gesprächsräume für Kundentermine. Der erste Stock besteht aus dem IT-Bereich und der Projektabwicklung. Innerhalb der Projektabwicklung wird zwischen Steuerung, SCADA, Fördertechnik, Hängefördertechnik, Lagertechnik, Mechanischer Konstruktion, Elektrischer Konstruktion, Produktdesign, Service, Projektmanager, Dokumentation und den Software-Ingenieuren bestehend aus Warehouse Management, Material Flow, Nutzeroberfläche, Softwarewartung, unterschieden. Das oberste Stockwerk ist für den Vertrieb, Betriebsrat und Management vorgesehen.
 
-Die Sitzplätze des Großraumbüros sind nach Teams innerhalb Trennwänden gruppiert, um Kommunikationswege kurz zu halten, den Austausch zu fördern, jedoch bei Gesprächen andere Gruppen nicht zu belästigen, und bestehen aus jeweils vier bis fünf Leuten. Die Leute innerhalb eines Teams behandeln die gleichen Kundenprojekte. Diese \glqq{}Sitzordnung\grqq{} ist trotzdessen nicht bindend und jeglich eine Empfehlung, um Kommunikation zwischen den Gruppen nicht zu blockieren. Die Gruppe Projektabwicklung Software-Engineering Graphical User Interface, welcher ich untergewiesen bin, ist auf 4 Teams verteilt.
+Die Sitzplätze des Großraumbüros sind nach Teams mithilfe von Trennwänden gruppiert, um Kommunikationswege kurz zu halten, den Austausch zu fördern, jedoch bei Gesprächen andere Gruppen nicht zu stören, und bestehen aus jeweils vier bis fünf Leuten. Die Leute innerhalb eines Teams behandeln die gleichen Kundenprojekte. Diese \glqq{}Sitzordnung\grqq{} ist trotzdessen nicht bindend und jeglich eine Empfehlung, um Kommunikation zwischen den Gruppen nicht zu blockieren. Die Gruppe Projektabwicklung Software-Engineering Graphical User Interface, welcher ich untergewiesen bin, ist auf 4 Teams verteilt.
 
-Das Software-Engineering Department befindet sich im ersten Stock auf der Südseite, und ist mit einer Feuerschutztür von den anderen Projektabwicklungs-Abeilungen physisch getrennt. Bei Eintritt in die Abteilung wird man von den Meetingsräumen sowie darauffolgende Kücheneinheit und Sanitäranlagen begrüßt. Die Küchentheke besteht aus zwei Kaffeemaschinen, einem Wasserkocher, Kühlschrank sowie Spülmaschine und -becken. Direkt gegenüber befindet sich mein zugewiesener Arbeitsplatz, welcher mit einer Docking-Station meinen Arbeitslaptop mit Bildschirmen und Peripherie verbindet. Meine direkten Nachbarn befassen sich mit dem gleichen Themengebiet meiner Praxisphase und ermöglichen durch physische Nähe schnnelle, effiziente, E-Mail unabhängige Kollaboration und Problemlösung, besonders bei Trivialitäten. 
+Das Software-Engineering Department befindet sich im ersten Stock auf der Südseite, und ist mit einer Feuerschutztür von den anderen Projektabwicklungs-Abeilungen physisch getrennt. Beim Betreten der Abteilung fällt zunächst der Blick auf die Meetingräume, gefolgt von der angrenzenden Kücheneinheit. Direkt gegenüber befindet sich mein zugewiesener Arbeitsplatz, welcher mit einer Docking-Station meinen Arbeitslaptop mit Bildschirmen und Peripherie verbindet. Meine direkten Nachbarn befassen sich mit dem gleichen Themengebiet meiner Praxisphase und ermöglichen durch physische Nähe schnnelle, effiziente, E-Mail unabhängige Kollaboration und Problemlösung, besonders bei Trivialitäten. 
 
 \section{Aufgabenbereich}
 
-Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends von selektron zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, weil jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses Händische Softwaredeployment ist nicht nur aufwändig, sondern senkt dazu die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Folgend ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen im Schlimmstfall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Würde im aktuellen System eine Ausfallsicherheit existieren, könnte diese zumindest den Service bei einigen trivialen Fällen entlasten, jedoch ist aktuell keine vorhanden.
+Mein Arbeitsplatz befindet sich im Zentrum des Software-Engineering-Department, der GUI-Abteilung. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends von selektron zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, weil jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses händische Softwaredeployment ist nicht nur aufwändig, sondern senkt dazu die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Folgend ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen im Schlimmstfall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Würde im aktuellen System eine Ausfallsicherheit existieren, könnte diese zumindest den Service bei einigen trivialen Fällen entlasten, jedoch ist aktuell keine vorhanden.
 
-Jedes der Module der selektron-Suite wurde innerhalb der letzten Jahre in Container-Images gebündelt und daraufhin das Deployment mit Containerverwaltungstools wie Docker oder Podman durchgeführt, um das Deployment weitestgehend zu vereinfachen und Kundeninfrastrukturunabhängiger zu gestalten. Trotzdessen gehen viele der gennanten Probleme über die simple Containerisierung von Software hinaus, und bleiben somit bestehen.
+Jedes der Module der selektron-Suite wurde innerhalb der letzten Jahre in Container-Images gebündelt und daraufhin das Deployment mit Containerverwaltungstools wie Docker oder Podman durchgeführt, um das Deployment weitestgehend zu vereinfachen und unabhängiger von der Kundeninfrastruktur zu gestalten. Trotzdessen gehen viele der gennanten Probleme über die simple Containerisierung von Software hinaus, und bleiben somit bestehen.
 
-Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe im Bezug auf die Nutzeroberfläche, ist in der Firmenstruktur, da es als Integration gilt, dieser Abteilung untergliedert. Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen und triviale Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. In Anbetracht, dass die Firma aktuell noch keine Forschung über Kubernetes, außer dem Fakt, dass es existiert und die aktuelle Problemlage Lösen könnte, betrieben hat, sollte dies meine Aufgabe werden. Das Ziel ist es, herauszufinden, welche Features Kubernetes und dessen Ökosystem bietet, zu analysieren wie diese funktionieren als auch zu überprüfen, ob diese konkret für das Projekt Sinn ergeben. Mithilfe der Erkenntnisse soll Basiswissen über die Containerorchestration sowie ein möglichst automatisch deploybares Walking Skeleton auf Grundlage des selektron-Basisprojektes entstehen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen. Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.
+Obwohl das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb keine klassische Aufgabe im Bezug auf Nutzeroberflächen darstellt, ist die Aufgabe in der Firmenstruktur dieser untergliedert, da es als Integration von Systemen gilt.
+Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen und triviale Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. In Anbetracht, dass die Firma aktuell noch keine Forschung über Kubernetes, außer dem Fakt, dass es existiert und die aktuelle Problemlage lösen könnte, betrieben hat, sollte dies meine Aufgabe werden.
+
+Das Ziel ist es, herauszufinden, welche Features Kubernetes und dessen Ökosystem bietet, zu analysieren wie diese funktionieren, als auch zu überprüfen, ob diese konkret für das Projekt Sinn ergeben. Mithilfe der Erkenntnisse soll Basiswissen über die Containerorchestration sowie ein möglichst automatisch deploybares Walking Skeleton auf Grundlage des selektron-Basisprojektes entstehen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen. Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.
 
 \section{Methodik}
 
-Während der gesamten Praxisphase wurde, soweit realisierbar, ein iterativer Zyklus verfolgt. Dieser beginnt initial mit der Discovery-Phase, in welcher neue Produkte identifiziert werden, die zu den gegebenen Zielen passen. Anschließend werden sie in einem Backlog festgehalten. Dieser wird in Absprache mit den Betriebsmitgliedern geordnet.
+Während der gesamten Praxisphase wurde, soweit realisierbar, ein iterativer Zyklus verfolgt. Dieser beginnt initial mit der Discovery-Phase, in welcher neue Produkte identifiziert werden, die zu den gegebenen Zielen passen. Anschließend werden sie in einem Backlog festgehalten. Dieser wird in Absprache mit den Teamkollegen geordnet.
 
-Sofern ein Produkt die Spitze des Backlogs erreicht, werden Eigenschaften über das Produkt und dessen Funktionsweise ermittelt. Sofern die Ziele des Produktes mit den Zielen des Betriebes übereinstimmen, beginnt die Evaluationsphase, in welcher das Produkt in einer isolierten Umgebung ausprobiert wird, um Funktionsweisen und Charakteristiken zu observieren. Diese werden im Firmeninternen Confluence-Board, einer kollaborativen Knowledgebase von Atlassian, dokumentiert.
+Sofern ein Produkt die Spitze des Backlogs erreicht, werden Eigenschaften über das Produkt und dessen Funktionsweise ermittelt. Sofern die Ziele des Produktes mit den Zielen des Betriebes übereinstimmen, beginnt die Evaluationsphase, in welcher das Produkt in einer isolierten Umgebung ausprobiert wird, um Funktionsweisen und Charakteristiken zu observieren. Diese werden im firmeninternen Confluence-Board, einer kollaborativen Knowledgebase von Atlassian, dokumentiert.
 
-Täglich wird der aktuelle Stand dem Fachbetreuer mitgeteilt. Wöchentlich gibt es ein Meeting mit dem Fachbetreuer, dem organisatorischen Betreuer, meinem Gruppenleiter und weiteren Stakeholdern, um über ausprobierte Produkte, deren Eigenschaften und mögliche Integration in den Stack zu besprechen. Sofern Alternativen zu den Produkt bestehen erfolgt ein Vergleich mit diesen. Somit wird Techstack-Creep, welches mit übermäßiger Komplexitat, Ineffizienzen und Sicherheitsrisiken verbunden ist, verhindert. Gleichzeitig wird garantiert, dass wertschöpfende Produkte nicht ausgelassen werden. Bei grünem Licht wird das Produkt in die bestehende Testlandschaft integriert und weitere Optimierungen und Anpassungen für selektron erarbeitet.
+Täglich wird der aktuelle Stand dem Fachbetreuer mitgeteilt. Wöchentlich gibt es ein Meeting mit dem Fachbetreuer, dem organisatorischen Betreuer, meinem Gruppenleiter und weiteren Stakeholdern, um sich über ausprobierte Produkte, deren Eigenschaften und mögliche Integration in den Stack zu besprechen. Sofern Alternativen zu den Produkt bestehen erfolgt ein Vergleich mit diesen. Somit wird Techstack-Creep, welches mit übermäßiger Komplexitat, Ineffizienzen und Sicherheitsrisiken verbunden ist, verhindert. Gleichzeitig wird garantiert, dass wertschöpfende Produkte nicht ausgelassen werden. Bei grünem Licht wird das Produkt in die bestehende Testlandschaft integriert und weitere Optimierungen und Anpassungen für selektron erarbeitet.
 
 \section{Aufgabenbearbeitung}
 
@@ -247,7 +236,7 @@ Viele der Kunden haben strikte IT-Infrastrukturregeln, in welchem Zugang in das
 
 Der iterative Zyklus, welcher im Rahmen der Praxisphase angewandt wurde basiert auf dem Prinzip der agilen Softwareentwicklung. Diese Struktur bietet eine solide Grundlage für kontrollierte Identifikaiton, Bewertung und Integrataion neuer Technologien in ein System. Dennoch ist dieser Prozess nicht unfehlbar.
 
-Die Identifikationsphase, welche neu gefundene Produkte den übergeordneten Zielen zuweist und anschließend innerhalb eines Backlogs priorisiert gewährt eine strukturierte Abarbeitung. Durch das Einbeziehen von Betriebsmitgliedern werden unterschiedliche Perspektiven einbezogen, wodurch die Priorisierung auf fundierter Grundlage steht. Gleichzeitig besteht die Gefahr, dass subjektive Erfahrungen oder betriebliche Hierarchien die Priorisierung negativ beeinflussen und relevante Lösungen für Probleme in Vergessenheit geraten.
+Die Identifikationsphase, welche neu gefundene Produkte den übergeordneten Zielen zuweist und anschließend innerhalb eines Backlogs priorisiert gewährt eine strukturierte Abarbeitung. Durch das Einbeziehen von Teamkollegen werden unterschiedliche Perspektiven einbezogen, wodurch die Priorisierung auf fundierter Grundlage steht. Gleichzeitig besteht die Gefahr, dass subjektive Erfahrungen oder betriebliche Hierarchien die Priorisierung negativ beeinflussen und relevante Lösungen für Probleme in Vergessenheit geraten.
 
 Die Evaluationsphase stellt einen den nächsten Bestandteil des Prozesses dar. Das verwenden einer isolierten Testumgebung ermöglicht eine risikoarme Analyse des Produktes und nullifiziert Auswirkungen auf das bestehende Testsystem, wodurch die Stabilität dessen garantiert werden kann. Allerdings sorgt diese Isolation auch zu einer eingeschränkten Evaluationsfähigkeit, da reale Integraitonsbedingungen nicht abgebildet werden. Somit kann ein Produkt in der Testumgebung überzeugen, sich jedoch im Testsystem unerwartet Verhalten oder Probleme verursachen.
 
@@ -265,6 +254,22 @@ Die Praxisphase gab mir die Möglichkeit, mich mit technischen Themen auseinande
 
 Zusammenfassend sehe ich die Praxisphase als positiven Teil des Studiums und bin froh, diesen bei der psb intralogistics GmbH ablegen zu dürfen.
 
+\vfill
+\begin{minipage}[c]{0.49\textwidth}
+	\begin{center}
+		\noindent\rule{6cm}{0.3pt}\\
+		Unterschrift Student
+	\end{center}
+\end{minipage}
+\hfill
+\begin{minipage}[c]{0.49\textwidth}
+	\begin{center}
+		\noindent\rule{6cm}{0.3pt}\\
+		Unterschrift Unternehmen
+	\end{center}
+\end{minipage}
+\vspace{1cm}
+
 \newpage
 
 \printbibliography%[title={Quellen}]