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

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.

Einführung von ethischen Themen der Softwareentwicklung mit Fallbeispielen

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende sich mit dem Thema Ethik innerhalb der Disziplin Software Engineering auseinandersetzen. Die Studierenden erhalten einerseits theoretischen Input und andererseits Fallbeispiele zur Bearbeitung ethischer Themen im Software Engineering.


Übersicht

Ziele:

  • Die Studierenden sollen für ethische Themen im Software Engineering und deren Tragweite sensibilisiert werden
  • Die Studierenden verstehen die Wichtigkeit des Themas Ethik
  • Die Studierenden kennen ethische Leitlinien der Gesellschaft für Informatik oder IEEE und können diese verstehen und anwenden
  • Die Studierenden sollen ihre Reflexionsfähigkeit stärken

Didaktische Funktion(en):

  • Informationsaneignung
  • Sensibilisierung

Hintergrund / didaktisch-methodische Einordnung:

Die Ethik benennt den Bereich der Normenbegründung, die dabei z.B. auf „oberste Normen“ oder „Prinzipien“ zurückgreift. Die Moral benennt den Ort, an dem Ethik praktisch wird. Ethik beschäftigt sich also damit, in welchem Moment eine Handlung zu einer moralisch guten Handlung wird. Dabei spielen Begriffe, wie Moral, das Gute, Pflicht, Sollen, Erlaubnis, Glück etc. eine Rolle. Die Ethik beschäftigt sich methodisch mit moralischen Handlungen und will zu argumentativ begründeten Ergebnissen gelangen aber keine Handlungsanweisungen vorschreiben. Es gibt verschiedene Leitlinien für ethisches Handeln von unterschiedlichen Organisationen. Im Bereich Software Engineering stehen beispielsweise die ethischen Richtlinien der Gesellschaft für Informatik zur Verfügung. Dieses LLA zum Thema Ethik in der Softwareentwicklung kann dem theoretischen Rahmen des induktiven Lernens, konkret dem problembasierten Lernen, zugeordnet werden.

Induktives Lehren und Lernen ist ein umfassender Begriff, welcher verschiedene Methoden wie beispielsweise forschungsbasiertes Lernen, problembasiertes Lernen, projektbasiertes Lernen, fallbasiertes Lernen, oder Just-in-time-teaching umfasst. Eine Gemeinsamkeit dieser Ansätze ist das lerner-zentrierte Design, was bedeutet, dass die Verantwortung für das eigene Lernen, im Vergleich zu traditionellen Lehr/-Lernansätzen mehr auf Seiten des Lernenden liegt (Prince, M. J., Felder, R. M., 2006).  Der Einsatz induktiver Lehrmethoden wird gestützt von Forschungsergebnissen, welche besagen, dass Studierende lernen, indem sie neue Informationen in bestehende kognitive Strukturen einordnen. Wenn es nur wenige Verbindungen zum bestehenden Wissen der Studierenden gibt, ist es unwahrscheinlich, dass Lernen stattfinden kann. Induktiven Lehrmethoden liegt der Konstruktivismus zugrunde, welcher auf der Ansicht basiert, dass jeder Lernende seine eigene Version der Realität konstruiert, statt bloßes Wissen zu absorbieren, welches von Seiten der Lehrkräfte präsentiert wird.

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

ab 1 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

Mind. 1 Lehrperson

Ausstattung & Medien:

  • Seminarraum
  • 1 Beamer
  • 1 Flipchart

Ablauf

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Beispiel Einführungsaufgabe:

Die nächsten 5 Minuten haben sie Zeit, frei darauf los-zuschreiben, was ihnen zu Ethik ganz allgemein einfällt, was sie mit dem Begriff Ethik assoziieren.

Beispiele Wiederholung:

An welcher Stelle wird der Punkt „Professionalität“ in den Leitlinien der GI erwähnt?

Wie schätzen sie die Thematik. „Ethik im SE ein?“

Beispiel Fallbeispielaufgabe:

Bearbeiten Sie mit Hilfe des Diskussionsschemas (siehe Weber-Wulff, D. & Kollegen (2015)) den Fall „Zivilitäre Forschung“ (https://gewissensbits.gi.de/) und präsentieren sie ihre Ergebnisse in der Gruppe.

Hinweise zur Vorbereitung:

  • Konzeption von Aufgaben und Vorlesung Folien zum Thema Ethik
  • Suche & Auswahl eines geeignetem Fallbeispieles (z.B. hier: https://gewissensbits.gi.de/)

Hinweise zur Nachbereitung:

Die abgegebenen Aufgaben müssen kontrolliert und bewertet werden.

Hinweise zur Dauer: Insgesamt 2 Vorlesungen


Kritische Einordnung

Vorteile und Stärken:

Die Studierenden werden für zukünftige Arbeitsverhältnisse sensibilisiert.

Grenzen und Schwächen:

Die Bewertung der abgegebenen Aufgaben ist schwierig und darf nicht im Sinne einer inhaltlichen Beurteilung einer Meinung eines Studierenden erfolgen

Sonstige Hinweise:

Dieses Fach ist prüfungsrelevant und fließt somit in die Bewertung mit ein.

Fälle: https://gewissensbits.gi.de/

Leitlinien: https://gewissensbits.gi.de/ethische-leitlinien/


Literatur und weiterführende Hinweise

Schmidt, H.G. (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16

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

Weber-Wulff, D., Class, C., Coy, W., Kurz, C., & Zellhöfer, D. (2015). Gewissensbisse: Ethische Probleme der Informatik. Biometrie-Datenschutz-geistiges Eigentum. transcript Verlag.

Pieper, A. (2003): Einführung in die Ethik. 5., überarb.und aktualisierte Aufl. Tübingen: Francke (UTB für Wissenschaft Uni-Taschenbücher Philosophie, 1637).

Mathwig, F. (2000): Technikethik Ethiktechnik. Was leistet angewandte Ethik? Univ., Diss. u.d.T.: Mathwig, Frank: Technikethik im Spannungsfeld neuer Technologien und ethischer Tradition–Marburg, 1998. Stuttgart: Kohlhammer (Forum Systematik, 3).

Weber-Wulff, D. (2009): Gewissensbisse. Ethische Probleme der Informatik ; Biometrie -Datenschutz -geistiges Eigentum. Bielefeld: Transcript-Verl. (Kultur-und Medientheorie).

Entwicklungsprozesse Übung mit „überfordernder“ Aufgabe

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Vorteile und Nutzen des Einsatzes von Entwicklungsprozesse nachvollziehen können. Hierfür werden unterschiedliche Aufgabenformate vorbereitet, welche sich in Bezug auf die Komplexität unterscheiden und steigern. Die Studierenden versuchen, diese Aufgaben zu lösen.


Übersicht

Ziele:

  • Die Studierenden können die Motivation, Gründe und Vorteile von Entwicklungsprozessen herausarbeiten
  • Die Studierenden verstehen, warum es Entwicklungsprozesse gibt
  • Die Studierenden verstehen die Wichtigkeit bzw. den Vorteil bei der Entwicklung von Software mithilfe von Entwicklungsprozessen

Didaktische Funktion(en):

  • Einstieg & Aktivierung
  • Informationsaneignung

Hintergrund / didaktisch-methodische Einordnung:

Das LLA zum Thema Softwareentwicklungsprozesse kann dem theoretischen Rahmen des induktiven Lernens, konkreter dem problembasierten Lernen zugeordnet werden. Induktives Lehren und Lernen ist ein umfassender Begriff, welcher verschiedene Methoden wie forschungsbasiertes Lernen, problembasiertes Lernen (PBL), projektbasiertes Lernen, fallbasiertes Lernen, Just-in-time-teaching etc. umfasst. Eine Gemeinsamkeit dieser Ansätze ist das lerner-zentrierte Design, was bedeutet, dass die Verantwortung für das eigene Lernen mehr auf Seiten des Lernenden liegt, im Vergleich zu traditionellen Lehr/-Lernansätzen (M. J. Prince & R. M. Felder (2006)).

Für problembasiertes Lernen (PBL) stellt eine authentische und komplexe Problemstellung die Ausgangsgrundlage dar. Dabei lernen die Lernenden in Form von Gruppenarbeit, Fragestellungen zum Problem zu finden und wichtige Begriffe des Problems ausfindig zu machen und zu definieren. Anschließend wird das Problem analysiert, Bestandteile des Problems werden mit bestehendem Wissen verknüpft und Hypothesen können aufgestellt werden. Diese Hypothesen werden bewertet und priorisiert (H.G. Schmidt (1983)).  

Sozialform(en):

Partnerarbeit, Gruppenarbeit (3-5)

Anzahl der Lernenden:

ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson benötigt Hintergrundwissen zu Entwicklungsprozessen

Ausstattung & Medien:

  • Seminarraum
  • Papier/Flipchartpapier (entspr. Flipchart-Stifte)
  • Flipchart/Magnete

Ablauf

Beispiele oder Materialien:

Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Beispielaufgabe:

Aufgabe 2:

Einem oberpfälzischen Automobilzulieferer stehen mehrere Fahrzeuge zur Verfügung, die für Dienstreisen genutzt werden können. Dieser Automobilzulieferer ist sehr fortschrittlich und will auf modernere Möglichkeiten zur Verwaltung des eigenen Fuhrparks setzen als Stift und Papier, oder Verwaltung über Kalender. Unterstützen Sie als zukünftige Software-Engineers den lokalen Automobilzulieferer bei diesem Vorhaben und entwickeln Sie in Teams von 4-6 Personen ein Softwareprogramm zum Management des Fuhrparks.

Aufgabe 3:

Vermutlich konnten Sie die erste Aufgabe jede(r) für sich recht problemlos lösen, während die Zweite eine größere Herausforderung war. Überlegen Sie sich in den Gruppen aus Aufgabe 2, warum das so war.

  1. Was sind die wesentlichen Unterschiede zwischen dem Primzahlprüfer und dem Fuhrparkmanagementsystem?
  2. Wie würden Sie einem Kunden gegenüber begründen, warum es unter den gegebenen Voraussetzungen nicht möglich ist, eine solche Software innerhalb einer Stunde zu entwickeln?
  3. Was sind Aufgaben, die Sie erledigen müssten, wenn Sie in Viererteams erfolgreich ein solches Fuhrparkmanagementsystem entwickeln wollten?

Halten Sie Ihre Ergebnisse auf Karten fest und stellen Sie diese im Anschluss kurz im Plenum vor. Achten Sie dabei darauf, dass Sie pro Karte nur einen Aspekt notieren und dass Sie groß und lesbar schreiben.

Hinweise zur Vorbereitung:

Konzeption von Aufgaben mit geeignetem Programmcode. VoKonzeption von Aufgaben (sehr einfach vs. Sehr komplex), Vorbereitung von Moderationsmaterial

Hinweise zur Nachbereitung:

Keine

Hinweise zur Dauer: Insgesamt ca. 90 Minuten


Kritische Einordnung

Vorteile und Stärken:

  • Die Studierenden erarbeiten sich selbständig Wissen.
  • Die Studierenden werden für den Einsatz von Entwicklungsprozessmodellen sensibilisiert (durch „negative“ Erfahrung).

Grenzen und Schwächen:

  • Die Studierenden verstehen vielleicht nicht auf Anhieb auf was man hinaus will
  • Der Aufgabentyp „Gruppenarbeit“ mit Brainstorming ist für Studierende aus Ingenieursstudiengängen möglicherweise unbekannt

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