mirror of
https://github.com/fhswf/aki_prj23_transparenzregister.git
synced 2025-04-26 17:12:35 +02:00
58 lines
3.5 KiB
Markdown
58 lines
3.5 KiB
Markdown
# Weekly: 14.09.2023
|
|
|
|
## Teilnehmer
|
|
- Prof. Arinir
|
|
- Tristan Nolde
|
|
- Tim Ronneburg
|
|
- Phillip 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 eine 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 Datenabgreifen 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 Burndown 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 Burndown-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 iund -monitoring transparenter gestaltet werden
|
|
|
|
- Das Projektteam würde gerne anstatt des Burndown-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önte 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 Übersichtssplans der github-"Tickets" | Alle | nächstes Weekly |
|
|
|
|
|
|
|
|
|