Auf dem Workshop »Software Engineering im Unterricht an Hochschulen 2013«, der Bestandteil der Software Engineering Multikonferenz 2013 war, gab es einiges, was mir hängen blieb. Die Konferenz fand statt an der RWTH Aachen, die ja schon Erstsemester Roboter mit MATLAB und Lego Mindstorms bauen lässt, und ich freute mich besonders, dass wir dieses Ereignis sponserten. Ein paar Gedanken sind mir besonders aufgefallen, diese möchte ich hier teilen.
Vom Gemeinsamen Verständnis über Anforderungen
Es ist ineffizient, alles mit explizitem gemeinsamen Verständnis erreichen zu wollen.
Sie haben in Ihrem Projekt ein gemeinsames Verständnis über die Anforderungen erlangt? Wirklich? Prof. Martin Glinz von der Uni Zürich stellte in seiner Keynote ein wichtiges Konzept zum Verständnis über das gemeinsame Verständnis vor.
Neben explizitem und implizitem gemeinsamen Verständnis gibt es »Dark Information«, die zwar relevant ist, aber von niemandem wahrgenommen wird.
So gibt es Implizites vs. explizites gemeinsames Verständnis, das jeweils richtig oder falsch verstanden sein kann. Außerdem gibt es »Dark Information«, die zwar relevant ist, aber von niemandem wahrgenommen wird.
Gruppen organisieren sich bei Projektbasiertem Lernen selbst…
…wenn die Rahmenbedingungen stimmen. So jedenfalls fasse ich Prof. Bernd Brügges Keynote zum Workshop »Software Engineering im Unterricht an Hochschulen« auf. Sein Projektseminar ist keine Pflichtveranstaltung, die Teilnahme ist freiwillig.
Bei freiwilligen Veranstaltungen kann Gruppendruck und Selbsterkenntnis das Durchfallen ersetzen.
Als Brügge berichtete, in dieser Veranstaltung sei in den letzten 20 Jahren noch nie jemand durchgefallen, waren die Fragezeichen doch zunächst groß. Er erklärte, dies sei nur möglich, weil es eine Wahlveranstaltung sei, und den Studierenden ziemlich schnell klar würde, was auf sie zukäme. Diejenigen, die später ohnehin durchfallen würden, zögen sich rasch wieder zurück, und die anderen profitierten durch die Gruppendynamik, die die Leistung eines jeden einbeziehe.
Wiederverwendung erlauben, Verständnis fordern
Prof. Axel W. Schmolitzky gab seine Erkenntnisse aus der Programmierausbildung zum Besten. Wichtige Erkenntnisse:
Der Witz ist nicht unbedingt, die Aufgabe neu zu lösen, sondern die Lösung ‒ die ja auch aus dem Vorjahr kopiert werden könnte ‒ so zu durchdringen, dass sie auch präsentiert werden kann.
Dies erlaubt ihm, auch mehrere Jahre dieselben Praktikumsaufgaben zu stellen. So sei es durchaus erlaubt und gar nicht zu verhindern, dass Lösungen aus dem Vorjahr wiederverwendet würden. Der Knackpunkt wäre jedoch, dass die Studierenden ihre Lösung in der Abnahme präsentieren müssten, und dort ziemlich schnell auffiele, wer sich die Lösung nicht erarbeitet hätte. Schmolitzky gab zu bedenken, dass der Lernerfolg auch dann hergestellt sei, wenn die Lösung ganz verstanden wäre.
»Programmierausbildung im ersten Semester macht demütig.«
Er rief ferner dazu auf, sich immer wieder bewusst zu machen, was wir alles wüssten, und bei Studienanfängern eben keine Annahmen zu treffen, was das Vorwissen anginge. Das Konzept eines Booleschen Ausdrucks beispielsweise sei nichts, was generell bekannt sei.
Just-in-Time Teaching (JiTT)
Mehrere Vortragende, darunter Prof. Hagel (HS Kempten) gaben ihre Erfahrungen zum Thema Just-in-Time Teaching weiter.
Die Vorlesung dient nicht mehr der Wissensvermittlung, sondern Klärung studentischer Schwierigkeiten aus dem Selbststudium.
Ausser der Einführung in die Art der Veranstaltung bereitet Hager kein Skript vor, der Rest ergibt sich aus der Arbeit mit den Studierenden.
Dazu stellt er eine Wochenaufgabe: Kapitel eines Buches lesen, in dem Fall über Requirements Engineering. Dazu stellt er verschiedene Aufgaben: Wo sind Verständnisprobleme? Was war interessant? Was sind Anknüpfungspunkte zu Bekanntem? Behandlung der Antworten in der jeweils nächsten Vorlesung. Seine Vorlesung hatte eine überschaubare Zahl von Studierenden, so dass Hager darauf wert legte, alle deren Antworten selbst zu erfassen und beantworten. In der Diskussion nach dem Vortrag wurde das Problem thematisiert, dies auf große Studentenzahlen zu skalieren.
Geeignete Metriken für Praktikumsaufgaben
Michael Striewe und Michael Goedicke stellten in ihrem Vortrag »Analyse von Programmieraufgaben durch Softwareproduktmetriken« zwei Metriken vor, die sie betrachteten:
- Umfangsmetrik: Zahl der Statements
- Komplexitätsmetrik: Zyklomatische Komplexität
Interessanterweise sind das auch ungefähr die Metriken, die sich MATLAB Cody hernimmt, um eine Lösung zu bewerten.
Entwicklung von High-Integrity Systemen mittels Model-Based Design
Mein Kollege Mirko Conrad berichtete, wie Entwicklungsorganisationen mit Simulink und Embedded Coder sicherheitsgerichtete Systeme entwerfen und absichern können.
Prozessautomatisierung statt Prozessstillstand
Das Konzept basiert darauf, möglichst viele Prozessschritte zu automatisieren und damit leicht wiederholen zu können. Auf diese Weise können die Anwender immer die neueste Toolentwicklung verwenden, statt nur alle paar Jahre eine zertifizierte Version zu bekommen.
Resumé
Das Konzept, die Veranstaltungen mit wissenschaftlicher (SE), industrieller (SEE) und ausbildungsorientierter (SEUH) Ausrichtung in einer Multikonferenz zu kombinieren, ging auf und bescherte ein lehrreiches, inspirierendes und abwechslungsreiches Programm.
So darf das im nächsten Jahr gerne wieder ablaufen, auch wenn leider die SEUH nur zweijährlich durchgeführt wird.
Schreiben Sie einen Kommentar