Weekly 10: 14.09.2023

Teilnehmer

Das Projektteam wird einen Portainer-Zugang erhalten und würde gerne Docker Compose verwenden, so dass auf die Verwendung von Kubernetes verzichtet werden kann. 3 Processing-Container und 2 Datenbank-Container sind vorgesehen.
Laut Projektteam wird es sich um ein Web-Frontend handeln, die Quellen sind parallelisiert, es wird einen Lauf für Unternehmensregister und einen Lauf für tagesschau.de benötigt; es geht hier um eine Handvoll Datensätzen mit ca. 1 Kilobyte
Herr Arinir empfiehlt, die Knoten zwischen den Containern darzustellen, die eine hohe Rechenlast verursachen (3-stufige Differenzierung mit „S“ oder „M“ oder „L“);
Laut Projektteam wird die Rechenlast „S“ für daily fetch, stagingDB, prodDB sein, die Rechenlast für den Data loader wird „M“ sein
Herr Arinir empfiehlt, beim Sammeln der Daten aus dem Internet vorsichtig zu agieren; wenn man intrusion detection / Firewall verwendet, es kann sein, dass die Firewall dies abklemmt, zudem kann dies als denial-of-service attack identifiziert werden; die gesamte FH hat außerdem nur eine zentrale IP-Adresse
Laut Projektteam gibt es aktuell Probleme mit Routing table (Netzwerkprobleme); aber man kann in Python „Extras“ definieren, dass z.B. CPU für CPU gebaut werden kann; so kann man die Container gut zusammensetzen.

Aus Sicht von Herrn Arinir ist die Dokumentation sehr wichtig, es muss für jedermann verständlich sein; laut Projektteam kann dies durch die entsprechenden Github-Pages (verfügbar im Repository) erreicht werden; für Herrn Arinir ist es nur wichtig, dass er auf das Repository Zugriff hat;
Hinsicht des Zeitplans ist aus Sicht von Herrn Arinir sehr wichtig, dass es nicht nur einen einfachen Meilensteinplan gibt, sondern dass ein linearer Burn-down dargestellt wird („unterhalb“ bedeutet man ist vor dem Plan, „oberhalb“ bedeutet man ist nach dem Plan); ein Projektplan ist sinnvoll für eine Abhängigkeitsplanung (der Projektplan ist zum Teil statisch); ein Burn-Down-Diagramm (bevorzugt kalenderwochenweise) ist für die Zeitplanung am besten geeignet, daraus erkennt man den Soll- und Istzustand und sieht, wie weit der Istzustand vom Sollzustand abweicht; auf diese Weise kann das Projekttracking und -monitoring transparenter gestaltet werden
Das Projektteam würde gerne anstatt des Burn-Down-Diagramms direkt in github den Übersichtsplan der github-„Tickets“ verwenden, der in Zukunft besser gepflegt werden soll

Laut Projektteam gibt es Probleme beim Personen-Matching bei mehrdeutigen Personen-Namen (wie z.B. "Müller" ohne Vorname bzw. Geburtsdatum); für die Wirtschaftsprüfer kann nur die Verbindung zu dem geprüften Unternehmen aufgebaut werden (Vorname, Nachname, Geburtsdatum + Firma); wenn kein Geburtsdatum da ist, ist auch dies nicht möglich;
Laut Herrn Arinir könnte man ggf. eine Unschärfe einbauen; dies ist jedoch laut Projektteam nicht möglich mit foreign keys
Zu diesem Problem konnte noch keine abschließende Lösung gefunden werden

Action Item	Verantwortlicher	Deadline
Pflege des Übersichtsplans der github-"Tickets"	Alle	nächstes Weekly