Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:software:beuthbot:berichte:ws2020:alt:dennis [17.11.2020 14:58]
Dennis Walz
+++ wiki:software:beuthbot:berichte:ws2020:alt:dennis [22.11.2020 16:52] (aktuell)
Robert Xaver Halwaß ↷ Seite von wiki:software:beuthbot:berichte:ws2020:dennis nach wiki:software:beuthbot:berichte:ws2020:alt:dennis verschoben
@@ Zeile 1: / Zeile 1: @@
+====== Pflichtenheft Features ======
@@ Zeile 44: / Zeile 46: @@
 | Anforderungen            | * Erfolgreiche "erinnere"-Anfragen werden vom Dienst durch Bestätigung der erkannten und persistierten Daten beantwortetoder  \\ * Fehlerhafte “erinnere”-Anfragen werden durch ein Mini-Usage-Tutorial beantwortet, damit der User seine Anfrage korrigieren kann  \\ * Erinnerungen werden auf user-ebene (clientunabhängig) gespeichert, so dass ein User die gleichen Erinnerungen in allen genutzten Clients zur Verfügung hat  \\ * Erinnerungen werden bei Fälligkeit einmalig (an alle clients des users) ausgespielt  \\ * Wiederkehrende Erinnerungen werden ausgespielt und anschließend an Hand des Intervals neu terminiert  \\ * Der Nutzer kann Erinnerungen löschen  \\ * Der Nutzer kann seine Erinnerungen anzeigen lassen  \\ * Der Service wird als Docker Container via docker-compose verwaltet und in das BHT-Repository integriert  \\ * Der Service nutzt das (noch zu schaffende) Content-Service-Framework  \\ * Wenn der Reminder-Service nach einem Ausfall wieder aktiv wird erinnert er nicht (einzeln) an alle Termine, die zwischenzeitig fällig waren  \\ * Der Serive ist in Hilfe-Texten des (Chat) BHT-Bots integriert                                |
 | Tasks                    | * BOT-57 Rasa Anbindung "Erinnere"-Direktive \\ * BOT-58 Service Endpoint speichert Reminder und Antwortet auf Probleme \\ * BOT-59 Scheduler/Cronjob prüft und sendet regelmäßig fällige Erinnerungen \\ * BOT-60 Dokumentation Service Usage \\ * BOT-109 Deployment / Release \\ * BOT-112 Hilfe-Texte in (Chat)BHT-Bot help-command / willkommensnachricht                                               |
@@ Zeile 54: / Zeile 55: @@
 | Anforderungen            | * Relevante Termine werden regelmäßig, automatisch bezogen und als Erinnerung gespeichert  \\ * User können “globale Erinnerungen” aktivieren oder deaktivieren  \\ * Das Feature ist resistent gegen Änderungen an den Domains oder deren Struktur → Fallen gescrapete Dienste länger aus wird dies reported  \\ * Das Feature wird als nicht-eigenständig in den Reminder Service integriert  \\ * Das Feature ist bzgl. Opt-in oder Opt-out in den Hilfe-Texten/Begrüßungsnachrichten des BHT-Bot dokumentiert                                   |
 | Tasks                    | * BOT-83 Prüfen ob Opt-In (nötig ist) oder Opt-Out (möglich ist) \\ * BOT-84 Quellen mit relevanten Terminen zusammentragen - auf Scrapebarkeit achten \\ * BOT-85 Scraping (mittels Scapring-Service) implementieren \\ * BOT-86 Termine aus Scraping in Erinnerungs Datenbank überführen \\ * BOT-87 Rasa Direktive Opt-In oder Opt-Out implementieren \\ * BOT-88 Error-Reporting implementieren, bei Misslungenen Scraping (über gewisse Zeit hinweg) \\ * BOT-114 Opt-In oder Opt-Out in Hilfe-Texten / Willkommensnachricht dokumentieren                                                 |
@@ Zeile 65: / Zeile 64: @@
 | Anforderungen            | * Der User kann dem Bot seinen Moodle-Kalender-Export-Link senden um einen Import auszulösen  \\ * Die iCal Datei hinter dem Export-Link wird in Erinnerungs-Einträge des Erinnerungs-Service umgewandelt  \\ * Erinnerungen an Abgabetermine erfolgen zu Beginn des Tages / zeitlich versetzt vor der Fälligkeit der Abgabe, nicht zum im Kalender angegebenen Zeitpunkt  \\ * Das Moodle-Import Feature wird nicht-eigenständig in den Reminder-Service integriert  \\ * Das Feature (und seine Nutzung) ist in der BHT-Bot Hilfe gelistet                                   |
 | Tasks                    | * BOT-90 Import Moodle Rasa Direktive \\ * BOT-91 Moodle iCal Download via zentralem Scaper Service \\ * BOT-92 iCal Parsing und Persistierung als (sinnvolle) Erinnerung \\ * BOT-111 Feature Release \\ * BOT-113 Hilfe-Texte in (Chat)BHT-Bot help-command / willkommensnachricht                                                  |
+| BACKLOG BOT-106: Monitoring bzw. Alerting Features                                                                          ||
+| Aktuell gibt es keine Stelle durch die sich der Bot im Falle von Problemen bemerkbar machen kann. \\   So fallen Ausfälle von ganzen Servicen ebenso wenig auf, wie der Ausfall von Teil-Logiken. \\   2 aktuelle Beispiele: \\   1) Der Bot stürzt regelmäßig ab, der Container startet neu und funktioniert wieder. Kein Admin kann derzeit mitbekommen oder analysieren warum das so ist. \\   2) Services die bspw. Webscraping einsetzen werden zwangsweise irgendwann unfunktional, weil sich die genutzten Endpunkte / Strukturen ändern ohne dass dies von Admin/Entwicklerseite bekannt ist. Solche Dienste fallen ggf. vom Service sogar richtig behandelt aus, so dass der User ein Fehler-Feedback bekommt, Admins bekommen diese Information aber wiederum nicht                                                                               ||
+| BACKLOG BOT-115: History Feature prüfen  ||
+| Im Gespräch mit Lukas aus dem SoSe2020 wurde bekannt, dass das "History Feature" letztes Semester etwas vernachlässigt wurde. Es handelt sich um ein Array, das bei Requests weitergereicht und von jedem Service mit eigenen Einträgen befüllt wird, so dass zu jedem Zeitpunkt ersichtlich wird welche Services bereits Kontakt mit dem Request hatten \\   Da dieses Feature nützlich beim Debuggen ist, aber nur helfen kann, wenn genügend Informationen darin gesammelt werden, muss die Konsistenz überprüft und mindestens in neuen Services wieder hergestellt werden ||
+| BACKLOG BOT-119: Mock-Option für Deconcentrator ||
+| Aus Gespräch mit Lukas aus SoSe2020 hat sich ergeben, dass die Sprachverarbeitung in früheren Stadien des BHT-Bot gemocked wurde. Dieses Feature ist nicht mehr funktionsfähig, für die Entwicklung könnte eine solche Implementation allerdings hilfreich sein: \\   Wenn ein Service entwickelt wird kann dieser nur durch User angesprochen werden, wenn der Concentrator User-Requests korrekt parsed. Dies beinhaltet die Weitergabe und Analyse des Requests mittels Sprachananalyse Services, aktuell insbesondere durch Rasa.  \\   Um einen Service unabhängig von Rasa-Training und NLP testen/entwickeln zu können wird ein Mock-Feature für den oder als Ersatz für den Concentrator entwickelt. ||
+| BACKLOG BOT-121: Database und Database_micrososervice zusammenführen ||
+| Es gibt derzeit 2 Services, die im Grunde das gleiche zu machen scheinen: \\   https://github.com/beuthbot/database_microservice \\   https://github.com/beuthbot/database/ \\   Der Unterschied scheint lediglich in der bereitgestellten Funktionalität zu liegen: Während der "database" Service lediglich userbezogene Abfragen behandelt kann der "database_mircoservice" Service arbiträre Datensätze der Services persistieren. Im Kern dienen beide Services aber lediglich dazu eine zentrale Schnittselle zur gleichen Mongo-DB herzustellen \\   Diese dopplung der Datenbankservices ist nicht dokumentiert, oder zumindest ist diese Dokumentation nicht sichtbar geworden. Daher gilt es die beiden Datenbanservices zu einer logischen Einheit zu vereinen, oder zumindest sicherzustellen, dass nachfolgende EntwicklerInnen erkennen können dass es hier eine "unlogische" Service-Redundanz gibt ||
@@ Zeile 74: / Zeile 90: @@
 | Anforderungen            | * <Anforderung 1>\\ * <Anforderung 2>                                  |
 | Tasks                    | * <Task1>\\ * <Task2>                                                  |

wiki.ziemers.de

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge