coalbase

 

 

Lehr- und Lernplattform für die gemeinschaftliche Erarbeitung von Software-Architektur in großen Gruppen

Problemstellung

Persönliche Motivation

Die meiste Zeit meines beruflichen Lebens habe ich als Software-Architekt verbracht, als Planer und Gestalter großer IT-Systeme oder -Landschaften. Der Software-Architekt entwirft die Blaupausen dieser Systeme. Software-Applikationen müssen nach den Regeln der Technik umgesetzt sein und den Wünschen des Auftraggebers entsprechen. Der Architekt muss aber auch zukünftige Anforderungen antizipieren, um das IT-System nachhaltig gestalten zu können – nur so kann es leicht gewartet und erweitert werden.

Hierzu hält die Softwaretechnik einen großen und sehr komplexen Werkzeugkasten bereit – Modellierungssprachen wie UML, Design-Patterns und Architekturstile, Entwurfsmethoden, etc. Diese beherrscht ein erfahrener Architekt so flüssig und intuitiv wie ein Konzertmusiker sein Instrument. Andernfalls könnte er sich nicht genügend auf seinen Entwurf konzentrieren.

Darüber hinaus muss der Architekt aber auch noch an der Umsetzung seines Entwurfs mitwirken. Er muss also in der Lage sein, seinen hochkomplexen Entwurf so zu kommunizieren, dass sowohl Ausführende (Softwareentwickler, Betriebsexperten, etc.) wie auch nicht IT-affine Auftraggeber ihn verstehen. Häufig verlaufen solche fachliche Diskussionen kontrovers. Kommunikationsvermögen ist also neben analytischen Fähigkeiten eine Schlüsselkompetenz.

Ich habe viele Jahre Teams von Softwarearchitekten geleitet und damit auch an der Ausbildung von Architekten mitgewirkt. Die Frage, was genau einen guten Software-Architekten ausmacht, und wie man die nötigen Fähigkeiten am besten vermittelt, beschäftigt mich also schon lange.

Problemstellung in der Hochschullehre

In der Berufswirklichkeit wird man erst nach einigen Jahren praktischer Erfahrung als Software-Entwickler zum Architekten. In der Hochschullehre müssen die Grundlagen der oben beschriebenen Kernfähigkeiten aber schon ab dem 3. Semester vermittelt werden, beispielsweise in der Veranstaltung Softwaretechnik.

Die klassische Softwaretechnik tendiert dabei dazu, sich auf die Lehre des Werkzeugkastens (UML-Modellierung, Liste der Entwurfsmuster, …) zu fokussieren. Drängende Fragen der Studierenden nach dem Kontext der Anwendung – „Wie setze ich das alles ein? Was nutze ich wann? Womit fange ich an, wenn ich einen neuen Entwurf erstelle?“ – werden in den klassischen Lehrwerken oft nur unzureichend beantwortet. Stattdessen behandeln die Autoren die einzelnen Werkzeuge (wie etwa UML-Diagrammtypen) eins nach dem anderen in großer Detailtiefe.

Diese Art der Lehre bewegt sich hauptsächlich auf Stufe 2-3 (Understanding, Applying) der Revised Bloom’s Taxonomy [1]. In der praktischen Anwendung im Projekt sind aber eher die Stufen 4-6 gefordert (Analysing, Evaluating, Creating). Wenn also ein in dieser Form ausgebildeter Student nach Ende des Studiums an die eigenverantwortliche Umsetzung geht, hat er vermutlich 80% der Details bereits vergessen. Bei dem Rest an verbliebenem Wissen fehlt ihm dann oft der Kontext der praktischen Anwendung. Dies führt in der Praxis häufig dazu, dass die Entwurfsphase ausgelassen oder das Softwaresystem mit Hilfe einer unvollkommenen Ad-hoc-Modellnotationen spezifiziert wird. Das Risiko von unvollständigen und inkonsistenten Softwareentwürfen steigt dadurch deutlich.

Lösungsansatz der Lehrinnovation „ArchiLab“

Das oben genannte zentrale Problem der Softwarearchitektur-Ausbildung lässt sich nach dem Ansatz von Middendorf  und Pace [4] lösen. In ihrem Artikel Decoding the Disciplines schlagen sie einen siebenstufigen Zyklus für die Vermittlung komplexen Expertenwissens vor (siehe Abbildung 1).

Abbildung 1: Lernschritte nach Middendorf und Pace [4] und deren Abdeckung durch die vorgeschlagenen Lehrinnovationen

Abbildung 1: Lernschritte nach Middendorf und Pace [4] und deren Abdeckung durch die vorgeschlagenen Lehrinnovationen

 

Die Informatik-Bachelor-Veranstaltung Softwaretechnik, die vornehmlich Architekturwissen vermittelt, nutzt drei didaktische Kernelemente, um diesen Ansatz umzusetzen:

  • Management von Learning Outcomes: modularer Aufbau und hierarchische Untergliederung der Veranstaltung in Form von (Teil-)Fähigkeiten (siehe (Constructive Alignment nach [2])
  • Fallstudien-Bearbeitung: Kollaborative, projektorientierte Erarbeitung von Softwarearchitekturen für eine Fallstudie, zur praktischen Erprobung der erlernten Kompetenzen
  • Onlinetool zur Lernstandskontrolle: Quiz, Selbsttests, Verwaltung von Prüfungsfragen

In der Veranstaltung Softwaretechnik werden diese Mittel schon jetzt erfolgreich eingesetzt, allerdings jeweils nur in einer stark vereinfachten, manuellen Form. Dadurch wird ihr Potenzial bei weitem nicht ausgeschöpft. Darüber hinaus ist die Veranstaltung durch den hohen manuellen Aufwand sehr betreuungsintensiv.

ArchiLab ist die Vision einer digitalen und vernetzten Plattform zur Lehr- und Lernunterstützung gemäß des Ansatzes von Decoding the Disciplines, fokussierend auf die drei genannten Kernfunktionalitäten. In den nachfolgenden Kapiteln werden die drei Teilmodule von ArchiLab sowie ihr jeweiliger Bezug zu den ersten sechs der „Decoding the Disciplines“-Stufen näher erläutert.

Geplantes Einsatzgebiet von ArchiLab

Zunächst soll ArchiLab in der zweisemestrigen Veranstaltung Softwaretechnik eingesetzt werden, einer Pflichtveranstaltung im 3. und 4. Semester des Informatik-Bachelor-Studiums an der TH Köln.

Eine Ausweitung von ArchiLab auf die Pflichtmodule Mensch-Computer-Interaktion und Datenbanken der Bachelor-Studiengänge Informatik und Wirtschaftsinformatik (ebenfalls zweisemestrig im 3. und 4. Semester) liegt nahe, da die Praktika dieser Veranstaltungen schon jetzt miteinander koordiniert sind.

Zukünftig wird innerhalb des Instituts für Informatik an der TH Köln angestrebt, die Praktika dieser drei Pflichtmodule noch stärker zu verzahnen. Einerseits senkt dies angesichts der hohen Studierendenzahlen den Betreuungsaufwand, zum anderen ergibt sich ein realistischerer Projekteindruck für die Studierenden, wenn Architektur des Gesamtsystems, Nutzerschnittstelle und Datenhaltung gleichzeitig und mit gemeinsamer Aufgabenstellung spezifiziert werden.

In einem solchen Szenario können dann Learning Outcomes, Praktikums-Fallstudien und Online-Fragenpool dieser drei Informatik-Kernfächer gemeinsam in ArchiLab verwaltet werden.

Management von Learning Outcomes

Gemäß Middendorf und Pace beginnt der Lehr- und Lernprozess bei der Frage nach Lernhindernissen (Bottlenecks) für Studierende (Schritt (1) in Abbildung 1). Beim Erlernen von Softwarearchitektur-Fähigkeiten kann das beispielsweise die Frage sein, mit welchen konkreten Schritten man beim Entwurf denn beginnt. Eine Unsicherheit an dieser Stelle wirkt typischerweise als Blockade.

In den Schritten (2) und (3) werden Hemmnisse durch den Lehrenden mittels einer dekompositorischen Analyse der Kompetenzen aufgelöst: Wie macht der Experte das? Welche expliziten Schritte unternimmt er? Wie kann man diese weiter in Teilschritte zerlegen, damit auch ein Novize geführt diesen Weg gehen kann?

Das Learning Outcome aus dem Constructive Alignment [2] ist das ideale Beschreibungswerkzeug für diese hierarchisch untergliederten Kompetenzen. Statt nur ein einziges, globales Learning Outcome zu schreiben, kann die Veranstaltung auch durch eine Menge von rekursiv verschachtelten Learning Outcomes definiert werden, welche die zu erwerbenden Kompetenzen sehr feingranular beschreiben.

In der jetzigen Veranstaltung wurde dieser Ansatz in statischer Form (Excel) punktuell durchgespielt. Das Learning Outcome folgt dabei einer festen formalen Form:

Als <Rolle> 
kann ich <Fähigkeit>, 
vorausgesetzt <Vorbedingungen>, 
     indem ich <Teilfähigkeiten> 
     und abschließend <abschließende Teilfähigkeit>, 
so dass <Nutzen der Fähigkeit>.
Abbildung 2: Beispiel für eine (Teil-)Fähigkeit im Architekturentwurfsprozess, in Form einer rekursiv aufgebauten und untergliederten Learning Outcomes

Abbildung 2: Beispiel für eine (Teil-)Fähigkeit im Architekturentwurfsprozess, in Form einer rekursiv aufgebauten und untergliederten Learning Outcomes

 

Abbildung 2 zeigt als Beispiel eine typische Teilfähigkeit zu Anfang des Architekturentwurfs, die Bestimmung des sogenannten Architekturstils. Die Teilfähigkeiten (wie etwa 4) die funktionalen und nichtfunktionalen Randbedingungen bestimmen) sind ihrerseits wieder (Sub-) Learning Outcomes, die dann in der gleichen Form spezifiziert werden.

Auf diese Weise kann der Lehrende, den Schritten (2) und (3) von Decoding the Disciplines folgend, die Zielkompetenzen seiner Veranstaltung spezifizieren. Es entsteht auf diese Weise ein feingranulares, inhaltlich-didaktisches Gerüst.

Pilotanwendung im Fach Softwaretechnik 1

Für das Fach ST1 wurde eine solche feingranulare, hierarchisch geschachtelte Spezifikation vorgenommen (Bente 2017a). Die Spezifikation erfolgte zunächst im MS-Word-Form, um einen Beispieldatensatz für die ArchiLab-Entwicklung zu schaffen. Später, wenn das ArchiLab-Datenmodell für LOs implemeniert ist, wird der Datensatz dann nach ArchiLab importiert.

Es zeigt sich dabei, dass die Kompetenzen (die „kann ich … indem ich“-Bestandteile) in den Taxonomiestufen 3-5 angesiedelt sind, mit einem großen Schwerpunkt bei Stufe 4. Dies erklärt sich so:

  • Die meisten einzuübenden Kompetenzen haben einen analytischen Teil, und sind damit auf Stufe 4 (Auswahl von passenden Geschäftsobjekten, Komponenten, Prozessschritten etc. gemäß Prioritäten, die durch Anforderungen und die Natur der Domäne gegeben sind).
  • Die reine Modellierung ist dann eher bei Stufe 3 anzusiedeln: Wenn etwa in fachlichen Datenmodell die zu modellierenden Geschäftsobjekte und deren Beziehungen durch Analyse (=> Stufe 4) feststehen, dann entspricht die Umsetzung in ein UML-Klassendiagramm der klassischen Anwendung einer Methode, und damit eher Stufe 3.
  • Schließlich gibt es auch einige Kompetenzen der Stufe 5, die eine Evaluierung des bisher existierenden Entwurfs mit Entscheidungen über nötige Weiterentwicklungen zum Inhalt haben.

Zusätzlich wurde für das Fach ST1 eine Sammlung von Probeaufgaben (Bente 2017b) entwickelt, bei der jede (Teil-)Aufgabe einer oder mehreren Kompetenz(en) zugeordnet ist. (In der Datei erkennt man dies zunächst noch nicht, weil diese Zuordnungen nur als MS-Word-Kommentare hinterlegt und damit vor den Studenten verborgen sind. Bei einem späteren Import nach ArchiLab können diese Referenzen aber ausgewertet werden.)

Geplante Umsetzung in ArchiLab

In ArchiLab ist geplant, einen Editor für diese rekursiv untergliederten Learning Outcomes zu implementieren. Neben einer flexibleren Erstellung gewinnt man so die Möglichkeit, Teilfähigkeiten mit praktischen Übungen (siehe Kapitel 3) sowie mit Prüfungs- und Selbsttestfragen (Kapitel 4) zu verknüpfen.

Auf diese Weise kann die Frage (1) nach Lernhindernissen (Bottlenecks) gezielt beantwortet werden. Übungen und Prüfungs- / Selbsttestfragen, die von Studierenden mit unterdurchschnittlichem Erfolg bearbeitet werden, weisen auf schlecht vermittelte Teilfähigkeiten hin. Deren Lehr- / Lernformat kann dann für die nächsten Iteration der Veranstaltung überarbeitet werden.

Als Plattform für das Management von Learning Outcomes bietet sich das Konzept des semantischen Wikis [5] an. Diese verbindet die freie Eingabe von Inhalten mit der Möglichkeit, diese Inhalte durch ein dynamisch erweiterbares Datenmodell vorzustrukturieren. Zahllose Editor-Funktionalitäten sind bereits vorhanden und müssen nicht mehr implementiert, sondern nur durch das passende Datenmodell konfiguriert werden. Ein Kandidat für die ArchiLab-Plattform ist das als Open Source veröffentlichte, webbasierte semantische Wiki SocioCortex [7] der TU München. Dessen Eignung wird vorab noch durch eine Technologieevaluierung überprüft werden.

Datenmodell Lernraum / Learning Outcome

Abbildung 3: Datenmodell Lernraum / Learning Outcome

 

Alternativ zur Verwendung eines semantischen Wikis kann die Learning-Outcome-Verwaltung auch als eigenständiges Modul implementiert werden. Abbildung 3 zeigt das zugehörige fachliche Datenmodell.

 

Fallstudien-Bearbeitung

Die Stufen (3) – (5) des „Decoding the Disciplines“-Ansatzes (Abbildung 1) sehen vor, dass auf die explizite Definition der Arbeitsschritte (Stude 3) das praktische Einüben dieser Tätigkeiten (4) folgt. Das hat wiederum eine Motivation (5) durch das Erleben eigenen Könnens und der Relevanz des Gelernten zur Folge.

Es ist also unerlässlich, den Studierenden die Anwendung der erlernten Methoden und Werkzeuge im Rahmen ihres Studiums zu ermöglichen. Daher besteht die Veranstaltung Softwaretechnik neben der Vorlesung auch aus einem projektbasierten Praktikum. Hier wird ein Projektgegenstand – ein zu erstellendes fiktives Softwaresystem – mit möglichst hohem Realitätsbezug definiert. Dieses wird in Teilbereiche zerlegt und von den Studierenden in Gruppen bearbeitet. Das Ergebnis des Praktikums ist dann pro Gruppe ein Softwarearchitekturentwurf für das zugeordnete Teilsystem.

Wie schon in Kapitel 1.1 ausgeführt, beinhaltet der Architekturentwurf immer ein hohes Maß an Kommunikation. Dies gilt nicht nur für die Vermittlung des fertigen Entwurfs an die ausführenden Entwickler, sondern auch für die Entwurfsphase selbst. Gerade in sehr großen Softwaresystemen sind unzählige Abhängigkeiten und Schnittstellen zu modellieren, die jeweils mit den zuständigen Architekten oder Teams abgestimmt werden müssen.

Abbildung 4: Moderierter Schnittstellen-Abstimmungstermin mehrerer Praktikumsgruppen in Rahmen des Softwaretechnik-Praktikums

 

Ein Großteil der Entwurfsarbeit im Praktikum besteht daher für die Studierenden darin, die relevanten Aspekte ihres jeweiligen Teilbereichs in Form von UML-Diagrammen zu modellieren. Hierbei ist ein wichtiges Kriterium, dass die Schnittstellen zwischen den einzelnen Subsystemen klar definiert und die Zuständigkeiten für einzelne Geschäftsobjekte und -prozesse eindeutig geklärt werden. Während die Modellierung innerhalb der Praktikumsgruppe stattfindet, finden Bewertung und Abstimmung der Schnittstellen im kommunikativen Austausch zwischen den Praktikumsgruppen statt – wie im realen Projekt im späteren Berufsleben.

Die Veranstaltung Softwaretechnik bildet dies unter anderem dadurch ab, dass zu ein bis zwei Praktikumsterminen im Semester sich alle Gruppen gemeinsam treffen (siehe Abbildung 4). Sämtliche potenziellen Schnittstellen zwischen Teilsystemen werden durch beschriftbare elektrostatische Wandfolien repräsentiert, an denen die Studierenden ein gemeinsames Verständnis der jeweiligen Schnittstellenmodellierung erarbeiten können.

Dies simuliert im Praktikumskontext, dass ein Softwarearchitekt seine Modellierarbeit nicht nur allein am Rechner erledigen sollte. Die Architekturqualität ist deutlich höher, wenn der erste Entwurf gemeinsam am Whiteboard erarbeitet wird. Dort können die Teammitglieder lebhaft und kontrovers diskutieren und neue Ideen rasch ausprobieren und wieder verwerfen.

Um hier eine vollständige Abstimmung unter den einzelnen Gruppen und eine Bewertung des erreichten Abstimmungsgrades zu erreichen, sind im aktuellen Veranstaltungsformat mehrere zusätzliche Termine mit den Praktikumsgruppen notwendig. Die Abstimmungsqualität wird in einem aufwändigen Verfahren ermittelt, bei dem die Studierenden sich selbst einschätzen. Dem wird eine aus mehreren Einzelkriterien errechnete Einschätzung der Praktikumsbetreuer entgegengesetzt.

Abbildung 5: Bewertung der Abstimmungsqualität der Schnittstellenspezifikationen zwischen den Praktikumsgruppen.
Oben: Selbsteinschätzung der Studierenden (gemittelt aus den Einzeleinschätzungen der Mitglieder beider beteiligten Teams)
Unten: Einschätzung durch Betreuer (gemittelt aus mehreren Einzelkriterien)

 

Abbildung 5 zeigt einen Ausschnitt der so ermittelten Bewertung (der Praktikumsgegenstand war ein Softwaresystem für eine Restaurantkette). Die Studierenden erhalten eine Rückmeldung, ob ihre Schnittstellenmodellierung und -abstimmung genügt, um die gewünschten Geschäftsprozesse und deren Datenaustausch zwischen verschiedenen Modulen der Software abzubilden.

Geplante Umsetzung in ArchiLab

In der jetzigen Veranstaltung findet dieser Prozess komplett manuell statt, was aufgrund der stetig wachsenden Anzahl an Studierenden mehr und mehr eine organisatorische Herausforderung darstellt. Auch können nicht annähernd alle relevanten Abstimmungsaspekte betrachtet werden.

In ArchiLab ist es geplant, dass die Fallstudie mit ihren Teilbereichen durch die Betreuer im System selbst definiert werden kann. Hier bietet sich als Plattform wieder das semantische Wiki an. Damit können alle Modelldaten, die eine Praktikumsgruppe für den Architekturentwurf eines Teilmoduls zu spezifizieren haben, als Attribute im Datenmodell konfiguriert werden. (Die eigentlichen Modelldiagramme sollen weiterhin in einem externen UML-Modellierungstool erstellt werden und nur als fertige Grafiken eingebunden werden. Die Erstellung eines kollaborativen UML-Editors wäre ein vielfach komplexeres Vorhaben mit einer ganz anderen Zielstellung als ArchiLab.)

Die Praktikumsgruppen nutzen dann ArchiLab als webbasiertes Managementsystem für ihren Entwurf. Damit können dann sowohl Abstimmungsprozesse zwischen den Gruppen wie auch Bewertung der Entwurfs- und Abstimmungsqualität komplett innerhalb des Systems vorgenommen werden. Das gilt sowohl für Selbsteinschätzung wie auch für Bewertung durch Betreuer.

Die kollaborative Erstellung von Architekturentwürfen großer Systeme wird mit einem solchen System transparent gemacht, ohne zusätzlichen „technischen“ Betreuungsaufwand wie das manuelle Erstellen von Einschätzungs-Umfragen nötig zu machen. Die Betreuer können sich also ganz auf die fachliche Auseinandersetzung mit den Studierenden konzentrieren.

Vernetzung mit dem Learning Outcome der Veranstaltung (siehe oben)

Da das Management von Learning Outcomes (Kapitel 2) und Praktikums-Fallstudien zwei Teilmodule von ArchiLab auf der gleichen Plattform eines semantischen Wiki sind, ist eine effektive Vernetzung dieser Module leicht möglich.

Die Attribute des Entwurfs der Praktikumsgruppen lassen sich unmittelbar mit den Fähigkeiten verlinken, die zu ihrer Entstehung benötigt werden. Nehmen wir die Teilfähigkeit „Festlegung des Architekturstils“ aus Abbildung 2 auf Seite 4 als Beispiel: Hier gäbe es dann Attribute „Architekturstil“ und „Begründung des Stils“, die von den Praktikumsgruppen mit Inhalt gefüllt werden. Die Eigen- und Betreuerbewertungen geben dann Aufschluss darüber, wie gut die Teilfähigkeit „Festlegung des Architekturstils“ bereits beherrscht wird, und ermöglicht ein gezieltes Erkennen von Lehr- und Lerndefiziten.

Onlinetool zur Lernstandskontrolle

Der „Decoding the Disciplines“-Ansatz enthält als Stufe (6) die Frage „How well are students mastering these learning tasks?“. Feedback-Erhebungen unter Studierenden ergeben regelmäßig, dass sie die Überprüfung des eigenen Kenntnisstandes als wichtig, aber auch schwierig empfinden. Eine effektive Möglichkeit zur Selbsteinschätzung des Lernstandes wirkt auch gleichzeitig als Motivator für Studierende (Stufe 5). Zusätzlich helfen die aggregierten und ausgewerteten Ergebnisse natürlich auch den Lehrenden, Lernhindernisse zu erkennen (Stufe 1).

In der jetzigen Form der Veranstaltung Softwaretechnik wird das Tool Pingo der Universität Paderborn [2] für interaktive Wiederholungsfragen eingesetzt. Zusätzlich werden am Ende der Veranstaltung die Pingo-Fragen gesammelt, nochmals variiert sowie ergänzt und dann in der letzten Vorlesung als Online-Quiz mit direkter Auswertung durchgespielt. Die drei bestplatzierten Studierenden erhalten einen symbolischen Preis.

Das Feedback zur Veranstaltung zeigt eine hohe Wertschätzung der Studierenden für die beiden Einschätzungsmittel. Leider bedeutet insbesondere das Online-Quiz einen relativ hohen manuellen Vorbereitungsaufwand, da parallel zur Quizerstellung auch eine automatisch durchlaufende Powerpoint-Präsentation mit den teilweise komplexen Fragestellungen (die nicht in dem einfachen Quiztool allein abzubilden sind) erstellt werden muss.

Darüber hinaus ist es zurzeit kaum möglich, den Grad der korrekten Beantwortung der Fragen systematisch nachzuhalten. Die Anteile der richtigen Antworten müssten gesammelt und systematisch mit Bezug auf die jeweiligen Inhalte nachgehalten werden, was aus Zeitgründen unterbleibt.

Geplante Umsetzung in ArchiLab

Ein Online-Quiztool soll vor diesem Hintergrund fester Bestandteil von ArchiLab werden. Den Studierenden werden hier verschiedene Modi angeboten, von zufällig ausgewählten Fragen bis hin zu Fragen bestimmter Themengebiete oder Schwierigkeitsgrade. Die Anpassbarkeit des Quiz sorgt dafür, dass jeder Studierende sich individuell anhand seiner Stärken und Schwächen gezielt auf die Prüfung vorbereiten kann.

Mit der Arbeit an dem Quiztool wurde im Rahmen eines Informatikprojekts im WS16/17 begonnen. Das Quiztool ist zwar nicht das zentrale Element von ArchiLab, hat aber den Vorteil, auch ohne tiefere Kenntnis des ArchiLab-Konzepts sofort verstanden zu werden. Mit über 20 Studierenden wurden in drei Teams die folgenden Teilprojekte bis zu einem lauffähigen Prototypstadium getrieben:

  • Quizclient (Abbildung 6)
  • Quizeditor (Abbildung 7)
  • Auswertungstool für Quizergebnisse (Abbildung 8)

Abbildung 6: ArchiLab-Quizclient, mobile Version (aktueller Stand des Prototypen)

 

Abbildung 7: ArchiLab-Fragen- und Quizeditor (aktueller Stand des Prototypen)

 

Abbildung 8: ArchiLab-Fragen- und Quizeditor (aktueller Stand des Prototypen)

 

Die Studierenden sollen die Möglichkeit erhalten, den Fragenkatalog des Quiztools selbstständig zu erweitern. Die durch die Studenten vorgeschlagenen Fragen und Antworten werden durch die Betreuer der Veranstaltung überprüft werden und freigegeben. Dadurch wird die aktive Mitwirkung der Studierenden an der Veranstaltung Softwaretechnik gefördert und Elemente eines Flipped Classroom eingeführt.

Teil des Quiztools ist damit ein kontinuierlich wachsender Pool von Quizfragen zu den Architekturentwurfsmethoden. Fragen können mittels Rollen-/Rechtekonzept nur für Betreuer sichtbar gemacht werden. Das erlaubt es, auch Fragenpools für mündliche und schriftliche Prüfungen zu verwalten, die die Studierenden natürlich nicht vorher zu Gesicht bekommen sollen. Nach Verwendung in der Prüfung gehen sie dann in den allgemein zugänglichen Pool über.

Vernetzung mit dem Learning Outcome der Veranstaltung (Kapitel 2)

Die Vernetzung der Quiz- / Prüfungsfragen mit dem Learning Outcome liegt an der Stelle nahe. Fragen lassen sich direkt den Teilfähigkeiten eines Learning Outcome zuordnen (siehe auch Abbildung 2 auf Seite 4, unten rechts). Sofern die entsprechenden passende Auswertungssichten von der Software zur Verfügung gestellt werden, wird es mit ArchiLab unmittelbar transparent, bei welchen Themengebieten die Studierenden noch Verständnisprobleme haben.

Für das Online-Quiztool ergibt – anders als beim Management von Learning Outcomes und der Fallstudienverwaltung – ein semantisches Wiki als Plattform keine Vorteile, da das Datenmodell hier eher einfach ist und sich selten ändert. Eine klassische Webarchitektur ist an dieser Stelle der einfachere und bessere Weg. Dies bedeutet, dass die Integration mit dem Management der Learning Outcome etwas aufwändiger ist als bei der Fallstudienverwaltung. Im Arbeitsplan ist die Integration daher auch als explizites Teilprojekt vorgesehen.

Langfristige Planung für ArchiLab

Verstetigung der Lehrinnovation

Das ArchiLab-Konzept ist auf eine Laufzeit von mehreren Jahren ausgelegt. Die grundsätzliche Idee hierbei ist, die starke Projektorientierung der TH Köln als Fachhochschule zu nutzen. Die Studierenden im Informatik-Bachelor und -Master müssen verschiedene Pflichtpraktika absolvieren, in denen konkrete Programmierarbeiten zu absolvieren sind.

Es ist vorgesehen, einen großen Teil der Spezifikation und Implementierung von ArchiLab als Studienleistung in studentischen Projektteams oder als Teil von Abschlussarbeiten durchzuführen (siehe hierzu auch den Arbeitsplan). Dadurch ist sichergestellt, dass das Projekt durch das Team der Fachgruppe Systemgestaltung am Institut für Informatik der TH Köln und durch meine eigene Person nachhaltig vorangetrieben wird.

Eine Projektförderung ist allerdings nötig für die Produktifizierung der Software – und damit auch erst für den praktischen Einsatz in der Lehre. Robustheit, Tests, Dokumentation und Wartung bleiben bei reinen Studentenprojekten erfahrungsgemäß mangelhaft. Eine Betreuung durch fest angestellte Kräfte ist nötig, um ArchiLab auch tatsächlich effektiv im Lehralltag zu verankern.

Bei diesem Lehreinsatz ist es auch hilfreich, dass ich als Lehrender die Randbedingungen der Lehre so gestalten kann, dass ein schlüssiges Gesamtkonzept entsteht. So wurden beispielsweise beim jetzt anstehenden Umzug der Fachgruppe Systemgestaltung in ein anderes Gebäude der TH Köln die Projekträume mit beschriftbaren und abwaschbaren Wänden ausgestattet wurden. Gemeinschaftliche Modellierungs-Workshops (wie in Abbildung 3 auf Seite 5) werden dadurch einfacher: Die Studierenden können einfach komplett alle Wände mit Whiteboardstiften beschriften.

Übertragung auf andere Fächer und Disziplinen

Oben wurde schon dargestellt, welche Synergien innerhalb der Informatik-Studiengänge der TH Köln möglich sind. Darüber hinaus ist – vorausgesetzt das Konzept wird erfolgreich umgesetzt und produktifiziert – ein Einsatz von ArchiLab auch in der Informatik-Ausbildung außerhalb der Hochschule sinnvoll. Es ist geplant, ArchiLab als Open Source zu veröffentlichen.

Eine Übertragung auf andere komplexe Fachdisziplinen (z.B. Ingenieurswissenschaften) scheint ebenfalls grundsätzlich möglich. Durch die Orientierung am „Decoding the Disciplines“-Ansatz trägt das Konzept keine inhärent Informatik-spezifischen Züge. Ein Einsatz von ArchiLab ist grundsätzlich auch in der Lehre von komplexen Ingenieursprojekten sinnvoll und möglich, wenn das Datenmodell entsprechend angepasst wird.

Erfolgs- und Risikobewertung in der Erprobung

Durch die Bindung an das Learning Outcome ist Feedback und Erfolgskontrolle ein wesentliches Element von ArchiLab, wie in den obigen Kapiteln dargestellt. Darüber hinaus werden werden wir – wie auch schon jetzt – Evaluationsbögen und andere Feedbackformen wie etwa den Teaching Analysis Poll (TAP) [5] zurückgreifen, um Erfolg und Risiken des Einsatzes von ArchiLab in der Lehre zu bewerten.

Referenzen