Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-10-09T19:21:07Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}

{{BR}}
= Einleitung =

'''Anwendungsentwicklung und Softwarequalität – Anforderungen als Nutzungsfälle erfassen'''

'''Zielgruppe:''' Ausbildung Fachinformatiker/in Anwendungsentwicklung und verwandte IT-Berufe

'''Lernziel:''' Du kannst Rollen und fachliche Ziele erkennen, Nutzungsfälle beschreiben und überprüfbare Ergebnisse mit Akzeptanztests nachweisen.

'''Ausbildungsfall:''' Eine fiktive Lernwerkstatt benötigt eine Anwendung zur Reservierung von Werkzeugen.

[[Datei:UML Use Case diagram.svg|500px|rahmenlos|center]]

''Bildimpuls: Welche Elemente zeigen Rollen, Systemgrenzen und fachliche Ziele?''

{{BR}}
== Dein Lernpfad ==

{| class="wikitable"
! Einheit
! Schwerpunkt
! Zeit
|-
| A
| Rollen und Systemgrenzen
| 8 Minuten
|-
| B
| Nutzungsfälle und Ziele
| 10 Minuten
|-
n| C
| Szenarien und Ergebnisse
| 12 Minuten
|-
| D
| Akzeptanzkriterien und Qualität
| 12 Minuten
|-
| E
| Lokales Python-Testlabor
| 15 Minuten
|-
| F
| Erweiterungen und Transfer
| 10 Minuten
|}

'''Arbeitsregel:''' Verwende ausschließlich fiktive Daten und eigene lokale Übungsdateien. Die Codebeispiele benötigen keine Netzwerkverbindung, keine Zugangsdaten und keine fremden Systeme. Sie dürfen nicht ungefragt mit Produktivanlagen oder Kundendaten verbunden werden.

Externe Videos, Wikipedia und LearningApps sind optionale Online-Lernmedien. Ihre Einbettung kann Verbindungen zu Drittanbietern herstellen. Nutze sie nur, wenn dies für Deine Lernumgebung freigegeben ist. Die Programmierübungen funktionieren offline.

{{BR}}
= Ausbildungsfall: Die Lernwerkstatt =

Die fiktive '''Lernwerkstatt Nord''' möchte Werkzeuge digital reservieren.

{| class="wikitable"
! Rolle
! Fachliches Ziel
! Beobachtbares Ergebnis
|-
| Auszubildende Person
| Gerät reservieren
| Reservierung wird bestätigt
|-
| Werkstattverwaltung
| Gerätebestand pflegen
| Bestand ist aktualisiert
|-
| Auszubildende Person
| Eigene Reservierung prüfen
| Reservierungsstatus wird angezeigt
|}

'''Leitfrage:''' Was muss die Anwendung für welche Rolle leisten, und woran erkennst Du, dass das Ziel erreicht wurde?

Die Reservierung wird vollständig als Übungsprototyp umgesetzt. Die anderen Nutzungsfälle dienen zunächst als Modellierungsaufgaben.

{{BR}}
= Lerneinheit A: Rollen und Systemgrenzen =

{{BR}}
== Was ist ein Akteur? ==

Ein [[Akteur (UML)|Akteur]] bezeichnet eine '''Rolle außerhalb des betrachteten Systems'''. Eine Person kann mehrere Rollen übernehmen. Auch ein externes System kann Akteur sein.

[[Datei:Uml-UseCase-Akteur.svg|250px|rahmenlos|center]]

'''Merksatz:''' Beschreibe Rollen statt konkreter Personen.

{| class="wikitable"
! Weniger geeignet
! Besser
|-
| Mila Müller
| Auszubildende Person
|-
| Herr Schneider
| Werkstattverwaltung
|-
| Der Computer
| Externer Geräteverwaltungsdienst, falls tatsächlich beteiligt
|}

{{BR}}
== Was gehört zum System? ==

Die [[Systemgrenze]] trennt das betrachtete System von seiner Umgebung.

[[Datei:Uml-UseCase-Beispiel1.svg|500px|rahmenlos|center]]

'''Mini-Aufgabe:''' Entscheide, ob die Auszubildendenrolle innerhalb oder außerhalb der Systemgrenze liegt.

'''Feedback:''' Die Rolle liegt außerhalb. Sie interagiert mit der Anwendung, ist aber nicht selbst Teil des Softwaresystems.

{{BR}}
= Lerneinheit B: Fachliche Ziele als Nutzungsfälle =

Ein [[Anwendungsfall|Nutzungsfall beziehungsweise Use Case]] beschreibt ein von außen sichtbares Systemverhalten, das für mindestens einen Akteur ein sinnvolles Ergebnis liefert.

[[Datei:Uml-UseCase-Anwendungsfall.svg|350px|rahmenlos|center]]

{| class="wikitable"
! Zu technisch oder zu klein
! Fachliches Ziel
|-
| Auf Schaltfläche klicken
| Werkzeug reservieren
|-
| Textfeld ausfüllen
| Reservierung suchen
|-
| Datenbankzeile anlegen
| Gerätebestand verwalten
|}

Ein [[Anwendungsfalldiagramm]] zeigt Akteure, Nutzungsfälle und Beziehungen. Es beschreibt '''nicht''' die zeitliche Reihenfolge der Verarbeitungsschritte.

{{#ev:youtube| https://www.youtube.com/watch?v=eQoC4GDzYbI |500|center}}

'''Videolernauftrag:''' Stefan Macke erklärt das UML-Anwendungsfalldiagramm für IT-Ausbildungsberufe. Beachte besonders die Abschnitte zu Systemkontext, Akteuren und Anwendungsfällen ab etwa Minute 2:33. Die weiterführenden Beziehungen werden später benötigt.

{{BR}}
== Modellskizze für unseren Ausbildungsfall ==

<pre>
Auszubildende Person
|
v
+--------------------------------+
| Lernwerkstatt-System |
| |
| (Gerät reservieren) |
| (Reservierung prüfen) |
| (Gerätebestand pflegen) |
| |
+--------------------------------+
^
|
Werkstattverwaltung
</pre>

''Didaktische Skizze, kein vollständig normgerechtes UML-Diagramm. Die Rolle Werkstattverwaltung ist fachlich dem Nutzungsfall Gerätebestand pflegen zugeordnet.''

'''Deine Aufgabe:''' Zeichne daraus ein UML-Anwendungsfalldiagramm mit passenden Assoziationen und einer klaren Systemgrenze.

{{BR}}
= Lerneinheit C: Nutzungsfälle präzise beschreiben =

Für einen Nutzungsfall genügen nicht allein ein Titel und eine Ellipse. Ein prüfbares Modell braucht Ausgangslage, Auslöser, Ablauf und Ergebnis.

{{BR}}
== UC-01: Gerät reservieren ==

{| class="wikitable"
! Merkmal
! Beschreibung
|-
| ID
| UC-01
|-
| Name
| Gerät reservieren
|-
| Primärer Akteur
| Auszubildende Person
|-
| Ziel
| Ein verfügbares Gerät reservieren
|-
| Auslöser
| Die Rolle fordert eine Reservierung an
|-
| Vorbedingung
| Eine fiktive Nutzerkennung ist vorhanden; die Geräteauswahl kann erfolgen
|-
| Hauptablauf
| Gerät auswählen, Verfügbarkeit prüfen, Reservierung speichern, Ergebnis zurückgeben
|-
| Erfolgsnachbedingung
| Das Gerät ist im Übungsspeicher der Nutzerkennung zugeordnet
|-
| Alternative
| Bereits reserviertes Gerät wird abgewiesen
|-
| Ausnahme
| Eine unbekannte Gerätekennung wird zurückgewiesen
|}

{{BR}}
== Hauptablauf und Alternativen ==

{| class="wikitable"
! Situation
! Systemreaktion
! Ergebnis
|-
| Bekanntes, freies Gerät
| Reservierung eintragen
| BESTAETIGT
|-
| Bekanntes, belegtes Gerät
| Keine Änderung vornehmen
| BELEGT
|-
| Unbekanntes Gerät
| Keine Änderung vornehmen
| UNBEKANNT
|}

'''Mini-Aufgabe:''' Warum darf ein belegtes Werkzeug nicht nochmals reserviert werden?

'''Feedback:''' Zwei gleichzeitig gültige Reservierungen für dasselbe Gerät würden die festgelegte Geschäftsregel verletzen. Die Ablehnung verhindert einen widersprüchlichen Zustand.

{{BR}}
= Lerneinheit D: Überprüfbare Ergebnisse und Softwarequalität =

Eine gute [[Anforderung (Informatik)|Anforderung]] ist hinreichend eindeutig, nachvollziehbar, konsistent und überprüfbar.

[[Akzeptanzkriterium|Akzeptanzkriterien]] übersetzen fachliche Erwartungen in beobachtbare Bedingungen.

{{BR}}
== Gegeben – Wenn – Dann ==

'''Gegeben:''' Das Gerät W01 existiert und ist frei.

'''Wenn:''' AZUBI_A das Gerät W01 reserviert.

'''Dann:''' Das System liefert BESTAETIGT und speichert die Zuordnung W01 zu AZUBI_A.

Dieses Schema beschreibt den Startzustand, das Ereignis und das erwartete Ergebnis.

{{BR}}
== Akzeptanzmatrix ==

{| class="wikitable"
! Kennung
! Ausgangszustand und Aktion
! Erwarteter Nachweis
|-
| AK1
| W01 frei, AZUBI_A reserviert
| BESTAETIGT und gespeicherte Zuordnung
|-
| AK2
| W01 belegt, AZUBI_B reserviert W01
| BELEGT und keine Zustandsänderung
|-
| AK3
| W99 unbekannt, Reservierung angefordert
| UNBEKANNT und keine Zustandsänderung
|-
| AK4
| W01 und W02 frei, zwei Reservierungen
| Zwei Bestätigungen und zwei gespeicherte Zuordnungen
|}

'''Qualitätsziel des Übungsprototyps:''' Alle vier beschriebenen automatisierten Akzeptanzbeispiele sollen erfolgreich ausgeführt werden. Das bedeutet nicht, dass damit eine vollständige Produktfreigabe oder vollständige Testabdeckung erreicht ist.

Zur [[Softwarequalität]] gehören neben der funktionalen Eignung weitere Merkmale. Die Norm [[ISO/IEC 25010]] beschreibt ein Modell für Software- und ICT-Produktqualität. Für unseren Prototyp sind insbesondere funktionale Korrektheit, Zuverlässigkeit der Ergebnisse und Schutz der Übungsdaten relevant.

{{BR}}
== Testdaten visualisieren ==

'''Fiktive Beispieldaten:''' zwölf angenommene Reservierungsversuche für eine spätere Auswertung. Diese Häufigkeiten sind keine Messung der vier automatisierten Tests.

{| class="wikitable"
! Ergebnis
! Anzahl
! Balken
|-
| BESTAETIGT
| 7
| ███████
|-
| BELEGT
| 3
| ███
|-
| UNBEKANNT
| 2
| ██
|-
| '''Summe'''
| '''12'''
| '''████████████'''
|}

'''Auswertung:''' Sieben von zwölf Anfragen waren erfolgreich. Die übrigen fünf Anfragen benötigen eine fachlich definierte Rückmeldung. Eine Ablehnung kann korrektes Verhalten sein und ist nicht automatisch ein Softwarefehler.

{{BR}}
= Lerneinheit E: Lokales Python-Testlabor =

Jetzt verbindest Du den Nutzungsfall mit überprüfbarem Programmverhalten.

'''Voraussetzung:''' Lokal installiertes Python 3 und ein selbst angelegter Übungsordner. Es werden nur die Python-Standardbibliothek und fiktive Kennungen verwendet.

'''Sicherheitsrahmen:''' Keine Webanfragen, keine Datenbank, keine Zugangsdaten, keine echten Namen und keine Verbindung zu Produktivsystemen. Die Reservierungen bleiben im Arbeitsspeicher und werden beim Beenden verworfen.

{{BR}}
== Codebeispiel 1: Interaktive Werkzeugreservierung ==

Speichere den folgenden vollständigen Code als '''werkstatt.py'''.

<pre>
"""Lokale Lernwerkstatt: nur fiktive Kennungen und RAM."""
GERAETE = {"W01": "Akkuschrauber", "W02": "Multimeter"}

def reservieren(person, geraet, belegt):
"""Ergebnis ohne Netz- oder Datenbankzugriff."""
if geraet not in GERAETE:
return "UNBEKANNT"
if geraet in belegt:
return "BELEGT"
belegt[geraet] = person
return "BESTAETIGT"

if __name__ == "__main__":
belegung = {}
print("Übungsmodus: W01 oder W02; X beendet.")
while True:
geraet = input("Gerätekennung: ").strip().upper()
if geraet == "X":
break
print("Ergebnis:",
reservieren("AZUBI_A", geraet, belegung))
print("RAM-Zustand:", belegung)
</pre>

'''Lokal starten:'''

<pre>
python werkstatt.py
</pre>

Falls Dein System Python über den Befehl <code>python3</code> startet, verwende stattdessen diesen Befehl.

'''Probiere nacheinander:''' W01, W01, W99, W02 und X.

{| class="wikitable"
! Eingabe
! Erwartete Ausgabe
|-
| W01
| BESTAETIGT
|-
| W01
| BELEGT
|-
| W99
| UNBEKANNT
|-
| W02
| BESTAETIGT
|-
| X
| Ende der Eingabe
|}

'''Begründetes Feedback:''' Der zweite Versuch mit W01 muss BELEGT liefern, weil die erste Reservierung noch im Speicher steht. W99 ist nicht im fiktiven Gerätekatalog enthalten. W02 bleibt unabhängig von W01 reservierbar.

{{BR}}
== Codebeispiel 2: Isolierte automatisierte Tests ==

Speichere die folgende Datei als '''test_werkstatt.py''' im selben lokalen Ordner.

<pre>
import unittest
from werkstatt import reservieren

class ReservierungTest(unittest.TestCase):
def setUp(self):
self.belegt = {} # jeder Test beginnt isoliert

def test_ak1_erfolg(self):
self.assertEqual(
reservieren("AZUBI_A", "W01", self.belegt),
"BESTAETIGT")
self.assertEqual(self.belegt["W01"], "AZUBI_A")

def test_ak2_belegt(self):
self.belegt["W01"] = "AZUBI_A"
self.assertEqual(
reservieren("AZUBI_B", "W01", self.belegt),
"BELEGT")
self.assertEqual(
self.belegt, {"W01": "AZUBI_A"})

def test_ak3_unbekannt(self):
self.assertEqual(
reservieren("AZUBI_A", "W99", self.belegt),
"UNBEKANNT")
self.assertEqual(self.belegt, {})

def test_ak4_zwei_geraete(self):
self.assertEqual(
reservieren("AZUBI_A", "W01", self.belegt),
"BESTAETIGT")
self.assertEqual(
reservieren("AZUBI_B", "W02", self.belegt),
"BESTAETIGT")
self.assertEqual(len(self.belegt), 2)

if __name__ == "__main__":
unittest.main()
</pre>

'''Testaufruf im lokalen Übungsordner:'''

<pre>
python -m unittest -v
</pre>

Die Testdatei wird anhand ihres Dateinamens erkannt. Bei korrekter unveränderter Übernahme werden vier erfolgreiche Tests erwartet.

'''Warum ist das isoliert?''' Die Methode <code>setUp</code> erzeugt für jeden Test einen eigenen leeren Speicherzustand. Damit beeinflussen die Reservierungen eines Tests nicht die anderen Tests.

{{#ev:youtube| https://www.youtube.com/watch?v=n4YPBuTkXYw |500|center}}

''Video: Einführung in Python-Unittests von Datamics.''

{{#ev:youtube| https://www.youtube.com/watch?v=ZQD4M3jSA1s |500|center}}

''Video: Kurzdemo des Python-Unittest-Frameworks von Stefan Helmert.''

{{BR}}
== Grenzen des Prototyps ==

Der Prototyp überprüft weder eine reale Identität noch Berechtigungen. Auch gleichzeitige Zugriffe, dauerhafte Speicherung und eine Benutzeroberfläche sind nicht implementiert. Diese Punkte benötigen bei einer echten Anwendung zusätzliche Anforderungen und Tests.

'''Mini-Experiment:''' Ändere in einer lokalen Kopie bei belegten Geräten den Rückgabewert von BELEGT zu BESTAETIGT. Führe die Tests erneut aus und mache die Änderung anschließend rückgängig.

'''Feedback:''' Der Test zu AK2 muss fehlschlagen. Damit wird erkennbar, dass automatisierte Prüfungen eine konkrete Abweichung zwischen Erwartung und Implementierung anzeigen können.

{{BR}}
= Lerneinheit F: Beziehungen und Transfer =

Zusammenhänge zwischen Nutzungsfällen können in UML zusätzlich modelliert werden.

{{BR}}
== Include und Extend ==

[[Datei:Uml-UseCase-Include.svg|500px|rahmenlos|center]]

'''include:''' Ein Nutzungsfall bindet das Verhalten eines anderen Nutzungsfalls als verpflichtenden Bestandteil ein.

[[Datei:Uml-UseCase-Extend.svg|500px|rahmenlos|center]]

'''extend:''' Ein Nutzungsfall ergänzt einen anderen unter festgelegten Bedingungen um optionales Verhalten.

'''Wichtig:''' Verwende diese Beziehungen nur, wenn die fachlichen Voraussetzungen erfüllt sind. Nicht jede gemeinsame Programmanweisung ist ein eigener Nutzungsfall.

[[Datei:Uml-UseCase-Generalisierung2.svg|350px|rahmenlos|center]]

''Zusatz: Auch Akteure können durch Generalisierung in Beziehung stehen. Prüfe dabei, ob tatsächlich eine sinnvolle Rollenverallgemeinerung vorliegt.''

{{BR}}
== Ein weiteres Modell betrachten ==

[[Datei:Se-lib course portal use case diagram.svg|500px|rahmenlos|center]]

'''Transferfrage:''' Welche externen Rollen und fachlichen Ziele lassen sich in diesem Diagramm erkennen? Wie würdest Du für einen Nutzungsfall ein überprüfbares Ergebnis formulieren?

'''Feedback:''' Ein gutes Ergebnis nennt einen von außen beobachtbaren Zustand und nicht nur eine technische Funktion oder einen Klick.

{{BR}}
= Gestufte Lernhilfen =

{| class="wikitable"
! Stufe
! Hilfe
! Beispiel
|-
| '''Hilfe 1: Impuls'''
| Frage nach Rolle und Nutzen.
| Wer braucht welches Ergebnis?
|-
| '''Hilfe 2: Gerüst'''
| Nutze eine feste Satzstruktur.
| Als Rolle möchte ich Ziel, damit Nutzen entsteht.
|-
| '''Hilfe 3: Muster'''
| Vergleiche mit einem prüfbaren Beispiel.
| Als Auszubildende Person möchte ich W01 reservieren, damit ich das Gerät später nutzen kann.
|}

'''Für Tests:'''

{| class="wikitable"
! Stufe
! Vorgehen
|-
| Impuls
| Welchen Zustand hat das System vor der Aktion?
|-
| Gerüst
| Formuliere Gegeben – Wenn – Dann.
|-
| Muster
| W01 frei, AZUBI_A reserviert, Ergebnis BESTAETIGT und gespeicherte Zuordnung.
|}

{{BR}}
= Interaktive Aufgaben =

{{BR}}
== Quiz: Teste Dein Wissen ==

{{MC}}

'''Was bezeichnet ein Akteur im UML-Nutzungsfallmodell?'''
(Eine externe Rolle, die mit dem System interagiert)
(!Eine Datenbanktabelle)
(!Eine Programmiersprache)
(!Eine beliebige interne Methode)

{{E}}
<br>

{{MC}}

'''Welche Aufgabe hat die Systemgrenze?'''
(Sie trennt das betrachtete System von seiner Umgebung)
(!Sie bestimmt die Bildschirmauflösung)
(!Sie legt die Anzahl der Programmiersprachen fest)
(!Sie speichert die Benutzerkennungen)

{{E}}
<br>

{{MC}}

'''Welches Beispiel beschreibt ein fachliches Ziel?'''
(Gerät reservieren)
(!Schaltfläche anklicken)
(!Variable deklarieren)
(!Schriftfarbe ändern)

{{E}}
<br>

{{MC}}

'''Was zeigt ein Anwendungsfalldiagramm normalerweise nicht?'''
(Die genaue zeitliche Reihenfolge aller Verarbeitungsschritte)
(!Die beteiligten Akteure)
(!Die Namen der Nutzungsfälle)
(!Die Beziehungen zwischen Akteuren und Nutzungsfällen)

{{E}}
<br>

{{MC}}

'''Was gehört zur erfolgreichen Nachbedingung von UC-01?'''
(Das Gerät ist der fiktiven Nutzerkennung zugeordnet)
(!Die gesamte Anwendung wird gelöscht)
(!Das Gerät wird automatisch beschädigt)
(!Die Systemgrenze verschwindet)

{{E}}
<br>

{{MC}}

'''Welches Ergebnis ist für ein bereits reserviertes Gerät vorgesehen?'''
(BELEGT)
(!UNBEKANNT)
(!BESTAETIGT)
(!NEUSTART)

{{E}}
<br>

{{MC}}

'''Was beschreibt der Dann-Teil eines Akzeptanzkriteriums?'''
(Das erwartete beobachtbare Ergebnis)
(!Nur den Namen der entwickelnden Person)
(!Nur die installierte Python-Version)
(!Eine beliebige grafische Gestaltung)

{{E}}
<br>

{{MC}}

'''Welche Anforderung ist am besten überprüfbar?'''
(Eine zweite Reservierung desselben Geräts wird mit BELEGT abgewiesen)
(!Die Anwendung soll irgendwie modern sein)
(!Die Reservierung soll sich besonders gut anfühlen)
(!Das System soll möglichst schön funktionieren)

{{E}}
<br>

{{MC}}

'''Warum wird im Test vor jedem Testfall ein leerer Speicher angelegt?'''
(Damit sich die Testfälle gegenseitig nicht beeinflussen)
(!Damit alle Reservierungen dauerhaft erhalten bleiben)
(!Damit ein fremder Server gestartet wird)
(!Damit vorhandene Kundendaten überschrieben werden)

{{E}}
<br>

{{MC}}

'''Welche Testumgebung ist für diesen Kurs vorgesehen?'''
(Ein eigener lokaler Übungsordner mit fiktiven Daten)
(!Ein fremder Produktionsserver ohne Zustimmung)
(!Eine Kundendatenbank mit echten Personendaten)
(!Ein öffentlich erreichbares System mit unbekannter Berechtigung)

{{E}}
<br>

{{BR}}
== Memory ==

Finde die zusammengehörenden Fachbegriffe und Erklärungen.

<div class="memo-quiz">
{|
|-
| Akteur || Externe Rolle mit Systeminteraktion
|-
| Systemgrenze || Trennung von System und Umgebung
|-
| Nutzungsfall || Fachliches Ziel mit beobachtbarem Ergebnis
|-
| Vorbedingung || Erforderlicher Ausgangszustand
|-
| Nachbedingung || Überprüfbarer Endzustand
|-
| Alternativablauf || Abweichender fachlich definierter Verlauf
|-
| Akzeptanzkriterium || Bedingung für die fachliche Annahme
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

Ordne die Begriffe den Beschreibungen zu.

<div class="lueckentext-quiz">

{| class="wikitable"
! Ordne die richtigen Begriffe zu.
! Thema
|-
| '''Auszubildende Person'''
| Reservierung anfordern
|-
| '''Werkstattverwaltung'''
| Gerätebestand verwalten
|-
| '''Systemgrenze'''
| Innen und außen unterscheiden
|-
| '''Nachbedingung'''
| Gespeicherte Zuordnung nachweisen
|-
| '''Alternativablauf'''
| Bereits belegtes Gerät behandeln
|-
| '''Akzeptanztest'''
| Erwartetes Verhalten überprüfen
|}
{{E}}

<br>

{{BR}}
== Kreuzworträtsel ==

<div class="kreuzwort-quiz">
{|
|-
| AKTEUR || Wie heißt eine externe Rolle im UML-Modell?
|-
| SYSTEMGRENZE || Welches Modellelement trennt das betrachtete System von seiner Umgebung?
|-
| SZENARIO || Wie nennt man eine konkrete Abfolge von Interaktionen innerhalb eines Nutzungsfalls?
|-
| VORBEDINGUNG || Wie heißt ein notwendiger Ausgangszustand für einen Ablauf?
|-
| NACHBEDINGUNG || Wie heißt ein überprüfbarer Zustand nach einem Ablauf?
|-
| RESERVIERUNG || Wie heißt die Zuordnung eines Geräts zu einer Person in unserem Ausbildungsfall?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

Weitere Übungen kannst Du über die thematische Suche von LearningApps finden. Es handelt sich um einen externen Online-Dienst; nutze ihn nur bei freigegebenem Internetzugang.

<iframe> https://learningapps.org/index.php?s=Anwendungsentwicklung+und+Softwarequalität+-+Anforderungen+als+Nutzungsfälle+erfassen </iframe>

{{BR}}
== Lückentext ==

<quiz display=simple>
{'''Vervollständige den Text.'''<br>
|type="{}"}
Ein Akteur bezeichnet eine { Rolle } außerhalb des betrachteten Systems.

Die Trennung zwischen System und Umgebung heißt { Systemgrenze }.

Ein Nutzungsfall verfolgt ein fachliches { Ziel }.

Ein Nutzungsfall wird in einem UML-Anwendungsfalldiagramm gewöhnlich durch eine { Ellipse } dargestellt.

Ein notwendiger Ausgangszustand heißt { Vorbedingung }.

Der erfolgreiche Standardverlauf wird als { Hauptablauf } beschrieben.

Ein abweichender Verlauf wird als { Alternativablauf } dokumentiert.

Ein überprüfbarer Zustand nach der Durchführung heißt { Nachbedingung }.

Für die fachliche Überprüfung werden { Akzeptanzkriterien } formuliert.

Eine erfolgreiche Reservierung liefert im lokalen Prototyp den Status { BESTAETIGT }.

Eine bereits bestehende Reservierung führt zur Rückmeldung { BELEGT }.

Das verwendete Python-Testframework heißt { unittest }.

Die praktischen Übungen werden mit fiktiven Daten { lokal } ausgeführt.
</quiz>

<br>

{{BR}}
= Offene Aufgaben =

Bearbeite die Aufgaben in Deinem eigenen lokalen Übungsbereich. Erstelle ausschließlich fiktive Beispiele.

{{BR}}
=== Leicht – Basisaufgaben ===

# [[Akteur (UML)|Rollen erkennen]]: Benenne die beiden Rollen aus der Lernwerkstatt und erkläre ihren jeweiligen Nutzen.
# [[Anwendungsfall|Ziele formulieren]]: Formuliere drei fachliche Ziele für die Lernwerkstatt.
# [[Systemgrenze|System abgrenzen]]: Zeichne die Grenze zwischen Rollen und Anwendung.
# [[Anforderung (Informatik)|Anforderungen unterscheiden]]: Formuliere fünf Aussagen und ordne sie als fachliches Ziel, technische Lösung oder Qualitätsanforderung ein.

{{BR}}
=== Standard – Anwendungsaufgaben ===

# [[Anwendungsfall|UC-01 dokumentieren]]: Erstelle eine vollständige Nutzungsfallbeschreibung mit Vorbedingung, Hauptablauf und Alternativen.
# [[Akzeptanztest|Akzeptanztests entwerfen]]: Schreibe drei Gegeben-Wenn-Dann-Szenarien und begründe die erwarteten Ergebnisse.
# [[Python (Programmiersprache)|Code variieren]]: Führe das lokale Python-Beispiel aus und untersuche die Ergebnisse verschiedener fiktiver Gerätekennungen.
# [[Softwaretest|Testbericht erstellen]]: Dokumentiere die vier automatisierten Tests, ihre Erwartungen und die beobachteten Resultate in einer Tabelle.

{{BR}}
=== Schwer – Transferaufgaben ===

# [[Geschäftsregel|Neue Regel entwickeln]]: Entwirf eine Begrenzung auf höchstens zwei gleichzeitige Reservierungen pro fiktiver Nutzerkennung und ergänze geeignete lokale Tests.
# [[Anwendungsfalldiagramm|Neuen Nutzungsfall modellieren]]: Ergänze Gerät stornieren mit eigenen Vorbedingungen, Erfolgsnachbedingungen und mindestens zwei Ausnahmefällen.
# [[Softwarequalität|Qualitätsreview durchführen]]: Untersuche den Prototyp bezüglich Rollenprüfung, gleichzeitiger Zugriffe und Datenspeicherung und leite überprüfbare zusätzliche Anforderungen ab.
# [[Requirements Engineering|Fiktives Anforderungsinterview]]: Führe ein Rollenspiel zwischen Werkstattverwaltung und Entwicklungsteam durch und dokumentiere offene Fragen, Annahmen und überprüfbare Ergebnisse.

{{BR}}
== Begründetes Feedback zu den Aufgaben ==

{| class="wikitable"
! Kompetenzstufe
! Gutes Ergebnis
! Überarbeiten, wenn ...
|-
| Basis
| Rolle und fachliches Ziel sind klar getrennt.
| Nur konkrete Personen oder Schaltflächen beschrieben werden, weil dadurch der fachliche Nutzen unklar bleibt.
|-
| Anwendung
| Ausgangszustand, Aktion und erwartetes Ergebnis sind widerspruchsfrei und testbar.
| Eine erwartete Zustandsänderung fehlt, weil der Test dann ein falsches Systemverhalten übersehen könnte.
|-
| Transfer
| Neue Geschäftsregeln sind begründet, berücksichtigen Fehlerfälle und besitzen eigene Prüfnachweise.
| Nur der Erfolgsfall behandelt wird, weil widersprüchliche Zustände oder unzulässige Reservierungen unentdeckt bleiben können.
|}

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =

Bearbeite die folgenden Aufgaben ohne Übertragung von Daten an externe Testdienste.

# [[Anforderungsanalyse|Unklare Anforderung verbessern]]: Die Werkstattleitung verlangt eine schnelle und einfache Reservierung. Erkläre, warum diese Aussage nicht ausreichend prüfbar ist, und formuliere zwei konkrete Qualitätskriterien mit nachvollziehbarer Messmethode.
# [[Anwendungsfall|Ziel und Technik unterscheiden]]: Ein Entwicklerteam dokumentiert Datenbankeintrag anlegen als eigenständigen Nutzungsfall. Bewerte dieses Vorgehen anhand des fachlichen Nutzens und schlage eine bessere Modellierung vor.
# [[Softwaretest|Fehlerfall bewerten]]: Ein bereits belegtes Gerät wird ein zweites Mal bestätigt. Leite aus der fachlichen Regel die erforderliche Reaktion, die betroffenen Akzeptanzkriterien und geeignete Testfälle ab.
# [[Systemgrenze|Systemgrenze verändern]]: Ein externer Reservierungsdienst soll künftig beteiligt werden. Erläutere, wie sich Systemkontext, Akteure, Verantwortlichkeiten und Testanforderungen verändern können.
# [[Softwarequalität|Qualitätsrisiken analysieren]]: Zwei Reservierungsanfragen treffen nahezu gleichzeitig ein. Erkläre, weshalb die bisherigen lokalen Tests dafür nicht ausreichen und welche zusätzlichen Prüfungen in einer autorisierten Testumgebung erforderlich wären.
# [[Anforderungsmanagement|Änderungen nachvollziehen]]: Die Werkstattleitung möchte eine Stornierung ermöglichen. Beschreibe, welche Nutzungsfalltexte, Akzeptanzkriterien, Tests und Dokumentationen angepasst werden müssen.

'''Bewertungshinweis:''' Gute Antworten enthalten jeweils eine fachliche Begründung, ein konkretes Beispiel und einen überprüfbaren Nachweis.

<br>
<br>

{{BR}}
= Lernnachweis =

Für Deinen Lernnachweis erstellst Du ein kompaktes Portfolio zum fiktiven Ausbildungsfall.

# '''Rollenmodell:''' Mindestens zwei Rollen mit ihren fachlichen Zielen.
# '''Systemmodell:''' Ein verständliches Anwendungsfalldiagramm mit abgegrenztem System.
# '''Nutzungsfallbeschreibung:''' UC-01 mit Auslöser, Vorbedingung, Hauptablauf, Alternativen und Nachbedingungen.
# '''Akzeptanzmatrix:''' Mindestens vier nachvollziehbare und überprüfbare Kriterien.
# '''Lokaler Prototyp:''' Lauffähige Python-Dateien mit ausschließlich fiktiven Daten.
# '''Testnachweis:''' Protokoll der vier automatisierten Prüfungen und Erläuterung ihrer Aussagekraft.
# '''Reflexion:''' Mindestens drei Grenzen des Prototyps und passende Vorschläge zur Qualitätssicherung.

'''Beurteilungsmaßstab:''' Fachliche Korrektheit, Prüfbarkeit, Konsistenz zwischen Nutzungsfall und Tests, sichere lokale Durchführung und begründete Transferleistung.

<br>
<br>

{{BR}}
= Fachquellen und Medienrechte =

Die fachliche Darstellung orientiert sich an den folgenden überprüfbaren Quellen:

# '''IREB – Requirements Engineering:''' [https://cpre.ireb.org/de/downloads-and-resources/downloads CPRE Foundation Level – Lehrplan und weiterführende Unterlagen]. Die Unterlagen dienen als fachliche Referenz und werden hier nicht als frei nachnutzbare Volltexte übernommen.
# '''UML:''' [https://de.wikipedia.org/wiki/Anwendungsfall_%28UML%29 Anwendungsfall in der UML] und [https://de.wikipedia.org/wiki/Anwendungsfalldiagramm Anwendungsfalldiagramm].
# '''Offenes Unterrichtsmaterial:''' [https://oer-informatik.de/uml-usecase OER Informatik – UML-Anwendungsfalldiagramme].
# '''Produktqualität:''' [https://www.iso.org/standard/78176.html ISO/IEC 25010:2023]. Die Norm wird als Referenz genannt, ihr urheberrechtlich geschützter Volltext wird nicht reproduziert.
# '''Akzeptanzszenarien:''' [https://agilealliance.org/glossary/given-when-then/ Agile Alliance – Given, When, Then].
# '''Python-Tests:''' [https://docs.python.org/de/3.11/library/unittest.html Offizielle Python-Dokumentation zu unittest].

{{BR}}
== Bildnachweise ==

Die verwendeten Abbildungen sind auf Wikimedia Commons dokumentiert. Sie werden unverändert eingebunden.

'''Stkl – CC BY-SA 3.0:'''

# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Akteur.svg Akteur]
# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Anwendungsfall.svg Anwendungsfall]
# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Beispiel1.svg Anwendungsfallbeispiel]
# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Include.svg Include-Beziehung]
# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Extend.svg Extend-Beziehung]
# [https://commons.wikimedia.org/wiki/File:Uml-UseCase-Generalisierung2.svg Generalisierung von Akteuren]

Lizenz: [https://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0].

'''Slashme – CC BY-SA 4.0:''' [https://commons.wikimedia.org/wiki/File:UML_Use_Case_diagram.svg UML Use Case diagram]. Lizenz: [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0].

'''Mudcap – CC0 1.0:''' [https://commons.wikimedia.org/wiki/File:Se-lib_course_portal_use_case_diagram.svg Se-lib course portal use case diagram]. Lizenz: [https://creativecommons.org/publicdomain/zero/1.0/ CC0 1.0].

Die jeweiligen Commons-Dateiseiten enthalten weitere Angaben zu Entstehung, Quellen und gegebenenfalls ursprünglichen Vorlagen.

{{BR}}
== Videonachweise ==

# '''Stefan Macke:''' UML-Anwendungsfalldiagramm für die IT-Berufe. Verifiziertes YouTube-Video: https://www.youtube.com/watch?v=eQoC4GDzYbI
# '''Datamics:''' Python Tutorial – Code testen mit Unittest. Verifiziertes YouTube-Video: https://www.youtube.com/watch?v=n4YPBuTkXYw
# '''Stefan Helmert:''' Python Unittest Framework Kurzdemo. Verifiziertes YouTube-Video: https://www.youtube.com/watch?v=ZQD4M3jSA1s

Die Videos sind als externe Medien eingebettet. Ihre Einbettung begründet keine freie Lizenz für Kopien, Bearbeitungen oder Weiterverbreitung.

{{BR}}
= OERs zum Thema =

Weiterführende Informationen bietet der Wikipedia-Artikel zum UML-Anwendungsfalldiagramm:

<iframe> https://de.m.wikipedia.org/wiki/Anwendungsfalldiagramm </iframe>

Ergänzend eignet sich das frei zugängliche Lernangebot [https://oer-informatik.de/uml-usecase OER Informatik – UML Use Cases]. Beachte bei jeder Weiterverwendung die konkreten Lizenzangaben der jeweiligen Ressource.

<br>

{{BR}}
= Verknüpfte Lernbereiche =

{| align=center
{{:D-Tab}}
'''[[Anwendungsentwicklung]]'''
# [[Requirements Engineering]]
# [[Anforderungsanalyse]]
# [[Anforderungsmanagement]]
# [[Stakeholder]]
# [[Akteur (UML)]]
# [[Anwendungsfall]]
# [[Anwendungsfalldiagramm]]
# [[Unified Modeling Language]]
# [[Systemgrenze]]
# [[Szenario]]
# [[Akzeptanzkriterium]]
# [[Akzeptanztest]]
# [[Softwaretest]]
# [[Softwarequalität]]
# [[Python (Programmiersprache)]]
# [[Unit-Test]]
|}

[[Kategorie:Informatik]]
[[Kategorie:Softwaretechnik]]
[[Kategorie:Anwendungsentwicklung]]
[[Kategorie:Softwarequalität]]
[[Kategorie:Requirements Engineering]]
[[Kategorie:UML]]
[[Kategorie:Berufsausbildung]]
[[Kategorie:IT-Berufe]]
[[Kategorie:Fachinformatiker Anwendungsentwicklung]]

{{BR}}
= aiMOOC-Projekte =
[[Kategorie:AI_MOOC]] [[Kategorie:GPT aiMOOC]]
{{MT}}

Anwendungsentwicklung und Softwarequalität – Anforderungen als Nutzungsfälle erfassen - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt