# PRIVAT!: User Stories & QS-Ziele
| ID | 1 |
| :-------------------------------- | :- |
| Name | Startbildschirm |
| Beschreibung | Der/Die Nutzer\*in kann eine App öffnen, welche folgende zwei Optionen anzeigt: <br>Option 1: eigene Karte laden <br>Option 2: Scannen und speichern für GPS-Koordinaten <br> Das Laden der Karte und das Scannen selbst gehört nicht zu dieser User Story |
| Akzeptanzkriterium | Der Startbildschirm bietet die Auswahlmöglichkeiten eine Karte reinzuladen und für GPS-Koordinaten zu scannen. |
| Geschätzter Aufwand <br>(Story Points) | 10 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity <br>(Story Points/h) | |
| Bemerkung | führt zu User Story 2 & 3 |
- **Beschreibung**: Bündelung von User Stories 3,4 und 5
- **Akzeptanzkriterium**: Akzeptanzkriterien von US 3,4 und 5 sind erfüllt
| ID | 2 |
| :-------------------------------- | :- |
| Name | Karte als Bild reinladen |
| Beschreibung | Der Nutzer kann eine eigene Karte von seinem Gerät in png oder jpeg in die App laden und anzeigen lassen. |
| Akzeptanzkriterium | Das reingeladene Bild wird angezeigt.|
| Geschätzter Aufwand (Story Points) | 50 |
| Entwickler | Marius, Patrick |
| Umgesetzt in Iteration | 2 |
| tatsächlicher Aufwand (h) | 2 * 4,5 |
| Velocity (Story Points/h) | |
| Bemerkung | |
| ID | 3 |
| :-------------------------------- | :- |
| Name | Navigation auf der Karte (inkl. zoom) |
| Beschreibung | Der Nutzer soll in der Lage sein das reingeladene Bild zu verschieben und zu vergrößern.|
| Akzeptanzkriterium | Ein angezeigtes Bild lässt sich zur einfacheren Navigation verschieben und vergrößern. |
| Geschätzter Aufwand (Story Points) | 40 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
| ID | 4 |
| :-------------------------------- | :- |
| Name | Standort auf Karte markieren |
| Beschreibung | Der Nutzer soll die Möglichkeit erhalten auf einer Karte einen Standort zu markieren.|
| Akzeptanzkriterium | Der ausgewählte Standort wird visuell auf der Gesamtkarte korrekt (an der vom Nutzer angeklickten Position) markiert und zwischengespeichert |
| Geschätzter Aufwand (Story Points) | 25 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
6. Speichern der Daten pro Standort
- Voraussetzung: Wir können eine alte Karte erneut mit den zugehörigen Standorten aufrufen
- **Beschreibung**: Zu jedem Standort ist ein zugehörigen Datensatz verlinkt.
- **Akzeptanzkriterium**:
| ID | 5 |
| :-------------------------------- | :- |
| Name | Speichern der Daten pro Standort |
| Beschreibung | Zu jedem Standort ist ein zugehörigen Datensatz verlinkt.|
| Akzeptanzkriterium | |
| Geschätzter Aufwand (Story Points) | 25 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
7. Speicherungsstruktur entwerfen und implementieren
- auf Smartphone sinnvoll abspeichern
- **Beschreibung**:
- **Akzeptanzkriterium**:
8. Daten sammeln
- [wiki](https://de.wikipedia.org/wiki/Wireless_Local_Area_Network#Standards_nach_IEEE_802.11)
- [Properties](https://developer.android.com/reference/kotlin/android/net/wifi/ScanResult)
- Führt zu US 8
| **ID** | **6** |
| :-------------------------------- | :- |
| Name | Speicherstruktur implementieren |
| Beschreibung | Die Daten eines Wlan-Netze-Scans werden in einer Datei im SQLite-Format abgespeichert. |
| Akzeptanzkriterium | Es existiert eine SQLite-Datei, die von der Anwendung zum speichern und abrufen der gesammelten Daten genutzt wird. |
| Geschätzter Aufwand (Story Points) | 70 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity <br>(Story Points/h) | |
| Bemerkung | |
| **ID** | **7** |
|:------- |:--- |
| Name | Daten sammeln |
| Beschreibung | Es werden automatisiert die für das Gerät nutzbaren Wlan-Funkfrequenzen durchgegangen und zugehörige Daten gesammelt. Hierbei werden folgende Daten erfasst: <br>`BSSID`, `SSID`, `capabilities`, `centerFreq0`, `centerFreq1`, `channelWidth`, `frequency`, `level`, `operatorFriendlyName`, `timestamp`, `venueName`. <br>Diese User Story erfüllt den zentralen Zweck der Anwendung die Daten zu sammeln. |
| Akzeptanzkriterium | Es wurde über alle für das Gerät nutzbaren Wlan-Funkfrequenzen iteriert und alle Daten zu den sichtbaren Wlan-Netzen erfasst, die für das Gerät erreichbar sind. |
| Geschätzter Aufwand (Story Points) | 50 |
| Entwickler | Marius, Patrick |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | 2 * 5 |
| Velocity <br>(Story Points/h) | |
| Bemerkung | |
|||
| ID | 8 |
| Name | Daten in Datenbank speichern|
| Beschreibung | Als Nutzer\*in möchte ich, dass meine Wlan-Daten und Standortdaten abgespeichert werden.|
| Akzeptanzkriterium | Nach Durchführung eines Scans werden zusammengehöhrende Wlan- und Standortdaten abgespeichert. (hier ist die Datenbankstruktur dann wichtig!)|
| Geschätzter Aufwand (Story Points) | 15 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Benötigt US 6.|
|||
| ID | 9 |
| Name | Wifi-Daten mit Ortungsdaten verbinden |
| Beschreibung | Als Nutzer\*in möchte ich, dass die gesammelten Daten zu den markierten Standorten auf der Karte gespeichert werden, damit diese später darüber referenziert werden können.|
| Akzeptanzkriterium | Zu jeder Markierung auf der Karte werden die absoluten Koordinaten in Form von Pixeln abgespeichert. Die gesammelten Daten werden dann zusammen mit diesen Positionen in die Datenbank gelegt. Anhand der gespeicherten Positionen kann dann auf die gesammelten Daten zugegriffen werden.|
| Geschätzter Aufwand (Story Points) | 30 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
|ID | 10 |
| Name | Benachrichtigung über Scan-Beendigung |
| Beschreibung | Als Nutzer\*in möchte ich, dass mir angezeigt wird, ob der Scan erfolgreich beendet wurde. |
| Akzeptanzkriterium | Nachdem alle benötigten Daten gesammelt wurden, wird auf dem Bildschirm in Form eines kleinen Fensters angezeigt, dass der Scan erfolgreich beendet wurde. Sollte ein Fehler auftreten, sodass nicht alle benötigten Daten gesammelt wurden und der Scan vorzeitig beendet wird erscheint ebenfalls ein kleines Fenster mit genau dieser Benachrichtigung. |
| Geschätzter Aufwand (Story Points) | 15 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
- Eigene US für "Nicht bewegt?"?
- Benachrichtigung?
- **Beschreibung**: Der aktuelle Scan wird beendet und die Daten aus dem RAM in persistenten Speicher schreiben. Ruft Routinen für Datenvalidierung auf.
- **Akzeptanzkriterium**:
11. Daten validieren und aussortieren
| ID | 11 |
| :-------------------------------- | :- |
| Name | Validieren und aussortieren der Daten |
| Beschreibung | Als Nutzer\*in möchte ich, dass bei der Datenerfassung nur sinnvolle Daten gespeichert werden.|
| Akzeptanzkriterium | Die gesammelten Daten werden nach dem Scan anhand von vorher festgelegten Regeln für die erhobenen Werte überprüft. Sollten diese die Regeln nicht verletzen so werden diese Werte gespeichert. Andernfalls werden die Daten dieses Netzes verworfen. |
| Geschätzter Aufwand (Story Points) | 35 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
- **Beschreibung**: Wird von "Scan beenden" aufgerufen und dient dazu fehlerhafte Daten zu erkennen und auszusortieren.
- **Akzeptanzkriterium**: Es werden nur die fehlerhaften Daten aussortiert.
12.
| ID | <del>12 |
| :-------------------------------- | :- |
| Name | <del>Alte Karten laden |
| Beschreibung | <del>Als Nutzer\*in möchte ich auf alte, bereits verwendete Karten zugreifen können, um auf diesen neue Messungen durchzuführen. |
| Akzeptanzkriterium | <del>Es muss möglich sein bereits gespeicherte Karten auszuwählen, sodass man mit ihnen interagieren kann. Alle vorher darauf gespeicherten Messungen sind weiterhin markiert und neue Messungen werden zusammen mit den alten abgespeichert. |
| Geschätzter Aufwand (Story Points) | 25 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Benötigt US 20 <br> ist jetzt in US 27 und 28 aufgeteilt |
13. Permissionanfragen überarbeiten
| ID | 13 |
| :-------------------------------- | :- |
| Name | Permissionabfrage beim Starten der App |
| Beschreibung | Als Nutzer\*in möchte ich beim ersten Starten der App von der App gefragt werden, ob sie auf bestimmte Dienste meines Gerätes zugreifen darf.|
| Akzeptanzkriterium | Wenn die App nach der Installation zum ersten mal gestartet wird, werden alle Permissions für einen vollen Funktionsumfang zusammen abgefragt. Der User sieht die(das) üblichen Fenster, welche bei Permissionabfragen standardmäßig von Android verwendet werden. |
| Geschätzter Aufwand (Story Points) | 40 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Zukünftige US: Permissions bei jedem Start überpfrüfen, einzelne Funktionen evtl sperren oder Permission abfragen |
---
| ID | 14 |
| :-------------------------------- | :- |
| Name | Standort zu aktivieren |
| Beschreibung | Als Nutzer\*in möchte ich Standortdialog angezeigt bekommen, über den ich innerhalb der App den Standortdienst aktivieren kann. |
| Akzeptanzkriterium | Den Nutzenden wird eine Anfrage zur Aktivierung des Standortdienstes angezeigt. Nach der Bestätigung der Anfrage wird der Standortdienst erfolgreich aktiviert. |
| Geschätzter Aufwand (Story Points) | 30 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
| | |
| **ID** | **15** |
| Name | Queransicht |
| Beschreibung | Als Nutzer\*in möchte ich den Bildschirm drehen können, um die Anwendung im Querformat nutzen zu können. |
| Akzeptanzkriterium | Nachdem der/die Nutzer\*in den Bildschirm gedreht hat, wechselt die Anwendung in das Querformat der Anwendung. |
| Geschätzter Aufwand (Story Points) | 50 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity <br>(Story Points/h) | |
| Bemerkung | Diese US schließt US16 aus |
| | |
| **ID** | **16** |
| Name | Rotieren blockieren |
| Beschreibung | Als Nutzer\*in möchte ich, dass die Anwendung trotz Drehung des Bildschirm nicht in eine Queransicht wechselt. |
| Akzeptanzkriterium | Es ist nicht möglich die Anwendung in ein Querformat zu versetzen, um den Verlust eines reingeladenen Bildes zu verhindern. |
| Geschätzter Aufwand (Story Points) | 1 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Diese US schließt US15 aus |
| | |
| **ID** | **17** |
| Name | Karte verschieben mit Fling-Bewegung |
| Beschreibung | Als Nutzer\*in möchte ich durch eine Fling-Bewegung die Karte schneller verschieben können. |
| Akzeptanzkriterium | Eine Fling-Bewegung führt zu einer Verschiebung der Karte abhängig von der Fling-Geschwindigkeit. |
| Geschätzter Aufwand (Story Points) | 30 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
| | |
| **ID** | **18** |
| Name | Grenzen für die Karte |
| Beschreibung | Als Nutzer\*in möchte ich, dass die Verschiebung der Karte durch den Bildschirmrand begrenzt wird. |
| Akzeptanzkriterium | Die Karte kann durch eine Bewegung nicht in den Bildschirm hinein gezogen werden. <br> Beispielsweise soll es nicht möglich sein den rechten Rand des Bildes, durch eine Linksbewegung, weiter nach links zu bewegen als den rechten Rand des Bildschirms. |
| Geschätzter Aufwand (Story Points) | 40 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
| | |
| **ID** | **19** |
| Name | Multiscans pro Position |
| Beschreibung | Um Schwankungen in der Signalstärke besser feststellen zu können, möchte ich als Nutzer\*in die Möglichkeit haben, an meiner aktuellen Position automatisiert mehrfach scannen zu können. |
| Akzeptanzkriterium | Der/die Nutzer\*in hat die Möglichkeit eine Anzahl an Scans einzustellen, welche nacheinander am aktuellen Standort ausgeführt werden. Jeder dieser Scans wird separat abgespeichert. |
| Geschätzter Aufwand (Story Points) | 15 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Abhängig von US7 |
|||
| **ID** | **20** |
| Name | Karte dauerhaft in Anwendung speichern |
| Beschreibung | Als Nutzer\*in möchte ich die Möglichkeit haben, dass meine reingeladene Karte für zukünftige Nutzung abgespeichert wird. |
| Akzeptanzkriterium | Nachdem der/die Nutzer\*in eine Karte in die Anwendung geladen hat, wird nach einer dauerhaften Speicherung gefragt. |
| Geschätzter Aufwand (Story Points) | 55 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **21** |
| Name | CI Task: apk, Style Checking, Tests |
| Beschreibung | Als Nutzer\*in möchte ich nach Abschluss jeder User Story, die Möglichkeit haben, die aktualisierte Anwendung nutzen zu können. |
| Akzeptanzkriterium | Nachdem eine User Story abgeschlossen wurde, soll durch einen CI Task das Style checking sowie Testen durchgeführt und eine apk-Datei automatisiert erstellt werden. |
| Geschätzter Aufwand (Story Points) | 10 |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | <del>**22** |
| Name | <del>UI verbesserungen: Startmenü |
| Beschreibung | <del>Als Nutzer\*in möchte ich ein ansprechendes Hauptmenü mit einer sinnvollen Menüführung haben. |
| Akzeptanzkriterium | <del>Die Startseite der Anwendung besitzt nicht nur Buttons, die die Funktionen der Anwendung direkt ausführen, sondern, die die Nutzenden zu den jeweiligen |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **23** |
| Name | UI verbesserungen: Default Hintergrund wenn keine Karte geladen |
| Beschreibung | Als Nutzer\*in möchte ich, dass ein Default Hintergrund angezeigt wird solange keine Karte geladen ist. |
| Akzeptanzkriterium | Es soll eine "leere" Beispiel Karte angezeigt werden solange keine Karte geladen ist, damit kein leerer Bildschirm angezeigt wird. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **24** |
| Name | UI verbesserungen: Scan interface nach Punktauswahl |
| Beschreibung | Als Nutzer\*in möchte ich eine Scan-option angezeigt bekommen, nachdem ich einen Punkt auf einer geladenen Karte ausgewählt habe. |
| Akzeptanzkriterium | Es erscheint eine Interaktionsfläche, nachdem man eine Position innerhalb der Karte markiert hat mit der man einen Scan an der Markierten Stelle starten kann. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **25** |
| Name | UI verbesserungen: Button für alte Karten |
| Beschreibung | Als Nutzer\*in möchte ich die Möglichkeit haben in einem Menü eine vorherige Karte auszuwählen um diese zu laden. |
| Akzeptanzkriterium | Am oberen Linken Rand des Bildschirms soll ein Knopf erstellt werden über welchen man zu einer Liste gelangt die einem die zuletzt geöffneten Karten anzeigt, damit man diese erneut laden kann. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Benötigt US 28 |
|||
| **ID** | **26** |
| Name | Deprecated WifiManager#startScan() |
| Beschreibung | Als Nutzer\*in möchte ich, dass die App auch in zukunft noch verwandbar sein wird. |
| Akzeptanzkriterium | Da die Methode WifiManager#startScan() ab Android x.x.x als Deprecated markiert ist wird diese ersetzt. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Diese US ist eine Erinnerung, dass diese Methode in Zukunft entfernt werden wird. Da es in Android 8-11 jedoch keine Alternative zu dieser Methode gibt ist es nicht möglich diese Methode sofort auszutauschen |
|||
| **ID** | **27** |
| Name | Karten Speichern mit Name |
| Beschreibung | Als Nutzer\*in möchte ich meine Karte in ihrem aktuellen Zustand abspeichern können. |
| Akzeptanzkriterium | Der/die Nutzer\*in bekommt die Möglichkeit die aktuell in Verwendung befindliche Karte mit den bereits gescannten Standpunkten zu speichern. Hierbei soll der Name auf vorherige existenz geprüft werden. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **28** |
| Name | Karte mit allen vorherigen Scanpunkten anzeigen |
| Beschreibung | Als Nutzer\*in möchte ich eine in der Vergangenheit genutzte Karten in die App laden können um diese erneut verwenden zu können |
| Akzeptanzkriterium | Es soll eine Möglichkeit geben eine Karte die vorher verwendet wurde in die Anwendung erneut zu laden um dieser neue Scan Daten hinzu zu fügen. Außerdem sollen alle zu dieser Karte vorhandenen Scan daten geladen werden damit diese angezeigt werden können. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **29** |
| Name | Export interface für Daten |
| Beschreibung | Als Nutzer\*in möchte ich eine API zur Verfügung haben, durch welche den Export, der Scandaten zu einer beliebigen Karte, in ein beliebiges Format ermöglicht. |
| Akzeptanzkriterium | Ziel dieser US ist es eine API bereit zu stellen, über die ein Außenstehender Entwickler sein eigenes Export-format definieren und implementieren kann. Es soll dabei möglich sein alle Scandaten für alle Karten zu erhalten. Nicht Ziel dieser US ist es das Exportieren in einem bestimmten Vormat zu erlauben. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **30** |
| Name | Export als JSON Datei |
| Beschreibung | Als Nutzer\*in möchte ich meine Scandaten in ein JSON vormat exportieren können, um diese auf einem Computer verwenden oder analysieren zu können. |
| Akzeptanzkriterium | Es soll möglich sein alle Scandaten die in der Anwendung vorliegen in eine JSON Datei zusammenzufassen und diese Anschließend per Android share Intent an andere Anwendungen weiterzuleiten. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Benötigt US29 |
|||
| **ID** | **31** |
| Name | Export um Daten zu Mozilla Location Service hochzuladen |
| Beschreibung | Als Nutzer\*in möchte ich die Möglichkeit besitzen die gesammelten Scandaten an Mozilla Location Service weiter zu leiten. |
| Akzeptanzkriterium | Ziel dieser US ist es, dass alle vorhandenen Scandaten mit ihren Positionsdaten in ein Format gebracht werden, welches zu Mozilla Location hochgeladen werden kann. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | Benötigt US29 |
|||
| **ID** | **32** |
| Name | Outdoor Scan |
| Beschreibung | Als Nutzer\*in möchte ich die Möglichkeit besitzen einen Scan auch außerhalb eines Gebäudes durchzuführen. |
| Akzeptanzkriterium | Es ist möglich einen Scan außerhalb eines Gebäudes mit einem vorhandenem Gebäudeplan durchzuführen. Hierfür wird d3er GPS-Standort verwendet um die Position des Scans zu bestimmen und zu Speichern. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | abhängig von US 33 |
|||
| **ID** | **33** |
| Name | Abspeichern von GPS-Location zu |
| Beschreibung | Als Nutzer\*in möchte ich die Möglichkeit besitzen zu jeder gespeicherten Karte eine GPS-Location zu Spiechern, damit diese Leichter örtlich eingeordnet werden kann |
| Akzeptanzkriterium | Es ist möglich zu jeder Karte eine GPS-Location abzuspeichern und diese im weiteren Verlauf auch zu überarbeiten oder ausgeben zu lassen. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
|||
| **ID** | **??** |
| Name | Heatmap für bestimmte Wlans |
| Beschreibung | Als Nutzer\*in möchte ich eine Heatmap angezeigt bekommen können die für jedes Wlan die stärke über die Geladene Karte anzeigt. |
| Akzeptanzkriterium | Es wird eine Heatmap generiert die die Signalstärken einzelner Accesspoints signalisieren soll. Außerdem werden an flächen zwischen einzelnen Messungen die Signalstärken interpoliert, sodass ein flächendeckendes Bild angezeigt wird. |
| Geschätzter Aufwand (Story Points) | |
| Entwickler | |
| Umgesetzt in Iteration | |
| tatsächlicher Aufwand (h) | |
| Velocity (Story Points/h) | |
| Bemerkung | |
# Namen
- POWA (portable optimizing wifi analyzer)
# QS-Ziele
## Vorlage QS-Ziele
>Im Rahmen dieses Projektes hat die Sicherstellung der... höchste Priorität, da ...
>Im Rahmen dieses Projektes können wir jedoch nur gewährleisten, ...
## Vorlage QS-Maßnahmen
>Um das Qualitätsziel zu erreichen, führen wir nach jedem Commit(Release/Fertigstellung einer US/...) automatische Tests( statische Analysen/Studien/CodeReviews/...) durch. [Aussagen, die die Maßnahme genau beschreiben.] Weiterhin setzen wir folgende Werkzeuge ... ein, die ...
## Vorlage QS-Prozess (Durchführung der Maßnahmen)
> Die Maßnahme wird alle ... durchgeführt. Die Ergebnisse werden ... diskutiert und einer Entwicklerin zum Lösen zugewiesen. Für geänderten Code wird derselbe Qualitätssicherungsprozess angewandt wie für neuen.
## QS-Ziele 1. Entwurf
- Portabilität (auf mehrere Geräte)
- Maßnahmen: Testen auf eigenen unterschiedlichen Android-Geräten
- Wartbarkeit
- Maßnahmen: Statische Analysetools, Code-Review
- Funktionalität
- Maßnahmen: Automatisierte Tests
- (Benutzbarkeit)
- Maßnahmen: Nutzerstudie
## Anmerkungen zu QS-Ziele
### Allgemeines
- Die QS-Ziele müssen messbar formuliert werden.
- Alle QS-Ziele müssen bei der Abgabe auch belegt werden.
- Prozess für das sichern der QS-Ziele fehlt.
### Portabilität
- Bspw. 4 Gerätetypen angeben damit dieses Ziel Messbar ist.
- Anforderung der AGs: Mindestens Android 8.0/9.0
### Funktionalität
- Es muss klar formuliert werden worauf sich die Testabdeckung von 76% bezieht.
### (Benutzbarkeit)
- Diese Maßnahme ist bisher ebenfalls nicht messbar.
- Die AGs fordern nicht, dass jeder die App nutzen kann. (Alex ist das Maß)
## Eigene Formulierung QS-Ziele
### Wartbarkeit
Unsere Auftraggebenden (folgend als AGs bezeichnet) planen das Projekt durch eine Visualisierung der von unserer Anwendung gesammelten Daten zu erweitern. Zusätzlich soll es möglich sein die WiFi-Access-Point Parameter zu optimieren.
Hierfür ist gut lesbarer und verständlicher Code eine Voraussetzung.
Deshalb haben wir dem Qualitätssicherungsziel "Wartbarkeit" die höchste Priorität zugeteilt.
Um dieses Qualitätsziel zu erreichen, werden wir nach jeder abgeschlossenen User Story Code Reviews durchführen, um unsauberen und unleserlichen Code frühzeitig zu erkennen. Diese werden unterstützt und geleitet durch eine automatische Überprüfung anhand des Kotlin Style Guides.
### Portabilität
Im Rahmen dieses Projektes hat die Sicherstellung der Portabilität eine hohe Priorität, um die Verbreitung der Software zu vergrößern.
Da unsere Software dazu dienen soll die Einstellungen eines Routers zu verbessern und dies im Optimalfall für jede Person möglich sein soll, ist eine Ausführbarkeit auf möglichst vielen verschiedenen mobilen Endgeräten wünschenswert. Wir haben die Android Version 8.0 als Minimum ausgewählt, da dies die minimale Version eines Gerätes ist, die uns zum Testen zur Verfügung steht. Mit dieser Anforderung kann unsere Anwendung auf etwa 82% der aktuellen Android-Geräten ausgeführt werden. (Stand: 09.12. - Android Studio)
Dies werden wir mit manuellen Tests auf physischen Geräten sicherstellen, um Abweichungen der Funktionalität in Simulation und durch verschiedene Android Versionen ausschließen zu können. Die manuellen Tests werden auf folgenden Geräten durchgeführt, da uns diese zur Verfügung stehen:
- HUAWEI P8 lite 2017(Android 8.0.0)
- Samsung Galaxy S9 (Android 10)
- Xiaomi Mi 9 (Android 11)
### Zuverlässigkeit
Im Rahmen dieses Projektes hat die Sicherstellung der Zuverlässigkeit eine hohe Priorität.
Da unsere Software dazu dienen soll die Einstellungen eines Routers zu verbessern, sind wir auf die Richtigkeit unserer gesammelten Daten angewiesen.
Hierfür werden wir automatisierte Tests verwenden, welche die Funktionen des Backends überprüfen. Das Frontend wird durch manuelle Tests der Portabilität mit überprüft, um auch dort eine korrekte Funktionsweise sicherstellen zu können.
# Agenda AG-Treffen 02.12.2021
1. Anmerkung zum Protokoll
2. Überarbeitete QS-Ziele
3. Feedback zu den User Stories
- Worin liegt der Unterschied zwischen Option 1 und Option 2 beim startbildschirm?
- Option 1: Eine Karte wird reingeladen, auf der man die zu scannenden Punkte markiert. GPS Position waren bisher nicht eingeplant, können jedoch zusätzlich zur Einordnung der Karte genutzt werden.
- Options 2: Keine Karte reingeladen, sondern nur anhand der GPS-Position wird der aktuelle Standpunkt ermittelt.
- Gps Position werden letztlich doch benötigt, egal ob Ich einen Plan abfotografiere oder aus einer Datei lade
- ursprünglich nicht geplant.
- Annahme: mit scannen ist aus der Papierform abfotografieren ist korrekt?
- Mit scannen meinen wir das sammeln der Wlan-Daten
- Markierung auf der Karte (Punkt 3) wie wird der Punkt referenziert? Irgendein Maßstab wird das vermutlich benötigt.
- Maß sind die Pixel des Bildes.
- Speicherstruktur entwerfen und implementieren ist eine Story?
- Da zu unkonkret, haben wir die US (6) nicht weiter ausformuliert.
- Ein Sprint beginnt üblicherweise wenn die Fragen für die Implementierung geklärt sind
- ok
- Ich denke die Struktur sollte ihr vorher vorstellen, dass hilft euch Zeit zu sparen und nichts zu implementieren, dass dann noch passt.
- Speicherstruktur: (SQLite/Alternative?)
- json vorest nur auf Handy
```json
Ort: <GPS-Coordinaten>
<BSSID (Mac-Adresse)>:
SSID: <Wlan name>
capabilities:
centerFreq0: <frequenz>
centerFreq1:
channelWidth:
frequency:
level: <stärke>
operatorFriendlyName:
timestamp:
venueName:
```
5. User Story: Startbildschirm
6. Name & Logo
- Namen:
- Yet another Wifi Tool
- Not just another Wifi Tool
- Freifunk-WiFi-Tool
- POWA (portable optimizing wifi analyzer)
- Logo
- Idee pitchen: Wlansymbol vor Raumplan
8. User Stories für den nächsten Sprint
- Daten sammeln
# Agenda AG-Treffen 17.12.2021
Moderation: Patrick
Protokoll: Christian
1. Anmerkung zum Protokoll
2. Logo: Rechte für FreiFunk Karte?
3. Abnahme der User Stories der letzten Iteration
4. Auswahl User Stories nächste Iteration
5. Vorführen QS-Ziele und Maßnahmen
6. Rückfragen
## Feedback Projektbeschreibung LiGround
Könntet ihr in wenigen Worten zusammenfassen, was das Hauptziel des Projekts ist?
Wurde der Kontext (d.h. Motivation, Einsatzgebiet, ev. Zielgruppe) erläutert?
Wird deutlich wie das Projekt umgesetzt wurde d.h. werden Komponenten oder Architektur skizziert und relevante eingesetzte Technologien genannt?
Wird der Umfang des Projektes klar? Was soll gebaut werden? Was existiert ggf. bereits schon? Was ist nicht relevant?
Hat die Beschreibung einen angemessenen Umfang? Werden also alle oben genannten Punkte ausreichend klar, ohne, dass unnötig viele weitere Dinge aufgelistet werden?
Was fällt euch noch auf? Welche Tipps habt ihr aus eurer eigenen Erfahrung? Was hilft euch beim Schreiben? Bitte explizit auch angeben, wenn euch etwas positives auffällt.
- Die Einleitung ist ingesamt sehr gut gelungen, jedoch könnten einige Elemente zur Entstehung des Spiels Schach kürzer gefasst werden.
- Im Abschnitt Motivation geht nicht klar hervor wieso ihr LiGround verbessern und ausbauen wollt. Ihr schreibt selbst, dass "[LiGround] bietet eine übersichtliche GUI"
#### Beschreibung
- Der Hauptteil der Projektbeschreibung ist sehr detailiert geschrieben.
- Es geht für uns nicht hervor, ob sich der erste Teil der Beschreibung auf die bereits existierende Anwendung oder eure Implementierung bezieht.
- Zu electron könnte eine Fußnote hinzugefügt werden.
- Wer ist die Zielgruppe von LiGround? Jeder Schachspieler?
- "Das Entwicklungsziel von LiGround während dieses Bachelorpraktikums lag in der Steigerung der Benutzerfreundlichkeit." würden wir in den Anfang der Beschreibung verschieben. So würdet ihr verdeutlichen, dass die Anwendung bereits exisitert, aber von euch überarbeitet wird.
- Bei der Aufzählung der neuen Funktionalitäten könnten wir uns noch eine Begründung für die neuen Funktionalitäten vorstellen.
Insgesamt habt ihr unserer Meinung nach den Umfang der Projektbeschreibung gut getroffen. Die meisten Punkte werden ersichtlich, teilweise jedoch erst nach einer aktiven Suche.
Sign in with Wallet
Connect another wallet