{"id":906,"date":"2017-03-10T16:46:07","date_gmt":"2017-03-10T15:46:07","guid":{"rendered":"http:\/\/lwibs01.gm.fh-koeln.de\/blogs\/bente\/?page_id=906"},"modified":"2018-09-27T04:49:04","modified_gmt":"2018-09-27T02:49:04","slug":"coalbase","status":"publish","type":"page","link":"http:\/\/blogs.gm.fh-koeln.de\/bente\/forschung-entwicklung\/coalbase\/","title":{"rendered":"coalbase"},"content":{"rendered":"

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

Lehr- und Lernplattform f\u00fcr die gemeinschaftliche Erarbeitung von Software-Architektur in gro\u00dfen Gruppen<\/em><\/p>\n

Problemstellung<\/h2>\n

Pers\u00f6nliche Motivation<\/h4>\n

Die meiste Zeit meines beruflichen Lebens habe ich als Software-Architekt verbracht, als Planer und Gestalter gro\u00dfer IT-Systeme oder -Landschaften. Der Software-Architekt entwirft die Blaupausen dieser Systeme. Software-Applikationen m\u00fcssen nach den Regeln der Technik umgesetzt sein und den W\u00fcnschen des Auftraggebers entsprechen. Der Architekt muss aber auch zuk\u00fcnftige Anforderungen antizipieren, um das IT-System nachhaltig gestalten zu k\u00f6nnen \u2013 nur so kann es leicht gewartet und erweitert werden.<\/p>\n

Hierzu h\u00e4lt die Softwaretechnik einen gro\u00dfen und sehr komplexen Werkzeugkasten bereit \u2013 Modellierungssprachen wie UML, Design-Patterns und Architekturstile, Entwurfsmethoden, etc. Diese beherrscht ein erfahrener Architekt so fl\u00fcssig und intuitiv wie ein Konzertmusiker sein Instrument. Andernfalls k\u00f6nnte er sich nicht gen\u00fcgend auf seinen Entwurf konzentrieren.<\/p>\n

Dar\u00fcber 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\u00fchrende (Softwareentwickler, Betriebsexperten, etc.) wie auch nicht IT-affine Auftraggeber ihn verstehen. H\u00e4ufig verlaufen solche fachliche Diskussionen kontrovers. Kommunikationsverm\u00f6gen ist also neben analytischen F\u00e4higkeiten eine Schl\u00fcsselkompetenz.<\/p>\n

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\u00f6tigen F\u00e4higkeiten am besten vermittelt, besch\u00e4ftigt mich also schon lange.<\/p>\n

Problemstellung in der Hochschullehre<\/h4>\n

In der Berufswirklichkeit wird man erst nach einigen Jahren praktischer Erfahrung als Software-Entwickler zum Architekten. In der Hochschullehre m\u00fcssen die Grundlagen der oben beschriebenen Kernf\u00e4higkeiten aber schon ab dem 3. Semester vermittelt werden, beispielsweise in der Veranstaltung Softwaretechnik.<\/p>\n

Die klassische Softwaretechnik tendiert dabei dazu, sich auf die Lehre des Werkzeugkastens (UML-Modellierung, Liste der Entwurfsmuster, \u2026) zu fokussieren. Dr\u00e4ngende Fragen der Studierenden nach dem Kontext der Anwendung \u2013 \u201eWie setze ich das alles ein? Was nutze ich wann? Womit fange ich an, wenn ich einen neuen Entwurf erstelle?\u201c \u2013 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\u00dfer Detailtiefe.<\/p>\n

Diese Art der Lehre bewegt sich haupts\u00e4chlich auf Stufe 2-3 (Understanding, Applying) der Revised Bloom\u2019s Taxonomy<\/em> [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\u00fchrt in der Praxis h\u00e4ufig dazu, dass die Entwurfsphase ausgelassen oder das Softwaresystem mit Hilfe einer unvollkommenen Ad-hoc-Modellnotationen spezifiziert wird. Das Risiko von unvollst\u00e4ndigen und inkonsistenten Softwareentw\u00fcrfen steigt dadurch deutlich.<\/p>\n

L\u00f6sungsansatz der Lehrinnovation \u201eArchiLab\u201c<\/h4>\n

Das oben genannte zentrale Problem der Softwarearchitektur-Ausbildung l\u00e4sst sich nach dem Ansatz von Middendorf\u00a0 und Pace [4] l\u00f6sen. In ihrem Artikel Decoding the Disciplines<\/em> schlagen sie einen siebenstufigen Zyklus f\u00fcr die Vermittlung komplexen Expertenwissens vor (siehe Abbildung 1).<\/p>\n\"Abbildung<\/a>\n

Abbildung 1: Lernschritte nach Middendorf und Pace [4] und deren Abdeckung durch die vorgeschlagenen Lehrinnovationen<\/em><\/p>\n

 <\/p>\n

Die Informatik-Bachelor-Veranstaltung Softwaretechnik<\/em>, die vornehmlich Architekturwissen vermittelt, nutzt drei didaktische Kernelemente, um diesen Ansatz umzusetzen:<\/p>\n