46 lines
9.5 KiB
TeX
46 lines
9.5 KiB
TeX
|
\documentclass[../review_1.tex]{subfiles}
|
||
|
|
\graphicspath{{\subfix{../img/}}}
|
||
|
|
\begin{document}
|
||
|
|
|
||
|
|
\chapter{Interne Organisation}\thispagestyle{fancy} \section{Rollen}
|
||
|
|
% Welche Rollen gibt es, wie sind sie besetzt und für was ist welche Rolle verantwortlich?
|
||
|
|
Abhängig von individuellen Fähigkeiten und Interessen der einzelnen Teammitglieder wurden zu Beginn folgende Rollen zugeteilt:
|
||
|
|
\begin{table} [h]
|
||
|
|
\centering
|
||
|
|
\begin{tabular} {lll}
|
||
|
|
\textbf{Rolle} & \textbf{Name} & \textbf{Studiengang} \\ \toprule
|
||
|
|
Projektleiterin & Fabienne Göpfert & Wirtschaftsinformatik \\
|
||
|
|
Systemarchitekt & Robert Jeutter & Informatik \\
|
||
|
|
DPDK-Chief & Jakob Lerch & Ingenieurinformatik \\
|
||
|
|
Redakteur & Tim Häußler & Wirtschaftsinformatik \\
|
||
|
|
Dokumentation & Leon Leisten & Informatik \\
|
||
|
|
Build Engineer & Johannes Lang & Informatik \\
|
||
|
|
Qualitätsmanager bzw. Tester & Tobias Scholz & Ingenieurinformatik \\
|
||
|
|
Angreifer & Felix Hußlein & Informatik \\
|
||
|
|
Entwickler & alle Teammitglieder & - \\
|
||
|
|
\end{tabular}
|
||
|
|
\end{table}
|
||
|
|
\\Im Folgenden werden die Rollen und die dazugehörigen Aufgaben näher beschrieben. \\
|
||
|
|
Die \textbf{Projektleitung} übernimmt im Projekt die operative organisatorische Leitung. Dabei ist sie nicht nur verantwortlich für die Koordination der Mitglieder, der Organisation des Ablaufs oder der Kontrolle und Bewertung des Projektergebnisses, sondern muss auch \glqq jedem Teammitglied das Gefühl [geben], es habe selbst entschieden\grqq (Daniel Goeudevert). Zudem stellt die Projektleitung die Schnittstelle zur Umgebung des Projekts dar, was sich zum Beispiel in der Kommunikation mit Stakeholdern widerspiegelt. Um diese Rolle bestmöglich erfüllen zu können, ist Kommunikationsfähigkeit, große Zuverlässigkeit und hohes Verantwortungsbewusstsein erforderlich. Auch sind Erfahrung bei der Organisation, Planung und Steuerung hilfreich, die zumindest durch theoretische Veranstaltungen wie \glqq IT-Projektmanagement\grqq{} oder \glqq Geschäftsprozessmanagement\grqq{} Wirtschaftsinformatiker und -informatikerinnen vorweisen können. \\
|
||
|
|
Das Überblicken aller Komponenten und der Zusammenarbeit derer ist die Aufgabe des \textbf{Systemarchitekten}. Zudem ist er für die Entwicklung der Architektur des Systems und die Erweiterung vorhandener Architekturen zuständig. Vor allem im Systementwurf und der Systemspezifikation ist diese Rolle stark von Bedeutung. Um all diese Aufgaben zu erfüllen, sind Fähigkeiten wie ein tiefes Verständnis im technischen Bereich, Kenntnis in Methodenentwicklung und Kommunikationsfähigkeit erforderlich.\\
|
||
|
|
Die Rolle des \textbf{DPDK-Chiefs} ist stark projektspezifisch. DPDK steht dabei für Data Plane Development Kit, wobei es sich um ein schnelles Paketverarbeitungsframework auf Benutzerseite speziell für leistungsintensive Anwendungen handelt. Die Rolle des DPDK-Chiefs muss DPDK tiefer verstehen und dieses gewonnene Verständnis auch mit seinen Teammitgliedern kommunizieren. Zudem steht er diesen als ständiger Ansprechpartner zu diesem Thema zur Verfügung.\\
|
||
|
|
Zu den Aufgaben eines \textbf{Redakteur} gehört das Konzipieren, Erstellen und Überprüfen von Dokumentationen. Solche Dokumente können zum Beispiel die Installationsanleitung, das Pflichtenheft oder die Entwicklerdokumentation sein. Um diese Aufgaben erfüllen zu können, muss der Redakteur im stetigen Austausch mit den Entwicklern stehen.\\
|
||
|
|
Zur \textbf{Dokumentation}: Diese Rolle ist dafür zuständig, ein Softwaredokumentationswerkzeug auszuwählen und festzulegen, was genau auf welche Weise dokumentiert werden soll. Weiterhin ist er der Ansprechpartner für alle Fragen zur Dokumentation und kümmert sich um die Voll- ständigkeit der Code-Dokumentation.\\ Der \textbf{Build Engineer} plant das Build System und die Unit Tests. Außerdem ist er für die Versionierung zuständig.\\
|
||
|
|
Die Rolle des \textbf{Qualitätsmanagers und Testers} hat zahlreiche Aufgaben. Der Tester definiert verschiedene Testfälle. Er leitet diese Testfälle sowohl aus der Spezifikation (funktionale Testverfahren), als auch aus der Struktur des Quellprogramms ab (strukturelle Testverfahren). Daraufhin wählt der Tester verschiedene Testdatenkombinationen aus und definiert das erwartete Softwareverhalten. Nachdem er das Testobjekt mit einer Testdatenkombination ausgeführt hat, vergleicht er das erwartete mit dem tatsächlichen Verhalten. Das Testergebnis wird anschließend dokumentiert. Falls Fehler erkannt wurden, müssen diese an die Entwickler zur Fehlerbehebung weitergegeben werden. Nachdem diese Rolle auch das Qualitätsmanagement umfasst, kommen noch folgende Aufgaben hinzu: die Qualitätsplanung, d.h. die Planung der Anforderungen an ein Produkt (bzw. an das Projekt); die Qualitätsplanung, d.h. das steuernde Eingreifen bei Abweichungen von den Anforderungen; die Qualitätssicherung, d.h. Vertrauen schaffen, dass die Qualitätsanforderungen eingehalten werden; Qualitätsverbesserung, d.h. die kontinuierliche Verbesserung des Ausmaßes der Erfüllung von Anforderungen.\\
|
||
|
|
Aufgaben wie das Vorbereiten von Angriffen und das Ausführen von Tests gehören zu den Aufgaben des \textbf{Angreifers}. Der Angreifer versucht, das Programm durch gezielte Angriffe zu einem Zustand der Nichtfunktionalität zu bringen. Dabei baut der Angreifer nicht nur eine einzelne Verbindung vom Angriffsrechner zum Server auf, wie es bei DoS-Attacken der Fall ist, sondern er kann auch eine Vielzahl (dezentraler) Quellen für den Angriffstraffic nutzen. Dies erschwert es, den Angriff abzudämmen. Eine solche Attacke, welche in der Praxis von Bot-Netzen ausgeht, nennt man DDoS-Attacke (DDoS steht hierbei für \glqq Distributed Denial of Service\grqq). Zur weiteren Aufgabe des Angreifers zählt es, die Software auf neue Angriffspotentiale zu untersuchen. Außerdem soll er Informationen bereitstellen, um diese Angriffe zu verhindern.
|
||
|
|
|
||
|
|
\section{Kommunikationswege}
|
||
|
|
Das meist genutzte Kommunikationstool ist das Open Source-Tool \textbf{Zulip}. Dabei handelt es sich um ein Gruppen-Chatsystem, das vom Fachgebiet Telematik betrieben wird und zur Kommunikation aller Teammitglieder untereinander und mit dem Betreuer Martin Backhaus verwendet wird.\\
|
||
|
|
Wesentliche Vorteile von Zulip sind im Folgenden kurz beschrieben: Clients sind für alle gängigen Plattformen verfügbar und man kann sowohl Gruppen- als auch Direktnachrichten versenden. Weiterhin braucht man sich nicht mit fragwürdigen Datenschutzbestimmungen beschäftigen. Außerdem unterstützt die Software Markdown und Syntaxhervorhebung und einzelne Personen lassen sich mit \glqq @\grqq{} markieren, wodurch eine direkte und effiziente Kommunikation möglich wird.\\
|
||
|
|
Bezüglich der Organisation gibt es mehrere Streams, also themenspezifische Gruppenchats. Es gibt einen Haupt-Stream und einige weniger genutze Streams. Weiterhin wird ein Stream in mehrere Topics (Themen) unterteilt, z. B. für die Agenda eines bestimmten Treffens, konkrete Fragen zum Installieren von DPDK oder zum Git-Workflow. Es ist möglich, sich entweder alle Nachrichten oder nur die Nachrichten einer bestimmten Topic anzeigen zu lassen und somit mehrere Diskussionen gleichzeitig zu führen.\\
|
||
|
|
Für die Meetings wird auf \textbf{Cisco Webex Meetings} zurückgegriffen. Das ist ein Tool für Videokonferenzen, das von der Universität bereitgestellt wird. Über einen Link, den alle Teammitglieder vor dem Meeting erhalten, kann sich jeder einwählen. Die Software steht für alle gängigen Betriebssysteme zur Verfügung und bietet das Feature, den Bildschirm zu teilen, um Präsentationen zu zeigen oder gemeinsam an einem Dokument zu arbeiten. Bei technischen Schwierigkeiten mit Webex oder für interne Treffen wird auch teilweise auf \textbf{Jitsi} zurückgegriffen.\\
|
||
|
|
Eine weitere Form der Kommunikation stellt \textbf{GitLab} dar. Dabei handelt es ich um ein Open Source-Versionsverwaltungssystem, das für das Projekt benutzt wird. Issues, Labels und Branches sollen aussagekräftig benannt werden. Außerdem besteht für das Projekt ein Wiki, über das verschiedenste Informationen ausgetauscht werden, z.B. Protokolle für jedes Meeting, nützliche Links, der Git-Workflow, verwendete Software u.v.m.\\
|
||
|
|
Die gemeinsam beschlossenen Bennenungskonventionen besagen, dass z.B. Branch-, Issue-, Ordner- und Dateinamen klein geschrieben werden. Des weiteren soll nur ASCII und nur die englische Sprache benutzt werden, mit Ausnahme des Wikis, der Präsentationen und der Review-Dokumente.
|
||
|
|
|
||
|
|
\section{Weitere organisatorische Festlegungen}
|
||
|
|
% umfasst z. B. die Anzahl und Art der Gruppentreffen
|
||
|
|
Das komplette Projektteam trifft sich zweimal wöchentlich für circa 90 Minuten mit seinem Betreuer Martin Backhaus. Zu diesen Treffen ist pünktliches Erscheinen erfordert. Diese Treffen werden durch zweimal wöchentliche interne Team-Meetings ergänzt. Der zeitliche Umfang dieser Meetings variiert je nach Bedarf. Zu jedem Meeting wird im Vorhinein eine Agenda erstellt. Regelmäßig wird in diesen Meetings der derzeitige Stand abgefragt, Zudem werden wichtige Entscheidungen protokolliert und in das Gitlab-Wiki übertragen. In diesem Wiki werden außerdem nützliche Links geteilt und Wissen weitergegeben.\\
|
||
|
|
Um den Einstieg in das Projekt zu erleichtern, wurde am 06.05.2021 von je zwei Teammitgliedern eine Präsentation halten. Die Themen der Präsentationen umfassten DPDK, Denial-of-Service-Angriffe, effizienten Datenstrukturen, Git und Latex.
|
||
|
|
|
||
|
|
\end{document}
|