added diskussion and figures evaluation
This commit is contained in:
@@ -3,6 +3,6 @@
|
||||
|
||||
|
||||
\subsection{Ausblick}
|
||||
Was war bei mir nicht enthalten, warum ist die Berechnung nur teilweise valide, eigenen ergebnisse nicht schlecht machen
|
||||
Datenbank optimieren (Taggable Manager evtl raus)
|
||||
Emails mit Cron
|
||||
Einbidnung in die Hochschulewebsite
|
||||
|
||||
@@ -16,8 +16,8 @@ Um den Umfang der E-Mail-Flut einordnen zu können, wird das Postfach des Studie
|
||||
\hfill
|
||||
\end{figure}
|
||||
|
||||
Während des Semesters trafen in Summe 264 Nachrichten im Postfach ein. Darunter sind 95 dieser, innerhalb der Fakultät befördert worden. Abbildung 4.1. verdeutlicht auf der linken Seite das Verhältnis zwischen den Nachrichten hochschulweit, und innerhalb der Fakultät. Diese wurden von diversen Verteilern der Hochschule an den Probanten gesendet.
|
||||
Auf der rechten Seite der Abbildung 4.1. ist eine Übersicht der genutzten Distribuenten dargestellt. Dabei wird verdeutlicht, dass die Mailingliste der Studierenden am häufigsten genutzt wird um Informationen zu versenden. Daraus lässt sich schlie"sen, dass über die Hälfte aller Mitteilungen unter Anderem an Studierende verteilt werden.
|
||||
Während des Semesters trafen in Summe 264 Nachrichten im Postfach ein. Darunter sind 95 dieser, innerhalb der Fakultät befördert worden. Abbildung 4.1. verdeutlicht auf der linken Seite das Verhältnis zwischen den Nachrichten hochschulweit, und innerhalb der Fakultät. Diese wurden von diversen Verteilern an den Probanten gesendet.
|
||||
Auf der rechten Seite der Abbildung 4.1. ist eine Übersicht der genutzten Distribuenten dargestellt. Dabei wird verdeutlicht, dass die Mailingliste der Studierenden am häufigsten genutzt wird um Informationen zu versenden. Daraus lässt sich schlie"sen, dass über die Hälfte aller Mitteilungen an Studierende verteilt werden.
|
||||
|
||||
Sortiert der Probant nun den Posteingang nach relevanten Informationen, so zeigt sich in Abbildung 4.2. folgendes Ergebnis:\\
|
||||
|
||||
@@ -30,19 +30,64 @@ Sortiert der Probant nun den Posteingang nach relevanten Informationen, so zeigt
|
||||
|
||||
Das Balkendiagramm der Abbildung 4.2. zeigt, wie viele Informationen der Gesamtanzahl von E-Mails bedeutsam für den Probanten sind. Detaillierter wird gezeigt, wie viele hiervon innerhalb der Fakultät das Interesse geweckt haben. Fokussiert man die Themenübersicht wird deutlich, dass allgemeine Benachrichtigungen, wie Termine von Veranstaltungen, prüfungsrelevante Neuigkeiten oder Updates zu den Systemen der Hochschule durch das Rechenzentrum, den Interessenschwerpunkt bilden. Spezifischere Informationen, wie des Language Centers, des International Office oder der Fachschaft EFI nehmen zwar einen geringeren Anteil ein, sind für den Probanten aber dennoch nicht vernachlässigbar.
|
||||
|
||||
Werden die eingehenden E-Mails betrachtet, die der Studierende als nicht relevant aussortiert hat, lassen sich bereits eindeutige Tendenzen erkennen. Wie bereits in Abbildung 4.1. erkennbar ist, sind 169 Informationen irrelevant, das sind 64 Prozent der Gesamtheit. Extrahiert man davon die Fakulätinternen Benachrichtigungen so ergibt sich die Anzahl 53. Prozentual lässt sich daraus berechnen, dass 31 Prozent der überflüssigen E-Mails ausgehend der EFI-Fakultät selbst sind.
|
||||
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=1.0\textwidth]{figures/evaluation-2}
|
||||
\caption{Details der relevanten E-Mails des Probanten.}
|
||||
\includegraphics[width=1.0\textwidth]{figures/evaluation-3}
|
||||
\caption{Details der irrelevanten E-Mails des Probanten.}
|
||||
\hfill
|
||||
\end{figure}
|
||||
|
||||
Bei Sondierung der Detailansicht von Abbildung 4.3., auf der linken Seite zu sehen, ist klar zu erkennen, dass zu meist die sehr spezifischen Informationen über Vorlesungen, Interessen oder Freizeitaktivitäten vom Probanten aussortiert werden. Hierbei lässt sich erschlie"se, wie symptomatische Informationen, trotz fehlender Relevanz, das Postfach eines Einzelnen überfluten.
|
||||
|
||||
Dadurch bestätigt sich die Hypothese: Die E-Mail-Flut der Hochschule wird durch den Einsatz einer Weberweiterung gedrosselt.
|
||||
-> verifizieren, bestätigen, überprüfen
|
||||
|
||||
\subsection{Ergebnis}
|
||||
|
||||
Werden alle Auswertungen der Evaluation zusammengefasst und betrachtet, so ist deutlich zu sehen, dass Benachrichtigungen der Hochschule zu ausgedehnt verteilt werden. Fakultätsübergreifende Themengebiete sind häufig über umfangreiche Verteiler an Einzelpersonen weitergegeben worden und erzeugen dabei eine schwer administrierbare Menge.
|
||||
|
||||
Der Fokus dieser Arbeit liegt jedoch zunächst auf dem reduzieren der E-Mail-Flut innerhalb der EFI-Fakultät. Wird der Prototyp auf der Hochschul-Website eingebunden, so kann die Problematik im Idealfall auf ein Kleinstes reduziert werden. In Abbildung 4.4. ist das Verhältnis zwischen irrelevanten und relevanten Informationen der Fakultät visualisiert. Hier wird nochmal deutlich, dass über die Hälfte der Nachrichten keinerlei Bedeutsamkeit für den Probanten haben. Aufgrund dessen, lassen sich folgende Erkenntnisse festhalten. Die Website-Erweiterung vermeidet das Eintreffen der unwichtigen und informiert Studierende und Angestellte über alle wichtigen Benachrichtigungen. Somit lässt sich der eintreffende Verkehr bereits um 35 Prozent reduzieren.
|
||||
|
||||
Werden die allgemeinen Informationen der gesamten Hochschule ebenfalls in das System eingetragen, so kann das Postfach lediglich für persönliche und organisatorische Absprachen innerhalb der Hochschule genutzt werden und der administrative Aufwand des E-Mail-Speichers kann aufs Kleinste beschränkt werden.
|
||||
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=0.3\textwidth]{figures/evaluation-4}
|
||||
\caption{Vergleich relevanter und nicht relevanter Mails.}
|
||||
\hfill
|
||||
\end{figure}
|
||||
|
||||
(Dadurch bestätigt sich die Hypothese: Die E-Mail-Flut der Hochschule wird durch den Einsatz einer Weberweiterung gedrosselt.
|
||||
-> verifizieren, bestätigen, überprüfen)
|
||||
|
||||
|
||||
\subsection{Diskussion}
|
||||
In diesem Kapitel wird das Ergebnis der Arbeit in Bezug auf die Forschungsfrage diskutiert. Au"serdem wird der Prototyp mit einem bereits vorhandenen Framework verglichen und in Bezug darauf eingeordnet.
|
||||
|
||||
Unter Verwendung der entwickelten Erweiterung kann die E-Mail-Flut der Hochschule unter bestimmten Voraussetzungen gedrosselt werden. Die Evaluation, anhand eines Probanten, zeigt eindeutig das Potenzial, die Anzahl von Nachrichten zu reduzieren, durch eine optimierte Personalisierbarkeit. Anhand der Beispielhaften Zählung der im Postfach vorhandenen E-Mails kann zudem festgehalten werden, dass eine Gro"szahl dieser als unnötig für Individuen einzustufen ist. Zu beachten ist jedoch, dass es sich bei der Bewertung nur um eine theoretische Annäherung eines realen Ergebnisses handelt.
|
||||
|
||||
Weiter Schritte, um den Einsatz des Prototypen finalisieren zu können, sind ein au"sführliches Testing, für das im Rahmen dieser Arbeit keine Kapazitäten mehr frei waren. Unter Beobachtung der einzubindenden Web-Erweiterung kann die Plattform für einen gewissen Zeitraum genutzt werden und in Folge dessen eine detaillierte Aussage über die mögliche Reduzierung des Speicheraufwands im Postfach möglich sein.
|
||||
|
||||
Das Ergebnis dieser Arbeit wird im Folgenden mit Eigenschaften des Kursmanagementsystems Moodle verglichen.
|
||||
Die Struktur des Prototypen ist, wie in den oberen Kapiteln bereits erläutert, mit verschieden zuordnebaren Tags realisiert. Bestimmte Benutzer können Informationen einpflegen und verwalten. In Moodle ist der Vorgang ähnlich gehandhabt. Hier können Lehrende Material und Informationen in verschiedenen Lernräumen hochladen. Das System ist, im Gegensatz zum Prototyp, sehr umfangreich. Als Benutzer ist es möglich sich in diese Lernräume einzutragen und durch die Anmeldung aktuelle Benachrichtigungen zu erhalten. Sind manche Informationen in Moodle nur mit einem extra Passwort zugänglich, so ist das in der Erweiterung dieser Arbeit für alle Benutzer gleich verfügbar (vgl. [Dok15]).
|
||||
|
||||
Die Menge der Daten einer solchen Plattform sind nicht zu unterschätzen. Moodle verwendet unter anderem Caching-Tools und optimierte Prozesse um die Datenbanken zu befüllen und schnellstmöglich abfragen zu können. In der hier erstellten Anwendung liegt der Schwerpunkt nicht auf der Optimierung einer Datenbank oder dem Verbessern der Performanz.
|
||||
|
||||
Eine weitere wichtige Eigenschaft einer Informationsplattform ist das regelmä"sige Abrufen der neusten Informationen. Um das Interesse der Studierenden und Lehrenden aufrecht zu erhalten, integriert Moodle ein Skript, bekannt unter dem Name Cron, dass asynchrone Benachrichtigungen ermöglicht. Wird ein \texttt{Cron-Job} auf dem systeminternen Server ausgeführt, so wird zyklisch der Benutzer über Neuigkeiten informiert (vgl. [Dok18]).
|
||||
Im Prototyp wurde das Verfahren der asynchronen E-Mail-Benachrichtigung getestet. Mit der Konfiguration des Shell-Skripts werden die Sendezyklen und die Inhalte festgelegt. Die Abbildung 4.5. zeigt den Cron-Tab, der wöchentlich gesendet werden soll ( \texttt{0 0 * * 0} ). Des weiteren werden die Pfade der Entwicklungsumgebung und des Servers mitgegeben. Um das Senden der Mails überwachen zu können werden die Aktivitäten in ein Log-File geschrieben und sind im Adminsitrator-Backend abrufbar.
|
||||
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=1\textwidth]{figures/crontab}
|
||||
\caption{Cron-Tab der im Prototyp getesteten Benachrichtigung.}
|
||||
\hfill
|
||||
\end{figure}
|
||||
|
||||
Zusammenfassend lässt sich sagen, dass Moodle ein weit umfangreicheres Repertoire an Funktionen und Möglichkeiten bietet als der entwickelte Prototyp. Einige der Eigenschaften sind jedoch in der Web-Erweiterung enthalten und lassen darauf schlie"sen, dass diese zur Reduzierung der E-Mail-Flut beitragen kann.
|
||||
|
||||
|
||||
Der Umfang des Prototyp soll sich nur auf die Verbreitung von Informationen beschränken und kann deshalb nicht vollständig mit Moodle gleichgesetzt werden.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -81,13 +81,6 @@ Der Autor ist durch einen \texttt{ForeignKey} mit dem \texttt{UserModel} verbund
|
||||
Die Abbildung 3.3. zeigt die Modellierung der Tabelle \texttt{User} und \texttt{Post}. Au"serdem verdeutlicht es die Erweiterung des User-Modells von Django mit dem in der Applikation angelegtem CustomUser. Die im User vorkommenden \textit{booleschen Felder} werden im Kapitel Berechtigungen der User genauer erörtert.
|
||||
\end{addmargin}
|
||||
|
||||
\subsection{Verwaltung im Administrator-Back-end}
|
||||
In diesem Kapitel wird beschrieben wie das Administrations-Back-end genutzt werden kann. Es ist jedoch zu beachten, dass die Applikation vorwiegend von Dozenten und Angestellten der Hochschule ohne Administratorrechte verwendet werden soll. Die gestaffelten Berechtigungen werden im Kapitel Berechtigung der User genauer beschreiben.
|
||||
|
||||
Ein Django-Projekt bildet bereits beim Einrichten, standardmä"sig, eine Administrator-Oberfläche um die Inhalte der Website kontrollieren zu können. Nach der Migration von den oben genannten Modellen wird diese erweitert. Nich zu vergessen sind die externen Tabellen der installierten Add-on's, die nach der Migration das Back-end expandieren.
|
||||
|
||||
---eevtl kapitel löschen
|
||||
|
||||
|
||||
\subsection{Berechtigungen der User}
|
||||
Im Allgemeinen verwendet man Berechtigungen um Benutzern Zugang zu bestimmten Resourcen in einem Netzwerk einzuräumen. Au"serdem bestimmt es die Art des Zugangs, also ob der User die Resourcen nur lesen, verändern oder löschen darf (vgl. [Com18]). Die Rechte werden meist einzelnen Individuen oder einer Gruppe zugeordnet.
|
||||
|
||||
Reference in New Issue
Block a user