mirror of
https://github.com/fhswf/aki_prj23_transparenzregister.git
synced 2025-04-24 21:42:35 +02:00
48 lines
3.6 KiB
Markdown
48 lines
3.6 KiB
Markdown
# 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 |
|