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

Design Pattern

Kurzzusammenfassung:

Das Lehr-Lern Arrangement Design Pattern besteht aus einem dreiteiligen Übungspaket mit jeweils einer Übungseinheit der drei ausgewählten Gang of Four Design Pattern, dem Observer-, Decorator- und Command Pattern. Die Übungseinheiten haben jeweils eine zugrundeliegende Problemstellung und sind vor dem Hintergrund des Problembasierten Lernens konstruiert worden. Außerdem kommt hier das Konzept des Scaffolding zum Einsatz: Durch gezieltes Steuern des Umfangs der Unterstützung, die Studierende über die drei Übungseinheiten erhalten, soll insgesamt ein selbstgesteuerter Lernerfolg herbeigeführt werden. Mit dem Observer Pattern wird ein leichter Einstieg in das Thema des Design Pattern geschaffen. Diese Übung ist die erste einer dreiteiligen Übungsreihe, in welcher die Studierenden angeleitet werden, den theoretischen Inhalt auf praktische Anwendungen zu transferieren. Das Command Pattern ist der zweite Teil der Design Pattern Übung. In dieser Übung sollen die Studierenden das Command Pattern auf Basis eines bestehenden Rahmenprogramms verbessern und implementieren. Die Übung Decorator Pattern ist der dritte Teil der dreiteiligen Design Pattern Aufgaben. Dabei sollen die Studierenden bereits selbstständig Quellcode für Decorator Pattern implementieren.


Übersicht

Ziele:

  • Verstehen und Anwenden der Design Pattern: Observer, Decorator und Command Pattern

Didaktische Funktion(en):

  • Wiederholung & Festigung
  • Transfer & Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Partnerarbeit, Pair Programming

Anzahl der Lernenden:

2-3 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Lehrender: Erfahrungen in Software Engineering, Design Pattern
  • Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Design Pattern Erfahrungen in C++ 

Ausstattung & Medien:

  • Jede Gruppe benötigt einen PC und eine IDE mit C++ Compiler. 
  • Ausreichend PCs im CIP-Pool
  • Beamer (für Präsentation)
  • Uhr, falls Pair Programming mit Zeitgeber durchgeführt wird

Ablauf

Observer Pattern

  • 10 min Einleitung, kurze Wiederholung der Theorie
  • 15 min Beschreibung eines eigenen Observer Pattern Beispiels
  • 20 min Vervollständigung des Klassendiagramms Observer Pattern
  • 25 min Beschreibung verschiedener Prinzipien des Observer Pattern
  • 20 min Implementierung des Observer Pattern Rahmenprogramms in Pair Programming

Command Pattern

  • 10 Min Verbesserung des Klassendiagramms
  • 30 Min Implementierung der fehlenden Klassen
  • 35 Min Implementierung der konkreten Konsolenausgabe auf Basis eines Szenarios
  • 5 Min Beantwortung Abschlussfrage

Decorator Pattern

  • 10 Minuten Einleitung, kurze Wiederholung
  • 80 Minuten Eigenständige Bearbeitung des Rahmenprogramms auf Basis des Handouts

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.

Hinweise zur Vorbereitung:

  • Präsentationen
  • Rahmenprogramme vorbereiten
  • benötigte Zeit: 45 Minuten pro Übungseinheit

Hinweise zur Nachbereitung:

Keine Nachbereitung nötig

Hinweise zur Dauer: 90 Minuten pro Übungseinheit


Kritische Einordnung

Vorteile und Stärken:

Design Pattern ist einer der schwierigeren Inhalte für Software Engineering Studierende. Der Scaffolding-Ansatz ebnet schrittweise den Weg zur selbstständigen Umsetzung eines Entwurfsmusters.

Grenzen und Schwächen:

Die Bereitstellung der Rahmenprogramme erfordert es, dass die Studierenden alle die gleiche Entwicklungsumgebung verwenden, was nicht immer der Fall ist.


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
  • J.J.G. Merrienboer, P. Kirschner (2003). Taking the Load Off a Learner’s Mind. In: Instructional Design for Complex Learning. In: Educational Psychologist
  • Soska, A., Reuter, R., Hauser, F., Reiß, M. & Mottok, J. (2017). Scaffolding in der Lehre von Design Pattern. Tagungsband zum 3. Symposium zur Hochschullehre in den MINT-Fächern, 112–116.

Einsatz von Deep-Learning-Technologien für die Lehre von UML-Klassendiagrammen

Kurzzusammenfassung:

Für Studierende in Informatikstudiengängen stellt das Erlernen und selbstständige Erstellen von UML-Klassendiagrammen eine Grundvoraussetzung für das erfolgreiche Absolvieren des Studiums dar. Jedoch stellen diese Aufgaben Studierende immer wieder vor Herausforderungen. Da studentische Lösungen von einer Musterlösung abweichen und dennoch korrekt sein können, ist die Korrektur studentischer Klassendiagramme für Lehrende oft mit einem gewissen Zeitaufwand verbunden. Um Studierende bei ihrem Lernprozess und Lehrende bei der Korrektur zu unterstützen, wurde ein Prototyp für die Erkennung und syntaktische Analyse von UML-Klassendiagrammen erstellt. Während den Übungsstunden erhalten Studierende textuelle Beschreibungen (Anforderungen) und erstellen anhand dieser ein Klassendiagramm. Der Prototyp kann Studierenden während den Übungsstunden ein erstes Feedback zu den von ihnen erstellten Klassendiagrammen liefern.


Übersicht

Ziele:

  • Die Studierenden erhalten einen Prototypen, der ihnen ein erstes Feedback zu erstellten Lösungen gibt.
  • Die Studierenden können ihre Lösungen durch individuelles Feedback verbessern.
  • Die Studierenden können anhand des individuellen Feedbacks langfristig ihre Kompetenzen bei der Erstellung von UML-Klassendiagrammen verbessern.
  • Lehrpersonal kann entlastet werden.
  • Studierende können auch zuhause, wo kein Lehrpersonal anwesend ist, üben und Feedback erhalten.

Didaktische Funktion(en):

  • Wiederholung & Festigung
  • Transfer & Anwendung
  • Beurteilung
  • Rückmeldung & Feedback

Hintergrund / didaktisch-methodische Einordnung:

Die in der Kurzzusammenfassung angeführten Punkte motivierten die Entwicklung eines Prototyps zur Erkennung und syntaktischen Analyse von UML-Klassendiagrammen. Da sich Deep-Learning-Technologien aufgrund ihrer rasanten Entwicklung in Bereichen wie Bild- und Texterkennung bewähren konnten, wurden diese für die Entwicklung herangezogen.

Sozialform(en):

Einzelarbeit

Anzahl der Lernenden:

ab 1 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

Lernende benötigen Vorkenntnisse zu den einzelnen Diagrammelementen der UML-Klassendiagramme und deren mögliche Beziehungen zueinander.
Eine Lehrperson ist nicht zwingend erforderlich, aber dennoch hilfreich, falls es auf Seite der Studierenden zu weiterführenden Fragen kommt.

Ausstattung & Medien:

PC mit Grafikkarte, 1 Beamer


Ablauf
Abb. 1: Beispiel für ein textuelles Feedback an Studierende

Beispiele oder Materialien:

Beispiel einer textuellen Aufgabe:

Ein Spieler meldet sich mit Name und Passwort beim Spiel an.
Dann kann er aus drei verschiedenen Charakteren seine Spielfigur wählen: 
Zauberer, Fee, Zwerg. Diese können zwei 
Waffen besitzen, die der Spieler aus der Menge 
Axt, Lanze, Dreizack und Pfeil und Bogen wählen 
kann. Waffen haben einen Schadenswert und einen
 Verteidigungswert. Außerdem kann ein Character
 eine Tasche mitführen, in der verschiedene 
Gegenstände gesammelt werden können, die man im 
Laufe des Spiels findet (Zauberbuch, Stein, 
Feder, Urkunde). Feinde des Character können 
Ork, Magier und Ritter sein. Diese können 
ebenfalls bis zu zwei der obigen Waffen besitzen.


a.) Beschreiben Sie die Klassen in UML-Notation mit sinnvollen Attributen und Methoden.
b.) Fügen Sie sinnvolle Vererbungsbeziehungen ein.
c.) Fügen Sie weitere Beziehungen zwischen den Klassen mit Multiplizitäten ein.
Abb. 2: Beispiel für die Erkennung von UML-Elementen innerhalb eines Diagramms

Hinweise zur Vorbereitung:

Konzeption von textuellen Beschreibungen.
Vorbereitung einer Beispiellösung, mit der der Prototyp studentische Lösungen vergleichen kann.

Hinweise zur Nachbereitung:

Am Ende der Übungsstunde sollte mit den Studierenden eine gemeinsame Beispiellösung erstellt werden.

Hinweise zur Dauer: Insgesamt ca. 50 Minuten


Kritische Einordnung

Vorteile und Stärken:

Studierende erhalten ein erstes und individuelles Feedback zu ihren erstellten UML-Klassendiagrammen.

Grenzen und Schwächen:

PC mit Grafikkarte muss verfügbar sein. Erstellte studentische Lösungen können bisher nur mit einer Beispiellösung verglichen und Differenzen an Studierende kommuniziert werden.

Sonstige Hinweise:

Das hier beschriebene Lehr-Lern-Arrangement beschreibt, wie ein erstellter Prototyp Studierenden während den Übungsstunden ein erstes und individuelles Feedback zu den von ihnen erstellten Klassendiagrammen liefern kann. Der Prototyp verwendet hierfür Deep-Learning-Technologien. Dadurch können sowohl Studierende unterstützt als auch Lehrpersonen entlastet werden.


Literatur und weiterführende Hinweise

Huber, F.; Hagel, G. (2020): Work-in-Progress: Towards detection and syntactical analysis in UML class diagrams for software engineering education, In: Global Engineering Education Conference (EDUCON), Porto, IEEE.

Redmon, J.; Farhadi, A. (2018): YOLOv3: An Incremental Improvement, arXiv, https://arxiv.org/abs/1804.02767

Gruppenpuzzle – Prüfungsvorbereitung Software Engineering

Kurzzusammenfassung:

In diesem LLA sollen die Studierenden durch eine zweistündige Veranstaltung auf die am Semesterende stattfindende Prüfung vorbereitet werden. Dazu erhalten die Studierenden eine Klausur aus vorherigen Semestern. Sie werden dann nach der Methodik des Gruppenpuzzles in Gruppen eingeteilt. Jede Gruppe bearbeitet eine der Klausuraufgaben, erstellt eine Lösung und stellt diese Lösung im Anschluss im Plenum vor. Die anderen Gruppen haben dann die Möglichkeit Fragen zu stellen, um so eine gemeinsame Wissensbasis für die Klausur am Ende des Semesters zu gewährleisten.


Übersicht

Ziele:

  • Wiederholung und Vertiefung des Vorlesungsstoffs aus der Software Engineering Vorlesung
  • Aktive Einbindung der Studierenden in die Prüfungsvorbereitung

Didaktische Funktion(en):

  • Wiederholung & Festigung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Kleingruppenarbeit (3-5)

Anzahl der Lernenden:

10 – 50 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Der Dozierende sollte mit den Inhalten des Software Engineering und der Methodik des Gruppenpuzzles vertraut sein. 
  • Die Studierenden sollten die Vorlesung zu Software Engineering besucht haben

Ausstattung & Medien:

  • PC für die Präsentation von Folien bzw. der Aufgaben
  • Beamer
  • Flipchart(s) und/oder Flipchartpapier zur Vorstellung der Aufgaben
  • Optional: Online-Lernplattform wie z.B. Moodle

Ablauf

Hinweise zur Vorbereitung:

Zur Vorbereitung müssen die Aufgabenhandouts in ausreichender Menge zur Verfügung gestellt werden

Hinweise zur Nachbereitung:

Keine Nachbereitung nötig

Hinweise zur Dauer: Eine Vorlesungseinheit mit 90 min.


Kritische Einordnung

Vorteile und Stärken:

  • Studierende erhalten eine gemeinsame Wissensbasis vor der Klausur sowie einen Einblick in mögliche Aufgabentypen
  • Aktive Einbindung der Studierenden in den Vorlesungsablauf

Grenzen und Schwächen:

90 min. sind knapp für detaillierte Bearbeitung und Besprechung der kompletten Klausur

Sonstige Hinweise:

Nachfrage nach Altklausuren kann von Dozierenden-Seite gesteuert werden


Literatur und weiterführende Hinweise

R. M. Felder und M. J. Prince (2006): “Inductive teaching and learning methods: Definitions, comparisons, and research bases,” J. Eng. Educ., vol. 95, no. 2, S. 123–138

Requirements Engineering im virtuellen Raum

Kurzzusammenfassung:

In diesem Lehr Lern Arrangement wird ein rollenspielartiges Lehrkonzept vorgestellt, welches ein Virtual-Reality Szenario (VR) zur Verbesserung eines akademischen Software-Engineering-Kurses am Beispiel des Requirements Engineering beschreibt. Es wird ein virtueller Raum vorgestellt, in dem mögliche Kunden sitzen, die Anforderungen an eine Software haben. Außerdem sind dort Hilfsmittel platziert, die dabei helfen sollen Anforderungen aufzustellen.


Übersicht

Ziele:

  • Bereitstellung eines „realen“ Szenarios im Rahmen von VR
  • Studenten sollen theoretisch erworbenes Wissen anwenden
  • Studenten sollen mehr fürs Lernen motiviert werden

Didaktische Funktion(en):

  • Anwendung von theoretischem Wissen zur Erhebung von Anforderungen
  • Transfer & Anwendung
  • Rückmeldung & Feedback

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Einzelarbeit

Anzahl der Lernenden:

1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson muss eine VR Brille bedienen können und entsprechende Kenntnisse über VR und Requirements Engineering besitzen

Ausstattung & Medien:

  • VR Klassenzimmer
  • HTC Vive

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.

Abbildung 1: Darstellung einer Aufgabe
Abbildung 2: Darstellung eines Hilfsmittels

Beispielaufgabe:

  • Beispiel-Anfangsaufgabe: „Sehen Sie sich das folgende Video über ein Projekttreffen an. Nennen Sie alle möglichen Personen, die ein Interesse an dem Projekt haben, und definieren Sie ihre Interessen“.
  • Beispiel-Konsoliderungsaufgabe: „Lesen Sie den Abschnitt über Requirements Engineering aus Sommerville und identifizieren Sie die wichtigsten Schritte“.
  • Beispiel-Übungsaufgabe: „Nennen Sie fünf Qualitätskriterien für Anforderungen.“
  • Beispiel-Anwendungsaufgaben: „Gehen Sie in Besprechungsraum 2. Fünf Kunden warten auf Sie, um ihre Wünsche für ihre neue Software zu erläutern. Es ist Ihre Aufgabe, alle Anforderungen zu extrahieren und dem Requirements Engineering Prozess zu folgen“.
  • Beispiel-Problemlöseaufgabe: „Gehen Sie zum Besprechungsraum 3. In diesem Raum wartet ein Kunde auf Sie. Er behauptet, dass sein Produkt nicht wie vorgesehen funktioniert. Leiten Sie mögliche Probleme mit den Anforderungen ab und erklären Sie diese Ihrem Kunden.“
  • Beispiel-Evaluationsaufgabe: „Lesen Sie die bereitgestellten Fallstudien zu den Prozessen des Requirements Engineering in zwei industriellen Softwareprojekten. Vergleichen Sie die beiden Fälle: Diskutieren und bewerten Sie sie hinsichtlich ihrer Ansätze und Ergebnisse“.

Hinweise zur Vorbereitung:

Konzeption von Lernaufgaben, welche für VR Umwelt besonders geeignet sind.

Hinweise zur Nachbereitung:

Keine

Hinweise zur Dauer: Insgesamt ca. 90 Minuten


Kritische Einordnung

Vorteile und Stärken:

  • Lernen findet Ortsunabhängig statt wegen VR
  • Motivation der Studierenden
  • Alternative zum klassischen Unterrichten
  • Lernen findet in einem realitätsnahem Umfeld statt

Grenzen und Schwächen:

Die Einbettung von VR-Räumen in den Lehrkontext ist sehr aufwändig. Neben der Konzeption und Umsetzung des Settings, wird Platz und Infrastruktur benötigt. Im Gegensatz zu AR muss für VR der virtuelle Raum durch Stützen aufgespannt werden, es wird entsprechender freier Raum benötigt.


Literatur und weiterführende Hinweise
  • Hagel,G. Müller-Amthor, M. Landes, D. and  Sedelmaier, Y. (2018): “Involving customers in requirements engineering education: Mind the goals!”. in: Proceedings of the 3rd European Conference of Software Engineering Education – ECSEE18, S. . 113–121, ACM Press.
  • Brabrand, C., & Dahl, B. (2007): Constructive alignment and the SOLO taxonomy: a comparative study of university competences in computer science vs. mathematics. Seventh Baltic Sea Conference on Computing Education Research Koli Calling 2007, 88, S. 3–17.
  • Müller, L., Jahn, S., Reuter, R., & Mottok, J. (2018): A Task Design Concept for a Virtual Classroom for Requirements Engineering Education. In L. G. Chova, A. L. Martínez, & I. C. Torres (Hrsg.), ICERI2018 Proceedings (Bd. 1, S. 911–920). Sevilla: IATED Academy.

Rollenspiel Kaffeeautomat

Kurzzusammenfassung:

In diesem LLA sollen die Studierenden die Implementierungs- und Modellierungskonzepte eines Zustandsautomaten aktiv erleben. Im Rahmen zweier Vorlesungseinheiten wird dabei ein Kaffeeautomat schrittweise entwickelt. Ausgehend von einer Plenumsdiskussion wird zunächst „unsauberer“ Code erarbeitet, der im Anschluss durch eine Gruppenarbeit sowie ein Rollenspiel verbessert wird. Zum Abschluss wird die Methode Nested-Switch vorgestellt, durch welches eine „saubere“ Methode vorgestellt wird.


Übersicht

Ziele:

  • Verstehen der Notation und Funktion von UML-Zustandsautomaten
  • Umsetzung eines UML-Zustandsautomaten in Code
  • Verstehen des Implementierungskonzepts Nested-Switch

Didaktische Funktion(en):

  • Einstieg & Aktivierung
  • Wiederholung & Festigung
  • Transfer & Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Mischform aus Gruppenarbeit und Frontalunterricht

Anzahl der Lernenden:

10-100 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Dozierende: Moderationsfähigkeit; Erfahrungen im Software Engineering und der Methode des Rollenspiels
  • Lernende: Erste Erfahrungen in der Programmierung

Ausstattung & Medien:

  • PC (für die begleitende PPT)
  • Unterlagen zur Durchführung des Rollenspiels mit visueller Darstellung der Rollen
  • Beamer (Für das Live-Coding sowie die Begleitung des Rollenspiels)
  • Genügend Raum zwischen Tafel und Bänken zur Durchführung des Rollenspiels

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.

Arbeitsauftrag
Beispiellösung

Hinweise zur Vorbereitung:

  • Unterlagen für das Rollenspiel vorbereiten
  • Benötigte Zeit: 60 Minuten

Hinweise zur Nachbereitung:

Keine Nachbereitung nötig

Hinweise zur Dauer: 90 min pro Vorlesung, Gesamt: 180 Minuten


Kritische Einordnung

Vorteile und Stärken:

  • Die Studierenden werden aktiv in die Vorlesung eingebunden
  • Die Studierenden erarbeiten lernerzentriert die Inhalte der Vorlesung

Grenzen und Schwächen:

Die Anwendung der Methode des Rollenspiels ist nicht für alle Lerntypen geeignet


Literatur und weiterführende Hinweise

Prince, M. J. & Felder, R. M. (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138.

Software Engineering II

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende im Rahmen einer Veranstaltung den kompletten Entwicklungsprozess eines Softwareprojekts durchlaufen. Diese Veranstaltung ist als Blockveranstaltung geplant, mit mehreren Blöcken verteilt über das Semester. Die einzelnen Blöcke werden jedes Semester neu definiert, abhängig von der Anzahl der Semesterwochen und der Teilnehmerzahl. Ziel der Veranstaltung ist die eigenständige Bearbeitung eines Softwareprojekts, wahlweise mit einer zur Verfügung gestellten Technologie des LaS3. Solche Technologien sind beispielsweise Augmented Reality, Virtual Reality, Apps, NXTs, Eye Tracking, Scheduling, Safety, Games, Quadcopter. Dabei steht je ein Mitarbeiter des LaS3 als „Vertragspartner“ für eine Technologie zur Verfügung. Die Studierenden arbeiten in Gruppen, welche mit dem Vertragspartner des LaS3 des einen Vertrag bzw. Zielvereinbarungen über den Inhalt der Arbeit schließt. Dabei werden Leitlinien und Vertrag definiert.


Übersicht

Ziele:

  • Die Studierenden sollen qualitativ hochwertige Artefakte entwickeln.
  • Die Studierenden sollen den gesamten Softwareentwicklungsprozess schrittweise durchlaufen und selbst anwenden können.
  • Die Studierenden sollen ausgewählte Methoden des Software Engineering Prozesses selbstständig anwenden und kritisch reflektieren können.

Didaktische Funktion(en):

  • Wiederholung & Vertiefung
  • Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Kleingruppenarbeit (3-5)

Anzahl der Lernenden:

  • 4 Personen pro Gruppe / Team
  • insgesamt maximal 30 Personen

Voraussetzungen und Ressourcen

Voraussetzungen:

  • 2 Lehrpersonen, da hoher Betreuungsaufwand erforderlich
  • je einen Betreuer für die gewählte Technologie des Teams

Ausstattung & Medien:

  • Online-Meeting Tool
  • Moodle für Abgaben (wie Wiki Einträge)
  • abhängig von der Themenwahl weitere Hardware/Software (z.B. Nao, NXT, Vector Roboter)

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.

Beispielausschreibungen:

Beispielausschreibung 1
Beispielausschreibung 2

Hinweise zur Vorbereitung:

  • Konzeption von Ausschreibungstexten
  • Betreuersuche

Hinweise zur Nachbereitung:

Korrektur, Bewertung und Feedback auf die erstellten Artefakte.

Hinweise zur Dauer: Insgesamt 150 Stunden, davon 50 Stunden Präsenzzeit für organisatorisches, die beiden Blockveranstaltungen und die verschiedenen Betreuertermine & 100 Stunden selbstorganisiertes Arbeiten für Vorbereitung des Workshops und die einzelnen Meilensteine.


Kritische Einordnung

Vorteile und Stärken:

Es entstehen qualitativ hochwertigere Projektarbeiten als in einer Woche

Grenzen und Schwächen:

Hoher Arbeitsaufwand für Lehrperson während des Semesters durch die Betreuung der einzelnen Gruppen

Sonstige Hinweise:

Die Veranstaltung wurde im Gegensatz zur NXT Blockwoche semesterbegleitend erprobt. Hier liegt auch der größte Unterschied. Ein Projekt der Blockwoche lief im Wesentlichen in einer Woche ab, das hier beschriebene über ein gesamtes Semester hinweg.


Literatur und weiterführende Hinweise
  • Krajcik, J. S., Blumenfeld P. C. (2006). Projekt based Learning. In: The Cambridge Handbook of the Learning Sciences. (2006).  R. Keith Sawyer (ed). Cambridge University Press
  • Bell, S. (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

Software Engineering im Team mit Anki Cozmo und Vektor Robotern

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende im Rahmen einer Veranstaltung den kompletten Entwicklungsprozess eines Softwareprojekts mit einem Anki Cozmo oder Vector. 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:

  • Verantwortung für eine Aufgabe übernehmen.
  • im Team arbeiten können.
  • Konflikte erkennen und mit ihnen umgehen können.
  • sich als Team selbst managen.
  • den gesamten Softwareentwicklungsprozess schrittweise durchlaufen und selbst anwenden können.
  • einen für eine speziellen Anwendungsfall geeigneten Softwareentwicklungsprozess identifizieren und durchführen können.
  • ausgewählte Methoden des Software Engineering Prozesses selbstständig anwenden und kritisch reflektieren können.
  • Templates für verschiedene Prozesse im Projektmanagement benennen und ausfüllen können.

Didaktische Funktion(en):

  • Wiederholung & Vertiefung
  • Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Sozialform(en):

Gruppenarbeit

Anzahl der Lernenden:

4-7 Personen pro Gruppe / Team, insgesamt max. 30 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrpersonen benötigen Kenntnisse über:

  • Projektmanagement
  • relevante Algorithmen für die Aufgabenstellung
  • eingesetzte Technologie(n) (Implementierung, Konfiguration, Kompatibilität)

Ausstattung & Medien:


Ablauf

Hinweise zur Vorbereitung:

  • Die Einarbeitung in die Funktion und Implementierung der Roboter muss bei Planung und Bearbeitung berücksichtigt werden
  • Templates für die Dokumentation der Arbeitsbereiche sind von Vorteil, um den Studierenden einen Rahmen zu geben und den Umfang und Inhalt einzugrenzen
  • Detaillierte Planung des Ablaufs der Blockwoche nötig
  • Erstellen von Projektleiter-Mappen mit allen nötigen Infos für die Teams in der Blockwoche von Vorteil

Hinweise zur Nachbereitung:

Korrektur, Bewertung und Feedback auf die erstellten Artefakte.

Hinweise zur Dauer: Insgesamt 150 Stunden, davon zwei einzelne Termine und Vorarbeiten von etwa 70-100 Stunden und die Projektwoche selbst (50 Stunden).


Kritische Einordnung

Vorteile und Stärken:

Die Studenten durchlaufen innerhalb dieser Woche einen kompletten Software Zyklus. Sie lernen in einem Team zu arbeiten und mit überfachlichen Problem umzugehen. Außerdem verbessern sie ihre Fähigkeiten in der Entwicklung von Software.

Die Studenten können agile Projektmanagement Methoden anwenden.

Grenzen und Schwächen:

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


Literatur und weiterführende Hinweise
  • Krajcik, J. S., Blumenfeld P. C. (2006). Projekt based Learning. In: The Cambridge Handbook of the Learning Sciences. (2006).  R. Keith Sawyer (ed). Cambridge University Press
  • Bell, S. (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