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

Aufbau einer Continuous Delivery-Pipeline in der Informatiklehre

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Continuous Delivery (CD) kennenlernen. CD ist eine Sammlung von Techniken, Prozessen und Werkzeugen zur Verbesserung des Softwareauslieferungsprozesses. Das Ziel ist es, dass die Studierenden in der Lage sind (1) den Begriff CD sowie die damit verbundenen Prozesse zu erklären, (2) eine CD-Pipeline unter Anleitung aufzubauen sowie (3) die notwendigen Tools zu installieren, konfigurieren und anwenden zu können. Hierfür sollen die Teilnehmenden eigenständig eine CD-Pipeline für einen Beispielservice entwickeln und somit ein tieferes Verständnis erhalten.


Übersicht

Ziele:

  • Die Studierenden verstehen den Begriff CD sowie die damit verbundenen Prozesse und können diese erklären.
  • Die Studierenden können eine CD-Pipeline unter Anleitung aufbauen.
  • Die Studierenden können die notwendigen Tools installieren, konfigurieren und anwenden.

Didaktische Funktion(en):

  • Einstieg & Aktivierung
  • Informationsaneignung
  • Transfer & Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Continuous Delivery spielt in der professionellen Softwareentwicklung eine große Rolle. Das übergeordnete Ziel ist es, die Zeit bis zur Markteinführung einer Anwendung zu verkürzen und gleichzeitig die Qualität dieser Software zu erhöhen (vgl. Wolff 2016, Humble & Farley 2010). Da der Aufbau einer Pipeline sehr aufwändig ist, ist CD häufig kein Bestandteil der Hochschullehre. Neben dem fachlichen Wissen wird Problemlösefähigkeit gefördert sowie die Fähigkeit sich eigenständig komplexe Themen anzueignen (siehe auch Greising, Bartel & Hagel 2018).

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

  • Mind. 1 Lehrperson, besser 2 Lehrpersonen, da hoher Betreuungsaufwand erforderlich
  • Lehrperson(en) benötigen gute Kenntnisse im Bereich CD
  • Lernende benötigen Vorkenntnisse im Bereich Softwarearchitektur
  • Lernende müssen sich intensiv mit dem Lernstoff beschäftigen, da ein hoher Selbstlernteil besteht

Ausstattung & Medien:

  • Seminarraum
  • Je nach Anzahl der Lernenden aktuelle PC-Hardware
  • 1 Beamer
  • Internetverbindung

Ablauf

Beispiele oder Materialien:

Aufgabe zur Entwicklungsphase 2: Deployment der Webseite:
a.) Legen Sie in Eclipse ein Projekt "Parcel-Webserver" an
b.) Laden Sie den bestehenden Quellcode der Website aus Moodle herunter und integrieren Sie diesen in das soeben erstellte Projekt
c.) Exportieren Sie das Projekt "Parcel-Webserver" als *.war File auf ihren Tomcat-Webserver
d.) Testen Sie ob die Weboberfläche unter: http://localhost:8080/ParcelWebserver/ verfügbar ist

Hinweise zur Vorbereitung:

Konzeption von Aufgaben und möglichen Tutorials für die Studierenden.
Pipeline muss funktionsfähig vorbereitet sein.

Hinweise zur Nachbereitung:

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

Hinweise zur Dauer: Insgesamt 1 Semester (für den vollständigen Aufbau der Pipeline).


Kritische Einordnung

Vorteile und Stärken:

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

Grenzen und Schwächen:

Sehr zeitaufwändig in der Vor- sowie Nachbereitung (Gilt für Lehrenden und Studierenden.)

Sonstige Hinweise:

Diese Variante sollte nur mit erfahrenen Studierenden (z.B. Master) durchgeführt werden, die bereits einen sehr fortgeschrittenen Studienverlauf haben (aufgrund der hohen Komplexität).
Zudem sollte versucht werden die Pipeline soweit wie möglich zu vereinfachen (z.b. vorgebende Skripte, Quellcode etc.) Der Hauptfokus sollte auf der Entwicklung der Pipeline liegen und nicht durch zusätzliche Aufgaben erschwert werden.


Literatur und weiterführende Hinweise
  • Greising, L.; Bartel, A.; Hagel, G. (2018): Introducing a Deployment Pipeline for Continuous Delivery in a Software Architecture Course., In: Proceedings of the 3rd European Conference of Software Engineering Education.
  • Humble, J.; Farley, D. (2010): Continuous delivery: reliable software releases through build, test, and deployment automation. Addison-Wesley, Upper Saddle River, NJ. 
  •  Wolff, E. (2016): Continuous delivery: der pragmatische Einstieg. dpunkt. verlag. 

Bearbeitung von Aufgaben innerhalb vorlesungsbegleitender Übungen

Kurzzusammenfassung:

In diesem Lehr-Lern-Arrangement geht es um Lernaufgaben, welche innerhalb einer vorlesungsbegleitenden Übungsstunde von den Studierenden bearbeitet werden. Der gesamte Aufgabenprozess (Einführung, Bearbeitung, Besprechung und Vertiefung sowie Abschluss) findet direkt innerhalb der Übung statt. Die Studierenden erhalten zu Beginn Aufgabenblätter und bearbeiten diese. Die Übungsleitung steht bei Fragen zur Verfügung und bespricht die Lösungen vollständig.


Übersicht

Ziele:

  • Die Studierenden beschäftigen sich intensiv mit den Vorlesungsinhalten in der Übung.
  • Die Studierenden werden in den Übungen selbst aktiv und bearbeiten gestellte Aufgaben.
  • Die Studierenden erhalten direkte Rückmeldung zu ihren Lösungen und müssen nicht bis zur nächsten Besprechung (i.d.R. eine Woche später) warten.

Didaktische Funktion(en):

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

Hintergrund / didaktisch-methodische Einordnung:

In „traditionellen Lehrformaten“ – gemeint sind damit Präsenzveranstaltungen, welche primär auf eine Wissensvermittlung abzielen (vgl. Sailer & Figas 2018) – spielen häufig Lernaufgaben eine Rolle. In vielen Fällen werden diese im Anschluss an die Wissensaneignung individuell von Studierenden außerhalb der Lehrveranstaltung bearbeitet (vgl. ebd.). Wenn es sich dabei um kleinere Aufgaben handelt mit einer geringen Bearbeitungszeit, die begleitend zu einer Lehrveranstaltung mit engem Rückbezug zu dieser eingesetzt werden, kann diese Art der aufgabenorientierten Lehre auch als „Strategie der kleinteilig-begleitenden Aufgaben“ bezeichnet werden (vgl. Bartel 2019), welche etwa in Übungen nach der Bearbeitung besprochen werden (siehe hierzu z.B. das Lehr-Lern-Arrangement Aufgabenbesprechung in Übungen). In dem hier vorgestellten Lehr-Lern-Arrangement werden die Aufgaben jedoch nicht in Einzelarbeit außerhalb der Lehrveranstaltung bearbeitet, sondern der gesamte Aufgabenprozess – Einführung, Bearbeitung, Besprechung und Vertiefung sowie Abschluss (vgl. Figas et al. 2014) – findet innerhalb der Präsenzphase statt, wie es etwa auch im Flipped Teaching üblich ist (Sailer & Figas 2018, S. 321). Das hier beschriebene Lehr-Lern-Arrangement lässt sich auf verschiedene Aufgabenformate anwenden (zu Aufgabenformaten siehe Bartel & Hagel 2015).

Sozialform(en):

Einzelarbeit, Partnerarbeit, Kleingruppenarbeit (3-5)

Anzahl der Lernenden:

1 bis 30 Personen


Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrpersonen müssen sich gut mit den Inhalten der Übung und den Aufgaben auskennen, da diese bei Fragen Hilfestellung geben sollen und auch die Lösung live vorstellen.

Ausstattung & Medien:

Seminarraum je nach Anzahl der Lernenden, PC, 1 Beamer


Ablauf

Beispiele oder Materialien:

Beispielaufgabe:

Hinweise zur Vorbereitung:

  • Konzeption von Aufgaben.
  • Vorbereiten eines Lösungsvorschlags.

Hinweise zur Nachbereitung:

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

Hinweise zur Dauer: Insgesamt ca. 90 Minuten (je eine Übungseinheit)


Kritische Einordnung

Vorteile und Stärken:

  • Die Studierenden beschäftigen sich in der Übung mit den Lehrinhalten.
  • Die Studierenden können sich bei Problemen untereinander austauschen.
  • Die Studierenden können ihren eigenen Wissensstand überprüfen.

Grenzen und Schwächen:

  • Studierende beschäftigen sich möglicherweise nicht mehr zusätzlich mit den Lehrinhalten zu Hause.

Sonstige Hinweise:


Literatur und weiterführende Hinweise
  • Bartel, Paula (2019): Aufgabenorientierte Hochschullehre: Eine explorative Untersuchung zum Einsatz von Lernaufgaben in der Hochschullehre aus allgemeindidaktischer und fachdidaktischer Sicht. Dissertation. Universität Augsburg.
  • Figas, Paula et al. (2014): Man wächst mit seinen Aufgaben. Über die kompetenzorientierte Konstruktion von Lernaufgaben in der Hochschullehre am Beispiel von Software Engineering. In: Ralle, Bernd et al. (Hrsg): Lernaufgaben entwickeln, bearbeiten und überprüfen. Ergebnisse und Perspektiven fachdidaktischer Forschung. Münster: Waxmann, S. 246–249.
  • Figas, Paula; Bartel, Alexander; Hagel, Georg (2015): Übung macht den Meister? Lernaufgabentypen im Hochschulfach Software Engineering. In: Spillner, Andreas; Lichter, Horst (Hrsg.): Tagungsband des 14. Workshops ”Software Engineering im Unterricht der Hochschulen” (SEUH). Dresden, S. 21–27.
  • Figas, Paula; Hagel, Georg (2016): Merkmale hochschuldidaktischer Lernaufgaben aus Studierendensicht. In: Stefan Keller und Christian Reintjes (Hg.): Aufgaben als Schlüssel zur Kompetenz. Münster: Waxmann, S. 417-428.
  • Sailer, Maximilian; Figas, Paula (2018): Umgedrehte Hochschullehre: Eine Experimentalstudie zur Rolle von Lernvideos und aktivem Lernen im Flipped Teaching. In: Die Hochschullehre 4, S. 317–338.

Beratung mit Bildkarten

Kurzzusammenfassung:

Im Hochschulkontext spielt die individuelle und effektive Beratung von Studierenden eine zentrale Rolle für qualitativ hochwertige Lehre. Im Folgenden geht es um die Verwendung von Bildkarten in der Beratung, um die Kommunikation zwischen Lehrperson und Studierenden in Einzelgesprächen zu unterstützen.


Übersicht

Ziele:

  • Die Studierenden können Themen (z.B. ihre Ziele oder Schwierigkeiten) bildhaft machen.
  • Studierende und Lehrpersonen erhalten Unterstützung bei schwierigen Gesprächen.
  • Studierende können Gefühle und Gedanken besser ausdrücken.

Didaktische Funktion(en):

  • Einstieg & Aktivierung

Hintergrund / didaktisch-methodische Einordnung:

Bildkarten werden besonders häufig im Coaching eingesetzt und können entweder selbst erstellt oder von Anbietern erworben werden (z.B. Weidenmann & Weidenmann 2013). Dabei handelt es sich um Kartensets mit gedruckten Bildern (meist im Din-A5 Format), welche unterschiedliche Motive abbilden. Das können zum Beispiel Landschaften, Fotos von Menschen mit unterschiedlichen Gesichtsausdrücken oder abstrakten Figuren und Farben sein. Die Bilder können eingesetzt werden, um etwa Gefühle zu verbildlichen oder metaphorisch ein Ziel zu konkretisieren. Der Einsatz von derartigen Bildern in der Beratung bietet sich laut Weidenmann & Weidenmann (2013) insbesondere dann an, wenn a) es den Studierenden schwer fällt, über etwas zu sprechen oder etwas in Worte zu fassen, b) sehr allgemein über ein Thema gesprochen wird, c) sehr rational über ein Thema gesprochen wird, d) Probleme bestehen, sich etwas vorzustellen (vgl. Bartel & Hagel 2019).

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

ab 1 Person


Voraussetzungen und Ressourcen

Voraussetzungen:

Für einen gelungenen Beratungsprozess benötigen Lehrperson(en) beratungstheoretisches und arbeitsspezifisches Fachwissen, Methodenkompetenz (z.B. aktives Zuhören, Paraphrasieren, Systemisches Fragen) sowie eine professionelle Haltung (z.B. wertschätzendes Verstehen, ausgeprägte Selbstreflexion oder Interesse und Zuversicht am Klienten) (vgl. Bartel & Hagel 2019).

Ausstattung & Medien:

Set von Bildkarten


Ablauf

Beispiele oder Materialien:

Fallbeispiel für den Einsatz von Bildkarten (aus Bartel & Hagel 2019):

"Nachdem Monika geschildert hat, warum sie sich an Prof. B. gewandt hat, fällt es ihr schwer, konkret zu formulieren, was eigentlich ihr konkretes Ziel ist. Prof. B. bittet sie daher eine Karte aus einem Kartenset wählen. Nach anfänglicher Skepsis sucht sie eine Karte aus, auf der ein steiler Abgrund sowie eine wackelige Hängebrücke zu sehen sind, an deren Anfang zwei Personen mit großen Rucksäcken stehen (siehe Abb. 2). Monika beschreibt, dass sie sich mit dem Bild identifizieren könne, da für sie die andere Seite eine erfolgreiche Beendigung des Studiums darstellt, sie aber nicht wisse, wie sie dorthin gelangen solle. Im Beratungsgespräch wurde diese Metapher im Folgenden wieder aufgegriffen. Mit Hilfe der Visualisierung wurden drei Kernpunkte erarbeitet: Es wurde anschaulich das Ziel („die andere Seite“) sowie der Grund für das Erreichen des Ziels thematisiert. Auch wurden die Eigenschaften des Weges („die Brücke“) und Hindernisse („schwerer Rucksack“) ausgeführt. Durch das Bild wurde das Beratungsanliegen ebenso wie später die Lösungsvisionen der Studentin sehr deutlich erkennbar und es gelang, verschiedene zielführende Strategien mit der Studentin zu entwickeln."

Hinweise zur Vorbereitung:

Auswahl geeigneter Karten

Hinweise zur Nachbereitung:

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

Hinweise zur Dauer: je nach Gesprächsdauer sehr unterschiedlich


Kritische Einordnung

Vorteile und Stärken:

Bildkarten unterstützen die Kommunikation und Interaktion zwischen Lehrperson und Studierenden. Aufgrund der Abstrahierung des Beratungsgegenstands können auch versteckte Aspekte, wie Konflikte oder Ängste, sichtbar werden.

Grenzen und Schwächen:

Es kann mitunter hohe Beratungskompetenz erfordern, professionell in unerwarteten Situationen zu reagieren.

Sonstige Hinweise:

Der hier beschriebene Einsatz von Bildkarten in der Beratung ist sehr allgemein gehalten. Besonders gut eignen sich Bildkarten zum Beispiel bei Lösungsorientierten Ansätzen (vgl. Bartel & Hagel 2019).


Literatur und weiterführende Hinweise
  • Bartel, P.; Hagel, G. (2019): Lösungsorientierte Beratung in der Hochschullehre (2), S. 18-30.
  • Weidenmann, S.; Weidenmann, B. (2013): 75 Bildkarten für Coaching und Beratung. Beltz.