Lecture Engineering Thomas Lehmann und Bettina Buth, HAW Hamburg thomas.lehmann|bettina.buth@haw-hamburg.de Zusammenfassung "Wo der Überblick fehlt, ist das Grauen nicht weit."(Lotter (2005)) Für die Überarbeitung des Moduls Software Enginee- ring im Studiengang Mechatronik der HAW Hamburg Mit der Entscheidung zur Neugestaltung ergab sich wurde ein kompetenzorientierter Ansatz verwendet. die Frage, ob es einen systematischen Ansatz zur fach- Dabei wurden Anleihen an die Vorgehensweisen und lichen und didaktischen Ausgestaltung eines Moduls Prinzipien des Softwareengineerings genutzt, um sys- gibt? Aus der Diskussion innerhalb der Hochschule tematisch zunächst die Kompetenzen und dann daraus bietet sich hier ein kompetenzorientiertes Vorgehen die Inhalte des Moduls zu entwickeln. In diesem Ar- an. Wie behalte ich den Überblick bei der Entwicklung tikel berichten wir über die bisherigen Erfahrungen des Moduls? Da es hier um eine Art Produktentwick- bei der Konzeption und der Durchführung des Moduls lung geht, entstand die Idee, Ideen und Methoden des anhand eines Fallbeispiels. Softwareengineerings auf die Entwicklung des Mo- duls Software Engineering anzuwenden. Dazu wurden Ausgangssituation Äquivalenzen zwischen den Entwicklungsschritten im V-Modell und der Entwicklung eines Moduls identifi- An der HAW Hamburg wird der Studiengang Me- ziert. Im Folgenden wird beschrieben welche Anleihen chatronik gemeinsam von den Bereichen Maschinen- gemacht, wie diese im kompetenzorientiertem Umfeld bau, Elektrotechnik, Informatik und Fahrzeugtechnik eingesetzt und welche Erfahrungen dabei gesammelt durchgeführt. Das Department Informatik betreut ent- wurden. sprechend den Informatik-Anteil des Studiengangs. Durch personelle Änderungen ging die Verantwortung Erste Schritte für das Modul Software Engineering zum Winterse- mester 2013/14 an uns über. Die Übernahme sollte da- Das Requirements Engineering (vgl. z. B. Hammer- zu genutzt werden, es von Grund auf neu zu konzipie- schall u. Beneken (2013)) sammelt die Erwartungen ren. Die Mechatronik vereint Mechanik, Elektrotech- und Anforderungen an ein Produkt in seinen Facetten nik und Informatik, sodass man hier Studierende mit ein und gibt Leitlinien zu dieser Anforderungserhe- einer geringeren Affinität zu Software antrifft als in bung. In einer Vision wird ein Leitbild für das Produkt den Informatik-Studiengängen. In diesem Zusammen- beschrieben, welche durch die Stakeholder in seinem hang scheint es sinnvoll, den angehenden Mechatro- Kontext näher definiert wird. Die Anforderungen wer- nikern nicht Softwareengineering im engeren Sinne, den systematisch dokumentiert und in einen Entwurf sondern die Perspektive des systematischen Vorgehens umgesetzt. Mit diesen Kernideen sind wir in das Er- aus System- und Softwaresicht nahe zu bringen. Eine stellen von Requirements für das Modul eingestiegen. direkte Übernahme des Moduls Software Engineering In einem Textdokument haben wir zunächst unsere aus der (Technischen) Informatik war deshalb nicht Vorstellung über ein Softwareengineering für einen angebracht, da dieses nur die Softwareseite beleuchtet Mechatroniker, somit das Ziel des Moduls im Kontext und von anderen Vorkenntnissen ausgeht. Das Modul des Curriculums, dokumentiert. Bei der Betrachtung musste auf die anderen Vorkenntnisse in Programmie- der Stakeholder lag der Fokus auf dem Hochschulkon- ren und die andere Art von Studierenden in diesem text, also Studierende, Professoren/Dozenten, Labor- Studiengang angepasst sein. mitarbeiter, Stundenplaner und Studiengangskoordi- natoren. Externe Stakeholder wie Personalverantwort- Das Modul kann aufbauen auf Vorkenntnisse aus liche wurden im ersten Iterationsschritt der Anwen- zwei Semestern Programmierung in C/C++. Insge- dung dieses Vorgehens nicht betrachtet. Diese hätten samt entspricht der Kenntnisstand hier ca. 40-50% wie bei der Studie zu erforderlichen Kompetenzen dessen was in den Informatik-Studiengängen der HAW (vgl. Hummel (2013)) für die Auswahl der Kompeten- in den ersten beiden Semestern vermittelt wird. Die zen mit hinzugezogen werden müssen. Hier wurde planerischen Rahmenbedingungen des Fachs gehen zum Ausprobieren der Vorgehensweise auf die eige- von einer Vorlesung mit 3 Vorlesungsstunden und 1 nen Erfahrungen aus der Praxis zur Definition der Praktikumsstunde pro Woche aus, üblich erfolgt eine Kompetenzen vertraut. Blockung der Praktika in 4 Termine a 4 Stunden. Die Hochschule gibt einen Rahmen für die Umset- zung vor. Dieser Rahmen aus Anzahl der Semesterwo- Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 103 chen, Semesterwochenstunden (3+1 SWS), Kohorten- Es wurde so versucht, die zu erreichende Niveaustufe größe, verfügbaren Laborplätzen, Anwesenheitspflicht (Bloom (1972)) direkt in den verwendeten Verben im Labor, typischen Gestaltung des Stundenplans, Ver- abzubilden. Diese führten dann zu Unterkompetenzen fügbarkeit von Labormitarbeitern, Laborinfrastruktur, analog zu Hierarchien von Requirements. Die Studie- Credit Points (5 CP) und ähnliche Rahmenbedingun- renden müssen zum Beispiel nicht in der Lage sein ein gen haben wir mit Architekturvorgaben gleichgesetzt. Lasten- oder Pflichtenheft zu erstellen; sie sollten aber Auch wenn uns diese Rahmenbedingungen geläufig die Bedeutung dieser Dokumente kennen. Dieses ”ken- waren, haben wir sie zur Reflexion in unserem Do- nen” wurde durch die Unterkompetenzformulierung kument aufgeführt. Weiterhin liefern sie für Außen- „Die Studierenden können den Unterschied zwischen stehende (z. B. andere Departments/Studiengänge) einem Lasten- und einem Pflichtenheft erläutern.“1 Hinweise darauf, inwieweit unsere Umsetzungside- abgebildet. Im Gegensatz dazu wurde auf das Doku- en übernommen werden können. Für den eigenen mentieren einzelner Requirements Wert gelegt, was Überblick wurden auch Referenzen auf bestehendes sich im Rahmen des Themas Requirement Engineering Material aus anderen Modulen aufgeführt, sowie die in der Formulierung der Teilkompetenz „Die Studie- Liste der Deliverables, d. h. Artefakte an Vorlesungsun- renden können einzelne Requirements strukturiert terlagen, Übungsaufgaben, Laboraufgaben, Templates, dokumentieren und die Qualität der Dokumentation usw. bis hin zur Klausur, erstellt. Eine Liste an Quellen bewerten.“ widerspiegelt. Gerade die Bewertung der wie Bücher oder Vod-/Podcasts ergänzt die Material- Qualität liegt auf einer hohen Niveaustufe. Dieses Vor- liste. gehen bei der Erstellung der Kompetenzliste führte zu Unterkompetenzen analog zu Hierarchien bei Requi- Requirements Engineering rements. Die Unterkompetenzen beschreiben hier de- taillierter, was unter der übergeordneten Kompetenz Ziel eines Moduls ist, dass die Studierenden am En- verstanden wird oder führen auf, welcher Baustein de über einen Satz an (akademischen) Kompetenzen zum Erlangen der Hauptkompetenz beitragen soll. verfügen. Entsprechend wurden im Sinne von Requi- Beispiel aus dem Bereich Requirements Enginee- rements zu erreichende Kompetenzen formuliert. Es ring: wurde hier das akademisches Kompetenzmodell nach Die Studierenden . . . Reis (2013) verwendet, welches keine weitere Unter- K-10 . . . können Kundenwünsche identifizieren und teilung in fachliche, Methoden-, soziale und Selbst- als Requirements-Katalog dokumentieren und bewer- kompetenz (Böttcher u. a. (2011)) wie aus der Berufs- ten. bildungsforschung vorsieht. Die Kompetenzen wurden als Learning Outcomes (Biggs u. Tang (2007) oder K-10.1 . . . können einzelne Requirements im Sinne Kennedy (2007)) formuliert, die ein Handlungsziel in von strukturiertem Text formulieren und dokumentie- einer komplexen Situation sichtbar machen. Im Sinne ren. des Constructive Alignment (vgl. z. B. Biggs u. Tang K-10.2 . . . können Requirements geeignet attribuie- (2007) oder Brabrand (2008)) lassen sich so leicht ren (Prioritäten, Stakeholder, usw.). formative als auch summative Prüfungsfragen (Zürich K-10.3 . . . können Abnahmekriterien (Abnahme- (2008)) ableiten. Das Constructive Alignment sieht tests) für Requirements entwerfen. vor, dass die Intended Learning Outcomes mit den ... Prüfungen und die darauf vorbereitenden Lehreinhei- K-10.7 . . . können die Qualität von Requirements ten zueinander inhaltlich und auf den Niveaustufen beurteilen. (Bloom (1972)) kohärent sind. Es darf nicht erwartet K-10.8 . . . können strukturiert ein Requirements werden, dass die Studierenden UML Modelle erstel- Review durchführen. len können, wenn in der Vorlesung nur die einzelnen Für die Identifikation der erforderlichen Kompeten- Symbole durchgearbeitet werden und dann auf dieser zen wurde wie folgt vorgegangen: Aus bestehenden Basis in der Prüfung Analyseaufgaben auf einem ge- Modulen der Informatik und der persönlichen Erfah- gebenen Diagramm gestellt werden. Dieses wäre im rung des Software und Systems Engineering wurden Sinne des Constuctive Alignment inkohärent, alleine die Hauptkompetenzen formuliert. Unterkompeten- schon weil die drei Teile auf verschiedenen Niveaustu- zen ergänzten diese oder beschrieben genauer, was fen liegen. Wird eine Modellierungskompetenz erwar- die Hauptkompetenz eigentlich aussagt. Hierzu wur- tet, dann ist eine Prüfungsaufgabe zur Modellierung den auch Modulbeschreibungen anderer Hochschulen zu stellen und diese Kompetenz (nicht die Musterlö- herangezogen. Weiterhin wurden Lehrbücher und Vor- sung) im Rahmen der Lehreinheiten einzuüben. Das lesungsunterlagen gesichtet. Bei den interessanten Design der Vorlesung arbeitet somit auf die Prüfung Themenfeldern wurde immer die Frage gestellt, was der Kompetenz hin. für sichtbare Handlungen können die Studierende in Im Gegensatz zur Forderung von Oliver Reis wur- diesem Themenfeld ausführen, bzw. was ist ein mög- den hier nicht nur Learning Outcomes im engeren 1 Die abgeleitete Prüfungsfrage im Sinne des Constructive Ali- akademischen Sinne formuliert, sondern auch Kompe- gnment ist dann „Erläutern Sie die Unterschiede zwischen einem tenzen auf niedrigen Niveaustufen explizit aufgeführt. Lasten- und einem Pflichtenheft!“ 104 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 liche Handlung, die sich aus dem Wissen erschließt? Assignment to Components). So wurden zum Beispiel Die Antworten führten dann zur Formulierung der für den Block „Requirements Engineering“ zwei Vorle- Kompetenz mit einem geeigneten Verb des sichtbaren sungstermine vorgesehen (siehe Tabelle 1). Handelns2 . In einer Matrix wurden dann die Kompetenzen den Nichtfunktionale Anforderungen ergeben sich aus Blöcken zugeordnet. Es zeigt sich auch hier, dass eini- den planerischen Randbedingungen; dies bezieht sich ge Kompetenzen mehreren Vorlesungs- und Laborter- zum einen auf den generellen Zuschnitt als Modul mit minen zugeordnet werden können und müssen. Ana- 3 Stunden Vorlesung und 1 Stunde Praktikum und log zum Verhalten, dass einige Requirements wie zum die praktische Umsetzung wie oben beschrieben. An- Beispiel Performance nur querschnittartig im System dererseits sind aber auch die Vorgaben der Prüfungs- umgesetzt werden können, findet sich die Vermittlung ordnung bezüglich der Prüfungsform (Klausur) und einiger Kompetenzen als Querschnittsthemen wieder. die Prüfungsvoraussetzung durch das erfolgreiche Ab- Die Zuordnung zu Vorlesungs- oder Labortermi- solvieren aller Praktikumstermine und -aufgaben als nen erfolgt je nach Kompetenz und erforderlichen einschränkende Randbedingungen für die didaktische Vermittlungs- als auch Prüfungsmethoden. Für die Ausgestaltung des Moduls zu sehen. Kompetenz K-10.8 ”Die Studierenden können struk- turiert ein Requirements Review durchführen.” ergibt Übergang zum Design sich durch das Verschieben des Verbs der Prüfungsauf- Beim Erarbeiten der Kompetenzen fielen automatisch trag ”Führen Sie strukturiert ein Requirements Review bereits Zusatzinformationen an, die den Übergang durch.” Durch die in der Prüfungsordnung vorgesehe- zum Design, dem Ausgestalten von Vorlesung, Labor- ne Klausur (vgl. oben zu den nicht-funktionalen An- praktika und Übungen, vereinfachen. Analog erge- forderungen) lässt sich diese Kompetenz nur schlecht ben sich beim Erfassen von Requirements bereits Ide- prüfen. Darüber hinaus sollten die zugehörigen Hand- en zu möglichen Realisierungen oder Designs. Diese lungen auch tatsächlich ausgeführt werden. (Design-)Informationen wurden strukturiert in einem Wir hatten deshalb beschlossen, diese Kompetenz Mindmapping-Tool (hier FreeMind) erfasst. Zu jeder nicht im Sinne einer Notengebung zu prüfen. Diese Kompetenz wurde die Motivation für die Aufnahme Kompetenz wurde einem Labortermin zugeordnet, da der Kompetenz, Verweise auf vorhandenes Material, hier Teams eine Aufgabe ausführen müssen und man Querverweise, Notizen, Ideen für mögliche Prüfungs- als Dozent die Durchführung beobachten kann. Man aufgaben sowie Ideen zur Vermittlung der Kompetenz kann die Teams bei der Ausführung beobachten und annotiert (vgl. Abbildung 1). Bei den Vermittlungside- ihnen besser Feedback geben, als bei einer integrierten en wurde neben Vorlesungsvorträgen auch schon Ver- Übung in der Vorlesung. Weiterhin ist die Laborübung weise auf Methoden der aktivierenden Lehre (Macke Teil der Prüfungsvorleistung und unterliegt somit auch u. a. (2012) bzw. Dallmeier u. a. (2013)) im Rahmen einem Qualitätsanspruch. In den vorgelagerten Vor- des seminaristischen Unterrichts mit Aufgabenstellun- lesungen wird das Wissen um die Prozesse und die gen vermerkt. Es wurde trotz der scheinbar gleichmä- Qualitätsmerkmale von Reviews vermittelt. In dem ßigen Struktur der Annotationen ein Mindmapping- eigentlichen Review im Praktikum sollen die Teams Tool verwendet, da es wesentlich flexibler bei der Aus- von vier Studierenden die Requirements eines ande- bildung von hierarchischen Strukturen ist, bzw. für ren Teams des gleichen Labortermins überprüfen. Dies die Aufnahme von Ideen besser geeignet ist als die wiederum setzt voraus, dass vorher die Kompetenz zur strenge Tabellenstruktur eines Requirement Tools. Erstellung von Requirements vermittelt wurde. Aus dieser Abhängigkeit ergeben sich Randbedingungen für das Scheduling der Lehreinheiten und der Prakti- kumsinhalte. Insgesamt ergab sich für diesen Labortermin die Aufgabenstellung in das Erstellen von Requirements auf Basis einer Fallbeschreibung, welche eine kurzen Eingangsprüfung unterzogen wurden, und die Review- Sitzung unter Beobachtung mit abschließenden Feed- Abbildung 1: Zusatzinformationen zur Kompetenz backrunden. Die Qualitätsbeurteilung und die über- 10.7 ”... können die Qualität von Requirements be- arbeiteten Requirements wurden dann geprüft und urteilen.” im Mindmapping-Tool. ergaben die Prüfungsvorleistung. An diesem Punkt der Planung muss man abwägen, Im Sinne eines Architektur-Entwurfes wurde das ob der Aufwand in Lehre und Prüfung zum Erreichen Modul in thematischen Blöcke der beiden Lehrformen der jeweiligen Kompetenz gerechtfertigt ist. Falls nicht Vorlesung und Laborpraktikum aufgeteilt und grob ist es erforderlich die geforderte Kompetenz anzupas- der zeitliche Umfang pro Block festgelegt (Analogie: sen, da man sonst das Constructive Alignment nicht 2 Die Sichtbarkeit ist für die Ableitung einer guten Prüfungsauf- erzielt. Auch hier findet sich die Analogie zu den Auf- gabe erforderlich. gaben eines Softwarearchitekten wieder, der das Grob- Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 105 Tabelle 1: Zuordnung Themenbereiche zu Vorlesungsterminen Thema Themenbereich Termin(e) Organisatorisches Organisatorisches, Übersicht, Einführung 1 Requirements Requirements, Kano-Modell, Stakeholder, Requirements Prozess, Doku- 1-2 mentation, Qualitätssicherung Systemdesign Systemdesign, Modellierung allgemein, SysML, Block Diagramms, Inter- 3-4 nal Block Diagrams, Flows, Systemsicht Verhaltensmodelle Verhaltensmodellierung, Sequence Diagrams, Activity Diagrams, State 5-7 Diagrams Software Modellierung von Software, Datenmodelle, technische Systeme steuern, 7-9 Umsetzung in lauffähige Software QA Qualitätssicherung 10-11 Prozesse Prozesse/Configuration Management 11 Projektmanagement Configmanagement, Ticketsysteme, Projektmanagement 12 Safety (Optional) Prinziples, Begriffe, Analysemethoden, Techniken 12 Abbildung 2: Ausschnitt der Zuordnungsmatrix von Kompetenz zu Lehreinheiten. design auf Machbarkeit im Rahmen der zur Verfügung der Leistungsstärke gemischte, immer neu zusammen- stehenden Ressourcen prüfen und ggf. Maßnahmen gestellte Teams aktiviert wurden. Die Übungen sind ergreifen muss. großteils nach Ansätzen des Peer Facilitated Learning konzipiert, d. h. jeder Studierender skizziert zunächst Implementierung eine individuelle Lösung, diese wird im zusammenge- Auf Basis der Blockzuordnung der Kompetenzen und stellten Team diskutiert und zu einem Teamergebnis der Zusatzinformationen wurden die einzelnen Ter- zusammengeführt. Die Ergebnisse der Teams wurden mine bezüglich ihrer Inhalte, Vermittlungsmethoden dann jeweils auf einem ”Marktplatz” präsentiert und und zeitlichem Umfang geplant. Dabei wurde Material diskutiert. Gerade bei Modellierungsaufgaben erweist (Folien, Übungsaufgaben, usw.) aus bestehenden Vor- sich die Diskussion auf dem Marktplatz als günstige lesungen übernommen, angepasst oder neu erstellt. formative Lernkontrolle, da es oftmals keine eindeuti- Als ergänzendes Material wurden den Studierenden ge (Muster-)Lösung gibt. die Liste der zu erwerbenden Kompetenzen, Kontroll- fragen und weiterführende Quellen für jeden Themen- Die Entwicklung der Laboraufgaben gestaltete sich block zur Verfügung gestellt. Ein Tracing der Kompe- schwieriger, da hier mehr Randbedingungen, insbeson- tenzen auf einzelne Folien oder Übungen wurde als dere die verfügbaren oder beschaffbaren technische zu feingranular angesehen. Aufbauten mit berücksichtigt werden müssen. Weiter- Bei der Umsetzung wurde bei den im Sinne des hin darf die Problemstellung eine gewissen Komplexi- seminaristischen Unterrichts in die Vorlesungen in- tät weder über- noch unterschreiten, da die Problem- tegrierte Gruppenübungen darauf geachtet, dass in stellungen alle Teammitglieder auslasten sollen. 106 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 Die Rahmenbedingungen des Departments sehen Qualitätskontrolle vier Laborterminen mit je 4 SWS vor. Dazu kommen Vor- und Nachbereitung. Typischerweise wird in unse- In der Qualitätskontrolle muss man zwischen der ab- ren Modulen in Gruppen von 12-16 Studierenden in schließenden Prüfung (weiter unten), Beurteilung des Zweierteams gearbeitet. Softwareengineering Metho- Lernfortschrittes im laufenden Semester und der Qua- den kommen aber erst dann zum Tragen, wenn eine litätskontrolle in der Umsetzung unterscheiden. Grundkomplexität überschritten wird. Somit wurde Für die Beurteilung des Lernfortschrittes der Semes- die Teamgröße im ersten Durchlauf auf 4-5 Studieren- tergruppe wurden die Diskussionen im seminaristi- de festgelegt und in nachfolgenden Durchläufen wie- schen Unterricht und die Bearbeitung der Übungsauf- der auf 3-4 Studierende reduziert (vgl. Liebehenschel gaben herangezogen. Während der integrierten Grup- (2013)). In dieser Teamgröße können ausreichend penübungen in den Vorlesungen hat man als Dozent komplexe Aufgaben gestellt werden, die in der Zeit die Möglichkeit zwischen den Teams zu wandern und bearbeitbar bleiben. Die Teamgröße erfordert eine an- die Arbeit der Teams zu beobachten. Hier kann man dere Kommunikation als im eingespielten Zweierteam. gut den Stand der Studierenden erkennen und auch Ein strukturiertes Vorgehen und ein Informationsaus- direkt Feedback geben, falls die Studierenden kollek- tausch über Diagramme (UML) wird nun erforderlich. tiv falsche Lösungsansätze verfolgen. Dies gilt ebenso Die Labortermine eignen sich gut, die Studieren- bei den Diskussionen der Teamergebnisse. Formative den beim Bearbeiten der Problemstellung und ihre Prüfungen durch Classroom Response Systeme, wie Vorgehensweise zu beobachten. Deshalb wurden die Klicker-Systeme, kamen hier noch nicht zum Einsatz, Problemstellungen so ausgewählt, dass der Prozess im wären aber denkbar. Vordergrund steht und das Ergebnis der Problembe- arbeitung durch nachzureichende Artefakte geprüft Im Bereich der Umsetzung wurde nach jedem Vor- wurde. Im Einzelnen: lesungstermin geprüft, ob die angesetzte Zeit für die Vermittlung der Teilkompetenz durch Vorlesungsteil 1. Labortermin: Strukturiertes Requirements Review und integrierten Übungen grob eingehalten wurde. Hier zeigte sich, dass der Zeitaufwand für die Grup- Vorleistung: Kleines Requirements-Dokument er- penübungen unterschätzt wurde, insbesondere die stellen Zeit für die Diskussion der Ergebnisse. Letztere wer- Nacharbeiten: Einarbeiten der Mängelliste (er- den aber von uns als wesentlich für die Verankerung stellt durch anderes Team) oder Vertiefung der Themen angesehen. Fehler in den Unterlagen wurden direkt als Errata 2. Labortermin: Modellierung eines Systems korrigiert. Weiterhin wurde ein Tagebuch geführt, in Vorleistung: Einarbeiten in die Diagrammtypen dem Beobachtungen aus den Veranstaltungen und Ver- besserungsideen festgehalten wurden. Von Seiten der Nacharbeiten: Diagramme vollständig mit Kom- Hochschule werden regelmäßig Evaluationen der ein- mentaren zelnen Vorlesungen durchgeführt, so auch für dieses Modul. Hier waren insbesondere die Freitextrückmel- 3. Labortermin: Wartung Teil 1. dungen der Studierenden hilfreich, um Anpassungen Eine bestehende Steuerungssoftware soll erwei- vorzunehmen. tert werden. Aufarbeiten der Requirements und Analyse des Bestandssystems. Maintenance Nacharbeiten: Dokumentation der Requirements und Analyseergebnisse Die Vorlesung wurde nun bereits zwei Mal, unser Meinung nach erfolgreich, durchgeführt. Nach jedem 4. Labortermin: Wartung Teil 2. Durchlauf wurden zunächst die Verbesserungsideen und die Beobachtungen aus dem Tagebuch ausgewer- Design, Umsetzung und Test der Erweiterung. tet und zusammengefasst. Analog zum prinzipiellen Nacharbeit: Dokumentation des Designs, der Um- Vorgehen in der Softwareentwicklung müssen hier bei setzung und der Abnahmetests neuen Erkenntnissen aus dem Feld die Requirements überarbeitet werden, das Design angepasst werden, Gerade die Wartungsaufgabe erwies sich für die Stu- usw. Entsprechend führten die gewonnenen Erkennt- dierenden als große Herausforderung, da sie sich in nisse zur Überarbeitung der Kompetenzen, der Zusatz- eine fremdes System eindenken müssen und sie mit informationen, der Laboraufgaben, bis hin zur Neuge- dem üblichen Trial-and-Error nicht effektiv zum Ziel staltung einzelner Folien oder Vorlesungsabschnitte. kommen. Trotz des Aufwandes und den Schwierig- Die beobachteten Schwierigkeiten bei der Wartungs- keiten bei der Aufgabenstellung war das Feedback zu aufgabe führten zum Beispiel dazu, dass das Thema dieser Problemstellung sehr positiv, da es sich wie ein ”einarbeiten in ein fremdes System” nun explizit in der Problem aus dem realen Leben anfühlte. Vorlesung thematisiert wird. Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 107 Prüfung Durch die gute Formulierung von (Teil-)Learning Abgeschlossen wird das Modul mit einer schriftlichen Outcomes war es zum Teil sehr leicht, Prüfungsauf- Prüfung am Ende der Vorlesungen, wie es die Prü- gaben zu entwickeln. Auch konnte man den Studie- fungsordnung vorschreibt. Ein erfolgreicher Abschluss renden Hinweise auf die Prüfung geben, insbesondere aller Labortermine ist Voraussetzung für die Zulassung da die zur Verfügung stehenden Klausuren der Ver- zur Klausur. Eine individuelle Benotung ist im Labor- gangenheit nicht mehr zur aktuellen Ausgestaltung praktikum nicht erforderlich, nur eine individuelle Zu- des Moduls passten. Weiterhin hat die Kompetenz- lassung zur Klausur. Für das erfolgreiche Abschließen orientierung mit dem Hinterfragen der erwarteten eines Labortermins wurden die abgelieferten Artefak- Handlungsfähigkeit dazu geführt, dass sich weniger te als Teamleistung bewertet. Auch wenn nur eine „sinnloses“ Wissen in der Vorlesung anhäuft als bei Zulassung erreicht werden muss, somit ein Mindest- einer themenorientierten Vorgehensweise. maß an Leistung, so wurden auch hier beobachtet, Der Ansatz zur Übernahme von Methoden aus dem dass es innerhalb einzelner Teams Ärger bezüglich der Softwareengineering wurde noch nicht konsequent Zuarbeit einzelner Teammitglieder gab. umgesetzt. So fehlt zum Beispiel eine Betrachtung des Kontextes der Vorlesung, d. h. die genaue Betrachtung Die abschließende Klausur ist weiterhin klassisch aller anderen Vorlesungen des Curriculums. Auch wur- mit kleinen Aufgaben aufgebaut und akkumuliert Teil- de kein konsequentes Controlling bezüglich der einge- punkte, die wiederum auf eine Note abgebildet wer- flossenen Aufwände durchgeführt3 . Ein wesentlicher den. Bei der Entwicklung der Klausuraufgaben konn- nächster Schritt wäre nun auch das sich Lösen von ten Aufgaben leicht aus den Kompetenzen abgeleitet den gegebenen Rahmenbedingungen und zeitlichen werden. Aus der Kompetenz K-10.7 ”Die Studierenden Taktungen. Diese schränken das Denken in möglichen können die Qualität von Requirements beurteilen.” Vermittlungsmethoden noch zu sehr ein. wurde die Prüfungsaufgabe ”Beurteilen Sie die nach- folgenden Requirements auf ihre Qualität.” Dazu war Die mit der Kompetenzorientierung einhergehen- ein Block mit Requirements gegeben, die in der Vorle- de Problemorientierung war gerade in den Laboren sung angesprochene Mängel unterschiedlichster Art eine Herausforderung für die schwächeren Studieren- enthielten. den. Sie erwarten klar umrissene (Teil-)Aufgaben, die abzuarbeiten sind. Die gefühlte Akzeptanz von rea- Bei Aufgaben höherer Niveaustufen, wie zum Bei- listischen Problemstellungen statt Aufgaben war bei spiel die Qualitätsbewertung von gegebenen Require- den leistungsstärkeren, bzw. softwareaffineren Studie- ments oder Modellierung, wurde in den Teilaufgaben renden hoch und wurde begrüßt. Die Laboraufgaben ein Niveaustufenmodell angewandt. Es wurde nicht waren so konzipiert, dass diese nur im 4er-Team bei die Anzahl der gefundenen Problemstellen (ein Ding, strukturiertem Vorgehen in der Zeit zu lösen waren. ein Punkt), sondern die Komplexität und Tiefe der Ein ”Gebastel”, wie man es oftmals im dritten Semes- Analyse bewertet und auf eine Punktzahl abgebildet ter noch beobachtet, führte nicht zum Erfolg und ließ (Qualität der Antwort). Wurden zum Beispiel bei der einige Teams dann doch auf systematisches Arbeiten Qualitätskontrolle der Requirements ausschließlich umschwenken. die Rechtschreibfehler bemängelt, aber nicht erkannt, dass immer wieder Synonyme verwendet wurden oder Die an das Softwareengineering angelegte syste- das es Widersprüche gab, so führte dieses zu einem matisch konstruktive Vorgehensweise kann unserer schlechteren Ergebnis. Meinung nach auch für andere Module angewandt werden. Das Lecture Engineering gibt Dozenten aus Ein vollständiger Übergang zur kompetenzorientier- den Ingenieurwissenschaften/der Informatik Mittel ten Prüfung würde zwei bis drei komplexe Learning aus Ihrer Denkwelt an die Hand, um ihre Module Outcomes/Kompetenzen prüfen, welche die notwen- durchzuplanen und auszugestalten. Die Qualität der digen Teilkompetenzen mit abdecken. Ein derartiger Module erhöht sich, da eine Transparenz existiert und Umstieg der Prüfungsmodalitäten wurde als zu großer ein Abgleich im Sinne des Constructive Alignment Bruch betrachtet und wird nach und nach durch Ab- zwischen Learning Outcome, Vorlesungs- und Übungs- kehr von kleinen Teilaufgaben zu wenigen komple- inhalten und der Prüfung vereinfacht wird. xeren Aufgaben vollzogen. Als Zwischenstufe wird eine Klassifikation der Teilaufgaben, wie von Waffen- schmidt (Waffenschmidt (2013)) vorgeschlagen, mit Literatur entsprechendem Bewertungsschema angestrebt. [Biggs u. Tang 2007] B IGGS, J. ; TANG, C.: Teaching for Quality Learning. McGraw-Hill Companies,Inc., Fazit 2007 Die hier gezeigte Übernahme von Vorgehensmodellen [Bloom 1972] B LOOM, Benjamin S. ; B LOOM, Benja- des Softwareengineerings erscheint vielleicht unge- min S. (Hrsg.): Taxonomie von Lernzielen im kogni- wöhnlich, hat uns aber einen guten Überblick ver- schafft und Hinweise für das jeweils weitere systema- 3 Falls Leser sich auf einen ähnlichen Weg begeben, wären wir tische Vorgehen gegeben. an entsprechenden Daten interessiert. 108 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 tiven Bereich. 4. Beltz Verlag, Weinheim und Basel, [Zürich 2008] Z ÜRICH ; H OCHSCHULDIDAKTIK, Uni- 1972 versität Zürich. A. (Hrsg.): Leistungsnachweise in modularisierten Studiengängen: Dossier. Universität [Böttcher u. a. 2011] B ÖTTCHER, Axel ; T HURNER, Ve- Zürich, Arbeitsstelle für Hochschuldidaktik, 2008 ronika ; M ÜLLER, Gerhard: Kompetenzorientierte Lehre im Software Engineering. In: L UDEWIG, Jo- chen (Hrsg.) ; B ÖTTCHER, Axel (Hrsg.): Software Engineering im Unterricht der Hochschulen (SEUH 2011). München : dpunkt.verlag, Heidelberg, 2011, S. 33–39 [Brabrand 2008] B RABRAND, Claus: Teaching Teaching & Understanding Understanding. DVD, 2008 [Dallmeier u. a. 2013] D ALLMEIER, Valentin ; G ROSS, Florian ; H AMMACHER, Clemens ; H ÖSCHELE, Matt- hias ; JAMROZIK, Konrad ; S TREIT, Kevin ; Z ELLER, Andreas: Muster der Softwaretechnik-Lehre. In: S PILLNER, Andreas (Hrsg.) ; L ICHTER, Horst (Hrsg.): Software Engineering im Unterricht der Hochschulen (SEUH 2013). Aachen : dpunkt.verlag, Heidelberg, 2013, S. 101–102 [Hammerschall u. Beneken 2013] H AMMERSCHALL, U. ; B ENEKEN, G.H.: Software Requirements. Pearson Studium, 2013. – ISBN 9783868941517 [Hummel 2013] H UMMEL, Oliver: Transparente Bewertung von Softwaretechnik-Projekten in der Hochschullehre. In: S PILLNER, Andreas (Hrsg.) ; L ICHTER, Horst (Hrsg.): Software Engineering im Unterricht der Hochschulen (SEUH 2013). Aachen : dpunkt.verlag, Heidelberg, 2013, S. 103–114 [Kennedy 2007] K ENNEDY, D.: Writing and Using Learning Outcomes: A Practical Guide. University College Cork, 2007. – ISBN 9780955222962 [Liebehenschel 2013] L IEBEHENSCHEL, Jens: Software-Engineering Projekte in der Ausbildung an Hochschulen - Konzept, Erfahrungen und Ideen. In: Software Engineering im Unterricht der Hochschulen (SEUH 2013). Heidelberg : .verlag, 2013, S. 27–34 [Lotter 2005] L OTTER, Wolf: DER ROTE FADEN. In: Brandeins 02 (2005) [Macke u. a. 2012] M ACKE, G. ; H ANKE, U. ; V IEH - MANN , P.: Hochschuldidaktik: Lehren – vortragen – prüfen – beraten. Beltz, 2012 [Reis 2013] R EIS, Oliver: Kompetenzorientierte Prü- fungen: Prüfungstheorie und Prüfungspraxis. In: G UTGE -W ICKERT, Angelika (Hrsg.) ; K ESSLER, Ulri- ke (Hrsg.): Die homöopathische Behandlung chroni- scher Krankheiten, 2013 [Waffenschmidt 2013] WAFFENSCHMIDT, Eberhard: Kompetenzorientierte schriftliche Prüfungen. In: Handbuch Qualität in Studium und Lehre (2013) Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 109