Current CheckIn

chapters/thesis/appendix02.tex

@@ -0,0 +1,48 @@
+%********************************************************************
+% Appendix
+%*******************************************************
+% If problems with the headers: get headings in appendix etc. right
+%\markboth{\spacedlowsmallcaps{Appendix}}{\spacedlowsmallcaps{Appendix}}
+\chapter{Umfrage zur Optimierung}
+\label{ch:Umfrage}
+
+Herzlich Willkommen
+
+\hfill
+
+Diese Umfrage ist Teil der Bachelorarbeit >>Analyse und Optimierung der Webseite des Wedekind Projektes<< von Marco
+Galster, die Rahmen des Projektes >>Edition der Korrespondenz Frank Wedekinds als Online"=Volltextdatenbank<< an der
+Fernuni Hagen durchgeführt wird. In der Bachelorarbeit soll der aktuelle Prototyp auf Performance"=Probleme untersucht
+und im Anschluss optimiert werden, um die Benutzerfreundlichkeit und die Akzeptanz der Anwendung zu verbessern.
+Dies soll dazu führen, dass die digitalen Briefeditionen verstärkt bei der Forschung zur literarhistorischen und
+kulturgeschichtlichen Wissenssteigerung eingesetzt werden.
+
+\mytodos{der letzte Satz nochmal überarbeiten!}
+
+% helfen das die FOrschung mithilfe solcher datenbank vorrangetrieben wird und somit die foschung an briefedition das Wissen über die Kultur erweitert
+\hfill
+
+Der aktuelle Prototyp der Anwendung wird unter \href{https://briefedition.wedekind.h-da.de} bereitgestellt. Die Fragen
+sind bitte im Rahmen ihrer normalen Tätigkeit an dem Projekt zu beantworten. Bitte geben Sie so viele Informationen
+mit an, die ihnen zu den Problemen mit auffallen.
+
+\hfill
+
+Wir bedanken uns im Voraus für ihre Zeit und die Teilnahme an der Umfrage. Für die Umfrage benötigen Sie ca. 10 Minuten.
+
+\hfill
+
+\begin{enumerate}
+    \item Welche Tätigkeit führen Sie aus? (Bearbeiter/Verwender)
+
+    \item Bitte geben Sie nun die Tätigkeiten an, bei denen immer wieder Verzögerung auftreten. Geben Sie bitte zu
+            jeder Tätigkeit noch folgende Informationen mit an:
+
+    \begin{itemize}
+        \item Wie häufig tritt die Verzögerung auf? (in Abhängigkeit zum Aufruf)
+        \item Gibt es einen zeitlichen Bezug? (z.B. tritt die Verzögerung nur Vormittags auf)
+        \item Tritt es immer einer bestimmten Abfolge auf, und wenn ja in welcher? (z.B. wenn man zuerst die
+                Benutzerliste anwählt und dann in den Bearbeiten-Modus wechselt)
+    \end{itemize}
+
+\end{enumerate}

chapters/thesis/chapter03.tex

@@ -11,17 +11,18 @@ Frameworks diskutiert.
 \section{Aufbau der Umfrage}
 \label{sec:concept:poll}
 
-Die Umfrage wird per Email an die XX Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
+Die Umfrage wird per Email an die \mytodos{XX} Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
 unter \href{https://briefedition.wedekind.h-da.de} verwendet. Hierbei wird die gleiche Umfrage für Bearbeiter
 und Benutzer versendet.
 
 Die erste Frage ist zur Unterscheidung ob die Antworten von einen Bearbeiter oder von einem Benutzer kommt. Dies ist
-nur notwendig, um bei der Nachstellung zu unterscheiden welche Zugriffsrechte aktiv sind.
+nur notwendig, um bei der Nachstellung zu unterscheiden welche Zugriffsrechte aktiv sind und diese zu unterschiedlichen
+Performance-Problemen führt.
 
 Die weiteren Fragen sind aufeinander aufgebaut. Hierbei wird zuerst überprüft, bei welchen Aktionen eine längere
 Wartezeit auftritt. Zusätzlich soll noch dazu angegeben werden, wie häufig dies auftritt, also ob dies regelmässig
 auftritt oder immer nur zu bestimmten Zeitpunkten. Des Weiteren wird die Information nachgefragt, ob die Probleme
-immer bei der gleichen Abfolge von Aktionen auftritt.
+immer bei der gleichen Abfolge von Aktionen auftritt, oder die vorherigen Aktionen irrelevant sind.
 
 Die Anfrage wird im Anhang \ref{ch:Umfrage} dargestellt.
 
@@ -58,8 +59,13 @@ zwischengespeichert werden kann und daher diese Daten immer wieder direkt von de
 \section{Untersuchung der Anwendung}
 \label{sec:concept:softwarestructure}
 
-Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Hierbei ist jede
-Schicht einzeln aber auch im ganze zu betrachten.
+Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Zuerst wird der
+komplette Ablauf als BlackBox betrachtet, um neben der Umfrage, auch über automatisierte Anfragen, zu ermitteln wo die
+größten Performance-Probleme auftreten. 
+
+
+Hierbei ist jede
+Schicht einzeln, sowie der komplette Ablauf als BlackBox zu betrachten. 
 
 \mytodos{angenfangen bei jeder Schicht, kurz beschreiben und was da getan wird um dort etws zu untersuchen}
 
@@ -74,7 +80,7 @@ aufrufen und die Messung dazu protokolieren sowie die min und max werte (Skript
 \section{Vergleich mit anderen Technologien}
 \label{sec:concept:technologiecompare}
 
-% Vergleich mit AspNetCore und vielleicht VueJS oder Konsorten, wobei hier der Serverteil fehlt
+\mytodos{Noch tiefer eingehen}
 
 Damit eine Umsetzung mit einer anderen Technologie umgesetzt werden kann, muss dies den kompletten Aufbau unterstützen,
 wie dies die \ac{JSP} unterstützen. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus der Betrachtung
@@ -148,9 +154,13 @@ Skriptsprache aber verloren gegangen.
 \subsection{Fazit}
 \label{sec:concept:technologiecompare:summary}
 
-\mytodos{Noch entscheiden, ob der Compare direkt bei der Technologie gemacht \\ wird, oder allgemein am ende}
+Den größten Vorteil würde man aktuell mit der Umsetzung in Go bekommen, da dies für seine Geschwindigkeit und einfach
+bekannt und Entwickelt wurde. Zudem ist die Programmiersprache sehr jung und hat keine Altlasten mit dabei. Der
+größte Nachteil darin ist aber, dass hierfür noch nicht so viele Entwickler existieren, die dann das Projekt
+unterstützen können.
 
-PHP fällt aufgrund der Script-Sprache raus, da dies nicht verteilbar ist und an den Uni keine Entwickler zu finden sind.
-Bei Go sind es ebenfalls hauptsächlich die nicht vorhandenen Entwickler an der Uni
-ASP.NET Core ist im Vergleich zu JSP identisch, aber auch hier werden aktuell die Entwickler fehlen, da Java in den
-Vorlesungen dran genommen wird.
+Mein Einschätzung nach, wäre ein Umstieg im aktuellen Stadium nicht sehr sinnvoll, da zum einen der großteil der 
+Anforderung umgesetzt ist, und für jeden Änderung die Mitarbeiter sich erst in die neue Code-Basis einarbeiten müssten.
+Bei Weiterentwicklungen durch Studenten, ist man mit Java im Vorteil, da dies an der Uni gelehrt wird.
+
+\mytodos{Noch entscheiden, ob der Compare direkt bei der Technologie gemacht \\ wird, oder allgemein am ende}