Übungsaufgaben zu Vorgehensmodellen

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Vorgehensmodelle“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/vorgehensmodelle
- https://oer-informatik.de/projektorganisation
- https://oer-informatik.de/stakeholderanalyse
- Stilbeispiel: https://oer-informatik.de/vorgehensmodelle-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Vorgehensmodelle
- Scrum
- Kanban
- Wasserfallmodell
- V-Modell
- Verifikation und Validierung
- User Story
- Minimum Viable Product
- Rapid Prototyping
- Projektmanagement

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

2 Punkte für die vollständig richtige Zuordnung (ein Fehler: 1 Punkt), je Gruppe 1 Punkt für die Annahme und 1 Punkt für die Folge, zum Beispiel:

• Klassisch: Wasserfallmodell, V-Modell. Die Modelle gehen davon aus, dass sich die Anforderungen schon zu Beginn vollständig ermitteln lassen und stabil bleiben. Deshalb wird am Anfang das ganze Projekt geplant, und die Phasen folgen nacheinander; jede endet mit einem Dokument, auf dem die nächste aufbaut. Spätere Änderungen sind aufwendig.

• Agil: Kanban, Extreme Programming, Scrum. Diese Modelle gehen davon aus, dass sich Anforderungen ändern und erst an ersten Ergebnissen klar werden. Deshalb wird in kurzen Zyklen (Scrum, XP) oder in einem stetigen Fluss (Kanban) gearbeitet, es entstehen regelmäßig lauffähige Teilergebnisse, und die Anforderungen werden laufend neu priorisiert.

Je Zelle 1 Punkt, zum Beispiel:

1 Punkt für Scrum, je 1 Punkt für zwei passende Textstellen, zum Beispiel:

• Zyklen fester Länge von zwei Wochen („cycles of exactly two weeks“) = Sprints.

• „product owner“ als verantwortliche Person für die geordnete Anforderungsliste (Product Backlog).

• tägliches Treffen der Developers von höchstens 15 Minuten = Daily Scrum.

• „definition of done“ als gemeinsames Qualitätskriterium.

• Treffen mit Stakeholdern am Zyklusende (Sprint Review) und Treffen ohne Gäste zur Verbesserung der Zusammenarbeit (Sprint Retrospective).

Je Rolle 1 Punkt für die Erläuterung, 1 Punkt für die Zuordnung:

• Product Owner (Clara Neumann): verantwortet den Wert des Produkts, pflegt und priorisiert das Product Backlog, spricht mit Stakeholdern und entscheidet, was als Nächstes umgesetzt wird.

• Scrum Master (Sanna Lindqvist, im Text „coach“): sorgt dafür, dass Scrum wirksam umgesetzt wird, beseitigt Hindernisse, schützt das Team vor Störungen und coacht Team und Unternehmen; verteilt keine Aufgaben.

• Developers (das Backend-Team, z. B. Jonas Weber, Du, Anh Nguyen; auch Yusuf Demir, wenn er mitentwickelt): erstellen im Sprint das Increment, planen ihre Arbeit selbst (Sprint Backlog), halten das Daily Scrum ab und sind für die Qualität nach der Definition of Done verantwortlich.

Je Ereignis 1 Punkt für Bezeichnung und richtige Position, 1 Punkt für den Zweck:

1. Sprint Planning (zu Beginn): Das Scrum Team legt das Sprintziel fest, wählt die wertvollsten Einträge aus dem Product Backlog und plant, wie sie umgesetzt werden (Ergebnis: Sprint Backlog).

2. Daily Scrum (jeden Tag, max. 15 Minuten): Die Developers prüfen ihren Fortschritt zum Sprintziel und passen ihren Plan für den nächsten Tag an.

3. Sprint Review (am Ende): Das Scrum Team zeigt den Stakeholdern das Increment; gemeinsam wird besprochen, was als Nächstes kommt, und das Product Backlog wird angepasst.

4. Sprint Retrospective (zum Abschluss, nach dem Review): Das Scrum Team reflektiert seine Zusammenarbeit, Werkzeuge und Qualitätsregeln und vereinbart Verbesserungen für den nächsten Sprint.

Der Sprint selbst ist der Rahmen (zwei Wochen), der alle vier Ereignisse enthält; danach beginnt sofort der nächste Sprint.

Je fehlerhafte Aussage 1 Punkt für das Erkennen, 1 Punkt für die Richtigstellung:

• Aussage 2: Scrum Master ist Sanna Lindqvist. Ein Scrum Master verteilt keine Aufgaben; die Developers organisieren sich selbst und entscheiden gemeinsam, wer was übernimmt. (Ein disziplinarischer Vorgesetzter als Scrum Master wäre zudem ungünstig, weil das die Selbstorganisation behindert.)

• Aussage 3: Das Daily Scrum ist kein Statusbericht an den Product Owner. Es ist ein Treffen der Developers von höchstens 15 Minuten, in dem sie den Fortschritt zum Sprintziel prüfen und den nächsten Tag planen.

• Aussage 5: Sprints haben eine feste Länge und werden nicht verlängert. Nicht fertige Einträge gehen zurück ins Product Backlog und werden neu priorisiert.

• Aussage 6: Die Ergebnisse werden im Sprint Review mit den Stakeholdern besprochen. Die Retrospective findet ohne Gäste statt und behandelt die Zusammenarbeit im Scrum Team.

Die Aussagen 1, 4 und 7 sind richtig.

1 Punkt für das Schema „Als … möchte ich …, damit …“, 1 Punkt für einen sinnvollen Inhalt, zum Beispiel:

„Als Nutzerin möchte ich meine gespeicherten Daten in der App als Datei herunterladen, damit ich weiß, was über mich gespeichert ist, und die Daten zu einem anderen Dienst mitnehmen kann.“

Zum Beispiel:

• Der Wunsch wird als neuer Eintrag (User Story) ins Product Backlog aufgenommen. (1 Punkt)

• Clara Neumann als Product Owner priorisiert ihn gegenüber den anderen Einträgen; wegen der gesetzlichen Pflicht wird sie ihn vermutlich weit oben einordnen. Im nächsten Sprint Planning kann das Team ihn dann auswählen und umsetzen. (1 Punkt)

• Begründung: Das Sprintziel und das Sprint Backlog bleiben während des Sprints stabil; das Team kann seine Zusage nur einhalten, wenn nicht ständig neue Arbeit hineingeschoben wird. Spätestens nach zwei Wochen kommt die Anforderung ohnehin zum Zug. (1 Punkt)

2 Punkte für eine begründete Stellungnahme, 2 Punkte für zwei passende Maßnahmen, zum Beispiel:

Stellungnahme: Scrum passt weiterhin, weil die Anforderungen unsicher sind und sich erst an ersten Versionen klären; ein vollständiger Plan aller Funktionen wäre jetzt nur scheinbar verbindlich und müsste ohnehin geändert werden. Mit Clara Neumann ist die Auftraggeberin im Haus und kann laufend priorisieren. Feststehen können Zeit und Budget (Teamgröße × Sprints bis Juni 2027); flexibel bleibt der Umfang, wobei die wichtigsten Funktionen zuerst umgesetzt werden. (Auch eine Gegenposition ist bei guter Begründung möglich, z. B. ein hybrides Vorgehen mit festen Meilensteinen.)

Maßnahmen für Planungssicherheit:

• ein Produktziel und ein grober Release-Plan (welche Funktionen voraussichtlich in welchem Quartal) aus dem priorisierten Product Backlog,

• Geldgebende zu Sprint Reviews einladen, damit sie den Fortschritt an lauffähiger Software sehen,

• Fortschritt messbar machen, z. B. mit einem Burn-up-Diagramm über die erledigten Backlog-Einträge,

• feste Meilensteine vereinbaren, an denen über Budget und Prioritäten entschieden wird.

Je Merkmal 2 Punkte, 2 Punkte für die Begründung, zum Beispiel:

Merkmale:

• Visualisierung auf einem Kanban-Board: Jede Meldung ist eine Karte, die durch Spalten wie „Neu – In Bearbeitung – Rückfrage – Erledigt“ wandert; so sieht jede*r den aktuellen Stand.

• WIP-Limit: Die Zahl der gleichzeitig bearbeiteten Karten je Spalte ist begrenzt (z. B. höchstens drei „In Bearbeitung“); erst wird fertiggestellt, dann Neues begonnen.

• Pull-Prinzip: Wer frei ist, zieht sich die nächste Karte mit der höchsten Priorität.

• kontinuierlicher Fluss statt Sprints; gemessen wird z. B. die Durchlaufzeit einer Meldung.

So könnte das Kanban-Board des Support-Teams aussehen:

Begründung: Meldungen kommen unvorhersehbar und müssen teils sofort bearbeitet werden (z. B. ein gemeldetes Fake-Profil). In Scrum müsste neue Arbeit bis zum nächsten Sprint warten oder würde den Sprint ständig stören. Kanban hat keine festen Zyklen, neue Karten können jederzeit priorisiert und gezogen werden. Außerdem ist ein Team aus zwei Personen für die Rollen und Ereignisse von Scrum sehr klein.

Grundprinzip (2 Punkte): Das Projekt wird in Phasen eingeteilt, die streng nacheinander durchlaufen werden. Jede Phase muss vollständig abgeschlossen sein, bevor die nächste beginnt; ihr Ergebnis (meist ein Dokument) ist die verbindliche Vorgabe für die nächste Phase. Im reinen Modell gibt es keine Rückkehr, im erweiterten Modell Rücksprünge in die vorige Phase.

Reihenfolge (3 Punkte, bei einem Vertauschungsfehler 2 Punkte, sonst 0):

1. Analyse

2. Entwurf

3. Implementierung

4. Test

5. Einsatz und Wartung

Je Nachteil 2 Punkte (Nachteil und Bezug zum Projekt), zum Beispiel:

• Tests erst am Ende: Getestet wird erst nach der vollständigen Implementierung. Stellt sich dann heraus, dass z. B. die Firewall den Zugriff aus dem VLAN 520 auf die Datenbank sperrt, ist der 01.02.2027 kaum noch zu halten.

• Fehler in den Anforderungen fallen spät auf: Hat niemand festgelegt, was bei Ausfall der Verbindung angezeigt wird, merkt das Team es erst im Test oder beim Abnahmetermin, und die Änderung ist teuer.

• Keine Zuordnung von Tests zu Vorgaben: Das Modell legt nicht fest, wogegen auf welcher Ebene geprüft wird; die von Svenja Krämer und Andrea Wolf geforderten Nachweise entstehen nicht systematisch.

• Kein Rückweg im reinen Modell: Eine Lücke im Entwurf (z. B. Helligkeitssteuerung vergessen) kann nicht sauber in einer früheren Phase korrigiert werden.

Je Fehler 1 Punkt für das Beschreiben, 1 Punkt für die Richtigstellung:

• Systementwurf und Komponentenentwurf sind vertauscht. Auf dem linken Ast wird von grob nach fein zerlegt: Zuerst legt der Systementwurf die Bausteine fest (Player, Schnittstelle zu v_monitor, Netz und Strom), danach beschreibt der Komponentenentwurf den Ablauf jedes Moduls. Dadurch liegt der Systementwurf auch wieder dem Integrationstest gegenüber und der Komponentenentwurf dem Komponententest.

• Systemtest und Abnahmetest sind vertauscht. Der Abnahmetest ist die letzte Stufe oben rechts und liegt der Anforderungsdefinition gegenüber: Thomas Becker und Andrea Wolf prüfen gegen das Lastenheft. Der Systemtest liegt der Systemspezifikation gegenüber und prüft das Gesamtsystem gegen das Pflichtenheft.

• Die Pfeile auf dem rechten Ast zeigen abwärts. Nach einem bestandenen Test geht es aufwärts zur nächsten Teststufe (Implementierung, Komponententest, Integrationstest, Systemtest, Abnahmetest). Nur wenn ein Test nicht bestanden ist, geht es waagerecht zurück zur gegenüberliegenden Entwurfsphase.

Richtig sieht das V-Modell so aus (die gepunkteten Pfeile zeigen zusätzlich, wo die Testfälle festgelegt werden):

Je Zelle 1 Punkt, zum Beispiel:

Erläuterung 2 Punkte, Vorgehen bei Fehlschlag 2 Punkte, zum Beispiel:

• Warum früh: Wer eine Vorgabe macht, legt gleich fest, woran ihre Erfüllung gemessen wird. Dadurch werden die Vorgaben eindeutig und prüfbar formuliert, Unklarheiten fallen schon im Entwurf auf, und der Test prüft genau das, was entworfen wurde (nicht das, was programmiert wurde). Außerdem kann der Test vorbereitet werden, während noch entwickelt wird.

• Bei Fehlschlag: Der Fehler wird dokumentiert (Testprotokoll), und es geht zurück zur gegenüberliegenden Phase, dem Systementwurf: Dort wird z. B. die Schnittstelle oder die Netz- und Rechtekonfiguration überarbeitet. Anschließend werden die betroffenen Phasen erneut durchlaufen (Komponentenentwurf, Implementierung, Komponententest) und der Integrationstest wiederholt.

Je 1 Punkt:

• Verifikation („Bauen wir das Produkt richtig?“): Prüfung gegen die technische Vorgabe; der Systemtest prüft das Gesamtsystem gegen das Pflichtenheft.

• Validierung („Bauen wir das richtige Produkt?“): Prüfung, ob der tatsächliche Zweck der Auftraggebenden und Nutzenden erfüllt ist; das geschieht im Abnahmetest gegen das Lastenheft. Ein Systemtest kann bestanden sein, obwohl z. B. die Schrift auf dem Flurmonitor für Vorbeigehende zu klein ist.

Je richtiger Zuordnung 1 Punkt:

Hinweis: Agile Modelle sind ebenfalls iterativ. Die Aussagen 1 und 4 betonen aber typisch agile Werte (funktionierende Software, Zusammenarbeit, Reagieren auf Veränderung), die Aussagen 3 und 5 nur die Wiederholung.

2 Punkte für die begründete Stellungnahme, 2 Punkte für einen begründeten Vorschlag, zum Beispiel:

Stellungnahme: Für die App ist das V-Modell weniger geeignet. Die Wünsche der Auszubildenden (Bedienung, Erinnerungen, Barrierefreiheit mit Screenreader) zeigen sich erst an ersten Versionen; Thomas Becker steht als Ansprechpartner regelmäßig zur Verfügung, und lauffähige Teilversionen schaffen früh Akzeptanz. Mit dem V-Modell kämen diese Rückmeldungen erst beim Abnahmetest, und Änderungen würden teuer.

Vorschlag: ein hybrides Vorgehen: Die App wird agil (z. B. Scrum mit zweiwöchigen Sprints und Thomas Becker im Sprint Review) entwickelt, die Flurmonitor-Anzeige mit Hardware, Elektroarbeiten, Netzfreigabe und Datenschutznachweis nach dem V-Modell. Gemeinsame klassische Meilensteine (Datenschutzfreigabe, Abnahme, Start am 01.02.2027) verbinden beide Teilprojekte. Auch in den Sprints können über die Definition of Done dokumentierte Tests verlangt werden, sodass Svenja Krämers Nachweise trotzdem entstehen.

Je Grund 2 Punkte, zum Beispiel:

• Vollständigkeit: Das Modell gibt alle Schritte vor, auch ungeliebte wie Testplanung, Reviews und Abnahme; nichts wird unter Zeitdruck „vergessen“.

• Prüfbare Ergebnisse: Jede Phase endet mit einem Dokument, das geprüft werden kann (z. B. Pflichtenheft im Review, Testprotokolle); Fehler werden früh und auf der richtigen Ebene gefunden.

• Nachvollziehbarkeit und Nachweise: Die Dokumente belegen gegenüber Schul-IT, Datenschutz und Auftraggeber, dass Anforderungen erfüllt und getestet sind, und erleichtern spätere Wartung, etwa wenn das Team nach dem Schuljahr wechselt.

• Einheitliche Begriffe und Rollen: Alle Beteiligten wissen, was wann von wem erwartet wird; das verringert Missverständnisse zwischen Schule, Schul-IT und Projektteam.

Je Merkmal 2 Punkte (beide Seiten), 2 Punkte für die begründete Entscheidung, zum Beispiel:

Entscheidung: Hannahs Vorschlag passt besser. Ob die App angenommen wird, zeigt sich nur, wenn Gäste sie freiwillig auf dem eigenen Handy aufrufen und wieder öffnen; das lässt sich beim MVP an den Zugriffen messen. Ein Prototyp am Tablet des Teams zeigt eher, wie die Bedienung ankommt. (Eine Kombination ist bei guter Begründung ebenfalls richtig, z. B. MVP für alle und ein Prototyp der geplanten Abstimmungsseite am Stand.)

2 Punkte für die Beurteilung, 3 Punkte für die begründete Alternative, zum Beispiel:

Beurteilung: Die Auswahl ist ungeeignet. Ein MVP soll mit möglichst wenigen Funktionen den eigentlichen Zweck der App erfüllen. Ohne Sessionplan (1) gibt es nichts, was sich merken ließe, und ein Chat (5) ist aufwendig (Moderation, Datenschutz, Missbrauch), ohne dass die App ihn für ihren Zweck braucht.

Alternative: Das MVP enthält nur Wunsch 1, den Sessionplan mit Raum und Uhrzeit. Er ist der Kern der App, die Daten liegen schon vor, und er lässt sich am Infotag mit dessen Programm sofort nutzen. Wer zwei Funktionen wählt, kann die Abstimmung (2) ergänzen, weil sie das Barcamp-Prinzip trägt. Andere Vorschläge sind bei passender Begründung ebenfalls richtig.

Je Messgröße 1 Punkt, 2 Punkte für die abgeleitete Entscheidung, zum Beispiel:

• Messgrößen: Zahl der Geräte, die die App aufrufen, im Verhältnis zur Zahl der Gäste; Anteil der Gäste, die den Plan im Laufe des Tages mehrmals öffnen; Zahl und Inhalt der Rückmeldungen über einen Feedback-Knopf; Stellen, an denen Nutzende die App verlassen.

• Entscheidung: Öffnen zwar viele Gäste den Plan, schreiben aber oft „Wo ist Raum B 214?“ ins Feedback, setzt der Product Owner den Lageplan (6) im Product Backlog nach oben; er kann im nächsten Sprint umgesetzt werden. Nutzen dagegen nur sehr wenige Gäste die App, klärt das Team zuerst die Ursache (z. B. QR-Code am Eingang schlecht sichtbar), bevor es neue Funktionen baut.

3 Punkte für eine schlüssig begründete Reihenfolge, 2 Punkte für die Erläuterung, zum Beispiel:

1. Abgeschnittener Plan beheben: ein Fehler in der Kernfunktion, der viele Nutzende trifft und wenig Aufwand macht.

2. Lageplan mit barrierefreien Wegen (Wunsch 6): Beim Barcamp verteilen sich die Sessions auf drei Gebäude; ohne Lageplan sind Menschen mit Rollstuhl oder Rollator ausgeschlossen.

3. Merkliste mit Erinnerung (Wunsch 3): erhöht die Bequemlichkeit, ist aber für den Zweck nicht zwingend.

4. Chat für Fahrgemeinschaften: aufwendig und nicht Kernzweck der App; für Fahrgemeinschaften gibt es am RRB schon die Mitfahr-App RatzFahrt, auf die die App verlinken kann.

Wer entscheidet: Dimitrios Papadopoulos als Product Owner. Er verantwortet den Wert des Produkts und ordnet das Product Backlog. Developers und Stakeholder bringen im Sprint Review ihre Sicht ein; welche Einträge in einen Sprint kommen, wählt das Scrum Team im Sprint Planning aus den oberen Einträgen aus.

Je Prototypart 1 Punkt für die Erläuterung, 1 Punkt für den Vorteil, zum Beispiel:

• Wegwerf-Prototyp (Mia): dient nur dazu, etwas über Bedienung und Abläufe zu lernen, und wird danach verworfen. Vorteil: Papierskizzen sind in Minuten gezeichnet; das Team kann mehrere Varianten der Abstimmung in einer Runde mit Gästen vergleichen, ohne an vorhandenem Code zu hängen.

• Evolutionärer Prototyp (Hannah): wird nach jeder Rückmeldung verbessert und schrittweise zum fertigen Produkt ausgebaut. Vorteil: Die Arbeit geht nicht verloren, und die Gäste testen die Abstimmung realistisch auf dem eigenen Handy.

2 Punkte für die Richtigstellung, je Ergänzung 2 Punkte (Vereinbarung und Begründung), zum Beispiel:

• Vereinbarung 3 ist falsch: Im Sprint Planning wählt das Scrum Team gemeinsam die Einträge für das Sprintziel aus. Wer welchen Eintrag bearbeitet, entscheiden die Developers selbst; der Product Owner erklärt nur Ziel und Prioritäten.

• Scrum Master bestimmen: Jemand muss darauf achten, dass Scrum wirksam gelebt wird, und Hindernisse beseitigen, z. B. fehlende Zugänge zum Schulserver.

• Definition of Done vereinbaren: Erst dann ist klar, wann ein Eintrag fertig ist (z. B. getestet, auf kleinen Handys geprüft, im Repository dokumentiert).

• Termine für Daily Scrum, Sprint Review und Retrospective festlegen: Das Team trifft sich nur an Schultagen und braucht feste Zeiten, etwa in der ersten Pause.

• Produktziel und User Stories formulieren: Die Wunschliste wird erst als User Stories mit Nutzen für die Teilnehmenden planbar und schätzbar.