Aufgabe 04 - Jahresprojekt Sprint 1 - Use Cases

Lernziele

Du beurteilst ein Use-Case-Diagramm mit der Prüffrage aus Kapitel 08 und korrigierst Akteure, Anwendungsfälle und die Pfeile von include und extend.
Du planst Sprint 1 deines Jahresprojekts mit einem Sprint-Ziel und einer Auswahl, die zur unbekannten Velocity passt.
Du zeichnest das Use-Case-Diagramm deines Jahresprojekts und beschreibst den wichtigsten Anwendungsfall mit Vorbedingung, Standardablauf, Alternativablauf und Nachbedingung.
Du gleichst Diagramm und Backlog gegeneinander ab.

Ausgangslage

Sprint 0 ist abgeschlossen (Aufgabe 03): Produktidee, Backlog, Definition of Done, Board und ein Repository mit grüner Pipeline stehen. Ab dieser Woche ist das Jahresprojekt eure Praxis. Jede Woche bringt ein Kapitel Theorie, und ihr setzt sie in eurem Projekt um. Eine kurze Übung zu Beginn (die Kata) macht dich vorher mit dem neuen Werkzeug vertraut.

Der Rhythmus der nächsten Wochen:

Ein Sprint dauert drei Wochen. Diese Woche ist die erste Woche von Sprint 1: Ihr plant ihn.
Jede Einheit beginnt mit dem Board-Check aus Kapitel 06 (fünf Minuten).
Projektarbeit läuft nach dem Git-Workflow light aus Kapitel 07: Issue, Branch, Merge Request mit Review durch eine zweite Person, Zeiterfassung mit /spend.

Klarstellungen zu Aufgabe 03. Ab jetzt gilt für alles, was ihr in Sprint 0 angelegt habt:

Sprintlänge: Ein Sprint dauert genau drei Wochen (Sprint 1 bis 4, danach Abnahme und Präsentation). Habt ihr in Aufgabe 03 andere Termine geplant, passt ihr sie heute an.
Bibliotheken: Kapitel 21 mit den Prüffragen und dem Entscheidungsdokument wird erst am Ende vorgetragen (Aufgabe 15). Bis dahin notiert ihr jede neue Bibliothek mit einem Satz Begründung als Kandidat. Wer den Abschnitt „Bibliotheken und Schnittstellen auswählen“ schon jetzt liest, darf die Prüffragen gleich verwenden.
„Tests grün“ in der Definition of Done: Bis zu den Kapiteln über Teststrategien testet ihr mit dem, was ihr aus der 4. Klasse kennt. Die Teststrategie und die Testpyramide ergänzt ihr in Aufgabe 13 und 14.
Abgabe: Das README.md des Projekt-Repositorys bleibt die Projektbeschreibung. Was du persönlich abgibst, steht ab jetzt im README.md deines Projektordners, mit Links ins Repository (siehe Allgemein).

Die erste Karte der Navi-App aus Kapitel 08 ist das Use-Case-Diagramm: Wer will mit dem System was erreichen? Genau diese Frage stellst du heute an euer Projekt, bevor in Sprint 1 die erste Zeile Fachlogik entsteht.

Die Kata: Probenraum-Buchung der Schulband. Ein Teammitglied hat für ein kleines Buchungssystem dieses Diagramm gezeichnet und bittet dich um ein Review. Die Anforderungen:

Bandmitglieder buchen den Probenraum für einen Termin und sehen ihre eigenen Buchungen. Eine Buchung kann storniert werden, solange der Termin noch nicht begonnen hat.
Die Bandleitung gibt Buchungen frei. Erst eine freigegebene Buchung blockiert den Raum.
Die Musiklehrkraft sperrt den Raum für Konzerte; eine Sperre überschreibt alle Buchungen in diesem Zeitraum.
Bei einem Konflikt mit einer bestehenden Buchung kann das Bandmitglied einen Ersatztermin vorschlagen lassen.
Für alles ist eine Anmeldung nötig.

usecase-beta
  actor HerrWagner
  actor Bandmitglied
  actor Datenbank
  systemBoundary Probenraum
    Login(Passwort eingeben)
    Book(Raum buchen)
    Release(Buchung freigeben)
    Save(Buchung speichern)
    Lock(Raum sperren)
    Suggest(Ersatztermin vorschlagen)
    Button(Button Stornieren klicken)
  end
  Bandmitglied --> Book
  Bandmitglied --> Button
  HerrWagner --> Lock
  HerrWagner --> Release
  Book --> Datenbank
  Login --include--> Book
  Book --extend--> Suggest
  Save --include--> Book

Dafür brauchst du:

Kapitel 08 UML I – Use-Case-Diagramm (Prüffrage für Anwendungsfälle, Verb und Objekt, Akteure als Rollen, include und extend, Beschreibung eines Anwendungsfalls).
Kapitel 04 bis 07 für Backlog, Sprint-Planning, Board und Git-Workflow light.
Euer Jahresprojekt aus Aufgabe 03. Diagramme zeichnest du mit Mermaid (usecase-beta ab Mermaid 12), draw.io oder als gut lesbare Handskizze.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
Abgegeben wird dein Projektordner mit einer README.md: darin die Kata und die Links auf die Issues, Merge Requests und Dateien dieser Woche im Jahresprojekt-Repository. Projektartefakte liegen im Repository des Teams, Diagramme als Mermaid-Quelltext oder draw.io-Datei unter docs/uml/.
Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07). Ein Beitrag ohne eigene Spur im Repository zählt nicht als dein Beitrag.

Wesentlich_überwiegend

Aufgabe

Kata: Beurteile das Diagramm der Probenraum-Buchung gegen die Anforderungen und die Regeln aus Kapitel 08. Liste mindestens fünf Fehler oder Lücken auf und begründe jeden in einem Satz (Prüffrage, Verb und Objekt, Rolle statt Person oder Technik, Pfeilrichtung, fehlender Anwendungsfall).
Zeichne das korrigierte Diagramm mit mindestens einem include und einem extend und begründe für beide in einem Satz, warum es genau diese Beziehung ist.
Sprint 1 planen: Habt ihr Sprint 1 in Aufgabe 03 schon geplant, überprüft die Planung, sonst holt ihr sie jetzt nach. Legt den Milestone Sprint 1 mit Start- und Enddatum (drei Wochen, Review in der dritten Einheit) an, formuliert das Sprint-Ziel als einen Satz, der einen Zustand des Produkts beschreibt, und zieht die Stories für Sprint 1 in den Milestone. Ihre Summe an Story Points ist bewusst klein, weil eure Velocity noch unbekannt ist.

Tipp: Frag bei jedem Oval der Kata: Hat der Akteur danach etwas erreicht, wofür er das System überhaupt geöffnet hat? Bei extend zeigt der Pfeil von der Erweiterung zum erweiterten Anwendungsfall, bei include vom Basisfall zum immer ausgeführten Teil. Ein Sprint-Ziel lässt sich am Sprintende mit „erreicht“ oder „nicht erreicht“ beantworten.

Bewertungskriterien

Vollständig, wenn:

mindestens fünf Fehler oder Lücken gefunden und je mit einem Satz begründet sind, darunter die Person als Akteur, die Datenbank als Akteur, mindestens ein Bedienschritt als Anwendungsfall und mindestens eine falsche Pfeilrichtung,
das korrigierte Diagramm alle Anforderungen abdeckt, Akteure als Rollen zeigt und include und extend in richtiger Richtung mit Begründung enthält,
der Milestone Sprint 1 mit Daten existiert, das Sprint-Ziel ein Satz über einen Zustand des Produkts ist und die gezogenen Stories im Milestone liegen.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Zeichnet das Use-Case-Diagramm eures Jahresprojekts in docs/uml/use-cases.md: Systemgrenze, alle Rollen, mindestens fünf Anwendungsfälle, die die Prüffrage bestehen, und mindestens ein include oder extend mit Begründung. Legt dafür ein Issue an und bringt das Diagramm über einen Merge Request mit Review nach dev.
Beschreibt den wichtigsten Anwendungsfall (den, an dem euer Sprint-Ziel hängt) mit Akteuren, Vorbedingung, nummeriertem Standardablauf, mindestens einem Alternativablauf und Nachbedingung.
Legt das Diagramm neben euer Backlog: Ordnet jeder Story einen Anwendungsfall zu. Notiert Anwendungsfälle ohne Story und Stories ohne Anwendungsfall und entscheidet jeweils, ob das Backlog oder das Diagramm unvollständig ist. Korrigiert das Unvollständige (neue Story als Issue oder Ergänzung im Diagramm).

Tipp: Mehrere Stories gehören oft zu einem Anwendungsfall. Eine Story ohne Anwendungsfall ist nicht automatisch falsch, sie kann auch ein technischer Task sein. Die Beschreibung macht den Anwendungsfall, das Oval ist nur das Inhaltsverzeichnis.

Bewertungskriterien

Vollständig, wenn:

das Diagramm zum eigenen Projekt gehört, mindestens fünf Anwendungsfälle hat, die Prüffrage besteht und über einen Merge Request mit Review gemergt ist,
die Beschreibung Vorbedingung, nummerierten Standardablauf, mindestens einen Alternativablauf und Nachbedingung enthält,
die Zuordnung Story zu Anwendungsfall dokumentiert ist und jede Lücke mit Entscheidung und Korrektur versehen ist.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Leite aus jedem Alternativablauf deiner Beschreibung mindestens ein Akzeptanzkriterium im Schema Gegeben/Wenn/Dann ab (Kapitel 04) und ergänze es im Issue der passenden Story von Sprint 1.
Prüfe jede Story von Sprint 1: Hat sie Akzeptanzkriterien für Normalfall und Ausnahme? Ergänze fehlende und halte im README.md fest, welche Ausnahme euch ohne die Beschreibung entgangen wäre.

Tipp: Kapitel 08 nennt, was aus einer Beschreibung folgt: Der Standardablauf wird später zum Sequenzdiagramm, die Alternativabläufe zu Testfällen, Vor- und Nachbedingung zum Abnahmetest.

Bewertungskriterien

Vollständig, wenn:

jeder Alternativablauf mindestens ein Akzeptanzkriterium in Gegeben/Wenn/Dann ergeben hat und dieses im Issue der passenden Story steht,
jede Story von Sprint 1 Akzeptanzkriterien für Normalfall und Ausnahme hat und eine konkrete, sonst übersehene Ausnahme benannt ist.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Formuliere aus Vor- und Nachbedingung des wichtigsten Anwendungsfalls einen Abnahmetest für das Review von Sprint 1: Ausgangszustand, Schritte, die die Lehrkraft im Review vorführt bekommt, und das beobachtbare Ergebnis. Lege ihn in docs/ ab und verlinke ihn im Issue der Story.
Entscheide für euer Use-Case-Diagramm und die Beschreibung, ob sie Skizze oder Bauplan sind, und begründe es in zwei bis drei Sätzen mit eurer Teamgröße, dem Stakeholder und der Lebensdauer des Projekts. Folgt daraus eine Pflicht, das Diagramm aktuell zu halten, schreibe sie als Vorschlag für eine Zeile der Definition of Done auf.

Tipp: Ein Abnahmetest prüft, was der Stakeholder sieht, nicht wie es im Code gelöst ist. Kapitel 08 beschreibt drei Lagen (Skript, Jahresprojekt, Übergabe) mit unterschiedlicher Antwort.

Bewertungskriterien

Vollständig, wenn:

der Abnahmetest Ausgangszustand, vorführbare Schritte und ein beobachtbares Ergebnis enthält, aus Vor- und Nachbedingung folgt und in der Story verlinkt ist,
die Entscheidung Skizze oder Bauplan mit Bezug auf das eigene Projekt begründet ist und eine daraus folgende Pflege-Regel prüfbar formuliert ist.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 15 min Kata, 20 min Planning, 30 min Use Cases im Projekt)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules