Nonsense
Inconsistent / irrelevant / very brief
Confusing / redundant / severe formal flaws / quite brief
A bit superficial / slightly inconsistent / quite short / visible formal flaws
Good, but ... a bit short / minor formal flaws
Comprehensive, well defined, formally fine
Use-Case-Diagramm zu funktionaler Anforderung »Untertützung von Gamification zur Motivation« (UCD-16)
- gehört zu funktionalem Requirement
- FR-66: Untertützung von Gamification zur Motivation
- History
- (v1) 2021-07-23 - initially created
- (v2) 2021-07-28 - Verbesserungen aus Review umgesetzt
- (v3) 2021-07-31 - Verbesserungen aus Todos umgesetzt + Anmerkungen zu offenen Punkten addiert
- Errors, Warnings, Todos
(sbe) Ist die Trennung in "Auswahl, Bearbeitung und als Erweiterung das Finalisieren einer Aufgabe" nicht zu kleinteilig? Siehe User Happiness Rule.- (psc) Schmaler Grad zwischen beiden Extremen. Das Finalisieren kann auch Tage dauern. Daher würde ich das Diagramm für diesen Kontext so lassen und im Falle einer Konkretisierung von Gamification erneut evaluieren. Als erste Idee sollte das passen.
- (sbe) zumindest - was ist Unterschied zwischen "commit + push" und "finalisieren"? Wie bekommt das System und der WMA es mit, dass ab jetzt nichts mehr kommt?
- (psc) Der WMA sollte davon möglichst nichts mitbekommen und keine weitere Arbeit haben (siehe Ziel _Entlastung_). Die Errungenschaften sollten automatisiert geprüft und vergeben werden. Allerdings stellt sich hier die Frage, wie Gamification didaktisch sinnvoll integriert werden kann und ob dann eine rein automatisierte Überprüfung in allen Fällen möglich ist.
- (sbe) wenn man die Trennung belässt - wann genau gibts doch Errungenschaft? Potenziell bei jedem der Schritte?
- (psc) Theoretisch lassen sich zu allen erdenklichen Schritten Errungenschaften entwickeln. Diese können einzelne oder summierte Tätigkeiten sein. z. B. kann der 1000 Commit eine Errungenschaft auslösen
Diagramm
Folgende Use Cases sind im nachfolgenden Diagramm dargestellt. Wenn es zu einem Use Case eine ausführliche Version mit Szenarien gibt, so ist diese verlinkt.
- Gamification (UC-9)
- Errungenschaften mit Bedingungen konfigurieren
- Aufgabe auswählen
- Bearbeitungsstand committen und pushen
- Bedingungen für Errungenschaft prüfen
- Bedingungen manuell prüfen
- Aufgabe finalisieren
- Errungenschaft erhalten
Beschreibung
Dieses Usecase-Diagramm stellt eine mögliche Option der funktionalen Anforderung Lernmotivation durch Gamification dar.
Der primäre Nutzer ist hierbei der Studierende, der durch die Interaktion mit dem System (Divekit) entsprechende Errungenschaften erlangen kann.
Exemplarisch wird im Use Case Diagramm allgemein die Arbeit (Auswahl, Bearbeitung und als Erweiterung das Finalisieren einer Aufgabe) mit dem DiveKit abgebildet. Aufgabenspezifische Errungenschaften werden hier nicht abgebildet. Dies bedeutet zudem, dass eine Überprüfung möglichst automatisiert erfolgen sollte.
Um Errungenschaften zu erhalten, sind diese im Vorfeld vom Entwickler mit Bedingungen zu konfiguieren.
Wählt der Studierende zum ersten Mal eine Aufgabe aus, so erfüllt er eine Bedingung und erhält somit eine Errungenschaft.
Der Studierende erabeitet dann die Aufgabe und stellt, sobald ein erster Bearbeitungsstand vorliegt, den ersten Commit und pushed diesen in sein Repo. Das System überprüft, ob die Bedingungen für eine Errungenschaft erfüllt sind. Zum Beispiel, ob der bereitgestellt Commit der aller erste ist. Der Studierende erhält eine weitere Errungenschaft.
Der Studierende finalisiert (dies wäre erfüllt, wenn die Aufgabe Kontrollmechanismen hat wie zum Beispiel Tests bei Codingaufgaben) die Aufgabe und pushed diese zur Überprüfung in das System. Ist die Überprüfung erfolgreich und werden Bedingungen einer Errungeschaft erfüllt, wird eine Errungenschaft vergeben.
Weist die Aufgabe hingegen Fehler auf, kann dies auch zum Erfüllen von Errungenschaften ausreichen und Errungenschaften vergeben.