Page tree

Softwaretechnik in der Lehre

Ein Softwarearchitekt entwirft die Spezifikation eines IT-Systems – eine hochkomplexe Aufgabe. In der Berufswirklichkeit wird man erst nach einigen Jahren zum Softwarearchitekten. In der Hochschullehre müssen die Grundlagen der Softwarearchitektur aber im 3./4. Semester vermittelt werden, z.B. in der Veranstaltung Softwaretechnik. Die klassische Softwaretechnik lehrt hauptsächlich Modellierungsmethoden wie UML – und dies in großer Detailtiefe. Diese Art des Wissens bewegt sich hauptsächlich auf Stufe 2-3 (Understanding, Applying) der Revised Bloom’s Taxonomy. Drängende Fragen der Studierenden nach dem Kontext werden dabei nur unzureichend beantwortet:

  • „Wofür brauche ich das?“
  • „Wann nutze ich was in welcher Weise?“
  • „Womit fange ich an?“

In der praktischen Anwendung im Projekt sind aber eher die Stufen 4-6 nach Bloom gefordert (Analysing, Evaluating, Creating). Das erlernte Wissen bleibt dann in der Praxis unbenutzbar und ungenutzt - ein Grund für fehlschlagende Softwareprojekte.

„Decoding the Disciplines“ mittels der Didaktik-Plattform ArchiLab

Die Didaktik-Plattform ArchiLab hilft bei der Bewältigung dieses Problems nach dem Ansatz Decoding the Disciplines (DtD) (Middendorf und Pace, 2004):

  1. What is a bottleneck to learning in this class?
  2. How does an expert do these things?
  3. How can these tasks be explicitly modelled?
  4. How will students practice these skills and get feedback?
  5. What will motivate the students?
  6. How well are students mastering these learning tasks?
  7. How can the resulting knowledge about learning be shared?

ArchiLab unterstützt den DtD-Ansatz in Form einer webbasierten Didaktik-Plattform. ArchiLab wird in studentischen Projektteams implemeniert. Dadurch ergibt sich nach den ersten Erfahrungen eine hohe Motivation der Studierenden, da sie der „nachfolgenden Generation“ das Leben erleichtern können.

Die drei Teilmodule von Archilab

ArchiLab hat drei Kernmodule. Vernetzung sorgt dafür, dass alle Daten mit dem Learning Outcomes verbunden sind. Dadurch bietet sich jederzeit ein detailliertes Bild des Lernstands der Teilnehmer.

Management von Learning Outcomes (DtD 1 –3)
Modularer Aufbau und hierarchische Untergliederung der Veranstaltung in Form von(Teil-)Fähigkeiten.

Kollaborative Fallstudien-Bearbeitung und –Bewertung von Softwarearchitekturen (DtD 4 – 5)

  • Aushandeln und Bewerten von SW-Schnittstellen zwischen Teams
  • Verknüpfung mit Learning Outcomes => Feedback zur Methoden-Beherrschung möglich

Lernstandskontrolle: Quiz, Selbsttests, Verwaltung von Prüfungsfragen (DtD 6)

  • Anonyme Teilnahme über Alias
  • Verknüpfung von Selbsttest- und Prüfungsfragen mit Learning Outcomes
  • Detaillierte Selbst- und Kursauswertung