Scrum: Übersicht zum Einsatz in der Lehre

Kurzzusammenfassung:

Das Besondere an diesem Ansatz ist, dass das Lehr-Lern-Konzept die ganzheitliche Kompetenzentwicklung von Software Engineering-Studierenden unterstützt, sich letztlich über das agile Framework Scrum zu ihrem eigenen Lern-Prozess-Coach zu entwickeln. Nach und nach soll damit eine Akzeptanz für den Ansatz einer konstruktivistisch geprägten Lehre in die Lehr-Lern-Kultur der Fachdisziplinen integriert und gefördert werden, damit das Motto eines „shift from teaching to learning“ an Einfluss gewinnt im Sinne einer studierendenorientierten Lehre. Die Beteiligten werden nachhaltig angeregt, die Akzeptanz für agiles Lehren und Lernen zu steigern.
Während des gesamten Semesters wird das Szenario-basierte Lernen so gestaltet, dass die Bearbeitung der Product-Backlogs mit Arbeitsschritten durch die Studierenden untereinander in Kleingruppen verteilt wird und sich darüber austauschen. Zudem bestehen Austausch- und Feedbackschleifen (Review & Retrospektive) mit der gesamten Gruppe (Scrum-Team) und dem Dozierenden (Product Owner und Scrum Master).


Übersicht

Ziele:

  • Die Studierenden können Scrum durchführen und lernen Selbst- und Teamdisziplin.
  • Die Studierenden können das „Fachvokabular“ in Form von Ereignissen, Rollen, Artefacte anwenden.
  • Die Studierenden können ihren Lernfortschritt im Plan-Do-Check-Learn-Zyklus dokumentieren.

Didaktische Funktion(en):

  • Aktivierung der Teamarbeit
  • Informationsaneignung
  • Wiederholung & Festigung
  • Transfer & Anwendung
  • Beurteilung
  • Rückmeldung & Feedback&Reflexion

Hintergrund / didaktisch-methodische Einordnung:

Mit diesen Rahmenbedingungen lässt sich die didaktische Konzeption von diversen Szenario-basierten Lehr-Lern-Arrangements für Software Engineering durch Agile-Learning-Elemente aus Scrum und eduScrum agil weiterentwickeln. Die Wirkung von Lern-Prozess-Coaching wurde im Umfeld des Software-Engineering bei Wirtschaftinformatiker und Informatikern evaluiert und angepasst. Das eingesetzte Framework Scrum LPC mit den Ereignissen Sprint-Planning, Sprintdurchführung mit Hilfe von innovativen Lehr- und Lernmitteln, Sprintreview zum Check des Lernprozesses und Sprint-Retrospektive mit der Definition of Flow [CSIK1982] dient als Gelegenheit der Selbst- und Teamreflexion. Es fördert individuelles als auch gruppenbezogenes Lernen von Software Engineering und überfachliches Selbstcoaching über den gesamten Veranstaltungszyklus eines Semesters hinweg. Dabei gilt es, die eigenen Stärken zu ermitteln, individuelle Entwicklungspotentiale im Dialog bewusst zu machen und gemeinsam gezielt zu fördern. (siehe hierzu Müller-Amthor et.al. 2020).

Agiles lebenslanges Lernen ist nur gestaltbar, wenn sich Studierende mit Freude als stetig Lernende wahrnehmen, sich auf ihren eigenen Lernprozess einlassen, indem sie sich selbst Lernziele (Sprintziele) setzen, bewusst Lernwege auswählen und selbstständig realisieren. Das bedeutet, den eigenen Entwicklungsweg – „Lernplan“ – im Sprint selbstbestimmt zu gestalten. Nach dem Review der inhaltlich fachlichen Lösung gilt es, sich überfachlich reflexiv weiterzuentwickeln [DECI1985]. Dazu steht ein erfahrener Scrum Master als lösungsorientierter Coach zur Verfügung. Coaching als personenbezogener, individuell lösungsorientierter Beratungs- und Betreuungsprozess versucht das Wachstum der Selbstwirksamkeit von Studierenden zu fördern [MUEL2020a]. Wertebasiertes Scrum LPC leistet hilfreiche Unterstützung [MUEL2020b] und die Kombination diverser Scrum Framework Elemente führt zu unterschiedlichen Wirkungen im Lehren und Lernen [MUEL2020c].

Sozialform(en):

Einzelarbeit, Partnerarbeit, Kleingruppenarbeit (3-5), Großgruppenarbeit (ab 6)

Anzahl der Lernenden:

ab 1 Person mit persönlichem Scrum-Board


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson(en) benötigen sehr gute Kenntnisse bezüglich des Scrum Framework. Lernende benötigen je nach Aufgabentyp Vorkenntnisse im Bereich Programmieren.

Ausstattung & Medien:

Seminarraum je nach Anzahl der Lernenden, PC, 1 Beamer,
analog: Flipchart, PostIT

digital: Scrum-Board auf einer kollaborativen Online-Plattform


Ablauf

Beispiele oder Materialien:

Ein Trello-Board mit dem gesamten Inhalt mit Beispielaufgaben und Lösungen der Software Engineering Veranstaltung kann unter folgender Adresse eingesehen werden:
SWT

Das Scrum Sprint-Backlog dient der wöchentlichen Planung der Praktikumsveranstaltung. Diese wird ebenfalls als Sprint gestaltet. Sie beinhaltet alle Scrum Ereignisse: Sprint-Review, Sprint-Retrospektive mit Definition of Flow (DoF) und Vorbereitung der neuen Sprint–Planung für die studentischen Scrum-Teams. Diese schätzen selbstständig den Aufwand in Relation der Schwierigkeit einer Aufgaben-Anforderung, die als Produkt-Backlog mit der Definition of Ready (DoR) beschrieben sind. Danach startet das Scrum-Team selbstorganisiert den nächsten Sprint mit eigenem Sprintziel, -umfang und Definition of Done (DoD).

Hinweise zur Vorbereitung:

Konzeption von Aufgaben in Form von Product-Backlogs mit geeignetem Umfang. Vorbereiten von Lösungsvorschlägen, in welchen die Anwendung von UML oder anderen Konzepten ordentlich und präzise dokumentiert sind.

Hinweise zur Nachbereitung:

Die Ergebnisse werden ggf. gespeichert und den Lernenden zur Verfügung gestellt.

Hinweise zur Dauer: Insgesamt ca. 55 Minuten


Kritische Einordnung

Vorteile und Stärken:

Sehr gut geeignet für Software Engineers, es unterstützt die Kommunikation und Interaktion zwischen den Studierenden und fördert nachweislich die Teamfähigkeit.

Grenzen und Schwächen:

Vergleichsweise zeitaufwändig

Sonstige Hinweise:

Den Verantwortlichen liegt am Herzen, dass ein agiles Mindset im Studium angeeignet werden kann. Dazu schaffen wir den benötigten Aneignungsraum: Einsatz eines agilen Framework Scrum, einer modernen, bereits in der Industrie weit verbreiteten Kollaborationsplattform Jira von Atlassian bzw. Trello als Scrum-Board und Einsatz der Modellierungssoftware Enterprise Architect von Sparx.


Literatur und weiterführende Hinweise

Csikszentmihalyi, Mihaly (1999/1975): Das Flow-Erlebnis – jenseits von Angst und Langeweile: im Tun aufgehen. Hrsg. von Hans Aebli. Übers. von Urs Aeschbacher. 7. Aufl. Stuttgart: Klett-Cotta. (Original erschienen 1975: Beyond Boredom and Anxiety-The Experience of Play in Work and Games)
Deci, E. L.; Ryan, R. M.: Intrinsic motivation and self-determination in human behavior. Plenum Press, New York 1985.
Mueller-Amthor, M.: „KOLLERN-Gemeinsam leichter lernen!“ -mit kollegialer Beratung Studierfähigkeit fördern, unveröffentlichtes Werkstattpapier, Hochschule Kempten, Jan. 2015
Müller-Amthor, M.; Hagel, G.; Gensheimer, M.; Huber, F. (2020a): Scrum Higher Education – The Scrum Master Supports as Solution-focused Coach. IEEE Global Engineering Education Conference EDUCON, Porto, Portugal, S. 948-952.
Mueller-Amthor, M.: Scrum LPC – A Value-Based Framework for Learning Process Coaching, International Conference on Advancements of Science and Technology, EAI ICAST 2020, Bahir Dar, presented Oct. 2020b
Mueller-Amthor, M.: Scrum Approach between Education and Learning-Process-Coaching: Towards a Systematic Literature Review, 13th International Conference of Education, Research and Innovation, ICERI 2020, IATED Academy, Virtual presentation Nov. 2020c.

Hinweis: Literaturangaben bitte in einheitlichem Stil (Beispiel siehe oben).

CRC-Karten-Workshop mit Augmented Reality

Kurzzusammenfassung:

Konkret wird diese neue Herangehens­weise für die Vermittlung von Techniken konzipiert, um Verantwortlichkeiten und Beziehungen eines UML (Unified Modeling Language)-Klassendiagramms im Rah­men eines CRC-Karten Workshops erarbeiten zu können. Das Visualisie­ren und Verifizieren im Workshop am „Runden Tisch“ oder mit HIlfe des SMART Boards mit einer Gruppe von Studierenden soll de­ren Fach- und Methodenkompetenz sowie neben analytischen Fähig­keiten und Beurteilungsvermögen zahlreiche überfachliche Kompetenzen fördern. Aktivitäts- und Handlungs­kompetenz, z. B. ergebnisorientiertes Handeln, Gestaltungswille und Entscheidungs-fähigkeit scheinen bei der Klassenmodellierung eine wichtige Rolle zu spielen. Speziell für die Phase der Anforderungsermittlung, die im Curriculum zum Software Engineering im Bereich des Requirements Engineering verankert ist, wird ein Konzept zum Einsatz von Augmented Rea­lity in Kombination mit einem SMART Board als innovatives Lehr- und Lern­mittel erstellt.


Übersicht

Ziele:

  • Die Studierenden können die Technik der CRC-Karten (Class-Responsibility-Collaboration) beschreiben und verstehen.
  • Die Studierenden können die Beziehungen und Verantwortlichkeiten von Klassen anhand eines Rollenspiels er­kennen und verstehen.
  • Die Studierenden verwenden dabei die CRC-Karten durch eine Smart­phone-App, die auf dem vorhandenen Konzept basiert.

Didaktische Funktion(en):

  • Einstieg & Aktivierung
  • Informationsaneignung
  • Transfer & Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Das Prinzip des CRC-Karten-Workshops ist es, für Studierende anhand eines mit CRC-Karten ausgestalteten Rollenspiels die Verantwortlichkeiten einer Klasse und ihrer Beziehungen erlebbar zu machen. (siehe hierzu Müller-Amthor et.al., 2013). Dabei werden sowohl fachliche als auch zahlreiche überfachliche Kompetenzen eines Requirements Engineer gefördert. Die Evaluation durch Fragebogen erweis, dass der Erkenntnisgewinn hoch eingeschätzt wurde.

Sozialform(en):

Kleingruppenarbeit
5-12 Personen

Anzahl der Lernenden:

ab 5 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson(en) benötigen gute Kenntnisse in Objektorientierter Analyse. Lernende benötigen je nach Aufgabentyp Vorkenntnisse im Bereich Programmieren zu Klassen, Attributen und Methoden.

Ausstattung & Medien:

Seminarraum mit Carre-Tischen je nach Anzahl der Lernenden, PC, 1 Beamer bzw. Smart-Board


Ablauf

Beispiel Anwendungsfall – BeschreibungBuch ausleihen

Kurzbeschreibung: 
Kunde möchte Buch aus der Bibliothek leihen.
Akteure:
Kunde, Bibliothekar, Drucker/Scanner, Verwaltungssystem
Auslöser:
Kunde legt ausgewähltes Buch zur Ausleihe vor.
Ergebnisse:
Was wurde dem Akteur zurückgegeben?
  –>Kunde erhält Buch und Leihschein
Eingehende Daten:
Alle Daten, die während der Abfolge des Use case entgegengenommen werden (z.B. Benutzereingaben)
Vorbedingungen: (opt.) In welchem Zustand befindet sich das System, bevor der Use case eintritt?
–>System ist gestartet, Benutzer (Kunde, Bibliothekar) ist registriert und angemeldet, Ausleihfunktion steht zur Verfügung. Buch ist ausleihbar
–>Buch- und Kundendaten werden per Scanner erfasst.
Nachbedingungen: (opt.) In welchem Zustand befindet sich das System nach erfolgreicher Abarbeitung des Use case?
–>Leihschein ist für Kunde und für Buch gespeichert.
Buch hat Status entliehen.
Essenzielle Schritte: Kern des Anwendungsfalls.
Einzelne Ablaufschritte, gegliedert in Einzelpunkte.
Offene Punkte: Alles, was nicht sofort geklärt werden kann.

Materialien:

und Unterlagen zum Workshop

Hinweise zur Vorbereitung:

Konzeption von Use Case mit geeignetem Szenario. Vorbereiten der leeren CRC-Karten und einer gefüllten CRC-Karte mit Lösungsvorschlag, in welchem die Attribute und Methoden ordentlich und präzise dokumentiert sind.

Hinweise zur Nachbereitung:

Die Ergebnisse werden ggf. gesammelt, aufbereitet und gespeichert und den Lernenden zur Verfügung gestellt.

Hinweise zur Dauer: Insgesamt ca. 90 Minuten


Kritische Einordnung

Vorteile und Stärken:

Sehr gut geeignet für Anfänger(innen), es unterstützt das Begreifen und Verstehen einer Klasse, die Kommunikation und Interaktion zwischen den Studierenden.

Grenzen und Schwächen:

Vergleichsweise zeitaufwändige Vorbereitung.
Bei erstelltem und vervielfältigtem Einsatzmaterial entsteht nur geringer laufender Aufwand

Sonstige Hinweise:

Das Verfahren analog mit Karten oder digital mit Smartphone-App kann bislang nicht hybrid eingesetzt werden.


Literatur und weiterführende Hinweise

Müller-Amthor, M.; Baumgärtner, A.; Hagel, G.; Gegner, T. (2013): Kompetenzorientiertes Lehren und Lernen von Requirements Engineering – Anforderungsanalyse unter Verwendung innovativer Lehr- und Lernmittel. In: Embedded Software Engineering Kongress ESE-Kongress 2013, Sindelfingen, S. 521-532.

Strukturierte Testfallermittlung mit Moodle Add-in

Kurzzusammenfassung:

Das LLA zu „Strukturierte Testfallermittlung mit Moodle Add-in“ beschreibt die technologische und pädagogisch gestützte Entwicklung eines Fragetyps, der das Einüben der strukturierten Testfallermittlung erleichtern und damit den Lernerfolg bei den Studierenden verbessern soll. Eine schrittweise Erarbeitung, welche eine mediengestützte Lernplattform zur Verfügung stellt, unterstützt den Aneignungsprozess. Der Lösungs-prozess beinhaltet und durchläuft implizit alle nötigen Bestandteile des Testszenarios. Studierende erkennen die Bedeutung einer hohen Fehlerentdeckungswahrscheinlichkeit bei minimaler Anzahl von Testfällen. Während den individuell oder gemeinsam erarbeiteten Lösungsschritten können sich die Studierenden sowohl per Programm automatische Lösungsunterstützung anfordern als auch untereinander in Kleingruppen austauschen. Zudem bestehen Austausch- und Feedbackschleifen mit der gesamten Gruppe und dem Dozierenden.


Übersicht

Ziele:

  • Die Studierenden kennen die Aufgabe der strukturierten Testfallermittlung und verstehen die dabei entstehenden Herausforderung.
  • Die Studierenden können das „Fachvokabular“ beim Testen anwenden.
  • Die Studierenden können verlässlich die Software-Entwicklungsphase des Testens strukturiert unterstützen.

Didaktische Funktion(en):

  • Einstieg & Aktivierung
  • Informationsaneignung
  • Wiederholung & Festigung
  • Transfer & Anwendung
  • Beurteilung
  • Rückmeldung & Feedback

Hintergrund / didaktisch-methodische Einordnung:

Das Vorgehen wurde zur Aneignung der Strukturierten Testfallermittlung entwickelt (siehe hierzu Gabler 2017). Dadurch sollen die Studierenden die strukturierte Testfallermittlung später selbstständig durchführen können, so müssen sie dies bereits in den Übungen tun und die Prüfung müsste auch entsprechend gestaltet sein. Es reicht dann nicht, in der Übung oder Prüfung nur die Fachbegriffe abzufragen oder Aussagen über die strukturierte Testfallermittlung beurteilen zu lassen bzw. die strukturierte Testfallermittlung nur theoretisch durch Beschreibung der einzelnen Schritte vorzustellen. Sowohl im Lehr-Lern-Szenario des Einsatzes in Präsenz sowie in Online-Veranstaltung als auch in der Prüfungsvorbereitung kann der/die Studierende selbst entscheiden, zu welchem Zeitpunkt er/sie die Eingaben überprüfen lassen will: Er oder sie kann die Überprüfung nach jeder „ausgefüllten“ Äquivalenzklasse anstoßen. Falls er/sie noch wenig Erfahrung mit der strukturierten Testfallermittlung hat oder auch komplett gegen Ende der Bearbeitung, kann sich der/die Studierende gegebenenfalls immer bzw. bei Bedarf korrigieren und somit seine/ihre Selbstwirksamkeit beeinflussen.


Sozialform(en):

Einzelarbeit, Partnerarbeit, Kleingruppenarbeit (3-5), Großgruppenarbeit (ab 6), Plenum

Anzahl der Lernenden:

von 1 Personen bis 30 gleichzeitige Zugriffe auf die Lernplattform


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson(en) benötigen sehr gute Kenntnisse der Strukturierten Testfallermittlung. Lernende benötigen keine Vorkenntnisse im Bereich des Testens.

Ausstattung & Medien:

Seminarraum je nach Anzahl der Lernenden, PC, 1 Beamer, Zugriff auf die Lernplattform


Ablauf

Beispiele oder Materialien:

Beispielaufgabe:
Die folgende Beschreibung zeigt einen Testfall

und die entsprechende Lösung, welche online erzielt werden soll:

Hinweise zur Vorbereitung:

Konzeption von Aufgaben mit geeignetem Testfallszenario. Vorbereiten von einem Lösungsvorschlag, in welchem die Eingaben ordentlich und präzise dokumentiert sind.

Hinweise zur Nachbereitung:

Die Ergebnisse wurden gespeichert und stehen den Lernenden jederzeit wieder zur Verfügung.
Dabei können die Lernenden die Testung jederzeit erneut durchführen und sich mit ihrem individuellen Vorergebnis benchmarken.

Der Lehrende kann mittels Logfile-Analyse folgendes ermitteln:

  • Nutzung der Vorab-Überprüfung
  • Häufigkeit des Aufrufs der Online-Übung
  • Erreichte Punktzahl
  • Häufige Fehlerquellen

Hinweise zur Dauer: Insgesamt ca. 90 Minuten


Kritische Einordnung

Vorteile und Stärken:

Sehr gut geeignet für Software Engineer Veranstaltung in der Phase des Entwicklungszyklus „Testing“, es unterstützt die Kommunikation und Interaktion zwischen den Studierenden.

Grenzen und Schwächen:

Nach Implementierung des unter SCORM-Format kombatiblen LLA
ist die zur Verfügungstellung vergleichsweise wenig zeitaufwändig.

Sonstige Hinweise:

Das hier beschriebene Lehr-Lern-Arrangement beschreibt die Version eines online-basierten, medium-gestützten Tools im SCORM-Format, was darauf abzielt, die Studierenden mit dem eher trockenen Thema des Testens zu motivieren. Dieses Verfahren eignet sich zum individuellen und Gruppen-Benchmark durch eine technisch gesteuerte Anwendung. Die Evaluation erfolgte durch Logfile-Analyse, Beobachtung, Fragebogen und Leitfadeninterview mit Dozentin sowie durch Lernerfolgsanalyse der Prüfung.


Literatur und weiterführende Hinweise

Gabler, D. (2017): Entwicklung und Evaluation eines Fragetyps in einer Lehr-/Lernplattform zum Erlernen der strukturierten Testfallermittlung, Masterarbeit an der FAU Nürnberg, Master Multimedia-Didaktik, 30.12.2016.

Gabler, D.; Müller-Amthor, M.; Hagel, G. (2017): Motiviert an die strukturierte Testfallermittlung. In: Igel, Christoph, Ullrich, Carsten, Wesser, Martin (Hrsg.), Bildungsräume 2017. Gesellschaft für Informatik, Bonn, S. 125-130.

Softwaretest: Anweisungs-, Verzweigungs-, und Pfadüberdeckung

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Formen des Whiteboxtests anhand von vollständig implementierten Methoden (Testfälle für Anweisungs-, Verzweigungs- und Pfadüberdeckung) selbstständig, praktisch durchführen. Im zweiten Teil des Übungsblattes sollen Studierende einen Kontrollflussgraphen für eine vorgegebene Methode entwerfen.


Übersicht

Ziele:

  • Verstehen und Erstellen von Tests mit vollständiger Anweisungsüberdeckung
  • Verstehen und Erstellen von Tests mit vollständiger Verzweigungsüberdeckung
  • Verstehen und Erstellen von Tests mit vollständiger Pfadüberdeckung
  • Erstellen eines Kontrollflussgraphen

Didaktische Funktion(en):

  • Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen zu Blackboxtestverfahren und Whiteboxtestverfahren; Kenntnisse über Anweisungs-, Verzweigungs- und Pfadüberdeckung (C0, C1, C2 Überdeckung)
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen im Bereich Whiteboxtestverfahren

Ausstattung & Medien:


Ablauf
  1. Die Studierenden erhalten ein Aufgabenset mit verschiedenen Vorgaben (Nassi-Shneiderman-Diagramm, Codebeispiele) und die Aufgabe ein Set an minimalen Testfällen zu generieren, um Anweisungsüberdeckung, Zweigüberdeckung und Pfadüberdeckung zu erzielen. Außerdem soll zu einer Aufgabe ein Kontrollflussgraph erstellt werden.
  2. Die Studierenden (alleine oder in Gruppen) bearbeiten selbstständig die Aufgaben des Übungsblattes.
  3. Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
  4. Die Studierenden dokumentieren ihre Ergebnisse direkt im Übungsblatt.

Hinweise zur Vorbereitung:

  • Konzeption von Aufgaben und entsprechenden Codebeispielen für die Studierenden
  • Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand eines Bewertungsschemas
  • Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der Whiteboxtestverfahren auf.

Grenzen und Schwächen:

Keine


Literatur und weiterführende Hinweise
  • H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
  • M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

Softwaretest: Äquivalenzklassentest & Grenzwertanalyse

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Formen des Blackboxtests – Äquivalenzklassentest und Grenzwertanalyse – anhand eines praktischen Beispiels durchführen. Sinn und Zweck der beiden Methoden bzw. der Durchführung von Blackboxtests sollen Studierenden durch den praktischen Einsatz verdeutlicht werden.


Übersicht

Ziele:

  • Ableiten von Äquivalenzklassen zur Äquivalenzklassenanalyse
  • Ableiten von Grenzwerten zur Grenzwertanalyse

Didaktische Funktion(en):

  • Informationsaneignung
  • Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen im Bereich Software Test; Kenntnisse zur Durchführung von Äquivalenzklassentests und Grenzwertanalyse
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen im Bereich Softwaretestverfahren

Ausstattung & Medien:


Ablauf
  1. Die Studierenden erhalten mehrere Szenarien und zum Teil Codeausschnitte mit der Anweisung Äquivalenzklassentests und Grenzwertanalysen durchzuführen. Die Codeausschnitte beschreiben vollständig implementierte Funktionen in C++ (Da ein Blackboxtest durchgeführt werden soll, sind diese eigentlich nicht notwendig. Dies ist allerdings intendiert, um Studierenden die Unterschiede zwischen Blackbox- und Whiteboxtestverfahren zu verdeutlichen)
  2. Die Studierenden (alleine oder in Gruppen) bearbeiten selbstständig die Aufgaben des Übungsblattes.
  3. Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
  4. Die Studierenden dokumentieren ihre Ergebnisse direkt im Übungsblatt in bereits vorgegeben Tabellenstrukturen.

Hinweise zur Vorbereitung:

  • Konzeption von verschiedenen Szenarien, die Äquivalenzklassentests und Grenzwertanalyse erfordern
  • Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand eines Bewertungsschemas
  • Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der Blackboxtestverfahren auf.

Grenzen und Schwächen:

Keine


Literatur und weiterführende Hinweise
  • H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
  • M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

UML Diagramm Übung: Zustandsautomat & Sequenzdiagramm

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende mithilfe von bereit gestellten Informationen in Form eines Requirement-Dokuments ein Lückenbild eines Zustandsdiagramms vervollständigen. Die entsprechenden Textbausteine (Trigger, Guards und Actions) für die Fertigstellung des Diagramms werden den Studierenden in Form einer Liste mitgegeben. Zusätzlich ist ein Teil des Zustandsdiagramms eigenständig zu modellieren.
Der zweite der Teil des LLAs besteht aus der Fertigstellung eines Sequenzdiagramms. Auch hier werden den Studenten die Textbausteine zur Verfügung gestellt. Dieses LLA ist eines von zwei LLAs (zuvor kann das LLA zur Modellierung von Use-Case- und Klassendiagrammen eingesetzt werden), das Studierende in die Verwendung der Unified Modeling Language (UML) als eine Sprache zur Modellierung einer Softwarearchitektur und –design einführt.


Übersicht

Ziele:

  • Erstellung eines Zustandsdiagramms
    • Korrekter Einsatz der wesentlichen Elemente (Zustände, Transitionen mit Trigger, Guard und Actions)
    • Semantisches Verständnis von Zustandsfolgen
  • Erstellung eines Sequenzdiagramms
    • Semantisches Verständnis von zeitlichen Abfolgen in einem Anwendungsfall resp. Dem Aufbau eines Sequenzdiagramms
    • Korrekter Einsatz der wesentlichen Elemente, v.a. synchroner und asynchroner Nachrichten

Didaktische Funktion(en):

  • Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen in der Modellierung von Sequenzdiagrammen und Zustandsautomaten;
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Zustands- und Sequenzdiagrammen

Ausstattung & Medien:


Ablauf
  1. Zu Beginn wiederholt der Dozierende in Form eines Impulsvortrags noch einmal wesentliche Elemente der beiden Diagrammtypen und erläutert diese an einem Beispiel.
  2. Studierende erhalten das Übungsblatt zur Modellierung mit der UML über die Lernplattform. Zentrale Aufgabe ist es auf Basis einer vorhandenen Dokumentation die Lücken eines vorgegebenen Zustandsautomaten mit den korrekten Trigger, Guards und Actions zu vervollständigen.
  3. Die Studierenden bearbeiten (alleine oder in Gruppen) selbstständig die Aufgaben des Übungsblattes.
  4. Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
  5. Die Studierenden dokumentieren ihre Ergebnisse und geben diese über die Lernplattform in Form einer PDF oder eines Bildes des UML-Diagramms ab.

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Aufgabenstellung – Zustandsautomat:

Ergänzen Sie mit Hilfe der gegeben Requirements das Lückenbild des Zustandsdiagramms. Verwenden Sie dabei jeden Begriff auf den gegebenen Listen genau einmal!

Modellieren Sie den fehlenden Teil des Diagramms. Die Begriffe für den zu modellierenden Teil stehen nicht auf der Liste.

Aufgabenstellung – Zustandsautomat:

Ergänzen Sie das gegebene Lückensequenzdiagramm mit den Texten. Wieder gilt Jeder Text muss genau einmal verwendet werden.

Hinweise zur Vorbereitung:

  • Erstellung eines Lücken-Zustandsdiagramms
  • Erstellung eines Lücken-Sequenzdiagramms
  • Erstellung eines Bewertungsschemas für die Abgaben
  • Erstellung eines Requirement-Dokuments

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand eines Bewertungsschemas
  • Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90 min + Fertigstellung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden wenden Faktenwissen praktisch an. Studierende erhalten eine Einführung in die Modellierung von Sequenz- und Zustandsdiagrammen.

Grenzen und Schwächen:

Es wird nicht eigenständig ein Sequenzdiagramm modelliert, sondern nur vervollständigt.


Literatur und weiterführende Hinweise
  • H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
  • M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

UML Diagramm Übung: Use Case- & Klassendiagramm

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende aus einer bestehenden Anforderungsbeschreibung ein Use-Case-Diagramm und ein Klassendiagramm mittels einer Modellierungssoftware ihrer Wahl (z.B. Astah, Enterprise Architect o.Ä.) modellieren. Studierende werden in diesem LLA mit der Aufgabe konfrontiert, aus einem mitgelieferten Requirement-Dokument die wichtigsten Informationen zu extrahieren und in ein erstes Software Grobdesign zu abstrahieren. Dazu wird ihnen die Methode der Substantiv-Verb-Analyse vorgestellt, mit der die Identifikation von Klassenkandidaten für das Klassendiagramm unterstützt werden soll. Dieses LLA ist eines von zwei LLAs, das Studierende in die Verwendung der Unified Modeling Language (UML) als eine Sprache zur Modellierung von Softwarearchitektur und –design einführt.


Übersicht

Ziele:

  • Erstellung eines Use-Case-Diagramm auf Basis einer Anforderungsbeschreibung
    • Identifkation und Formulierung von Use-Cases
    • Korrekter Einsatz der Elemente des Use-Case-Diagramms
  • Einstieg in eine Modellierungssoftware
  • Erstellung eines Klassendiagramms auf Basis einer Anforderungsbeschreibung
    • Identifkation und Modellierung von geeigneten Klassen (sowie Methoden und Attributen)
    • Korrekter Einsatz der Elemente des Klassendiagramms (v.a. Assoziationstypen)
  • Anwendung der Substantiv-Verb-Analyse

Didaktische Funktion(en):

  • Transfer / Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen in der Modellierung von Klassen- & Use-Case-Diagrammen und dem Einsatz verschiedener Modellierungssoftware;
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Klassen- und Use-Case-Diagrammen

Ausstattung & Medien:


Ablauf
  1. Studierende erhalten das Übungsblatt zur Modellierung des Use-Case- und Klassendiagramms über die Lernplattform. Zentrale Aufgabe ist es auf Basis einer Anforderungsbeschreibung Anwendungsfälle für den Coff-E Kaffeeautomaten zu modellieren. Außerdem ist für die Modellierung des Klassendiagramms ein ausführlicheres Requirement-Dokument enthalten, anhand dessen das Diagramm modelliert werden soll.
  2. Es folgt eine kurze einführende Präsentation in die möglichen Modellierungssoftware
  3. Zudem werden in einem Impulsvortrag noch einmal wesentliche Elemente der beiden Diagrammtypen wiederholt und beispielhaft erläutert.
  4. Die Studierenden bearbeiten (alleine oder in Gruppen) selbstständig die Aufgaben des Übungsblattes.
  5. Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
  6. Die Studierenden dokumentieren ihre Ergebnisse mit Hilfe einer Modellierungssoftware und geben die Diagramme über die Lernplattform in Form einer PDF oder eines Bildes des UML-Diagramms ab.

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Aufgabenstellung Use Case-Diagramm:

Ihnen liegt nun folgende Anforderungsbeschreibung für „Coff-E“ vor. Erstellen Sie ein Use Case Diagramm, das auch die Abhängigkeiten der Elemente darstellt. Beachten Sie, dass für ein Use Case Diagramm möglicherweise Verallgemeinerungen nötig sind und/oder nicht alle beschriebenen Informationen relevant sind. Modellieren Sie das Diagramm in Modelio oder einer anderen Modellierungssoftware Ihrer Wahl.
Hinweis: Benutzen Sie bitte bei der Modellierung Generalisierungen, „include“ und „extend“ Beziehungen.

Ihre Firma hat sich entschieden den ersten Prototypen von „Coff-E“ im eigenen Haus zu betreiben. Im Büro ihrer Firma solle daher der neue Kaffeevollautomat „Coff-E“ installiert werden. Um ein fachliches Ziel zu erreichen werden die folgenden Anwendungsfälle definiert.

  • Der Benutzer kann sich auf der App mit Benutzername und Passwort in sein Profil einloggen
  • Der Benutzer kann verschiedene Getränke über die App auswählen:
    • Kaffee schwarz, Kaffee weiß, Cappuccino, Heißes Wasser, Heiße Milch
  • Der Benutzer kann verschiedene Getränke am Kaffeeautomaten auswählen:
    • Kaffee schwarz, Kaffee weiß, Cappuccino, Heißes Wasser, Heiße Milch
  • Nach der Getränkeauswahl kann der Benutzer die Zuckermenge bestimmen:
    • Kein Zucker, Standard Zucker, viel Zucker
    • Falls der Benutzer keine Option wählt, wird per Default Standard Zucker gewählt.
  • Der Benutzer muss nach der Auswahl mit Münzen bezahlen.
  • Bei der Auswahl von viel Zucker muss der Benutzer extra bezahlen.
  • Der Benutzer kann die Scheine im Erdgeschoß wechseln, falls er keine Münzen hat.
  • Der Benutzer kann seine Bankdaten in der App hinterlegen.
  • Der Benutzer kann nach der Auswahl per App bezahlen.
  • Der Benutzer kann die fehlenden Zutaten holen, falls die entsprechende Anzeige auf dem Bildschirm steht.
  • Der Benutzer kann den Techniker anrufen, falls der Kaffeeautomat kaputt ist.
  • Der Techniker repariert den Automaten.
  • Der Techniker kann auch Getränke bestellen.

Aufgabenstellung Klassendiagramm:

Modellieren Sie anhand des Requirements-Dokuments ein Klassendiagramm Kaffeeautomat.

Vorgehensweise um mögliche Klassen zu identifizieren:

  1. Vereinfachen Sie das Requirements- Dokument, extrahieren Sie die wichtigsten Informationen, um einen besseren Überblick über die Requirements zu bekommen.
  2. Führen Sie eine Substantivanalyse des RQ-Dokuments durch.
  3. Erstellen Sie mögliche Klassenkandidaten.
  4. Modellieren Sie das Diagramm in Modelio oder einer anderen Modellierungssoftware Ihrer Wahl.

Hinweise zur Vorbereitung:

  • Erstellung einer Anforderungsbeschreibung für die Erstellung des Use-Case-Diagramms
  • Erstellung eines Requirement-Dokuments für die Erstellung des Klassendiagramms
  • Konzeption von Aufgaben für die Studierenden
  • Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand des Bewertungsschemas
  • Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der UML-Diagramme auf.
Sie lernen das Erstellen von Use-Case-Diagrammen und Klassendiagrammen. Außerdem verstehen sie nach dieser Übung die Generalisierungs-Beziehungen „include“ und „extend“.

Grenzen und Schwächen:

Keine


Literatur und weiterführende Hinweise
  • H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
  • M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

Interviewbasierte Anforderungsanalyse

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende die Fähigkeit erlernen, Anforderungen nach der Schablone von Chris Rupp zu definieren.  Die benötigten Informationen für die Erstellung, werden mittels Interviews verschiedener Stakeholder bereitgestellt. Studierende sollen dabei die Rollen und Verantwortungen des Anwenders wie auch des Stakeholders kennenlernen. Außerdem sollen Studierende in der Lage sein zwischen funktionalen und nicht-funktionalen Anforderungen unterscheiden zu können.


Übersicht

Ziele:

  • Verstehen und Anwenden der Anforderungsschablone von Chris Rupp
  • Unterscheidung zwischen funktionalen und nicht funktionalen Anforderungen
  • Ableiten von Anforderungen an eine Software

Didaktische Funktion(en):

  • Transfer / Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Kleingruppenarbeit (3-5), Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen in Requirements Engineering; Kenntnisse der Schablone nach Chris Rupp
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Requirements Engineering

Ausstattung & Medien:


Ablauf
  1. Die Studierenden erhalten das Übungsblatt zur interviewbasierten Anforderungsanalyse sowie die zugehörigen Stakeholder-Interviews über die Lernplattform.
  2. Sie bearbeiten das bereitgestellte Übungsblatt in Partnerarbeit. In den Interviews werden Statements mit Projektbeteiligten gelistet, die die Anforderungen an das Produkt enthalten, die es zu identifizieren und auszuformulieren gilt. Außerdem ist ein Template enthalten, in das die Anforderungen eingetragen werden sollen.
  3. Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
  4. Die Studierenden dokumentieren ihre Ergebnisse im bereitgestellten Template und geben dieses über die Lernplattform ab.

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Aufgabe:

  • Überlegen Sie sich zunächst tabellarisch mögliche Anwender und Stakeholder.
    • Bearbeiten Sie dazu die Tabelle im Template unter Abschnitt 3.1.. Benennen Sie die Stakeholder, beschreiben Sie diese und überlegen Sie sich Verantwortungen, die die jeweiligen Stakeholder haben.
  • Überlegen Sie sich in welcher Umgebung Coff-E betrieben wird und was den Stakeholdern wichtig ist.
  • Teilen Sie die Requirements in sinnvolle Kategorien (mindestens aber nicht-funktionale/funktionale Anforderungen) ein.
  • Geben Sie den Requirements eine sinnvolle ID (dort kann man zum Beispiel auch die Kategorie abbilden).
  • Verwenden Sie bei der Formulierung der Anforderungen die Schablone von Chris Rupp.

Hinweise zur Vorbereitung:

  • Erstellung von Interviews für die Anforderungsanalyse
  • Konzeption von Aufgaben für die Studierenden
  • Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand des Bewertungsschemas

Hinweise zur Dauer: 90-minütige Übung + Vervollständigung außerhalb der Übung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet des Requirement Engineerings auf.

Grenzen und Schwächen:

Die Übung basiert auf Textarbeit, die auch mit realen Stakeholdern durchgeführt werden könnte. Ein weiterer digitalisierter Ansatz wurde mit der Virtual Reality durchgeführt.


Literatur und weiterführende Hinweise

Qualitätskriterien von Requirements

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende ihnen vorgelegte, teils schlecht formulierte Requirements erkennen und mit Hilfe einer beigefügten Checkliste zunächst nach ihrer Qualität beurteilen. Anschließend sollen diese unter Anderem mit Hilfe der Anforderungsschablone von Chris Rupp verbessert werden. Zusätzlich benötigte Informationen zur Verbesserung der Requirements erhalten die Studierenden aus zusätzlich bereitgestellten Interviews. Dieses LLA folgt dem LLA zur interviewbasierten Anforderungsanalyse.


Übersicht

Ziele:

  • Erkennen von schlecht formulierten Requirements
  • Einordnung der Qualität von Requirements mit Hilfe einer Checkliste
  • Verbesserung von schlecht formulierten Requirements
  • Verstehen und Anwenden der Anforderungsschablone von Chris Rupp

Didaktische Funktion(en):

  • Wiederholung / Festigung
  • Transfer / Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrperson: Erfahrungen in Requirements Engineering; Kenntnisse der Schablone nach Chris Rupp
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Requirements Engineering

Ausstattung & Medien:


Ablauf
    1. Studierende erhalten das Übungsblatt zur Evaluation von Requirements über die Lernplattform. Zentrale Aufgabe ist es vorab beabsichtigt schlecht formulierte Anforderungen zu erkennen und zu korrigieren. Es werden Statements bzw. Interviews mit Projektbeteiligten mitgeliefert, die als Hilfestellung und Informationsquelle dienen und bei der Verbesserung der Requirements unterstützend wirken. Außerdem ist eine Checkliste für Requirements (vorgeschlagen von Chris Rupp & den Sophisten) enthalten, mit Hilfe die Studierenden die Requirements bewerten sollen.
    2. Die Studierenden dokumentieren ihre Ergebnisse in der bereitgestellten Checkliste mit Hilfe einer dreistufigen Priorisierung (vollständig erfüllt/teilweise erfüllt/nicht erfüllt) und einem Textdokument mit den verbesserten Requirements und geben dieses über die Lernplattform ab.
    3. Die Studierenden können dann mit dem Lehrenden offene Fragen klären.

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Beispiel-Aufgabe:
Bewerten Sie die nachfolgend angegebenen Anforderungen anhand der Requirements Checkliste (füllen Sie sie entsprechend aus), identifizieren Sie eventuelle unsachgemäße oder fehlerhafte Formulierungen (z.B. nicht eindeutig) und korrigieren Sie das Requirement entsprechend!

Hinweise zur Vorbereitung:

  • Erstellung von Interviews für die Anforderungsanalyse
  • Vorbereitung von nicht korrekten Requirements mit verschiedenen Fehlerarten
  • Konzeption von Aufgaben für die Studierenden
  • Erstellung eines Bewertungsschemas für die Abgaben
  • Vorbereitung einer Checkliste für Requirements

Hinweise zur Nachbereitung:

  • Korrektur der Abgaben anhand des Bewertungsschemas
  • Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen im Gebiet des Requirement Engineerings auf.

Grenzen und Schwächen:

Die Bewertung von Requirements ist oft nicht objektiv, d.h. nach besonderen Algorithmen (Vorgehensweisen) durchführbar. Dies sorgt bei Studierenden für Probleme und macht eine Bewertung nur auf Basis der Checkliste zum Teil schwierig. Eine Begründung der Studierenden, warum eine Qualitätskriterium in welchem Grad  erfüllt ist kann hier für den Dozierenden hilfreich sein.

Dozierende sollten Studierenden vermitteln, dass es in vielen Fällen im Bereich des Software Engineering, hier am Beispiel der Bewertung von Anforderungen nicht eine einzige korrekte Lösung gibt und mehrere Möglichkeiten existieren gute Anforderungen zu formulieren.


Literatur und weiterführende Hinweise
  • H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
  • M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138
  • die Sophisten (2020). Abgerufen am 08.03.2021 unter: https://www.sophist.de/unsere-themen/requirements-engineering/

Agiles Software Engineering im Team mit Scrum

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende im Rahmen einer Veranstaltung den agilen Entwicklungsprozess eines Softwareprojekts mittels Scrum kennenlernen und vollständig durchlaufen. Die Studierenden planen, konzeptionieren, implementieren und testen in diesem Lehr-Lern-Arrangement selbstständig ein eigenes Softwareprojekt und arbeiten dabei in Teams. Die Veranstaltung ist als 5-tägige Blockveranstaltung mit zwei zusätzlichen Terminen während des Semesters geplant. Dabei sollen fachliche und überfachliche Kompetenzen gleichverteilt adressiert werden.


Übersicht

Ziele:

Die Studierenden sollen auf den folgenden Gebieten Kompetenzen erlernen: Technische Kompetenzen, soziale Kompetenzen, kommunikative Kompetenzen, persönliche Kompetenzen, methodische Kompetenzen. Folgende Lernziele sollen dabei erreicht werden:

Die Studierenden sollen:

  • Verantwortung für eine Aufgabe übernehmen.
  • im Team arbeiten können.
  • Konflikte erkennen und mit ihnen umgehen können.
  • sich als Team selbst managen können.
  • alle Schritte des Projektmanagements durchlaufen können.
  • ausgewählte Methoden von Scrum selbstständig anwenden und kritisch reflektieren können.
  • die Artefakte in Scrum benennen und erstellen können.

Didaktische Funktion(en):

  • Informationsaneignung
  • Wiederholung & Vertiefung
  • Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Gruppenarbeit

Anzahl der Lernenden:

5-9 Personen pro Team, insgesamt max. 30 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrpersonen benötigen Kenntnisse über Projektmanagement, sowie sehr gute Kenntnisse in Bezug auf Planung und Umsetzung von Scrum
  • Kenntnisse im Bereich der Implementierung, Ansteuerung, und entsprechender Entwicklungsumgebungen für die eingesetzten Roboter (hier: Anki Cozmo, Vector und Lego Mindstorms NXT Roboter)

Ausstattung & Medien:

  • Mind. 1 Lehrperson, die als Experte für Team-Building Maßnahmen fungiert
  • 1 Lehrperson die als Kunde auftritt und die Projektaufgabe mitteilt
  • 2 Lehrpersonen, da hoher Betreuungsaufwand erforderlich
  • Je ein Arbeitsraum pro Team
  • Ein Seminarraum für Meetings und Präsentationen

Ablauf

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

  • Dokumentationsmaterialien (Wiki)
  • Projektmanagement Materialien
  • Software Dokumente (Produkt-Backlog, Sprint-Backlog, Testdokumente, Design-Dokument etc.)
  • Diese Aufgabe enthält Anforderungen an einen Roboter, der sowohl manuell gesteuert werden kann als auch über einen automatischen Modus verfügt, um den Weg aus einem Labyrinth zu finden.  Optionale Anforderungen sind die Aufzeichnung der Karte und die Möglichkeit, das Labyrinth auf der Grundlage der Aufzeichnung auf dem kürzesten Weg zu verlassen.

Hinweise zur Vorbereitung:

Konzeption möglichst realistischer Projektaufgabe für die Studierenden

Hinweise zur Nachbereitung:

Korrektur, Bewertung und Feedback auf die erstellten Artefakte.

Hinweise zur Dauer: Gesamt ca. 150 Stunden: 1 volle Woche (ca. 50 Stunden) + zwei Einzeltermine + Vorarbeitszeit von etwa (ca. 70-100 Stunden)


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden durchlaufen innerhalb dieser Woche einen kompletten Software Zyklus basierend auf Scrum und lernen dabei die Methoden und Prozesse von Scrum praktisch anzuwenden. Sie lernen in einem Team zu arbeiten und mit überfachlichen Problemen umzugehen. Außerdem verbessern sie ihre Fähigkeiten in der Entwicklung von Software. Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen auf.

Grenzen und Schwächen:

Zeitaufwändig in der Vor- sowie Nachbereitung (vor allem für die Lehrenden), sowie hoher Betreuungsaufwand während der Blockwoche.

Sonstige Hinweise:

Studierende können diesen Kurs ohne vorhandene Vorkenntnisse besuchen. Es werden Ein-Tages-Sprints oder Halb-Tages-Sprints empfohlen durch den relativ kurzen Zeitraum von 5 Tagen. Die Rollen des Product Owner und Scrum Master werden bewusst an Studierende vergeben, da dadurch die Planung und Einhaltung des Scrum-Prozesses beim Team liegt und ein reales Szenario erhalten bleibt.


Literatur und weiterführende Hinweise
  • Stephanie Bell (2010) Project-Based Learning for the 21st Century: Skills for the Future, The Clearing House: A Journal of Educational Strategies, Issues and Ideas, 83:2, 39-43, DOI: 10.1080/00098650903505415
  • Georgia M. Kapitsaki and Marios Christou (2014) Where Is Scrum in the Current Agile World?  In Proceedings of the 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE) pp. 1-8.
  • M. Klopp, C. Gold-Veerkamp, J. Abke, K. Borgeest, R. Reuter, S. Jahn, … D. Landes, Totally Different and yet so Alike: Three Concepts to Use Scrum in Higher Education. Association for Computing Machinery, 12–21. https://doi.org/10.1145/3396802.3396817. June 2020
  • Joseph S. Krajcik and Phyllis C. Blumenfeld (2006) Project -Based learning, In: The Cambridge Handbook of the Learning Sciences. R. Keith Sawyer (ed). Cambridge University Press
  • Yvonne Sedelmaier (2019) Basics of didactics for software engineering:  Research-based and application-oriented development and evaluation Saarbrücken: LAP LAMBERT Academic Publishing