NETUNUS - Minutes of Meeting

Uns wurde empfohlen kürzere Sätze zu formulieren. Nebenbedingungen werden nicht erkannt, sondern berücksichtigt. Das aktuelle System wird nur als Prototyp geplant, da die Sicherheitskontrollen für den tatsächlichen Betrieb noch nicht implementiert werden. In den Anforderungen sollen Ausdrücke wie z.B. "Wünschenswert wäre …​" unbedingt vermieden werden. Performance und Nachhaltigkeit eines Systems sind NFA’s (Nicht funktionale Anforderungen). "nur für den jeweiligen Nutzer" soll umgeschrieben werden auf "für berechtigte Personen".

Nachhaltigkeit kann in unseren Anforderungen weggelassen werden, da ein Menschenleben nicht mit zwei AA-Batterien verglichen werden kann.

Der Alarm wird nicht deaktiviert, sondern quittiert. Der Poolsensor löst den Alarm aus. Statt Poolbenutzer sollen wir "Objekt in Pool" schreiben.

Zwischen dem MQTT-Broker und dem Quarkus-Server muss eine Verbindung bestehen. "old Data" soll in "retrieve Data" umformuliert werden. Zwischen dem Quarkus-Server und der Datenbank soll eine normale Linie sein. Der MQTT-Broker gehört in das docker-compose. Wir sollen uns überlegen, wie man das System lokal laufen lassen kann, also unabhängig vom Internet. Es fehlt ein akustisches und ein visuelles Signal. Jedes dieser Signale hat einen eigenen ESP8266 oder wenn möglich einen gemeinsamen. Der Webserver greift über eine REST-Schnittstelle auf den Quarkus-Server zu. Statt der MariaDB sollen wir eine SQLite Datenbank verwenden.

Es soll Alarm quittieren heißen. Wir müssen uns im Vorhinein schon Zustände als Ziele definieren, um ein genaues Bild vor Augen zu haben wo wir hin wollen. Muss es immer der volle Alarm sein? Man könnte ihn in ein akustisches und ein visuelles Signal aufteilen. Somit kann man verschiedene Fälle abdecken z.B. Stromausfall = nur akustisches Signal. Der Benutzer kennt sich sofort aus.

Im Gantt-Diagramm werden die Sprints angezeigt. User Storys gehören (auch ohne Tasks) grob bis zum Ende durchgeplant.

Wir haben zu viel Inhalt im YouTrack. Wir sollen die Sprints bis zum Jahresende durchplanen. Zuerst alle User Storys und die die in nächster Zeit erledigt werden müssen mit Tasks noch genauer geplant sein. User Storys die erst später erledigt werden müssen vorerst nicht so genaue Tasks haben.

Am Master-Branch sollen nur Releases sein. Entwickelt wird nur am Developer-Branch. Für eine Website soll z.B. ein Feature-Branch erstellt werden.

Wir haben vier Use-Cases (Alarm auslösen, Alarm quittieren, Alarm für eine gewisse Zeitdauer deaktivieren, die Historie der Auslöser betrachten). Diese Use-Cases sollen wir bis zum Ende des Jahres erledigt haben.

Alarm auslösen: Wir sollen auf einer Website mittels Gif etc. angezeigt bekommen, wann ein Alarm ausgelöst werden würde.

Alarm quittieren: Mit einem Button auf dieser Website sollen wir den Alarm quittieren können.

Alarm für eine gewisse Zeitdauer deaktivieren: Der Alarm kann mit einem weiteren Button auf der Website für z.B. 5 Minuten deaktiviert werden. Jetzt kann der Benutzer schwimmen gehen, ohne, dass ein Alarm ausgelöst wird.

Historie der Auslöser betrachten: Der Benutzer kann sich eine Historie der Auslöser in Tabellenform auf der Website anzeigen lassen.