# Weekly *10*: 14.09.2023

## Teilnehmer
- Prof. Arinir
- Tristan Nolde
- Tim Ronneburg
- Philipp Horstenkamp
- Kim Mesewinkel-Risse
- Sascha Zhu
- Sebastian Zeleny

## Themen

### Zum Thema Container (Docker Compose)

- 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.



### Zum Thema Projekt-/Zeitplan und Dokumentation:

- 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


### Zum Thema Personen-Matching bei mehrdeutigen Personen-Namen

- 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

## Abgeleitete Action Items

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