Software Engineering Im Unterricht Der Hochschulen

16. Workshop Tagungsband

SEUH 2019

Software Engineering im Unterricht der Hochschulen

21. und 22. Februar 2019 Hochschule Bremerhaven

Qualität im Fokus der Software Engineering Ausbildung

Herausgeberschaft Veronika Thurner, Hochschule München Oliver Radfelder, Hochschule Bremerhaven Karin Vosseberg, Hochschule Bremerhaven Inhaltsverzeichnis

Vorwort Veronika Thurner...... 2 Software-Tests automatisch erzeugen - Frische Ansätze für Forschung, Praxis und Lehre Andreas Zeller, CISPA Helmholtz-Zentrum für Informationssicherheit, Saarbrücken...... 4 Meine Lehren aus 10 Jahren Forschung und Lehre als Säulen unseres Firmenwachstums Elmar Jürgens, CQSE GmbH, Garching b. München...... 5 Test Architects at Siemens Peter Zimmerer, Siemens AG, München...... 6 Agile is real - Alltag in einem XP Office Eleonora Scherl, Volkswagen AG...... 7 UML in der Hochschullehre: Eine kritische Reflexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln...... 8 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg...... 21 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München 34 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln...... 44 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München... 56 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven...... 65 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal...... 75 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein..... 87 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin...... 99 Lernzieldefinitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München...... 112 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München...... 125 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München...... 133 *

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 1 Vorwort

Dieser Tagungsband begleitet den 16. Workshop Das Programmkomitee wählte aus 16 Einreichun- „Software Engineering im Unterricht der Hochschulen“ gen 12 Beiträge aus, die sich überwiegend folgenden (SEUH 2019) an der Hochschule Bremerhaven. Themenschwerpunkten zuordnen lassen:

Tradition der SEUH Die kritische Auseinandersetzung mit Modellen und Methoden Seit der ersten SEUH im Jahre 1992 haben sich ei- • Brauchen wir überhaupt noch UML in der Bache- nige Eigenschaften der Tagung herausgebildet, die lorausbildung? als SEUH-typisch bezeichnet werden können und die Jochen Ludewig, einer der Gründungsväter der Ta- • Welche formale Methoden sollen vermittelt wer- gungsreihe, im Vorwort des Tagungsbandes der SEUH den? 2011 sehr schön aufgelistet hat: Neben Konstanten wie einem stabilen Termin (immer Ende Februar in • Wie kann ein Werkzeug zur Unterstützung von den ungeraden Jahren), Deutsch als Tagungssprache, Code-Reviewern in der Bewertung aussehen? einer niedrigen Teilnahmegebühr und dem informel- Kompetenzen in der Durchführung von len Vorabendtreffen ist vor allem hervorzuheben, dass Projekten dies eine Tagung zum intensiven Austausch zwischen • Interessierten von Universitäten UND Fachhochschu- Können wir Projektmanagement lernen und leh- len ist. ren ohne Projekte? • Brauchen alle Projektbeteiligten algorithmisches Thematische Schwerpunkte der SEUH 2019 Denken? Der 16. SEUH-Workshop wird gemeinsam mit der • Wie werden Grundfertigkeiten zur Selbstverständ- Fachtagung der GI-Fachgruppe „Test, Analyse und Ve- lichkeit? rifikation von Software“ (TAV) unter dem Motto „Qua- lität im Fokus der Software Engineering Ausbildung “ Erfahrungen mit unterschiedlichen durchgeführt. Lernformaten Der Tradition folgend, schafft auch die diesjährige • Wie können empirische Methoden in Projekten Tagung einen Rahmen für die Diskussion zu aktuellen vermittelt werden? Fragen der Softwaretechnik im Kontext der Hochschul- lehre. Diese Fragen führen zu altbekannten Themen, • Wie können aktive Lernumgebungen gestaltet wer- die wiederholt Programmpunkte seit 1992 sind, aber den? auch zu neuen Themen, die sich insbesondere aus Ver- • Welche Erfahrungen gibt es mit integrierten Pra- änderungen der industriellen Softwareentwicklung xisprojekten im Studium? und den Qualitätsanforderungen in einer sich schnell verändernden Welt ergeben. Dieses Spektrum spiegeln • Wie definieren wir Lernziele im Software Enginee- auch die vier eingeladenen Vorträge wider: Andreas ring? Zeller blickt auf frische Ansätze für Forschung, Praxis und Lehre in der Testautomatisierung. Peter Zimmerer Agile Projekte mit crossfunktionalen Teams stellt vor dem Hintergrund seiner langjährigen Pra- • Wie werden Entscheidungen in agilen Teams ver- xiserfahrungen die Anforderungen an Kompetenzen waltet? von Testarchitekten zur Diskussion. Während Elmar Jürgens und Eleonora Scherl Methoden des Software • Wie vermitteln wir Usability Engineering in agilen Engineering reflektieren, die essentielle Grundlagen Teams? für ihre agilen Projekte und in ihren Unternehmen Wir hoffen, dass die ausgewählten Beiträge auch in sind. diesem Jahr die Grundlage für anregende Diskussio- Mit diesen Vorträgen spannen wir einen Bogen über nen bilden. ein breites Spektrum an Kompetenzen, die wir im Soft- ware Engineering vermitteln und stärken wollen. Mit den eingereichten Beiträgen haben wir eine Vielzahl von konkreten Beispielen, die zum Diskutieren oder auch zum Nachahmen anregen.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 2 Vorwort Veronika Thurner

Dank Programmkomitee der SEUH 2019 Eine Tagung wie die SEUH ist nicht denkbar ohne Ruth Breu, Uni Innsbruck die Menschen, die die Wichtigkeit von Diskussion und Bernd Brügge, TU München Dialog zwischen Gleichgesinnten erkannt haben und dies durch ihre Unterstützung zum Ausdruck bringen. Anna Hauptmann, HS Dresden Ihnen wollen wir an dieser Stelle danken. Maritta Heisel, Uni Duisburg-Essen Zu allererst bedanken wir uns bei den Fachkolle- ginnen und Fachkollegen, die Beiträge eingereicht Marco Kuhrmann, TU Clausthal und damit eine Auswahl ermöglicht haben. Dem Pro- Dieter Landes, HS Coburg grammkomitee danken wir für die Begutachtung der Beiträge, deren Einordnung in das Programm sowie Barbara Paech, Uni Heidelberg das hilfreiche Feedback für die Verbesserung der Bei- Oliver Radfelder (Organisation), HS Bremerhaven träge. Karin Vosseberg und Oliver Radfelder von der Hoch- Kurt Schneider, Uni Hannover schule Bremerhaven und lokale Organisatoren der Juliane Siegeris, HTW Berlin SEUH 2019 danken wir für die professionelle Gestal- tung der Webseite, das tatkräftige Zupacken bei der Veronika Thurner (Vorsitz), HS München Umsetzung des Tagungsbandes, die Unterstützung bei Karin Vosseberg (Organisation), HS Bremerhaven der Planung im Vorfeld sowie die hervorragende Or- ganisation vor Ort. Des Weiteren bedanken wir uns bei den studenti- Ständiges Organisationskomitee schen Hilfskräften für ihre Unterstützung vor Ort bei Axel Schmolitzky, HS Hamburg der Durchführung der SEUH 2019. Ebenso danken wir der Hochschulleitung der Hoch- Kurt Schneider, Leibniz-Universität Hannover schule Bremerhaven für die Möglichkeit, die Räumlich- Veronika Thurner, HS München keiten und technischen Einrichtungen der Hochschule für die SEUH zu nutzen. Ein herzlicher Dank gebührt ferner den Sponso- ren, ohne deren Unterstützung die Durchführung der SEUH in dieser From nicht möglich wäre: • German Testing Board e.V.

• Merentis GmbH • dpunkt Verlag • ASQF e.V.

• GI e.V. Den Mitarbeitern des Publikationsdienstes CEUR Workshop Proceedings danken wir für die elegante und zeitgemäße Möglichkeit, diesen Tagungsband in elektronischer Form zu veröffentlichen. Wir freuen uns, mit diesem Tagungsband einen Ein- blick in die SEUH 2019 geben zu können, und wün- schen anregendes und inspirierendes Lesen.

Veronika Thurner, Hochschule München Vorsitzende des Programmkomitees

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 3 Software-Tests automatisch erzeugen – Frische Ansätze für Forschung, Praxis und Lehre

Andreas Zeller CISPA Helmholtz-Zentrum für Informationssicherheit, Saarbrücken [email protected]

Zusammenfassung Abstract Automatisch erzeugte Softwaretests können mit we- Automatically generated software tests can ﬁnd many nig menschlichem Aufwand viele Fehler ﬁnden. In errors with little human effort. In this talk I will intro- diesem Vortrag stelle ich aktuelle Techniken zur Test- duce current test generation techniques that automat- erzeugung vor, die für ein gegebenes Programm ically derive the input language of a given program vollautomatisch dessen Eingabesprache ableiten und and derive large amounts of valid test inputs from the aus den so entstehenden Grammatiken große Men- resulting grammars. Our grammar-based LangFuzz gen gültiger Testeingaben ableiten. Unser gramma- test generator has found thousands of errors in the tikbasierter LangFuzz-Testgenerator hat so in den JavaScript interpreters of Firefox, Chrome and Edge. JavaScript-Interpretern von Firefox, Chrome und Edge The techniques are summarized in the interactive book tausende Fehler gefunden. Die Techniken sind in "Generating Software Tests" (www.fuzzingbook.org). dem interaktiven Buch “Generating Software Tests” In a mixture of text and program code, readers can di- (www.fuzzingbook.org) zusammengefasst. In einer Mi- rectly experiment with the programs in their browsers schung von Text und Programmcode können Leser im and supplement and extend their code live. Browser direkt mit den Programmen experimentieren und ihren Code live ergänzen und erweitern.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 4 Meine Lehren aus 10 Jahren Forschung und Lehre als Säulen unseres Firmenwachstums

Elmar Jürgens CQSE GmbH, Lichtenbergstr. 8, 85748 Garching b. München [email protected]

Zusammenfassung Abstract Die Firma, die ich mitgegründet habe, ist vor 10 The company I co-founded 10 years ago is a spin-off Jahren als Spin-Off unserer Forschungsarbeiten zu of our research on software quality at the TU Munich. Software-Qualität an der TU München entstanden. Since then, we have grown to 35 employees, half Seitdem sind wir auf 35 Mitarbeiter gewachsen, von of whom have a PhD in software engineering. Our denen die Hälfte ihre Promotion im Bereich Software- research prototypes have developed into a commer- Engineering gemacht hat. Aus unseren Forschungs- cial analysis tool that is used daily by developers and prototypen ist in dieser Zeit ein kommerzielles Analy- testers all over the world. sewerkzeug entstanden, das täglich von Entwicklern Research and education were not only the trigger und Testern auf der ganzen Welt eingesetzt wird. for our foundation, but also continue to play a central Forschung und Lehre waren dabei nicht nur der role in innovation and growth. In this keynote I would Auslöser unserer Gründung, sondern spielen auch like to present my central experiences and surprises weiterhin eine zentrale Rolle für Innovationen und from 10 years of research, teaching and company Wachstum. In dieser Keynote möchte ich meine zen- building in the ﬁeld of software quality analysis. tralen Erfahrungen und Überraschungen aus 10 Jah- ren Forschung, Lehre und Firmenaufbau im Bereich Software-Qualitätsanalysen vorstellen.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 5 Test Architects at Siemens

Peter Zimmerer, Siemens AG, [email protected]

Abstract experiences and lessons learned since the Test Ar- chitect program was launched in 2016 (see [3]): At Siemens we have invented and defined a new • Why do we need a Test Architect? key role Test Architect to meet the diverse challen- • What is a Test Architect? ges of shorter time-to-market, increasing com- • What are the responsibilities and tasks of a Test plexity and more agility while keeping quality and Architect? other key system properties high. In the real world • How can a Test Architect provide value and our test systems increase in size, volume, flexibility, create impact on the business? velocity, complexity and unpredictability: think about testing of autonomous systems or testing of Attend this presentation and learn what a Test Ar- AI systems (artificial intelligence). Additionally, chitect is all about and why we at Siemens are driv- digitalization (virtualization, cloud, mobile, big ing this forward. We are continuing our journey in data, data analytics, internet of things, continuous this direction – at Siemens our target is to have delivery, DevOps) requires more than just a face lift nearly 50 certified Test Architects by the end of in testing. 2019. That means a tremendous upgrade and em- This talk shares our motivations, decisions, powerment of testing! achievements, and experiences on our journey since 2016 to establish this new key role Test Architect on Key Takeaways eye level with the software architects within the • Understand the rationale why we need a new company. key role Test Architect • Get familiar with a thorough definition of a real Talk Description Test Architect – it’s not just another fancy title What is a “Test Architect”? At Siemens we have that is misused invented this new key role by defining the respon- • Get to know the responsibilities and tasks of a sibilities and tasks of a Test Architect and this talk Test Architect – job profile, contents, focus is about our journey to establish this new key role points within the company. • Apply discussed strategies, tactics, practices, Imagine that you build a system with 10 million and experiences and become a successful Test lines of code. To be successful this system should Architect – a new career path for testers! have a good architecture, and for that you need good software architects (see experience report [1]). References Next, to perform good testing on 10 million lines of (1) Paulisch, F. and Zimmerer, P. 2010. A role- code, you also need to build an appropriate test based qualification and certification program system – not by spaghetti coding but with a well- for software architects: An experience report designed, sustainable test architecture and by ap- from Siemens. In Proceedings of the Interna- plying innovative software and test technologies. tional Conference on Software Engineering, But, who is responsible and in charge to make 2010, DOI: 10.1145/1810295.1810300 this happen? Typically, neither the test manager (2) Paulisch, F. and Zimmerer, P. 2016. Collabor- nor the quality manager will do this; therefore, we ation of Software Architect and Test Architect need to create a new role on eye level with the Helps to Systematically Bridge Product Lifecy- software architects: The Test Architect is born (see cle Gap. In Proceedings of the 1st International position paper [2]). To implement and establish this Workshop on Bringing Architectural Design key role we have developed a unique expert train- Thinking Into Developers' Daily Activities ing program for Test Architects at Siemens to meet (Bridge), 2016, co-located workshop at Interna- the diverse challenges of shorter time-to-market, tional Conference on Software Engineering, increasing complexity, and more agility while 2016, DOI: 10.1145/2896935.2896936 keeping quality and other key system properties high. (3) Zimmerer, P. 2016. Test Architect a key role This talk introduces the new key role Test Ar- defined. Professional Tester Magazine, issue 39, chitect, provides practical guidance on the needed December 2016. strategies, tactics, and practices, and shares our http://www.professionaltester.com/

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 6 Agile is real – Alltag in einem XP Ofﬁce

Eleonora Scherl Volkswagen AG, Digital:Lab Berlin, Starlauer Allee 7, 10245 Berlin [email protected]

Zusammenfassung Abstract In einer sich schnell wandelnden Welt werden agile In a rapidly changing world, agile software engineer- Methoden im Software Engineering allein schon aus ing methods are becoming more and more interesting, wirtschaftlichen Gründen immer interessanter und for economic reasons alone, as well as taking more nehmen auch in den Lehrplänen mehr Platz ein. In relevance in curricula. In the talk you will get an dem Vortrag erhalten Sie Einblick in ein Software insight into a software product ofﬁce, which works Product Ofﬁce, welches vollumfänglich mit schlanken completely with lean (Lean Startup) and agile (XP) (Lean Startup) und agilen (XP) Methoden arbeitet. Er- methods. Learn how, what and why we think this fahren Sie wie, was und warum wir denken, dass dies is the ’state of the art’ approach to modern software das ’State of the Art’ Vorgehen für modernes Software engineering to overcome uncertainty gracefully. Engineering ist.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 7 UML in der Hochschullehre: Eine kritische Reflexion

Jürgen Anke, Hochschule für Telekommunikation Leipzig Stefan Bente, Technische Hochschule Köln [email protected], [email protected]

Zusammenfassung Abstract Trotz ihrer hohen Bekanntheit und Verbreitung ist Despite its pervasiveness and popularity, the Uni- die Unified Modelling Language (UML) 20 Jahre fied Modeling Language (UML) is not uncontro- nach der Vorstellung ihrer ersten Version in der versial in software engineering 20 years after the Softwaretechnik nicht unumstritten. Ein wesentli- launch of its first version. A major reason is their cher Grund ist ihre unklare Nutzung in der Praxis unclear use in practice, which is influenced by the die u.a. durch Ausdifferenzierung von Software- differentiation of software product types, agile produktarten, agilen Entwicklungsansätzen sowie development approaches and microservices as Microservices als Architekturstil mit reduzierter architectural style with reduced complexity. These Komplexität beeinflusst wird. Diese Trends beför- trends move away from traditional top-down, se- dern eine Abkehr von klassischen Top-Down- quential approaches that require extensive specifi- Ansätzen mit sequenziellem Vorgehen, das um- cations of requirements and design. For teaching fangreiche Spezifikationen der Anforderungen und (especially at the Bachelor level), therefore, the des Entwurfs erfordert. Für die Lehre (insbesonde- question arises whether we still need UML at all re auf Bachelorniveau) stellt sich daher die Frage, and if so, for what and to what extent. The aim of ob wir UML überhaupt noch brauchen und wenn this paper is to gather empirical evidence on the ja, wofür und in welchem Umfang. Ziel dieses Bei- relevance of UML and to draw conclusions for pos- trags ist es, empirische Belege zur Relevanz der sible competence goals in software engineering UML zusammenzutragen und daraus Schlussfolge- education. Our goal is to provide an up-to-date rungen für mögliche Kompetenzziele in der Soft- view of the practical relevance of UML to stimulate waretechnikausbildung zu ziehen. Unser Ziel ist es, discussion about the role of UML in software engi- eine aktuelle Sicht auf die praktische Relevanz der neering courses. UML zu liefern und damit die Diskussion über die Ausgestaltung der Lehre im Fach Softwaretechnik anzuregen.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 8 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Einleitung und Motivation Praxis wird anhand von bestehenden Studien bewertet. Daneben haben wir eine Analyse von stu- Die Beschreibung bestehender oder geplanter Sys- dentischen Projekt- und Abschlussarbeiten hin- teme ist eine wichtige Teilaufgabe im Software sichtlich ihrer Nutzung von grafischer Modellie- Engineering. Dies wird vielfach mit grafischen rung durchgeführt. Modellen der Unified Modelling Language (UML) durchgeführt. Die UML ist der De-facto-Standard die grafische Modellierung von objektorientierten Systemen, um deren Analyse, Entwurf und Doku- mentation zu unterstützten (Rupp, Queins, & SO- PHISTen, 2012; Sommerville, 2015). Folgerichtig ist das Erlernen der UML ein wichtiger Bestandteil in vielen Software Engineering Modu- len an Hochschulen, wie es auch in den Rahmen- empfehlungen der Gesellschaft für Informatik (GI) verankert ist (Gesellschaft für Informatik, 2016). Jedoch ist die UML auch in der Lehre aus unserer Erfahrung nicht unumstritten. Aus unserer Sicht sind mögliche Gründe dafür z.B.:

- Die Relevanz der UML in der Praxis scheint zurückzugehen, da umfangreiche Spezifikatio- Abb. 1: Google Trends für Begriffe des Software nen in agilen Entwicklungsansätzen wie z.B. Engineerings (2004-2018, nur Deutschland) Scrum nicht mehr erforderlich sind. - Aufgrund ihrer Komplexität ist die UML Dieser Beitrag ist wie folgt aufgebaut: Zunächst schwer zu erlernen (Erickson & Siau, 2007; ordnen wir die UML historisch ein, diskutieren die Seiko Akayama u. a., 2013). Einsatzfelder sowie den Nutzen der Modellierung. - Besondere Schwierigkeiten verursacht die Ver- Anschließend erfolgt die Analyse von Studien zur bindung verschiedener Sichten auf das Soft- Nutzung von UML in der Praxis sowie studenti- waresystem (Boberić-Krstićev u. a., 2011). schen Arbeiten. Nach der Diskussion der Ergebnis- - Klassische UML-Tools führen aufgrund ihrer se leiten wir Schlussfolgerungen für die Rolle der Komplexität in der Lehre oft zu Herausforde- UML in der Lehre ab. rungen (Liebel, Heldal, & Steghofer, 2016; Seiko Akayama u. a., 2013). UML in der Softwaretechnik - Der Nutzen der Modellierung erschließt sich Studierenden nicht (Boberić-Krstićev u. a., Entstehung der UML 2011; Burgueño, Vallecillo, & Gogolla, 2018). Im Methodenkrieg der 1990er Jahre gab eine Reihe Der Eindruck einer sinkenden Bedeutung von UML konkurrierender Ansätze für objektorientierte Me- wird auch anhand der Google Trends deutlich, thoden und Modellierungssprachen. Die erste Ver- welche die relative Häufigkeit von Suchanfragen sion der UML wurde 1997 als Vereinigung einer betrachtet (Abb. 1). Hierbei wurde der Zeitraum aus der „Unified Method“ nach Rumbaugh/Booch 2004-2018 sowie die Region Deutschland gewählt. und dem „Object Oriented Software Engineering“ Zudem wurde mit „Themen“ statt Suchbegriffen nach Jacobsen gebildet. Der Toolhersteller Rational gearbeitet, die verschiedene Formulierungen und unterstützte die UML bereits damals und trug da- Schreibweisen berücksichtigen. mit zu ihrer Verbreitung bei (Rupp u. a., 2012). In Vor diesem Hintergrund stellt sich die Frage, ob den folgenden Jahren fand eine Erweiterung der und wie die UML in der grundständigen Software UML um weitere Diagrammtypen und Konstrukte Engineering Ausbildung zu integrieren ist. Dazu wie der Object Constraint Language (OCL) statt. haben wir uns in diesem Beitrag an folgenden Leit- Zur Standardisierung wurde die UML schließlich fragen orientiert: an die Object Management Group (OMG) überge- ben. In der aktuellen Version 2.5 enthält die UML - Wie und wofür wird die UML in der Praxis insgesamt 14 Diagrammtypen, von denen jeweils tatsächlich eingesetzt? sieben zur Beschreibung der Struktur (z.B. Klassen- - Welche Kompetenzen sollten dafür durch die diagramm, Verteilungsdiagramm, Paketdiagramm) Hochschullehre entwickelt werden? und sieben zur Beschreibung des Verhaltens (z.B. Grundlage dieser Arbeit sind empirische Studien Use-Case Diagramm, Aktivitätsdiagramm, Se- über den Einsatz der UML anhand ihrer tatsächli- quenzdiagramm) dienen. chen Nutzung. Die Relevanz in der industriellen

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 9 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Einsatzfelder und Modellarten Nutzen der Modellierung Modelle können beschreibend (deskriptiv) oder Die Verwendung von UML für die Modellierung vorschreibend (präskriptiv) sein. Beschreibende im Software Engineering soll sowohl Produktquali- Modelle werden einerseits für die Systemdokumen- tät als auch Entwicklungsproduktivität verbessern. tation und andererseits in der Analyse für die Be- Die Zwischenschritte zu diesen Wirkungen entste- schreibung des Problemraums (Domänenmodell, hen in den Kategorien Entwickler, Team, Prozess Geschäftsprozesse usw.) eingesetzt. Präskriptive und Produkt, wie eine Studie von Chaudron u. a. Modelle hingegen werden für den Entwurf und die (2012) ergeben hat (siehe Abb. 2). Insgesamt lässt Implementierung eingesetzt, da sie einen Bauplan sich sagen, dass das Ziel der Nutzung von UML im („Vorschrift“) für ein zu realisierendes System be- Verstehen, Beschreiben und Kommunizieren von schreiben. Für die automatische Codeerzeugung existierenden oder geplanten Softwaresystemen in auf Basis eines solchen Modells ist ein hoher De- verschiedenen Lebenszyklusphasen (Analyse, Ent- tailgrad und ein für die Zielplattform geeigneter wurf, Implementierung, Wartung) besteht. Ivar Generator erforderlich. Wenn hingegen ein Pro- Jacobson, einer der Gründerväter von UML grammierer die Implementierung manuell durch- schreibt dazu: „Used appropriately it is a practical führt, kann dieser auf Basis seiner Interpretations- tool for raising the level of abstraction on software fähigkeiten auch mit einem weniger formalen Mo- from the level of code to the level of the overall dell arbeiten. Tab. 1 fasst die verschiedenen Aufga- system” (Jacobson, 2009). ben, Modellarten und Beteiligte zusammen. Die zentrale Rolle der Modellierung wird auch Je nachdem, wofür die UML eingesetzt wird, gibt durch den Guide to the Software Engineering Body of unterschiedliche Anforderungen an die Modelle Knowledge (SWEBOK) unterstrichen. Hier wird die und demnach auch die Fähigkeiten der Modeller- UML als eine mögliche Modellierungssprache ge- steller und -nutzer. Sommerville nennt für die Mo- nannt und auf die Notwendigkeit verwiesen, eine dellierung von Systemen drei verschiedene Absich- für die jeweilige Aufgabenstellung geeignete grafi- ten, die jeweils unterschiedliche Grade an Detaillie- sche Notation auszuwählen (Bourque, Fairley, & rung und Rigorosität in der Anwendung der Mo- IEEE Computer Society, 2014). dellierungssprache erfordern (Sommerville, 2015): - Diskussionen über ein bestehendes oder geplantes System: Diese Modelle können unvollständig Phase Analyse Entwurf Imple- Doku- sein und die Notationen der Modellierungs- men- mentation sprache informell verwenden. tierung - Dokumentation eines bestehenden Systems: Diese Original Problem- Analyse- Ent- Implemen- Modelle müssen ebenfalls nicht vollständig / Grund- raum modell wurfsmo- tiertes sein, wenn nur Teile des Systems dokumentiert lage dell System werden. Jedoch ist Korrektheit und Genauig- Modell- Analyse- Entwurfs- (Code) Entwurfs- keit erforderlich. inhalte modelle, modelle, modell, - Codegenerierung: Präzise Systembeschreibung z.B. Do- z.B. Da- z.B. Da- als Basis für die Erzeugung der Implementati- mänen- tenstruk- tenstruk- on in einer modell-basierten Entwicklung. modell, turen, turen, Dies ist im Wesentlichen übereinstimmend mit der Geschäfts- System- System- Systematisierung von Chaudon et.al., die prozesse architektur architektur 1. Modelle zur Analyse und Verstehen Ersteller Mensch Mensch Mensch Mensch / 2. Modelle zur Kommunikation Maschine 3. Modelle als Vorlage für die Implementierung Nutzer Mensch Mensch Mensch / Mensch 4. Modelle als Basis für die Codegenerierung Maschine unterscheiden (Chaudron, Heijstek, & Nugroho, 2012). Die Reihenfolge dieser Nutzungsarten (von Modell- Informell, präzise, präzise, Vollstän- den Autoren als modeling styles bezeichnet) gibt qualität geringer mittlerer hohe De- dig, kor- ebenfalls die steigende Anforderung an Modellqua- Detailgrad Detailgrad taillierung rekt, ge- lität bzw. Genauigkeit an. nau

Tab. 1: Modellarten und ihre Eigenschaften

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 10 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Abb. 2: Nutzen der UML Modellierung (Chaudron u. a., 2012)

- Nur für Validierung von Anforderungen mit UML-Nutzung durch Praktiker dem Kunden wurde der Nutzen bei Aktivi- täts- und Use Case-Diagrammen am höchs- Für die Beurteilung der praktischen Relevanz von ten eingeschätzt. UML stützen wir uns auf Studien, die den Einsatz - Der Einbezug von Kunden wurde anhand der UML in der Praxis untersucht haben. Dabei ihrer Mitwirkung beim Entwickeln, Prüfen werden einerseits die empirisch ermittelte Nutzung und Freigeben von Modellen bewertet. In al- von UML-Modellelementen und andererseits die len Fällen wird das Use Case Diagramm Verwendungszwecke untersucht. am häufigsten genannt, gefolgt vom Akti- Häufigkeit von Modellelementen der UML vitätsdiagramm. 3) Analyse von Lehrbüchern, UML Tutorials, Die Frage nach der Nutzung der UML anhand der Hochschulkursen (Gianna Reggio, Maurizio tatsächlichen Verwendung von Diagrammtypen Leotta, Filippo Ricca, & Diego Clerissi, 2013) und Modellelementen wurde in den letzten 15 Jah- - In Hochschulkursen sind Klassen-, Se- ren mittels verschiedener Methoden untersucht. quenz-, Aktivitäts-, Use Case- und Zu- Die Ergebnisse und die zugrundeliegende Methode standsdiagramme besonders häufig. werden nachfolgend kurz vorgestellt. - In UML Tutorials zusätzlich dazu Kompo- 1) Delphistudie (Erickson & Siau, 2007) nenten- und Verteilungsdiagramme. - Enterprise Systeme: 1. Klassen-, 2. Use - Die am seltensten genutzte Diagrammty- Case-, 3. Sequenz-, 4. Aktivitätsdiagramme pen sind Timing-, Profil-, Interaktionsüber- - Echtzeitsysteme: 1. Klassen-, 2. Zustands-, sichts- und Kompositionsstrukturdia- 3. Sequenz-, 4. Use Case-Diagramme gramme. - Web Applikationen: 1. Klassen-, 2. Use 4) Quantitative Analyse von Open UML Model- Case-, 3. Sequenz-, 4. Zustandsdiagramme len, N=121 (Langer, Mayerhofer, Wimmer, & Kap- 2) Befragung, N=284 (Dobing & Parsons, 2010) pel, 2014) - 73% der Befragten nutzten in mind. 2/3 ih- - Häufigste Sprachelemente: Class (100%), rer Projekte Klassendiagramme, gefolgt Use Case (47%), Interactions (39%) von Use Case (51%) und Sequenzdia- - Häufigste Elemente in Interaktionsdia- grammen (50%) grammen: Message, Lifeline - Klassen- und Sequenzdiagrammen wurden - Profile werden häufig für Robustness- für die Aufgaben Implementierung, Doku- Diagramme u. Datenbankschemata genutzt mentation, Erklären/Verständnis im Team am - Klassen sind die am häufigsten mit Stereo- häufigsten ein mindestens begrenzter Nut- typen versehenen Modellelemente. zen zugeschrieben.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 11 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

5) Experteninterviews, N=50 (Petre, 2013) - Das Verhältnis von modellierten Klassen - 35 von 50 Befragten nutzen UML gar nicht, und implementierten Klassen lag zwischen v.a. wegen des Fokus auf die Softwarear- 4% im größten Projekt (~900 Klassen) und chitektur und nicht auf das ganze System 40% im kleinsten Projekt (<60 Klassen) (fehlender Kontext), dem hohen Aufwand - Nur wenige Projekte aktualisierten ihre ini- zum Verstehen der UML (unnötige Kom- tialen Modelle, meist wurden bei neuen plexität) sowie Problemen von Synchroni- Features neue Modelle hinzugefügt. sierung bzw. Inkonsistenzen zwischen 3) Befragung zum Einsatz von Entwurfsmodellen, Modell und Code bzw. Modellsichten N=3785 (Gorschek, Tempero, & Angelis, 2014) - 11 von 50 Befragten nutzen UML nur selek- - Entwurfsmodelle werden in der Praxis tiv, besonders in frühen Phasen zur Bewer- nicht häufig verwendet. tung von Ideen, auch im Team. Sie weniger - Modelle werden eher informell und ohne verwendeten UML meist in kleineren Mo- Toolsupport erstellt. dellen, adaptierten die Notation an ihre - Die Notation ist tendenziell nicht UML. Bedürfnisse und beendeten die Verwen- - Die Nutzung von Modellen nimmt mit dung, wenn UML in der jeweiligen Pro- Grad an Erfahrung und Qualifikation ab jektphase nicht mehr gebraucht wurde. - Modelle werden eher zur Kommunikation - 3 der 50 Befragten nutzten UML für die au- und Zusammenarbeit genutzt und auf tomatische Codeerzeugung. Die entspre- Whiteboard oder Papier gezeichnet und chenden Einsatzfälle waren Software für werden nach Erstellung selten aktualisiert. eingebettete System oder Produktlinien. 4) Befragung zum Einsatz von Skizzen und Dia- grammen im Software Engineering, N=394 Einsatz von konzeptioneller Modellierung (Baltes & Diehl, 2014) Bei diesem Aspekt geht es um die Erhebung von - 48% aller Skizzen enthalten einige UML- Einsatzfällen für Modellierung, z.B. in Anhängig- Elemente, 9% ausschließlich UML. keit von Unternehmensgrößen, Modellierungser- - Die Hälfte der Skizzen wurde von einer fahrung, Projekttyp oder Entwicklungsphase. Die einzelnen Person angefertigt, 28% von zwei hier betrachtete konzeptionelle Modellierung um- und 15% von drei Personen. fasst auch andere Sprachen, nicht nur die UML. - 58% aller Skizzen wurde analog (Papier, Wie auch schon bei den Studien zur Häufigkeit von Whiteboard) angefertigt, 40% digital. Modellelementen werden hierfür unterschiedliche - Digitale Skizzen werden im Vergleich zu Forschungsmethoden eingesetzt. analogen Skizzen zu einem höheren Teil 1) Befragung zur Modellierung, N=312 (Davies, (77%) überarbeitet und archiviert (94%).

Green, Rosemann, Indulska, & Gallo, 2006) - Wesentliche Einsatzzwecke sind Entwerfen - Die häufigsten regelmäßig eingesetzten (75%), Erklären (65%), Verstehen (56%) Modellierungstechniken sind ER- sowie Anforderungen analysieren (45%). Diagramm (42%), Datenflussdiagramm Zwischenfazit und Diskussion (34%) und Flowcharts (29%). UML ist mit 21% auf Platz 5. Da einige Studien z.T. schon über 10 Jahre alt sind, - Die meistgenutzten Tools sind MS Visio können die Ergebnisse der Studien nur mit Vor- (44%) und Rational Rose (11%). sicht auf die heutige Verwendung extrapoliert - Unternehmensgröße: Die UML wird bei werden. Dennoch lassen sich gewisse Tendenzen mittleren Unternehmen (100-1000 Mitarbei- bei der Nutzung von UML (bzw. konzeptionellen ter) häufiger eingesetzt als bei kleineren Modellierungsansätzen insgesamt) in der Praxis oder größeren Unternehmen. der Softwareentwicklung durchaus ausmachen. - Modellierungserfahrung: Mitarbeiter mit 4- Tendenzen in der UML-Nutzung 10 Jahren Erfahrung nutzen häufiger kon- Die UML hat gemäß den ausgewerteten Studien in der zeptionelle Modelle als Kollegen, die kür- Praxis eine sehr hohe Bekanntheit und auch eine hohe zere oder längere Erfahrung haben. Nutzung. Allerdings werden in der Praxis die ein- - Die häufigsten Einsatzzwecke für konzep- zelnen Diagrammtypen unterschiedlich häufig tionelle Modellierung sind (1) Datenbank- verwendet. Insbesondere Klassen-, Aktivitäts-, Use- design/–management, (2) Geschäftspro- Case- und Sequenzdiagramme sind verbreitet. zessdokumentation, (3) Interne Prozess- verbesserung, (4) Softwareentwicklung, (5) Die Verwendungszwecke sind oft in frühen Phasen der Verbesserung kollaborativer Prozesse. Systementwicklung, z.B. zur Unterstützung der Ana- 2) Analyse der Repositories von Open Source lyse. Dabei spielt Modellierung besonders für die Projekten, N=10 (Osman & Chaudron, 2013) Kommunikation und Zusammenarbeit zwischen den Beteiligten eine wichtige Rolle.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 12 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Modelle sind häufig informell oder werden mit infor- trachtet. Ein Beleg ist etwa das Prinzip 11 des Agi- mellen Notationen gemischt. Alternativen zur Mo- len Manifests: “The best architectures (…) and de- dellierung mit UML sind weniger formelle Model- signs emerge from self-organizing teams”, (Beck lierungsansätze wie das C4-Architekturmodell u. a., 2001), kritische Aussagen zu „klassischer“ (Brown, 2018), textuelle Domain Specific Langu- Softwarearchitektur finden sich darüber hinaus an ages (DSL) oder auch Ad-Hoc-Notationen. vielen Stellen in der agilen Literatur (z.B. Coplien & Als Medien werden neben Papier und Whiteboard auch Bjørnvig, 2010, S. 85). Diese Grundhaltung trägt verschiedene Tools eingesetzt, wobei diese nicht not- dazu bei, dass formale Modellierung in agilen Pro- wendigerweise klassische UML-Modellierungstools jekten weniger verbreitet ist, auch wenn seit mehre- sind. Wenn ein konsistentes Gesamtmodell mit ren Jahren eine Reihe von Frameworks existieren, vielen untereinander verbundenen Sichten weniger die agiles Vorgehen mit Architekturplanung ver- wichtig ist, kann auf ein Model Repository verzich- binden (siehe z.B. Cockburn, 2006; Larman & Vod- tet werden. In diesen Fällen können auch Zeichen- de, 2009; Leffingwell, 2007). tools wie Visio oder eines der zahlreichen auf Kol- Microservices haben keine zentralen Modelle mehr. Das laboration ausgelegten webbasierten Zeichenwerk- Aufkommen des Microservice-Architekturstils als zeuge für die UML-Modellierung genutzt werden. Alternative zur monolithischen oder service- Die Erzeugung von Code aus UML-Modellen spielt in orientierten Architektur ist eng verbunden mit der der Praxis eine sehr untergeordnete Rolle. Der An- agilen Vorgehensweise. Microservices sind so weit satz der modellgetriebenen Architektur (MDA) mit wie möglich lose gekoppelt, unter Inkaufnahme umfangreicher Codeerzeugung aus detaillierten von Daten-Redundanzen. Eine klassische Top- UML-Modellen hat sich im Wesentlichen nur in für Down-Modellierung von Applikations-, Daten- langlebige Systeme in gut verstandenen Domänen und Technologiearchitektur findet hier nicht mehr etabliert (Sommerville, 2015). statt (oder in einer wesentlich abstrakteren, Prinzi- pien-orientierten Weise, die nicht unbedingt mehr Gründe für die veränderte Nutzung von UML eine formale Modellierung erfordert). Trotz ihrer Verbreitung wird die UML in der Praxis Die Services selbst sind eher klein und interagieren in sehr unterschiedlichem Maße eingesetzt. Hierfür mit ihrer Umgebung häufig durch REST- und lassen sich eine Reihe von Gründen identifizieren. Eventschnittstellen, die sich ebenfalls gut ohne eine Die zunehmende Diversifizierung von Softwarepro- graphische Modellierung spezifizieren lassen. Die- duktarten schränkt der Nutzen einer einheitlichen Mo- se maximal autarken Softwareeinheiten ermögli- dellierungssprache ein. Die Diversität der Software- chen eine idealtypische Anwendung des agilen landschaft insgesamt nimmt zu. Beispiele sind die Ansatzes selbstorganisierter, autarker und im We- weite Verbreitung von Webapplikationen und mo- sentlichen auf mündliche (oder zumindest infor- bilen Apps oder das Nebeneinander von Endkun- melle) Kommunikation ausgerichtete Entwick- denorientierten E-Commerce-Applikationen neben lungsteams. Eine Modellierungssprache wie UML, klassischen betrieblichen Informationssystemen die inhärent von einem zentralen Gesamtmodell oder sicherheitskritischen Echtzeitsystemen. Diese mit vielen komplementären Sichten ausgeht, stiftet verschiedenen Softwareprodukte unterscheiden in diesem Kontext nur geringen Nutzen. sich sowohl in ihren technischen Plattformen wie Domain Driven Design modelliert fachlich und weniger auch in ihren typischen Projektkonstellationen komplex. Domain Driven Design (Evans, 2003) ist stark voneinander. Dies betrifft u.a. die Stabilität der dem Microservice-Stil zugrundeliegende ver- der Anforderungen, die Größe des Projektteams bundene Entwurfsansatz. Der Designfokus liegt sowie den formalem Projektrahmen, was wiede- hier auf dem Verständnis und der Modellierung rum den Nutzen der Modellierung beeinflusst. der Domäne, also der Fachlichkeit einer Anwen- Agile Entwicklung braucht weniger UML. Agile Me- dung. Die Gestaltung der Applikations- und Tech- thoden basieren auf iterativer und inkrementeller nologiearchitektur rückt in Hintergrund, gemäß Entwicklung, in denen die Phasen Analyse, Ent- der Überzeugung, dass diese nachgeordnet und wurf, Implementierung, Test und Dokumentation dezentral gestaltet wird. Domain Driven Design in kurzen Zyklen wiederholt werden. Dadurch nutzt zur Analyse nicht-graphische Begrifflichkei- sinkt die Notwendigkeit einer umfangreichen Spe- ten wie die Ubiquitous Language oder informelle zifikation des gesamten Systems bzw. großer Sys- Modellierungsformen wie Context Maps (Fowler, temteile, wofür in einem klassischen Wasserfall- 2014), die nicht standardisiert sind und sich höchs- Vorgehen häufig UML eingesetzt wird. tens (im Fall der Context Map) grob an UML- In der agilen Welt wird die Rolle des Software- Klassendiagramme anlehnen. Architekten, die klassischerweise UML als wesentliches Spezifikations- und Kommunikationsinstru- ment verwendet, mit einer gewissen Skepsis be-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 13 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

UML-Nutzung durch Studierende Vorlesungen in Informatik, Medien- und Wirt- schaftsinformatik vermittelt werden (nur Zu- Wir haben anhand von 47 Abschlussarbeiten und standsdiagramme fallen aus der Reihe, die zwar Projektberichten in den Studiengängen Informatik, gelehrt, aber in den Arbeiten nicht auftreten). Da- Medien- und Wirtschaftsinformatik (Bachelor und von abgesehen bestätigen sich die Ergebnisse der Master) der TH Köln untersucht, ob und welche oben zitierten Studien zum UML-Einsatz: Eine Modellierungsansätze Studierende verwendet ha- Teilmenge der UML-Diagramme wird in der Praxis ben. Es wurden nur Arbeiten betrachtet, in denen in nennenswertem Umfang verwendet. die Konzeption und/oder Erstellung eines Soft- waresystems mindestens einen Teilschwerpunkt darstellte. Die Arbeiten durften nicht älter als fünf Jahre sein, um ein aktuelles Bild zu gewinnen. Weiterhin durfte es keinerlei Vorgaben seitens der Betreuer geben, ob (und wenn ja welche) Modellie- rungsansätze zu verwenden waren1. Da die betrachteten Arbeiten also UML nicht explizit erfordern, lässt sich aus den Ergebnissen eine Tendenz ableiten, inwiefern Studierende UML (oder kon- kurrierende Ansätze) als Mehrwert bei der Spezifi- kation und Dokumentation empfinden.

Abb. 4: Häufigkeit von UML-Diagrammen Eine weitere Erkenntnis lässt sich aus Abb. 4 ableiten: Komponentendiagramme treten in knapp 30% der Arbeiten auf, dort gibt es davon dann insgesamt 49 Instanzen. Klassen- und Use-Case- Diagramme werden in ähnlich vielen Arbeiten verwendet, aber mit weniger Instanzen. Wenn also eine Arbeit Komponentendiagramme enthält, dann in der Regel mehrere; Use-Case-Diagramme hingegen treten fast überall maximal einmal auf, bei Klassendiagrammen ist es ähnlich. Abb. 3: Modellierungsnutzung durch Studierende Einsatzkontexte graphischer Modellierung Wie Abb. 3 zeigt, verwenden weniger als die Hälfte der graphischen Modellierungen in den untersuch- Ein wesentliches Ziel der Untersuchung war es, die ten Arbeiten UML. In knapp der Hälfte der Arbei- Verwendung von UML-Diagrammen mit der von ten werden zudem UI-Mockups genutzt, die im Nicht-UML-Notationen zu vergleichen. Hierfür Folgenden jedoch nicht weiter betrachtet werden. wurden zwölf Einsatzkontexte für graphische Mo- In den analysierten Arbeiten spielen nur Klassen-, dellierung definiert, in denen neben UML auch Komponenten-, Aktivitäts-, Use-Case- und Se- andere formale Notationen sowie informelle Dar- quenzdiagramme eine nennenswerte Rolle (siehe stellungen in den untersuchten Arbeiten auftraten. Abb. 4). In jeweils einer Arbeit kommt auch ein Diese sind in Tab. 2 übersichtsweise dargestellt. Objekt- und Deployment-Diagramm zum Einsatz. Die Häufigkeit des Auftretens der verschiedenen Das mag daran liegen, dass diese Diagrammtypen Einsatzkontexte (unabhängig davon, ob UML oder gerade diejenigen sind, die in den Softwaretechnik- eine alternative Darstellung gewählt wurde) ist in Abb. 5 dargestellt. Demnach wird eine Komponen- tenstruktur in über der Hälfte der Arbeiten gra- 1 Dadurch schieden z.B. Praktikumsberichte in Veranstal- phisch modelliert, technisch-algorithmische Abläu- tungen aus, bei denen die Beschäftigung mit UML- fe, eine Klassenstruktur der Implementierung so- Modellierung ein explizites Lernziel war. Die untersuch- wie eine Übersicht der Anwendungsfälle sind ten Arbeiten wurden von neun verschiedenen Professo- ebenfalls oft anzutreffen. ren betreut. Damit dürfte sich auch der Einfluss von dem Bemühen der Studierenden, ihrem Betreuer in dessen persönlichen Modellierungsvorlieben zu gefallen, über die Gesamtheit der Ergebnisse verwischen.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 14 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Andere Allerdings ist es etwas ernüchternd, dass im Medi- Einsatzkon- UML- Informelle formale an jede untersuchte Arbeit nur jeweils zwei der text Diagramm Variante Notation genannten Einsatzkontexte graphisch modelliert, mit jeweils vier Diagrammen. Abb. 6 zeigt die Häu- ArchiMa- Verknüpfung figkeit der Wertepaare „(Anzahl Diagramme, An- te Busi- von Aktoren Anwendungs- Use Case zahl Einsatzkontexte)“ als Blasendiagramm (je häu- fälle ness Ser- und Anwen- figer ein Wertepaar auftritt, desto größer die Blase). vices dungsfällen Bei Diagrammen liegt der Mittelwert mit ca. acht Diagrammen je Arbeit deutlich über dem Median. Nutzungs- Informelles Aktivitäts- BPMN, Einzelne Arbeiten verwenden also graphische Mo- szenario / Flussdia- diagramm EPK dellierung deutlich größerem Ausmaß als der Rest. Geschäftspro- gramm zess Fachliche Zustands- Informeller Zustände von - Geschäftsob- diagramm Graph jekten Klassen- Informeller Fachliches - Datenmodell diagramm Graph

Technischer Informelles Aktivitäts- BPMN, Prozess / Flussdia- diagramm EPK algorithmi- gramm scher Ablauf

Technische Zustands- Informeller Abb. 5: Abdeckung der Einsatzkontexte Zustandsfolge - (State Machi- diagramm Graph ne) Sequenz- Mit Pfeilen Technisches oder und Sequenz- Kommunika- Kommuni- - Zahlen anno- tionsszenario kations- tierte Struk- diagramm turen

Logisches ER- Klassen- Informeller Datenmodell / Dia- diagramm Graph Domänenmo- gramm dell ER- Klassen- Informeller Physisches Dia- diagramm Graph Datenmodell gramm Abb. 6: Anzahl Diagramme vs. Einsatzkontexte Klassenstruk- Informeller Verwendung von UML im Vergleich mit an- Klassen- Graph, teilw. tur der Im- - deren Notationen diagramm aus Technik- plementie- UML-Klassendiagramme stellen in gleich vier von symbolen rung zwölf Einsatzkontexten eine der Alternativen dar Informelle Kompo- (siehe Abb. 7). Am häufigsten wird die Klassen- Block- oder Komponen- nenten- - struktur der Implementierung dargestellt, hier trifft Symbolgra- tenstruktur diagramm man hauptsächlich auf UML-Klassendiagramme. phik Das physische Datenmodell wurde in den unter- Informelle suchten Arbeiten hingegen ausschließlich als ER- Deploy- Block- oder Diagramm modelliert. Logisches und fachliches Verteilungs- mentdia- - Symbolgra- Datenmodell werden nur selten modelliert. sicht gramm phik UML-Aktivitätsdiagramme sind in zwei der zwölf untersuchten Einsatzkontexte von Belang. In bei- Tab. 2: Untersuchte Einsatzkontexte graphischer den tritt eine UML-Modellierung gleichberechtigt Modellierung neben anderen Darstellungsformen auf (siehe Abb. 8). Bei technischen Prozessen und algorithmischen

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 15 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Abläufen trifft man häufig eine informelle Flussdi- Zwischenfazit und Diskussion agramm-Notation an, während Geschäftsprozesse Auch wenn geplant ist, die Untersuchung noch oder Nutzungsszenarien häufig als BPMN (und weiterzuführen und ihre Datenbasis zu verbreitern, gelegentlich auch als EPK) modelliert waren. lassen sich schon einige Erkenntnisse festhalten. Graphische Modellierung wird benötigt. Graphische Modellierung hat ihren festen Platz in der Doku- mentation studentischer Softwarekonzeption und - Implementation. Allerdings streuen die untersuchten Arbeiten stark in Umfang und Konsistenz der verwendeten Modellierungsansätze. Möglicher- weise liegt dies einfach an der natürlichen Quali- tätsverteilung der untersuchten Arbeiten. Nur ein Subset der UML-Spezifikation ist für studentische Arbeiten relevant. Die Untersuchungen zeigen, dass in den Arbeiten im Wesentlichen diejenigen Diagramme verwendet werden, auf die sich auch Abb. 7: Einsatzkontexte mit UML- die Lehre an der TH Köln beschränkt (und die auch Klassendiagrammen in den Praxisstudien als die dominierenden Typen festgestellt werden). Ob die Studierenden einfach das einsetzen, was sie im Studium kennengelernt haben, oder aber diese Diagrammtypen anschei- nend ihren Zweck gut erfüllen, lässt sich aus dieser Untersuchung nicht klären. Die Tatsache, dass so viele andere formale und informelle Notationen eingesetzt werden, spricht doch für eine „Freiwil- ligkeit“. Sprich: Es ist zu vermuten, dass die Studie- renden nur Diagrammtypen verwenden, die sie für sinnvoll erachten und gut verstehen.

Informelle Notationen haben ihren Platz. Es fällt auf, Abb. 8: Einsatzkontexte mit UML- dass informelle Notationen oft eingesetzt werden, Aktivitätsdiagrammen in denen UML möglicherweise eine Überformali- sierung darstellt (Komponentenstrukturen, technisch-algorithmische Abläufe). Dort, wo die UML- Diagramme jedoch entweder intuitiv klar (Use- Case-Diagramme) und/oder kompakt und aus- drucksstark (Klassen-, Sequenz-Diagramme) sind, kommen informelle Alternativen selten vor. Andere formale Notationen haben ebenfalls ihren Platz. Bei Geschäftsprozessen und physischem Datenmo- dell dominieren andere Notationen als UML. Mög- licherweise liegt dies an der Struktur der Informa- tik-Ausbildung an der TH Köln, die in den entsprechenden Fächern (Datenbanken, Informationsma- nagement) die Standards „ER“ und „BPMN“ lehrt. Abb. 9: Verwendung von weiteren UML- Vielleicht sind diese Standards aber einfach tatsäch- Diagrammen in ihren jeweiligen Einsatzkontexten lich verbreiteter als ihre UML-Gegenstücke. In Abb. 9 sind die Einsatzkontexte dargestellt, in Das Potential graphischer Modellierung für fachliche denen UML-Use-Case-, Komponenten-, Sequenz-, Aspekte wird nicht ausgeschöpft. Betrachtet man die Deployment- und Kommunikationsdiagramme Ergebnisse in Abb. 5, so sind die drei am häufigsten eine Rolle spielen. Komponentendiagramme haben abgedeckten Einsatzkontexte graphischer Modellie- in einer informellen Darstellung mit gestapelten rung allesamt technischer Natur. Die fachlich ge- oder geschachtelten Blöcken eine große Konkur- prägten Kontexte „Anwendungsfälle“, „Nutzungs- renz. Anwendungsfälle werden hingegen in der szenario / Geschäftsprozess“ und „fachliches Da- Regel als Use-Case-Diagramme modelliert. Glei- tenmodell“ stehen auf den Plätzen 4, 6 und 10 (von ches gilt für Kommunikationsszenarien, hier domi- 12). Klassendiagramme werden überwiegend für nieren Sequenz- und Kommunikationsdiagramme. Code-Dokumentation verwendet (Abb. 7). Zu-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 16 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln standsfolgen von Geschäftsobjekten (die ein starkes These 1. UML-Kompetenz sollte in der Software- Werkzeug fachlicher Modellierung sind) wurden in technikausbildung weiterhin vermittelt werden. den untersuchten Arbeiten gar nicht gefunden. Die hohe Verbreitung von UML und ihre Nutzung Dies alles zeigt ein deutlich technisches Überge- als mittlere Abstraktionsebene zwischen fachlichem wicht der graphischen Modellierung (ob in UML Problem und Implementierung lassen ihre Behand- oder in anderer Form). Auf das Potential fachlicher lung in der Lehre weiterhin sinnvoll erscheinen. Modellierung sollte also in der Lehre noch stärker Die Aktivität der modellbildenden Abstraktion ist hingewiesen werden. eine grundlegende Querschnittskompetenz in der Informatik (Engels, Hausmann, Lohmann, & Sauer, UML in der Lehre – belassen, verän- 2006). Vor diesem Hintergrund dient die Beschäfti- dern, abschaffen? gung mit UML grundsätzlich dem Erlernen dieser Die Beschreibung von Software mithilfe von Mo- Kompetenz – ganz unabhängig davon, ob man die dellen ist eine essentielle Aufgabe und gehört da- konkreten Modellelemente auch tatsächlich später her zum Kernbestandteil der Softwaretechnikaus- in seiner beruflichen Praxis verwendet. bildung. Bereits von 10 Jahren stellte Glinz dazu ein Darüber hinaus scheinen einige UML-Diagramm- Thesenpapier über die Rolle der Modellierung in typen intuitiv verständlich und gut anwendbar zu der Lehre vor (Glinz, 2008), das jedoch nicht spezi- sein, oder zumindest als bewusste oder unbewusste fisch auf UML bezogen ist. Vorlagen für eine informelle Modellierung zu die- Die dargestellten empirischen Untersuchungen nen. Sie können daher als eine Art von informati- zeigen, dass die UML in der Praxis eher selektiv scher Allgemeinbildung angesehen werden. (siehe eingesetzt wird. Eine eigene schlaglichtartige Ana- auch These 2.) lyse von studentischen Arbeiten bestätigt diesen These 2. Die Lehre sollte sich auf ausgewählte Eindruck auch für diejenigen Informatikern, die UML-Modellelemente fokussieren. gerade ins Berufsleben eintreten. Die dargestellten Studienergebnisse legen nahe, Welcher Schluss ist daraus für die zukünftige Aus- dass ein Anspruch an Studierende, die UML- gestaltung und Weiterentwicklung der Software- Sprachelemente möglichst umfänglich zu beherr- technik-Lehre zu ziehen? Ist die UML-Ausbildung schen, nicht sinnvoll ist. Insbesondere die hohe in ihrer jetzigen Form noch zeitgemäß? Sollte sie Komplexität und der hohe Formalisierungsgrad verändert werden? Oder wäre es sinnvoll, sie ganz der UML erscheint nicht mehr zeitgemäß, da insbe- aus den Curricula von Informatik-Studiengängen sondere die Maschinenlesbarkeit von UML Model- zu verbannen? Diese Fragen kann nur durch eine len für Codegenerierung bzw. direkter Ausführung Diskussion in der Fachcommunity beantwortet („Executable UML“) sich nicht in der Breite durch- werden. Dazu möchten wir nicht nur die mögli- setzen konnten. chen Alternativen aufzeigen, sondern auch selbst Wie die empirischen Untersuchungen zeigen, wer- Stellung beziehen. den UML-Modelle vielfach informell zur Kommu- Die Erkenntnisse und Schlussfolgerungen aus Re- nikation und Zusammenarbeit eingesetzt. In diesen cherche und eigenen Erhebungen legen unserer Situationen werden nur wenige Sprachelemente Meinung nach nahe, dass eine UML-Ausbildung in benötigt. Einige Diagrammtypen scheinen intuitiv der Form, wie sie vor 15 Jahren angemessen war, verständlich und gut merkbar zu sein. Sowohl in heute nicht mehr in die Zeit passt. Die Gründe hier- der Praxis wie auch in der Auswertung studenti- für haben wir unter „Zwischenfazit und Diskussi- scher Arbeiten werden diese Elemente mehr oder on“ bei UML-Nutzung durch Praktiker und durch weniger nahe am definierten Standard verwendet. Studierende aufgezeigt. Ein reines „Belassen“ ist Dies trifft insbesondere auf Klassen-, Use-Case und unserer Ansicht nach also keine sinnvolle Option. Sequenz-Diagramme zu. Ebenso wenig erscheint es angebracht, UML kom- Andere UML-Diagrammtypen findet man häufig plett aus den Curricula zu entfernen. Unsere Er- auch in einer informellen, „verballhornten“ Form, kenntnisse legen nicht den Schluss nahe, dass UML die sich aber durchaus mehr oder weniger deutlich für die Softwaretechnik nicht mehr relevant ist. an den UML-Sprachelementen orientiert. Beispiele Damit erscheint eine Anpassung des jetzigen Lehr- hierfür sind Komponenten-, Deployment-, Aktivi- konzepts der sinnvollste Ansatz zu sein. Aus den täts-, Zustands- und Kommunikationsdiagramme. obigen Analysen und Erkenntnissen lassen sich Diese Tatsache allein ist unserer Ansicht nach durchaus Bereiche identifizieren, in denen eine Grund genug, Kompetenzen in den „originalen“ Neujustierung der Lehre sinnvoll ist. Um eine UML-Diagrammtypen in der Lehre zu vermitteln. Fachdiskussion zum Thema anzuregen, haben wir Eine größere Bedeutung hat die UML nach wie vor unsere Vorschläge als Thesen strukturiert. für die Analyse, z.B. für Domänen- oder Geschäfts-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 17 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln prozessmodelle. Da in diesen Fällen sowohl Mo- These 5. Die Modellierungskompetenz sollte auf dellersteller als auch -nutzer Menschen sind, ist ein das Absolventenprofil abgestimmt sein. geringeres Maß an Formalität ausreichend. Sinnvoll wäre aus unserer Sicht eine Herleitung der Dafür wird der durch die hohe Ausdrucksstärke angestrebten Modellierungskompetenz anhand des bedingte große Umfang an Modellelementen je- gewünschten Kompetenzprofils pro Studienfach doch nicht benötigt. Dies sorgt zum einen für Kon- und bestehenden Vorkenntnissen. Bei reinen In- kurrenz durch informelle Modellierungsansätze, formatikstudiengängen ist in der Regel das Berufs- für eine hohe Hürde beim Erlernen der UML sowie bild des Softwarearchitekten Teil des Absolventen- auch mangelhafte Einsicht in die Notwendigkeit profils, was einen bewussten Umgang mit Me- der Sprachbeherrschung bei den Studierenden. taebenen und Abstraktion voraussetzt. Im Gegen- satz dazu steht bei angehenden Medien- oder Wirt- Konkrete Kandidaten für eine Verschlankung in schaftsinformatikern eher die Anwendung im Vor- der Lehre sind nach unserer Ansicht die Vielzahl dergrund. Verschiedene technische Studiengänge von Beziehungstypen in Komponentendiagram- sind z.B. mit der Entwicklung von Echtzeitsyste- men, detaillierte Spezifikation von Extension Points men befasst, in denen formale Verifikation und in Use-Case-Diagrammen oder komplexe Entry- Codegenerierung relevant sind. und Exit- Aktionen in Zustandsdiagrammen. These 3. Die Lehre sollte sich auf die Beherr- Zudem spielt Ausrichtung des Studiengangs auf schung von Einsatzkontexten anstatt von UML- eine Zieldomäne eine wichtige Rolle. Dabei sollten Diagrammtypen fokussieren. die verschiedenen Schwerpunkte in Softwarepro- dukten (Web vs. Backend, E-Commerce / Social Die GI gibt für die Informatikausbildung an Hoch- Media vs. betriebliche Anwendungssysteme) sowie schulen folgende inhaltliche Empfehlungen mit Projektmanagementansätze (agil vs. phasenorien- Bezug zur UML (Gesellschaft für Informatik, 2016): tiert) als Leitlinie dienen. In weiterführenden Mo- - Stufe 1 (Verstehen): „Verschiedene Notationen dulen zum Thema Softwareproduktlinien oder wie z.B. UML für die Modellierung von Soft- Softwarewartung können besondere Einsatzberei- waresysteme erläutern.“ che der Modellierung erschlossen werden. - Stufe 2 (Anwenden): „Standardsituationen im Bereich der Modellierung (…) umsetzen. Die These 6. Die UML-Ausbildung sollte die Model- Begriffswelt des Anwenders durch geeignete lierung von Fachlichkeit stärker fokussieren. Vorgehensweisen erfassen und zu einer fachli- Die Lehre sollte die frühen Phasen der Modellbear- chen Terminologie im Projekt verdichten.“ beitung stärker in den Fokus nehmen. UML hat - Stufe 3 (Analysieren): „Die Eignung eines Vor- große Stärken in der Beschreibung einer fachlichen gehensmodells, einer Notation oder einer Me- Domäne in Form eines fachlichen Datenmodells thode für ein klassifiziertes Softwaresystem sowie von geschäftlichen Abläufen als Aktivitäts- oder eine klassifizierte Aufgabe einschätzen.“ diagrammen. Transaktionale Vorgänge lassen sich In dieser Systematik ist 2 (Anwenden) die praxisre- sehr gut als Zustandsdiagramme eines Geschäfts- levanteste Lernstufe. Allerdings wird in realen objekts beschreiben. Projekten nicht die Kompetenz „Entwerfe ein Unsere Auswertung der studentischen Arbeiten hat UML-Klassendiagramm“ gefordert, sondern „Ent- im Gegensatz dazu gezeigt, dass UML eher für die werfe ein fachliches oder logisches Datenmodell“. technische Beschreibung aus Entwickler- statt aus Daher plädieren wir dafür, in der Formulierung Nutzersicht eingesetzt wird (siehe z.B. Abb. 7). von Lernzielen den Fokus von UML-Diagramm- These 7. Die Lehre sollte nicht Tools, sondern typen hin zu Einsatzkontexten graphischer Model- Kommunikation und Interaktivität in den Fokus lierung zu lenken. In Tab. 2 haben wir dazu einen stellen. Vorschlag von zwölf Einsatzkontexten gemacht. Softwareentwicklung wird immer stärker durch These 4. Die Fähigkeit zur Auswahl von Model- Kommunikation und Zusammenarbeit geprägt. lierungsansätzen sollte gestärkt werden. Damit sollte die Ausbildung die interaktive Nut- Neben der UML haben sich diverse andere mehr zung von UML stärker einüben, z.B. in der Analy- oder weniger formale Modellierungsansätze etab- se- und frühen Entwurfsphase, in der in der Praxis liert. Informelle Modellierungsansätze sowie for- oft auf Papier oder am Whiteboard gearbeitet wird. male Nicht-UML-Modellierungssprachen sollten Für die praktische Umsetzung ergeben sich daraus daher vergleichend in die Lehre einfließen. Studie- interessante Fragestellungen in Bezug auf die kon- rende sollten die Kompetenz erwerben, geeignete krete didaktische Umsetzung sowie die damit ver- Modellierungsansätze, Diagrammtypen und den bundene geeignete Toolunterstützung. angemessenen Detailgrad im Modell in Abhängig- keit von der Aufgabenstellung auszuwählen. Dies ist konform mit Stufe 3 der o.g. GI-Empfehlung.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 18 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Zusammenfassung und Ausblick Boberić-Krstićev, D., Tešendić, D., Simos, T. E., Psihoyios, G., Tsitouras, C., & Anastassi, Z. Die Bedeutung von UML für die Softwaretechnik (2011). Teaching Object-Oriented Modelling Us- ist in Veränderung begriffen. Die Ursachen dafür ing UML. In Numerical Analysis and Applied liegen in Trends, die umfangreiche Modellierungen Mathematics ICNAAM 2011 (S. 810–812). AIP. nicht mehr erforderlich machen. Dazu gehören https://doi.org/10.1063/1.3636856 agile Entwicklungsansätze, Microservicearchitektu- ren sowie das weitgehende Scheitern des MDA- Bourque, P., Fairley, R. E., & IEEE Computer Socie- Ansatzes, der detaillierte und formale Modelle ty. (2014). Guide to the Software Engineering Body erfordert. Die Aufmerksamkeit, die diesen Themen of Knowledge (SWEBOK(R)): Version 3.0 (3. derzeit geschenkt wird, darf nicht darüber hinweg- Aufl.). IEEE Computer Society Press. täuschen, dass in vielen Großprojekten oder für Brown, S. (2018). The C4 model for software archi- sicherheitskritische Produkte die UML nach wie tecture. Abgerufen 21. Oktober 2018, von vor eine sehr wichtige Rolle spielt. https://c4model.com/ Aus unserer Sicht ist es notwendig, die Stellung der Burgueño, L., Vallecillo, A., & Gogolla, M. (2018). UML in der Lehre kritisch zu hinterfragen. Wir Teaching UML and OCL models and their vali- haben in diesem Beitrag dazu empirische Belege dation to software engineering students: an ex- über die Nutzung der UML zusammengetragen. perience report. Computer Science Education, Diese Bestandsaufnahme diente als Grundlage für 28(1), 23–41. die Ableitung von Konsequenzen für die Ausge- https://doi.org/10.1080/08993408.2018.1462000 staltung der Lehre. Naturgemäß kann dies keine Chaudron, M. R. V., Heijstek, W., & Nugroho, A. abschließende Bewertung sein, sondern soll ent- (2012). How effective is UML modeling ? Soft- sprechend unserer Zielsetzung Impulse zu diesem ware & Systems Modeling, 11(4), 571–580. Thema liefern. https://doi.org/10.1007/s10270-012-0278-4 Für weiterführende Arbeiten erscheint neben einer Cockburn, A. (2006). Agile Software Development: The Verbreiterung und Aktualisierung der empirischen Cooperative Game (0002 Aufl.). Upper Saddle Basis auch eine Ausdifferenzierung hinsichtlich River, NJ: Addison Wesley Pub Co Inc. verschiedener Studienrichtungen und -niveaus sinnvoll. Es muss beobachtet werden, wie sich die Coplien, J. O., & Bjørnvig, G. (2010). Lean architec- Nutzung der UML in der Praxis weiterentwickelt. ture for Agile software development. Hoboken, Dabei sind Situationen zu betrachtet, in denen Mo- N.J.: Wiley. delle einen Mehrwert leisten. Wer ist Modellerstel- Davies, I., Green, P., Rosemann, M., Indulska, M., & ler, wer -nutzer? Wie umfangreich und präzise Gallo, S. (2006). How do practitioners use con- müssen die Modelle sein? Müssen aufkommende ceptual modeling in practice? Data & Knowledge Programmierparadigmen wie funktionale und de- Engineering, 58(3), 358–380. klarative Programmierung berücksichtigt werden, https://doi.org/10.1016/j.datak.2005.07.007 da UML unmittelbar mit OOP zusammenhängt? Dobing, B., & Parsons, J. (2010). Dimensions of Wie kann Fachlichkeit stärker in den Fokus ge- UML Diagram Use: Practitioner Survey and Re- nommen werden? Wie kann der identifizierte search Agenda. Principle Advancements in Data- Kompetenzbedarf in praxisorientierten Lehrkon- base Management Technologies: New Applications zepten umgesetzt werden? Wir hoffen, mit diesem and Frameworks, 271–290. Beitrag die Diskussion dazu ein Stück weit ange- https://doi.org/10.4018/978-1-60566-904-5.ch013 regt zu haben. Engels, G., Hausmann, J. H., Lohmann, M., & Sau- Literaturangaben er, S. (2006). Teaching UML Is Teaching Soft- ware Engineering Is Teaching Abstraction. In J.- Baltes, S., & Diehl, S. (2014). Sketches and diagrams M. Bruel (Hrsg.), Satellite events at the MoDELS in practice. In S.-C. Cheung, A. Orso, & M.-A. 2005 conference (Bd. 3844, S. 306–319). Berlin: D. Storey (Hrsg.), Proceedings of the 22nd ACM Springer. https://doi.org/10.1007/11663430‗ SIGSOFT International Symposium on Founda- Erickson, J., & Siau, K. (2007). Can UML Be Simpli- tions of Software Engineering, (FSE-22), Hong fied? Practitioner Use of UML in Separate Do- Kong, China, November 16 - 22, 2014 (S. 530–541). mains. ACM. https://doi.org/10.1145/2635868.2635891 Evans, E. (2003). Domain-Driven Design: Tackling Beck, K., Beedle, M., Bennekum, A. van, Cockburn, Complexity in the Heart of Software (1 edition). A., Cunningham, W., Fowler, M., … Thomas, Boston: Addison-Wesley Professional. D. (2001). Manifesto for Agile Software Develo- pment. Abgerufen 30. November 2018, von Gesellschaft für Informatik. (2016). Empfehlungen http://agilemanifesto.org/ für Bachelor- und Masterprogramme im Studienfach

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 19 UML in der Hochschullehre: Eine kritische Reﬂexion Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln

Informatik an Hochschulen (GI-Empfehlungen). Seiko Akayama, Birgit Demuth, Timothy Leth- Abgerufen von bridge, Marion Scholz, Perdita Stevens, & Dave https://gi.de/fileadmin/GI/Hauptseite/Aktuelles R. Stikkolorum. (2013). Tool Use in Software /Meldungen/2016/GI-Empfehlungen_Bachelor- Modelling Education. In EduSymp@MoDELS. Master-Informatik2016.pdf Sommerville, I. (2015). Software Engineering, Global Gianna Reggio, Maurizio Leotta, Filippo Ricca, & Edition (10th edition). Boston: Pearson. Diego Clerissi. (2013). What are the used UML diagrams? A Preliminary Survey. In EESS- MOD@MoDELS. Glinz, M. (2008). Modellierung in der Lehre an Hochschulen: Thesen und Erfahrungen. Infor- matik-Spektrum, 31(5), 425–434. https://doi.org/10.1007/s00287-008-0273-x Gorschek, T., Tempero, E., & Angelis, L. (2014). On the use of software design models in software development practice: An empirical investigation. Journal of Systems and Software, 95, 176–193. https://doi.org/10.1016/j.jss.2014.03.082 Jacobson, I. (2009). Taking the temperature of UML. Abgerufen 1. November 2018, von http://blog.ivarjacobson.com/taking-the- temperature-of-uml/ Langer, P., Mayerhofer, T., Wimmer, M., & Kappel, G. (2014). On the usage of UML: initial results of analyzing open UML models. In H.-G. Fill (Hrsg.), Modellierung 2014. Bonn: Köllen. Larman, C., & Vodde, B. (2009). Scaling lean & agile development: thinking and organizational tools for large-scale Scrum. Upper Saddle River, NJ: Ad- dison-Wesley. Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises. Upper Saddle River, NJ: Pearson Education. Liebel, G., Heldal, R., & Steghofer, J.-P. (2016). Im- pact of the Use of Industrial Modelling Tools on Modelling Education. In 2016 IEEE 29th Interna- tional Conference on Software Engineering Educa- tion and Training (CSEET) (S. 18–27). IEEE. https://doi.org/10.1109/CSEET.2016.18 Osman, H., & Chaudron, M. R. V. (2013). UML Usage in Open Source Software Development: A Field Study. Gehalten auf der EESS- MOD@MoDELS 2013. Petre, M. (2013). UML in Practice. In Proceedings of the 2013 International Conference on Software En- gineering (S. 722–731). Piscataway, NJ, USA: IE- EE Press. Abgerufen von http://dl.acm.org/citation.cfm?id=2486788.24868 83 Rupp, C., Queins, S., & SOPHISTen, die. (2012). UML 2 glasklar: Praxiswissen für die UML- Modellierung (4. Aufl.). München: Carl Hanser Verlag.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 20 Formale Methoden in der Softwaretechnik-Vorlesung

Bernd Westphal, Albert-Ludwigs-Universität Freiburg [email protected]

Zusammenfassung informal • informal • Dieser Artikel stellt die Ergänzung einer Einfüh- rung in die Softwaretechnik um Formale Metho- semi-formal • semi-formal • den im Bereich Requirements Engineering, Software- Modellierung und Qualitätssicherung vor. Wir beschreiben die Konstruktion der Veranstaltung und be- formal formal richten empirische Daten und Erfahrungen aus 4 Jah- • •• • ren der Durchführung. Ein Schwerpunkt ist die Be- simple complex schreibung der verwendeten didaktischen Methoden (a) (b) zur Vermittlung der neuen Inhalte. Abbildung 1: Einführung Formaler Methoden. Abstract This article presents the extension of an introductory den (Semi-)Entscheidungsprozeduren. Das Ziel der course on software engineering by formal methods Ergänzung um Formale Methoden ist motiviert durch in the topic areas requirements engineering, software unsere Erfahrung in zahlreichen Projekten mit Part- modelling, and quality assurance. We describe the nern aus der Industrie von kleinen Anbietern sicher- construction of the course and report empirical data heitskritischer Systeme (z.B. (Arenis u. a., 2016)) and experience from 4 years of conducting the course. bis hin zu großen Automobilanbietern und Zuliefe- A focus of this article is the description of didactical rern (z.B. (Langenfeld u. a., 2016)). In der Projekt- methods employed for teaching the new content. arbeit nehmen wir eine klare Nachfrage nach und Anwendung (!) von Formalen Methoden im oben ge- 1 Einleitung nannten Sinne in verschiedenen Bereichen der Soft- Im Studienplan des Bachelorstudiums der Informatik waretechnik in den Firmen wahr. Hierbei steht übli- der Universität Freiburg ist eine einsemestrige Veran- cherweise nicht die vollständige und umfassende for- staltung zur Einführung in die Disziplin der Softwa- male Beschreibung von Anforderungen und Entwurfs- retechnik vorgesehen. Das Modulhandbuch fordert, entscheidungen bzgl. Struktur und Verhalten im Vor- wie in Deutschland nicht unüblich, eine Übersicht dergrund (wie es etwa im Luft- und Raumfahrtbe- über die Problembereiche, Konzepte und Techniken reich teilweise angestrebt wird), sondern eine ange- der Softwaretechnik, wie sie von den bekannten Lehr- messene Verwendung von Formalen Methoden, um büchern, etwa (Sommerville, 2010; Balzert, 2009; bestimmte, besonders kritische oder risikobehaftete Ludewig u. Lichter, 2013), abgedeckt werden. Im Jah- Aspekte von Software zu beschreiben und zu ana- re 2015 stand eine Überarbeitung der Vorlesung ‚Soft- lysieren. Dem entsprechend möchten wir heute be- waretechnik‘ an, über deren Resultat wir in diesem ginnen, die in vielen Einführungen in die Software- Artikel berichten. technik fest etablierte (semi-formale) Modellierung Zwei Ziele standen bei der Überarbeitung der Ma- von Softwareaspekten in unserer Einführungsveran- terialien im Fokus. Erstens ein „Zurechtrücken“ der staltung um eine formale Sicht zu erweitern und den Proportionen der verschiedenen Bereiche der Softwa- Studierenden eine Übersicht über Konzepte, Möglich- retechnik in den Materialien (die über mehrere Jah- keiten und Voraussetzungen Formaler Methoden für re von verschiedenen Veranstaltern verwendet und ihre zukünftigen Berufssituationen zu vermitteln. bearbeitet wurden), und zweitens eine neue Ergän- Mit diesem Ziel ergibt sich neben der üblichen zung der Materialien um eine verständliche und nach- Herausforderung, aus dem umfangreichen Angebot vollziehbare Einführung formaler Beschreibungsspra- der Lehrbücher eine ausgewogene Vorlesung zusam- chen und Analysetechniken (kurz Formale Metho- menzustellen, die Herausforderung, Lehrmaterialien den), also Beschreibungssprachen mit formal deﬁ- für den Bereich Formale Methoden auszuwählen bzw. nierter Syntax und Semantik und darauf aufbauen- herzustellen. Interessanterweise ist die zweite Her-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 21 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg ausforderung keine Teilmenge der ersteren. In den den Rahmen unserer Veranstaltung sprengen würde etablierten Lehrbüchern (s.o.) und dem vorhandenen und für unsere Lernziele nicht notwendig ist. Weiter- Material wird ganz überwiegend ein Ansatz verfolgt, hin ist das Material u.E. so weit von der (heutigen den wir in Abbildung 1(a) visualisieren. Wir sehen und mutmaßlich morgigen) Lebenswirklichkeit und die für z.B. die Beschreibung von Anforderungen ver- den etablierten Lehrbüchern entfernt, daß wir anneh- fügbaren Mittel auf einer Achse, die von informal men müssen, daß es Studierenden unnötig schwer (rein natürlichsprachlich), über semi-formal (mit for- fallen würde, andere Lehrbücher oder Fortbildungen maler konkreter Syntax, aber ohne formale abstrakte in der Arbeitssituation zu unserer Veranstaltung in Syntax oder Semantik) hin zu formal (mathematisch Bezug zu setzen. Unser (zugegeben: hoher) Anspruch präzise definierte Syntax und Semantik) reichen. Die an unsere Veranstaltung ist, daß nach der Teilnahme vorgenannten Lehrbücher und Materialien bewegen an unserer Veranstaltung keines der etablierten Lehr- sich auf dieser Achse zwischen informal und semi- bücher große konzeptionelle Überraschungen bereit formal und geben kurze Ausblicke auf Formale Me- hält, sondern nur von den Studierenden einordne- thoden, indem Beispiele auf einer intuitiven Ebene bares, zusätzliches Hintergrundwissen sowie weitere diskutiert werden. Bei diesem Ansatz sehen wir ein Techniken liefert. inhärentes Problem, das bereits Lehman & Buth (Leh- In diesem Artikel beschreiben wir die Konstrukti- mann u. a., 2015) beschreiben: „Es darf nicht erwar- on unserer Vorlesung zur Einführung in die Softwa- tet werden, dass die Studierenden UML Modelle er- retechnik im Grundstudium, in der die in etablierten stellen können, wenn in der Vorlesung nur die einzel- Lehrbüchern zur Softwaretechnik (s.o.) vorgestellten nen Symbole durchgearbeitet werden und dann auf Inhalte um Techniken zur Beschreibung von Anforde- dieser Basis in der Prüfung Analyseaufgaben auf ei- rungen und Entwurfsaspekten vollständig formal, al- nem gegebenen Diagramm gestellt werden.“ Streng so mit konkreter Syntax und präziser abstrakter Syn- genommen können wir schon nicht erwarten, daß tax und Semantik, ergänzt werden, und berichten von Studierende in Bloom’s Taxonomie echt leichtere Auf- Erfahrungen aus vier Sommersemestern mit der neu gaben, wie etwa gegebene Objektdiagramme darauf- gestalteten Veranstaltung. Schwerpunkt dieses Arti- hin analysieren, zu welchem der (drei) Wahrheits- kels sind die Voraussetzungen der Veranstaltung (ins- werte eine gegebene OCL-Formel ausgewertet wird, in besondere die Einbettung in den Studienplan), Kon- Übungen so zu bearbeiten, daß gegenüber den Tu- sequenzen der ergänzten Inhalte für Übungen und tor::innen die Korrektheit der Lösung argumentiert Klausur, sowie Organisation und didaktische Maß- (im besten Falle: bewiesen) werden kann bzw. von nahmen (vor allem Bereich des Übungsbetriebs), mit Seiten der Tutor::innen die Inkorrektheit eines Lö- denen wir die Vermittlung und Erarbeitung der neu- sungsvorschlags bewiesen und systematisch erklärt en Inhalte unterstützen. Die neuen Inhalte als solche werden kann. Unser Lösungsansatz besteht darin, in werden für den Bereich Requirements Engineering der Veranstaltung Endpunkte der Formalitätsachse zu in (Westphal, 2018) vorgestellt und sind zudem auf behandeln. Wir diskutieren sowohl informale Ansät- der Homepage der Veranstaltung frei zugänglich.1 ze (und im Themenbereich Requirements Enginee- Der Artikel ist wie folgt strukturiert. In Abschnitt 2 ring verschiedene semi-formale Ansätze) und sprin- beschreiben wir die Situation der Veranstaltung im gen dann zu vollständig definierten Beschreibungs- Studienplan der Universität Freiburg sowie der Stu- sprachen, die für den Zweck der Vorlesung (bis auf dierenden zu Beginn der Veranstaltung. Abschnitt 3 eine Ausnahme) auf einen essentiellen Kern reduziert legt unsere Lernziele dar und beschreibt, wie wir die sind (vgl. Abbildung 1(b)). Auf diese Weise geben wir neuen Inhalte bzgl. Formaler Methoden durch didak- eine konkrete Übersicht über die gesamte Achse. Für tische Maßnahmen im Übungsbetrieb unterstützen. eine ausgewählte Beschreibungssprache diskutieren Einen Überblick über die neuen Inhalte, ihre Einbet- wir mehr als einen essentiellen Kern, um zu demons- tung in die gesamte Vorlesung und unsere Erfahrun- trieren, daß es eine orthogonale Achse der Einfach- gen bzgl. Lernerfolgen gibt Abschnitt 4. Wir schließen heit formaler Beschreibungssprachen gibt (Einfach- den Artikel mit einer Betrachtung von Evaluationser- heit sowohl bzgl. der Ausdrucksstärke als auch bzgl. gebnissen und einer Zusammenfassung. des Aufwands, zu einer vollständigen Definition (von abstrakter Syntax und Semantik) zu gelangen). 2 Kontext der Veranstaltung und Für den Bereich der Formalen Methoden in der Situation der Studierenden Softwaretechnik steht mit (Bjørner, 2006a,b,c) ein Die Veranstaltung ‚Softwaretechnik‘ ist eine Pflicht- dreibändiges Lehrbuch zur Verfügung, das versucht, vorlesung im B. Sc.-Studiengang Informatik der Uni- die Softwareentwicklung vollständig aus formaler versität Freiburg mit einem Umfang von 3+1 SWS für Sicht zu vermitteln. Wir haben uns aus zwei Grün- Vorlesung und Übung und 6 ECTS-Punkten. Zusätz- den dagegen entschieden, diesem Lehrbuch zu fol- lich besuchen Studierende des nicht-konsekutiven gen. Zunächst scheint uns das Ziel des Materials von Masterstudiengangs, der Studiengänge ‚Embedded Bjørner zu sein, formale Beschreibungssprachen mög- 1Die URL für das Sommersemester 2018 ist: https://swt. lichst in vollem Umfang darzustellen, was schlicht informatik.uni-freiburg.de/teaching/SS2018/swtvl

2 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 22 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

Tabelle 1: Selbsteinschätzung der Erfahrung (Minimum · 1., 2., 3. Quartil · Maximum). Proj. Mgmt. Req. Eng. Programm. Modellierung QA 2016 (77 Antw.) – 0 · 1 · 1 · 3 · 9 1 · 2 · 3 · 5 · 10 0 · 1 · 1 · 2 · 7 0 · 1 · 2 · 3 · 9 2017 (87 Antw.) 0 · 0 · 1 · 3 · 10 0 · 1 · 1 · 4 · 10 0 · 2 · 3 · 5 · 10 0 · 1 · 1 · 3 · 10 0 · 1 · 1 · 4 · 10 2018 (64 Antw.) 0 · 0 · 1 · 3 · 8 0 · 0 · 1 · 2 · 8 1 · 1 · 3 · 5 · 10 0 · 1 · 1 · 3 · 9 0 · 1 · 2 · 4 · 10

Systems Engineering‘ (ESE) und ‚Mikrosystemtech- the planning and execution of the activity in a software deve- nik‘ sowie des bivalenten Studiengangs Informatik lopment project within defined resource and time constraints. die Veranstaltung. In den vier Jahren der Veranstal- tung haben wir zwischen 80 und 150 angemelde- Tabelle 1 zeigt die bisherigen Ergebnisse, die unse- te Teilnehmer::innen beobachtet. Unter den Teilneh- re Annahmen durchweg bestätigen. Etwas überra- mer::innen (der Evaluation2) studierten zwischen 73 schend finden wir, daß sich das obere Quartil der und 96 % Informatik, der zu 100 % fehlende Teil Studierenden im Bereich Programmierung regelmä- wird stark von ESE-Studierenden dominiert. Außer in ßig als relativ erfahren einschätzte, sich im Bereich 2016 strebten jeweils mehr als knapp zwei Drittel der Qualitätssicherung (der die Aktivität des Testens ein- Teilnehmer::innen einen B. Sc.-Abschluss an. schließt, von der man erwarten sollte, daß diese Die ‚Softwaretechnik‘ ist im 4. Semester vor- mit ernsthafter Programmierung einhergeht) als eine gesehen, d.h. wir können einen zweiteiligen Pro- oder zwei Stufen geringer erfahren einordnet. grammierkurs und Algorithmen & Datenstrukturen, In der zweiten Vorlesung zeigen und diskutieren Technische und Praktische Informatik (Betriebssyste- wir die Ergebnisse des jeweiligen Jahres. Mit der Prä- me, Netzwerke, Datenbanken) und die Mathematik- sentation der Ergebnisse verbinden wir die folgenden Vorlesungen voraussetzen. Logik und die Einführung Botschaften: Erstens, daß wir, d.h. die Veranstalter in die Theoretische Informatik sind in Freiburg im und die Studierenden, es (auch dieses Jahr wieder) 3. Semester vorgesehen, liegen also auch zeitlich vor mit einem bzgl. Vorerfahrung eher heterogenen Au- der ‚Softwaretechnik‘. Parallel zur ‚Softwaretechnik‘ ditorium zu tun haben. Zweitens, daß die Vorlesung findet für die B. Sc.-Studierenden der Informatik ein explizit für Studierende angelegt ist, die sich zwi- Softwarepraktikum statt (vgl. Abschnitt 3). schen den Werten 0 und 1 einordnen (und daß die- Entsprechend der Position der ‚Softwaretechnik‘ im se Studierenden in der klaren Mehrheit sind, man al- Curriculum und aus der Erfahrung der Jahre vor so nicht „allein“ ist, wenn man sich dort eingeordnet 2015 gehen wir einerseits davon aus, daß der Groß- hat). Drittens, daß für die Studierenden, die sich bei teil der Teilnehmer::innen vor unserer Veranstaltung Werten von 5 und höher einordnen, möglicherweise bzgl. der meisten Themenbereiche der Softwaretech- keine Neuigkeiten vermittelt werden, daß diese Stu- nik über wenig bis sehr wenig Erfahrung verfügt. dierenden jedoch explizit eingeladen sind, in Form Andererseits wissen wir aus persönlichen Gesprä- von Fragen oder Kommentaren ihre Vorerfahrung in chen, daß es im nicht-konsekutiven M. Sc.-Programm den Vorlesungs- und Übungsterminen einzubringen. durchaus einzelne Studierende gibt, die über mehr- In der Diskussion der Ergebnisse stellen wir heraus, jährige Berufserfahrung verfügen. daß die Inhalte der Vorlesung die Studierenden dar- Seit 2016 überprüfen wir diese Annahme durch auf vorbereiten möchten, in Softwarentwicklungspro- eine Aufgabe auf dem ersten Übungsblatt, in der jekten höherer Stufen mitzuarbeiten, also Projekte wir die Teilnehmer um eine Selbsteinschätzung der die einen größeren Umfang und eine größere Nutzer- Vorkenntnisse in den Themenbereichen (die wir in basis haben als jedes Projekt, das man im Studium in der ersten Vorlesung jeweils grob umreißen) Projekt- Freiburg erlebt, sowie üblicherweise einen wirtschaft- management (seit 2017), Requirements Engineering, lichen Aspekt haben. Programmierung, Modellierung und Qualitätssiche- rung bitten. Wir schlagen in der Aufgabe die folgende, 3 Ziele und Konstruktion subjektiv zu interpretierende Skala vor (die Übungs- blätter sind in Englisch verfasst): der Veranstaltung Ein Lernziel unserer Veranstaltung ist zunächst, wie 0: I have no experience in that activity whatsoever. I have not taken any related subjects during my studies. in der Einleitung beschrieben, eine Übersicht über die verschiedenen Themenbereiche der Softwaretech- 1: I have only performed the activity in the context of a lecture nik entsprechend der etablierten Lehrbücher zu ge- or programming course. ben. Unser Schwerpunkt ist hierbei die Vermittlung 10: I have performed the activity in a project with a large user ba- der verschiedenen Probleme, die sich daraus ergeben, se (100+ users), a large work volume (36+ person-months) daß mehrere Menschen über einen längeren Zeit- or a specific commercial purpose. I have been responsible for raum zusammen nichttriviale Softwaresysteme entwi- 2Zwischen 26 und 40 Angaben; leider haben wir keinen direk- ckeln, sowie bekannte Lösungsansätze und deren Vor- ten Zugriff auf Studiengang oder angestrebten Abschluss. und Nachteile vorzustellen.

3 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 23 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

Der neue Aspekt unserer Veranstaltung ist die voll- Bei der Punkteverteilung der Klausur orientieren ständig formale Deﬁnition von Beschreibungsspra- wir uns grob an den Stufen der (überarbeiteten) Ta- chen und Analysetechniken an den entsprechenden xonomie der Lernziele (Bloom, 1956; Anderson u. a., Stellen in der Vorlesung (vgl. Tabelle 2). Die Lernzie- 2001). Circa 50 % der Punkte entfallen auf „leichte“ le sind hier das sichere Verstehen und Anwenden der Aufgaben (Vokabular, einfache Verfahren verstehen eingeführten Formalen Methoden, sowie die Interpre- und wie in den Übungen (jedoch auf andere Proble- tation von Analyseergebnissen. Die entsprechenden me) anwenden), ca. 33 % der Punkte entfallen auf Inhalte und die Einbettung in die Vorlesung werden „mittlere“ Aufgaben (ähnlich wie Übungsaufgaben, je- in Abschnitt 4 beschrieben. doch Analyse bzw. Transfer notwendig) und ca. 17 % der Punkte sind für „schwere“ Aufgaben (nicht in Wir beschreiben die Ziele unserer Veranstaltung in den Übungen besprochen, neue Sichten auf diskutier- der ersten Vorlesung, um Missverständnisse (und Ent- te Konzepte, offenere kreative Aufgaben) vorgesehen. täuschungen) zu vermeiden. In einer Aufgabe des ers- Unsere Absicht ist, Kompetenzen über alle kognitiven ten Übungsblattes bitten wir die Studierenden, aus- Kategorien hinweg zu prüfen; in der o.g. Punktever- gehend von der ersten Vorlesung ihre Erwartungen teilung reicht es z.B. zum Bestehen nicht aus, alle an die Veranstaltung in eigenen Worten zu beschrei- „schweren“ Aufgaben (ggf. intuitiv oder zufällig) zu ben. In der zweiten Vorlesung stellen wir eine Aus- lösen, sondern es sind Punkte aus den Bereichen Ver- wahl der Antworten vor, und gehen jeweils darauf stehen und Anwenden zum Bestehen notwendig. ein, inwiefern die Veranstaltung diese Erwartungen erfüllen kann. Ein über die Jahre wiederkehrender 3.2 Vorlesungen Punkt, ist der Wunsch, gutes Design zu lernen. Diese Teil unserer Veranstaltung ‚Softwaretechnik‘ ist eine Erwartungen liefern einen guten Anlass, erneut aus- klassische Vorlesung im Umfang von 3 SWS. Um nicht zuführen, daß ein Ziel der Vorlesung ist, fundamenta- an einem Tag der Woche auf eine Stunde Tutorium le Designprobleme zu verstehen und Designentschei- umschalten zu müssen, interpretieren wir das 3+1- dungen präzise zu beschreiben und auf Aspekte gu- Format als drei Vorlesungen (à 90 Minuten) und ein ten Designs hin zu analysieren, wir jedoch keine kon- Tutorium (à 90 Minuten) in zwei Wochen. kreten Verfahren zur Erstellung guter Designs für spe- Über die vorhandene Infrastruktur zeichnen wir ziﬁsche Anwendungsfelder diskutieren. Wir plausibi- das gesprochene Wort und den Bildschirminhalt auf lisieren diese Zielsetzung durch eine grobe Beschrei- und stellen die Aufzeichnungen zeitnah zur Verfü- bung des weiten Spektrums von Software: von Onli- gung. Auf diese Weise konnten wir die Vorlesungen neshops, über Standardanwendungen (Textverarbei- ohne Skript bestreiten, da das gesprochene Wort je- tung, etc.), kommerzielle Spiele, Betriebswirtschaftli- derzeit zum Nachhören verfügbar ist. Weiterhin kön- che Software, bis hin zu sicherheitskritischen, einge- nen die Teilnehmer::innen, denen unser Vortrag zu betteten Systemen. Jeder dieser Bereiche hat eigene, langsam oder zu ausführlich ist, die Geschwindig- bewährte Vorstellungen von gutem Design, die unter- keit beim Anhören der Aufzeichnung selbst bestim- einander nicht austauschbar sein müssen. men. Entsprechend der Selbsteinschätzung der Teil- nehmer::innen (vgl. Abschnitt 1) sprechen wir in der 3.1 Klausur Vorlesung lieber zu langsam als zu schnell und betrachten neue Inhalte ggf. aus mehreren Perspekti- Ähnlich wie (Lehmann u. a., 2015), haben wir sehr ven, was für einige Teilnehmer::innen zu langsam früh in der Überarbeitung der Veranstaltung mit sein kann. In der Evaluation geben, über die Jah- der Vorbereitung der Klausur begonnen. Laut Mo- re 2016 bis 2018 aggregiert,3 von 99 Rückmeldun- dulhandbuch ist eine schriftliche Prüfung vorgese- gen knapp 25 % an, sich die Inhalte hauptsächlich hen und somit war klar, daß die Vorlesung notwen- durch Anwesenheit anzueignen, und 18 % bzw. 33 % dig schriftlich prüfbare Inhalte in hinreichendem Um- geben ‚teils/teils‘ bzw. ‚hauptsächlich über die Auf- fang und Tiefe präsentieren muß. Um das Risiko zeichnungen‘ an. Entsprechend haben wir eher ge- zu mindern, zum zentral festgelegten Klausurtermin ringe Besucherzahlen in der eigentlichen Vorlesung, keine geeignete Klausur stellen zu können, haben dafür jedoch Besucher::innen, die die Präsenz für Fra- wir, ausgehend von einem ersten Entwurf des Zu- gen oder Kommentare nutzen möchten, denen wir, so schnitts der Vorlesung, Aufgabenskizzen und eine gut es die Zeit erlaubt, Raum geben. grobe Festlegung der Proportionen für die Themen- Das Lernziel, eine Übersicht entsprechend der eta- bereiche erstellt. Vorlesungsinhalte, Klausuraufgaben blierten Lehrbücher zu geben, hat für uns zwei und Übungsinhalte wurden dann im Sinne eines gu- Teilaspekte. Einerseits den Aspekt der Vermittlung ten Constructive Alignments (Biggs u. Tang, 2011) auf- von Techniken und Verfahren und andererseits den einander abgestimmt. Zum Ende der Vorlesungszeit Aspekt „der Mensch steht im Mittelpunkt“ (Ludewig 2015 stand für die Studierenden zur Klausurvorberei- u. Lichter, 2013). Der erste Aspekt ist relativ gut prüf- tung eine Beispielklausur zur Verfügung, seit 2016 ist die Beispielklausur mit dem ersten Vorlesungstag auf 3Im Jahr 2015 wurde in der Evaluation zum Vortragsbesuch der Lernplattform verfügbar. eine andere, nicht gut vergleichbare Frage gestellt.

4 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 24 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg bar (und kann als Vorbereitung auf die Klausur gesehen sind. Weiterführende technische Fragen können hen werden). Zum zweiten Aspekt ist unser Ziel, das konstruiert werden, indem man die gezeigte Problem- (gesprochene und schriftliche) Kommunizieren von stellung leicht modifiziert und eine erneute Analyse Softwaretechnik-Problemen und Lösungsideen und erfragt. Bei der Diskussion von Lösungen und weiter- die Analyse und Bewertung von Lösungsideen ein- führenden Fragen achten die Tutor::innen auf präzise zuüben. Dieser zweite Aspekt ist ungleich schwerer Sprache, insbesondere die korrekte Verwendung von prüfbar (und kann als Vorbereitung auf „das echte Softwaretechnik-Fachsprache. Leben“ gesehen werden) und findet in unserer Veran- Für die schriftliche Darstellung in den Einreichun- staltung schwerpunktmäßig im Übungsbetrieb statt gen fordern wir regelmäßig die Form „Problem in ei- (siehe folgender Abschnitt). genen Worten darstellen – eigenen Lösungsvorschlag formulieren – begründen, argumentieren, im besten 3.3 Übungsaufgaben und Tutorate Falle: beweisen, daß der Lösungsvorschlag das defi- Die Vorlesung wird von Übungen begleitet. Vor der nierte Problem löst“ und halten die Tutor::innen da- ersten Vorlesung jedes 3er Blocks steht ein Übungs- zu an, in Kommentaren zu den Einreichungen kon- blatt zur Verfügung, das direkt nach dieser Vorlesung tinuierlich diese Form nachzufragen.5 Entsprechend teilweise und nach der zweiten Vorlesung des Blocks sind die (ausgewogen vorkommenden) offenen Mo- vollständig bearbeitet werden kann, sodaß für jede dellierungsaufgaben absichtlich unpräzise formuliert. Aufgabe mindestens eine Woche zur Bearbeitung zur Hierbei ist unserer Erfahrung nach der angemesse- Verfügung steht. Studierende bearbeiten die Aufga- ne Grad an Unschärfe in der Aufgabenstellung im ben in Teams aus 2 bis 3 Personen und können ihre B. Sc.-Programm signifikant geringer als im M. Sc.- Bearbeitungen bis zur Minute vor Beginn des Tutori- Programm. Diese absichtliche Unschärfe und die diums auf der Lernplattform einreichen. daktische Absicht kommunizieren wir ganz explizit: In den Tutorien legen wir Wert auf Interaktion wir gehen (stark) davon aus, daß die allerwenigs- (i.S.v. (Krusche u. a., 2017)). Das heißt, es sind nicht ten Absolventen in ihrer beruflichen Laufbahn präzi- die Tutor::innen, die eine Beispiellösung vorstellen, se Aufgabenstellungen bekommen werden — und un- die „passiv konsumiert“ werden kann („man trifft sich ter dieser Annahme können wir ruhig im 4. Semester nicht mehr nur, um ‚gemeinsam zuzuhören‘“ (Siege- langsam mit Aufgaben dieser Art beginnen. Im ersten ris, 2017)),4 sondern der Modus der Tutorien ist „wir Jahr der Veranstaltung gab es in der Evaluation ver- erarbeiten eine gute Lösung zusammen“ bzw. „wir einzelt Wünsche nach ganz klaren Aufgaben. Unsere analysieren und bewerten Lösungsvorschläge und Hypothese ist, daß in den meisten vorherigen Veran- diskutieren weiterführende Fragen“. Die Tutor::innen staltungen präzise Aufgabenstellungen vorherrschen sehen wir im Tutorium vor allem als Moderator::in, (und den Lernzielen angemessen sind, vgl. auch Ab- nicht als Vortragende::r. Hierbei sollen die Lösungs- schnitt 4.2) und die ‚Softwaretechnik‘ sich in diesem wege und -überlegungen transparent werden. Zu die- Aspekt für die Studierenden ungewohnt anfühlt. sem Zweck sind die Tutor::innen angehalten, für die Am Tag vor den Tutorien führen wir jeweils ein Tu- technischen Aufgaben (im Sinne des Retrieval-Based- torium für die Tutor::innen durch, vor dem die Tu- Learning) die Teilnehmer::innen zunächst nach den tor::innen das Übungsblatt selbst skizzenhaft lösen. relevanten Definitionen zu fragen. Bei kleinen Auf- In diesen Tutors’ Tutorials gehen wir (in der Art der gaben schreiben die Tutor::innen Lösungsvorschläge Tutorien für die Studierenden) die Aufgaben durch, aus dem Auditorium auf den Bildschirm, bei größe- diskutieren weiterführende Fragen, legen die Lernzie- ren Aufgaben bringen die Tutor::innen bemerkens- le der jeweiligen Aufgaben und Fragen dar und geben werte Lösungen mit ins Tutorium und stellen sie zur Tips zur Moderation. Der Ablauf der Tutorien steht Diskussion. Die bemerkenswert guten oder eigenarti- danach inklusive Vorschlägen für weiterführende Fra- gen Lösungen werden aus sogenannten Early Submis- gen und Lernziele als eine Art „Drehbuch“ zur Verfü- sions ausgewählt. Wir bieten denjenigen Teams, die gung. In der ersten Durchführung hatten wir leich- 24 Stunden vor dem Tutorium Lösungen einreichen, te Sorge, daß sich die Tutor::innen in ihrer gestal- einen 10 %-Bonus auf die erzielten Zulassungspunk- terischen Freiheit beschränkt fühlen könnten. Hier te. Beispiele für weiterführende Fragen ergeben sich waren die Rückmeldungen bisher durchweg positiv: z.B. im Bereich des Requirements Engineering wie ganz im Gegenteil würden die Tutors’ Tutorials Sicher- folgt. Eine technische Aufgabe kann darin bestehen, heit (z.B. im Zeitmanagement) geben und kognitive eine gegebene Formalisierung einer Anforderung auf Kapazitäten für tiefer gehende Fragen und Kommen- (formale) Vollständigkeit zu untersuchen. Ausgehend tare von Seiten der Studierenden freihalten. Weiter- von der (technischen) Lösung ergibt sich die Frage, hin erreichen wir durch diesen Ansatz eine überwie- wie das Resultat in der Rolle Requirements Engineer gend gleichbleibende Qualität der Tutorien, unabhän- zu interpretieren ist und welche Konsequenzen für gig von dem/der konkreten Tutor::in. die Kommunikation mit der Kundenseite ggf. zu zie- 5Nicht zuletzt im Interesse der Studierenden: Wir gehen davon 4Auch wenn einige Studierende sich dies lt. Evaluation wün- aus, daß gut präsentierte Lösungsvorschläge bei der Klausurvorbe- schen würden. reitung zumindest nicht hinderlich sind.

5 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 25 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

Tabelle 2: Kursinhalte und Struktur. Vorlesungen Themenbereich Inhaltsübersicht 1 Einleitung Software, Engineering, Software Engineering; Erfolgreiche Softwareent- wicklung, Empirische Daten zum Erfolg von Softwareprojekten; Aufbau des Kurses, Bezug zu anderen Lehrveranstaltungen, Organisatorisches. 2–5 Projektmanagement Softwaremetriken, Skalen; Kostenschätzung (Experten- und algorithmische Schätzung); Projekt, Prozess, Prozess Modellierung; Prozedurmodel- le; Prozessmodelle (Agil, V-Modell (semi-formal)). 6–10 Requirements Engineering Vokabular: Anforderungen, Anforderungsanalyse; Anforderungen im Ent- wicklungsprozess; Eigenschaften von Anforderungsspezifikationen (Voll- ständigkeit, Konsistenz, . ..), Arten von Anforderungen, Analysetechniken; Dictionary; Spezifikationssprachen für Anforderungen: natürlichsprachli- che Pattern, Entscheidungstabellen (formal), Use Cases und -Diagramme (semi-formal), LSCs (formal). 11 – 14 Design & Architektur Modell; Sichten; Strukturmodellierung für Software (Klassen- und Objekt- diagramme (formal), Proto-OCL (formal)); Designprinzipien; Design Pat- terns; Verhaltensmodellierung für Software (Communicating Finite Auto- mata (formal), Query Language (formal)); ein Ausblick zu UML State- Machines. 15 – 18 Qualitätssicherung Testfall, Testausführung, falsch/richtig positive/negative Ergebnisse (formal); Grenzen des Softwaretestens; Glas-Box-Testen (Anweisungs-, Verzeigungs-, Term-Überdeckung); Modell-basiertes Testen, Runtime-Veri- fikation; Programmverifikation (formal), Code Review.

In der auf das Tutorium folgenden Woche geben los an die Diskussion der Begriffe der Modellierung die Tutor::innen individuelle (für die Klausurzulas- und die Bedeutung von Modellen in der Softwareent- sung relevante) Bewertungen und Kommentare zu wicklung bereits im ersten Kapitel von (Ludewig u. den Einreichungen. Hierbei werden die Einreichun- Lichter, 2013) anfügt. In der Diskussion der (gegen- gen auf zwei verschiedenen Skalen bewertet. Die für über (Ludewig u. Lichter, 2013)) neuen Inhalte bemü- die Klausurzulassung relevante good-will-Skala be- hen wir uns, dem evidenzbasierten Stil des Lehrbuchs wertet „sinnvolle Bearbeitung“ relativ zum Wissen zu folgen, also rationale Wertungen zu ermöglichen der Studierenden vor dem Tutorium. Hier interpre- und soweit möglich die (ursprünglichen) Quellen an- tieren die Tutor::innen unklare Formulierungen im zugeben. Entsprechend zeigen wir anhand von Bei- Zweifel zugunsten der Studierenden. Um einen Ein- spielen, was Formale Methoden konkret leisten kön- druck von der Bewertung in der Klausur zu geben, be- nen, was ihre Fürsprecher::innen versprechen und werten wir außerdem jede Aufgabe auf der evil-Skala, welche Kritik vorgebracht wird, sodaß die Studieren- die sich am Punkteschema der Klausur und am Wis- den Vor- und Nachteile verantwortlich und kontext- sen nach dem Tutorium orientiert, insbesondere dar- abhängig abwägen können. über, wie bestimmte Aufgabenstellungen im Kontext der Veranstaltung im Zweifel zu interpretieren sind. Tabelle 2 gibt einen Überblick über die Inhalte Hier werden unklare Formulierungen oder Fehler in der Vorlesung. Wir beginnen mit dem Themenbereich der Syntax zuungunsten der Studierenden gewertet. Projektmanagement, da die Inhalte dieses Bereichs für die Teilnehmer::innen des parallel im 4. Semes- 4 Formale Methoden in der ter stattfindenden Software-Praktikums (SoPra) für Softwaretechnik-Vorlesung B. Sc.-Studierende nützlich sein können. Es gibt von Seiten der Teilnehmer::innen durchaus den Wunsch Für die Darstellung von Vokabular, Problembereichen nach einer Abstimmung zwischen dem SoPra und und nicht formalen Inhalten folgt unsere Vorlesung der ‚Softwaretechnik‘, der aus verschiedenen Grün- im Wesentlichen dem Lehrbuch (Ludewig u. Lichter, den nicht praktikabel (und, da das SoPra eine in sich 2013). Wir schätzen an diesem Lehrbuch die expli- abgeschlossene Veranstaltung mit eigenen Vorlesun- zit adressierte Sicht, „dass sich Software-Engineering gen ist, auch nicht notwendig) ist. Ein Grund ist, daß vor allem mit den Menschen befasst, die Software in im SoPra bereits in der dritten Woche die Spezifika- Auftrag geben, entwickeln und ändern oder benut- tion und ein Architekturentwurf abzugeben sind. Ein zen“ und das u.E. sehr gelungene „[B]emühen [...] weiterer Grund ist, daß in jedem Jahr über 30% der um eine rationale Wertung“ und darum, „alle Quel- ‚Softwaretechnik‘-Teilnehmer::innen das SoPra nicht len [...] vollständig anzugeben“. in ihrem Studienplan haben und Versuche einer en- Im folgenden beschreiben wir unsere Erweiterung geren Abstimmung bei diesen Teilnehmer::innen zu der Inhalte um formale Modelle in der Softwareent- signifikanten Verwirrungen geführt haben. Als Kom- wicklung, die sich unserer Wahrnehmung nach naht- promiss haben einige Übungsaufgaben einen Bezug

6 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 26 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg zum SoPra, der sich den SoPra-Teilnehmer::innen er- Wir nutzen bei der Auswahl der Inhalte die re- schließt, und für die anderen Studierenden einfach lative späte Lage der Veranstaltung im Studienplan „ein Beispielprojekt“ ist. aus (vgl. Abschnitt 2). So bauen wir auf ‚Grundla- In der Präsentation und Diskussion der nicht- gen der Theoretischen Informatik‘, die Mathematik- formalen Inhalte folgen wir (Ludewig u. Lichter, Vorlesungen und ‚Rechnerarchitektur‘ auf, in denen 2013), wobei wir im Zweifel direkt auf die ursprüng- die Studierenden bereits mit verschiedenen Forma- lichen Quellen zurückgreifen, z.B. die Normtexte IE- len Methoden konfrontiert wurden (wenn auch viel- EE 601.12 und ISO 24765 für Vokabular und IE- leicht nicht unter diesem Namen). Unsere Veranstal- EE 830 zur Struktur von Anforderungsdokumenten. tung zeigt gewissermaßen, wie ein großer Teil des In den folgenden Abschnitten geben wir einen Über- bisher Gelernten in der Softwarekonstruktion ange- blick über die von uns ergänzten formalen und semi- wandt werden kann. formalen Inhalte. 4.1 Themenbereich Aufgrund unserer in der Einleitung ausgeführten Softwareprojektmanagement Beobachtung eines Mangels an geeigneten Lehrbü- chern, haben wir die formalen Inhalte selbst ausge- Im Themenbereich Softwareprojektmanagement wählt bzw. konstruiert. Der Überarbeitung der Veran- überwiegen nicht-formale Inhalte (vgl. Tabelle 2). staltung lag die Hypothese zugrunde, daß es durch ei- Ein Schwerpunkt sind Softwaremetriken als ein ne angemessene Reduktion des Sprachumfangs mög- Aspekt der ingenieurmäßigen, objektivierten Soft- lich ist z.B. die formale Spezifikationssprache für wareentwicklung (inklusive des Bewusstseins für Strukturaspekte OCL vollständig definiert einzufüh- Pseudometriken (vgl. (Ludewig u. Lichter, 2013))). ren und die Idee Formaler Methoden und Analysen Ein weiterer Schwerpunkt ist die Prozessmodellie- 7 zu vermitteln, und gleichzeitig der Vermittlung der rung. Hier führen wir zunächst eine semi-formale etablierten nicht-formalen Inhalte einen angemesse- graphische Beschreibungssprache für Prozesse ein, nen Raum zu geben. Bei der Auswahl der Teilspra- bestehend aus Rollen, Artefakten, Aktivitäten und chen von z.B. OCL stand das Ziel im Vordergrund, den entsprechenden Relationen. Wie zeigen, wie die formalen Sprachen nicht artifiziell zu vereinfa- ein konkreter Ablauf (oder Prozess) einer Softwa- chen, sondern echte Teilsprachen auszuwählen, die reentwicklung modelliert werden kann (deskriptiv, in Spezialvorlesungen konservativ erweitert werden. Abbild), um dann zu zeigen, wie ein graphisches Pro- Wir konnten hierbei auf eine langjährige Erfahrung zessmodell präskriptiv (Vorbild) verwendet werden aus Forschungs- und Projektarbeit sowie aus unse- kann, um Prozessabläufe vorzugeben. Wir verwen- ren Spezialvorlesungen ‚Software, Design, Modelling, den unsere graphische Beschreibungssprache, um and Analysis in UML‘ (UML) und ‚Real-Time Sys- konkrete Prozedur- und Prozessmodelle (Wasserfall, tems‘ im M. Sc. Informatik zurückgreifen, in denen V-Modell, XP, Scrum) vorzustellen bzw. setzen die für die Modellierungssprachen jeweils eine vollständi- Notation z.B. der V-Modell-Beschreibung zu unserer ge konkrete und abstrakte Syntax sowie eine forma- Teilsprache in Beziehung. le Semantik eingeführt wird. In der UML-Vorlesung In den Übungsaufgaben ist anhand von vorgegebe- sind dies Klassen- und Objektdiagramme, OCL, State- nen Prozessbausteinen ein kleines Entwicklungspro- Machines und Sequenzdiagramme. jekt zu planen inklusive Besetzung von Rollen mit Per- Bei der Auswahl der Beispiele in der Vorlesung und sonen. Um die Tutor::innen insbesondere auf Fragen der Konstruktion der Übungsaufgaben greifen wir sound Diskussionen zur Verwendung und zum Nutzen weit möglich auf reale, industrielle Softwareprojekte von Prozessmodellen vorzubereiten, haben wir ent- (bestenfalls aus unserer eigenen Erfahrung) zurück, sprechend des Prinzips „lehren, was wir praktizieren“ da so sichergestellt ist, daß wir Nachfragen in belie- in 2018 den Prozess des Übungsbetrieb vollständig biger Detailtiefe zufriedenstellend beantworten kön- modelliert. Die Erläuterung des Prozesses ist aufwen- nen.6 Dabei verwendet die Vorlesung für die verschie- dig, dafür weiß über das gesamte Semester jede::r denen Formalen Methoden verschiedene Beispiele an Tutor::in, wer wann welches Artefakt wie zu bearbei- denen sich die spezifischen Stärken zeigen. Wir möch- ten hat und wir können unsere ganze Aufmerksam- ten (und können redlicherweise) nicht den Eindruck keit den eingereichten Lösungsvorschlägen widmen. erwecken, daß der Stand der Technik der Formalen 4.2 Themenbereich Methoden ist, ein Softwaresystem vollständig und Requirements Engineering durchgängig konsistent formal zu beschreiben. For- male Methoden sind dann effektiv, wenn geeignete Der Themenbereich Requirements Engineering (RE) Formalismen zur Beschreibung und Analyse spezifi- ist in der Veranstaltung etwas stärker gewichtet als scher, besonders kritischer oder komplexer Aspekte die weiteren Themenbereiche (vgl. Tabelle 2). Dies von Software mit Bedacht eingesetzt werden. ist vor allem drei Überlegungen geschuldet. Erstens stimmen wir zu (etwa (Sedelmaier u. Landes, 2017)), 6Dies ist bei artifiziell konstruierten Beispielen ungleich schwerer herzustellen und kann, wenn es nicht gelingt, unnötige Unzu- 7d.h. präzise konkrete Syntax, informelle Beschreibung der Be- friedenheit auf Seiten der Studierenden hervorrufen. deutung.

7 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 27 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg daß dem Themenbereich RE in der Softwareentwick- ist, eine für alle Beteiligten gute Beispiellösung zu er- lung eine besondere Relevanz zukommt. Die Rele- arbeiten. Unser Kunde ist ein Organisator des SoPra, vanz wird dabei in den späteren Themenbereichen unsere Anforderung war in 2018 der oben genannte sehr natürlich aufgegriffen: Der Begriff der Korrekt- Satz. Die Aufgabe besteht darin, durch Kommunika- heit von Softwareentwürfen (insbesondere bzgl. des tion mit dem Kunden ein Begriffslexikon zu erarbei- Verhaltens) und von Software ist relativ zu einer An- ten und die nicht im Satz enthaltenen Informationen forderung. Etwa ein Algorithmus kann nur als korrekt „herauszukitzeln“. Um die Aufgabe skalierbar zu ge- (bzgl. einer Anforderung) bewiesen werden, wenn stalten, führen zunächst die Organisatoren unserer es eine formale Beschreibung der Anforderung gibt. Veranstaltung eine Anforderungsanalyse durch und Zweitens beobachten wir, daß die Vermittlung von notieren die Findungen in einem Wiki. Die Studieren- Problemen und Techniken des RE für Studierende mit den kommunizieren mit dem (für sie anonymen) Kun- wenig oder keiner Vorerfahrung eine besondere Her- den per Mail, vermittelt durch die Tutor::innen. Mit ausforderung darstellt (vgl. Selbsteinschätzung der Hilfe des Wiki können die Tutor::innen die meisten Studierenden, Abschnitt 2). Drittens führen wir in un- Fragen ihrer Tutanden schon im Stile eines Kunden serer Veranstaltung im Themenbereich RE zum ers- beantworten, noch unklare Aspekte werden an den ten Mal Formale Methoden ein. SoPra-Organisator weitergeleitet und im Wiki nach- Wir sprechen bei unseren Diskussionen i.d.R. über geführt; weiterhin sind die Tutor::innen angehalten, die u.E. besonders herausfordernde Situation eines die Kommunikation in der Art eines Coaches zu be- Softwareentwicklungsvertrages zwischen getrennten obachten und Tips für weitere Fragen zu geben. Für Kunden- und Entwicklungsunternehmen. Die Softwa- das Tutorium bereiten wir eine Liste von bekannten reentwicklung in Start-Ups, innerhalb einer Abtei- Beispielspielen vor, die die Anforderung lt. Kunde er- lung oder zwischen Abteilungen desselben Unterneh- füllen bzw. nicht erfüllen. Im Tutorium sollen die Teil- mens hat ggf. andere Rahmenbedingungen. nehmer::innen durch Handzeichen pro Beispiel anzei- Bei der Vermittlung von Problemen und Techniken gen, ob nach ihrer konkreten Anforderungsanalyse des RE arbeiten wir mit zwei (bisher leider nicht das Beispiel vom Kunden akzeptiert oder abgelehnt empirisch belegten) Hypothesen zu Ursachen von wird bzw. ob sie sich nicht sicher sind. In 4 Jahren Schwierigkeiten. Eine Ursache sehen wir darin, daß Durchführung dieser Übung hat noch nicht ein Team der weitaus überwiegende Teil der Übungsaufgaben, alle Beispiele korrekt klassifiziert; dies wird durch das die die Studierenden bis zum 4. Semester bearbei- Verfahren mit den Handzeichen im Tutorium unmit- ten, von Fachleuten in Fachsprache präzise formu- telbar für die Studierenden erfahrbar. liert sind (nicht zuletzt, um die Korrektur zu vereinfa- In der Einführung der Problemstellung der An- chen). Entsprechend stellen wir Übungsaufgaben zu forderungsanalyse und nicht-formalen Beschreibung unserer Veranstaltung absichtlich unpräzise und hal- von Anforderungen folgen wir (Rupp u. a., 2014). ten dazu an, in den Einreichungen zunächst die Auf- Wir beginnen die Diskussion von Beschreibungsspra- gabenstellung in eigenen Worten wiederzugeben (vgl. chen am nicht-formalen Ende der in Abbildung 1(b) Abschnitt 3.3). Als zweite Ursache vermuten wir, daß dargestellten Achse mit der natürlichsprachlichen Be- der Umgang mit Sprache im Alltag von dem in der schreibung und Sprach-Patterns (Rupp u. a., 2014) RE-Arbeit verschieden ist. Im Alltag sind Menschen und diskutieren Eigenschaften guter Anforderungsdo- üblicherweise gern bereit, einen Satz wie: kumente wie Vollständigkeit. Die Präsentation wech- Spielfiguren müssen indirekt gesteuert werden. selt dann ans formale Ende der Achse und dort zu einem möglichst einfachen Formalismus (vgl. Ab- direkt als „klar“ zu akzeptieren und keinen Bedarf schnitt 4.2.1), um dann im semi-formalen Bereich für Nachfragen zu sehen (fehlende Information wird z.B. User Stories und Use Cases einzuführen. Ein kom- plausibel aufgefüllt; man sieht nur Information). In plexer Formalismus (vgl. Abschnitt 4.2.2) und ein der RE-Arbeit geht es unseres Erachtens beim Blick Rückblick schließen den Themenbereich ab. auf den obigen Satz vor allem darum, zu sehen, wel- 4.2.1 Entscheidungstabellen che Information der Satz nicht enthält. Um diesen Sichtwechsel anzuregen, führen wir Als Einstieg in die formale Beschreibung von Anfor- eine Übung durch, in der die Studierenden eine derungen haben wir als eine möglichst einfache Spra- textuell gegebene Anforderung analysieren. Diese che die in vielen Lehrbüchern semi-formal eingeführ- Übung wird in verschiedenen Ausprägungen im RE- ten Entscheidungstabellen (ET) ausgewählt. ET sind Unterricht eingesetzt, etwa mit Paaren von studenti- eine der einfachsten Beschreibungssprachen, die mit schen Teams, die jeweils die Kunden- bzw. Entwickler- formaler Semantik und Analysen versehen werden rolle übernehmen oder mit nicht technisch vorgebil- können, sind jedoch weder trivial noch eine artifi- deten (echten) Kunden. Wir verwenden eine Varian- zielle Lehrsprache. Die schlichten Sprachmittel von te mit einem technisch vorgebildeten Kunden, da wir ET reichen vollständig aus, um Anforderungen zu bein den anderen Szenarien die Gefahr sehen, daß die schreiben, die in textueller Form sehr schnell nicht Parteien aneinander vorbeireden und es aufwendig mehr überblickbar, wartbar oder analysierbar sind.

8 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 28 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

T r ··· r : decision table 1 n ET die wichtige Diskussion, wie sich z.B. die formale c c v ··· v 1 description of condition 1 1,1 1,n Vollständigkeit einer ET zur vollständigen Erfassung ...... einer Anforderung im Sinne von (Rupp u. a., 2014) c c v ··· v m description of condition m m,1 m,n verhält. Eine Analyse einer formalen Beschreibung a a w ··· w 1 description of action 1 1,1 1,n bzgl. einer Eigenschaft wie Vollständigkeit kann po- ...... sitiv (Eigenschaft nicht gegeben) oder negativ aus- a a w ··· w k description of action k k,1 k,n fallen und dieses Ergebnis kann (wie Testresultate) falsch oder richtig sein. Ein Grund für ein falsch- Abbildung 2: Konkrete Syntax von ET. positives Resultat kann z.B. ein simpler Schreibfeh- ler beim Verfassen der formalen Beschreibung sein. Formal ist eine ET T über disjunkte Mengen von Be- Ein positives Resultat liefert jedoch in jedem Fall ein dingungen C und Aktionen A eine n × m-Matrix (sie- Indiz dafür, daß uns z.B. in der Anforderungserfas- sung ein Fehler unterlaufen ist und dieses Indiz ist he Abbildung 2) wobei c1,...,cm ∈ C, a1,...,ak ∈ im Zweifel zusammen mit den Kunden zu klären. Für A, v1,1,...,vm,n ∈ {−, ×, ∗}, und w1,1,...,wk,n ∈ {−, ×}. Eine wohlgeformte ET hat einen Namen. ET liefern die Werkzeuge im positiv-Fall sogar alle Be- obachtungen, die in T nicht berücksichtigt werden, Spalten (v1,i,...,vm,i, w1,i,...,wk,i), 1 ≤ i ≤ n, werden Regeln genannt und haben einen eindeutigen Na- und die sich üblicherweise gut in die Begriffs- und Er- fahrungswelt der Kunden übersetzen und als solche men (hier: r1,...,rn). Die Vektoren (v1,i,...,vm,i) klären lassen. Die Formalisierung einer Anforderung und (w1,i,...,wk,i) heißen Prämisse und Effekt von und die formale Analyse kann also sicherstellen, daß Regel ri. Die Semantik einer ET T ist durch die Funk- tion F gegeben, die jeder Regel r in T eine Formel alle Probleme, die zu positiven Resultaten führen, er- der propositionalen Logik über C und A wie folgt zu- kannt und ggf. ausgeräumt werden. Die formale Ana- lyse kann nicht sicherstellen, daß die Anforderungs- ordnet. Seien (v1,...,vm) und (w1,...,wk) Prämisse und Effekt von r. Dann ist analyse als solche vollständig ist, da falsch-negative Resultate möglich sind. Ob der Aufwand der Formali- sierung und Analyse von Anforderungen oder Design- F(r) := V1≤i≤m F (vi,ci) ∧ V1≤j≤k F (wj ,aj) (1) ideen das verringerte Fehlerrisiko rechtfertigt, ist je | {z } | {z } =:Fpre(r) =:Feff (r) nach Projektkontext zu entscheiden. Die Übungsaufgaben zu ET umfassen verschiedene mit F := {(×, x) 7→ x, (−, x) 7→ ¬x, (∗, x) 7→ formale Analysen von gegebenen ET sowie eine Auf- true}. Die Teilformeln F (r) und F (r) heißen pre eff gabe, in der ein Transkript eines Kundeninterviews Prämissen- bzw. Effektformel. (mit absichtlichen Redundanzen und Mehrdeutigkei- Eine ET kann wie folgt zur Formalisierung einer ten) im Umfang von ca. einer DIN-A4-Seite in eine Anforderung der Art, daß Systemverhalten in akzep- ET mit ca. 10 Regeln über jeweils 5 Bedingungen und tabel (oder erwünscht) und unerwünscht klassifiziert Aktionen überführt werden soll. Im Tutorium stellen wird, verwendet werden. Ein System erfüllt die durch wir die (provokante) Frage: Nehmen wir an, man ET T gegebene Anforderung genau dann, wenn je- müsste als Implementierer::in des Kundenwunsches des beobachtbare Systemverhalten durch eine Regel zwischen Text und ET als Spezifikation wählen, was in T erlaubt wird. Formal kann eine Beobachtung ei- wäre die Wahl? Und warum? Meiner Kenntnis nach nes Systems bzgl. der Bedingungen und Aktionen in hat sich in den 4 Jahren der Veranstaltung noch nie- C und A, also welche Bedingungen aus C erfüllt sind mand ausdrücklich den Text gewünscht. Hier versu- und welche Aktionen aus A ausgeführt werden, als chen wir, einen Aspekt sichtbar zu machen, der unse- Boole’sche Belegung σ C A , der logischen : ∪ →{0 1} rer Meinung nach im Kontext formaler Beschreibun- Variablen in C A notiert werden. Die Beobachtung ∪ gen noch vor der Anwendung von formalen Analy- σ erfüllt T genau dann, wenn es eine Regel r in T sen steht. Eine formale Beschreibung einer Anforde- gibt, sodaß σ r . |= F( ) rung hat den Effekt, daß (mit hoher Wahrscheinlich- Begriffe wie Vollständigkeit können für ET präzise keit) alle im verwendeten Formalismus ausgebildeten T definiert werden, z.B. nennen wir eine ET (formal) Softwaretechniker::innen zu jeder Zeit dieselbe Infor- vollständig, wenn die Disjunktion der Prämissenfor- mation sehen.8 So sehen wir formale Beschreibun- T meln von eine Tautologie ist. Das Problem der Ana- gen zuvorderst als Werkzeug, um auf Seiten der Soft- lyse auf (formale) Vollständigkeit kann auf das Erfüll- waretechniker::innen das Risiko von Missverständnis- barkeitsproblem propositionaler Logik reduziert wer- sen zu verringern. Als Analogie verwenden wir z.B. den, für das in Form von sogenannten SAT-Solvern von Jurist::innen konstruierte Individualverträge, de- Entscheidungswerkzeuge zur Verfügung stehen. ren Konsequenzen man als Nicht-Jurist üblicherwei- In der Vorlesung ‚Softwaretechnik‘ diskutieren wir se nicht überblicken kann. Man hat als Auftragge- nun nicht eine Reduktionsprozedur oder die Kon- ber des Individualvertrags jedoch den Anspruch, von struktion von SAT-Solvern, sondern nehmen eine Nut- zersicht ein, nehmen also zur Kenntnis, daß Werkzeu- 8Gestandene Praktiker::innen berichten, daß es vorkommt, daß ge dieser Art existieren. Wir führen am Beispiel der dieselbe Person am selben Tag einen Text verschieden interpretiert.

9 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 29 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg der Fachperson eine „Übersetzung“ zu erhalten bzw. 4.3 Themenbereich Entwurf darauf, wichtige Szenarien gemeinsam durchzuspie- Im Themenbereich Softwarearchitektur und Entwurf len. Ebenso hat man als Softwarekunde einen An- liegt der Schwerpunkt auf der Modellierung der spruch, von den Entwickler::innen deren z.B. in for- Struktur und des Verhaltens von Softwaresystemen maler Form notiertes Verständnis der Anforderun- als Baupläne im Sinne von (Lamport, 2015). Zur gen erklärt zu bekommen. Dies kann insbesondere Strukturmodellierung führen wir eine übersichtliche durch Szenarien gelingen (vgl. (Arenis u. a., 2016)). Teilsprache der Klassendiagramme von UML ein, die Für jedes von dem/der Kund::in formulierte Szena- im wesentlichen Klassen mit Attributen von Basisty- rio können Entwickler::innen auf Basis der formalen pen und gerichteten Assoziationen der Multiplizitä- Beschreibung Auskunft geben, ob ihrem Verständnis ten 0,1 und 0,∗ mit Ownership umfasst.Neben der be- nach dieses Szenario erwünscht oder unerwünscht kannten Sicht, Klassendiagramme als Visualisierung ist. Bei Verwendung formaler Beschreibungen ist die- von (Klassen in) Programmen zu betrachten, beto- se Auskunft objektiv und beliebig reproduzierbar. nen wir die Sicht eines abstrakten (von der Pro- Die Klausur umfasst Aufgaben verschiedener Taxo- grammierung zunächst unabhängigen) Strukturmo- nomie-Stufen zu ET, vom Beweis z.B. der Vollstän- dells. Die abstrakte Syntax eines Klassendiagramms digkeit einer ET, über die Analyse einer gegebenen ist eine Signatur mit Klassen, Basis- und abgeleiteten ET auf Konsistenz bis hin zur Erstellung einer klei- Typen, und je Klasse der Menge der Attribute dieser nen ET zu einem Text. Die Ergebnisse (vgl. (Westphal, Klasse. Die Semantik eines Klassendiagramms ist die 2018)) sind sehr erfreulich. Den gesamten Aufgaben- Menge der über dieser Signatur bildbaren System- bereich lösten in 2015 bis 2017 mehr als 50 % der zustände (OMG, 2006), d.h. partiellen Funktionen, Teilnehmer::innen mit 14 bzw. 13 von 15 Punkten, die (einige) Objektidentitäten auf jeweils eine Bele- liegen also im guten oder sehr guten Bereich, obwohl gung der Attribute mit Werten abbilden. Systemzu- wir die Analyseaufgabe klar den „schweren“ Aufga- stände können graphisch (ohne Informationsverlust) ben der Klausur zuordnen. Die Grenze zum unteren durch vollständige Objektdiagramme dargestellt wer- Quartil liegt bei erfreulichen 12,5 bzw. 12 Punkten. den. Hier stellen wir die Anwendung von Objektdia- 4.2.2 Live Sequence Charts grammen in der Dokumentation und Spezifikation Als komplexen Formalismus (mit höherer Ausdrucks- heraus. Wenn der Aufwand, bestimmte Annahmen stärke und Informationsdichte, und höherem Auf- einer Datenstruktur z.B. mit OCL zu formalisieren, wand zur Definition von (abstrakter) Syntax und Se- in einem Projekt als zu hoch bewertet wird, kann mantik) haben wir Live Sequence Charts (Damm u. eine geeignete Auswahl von Objektdiagrammen her- Harel, 2001) (LSCs) ausgewählt, eine formale Vari- vorragend zur Spezifikation dieser Annahmen „durch ante der weit verbreiteten Sequenzdiagramme. Wir Beispiel“ verwendet werden. Wenn etwa eine Listen- führen die Automatensemantik für LSCs nach (Klo- struktur nur unter der Annahme verwendet werden se u. Wittke, 2001) ein, inklusive Chart-Modus, Cold darf, daß keine Zyklen konstruiert werden. Conditions, und Pre-Charts. Ein System erfüllt eine Eigenschaften von Strukturen können mit Hilfe der (universelle) LSC genau dann, wenn alle Berechnun- Object Constraint Language (OCL) formalisiert wer- gen des Systems von dem aus der LSC konstruier- den. Hier führen wir Proto-OCL ein, eine Teilspra- ten Automaten akzeptiert werden. Weiterhin führen che der OCL, deren konkrete Syntax sich an der den wir aus, wie LSCs (bzw. ihre Automaten) in der auto- Studierenden vertrauten Form der Logik erster Stufe matischen Testdurchführung verwendet werden kön- orientiert. Die Semantik von Proto-OCL ist eine In- nen (Klose u. Lettrari, 2001). terpretationsfunktion, die eine gegebene Proto-OCL- Die Klausur umfasst Aufgaben zur Konstruktion Formel und einen gegebenen Systemzustand (oder der Automaten sowie erfragt Beispiele für akzeptier- ein vollständiges Objektdiagramm) auf einen der drei te bzw. nicht akzeptierte Systemberechnungen. Nicht (!) Werte true, false und ⊥ abbildet. Wir stellen die zuletzt da die Einführung von LSCs den technisch an- Besonderheiten heraus, daß OCL Assoziationen ver- spruchsvollsten Teil unserer Vorlesung darstellt, se- schiedener Multiplizität verschieden behandelt sowie hen wir diese Aufgaben im „mittleren“ und „schwe- die Bedingungen, unter denen man eine Auswertung ren“ Bereich, der am Ende die guten und sehr guten zum dritten Wahrheitswert beobachten kann. Gesamtnoten entscheidet. Mit den Resultaten sind Für die konstruktive Modellierung von Verhalten wir auch hier zufrieden, das untere Quartil endet bei führen wir eine einfache Teilsprache von State- 8,5 bzw. 7 von 15 bzw. 16 Punkten, das obere Quartil Machines ein. Unsere Communicating Finite Automa- beginnt bei 13 bzw. 12 Punkten. ta (CFA) sind im Wesentlichen nicht-hierarchische Im ersten Jahr waren wir von den guten Ergebnis- State-Machines mit Rendezvous-Synchronisation, sen bei aller Zuversicht positiv überrascht. Wir hatten d.h. zwei Kanten in verschiedenen Automaten uns vereinzelt vorgetragenen Sorgen, daß die LSC- können eine Transition begründen, wenn je eine Semantik zu schwer sein könnte, nicht völlig entzie- der Kanten bzgl. eines Events sende- bzw. emp- hen können und entsprechend Vorsorge getragen, die fangsbereit ist. Dieses Synchronisationsparadigma Aufgaben zu LSCs ggf. aus der Wertung zu nehmen. ist mit durch State-Machines implementierten

10 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 30 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

Behavioural Features in UML vergleichbar jedoch ment von Soll ist. Hier betonen wir ((Ludewig u. Lich- nicht (ohne weitere Annahmen) identisch. Zu dieser ter, 2013) folgend) besonders den Aspekt, daß die Abweichung von der UML-Semantik haben wir uns Begriffe des positiven und negativen Tests relativ zu vorrangig aus zwei Gründen entschieden. Einerseits Soll-Werten (die sich ggf. aus (formalen) Anforderun- erfordert die formale Einführung des abstrakten gen ableiten lassen) definiert sind. Die Resultate der Event-Speichers (in der die UML-Semantik be- Klausuraufgaben zum Testen sind durchweg ordent- kanntlich parametrisiert ist) sowie einer konkreten lich, jedoch sind wir jedes Jahr wieder überrascht, Ausprägung, etwa einer empfängerseitigen FIFO- daß eine signifikante Anzahl der Studierenden keine Queue, wie sie IBM Rhapsody verwendet, in unserer Soll-Werte angibt, obwohl explizit nach einer erfolglo- UML-Veranstaltung ca. 2 Vorlesungen. Der Erkennt- sen Test-Suite gefragt wird. nisgewinn im Vergleich zum Aufwand erscheint uns Als gegenüber den etablierten Lehrbüchern neu- für eine Softwaretechnik-Veranstaltung zu gering. en Inhalt präsentieren wir Programmverifikation Andererseits steht mit Uppaal (Larsen u. a., 1997) nach (Hoare, 1969) in der Form des Lehrbuchs (Apt ein Werkzeug zur Erstellung, Simulation und Verifi- u. a., 2009). Für die Übungen verwenden wir das kation von (insbesondere)9 CFAs mit einer reichen Web-Interface des Verifying C Compilers (Cohen u. a., Programmiersprache für Guards und Aktionen zur 2009) (VCC) und diskutieren als weiterführende Fra- Verfügung, das nicht zuletzt aufgrund seines sehr gut gen den Unterschied zwischen der Verifikation eines auf das Wesentliche reduzierten User-Interfaces10 Algorithmus und der Verifikation eines C-Programms hervorragend für unsere Ziele geeignet ist.11 unter Annahmen über die Ausführungsplattform. Die Die Übungsblätter zu CFA umfassen Aufgaben zur Klausuraufgabe besteht üblicherweise darin, eine ge- Erstellung eines Modells eines verteilten Algorithmus gebene Beweisskizze mit den verwendeten Axiomen für Mutual-Exclusion (das den Teilnehmer::innen als und Beweisregeln zu annotieren. Hier erreicht das Problem aus der Betriebssysteme-Vorlesung bekannt obere Quartil zwischen 5,5 und 7 von 7 Punkten, das sein müsste), zur Simulation verschiedener Abläu- untere Quartil endet bei 3 bis 5 Punkten. fe und zur Verwendung von Uppaal’s Temporallogik (Query Language) zur Spezifikation und Verifikati- 5 Lehrevaluation on der Mutual-Exclusion-Eigenschaft. Mit den Übun- Da die Veranstaltung neu konstruiert wurde, beob- gen verfolgen wir insbesondere das Ziel, das mäch- achten wir seit der ersten Durchführung verschiedene tige Modellierungskonzept des Nichtdeterminismus Metriken (vgl. Abschnitt 4.1) auf Indizien für Fehlent- und die durch nebenläufiges Verhalten induzierten wicklungen. Daten beziehen wir aus dem Übungsbe- Schwierigkeiten sichtbar zu machen. trieb, den Klausuren und der zentralen Evaluation. In der Klausur ist üblicherweise der Transitions- In der Evaluation beachten wir besonders die graph eines gegebenen Systems von mehreren CFAs Aspekte „Workload“ und „Niveau“ (Uttl u. a., 2017) zu erstellen. Mit den Ergebnissen sind wir durchweg und die Freitexte. Den Workload sehen über alle zufrieden, der Median liegt zwischen 10 und 12,25 4 Jahre gesehen rund 62% der Studierenden als ‚mit- von 13 Punkten, das obere Quartil beginnt zwischen tel‘ und rund 30 % als ‚hoch‘, das Niveau sehen rund 12 und 13 Punkten, liegt also im sehr guten Bereich. 62 % als ‚angemessen‘ und rund 29 % als ‚hoch‘. Dies 4.4 Themenbereich Qualitätssicherung entspricht vollständig unserem Ziel für eine universi- täre Lehrveranstaltung. Im Themenbereich Qualitätssicherung betrachten wir Den Lernerfolg bzgl. des Lernziels der Vermittlung speziell die Prüfung von Programmcode. Hier disku- von Methoden und Techniken messen wir anhand der tieren wir zunächst die Disziplin des Softwaretestens. Klausurergebnisse, mit denen wir über alle 4 Jahre Dem formalen Charakter der gesamten Veranstaltung sehr zufrieden sind. Das viel interessantere Lernziel folgend, führen wir Testfälle als Paare (In, Soll) aus der Vorbereitung auf das „echte Leben“ läßt sich lei- einer (Menge von) Eingabe(n) und Soll-Wert(en) ein. der notorisch nicht gut messen. Als ein positives In- Eine Ausführung eines Testfalls ist eine Beobachtung diz sehen wir unsere und von Kolleg::innen berichte- des Systems, die Eingaben entsprechend In erhält, te Erfahrung aus Vorgesprächen zu individuellen Pro- was ein einzelner Wert oder eine Sequenz von z.B. jekten wie etwa B. Sc.-Arbeiten. Hier nehmen wir die Events sein kann. Ein Test ist negativ (Test passed) ge- Inhalte der Vorlesung als (angestrebten) soliden Be- nau dann, wenn die betrachtete Beobachtung ein Ele- zugspunkt wahr, um über spezialisierte Aufgabenstel- 9Daß Uppaal für CFAs mit Uhrenvariablen, also Timed Automa- lungen zu sprechen. Wir hoffen, daß sich die Veran- ta, entwickelt wurde, verschweigen wir schlankerhand. staltung ebensogut als Bezugspunkt für den Einstieg 10Aus denselben Überlegungen führen wir kein Werkzeug zur in die berufliche Karriere der Studierenden eignet. Erstellung von Klassendiagrammen ein. Die für die Einarbeitung in die Bedienung der meisten dieser Werkzeuge notwendige Zeit steht unserer Meinung nach in keinem akzeptablen Verhältnis zu 6 Zusammenfassung den Absichten z.B. unserer Übungen (vgl. (Glinz, 1996)). Formale Methoden werden zunehmend in vielen 11Einige Teilnehmer::innen unserer UML-Veranstaltung, in der wir IBM Rhapsody verwenden, vermissen die mächtige und leicht Bereichen der Softwaretechnik angewandt. Unserer zu bedienende Simulationsfunktion von Uppaal. Überzeugung nach ist es hilfreich, wenn die Bedeu-

11 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 31 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg tung formaler Beschreibungen vollständig durchdrun- [Glinz 1996] GLINZ, M.: The Teacher: “Concepts!” gen wird und die aus formalen Analysen zu ziehen- The Student: “Tools!”. In: Softwaret.-Trends 16 den Schlüsse verstanden werden. (1996), Nr. 1 Unsere Erfahrung zeigt, daß es möglich ist, eine Veranstaltung zur Einführung in die Softwaretechnik [Hoare 1969] HOARE, C. A. R.: An axiomatic basis im Grundstudium um genau diese Aspekte zu ergän- for computer programming. In: CACM 12 (1969), zen ohne hierbei die Inhalte der etablierten Lehrbü- Nr. 10, S. 576–580 cher zu vernachlässigen. [IEEE 1990] IEEE: Standard Glossary of Software En- Danksagungen. Wir danken Sergio Feo Arenis und gineering Terminology, 1990. – Std 610.12-1990 Christian Schilling für ihre Unterstützung als Assistenten [IEEE 1998] IEEE: Recommended Practice for Softwa- der ersten beiden bzw. des letzten Jahres. Ohne die Ge- re Req. Specifications, 1998. – Std 830-1998 spräche mit Sergio und Christian und ihre Ausarbeitung und Weiterentwicklung der Übungsaufgaben wäre die Ver- [ISO/IEC/IEEE 2010] ISO/IEC/IEEE: Systems and anstaltung in ihrer heutigen Form nur schwer vorstellbar. software eng. – Vocabulary, 2010. – 24765:2010(E) Weiterhin danken wir unseren stud. Hilfskräften für ihre engagierte Mitarbeit an Aufgaben und Tutorials. [Klose u. Lettrari 2001] KLOSE, J.; LETTRARI, M.: Scenario-based Monitoring and Testing of Real- Literatur time UML models. In: GOGOLLA, M. (Hrsg.) u. a.: UML Bd. 2185, Springer, 2001 (LNCS) [Anderson u. a. 2001] ANDERSON, L. W. (Hrsg.) u. a.: A Revision of Bloom’s Taxonomy of Educational Ob- [Klose u. Wittke 2001] KLOSE,J.; WITTKE, H.: An jectives. Longman, 2001 Automata Based Representation of Live Sequence Charts. In: MARGARIA, T. (Hrsg.) u. a.: TACAS, [Apt u. a. 2009] APT,K.R.; BOER,F.S.; OLDEROG, Springer, 2001 (LNCS 2031) E.-R.: Verification of Sequential and Concurrent Pro- grams. Springer, 2009 [Krusche u. a. 2017] KRUSCHE,S.;FRANKENBERG, N. von ; AFIFI, S.: Experiences of a Software Engi- [Arenis u. a. 2016] ARENIS, S. F. ; WESTPHAL, B. u. a.: neering Course based on Interactive Learning. In: Ready for testing: ensuring conformance to indus- SEUH, 2017, S. 32–40 trial standards through formal verification. In: FAoC 28 (2016), Nr. 3, S. 499–527 [Lamport 2015] LAMPORT, L.: Who builds a house without drawing blueprints? In: CACM 58 (2015), [Balzert 2009] BALZERT, H.: Lehrbuch der Softwa- Nr. 4, S. 38–41 retechnik: Basiskonzepte und Requirements Enginee- ring. 3rd. Spektrum, 2009 [Langenfeld u. a. 2016] LANGENFELD, V. ; POST, A. u. a.: Requirements Defects over a Project Lifeti- [Biggs u. Tang 2011] BIGGS,J.;TANG, C.: Teaching me. In: DANEVA, M. (Hrsg.) u. a.: REFSQ Bd. 9619, for Quality Learning at University. 4th. Open Uni- Springer, 2016 (LNCS), S. 145–160 versity Press, 2011 [Larsen u. a. 1997] LARSEN,K.G.;PETTERSSON, P. ; [Bjørner 2006a] BJØRNER, .: SWE, Vol. 1: Abstraction YI, W.: UPPAAL in a Nutshell. In: STTT 1 (1997), and Modelling. Springer, 2006 Dezember, Nr. 1, S. 134–152 [Bjørner 2006b] BJØRNER, D.: SWE, Vol. 2: Specifica- [Lehmann u. a. 2015] LEHMANN, T. u. a.: Lecture En- tion of Systems and Languages. Springer, 2006 gineering. In: SCHMOLITZKY, A. (Hrsg.) u. a.: SEUH [Bjørner 2006c] BJØRNER, D.: SWE, Vol. 3: Domains, Bd. 1332, CEUR-WS, 2015, S. 103–109 Req. and Software Design. Springer, 2006 [Ludewig u. Lichter 2013] LUDEWIG,J.;LICHTER, H.: [Bloom 1956] BLOOM, B. S. (Hrsg.): Taxonomy of Software Engineering. 3rd. dpunkt, 2013 Educat. Objectives: Cognitive Domain. Longman, [OMG 2006] OMG: Object Constraint Language, Ver- 1956 sion 2.0. formal/06-05-01, 2006 [Cohen u. a. 2009] COHEN, E. u. a.: VCC: A Practical [Rupp u. a. 2014] RUPP, C. u. a.: Requirements- System for Verifying Concurrent C. In: BERGHOFER, Engineering und -Management. 6th. Hanser, 2014 S. (Hrsg.) u. a.: TPHOLs Bd. 5674, Springer, 2009 (LNCS), S. 23–42 [Sedelmaier u. Landes 2017] SEDELMAIER, Y. ; LAN- DES, D.: Experiences in Teaching and Learning Req. [Damm u. Harel 2001] DAMM, W. ; HAREL, D.: LSCs: Engineering on a Sound Didactical Basis. In: DAVO- Breathing Life into Message Sequence Charts. In: LI, R. (Hrsg.) u. a.: ITiCSE, ACM, 2017, S. 116–121 FMSD 19 (2001), Juli, Nr. 1, S. 45–80 [Siegeris 2017] SIEGERIS, J.: LearnTeamPlenum. In: SEUH, 2017, S. 1–7 12 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 32 Formale Methoden in der Softwaretechnik-Vorlesung Bernd Westphal, Uni Freiburg

[Sommerville 2010] SOMMERVILLE, I.: Software Engi- lated. In: Stud. Educat. Eval. 54 (2017), S. 22 – 42 neering. 9th. Pearson, 2010 [Westphal 2018] WESTPHAL, B.: An Undergraduate [Uttl u. a. 2017] UTTL, B. u. a.: Meta-analysis of fa- Requirements Engineering Curriculum with Formal culty’s teaching effectiveness: Student evaluation Methods. In: REET, IEEE, 2018, S. 1–11 of teaching ratings and student learning are not re-

13 V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 33 Stager: Simplifying the Manual Assessment of Programming Exercises

Christopher Laß, Stephan Krusche, Nadine von Frankenberg, Bernd Brügge Technische Universität München [email protected], [email protected], [email protected], [email protected]

Abstract programming exercises in large courses can take a Assessing programming exercises requires time and ef- considerable amount of time and effort. Automatic fort from instructors, especially in large courses with assessment systems (also called auto-graders) aim at many students. Automated assessment systems re- flexibility and scalability in large courses, and allow duce the effort, but impose a certain solution through to integrate exercises into lectures [Krusche et al., test cases. This can limit the creativity of students and 2017b]. These systems utilize, among others, version lead to a reduced learning experience. To verify code control systems (VCS) to store the code solutions of quality or evaluate creative programming tasks, the students in repositories and test cases that are exe- manual review of code submissions is necessary. How- cuted on a continuous integration server to assess ever, the process of downloading the students’ code, the solution to a programming exercise automatically identifying their contributions, and assessing their [Heckman and King, 2018; Krusche and Seitz, 2018]. solution can require many repetitive manual steps. While automated assessment systems significantly In this paper, we present Stager, a tool designed reduce manual assessment effort, they have draw- to support code reviewers by reducing the time to backs. Predefined test cases cannot cover all possible prepare and conduct manual assessments. Stager solutions and therefore impose a certain solution on downloads multiple submissions and adds the stu- the students. Some students are limited in their pro- dent’s name to the corresponding folder and project, gramming skills, while other students can exploit the so that reviewers can better distinguish between dif- test cases by repetitive trial-and-error submissions. ferent submissions. It filters out late submissions and Especially first year students who are new to program- applies coding style standards to prevent white space ming often experience problems when trying to for- related issues. Stager combines all changes of one mulate their solution and thoughts as an executable student into a single commit, so that reviewers can computer program [Robins et al., 2003]. Such sub- identify the student’s solution more quickly. missions can be overly complicated, and assessment Stager is an open source, programming language systems cannot (yet) provide enough useful feedback agnostic tool with an automated build pipeline for in that regard. Furthermore, some programming exer- cross-platform executables. It can be used for a va- cises cannot be assessed automatically. The automated riety of computer science courses. We used Stager grading of creative assignments with open problem in a software engineering undergraduate course with statements is hardly possible because different solu- 1600 students and 45 teaching assistants in three sep- tions exist [Knobelsdorf and Romeike, 2008; Krusche arate programming exercises. We found that Stager et al., 2017a]. An example for such an assignment improves the code correction experience and reduces is to implement a creative collision strategy in a 2D the overall assessment effort. racing game. Automated test cases could be able to validate a collision, but are incapable of assessing 1 Introduction the creativity or code quality of the solution. As a result, manual assessment can be beneficial, even in The number of students in university courses is in- large courses that have fully implemented automated creasing. The number of new undergraduate students grading solutions. at our computer science department increased by 81 % However, the process of manually assessing multi- between 2013 (1110 students) and 2017 (2005 stu- ple students’ solutions requires repeated manual steps. dents)1. Practical programming exercises are essential Tasks such as finding the next student’s repository, in computer science education and help students ac- downloading the source code, and renaming the fold- quire important skills in software development [Staub- ers and projects names for standardization can be itz et al., 2015]. However, a manual assessment of time-consuming and error-prone. Determining a stu- 1https://www.tum.de/die-tum/die-universitaet/ dent’s contribution is challenging when the exercise die-tum-in-zahlen/studium builds upon a provided code template and when the

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 34 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München students use multiple commits in their code repository. can therefore be less time consuming to manually as- Then it becomes difficult to separate the provided sess solutions rather than to design the automated template and the final solution. assessment system [Ala-Mutka, 2005]. In this paper, we present Stager, a tool that is de- Further, students can become distracted by au- signed to support the manual assessment of program- tomated feedback. For instance, students may be ming exercises. Reviewers, e.g. teaching assistants or tempted to fix only the failing tests instead of focus- instructors, can automate the manual steps that are ing on the assignment [Heckman and King, 2018]. necessary to prepare the students’ code repositories, Automated assessment systems circumvent the de- for instance download all repositories at once, and tection of frequent mistakes or misunderstandings thereby reduce the manual assessment time. The idea among students. The understanding and resolution for Stager evolved during an undergraduate university of common errors is an essential learning experience course with 1600 students and 45 teaching assistants. for students. Semi-automated systems combine the An initial implementation was used for three separate mentioned aspects by providing automated grading, programming assignments. as well as manual feedback. Such systems offer per- The remainder of the paper is organized as follows. sonalized feedback to some extent, for instance the We describe related work focusing on existing auto- instructor can annotate a static assessment [Gerdes mated assessment solutions and the limitations of et al., 2017]. Other systems give the student instant automated assessment approaches in Section 2. In feedback if the student’s solution is correct. If it is Section 3, we cover Stagers’ approach to automat- not, the instructor reviews each solution and can give ing the recurring manual steps during the correction additional feedback if required [Insa and Silva, 2015]. of programming exercises. We describe design deci- Many systems focus on the grading itself, but not on sions, the exercise workflow with Stager, the configu- the process the instructor has to follow to obtain the ration possibilities of the tool, and the concrete tasks students’ solutions. of Stager, e.g. the Download repositories task. We ana- Some commercially available systems and tools that lyze the improved code assessment experience of the are used in computer science (CS) courses offer fea- teaching assistants by means of an experience report tures that aim at simplifying this process. In 2000, in Section 4, where we also present the results of a Jackson proposed an approach that pre-processes stu- quantitative analysis of Stager’s use in three program- dent submissions (sent via e-mail) by removing irrele- ming exercises. Section 5 concludes the paper and vant information or unpacking files [Jackson, 2000]. provides directions for future work. For submissions via repositories, pull requests (also called merge requests) in GitHub2, GitLab3, or Bit- 2 Related Work bucket4 allow students to commit their changes into separate branches. After requesting the code to be Several automated assessment system approaches for merged into the main branch, i.e. a submission, re- programming assignments exist [Heckman and King, viewers can highlight the student’s contribution as 2018; Knobelsdorf and Romeike, 2008; Krusche and difference to the template code and provide feedback Seitz, 2018; Pieterse, 2013]. Advantages include a de- by requesting changes. While pull requests can also crease in the workload of course instructors and timely be integrated with continuous integration systems, feedback for students [Pieterse, 2013]. Automated e.g. using TravisCI5 to detect compile errors and to systems work well to grade programming assignments run automated tests, reviewers might still need to consistently and evaluate specific aspects, e.g. the download the source code and execute it to verify if functionality [McCracken et al., 2001] or efficiency of all requirements of the problem statement have been a system [Jackson and Usher, 1997]. However, they solved. are missing the benefit of personal feedback which GitLab introduced a “Squash and Merge” option a manual grading approach could provide. The test which “applies all of the changes in a merge request cases used by such systems cannot assess the code as a single commit, and then merges that commit us- quality and “elegance” of the solution [Poženel et al., ing the merge method set for the project”6. This cleans 2015]. up the commit history and can make it easier to iden- Building a robust automated assessment system tify the contribution of one particular student. Tools amounts to a heavy workload, whereby the definition and services, such as Gerrit7, support code reviews of the test cases is (usually) the most time consuming that enable the reviewer to see the code difference, activity [Cerioli and Cinelli, 2008]. This workload is and provide the option to leave in-line comments. amplified when designing tasks with some degree of freedom of solutions [Chen, 2004]. The degree of free- 2https://github.com dom of solutions indicates the difficulty of the exercise 3https://gitlab.com [Striewe and Goedicke, 2013], meaning that a diffi- 4https://bitbucket.org 5 cult exercise has more possible solutions and therefore https://travis-ci.org 6https://docs.gitlab.com/ee/user/project/merge_ has an increased workload to design the automated requests/squash_and_merge.html assessment system. Depending on the class size, it 7https://www.gerritcodereview.com

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 35 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

However, such tools primarily focus on continuous Reviewer Stager Student feedback rather than assessing a student’s solution. 1.1 Receive exercise and 3 Stager’s Approach code template

This section presents an approach that automates man- 1.2 Solve ual steps during the correction of programming ex- exercise ercises in order to prepare student repositories for easier assessment. We show how code reviewers can 2.1 Configure 1.3 Commit and Stager push solution use Stager. Furthermore, we explain the different tasks that are automatically executed by Stager. 2.2. Trigger Figure 1 illustrates the exercise workflow including Stager the manual assessment with the help of Stager as a 3.1 Download UML activity diagram. As precondition for this work- repositories flow, every student must have their own repository 8 3.2 Rename with the code template for the exercise in a VCS . Af- folders ter the students complete the exercise, they commit and push their solutions to the VCS (action 1.3). 3.3 Filter late Before reviewers start to work, they need to config- submissions ure Stager (action 2.1). Then, they trigger Stager to process different tasks (actions 3.1 ... 3.6), such as 3.4 Rename projects Download repositories or Normalize code style. Finally, the reviewer can manually assess the pre-processed 3.5 Normalize submissions and give qualitative feedback (action 4.2 code style and 5.) to the students in any arbitrary form (e.g. uploading the feedback into an exercise management 4.1 Manually 3.6 Combine 9 system such as Moodle ). assess commits prepared The action 2.1 Configure Stager of the Reviewer is repositories described in Section 3.1. Stager’s actions are described as tasks in Section 3.2. The numbering in Section 3.2 4.2 Give 5. Receive aligns with the corresponding action in Figure 1. qualitative qualitative feedback feedback 3.1 Stager’s Setup Stager is free, open source, and available under the MIT license10. It is platform independent and pro- Figure 1: Exercise workflow with Stager: students gramming language agnostic, making Stager univer- complete the exercise and upload their solutions to a sally applicable. It is written in the Go programming VCS. The reviewer configures and triggers Stager to language11 and makes use of the distributed version process different tasks, e.g. 3.1 Download repositories. control system git12. Cross-platform executables can Afterwards, the reviewer manually assesses the pre- be downloaded from the automatic build pipeline or pared repositories and gives qualitative feedback to compiled from the source code. the students. Stager’s configuration is separated into two files students.csv and config.json, based on how frequently password have to be set with valid credentials and the settings change. The list of students in students.csv access rights to the VCS. For SSH, Stager uses the might not change during the course duration, while operating system’s global SSH settings and therefore config.json changes for every exercise. The configu- does not require further configuration. ration procedure must be completed after the code 2. Latest commit hash of a programming exer- template was finished and before Stager is executed. cise template: The programming exercises that are Stager or its configuration does not add any precon- distributed to the students build upon a given code ditions or constraints on the students. The following template. The SHA hash of the latest commit for settings can be edited: the code template, meaning the latest code changes 1. Credentials: Remote git repositories can be ac- the reviewer included, must be set for the JSON key cessed via the SSH or HTTP protocols [Lawrance et squash_after. This setting is required for Stager to al., 2013]. For HTTP, the JSON keys username and distinguish between the given code by the reviewer 8There are multiple tools available that automate this step, e.g. and code written by the student. This configuration ArTEMiS, Github Classroom, etc. option is used by the task Combine commits and is 9 https://moodle.org further elaborated in Section 3.2. 10https://github.com/arubacao/stager 11https://golang.org 3. Deadline for homework submission: Students 12https://git-scm.com have to submit their homework in a given time-frame.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 36 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

For example, the homework must be submitted by purpose. For example, the Rename folders task ap- Sunday midnight because the programming exercises pends the student’s name to the corresponding folder. will be discussed in class on Monday morning. How- Stager is composed of multiple tasks (shown in the ever, VCSs have limitations when it comes to time- Stager swimlane in Figure 1) that adhere to certain based repository access. As described in more detail rules and are sequentially performed during the tool’s in Section 3.2, the task Filter late submissions allows execution. The implementation allows a clear distinc- to overcome these VCSs limitations. The deadline for tion of tasks, such that each task addresses a separate students submitting their homework is set with the purpose. Therefore, it is easy to add new tasks or re- JSON key deadline. The standard datetime format move existing ones conceptually and implementation- YYYY-MM-DD HH:MM:SS must be used. For example, wise in the future. For example, when the reviewer 2018-08-31 23:59:59 is valid. does not need a certain task, only one line of code 4. Remote repository URL schema: Each student within the array of tasks has to be removed. Fur- has a personal repository that can be accessed with thermore, tasks must be idempotent, meaning that a unique URL. A general URL schema can be derived multiple executions of the task lead to the same out- from these unique URLs, where the students’ identi- put. Even though tasks are independent, they are fiers are substituted by a placeholder. For example, for processed sequentially, i.e. the order of the tasks is the repository URL (1) of student 10001, the derived relevant. For instance, repositories first have to be general URL schema is (2). If the repositories are ac- downloaded before other tasks have local file access. cessed using HTTP as in the example, two additional The goal of Stager is to simplify the manual assess- placeholders must be set for the reviewer’s credentials ment of programming exercises by modifying source (3). The resulting schema is set for the key url. code, files, and repositories. Repetitive manual steps that are required for the reviewer to start the assessment should be reduced or eliminated by Stager. We https://repo.uni/cs101/exercise01-10001.git (1) identified the following relevant tasks (listed accord- https://repo.uni/cs101/exercise01-%s.git (2) ing to the order of execution) and describe each of https://%s:%[email protected]/cs101/exercise01-%s.git (3) them in detail in the following: 1. Download repositories 5. List of students: In addition to the mentioned settings, Stager requires a list of students the reviewer 2. Filter late submissions wants to assess. The students’ names and identifiers 3. Rename folders are defined in the students.csv file with the format 4. Rename projects shown in Listing 1. All mentioned people and courses in this paper are placeholder names and do not exist 5. Normalize code style in reality. 6. Combine commits Listing 1: Sample students.csv 1. Download repositories: In order to better de- name , id termine the software quality and verify if all require- John Doe,10001 ments of the problem statement have been solved by Jane Roe,10002 the students’ submissions, it is necessary for the reviewer to compile and execute their homework source After configuration, the Stager executable, con- code locally. Hence the repositories must be available fig.json, and students.csv are placed in a dedicated on the reviewer’s computer. The initial task clones all and empty folder. Stager can then be executed via a repositories of the predefined students as-is and all at double click or from the terminal. Listing 2 illustrates once to a given folder on the reviewer’s computer. This this workflow. After Stager terminates, the students’ first task takes potential existing local repositories into repositories are locally available and prepared by the account and overwrites them. It ensures that each lo- tasks described in the following Section 3.2. cal repository is in sync with the remote repository Listing 2: Folder setup and execution of Stager and in a clean state. The following tasks modify files and therefore $ cd ~/cs101/assessment3 require write access to the repositories. These $ l s modifications can only be performed when the config.json stager students.csv repositories are locally available. Consequently, the $ . / s t a g e r Download repositories task must be first.

3.2 Stager’s Tasks 2. Filter late submissions: Homework submis- Stager provides an extendable framework which sions are tied to a hard deadline. With web-based makes it easy to add or remove tasks according to VCSs like Bitbucket or GitLab, it is hardly possible to the reviewer’s requirements. Tasks are functions that block student commits after a given deadline. Stu- modify the repository or its contents and have a single dents could exploit this situation and extend their

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 37 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München time to finish the exercise as shown in Figure 2. The distinguish between students within source code edi- Filter late submissions task analyzes the commit times- tors or integrated development environments (IDEs), tamps and sets the repository to the state of the pre- e.g. Eclipse13 (Figure 4), and allows to import mul- configured deadline in config.json. Commits after the tiple projects at the same time. Eclipse, for instance, deadline are not considered anymore. This way time- does not allow to import multiple projects with iden- based limitations of web-based VCSs are bypassed. tical names, which makes it impossible to compare However, this procedure is not fully forgery-proof, multiple solutions without renaming the projects. since commit timestamps can be manipulated. File changes made prior to this task would be striped out, since the repository is set to the state of the pre-configured deadline. Therefore, the Fil- ter late submissions task must be executed before any other task can modify files.

Figure 4: Prepend student names to projects so that the submissions of multiple students can be imported into Eclipse and reviewed at the same time. Jane Roe and John Doe are prepended to the project name. Otherwise the reviewer could only import one Eclipse Figure 2: Filter late homework submissions by exclud- project at the same time. ing commits after the homework submission deadline. The two commits above the red line are after the 5. Normalize code style: The encoding and code deadline while the two commits below the red line style of the provided code template and the final are before the deadline. student’s contribution should be consistent. Windows and Unix-based systems use different line breaks for 3. Rename folders: Depending on the naming code files by default. Windows uses carriage return convention, only the student’s identifier is used for and line feed “\r\n” as a line ending, whereas Unix the repository name. The resulting folders can be based systems use just line feed “\n”. Also, IDEs hard to keep separate and to associate with the correct might automatically enforce a different code style student. For obfuscation and identity protection this standard than desired. As illustrated in Figure 5, this is reasonable, but counterproductive on the reviewer’s could lead to non-relevant changes and obscured local system since it is easier to identify a student code differences in commits, thereby making it harder by their name and not through their id. Once the to assess the submission. To avoid these non-relevant repositories are locally available, the Rename folders file changes by the student, Stager invokes a linter task appends the student’s name to the corresponding that automatically normalizes the code to the same folder as illustrated in Figure 3. standards as the initial template. This means that all white space related changes, e.g. line breaks, empty spaces and tabs are removed, so that the reviewer does not need to analyze them. Each programming language has its own linting strategies, utilizing existing tools like eslint14 for Javascript or checkstyle15 for Java. This hides pure white space and encoding Figure 3: Append names to folders to better distin- changes and allows code reviewers to focus on the guish between students. Without the names john_doe actual contributions by the students. and jane_roe, it would be difficult to identify which folder belongs to which student. 6. Combine commits: Reviewers provide code templates as a starting point for the programming 4. Rename projects: As precondition of Stager, exercise, in which the student has to make changes each student must have their own repository for each across multiple files. These changes can be small com- published exercise. The content of these repositories pared to the provided template and consequently hard is always identical. As a result, the project names to identify by the reviewer. In order to determine the are also identical for all students. This leads to the student’s contribution more effectively, it is helpful to problem that reviewers could only import one project see the exact difference between the template and the at the same time into Eclipse in order to review and final submission instead of only looking at the final execute the code. Renaming all projects manually is submission. VCSs provide easy comparison methods time-consuming and error-prone. Analogue to the Re- 13https://www.eclipse.org name folders task, a student’s name is prepended to the 14https://github.com/eslint/eslint corresponding project name. This makes it possible to 15https://github.com/checkstyle/checkstyle

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 38 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München 4 Experience Report The following experience report describes the lecture- based course Introduction to Software Engineering (EIST16) in which we used Stager to improve the manual assessment of programming exercises. EIST is a second semester bachelor’s course with a heteroge- neous group of students including computer science, business informatics, and business students. Figure 5: There is no visual change in the two code The course assumes that students have successfully blocks in this figure. However, non-visible line breaks completed an introductory course in computer science cause the comparison tool to show these lines. This (e.g. CS1) and are familiar with object-oriented pro- can make it time-consuming for the reviewer to iden- gramming in Java. The course’s learning goals are tify relevant changes. that students are able to apply relevant concepts and methods in all phases of software engineering projects including analysis, design, implementation, testing, and delivery. Further, students know the most important terms and concepts and can apply them in where the difference made by a single commit is vis- modeling and programming tasks. They are aware ible. However, a submission can consist of multiple of the problems and issues that generally have to be commits. The reviewer would have to compare each considered in software engineering projects. Table 1 commit and memorize the changes themselves, which shows the schedule and the content of the course. makes the standard comparison method impractical and error-prone. Week Content 1 Introduction The combine commits task combines the students 2 Model-Based Software Engineering commits into one single commit. The reviewer does not need to review multiple changes within the same 3 Requirements Elicitation and Analysis code line and can omit changes that have been added 4 System Design I in one commit and removed again in a later commit. 5 System Design II This single commit also contains all Stager related 6 Object Design changes (e.g. white space changes). As a result, it is 7 Model Transformations and Refactorings easy for the reviewer to quickly identify the student’s 8 Pattern-Based Development contribution and to decide if the solution is correct. 9 Lifecycle Modeling In addition to the existing branches with the complete 10 Software Configuration Management commit history, Stager adds the combined commit into 11 Testing a separate branch. Thus, information is only added 12 Project Management and not removed from the repository and the reviewer 13 Repetitorium could still see the whole commit history. Web-based VCSs like GitHub also offer a squash feature, however, Table 1: The course Introduction to Software Engineer- the reviewer would have to trigger it manually for ing lasts 13 weeks. each repository. 1600 students were registered for the course in Figure 6 illustrates this process with an example 2018. One lecturer and three exercise instructors student John Doe and an Instructor. The Instructor were involved in the organization of the course. 45 provides a code template. John Doe works on the teaching assistants were responsible for holding 74 given exercise. Over a period of one day, John submits exercise group sessions per week. Teaching assistants his work separated across multiple commits. As seen were mainly bachelor students in the fourth semester, in the bottom right corner of Figure 6, one assignment who successfully completed the same course in the was to Add new car types to the game. Since John previous year. submitted multiple code changes and removed the The course design is based on interaction and as- “TODO” lines within the code, the reviewer would sumes active participation from students. The interac- have to actively scan all nine commits to identify tive parts include in-class exercises, in-class quizzes, John’s solution. Stager solves this time-consuming and exercise sessions. Students need to bring their process by combining all student commits into one laptops to the class and to exercise sessions. Stu- single commit that includes all changes by John. This dents can earn bonus points for completing in-class single commit is selected in the top of Figure 6. The and homework exercises successfully. They can use reviewer can see every file that has been modified by these bonus points to improve their final exam grade. the student and quickly identify, whether John has completed the assignment correctly. 16The German title is “Einführung in die Softwaretechnik”.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 39 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

Figure 6: Student commits are combined into one discrete change set: the commit at the top highlighted in blue. This commit displays the difference between a provided code template by the instructor and the submitted solution by the student. All commits of the student John Doe are still available.

For instance, if they score more than 90 % of the to- different design patterns to make the game extensible tal exercise points, their grade in the ﬁnal exam is for new requirements. improved by 1.0. This possibility motivates the stu- To submit their solutions, the students commit their dents to participate in the in-class exercises and in changes to a version control system. This automati- the homework exercises. In-class exercises consist cally triggers test cases on a continuous integration of quizzes (similar to the quiz exercises described in server to verify the given solution. After the submis- [Krusche et al., 2017c]), modeling and programming sion of their solution, students can automatically see exercises. Homework exercises include modeling, text the test results as individual feedback and improve and programming exercises. their solution according to this feedback.

4.1 Programming Exercises 1500 Participations in Homework Programming Exercises

Between 600 and 1200 students have actively partici- 1000 1.070 1.104 pated in each programming exercise throughout the 824 794 semester which is shown in Figure 7 and Figure 8. In 500 637 each exercise, the students had to write new source code or adjust existing code based on a given prob- 0 lem statement. All students worked on the existing H01 H02 H07 H08 H11 template code of an exercise in their individual git repository. The exercises were based on a 2D rac- Figure 7: Number of students who submitted solutions ing game called Bumpers. In the game, cars collide to homework programming exercises with each other and each collision has a winner. The course is designed so that each week’s exercises focus However, not all aspects of a problem statement on a different part of Bumpers in accordance with the can be automatically tested. Either it is difﬁcult to test lecture’s content, e.g. in week 8, “Pattern-Based De- a certain aspect of a solution, for instance complex velopment”, exercises include the implementation of behavior tests, or the problem statement provides a

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 40 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

1500 submission metrics. The number of commits per stu- Participations in In-Class Programming Exercises dent varies from 1.81 to 5.91 on average. Stager’s 1.213 1000 combine commits task will combine student commits 896 863 into one single commit so that reviewers can distin- 776 765 500 guish the difference between the provided code template and code submitted by the student immediately. 0 There are respectively 34, 8, and 7 late submissions L02 L07 L08 L10 L11 for the observed exercises. Stager will automatically filter commits that are contributed after the defined Figure 8: Number of students who submitted solutions exercise deadline. There are between 118 and 183 to in-class programming exercises students that submitted at least one commit where they only changed white spaces. While reviewing the high degree of freedom which makes it difficult to student contributions, white space related changes write test cases, e.g. open or visionary questions. are visually distracting to the reviewer (see Figure 5), The following three homework programming ex- since these changes are not relevant to the exercise. ercises required manual assessment by the teaching In informal discussions, seven teaching assistants assistants. The second and third exercises were graded reported that Stager reduced their reviewing effort semi-automated. significantly. The workflow without Stager required 1. Collision Detection: The task was to implement the teaching assistants to first filter the repositories a creative collision detection algorithm for cars in by student, then to check the commit dates and times, Bumpers. The students were given executable tem- clone or download the code, and to fix potential white plate code and had to extend it with a new class that space problems in order to be able to assess the actual included their solution. This exercise required manual sumbission. Depending on the amount of exercise ses- correction to test whether the new collision algorithm sions, teaching assistants had to perform this manual performed as intended. Additionally, the most creative workflow for up to 50 student submissions. Further, solutions were awarded and shown in class. the repository names only include the student’s iden- 2. Serialization of Code: The students had to in- tifiers, not names, so that mix-ups could occur when stantiate objects from two classes in Java. The main importing the solutions into an IDE. task was to serialize and deserialize these object using 4.3 Discussion JSON. An automated assessment system was used to test the input and output of the serialization. How- While using Stager, we identified four main advan- ever, the students wrote their own serialization code, tages: (1) Combining commits is particularly helpful so their solutions varied, e.g. in the naming of the ob- to review all changes of one student at a glance. This jects or methods. This required the teaching assistants allows the reviewer to immediately identify whether to assess the implementations manually. the student has understood the problem statement 3. Adapter Pattern: Based on a code template, the and has implemented a proper solution. (2) Renam- assignment was to extend the 2D car racing game ing the projects simplifies the assessment and compar- Bumpers with legacy code using the adapter pattern. ison of multiple solutions. The reviewer can import The legacy code for an existing analog speedome- multiple solutions at the same time with one click into ter panel was provided separately. An automated an IDE. It increases the confidence of the reviewers, so assessment system graded the students’ solution. In that the assessment is associated with the correct stu- addition, the teaching assistants had to verify if the dent. (3) While most students follow the deadline of speedometer panel was shown in the game user inter- an exercise, some students have committed changes face and displayed the velocity correctly. after the deadline. It would be possible to remove write permissions for all student git repositories at the 4.2 Results given deadline, but this might be hard to realize. En- In order to determine how many manual steps during forcing the deadlines in Stager is easier and filters the a homework assessment can be automated by Stager, cases where students try to circumvent the deadline. we conducted a quantitative analysis for these three (4) Stager only depends on using git repositories for programming exercises. For the qualitative analysis programming exercises and other instructors can use we focused on: it without adaptions in their courses, e.g. in GitHub Classroom or other git environments17. As Stager is 1. Number of commits per student open-source, other instructors can adapt it to their 2. Number of commits after the exercise deadline own needs. 3. Source code changes where only white spaces While Stager is easy to use as a standalone tool, have been added or removed reviewers need to configure it for each exercise as described in Section 3.1. It would further simplify the Table 2 displays an overview of the number of participating students for each exercise together with 17https://classroom.github.com

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 41 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

Metric 1. Collision Detection 2. Serialization of Code 3. Adapter Pattern Total submission count 1104 657 794 Total commit count 1998 3880 2447 Average amount of commits per student 1.81 5.91 3.08 Total commits after exercise deadline 34 8 7 Total submission count with at least 125 118 183 one white space related change

Table 2: Quantitative analysis of submission metrics for three programming exercises of the course configuration if Stager would be integrated into the fixes typical white space problems. All commits of one exercise management system, where the instructor student are combined into one discrete change-set sets up the programming exercise. Then Stager would that is easier to review. Code reviewers can better dis- automatically know the submission deadline, the lat- tinguish between the submissions of multiple students est commit of the instructor in the code template, and and identify students’ contributions more quickly. the remote repository URL. This would make the use Our experience in a course with 1600 students and of Stager easier and seamlessly. 45 teaching assistants shows that Stager reduced the reviewing effort and time for teaching assistants. The 4.4 Limitations reviewers used the saved time to write better reviews Our experience report only included three exercises and give more detailed feedback to the students. This that used Stager for code reviews. It would be in- improved the student’s learning. A quantitative analy- teresting to analyze the concrete time-savings with a sis in three programming exercises shows that Stager comparison and to use Stager throughout the whole identifies several late submissions and fixes many course. While we have first indications, we did not white space issues. evaluate whether the quality of the reviews improved Stager is free, open source, and available under the through the use of Stager. MIT license, so that other instructors can use it in their In addition, Stager’s implementation currently has courses18. We will continue the development and aim the following limitations: (1) Reviewers have to man- to integrate the tool into the automated assessment ually search for each student repository’s key the first system ArTEMiS [Krusche and Seitz, 2018]. Our fu- time they use Stager, before being able to use Stager ture work also includes the integration of code quality for the remaining steps. The previously mentioned metrics to support the actual code assessment. This integration of Stager into an exercise management could make it easier for reviewers to spot code quality system would overcome this step. (2) For every exer- issues in the students’ solutions and be included, e.g. cise, the config.json file has to be changed accordingly as a text file, into the feedback pipeline. with the deadline, URL-schema, and commit of the In addition, we would like to evaluate the quality instructor. This could also be adapted to be automat- of the code reviews when using Stager compared to ically included when creating exercises by means of pure manual reviews with respect to the completeness, an exercise management system. (3) Reviewers have helpfulness, and understandability of the review. De- to install Stager on their computer and start it via a pending on the results of this evaluation, we could in- double-click or the command line interface. A web- tegrate strategies to semi-automatically propose com- based solution or a plugin into an IDE (e.g. Eclipse) mon code review feedback. Automatic suggestions in which the reviewers import the code would provide would further reduce the effort of reviewers but al- a more user-friendly experience. low them to tailor these suggestions to the concrete situation. 5 Conclusion Manual code reviews are important for the learning References experience of students. While automatic tests can find [Ala-Mutka 2005] ALA-MUTKA, Kirsti M.: A Survey typical problems and check whether code works as of Automated Assessment Approaches for Program- intended, they cannot find all problems, code smells, ming Assignments. In: Computer Science Education and implementation issues. Automatic assessment 15, pages 83–102, 2005. imposes certain solutions on the students and might limit their creativity. Stager supports code review- [Cerioli and Cinelli 2008] CERIOLI, Maura ; CINELLI, ers by automating steps in the manual assessment of Pierpaolo: GRASP: Grading and Rating ASsistant programming exercises to reduce effort for the prepa- Professor. In: Proceedings of the Informatics Educa- ration and the conduction of code reviews. Stager tion Europe III Conference, 2008. downloads multiple students’ submissions, renames folders and projects, filters out late submissions, and 18https://github.com/arubacao/stager

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 42 Stager: Simplifying the Manual Assessment of Programming Exercises Christopher Laß, Stephan Krusche, Nadine von Frankenberg und Bernd Bruegge, TU München

[Chen 2004] CHEN, P. M.: An automated feedback the 19th Australasian Computing Education Confer- system for computer organization projects. In: IEEE ence, pages 17–26, 2017. Transactions on Education 47, pages 232–240, 2004. [Krusche et al. 2017c] KRUSCHE, Stephan ; VON FRANKENBERG, Nadine ; AFIFI, Sami: Experiences of [Gerdes et al. 2017] GERDES, Alex ; HEEREN, Bas- a Software Engineering Course based on Interactive tiaan ; JEURING, Johan ; BINSBERGEN, L. T. van: Learning. In: Tagungsband des 15. Workshops "Soft- Ask-Elle: an Adaptable Programming Tutor for ware Engineering im Unterricht der Hochschulen", Haskell Giving Automated Feedback. In: Interna- pages 32–40, 2017. tional Journal of Artiﬁcial Intelligence in Education 27, pages 65–100, 2017. [Lawrance et al. 2013] LAWRANCE, Joseph ; JUNG, Seikyung ; WISEMAN, Charles: Git on the Cloud [Heckman and King 2018] HECKMAN, Sarah ; KING, in the Classroom. In: Proceeding of the 44th ACM Jason: Developing Software Engineering Skills Us- Technical Symposium on Computer Science Education, ing Real Tools for Automated Grading. In: Pro- pages 639–644, 2013. ceedings of the 49th ACM Technical Symposium on Computer Science Education, pages 794–799, 2018. [McCracken et al. 2001] MCCRACKEN, Michael ; [Insa and Silva 2015] INSA, David ; SILVA, Josep: ALMSTRUM, Vicki ; DIAZ, Danny ; GUZDIAL, Semi-Automatic Assessment of Unrestrained Java Mark ; HAGAN, Dianne ; KOLIKANT, Yifat Ben- Code: A Library, a DSL, and a Workbench to Assess David ; LAXER, Cary ; THOMAS, Lynda ; UTTING, Exams and Exercises. In: Proceedings of the Con- Ian ; WILUSZ, Tadeusz: A Multi-national, Multi- ference on Innovation and Technology in Computer institutional Study of Assessment of Programming Science Education, pages 39–44, 2015. Skills of First-year CS Students. In: Working Group Reports on Innovation and Technology in Computer [Jackson 2000] JACKSON, David: A semi-automated Science Education, pages 125–180, 2001. approach to online assessment. In: SIGCSE Bulletin 32, pages 164–167, 2000. [Pieterse 2013] PIETERSE, Vreda: Automated As- sessment of Programming Assignments. In: Proceed- [Jackson and Usher 1997] JACKSON, David ; USHER, ings of the 3rd Computer Science Education Research Michelle: Grading Student Programs Using ASSYST. Conference, pages 45–56, 2013. In: Proceedings of the 28th Technical Symposium on Computer Science Education, pages 335–339, 1997. [Poženel et al. 2015] POŽENEL, Marko ; FÜRST, Luka ; MAHNICˇ, Viljan: Introduction of the auto- [Knobelsdorf and Romeike 2008] KNOBELSDORF, mated assessment of homework assignments in a Maria ; ROMEIKE, Ralf: Creativity As a Pathway university-level programming course. In: 38th In- to Computer Science. In: Proceedings of the 13th ternational Convention on Information and Commu- Annual Conference on Innovation and Technology in nication Technology, Electronics and Microelectronics, Computer Science Education, pages 286–290, 2008. pages 761–766, IEEE, 2015. [Krusche et al. 2017a] KRUSCHE, Stephan ; BRUEGGE, Bernd ; CAMILLERI, Irina ; KRINKIN, Kir- [Robins et al. 2003] ROBINS, Anthony ; ROUNTREE, ill ; SEITZ, Andreas ; WÖBKER, Cecil: Chaordic Janet ; ROUNTREE, Nathan: Learning and teaching Learning: A Case Study. In: Proceedings of the 39th programming: A review and discussion. In: Com- International Conference on Software Engineering: puter Science Education 13, pages 137–172, 2003. Software Engineering Education and Training Track, pages 87–96, IEEE, 2017. [Staubitz et al. 2015] STAUBITZ, Thomas ; KLE- MENT, Hauke ; RENZ, Jan ; TEUSNER, Ralf ; MEINEL, [Krusche and Seitz 2018] KRUSCHE, Stephan ; Christoph: Towards practical programming exer- SEITZ, Andreas: ArTEMiS: An Automatic Assess- cises and automated assessment in Massive Open ment Management System for Interactive Learning. Online Courses. In: Teaching, Assessment, and Learn- In: Proceedings of the 49th ACM Technical Sympo- ing for Engineering, pages 23–30, IEEE, 2015. sium on Computer Science Education, pages 284–289, 2018. [Striewe and Goedicke 2013] STRIEWE, Michael ; GOEDICKE, Michael: Analyse von Programmier- [Krusche et al. 2017b] KRUSCHE, Stephan ; SEITZ, aufgaben durch Softwareproduktmetriken. In: Andreas ; BÖRSTLER, Jürgen ; BRUEGGE, Bernd: In- Tagungsband des 13. Workshops "Software Engineer- teractive Learning: Increasing Student Participation ing im Unterricht der Hochschulen", pages 59–68, through Shorter Exercise Cycles. In: Proceedings of 2013.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 43 Projektmanagement lernen ohne Projekt Mario Winter, TH Köln [email protected]

Zusammenfassung Dabei sollen sie die PM-Methoden, -Techniken und -Werkzeuge zielgerichtet einsetzen und auch die er- Das Modul "Projektmanagement" (PM) wird seit forderlichen soziologischen und kommunikativen dem Studienjahr 2003 an der Fakultät Informatik Aspekte berücksichtigen können. Sie sollen mit dem und Ingenieurwissenschaften der TH Köln (bis Ziel einer menschengerechten und soziologisch fun- 09/2015 FH Köln) für alle Informatik-Studiengänge dierten Menschenführung eine wirkliche und opti- angeboten. Besondere Herausforderungen sind die male Produktivität bei komplexen Projekten erreicht seit 2012 zunehmend hohen Studierendenzahlen können. und die inhaltlichen und strukturellen Unterschiede Besondere Herausforderungen sind die seit 2012 der Curricula der vier beteiligten Bachelor-Studien- zunehmend hohen Studierendenzahlen und die in- gänge. Zudem lassen es unterschiedliche Gründe haltlichen und strukturellen Unterschiede der Cur- nicht zu, das PM unmittelbar auf ein reales (studen- ricula der vier beteiligten Studiengänge (Informatik, tisches Lehr-) Software-Entwicklungsprojekt ange- Medieninformatik, Technische Informatik, IT Ma- wendet wird. nagement und Wirtschaftsinformatik. Dieser Beitrag beschreibt die Entwicklung des Die unterschiedliche Positionierung des Moduls grundsätzlichen Lehr-/ Lern-Arrangements von PM in den Bachelor-Studiengängen – tw. im dritten, tw. hin zu einer kompetenzorientierten "Team- im fünften Semester – lässt es nicht zu, das die In- Teaching"-Veranstaltung für alle Studiengänge, den halte des Moduls von den Studierenden unmittelbar didaktischen Hintergrund und die Lehr-Erfahrun- auf reale (studentische Lehr-) Software-Entwick- gen sowie -Aufwände in der PM-Lehre mit über 350 lungsprojekte angewendet werden. Dies erscheint Studierenden. auch aufgrund der großen Abhängigkeiten zwi- Abstract schen Projektmanagement, Erfahrung in der Soft- Since the academic year 2003, the module "Pro- wareentwicklung und Projekterfolg als zu riskant. ject Management" (PM) has been offered at the Fac- Der Beitrag beschreibt die Entwicklung des ulty of Computer Science and Engineering of the grundsätzlichen Lehr-/ Lern-Arrangements, also der Technical University of Cologne (until 09/2015 FH Lehr-, Hausarbeits- und Prüfungsformate des Mo- Köln) for all computer science courses. Particular duls Projektmanagement von eher inhaltsorientier- challenges are the increasing number of students ten "Single-Teacher"-Veranstaltungen pro Studien- since 2012 and the content and structural differences gang hin zu einer gemeinsamen kompetenzorien- in the curricula of the four participating Bachelor tierten "Team-Teaching"-Veranstaltung für alle Stu- programs. In addition, there are several reasons why diengänge, den didaktischen Hintergrund und die PM is not applied directly to a real-world (student) Lehr -Erfahrungen sowie -Aufwände in der Projekt- software development project. management-Lehre mit über 350 Studierenden. This article describes the development of the basic teaching / learning arrangement of PM to- Historie und Inhalte wards a competence-oriented "Team Teaching" Im Sommersemester 2003 wurde PM im 6. Semester event for all study programs, the didactic back- des damaligen Diplom-Studiengangs „Allgemeine ground, and the teaching experience and efforts in Informatik“ der FH Köln erstmals vom Autor und PM teaching with more than 350 students. einer Mitarbeiterin1 durchgeführt. Die Veranstal- tung war im damaligen Curriculum mit 2 SWS Vor- Kurze Vorstellung lesung und 2 SWS Praktikum verankert. Teilgenom- Ziel des Moduls "Projektmanagement" (PM, 5 ECTS men haben 53 Studierende. CP) ist die Befähigung der Studierenden, die grund- ______1 legenden Aufgaben des PMs, insbesondere in IT- Im Folgenden meint „wir“ die an PM beteiligten Kolle- Projekten, zu charakterisieren und durchzuführen. gen und Mitarbeiterinnen sowie Mitarbeiter.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 44 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Einführung und Überblick, 1. Vorlesung: 20.03.2003 Organisatorische Aspekte der Vorlesung und insbesondere des Praktikums (Einteilung der Studierenden in- Teams). Danach werden Definitionen zentraler Begriffe wie „(Software-) Projekt“ und „Management“ erar- beitet und ein Überblick über die Aktivitäten beim Management von Softwareprojekten – und damit den weiteren Inhalt der Vorlesung – gegeben. Die „menschliche Komponente“ 2. Vorlesung: 27.03.2003 Gegenstand dieser Vorlesung sind die – nicht nur für Softwareprojekte – zentralen Fragen der Team Bildung, der Zusammenarbeit im Team und der Motivation von Kollegen und Mitarbeitern. Grundlegende für diese Fragen ist, die Individualität der Menschen anzuerkennen, ihre Stärken zu nutzen und mit den Schwächen umzugehen. Da hierzu die “richtige“ Kommunikation wesentlich ist, werden zunächst Kommunikationsmo- delle und -muster vorgestellt. Darauf – und auf dem Phänomen “Motivation“ – aufbauend werden typische Merkmale der Gruppenbildung erläutert und Hinweise zum Krisenmanagement gegeben. Kosten/Nutzen-Analysen und Entscheidungstechniken3. Vorlesung: 03.04.2003 Diese Vorlesung betrachtet Kosten/Nutzen-Analysen und Entscheidungstechniken für Softwareprojekte. Den Ausgangspunkt bildet eine Klassifikation der Kosten- und der Nutzenarten. Ein besonderes Augenmerk liegt hierbei auf der Differenzierung in quantifizierbare und nicht quantifizierbare Kosten- und insbesondere Nut- zenarten sowie auf dem Aspekt der Unsicherheit der Plandaten. Anschließend werden statische Verfahren der Investitionsrechnung auf Investitionen in Software angewendet. Zur Einbeziehung nicht-monetärer Ent- scheidungskriterien runden eine Einführung in ein Entscheidungsmodell sowie Entscheidungstechniken wie z.B. die Nutzwertanalyse unter Sicherheit, Risiko und Unsicherheit diese Vorlesung ab. Organisation 4. Vorlesung: 10.04.2003 Aufbauorganisation, 5. Vorlesung: 17.04.2003 Ablauforganisation Bei der Projektorganisation geht es zum einen um die Aufbauorganisation, bei der die Integration des Projekts in das Unternehmen und die projektinterne Aufbauorganisation unterschieden wird. Andererseits wird die Ablauforganisation im Rahmen von Softwareprojekten in der Regel durch Vorgehensmodelle beschrieben. Wir skizzieren “klassische“ Vorgehensmodelle, bei denen die Aktivitäten in strenger Reihenfolge jeweils voll- ständig durchgeführt werden, als auch modernere Vertreter, die iterativ vorgehen und das Produkt in kleinen Schritten – sozusagen inkrementell – entwickeln. Aufwandsschätzung 6. Vorlesung: 08.05.2003 Projektumfang 7. Vorlesung: 15.05.2003 Entwicklungszeit Als Grundlage der Projekt-Durchführungsentscheidung sowie -Planung betrachten wir in diesen Vorlesun- gen Verfahren zur Aufwandsschätzung für Software-Entwicklungsprojekte. Ziel ist zum einen, konkrete Zah- len zu liefern und zum anderen, eine fundierte Ressourcenplanung für das Projekt zu ermöglichen. Nach einfachen Verfahren wie der Prozentsatzmethode gehen wir auf die Function-Point-Analyse zur Schätzung der Produktkomplexität anhand der im Lastenheft skizzierten Produktanforderungen ein. Es folgt das COCOMO- Verfahren zur Abschätzung der Entwicklungszeit anhand des - vorher zu schätzenden – Produktumfangs. Planung und Risikomanagement 8. Vorlesung: 22.05.2003 Projektplanung I 9. Vorlesung: 05.06.2003 Projektpla- nung II 10. Vorlesung: 12.06.2003 Risikomanagement Inhalt dieser Vorlesungen sind die detaillierte Projektplanung und das Risikomanagement für Softwarepro- jekte. Für die Projektplanung werden u.A. die Verfahren der Netzplantechnik und ihre Anwendung in einem Software-Entwicklungsprojekt behandelt. Grundlage ist die vorgangsorientierte Zeit- und Ressourcenpla- nung. Risiken verbleiben auch bei bester Planung - im Rahmen des Risikomanagements versucht man, die wichtigsten Risiken zu identifizieren, zu priorisieren und Möglichkeiten zu ihrer Beherrschung zu finden. Controlling und Abschluss 11. Vorlesung: 26.06.2003 Projektcontrolling und Projektabschluss Im Hinblick auf die Steuerung und das Controlling von Softwareprojekten besprechen wir Möglichkeiten, die Zeit- und Ressourcenplanung auf aktuelle Planabweichungen anzupassen. Dabei betrachten wir auch den Einsatz von Kennzahlen und das Berichtswesen. Im letzten Teil befassen wir uns mit dem für die „lernende Organisation“ wichtigen Projektabschluss. Querschnittsthemen 12. Vorlesung: 03.07.2003 Diese Vorlesung widmet sich den ergänzenden Bereichen Dokumentation sowie Versions- und Konfigurati- onsmanagement. Einige Aspekte der Mitarbeiterführung wie die Einstellung neuer Projektmitarbeiter sowie die Personalentwicklung runden die Vorlesung ab.

Abb. 1 PM-Inhalte (Auszüge aus dem Skript des Autors von 2003)

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 45 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Die Inhalte der Vorlesungen orientierten sich an ver- Die Teilnehmerzahlen seit Wintersemester breiteten Lehrbüchern wie z.B. (Feyhl & Feyhl 1996), 2010/2011 zeigt die Tabelle 1. (Balzert 1998), (Grupp 1998) und (Friedlein 2003) sowie den Lerneinheiten zum Fernstudienkurs „Ma- Semester Studierende nagement von Softwareprojekten“ der FernUniver- 2010/11 143 sität Hagen (Henrich, 2001). Im Praktikum wurden diese an einem vorgegebenen Fallbeispiel angewen- 2011/12 102 det (s.U.). Im Laufe der Jahre wurden immer wieder 2012/13 150 aktuellere Werke wie z.B. (Aichele, 2014), (Broy & Kuhrmann, 2013) und (Kerzner, 2009) einbezogen. 2013/14 182 In Abb. 1 sind die in den wöchentlichen Frontalvor- 2014/15 303 lesungen behandelten Themenbereiche skizziert 2015/16 261 (Auszüge aus dem Skript des Autors von 2003). 2016/17 263 Bereits im Sommersemester 2004 wurde die Veran- 2017/18 359 staltung von zwei weiteren Lehrenden parallel auch in den beiden Studiengängen „Medieninformatik“ 2018/19 286 und „Technische Informatik“ durchgeführt. Aus den drei beteiligten Studiengängen nahmen insge- Tabelle 1 PM Teilnehmerzahlen seit 2010 samt 164 Studierende teil. Ab 2006 waren alle Studiengänge auf das Ba- chelor-Modell umgestellt. Die Straffung der Curri- Entwicklung des Lehr-/Lernarrange- cula auf 6 Semester führte auch zu einer Vereinheit- ments lichung der Studienverlaufspläne, mit einem fast Entwicklungsphase I: Inhaltsorientierung und identischen „Stamm“ in den ersten beiden Semes- Single-Teacher-Setting tern und spezialisierenden „Ästen“ in den Semes- Die erste Durchführung von PM im Sommersemes- tern 3-6. PM war nun in allen Bachelor-Curricula im ter 2003 für den Diplom-Studiengang „Allgemeine 5. Semester mit 5 ECTS-Punkten angesiedelt, nach Informatik“ erfolgte durch den Autor im "Single- wie vor mit 2 SWS Vorlesung und 2 SWS Praktikum. Teacher"- Lehr-/ Lern-Arrangement. Über die ge- Mit der ersten Reakkreditierung der Studien- samte Vorlesungszeit wurden die Inhalte der in gänge im Jahr 2012 erfolgte eine Differenzierung der Abb. 1 skizzierten Frontalvorlesungen im Prakti- Studienverlaufspläne: PM blieb in drei Bachelor- kum in praktischen Übungen vertieft und in einer Curricula im 5. Semester, in einem (Wirtschaftsin- Klausur „abgeprüft“. formatik) jedoch nun im 3. Semester. Der studenti- Dazu bildeten die Studierenden Teams mit 6 sche Aufwand betrug weiterhin 5 ECTS-Punkte, wie Team-Mitgliedern, in denen Sie die Übungsaufga- zuvor mit 2 SWS Vorlesung und 2 SWS Praktikum. ben bearbeiteten. Jede Aufgabe erforderte die An- wendung einer bestimmten Technik auf einen vor- Studierendenzahlen gegebenen Projektgegenstand. Grundlage bildete Nachdem im Sommer 2004 noch 164 Studie- ein vom Autor erstelltes Lastenheft für eine Anwen- rende aus den vier Studiengängen teilgenommen dung zur Seminarverwaltung, angelehnt an das be- haben, nahm deren Zahl in den darauffolgenden kannte Fallbeispiel aus (Balzert, 1996). Durch eine Jahren tw. aufgrund der Erhebung von Studienge- inhaltliche Verzahnung der Aufgaben über den Pro- bühren in NRW bis 2009 tendenziell eher ab. Begin- jektgegenstand wurde angestrebt, die Planungs- nend mit dem Studienjahr 2010 führten die Ausset- und Überwachungstätigkeiten im Projektmanage- zung der allg. Wehrpflicht zum 1. Juli 2011, die Ab- ment realitätsnah abzubilden. schaffung der Studiengebühren in NRW zum Win- Abnahmen der Lösungen zu den Übungsaufga- tersemester 2011/12 sowie der „Doppel-Abiturjahr- ben inklusive formativem Feedback der Projekter- gang“ im Jahr 2013 (inkl. Hochschulpakt NRW) zu gebnisse erfolgten im 2-wöchigen Rhythmus durch einem stark ansteigenden Trend der Zahlen, der sich den Autor und eine Mitarbeiterin. seitdem fortsetzt und nun um ein Plateau von ca. 300 Studierenden pendelt. Spitzenreiter war das Winter- semester 2017/18 mit 359 Studierenden.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 46 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Das summative Feedback – also die Modulprü- Projektgegenstand geplant und auch durchge- fung – erfolgte in Form einer 120-minütigen Klau- führt und gesteuert werden müssen (während sur. Neben einigen Wissensfragen mussten die Stu- die Arbeitspakete für den vorgegebenen Pro- dierenden 3 bis 4 „konstruktive“ Aufgaben z.B. zur jektgegenstand in PM nur geplant, aber nicht ge- Nutzwert-Analyse, Aufwandschätzung mit Func- steuert und durchgeführt werden müssen). tion-Point-Analyse oder Netzplanung bearbeiten (s. • Last but not least waren viele Studierende nicht Abb. 2). wirklich motiviert dabei, da die vorgegebene Aufgabenstellung (Anwendung zur Seminar- verwaltung, s.O.) eher angestaubt, akademisch und fachlich sowie technisch uninteressant er- schien. Ein erstes Brainstorming konzentrierte sich auf den Projektgegenstand. Schnell kam die Frage auf, warum wir in PM nicht ein wirkliches Studierenden- projekt planen und dann tatsächlich auch durchfüh- ren lassen? Dagegen sprach, dass im Rahmen der 5 ects cp zusätzlich zum Erlernen von PM kein noch so bescheidenes „Entwicklungsprojekt“ möglich ist. Eine Verknüpfung von PM mit den im Curriculum verankerten Studien- und Praxisprojekten war nicht in der Breite durchführbar, da viele solcher Projekte in Zusammenarbeit mit externen Projektpartnern Abb. 2 Klausurthemen 2003 durchgeführt werden und eben fundierte PM- Entwicklungsphase II: Realitätsnähe und Team- Kenntnisse bereits voraussetzen. Das Risiko, dass Teaching „Fehlplanungen“ den Projekterfolg gefährden, war uns einfach zu groß2. Unsere Diskussionen vor der ersten parallelen Durchführung von PM ab dem Sommersemester Beschlossen wurde, die Studierenden-Teams im- 2004 in den vier Studiengängen „Allgemeine Infor- merhin einen eigenen Projektgegenstand im Bereich matik“, „Medieninformatik“, „Technische Informa- Softwareentwicklung definieren zu lassen, um da- tik“ und „Wirtschaftsinformatik“ basierten i.W. auf mit die intrinsische Motivation zu fördern. den Eindrücken während der Praktikum-Abnah- Diese und einige weitere Diskussionen zum men und den Ergebnissen der ersten Klausuren. Wir „Team-Setting“ führten schließlich zu folgenden identifizierten folgende Probleme des initialen Lehr- Veränderungen der Praktika: /Lernformates: 1. Die Teams wurden heterogen mit 6 Studie- • Die Studierenden bearbeiteten die Praktikum- renden aus mindestens 3 Studiengängen ge- Aufgaben nicht wirklich als Team, sondern gebildet. Dies sollte die „Diversität“ in der Be- mäß „Teile und Herrsche“ eher in Einzelarbeit. setzung realer Projektteams widerspiegeln. Dadurch wurden Querbezüge in den Aufgaben- 2. Es sind 6 Projektaufgaben zu bearbeiten: stellungen und der Anwendung der Methoden I) Erstellung des Lastenheftes; bzw. Techniken oft nicht erkannt, worunter die II) Aufwandsschätzung; Konsistenz der Lösungen erheblich litt. III) Kosten-/Nutzen-Betrachtung; • Zusätzlich waren viele Studierende „Experten“ IV) Risikomanagement; genau für die PM-Methode bzw. PM-Technik, V) Vorgehensmodell-Tailoring; welche sie selbst im Praktikum aktiv angewen- VI) Zeit- und Ressourcenplanung. det haben, zeigten aber tw. erhebliche Lücken in 3. Für jede dieser 6 Projektaufgaben musste anderen Bereichen. das Team eine Rollenzuteilung festlegen: • Auch wurde vielen Studierenden nicht bewusst, - Ein Projektleiter (PL); dass die Bearbeitung jeder einzelnen Aufgabe - Ein Repräsentant (PR); selbst ein „Mini-Meta-Projekt“ darstellt. „Meta“ - 2-4 Mitarbeiter (Bearbeiter, Recher- in dem Sinne, dass dabei Arbeitspakete für das cheur, Reviewer, …). PM von Arbeitspaketen für den vorgegebenen

2 Dies haben u.A. auch Fleischmann und Spies an den TU’s Darmstadt und München festgestellt. Sie schreiben dazu, „dass die größten Herausforderungen für die beteiligten Studierenden dabei weniger in der Bewältigung technischer oder fachlicher Fragestellungen liegen: Diese Prob- lematik ist ihnen aufgrund ihrer Lernerfahrung im Studienverlauf bereits geläufig. Vielmehr stellt der Umgang mit organisatorischen und sozialen Problemen eine viel größere Herausforderung dar und führt daher oft zu für die Studierenden unvorhergesehenen Problemen im Projekt.“ (Fleisch- mann & Spies, 2005, S. 26)

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 47 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Damit sollte die Bearbeitung der Aufgaben als „Mini-Meta-Projekt“ im Team gefördert Die Studierenden sollen befähigt werden, werden. • die grundlegenden Aufgaben des Projektmana- 4. Jedes Team definierte einen eigenen Projekt- gements, insb. in IT-Projekten, zu charakterisie- gegenstand gemäß der groben Vorgabe, ren und durchzuführen; dass dieser innerhalb vorgegebener Budget- • die Projektmanagement-Methoden, -Techniken (500.000 € bis 1.000.000 €) und Aufwands- und -Werkzeuge zielgerichtet einzusetzen; bzw. Zeit-Grenzen (36 bis 72 PM, 6 bis 12 • die erforderlichen soziologischen und kommuni- Monate) liegt. Dies sollte einerseits die Mo- kativen Aspekte zu berücksichtigen, insb. mit dem tivation der Studierenden steigern und an- Ziel einer menschengerechten und soziologisch dererseits den „Ergebnisaustausch“ zwi- fundierten Menschenführung zur Erreichung einer schen den Teams mindern. wirklichen und optimalen Produktivität bei kom- In einem Team-Teaching-Setting mit drei Lehr-Tan- plexen Projekten. dems aus Kollege und Mitarbeiterin bzw. Mitarbei- Abb. 3 Modulziel von PM 2006 ter wurden die Vorlesungen dann zwar nach wie vor über die gesamte Vorlesungszeit, jetzt aber im Ende 2006 waren dann alle Informatik-Studien- Wechsel von den drei beteiligten Kollegen gehalten. gänge vom Diplom auf den Bachelor umgestellt. Das In dieser Zeit wurde die Bearbeitung der Aufgaben oben genannte Feedback der Studierenden, die Ver- im Praktikum je Team von einem Kollegen und ei- ständigung auf das explizit formulierte Lernziel so- ner Mitarbeiterin oder einem Mitarbeiter betreut. wie unsere zunehmende Erfahrung mit der Ein- Die Bearbeitung der Praktika bestand aus zwei schätzung und Bewertung der von den Studieren- Teilen: den im Team erzielten Praktikum Ergebnisse und 1. Jedes Team erstellte jeweils unter der Pro- Präsentationen ermutigten uns dann ab dem Som- jektleitung eines/einer Studierenden die Ar- mersemester 2007, die Modulnote anhand der tefakte inkl. der Begründung der Vorge- Teamleistung und der individuellen Leistung (als hensweise und Ergebnisse zu jeder der Auf- PL und PR) im Praktikum und im Abschluss-Kollo- gaben I) bis VI); quium zu ermitteln. (Inhaltlich wurde 2007 das bis 2. In einem Abschluss-Kolloquium präsentier- dahin für die Ablaufplanung verwendete V-Modell ten die Team-Mitglieder nacheinander in je- 97 durch den Nachfolger V-Modell XT ersetzt.) weils 5 Minuten die Ergebnisse einer der Zur besseren Einschätzung der Teamleistung sechs Aufgaben, wobei einige Verständnis- musste nun jedes Team zu den Aufgaben neben den fragen gestellt wurden. Bearbeitungsergebnissen auch Protokolle abgegeben. Diese sollten das Zustandekommen der jeweili- Die selbstdefinierten Projektgegenstände waren in gen Ergebnisse im Vorfeld der Präsentation doku- der Regel reine Softwareentwicklungen (z.B. Park- mentieren, insbesondere Informationen zur Team- platz-Reservierung im Web, Client-/Server-Anwen- /Rollenaufteilung, zur Bearbeitung der Aufgaben dung zur Raumreservierung) und nur einige wenige (evtl. mit den jeweiligen Teilschritten) und zum je- HW/SW-Systementwicklungen. Die Motivation der weiligen Arbeitsfortschritt. Auch für ein angemesse- Studierenden stieg durch den selbstgewählten Pro- nes Layout der Protokolle war zu sorgen. jektgegenstand merklich, wobei die Präzisierung Die gesamte Bewertung der einzelnen Studie- der Projektvision durch das Lastenheft für viele renden ergab sich zum einen aus der Bewertung der „Aha-Momente“ bzgl. unterschiedlicher Interpreta- Dokumentation zu der als PL bearbeiteten Aufgabe tionen der Projektidee sorgte. Die Modulnote ergab (Hausarbeit). Es wurden jedoch im Verlaufe des sich weiterhin alleine aus einer Klausur. Praktikums durch die Präsentationen, die Protokolle Ein wesentlicher Punkt des eingeholten Feed- und in den Fragerunden „Punkte“ gesammelt, die backs der Studierenden war der Wunsch, die team- sich positiv in der Gesamtbewertung niederschlu- basierten Leistungen bei der Bearbeitung der Pro- gen. jektaufgaben auch in die summative Bewertung, Insgesamt wählten wir folgende Gewichtung also die Modulnote einließen zu lassen. der einzelnen Prüfungsbestandteile: Entwicklungsphase III: Lernziel-Orientierung und • Dokument (Hausarbeit) 40 Punkte. veranstaltungsbegleitende Prüfungsformate • Präsentation und Fragen 40 Punkte Im Rahmen der Umstellung auf das Bachelor-Mo- • Protokolle/Teamleistung 20 Punkte dell wurde erstmals eine Modulbeschreibung mit Die Bewertung der Dokumente erfolgte separat für den Lernzielen bzw. den „von den Studierenden zu jedes Team alleine durch den Kollegen im betreuen- erlangenden Kompetenzen“ gefordert. Das von uns den Lehr-Tandem. Dies bedeutete für jeden von uns formulierte Modulziel zeigt Abb. 3. drei Kollegen die Bewertung der im Praktikum er-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 48 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln stellten Arbeitsergebnisse, begründenden Doku- der Bepunktung der Protokolle wurde das in den mente sowie Protokollen von ca. 10 Praktikum- Protokollen beschriebene Vorgehen des Teams inkl. Teams. Teilaufgaben-Zuteilung, Zeitplanung und „Kon- Die Präsentationen der Studierenden fanden ge- fliktlösungen“ gewertet. blockt an drei Tagen am Ende der Vorlesungszeit In diesem Lehr-/Lernarrangement wurde die statt und wurden pro Team separat vom Kollegen Veranstaltung dann mehrfach durchgeführt. Das und der Mitarbeiterin bzw. dem Mitarbeiter des be- Feedback der Studierenden war durchaus positiv, treuenden Lehr-Tandems bewertet. allerdings wurden insbesondere unsere Mitarbeite- Zum Schluss wurden die Bewertungen zusam- rinnen und Mitarbeiter von einzelnen Studierenden mengeführt und ergaben die Modulnote. Die hierbei „hinter vorgehaltener Hand“ auf die teilweise eher unvermeidlichen Unterschiede in den subjektiven „gefühlte“, tw. aber auch nachvollziehbare Diskre- Einschätzungen wurden durch das in Tabelle 2 ge- panz der Benotungen durch die drei Lehr-Tandems zeigte Gesamt-Bewertungsschema für die Projekter- hingewiesen. gebnisse sowie eine grobe Kriterienliste für die Prä- sentationen und Fragen (Tabelle 3) abgemildert. Bei

Tabelle 2 Gesamt-Bewertungsschema SoSe 2007

Fragen Stil A____F____: ______Rede: Sicher / Flüssig / Stockend / Zum Zuhörer / Unterhaltsam A____F____: ______Inhalt: Vollständig + Richtig / Sachkundig / Überlegt / tw. falsch A____F____: ______A____F____: ______Sprache: Fachsprachlich / Teils-Teils / Umgangssprachlich A____F____: ______A____F____: ______Dialog: Geht auf Fragen ein / Weicht aus / Chaotisch A____F____: ______

Tabelle 3 Bewertungsschema Präsentation und Fragen SoSe 2007

Im Rahmen der 2009 beginnenden Vorbereitungen Wir präzisierten zunächst unsere bis dahin nur der Reakkreditierung der Studiengänge stand zu- implizit im Lehr-/Lern-Arrangement vorhandenen nächst die Lernzielorientierung der Curricula im Ansätze zur Erreichung der Lernziele von PM. Vordergrund. Insbesondere hatten wir Probleme, Schnell wurde klar, dass die bislang von den Lehr- mit den „herkömmlichen“, eher inhaltsorientierten Tandems unterschiedliche Handhabung der Veran- Beschreibungsmitteln begründet die übergeordne- staltungs-Bestandteile vereinheitlicht und den Stu- ten Lernziele (learning outcomes, vgl. Thurner & dierenden explizit zu Beginn des Semesters verdeut- Böttcher et al. 2015) der Studiengänge auf deren licht werden muss. Curricula herunter zu brechen bzw. deren Erfüllung Die erste Veränderung bestand somit in einer ex- (oder Erfüllbarkeit) aus den Lernzielen der einzel- pliziten Formulierung der Modalitäten für die ver- nen Module abzuleiten. Dies erforderte eine erneute anstaltungsbegleitenden Prüfungsformate in Form Fokussierung auf die für PM formulierten Lernziele.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 49 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln eines „Lehr-/Lern-Vertrages“ (Abb. 4). Das (posi- In den beiden darauffolgenden Semestern be- tive) Feedback der Studierenden hierzu ergab sich wertete daher jedes Lehr-Tandem zwei unmittelbar implizit dadurch, dass die Abgabe-Meilensteine zu aufeinanderfolgende Aufgaben. Daraus ergab sich den Projektaufgaben von deutlich weniger Projekt- eine deutlichere, jeweils nach einem Drittel der Vor- leitungen „gerissen“ wurde wie in den früheren Se- lesungszeit geblockte „Prüfungsbelastung“. Auch mestern. bei dieser Aufteilung war für die beiden Lehr-Teams Die zweite Veränderung betraf die Bewertung zu den Aufgaben 3 und 4 bzw. 5 und 6 ein Einblick der Dokumente aus den Aufgabenlösungen der in die davorliegenden Aufgabenlösungen der Teams. Hier versuchten wir, durch unterschiedliche Teams notwendig. Zuteilungen der Aufgaben zu den Lehr-Tandems zu Die dritte Veränderung führte zu einer Entzer- einer gleichen Bewertung aller Teams zu gelangen. rung der Präsentationstermine, die nun nicht mehr Zunächst erstellten wir zur möglichst objektiven geblockt am Ende der Vorlesungszeit, sondern ge- Bewertung der Aufgabenlösungen feingranulare blockt nur noch für jeweils zwei Aufgaben nach der „Controlling“ Bewertungsformulare. Dann teilten Meilenstein-Abgabe zu den Projektaufgaben er- wir die Aufgabenlösungen aller Teams abwechselnd folgte. Dadurch wurde eine zeitnahe „Prüfung“ der jeweils einem den Lehr-Tandems zu, so dass z.B. erreichten Kenntnisse möglich, allerdings auf Kos- Lehr-Tandem A die Aufgaben 1 und 3 bewertete. ten einer gewissen „Ungleichbehandlung“ der Stu- Die „Lücke“ zwischen den beiden zu bewertenden dierenden, da ja die Repräsentanten der ersten bei- Aufgabenstellungen und die bereits genannten Ab- den Aufgaben nicht auf Erfahrungen aus vorherigen hängigkeiten erforderten jedoch bei der Bewertung Präsentationsterminen aufbauen konnten. der zweiten Aufgabe auch eine nähere Ansicht der Lösung zur unmittelbar davorliegenden Aufgabe.

Hausarbeit (Dokumentation der Ergebnisse einer Aufgabe) Zu den 6 Aufgaben muss das Team eine Dokumentation (Hausarbeit) erstellen. Für die Erstellung der Dokumentation ist dasje- nige Teammitglied verantwortlich, das für die jeweilige Aufgabe die Rolle Projektleiter ausfüllt. Es muss in der Rolle des Projekt- leiters dafür sorgen, dass das Team ihm bei der Erstellung der Dokumentation tatkräftig zur Seite steht und die richtigen Teil- aufgaben jeweils an die anderen Teammitglieder verteilen. In diesem Sinne ist jeder aus dem Team für eine Aufgabe als „Pro- jektleiter“ verantwortlich und muss deren Ergebnisse in einer Hausarbeit dokumentieren. Auf dem Weg bis zur endgültigen Abgabe der Hausarbeiten müssen die Ergebnisse in insgesamt 3 Abnahmeterminen präsentiert werden. Hierzu wird jedes Teammitglied die Ergebnisse einer Aufgabe bei der er/sie nicht die Rolle Projektleiter spielt, in der Rolle als Repräsentant präsentieren. Die 6 Dokumentationen werden dann zum 3. Abnahmetermin abgegeben. Abnahmen der Praktika Die Projektergebnisse werden zu je zwei Aufgaben in insgesamt 3 Abnahmeterminen (siehe Terminplan) vor den verantwortli- chen Professoren präsentiert und das gesamte Team muss sich einer Reihe von Fragen hierzu stellen. Präsentation der Ergebnisse durch Repräsentanten In den Abnahmeterminen sind die Ergebnisse zu den beiden jeweils betroffenen Aufgaben zu präsentieren. Bei der Präsentation zu einer Aufgabe stellt ein Repräsentant (nicht der Projektleiter selber) die Ergebnisse zur Aufgabe anhand einiger Folien in genau 5 Minuten vor. Fragerunde Nach der Präsentation zu den beiden Aufgaben wird in einer ca. 20 minütigen Fragerunde das gesamte Team mit einer Reihe von Fragen zu den beiden Aufgaben konfrontiert und die einzeln befragten Teammitglieder müssen diese beantworten. Protokolle Zusätzlich müssen vom Team zu den beiden in der Abnahme zu präsentierenden Aufgaben und zu den zugehörigen Einstim- mungsaufgaben Protokolle abgegeben werden, die das Zustandekommen der jeweiligen Ergebnisse im Vorfeld der Präsentation dokumentieren. Die Protokolle enthalten insbesondere Informationen zur Team-/Rollenaufteilung, zur Bearbeitung der Aufga- ben (evtl. mit den jeweiligen Teilschritten) und dokumentieren den jeweiligen Arbeitsfortschritt. Auch für ein angemessenes Layout der Protokolle ist zu sorgen. Abgabe der Hausarbeiten eine Woche nach der 3. Abnahme Die dokumentierten Endergebnisse zu allen 6 Aufgaben werden dem jeweiligen Prüfer eine Woche nach dem 3. Abnahmetermin als ausgedrucktes finales Dokument übergeben.

Abb. 4 Explizite Veranstaltungsmodalitäten ab WiSe 2010/11

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 50 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Entwicklungsphase IV: Kompetenzorientierung Kompetenzbegriff sein, welcher folgende Punkte umfasst (Reis 2010): Im Rahmen seiner hochschuldidaktischen Weiter- • Die wissenschaftliche Modellierung komplexer bildung zum Fakultäts- Multiplikator für kompe- Anforderungskontexte (Kenntnisse, Fertigkeit, tenzorientierte Prüfungen im Sommer 2014 konnte Fähigkeit); der Autor die bisherigen Ansätze und Erfahrungen • Die Erschaffung und Gestaltung innovativer im Modul PM reflektieren. Konzepte und Problemlösungen; Die Kompetenzorientierung ist ein wichtiges • Die anschlussfähige Kommunikation von wis- Mittel, Lehre und Prüfung voneinander zu trennen senschaftlichen Wissensbeständen, Konzepten und gleichzeitig sowohl Lehre als auch Prüfungen und Methoden; zielgerichtet, effektiv, transparent, valide und zu- • Die Selbstregulation und Reflexion des eigenen verlässig zu gestalten. Abb. 5 zeigt den damit entste- problemlösungs- und erkenntnisgeleiteten Han- henden Dreiklang von Lernziel, Lehr-/Lern-Arran- delns. gement und Prüfungsform(en) nach (Biggs & Tang, 2011). Nach Meinung des Autors wurde seinerzeit insbes. Insbesondere bei Lernzielen auf höheren kogni- im Fachhochschulbereich der Bereich der Kennt- tiven Stufen, wie sie ja in PM erreicht werden sollen, nisse, Fähigkeiten und Fertigkeiten inhaltlicher Art bietet die Kompetenzorientierung einen begründe- immer noch überbetont, es zählte „der Stoff“. Hier ten Handlungsrahmen, in dem sich auch genügend möchte der Autor dazu beitragen, auch die weiteren Spielraum für die individuelle Ausgestaltung findet. Anteile des akademischen Kompetenzbegriffes an- Für projektorientierte SE-Lehrveranstaltungen zei- gemessen mit in die Gestaltung der Curricula sowie gen dies z.B. (Böttcher & Thurner 2011 und Hum- der einzelnen Module der Informatik einzubringen. mel, 2013). Ein weiteres Argument gegen die Kompetenzor- ientierung zielt gerade vor dem Hintergrund hoher Lernziele Studierendenzahlen auf die ökonomische (Durch- führungs-)Ebene. Gerade in Grundlagenveranstal- tungen werden Lernziele oft rein auf Inhaltsebene bzw. auf den „unteren Taxonomiestufen“ (Ander- son & Krathwohl 2001) formuliert. Die Pragmatik, also das „Warum bzw. Wofür“ wird außer Acht gelassen, da berufsfeldnahe Beispiele oder Probleme Lehr-/Lern-Arrangement Prüfungsform(en) als zu komplex erachtet werden. In Prüfungen (i.d.R. Klausuren) werden dann eher Wissens-, Ver- Abb. 5 Constructive Alignment ständnis- und algorithmisch lösbare Handlungsfra- gen gestellt, die eine fest umrissene „Musterlösung“ Gegen die Kompetenzorientierung wird oft da- und damit eine „objektive“ Aus- und Bewertung er- hingehend argumentiert, dass es i.S. der Freiheit von möglichen. Forschung und Lehre nicht in erster Linie darum ge- Hier ermuntert der Autor dazu, zunächst einmal hen kann, „berufsfähige“ Absolventen zu „produ- die Lernziele der eigenen Veranstaltung ehrlich, mit zieren“. Diese Argumentation greift m.E. zu kurz, hoher Formulierungsqualität, nach dem Dreiklang da hierbei der Begriff Kompetenz i.d.R. nur i.S.d. Be- „Was, Womit, Wozu?“ und taxonomisch eindeutig rufsbildungsforschung gesehen wird2. Kurz gefasst zu formulieren. Wenn diese eben tatsächlich nur auf meint Kompetenz hier genau solche Fähigkeiten den „unteren Kompetenzstufen“ liegen und das so und Fertigkeiten, die in der heutigen industriellen ausreichend auf die curricularen Lernziele „ein- bzw. beruflichen Praxis gefordert werden. zahlt“, ist es OK. Sollen aber auch Lernziele auf hö- Darüber hinaus werden oft kommunikative und herer Taxonomiestufe erreicht werden, muss oft der reflexive Fähigkeiten sowie „höhere“ Fähigkeiten Stoffumfang gekürzt und auf andere Lehr- und wie evaluieren und synthetisieren nicht betrachtet. Prüfmethoden zurückgegriffen werden. Hierzu sollte man sich §2 (1) des HRG vor Augen Im Sinne des „Constructive Alignment“ unter- halten: „Die Hochschulen […] bereiten auf berufli- suchten wir zunächst, ob sowohl die Lehrveranstal- che Tätigkeiten vor, die die Anwendung wissen- tung als auch die Prüfung(en) konsequent auf die zu schaftlicher Erkenntnisse und wissenschaftlicher erreichenden Lernziele hin ausgerichtet sind. Insbe- Methoden oder die Fähigkeit zu künstlerischer Ge- sondere bei der Bewertung der Aufgabenlösungen staltung erfordern.“ Grundlage der Kompetenzori- entierung in der Hochschule sollte der akademische

2 S. A. die aktuelle Kritik an der Kompetenzorientierung in der gymnasialen Oberstufe und der zentralen Abiturprüfung in (Weiss & Kaenders, 2018).

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 51 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln und der Präsentationen konnten wir deutlichen Ver- werden. Im Rahmen der Aufgabe zur Vorgehens- besserungsbedarf ausmachen. modellierung müssen die Studierenden im Kontext Hier wurde die bisherige, eher feingranulare ihres Projektgegenstandes diskutieren, ob das von und quantitative Bewertung der Aufgabenlösungen ihnen „zugeschneiderte“ V-Modell XT oder ein agi- zu Gunsten eines gröberen Bewertungsrasters auf- les Vorgehen zielführender erscheint. gegeben (Tabelle 5). Das zu grobe Bewertungsraster Letztendlich führten wir, um die Inhaltsvalidität für die Präsentationen inklusive der zu erstellenden der Prüfung zu erhöhen, ab dem Wintersemester Präsentationsfolien hingegen verfeinerten wir zu 2016/17 einen einstündigen Wissenstest ein, in dem dem in Tabelle 6 gezeigten fünfstufigen Raster. die erlangten Kenntnisse und (Technik-)Fertigkeiten Mit diesen Handreichungen erfolgt seitdem die der Studierenden „in der Breite“ beobachten. Hier Bewertung in den zwei Schritten 1.) Beobachten und verwenden wir das MC-Format als effektives Prü- 2.) Bewerten (vgl. Szczyrba, Wildt & Dany 2008). Die fungsformat für Kenntnisse und Fertigkeiten bis zur Benotung wird seitdem von den Studierenden als vierten kognitiven Ebene des Wissenserwerbs objektiver und nachvollziehbarer angesehen. („Analysieren“, s. Anderson & Krathwohl et al. Als weitere Änderung wurden die Präsentati- 2001, Miller, Linn & Gronlund 2008). onstermine wieder am Ende des Semesters geblockt, Tabelle 4 fasst die Entwicklung des Moduls PM von so dass alle Studierenden auch für diesen Prüfungs- 2003 bis heute zusammen. teil die gleichen Voraussetzungen haben. Inhaltlich haben wir insbesondere bei der Ab- lauforganisation die agilen Vorgehensweisen einbezogen, da diese in der Praxis zunehmend eingesetzt

Entwicklungsphase Auslöser Lehr-/Lernarrangement Prüfungsform I.) 2003: Inhaltsorientierung Erste PM-Veranstaltung Single-Teacher, Praktikum Klausur und Single-Teacher-Setting des Autors nach der Beru- eher i.S. von Übungsaufga- fung, Diplomstudiengang ben. „Allgemeine Informatik“ II.) 2004-2006: Realitäts- Gemeinsame PM-Veran- Team-Teaching, Praktikum Klausur nähe und Team-Teaching staltung mit zwei Kollegen mit vorgegebenem Projekt- für alle 4 Informatik-Diplom- gegenstand, studiengangs- Studiengänge der FH Köln übergreifende Teams, Ab- nahme am Ende der Vorle- sungszeit III.) 2007-2014: Lernziel- Umstellung auf Bachelor Team-Teaching, Praktikum Schriftliche Dokumentation Orientierung und veranstal- und Akkreditierung, Formu- mit selbst gewähltem Pro- der Lösung einer Aufgabe, tungsbegleitende Prü- lierung des Lernziels jektgegenstand, studien- Präsentation und mdl. fungsformate gangsübergreifende Kurzprüfung Teams, Meilenstein-Abga- ben und Präsentationen in Protokolle/Teamleistung der Vorlesungszeit IV.) Seit 2015: Kompetenz- Reakkreditierung und neue Team-Teaching, Praktikum Meilenstein-Einhaltung, orientierung Erkenntnisse zu kompe- mit selbst gewähltem Pro- PM-Artefakte tenzorientierter Lehre und jektgegenstand, studien- Präsentation und mdl. Prüfung gangsübergreifende Kurzprüfung, Teams, Meilenstein-Abga- ben und Feedback-Gesprä- MC-Wissenstest che in der Vorlesungszeit, Präsentationen geblockt am Ende der Vorlesungs- zeit

Tabelle 4 Entwicklungsphasen des Moduls Projektmanagement

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 52 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Team 1 4 AT4-AY9 Bewertung! Kriterien- Schlüssel in Komment. bei Aufg.Nr. Projekt auto_lo Living Reality Aufgabe Bewertungskriterien Faktor Kommentar Note Kommentar Note G& 19F& ?Do 1So 1U+ stdN+ G+ 20F+ 3D+ 0S! 3U& stdN+ 0T! Lastenheft 0,5 2,4 2,5 1 10T+ 0FR! 2FR&

Deckbl. unvollst., D in use cases, Personae gut, Fremdp. Unstrukt. Eindruck 0,5 1,7 1,7 sauber. Fremdprod. Fehlen! Abb-Quelle? Lastenheft

Inhalt - 35S, zt sehr ausführlich 2,0 14 S., Seitennum., Links! 2,1 _Lastenheft.pdf Ampelfeedback und Note :-) 2,0 :-) 2,1 (460RFP 50SI 529FP 60PMfp) (212RFP 44SI 231FP 13PMfp)& FPA, CoCoMo 0,5 11KLOC (Cbs CmdOrg Cim)+ 1,8 21KLOCo (Cbs ?Cmd ?Cim)o 2,5 (30PMco 9TDEVc)+ (60PMc 11TDEVc)o 2

Fundiert, FPA u CoCoMo tw. FPA gut, etw. umstdl., Coc basis, Eindruck 0,5 1,3 2,3 Begründung unvollst.; Diff nicht diskutiert Aufwandsschätzung Inhalt - Gut strukturiert 1,5 2,4 Ampelfeedback und Note :-) 1,5 :-| 2,4 (2PdR 8PjR)+ Prio Mit+ NtfP+ RisikoAnalyse 0,5 2,0 (#PdR #PjR) Pri Mit NtfP AE 0,0 4 AE& Fundiert, aber keine RPZ- Eindruck 0,5 Berechnung. Zu wenig 2 Risikomanagement Produktrisiken. Inhalt - knapp 2,0 0,0 Ampelfeedback :-) 2,0 0,0

Tabelle 5 Bewertungsschema Hausarbeiten im WiSe 2017/2018 (Ausschnitt)

PROJEKTMANAGEMENT WS 2017-2018 Bewertungskriterien für Folien und Präsentation

MW 20171114

Bereich Note Kriterien

F Inhalt mangelhaft 5 Inhaltlicher Zusammenhang und Aufgabenbezug nicht erkennbar

Ausreichend 4 Inhaltlicher Zusammenhang und Aufgabenbezug erkennbar, aber implizit

Durch- Inhaltlicher Zusammenhang, Aufgabenbezug und roter Faden erkennbar, Ergebnisse 3 schnittlich werden vermittelt

Über dem Kurze und im Wesentlichen nachvollziehbare Darstellung, Aufgabenstellung und 2

Durchschnitt Ergebnisse werden klar vermittelt

Kreative, jederzeit nachvollziehbare Darstellung von Zielen, Aufgabenstellung und Exzellent 1 Ergebnissen

F Darstellung mangelhaft 5 Themenstellung verfehlt, viele nebensächliche Details

Ausreichend 4 Einige Inhalte erkennbar, ausschweifend oder viel zu kurz

Durch- 3 Erläuterung einiger Ergebnisse und Details schnittlich Über dem Kurze Erläuterung einiger wichtiger, begründet ausgewählter Ergebnisse, 2 Durchschnitt Darstellungsformen korrekt, Details sinnvoll

Prägnante Erläuterung, Begründung und eigene Interpretation der zentralen Exzellent 1 Ergebnisse, Details helfen bei Verständnis

Tabelle 6 Bewertungsschema Präsentation im WiSe 2017/2018 (Ausschnitt)

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 53

Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Abb. 6 Evaluierungsergebnisse aus dem Wintersemester 2016/17 (Ausschnitt)

Wir führen das Modul PM nun seit dem Winterse- Erste Versuche mit SESAM waren zwar ermutigend, mester 2016/17 in der oben beschriebenen kompe- wurden aber eher im „single-player“ Modus in der tenzorientierten Form durch. Einige Ergebnisse der Rolle „Projektleitung“ absolviert und dienten dabei ersten studentischen Evaluierung nach der Umstel- weniger der Sensibilisierung der Studierenden für lung sind in Abb. 6 zusammengefasst. die Arbeit in einem Team. Speziell für den Bereich der Teamarbeit konzi- pieren wir zur Zeit mit einer Kollegin und einem Ausblick Kollegen aus dem Betriebswirtschaftlichen Institut Nach wie vor ist es für die Studierenden schwierig, Gummersbach ein Simulationsspiel zur Einführung sich für das Modul PM in neuen, studiengangsüber- in die Dynamik der Teamarbeit (Stumpf & Thomas greifenden Teams zusammen zu finden und mög- 2003). Hiermit sollen die Studierenden einerseits auf lichst zügig als Team zu arbeiten. die bevorstehende Teamarbeit bei der Bearbeitung Viele Ergebnisse zeigen, dass für das Projektma- der PM-Projektaufgaben vorbereitet werden. Ande- nagement die Simulation von Projekten einen guten rerseits möchten wir sie damit für kritische Team- Einstiegspunkt darstellt (Mandl-Striegnitz, 2001 prozesse in der Praxis sensibilisieren. und die vielen Folgeveröffentlichungen zu SESAM).

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 54 Software-Projektmanagement lernen ohne Projekt Mario Winter, TH Köln

Danksagung Henrich, A. (2001). Management von Softwarepro- jekten. Kurs 1895. Hagen: FernUniversität. Der Autor dankt den Kollegen Holger Günther und Lutz Köhler sowie unseren Mitarbeiterinnen und Hummel, O. (2013). Transparente Bewertung von Mitarbeitern Beate Breiderhoff, Konstantin Dimit- Softwaretechnik-Projekten in der Hochschul- riou, Guido Münster, Alex Maier, Patrick Oden- lehre. Proc. SEUH 11. dpunkt.verlag, Heidel- wald, Beate Otztronsek, Uwe Poborski, Pascal berg. Schönthier und Marc Schwede für die vielen leben- Kerzner, H. (2009). Projekt-Management. Bonn: dig geführten Diskussionen und das konstruktive mitp-Verlag. Miteinander bei der Durchführung und Entwick- Mandl-Striegnitz, P. (2001) Qualifizierte Software- lung unserer Veranstaltung Projektmanagement! Projektmanager durch simulationsbasierte Aus- Wertvolle Unterstützung bei der Umsetzung der bildung. Proc. SEUH 7. dpunkt.verlag, Heidel- kompetenzorientierten Lehre und Prüfungformen berg. (Constructive Alignment) in Phase IV leistete das Zentrum für Lehrentwicklung der TH Köln, insbe- Miller, M. D.; Linn, R. L. & Gronlund, N. E. (2008). sondere Susanne Gotzen, Birgit Sczyrba sowie Oli- Measurement and Assessment in Teaching. ver Reis von der Universität Paderborn während der (10th Edition), New York, Pearson Education Multiplikatoren-Ausbildung zu kompetenzorien- Ltd. tierten Prüfungen. Reis, O. (2010). Kompetenzorientierte Prüfungen – Wer sind sie und wenn ja wie viele? In: Ter- Literatur buyken, G. (Hg.) In Modulen lehren, lernen und prüfen.. Loccum: S. 157-183. Aichele, C. &. S. M. (2014). IT-Projektmanagement. Berlin: Springer Vieweg. Stumpf, S. & Thomas, A. (Hrsg.) (2003) Teamarbeit und Teamentwicklung. Reihe: Psychologie für Anderson, L. W.; Krathwohl, D. R. et al. (2001). A das Personalmanagement - Band 22, Hogrefe, Taxonomy for Learning, Teaching, and As- Göttingen. sessing: A Revision of Bloom's Taxonomy of Ed- ucational Objectives. Complete Edition. New Szczyrba, B.; Wildt, J. & Dany, S. (2008). Prüfungen York, Pearson/Longman. auf die Agenda! Bielefeld, AHD/wbv, Verlag W. Bertelsmann. Balzert, H. (1996). Lehrbuch der Software-Technik (Bd. 1). Software-Entwicklung. 1. Aufl., Spekt- Thurner, V.; Böttcher, A.; et al. (2015): Lernziele für rum-Akademischer Verlag, Heidelberg. die Kompetenzentwicklung auf höheren Taxo- nomiestufen. Proc. SEUH 12. http://ceur- Balzert, H. (1998). Lehrbuch der Software-Technik ws.org/Vol-1332/ (Bd. 2). Software-Management. 1. Aufl., Spek- trum-Akademischer Verlag, Heidelberg. Walzik, S. (2012). Kompetenzorientiert prüfen: Leis- tungsbewertung an der Hochschule in Theorie Biggs, J.; Tang, C. (2011). Teaching for Quality und Praxis, Opladen & Toronto, UTB GmbH. Learning at University. Maidenhead, Open Uni- versity Press/McGraw Hill. Weiss, Y.; Kaenders, R. (2018). Die Kompetenzfalle. Spektrum der Wissenschaft, Ausgabe 9/18, S. 80- Böttcher, A. & Thurner, V. (2011). Kompetenzorien- 85. tierte Lehre im Software Engineering. Proc. SEUH 10. dpunkt.verlag, Heidelberg. Broy, M. & Kuhrmann, M. (2013). Projektorganisa- tion und Management im Software Engineering. Berlin: Springer Vieweg. Feyhl, A. & Feyhl, E. (1996). Management und Con- trolling von Softwareprojekten. Gabler Wirt- schaftsverlag, Wiesbaden. Fleischmann, A. & Spies, K. (2005). Teamtraining für Software-Ingenieure. Proc. SEUH 9. dpunkt.verlag, Heidelberg. Friedlein, A. (2003). Web-Projektmanagement. dpunkt.verlag, Heidelberg. Grupp, B. (1998). Qualifizierung zum Projektleiter: DV-Projektmanagement im Wandel. 4. Auflage, Computerwoche-Verlag, München.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 55 Future Skills: How to strengthen computational thinking in all software project roles

Gudrun Socher*, Sarah Ottinger*, Veronika Thurner*, Ralph Berchtenbreitero *Department of Computer Science and Mathematics | oDepartment of Tourism Munich University of Applied Sciences, <ﬁrstname>.@hm.edu

Abstract like product owners, or user experience designers (see The digital transformation leads to software systems Figure 1), as well as for even more general roles such pervading almost all spheres of private and profes- as product management or project management. sional life. To ensure that these software systems are designed and successfully implemented as needed, intensive collaboration is essential in the key roles in software projects, in particular for the roles of product owner, user experience designer, as well as software engineer. The collaboration of people with usually different levels of IT-savviness requires the appropriate skills of those involved, which are also called Future Skills. Computational thinking is an important skill for everyone involved in software projects, no matter which role they are in. We describe an interdisciplinary tool-based teaching-and-learning program where we build virtual voice-based assistants (voice apps for Amazon Alexa) in interdisciplinary student teams to train computational thinking and collaboration skills. A ﬁrst competency test validates the effectiveness of our approach. Figure 1: Key roles in software projects.

1 Motivation: Future Skills Software products can only be successful if the key In current digitalization initiatives, there is a lot of roles work hand in hand in software projects: prod- discussion on how to increase graduation numbers uct owners with their knowledge of the application in software engineering related study programs in or- domain and product vision, user experience designers der to have more skilled people driving the ongoing who guide human-computer interaction, and software digital transformation. In this discussion, however, engineers being responsible for software implemen- we often forget that digitalization is always related tation. The skills and competencies related to these to an application domain. The digital transformation roles are essential in successful projects. They are beneﬁts strongly if software-related skills are strength- required to successfully meet the challenges of digital ened not only for the core software engineering roles, transformation. but also for less-technical roles in software projects How do we best train the talents for the ongoing digital transformation, and what exactly do future em- 1With ’Future Skills’ we refer to ’competencies’ required by uni- ployees need to learn? Stifterverband, a joint initiative versity graduates across all majors in the coming years. These of German organizations, has published a discussion competencies are necessary to meet digital requirements as they are currently expected in business and society (cf. (Kirchherr et al., paper in September 2018 together with McKinsey & 2018)). Company where they address three core competency

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 56 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Figure 2: Future Skills: Digitalization and new job profiles lead to two challenges for companies. (1) Jobs shift towards IT related profiles. (2) Work processes and work requirements change for the majority of employees. Many employees thus need a modified set of digital and non-digital key competencies (cf. (Kirchherr et al., 2018)). categories driving the digitalization (Kirchherr et al., clude - among others - data literacy, collaborative skills 2018). Figure 2 illustrates competencies related to and digital learning skills. Based on Wing (2006), the digital transformation as well as to new forms of computational thinking can be considered as a pre- work. requisite for digital learning. By now, the relevance With changes in the job portfolios and new forms of all these skills for virtually any member of our of work, there has been an expected shortage of quali- professional work force is undisputed and widely rec- fied people for some time now. In particular, the job ognized. market will be increasingly dominated by job profiles that are heavily related to software engineering. Ac- How can we integrate the development of these cordingly, a lot of effort is spent on increasing the competencies into study programs? Curricula are of- number of graduates of software engineering related ten overfull and the amount of available (and often degree programs, in order to increase the number of essential) knowledge is increasing in almost every software engineers in the market and thus to meet the application domain. Solutions have to be found to growing demand for qualified specialists. systematically integrate key competencies required At the same time, it is essential to strengthen ev- for the digital transformation into the teaching-and- erybody’s digital and non-digital key competencies. learning processes without weakening the core foun- Digitalization is not just an IT issue. Digitalization dation in the respective application domains. is inherently linked to the digital transformation and thus the creation of digital automation or digital assis- Project-based learning is a successful instructional tance systems in an application domain. Therefore, it learning format that has been proven to systematically is just as important for employees and students of all strengthen some of the required future skills (Bell, application domains to acquire software engineering 2010). Interdisciplinary project-based learning is even competencies. more effective, as team diversity is an additional suc- Stifterverband (Kirchherr et al., 2018) stresses that cess factor for creative, goal-oriented collaboration in both digital and non-digital key competencies are a addition to the future skills mentioned above (Digital- must-have for all current students. Key digital skills in- isierung, 2016; Meier et al., 2007).

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 57 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Related work ciplinary student teams. To achieve this, we use a Wing (2006) introduced the importance of compu- tool-chain for creating voice-based virtual assistants tational thinking for computer science-related tasks (such as Amazon Alexa), as well as by using Github. 12 years ago. She defines computational thinking as Over the last years, the usability of many tools for the interplay of decomposition and abstraction and creating software systems has evolved and improved recommends strengthening computational thinking in significantly. Digital tools in the context of software all study programs. engineering are nowadays no longer editors that are The ability of abstract thinking, in turn, has long specifically tailored to computer nerds. Rather, nowa- been recognized as a key competency of many techni- days they often are web-based interactive tools that cal disciplines, especially for computer science (Bucci are fun to use and that guarantee good results even et al., 2001; Kramer, 2007) and software engineer- for people without IT- and software engineering skills. ing (Ghezzi et al., 2002). A distinction is made be- Our student teams include tourism majors and com- tween static and dynamic abstraction, i.e. the abstrac- puter science students. Github is used as a source code tion of structural entities (static) and of processes or repository by computer science students, as well as a behavior (dynamic) (Davis et al., 2014). ticketing and project communication tool for all stu- The central element of computational thinking is a dents. We furthermore use the Github project board problem-oriented (as opposed to a solution-oriented) as a virtual agile board. In this way, we enable all approach (Lorenz and Wurzer, 2014). It is essential to students to make an active, creative contribution in get to the root of a problem or task, to abstract it and a digital software project even without programming to understand contexts and regularities. The goal is to knowledge. reduce the complexity of the task (keyword: decom- The non-IT students (i.e. students of an application position (Wing, 2006)) and to systematically limit the domain) are either in the role of product owner or choice of possible solutions. Only then are potential user experience designer. The role of product owner in- solution components identified and abstracted into cludes gathering and aggregating the users’ needs and an overall behavior. Computational thinking requires desires which requires static abstraction capabilities. not only the ability to decompose, but also the ability The user experience designer role focuses on reflecting to abstract behavior (Wing, 2006), thus requiring a what users expect. This definitely requires consid- very high degree of dynamic abstraction in particular. eration of dynamic processes. In parallel, computer Since algorithms always work on data entities, a cor- science students deepen their experience in the role responding degree of static abstraction is necessary. of software engineer by using new technologies for the In teaching-and-learning practice, it can be ob- implementation of voice-based assistants. served that not all students have a sufficient level We use pseudonymized pre- and post-tests to ana- of abstraction and computational thinking to be able lyze to what extent our interdisciplinary tool-based to cope with the study program requirements. This is teaching-and-learning program actually fosters the ad- especially true for students of subjects related to com- dressed competencies of static and dynamic abstrac- puter science. Accordingly, various approaches have tion in the students. been developed to systematically strengthen these abilities (Hazzan and Kramer, 2007; Böttcher et al., Computational thinking and 2016). These approaches mainly focus on promot- voice-based assistants ing computational thinking in students of computer Voice-based virtual assistants (voice apps) are cur- science related majors, but do not provide teaching- rently being massively pushed by major software com- and-learning concepts for strengthening these skills in panies. Examples are Amazon Alexa, Google Assistant, students of non-technical subjects, where little to no Cortana, and many more. In particular, Amazon and IT-affinity can be expected. Google provide well-designed, web-based tools that developers can use to create new voice apps with their Goals cloud offerings. These tools and cloud offerings are In this work, we develop and apply a teaching-and- available free of charge for educational use. In ad- learning program for promoting computational think- dition, the tools are so sophisticated that it’s fun to ing in students – and, as an essential basis for this, play with them. In just a few minutes, cool voice-user- for fostering students’ static and dynamic abstraction interfaces can be created without previous knowledge, competency. To this end, we develop a teaching-and- so first success can be achieved quickly. Figure 3 shows learning program for interdisciplinary, project-based the Alexa Developer Console, a tool for creating voice learning that addresses computer science students as apps for Amazon Alexa. well as non-IT students. Our concept takes into ac- To develop an application for voice-based assistants, count our students’ prior knowledge as well as their the development team must design the Voice User individual learning requirements. Interface (Voice UI) and implement the business logic. In our teaching-and-learning program, we create A voice UI must be structured in such a way that an easy introduction to digital projects for interdis- the dialogue appears natural to the users. At the

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 58 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Figure 3: Alexa Developer Console: Web-based tool to create voice apps for Amazon Alexa. same time, the dialogue must be designed so that the behavior). This process is rather simple for the joke- goals expressed by the users or the intentions behind of-the-day application (see Figure 5). them can be clearly identified and assigned to the The design of a dialog for a voice-based virtual implemented business logic. In the jargon of voice UIs, assistant is thus well suited to train both static and these intentions are called intents. Each intent must dynamic abstraction skills, and to guide students to- clearly invoke a feature of the implemented business wards computational thinking. Therefore, we use logic. dialog design and implementation for a voice-based Figure 4 shows an example dialog with Alexa for assistant as a task for an interdisciplinary tool-based an application called the "joke-of-the-day". A person teaching-and-learning program to strengthen compu- starts the voice app and gets told one joke. More jokes tational thinking. can be requested. If no more joke is desired, the voice app closes. Structuring a dialogue into intents strengthens both Interdisciplinary project to static and dynamic abstraction abilities. strengthen computational thinking The identification of the individual intents in a dialogue requires a static abstraction. For example, the Our didactic concept for the promotion of computa- joke-of-the-day application is structured into the fol- tional thinking and communicative future skills struc- lowing intents and the resulting dialog steps: tures the learning process into several phases (see Table 1). Initially, the students are taught core con- • welcome cepts in non-interdisciplinary groups. More precisely, the computer science students first • joke learn the technical basics of voice-based assistants, • closing and are introduced to tools for designing and implementing them. Furthermore, computer science stu- The individual dialog steps or intents must then dents learn requirements engineering. Having that be arranged in a meaningful sequence (the dynamic down their belts, these students are well equipped to

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 59 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Task Computer Science Students Students of Application Domain

Introduction to voice- Examples and tutorial for creating a Examples and simulation of dia- based assistants ﬁrst voice app logues between two partners

Idea for voice app and Invocation, intents, slots Generating ideas and deﬁning MVP its structure

Concept for Voice App Requirements engineering Speciﬁcation of a ﬁrst dialogue

Invocable, Alexa Developer Console, Using tools Alexa Developer Console, Github Github

1st Pitch: Students of application domain pitch their ideas to ﬁnd computer science students for their developer team.

1st Sprint 1st Release Reﬁning the dialogues

2nd Sprint 2nd Release Test 1st Release → Change Requests

2nd Pitch: Voice app demos by computer science students.

Test 2nd Release → Final changes and 3rd Sprint 3rd Release improvements

3rd Pitch: Final presentation with guests.

Table 1: Structure of the teaching-and-learning process throughout the semester for our interdisciplinary tool-based teaching-and-learning program for developing Alexa voice apps. take on the role of software engineer in the interdisci- development team. Following these pitches, mixed plinary teams that are formed later on. teams are formed each consisting of computer science The task of the application domain students is to students and students of the application domain. develop an idea for a voice-based assistant (in this Within the interdisciplinary teams, the computer case an Alexa voice app). For this idea, they then science students give feedback to the students of the define the dialogue between the user and the voice- application domain on the design of the dialog that based assistant required for a Minimum Viable Product underlies the respective prototype. Based on this, the (MVP). This dialog thus contains at least those steps voice user interface is subsequently refined together. and procedures that are necessary for the minimal The computer science students take their "natural role" functional implementation of the idea. It is important as software engineer in the interdisciplinary project. to break down the dialogue into short, simple steps The application domain students, on the other hand, and to structure it. The complexity of creating the are both product owner and user experience designer. voice app is significantly greater than the example So they design the interaction between the user and of the "joke-of-the-day" shown in Figure 4. Suitable the voice-based assistant in such a way that this in- ideas for voice apps are (quiz) games, guides, or useful teraction is technically meaningful and needs-based assistants. from their own perspective. So far in our didactic con- The dialogue is tested and tuned by the students cept, user experience design is not explicitly taught of the application domain. Then, using Invocable2, due to lack of time. However, it would be desirable to the students of the application domain create a first improve this in the future. interactive but hard-coded prototype of the voice app. The interdisciplinary collaboration in the teams be- Computer science students implement the back-end, gins when the students of the application domain while students of the application domain are respon- present their ideas to the computer science students. sible for the front-end in the implementation phase The students of the application domain pitch the proof the voice-based assistant. A simple form of Scrum totypes of their voice-based assistants to computer is useful for organizing the development process into science students and try to motivate them to join their sprints, thus structuring the semester process. Github repositories, including the integrated project boards 2Invocable: https://www.invocable.com and the integrated ticketing system (Github issues),

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 60 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Figure 5: Dynamic structure of the example application joke-of-the-day.

Assessing computational thinking skills As we were interested in investigating the develop- Figure 4: An example dialogue with a voice-based ment of our students’ computational thinking skills virtual assistant telling jokes. during the interdisciplinary tool-based teaching- and learning program, students were requested to work on a competency test at the beginning (week 2) and at the end of the semester (week 11). The test covered support team collaboration through an appropriate two facets of computational thinking, namely static tooling infrastructure. and dynamic abstract thinking processes. This teaching-and-learning program was used for The test was taken by two groups of students, all of the first time in the winter semester 2018/19 at Mu- which were working on voice-based virtual assistants nich University of Applied Sciences. Four computer in a project based way. The first group are computer science students (3rd semester) and two to three stu- science students and students of the application do- dents of tourism management (6th semester) form a main who worked together in interdisciplinary teams. mixed team for the pilot run of our program. The other group, our control group, consisted purely of computer science students. Even if static and dynamic abstraction are not ex- All these students were asked to solve two tasks plicitly addressed, all students in this one-semester that both form our competency test and that require interdisciplinary tool-based program train their static static and dynamic abstract thinking processes, re- and dynamic abstraction abilities by structuring and spectively. Using pseudonyms allowed us to match the specifying the dialogue between a person and the students’ pre- and post-tests and thus, to analyze their voice-based assistant in such a way that a correspond- individual learning outcomes. (Regarding the tourism- ing Alexa voice app can be built. All students (in- management students’ test performances, we will dis- cluding application domain students) work with the cuss the results in the next section “Coding scheme Alexa Developer Console and Invocable tools. The use of the abstract thinking test & first results”. The test of tools enables all students to work with a working performances of the computer science students have interactive voice app. The working prototype provides also been analyzed, but will not be presented in this rapid feedback so that in particular the students of paper.) the application domain can immediately check their Our hypothesis is that the computational thinking dialogue structuring. skills of students that actively participated in our inter- From our perspective, this interdisciplinary tool- disciplinary tool-based program increased significantly. based teaching-and-learning setting is well suited to More specifically, we assume that all students benefit foster our students’ abstraction skill and more effective from developing and implementing their innovative in this area than regular class exercises. Furthermore, ideas on Alexa voice apps, as both the design and standardized processes, such as completing Github the creation of voice-user-interfaces require static and Issues in team communication, help to structure col- dynamic abstract thinking processes. Note that even laboration. though we expect that students working in interdisci-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 61 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München plinary teams strongly train their collaboration skills • Criterion S3: presenting categories in a during the course, we have not explicitly assessed structurally-sound way, e. g. as UML-diagrams. theses skills in a test. • The first task of our competency test includes a Criterion S4: using formal notations in a logically menu of 22 different coffee specialties and requests consistent way. the students to teach a new barista about the coffee • Criterion S5: recognizing familiar structures and recipes. The menu contains pictures and ingredient realizing that the structures are coherent in a lists for each coffee specialty. The challenge is to given situation. structure the various coffees and their ingredients in such a way that a new barista can quickly grasp and Dynamic abstract thinking processes are opera- learn them. In the second task, students are asked to tionalized by defining these three criteria: generalize the abstraction process they applied when • Criterion D1: identifying a coherent chain of pro- solving the first task. cesses. To successfully accomplish the second task, the participants first have to become aware of their own • Criterion D2: presenting a coherent chain of pro- actions, identify and structure those processes, and cesses in a structurally sound way. derive a procedure that would be transferable to simi- • Criterion D3: relating the identified chain of pro- lar tasks. Therefore, they have to dynamically abstract cesses to one’s own solution, e. g. using one’s own from their own approaches and accurately document approach as a basis for generalizing and inferring their solutions. From our perspective, task 1 mainly appropriate processes. deals with static abstract thinking processes, whereas task 2 covers dynamic abstract thinking processes. We considered two additional criteria, character- Students are allowed 20 minutes for working on the izing one’s ability for self-reflection as well as meta- first task and 15 minutes for completing the second cognitive thinking skills: task. Once the students begin working on task two, they are not allowed to use the documents they have • Criterion R1: identifying errors and reflecting generated in task one. In winter semester 2018/2019, one’s own approach. 18 tourism students and 54 computer science students • Criterion R2: taking the users’ preferences into participated in the computational thinking compe- account, as well as the requirements. tency test. First results indicate that the computer science Coding scheme of the computational students demonstrate a significantly higher initial level of static abstract thinking skills (mean-value thinking competency test & first M=2.04; standard-derivation SD=0.49), in compar- results ison to the tourism majors (M=1.77; SD=0.46) To analyze the competency test of computational (t=2.119; df=70; p=0.030). thinking skills, a comprehensive coding scheme was Regarding the students’ initial dynamic abstract developed incorporating five criteria to evaluate static thinking skills, we found no statistically significant abstract thinking processes (S1-S5) and three crite- differences between the performances of computer ria to measure dynamic abstract thinking processes science students (M=2.12; SD=0.51) and tourism (D1-D3). We defined two additional criteria opera- students (M=2.28; SD=0.43; whereby U=384.00; tionalizing one’s ability for self-reflection (R1) and for p=0.210). It seems that tourism students have identifying the requirements needed (R2). All crite- reached a slightly higher level of dynamic abstract ria differentiate between four levels of competency thinking skills than computer science students. (outstanding, good, satisfactory, not yet satisfactory). Furthermore, the results indicate that computer sci- Score 1 characterizes the lowest level of competency, ence students (M = 2.07, SD = 0.78) and tourism score 4 the highest one. students (M = 1.81, SD = 0.73) do not differ signifi- We attempted to capture static abstract thinking cantly in their self-reflection skills (U = 384.00, p = processes by evaluating students’ performances along 0.210). We observe only a slight tendency in favor of these four criteria: the computer science students. Overall, the competency test gives some insight that • Criterion S1: developing categories that ideally most of the students – computer science students (3rd simplify the given representations (of coffee spe- semester) as well as tourism students (6th semester) – cialties) and structuring ingredients; struggle with demonstrating their static and dynamic Levels of competency may be described as ’un- abstract thinking skills. According to Wing (2006) refined’, ’put together’, ’structured’ and ’orga- and based on our results, we strongly recommend the nized’ (Hershkowitz et al., 2001). integration of interdisciplinary teaching- and learning- • Criterion S2: identifying and parameterizing at- programs in students’ curricula to foster students’ com- tributes. putational thinking skills.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 62 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München

Regarding students’ reflection skills, it seems to between the students in a purely virtual way, using be important to encourage students to reflect their the cloud-based Alexa Developer Console as well as own approaches and to think about the requirements Github and Github issues. The classroom events where needed. both computer science students and students of the The results of the pre- and post-tests provide empir- application domain are together are the three pitches ical evidence that the tourism students’ static abstract which are highlighted in gray in Table 1, i.e. the thinking skills development can be characterized by pitch of the prototypes by the students of the appli- a significant increase (t = -3.986, p = 0.001) sup- cation domain, the pitch of the voice app demos by porting our hypothesis. After actively participating in the computer science students, and finally the joint the interdisciplinary tool-based teaching-and-learning pitch during the final presentation. A mix of virtual program (M = 2.21, SD = 0.48) the tourism students and physical collaboration creates enough space for score significantly better in terms of their static ab- both teaching and learning sessions to accommodate stract thinking skills than before their participation in the specific contents of the respective modules and this program (M = 1.77, SD = 0.46). The effect size the corresponding competencies according to the defi- by Cohen (1992) is around r = 0.695, thus indicating nition of learning goals. a strong effect. Regarding the tourism students’ dy- The interdisciplinary project was a lot of fun for namic abstract thinking skills, no significant effect can everyone involved. For that reason alone, it is highly be reported (t = -1,475, p = 0.159). However, there recommended to repeat the project. The use of new is also a tendency towards an increase of dynamic web-based development tools was well received by abstract thinking skills (M = 2.24, SD = 0.44). Our all participating students independent of their field of hypothesis that tourism students improve their com- study. putational thinking skills during the interdisciplinary The computer science students were motivated pri- tool-based program can be confirmed. marily by the fact that new voice technologies were used in the context of this project. In turn, tourism Challenges and experiences students have grown into the role of product owner Project-based teaching presents many challenges to during the project. Furthermore, by using the de- teachers (Barron et al., 1998), among others: velopment tools, they were in able to increase their competency in using web-based tools. They also liked • Formulate clear definitions of learning goals and to creatively integrate sound effects into the Alexa competencies students should acquire. voice apps. • Make sure that the project tasks cover the planned learning content to the desired extent and ade- Summary and outlook quately demand and strengthen the competencies It is important for all students to develop and to to be acquired. strengthen their ability of computational thinking in order to meet the requirements of the digital transfor- • Build social interaction structures within the mation. As a basis, it is helpful that the students first project teams that allow a balanced distribution develop the skills for static and dynamic abstraction of roles and tasks. as these are a basic building block of the ability of computational thinking. Computational thinking is • Create a good (i.e. applicable) schedule. one of the Future Skills (Kirchherr et al., 2018), which 128 students in computer science and tourism man- are important core competencies for the future work- agement were in the pilot group in the winter semester ing life as well as for the participation in business and 2018/19. We combined a software engineering mod- society in the era of the digital transformation and the ule and a module for digital marketing and manage- new forms of work linked to it. ment. Both modules have their own learning objec- We strengthen computational thinking through in- tives and content. In addition to the learning objec- terdisciplinary, tool- and project-based learning. As a tives of these respective modules, additional learning project topic and work context, we select the design objectives of the interdisciplinary tool-based teaching- and implementation of voice-based digital assistants and-learning program include the increase in static (so-called voice apps). The students are encouraged to and dynamic abstraction abilities mentioned in this use static and dynamic abstraction for the specification paper as well as the improvement of collaboration and of the dialogue between a human and a voice-based communication skills in digital projects. Therefore, in- assistant. structors need to encourage students in their learning A competency test was developed in order to mea- process. At the same time, instructors have to take sure the effectiveness of our approach. The test was care to not overburden their students. run at the beginning and at the end of the semester. We solve the challenges of the different learning (The evaluation of the post-test is not yet completed.) objectives and content of the initial modules by run- The pseudonymized test results are used to determine ning some part of the interdisciplinary collaboration the extent to which the students were able to improve

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 63 Future Skills: How to strengthen computational thinking in all software project roles Gudrun Socher, Sarah Ottinger, Veronika Thurner und Ralph Berchtenbreiter, HS München their abilities of static and dynamic abstraction during Hershkowitz, R., B. B. Schwarz, and T. Dreyfus the program. 2001. Abstraction in context: Epistemic actions. More tests are required for a more detailed analy- Journal for Research in Mathematics Education, sis of future skills through interdisciplinary tool- and Pp. 195–222. project-based learning in digital projects. Accordingly, we plan to improve and further expand our approach Kirchherr, J., J. Klier, C. Lehmann-Brauns, and so that additional competencies are targeted and the M. Winde effects are captured by additional measuring instru- 2018. Future Skills: Welche Kompetenzen in ments. Deutschland fehlen. Kramer, J. 2007. Is abstraction the key to computing. Commu- nications of the ACM, 50. References Lorenz, W. E. and G. Wurzer Barron, B. J., D. L. Schwartz, N. J. Vye, A. Moore, 2014. Algorithmisches denken. In Brickster Style – A. Petrosino, L. Zech, and J. D. Bransford Digitales Entwerfen eines Kulturzentrums in Wien- 1998. Doing with understanding: Lessons from Meidling, P. 7–10. Technische Universität Wien. research on problem-and project-based learning. Journal of the Learning Sciences, 7(3-4):271–311. Meier, A., H. Spada, and N. Rummel 2007. A rating scheme for assessing the quality of Bell, S. computer-supported collaboration processes. Inter- 2010. Project-based learning for the 21st century: national Journal of Computer-Supported Collabora- Skills for the future. The Clearing House, 83(2):39– tive Learning, 2(1):63–86. 43. Wing, J. M. Bucci, P., T. Long, and B. Weide 2006. Computational thinking. Commun. ACM, 2001. Do we really teach abstraction? In Pro- 49(3):33–35. ceedings of the thirty-second SIGCSE technical symposium on Computer Science Education, New York, USA. ACM.

Böttcher, A., K. Schlierkamp, V. Thurner, and D. Ze- hetmeier 2016. Teaching abstraction. In 2nd International Conference on Higher Education Advances, HEAd’16, P. 357–364, València. Universitat Politècnica de València.

Cohen, J. 1992. Statistical power analysis. SAGE Journals, 1(3):98–101.

Davis, D., T. Yuen, and M. Berland 2014. Multiple case study of nerd identity in a cs1 class. In Proceedings of the 45th ACM Technical Sym- posium on Computer Science Education, SIGCS’14, P. 325–330, New York, USA. ACM.

Digitalisierung, H. 2016. The digital turn – hochschulbildung im digitalen zeitalter. Edition Stifterverband, Berlin.

Ghezzi, C., M. Jazayeri, and D. Mandrioli 2002. Fundamentals of Software Engineering. Pren- tice Hall PTR.

Hazzan, O. and J. Kramer 2007. Abstraction in computer science & software engineering: a pedagogical perspective. Frontier Journal, 4(1):6–14.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 64 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik

Oliver Radfelder, Karin Vosseberg, Ulrike Erb, Henrik Lipskoch {oradfelder,kvosseberg,uerb,hlipskoch}@hs-bremerhaven.de Hochschule Bremerhaven

Zusammenfassung Einführung Die zunehmende Heterogenität der Studierenden im Ziel der Studieneingangsphase in den Bachelorstu- ersten Semester erfordert ein Umdenken in der Ge- diengängen Informatik und Wirtschaftsinformatik der staltung der Studieneingangsphase. Nicht zuletzt ge- Hochschule Bremerhaven ist, die Studierenden in ei- fördert durch den Qualitätspakt Lehre wurden in den ne Fachkultur einzuführen, in der Informatik nicht letzen Jahren an vielen Hochschulen Projekte initi- nur Programmieren ist - aber ohne Programmieren iert, die Voraussetzungen an die Fachkompetenzen, nichts Informatik ist. In kleinen Schritten werden die die Studierfähigkeit aber auch die soziale Integrati- Studierenden an ihr grundlegendes Handwerkszeug on der Studienanfänger*innen in den Blick nehmen und eine einfache Linux-basierte Infrastruktur für die (Key u. Hill, 2018). Die verschiedenen Projekte setzen Automatisierung von Prozessen herangeführt sowie auf sehr unterschiedlichen Ebenen an. Allen Projekten das Arbeiten in Teams in einem ersten Projekt erprobt. gemeinsam ist aber eine enge Begleitung der Studie- Mit regelmäßigen kleinen Übungsaufgaben werden renden in der Übergangsphase zum Studium. die verschiedenen Grundlagenfächer miteinander ver- zahnt. Über den Projektkontext wird ein Anwendungs- Mit der letzten Reakkreditierung wurde an der bezug hergestellt. In dem vorliegenden Beitrag wird Hochschule Bremerhaven in den Bachelorstudiengän- das Konzept der überarbeiteten Studieneingangsphase gen Informatik und Wirtschaftsinformatik 2013 eine vorgestellt und anhand von kleinen Beispielen die Ver- fachspezifische Studieneingangsphase (STEP) im Cur- zahnung von Modulen demonstriert. Im weiteren wird riculum verankert. Ziel der Studieneingangsphase ist, ein Beispiel für eine Lerneinheit aus den Workshops das Berufsbild der Informatik und Wirtschaftsinforma- der Studieneingangsphase beschrieben. tik bei den Studierenden zu schärfen und das Zusam- menspiel der Grundlagenveranstaltungen als Basis für die Informatik- und Wirtschaftsinformatikausbil- Abstract dung zu verdeutlichen. Die Idee, das Studium mit einem Projekt zu starten, gibt dabei den notwendigen The introduction phase of the bachelor programmes Kontext für die vielfältigen Aufgaben in der Gestal- Informatics and Business Informatics at Bremerhaven tung und dem Einsatz von Softwaresystemen und lässt University of Applied Sciences aims at familiarising genügend Raum für Diskussionen über den vorhan- students with a faculty culture which understands in- denen Gestaltungsspielraum (Vosseberg, 2015). Mit formatics not only as programming, but follows also den Projekten können die Studierenden erste Erfah- the idea that without programming nothing is infor- rungen des eigenständigen, forschenden Lernens in matics. In small steps, students learn to handle their Teams sammeln in einem eng begleiteten Lernkon- basic tools. They are introduced to a simple Linux- text. Die Projekte fördern insbesondere die soziale based infrastructure for the automation of processes, Integration und den Austausch der Studierenden mit and experience collaborating in teams while working ihren vielfältigen Kompetenzen, die sie mit in ihr Stu- on a first project. Through continuous small exercises dium einbringen. Um an dem Erfahrungshintergrund they get an understanding of basic topics of the first der Studierenden anzuknüpfen wurden in den ers- semester modules and finally apply their knowledge in ten STEP-Jahren Analyseprojekte initiiert, da nicht the project context. This article presents the concept davon ausgegangen werden kann, dass die Studieren- of the introduction phase, describes the interlocking den bereits umfangreiche Programmiererfahrungen of modules based on small examples, and shows an mitbringen (Vosseberg u. a., 2015). Ähnliche Ansät- example of a workshop unit of the introduction phase. ze mit Projekten zum Studienstart werden auch an anderen Hochschulen verfolgt insbesondere mit dem

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 65 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven

Fokus auf Studierbarkeit und das Fördern von sozia- zahnung mit den Aufgaben im Modul Software En- len Kompetenzen (vgl. (Dennert-Möller u. Garmann, gineering I weitere Zeit für das Einüben der für die 2016)). STEP-Projekte notwendigen grundlegenden Fertigkei- Die Evaluation der ersten vier Durchläufe der Stu- ten eingeräumt. dieneingangsphase haben ergeben, dass die Startpro- Die Projektorientierung ist nach wie vor eine zentra- jekte und die enge Begleitung der Projektteams durch le Eigenschaft der Studieneingangsphase. Am ersten studentische Tutor*innen und einem Coaching von Studientag werden die Informatik- und Wirtschaftsin- Lehrenden die soziale Integration in beiden Studien- formatikstudierenden in 12 gemischte Teams mit je- gängen sehr gefördert haben. Die Verzahnung zu den weils 8- 10 Studierenden eingeteilt. Jedes Team wird Grundlagenfächern und die Angleichung von grund- durch eine*n Tutor*in über das ganze erste Semester legenden Fachkompetenzen war bislang jedoch nur begleitet und erhält einen Coach als erste Ansprech- bedingt gelungen. Gerade die Module Mathematik person an die Seite. Zur Zeit betreut jeder der drei und Programmierung wurden nach wie vor als ge- Coaches vier Teams, während die vier studentischen trennt von der Studieneingangsphase wahrgenommen Tutor*innen je drei Teams betreuen und für diese ein und die kontinuierliche Arbeitsweise aus den STEP- STEP-Tutorium anbieten. Zusätzlich betreuen ältere Projekten nicht übertragen. Ähnliche Effekte wie sie Studierende die technische Infrastruktur der STEP- in der Auswertung der Umfrage zur Programmieraus- Teams (siehe unten). Außerdem wird für jedes Team bildung von Axel Schmolitzky (Schmolitzky, 2017) be- zur Teamorganisation eine Gruppe im Rahmen des schrieben wurden, waren auch nach Einführung der Lernmanagementsystems Ilias eingerichtet. Studieneingangsphase weiter zu beobachten. Nach In den ersten Wochen werden neben Einzelaufga- wie vor sind die beiden Module Mathematik und Pro- ben auch Teamaufgaben gestellt, um sukzessiv auf die grammierung angstbesetzt, und die Modulprüfungen Projektaufgabe aber auch auf das gesamte Studium werden von einer überwiegenden Anzahl von Studie- vorzubereiten. Um eine Workshop-ähnliche Lernsitua- renden in spätere Semester geschoben. tion zu erzeugen werden in einem großen Veranstal- Diese Erfahrungen haben uns dazu bewogen, das tungsraum 12 Gruppentische aufgebaut, an denen Lernsetting der Studieneingangsphase mit dem Win- die Teams gemeinsam ihre Aufgaben bearbeiten und tersemester 2017/18 zu verändern. Gemäß dem Mot- sich gegenseitig in den Einzelaufgaben unterstützen to ”Informatik ist nicht nur Programmierung aber oh- können. Der Ablauf der 3-4-stündigen Workshops ist ne Programmierung ist nichts Informatik” erarbeiten geprägt durch einem Wechsel zwischen Inputs der sich die Studierenden in einer Workshop-ähnlichen Coaches, z.B. in Form einer kurzen Einführung in ein Lernumgebung erste Fertigkeiten in der Automatisie- Thema oder von kleinen Live-Coding-Einheiten, dem rung von Abläufen und schleifen diese mit kleinen selbständigen Üben von Fertigkeiten und der gemein- Übungen regelmäßig ein. Unterstützt werden die ca. samen Bearbeitung der Projektaufgabe im Team. Die 100 Studierenden durch Lehrende, die als Coaches Sitzungen sind geprägt durch eine sehr arbeitsintensi- zur Seite stehen, sowie durch studentische Tutorinnen ve Atmosphäre, in der alle Studierenden konzentriert und Tutoren. Das Einüben der Fertigkeiten bereitet sie mitarbeiten. Daneben werden sie mit kleinen Wochen- auf die gestellte Projektaufgabe vor, die in dem über- aufgaben angehalten, während der Woche regelmä- arbeiteten Konzept der Studieneingangsphase einen ßig - am besten täglich - sich mit der technischen wesentlichen Anteil an Programmierung enthält. Im Infrastruktur auseinanderzusetzen, um die einfachen Folgenden wird das Lernsetting der Studieneingangs- Fertigkeiten in der Automatisierung einzuschleifen. phase und insbesondere die Verzahnung mit den Mo- Im Rahmen einer Portfolio-Prüfung für den Modul dulen Mathematik und Software Engineering (SWE I) Einführung in die Informatik bzw. Einführung in die näher beschrieben. Wirtschaftsinformatik müssen die Studierenden die gestellten Aufgaben bearbeiten und jede Woche einen Studieneingangsphase - Eintrag in ihrem Reﬂektionsblog in das Lernmanage- Rahmenbedingungen mentsystem einstellen. Am Ende des Semesters stellen Die Studieneingangsphase ist an der Hochschule Bre- die Projektteams ihre Projektergebnisse am Tag der In- merhaven durch den Modul Einführung in die Infor- formatik mit einem Plakat vor. Über die regelmäßige matik bzw. Einführung in die Wirtschaftsinformatik Bearbeitung der gestellten Einzel- und Teamaufgaben im Curriculum der beiden Bachelorstudiengänge In- insbesondere aber über die wöchentlichen Blogein- formatik und Wirtschaftsinformatik verankert. Damit träge erhalten die Coaches einen guten Einblick über sind sowohl auf studentischer Seite ein Workload von den Lernfortschritt der Studierenden und können bei 5 CP vorgesehen, als auch auf Seiten der Lehrenden 8 Problemen sofort gegensteuern. Nach anfänglichen SWS Lehrleistung eingeplant. Im Rahmen eines Team- Schwierigkeiten werden die Blogeinträge regelmäßig teachings betreuen 3-4 Lehrende die Studieneingangs- geführt und sind damit eine wertvolle Informations- phase, um damit auch die Verzahnung zu anderen quelle für die Evaluation der Studieneingangsphase. Modulen im ersten Semester realisieren zu können. Um eine organisatorische Verzahnung zwischen den Zusätzlich wird den Studierenden über die enge Ver- verschiedenen Modulen im ersten Semester zu unter-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 66 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven stützen, werden die Teams als Lerngruppen in allen Modulen genutzt und in der Gruppenaufteilung im Stundenplan berücksichtigt. Zusätzlich übernehmen Lehrende aus dem ersten Semester eine Gruppe (3 Teams) im Rahmen des Programmierlabors, damit die Verzahnung zum Programmierenlernen sichtbarer wird. Die Programmierlabore werden mit zusätzlichen Tutor*innen unterstützt. Somit haben wir eine sehr enge Begleitung der Erstsemesterstudierenden und Abbildung 1: Modellboot mit Raspberry Pi sie lernen sehr frühzeitig viele Kolleg*innen aus dem Informatikbereich mit ihrer eigenen Vielfalt kennen. dem STEP-Veranstaltungsraum, dem ehemaligen Fähr- Inhalte der Studieneingangsphase haus, hat und von dort aus oft zu sehen war (siehe Abbildung 2). Im Zentrum der Studieneingangsphase stehen die Pro- jekte, die einen Anwendungskontext bieten und zum Erlernen von grundlegendem Handwerkzeug der In- formatik motivieren, das die Studierenden für die Rea- lisierung der Projekte benötigen. Dieses Handwerks- zeug wird sie auch durch ihr gesamtes Studium beglei- ten. Um die Studieneingangsphase abzurunden und einen praktischen Einblick in Berufsbilder der Informa- tik und Wirtschaftsinformatik zu erhalten, besuchen alle Teams an einem Tag jeweils ein Unternehmen aus der Region. Für den Unternehmensbesuch werden 12 ganz unterschiedliche Unternehmen ausgewählt, von klassischen Softwareentwicklungshäusern, spezialisierten Unternehmen beispielsweise aus der Logistik- oder Le- bensmittelbranche bis hin zu Beratungsunternehmen oder IT-Abteilungen von Konzernen. Die Teams müs- sen für den Unternehmensbesuch Fragen vorbereiten, Abbildung 2: Der Schlepper Tide die insbesondere an ihren bisherigen Erfahrungen mit der neu erlernten Infrastruktur und den Arbeitsweisen Als Hochschule am Meer haben wir auch in der Stu- anknüpfen. Nach dem Unternehmensbesuch werden dieneingangsphase 2018/2019 ein maritimes Thema die Erfahrungen in Form eines World-Cafes mit al- gewählt. Dieses Mal wurde ein Raspberry Pi mit ei- len Studierenden geteilt. Damit wird die Vielfalt der nem DVB-T-Empfänger verbunden und oben auf dem beruflichen Möglichkeiten sichtbar. Außerdem wird Fährhaus stationiert. Über diesen Rechner werden diskutiert, welche Grundlagen die Studierenden in permanent AIS-Signale aller Schiffe in einem Umkreis ihrem Studium brauchen, um in Zukunft solche oder von bis zu 50 km empfangen, dekodiert und in ei- ähnliche Jobs bewältigen zu können. nem bestimmten Format als Datenstrom in unserer Informatik-Infrastruktur zur Verfügung gestellt. Das Projekte 2017/2018 und 2018/2019 AIS ist das Automatische Schiffsidentifizierungssys- Die Projektaufgabe der Studieneingangsphase tem (engl. Automatic Identification System) und dient 2017/2018 bestand darin, Modellboote, die jeweils dem Austausch von Navigations- und Schiffsdaten zur mit einem Raspberry Pi ausgestattet und steuerbar Verbesserung der Sicherheit im Schiffsverkehr (WSV, sind, über einen Web-Browser per WLAN zu lenken 2018). und zu beschleunigen bzw. zu verlangsamen. Zur Vor- Die Projektaufgabe besteht darin, aus diesem Da- bereitung dieser Projekte hatten ältere Studierende tenstrom Angaben zu ausgewählten Schiffen zu filtern die Modellboote nach einer Konstruktionszeichnung und auf einer Website per HTML und SVG zu veran- des Deutschen Schifffahrtsmuseums Bremerhaven schaulichen. Zum Beispiel können die Positionen und (DSM) für den Druck per 3D-Drucker aufbereitet. Für Bewegungen von Schiffen relativ zum Fährhaus und jedes der 12 STEP-Teams haben sie ein Boot gedruckt auch auf einer Karte angezeigt werden. Dazu können und mit Motor, Steuerruder und Raspberry Pi Informationen wie Schiffsname oder Zielort gegeben versehen (siehe Abbildung 1). werden. Die Entscheidung über die Darstellungsart der Daten und die Anzeige zusätzlicher Informationen Eine Besonderheit bei dieser Aufgabe bestand dar- bleibt den STEP-Teams überlassen. Daraus ergeben in, dass der Original-Schlepper, der als Vorlage für sich Webseiten, bei denen eher Informationen über die Modellboote diente, seinen Liegeplatz direkt vor die Schiffe im Vordergrund stehen, und solche, die die

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 67 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven

Möglichkeiten dynamischer Webseiten in der gegebe- aufgesetzt (Merkel, 2014). Darin erhält jeder und nen Infrastruktur ausloten. jede Studierende einen eigenen gut ausgestatteten Anhand der beschriebenen Aufgabenstellungen wer- Container mit ssh- und Webserver, auf dem sie sich den grundlegende Kenntnisse von Bash-Shell-Skripten wiederum einloggen und mit cgi-Skripten dynamisch und HTML eingeübt sowie ein Verständnis für webba- Seiten erzeugen können. Java ist dort ebenfalls instal- sierende Client-Server-Architekturen vermittelt. liert, so dass sie ihre beginnenden Java-Kenntnisse frühzeitig anwenden können, ohne mit der Komple- Handwerkszeug der Informatik und xität von Enterprise-Java (Servlets etc.) oder GUI- Wirtschaftsinformatik Programmierung (AWT/Swing) schon konfrontiert zu An der Hochschule Bremerhaven wurde innerhalb werden. der vergangenen zwei Jahre wieder eine klassische Auf den Arbeitsservern sowie in den Containern ist Linux-basierte Infrastruktur aufgebaut, wie sie in den eine durchaus typische Server- und Arbeitsumgebung 80er und 90er Jahren an vielen Universitäten und installiert. Aufgrund der Gegebenheit, von Beginn an Hochschulen in der Informatik zum Standard gehörte. nur in der Kommandozeile zu arbeiten, um alle Ar- Damit wird der aktuellen Entwicklung Rechnung ge- beitsschritte wiederholbar und automatisierbar durch- tragen, in der Webtechnolgien und insgesamt Server- führen zu können, trotzdem aber die Studierenden orientierte Anwendungen einen massiven Aufschwung nicht auf die für sie zunächst unmodern und unhand- erleben. lich wirkende reine Textausgabe zu beschränken, wur- So besteht die gemeinhin als Cloud bezeichnete de ein spezifischer Arbeitsfluss etabliert: Wo immer technolgische Basis moderner Anwendungen letztlich sie etwas mit einem selbst geschriebenen Programm aus einer Menge an Servern mit Rechen- und Speicher- erzeugen, nutzen sie das Webverzeichnis, um sich kapazität. Anwendungen bestehen dort aus Program- das Ergebnis im Browser anzeigen lassen zu können men, die typischerweise unter Linux laufen. Selbst in und gegebenenfalls auch Freunden und Familie früh- der Microsoft-eigenen Azure-Cloud laufen zunehmend zeitig zu zeigen, was sie im Studium tun. So lernen Anwendungen unter Linux: sie früh das Werkzeug gnuplot kennen, um Graphen visuell ansprechend als PDF oder SVG zu erzeugen Today, Scott Guthrie, Microsoft’s executive vice und sie lernen LAT X, um Dokumente so zu generieren, president of the cloud and enterprise group, said E dass sie zum einen heutigen ästhetischen Ansprüchen in an interview, "it’s about half now, but it genügen als auch die sorgfältige Trennung von Struk- varies on the day because a lot of these work- tur und Darstellung verdeutlichen. Da sie frühzeitig loads are elastic, but sometimes slightly over HTML von Hand und ohne all zu mächtige Hilfsmittel half of Azure VMs are Linux." zu schreiben angehalten werden, können sie systema- (Steven J. Vaughan-Nichols) tisch Listen und Tabellen mit Skripten oder mit Java erzeugen. Zudem ist das InternetOfThings und große Teile des- Der grundsätzliche Arbeitsrhythmus ist also: Erstelle sen, was unter Industrie 4.0 verstanden wird, auf uni- ein Programm, das etwas produziert, das im Web an- xoiden System – speziell Linux – aufgebaut. gezeigt werden kann - sei es ein HTML-Dokument, eine Folglich müssen heute Studierende wieder darauf PDF-Datei, ein Bild (PNG) oder eine Grafik (SVG/PDF). vorbereitet werden, sich in einer solchen Umgebung Wie in dem Abschnitt zum Workshop Videoerstellung sicher bewegen zu können. dargestellt, gehen wir dabei soweit, dass aus einer Unsere Umgebung besteht aus mittlerweile mehre- Menge von generierten Grafiken automatisiert eine ren Arbeitsservern, auf denen sich die Studierenden Menge von Bildern und daraus dann ebenfalls automa- innerhalb der Hochschule ebenso wie von außerhalb tisiert ein Video erstellt werden kann. Die Werkzeuge per ssh einloggen können. Sie finden dort ein Home- dafür (inkscape und ffmpeg) gehören daher auch zu Verzeichnis für Ihre Arbeiten vor und lernen von Be- unserer Standardumgebung. ginn an, mit dem Editor vim Ihre Aufgaben zu erle- digen. Zudem haben sie dort ein Webverzeichnis, in dem sie ihre persönliche Webseite mit HTML und CSS Verzahnung von Modulen gestalten können und sollen. Die Infrastruktur bietet Um Studierenden einen Zugang und ein entsprechen- jedem Studierenden und jedem Lehrenden außerdem des Verständnis für grundlegende Konzepte der Infor- Zugang zu einer eigenen Datenbank, zu PHP, Java matik zu ermöglichen, verfolgen wir in der Studienein- und einem Git-Server. gangsphase den Ansatz, verschiedene Fachmodule der- Da wir neben Java und der Bash im ersten Semes- art miteinander zu verzahnen, dass spezifische The- ter nicht noch eine weitere Programmiersprache mit men aus jeweils einem der Module auch in anderen PHP einführen wollten, trotzdem aber mit dynamisch Modulen aufgegriffen und behandelt werden. Eine sol- erzeugen Webseiten bereits Automatisierung in das che Verzahnung ermöglicht es, Themen aus verschie- Zentrum der Vorbereitung auf die kommenden Se- denen Perspektiven und anhand von verschiedenen mester stellen wollten, haben wir für das Winterse- Beispielen zu betrachten. Die Hoffnung dabei ist, dass mester 2018/2019 eine Docker-basierte Umgebung mehr Studierende zeitnah beim Stoff der Vorlesun-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 68 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven gen mitgenommen werden und verschiedene Lernty- Schlepper Tide (siehe Abbildung 2), der seinen Lie- pen die Chance haben, den Stoff zu erfassen. Für die geplatz direkt vor dem Fährhaus hat, gibt es mehrere Verzahnung ist es wichtig, dass sich die beteiligten Modelle: Zum einen diente die Konstruktionszeich- Lehrenden der jeweiligen Module (mindestens der nung (siehe Abbildung 3) als präskriptives Modell Module STEP, Programmieren, Mathematik, Software sowohl für den Original-Schlepper als auch für den Engineering) abstimmen, in welchen Wochen voraus- 3D-Druck der Modellboote. sichtlich welche Themen behandelt werden. Es geht dann nicht darum, auf dem Vorwissen aus den jeweils anderen Veranstaltungen aufzusetzen, sondern das Thema mit dem Ansatz und aus der Perspektive der jeweiligen Veranstaltung einzuführen und dabei ggf. Beziehungen zu den anderen Veranstaltungen herzustellen. Dieses Konzept trägt auch den pädagogischen Erkenntnissen Rechnung, dass neues Wissen nachhal- tiger erworben werden kann, wenn es in einen breiten Kontext vorhandenen Wissens eingeordnet werden kann:

”As just explored, a wide range of converging evidence stresses the fundamental importance of the learning edge, the boundaries of existing knowledge which form the context into which newly learned concepts (information, under- Abbildung 3: Konstruktionszeichnung der Tide (Digi- standing and skills) must be integrated. This PEER) fact is widely understood and accepted, and the basis of many sound pedagogical practices.” Zum anderen ist das ausgedruckte STEP-Boot (sie- (Robins, 2010, S.66) he Abbildung 1) ein Modell, das einige wenige Merk- male des Originals abbildet. Abbildung, Verkürzung Unser Curriculum sieht insgesamt drei Module für und Pragmatismus, die von Stachowiak (Stachowiak, Software Engineering (SWE) vor: Im ersten Semes- 1973) benannten typischen Merkmale von Modellen, ter geht es um Modellierung im Allgemeinen und werden an diesem Beispiel greifbar. UML im Besonderen. Im zweiten Semester wenden Neben solchen allgemeinen Aspekten der Model- die Studierenden die gelernten Methoden in einem lierung erfahren die Studierenden ganz konkret den konkreten Kundenprojekt ihrer Wahl an, während im Nutzen der Modellierung beim Software Engineering, dritten Semester anhand von Fallbeispielen ein beson- wenn sie in SWE I die Aufgabe erhalten, das Konzept derer Fokus auf Software-Architekturen und Quali- für die im STEP-Projekt zu entwickelnde Anwendung tätssicherung gelegt wird. Die enge Verzahnung mit zunächst mittels UML-Anwendungsfalldiagramm zu Inhalten des STEP-Projektes bietet in SWE I die Chan- entwerfen und später einzelne Abläufe per UML- ce, Modellierungsbeispiele direkt auf die sehr pra- Aktivitätsdiagramm zu konkretisieren. In den STEP- xisbezogenen Aufgabenstellungen der STEP-Projekte Projekten werden keine festen Vorgaben zur erwar- zu beziehen. Insbesondere die Erstellung von UML- teten Funktionalität gemacht, sondern vor allem ein Aktivitätsdiagrammen zu konkreten bash-Skripten aus Rahmen abgesteckt. Die Idee für das Endprodukt wird den STEP-Projekten führt einerseits zu einem besse- von den Teams jeweils selbst entwickelt. Anwendungs- ren Verständnis für den Sinn der Modellierung. An- falldiagramme sind dann eine gute Methode für die dererseits erhalten die Studierenden dadurch einen Verständigung im Team über das zu entwickelnde Sys- anderen, visuellen Blick auf den Quellcode, der vielen tem. einen weiteren Zugang zum Verstehen der Programme Kontrollstrukturen, Aktivitätsdiagramm und und Programmierkonzepte ermöglicht. mathematische Berechnungen Im Folgenden skizzieren wir einige Beispiele zur Ver- In der STEP-Veranstaltung werden stets zahnung von Modulen aus der Studieneingangsphase auch Programmierprinzipien aus der Java- unserer Bachelorstudiengänge Informatik und Wirt- Programmierveranstaltung aufgegriffen und deren schaftsinformatik in den Wintersemestern 2017/2018 Umsetzung in der Bash gezeigt. Auf diese Weise wird und 2018/2019. die Programmiersprachen-übergreifende Bedeutung Modellbildung von Konstrukten wie bedingten Anweisungen und Die Aufgabenstellung des STEP-Projektes 2017/2018 Schleifen unterstrichen. In SWE erhalten die Studie- eignete sich besonders gut zur Erläuterung einiger renden durch die Modellierung dieser Konstrukte in Grundprinzipien der Modellierung im Allgemeinen, Aktivitätsdiagrammen auch einen visuellen Zugang. die in SWE I vermittelt werden. Zum Original, dem Ein anschauliches Beispiel ist die Modellierung der

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 69 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven

Erhöhung der Geschwindigkeit der STEP-Boote aus Fakultät in jeweils eigenen Veranstaltungseinheiten dem STEP-Projekt 2017/2018. Die Boote konnten per eingeführt. Binärzahlen als Grundlage der digitalen Browser durch den Aufruf entsprechender CGI-Skripte Computertechnik und das Dividieren mit Rest, wel- gesteuert werden, die auf einem Webserver, dem ches ein Beispiel für die Endlichkeit mathematischer Raspberry Pi der Boote, ausgeführt wurden. Ein Berechnungen im Computer darstellt, erfahren durch Skript diente z.B. dazu, die Boote zu beschleunigen, die Verzahnung mit STEP direkte praktische Übungen. bis sie sich zu sehr in Schieﬂage neigten. In SWE I Diese Übungen wären sonst im Modul Mathematik sollte dies mittels UML-Aktivitätsdiagrammen mit aufgrund der erforderlichen Themenbreite für Unix, ‘Schwimmbahnen‘ modelliert werden. Eine mögliche Shell-Skripte etc. nicht zu leisten. Lösung dazu ﬁndet sich in Abbildung 4. Der zyklische Insbesondere kann so das RSA-Verschlüsselungs- Verlauf einer Schleife kann im Aktivitätsdiagramm verfahren (Rivest u. a., 1977) praktisch ausprobiert gut veranschaulicht werden. werden: In der Mathematik lernen die Studierenden den Algorithmus und die mathematische Grundlage. Die Basis bilden zwei sehr große Primzahlen und dann werden nacheinander mehrere Zahlen daraus berechnet. Dabei wird auch das sogenannte Multiplikative Inverse benötigt. Hierzu lernen die Studierenden ebenfalls in der Mathematik den Euklidischen Algorithmus (Knuth, 1998) kennen und anwenden. Für die korrespondierende STEP-Aufgabe ist ein Programm, welches den Euklidischen Algorithmus ausführt und die einzelnen Schritte auf der Konsole darstellt, gegeben. In Abbildung 6 ist die Ausgabe der Berechnung zu sehen. In der Zeile für i = 5 ist der Wert von r gerade 1, was bedeutet, dass die Zahlen 310 und 617 Abbildung 4: Aktivitätsdiagramm Boot beschleunigen keine gemeinsamen Teiler haben. Deswegen gibt es das Multiplikative Inverse bezüglich modulo 617. Es Die Nutzung von Schleifen wurde auch zum Beispiel steht in der gleichen Zeile in der Alpha-Spalte. Da die anhand der Dezimal-Binär-Umwandlung mit Modulo- Zahl negativ ist, müssen die Studierenden zusätzlich Berechnung verdeutlicht. Mit diesem Beispiel wird 617 addieren: sowohl ein Bogen zur Mathematik-Veranstaltung ge- schlagen, als auch das bash-scripting einer Schleife (310 · (−205 + 617)) mod 617 = 1 gezeigt (siehe Abbildung 5). Zudem kommen dafür in den Aktivitätsdiagrammen Notationselemente wie Diese Teilaufgabe ist nicht ohne die mathematischen Verzweigung und Zusammenführung zum Einsatz. Kenntnisse zu lösen.

Abbildung 6: Erweiterter Euklidischer Algorithmus berechnet für die Zahlen 310 und 617

Abbildung 5: Bash-Skript Dezimal-Binär-Umwandlung Die gesamte STEP-Aufgabe besteht daraus, dass die Studierenden zwei große Primzahlen ﬁnden und die Verzahnung mit der Mathematik am Beispiel verschiedenen weiteren benötigten Zahlen für RSA RSA vermittels einfacher mathematischer Formeln (Multi- Im Modul Mathematik werden die Begriffe Binärzah- plikationen) berechnen. Wie sie die Primzahlen ﬁn- len, Dividieren mit Rest und Kombinatorik mit der den, ist ihnen überlassen. Durch Shell-Skript-Aufruf

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 70 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven bestimmen sie das Multiplikative Inverse, in dem das Rechteck, Linienzug oder Text können direkt im Editor gegebene Programm aufgerufen und aus der Ausgabe eingegeben werden: der entsprechende Wert herausgefiltert wird. Workshop Videoerstellung Die Vermittlung der Kompetenz, selbst Visualierungen zu generieren, ist ein weiteres Thema im Rahmen der Ohne Programmieren ist nichts Informatik Step-Veranstaltung, auf das wir im Folgenden einge- hen. Videos werden von heutigen Studierenden gern und viel zum Lernen genutzt. Jedoch sind fremdgeschaffe- ne Lernvideos zunächst einmal ein passives Medium und bieten Ihrer Natur nach eben keine Möglichkeit, den dargestellten Sachverhalt mit eigenen Parametern zu variieren oder mit eigenen Ideen anzureichern. Das hier vorgestellte Instrument selbsterstellte Videos zur Visualisierung komplexer Vorgänge knüpft an die Abbildung 7: SVG Ausgabe konstruktionistischen Ideen von Seymore Papert an: Es genügt zum Erstellen einer Grafik hier also zu- Slowly I began to formulate what I still consider nächst die Fertigkeit zur Bedienung eines Editors und the fundamental fact about learning: Anything die Beherrschung einiger weniger Unix-Kommandos is easy if you can assimilate it to your collec- wie cp für das Kopieren der Datei in das Webverzeich- tion of models. If you can’t, anything can be nis. Beim Editieren ist immer auch ein Browser geöff- painfully difficult. net, in dem das Ergebnis sehr schnell geprüft werden (Papert, 1980, S. iiv) kann. Da die Studierenden zu dem Zeitpunkt, da wir SVG eingeführt haben, bereits HTML-Kenntnisse be- Große Teile der Ideen von Papert sind explizit auf sitzen, ist die Syntax von SVG nicht mehr all zu fremd den Umgang von Schüler*innen mit Computern ausge- - die Tatsache, dass Baumstrukturen mit ineinander richtet, um sowohl das Programmieren als solches zu geschachtelten Tags in der speziellen Notation mit spit- erlernen als auch die Lust am mentalen Modellieren zen Klammern konstruiert werden, ist folglich keine und Prüfen der Modelle zu fördern. Demzufolge sind große Hürde mehr. Das schnell wechselnde Arbeiten auch in dieser Tradition fortgeführte Programmierum- zwischen Editor und Browser ist ebenfalls eingeübt gebungen (von Logo bis Scratch) nicht auf generische und stellt keine Probleme mehr dar. Programmiersprachen ausgerichtet und bisweilen für Studierende zu verspielt. Einheitskreis In unserem Ansatz verfolgen wir das Ziel, dass die Als bedeutend größere Schwierigkeit stellt sich her- Studierenden eine Grundmenge an Elementen an die aus, dass die Studierenden zwar mit den Worten Si- Hand bekommen, mit der sie sich aus jeder Program- nus, Cosinus, Pythagoras und Einheitskreis vertraut miersprache heraus selbst Visualisierungen höherer waren, jedoch die Zusammenhänge mit Koordinaten- und abstrakterer Konzepte erstellen können. systemen ihnen zu einem erheblichen Teil so fremd waren, dass sie nicht - oft auch kaum nach ausführli- Scalable Vector Graphics cher Hilfe in Tutorien - in der Lage waren, einen Kreis Das Format SVG (Scalable Vector Graphics) hat sich aus 18 Kreisen zu konstruieren. Der Stoff aus dem in den vergangenen Jahren zu einem Standardformat Mathematikunterricht spätestens der 10. Klasse war für Vektorgrafiken entwickelt. Jeder einigermaßen mo- nicht präsent - geschweige denn zu einem Teil der derne Browser kann SVG-Grafiken nativ (also ohne inneren Modellbildung geworden. Für einen Studien- Plugins) darstellen. SVG ist ein reines, auf XML ba- gang, der heutzutage so stark auf Visualisierungen sierendes Textformat - grafische Primitive wie Kreis, und Grafik im Allgemeinen aufbaut, stellt das eine

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 71 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven ernstzunehmende Problematik dar, der zu begegnen ist; zumal nicht wenige der Studierenden selbst sehr visuell geprägt sind und das Programmieren von Com- puterspielen recht weit oben auf der Wunschliste der eigenen Befähigungen steht. In Zeiten, in denen 3D- Visualisierungen und -Animationen für jeden program- mierwilligen Menschen erschwinglich und machbar ohne Spezialausrüstung sind, wird man die Studie- renden gerade zu diesem so zukunftsträchtigen und spannenden Feld so nicht hinführen können: Kein API Abbildung 8: SVG Ausgabe für die Längen im Einheits- oder Framework nimmt einem die Notwendigkeit ab, kreis bei 30 Grad mit drei ausgestreckten Fingern vor sich Rotationen im dreidimensionalen Raum in Cosinus und Sinus 3. Variieren Sie Ihr Skript so, dass es als Argument denken zu müssen. eine Zahl in Graden von 0 bis 360 entgegennimmt Grundannahme und zeichnen Sie eine Linie von dem Mittelpunkt des Wer Kreises bis zum Rand des Kreises bei der übergebe- nen Gradzahl. Fügen Sie dort noch einen Kreis mit • bereits einfache Skripte schreiben kann, die Texte dem Radius 8 ein. Berechnen Sie die Koordinaten ausgeben, mit bc. • degrees·π Ausgaben auf der Kommandozeile ganz problem- rad = 180 los in eine Textdatei umleiten kann, x = cx + cos(rad) · r • Schleifen und Bedingungen ausdrücken kann, y = height − (cy + sin(rad) · r) • versteht, dass Programmaufrufe unter Unix im- rad=$(echo ”($deg * 4*a(1))/180”|bc -l) mer sowohl in der Shell ausführbar sind als auch x=$(echo ”$cx + s($rad)*$r”|bc -l) genau so in einem Skript mit Kontrollstrukturen y=$(echo ”$h-($cy + c($rad)*$r)”|bc -l) zur Automatisierung stehen können, 4. Rufen Sie in einer Schleife mit i von 0 bis 360 Ihr • ein Kommandozeilenprogramm zur Verfügung Skript mit i als Argument auf und erzeugen Sie hat, das SVG-Graﬁken in PNG-Bilder konvertie- dadurch 361 SVG-Dateien der Form kreis$num.svg, ren kann (inkscape) und wobei sich $num aus $i + 1000 berechnet. Erzeugen Sie aus den SVG-Dateien ebenfalls in der Schleife • ein Kommandozeilenprogramm zur Verfügung jeweils eine PNG-Datei: hat, das eine Menge von PNG-Bildern in ein digi- inkscape -z --export-png=kreis$num.png \ tales Video konvertiert (ffmpeg), kreis$num.svg kann sich mit wenig Aufwand ein eigenes Video programmieren, in dem der Zusammenhang von Sinus, 5. Benutzen Sie ffmpeg nun, um aus den 361 Dateien Cosinus und Einheitskreis dargestellt wird. eine Videodatei zu erzeugen: Im folgenden Abschnitt zeigen wir die konkrete ffmpeg -y -i kreis1%03d.png \ Lerneinheit, die in Form eines Workshops an einem -pix_fmt yuv420p kreis.mp4 Vormittag den Studierenden etwa in der Mitte des Betrachten Sie das Video in Ihrem Browser. Semesters gegeben wurde, nachdem in der Vorwoche klar wurde, dass Trigonometrie noch einmal vertieft 6. Verändern Sie nun Ihr Skript so, dass zusätzlich zu werden könnte. der Linie, die vom Mittelpunkt zum Kreisrand gezogen wird, noch die Linie vom Kreismittelpunkt zu Ein Workshop zum Einheitskreis der berechneten X-Koordinate aber auf der gleichen 1. Schreiben Sie ein Skript, das eine SVG-Datei der Höhe wie der Kreismittelpunkt in blau eingezeichnet Breite 700 Einheiten und der Höhe 300 Einheiten wird. Nun zeichnen Sie noch eine Linie von diesem ausgibt, in dem ein Rechteck derselben Größe an Punkt zu dem berechneten Punkt auf dem Kreisrand dem Punkt (0,0) positioniert wird. in rot. Erzeugen Sie nun wieder ein Video und betrachten Sie den Verlauf des rechtwinkligen Dreiecks. 2. Fügen Sie einen Kreis mit dem Radius 100 Einheiten an der Position (150,150) ein und zeichnen Sie ein Koordinatenkreuz ein, das durch eben diesen Mit- 7. Verändern Sie in einem vorerst letzten Schritt noch telpunkt des Kreises geht. Für die folgenden Über- einmal Ihr Skript so, dass – wieder in einer Schleife legungen gilt dieser Punkt als Nullpunkt in dem – alle Werte von 0 bis zur aktuellen Gradzahl für kartesischen Koordinatensystem und 100 graphi- Cosinus (x-Achse) und Sinus (y-Achse) berechnet sche Einheiten entsprechen einer Einheit in diesem und neben dem Kreis als einzelne kleine Kreise mit System. einem Radius von 5 Einheiten aufgetragen werden.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 72 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven

bindung mit der Shell. Das Öffnen und Schließen und Beschreiben von Dateien in Java erfordert ein komplexes Geﬂecht aus Objekten und Klassen, die zu Beginn des Programmierenlernens noch zu fremd sind. Mit System.out.println lässt sich jedoch für jeden Programmaufruf ein Datenstrom beschreiben - und so wird in einer Shell-Schleife jeweils ein Java-Programm aufgerufen, das wiederum SVG hinausschreibt. Nach dem Workshop haben wir den Studierenden Abbildung 9: SVG Ausgabe für die Längen im Einheits- als Wochenaufgabe gestellt, mit den gleichen Konzep- kreis zur Veranschaulichung von Sinus und Cosinus ten (SVG, Bash und ffmpeg) irgendeine Animation zu bei 30 Grad erstellen - möglicherweise eine, die etwas aus dem bisherigen Studium veranschaulicht. Dabei sind sehr be- eindruckende Ergebnisse entstanden: mehrfach wurde ein Sortieralgorithmus visualisert und die Türme von Hanoi, die in der Programmiervorlesung behandelt worden waren, fanden sich ebenfalls mehrfach wieder. Dass in fast allen anderen in irgendeiner Form mit den Kreisfunktionen experimentiert wurde (von Ana- loguhren bis zu Lissajous-Figuren) war angesichts der oben beschriebenen Ausgangssituation ein besonders erfreuliches Ergebnis. Abbildung 10: SVG Ausgabe für die Längen im Ein- heitskreis zur Veranschaulichung von Sinus und Cosi- Fazit nus bei 330 Grad mit Sinus- und Cosinus-Kurve Die mittlerweile sechsjährigen Erfahrungen mit der Studieneingangsphase an der Hochschule Bremerha- 8. Betten Sie die das Video in Ihre HTML-Datei nun ven haben gezeigt, dass ein begleiteter, projektorien- so ein, dass es in einer Endlosschleife abläuft und tierter Studienstart die soziale Integration der Studie- betrachten Sie Ihr Werk einige Minuten. Versuchen renden fördert und in den meisten Teams die Zusam- Sie so das Verhältnis von Sinus und Cosinus im Ein- menarbeit auch nach anfänglichen Schwierigkeiten heitskreis als Längen in einem Koordinatensystem sehr gut funktioniert. Die Teams kommen zu guten zu begreifen. bis sehr guten Projektergebnissen und die Einzelnen zeigen deutliche Fortschritte in ihrer Lernentwicklung. Kontextualisierung Mit der Neuausrichtung der Projekte von reinen Analy- SVG als Visualisierungswerkzeug schult die Studieren- seaufgaben zu Programmieraufgaben kann eine besse- den von Beginn an darin, in Schnittstellen zu denken. re Verzahnung der Grundlagenfächer hergestellt wer- Statt spezieller APIs oder sogar Programmiersprachen den. Somit werden die Zusammenhänge für die Stu- wird in guter Unix-Tradition als Interface reiner Text dierenden erfahrbarer. genutzt, der über Pipes und Ausgabeumlenkung in Ob alle angestrebten Ziele auch tatsächlich er- Dateien gelenkt wird. Zusammen mit der Möglichkeit, reicht werden, bedarf noch entsprechender Evalua- in Schleifen viele, systematisch benannte Dateien zu tionen. Bisher gründen unsere Aussagen dazu auf erzeugen und mit einem einzigen Programmaufruf in eigenen Eindrücken sowie auf den STEP-Blogs der ein Video zu konvertieren, lassen sich selbständig kom- Studierenden. Wie erwähnt wird von den Studieren- plexe Sachverhalte durchdenken. Das oben beschrie- den erwartet, dass sie in ihrem Teamordner auf der bene Konzept führen wir bei uns in der Studienein- ILIAS-Lernplattform einen wöchentlichen, persönli- gangsphase etwa in der Mitte des Semesters ein. Das chen Blogeintrag schreiben, in dem kurz zusammen- Dateisystem, Schleifen, Bedingungen und einfache gefasst wird, was in allen Lehrveranstaltungen des Skripte sind den Studierenden bis dahin ebenso wie ersten Semesters gelernt wurde, welche Schwierig- HTML und SVG hinreichend nahe gebracht worden. keiten im Wege standen und was in der kommenden Dass das Beispiel Sinus und Cosinus am Einheitskreis Woche angestrebt wird. In Abbildung 11 ist das vorläu- behandelt wird, ist lediglich der konkreten Situation ﬁge Ergebnis zu sehen. Von etwa 90 Studierenden, die geschuldet, dass klar wurde, dass zumindest in die- wir als aktiv studierend betrachten können, schreiben ser Kohorte diesbezüblich Nachholbedarf bestand. Es im Schnitt mehr als 70 pünktlich ihren Blogeintrag. könnte sich ebenso gut um einfache Sortieralgorith- Diese Blogeinträge sind für uns ein wertvolles Eva- men, das Durchlaufen von Arrays oder Algorithmen luationsinstrument, bei dem wir wöchentliches Feed- auf Graphen handeln. back darüber erhalten, was in den verschiedenen Fä- Ebenfalls lässt sich das Konzept auf die Program- chern bei den Studierenden ”hängengeblieben” ist, mierung mit Java anwenden - allerdings nur in Ver- wo zusätzlicher Erklärungsbedarf besteht oder ob die

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 73 Informatik ist nicht nur Programmieren – aber ohne Programmieren ist nichts Informatik Oliver Radfelder, Karin Vosseberg, Ulrike Erb und Henrik Lipskoch, HS Bremerhaven

[Key u. Hill 2018] KEY, Olivia ; HILL, Lukasz: Die Abbildung 11: Blog-Einträge pro Semesterwoche Studieneingangsphase im Umbruch. Anregungen 100 aus den Hochschulen. In: nexus impulse für die Praxis (2018), Nr. 14 80

60 [Knuth 1998] KNUTH, Donald E.: The Art of Computer Programming. Bd. 2, Seminumerical Algorithms. 3. 40 Addison-Wesley Professional (Pearson), 1998 20 [Merkel 2014] MERKEL, Dirk: Docker: Lightweight 0 Linux Containers for Consistent Development and 1 2 3 4 5 6 7 8 9 10 11 12 Deployment. In: Linux J. 2014 (2014), März, Nr. Semesterwoche 239. – ISSN 1075–3583

[Papert 1980] PAPERT, Seymour: Mindstorms: children, Arbeitsbelastung zu hoch ist. Ein Wochenblogeintrag computers, and powerful ideas. New York, NY, USA : wie: ”In Programmieren und SWE haben wir Klas- Basic Books, Inc., 1980. – ISBN 0–465–04627–4 sen und Objekte kennengelernt” zeigt zum Beispiel auch, wie gut die Verzahnung der Module funktioniert. [Rivest u. a. 1977] RIVEST, R. L. ; SHAMIR, A. ; AD- Durch die Einträge wird den Studierenden selbst klar, LEMAN, L.: A Method for Obtaining Digital Si- was sie in der vergangenen Woche gelernt haben: gnatures and Public-Key Cryptosystems. 1977. – http://people.csail.mit.edu/rivest/Rsapaper.pdf "Diese Woche haben wir uns in STEP mit der Erstellung eines Einheitskreises beschäftigt. Mit [Robins 2010] ROBINS, Anthony V.: Learning edge Hilfe des Programms ffmpeg, haben wir außer- momentum: a new account of outcomes in CS1. dem mehrere Bilder, mit verschiedenen Varian- In: Computer Science Education 20 (2010), Nr. 1, S. ten des Kreises, zu einem Video zusammenfügen 37–71 können. [Schmolitzky 2017] SCHMOLITZKY, Axel: Zahlen, Be- Die Wochenaufgabe in STEP empfand ich diese obachtungen und Fragen zur Programmierlehre. In: Woche wesentlich leichter, als in der vergange- BRÜGGE, Bernd (Hrsg.) ; KRUSCHE, Stephan (Hrsg.): nen Woche und konnte sie auch schnell umset- Tagungsband des 15. Workshops Software Enginee- zen. In Programmieren haben wir das Thema ring im Unterricht der Hochschulen, 2017, 83–90 Rekursion wiederholt, hinzu kam das Thema Objektorientierte Programmierung in Java, so- [Stachowiak 1973] STACHOWIAK, Herbert: Allgemeine wie die Verknüpfung von mehreren Klassen. Modelltheorie. Bd. 2, Seminumerical Algorithms. Wi- en : Addison-Wesley Professional (Pearson), 1973. – Weiterhin schwer fällt mir Mathe, aber da muss ISBN 3–211–81106–0 man halt durch. Zum Glück hilft ja bekanntlich das Internet bei Verständnisproblemen. Ich freue [Steven J. Vaughan-Nichols ] STEVEN J.VAUGHAN- mich jedenfalls auf den Unternehmensbesuch in NICHOLS: Linux now dominates Azure.– der nächsten Woche." https://www.zdnet.com/article/linux-now -dominates-azure/ Zugriff: 30.10.2018 Als ein erfreuliches Ergebnis der Studieneingangs- phase kann zudem festgehalten werden, dass die [Vosseberg 2015] VOSSEBERG, Karin: Mit Projekten Workshop-ähnliche Lernumgebung über das ganze ins Studium starten. In: SCHMOLITZKY, Axel (Hrsg.) Semester hinweg eine Wissensvermittlung in einer ; HAUPTMANN, Anna S. (Hrsg.): Tagungsband des 14. sehr intensiven Lernatmosphäre ermöglicht hat. Workshops Software Engineering im Unterricht der Hochschulen, 2015, 123–124 Literatur [Vosseberg u. a. 2015] VOSSEBERG, Karin ; CZERNIK, [Dennert-Möller u. Garmann 2016] DENNERT- Soﬁe ; ERB, Ulrike ; VIELHABER, Michael: Projek- MÖLLER, Elisabeth ; GARMANN, Robert: Das „Start- torientierte Studieneingangsphase. Das Berufsbild projekt“ - Entwicklung überfachlicher Kompetenzen der Informatik und Wirtschaftsinformatik schärfen. von Anfang an. In: SCHWILL, Andreas (Hrsg.) ; LU- In: SCHUBERT, Sigrid (Hrsg.) ; SCHWILL, Andreas CKE, Ulrike (Hrsg.): HDI 2016 : Hochschuldidaktik (Hrsg.): HDI 2014 : Gestalten von Übergängen, 2015, der Informatik, 2016, 11 – 24 169 – 177 [DigiPEER ] DIGIPEER: Digitalisierung groß- formatiger Pläne und technischer Zeichnungen [WSV 2018] WSV: Maritime Verkehrstechnik. 2018. zur Erfassung und Erschließung des Raums. – https://www.gdws.wsv.bund.de/DE/schifffahrt/ – http://www.digipeer.de/index.php Zugriff: 03_verkehrstechnik/verkehrstechnik-node.html 02.12.2018

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 74 Using Mini-Projects to Teach Empirical Software Engineering

Michael Felderer1 and Marco Kuhrmann2 1University of Innsbruck, [email protected] 2Clausthal University of Technology, [email protected]

Abstract lines exist, such as for systematic reviews [16, 28], Empirical studies have become a central element of systematic mapping studies [23, 24], multi-vocal re- software engineering research and practice. Yet, teach- views [10, 11], or surveys [12, 21]. All these instru- ing the instruments of empirical software engineering ments are meant to support researchers and practi- is challenging, since students need to understand the tioners alike in conducting empirical studies and to theory of the scientific method and also have to de- ground their work and decisions in evidence. velop an understanding of the application of those in- Conducting empirical studies is challenging and struments and their benefits. In this paper, we present requires careful preparation and a disciplined work and evaluate an approach to teach empirical software approach. Quite often, students consider empirical engineering with course-integrated mini-projects. In studies of little to no help when it comes to software mini-projects, students conduct small empirical stud- development and project work, since the relation to ies, e.g., surveys, literature reviews, controlled ex- actual development tasks is not obvious. Yet, many periments, and data mining studies in collaborating of today’s applications rely on data, e.g., machine teams. We present the approach through two im- learning systems like text and speech recognition, IoT plementations at two universities as a self-contained devices, and autonomous cars. Empirical methods course on empirical software engineering and as part as such are about data analysis and, thus, provide of an advanced software engineering course; with 101 a suitable approach to teach data analysis—or data graduate students in total. Our evaluation shows a engineering in general—that is a core competence positive learning experience and an improved under- in data-intensive applications. Furthermore, modern standing of the concepts taught. More than a half software development paradigms, such as DevOps of the students consider empirical studies helpful for including continuous integration and deployment, uti- their later careers. Finally, a qualitative coding and lize data, e.g., to analyze a system’s performance, to a statistical analysis showed the proposed approach predict defects, and to make informed decisions in beneficial, but also revealed challenges of the scien- the development process as practiced in continuous tific work process, e.g., data collection activities that experimentation [5]. Therefore, it is necessary for were underestimated by the students. teachers to open the students’ minds for a rigorous and evidence-based work approach. 1 Introduction In this paper, we present and evaluate the concept of Empirical software engineering aims at making soft- course-integrated mini-projects to teach empirical software engineering claims measurable, i.e., to analyze ware engineering instruments. Our approach helps and understand phenomena in software engineering students learn how to conduct empirical studies and and to evaluate software engineering approaches and understand the instruments and challenges coming solutions, and to ground decision-making processes along with such studies. Collaborating project teams in evidence. For this, an extensive portfolio of instru- conducting small empirical studies form the basis of ments for empirical software engineering has been our approach. We implemented the approach in two developed. For instance, Wohlin et al. [27] provide a courses at the University of Southern Denmark (2016, collection of instruments, e.g., controlled experiments, 68 students) and University of Innsbruck (2017, 33 surveys and case studies, to be used for empirical stud- students). Mini-projects allow students to learn em- ies in software engineering. Kitchenham et al. [13] pirical instruments by practically applying them. Our extended these instruments by a detailed guideline for evaluation shows a positive learning experience and conducting systematic reviews. For most of the basic an improved understanding of (empirical) software instruments used in empirical software engineering engineering concepts. More than half of the students today, extended and more detailed (pragmatic) guide- perceive empirical studies helpful for their later ca-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 75 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal reers. Our evaluation also shows that notably data out actual research to practice the application of the collection activities (e.g., for surveys and experiments) empirical instruments. In our previous work [17–19], are underestimated by the students. Our findings thus we presented different, self-contained classroom ex- lay the foundation for improving research-oriented periments and developed a guideline to select the best- courses that require data and data analysis. fitting study type for a specific context [6]. In [14], we The remainder of the paper is organized as follows: introduced a teaming model that helps implementing Section2 gives an overview of background and re- empirical studies in larger project courses. lated work. Section3 describes the mini-project ap- We contribute a generalized concept grounded in proach, and Section4 presents the approach’s evalua- [6,14] that allows for including empirical studies as tion based on two implementations at the University course units. We implemented and evaluated our of Southern Denmark and the University of Innsbruck approach in a course on empirical software engineer- respectively. We conclude the paper and discuss future ing and an advanced course on software engineering work in Section5. and demonstrate how to implement and scale course- integrated empirical studies. 2 Background and Related Work 3 Course-Integrated Mini-Projects Using empirical studies in software engineering education is not a new idea [2]. However, empiri- We present the course-integrated mini-projects ap- cal studies—notably (controlled) experiments—are proach in Section 3.1. The presentation includes the mainly used as a tool to support research using stu- description of the team setups, project and task de- dents as subjects, but got little appreciation as a teach- scriptions, and examples for which we present details ing tool in software engineering in the first place. in Section 3.2. Section 3.3 demonstrates two inte- That is, students only get in touch with empirical gration strategies: the first integration strategy is a studies as subjects in an empirical inquiry, and they self-contained course on empirical software engineer- have to carry out tasks, e.g., in an experiment as for ing [14] and the second strategy is a topic-specific instance reported in [7,8, 18, 20]. Yet, teaching em- part of an advanced software engineering course. pirical software engineering as a subject requires a 3.1 Mini-Projects and Project Teams setup in which empirical studies are the main sub- Figure1 shows the general organization model for the ject or at least provide a significant contribution to mini-project approach. A MiniProject has a Topic, a a course. In this regard, Wohlin [26] proposes three Schedule, and optional Reference Literature and levels for integrating empirical studies in software Input Data. It is always carried out using at least one engineering courses: (i) integration in software en- Method, e.g., an experiment [27], a case study [25], gineering courses, (ii) as a separate course, and (iii) and a survey [21]. Finally, every mini-project consists as part of a research method course. Wohlin men- of a Project Team and an Advisory Team, which we tions that introducing empirical software engineering describe in more detail in the following. will provide more opportunities to conduct empirical studies in student settings, but that educational and 1 1..* research objectives need to be carefully balanced. Dil- Mini Project Result lon [4] comes to the same conclusion and considers - Topic [1] - Schedule [1] a successful observation of a phenomenon as part of - Method [1..*] - Reference Literature [*] joint research an empirical study not be an end in itself. Students - Input Data [*] I need time to get familiar with ideas and concepts request 1 1 1 associated with the phenomenon under observation. advice 0..* Advisory Team Project Team Finally, Parker [22] considers experiments distinctive provide 1 1..* 1 0..* and more participative. Students are likely to remem- advice 1..* S ber lessons associated with experiments. shared Advisor 2..* research design In this paper, we present an approach that considers Student empirical studies major subjects of a course and that Teacher Practice Team uses such studies as teaching tool. Referring to estab- External Advisor Method Team lished learning models such as Bloom’s Taxonomy of Service Team Learning [1] and Dale’s Cone of Learning [3], we aim to include as many active learning parts as possible in the courses. Still, we use passive learning methods Figure 1: Overall organization model of mini-projects. to transfer knowledge about theoretical basics, such as methods and their application contexts. Address- ing the active learning levels, however, is challenging. Advisory Teams An advisory team bundles all advi- In “ordinary” software engineering education, project sors involved in a specific mini-project—usually one courses are used to train software project work. For or two persons. An Advisor is either the teacher of empirical studies, it is required that the students carry the course or an external advisor, such as an external

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 76 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Style Description Item Description Isolated The “normal” way of doing a mini-project is Metadata This section contains all information rele- the isolated way of working. Isolated means vant to a task, e.g., hand-in date. that a project team has a self-contained task Title A project needs a telling title and an ID that can be worked on without any interaction Context This section briefly describes the context of with other teams. the project and provides a short summary Joint This style is applied if project teams collabo- of the basic tasks. Recommendation: the ratively work on a joint (research) project.A context section should be treated as an ab- complex project is broken down into a num- stract, such that it can be used as a teaser ber of smaller projects. Project teams thus and a small piece of information, e.g., used have to be coordinated in terms of task distri- in a course management system. bution, scheduling, and result synthesis. Work The detailed work description contains at Shared This style is applied if project teams competi- Description least: tively work on the same (research) topic. Two 1. A detailed task list. or more teams are assigned the same task; team-specific methods can be varied and re- 2. A list of input/reference material. sults can be compared. That is, this style helps 3. A list of deliverables to be shipped. conducting controlled experiments or imple- Note: The level of detail depends on the menting independently conducted studies. actual task, i.e., for an “explorative” task, the description needs to be more open while Table 1: Overview of the different interaction styles a specific development task requires a more among mini-project teams. detailed task description. Schedule The basic schedule lists all deadlines and the respectively expected results. project topic sponsor [14]. Besides offering and pro- Related Our concept allows for collaborative and moting project topics, advisors regularly interact with Projects competitive work (Figure1 and Table1). If the project teams for which they handle individual such a collaborative/competitive work style support requests, and they provide general technical is implemented, this section provides the in- and methodical support. formation about the other teams. If method or service teams provide useful services to a project, such teams are referred here too. Project Teams A project is composed of all students Literature This section lists selected reference litera- working on a specific problem. Project teams can ture relevant to a project. interact with each other. We distinguish the three interaction styles isolated, joint, and shared, which are Table 2: Structure of a mini-project task description explained in Table1. Furthermore, we distinguish (recommended minimal elements). three types of project teams according to the type of task they are working on: a Practice Team performs an “active” task, e.g., a development task or a fied right here; alternatively, a separate catalog of re- research task. A Method Team deals with methodologi- sults has to be provided, e.g., including templates and cal expertise, i.e., it develops competencies regarding mandatory/recommended outlines. Relevant types specific (scientific) methods and offers “consultancy for project outcomes are, e.g., (research) data1, es- services” in terms of applying a specific method “right” says or reports, presentations, tutorials, and software. to practice teams. Finally, a Service Team develops The second important item of the task description is skills in more general topics, such as data analysis or the list of related projects. For instance, if a task is a presentation, and offers respective “services” to other collaborative task, this list refers to all related projects teams—practice teams and method teams alike. that contribute to the overall project goal. Further- 3.2 Project- and Task Descriptions more, this list also refers those method and service teams that provide useful support, e.g., if the project Every mini-project is supposed to produce at least is concerned with developing and conducting a survey, one Result. In this section, we provide a blueprint this list can refer to a method team that is focused for a 1-page project- and task description, which also on the theoretical aspects of survey research. Finally, illustrates the manifestation of the different attributes the task description can also be used to develop a of the class Mini Project (Figure1). checklist, which is used for the final submission. This For every project, a description that includes tasks, checklist helps students to check if their delivery pack- dates, and expected results is necessary. Table2 pro- age is complete, and it helps teachers validating the vides a summary and a description of task-description delivery and grade its components. Figure2 shows items that we consider relevant. The work description requires special attention as it comprises the de- 1Recommendation: If students conduct a research task, analyzed tailed activity list, input material, and the description data that is necessary for the project documentation must always of expected results. The expected results are speci- be complemented with the original raw data.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 77 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Study Type SCM ASE Gr Top Gr Top Theory (tutorial) 9 9 Experiment 1 1 2 1 Survey 4 2 3 1 Systematic Review 3 2 1 1 Mapping Study 1 1 Simulation 2 2 Data Mining Study 7 3

Table 3: Overview of the study types implemented including the number of groups for a speciﬁc method (Gr) and the number of topics per study type (Top).

Introduction and Fundamentals

Presentation and Scientific Writing

Model Paper Reviews Lecture Exercise Exercise Lecture Introduction to Figure 2: Example of a mini-project task description. Empirical Research

Presentations: Theory and Tutorial Topics a practically used example of a task description as described in Table2. This task description is taken Status Control and Guest Lectures theory experts from the course given at University of Southern Den- help practice mark and describes a survey research task, which Status Control and teams… was performed collaboratively with two external re- Guest Lectures searchers [9]. This particular project was a collaborative project. Speciﬁcally, two teams (No. 15 and 16; Presentations: Secondary Studies see the related projects part) were assigned one task, but had to conduct the survey with different target Presentations: Experiments and groups. Each team submitted its own data and report, Simulations but, both teams gave only one joint presentation.

3.3 Course-Integration Strategies Presentations: Survey Research e.g., (incl. SLRs or surveys presenting and writing) Self-directed Self-directed learning: working on topics,the selected We describe two implementation strategies for the Group Papers’ presented approach using two graduate courses. For Peer Review these implementations, we provide a short summary of the respective courses and their learning goals, and Evaluation and Wrap-Up we provide an overview of the projects implemented in the respective courses (Table3). Furthermore, this section lays the foundation for the approach’s evalua- Figure 3: Overview of the topics and the general orga- tion, which is presented in Section4. nization of the SCM course. 3.3.1 Implementation as a Self-Contained Empirical Software Engineering Course cally, the major learning goals of the SCM course were defined as follows: A course on the Scientific Method (SCM, University of Southern Denmark, SDU, 2016) implemented the • After the course, students know the basic terminol- presented approach as a self-contained master-level ogy and the key concepts of the scientific method. course. Figure3 illustrates the overall organization of the SCM course showing the introduction parts and • After the course, students know and understand the active learning/project parts. the most important empirical research methods. The goal of the SCM course was to teach empirical • After the course, students have shown their ability software engineering as main subject by letting the stu- to practically apply one research method, conduct dents perform small studies themselves [14]. Specifi- and report on a small research project.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 78 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

In total, 30 research topics were presented to the stu- Overview Software dents. According to their preferences, students could Engineering apply for up to three topics, which built the founda- Empirical Methods in tion for the final team setup. Finally, 20 projects were Software Engineering started with two to three students each. Besides the Software Process theoretical topics, five research methods were covered Models Complementing by the projects (Table3). Material/Activities: The SCM course implements the concept from Fig- Lectures Modeling Languages Topic-specific ure1 as follows: method teams became theory teams empirical studies for those students that did not want to carry out Model and tutorials a study, but wanted to learn more details about a Transformations specific method or technique, e.g., the systematic re- Technical Software Engineering view method [13]. Service teams became cross-cutting Predictive Models teams that build up a specific expertise and consulted Overview: Empirical Methods in Software theory and practice teams. The 20 teams were con- Engineering (Experiments, Surveys, Data nected with each other, e.g., a theory team supported Mining, Secondary Studies) one or many practice teams, and both were supported by cross-cutting teams. The teacher supervised the Presentation of Project Topics individual teams as well as the groups of collaborating teams. The teams were formed right in the first ses- Topic Selection and Team Building sion of the course and, thus, the projects became the Initial Project Feedback main subjects to build the learning experience upon. writing) 3.3.2 Integration in an Advanced Software Weekly Standup (Project Progress) Engineering Course A course on Advanced Software Engineering (ASE, Uni- Final Project Presentations versity of Innsbruck, UI, 2017) implemented the pre- Final Project Feedback sented approach as part of a master-level course on Self-directed learning: working on the selected topics, e.g., (incl. SLRs or surveys presenting and software engineering in which empirical studies com- Project Evaluation plemented the (technical) software engineering topics. These technical software engineering topics were organized around the concept of models in software Figure 4: Overview of the topics and the general orga- engineering and covered software process models (in- nization of the ASE course. cluding agile process models), modeling languages including UML and DSLs, model transformations as well as predictive models, e.g., for defect prediction. Figure4 illustrates the overall organization of the ASE 13 projects were started with two to three students course showing the introduction parts and the active each. The projects covered four research methods and project parts. six topics (Table3). The overall goal of this course was to teach students advanced topics in software engineering and to let stu- The concept from Figure1 was implemented as fol- dents make the experience of the value that empirical lows: the 13 project teams were formed as practice studies have to support software engineering activi- teams. Since the empirical studies were designed to ties. Specifically, the major learning goals of the ASE complement selected topics of the ASE course, no ex- course were defined as follows: plicit method teams or service teams have been formed. That is, all practice teams worked on specific topics • After the course, students know and understand and developed the technical skills and parts of the different advanced software engineering concepts. required methodological skills themselves. Additional methodological skills were delivered to the teams by • After the course, students know the basic empir- the teachers and guest lectures, who also acted as ical research methods and know how to utilize advisors. Teams were formed when the mini-projects empirical studies in the different software engi- were assigned to the students. neering activities. • After the course, students have shown their ability to practically apply one research method to a 4 Evaluation specific software engineering activity, conduct and report on a small research project. In this section, we present the research design and evaluation strategy in Section 4.1, the results and a In total, eight topics have been proposed to the stu- discussion in Section 4.2, and threats to validity in dents and students could apply for the topics. Finally, Section 4.3.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 79 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Research Questions course, and the second data collection, again, in the course’s final evaluation when the mini-projects have RQ 1 Do course-integrated empirical studies (mini- projects) help students improving their work ap- been finished. All four questionnaires including a 2 proach? We aim to study if course-integrated summary are available online . empirical studies (mini-projects) help students Our questionnaire design allows for a 2-staged data better understand the value of structured scien- collection that helps observing changing student per- tific work approaches. For this, we investigated ceptions and evaluating the courses over time. The the following detailed questions: questionnaires share a number of questions to allow RQ 1.1 Do mini-projects support a better/more effective for comparing courses, the implementations of our learning? approach, and to qualitatively analyzing the student RQ 1.2 Do mini-projects support a better understanding feedback. As a learning from the SCM data collection, of concepts? the two ASE questionnaires put more emphasis on the RQ 1.3 What are the perceived learnings of mini- single phases of the scientific workflow, e.g., by specif- projects? ically asking for challenges and difficulties regarding RQ 2 Do course-integrated mini-projects help students the design of research instruments and conducting better understand the role of empirical studies? the data collection. Different to the questionnaires We aim to study the general attitude towards used in the SCM course, is the ASE questionnaires, empirical studies, i.e., do students change their students were asked to provide nicknames (to ensure attitude once they actively conducted an empirical study. For this, we investigated two anonymity), such that tracking individual students detailed questions: was possible to evaluate specific ratings and to evalu- RQ 2.1 Do mini-projects change the attitude towards ate such ratings over time. empirical studies? RQ 2.2 Do course-integrated empirical studies studies Analysis Procedures All four questionnaires pro- help understanding challenges (revealing mis- duce quantitative and qualitative data. For the quanti- conceptions)? tative analysis, we primarily use descriptive statistics RQ 3 What are the perceived pros and cons of the to analyze the four measurements individually, over mini-project approach? We aim to study dis- time per course, and for analyzing both courses. Fur- /advantages perceived by students that partici- thermore, due to the questionnaire’s evolution, for pated in mini-projects. the ASE course we could conduct additional inferen- tial statistical analyses, e.g., hypothesis testing and Table 4: Overview of the research questions studied. correlation analysis. To qualitatively analyze the data, we used the free- text answers provided by the students. For the ASE 4.1 Research Design and Evaluation course, an analysis of general learning and learning Strategy outcomes was performed using the questions for the We evaluated our approach in two master-level expected learning outcomes, and the questions about courses at two universities and by surveying the par- the learning regarding the mini-project topics and ticipating students. In this section, we present our the way of conducting empirical research (Appendix; research questions, outline the survey instrument, and variables MP6–MP8). An overall analysis of the course describe the data collection strategies. as such (in both courses) was performed using the questions for the courses’ appropriateness, the lectures Research Questions To evaluate the proposed mini- and exercises, and the perceived relation to practice project approach, we aim at answering the research (Appendix; variables GC2–GC4; interpreted as school questions listed in Table4. Our three top-level re- grades). The coding of the feedback into categories search questions address the (general) learning ex- was jointly performed by the two authors. perience, the usefulness of the approach in terms of improving the understanding of the role of empirical Validity Procedures To mitigate threats and to en- studies, and the perception concerning the pros and sure the validity of the instrument, we reused a ques- cons of the approach presented. tionnaire design that was already applied to other courses and that received an external quality assurance [15,18]. The original questionnaire design was Data Collection To collect the data, we (initially) extended by specific questions to evaluate the suitabil- developed two online questionnaires for the SCM ity of the mini-project approach. course based on Google Forms [14]. The first questionnaire was used in a mid-term evaluation; the second (extended) questionnaire was used for the final eval- Demographics In total, 68 students were enrolled uation. While preparing the ASE course, we revised in the SCM course of which 39 students participated both questionnaires and conducted the first data col- 2Appendix: https://kuhrmann.files.wordpress.com/2018/ lection before we started the mini-projects in the ASE 11/appendix-draft.pdf

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 80 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Category SCM, n=38 ASE, n=29 RQ 1.2: Support for a better understanding of con- Mean SD Mean SD cepts A key to provide value to the students is to Course complexity 2.87 0.66 2.62 0.55 make software engineering concepts better/easier to Course speed 3.05 0.76 2.83 0.38 understand. For this, students were asked to rate the Course volume 2.58 0.91 2.10 0.76 statement: “The mini-projects helped me understanding concepts better”, i.e., whether or not the understanding Relation to Practice 2.11 0.99 2.34 1.03 of concepts of interest has been improved. In this context, an investigation of the role of empirical studies is Table 5: Results of the final course evaluation. provided in Sect. 4.2.2. Again, the majority of the students (92% for the SCM course and 69% for the ASE in the initial evaluation, and 38 in the final evaluation. course; Figure6) considers the mini-project approach In the ASE course, 33 students were enrolled, and 29 advantageous for gaining a better understanding of students participated in both evaluations. From the software engineering concepts. 29 ASE-students, 27 provided a nickname that was used in the subject-based analyses. Table5 gives an overview of the general course evaluation. Students ASE 6 14 5 3 1 of both courses perceived the course complexity, speed SCM 13 22 2 1 and volume as moderate and see a good relation of 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% the course to practice. Fully Agree Somewhat Agree Indifferent Somewhat Disagree Fully Disagree 4.2 Results and Discussion This section presents the findings of the evaluation of Figure 6: Results for the improved understanding our proposed course-integrated mini-project approach. from final questionnaires (SCM: n=38, ASE: n=29). The following sections present the findings according to the research questions described in Table4. 4.2.1 RQ 1: Improved Work Approach RQ 1.3: Perceived Learning The question for the With RQ1, we aim to study if course-integrated mini- perceived learning is answered using five statements projects help students understand the value of a struc- (Appendix, MP2.4–MP2.8). In particular, we were inter- tured scientific work approach. To better structure ested to learn about the perceived impact to the later the findings, we defined three sub-questions (Table4), career (“The practiced scientific work approach will help which we discuss in the following. me in my later career.”) and shareable expertise built in the course (“I built a specific exercise that I could share with other teams.”), and a retrospective rating RQ 1.1: Support for a better learning This sub- of the group work in the mini-projects (looking back: question is addressed by the answers to the state- “contributed to my learning expericence”, “team work ment: “The mini-projects improve the learning experi- [..] was good” and “collaboration [..] was good”). ence”, which was quantitatively analyzed. Figure7 shows the aggregated results for the perceived learnings. Approximately 63% of the SCM

ASE 9 8 6 5 1 students and 59% of the ASE students think that the courses provide take-aways that will have a positive SCM 17 19 1 1 impact on their later careers. Concerning the share- 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% able expertise, 53% of the SCM students state that Fully Agree Somewhat Agree Indifferent Somewhat Disagree Fully Disagree they have obtained knowledge and expertise that they can share with others; 29% are indifferent. In the ASE Figure 5: Results for the learning experience from course, even though the course has more “practical” ﬁnal questionnaires (SCM: n=38, ASE: n=29). elements, only 41% of the students think that they built a shareable expertise, but 48% are indifferent. Figure5 shows the results (taken from the ﬁnal Concerning the general perceived learning experi- evaluation) for both courses and shows that 95% of ence and the teamwork within the project team, the the SCM-students consider the mini-project approach vast majority of the students rate the courses as good contributing to an improved perceived learning expe- and very good. However, the cross-team collaboration rience (3% each rate the teaching format neutral or shows a different picture—notably in the SCM course less effective than other teaching formats). For the in which interdisciplinary work was enforced by the ASE course, 59% consider the mini-project approach course design. In the SCM course, 29% of the students more effective, and 21% each rate it neutral or less considered the cross-team collaboration good to very effective. In summary, mini-projects contribute to an good, but 55% rated the cross-team collaboration bad improved perceived learning experience, especially in to very bad. Analyzing this phenomenon, we found the SCM setting, but also in ASE, where mini-projects the necessity for the different teams to interact with were only one part of the course. each other to obtain required knowledge from other

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 81 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Category Total SCM ASE ASE 7 10 6 3 3 Topic speciﬁc (i.e., mini-project topics) 16 2 14

career Empirical methods (e.g. experiments) 16 6 10 SCM 9 15 9 2 3 Help in later in Help Reporting ﬁndings (from studies) 13 13 0 Importance, meaning (emp. research) 12 2 10 ASE 2 10 14 2 1 Data management (in studies) 11 1 10 Effort (to plan/conduct a study) 10 0 10 SCM 4 16 11 6 1

Expertisetoshare Technical skills 3 2 1

ASE 8 8 7 2 4 Soft skills 17 12 5

SCM Cross-team 3 8 6 14 7 collaboration Table 6: Qualitative feedback for the perceived learnings of mini-projects from ﬁnal questionnaires. ASE 13 10 2 2 2

Teamwork SCM 16 13 7 2 of data) and reporting results of empirical studies are

ASE 10 11 4 2 2 highlighted. Students experienced that conducting an empirical study causes effort and might be a complex Learning experience SCM 13 21 3 1 endeavor (“It is hard to get results, which have a strong

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% meaning”). On the other hand, students also built an Fully Agree Somewhat Agree Indifferent Somewhat Disagree Fully Disagree understanding of the importance and the meaning of empirical research in software engineering (“The topic Figure 7: Results for the perceived leanings from final exists and is very useful if done correctly”). Finally, stu- questionnaires (SCM: n=38, ASE: n=29). dents hardly report learnings regarding technical skills (e.g., using LATEX or R). However, manifold learnings about soft skills (e.g., reviewing techniques) are reported, notably concerning teamwork and cross-team teams by also trying to keep their own schedule the collaboration (see also Figure7). most disappointing aspect. On the other hand, we found an “understanding” for this kind of work, which 4.2.2 RQ 2: Improved Understanding reflects reality in interdisciplinary collaboration and, This research question aims at investigating if students thus, students eventually considered this a significant built an understanding of the role of empirical stud- learning. Considering the ASE course, we wanted to ies. Specifically, if students consider empirical studies learn whether a similar behavior can be observed. As a valuable instrument to complement the technical Figure7 shows, cross-team collaboration is still con- software engineering activities in a beneficial way. sidered a problem, even though the heterogeneity of the project teams and thus the need to collaborate RQ 2.1: Changed Attitude towards Empirical Stud- was reduced. ies To learn about the students’ understanding of An in-depth analysis of the perceived learnings of the value of empirical studies, we asked the students mini-projects was performed by qualitatively coding whether their view on empirical studies has changed the responses of the free-form text questions (GC1: once they actively conducted an empirical study them- “What was your major take-home asset [..]?”, MP7: selves (“I like the mini-project part”). “What did you learn about the topic of your research project?” and MP8: “What did you learn about empir- ASE 5 10 3 9 2 ical research?”). For GC1, 26 students from the SCM course provided feedback. In the ASE course, 27 stu- SCM 9 23 3 1 2 dents provided feedback for MP7 and MP8. In total, 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% we extracted 38 statements from the SCM course and Fully Agree Somewhat Agree Indifferent Somewhat Disagree Fully Disagree 60 statements from the ASE course (for both questions). The students’ statements were categorized Figure 8: Results for the changed view on science based on keywords, and the threshold for building a from final questionnaires (SCM: n=38, ASE: n=29). category was set to three references. Table6 provides the condensed qualitative feed- Figure8 shows that 84% of the SCM students back on the perceived learnings in eight categories. changed their view on science and the value of em- Summarized, topic specific learnings (e.g., application pirical studies after conducting an empirical study of DSLs or comments in programming languages) as themselves. The ASE course provides a different pic- well as learnings related to the application of empiri- ture. Still 52% of the students changed their view, but cal methods (e.g., formulation of research questions almost 38% did not change their view on science and or application of specific empirical methods like sur- empirical studies. veys) were frequently mentioned. Also, data management (i.e., data collection, preparation and analysis

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 82 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

RQ 2.2: Challenges of Empirical Studies Besides the general perception of science and empirical stud- Final 3 6 7 12 1 ies, we are also interested in speciﬁc challenges. For Report Writing the Initial 3 3 8 11 2 this, we revised the questionnaire (see Appendix) and added questions that explicitly address the scientiﬁc Final 1 6 11 8 3 work process. Analysis Initial 1 4 10 8 3 3 Performing Data

Activity Results p-value Final 6 6 11 5 1

Deﬁnition of research questions V = 80 0.5257 Initial 2 3 13 8 1 2 Working with scientiﬁc literature V = 55.5 0.4927 Collection Data Design of research instruments V = 68 0.3254 Final 4 3 13 7 1 1 Implementation of instrument V = 43 0.7808

Instrument Initial 2 5 9 10 3

Data collection V = 135 0.0277 Implementation

Performing data analysis V = 107 0.9529 Final 2 7 6 12 1 1 Writing the report V = 106 0.3698

Design of Design Research Initial 2 4 6 10 4 3 Instruments Table 7: Results of the paired Wilcoxon signed-rank Final 3 4 9 10 1 2 test for the ASE course (n=27). Scientific Literature Initial 7 8 11 3 Wo rking with To study the perceived challenges students face Final 2 8 6 11 2 when implementing empirical studies, we asked the Research Questions Initial 2 6 6 12 1 2 students to rate the different parts of the scientific of Definition work process (Appendix, variables MP5.1–MP5.7; see 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% also Table7). Furthermore, 27 students enrolled in St raight forward Fairly easy Indifferent Somewhat difficult Very difficult Not applicable the ASE course provided a nickname, which we used to investigate challenges over time by evaluating the Figure 9: Overview of the perceived challenges on the initial and the final questionnaires. We performed different scientific work activities in the ASE initial a Wilcoxon signed-rank test to compare if there are and final questionnaire (n=29). significant differences between the initial perception of the scientific work process and the final one after the study has been performed. Table7 shows the test ing the responses of the free-form text questions (GC2: results for the various parts of the work process. “Up to 5 things that were good” and GC3: “Up to 5 The results show that only for the activity data col- things that were bad”). lection there is a significant difference (p < 0.05). In the SCM course data for GC2 and GC3 was col- This indicates the perceived difficulties and challenges lected in the initial and final questionnaire. For the regarding the data collection changed for the partici- ASE course, data was collected in the final evalua- pating students. A Spearman rank correlation coeffi- tion only. Hence, for the data analysis presented in cient for the initial and final feedback on the level of the paper at hand, we only consider the data col- challenges regarding the data collection is low (ρ = lected in both final evaluations. In the SCM course, 29 0.2775), which further indicates that there is only a students provided comments in the final evaluation. weak positive correlation between between the data Respectively, 21 ASE students provided feedback on collection challenges perceived initially and the chal- perceived dis-/advantages. In total, we extracted 72 lenges perceived at the end. Figure9 shows the uncor- pro- and 42 con-statements from the SCM feedback, related perceived challenges regarding the different and we extracted 54 pro- and 23 con-statements from activities in the scientific work process (collected in the ASE feedback. Both feedback sets were catego- the ASE course; initial and final questionnaire). rized and analyzed based on keywords (qualitative We conclude that the data collection is an activity coding), whereas the threshold for a category was set in empirical studies for which challenges can be easily to three mentions. Table8 provides the aggregated over- and underestimated. When teaching empirical qualitative feedback on the perceived pros and cons of software engineering it is therefore important to put the mini-project approach in nine categories grouped special emphasis on the important role of data collec- by SCM, ASE, and in total. tion and its challenges to prevent students from over- or underestimating the required effort. General Perception In summary, the mini-project 4.2.3 RQ 3: Perceived Dis-/Advantages approach was seen very positive. For both courses The third research question aims to investigate the SCM and ASE, the students identified considerably perceived advantages (“pros”) and disadvantages more pros than cons on the mini-projects. In both set- (“cons”) of the mini-project approach. For this, we tings, i.e., SCM (a self-contained empirical software qualitatively analyzed the students’ feedback by cod- engineering course) and ASE (a part of a software

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 83 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

Category SCM ASE Total ture (“A little slow lectures”) and the general schedul- -,-,-, ing and coordination of the lecture with other obli- Structure, organisation 18 14 9 11 27 25 gations (“During examination time, time overlap with Knowledge transfer 18 3 3 2 21 5 studying”). Mini-projects 14 3 6 2 20 5 Research, tech. skills 6 2 8 1 14 3 Effort Finally, the effort caused by the courses was Topics 6 4 7 0 13 4 Relevance 3 3 9 0 12 3 perceived negative in both settings. Feedback for the Guest lectures 5 7 6 0 11 7 SCM course says “The volume does not fit well a 5 ECTS Group work 2 1 6 1 8 2 point course” and, respectively, for the ASE course Effort 0 5 0 6 0 11 “Sometimes a single task was too big”. This feedback reflects a side-effect of project work that typically causes Table 8: Qualitative feedback on the perceived pros more effort than closed tasks—or even “listen-only” and cons of mini-projects from final questionnaires. classes. However, such comments motivate a revision of the projects, e.g., splitting tasks into smaller units to better support continuous work and to reduce the engineering course), the obtained research-related perceived effort in a short time frame, but still keep and technical skills were perceived very positive. The the learning effect of performing empirical research topics covered in the courses were positively evalu- as we received it also from the SCM comments “in my ated as well; especially in the ASE course in which opinion learning the scientific method without working mini-projects were integrated as a part of a software with the methods it’s only knowing about the methods, engineering course and focused on current (hot) top- not learning them.” ics in software engineering. Feedback and knowledge transfer were especially highlighted and considered 4.3 Threats to Validity positive in the SCM course with its different types of We discuss issues, which may have threatened the collaborating teams (dedicated practice, method and construct, internal and external validity as well as service teams), in-depth introductions to empirical measures to mitigate them. methods, and introductions and exercises in scientific reading and writing. Also, group work was generally considered positive, yet, the ASE course with its more Construct Validity The construct validity might be uniform teams was perceived more advantageous. As threatened by the two different implementations of already discussed in Sect. 4.2.2, the setting from the the approach presented and the instrument used for SCM course suffers from the teams’ heterogeneity and its evaluation. Although the two courses differed with the necessity to establish a cross-team collaboration, respect to the applied integration strategy for mini- which caused more effort for the project teams. projects, for both courses, we used the same yet tailored questionnaire and combined the responses. To increase construct validity, we developed the ques- Guest Lectures In both courses, guest lectures were tionnaire from an external source [15], which both given by external researchers. Considering the out- authors reviewed and evolved. Furthermore, we col- comes from Table8, guest lectures in the ASE course lected and combined quantitative and qualitative data were considered positive, whereas the guest lectures to answer and discuss the different research questions. in the SCM course received a more indifferent rating (with a slight tendency towards a negative evaluation). Due to the overall setup, the questionnaires differed We argue that this perception is related to the selec- between the courses. Hence, some analyses like the tion of the speakers rather than the course setting, yet, individual-based investigation of challenges over time this remains subject to further investigation. (RQ 2.2) were possible in the ASE course only. Fur- thermore, analyses regarding perceived learnings of the students had to be performed using different ques- From the organizational per- Course Organization tions (SCM: GC , ASE: MP and MP ; see Appendix), spective, the courses were perceived indifferent and a 1 7 8 which was handled using a multi-staged coding pro- relatively high number of positive and negative com- cess that resulted in common categories. ments was provided. On the positive side, students highlighted the organization and structure in general (“Organization was good”), and, in particular, also Internal Validity The internal validity might be the course assessment mode (“Fair grading system”) threatened by the rather low number of participants and the sequence of activities (“The mini-projects were and the participants’ self-reporting, which both might structured well—good planning of when to do the work, affect the relationship between course-integrated mini- when to make a presentation and when to turn in the projects and the investigated effects on learning and paper”). On the negative side, the overall flow was understanding of concepts and the role of empirical mentioned (“Things started to slow down way too much studies in software engineering. To mitigate these after the first 5 lectures”) as well as the speed of the lec- threats, we studied the integration of mini-projects

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 84 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal in two settings with an acceptable number of partici- increased importance of Data Science, Machine Learn- pants (SCM: 39 and ASE: 29). We also introduced the ing and Artificial Intelligence courses or even programs questionnaire to the students to minimize the risk of in general. In all these setting, effective and efficient misinterpretation. data collection and preparation for further analysis To triangulate the results of quantitative analysis is essential. Hence, we encourage other teachers to and to investigate the relationship between course- put special emphasis on all data-related activities, not integrated mini-projects and their effects holistically, only the data analysis. we also applied qualitative analysis to analyze the In summary, students provided an overall positive responses of the participating students. qualitative feedback on the course-integrated mini- projects as well as on the skills achieved and their External Validity The external validity might be relevance. This motivates to further explore and dis- threatened by the issue of the rather low number of seminate the presented approach. However, on the settings in which the course was performed and eval- downside, the students pointed out the overall flow of uated. However, we implemented and evaluated the the courses and the perceived high effort to perform course for each of the two course integration strategies mini-projects, which requires a further refinement of proposed in Section 3.3, i.e., self-contained empiri- the courses, e.g., by splitting it into smaller tasks of cal software engineering course and integration in uniform granularity. In future, we will therefore revise software engineering course. Two researchers from our approach accordingly and further disseminate it. two different institutions were involved in preparing, We also plan to perform further in-depth analyses of conducting and evaluating the courses. Furthermore, course artifacts, e.g., the students’ final reports, as we combined quantitative and qualitative data to get well as replications of the courses. a broader view on teaching empirical software engi- Finally, this paper presents an approach that has neering with course-integrated mini-projects. been implemented twice and it also provides initial The participants’ self-reporting might also affect the data. To get further insights and to improve the data generalizability of the results. To mitigate this threat, available, we cordially invite other teachers to adapt we introduced the questionnaire to the students to and integrate our approach into their courses and to minimize the risk of misinterpretation. Since the pa- share their experiences. per at hand is an initial study, we consider further in-depth analyses, e.g., of course artifacts like final References reports, and replications of the courses as well as the [1] L. W. Anderson and D. R. Krathwohl, editors. A transfer of the approach presented and its evaluation Taxonomy for Learning, Teaching, and Assessing: as future work. A Revision of Bloom’s Taxonomy of Educational Objectives, Abridged Edition. Pearson, 1st edition, 5 Conclusion 2000. In this paper we presented and evaluated an approach [2] V. Basili, R. Selby, and D. Hutchens. Experi- to teach empirical software engineering with course- mentation in software engineering. Trans. on integrated mini-projects. In such mini-projects stu- Software Engineering, 12(7):733–743, 1986. dents conduct small empirical studies in collaborating teams within a software engineering course or [3] E. Dale. Audiovisual methods in teaching. Dryden a research methods course. We illustrated the ap- Press, 3 edition, 1969. proach by presenting two integration strategies: first a self-contained course on empirical software engi- [4] J. Dillon. A Review of the Research on Practical neering given at the University of Southern Denmark Work in School Science. Technical report, King’s and second as part of an advanced software engi- College, 2008. neering course given at the University of Innsbruck. [5] F. Fagerholm, A. S. Guinea, H. Mäenpää, and Both implementations were complemented by a study J. Münch. Building blocks for continuous experi- that showed a positive learning experience and an mentation. In Proceedings of the 1st International improved understanding of (empirical) software engi- Workshop on Rapid Continuous Software Engi- neering concepts. neering, RCoSE 2014, pages 26–35, New York, More than half of the participating students state NY, USA, 2014. ACM. as a perceived learning of the course that empirical studies are helpful for their later careers (systematic [6] F. Fagerholm, M. Kuhrmann, and J. Münch. and evidence-driven work). In addition, a statistical Guidelines for using empirical studies in soft- analysis revealed that especially the data collection ware engineering education. PeerJ Computer activities are underestimated by the students, which Science, 3(e131), September 2017. allows for future improvements of university courses. We consider this aspect critical not only for empirical [7] D. Fucci and B. Turhan. A replicated experiment software engineering in particular, but also due to the on the effectiveness of test-first development. In

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 85 Using Mini-Projects to Teach Empirical Software Engineering Michael Felderer und Marco Kuhrmann, Uni Insbruck & TU Clausthal

International Symposium on Empirical Software [18] M. Kuhrmann and J. Münch. When teams go Engineering and Measurement, pages 103–112. crazy: An environment to experience group dy- IEEE, Oct 2013. namics in software project management courses. In International Conference on Software Engineer- [8] D. Fucci, B. Turhan, and M. Oivo. Impact of pro- ing, ICSE, pages 412–421. ACM, May 2016. cess conformance on the effects of test-driven development. In International Symposium on Em- [19] M. Kuhrmann and J. Münch. Enhancing soft- pirical Software Engineering and Measurement, ware engineering education through experimen- pages 10:1–10:10. ACM, 2014. tation: An experience report. In 2018 IEEE Inter- national Conference on Engineering, Technology [9] V. Garousi, M. Felderer, M. Kuhrmann, and and Innovation (ICE/ITMC), pages 1–9, June K. Herkiloglu.˘ What industry wants from 2018. academia in software testing?: Hearing practitioners’ opinions. In Proceedings of the 21st In- [20] K. Labunets, A. Janes, M. Felderer, and F. Mas- ternational Conference on Evaluation and Assess- sacci. Teaching predictive modeling to junior ment in Software Engineering, EASE’17, pages software engineers—seminar format and its eval- 65–69, New York, NY, USA, 2017. ACM. uation: poster. In Proceedings of the 39th In- ternational Conference on Software Engineering [10] V. Garousi, M. Felderer, and M. V. Mäntylä. The Companion, pages 339–340. IEEE Press, 2017. need for multivocal literature reviews in soft- [21] J. Linåker, S. M. Sulaman, R. M. de Mello, and ware engineering: complementing systematic M. Höst. Guidelines for conducting surveys in literature reviews with grey literature. In Pro- software engineering. Technical report, Lund ceedings of the 20th International Conference on University, January 2015. Evaluation and Assessment in Software Engineer- ing, page 26. ACM, 2016. [22] J. Parker. Using laboratory experiments to teach introductory economics. Working paper, Reed Col- [11] V. Garousi, M. Felderer, and M. V. Mäntylä. lege, http://academic.reed.edu/economics/ Guidelines for including grey literature and con- parker/ExpBook95.pdf, accessed 2014-10-23. ducting multivocal literature reviews in software engineering. Information and Software Technol- [23] K. Petersen, R. Feldt, S. Mujtaba, and M. Matt- ogy, 2018. son. Systematic mapping studies in software engineering. In International Conference on Eval- [12] M. Kasunic. Designing an effective survey. Tech- uation and Assessment in Software Engineering, nical report, Carnegie Mellon University Pitts- pages 68–77. ACM, 2008. burgh Software Engineering Institute, 2005. [24] K. Petersen, S. Vakkalanka, and L. Kuzniarz. [13] B. A. Kitchenham, D. Budgen, and P. Brereton. Guidelines for conducting systematic mapping Evidence-Based Software Engineering and System- studies in software engineering: An update. Inf. atic Reviews. CRC Press, 2015. Softw. Technol., 64:1–18, August 2015.

[14] M. Kuhrmann. Teaching empirical software en- [25] P. Runeson, M. Höst, A. Rainer, and B. Reg- gineering using expert teams. In SEUH, pages nell. Case Study Research in Software Engineer- 20–31, 2017. ing: Guidelines and Examples. John Wiley & Sons, 2012. [15] M. Kuhrmann, D. M. Fernández, and J. Münch. Teaching software process modeling. In Interna- [26] C. Wohlin. Empirical software engineering: tional Conference on Software Engineering, pages Teaching methods and conducting studies. In 1138–1147, 2013. Proceedings of the International Workshop on Em- pirical Software Engineering Issues: Critical As- [16] M. Kuhrmann, D. Mendez Fernández, and sessment and Future Directions, volume 4336 of M. Daneva. On the pragmatic design of lit- LNCS, pages 135–142. Springer, 2007. erature studies in software engineering: an [27] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, experience-based guideline. Empirical Software B. Regnell, and A. Wesslén. Experimentation in Engineering, 22(6):2852–2891, Dec 2017. software engineering. Springer Science & Busi- [17] M. Kuhrmann and J. Münch. Distributed soft- ness Media, 2012. ware development with one hand tied behind [28] H. Zhang, M. A. Babar, and P. Tell. Identifying the back: A course unit to experience the role relevant studies in software engineering. Infor- of communication in gsd. In 1st Workshop on mation and Software Technology, 53(6):625–637, Global Software Engineering Education (in con- 2011. junction with ICGSE’2016). IEEE, 2016.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 86 Experience Report on an Inquiry-Based Course on Model Checking

Sebastian Krings Universität Düsseldorf, Hochschule Niederrhein [email protected] Philipp Körner, Joshua Schmidt Universität Düsseldorf {koerner,schmidt}@cs.uni-duesseldorf.de

Abstract coming to grips with internal workings. In consequence, typical courses on model checking stay on a The development and improvement of model checkers theoretical level. Students often have no way of expe- for the validation of hard- and software is an ongoing riencing the practical aspects of developing a model research topic in computer science. Model checking re- checker. This leads to shortcomings in different areas: search connects theoretical and practical aspects; new algorithms are often implemented inside well-known • Learning results might be reduced due to missing model checkers which have been in development for hands-on experience. many years. This is seldom taken into account by university courses on the topic, which often remain • Regarding bachelor’s and master’s theses the on the theoretical level. Hence, they do not provide scope of topics is limited, as students have not practical access to the topic for reasons such as lack of learned how to appropriately address practical time or inaccessibility of tools and their source code. problems in model checker development. In this article, we present a recent revision of our • Missing experience in project work, tool usage course on model checking, shifting from a classical and working collaboratively have been identified lecture-based format to inquiry and research-based as major areas in which students do not meet teaching. We document course development, present expectations from industry (Radermacher u. a., some didactic methods used and evaluate the course 2014; Radermacher u. Walia, 2013; Tafliovich based on peer review and student feedback. Further- u. a., 2015). Those skills could be acquired en more, we try to assert student engagement empiri- passant in a programming project. cally. To improve, we decided to remodel our course on Introduction and Motivation model checking. The overall goal was to move from classic lectures to active learning techniques for an im- The development and improvement of model check- proved hands on experience. Furthermore, we noticed ers (Clarke u. a., 1999) for the validation of hard- and that students writing theses at our chair sometimes software is an ongoing research topic in computer sci- lack the required knowledge about how research is ence (Grumberg u. Veith, 2008). Model checking re- performed and thus need close supervision and initial search connects theoretical and practical aspects; new training. In order to motivate individual research and algorithms are often implemented inside well-known to enable students to train their skills, we decided to model checkers which have been in development for move from a classic lecture setting to inquiry-based many years. This is seldom taken into account by learning. In particular, we intended for the course university courses on the topic, which often remain to follow the typical pattern of asking appropriate on the theoretical level, not providing practical access questions for research, finding evidence or creating it for various reasons. through experiments, compare and discuss results as In particular, both complexity and code volume of well as explain and publish differences discovered. commonly used model checkers prevent students from During the course, participants should:

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 87 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

• Acquire the theoretical foundations of model enable participants to immediately continue with a checking by identifying and analyzing common masters thesis in model checking. software errors. There is a corresponding lecture on Safety Critical Systems, focussing on how to write software specifi- • Align these foundations with the body of knowl- cations and use model checkers and provers rather edge. than implement them. The two lectures are often attended one after the other. However, since we do not • Design and implement a novel model checker as enforce a particular order, Safety Critical Systems can independently as possible. not be considered a precondition for the course docu- Barron et al. (Barron u. a., 1998) identified four im- mented in this paper. For both courses, attendance is portant aspects contributing to the success of inquiry- not compulsory. based courses: Learning Objectives • Selecting appropriate learning goals, The learning objectives were already predefined and aligned with the overall curriculum. In consequence, • Begin with problem-based learning before gradu- we did not intend to change the high-level goals of ally switching to project work, the course. After attending, students should be able to • Enable self-assessment and revision, • present and compare different techniques for pro- • Develop an atmosphere and social structures that gram verification, support participation. • be able to summarize selected scientific literature Following, we discuss how we realized these aspects on program verification and be able to criticize in our course. where appropriate, Increasing practical relevance and self-responsibility • write their own specifications and evaluate them, aside, the course redesign serves another purpose. By implementing a novel model checker together with the • decide on appropriate formalisms, algorithms and students we rely less on locally developed tools and tools for given verification tasks. avoid tailoring towards in-house techniques. Instead, a course like the one outlined can help evaluating We believe these goals match the requirements stated alternative technologies together with our students. by Barron et. al. (Barron u. a., 1998). Additionally, the course provides other more long Former Course term benefits to the chair. First, we can use the result- The former course on model checking before the year ing software in bachelor’s and master’s theses, given 2017 was held in a classical lecture-based format. that it is more easily accessible than PROB (Leuschel The lectures dealt with the theoretical foundations u. Butler, 2008, 2003), the model checker developed of model checking. Lectures were accompanied by at our chair at the University of Düsseldorf. In partic- weekly exercises used to practice. There were no ular, it is written in Java, which most students know mandatory submissions but of course students were from their undergraduate studies, whereas PROB is encouraged to work on the exercises independently. written in Prolog, a language not as common. Sec- The course heavily relied on theoretical aspects of ond, it can serve as a playground for trying out more model checking, i.e., several theorems and lemmas experimental algorithms or backends. were proven in the lectures while others had to be Following, we start with introducing setting and proven by the students in the exercises. context of the course. Afterwards, we discuss goals Students were not supposed to implement any al- and challenges of remodelling the course using an gorithms throughout the course. Instead, the most inquiry-based format. In particular, we document important algorithms were discussed in pseudo-code preparation and execution phases. An evaluation of within the lecture. Moreover, the students were occa- student motivation and engagement will be performed sionally asked to create pseudo-code algorithms for as well. Evaluation and our conclusions lead to an- simple tasks on their own such as an explicit-state other iteration of the course which we describe later model checking algorithm for invariant checking. on, followed by overall conclusions about both itera- Students were not introduced in detail to any for- tions. malism for writing specifications but worked on an abstract level of formal modeling. However, the stu- Course Setting and Context dents have seen some small models in the lecture Our lecture on model checking is aimed at master without paying any attention to the used formalism students of computer science. In particular, the lec- but rather focussing on the overall structure. Apart ture is part of a major in software engineering and from this, the course remained theoretical neither of- programming languages. In consequence, it should fering any hands-on experience nor addressing issues

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 88 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein that might arise when implementing model checking scientific practice as well as the common parts of the algorithms. scientific publication process, e. g., peer-reviewing. In retrospect, we think that the majority of the students suffered from this lecture-based format, as it Challenges was not motivating them to work on more advanced Switching from a classic lecture to inquiry-based learn- topics of model checking. We think that focussing on ing result in a number of challenges: the theoretical aspects of model checking without any • hands-on experience might be daunting for students Cognitive requirements are higher, as we switch to work on that topic at all and hinders them to use from knowledge reproduction to production. model checking techniques in future projects. These • Course progression is less linear. In particular, insights have lead us to remodel the course in the next project progress will be fluctuating and has to semester, introducing more interactive elements and be monitored closely to allow for timely inter- practical experiences as we will outline below. ventions in case goals might become unreachable otherwise. Remodeled Course In the following sections, we will describe the remod- • Adding an additional programming task to the eled course in detail, starting with the participants, the curriculum increases the individual workload stu- goals and milestones of the redesign and the steps per- dents are exposed to. In consequence, individual formed in preparation, execution and postprocessing. motivation and commitment has to be increased. Additionally, we will discuss two teaching methods employed during the course. • Research has to be controlled in order to avoid getting off track. Students should have as much Participants freedom as possible, while still being guaranteed The first iteration of our remodeled course took place to reach the intended learning outcomes. in the summer term of 2017. There were 11 students attending, with 6 of them attending regularly. Three • Due to the higher amount of group work and students were undergraduates pulling up courses. cooperation, exams have to be prepared carefully to meet both the didactic requirements and the Goals ones posed by exam regulations. First, students should gain more practical access to model checking and how it connects to software engi- Documentation Preparation neering. Furthermore, the course should be connected As stated in Table 1, we began course preparation to recent research results. by collecting and inspecting existing lecture material In addition to teaching model checking, we want such as slides and exercise sheets. Furthermore, in to encourage independent research. In particular, this order to gain additional material, the latest literature includes supporting students throughout the common on model checking was sighted as well. research phases from finding a suitable hypothesis to Reducing existing material to make room for the publication. programming tasks proved difficult for two reasons: Target Milestones • It was hard to anticipate the speed with which stu- The target milestones are divided in three stages: dents would progress. As this is our first inquiry- 1. Planing and preparation. based attempt at teaching model checking, we could not rely on previous experiences. 2. Implementation and supervision of the research project. • As stated above, we intended for the module to be as open as possible. In particular, we wanted to 3. Publication and presentation of results. avoid predetermining techniques and algorithms to be used. However, this made it impossible to Individual milestones are given in Table 1. The third anticipate what the students would come up with phase is not completed as of yet: While we ensure first. We needed to prepare for several possible reproducibility for upcoming terms, research results pathways through the course. have not been published. This is mostly due to dates and deadlines of appropriate software engineering To reduce overhead, we decided to reduce content conferences. As a successful publication cannot be even more, until we reach the bare minimum of model guaranteed, it is not an essential part of our lecture checking knowledge. Additionally, we prepared sev- and will not be considered further. eral collections of articles, slides and exercises for So far, three of the six regularly participating stu- different subtopics. As soon as speed and direction dents are willing to contribute to a research paper. We of student research can be asserted, we could add or will use this opportunity to explain the rules of good remove collections as needed.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 89 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

Table 1: Phases, Milestones and Time for Completion

Preparation 1. Inspection of existing material 5 h 2. Literature research and selection, collect relevant papers and documentation to be supplied 5 h to students 3. Didactic reduction: make room for programming tasks by reducing course content without 5 h omitting learning outcomes 4. Prototypical implementation to assert difﬁculty level and needed effort, identify obstacles 10 h Execution 5. Project and time management, task distribution, team building (done in lectures) 13 h 6. Discussion, monitoring of results (outside of lectures) 15 h 7. Further implementation work, bugﬁxing (outside of lectures) 13 h 8. Peer review by didactics department 6 h Postprocessing 9. Collecting results, documentation 10 h 10. Benchmarks and performance evaluation 10 h 11. Publication process 10 h 12. Evaluation and preparation for upcoming terms 5 h Total 107 h

To assert the overall workload and to identify possi- oriented instead of immediately confronting students ble obstacles, we developed a prototypical implemen- with the need to develop a research question them- tation of a model checker suitable for the course. By selves1. To do so, we followed a four-step approach doing so, we learned that developing a parser for B, to introduce model checking: i.e. a software that turns the human readable repre- • sentation of software into a machine readable form, Error- and hazard analysis of an elevator control is a more time-consuming task than we initially sus- software, pected. Furthermore, we all had attended lectures • Introduce specification languages, by discussing a on compiler construction and thus had at least the- reduced version of the B language (Abrial, 1996). oretical knowledge in writing parsers. However, as stated above, we could not assume the same of the • Collaboratively develop key definitions such as participating students. state spaces and transitions, In consequence, we decided to make our prototypi- • Collaboratively develop a simple explicit-state cal parser available for the students instead of making model checking algorithm. it a part of the programming project. This allowed us to focus more on model checking itself, rather than We decided to rely on B as an input language, spending time on infrastructure. While this somewhat mainly because it is the specification language most reduces possible learning outcomes, we still feel our commonly used at our chair. However, it is a rather decision is justified. This is stressed by the fact that complex language with many features students had several other lectures, e. g., compiler construction, dy- to learn. In retrospect, a simpler language could have namic programming languages or logic programming, been used without reducing learning outcomes. In feature the development of parsers. consequence, the course was modified for later iterations, as we will discuss later on. Documentation Execution In the following sessions, we switched to a more In the following section, we will document our experi- inquiry-based approach: For instance, the reduced ence in course execution. In particular, we will discuss input language did not include a way to specify cer- how we introduced the topic and helped students for- tain system properties. As students were writing mulate initial research questions. Following, two key their own software models in order to gain test cases, methods used throughout the course are discussed. those shortcomings became obvious. In consequence, We conclude with our approach to grading. students had to come up with language extensions and develop new model checking algorithms to verify Developing a Research Hypothesis them. Following the work by Barron et. al. (Barron u. a., 1For a comparison on inquiry-based and problem-based learning 1998), we decided to start our course problem- see, for instance, (Oguz-Unver u. Arabacioglu, 2014).

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 90 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

Of course there are different extensions to simple ing processed, tasks follow a predefined live cycle by explicit-state model checking. We intended for the moving from and to different stacks: students to find them independently as well as share and discuss their findings. To avoid errors, we had 1. Backlog - Newly created tasks start here. If a four lectures allocated to scientific foundations. In task is not actionable, because a precondition is summary, those were barely needed, as our students missing, a new flashcard for the precondition is were able to independently discover and provide foun- added. If a task is too large or to unwieldy to dations. Without further guidance, they managed to handle, it is split into multiple subtasks. Tasks do literature collection and research and were able to that can be approached now are moved to the draw appropriate conclusions for further development. next stack. Furthermore, they managed to bridge the gap to their 2. To Do / Ready - Includes actionable tasks that can undergraduate studies where needed autonomously. be addressed right now. Students can pick a task Teaching Methods and assign it to themselves. Once this happens, the task moves forward. In the following sections, we will discuss two teaching and organization methods, which we used throughout 3. In Development - Tasks in process by someone. all lectures. The two methods complement each other: Each task in this stack has someone responsible The hazard collection helps keeping in mind the big for its handling assigned. picture. In contrast, the Kanban board is used to structure the programming project into parts and helps to 4. Testing / In Review - Task that the assigned stu- discover and tackle todos in an organized manner. dents consider finished are moved here. For qual- Collection of Hazards ity control, another student has to verify whether the task has been handled satisfactorily. This is To motivate the how and why of model checking, we usually done by adding automatic test cases and began the first lecture with a simplified hazard anal- by performing manual code review. If problems ysis. Working in groups, students were supposed to are identified, the task is moved back to “In Devel- describe behavior scenarios of an elevator that per- opment”. Added test cases and comments should forms as bad as possible. Scenarios were collected now help find a better solution. Otherwise, the and sorted, first by grouping corresponding ideas such task is moved to the next stack. as “the elevator never opens its doors” and “the elevator never closes its doors”. The resulting collection is 5. Done - Tasks that have been finished and verified. shown in Figure 1a. Not all of the identified scenarios can be prevented We used a virtual board on GitHub as shown in Fig- using a model checker. We thus supposed to reorga- ures 2 and 3. The method proved easy to learn for nize our collection by two axes: The dangerousness students and efficient in handling programming proof the scenario and the extent to which the elevator cess. Furthermore, it served as a documentation of control software is involved. The sorted collection is participation that could be considered for grading, as shown in Figure 1b. In the upper right corner, we we will discuss in the following section. see those scenarios that should be considered first, Grading i. e., those that are hazardous and primarily caused by software defects. As the course was teaching both theoretical and practical aspects of model checker development, exams We keep the collection around during the course were supposed to measure both parts. In additional, of the semester, removing those cards representing we had to ensure that grading complies with the exam- errors our model checker was able to detect. In conse- ination regulations. In particular, regulations enforce quence, the hazard collection was driving the inquiry- grades to be based on individual performance, i.e., based learning process: While some errors were easy group work can not easily be taken into account. to detect using simple explicit-state model checking To improve constructive alignment (Biggs, 1996), techniques, others made more involved techniques we implemented a combination of formative and sum- necessary. For instance, a property such as “If the mative exams: elevator is moving, doors are closed” is comparably simple to verify. In contrast, “At some point in time • Constant participation in the programming project the elevator is moving”, is more involved due to time- was documented using the Kanban project man- based reasoning. agement method as outlined above. As changes Project Management using Simplified Kanban in tasks and issues were recorded together with Boards the student’s username, following the individual To manage programming tasks and how they are dis- contribution was easy. This formative part mostly tributed between the participants we used a method considered the individual contributions to the pro- based on simplified Kanban boards. Every occurring gramming project and takes into account that dif- task is collected on a (virtual) flashcard. While be- ferent parts of the model checker were developed

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 91 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

(a) By Topic (b) By Hazardousness / Software Inﬂuence

Figure 1: Elevator System - Hazard Analysis

Figure 2: Kanban Board, Part 1

independently. For example, UI and model check- • The goal to enable the students to present and ing core were developed by different students and compare different techniques for program veri- at different times. fication was verified using project contributions. Students had to decide between different algo- • Changes in attitude, development of soft skills rithms (i.e. compare) and they had to present the such as ability to cooperate and stance towards implementations during the reflection & evalua- ethical issues in software development could be tion sections. observed both in the live sessions and the online discussions. Of course, those cannot simply • The goal to enable the students to summarize se- be graded on observation alone and thus mostly lected scientific literature on program verification served for the lecturers to assert progress. and be able to criticize where appropriate, was partially covered by the reflection & evaluation • Theoretical foundations of model checking were sections. Additionally, we used the exam to ask verified by a written summative exam at the end students to select an appropriate algorithm for of the semester. Keep in mind that we had to given problems, i.e. to criticize weaknesses ruling reduce theoretical content to be able to fit in the out algorithms. programming project. • Students wrote their own specifications and eval- The combined exam is able to verify, whether the uated them in order to create test cases for the learning objectives stated above have been reached: programming project.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 92 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

Figure 3: Kanban Board, Part 2

• Again, we used the written exam to ask students For future sessions we decided to discuss and doc- to decide on appropriate formalisms, algorithms ument new ideas more thoroughly, including visu- and tools for given verification tasks. alizing them on a flip chart. Resulting documentation should also help later implementation. Course Evaluation This section will discuss several means of evaluation • For some ideas the group decided to be worth- we employed to measure the success of the redesign. while of further experimentation, the next steps We will discuss review by other faculty members as to take remained unclear. In particular, resulting well as student feedback and engagement. tasks have to be identified immediately and clear commitment to resolving them has to follow. Peer Review Two sessions were monitored and reviewed by other Reflection & Evaluation Session faculty members and members of the didactics depart- The second session that was observed was meant as a ment. Each time, certain weaknesses were spotted synchronization point between different groups work- and later fixed based on suggestions of the observers. ing individually. While certain students were working R & D Session on verification techniques for infinite software mod- The intention of the first observed session was to de- els, others were working on time-based reasoning. As velop novel model checking techniques in order to be discussed, both topics are considered essential for the able to detect more of the hazards collected in Fig- course. We thus decided to form focus groups with ure 1b. In particular, we tried to encourage research the intent of later updating the other groups. and experimentation and avoided discussing known Furthermore, presenting intermediate results to solutions beforehand. We decided to have the session other groups was intended to account for the appro- supervised in order to verify if we hit the sweet spot priate reflection upon the executed research tasks. As between student research and lecture progress. pointed out in (Blumenfeld u. a., 1991; Schauble u. a., The overall concept of the sessions and the belong- 1995), project-based work could otherwise focus too ing teaching methods were evaluated as coherent and much on the execution without evaluation results and aligned with the goals of the sessions. However, weak- lessons learned. In consequence, students would have nesses were spotted when it comes to student interac- less opportunity for self-assessment and revision, vio- tion and result summarization and recapitulation: lating one of the principles of successful inquiry-based courses stated by Barron et. al. (Barron u. a., 1998). • Sometimes, we failed to ensure that all students During the lecture, presentation of intermediate had understood the currently discussed idea well results was sluggish, students appeared to be only enough to participate in further discussions. In superficially prepared. In retrospect, we identified consequence, some ideas for new algorithms were our imprecise task statement as the most likely rea- developed within smaller groups of students and son. Again, we adapted following sessions in order to only later discussed with the group as a whole. improve:

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 93 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

• In addition to asking for a presentation of inter- Table 2: Average Grades mediate research results, we supply an outline: 2014 2015 2016 2017 2018 1. Short presentation of used techniques and # Students 2 5 7 6 5 how they are supposed to work. ∅ Grade 1.85 2.58 1.71 1.28 1.88 2. Summary of difficulties and solutions implemented so far. 3. Open problems, followed by a discussion work and participation, the average improves to 1.28 of possible solutions. (equivalent to US 3.9, “excellent”). For comparison, the average grades of different 4. Code examples and actual implementa- course iterations is given in Table 2. The low average tion where sensible. in 2015 is due to one student not passing. If only passing students are counted, the average improves • To increase student commitment, outline and pre- to 1.98. sentation content has to be discussed with the Judging by the average grades, the highly inquiry- lecturers beforehand (see milestone 6 in Table 1). based course in 2017 performed better than the lesson- Student Feedback based course in 2016. Furthermore, the next iteration Due to the small number of participants, no official of the course, which includes several improvements evaluation was performed by the university. For the we we will discuss below, again exhibits a slightly same reason, there are no former evaluations we could worse average grade. compare to. Of course, we would like to attribute the improved However, during the course, we performed several grades to the practical research experience, that stu- intermediate evaluations using short online surveys. dents could gain during the hands-on sessions. How- Feedback was very positive and encouraging. In par- ever, with only five to seven students participating in ticular, the course was described as both interesting the exams, the sample size is much to small to draw and challenging at the same time. Furthermore, stu- reliable conclusions. dents evaluated their own learning achievements as Student Engagement high. More sustainable learning was attributed to the increased self-reliance compared to other courses. One of the main challenges was to keep students moti- The main point of criticism was the volatile speed vated to participate in research and programming. In of progression during the lectures. While this is not particular, participation outside of lecture hours had uncommon for research-based processes, it turned out to be ensured. Given that we used Git to record all to be the major cause of frustration for students. As changes made to the source code, we can use the data an immediate remedy, we started to monitor progress collected for statistics on participation and engage- more closely and intervened early once students got ment. Apparently, we were able to motivate partici- stuck. For the next iteration of the course, we believe pants to consistently and autonomously work towards we should reconsider the balance between problem- the course goals. based and inquiry-based learning. For instance, this can be seen in Figure 4, showing a In order to gain more insight into workload, moti- so called “punchcard”. Time of day on the x-axis and vation and learning outcomes, we performed another days of the week on the y-axis form a grid in which feedback round when writing this article. dots of different diameters are drawn. The larger a dot The student’s workload was rated with an average is, the more extensively the source code was changed of 3.75 on a scale from 1 (= low) to 5 (= high). at that time interval. This is in line with our expactations and does not Of course by far the biggest amount of changes was suggest that the inquiry-based setup increased the made during lectures, exercises and tutorials, wednes- overall workload. Learning outcome was rated with day and friday 12 - 2 p.m. While these are the most an average of 4.375, while overall motivation was active phases, we can see student activity throughout rated with an average of 4.625, both again on a scale all days and times. Particularly pleasant is the con- from 1 (= low) to 5 (= high). stant activity occurring wednesdays at 7 p.m. and However, given the low number of course partici- fridays at 8 p.m. Apparently, they are caused by stu- pants, we cannot claim any statistical significance. dents revising lecture material and incorporating it into the programming project. Grades Another indicator for high motivation is that the In 2017, six students participated in the exam. With- project was both fascinating and motivating enough out taking into account the project work, all students to cause the occasional all-nighter. For instance, we passed the exam with an average of 1.43 (equivalent see source code changes thursdays at 3 a.m. and satur- to US 3.9 - 3.7, “excellent”). When taking into ac- days at 4 a.m. To determine if this is an indication of count the formative part of the exam, i. e., project motivation or high work load, we asked the students

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 94 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

Figure 4: Source Code Changes per Day / Time to evaluate. Students stated that late night work was Publication not due to high work load or last-minute submissions, The last state of inquiry and research, namely publi- but to individual interest, motivation and time man- cation, was not part of the course for several reasons. agement. As we already stated, the workload was First of all, preparing a meaningful publication takes rated as 3.75 on average, using a scale from 1 (= low) a lot of work and publication cycles can be quite time to 5 (= high). consuming as well. Thus, it was impossible to fit publishing into the course as well. Second, while publish- With the data depicted in Figure 5 we tried to ing teaches a lot about how the scientific community evaluate, whether students were indeed following works, it does not contribute to the course topic. an inquiry-based approach to the course topics. To Nevertheless, three of the participating students do so we tried to evaluate if progress was linear or if were interested in writing a follow-up paper and pre- students had to follow the typical research pattern of senting their work to the community. This gave us the finding approaches, try and experiment and later eval- opportunity to introduce them to the common publi- uate. The x-axis shows project progress from February cation process, including concepts such as peer review to September. Y-axis shows additions and deletions as well as pre- and post-proceedings of conferences. performed in the source code, i.e., the higher the The overall process went through a number of mee- green part, the more source code has been added to tups and discussion sessions: the project. The red part depicts deletions, that is the lower the red bar is, the more source code has been 1. In a first session, we discussed the publication remove from the project. process as it usually takes places.

The small peak at the begin of February is caused 2. For two sessions, we discussed how to write an by the lecturers developing a prototypical implemen- interesting paper, mostly following Simon Peyton tation as we discussed for the preparation phase. Lec- Jones’ advise on the topic (Jones, 2018). tures itself started in april. In summary, the graph 3. We did a brainstorming session in order to identify shows that a considerable proportion of the source the key research questions students answered dur- code added has been removed later on. The amount ing the course and to assert which of them would of lines removed rises and falls with the amount of be relevant to a larger audience. lines added. This hints at the fact that students did not only add new code once a new idea was developed. 4. We had several meetups to discuss the writing Rather, constant reevaluation lead to code being revis- progress and to synchronize us. ited or even replaced. Participants did not progress in a linear fashion. As the publication process was not part of any official lecture or university event, we were unable to Another interesting point is the peak mid of June. provide credit points to the participants. Yet, all three At that time, students developed certain ideas of “sym- of them were very enthusiastic about the idea of writ- bolic model checking” and started to implement them ing their first article. In retrospect, we believe that it in our tool. For this peak, there is no following peak was mostly the fact that we were aiming for a “real with deletions. This could mean that students made scientific workshop”, that was highly motivating. Stu- some fundamental progress by reinventing and realiz- dents felt as part of the scientific community and truly ing a classic idea of model checking. as peers among peers.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 95 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

Figure 5: Source Code Add / Delete by Date

To our joy, the paper (Petrasch u. a., 2018) was In consequence, we tried to find a middle ground accepted for the 18th International Workshop on Au- between focussing on the implementation of a model tomated Verification of Critical Systems, which took checker and a lessons-based course. place in Oxford, GB in January 2018. Two students As knowledge propagation was our most prominent attended the workshop, with one of them giving the concern, we decided early on that each student should presentation. It lead to fruitful discussions both about implement a model checker on their own. This is a the topic and about the course itself. As many of those trade-off between allowing exploration and hands-on attending were teachers themselves, success reports experience as well as feature-completeness, as obvi- of our hands-on approach were of particular interest ously a single student is not expected to do the work to them. that six students did beforehand. When switching from group projects to individual Lessons Learned - the Next Semester programming tasks, students do not gain experience Two terms after we remodeled the course, the next in best practices of software development in a team iteration took place. During the preparation stage, we and project management. However, we think that started reconsidering the course and how to develop this was more of a side-effect, given that collaborative it further. In particular, we intended to address the software development and synchronization in teams following concerns, some of which occurred in the is taught in other courses. old course, while some are caused by environmental Thus, the overall programming workload had to be variables: reduced. To do so, we introduced two changes. First, we changed the formalism from B to petri nets (Petri, 1966), which are considerably easier to understand • We do not think the presented approach scales and implement: As far as the language interpreter is to larger groups. A single project for all students concerned, only addition and subtraction is required. seamed infeasible, since 18 students registered This allows to focus on model checking techniques in- and even more showed up in the first session. stead of writing a more complex language interpreter. • We were concerned that knowledge did not propa- However, writing meaningful test cases is harder gate evenly, as students specialized on a subset of in such a low-level formalism. Therefore, we used topics, e.g. LTL or explicit-state model checking. benchmarks from the annual model checking contest (Kordon u. a., 2016) instead of making students • As the B language is a rich formalism, many prob- writing their own. As in the previous iteration, we lems unrelated to model checking might surface. provided a parser for the input format. Furthermore, we split the programming project into • Given that theoretical foundations were reduced two parts. In the first part of the project, the students quite heavily, we feared students working on more had to implement a very basic explicit-state model advanced topics had to catch up individually. checker to check for deadlock freedom and to verify

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 96 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein certain safety properties. This part of the project had ist knowledge remains and is not distributed equally to be passed in order to receive the permission to throughout the participants. While the exam and its write the final exam. The second part of the project results show that all participants reached the desired dealt with more advanced topics: The existing model learning outcomes, we think that with a better focus checker had to be be extended in order to verify linear- on knowledge transfer an even better outcome could time properties by implementing algorithms that have have been reached. been introduced in the lecture. We graded the second To summarize, our refurbished lecture on model part of the programming project of each student and checking is gradually being refined. It is intended to incorporated the result into the overall grade with a replace the former lessons-only course in following weight of 25 %. iterations. Secondly, we brought back some of the theoreti- We believe that a few insights can be carried over cal lessons and exercises, yet cutting down on enor- from our course to other courses. In particular, we mous proofs so there was enough time to spare to believe that a strong connection between teaching and let our students work on their model checkers. We research is highly beneficial and can be achieved with intended that the theoretical exercises in particular little overhead using programming projects. Depend- deepen the knowledge and allow pointing out connec- ing on the scenario, a switch to inquiry-based learn- tions between individual components throughout the ing is feasible and leads to high motivation among lectures. participants, without causing too much reduction in Thirdly, in addition to the parser, we provided some course content. However, focus has to be given to the components of the model checker that were not cov- synchronization of participants, i.e., teachers have to ered in the lecture and required cumbersome imple- ensure that nobody is left behind. mentation of algorithms that are only sparsely docu- Last, our course shows that with the right motiva- mented in literature. tion and proper support, inquiry-based learning meth- In the exam, we focused on theoretical problems in- ods can produce research results on a very high level. stead of applying basic algorithms since each student implemented them already. Thus, given that we think Acknowledgments the exam was harder overall, we are pleased with the The authors would like to thank the university didac- result in 2018 as shown in Table 2. tics department of the Heinrich-Heine-University for During supervision and discussing of the model their constant support and consulting. In particular, checking projects, it became clear that many students the authors would like to thank Susanne Wilhelm procrastinated and put off work until the last few for the project supervision and Jens Bendisposto and weeks, not making use of the available time given by Janine Golov for peer reviewing the lectures. cutting back lectures. This might be caused by the lack of fruitful discussion about how components should References be implemented that results in inspiration to try it out [Abrial 1996] ABRIAL, J.-R.: The B-book: Assigning and peer-pressure to reach common goal during the Programs to Meanings. New York, NY, USA : Cam- next week. A possible solution might be to enforce bridge University Press, 1996 peer-programming during practical sessions. [Barron u. a. 1998] BARRON, Brigid J. ; SCHWARTZ, Conclusion Daniel L. ; VYE, Nancy J. ; MOORE, Allison ; PET- In summary, we believe that the restructured course ROSINO, Anthony ; ZECH, Linda ; BRANSFORD, on “model checking” met our self-set goals. Realiza- John D.: Doing With Understanding: Lessons From tion was more hassle-free than we anticipated. Research on Problem- and Project-Based Learning. In: Journal of the Learning Sciences 7 (1998), Nr. In particular, contrary to our concerns, we had no 3-4, S. 271–311 problems motivating students to active participation. Even though the course was quite experimental at [Biggs 1996] BIGGS, John: Enhancing Teaching times, everybody was willing to try. We only had to through Constructive Alignment. In: Higher Ed- intervene with speed and progress direction seldomly. ucation 32 (1996), Nr. 3, S. 347–364 One of the key challenges proved difficult however. [Blumenfeld u. a. 1991] BLUMENFELD, Phyllis C. ; Due to the scale of the programming projects, stu- SOLOWAY, Elliot ; MARX, Ronald W. ; KRAJCIK, dents had to form groups concerned with different Joseph S. ; GUZDIAL, Mark ; PALINCSAR, Annemarie: partial aspects. For instance, some were working on Motivating Project-Based Learning: Sustaining the techniques for the verification of temporal properties Doing, Supporting the Learning. In: Educational while other were working on performance improve- Psychologist 26 (1991), Nr. 3-4, S. 369–398 ments. However, all students were supposed to take the same exam. [Clarke u. a. 1999] CLARKE, Edmund M. Jr. ; GRUM- As planned, we had regular meetings dedicated to BERG, Orna ; PELED, Doron A.: Model Checking. synchronizing the different groups. However, special- Cambridge, MA, USA : MIT Press, 1999

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 97 Experience Report on An Inquiry-Based Course on Model Checking Sebastian Krings, Philipp Körner und Joshua Schmidt, Uni Düsseldorf & HS Niederrhein

[Grumberg u. Veith 2008] GRUMBERG, Orna (Hrsg.) ; [Taﬂiovich u. a. 2015] TAFLIOVICH, Anya ; PETERSEN, VEITH, Helmut (Hrsg.): 25 Years of Model Checking: Andrew ; CAMPBELL, Jennifer: On the Evaluation of History, Achievements, Perspectives. Berlin, Heidel- Student Team Software Development Projects. In: berg : Springer-Verlag, 2008 Proceedings of the 46th ACM Technical Symposium on Computer Science Education. New York, NY, USA [Jones 2018] JONES, Simon P.: How to write a great : ACM, 2015 (SIGCSE ’15), S. 494–499 research paper. https://www.microsoft.com/en- us/research/academic-program/write-great- research-paper/, 2018. – Accessed: 2018-10-24

[Kordon u. a. 2016] KORDON, Fabrice ; GARAVEL, Hu- bert ; HILLAH, Lom M. ; PAVIOT-ADET, Emmanuel ; JEZEQUEL, Loïg ; RODRÍGUEZ, César ; HULIN- HUBARD, Francis: MCC’2015 – The Fifth Model Checking Contest. (2016), S. 262–273

[Leuschel u. Butler 2003] LEUSCHEL, Michael ; BUT- LER, Michael: ProB: A Model Checker for B. In: Proceedings FME’03, Springer, 2003 (LNCS 2805), S. 855–874

[Leuschel u. Butler 2008] LEUSCHEL, Michael ; BUT- LER, Michael: ProB: an automated analysis toolset for the B method. In: Int. J. Softw. Tools Technol. Transf. 10 (2008), Nr. 2, S. 185–203

[Oguz-Unver u. Arabacioglu 2014] OGUZ-UNVER, Ayse ; ARABACIOGLU, Sertac: A comparison of inquiry-based learning (IBL), problem-based learning (PBL) and project-based learning (PJBL) in science education. 2 (2014), 07, S. 120–128

[Petrasch u. a. 2018] PETRASCH, Jessica ; OEPEN, Jan- Hendrik ; KRINGS, Sebastian ; GERICKE, Moritz: Writing a Model Checker in 80 Days: Reusable Li- braries and Custom Implementation. In: ECEASST (2018)

[Petri 1966] PETRI, Carl A.: Communication with automata, Universität Hamburg, Diss., 1966

[Radermacher u. Walia 2013] RADERMACHER, Alex ; WALIA, Gursimran: Gaps Between Industry Expecta- tions and the Abilities of Graduates. In: Proceeding of the 44th ACM Technical Symposium on Computer Science Education. New York, NY, USA : ACM, 2013 (SIGCSE ’13), S. 525–530

[Radermacher u. a. 2014] RADERMACHER, Alex ; WALIA, Gursimran ; KNUDSON, Dean: Investigat- ing the Skill Gap Between Graduating Students and Industry Expectations. In: Companion Proceedings of the 36th International Conference on Software En- gineering. New York, NY, USA : ACM, 2014 (ICSE Companion 2014), S. 291–300

[Schauble u. a. 1995] SCHAUBLE, Leona ; GLASER, Robert ; DUSCHL, Richard A. ; SCHULZE, Sharon ; JOHN, Jenny: Students’ Understanding of the Ob- jectives and Procedures of Experimentation in the Science Classroom. In: The Journal of the Learning Sciences 4 (1995), Nr. 2, S. 131–166

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 98 Evaluation des Arbeitsprozess-integrierten Projektstudiums

Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin {frank.fuchs-kittowski, juliane.siegeris, joern.freiheit}@htw-berlin.de

Zusammenfassung future applications of the work process-integrated project study. Für das Arbeitsprozess-integrierte Projektstudium im berufsbegleitenden Masterstudiengang „Profes- sional IT-Business“ der Hochschule für Technik und Wirtschaft Berlin wurde eine Evaluation durchge- Einführung führt. Mithilfe einer Umfrage unter den Studieren- Lebenslanges Lernen ist in der heutigen Gesellschaft den sollte die Wirksamkeit des Konzepts des Ar- unerlässlich. Damit Lernen ein Leben lang – und da- beitsprozess-integrierten Projektstudiums überprüft mit an verschiedenen Orten und in unterschiedli- werden. Es wurden acht Hypothesen aufgestellt. chen Institutionen - gelingen kann, ist die Durchläs- Die Überprüfung dieser Hypothesen sollte dazu die- sigkeit zwischen den verschiedenen (Lern- und Ar- nen, mögliche Fehlannahmen und Brüche im Kon- beits-) Institutionen und Orten von zentraler Bedeu- zept zu erkennen. An der Umfrage haben 20 der 31 tung. Doch Durchlässigkeit - insbesondere zwischen Studierenden teilgenommen, die das Projektstu- dem beruflichen und dem hochschulischen Bil- dium bisher absolviert haben. Die statistische Rele- dungsbereich – wird oftmals reduziert auf die An- vanz ist somit begrenzt, jedoch erlaubt die deskrip- rechnung beruflich erworbener Kompetenzen (Frei- tive Analyse der Umfrageergebnisse Rückschlüsse tag et al., 2011), insb. beim Übergang vom Beruf in auf Änderungs- und Verbesserungspotenziale des das Studium, d.h. vertikal (Buhr et al., 2008). dem Projektstudium zugrundeliegenden didakti- Ein großes, bisher aber kaum betrachtetes Poten- schen Konzepts. Neben der Beschreibung der Me- zial besteht aber in der horizontalen Durchlässig- thodik und der erzielten Ergebnisse werden Schluss- keit, die dadurch entsteht, dass Studierende oftmals folgerungen aus der Auswertung gezogen sowie neben- oder auch hauptberuflich arbeiten. Dabei Ausblicke auf zukünftige Anwendungen des Ar- wenden sie in der Hochschule erlerntes Wissen und beitsprozess-integrierten Projektstudiums gegeben. Fähigkeiten in der Arbeit an. Aber vor allem erwerben sie in der Arbeit auch neues Wissen und Kom- Abstract petenzen, die sie bisher noch kaum in ihr Hoch- schulstudium einbringen können. Um dieses Poten- An evaluation was carried out for the working pro- zial zu heben, erfordert es neuartiger Konzepte zur cess-integrated project study in the in-service master stärkeren Verbindung unterschiedlicher Lernorte programme "Professional IT-Business" of the Uni- (insb. Lernort Hochschule mit Lernort Arbeitsplatz versity of Applied Sciences Berlin (HTW Berlin). A in Unternehmen). survey conducted amongst students aimed to eval- Um gezielt die berufliche Handlungskompetenz uate the effectiveness of the concept of work pro- von Studierenden zu fördern und dabei den Lernort cess-integrated project study. Eight hypotheses were Unternehmen zu integrieren, wurde an der HTW set up. The review of these hypotheses should serve Berlin ein innovatives Konzept für die Durchfüh- to detect possible misconceptions and breaks in the rung des „Projektstudiums“ im Rahmen des berufs- concept. 20 of the 31 students who have completed begleitenden Masterstudiengangs „Professional IT- the project study participated in the survey. The sta- Business“ entwickelt (Fuchs-Kittowski et al., 2017): tistical relevance is thus limited, but the descriptive Die Studierenden im Projektstudium lernen dabei analysis of the survey results allows conclusions to im Arbeitsprozess, in realen Projekten (Praxispro- be drawn on the potential for change and improve- jekt) in (ihren) Unternehmen. Das Lernen in der Ar- ment of the didactic concept underlying the project beit gestalten die Studierenden dabei selbst, werden study. In addition to the description of the method- aber umfassend personell und technisch unterstützt. ology and the results obtained, conclusions are Ein prozess-orientiertes Curriculum, sog. Referenz- drawn from the evaluation as well as prospects for projekt, gibt die Lernziele vor und strukturiert das Projektstudium. Es dient der Auswahl des

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 99 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Praxisprojekts, der Planung der Arbeits- und Lern- Jahrgang in diesem Masterstudiengang wurde zum prozesse und schließlich auch dem Nachweis des er- Wintersemester 2016 immatrikuliert. folgreichen Projektstudiums. Alle Prozesse des Re- ferenzprojekts müssen nachweislich beherrscht wer- Konzept des Projektstudiums den, indem sie bewältigt und dabei reflektiert und Das Konzept für das Projektstudium (Fuchs-Kit- dokumentiert werden. towski et al., 2017) fokussiert auf die Integration von In diesem Beitrag sollen die wesentlichen Ergeb- Lernen und Arbeiten. Dabei findet das Lernen und nisse der Evaluation dieses Konzepts des Arbeits- Arbeiten nicht in der Hochschule an einer Aufgabe prozess-integrierten Projektstudiums dargestellt eines Unternehmens statt, sondern integriert in reale werden. Das Hauptziel der Evaluation lag auf der Arbeitsprozesse in den Unternehmen. Prüfung der Annahmen bzw. Wirksamkeit des Kon- Zur Systematisierung und Unterstützung sol- zepts des Arbeitsprozess-integrierten Projektstudi- cher Lernprozesse am Arbeitsplatz, im Arbeitspro- ums und der Erarbeitung von Optimierungsvor- zess, in realen Projekten wurden a) prozessorien- schlägen. tierte Curricula („Referenzprojekt“), b) eine Vorge- Dieser Beitrag ist wie folgt strukturiert: Nach der hensweise für das Lernen im Arbeitsprozess („Pra- Vorstellung des Hintergrunds der Untersuchung xisprojekt“) sowie c) organisatorische und techni- (Masterstudiengang, Konzept des Projektstudiums, sche Instrumente zur Unterstützung der im Arbeits- Evaluation) sowie der verwendeten Methodik wer- prozess Lernenden entwickelt (Fuchs-Kittowski et den die Ergebnisse der Umfrage präsentiert und dis- al., 2017): kutiert und mit den Ergebnissen die Gültigkeit der Lernprozesse werden durch Herausforderun- acht vorgestellten Hypothesen evaluiert. Es werden gen (Wissenslücken) in realen Projekten („Pra- Schlussfolgerungen für die zukünftige Anwendung xisprojekt“) initiiert. Diese Herausforderungen sol- des Konzeptes der Arbeitsprozess-integrierten Pro- len durch die Studierenden weitgehend selbstge- jektstudien gezogen und diskutiert. Eine Zusam- steuert bewältigt werden. Dabei sind bestimmte Ar- menfassung und ein Ausblick schließen den Beitrag. beitsprozesse zu durchlaufen. Dies sind für ein Tä- tigkeitsprofil (z.B. Data Analyst/-in) typische Tätig- Hintergrund keiten, die in einem profiltypischen „Referenzpro- jekt“ beschrieben sind, das die curriculare Grund- In diesem Kapitel wird der Masterstudiengang lage und Struktur der Qualifizierung (Projektstu- „Professional IT-Business“ und das Konzept des dium) bildet. „Projektstudiums“ kurz vorgestellt sowie das die- Personale Unterstützung erhalten die Studieren- sem Beitrag zugrundeliegende Verständnis einer den für das selbst gesteuerte Lernen während der Evaluation erörtert. Bearbeitung ihrer Praxisprojekte durch verschie- Masterstudiengang dene Rollen, wie Fachberater, Lernprozessbegleiter, Vorgesetzte und Kollegen/Kommilitonen. Eine tech- Der Masterstudiengang „Professional IT-Business“ nische bzw. mediale Unterstützung erhalten die Stu- wird berufsbegleitend durchgeführt. Die Studieren- dierenden in Form einer Lernplattform, die orts- den erwerben insgesamt 90 Leistungspunkte bei ei- und zeitunabhängiges Lernen und Arbeiten unter- ner Regelstudienzeit von 4 Semestern. Davon wer- stützt sowie eine individualisierte Betreuung und den allein 30 Leistungspunkte für die drei Projekt- Organisation der Teilnehmer ermöglicht. Zudem studien vergeben, die in den ersten drei Semestern nehmen die Studierenden im Semester zuvor an ei- durchgeführt werden. Neben dem Projektstudium I ner klassischen Lehrveranstaltung (Vorlesung mit (IT-Spezialist/-in) werden im ersten Semester Mo- Übung) zum relevanten Themengebiet (z.B. Data dule zu den Themen Cloud Computing, Data Ana- Analytics) teil, in denen das erforderliche Fachwis- lytics und Requirements Engineering durchgeführt, sen vermittelt wird. im zweiten Semester wird das Projektstudium II Die Prüfung der Studierenden erfolgt nicht, wie (Data Analyst/-in) von den Veranstaltungen Mobile an einer Hochschule traditionell üblich, durch eine Computing und Enterprise Architecture begleitet Prüfung (Klausur etc.), sondern anhand einer von je- und im dritten Semester werden neben dem Projekt- dem Studierenden einzeln erstellten Dokumenta- studium III (Enterprise Architecture Manager/-in) tion über die selbständige und kompetente Durch- die Veranstaltungen IT-Security und IT-Controlling führung von im Referenzprojekt vorgegebenen Ar- gelehrt. Im vierten Semester erstellen die Studieren- beitsprozessen. den ihre Masterarbeit. Die Durchführung der Pro- Im Konzept und der Bewertung des Projektstu- jektstudien sowie die Erstellung der Masterarbeit er- diums spielt die individuelle Reflektion des Arbeits- folgt hauptsächlich in den Unternehmen berufsbe- und Lernprozesses eine wichtige Rolle. Donald gleitend von Montag bis Donnerstag. Die anderen Schön prägte den Begriff der reflective practice Module finden als Präsenzveranstaltungen freitags (Schön, 1983). Er plädiert für die bewusste und sys- und samstags an der Hochschule statt. Der erste tematische Reflektion der eigenen Erfahrungen und

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 100 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin argumentiert, dass erst durch die Reflektion der Untersuchung Handlungen - während des Prozesses und danach - Die Untersuchung sollte als schriftliche Online-Be- ein Lernprozess ermöglicht wird. In vielen Publika- fragung der Studierenden durchgeführt werden. tionen (u.a. Upchurch & Sims-Knight, 1999; Unter der Zielsetzung der empirischen Über- Dingsoer, 2005; Prior et al., 2014) wird seitdem dis- prüfung der Grundannahmen des Konzepts des Ar- kutiert, wie Reflektion in die Lehre integriert und beitsprozess-integrierten Projekt-Studiums wurden aktiv vermittelt werden kann. Eine Zusammenfas- zu den o.g. Teilbereichen der Konzeption (a) Rolle sung verschiedener Ansätze im Bereich Software- der Prozessorientierten Curricula (Referenzpro- Entwicklung bietet (Burden & Steghöfer, 2019). jekte), b) Lernen im Arbeitsprozess (Praxisprojekte) Im vorgestellten Projektstudium wird Reflek- und c) Personale, technische und fachliche Unter- tion zu verschiedenen Anlässen ermöglicht und ein- stützung des Lernens in der Arbeit) sowie zur allge- gefordert. Dazu zählen regelmäßige Reflektionsge- meinen Akzeptanz des Projektstudiums (Gesamtbe- spräche, die Zwischenpräsentation, ein Fachge- wertung) Hypothesen gebildet. Zu jeder der Hypo- spräch am Ende des Projekts, insbesondere jedoch thesen wurden entsprechende Indikatoren definiert. die abschließende Dokumentation. Mittels Fragen Auf Basis der Indikatoren wurden dann die Erhe- zu den durchgeführten Prozessschritten werden die bungsinstrumente entwickelt, eingesetzt und ausge- Studierenden angeleitet, in der Ich-Perspektive über wertet. Zudem flossen auch Erfahrungen aus der Projekterfahrungen, Entscheidungen und aufgetre- Durchführung des Projektstudiums in die Interpre- tene Schlüsselsituationen zu berichten und die eige- tation der Ergebnisse ein, vgl. (Brand, 2014; nen Aktivitäten zum Referenzprozess in Beziehung Mattauch & Kubath, 2005). zu setzen. Anders als bei einem Projekt-Ergebnisbe- richt soll diese Art der Dokumentation (ähnlich dem Datenerhebung postmortem review, vgl. Dingsoer, 2005) den Studie- Der entstandene Fragebogen wurde Online (Survey- renden helfen, sich ihrer Lernerträge bewusst zu Monkey) im Oktober 2018 an die Studierenden ver- werden. teilt, die das Projektstudium im Sommersemester Evaluation 2018 durchgeführt hatten. Dies waren 16 Studie- rende aus dem aktuellen 3. Semester des Studien- Dieser Beitrag beschäftigt sich mit der Evaluation gangs sowie 15 Studierende aus dem vorherigen des Arbeitsprozess-integrierten Projektstudiums, Jahrgang, also insgesamt 31 Studierende. Die Frage- das bislang vom ersten Jahrgang komplett (Projekt- bogenerhebungen erfolgten anonymisiert. studium I-III) und vom zweiten Jahrgang bis ein- schließlich des Projektstudiums II absolviert wurde. Datenauswertung Evaluation im Sinne dieses Beitrages bedeutet: die Insgesamt wurde der Fragebogen von 20 Studieren- praxisnahe Beurteilung des Projektstudiums mit den ausgefüllt (Rücklaufquote: 64,5%). Die Daten empirischen Methoden (Wottawa & Thierau, 1990). wurden mit den im Online-Befragungs-Tool (Sur- Eine Evaluation dient der rückblickenden Wir- vey-Monkey) verfügbaren Werkzeugen ausgewer- kungskontrolle, der vorausschauenden Steuerung tet. Aufgrund der relativ kleinen Teilnehmerzahl und dem Verständnis von Situationen und Prozes- wurde auf die sonst üblichen parametrischen Ana- sen. Darauf aufbauend können untersuchte Pro- lyseverfahren verzichtet. Eine überwiegend de- zesse angepasst und optimiert werden (Götz, 1993). skriptive Analyse der Daten, insb. die Angabe von Das Hauptziel der Evaluation des Projektstudiums Absolutwerten und der prozentualen Verteilung, er- lag daher auf der Prüfung der Annahmen bzw. der schien zweckmäßig. Wirksamkeit des Konzepts des Arbeitsprozess-integrierten Projektstudiums. Die zentralen Grundan- Teilnehmer (Stichprobe) nahmen dieses Konzepts sollten empirisch geprüft Von den 20 Teilnehmern haben 12 im Sommerse- werden. Die Überprüfung der theoretischen Annah- mester das Profil „Data-Analyst/in“ durchgeführt, men mit der Praxis soll insbesondere dazu dienen, befinden sich also aktuell im 3. Semester. Die Studie- mögliche Fehlannahmen und Brüche im Konzept zu renden im vorhergehenden Jahrgang hatten im erkennen sowie Hinweise für Änderungen oder Er- Sommersemester 2018 die Wahl zwischen den Pro- weiterungen des Konzepts zu erhalten. filen „Software-Developer“ (2), „IT-Project-Coordi- nator“ (3) und „IT-Solution-Developer“ (3). Methodik Dieser Abschnitt beschreibt die Methodik der Unter- suchung zur Evaluation des Projektstudiums.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 101 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Hypothese 1: Referenzprojekte sind eine gute Hilfe zur Identifizierung und Auswahl von geeigneten Praxisprojekten Als Hypothese 1 wurde angenommen, dass das Re- ferenzprojekt eine wesentliche Orientierungs- und Unterstützungshilfe zur Identifikation und Aus- wahl von Praxis-Projekten darstellt. Die Studieren- den wurden konkret gefragt, ob sie „anhand der im Referenzprojekt beschriebenen Teilprozesse ein Pra- xisprojekt identifizieren konnten, das sich für das Projektstudium eignete“. Fast allen Teilnehmern ist es gelungen, ein geeignetes Praxisprojekt zu finden. Bei 30% der Teil- Abb. 1: Gewähltes Referenzprojekt im SoSe2018 nehmer geschah dies „Völlig unproblematisch“ (n=6) und bei 40% „Relativ leicht und mit geringem Die meisten Teilnehmer waren vor dem Beginn des Aufwand (n=8). Nur 25% der Teilnehmer hatten Master-Studiums an der HTW Berlin bereits 2-3 „große Mühe und Aufwand (n=5) und nur einem Jahre in der IT-Branche tätig (47,37%, n=9/19), ein Teilnehmer (5%) ist es „nicht gelungen, ein geeigne- weiterer großer Teil (42,11%, n=8/19) mehr als 4 tes Praxisprojekt zu finden“ (n=1). Bei Letzterem Jahre und nur ein geringer Teil nahm das Studium konnte kein Projekt zum Profil „Data-Analyst/in“ nach weniger als 1 Jahr auf (10,53%, n=2/19). gefunden werden, was in der Tat schwierig sein kann, da sich Unternehmen bislang nicht alle mit Data-Analytics beschäftigen.

Abb. 2: Berufsjahre der Teilnehmer vor Studium

Aussagekraft Abb. 3: Einfachheit Praxisprojekt zu finden Einschränkend ist anzumerken, dass aufgrund der geringen Stichprobenzahl (n = 20) die statistische Re- levanz begrenzt ist. So sind die Aussagen aufgrund Gründe für die aufgetretenen Schwierigkeiten sehen der Stichprobe nicht repräsentativ und auf ein Pro- die Studierenden vor allem in: jektstudium mit anderen Rahmenbedingungen (Un- „keine Daten in ausreichender Menge/Qualität vorhanden, Da- ternehmen, regionale Bedingungen etc.) nicht bzw. tenschutz.“ nur bedingt übertragbar. Die erhobenen Daten er- „In der Unternehmensabteilung gehört das angebotene Profil lauben aber erste Hinweise auf eine empirische Sta- (hier Data Analyst) nicht zum Tagesgeschäft.“ bilität des Konzepts. „Es war schwierig die geplante theoretische Herleitung im Pro- Unter diesen Voraussetzungen erbrachte die jekt der Arbeit umzusetzen, da das Vorgehen des Unternehmens Evaluation die im folgenden Kapitel dargestellten ein anderes ist.“ Ergebnisse. Zusammengefasst stellten die Referenzprojekte eine wesentliche Unterstützungshilfe zur Identifika- Ergebnisse tion von Praxisprojekten dar, wobei Probleme eher Die Grundannahmen des Konzepts wurden in acht darin bestanden, dass weder im Unternehmen Hypothesen zusammengefasst, für die jeweils geeig- selbst, noch bei derzeitige Kunden Projekte mit dem nete Indikatoren definiert worden waren. gesuchten Profil bearbeitet wurden. Zur weiteren Unterstützung der Praxisprojektauswahl erscheint es daher sinnvoll, zukünftig die Anzahl möglicher

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 102 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Referenzprojekte zu erweitern und die Wahl über Referenzprozesse inzwischen beherrschen, so dass alle Semester hinweg zu öffnen. diese Hilfe in Zukunft nicht mehr erforderlich ist. Hypothese 2: Referenzprojekte dienen als Strukturierungshilfe für das Lernen im Pra- xisprojekt Als Hypothese 2 wurde angenommen, dass das Re- ferenzprojekt eine wichtige Orientierungs- und Strukturierungshilfe für das Lernen in den Pra- xisprojekten darstellt. Hierzu wurde erhoben, „wie hilfreich das Referenzprojekt bei der Durchführung des Praxisprojekts empfunden wurde“ sowie, ob „geplant ist, das Referenzprojekt auch in Zukunft zur Strukturierung der Arbeit bzw. ähnlicher Pro- Abb. 5: Einsatz in Zukunft jekte einzusetzen“. Die Mehrzahl der Teilnehmer (40%, n=8) gab an, dass das Referenzprojekt „Überwiegend hilfreich“ Zusammengefasst hat sich das Referenzprojekt bei war, um das Praxisprojekt durchzuführen. Für 35% der überwiegenden Mehrheit der Teilnehmer als war es „Etwas hilfreich“ (n=7) und für 15% sogar Orientierungs- und Strukturierungshilfe zur Durch- „Sehr hilfreich“ (n=3). Nur 10% gaben an, dass das führung der Praxisprojekte bewährt. Es wurde von Referenzprojekt „Überhaupt nicht hilfreich“ war, der überwiegenden Mehrheit der Teilnehmer als um das Praxisprojekt durchzuführen (n=2). Wobei wichtige Hilfestellung zur Durchführung des Pra- einer der beiden Teilnehmer, die es nicht hilfreich xisprojekts eingeschätzt und soll zumindest von ei- fanden, angab, kein geeignetes Projekt gefunden zu nem Teil auch zukünftig als Strukturierungshilfe haben. Der zweite Teilnehmer gab an, das Projekt eingesetzt werden. nicht als Chance wahrgenommen, sondern nur notgedrungen gewählt zu haben - also mit der Absicht, Hypothese 3: Das Lernen und Arbeiten in es mit „möglichst wenig zusätzlichem Aufwand zu Praxisprojekten führt zu einem Kompetenz- absolvieren“. erwerb bzw. -zuwachs im Bereich des Tä- tigkeitsprofils (Berufliche Handlungskom- petenz) Als Hypothese 3 wurde angenommen, dass sich die Studierenden durch das Lernen und Arbeiten in den Praxis-Projekten die Kompetenzen des Tätigkeits- profils aneignen. Die Studierenden sollten beurteilen, „in welchen Bereichen sie im Rahmen des Projektstudiums etwas lernen“ konnten. Es sollten dazu jeweils der Lerner- trag in den Bereichen „fachlich“, „methodisch“, „so- zial“ und „persönlich“ bewertet werden. Die Mehr- heit der Teilnehmer (55%) gab an, im Bereich der fachlichen Kompetenzen „viel“ (50%, n=10) oder „sehr viel“ (5%, n=1) gelernt zu haben. Ähnlich Abb. 4: Referenzprojekt als Hilfe hierzu gab im Bereich der methodischen Kompeten- zen die Mehrheit der Teilnehmer (60%) an, „viel“ (50%, n=10) oder „sehr viel“ (10%, n=2) gelernt zu Ein relativ geringer Teil der Teilnehmer plant, das haben. Überraschend ist, dass im Bereich der sozia- Referenzprojekt auch in Zukunft zur Strukturierung len Kompetenz kein Teilnehmer angab, „viel“ oder der Arbeit bzw. ähnlicher Projekte einzusetzen. Ein „sehr viel“ gelernt zu haben, sondern alle Teilneh- etwas größerer Teil plant dies nicht. Aber die Mehr- mer angaben, „nichts“ (35%, n=7) oder „wenig“ heit weiß dies noch nicht. Da das Referenzprojekt (65%, n=13) gelernt zu haben. Dies lässt sich ggf. für die große Mehrheit „hilfreich“ war, ist dies dadurch erklären, dass die Studierenden ja auch wahrscheinlich darin begründet, dass die Studieren- ohne das Projektstudium aufgrund ihrer Einbin- den zum einen bereits in festen Kontexten in den dung in ihr Unternehmen Projekte durchgeführt Unternehmen arbeiten und es unsicher ist, ob die und Erfahrungen im Bereich der sozialen Kompe- Studierenden in Zukunft in den Themen der Refe- tenzen gesammelt hätten. Ebenso gaben auch nur renzprojekte arbeiten werden oder zum anderen die 30% der Teilnehmer (n=6) an, „viel“ im Bereich der persönlichen Kompetenzen gelernt zu haben.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 103 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Der Lernerfolg verteilt sich dabei jedoch nicht gleichmäßig auf die verschiedenen Kompetenzbe- reiche. Während 55% und 60% der Teilnehmer an- geben, fachlich bzw. methodisch „viel“ oder „sehr viel“ gelernt zu haben, haben nur 30% im Bereich der persönlichen Kompetenzen „viel“ gelernt und niemand „viel“ oder „sehr viel“ im Bereich der sozialen Kompetenzen. Ggf. spielt die Vorerfahrung der Teilnehmer eine Rolle, welcher in Zukunft bei der Arbeit der Lernprozessbegleiter eine höhere Auf- merksamkeit geschenkt werden sollte. Hypothese 4: Die Studierenden entwickeln die Fähigkeit, selbständig zu lernen Als Hypothese 4 wurde angenommen, dass die Stu- dierenden in der Lage waren, selbst gesteuert zu lernen. Hierzu wurde erhoben, inwieweit die Studie- renden eigenständig nach Informations- und Wis- sensquellen suchten, um ihre Wissenslücken zu schließen, sowie inwieweit die Studierenden das Abb. 6: Lernprozesse in Kompetenzfeldern Projektstudium als Chance wahrgenommen haben, Neues zu lernen.“ Die Studierenden fühlen sich nach Abschluss des Die Frage, „inwieweit das Projektstudium als Projektstudiums gut auf eine Tätigkeit in dem Tätig- Chance gesehen und aktiv genutzt wurde, um etwas keitsprofil (Data Analyst, IT-Project-Coordinator, Neues zu lernen“, hat die große Mehrheit der Teil- IT-Solution-Developer, Software Developer) bzw. nehmer (70%, n=14) positiv beantwortet. 40% der auf zukünftige Arbeitsaufgaben vorbereitet. Sie Teilnehmer (n=8) taten dies „Sehr aktiv (bewusst an- wurden befragt, „inwieweit das Praxisprojekt dazu spruchsvolles und passendes Projekt gesucht)“ und beigetragen hat, dass die typischen Arbeitsprozesse 30% (n=6) „Aktiv (existierendes Projekt gestaltet)“. des Profils jetzt besser beherrscht werden als vor- Lediglich 25% (n=5) machten dies „Notgedrungen her“. So gibt eine klare Mehrheit (70%) an, dass das (versucht Projekt mit möglichst geringem Aufwand Praxisprojekt „sehr“ (10%, n=2) bzw. „überwie- auf das Referenzprojekt abzubilden)“ oder „Gar gend“ (60%, n=12) dazu beigetragen hat, die typi- nicht“ (5%, n=1). schen Arbeitsprozesse des Profils (Referenzprojekt) jetzt besser zu beherrschen als vorher. Nur eine Min- derheit von 30% (n=6) gab an, dass das Praxisprojekt „wenig“ (20%, n=4) oder „nicht“ (10%, n=2) dazu beigetragen hat.

Abb. 8: Projekt als Chance zum Lernen nutzen

Auf die Frage, „wie oft es im Praxisprojekt vorkam, dass selbständig nach fehlenden Informationen ge-

sucht bzw. selbst fehlendes Wissen angeeignet wer- Abb. 7: Vorbereitung auf Tätigkeit den musste“, gab die Mehrheit der Teilnehmer (60%, n=12) an, dass dies „häufig“ (35%, n=7) oder „sehr oft“ (25%, n=5) notwendig war. Dies deutet zum ei- Zusammenfassend führte das Lernen in den Pra- nen darauf hin, dass im Praxisprojekt herausfor- xisprojekten zu einem Kompetenzerwerb der Teil- dernde, lernhaltige Tätigkeiten durchgeführt wer- nehmer im Tätigkeitsprofil des Referenzprojekts. den mussten (siehe Hypothese 3), und zum anderen,

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 104 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin dass die Studierenden eigenständig Wissenslücken profitierte von den gebotenen Reflexionsanlässen. geschlossen und damit gelernt haben. 35% der Teil- Dabei fällt es den Studierenden zu Beginn des Pro- nehmer (n=7) haben immerhin „Selten“ Wissenslü- jekts schwerer, Projektfortschritt und Lernerträge cken selbständig geschlossen. Nur ein Teilnehmer durch Reflexionsgespräche selbst einzuschätzen gab an, dass dies „Nie“ erforderlich war (5%, n=1). (26,32%, n=6/19). Zentrales Instrument für die Re- flektion und die Sicherung der Lernerträge ist die schriftliche Dokumentation (57,89%, n=11/19). Aber auch die Reflektion im Rahmen der Abschlussprü- fung (Fachgespräch) zum Ende des Projektstudiums ist nochmal ein wichtiger Anlass zur Reflektion (36,84%, n=7/19).

Abb. 9: Wissenslücken selbständig schließen

Die folgenden Zitate stehen beispielhaft für einen hohen eigenständigen Lernertrag: „...die Bereitstellung der Daten waren weitaus schwieriger und Abb. 10: Reflexionsanlässe zum Bewusstwerden zeitintensiver zu organisieren. Das Wissen hierzu musste ich komplett selbst erarbeiten.“ von Lernerträgen „Das Projektstudium habe ich genutzt, um mich in das eigene Projektumfeld vertiefend einzuarbeiten und um größtmögliche Zusammenfassend kann die Annahme, dass die Synergien zwischen dem "Neu-Gelernten" in den LVs und dem Teilnehmer in den Praxisprojekten selbständig ler- "Alt-Angewandten" im Unternehmen herzustellen.“ nen, prinzipiell bestätigt werden. Zu einem großen Prinzipiell fällt es Studierenden eher schwer, ihre Teil initiieren die Teilnehmer lernhaltige Lernsitua- Projektfortschritte und Lernerträge einzuschätzen tionen selbst, schließen Wissenslücken eigenständig und zu dokumentieren, vgl. (Platt, 2014). Im Kon- und sind in der Lage über Reflektion Lernfort- zept und der Bewertung des Projektstudiums spielt schritte einzuschätzen und Lernerträge zu sichern. die Reflektion des eigenen Vorgehens und aufgetre- Andererseits hat ein nicht unerheblicher Anteil der tener Schlüsselsituationen eine maßgebliche Rolle, Teilnehmer die Chance zum Lernen nicht aktiv ge- bei dem Ziel einen nachhaltigen Wissenserwerb nutzt, kaum die Notwendigkeit zum selbständigen (Lernertrag) zu ermöglichen und zu kontrollieren. Schließen von Wissenslücken gesehen und wurden Schlüsselsituationen sind solche Situationen, die auch die Anlässe zur Reflektion nur eingeschränkt den Projektverlauf verzögern oder den Projekterfolg als notwendig erachtet. D.h. das Projektstudium bie- verhindern, jedoch keinen inhaltlichen, sondern ei- tet die Möglichkeit zum selbständigen Lernen, stellt nen organisatorischen Projektbezug haben, z.B. Ter- dieses aber nicht notwendiger Weise sicher, was mit minfindungsprobleme mit Entscheidern, Sprach- den diversen Freiheitsgraden bei der Auswahl, probleme, mangelnde Expertise von Beteiligten. Im Durchführung und dem Abschluss des Praxispro- Projektstudium wird Reflektion daher zu verschie- jekts zu tun hat. Hier spielen Aspekte der Motiva- denen Anlässen ermöglicht und eingefordert. Dazu tion der Studierenden eine Rolle, wie auch die Si- zählen regelmäßige Reflexionsgespräche, die Zwi- cherstellung lernförderlicher Rahmenbedingungen, schenpräsentation, ein Fachgespräch und die Doku- die die Auswahl eines geeigneten Projekts maßgeb- mentation am Ende des Projekts. lich beeinflussen. Diese sind bisher im Konzept des Auf die Frage, zu welcher dieser Reflexionsan- Projektstudiums noch wenig berücksichtigt. lässe sich die Studierenden der Lernerträge des Pra- xisprojekts bewusst wurden (Mehrfachnennungen), Hypothese 5: Die personalen Rollen (Fach- gab knapp die Hälfte der Studierenden (52,63%, berater, Lernprozessbegleiter etc.) sind n=10/19) an, dass sie in der Lage waren, auch ohne eine wesentliche Unterstützung des selbst- die Anlässe des Projektstudiums zur Reflektion, sich gesteuerten Lernens der Studierenden der Projektfortschritte und Lernerträge des Projekt- Es wurde angenommen, dass Lernprozessbegleiter, studiums bewusst zu machen. Die andere Hälfte Fachberater, Vorgesetzte sowie Kommilitonen und

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 105 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Kollegen eine wesentliche Unterstützung der selbst gesteuerten Lernprozesse der Studierenden darstellen. Lernprozessbegleiter sind die Dozenten und Dozentinnen des Projektstudiums, die die Studie- renden methodisch betreuen, stets als Ansprech- partner zur Verfügung stehen, die Projektdokumen- tationen bewerten und die Reflexionsgespräche mit den Studierenden durchführen. Die Studierenden sollten jeweils bewerten, „wie wichtig die Unterstüt- zung durch die Lernprozessbegleiter (Projekt-Do- zenten) in den verschiedenen Projektphasen war“. Aus den Antworten der Teilnehmer geht hervor, dass die Unterstützung durch die Lernprozessbe- gleiters wichtig ist für das „Finden eines Praxispro- jekts“ (77,77% Zustimmung, n=14/19), „Reflektieren des Projekts (Reflexionsgespräche)“ (73,33% Zu- stimmung, n= 11/19) und „Auswerten des Projekts“ (68,75% Zustimmung, n=11/19). Weniger wichtig ist diese Hilfe für das „Planen des Praxisprojekts“ (46,67% Zustimmung, n=7/19), dem „Bearbeiten des Projekts“ (37,5% Zustimmung, n=6/19) sowie der „Dokumentation des Projekts“ (37,5% Zustimmung, n=6/19). Aus den Kommentaren der Teilnehmer geht zudem hervor, dass ein Mentor (Rolle des Vorgesetz- ten) aus dem Unternehmen gewünscht wird, der die Studierenden beim Finden eines geeigneten Projekts unterstützt und ihnen bei der Bearbeitung den Rü- cken freihält: „Es wäre sicher hilfreich, wenn von Beginn an Abb. 11: Unterstützung durch Lernprozessbegleiter JEDER Student einen unternehmensinternen Mentor (z.B. der Manager, der Kollege mit Erfahrung zum Studium, etc.) an der Zusammenfassend zeigen die Ergebnisse, dass Seite hat, der über die Lerninhalte des Studiums im Bilde ist und eine Unterstützung durch einen Lernprozessbeglei- eventuell proaktiv zur Vorbereitung (z.B. Themensuche) beitra- ter über das ganze Projekt hinweg, also am Anfang gen und den er fragen kann.“ (Projektfindung), während des Projekts (Reflektion) Aus den Kommentaren der Teilnehmer wird und auch am Ende des Projekts (Auswerten) wichtig ebenfalls die Bedeutung der Unterstützung der Stu- ist, um Lernerträge zu identifizieren und zu sichern. dierenden über den Austausch der Studierenden Dabei ist diese Unterstützung nicht für alle Tätig- untereinander deutlich. Aus den Kommentaren geht keitsbereiche gleichermaßen wichtig. Es gibt auch auch hervor, dass mehr Präsenz im Projektstudium Phasen bzw. Tätigkeiten, bei denen eine fachliche und eine Intensivierung des Austauschs unter den Unterstützung hilfreich ist. Zudem ist für bestimmte Kommilitonen gewünscht wird: „Die Kommilitonen wa- Aspekte auch die Unterstützung durch einen Men- ren sehr zurückhaltend und ich glaube, es wäre ein Mehrwert tor (Vorgesetzter) und der Austausch unter den Stu- gewesen, hätten wir gewusst, wer was bearbeitet.“ sowie „Öfter dierenden wichtig. eine Präsenzveranstaltung!“ sowie „Ich finde es auch sinnvoll, wenn man nach Projektabschluss die Ergebnisse im eigenen Hypothese 6: Unterstützung des selbstge- Kurs präsentieren würde. Das Interessante ist ja nicht nur die steuerten Lernens der Studierenden durch „Abarbeitung“ der Methodik, sondern der Einblick in andere IT-Unterstützung (Medien bzw. E-Learning- Themen, Ansätze und Unternehmen. Dies würde auch den Aus- Umgebung) tausch im Studiengang fördern.“ Als Hypothese 6 wurde angenommen, dass die E-

Learning-Umgebung (moodle) eine wichtige Unter-

stützung für das Lernen der Teilnehmer darstellt. Hierzu wurde gefragt, „ob sich die Teilnehmer mehr Informationen oder Austausch über die Lernplatt- form (moodle) gewünscht hätten“.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 106 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Dabei gaben alle 12 Studierenden, die das Profil „Data-Analyst/-in“ gewählt hatten (100%, n=12), an, dass sie im Rahmen der klassischen Lehrveranstal- tung überwiegend Dinge gelernt haben, die für das Praxisprojekt wichtig und nützlich waren. Keiner der Teilnehmer (n=0) gab an, dass sie das Praxispro- jekt auch ohne die vorherige Lehrveranstaltung hät- ten erfolgreich bewältigen können. Interessant ist, dass 15% (n=3) der Teilnehmer aussagten, dass auf- Abb. 12: Nutzung der Lernplattform grund der klassischen Lehrveranstaltung das Pro- jektstudium zu dem Thema „Data Analytics“ nicht

mehr erforderlich ist, um Probleme in der Praxis Nur ca. ein Drittel der Teilnehmer (35%, n=7) gab an, selbständig zu lösen. Es muss sich also um eine sehr dass sie sich mehr Informationen oder Austausch gute, praxisorientierte Lehrveranstaltung gehandelt über die Lernplattform (moodle) gewünscht hätten. haben. Die deutliche Mehrheit (65%, n=13) hat diesen Wunsch nicht. Bei der Auswertung der Kommentare wird deutlich, dass die Lernplattform kaum für den individuellen Wissenserwerb zur fachlichen Bewälti- gung des Projekts genutzt wurde (klassisches E- Learning). Vielmehr war die Plattform wichtig für a) die Organisation der Lehrveranstaltung, b) den Aus- tausch mit den Dozenten und c) den Austausch mit den anderen Studierenden. Zu a) „Frühere Abgabe des Projektes sollte ermöglicht werden.“, „Informationen zur ge- Abb. 13: Fachliche Fundierung „Data Analytics“ planten Herangehensweise“, „Beispiele wären hilfreich gewesen“, b) „Da die Dozenten versuchen, ALLE Fragen auch auf Zusammenfassend scheint die vorhergehende die Moodle-Plattform (also für alle) zu bringen, ist man über die klassische Lehrveranstaltung eine große Bedeutung wichtigsten Punkte meist informiert. Das sollte auch so beibe- für den Erfolg des Praxisprojekts zu haben. Darin ist halten werden.“ zu c) „Eventuell Vorstellung der Themen an- wahrscheinlich auch die geringe Bedeutung eines derer Kommilitonen, um ähnliche Problematik zu identifizieren „Fachberaters“ als unterstützende personale Rolle und Herangehensweise diskutieren zu können.“. begründet. Zusammenfassend lässt sich festhalten, dass eine E-Learning-Plattform im klassischen Sinne nicht erforderlich ist, da die Studierenden sich das Hypothese 8: Akzeptanz des Projektstudi- erforderliche Wissen selbständig aus Quellen im ums Unternehmen (Kollegen, Bücher etc.) oder im WWW beschaffen. Wichtig ist aber eine Online- Als Hypothese 8 wurde angenommen, dass das Pro- Plattform für die formale Organisation der Lehrver- jektstudium für die Studierenden eine attraktive anstaltung, aber vor allem für den Austausch mit Form der Lehre darstellt (Akzeptanz-Hypothese). den Dozenten sowie zwischen den Studierenden un- Hierzu sollte jeweils bewertet werden, „inwieweit tereinander. ein persönlicher Gewinn aus dem Projektstudium gezogen wurde“, „worin ungünstige Bedingungen Hypothese 7: Unterstützung des selbstge- bestanden“ und „was in Zukunft verbessert werden steuerten Lernens der Studis durch fachli- könnte“ sowie, ob „es leicht fiel, die Dokumentation che Fundierung zu erstellen“. Als Hypothese 7 wurde angenommen, dass die klassische Lehrveranstaltung zum Themengebiet des Praxisprojekts im vorherigen Semester eine wichtige fachliche Unterstützung für das Lernen und die Be- wältigung des Praxisprojekts der Teilnehmer darstellt. Hierzu wurde die Teilnehmer, die das Profil „Data-Analyst/-in“ gewählt hatten, befragt, „inwieweit die angebotene, klassische Lehrveranstaltung (Data Analytics) bei der Bewältigung des Projekts geholfen hat“.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 107 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Aus den Kommentaren der Teilnehmer geht zusätz- lich hervor, dass es schwierig ist, Projekte zu finden, die zeitlich genau in ein Semester passen (Semester- rhythmus, d.h. Start-/End-Termin und Dauer). Zu- dem kann es gerade bei großen Unternehmen mit länger laufenden Projekten schwierig sein, jedes Se- mester ein geeignetes Projekt zu finden, wenn diese Projekte keine Tätigkeiten für die unterschiedlichen Rollen des Projektstudiums beinhalten. Anderer- seits gab es aber bereits Beispiele, in denen die Stu- dierenden im gleichen Unternehmensprojekt im ersten Semester in der Rolle des IT Solution Developers und im zweiten Semester in der Rolle des Data Ana- lysten agierten.

Abb. 14: Persönlicher Gewinn

Die große Mehrheit der Teilnehmer (65%, n= 13) gab an, dass das Projektstudium als gewinnbringend für die persönliche und fachliche Entwicklung empfunden wurde. 40% (n=8) gaben an, dass das Projektstu- dium dazu beigetrage hat, dass die eigenen Kompe- tenzen im Unternehmen sichtbar wurden. Zudem gaben 25% (n=5) an, dass sie an Projekten beteiligt wurden, die sie sonst nicht hätten bearbeiten kön- Abb. 16: Aufwand für Dokumentation nen.

Als „ungünstige Bedingungen in den Unterneh- Zum Thema Dokumentation der Teilprozesse men, die die Arbeit am Praxisprojekt beeinträchtig- gab nur eine knappe Mehrheit von 52% (n=10/19) an, ten“, wurden vor allem ausgewählt (Mehrfachnen- dass die Teilprozesse leicht zu dokumentieren seien nungen möglich): (Mittelwert: 2,37). Dagegen gab eine deutliche Mehr- • Nicht genug Zeit verfügbar (61,11%, heit an (84%, n=16/19) an, dass für die Dokumenta- n=11/18) tion mancher Teilprozesse ich im Nachhinein Auf- • Schwer in meinem Unternehmen ein pas- wand betrieben werden musste (Mittelwert: 1,89). sendes Projekt zu finden (55,56%, n=10/18) Bezüglich der Dokumentation der Schlüsselsituatio- • Praxisprojekt nicht im gewohnten Arbeits- nen gaben nur 26% (n=5/19) an, dass sie sich die umfeld möglich (38,89%, n=7/18) Schlüsselsituationen mühsam ausdenken mussten (Mittelwert: 2,89), und 68% (n=13/19) gaben an, dass alle Schlüsselsituationen leicht zu dokumentieren waren (Mittelwert: 2,26). Zusammenfassend lässt sich feststellen, dass für über die Hälfte der Studierenden das Lernen unter erschwerten Bedingungen stattfand, weil die Arbeit im Praxisprojekt unter ungünstigen Lern-Bedingun- gen im Unternehmen stattfand. Insbesondere Zeit- mangel und hoher Projektdruck waren hierfür die Ursache. Die größte organisatorische Herausforde- rung besteht im Finden eines geeigneten Praxispro- jekts im Unternehmen, das sowohl zum Referenz- Abb. 15: Ungünstige Bedingungen projekt (Profil) als auch zum Zeitplan des Semesters passt. Zudem wurde die Aufgabe des Dokumentie-

rens der Teilprozesse von der Mehrzahl der Studie- Fehlende Unterstützung durch Vorgesetzte (5,56%, renden als schwierig und aufwendig empfunden. n=1/18) und erforderliche Geräte und Materialien nicht verfügbar (5,56%, n=1/18) werden dabei kaum als Problem genannt.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 108 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Schlussfolgerungen Es ist aber eine weitergehende Unterstützung erforderlich. Bspw. könnte das Spektrum mögli- Aus den Ergebnissen der Evaluation sind folgende cher Referenzprojekte erweitert werden (z.B. Re- Schlüsse zu ziehen: quirements Engineer/-in), passende Projekte in Schlussfolgerungen für das Konzept des anderen Unternehmen bereitgestellt werden o- Projektstudiums der die Durchführung über verschiedene Semes- ter ermöglicht werden. Das Konzept des Arbeitsprozess-integrierten Pro- • Ein Lernerfolg konnte zwar – insbesondere im jektstudiums hat sich prinzipiell bewährt: Bereich der fachlichen und methodischen Kom- Die Referenzprojekte stellen für die Mehrheit petenzen – nachgewiesen werden, aber dieser der Teilnehmer eine Orientierungshilfe zur Projekt- verteilt sich nicht gleichmäßig auf die verschie- findung (Hypothese 1) und eine Strukturierungs- denen Kompetenzbereiche. Insbesondere die hilfe für das Lernen (Hypothese 2) dar. Das Projekt- Stärkung der sozialen und personalen Kompe- studium führt zu einem Kompetenzerwerb im Be- tenzen wird nicht erkannt oder findet im Rah- reich des Tätigkeitsprofils (Hypothese 3) und die men des Projektstudiums zu wenig statt. Daraus Studierenden entwickeln die Fähigkeit zum selb- ergeben sich zwei Schlussfolgerungen: ständigen Lernen (Hypothese 4). Die Unterstützung • Erstens muss die bewusste Reflektion über des selbständigen Lernens durch personale Rollen, personale und soziale Kompetenzen verbes- insbesondere einen Lernprozessbegleiter, ist sehr sert und gefördert werden. Dies erfolgt der- wichtig (Hypothese 5). Die Unterstützung des Ler- zeit implizit über die Dokumentation von 10 nens durch eine IT-Umgebung (E-Learning) ist da- Schlüsselsituationen (Problem, Lösung, bei weniger für die Vermittlung von Fachinhalten, Lernertrag). Dies könnte durch die Pflicht aber für die formale Organisation und den Aus- zur Dokumentation von Lernerträgen expli- tausch zwischen den Beteiligten wichtig (Hypothese zit zu den verschiedenen Kompetenzberei- 6). Zudem ist die vorbereitende klassische Lehrver- chen erreicht werden. anstaltung von großer Bedeutung für den Erfolg • Zweitens muss das Lernen im Bereich der (Hypothese 7). sozialen und personalen Kompetenzen ex- Alle Studierenden haben das Projektstudium er- plizit gefördert und gefordert werden. Dazu folgreich bewältigt. Für sie war das Projektstudium bieten sich insbesondere die Förderung des durchgängig ein Erfolg. Die Mehrheit der Teilneh- Lernens in den Bereichen der Kommunika- mer sieht es als Chance, Neues zu erlernen und nutzt tion, des Verhandelns und des Führens an, es dafür aktiv. Darüber hinaus wird es von einer um den Studienzielen des Masterstudien- Mehrheit als gewinnbringend für die persönliche gangs „Professional IT-Business“ zu ent- und fachliche Entwicklung empfunden wurde. Das sprechen. Hierzu bedarf es einer Erweite- Projektstudium hat sogar dabei geholfen, dass die rung des Konzeptes der Arbeitsprozess-in- eigenen Kompetenzen im Unternehmen sichtbar tegrierten Projektstudium mit Fokus auf die wurden und dass Studierende an Projekten beteiligt Aneignung und Stärkung sozialer Kompe- wurden, die sie sonst nicht hätten bearbeiten können tenzen. (Hypothese 8). • In diesem Zusammenhang sehen wir weiteres Die Evaluation legt nahe, dass das Konzept des Optimierungspotential in der Verbesserung des Arbeitsprozess-integrierten Projektstudiums durch- Reflexionsprozesses. Insbesondere bei der Do- führbar ist, für die Studierenden einen Erfolg dar- kumentation fällt auf, dass die Studierenden oft- stellt und den gewünschten Kompetenzerwerb er- mals trotz der gezielten Fragen eher über das möglicht. Projekt berichten, anstatt zu getroffenen Ent- Optimierungspotenzial für das Projektstu- scheidungen oder Schlüsselsituationen tatsäch- dium lich reflektieren (Lernertrag). Es scheint, als würden die Studierenden nur zu den geforder- Ohne die obige Einschätzung relativieren zu wollen, ten zwei Zeitpunkten, nämlich zur Zwischen- zeigen die Ergebnisse Möglichkeiten der Verbesse- präsentation und zur Erstellung der Dokumen- rung sowohl des Konzepts als auch der praktischen tation für die Endpräsentation über ihre Schlüs- Umsetzung des Projektstudiums auf: selsituationen reflektieren. Dieser zeitliche Ab- • Die größte Herausforderung für die Studieren- stand zum Erlebten führt jedoch dazu, dass die den besteht darin, ein zum Referenzprojekt und Studierenden eher künstliche, nur scheinbar die Semesterzeitplan passendes Praxisprojekt in ih- Form wahrende Reflektionen formulieren. Um rem jeweiligen Unternehmen zu finden. Hierzu näher am Prozess und den erlebten Situationen wurde bereits das Projektstudium zeitlich von zu sein, müssten die Studierenden tatsächlich, der begleitenden bzw. vorbereitenden klassi- wie eigentlich auch gefordert, ihre Dokumenta- schen Lehrveranstaltung entzerrt (siehe unten). tion über die gesamte Projektzeit schreiben und

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 109 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

pflegen. Dies wäre ganz im Sinne eines reflective Dokumentation ist das Projektstudium reflektiert journals vgl. (Prior, 2016), als welches die Doku- und es ist Lerner-orientiert, da die Inhalte und die mentation gedacht ist. Eventuell müssen dazu Arbeitsabläufe aufgrund des individuellen Projek- weitere Prüfpunkte vereinbart werden, um die tes individualisiert sind. Der gesamte Lern- und Ar- Kontinuität der Reflektionen zu verbessern. beitsprozess läuft selbstorganisiert mit Unterstüt- • Bei den Studierenden zeigten sich unterschiedli- zung von Fachberatern und Lernprozessbegleitern che Grade an Selbststeuerung. Zwar haben die ab. Studierenden aufgrund der vorbereitenden Die hier berichtete Umfrage belegt, dass die Re- klassischen Lehrveranstaltung eine bestimmte ferenzprojekte eine gute Orientierungshilfe zur Pro- fachliche Vorerfahrung, doch diese kann den- jektfindung und eine gute Strukturierungshilfe für noch aufgrund des beruflichen Einsatzgebietes das Lernen darstellen. Die Mehrzahl der Studieren- immer noch recht unterschiedlich sein. So benö- den bezeichnet das Projektstudium als persönlichen tigen einige Studierenden eher Unterstützung Gewinn. Zudem wird mehrheitlich angegeben, dass bei der Bewältigung herausfordernder Aufga- die für die jeweiligen Rollen typischen Arbeitspro- ben, während andere Studierende (mit umfas- zesse nach Absolvieren des Projektstudiums besser sender Vorerfahrung) eher Hilfe beim Finden o- beherrscht werden. Die Mehrheit hat das Projektstu- der Initiieren lernhaltiger Situationen bzw. gar dium als Chance gesehen und auch aktiv genutzt, Projekte benötigen. Die fachliche Vorerfahrung um Neues zu erlernen. der Studierenden sowie die diversen Freiheits- Wesentliche Erkenntnisse hat die Umfrage über grade bei der Auswahl und Durchführung des die Reflektion zur Kompetenzgewinnung offenbart. Praxisprojekts müssen im Konzept und bei der Während noch eine Mehrzahl einen methodischen Arbeit der Lernprozessbegleiter in Zukunft stär- und/oder fachlichen Kompetenzgewinn angibt, re- ker berücksichtigt werden. Dies betrifft insbe- flektieren die Teilnehmer kaum persönlichen und sondere die Schaffung lernförderlicher Rahmen- gar keinen sozialen Kompetenzgewinn. Hierzu bedingung als auch die Motivation der Studie- muss eine Anpassung des Konzeptes dahingehend renden, die wesentlich die Auswahl von Projek- erfolgen, dass die Studierenden soziale Kompetenz ten beeinflussen. bewusst erlernen und darüber reflektieren. Bereits • Ein wesentliches Optimierungspotenzial besteht in den kommenden Durchgängen des Projektstudi- darin, jedem Studierenden einen „Mentor“ aus ums sollen die sozialen Kompetenzen besonders in dem Unternehmen explizit zuzuweisen, der so- den Bereichen der Kommunikation, des Verhan- wohl fachlich als auch organisatorisch unter- delns und des Führens gestärkt werden. Entspre- stützt. Zwar gibt es einen „Fachberater“ in der chende Erweiterungen und Optimierungen des Hochschule und die Rolle des „Vorgesetzten“ Konzeptes sind gegenwärtig in Arbeit und werden im Unternehmen sowie auch Kollegen, die fach- in einem zukünftigen Beitrag Berichtsgegenstand. lich und organisatorisch unterstützen sollen. Al- lerdings ist diese Unterstützung bisher implizit, Literatur d.h. nicht formal festgelegt. • Wie die Analyse der IT-Unterstützung gezeigt Brand, T. (2014): Evaluation einer arbeitsprozessori- hat, sehen die Studierenden einen großen Bedarf entierten IT-Weiterbildung: „IT-Spezialisten“. in der Unterstützung des Austauschs unterei- Dissertation, Erfurt, Universität Erfurt. nander. Daher sollte auch der Austausch unter Buhr, R.; Freitag, W.; Hartmann, E.A.; Loroff, C.; den Studierenden gefördert werden, um als Minks, K.H.; Mucke, K.; Stamm-Riemer, I. (2008) „Learning Community“ einen gegenseitigen (Hrsg.): Durchlässigkeit gestalten! Wege zwi- Mehrwert zu schaffen. schen beruflicher und hochschulischer Bildung. Münster, Waxmann. Zusammenfassung und Ausblick Dingsoer, T. (2005): Postmortem reviews: purpose Die Ergebnisse der Umfrage legt nahe, dass sich das and approaches in software engineering. Infor- Konzept und die praktische Umsetzung des Arbeits- mation a. Software Technology, 47 (5), 293-303. prozess-integrierten Lernens im Projektstudium Freitag, W.; Hartmann, E.A.; Loroff, C.; Stamm-Rie- prinzipiell bewährt hat. Das Arbeitsprozess-inte- mer, I.; Volk,̈ D.; Buhr, R. (2011) (Hrsg.): Gestal- grierte Projektstudium ist praxisorientiert, da reale tungsfeld Anrechnung - Hochschulische und be- Projekte in Unternehmen durchgeführt werden. Es rufliche Bildung im Wandel. Münster, ist prozessorientiert, da das Lernen in und entlang Waxmann. von Arbeitsprozessen erfolgt. Es ist erfahrungsgelei- Fuchs-Kittowski, F.; Freiheit, J.; Siegeris, J. (2017): tet, denn die Projektarbeit selbst ist Lern- und Re- Arbeitsprozess-integriertes Projekt-Studium in flektionsgegenstand. Aufgrund der häufigen Reflek- Unternehmen. In: Tagungsband des 15. tion in Zwischen- und End-Präsentation sowie der

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 110 Evaluation des Arbeitsprozess-integrierten Projektstudiums Frank Fuchs-Kittowski, Juliane Siegeris und Jörn Freiheit, HTW Berlin

Workshops "Software Engineering im Unter- richt der Hochschulen" 2017, 41-50 Götz, K. (1993): Zur Evaluierung beruflicher Weiter- bildung. Deutscher Studienverlag, Weinheim. Mattauch, W.; Kubath, S. (2005): Evaluation der ar- beitsprozessorientierten Weiterbildung. ISST- Bericht 74/05, Berlin, Fraunhofer ISST. Platt, L. (2014): The ‘wicked problem’ of reflective practice: a critical literature review, Innovations in Practice 9 (1). Prior, JR, Arjpru, S; Leaney, JR (2014): 'Towards an industry-collaborative, reflective software learning and development environment. In: Proc. of the 23rd Australasian Software Engineering Conf. ASWEC 2014, IEEE, Sydney, Australia. Prior, JR.; Ferguson, S.; Leaney, J. (2016): Reflection is hard: teaching and learning reflective practice in a software studio. In: Proc. of the Australasian Computer Science Week ACSW ’16, Canberra, Australia, 2016, 1–8. Schön, DA. (1983): The reflective practitioner: how professionals think in action. New York: Basic Books. ISBN 046506874X. OCLC 8709452. Upchurch, R.; Sims-Knight, J. (1999): Reflective Es- says in Software Engineering. In: Proc. of 29th ASEE/IEEE Frontiers in Education Conference, IEEE, San Juan, Puerto Rico. Wottawa, H.; Thierau, H. (1990): Handbuch Evalua- tion. Bern: Verlag Hans Huber.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 111 Lernzieldeﬁnitionen für Software Engineering — the Good, the Bad and the Ugly

Axel Böttcher, Veronika Thurner, Olga Nikoliai Fakultät für Informatik und Mathematik, Hochschule München .@hm.edu

Zusammenfassung Abstract Spätestens seit der Bologna-Reform sind wir als Leh- At least since the Bologna reform, we the lecturers are rende immer wieder dazu angehalten, Modulbeschrei- expected to compose or refine module descriptions bungen zu verfassen oder zu überarbeiten und in die- which comprise the definition of competence oriented sen kompetenzorientierte Lernziele zu definieren. learning objectives. Um die Qualitätssicherung von Lernzieldefinitionen To support the quality assurance of definitions of zu unterstützen hatten wir zunächst die Absicht, ein learning objectives, our first intention was to develop Softwarewerkzeug zur automatisierten Qualitätsprü- a software tool that automatically quality checks def- fung von Lernzieldefinitionen zu realisieren. Dabei initions of learning objectives. However, we quickly haben wir schnell festgestellt, dass vor einer Automa- realized that prior to an automization, a host of still tisierung noch viele offene Fragen auf konzeptueller open questions has to be clarified on a conceptual Ebene zu klären sind, hinsichtlich Kriterien und Indi- level, with regard to criteria and indicators for the katoren für die Qualität von Lernzieldefinitionen. Mit quality of learning objectives. This work is intended dieser Arbeit wollen wir eine Diskussion der Erkennt- to initiate a discussion of our findings. nisse anstoßen, die wir bei der Untersuchung dieser Starting from the observation that our curricula are Fragen gewonnenen haben. viewed from the different perspectives of lecturers, Ausgehend von der Beobachtung, dass unsere Cur- learners, accreditation organizations and employers, ricula aus den verschiedenen Perspektiven von Leh- we specify quality criteria for competence oriented renden, Lernenden, Akkreditierungsagenturen sowie learning objectives as a first step. Arbeitgebern betrachtet werden, formulieren wir zu- As a second step, we systematically analyzed the nächst Qualitätskriterien für kompetenzorientierte descriptions of software related modules. Based on Lernzielbeschreibungen. these empirical results, we identify indicators for posi- Auf Basis dieser Kriterien haben wir systematisch tive (good) and less positive (ugly to bad) definitions Beschreibungen für Software-bezogene Module analy- of learning objectives. Subsequently, we generalize siert. Anhand von diesen empirischen Befunden iden- these into more abstract criteria, name the respective tifizieren wir Indikatoren für positive (good) und we- underlying principle and appraise their relevance for niger positive (ugly bis bad) Lernzielbeschreibungen. the quality of a definition of learning objectives. Diese abstrahieren wir anschließend zu allgemeine- Well formulated definitions of learning objectives ren Kriterien, benennen das jeweils zugrundeliegende describe the intended learning outcome in a compe- Prinzip und gewichten diese Kriterien sodann nach tence oriented way, i. e., as a combination of content ihrer Bedeutung für die Qualität einer Lernziedefiniti- and action, which is expressed as an observable be- on. haviour and in a student centered way. As well, good Gute Lernzieldefinitionen beschreiben das ge- learning objectives are easy to understand, unambigu- wünschte Lernergebnis kompetenzorientiert, d. h. als ous and to the point. eine Kombination aus Inhalt und Handlungskompo- A first empirical analysis of existing module de- nente, die in Form von beobachtbarem Verhalten in scriptions indicates that there is still lots of room for Studierenden-zentrierter Form formuliert ist. Sie sind improvements in this area. dabei in ihrer Bedeutung verständlich, eindeutig und auf den Punkt. Eine erste empirische Analyse von bestehenden Mo- dulbeschreibungen zeigt, dass diesbezüglich noch viel- fältiges Verbesserungspotenzial vorhanden ist.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 112 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

1 Motivation dern wir von unseren Studierenden, dass sie Fähigkei- Spätestens seit der Bologna-Reform steht fest, dass für ten und Fertigkeiten entwickeln, die zwar auf Fakten- nahezu alle an europäischen Hochschulen durchge- wissen basieren, aber in ihrer Handlungsdimension führten Lehrveranstaltungen als Grundlage eine Mo- weit über das reine Wiedergeben dieses Faktenwis- dulbeschreibung zu erstellen ist. In dieser ist unter sens hinaus gehen. Nur wenn die Studierenden die anderem zu definieren, welche Lernergebnisse dieses faktischen Inhalte zielgerichtet und problemlösungs- Modul anstrebt, d. h. in den Studierenden entwickeln orientiert einsetzen und dabei die Qualität der ver- soll. Diese Lernergebnisse sind auf kompetenzorien- wendeten Vorgehensweise ebenso wie der erzielten tierte Weise zu beschreiben. Ergebnisse treffend beurteilen können, sind sie auf die Anforderungen des Arbeitsmarktes angemessen vor- Gemäß der Definition von Weinert (Weinert, 2001, bereitet. Entsprechend müssen kompetenzorientierte S. 27) verstehen wir unter Kompetenzen „die bei In- Lernzieldefinitionen die geforderten Fähigkeiten und dividuen verfügbaren oder durch sie erlernbaren ko- Fertigkeiten auf handlungsorientierte Weise so for- gnitiven Fähigkeiten und Fertigkeiten, um bestimmte mulieren, dass die unterschiedlichen Expertise-Grade Probleme zu lösen, sowie die damit verbundenen mo- darin erkennbar werden. tivationalen, volitionalen und sozialen Bereitschaften und Fähigkeiten, um die Problemlösungen in varia- Des Weiteren wurde mit dem Grundgedanken des blen Situationen erfolgreich und verantwortungsvoll Constructive Alignment (Biggs u. Tang, 2011) die nutzen zu können“. Kompetenzen drücken also ein Sinnhaftigkeit kompetenzorientierter Lernzieldefini- Handlungspotenzial eines Individuums in einer be- tionen untermauert, sowohl auf der psychologischen stimmten Situation aus, d. h. die Fähigkeit, bei Bedarf als auch auf der handwerklichen Ebene. Eine klare etwas Bestimmtes zu tun. Sie umfassen immer sowohl Zielvorstellung zu haben ist für uns als Lehrende die eine inhaltliche als auch eine prozessuale Komponen- Voraussetzung dafür, passende Lehr-Lern-Methoden te (UZH, 2008). Der Inhalt bestimmt, um was es dabei auszuwählen und einzusetzen, die möglichst syste- eigentlich geht, beschreibt somit den Gegenstand, auf matisch auf das Erreichen des gesetzten Lernzieles den sich die Kompetenz bezieht. Die Handlungskom- hinwirken. Analog dazu ist die Prüfung so zu gestal- ponente dagegen legt die Art der Tätigkeit fest, die auf ten, dass sie möglichst fokussiert das Erreichen der bzw. mit dem Inhalt durchzuführen ist, repräsentiert Lernziele überprüft. Beides setzt ein klares Verständ- also das Kompetenzniveau, d. h. den zu erreichenden nis der Lernziele voraus. Grad an Handlungsbefähigung. Halten wir also fest, dass die kompetenzorientierte Lernzieldefinition notwendiger und sinnvoller Be- Auch in der Vor-Bologna-Ära wurde an deutschen standteil einer jeden Modulbeschreibung ist, die viel- Hochschulen das verfügbare Lehrangebot dokumen- fältigen Nutzen stiftet. Trotz der immensen Wichtig- tiert, ehemals in Form von gedruckten Vorlesungsver- keit kompetenzorientierter Lernzieldefinitionen sind zeichnissen. Ähnlich wie die heutigen Modulbeschrei- die real existierenden Modulbeschreibungen, die man bungen sollten auch jene Urversionen eine Vorstel- so findet, jedoch qualitativ sehr unterschiedlich – the lung davon vermitteln, was die angehenden Hörerin- Good, the Bad and the Ugly. nen und Hörer in der Vorlesung, bzw. dem Modul, erwartet. In der Regel fokussierten diese Beschreibun- Hier besteht also weiterhin Handlungsbedarf, denn gen einen Fachbegriff-reichen Titel, der im Idealfall nur qualitativ gute Lernzieldefinitionen führen auch noch konkretisiert wurde durch eine Liste von zu be- zu dem erhofften Nutzen. handelnden Inhalten, jedoch meist ohne ergänzende Handlungskomponente. 2 Stand der Praxis Um die Bologna-Vorgaben zu erfüllen mussten die- Ein Lernziel beschreibt das am Ende eines Lernpro- se rudimentären Inhaltsangaben der historischen Mo- zesses erwünschte Ergebnis derart, dass nachprüfbar dulbeschreibungen zu kompetenzorientierten Lern- ist, ob dieses erwünschte Ergebnis auch tatsächlich zieldefinitionen ausgebaut werden. Dieser Prozess erreicht wurde (Terhart, 2005, S. 111f). Lernziele be- war mit diversen Stolpersteinen unterschiedlicher Art schreiben also möglichst exakt die angestrebten Lern- durchsetzt, rangierend von psychologischen („Wozu ergebnisse (Arnold u. a., 1999, S. 79). soll DAS denn gut sein?“) bis hin zu handwerklichen Darüber, ob ein definiertes Lernziel ein Versprechen („Kompetenz ist halt, wenn ich den Inhalt kann, das ist darstellt oder nicht, herrscht in der Praxis eine gewis- doch klar!“). Die ersten Ergebnisse dieser Bemühun- se Uneinigkeit. Häufig sind Lernziele so formuliert, als gen wirkten gelegentlich eher wie das Resultat einer würde keinerlei Zweifel daran bestehen, dass sie auch ungeliebten, aber verpflichtenden Fingerübung, blie- erreicht werden, wie beispielsweise „Sie als Teilneh- ben dabei in ihrem Nutzen jedoch wenig erhellend. mende durchdringen das Prüfungsrecht aus Sicht des Mittlerweile hat sich die Erkenntnis etabliert, dass Prüfers und der Studierenden. Sie wenden es in der in Zeiten der universellen Verfügbarkeit von Fakten- Prüfungssituation sicher an“ (DiZ, 2018). wissen über das Internet der Erwerb dieses Faktenwis- De facto machen jedoch die meisten Lehrenden sens für sich alleine als Lernziel einer akademischen und auch viele Lernende früher oder später die Er- Ausbildung keinesfalls ausreichend ist. Vielmehr for- fahrung, dass eben nicht alle Teilnehmenden auch

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 113 Lernzieldefinitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München die gewünschten Ziele in vollem Umfang erreichen. dert wird ein Nachweis für die kontinuierliche Über- Entsprechend sind in der Praxis die angestrebten Lern- prüfung und Weiterentwicklung der Qualifikations- ziele also nicht zwangsweise deckungsgleich mit den ziele. Des Weiteren hinterfragen die Akkreditierungs- tatsächlich erreichten Lernergebnissen (Bischoff u. a., agenturen, inwieweit das jeweilige Curriculum dazu 2017). In einer Handreichung der HRK zur Formu- geeignet erscheint, die definierten Qualifikationsziele lierung von Lernzielen schlägt (Gröblinghoff, 2013) auch tatsächlich zu erreichen. daher vor, der Zielformulierung gedanklich das Präfix Einzelne Fragmente in den Handreichungen der Ak- „Bei Abschluss des Lernprozesses wird der erfolgreiche kreditierungsagenturen weisen darauf hin, dass auch Student in der Lage sein, ...“ voranzustellen. hier nach wie vor eine gewisse Dozierenden-zentrierte Lernziele beschreiben das Handlungspotenzial, das Sichtweise besteht, die impliziert, dass Kompetenzen Studierende durch die erfolgreiche Teilnahme an einer von den Lehrenden vermittelt werden können und Lehrveranstaltung entwickeln (sollen). Dieses Hand- nicht von den Lernenden selbst entwickelt werden lungspotenzial wird durch Verben ausgedrückt (Biggs müssen. Typische Negativbeispiele sind Formulierun- u. Tang, 2011, Kap. 7), die unterschiedliche Exper- gen wie „Welche Qualifikationsziele werden vermit- tisegrade differenzieren. Üblicherweise orientieren telt?“ (ACQUIN, 2014) bzw. „Die Studierenden wer- sich die Definitionen kompetenzorientierter Lernzie- den in die Lage versetzt...“ (AQAS, 2016), welche den le dabei an etablierten Lernzieltaxonomien aus der Eindruck erwecken, als könnten Studierende quasi Literatur. Weit verbreitet ist die sechsstufige Taxono- von außen befähigt werden. mie von Bloom (Bloom u. a., 1956), die mittlerweile häufig in der Überarbeitung von Anderson und Krath- 3 Ziel wohl verwendet wird (Anderson u. a., 2001). Diese Wie bereits dargelegt betrachten wir Modulbeschrei- unterscheidet die kognitiven Ebenen Erinnern, Verste- bungen mit kompetenzorientierten Lernzieldefinitio- hen, Anwenden, Analysieren, Evaluieren und Kreieren. nen als eine wesentliche Informationsquelle, die ins- Neben diesen sechsstufigen Taxonomien sind auch besondere für Studierende und Lehrende, aber auch dreistufige Modelle in Gebrauch. Beispielsweise dif- für Arbeitgeberinnen und Arbeitgeber sowie für Ak- ferenzieren (Schneider, 2002; Hauer, 2011) die drei kreditierungsagenturen von zentraler Bedeutung sind. Ebenen Reproduktion, Anwendung und Übertragung, Entsprechend sehen wir speziell die Lernzieldefinitio- was (Metzger u. Nüesch, 2004; UZH, 2008) zu Wie- nen als zentrales Instrument für die Gestaltung unsere dergeben, Wissen und Anwenden sowie Probleme bear- Lehre sowie für die systematische Reflexion über die- beiten ausgestalten. Um die Überprüfbarkeit des Errei- se. Wir wollen also weg vom rein pflichterfüllenden, chens der Lernziele zu gewährleisten, wird empfohlen, schematischen Definieren und statt dessen hin zu sinn- ausschließlich solche Verben zu verwenden, die eine vollem, Klarheit stiftenden Inhalt. beobachtbare Handlung beschreiben (Kennedy, 2008; Unser initiales Ansinnen war, ein Softwarewerkzeug Hollender, 2010). zur automatisierten Qualitätsprüfung von Modulbe- Viele Hochschulen stellen Leitfäden für die Erstel- schreibungen zu realisieren, das bei der Erstellung lung von Modulbeschreibungen bereit. Diese legen bzw. Weiterentwicklung von Modulbeschreibungen in der Regel fest, welches Stufenmodell den Lernziel- deren Qualitätssicherung unterstützt, analog zu ei- definitionen zugrunde liegen soll und welche Verben ner Unit Test Stage. Nach ersten Experimenten mit jeweils für die Formulierung von Lernzielen auf den Systemen zur Sprachanalyse oder Ähnlichem wurde verschiedenen kognitiven Taxonomiestufen genutzt schnell sichtbar, dass vor der automatisierten Quali- werden sollen (FH Furtwangen, 2013; Uni Würzburg, tätsprüfung zunächst eine Fülle noch offener Fragen 2013; Cursio u. Jahn, 2015; TUM, 2016; Bischoff u. a., auf konzeptueller Ebene zu klären ist, um Qualitäts- 2017). Teilweise enthalten diese Leitfäden auch de- kriterien einerseits und typische Fehlermuster ande- tailliert begründete Negativbeispiele. Einige dieser rerseits zu konkretisieren. Leitfäden wirken ebenso fundiert wie pragmatisch Dafür sind zunächst die Personengruppen zu identi- auf den Punkt gebracht, bieten also den Modulver- fizieren, welche die Lernzieldefinitionen primär nut- antwortlichen eine sehr gute Ausgangsbasis. Dennoch zen, und deren spezifische Anforderungen an die Lern- ist die Existenz eines hervorragenden Leitfadens zur zieldefinitionen zu klären. Aus diesen Anforderun- Erstellung von kompetenzorientierten Modulbeschrei- gen ergeben sich Qualitätskriterien, die eine konkrete bungen an einer Institution kein Garant dafür, dass Lernzieldefinition erfüllen muss, damit sie diesen An- die an dieser Institution existierenden Modulbeschrei- forderungen gerecht wird. Darauf aufbauend lassen bungen auch tatsächlich alle diese wohl durchdachten sich Indikatoren entwickeln, die darauf hinweisen, ob Vorgaben erfüllen. und ggf. inwieweit diese Qualitätskriterien erfüllt oder Akkreditierungsagenturen verlangen in ihren Richt- verletzt sind. D. h. es ist zu klären, was genau eine linien üblicherweise die Beschreibung von Inhalten Lernzieldefinition good, bad oder ugly macht. und Qualifikationszielen, ohne dabei jedoch nähere Die dabei gewonnenen Erkenntnisse zu Qualitäts- Vorgaben zu deren Formulierung bzw. Detailgrad fest- kriterien und -indikatoren für kompetenzorientierte zulegen, siehe z. B. (ACQUIN, 2014). Ebenfalls gefor- Lernzieldefinitionen teilen wir in dieser Arbeit, um

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 114 Lernzieldefinitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München sie für andere nutzbar zu machen – auch jenseits der Ebenfalls hochrelevant sind kompetenzorientierte Automatisierung. Das Verständnis dieser Aspekte ist Lernzieldefinitionen, um bei der Gestaltung ei- die Grundlage für eine systematische Qualitätssiche- nes Curriculums die Stringenz des Aufbaus eines rung von Modulbeschreibungen. Diese ist aufgrund Studienganges sicherzustellen. Dabei muss insbe- der hohen Stückzahl von Modulen in einem Studien- sondere eine aus Sicht des iterativ-inkrementellen gang typischerweise ein sehr aufwändiges Unterfan- Kompetenzerwerbs sinnhafte Reihenfolge der Mo- gen – aber dennoch erforderlich, nicht nur kurz vor dule gewährleistet sein, welche einen sukzessiven der (Re-)Akkreditierung. Je klarer die Vorstellung dar- Kompetenzzuwachs choreographiert und gleich- über ist, was eine gute Lernzieldefinition ausmacht, zeitig Lücken und Redundanzen vermeidet. umso schneller und treffsicherer geht die Qualitätssi- cherung von der Hand. Mit dieser Arbeit leisten wir • Arbeitgeberinnen und Arbeitgeber nutzen die kom- somit einen Beitrag zur Verbesserung der Qualität von petenzorientierten Lernzieldefinitionen zuneh- kompetenzorientierten Lernzieldefinitionen. mend, um diese mit dem von ihnen benötigten Fernziel wäre dann die darauf basierende Entwick- Kompetenzprofil abzugleichen. Angesichts der Fül- lung von Templates mit Best Practices und die Ausar- le der heute verfügbaren Studienangebote einer- beitung von Leitfäden zur Definition kompetenzori- seits und der Diversität von Aufgabenstellungen entierter Lernziele, was jedoch den Rahmen dieser auf dem Arbeitsmarkt andererseits ist gerade in Arbeit sprengen würde. der IT-Branche die Suche nach einem „Informa- tiker (m/w/d)“ zunehmend unüblich. Statt des- 4 Anforderungen an sen geht der Trend dahin, Kompetenzprofile von Studienverläufen mit Anforderungsprofilen von kompetenzorientierte Job-Beschreibungen abzugleichen und so den Aus- Lernzielbeschreibungen wahlprozess explizit fähigkeitsorientiert zu gestal- Die in den Modulbeschreibungen dokumentierten ten. Lernzieldefinitionen sind für verschiedene Personen- gruppen von Bedeutung: • Nicht zuletzt blicken die Akkreditierungsagentu- ren im Rahmen der Qualitätssicherung von Stu- • Aus Sicht der Studierenden definiert die Modulbe- diengängen ebenfalls auf die Lernzieldefinitionen. schreibung die Prüfungsanforderungen und bie- Sie evaluieren auf dieser Basis sowohl die Strin- tet damit eine wichtige Orientierungshilfe für die genz des Aufbaus des Studienganges als auch die Gestaltung der studentischen Selbstlernzeit. Im Bedarfsgerechtigkeit der damit zu erlangenden Hinblick auf eine Mobilitätsentscheidung hilft sie Kompetenzen mit Blick auf die Erfordernisse von bei der Auswahl von äquivalenten und damit an- Gesellschaft und Arbeitsmarkt. erkennungsfähigen Angeboten im Ausland. Und Gleichzeitig stellen sie sicher, dass die oben ge- nicht zuletzt vermittelt eine handlungsorientier- nannten Bedürfnisse der jeweiligen Interessen- te Beschreibung der Lernziele einen Einblick in gruppen durch die verfügbaren Lernzieldefinitio- das zu erwartende Tätigkeitsfeld des angestrebten nen auf angemessene Weise erfüllt werden. Berufsbildes und dient damit als Entscheidungs- grundlage für eine fundierte Auswahl des „richti- Jede dieser Personengruppen blickt aus ihrer in- gen“ Studiengangs. dividuellen Perspektive auf die Lernzieldefinitionen. Daraus ergeben sich entsprechend unterschiedliche • Für die Lehrenden ist die kompetenzorientierte Ausprägungen von Anforderungen. Lernzieldefinition elementares Handwerkszeug Gemäß der heute immer noch weit verbreitet ge- bei der Ausgestaltung einer Veranstaltung, in- nutzten Definition von (Mager, 1972, S. 19) ist ein klusive des Leistungsnachweises, im Sinne des Lernziel „eine zweckmäßige Zielbeschreibung (. . . ), Constructive Alignment. Darüber hinaus bietet mit der es gelingt, die Unterrichtsabsichten dem Leser der Erstellungsprozess einer kompetenzorientier- mitzuteilen. Eine gute Zielbeschreibung schließt dar- ten Lernzieldefinition umfassendes Potenzial zur über hinaus eine möglichst große Anzahl möglicher Selbstreflexion: Was lehre ich hier eigentlich? Und Missdeutungen aus“. warum? Wofür ist das später wichtig? Aus dieser Definition heraus ergeben sich unmittel- Auch Lehrenden, die neu in ein Modul einstei- bare Hinweise auf Qualitätskriterien. Zunächst soll gen, dient eine kompetenzorientierte Lernzielde- die Zielbeschreibung „zweckmäßig“ sein, also einer- finition als Orientierung bei der eigenen Ausge- seits die benötigten Informationen bereit stellen, oh- staltung der Veranstaltung und der zugehörigen ne andererseits unnötigen Aufwand beim Erstellen Prüfungen. Vorsitzende von Prüfungskommissio- bzw. Verarbeiten zu generieren. Des Weiteren teilt die nen wiederum nutzen die Lernzieldefinition als Lernzieldefinition das Ziel bzw. die Unterrichtsabsicht Entscheidungsgrundlage für die Anerkennung von mit. Sie fokussiert also das zu erreichende Ergebnis Vorerfahrungen bzw. andernorts erbrachten Stu- und nicht den Weg dahin, also nicht die Schritte des dienleistungen. Lernprozesses. Darüber hinaus schließt eine gute Lern-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 115 Lernzieldefinitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München zieldefinition Missdeutungen aus. Sie ist also inhaltlich stoß gegen ein Positiv-Kriterium die Lernzieldefinition eindeutig sowie verständlich formuliert. auf semantische oder auf syntaktische Weise hässlich Daraus leiten wir die folgenden Qualitätskriterien wird. Als semantisch hässlich betrachten wir die Ver- ab: letzung von Kriterien, welche die Eindeutigkeit (also • Effizient / auf den Punkt die Sicherheit vor Missdeutung) fokussieren bzw. die • Ergebnisorientiert (nicht prozessorientiert) Ergebnisorientierung der Lernzieldefinition gewähr- • Eindeutig leisten. Diese Kriterien sehen wir als besonders rele- • Verständlich vant an. Wird in einer konkreten Lernzieldefinition Dabei ist zu beachten, dass Verständlichkeit indivi- eines oder mehrere dieser Kriterien verletzt, fällt diese duell sehr unterschiedlich wahrgenommen wird. Ins- Lernzieldefinition in die Äquivalenzklasse the Bad. besondere haben Studierende bzw. Studieninteressier- Im Gegensatz dazu klassifizieren wir die Verletzung te, die noch über wenig bis gar kein Domänenwissen von Kriterien, welche primär das Qualitätskriterium verfügen, hier völlig andere Bedarfe und eine andere Effizienz adressieren, als syntaktisch hässlich. Syntak- Wahrnehmung als Personen, die in dieser Domäne als tisch hässliche Lernzieldefinitionen sind zwar in ihrer Experten gelten. inhaltlichen Aussage prinzipiell klar definiert, aber so ungünstig in Sprache verpackt, dass diese inhaltliche 5 Vorgehensweise Aussagekraft nur mit entsprechender Mühe (und in Basierend auf diesem Grundverständnis der Anforde- der Folge mit einer gewissen „Unfallgefahr“) erkenn- rungen der verschiedenen Personengruppen an Lern- bar ist. Derartige Lernzieldefinitionen sind Repräsen- zieldefinitionen sowie der abgeleiteten Qualitätskrite- tanten von the Ugly. rien sind im nächsten Schritt Indikatoren zu identifi- Am Übergang zwischen the Bad and the Ugly liegen zieren, die darauf hinweisen, ob eine konkrete Lern- Lernzieldefinitionen, die gegen das Qualitätskriteri- zieldefinition im Sinne dieser Anforderungen und Qua- um Verständlichkeit verstoßen. Wenn eine bestimmte litätskriterien good, bad oder ugly ist. Person eine Lernzieldefinition nicht versteht, ist das aus Sicht dieser Person ähnlich schlimm, als wenn die 5.1 Prozess Lernzieldefinition semantisch uneindeutig ist – auch Zentraler Bestandteil einer kompetenzorientierten wenn anderen Personen die Bedeutung dieser Lernziel- Lernzieldefinition ist neben der Inhaltskomponen- definition klar ist. Dieses Kriterium ist insbesondere te auch das intendierte Handlungspotenzial. Dieses mit Blick auf die Personengruppe der Studierenden wird in der Regel ausgedrückt über Verben. In un- bzw. Studieninteressierten von großer Bedeutung. Die- serem ersten Ansatz der Analyse von Lernzieldefini- se sind in der Regel zu dem Zeitpunkt, zu dem sie tionen haben wir daher diese Verben automatisiert sich mit einer bestimmten Modulbeschreibung aus- aus den ersten von uns gesammelten Lernzieldefinitio- einander setzen, mit den in diesem Modul adressier- nen extrahiert mit Hilfe des Stanford Part-of-Speech- ten Inhalten noch nicht vertraut, da diese im Verlauf Tagger (Toutanova u. a., 2003), welcher in der Web- des Moduls ja erst gelernt werden sollen. Um die seite wortarten.info für die Deutsche Sprache inte- Verständlichkeit einer Lernzieldefinition sicherzustel- griert ist. Diese automatisierte Analyse hat zwar zu len müssen bei der Erstellung die unterschiedlichen ersten empirisch begründeten Erkenntnissen geführt, Expertise-Ebenen und fachlichen Hintergründe der aber schnell klar gemacht, dass ergänzend zu den verschiedenen Zielgruppen entsprechend berücksich- Verben noch weitere Indikatoren zu betrachten sind. tig werden. Um diese Indikatoren zu identifizieren haben wir eine Vielzahl von Modulbeschreibungen gesammelt, 5.2 Datenbasis deren Lernzieldefinitionen analysiert und diese dann Als Databasis für unsere Analysen haben wir von 39 als good oder bad im Sinne der oben genannten Qua- deutschen Hochschulen für angewandte Wissenschaf- litätskriterien klassifiziert. Dabei haben wir für kon- ten sowie von fünf deutschen Universitäten Modulbe- krete Beispiele herauspräpariert, was genau an diesen schreibungen gesammelt, aus dem fachlichen Umfeld Lernzieldefinitionen jeweils gut oder schlecht ist. Die von Softwareentwicklung bzw. Software Engineering so auf der konkreten Ebene identifizierten Indikatoren in Informatik-nahen Studiengängen. Betrachtet wur- haben wir anschließend hochabstrahiert zu Kriterien den dabei diejenigen Hochschulen für angewandte und das jeweils zugrunde liegende Prinzip benannt, Wissenschaften bzw. Universitäten, die in den Ranglis- sowohl für positive als auch für negative Beispiele. ten des Hochschulrankings der Wirtschaftswoche von Abschließend haben wir diese abstrahierten Krite- 2018 sowie dem CHE-Ranking auf den oberen Plätzen rien nach ihrer Relevanz gewichtet bzw. sortiert. Ins- aufgelistet sind, denen also eine hohe Qualität in der besondere für die Negativ-Kriterien ergab sich daraus Lehre attestiert wurde. Ebenfalls betrachtet wurden eine Abstufung zwischen the Bad und the Ugly (siehe alle Hochschulen aus dem UAS7-Verbund, die sich Abbildung 1). selbst als „dem höchsten Qualitätsstandard in [der] Bei dieser Gewichtung der abstrahierten Kriterien Lehre [...] verpflichtet“ (www.uas7.de) sehen. Ergän- unterscheiden wir insbesondere, ob bei einem Ver- zend wurden die Hochschulen und Universitäten in

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 116 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

Abbildung 1: Verletzung von Qualitätskriterien und deren Folgen unserer unmittelbaren geographischen Nachbarschaft aus unterscheiden. Entsprechend vermuten wir mit betrachtet. eine Korrelation zwischen der jeweiligen Akkredi- Im nächsten Schritt wurden an den so ausgewähl- tierungsagentur und der Form sowie ggf. Qualität ten Institutionen die Informatik-nahen Studiengän- der Lernzieldefinitionen in den Modulbeschrei- ge im Bachelor-Bereich identifiziert, mit Fokus auf bungen. „Informatik“, „Allgemeine Informatik“, „Angewandte Informatik“ und „Praktische Informatik“. Innerhalb • Lernzieldefinitionen, Inhalte und Lehrformen dieser Studiengänge konzentrierten wir uns dann auf Diese Daten lagen im eigentlichen Fokus unserer all diejenigen Module, die „Softwareentwicklung“ und Untersuchung. Um bei unserer Analyse eine ent- „Software Engineering“ adressieren, also auch „(Ob- sprechende Präzision zu gewährleisten und Miss- jektorientierte) Programmierung“, „Softwaretechnik“, deutungen zu vermeiden wurde explizit dokumen- „Programmiermethodik“, „Techniken der Programm- tiert, wie die einzelnen Institutionen innerhalb ih- entwicklung“ sowie Modulen zu konkreten Program- rer Modulbeschreibungen die jeweiligen Rubriken miersprachen. Ebenfalls berücksichtigt wurden Mo- für Lehr-Lernziele, Inhalte und Lehrform genau dule wie „Projekt“ bzw. „Projektarbeit“, wenn diese bezeichnen und inwieweit diese Rubriken syntak- erkennbaren Bezug zu Softwareentwicklung bzw. Soft- tisch voneinander abgegrenzt sind. ware Engineering aufwiesen. Insgesamt wurden auf diese Weise rund 250 Mo- 6 The Good dulbeschreibungen von Hochschulen für angewandte Abbildung 2 vermittelt eine sortierte Übersicht über Wissenschaften sowie rund 25 Modulbeschreibungen die Kriterien für gute bzw. schlechte Lernzieldefinitio- von Universitäten ausgewählt. Für jedes dieser Modu- nen, also für the Good, the Bad and the Ugly. Zunächst le wurden die folgenden Daten gesammelt: betrachten wir die positiven Beispiele und damit die- • Organisatorische Rahmendaten jenigen Kriterien, deren Erfüllung eine Lernzieldefini- Betrachtet wurden dabei grundlegende Informa- tion als eine Instanz von the Good qualifizieren. tionen zur organisatorischen Einbettung des Mo- Inhalt und Handlungskomponente duls, wie beispielsweise Hochschule, Studiengang, Jede gute Lernzieldefinition kombiniert einen Inhalt Lehrveranstaltung, Modul, Fakultät/Fachbereich, mit einer Handlungskomponente. Diese beschreibt, URL, ECTS, SWS, Arbeitsaufwand und Prüfungs- welche Art von Tätigkeit auf bzw. mit diesem Inhalt form. Obwohl diese Daten selbst nicht direkt im durchzuführen ist. In der Regel wird diese Handlungs- Mittelpunkt unserer Untersuchung standen waren komponente über ein Verb ausgedrückt. sie hilfreich, um eine grundlegende Vorstellung Ein Beispiel für eine Lernzieldefinition, die Inhalt der jeweiligen Module zu entwickeln und sie in und Handlungskomponente kombiniert, wäre „Die ihren fachlichen und organisatorischen Kontext Studierenden (...) können einfache Funktionalitäten einzuordnen. in Klassen kapseln, Objekte erzeugen und Methoden • Akkreditierungsdaten aufrufen. Darüber hinaus sind sie in der Lage, korrek- Hier wurde erfasst, ob der Studiengang, in dem ten, lesbaren und wartbaren Code zu erzeugen“ (HS das Modul verortet ist, bereits akkreditiert wur- Fulda, 2018). de und falls ja, wann und von welcher Akkredi- Studierendenzentrierung tierungsagentur die Akkreditierung erteilt wur- Lernziele beschreiben das Handlungspotenzial, das de. Diese Daten sind für unsere Untersuchung Studierende durch die erfolgreiche Teilnahme an ei- insofern relevant, als Modulbeschreibungen in der ner Lehrveranstaltung entwickeln (sollen). Die mit Regel im Rahmen von Akkreditierungsverfahren diesem Handlungspotenzial verbundenen Kompeten- qualitätsgesichert werden. Des Weiteren zeigt die zen werden dabei nicht von außen in die Studieren- Selbsterfahrung, dass unterschiedliche Akkreditie- den „eingefüllt“, sondern aktiv von den Studierenden rungsagenturen sich in ihren Vorgaben und Prä- erworben. Die in der Lernzieldefinition verwendeten ferenzen hinsichtlich kompetenzorientierter Lern- Verben entsprechen dieser Sichtweise, beschreiben zieldefinitionen in Modulbeschreibungen durch- also das von den Studierenden zu erlernende Ver-

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 117 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

Inhalt und Handlungskomponente Studierendenzentrierung Beobachtbares Verhalten Klare Zuordnung zu Kompetenzebenen � Spezifikation der Klassifikatoren good Zielgruppengerechte Sprache Zielgerichtete Formulierung

Phrasen ugly � Nominalstil Sinnfreie Füllverben Syntaktisch komplexe Formulierungen bad Unterspezifikation von Klassifikatoren � Semantisch falsche Verwendung von Verben Uneindeutige Kompetenzebene Nicht-beobachtbares Verhalten Prozessorientierung Dozierendenzentrierung Fehlende Handlungskomponente Vermischung von Inhalt und Lernzielen

Abbildung 2: Kriterien für die Bewertung von Lernzieldefinitionen – von bad über ugly nach good halten, wie im obigen Beispiel der HS Fulda. (Eine ein wohldefinierte Taxonomie von Kompetenzebenen Dozierenden-zentrierte Formulierung würde dagegen zugrunde, wie beispielsweise (Bloom u. a., 1956), (An- beschreiben, was die Lehrperson „vermitteln“ will, al- derson u. a., 2001), (Schneider, 2002), (Metzger u. so das Lehrziel der Lehrperson und nicht das Lernziel Nüesch, 2004) oder (Hauer, 2011). der Studierenden.) Einige Hochschulen legen in ihren Leitfäden zur Ergebnisorientierung Formulierung von Modulbeschreibungen fest, welche Ein Lernziel definiert, welche Fähigkeiten die Studie- Taxonomie für Kompetenzebenen verwendet werden renden im Laufe des Lernprozesses entwickelt haben soll. Teilweise werden auch die zu nutzenden Verben sollen, also die als Ergebnis gewünschten Kompeten- vorgegeben. Zu beachten ist, dass die gleichen Ver- zen, wie im obigen Beispiel der HS Fulda. Sie be- ben bei verschiedenen Taxonomien mit unterschiedli- schreiben dagegen nicht die einzelnen Schritte, die im chen Kompetenzebenen korrespondieren. Beispiels- Zuge des Lernprozesses zu durchlaufen sind, um diese weise liegt Beurteilen in der sechsstufigen Taxono- Kompetenzen aufzubauen. mie von (Bloom u. a., 1956) auf Ebene 6: Evaluieren, Beobachtbares Verhalten während in der ebenfalls sechsstufigen Überarbeitung von (Anderson u. a., 2001) Evaluieren auf Ebene 5 Gemäß der aktuell in Deutschland gängigen Lehr- liegt. Im dreistufigen Modell von (Metzger u. Nüesch, Lernpraxis muss spätestens am Ende einer Modul- 2004) wiederum korrespondiert Beurteilen mit der Durchführung überprüft werden, inwieweit die einzel- dritten Ebene Probleme bearbeiten. nen Studierenden die Lernziele erreicht haben. Damit klar wird, wann ein Lernziel als erreicht gilt, ist die Der erste Satz der nachfolgenden Lernzieldefinition Handlungskomponente in Form von beobachtbarem „Die Studierenden kennen weitergehende Konzepte Verhalten zu beschreiben. der nebenläufigen und verteilten Programmierung. Die Lernzieldefinition „Nach erfolgreicher Beendi- Sie können beurteilen, wann und wie ein Algorithmus gung der Veranstaltung sind die Studierenden in der sich erfolgreich parallelisieren lässt (...)“ (FH Münster, Lage, verschiedene Vorgehensmodelle mit ihren Stär- 2018) adressiert beispielsweise die Kompetenzebene ken und Schwächen zu beschreiben“ (HS Kempten, 1: Erinnern nach der Lernzieltaxonomie von (Ander- 2018) der Hochschule Kempten definiert, welches beson u. a., 2001), während der zweite Satz auf der obachtbare Verhalten die Studierenden zeigen müssen, Kompetenzebene 5: Evaluieren angesiedelt ist. damit das Lernziel als erreicht gilt. Dadurch wird das Spezifikation der Klassifikatoren Erreichen des Lernziels überprüfbar. Insbesondere auf den höheren Kompetenzebenen im Klare Zuordnung zu Kompetenzebenen Sinne der oben genannten Taxonomien finden sich Die Handlungskomponente eines Lernziels legt die Art immer wieder Formulierungen wie „an einfachen Auf- der Tätigkeit fest, die auf bzw. mit dem Inhalt durch- gabenstellungen bzw. Beispielen“. Die Erfahrung zeigt, zuführen ist. Sie repräsentiert also das Kompetenzni- dass es hochgradig von der bereits vorhandenen Ex- veau, d. h. den zu erreichenden Grad an handlungsbe- pertise abhängt, ob eine Person eine Aufgabenstellung fähigender Expertise. Guten Lernzieldefinitionen liegt bzw. ein Beispiel als „einfach“ empfindet oder nicht.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 118 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

Tabelle 1: Korrespondierende Paare von Kriterien für good vs. bad / ugly und deren Relevanz Relevanz The Good The Ugly and the Bad Relevanz ++++ Inhalt und Handlungskomponente Vermischung von Inhalt und Lernzielen –––– Fehlende Handlungskomponente –––– +++ Studierendenzentrierung Dozierendenzentrierung ––– +++ Beobachtbares Verhalten Prozessorientierung ––– Nicht-beobachtbares Verhalten ––– ++ Klare Zuordnung zu Kompetenzebenen Uneindeutige Kompetenzebene –– Semantisch falsche Verwendung von Verben –– ++ Spezifikation der Klassifikatoren Unterspezifikation von Klassifikatoren –– ++ Zielgruppengerechte Sprache Syntaktisch komplexe Formulierungen –– + Zielgerichtete Formulierung Sinnfreie Füllverben – Nominalstil – Phrasen –

Um die Lernzieldefinition eindeutig zu gestalten und katoren das schnell und klar erkennbar ist. Wir stellen Missdeutungen möglichst auszuschließen ist die Be- dabei eine Menge von Mustern (Anti-Patterns) zusam- deutung derartiger Klassifikatoren klar zu beschrei- men, die wir aus den Formulierungen der untersuch- ben. ten Modulbeschreibungen heraus abstrahiert haben Ein Beispiel für eine Lernzieldefinition mit klar spe- und die wir als ungünstig für die Definition kompeten- zifiziertem Klassifikator wäre: „Die Studierenden ent- zorientierter Lernziele betrachten. Diese Formulierun- wickeln für ein einfaches Problem aus einer gegebe- gen müssen nicht per se immer negativ sein. Es lohnt nen Anforderungsspezifikation heraus einen Entwurf, sich jedoch, in jedem Einzelfall nachzudenken, ob ihre der sowohl die Gesamtstruktur der Lösung als auch Verwendung für den Zweck der kompetenzorientier- die einzelnen Algorithmen vorgibt. (...) Ein „einfaches ten Lernzieldefinition zielführend ist – im Sinne des Problem“ ist dabei eine Aufgabenstellung, die mit max. Kapitels „Giftschrank der Wörter“ aus (Rechenberg, 10 Klassen objektorientiert zu lösen ist“ (HS München, 2006). 2018). Anders als bei den positiven Beispielen aus Ab- Zielgruppengerechte Sprache schnitt 6 geben wir zu den Negativbeispielen keine Damit die Zielgruppe eine Lernzieldefinition korrekt Quellen an, denn wir wollen mit unserer Arbeit kein interpretieren kann ist es wichtig, diese in eine Spra- Fingerpointing schüren, sondern zu Reflexion anre- che zu kleiden, die für die Zielgruppe auch verständ- gen. Aus dem gleichen Grund haben wir darauf ge- lich ist. Mit Blick auf die Studierenden ist hier beson- achtet, als Beispiele jeweils so kurze Fragmente aus ders wichtig, dass Fachbegriffe nur moderat verwenden zugrunde liegenden Lernzieldefinitionen heraus- det und deren Bedeutung ggf. knapp erläutert wird. zuschneiden, dass diese nicht mehr eindeutig durch Ebenfalls hilfreich ist es, Sätze kurz zu halten und eine einfache Internet-Suche zu identifizieren sind. In möglichst einfache Formulierungen zu verwenden. seltenen Fällen haben wir den vorgefundenen Wort- Zielgerichtete Formulierung laut auch marginal abgewandelt, damit eine Suche ins Leere läuft. Eine Lernzieldefinition empfinden wir dann als zielgerichtet, wenn die erforderlichen Informationen so Zu beachten ist ferner, dass die Zuordnung einer ausführlich wie nötig, aber so knapp wie möglich dar- Formulierung zu einem Kriterium nicht immer ein- gestellt werden. Die erforderliche Information muss deutig ist; d. h., manche Formulierungen qualifizieren also vollständig und angemessen detailliert sein, ohne sich für mehrere Arten von Hässlichkeit. Ergänzend dabei unnötig breit getreten oder mit Phrasen aufge- zur sortierten Übersicht über die Kriterien für gute bauscht zu werden. Zu beachten ist, dass das Empfin- bzw. schlechte Lernzieldefinitionen in Abbildung 2 den, welcher Umfang bzw. Detaillierungsgrad ange- stellt Tabelle 1 diese Kriterien einander gegenüber, als messen ist, ein Stück weit Geschmackssache ist. jeweils korrespondierende Paare für die positive bzw. negative Ausprägung des gleichen Anliegens. 7 What makes the Bad bad and the Ugly ugly? 7.1 Semantisch hässlich – the Bad Nach diesen positiven Beispielen widmen wir uns im Wir beginnen die Diskussion des Verbesserungspoten- Folgenden der Analyse von negativen Beispielen. Wir zials für Lernzieldefinitionen mit denjenigen Kriterien, untersuchen also, welche Kriterien dazu führen, dass die besonders gravierend sind, d. h. in besonderem eine Lernzieldefinition semantisch oder syntaktisch Maße dazu beitragen, dass eine Lernzieldefinition zu hässlich, also bad oder ugly ist, und an welchen Indi- the Bad zählt.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 119 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

Vermischung von Inhalt und Lernzielen Fehlende Handlungskomponente Ein kompetenzorientiertes Lernziel kombiniert jeweils Jedes kompetenzorientierte Lernziel beinhaltet eine einen Inhalt mit einer Handlungskomponente. Es Handlungskomponente. Diese wird über ein Verb aus- drückt also ein Handlungspotenzial aus, das die ler- gedrückt, wie beispielsweise „beurteilen“ oder „er- nende Person nach erfolgreichem Lernprozess auf bzw. stellen“ – oder zumindest die Nominalisierung von mit dem Inhalt durchführen können soll. Verben, wie beispielsweise „Kenntnis“ oder „Anwen- dung“. Die Struktur der meisten untersuchten Modulbe- schreibungen weist definierte, voneinander getrennte Zu beobachten ist, dass einige Lernzieldefinitionen Rubriken für Inhalte und für Lernziele aus. Ideal wäre keine kompetenzbeschreibende Handlungskomponen- es, wenn die Rubrik „Inhalt“ einen schnellen Über- te beinhalten, weder als Verb noch als Nominalisie- blick über die im Modul adressierten Themengebiete rung eines Verbs. Statt dessen werden entweder reine vermitteln würde, während die angestrebten Kompe- Inhalte aufgelistet oder aber Hilfsverben verwendet, tenzen (als Kombination von Inhalt und Handlungs- die lediglich den Lernprozess an sich beschreiben, je- komponente) in der Rubrik „Lernziele“ angegeben doch nicht das angestrebte Handlungspotenzial aus- werden. drücken. Dadurch wird nicht deutlich, welche Form von Zu beobachten ist jedoch, dass diverse Modulbe- Handlungspotenzial auf und mit dem jeweiligen Inhalt schreibungen diese Rubriken nicht trennscharf nut- als Lernergebnis erwartet wird. Die zu erreichende zen, sondern vielmehr reine Inhalte in die Rubrik für Kompetenz bleibt damit völlig unklar – sind lediglich Lernziele bzw. Kompetenzen schreiben. Umgekehrt Definitionen wiederzugeben oder ist ein fachliches werden gelegentlich auch die zu entwickelnden Kom- Artefakt zu entwickeln, das den etablierten Qualitäts- petenzen in der Rubrik für die Inhalte dokumentiert. kriterien der Zunft genügt? Durch diese strukturelle Unsauberkeit werden die Beispiele für Lernzieldefinitionen, in welchen die Modulbeschreibungen vergleichsweise schlecht lesbar. angestrebte Handlungsebene komplett offen bleibt, Insbesondere wird es für die Zielgruppen der Modul- sind: beschreibung ungleich schwieriger, zweifelsfrei die in • „(...) lernen die Studierenden weitergehende Me- diesem Modul adressierten Kompetenzen zu identifi- thoden ... [gefolgt von einer Auflistung von Tech- zieren – insbesondere dann, wenn die Lernziele nicht nologien]“ in der Rubrik „Lernziele“ aufgelistet sind, sondern ver- • „Daneben erwerben sie Kompetenz in ... [gefolgt steckt unter einer anderen Überschrift. Aber auch die von einer Aufzählung reiner Inhalte]“ Einbettung einzelner Lernziele zwischen umfangrei- • „Steigerung der (...) Fähigkeiten in (...)“ chen inhaltlichen Erläuterungen macht die Lernziele schwer erkennbar, selbst wenn sie letztlich doch in Dozierendenzentrierung der passenden Rubrik aufgeführt sind. Des Weiteren Dozierendenzentrierte Formulierungen beschreiben, liegt der Verdacht nahe, dass die Urheber derartiger was die Dozierenden zu lehren gedenken, häufig mit Modulbeschreibungen nicht angemessen präzise für einem starken Fokus auf reine Inhalte. Das Handlungs- sich selbst geklärt haben, wie nun eigentlich Inhalte potenzial und damit die Kompetenz, die die Studieren- und Lernziele zueinander in Beziehung stehen und den durch Teilnahme an der Lehr-Lernveranstaltung welche Kompetenzen die Studierenden überhaupt in entwickeln können, wird dagegen nicht definiert. diesem Modul entwickeln sollen. Entsprechend beschreiben derartige Formulierungen Lehrziele und nicht Lernziele. Beispiele für derartige, zwischen die Lernziele ein- gestreute inhaltliche Erläuterungen sind: Letztere bleiben dabei völlig unklar. Insbesondere wird das von den Studierenden erwartete Handlungs- • „Softwareentwicklung wird als iterativer und in- potenzial und damit die Kompetenzebene bei diesen krementeller Prozess (...) verstanden“ Formulierungen nicht deutlich. Des Weiteren weisen • „Die Entwicklung von Softwaresystemen (...) [ist] dozierendenzentrierte Formulierungen den Studieren- in der Praxis immer fächerübergreifend“ den in ihrem Lernprozess eine passive Rolle zu, die • „Software Engineering umfasst (...)“ einer modernen Lehr-Lernsituation nicht angemessen Einige dieser ausschließlich inhaltlichen Erläuterun- ist. Derartige Modulbeschreibungen lesen sich dann gen muten an wie eine motivatorische Begründung eher wie Drohungen, nicht wie Versprechen. der Relevanz der behandelten Inhalte. Diese ist ja Beispielsweise behandeln die folgenden Formulie- durchaus eine relevante Information, sollte aber an rungen die Studierenden wie passive Objekte des Lehr- einer dafür geeigneteren Stelle stehen, beispielsweise prozesses: in der Studiengangsbeschreibung oder eben in der • „die Studierenden werden in die Lage ver- Rubrik mit den Inhalten. setzt...“ (AQAS, 2016) Des Weiteren finden sich nach wie vor diverse Mo- • „die Studierenden werden befähigt zu ...“ dulbeschreibungen, die zwar Inhalte auflisten, aber • „Weiterhin erfahren [die Studierenden] eine Ein- keinerlei Lernziele definieren. führung in ...“

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 120 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

Im Extremfall kommt eine Lehrzielbeschreibung Um die Erwartungshaltung an die Lernenden klar ganz ohne Bezug zu Studierenden aus: zu definieren ist es daher sinnvoll, Lernziele so zu for- • „Die Lehrveranstaltung führt ein in ...“. mulieren, dass sie auf möglichst differenzierte Weise • „Das Modul vermittelt ...“ ein von außen beobachtbares Verhalten bzw. Ergebnis • „Außerdem wird ... behandelt“ beschreiben. Von diesem aus kann dann auf die Exis- • „In der Veranstaltung wird ... vorgestellt“ tenz der geforderten Kompetenz geschlossen werden. • „Die Programmierkenntnisse in Java werden er- Nicht alle Verben beschreiben ein Verhalten, das weitert um ...“ tatsächlich beobachtbar ist. Insbesondere trifft dies Typische Indikatoren für dozierendenzentrierte For- auf die Bezeichner der kognitiven Ebenen der Taxo- mulierungen sind also Verben wie „vermitteln“, „be- nomie von Anderson und Krathwohl (Anderson u. a., handeln“ oder „befähigen“, sowie deren Nominalisie- 2001) zu: Erinnern, Verstehen, Anwenden, Analysieren, rung, also beispielsweise „die Vermittlung von“. Evaluieren und Kreieren sind für sich genommen keine von außen wahrnehmbaren Verhaltensweisen. Prozessorientierung Um beispielsweise beobachten zu können, ob Stu- Einige Modulbeschreibungen dokumentieren als Lern- dierende einen Sachverhalt verstanden haben, ist ei- ziele weniger die gewünschten Lernergebnisse als den ne konkrete Aufgabenbeschreibung erforderlich, an Prozess bzw. die Lernsituation, der verfolgt bzw. die deren Bearbeitungsprozess bzw. erzieltem Ergebnis aufgebaut wird, um diese Lernergebnisse zu erreichen. sich der Grad des Verständnisses ablesen lässt. Geeig- Derartige Formulierungen sind aus zweierlei Grün- nete Formulierungen bzw. Verben für ein Verhalten, den nicht ideal. Zum einen bleibt die zu erlernende an dem Verstehen beobachtet werden kann, sind bei- Handlungskomponente in der Regel weit gehend un- spielsweise „... mit eigenen Worten beschreiben“ oder klar. Zum anderen ist es prinzipiell denkbar, dass es „veranschaulichen“. verschiedene mögliche Wege zum gleichen Ziel gibt. Uneindeutige Kompetenzebene Eine prozessorientierte Modulbeschreibung schränkt Nicht alle Verben spezifizieren die angestrebte damit unnötig ein auf den einen vorgegebenen Lern- Expertise-Ebene so genau, dass zweifelsfrei klar ist pfad. was die Lernenden nach dem Lernprozess wirklich Typische Indikatoren für prozessorientierte Formu- leisten können sollen. Auch wenn Lernzieldefinitionen lierungen sind Wörter, die eine zeitliche Reihenfol- basierend auf einer der bekannten Lernzieltaxonomi- ge einzelner Schritte bzw. eine Abfolge von Themen en formuliert werden, lassen sich nicht alle denkbaren implizieren, ohne dabei die Handlungskomponente Verben eindeutig einer kognitiven Ebene zuordnen. genauer auszuweisen, wie beispielsweise „ausgehend Dies könnte mit ein Grund dafür sein, warum sehr von“. häufig die Ebenenbezeichner selbst verwendet wer- • „Ausgehend von [Artefakt] steht dabei die Phase den, um Lernziele zu beschreiben – denn diese Ebe- ... im Mittelpunkt.“ nenbezeichner sind ja per Definitionem den Ebenen • „Einsatz [bestimmter Verfahren] ausgehend vom eindeutig zugeordnet. Sie beschreiben jedoch, wie [Artefakt]“ oben dargestellt, kein beobachtbares Verhalten. Auf Ebenfalls häufig vertreten sind listenartige Aufzäh- diese Weise definierte Lernziele sind somit nicht über- lungen der durchzuführenden Arbeitsschritte (meist prüfbar. als Nominalisierung) bzw. der zu verwendenden Werk- Typische Formulierungen, bei denen die von einem zeuge, sowie eine zwischen die Lernziele gemischte Lernziel adressierte Expertiseebene der Handlungs- Beschreibung der Lernsituation. komponente völlig offen bleibt, sind: • „Nutzung von [Verfahren]“ • „Fähigkeit zur [Paradigma-Adjektiv] Programmie- • „Einsatz von [Werkzeug]“ rung“ • „... werden in Gruppen von [n] Studierenden be- • „beherrschen“ arbeitet ...“ • „sinnvoll einsetzen“ Nicht-beobachtbares Verhalten • „lernen [Konzept oder Verfahren] kennen“ Nach den Konventionen unseres aktuellen Bildungs- Semantisch falsche Verwendung von Verben systemes ist im Verlaufe eines Bildungsprozesses im- Einige der analysierten Modulbeschreibungen bein- mer wieder auf geeignete Weise zu überprüfen, inhalten Lernzieldefinitionen, die Verben auf eine Weise wieweit die Lernenden die gesetzten Lernziele auch verwenden, dass diese Verben auf den ersten Blick erreicht, also die geforderten Kompetenzen entwickelt semantische Assoziationen wecken mit einer bestimm- haben. Ob eine Person über bestimmte Fähigkeiten ten Kompetenzebene, jedoch eigentlich einer ganz und Fertigkeiten verfügt kann von außen betrachtet anderen Kompetenzebene zugehören. ausschließlich am beobachtbaren Verhalten dieser Per- Dadurch wird die Lernzieldefinition schwer lesbar. son fest gemacht werden, oder an den beobachtbaren Es steigt das Risiko von Missdeutungen. Ergebnissen dieses Verhaltens. Geprüft wird also, ob Zu Formulierungen, die entsprechend risikobehaftet eine Person bei bestimmten Aufgaben ein den Aufga- sind, zählen beispielsweise ben angemessenes Verhalten zeigt. • „verstehen [etwas] sinnvoll einzusetzen“

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 121 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

• „erkennen ... die Anwendbarkeit [von Konzepten • Schlechte Strukturierung für eine Problemstellung]“ • Vermischung von reinem Inhalt, Lernzieldefinitio- Das erste Beispiel wirkt auf den ersten Blick so, nen und Beschreibung des Lernprozesses an sich als würde Ebene 2, Verstehen, der Taxonomien von bis zur Unkenntlichkeit Bloom (Bloom u. a., 1956) oder Anderson und Kra- • Zu geringer oder zu großer Umfang (d. h. unter- thwohl (Anderson u. a., 2001) adressiert. De facto spezifiziert vs. überdetailliert) geht es bei genauerem Hinsehen jedoch darum, et- Sinnfreie Füllverben was „einzusetzen“ und damit mindestens um Ebene Als sinnfreie Füllverben in Lernzieldefinitionen bezeich- 3, Anwenden. Im zweiten Beispiel fallen zunächst die nen wir Verben, die keine Handlungskomponente mit Begriffe „erkennen“ und „Anwendbarkeit“ ins Auge, Bezug zu Inhalt ausdrücken. Häufig treten diese sinn- die auf die Ebenen 1, Erinnern oder 3, Anwenden hin- freien Füllverben in Kombination mit Nominalstil auf. weisen. De facto geht es jedoch darum, zu identifi- D. h. die eigentlich im Fokus stehende Handlungs- zieren, welches der gelernten Konzepte am besten kompetenz wird in ein substantiviertes Verb verpackt. für die Lösung der Problemstellung geeignet ist, und Beispiele sind: dieses dann auszuwählen. Diese Kompetenz entsprä- • „verfügen die Studierenden über ein grundlegen- che jedoch Evaluieren, also Ebene 5 der Taxonomie des Verständnis“ von Anderson und Krathwohl, bzw. Ebene 6 in der • „beherrschen Grundkenntnisse“ Taxonomie von Bloom. • „erlernen [den] Tooleinsatz“ Unterspezifikation von Klassifikatoren für Inhalt Nominalstil Einige Lernzieldefinitionen klassifizieren die Inhalts- Von Nominalstil sprechen wir, wenn die Handlungs- komponente, meist durch Verwendung von Adjektiven, komponente nicht über ein Verb, sondern über dessen die den Inhalt genauer beschreiben. Diese Klassifikato- Substantivierung ausgedrückt wird. Häufig tritt dieses ren sind jedoch nur dann wirklich hilfreich, wenn ihre Phänomen in Kombination mit sinnfreien Füllverben Bedeutung ohne Interpretationsspielraum festgelegt oder Phrasen auf. Übermäßig verwendeter Nominal- ist. Beispielsweise hängt es von der bereits verfügba- stil macht einen Text (und damit auch eine Lernziel- ren Expertise ab, ob eine Person einen Algorithmus definition) meist schwerer verständlich. oder ein Problem als „einfach“ empfindet oder nicht. Typische Beispiele sind, ergänzend zu den bereits Meist wird die Bedeutung derartiger Klassifikatoren bei Sinnfreie Füllverben genannten: jedoch offen gelassen. • „Vermittlung von Grundkenntnissen“ Typische Beispiele sind: • „Umsetzung von Algorithmen“ • „grundlegende Konzepte“ • „Strukturierung von Daten“ • „kleinere Problemstellungen“ • „Einsatz von Werkzeugen“ • „eine einfache Anwendung“ Phrasen 7.2 Syntaktisch hässlich – the Ugly Ein identifiziertes Qualitätskriterium für Lernzieldefi- Die bisher betrachteten Kriterien weisen auf seman- nitionen ist die Effizienz, also ob eine Lernzieldefini- tische Schwierigkeiten hin, insbesondere auf Unklar- tion die relevante Information auf den Punkt bringt. heiten bzw. Unterspezifikation und damit auf hohen Kontraproduktiv dafür sind Phrasen, also wohltönen- Interpretationsspielraum. Sie bergen somit ein Risiko de, aber inhaltlich nichtssagende Textfragmente, da auf Missdeutungen. sie die Lernzieldefinitionen unnötig aufblähen. Im Folgenden diskutieren wir syntaktische Kriterien, Typische Repräsentanten für Phrasen in Lernzielde- die dazu führen, dass Lernzielformulierungen schwer finitionen sind: lesbar und damit ugly werden. • „Die Studierenden werden befähigt ...“ Syntaktisch komplexe Formulierungen • „Die Studierenden sollen ... verstanden haben“ Lernzieldefinitionen sollen insbesondere auch für Stu- • „Die Studierenden sind in der Lage ...“ dierende oder Studieninteressierte verständlich sein, • „Weiterhin erwerben [die Studierenden] Kenntnis- also eine Personengruppe, welche mit den in den Lern- se und Fertigkeiten im Bereich ...“ zielen thematisierten Inhalten zunächst nicht oder nur • „... soll ... Gelegenheit bieten ...“ wenig vertraut ist. Entsprechend ist darauf zu achten, eine möglichst einfache, klar verständliche Sprache 8 Zusammenfassung und Ausblick zu wählen. Diese wird nicht nur den Studierenden Basierend auf der Analyse der Lernzieldefinitionen besser gerecht, sondern ist ggf. auch für die anderen aus rund 275 deutschsprachigen Modulbeschreibun- Zielgruppen klarer und effizienter verständlich. gen aus dem fachlichen Umfeld von Programmierung Beispiele für typische Fallstricke in den Formulie- und Softwaretechnik haben wir Qualitätskriterien für rungen sind: Lernzieldefinitionen definiert. Auf dieser Grundlage • Hoher Anteil an Fremdwörtern und Fachsprache, haben wir sowohl Best Practices als auch Anti-Patterns wenn es „normalverständlich“ auch gehen würde identifiziert. Letztere haben wir differenziert nach se- • Stark verschachtelte Sätze mantischen und syntaktischen Hässlichkeiten. Diese

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 122 Lernzieldefinitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München beeinträchtigen die Qualität von Lernzieldefinitionen [AQAS 2016] Agentur für Qualitätssicherung durch unterschiedlich stark. Entsprechend klassifizieren wir Akkreditierung von Studiengängen (AQAS e.V.): je nach Erfüllung von Best Practices bzw. Anti-Patterns Qualität Transparenz Vergleichbarkeit Informa- einzelne Lernzieldefinitionen nach the Good, the Bad tionen zur Programmakkreditierung. 9. Auf- and the Ugly. lage. https://www.aqas.de/downloads/AQAS- Im Rahmen der genaueren Analyse der betrachte- Broschuere.pdf, 2016. – zuletzt aufgerufen am ten Lernzieldefinitionen wurde erkennbar, dass mit 4.11.2018 Blick auf verständliche, in ihrer Bedeutung eindeutige, kompetenzorientierte Lernzieldefinitionen durchaus [Arnold u. a. 1999] ARNOLD, R. ; KRÄMER-STÜRZL, noch Verbesserungspotenzial vorhanden ist. Beispiels- A. ; SIEBERT, H.: Dozentenleitfaden. Planung und weise beinhalten rund 10% der Lernzieldefinitionen Unterrichtsvorbereitung in Fortbildung und Erwach- noch Verben wie „vermittelt“ oder „befähigt“, die auf senenbildung. Berlin : Cornelsen, 1999 eine dozierendenzentrierte Haltung hinweisen. Des [Biggs u. Tang 2011] BIGGS, J. ; TANG, C.: Teaching Weiteren weist ein großer Anteil der analysierten Mo- For Quality Learning At University. McGraw-Hill dulbeschreibungen in den Lernzieldefinitionen kein Education, 2011 (SRHE and Open University Press beobachtbares Verhalten aus. Damit sind diese nicht Imprint). – ISBN 9780335242757 überprüfbar. Gerade wegen der weit reichenden Bedeutung von [Bischoff u. a. 2017] BISCHOFF, M. ; BOENTERT, A. ; Lernzieldefinitionen, sowohl für die Lehrenden als PERNHORST, C.: Module entwickeln und beschreiben. Grundlage der Gestaltung der Lehre im Sinne des https://www.fh-muenster.de/hochschule/ Constructive Alignments, als auch für die Studieren- qualitaetsentwicklung/downloads/170914_ den zum Verständnis der Prüfungsanforderungen und Modulbeschreibung_Druckfassung.pdf, 2017. – der inhaltlichen Ausrichtung eines Faches, ist der An- zuletzt aufgerufen am 4.11.2018 spruch an die Qualität von Lernzieldefinitionen zunehmend steigend. Entsprechend besteht hier an vielen [Bloom u. a. 1956] BLOOM, B. S. ; ENGELHART, M. B. Stellen noch Handlungsbedarf – auch für unseren ei- ; FURST, E. J. ; HILL, W. H. ; KRATHWOHL, D. R.: genen Wirkungsbereich. Taxonomy of educational objectives: The classificati- Zum Schluss bleibt festzustellen, dass eine automa- on of educational goals. New York : David McKay tisierte Qualitätssicherung von Lernzieldefinitionen Company, 1956 mit den derzeit verfügbaren technischen Mitteln noch sehr schwierig ist. Entsprechend wird bis auf Weiteres [Cursio u. Jahn 2015] CURSIO, M. ; JAHN, D.: Formu- eine manuelle Qualitätssicherung unabdingbar sein. lierung kompetenzorientierter Lernziele auf Module- Auch hier hilft ein klares Verständnis von Best Prac- bene. https://www.nat.fau.de/files/2015/12/ tices ebenso wie von Anti-Patterns, kritische Formu- 03-Leitfaden-Leitfaden-zur-Formulierung- lierungen schnell zu identifizieren und auf effiziente kompetenzorientierter-Lernziele-auf- Weise mögliche Verbesserungen anzugeben. Modulebene-NatFak-und-FBZHL.pdf, 2015. – zuletzt aufgerufen am 9.11.2018 Dank [DiZ 2018] DIZ: Lernzieldefinition des Kurses Das Autorenteam wurde gefördert durch das BMBF „Rechtsgrundlagen für die Lehre an Hochschulen“. Förderkennzeichen 01PL16025 (Projekt "Für die Zu- https://diz-bayern.de/programm/termine- kunft gerüstet"), im Programm "Qualitätspakt Lehre". und-buchung/details/4-diz-termin?xref= 161503:rechtsgrundlagen-fuer-die-lehre-an- Literatur hochschulen, 2018 [ACQUIN 2014] Akkreditierungsagentur AC- [FH Furtwangen 2013] Hochschule Furtwangen QUIN e. V.: Leitfaden für Verfahren der University, Prorektor für Lehre und Studium/ https://www. Programmakkreditierung. Stabsstelle Qualitätsmanagement: Modulbe- acquin.org/wp-content/uploads/2014/06/ schreibung und Formulierung von Lernergebnissen. LeitfadenProgrammakkreditierung.pdf, 2014. – http://findo.hs-furtwangen.de/pub/QM_ zuletzt aufgerufen am 4.11.2018 Board/HFU_Leitfaden_Modulbeschreibung.pdf, 2013. – zuletzt aufgerufen am 4.11.2018 [Anderson u. a. 2001] ANDERSON, Lorin W. ; KRA- THWOHL, David R. ; AIRASIAN, Peter W. ; CRUIKS- [FH Münster 2018] FH Münster: Modulbe- HANK, Kathleen A. ; MAYER, Richard E. ; PINTRICH, schreibung „Höhere Programmierkonzepte“. Paul R. ; RATHS, James ; WITTROCK, Merlin C.: A https://www.fh-muenster.de/eti/downloads/ Taxonomy for Learning, Teaching, and Assessing. A module/Modulhandbuch_Informatik_2012-06- Revision of Bloom’s Taxonomy of Educational Objecti- 20_Ueberarbeitet_2017.pdf, abgerufen am ves. 1. New York : Longman, 2001 27.11.2018, 2018

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 123 Lernzieldeﬁnitionen für Software Engineering - The Good, the Bad and the Ugly Axel Böttcher, Veronika Thurner and Olga Nikoliai, HS München

[Gröblinghoff 2013] GRÖBLINGHOFF, F.: ne- [Toutanova u. a. 2003] TOUTANOVA, Kristina ; KLEIN, xus impulse für die Praxis Nr. 2: Lerner- Dan ; MANNING, Christopher D. ; SINGER, Yoram: gebnisse praktisch formulieren. 1. Auﬂa- Feature-rich Part-of-speech Tagging with a Cyclic ge. https://www.hrk-nexus.de/fileadmin/ Dependency Network. In: Proceedings of the 2003 redaktion/hrk-nexus/07-Downloads/07-02- Conference of the North American Chapter of the Publikationen/Lernergebnisse_praktisch_ Association for Computational Linguistics on Human formulieren_01.pdf, 2013. – zuletzt aufgerufen Language Technology - Volume 1, 2003 (NAACL ’03), am 4.11.2018 S. 173–180

[Hauer 2011] HAUER, E.: Wird dumm geprüft, wird [TUM 2016] Technische Universität München: dumm gelernt – Plädoyer für den Einsatz anwen- Wegweiser zur Erstellung von Modulbeschrei- dungsorientierter Prüfungsaufgaben im Hochschul- bungen, Version 3. https://www.lehren. bereich. In: Magazin erwachsenenbildung.at (2011), tum.de/fileadmin/w00bmo/www/QM_Handbuch/ Nr. 12, S. 10.1–10.10 Dokumente/Wegweiser_Modulbeschreibungen_ Version3_Stand_Maerz_16.pdf, 2016. – zuletzt [Hollender 2010] HOLLENDER, D.: Formulierungs- aufgerufen am 4.11.2018 hilfen für Modulhandbücher – Handreichung zur Verstärkung der Kompetenzorientierung. [Uni Würzburg 2013] Julius-Maximiliansuniversität https://www.intern.tu-darmstadt.de/media/ Würzburg: Output-Orientierung und Kompe- dezernat_ii/ordnungen/Handreichung.pdf, tenzformulierung im Bologna-Prozess. https: 2010. – zuletzt aufgerufen am 13.11.2018 //www.uni-wuerzburg.de/fileadmin/39030000/ ZiLS/Material/Kompetenzorientierung/ [HS Fulda 2018] HS Fulda: Modulbeschreibung Kompetenzformulierung_15.10.2013.pdf, 2013. „Programmierung 1“. https://www.hs-fulda.de/ fileadmin/user_upload/Unsere_Hochschule/ – zuletzt aufgerufen am 4.11.2018 Hochschulrecht/Pruefungsordnungen_der_ [UZH 2008] Dossier Unididaktik – Lernziele for- Fachbereiche/Angewandte_Informatik/AI_BSc_ mulieren in Bachelor- und Masterstudiengän- AI_2017-06-21.pdf, abgerufen am 27.11.2018, gen. https://www.hrk-nexus.de/fileadmin/ 2018 redaktion/hrk-nexus/07-Downloads/07-03- Material/DU_Lernziele_11_08.pdf, 2008 [HS Kempten 2018] HS Kempten: Modulbeschrei- https://www.hs- bung „Softwaretechnik 1“. [Weinert 2001] WEINERT, F.E. (.: Leistungsmessung in kempten.de/fileadmin/fh-kempten/E_I/ Schulen. Weinheim : Beltz, 2001 inf_bsc/pdf/20180727_Modulhandbuch_IF_- _Beschlussvorlage.pdf, abgerufen am 27.11.2018, 2018 [HS München 2018] HS München: Modulbeschrei- bung „Softwareentwicklung 1 (IB)“. https://w3- o.cs.hm.edu:8000/public/module/226/, abgerufen am 27.11.2018, 2018

[Kennedy 2008] KENNEDY, D.: Lernergebnisse (Lear- ning Outcomes) in der Praxis – Ein Leitfaden; Deut- sche Version: T. Mitchell, V. Gehmlich, M. Steimann. 2008

[Mager 1972] MAGER, R.: Lernziele und programmier- ter Unterricht. 35. Weinheim : Beltz, 1972

[Metzger u. Nüesch 2004] METZGER, C. ; NÜESCH, C.: Fair prüfen: Ein Qualitätsleitfaden für Prüfende an Hochschulen. 2004

[Rechenberg 2006] RECHENBERG, P.: Technisches Schreiben: (nicht nur) für Informatiker. Hanser, 2006. – ISBN 9783446406957

[Schneider 2002] SCHNEIDER, W.: Foliensatz “Einfüh- rung in die Wirtschaftspädagogik”. Wien, 2002

[Terhart 2005] TERHART, E.: Lehr-Lern-Methoden. 4. Weinheim : Juventa, 2005

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 124 Teaching Rationale Management in Agile Project Courses

Anja Kleebaum1, Jan Ole Johanssen2, Barbara Paech1, and Bernd Bruegge2 1Heidelberg University, Heidelberg, Germany 2Technical University of Munich, Munich, Germany [email protected], [email protected], [email protected], [email protected]

Abstract of this lecture is to teach a rationale model to stu- Rationale management is beneficial since it supports dents, to introduce them to methods and tool support decision-making and prevents knowledge vaporiza- for rationale management, and to motivate them to tion. To apply rationale management, developers need apply rationale management in the future. We gave to know how to systematically capture rationale and this lecture as part of an agile multi-project course at how to exploit the documentation. We believe that the Technical University of Munich, in which student teaching these skills to students further integrates ra- teams work on different software projects over the tionale management into the daily work of developers period of one semester. The projects are initiated by and has positive effects on both the software develop- industrial customers [4]. As a default set of tools, the ment process and on the quality of the software. In students use the issue tracking system JIRA and the this paper, we report on a lecture on teaching ratio- wiki system Confluence. During the lecture, we pre- nale management to students. In this lecture, students sented our methods on rationale management to the are introduced to a rationale model, to capture and students and they applied parts of our tool support. exploitation methods, and tool support for rationale We asked students for their feedback on the presented management. The goal is to motivate them to apply tools and to perform exercises. rationale management. We present the students’ re- This paper is structured as follows. In Section 2, we sults as well as their attitude and feedback towards the outline background knowledge on rationale manage- applied methods. Further, we sketch how rationale ment and the agile multi-project course. In Section 3, management will be applied during the semester. we present our teaching material including six exercises, and the course of the lecture. Then, we summarize the students’ feedback, present the exercise 1 Introduction results, and discuss lessons learned. In Section 4, we Developing software means to continuously solve is- describe plans on how to evaluate rationale manage- sues and to make decisions. Developers possess knowl- ment during the agile project course. Section 5 lists edge about decisions, the issues they solve, alterna- related work and Section 6 concludes the paper. tives, and their justifications. This knowledge is called decision knowledge or rationale. The success of a 2 Background development project strongly depends on the decision- This section introduces the rationale model we use, making abilities of the developers and other relevant basics about issue tracking and wiki systems, our pre- stakeholders. Rationale management supports explicit vious work on integrating rationale management into decision-making by capturing rationale and by using agile software development, and a description of the the documentation [7]. Developers are said to be re- agile multi-project course that the lecture is part of. luctant to capture rationale systematically [1, 14, 18]. We believe that this can be alleviated by teaching de- 2.1 Rationale Models velopers how to capture rationale and by raising their A rationale model represents knowledge in the same awareness for the benefits of rationale management. way a system model represents a system. Rationale As part of our previous work, we developed meth- can be modeled as a graph of rationale elements ods and tool support to integrate rationale manage- and edges that represent the elements’ relationships. ment into agile development processes, in particular There are various models for building such graphs of into continuous software engineering [11, 12]. In rationale. In general, these models differ in the types this paper, we report on a lecture on teaching ratio- of elements and edges that they allow. For example, an nale management to university students. The goal advanced model is the decision documentation model,

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 125 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

Emoji Name Indicating Phrases 2.3 Continuous Rationale Management I have a question . . . Agile processes support lightweight, flexible, and con- How should . . . tinuous software development. Rationale manage- Issue . . . , any suggestions? ment integrates well into such processes, yet, it should We need to discuss how . . . be easy to apply, i. e., developers should need as lit- I { suggest | propose } ... tle effort for it as possible. Capturing and explor- Alternative One { option | proposal } is . . . ing rationale should be non-intrusive, which means What { about | do you think } ... that developers should be able to perform rationale management as part of their daily practices rather The { advantages | pros } are . . . Pro I { like | prefer } it because . . . than having to change their development context. I agree with user . . . For example, developers should be able to capture and explore rationale simultaneously with performing { | } The disadvantages cons are . . . development tasks, implementing requirements, or Con I don’t like it because . . . committing code. I disagree with user . . . In order to fulfill this requirement of non- Let’s do . . . intrusiveness, we develop tool support that directly Decision We decided . . . integrates into the development tools [12]. In particu- The best option is . . . lar, we integrate our tool support into the issue tracking system, version control system, wiki system, chat Table 1: Types of rationale elements, their represent- system, and the integrated development environment. ing emoji, and indicating phrases adapted from [5]. We refer to our tool support as ConDec, standing for the continuous management of decision knowledge. 3 which makes fine-grained differences in element types The ConDec tool support is available online. such as implications resulting from a decision or con- While ConDec comprises features to trigger devel- straints that need to be considered [9]. There could opers in capturing and exploring rationale [11], in be various types of relationships between rationale this paper, we focus on the basic infrastructure neces- elements, for example, a decision can solve an issue sary for capturing and visualizing rationale as a graph. or it can also lead to a new issue. Regarding the ConDec tool support, the students get In order to teach rationale management, we use to know and apply the ConDec JIRA plugin, i. e., the an easy-to-learn model to represent rationale. This tool support for the issue tracking system JIRA. model covers five types of rationale elements: issue, The ConDec JIRA plugin supports different docu- alternative, pro- and con-argument, and decision (Ta- mentation locations of rationale, e. g., JIRA issues and ble 1). In our model, we distinguish three types of comments. On the one hand, rationale elements can relationships, i. e., edge types. The relates to relation- be captured as JIRA issues with special types for issue, ship is the default edge type. Only for arguments alternative, argument, and decision. Note the differ- different types are used: A pro-argument supports an ence between JIRA issue as an abstract container and alternative or the decision, whereas a con-argument the concrete issue as the rationale element. JIRA issue attacks an alternative or the decision. links are used to link the rationale elements with each other and also to JIRA issues of other types such as 2.2 Issue Tracking and Wiki System scenarios or tasks. On the other hand, rationale can Developers can capture rationale in various documen- be captured as part of the comments of JIRA issues. tation locations, for example, in the issue tracking 2.4 The iPraktikum [3, 10, 18] or the wiki system. Issue tracking systems are widely applied to store requirements, bug reports, The iPraktikum is a multi-project course in which up as well as development tasks. They contain various to 100 students work in eight to ten teams on real information types such as functionality or quality re- problems provided by an industry customer [4]. quests and as-is descriptions [17]. Wiki systems are In particular in the first half of the semester, the collaborative writing tools that can be applied for practical character of the course is supported by theo- many purposes, for example, for meeting manage- retical, yet interactive lectures. During these lectures, ment and requirements elicitation [19]. For a lecture the students learn the basic concepts of agile develop- on rationale management, we assume that students ment, release and merge management, modeling, and use the issue tracking system JIRA and the wiki system usability engineering. Recently, we added a lecture Confluence.1 JIRA and Confluence are commercial sys- on rationale management. During the iPraktikum, the tems that provide free licenses to universities. Both students apply latest tools and frameworks that are systems can be extended with plugins.2 used in real industry projects. Moreover, they get to use the results of latest research projects, which might 1https://atlassian.com/software 2https://developer.atlassian.com 3https://github.com/cures-hub

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 126 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

Figure 1: The decision knowledge view as a separate view for performing rationale management in JIRA.

find their way into the development process in the future. This prepares the students for their future use. At the time of the rationale management lecture, they have already been introduced to JIRA and Con- fluence. Regarding JIRA, they have at least one month of experience. This knowledge is imparted through various channels: (a) a development introduction course in which the students are required to track the progress of their work via JIRA, (b) the work within their teams, and (c) a course-wide lecture on managing the backlog, on what JIRA issues are, on how to close, move, and work with them in sprints. Re- garding Confluence, we provide the students with a meeting management introduction at the beginning of the course. This is handled by the coaches of a team, a special role within the team that is fulfilled by an experienced student and which is similar to a scrum master. The coach can decide on what to present, however, we provide a guideline that contains the major aspects of using Confluence. In particular, this relates to managing the team agenda, i. e., (a) how does a team meeting schedule look like?, (b) which roles are Figure 2: The JIRA issue view including the interactive present during each meeting?, (c) what are guidelines, rationale tree. i. e., what to provide as the stand-up information and when to use it? and the instant messaging services Slack5. Further, the ConDec JIRA plugin6 needs to be installed in JIRA 3 Lecture on Rationale Management and be enabled for the specific projects that the stu- In this section, we describe the lecture, the results of dent teams work in. Rationale elements that can be its first instantiation, and then discuss these results explored by the students need to be added to the re- and our lessons learned. spective JIRA projects, e. g., the elements shown in Figure 1 and Figure 2. Slack is used as a communi- 3.1 Preparation and Introduction cation tool between the instructors and students. In The lecture is designed to last 90 minutes. Students particular, polls can be created with the Polly Slack are grouped into teams and require a web-connected app7 through which students participate during the device with access to the internet.4 During the lec- lecture. ture, three systems are needed: JIRA, Confluence, 5https://slack.com 4An alternative would be to run the servers locally and to give 6https://github.com/cures-hub/cures-condec-jira students access to the intranet (not possible for Slack). 7https://polly.ai

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 127 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

The first part of the lecture covers background in- In our example, the decision and alternative on the formation about rationale management, such as its left are more requirements-related, whereas the deci- definition, expected benefits, and the rationale ele- sion on the right is implementation-specific (Figure 2). ments. We advise students to use certain phrases With this exercise, the students should learn that ra- when talking about and capturing rationale (Table 1). tionale can be captured for all steps in the software Further, we recommend to phrase issues as questions engineering process, including requirements elicita- ending with a question mark and to end alternatives tion, implementation, deriving test cases, and when with an exclamation mark. processing user feedback. Now, the students will make their first experience 3.2 Capturing, Visualizing, and Filtering in capturing rationale: Rationale in JIRA In the second part of the lecture, the students are Exercise 3 Link the existing issue “How to save trans- introduced to the JIRA ConDec plugin including the actions?” to the scenario. JIRA issue types for rationale elements (Figure 3). This issue is already part of the JIRA project (Fig- ure 1) but not linked to the scenario yet. The students can link the issue via a context menu on the scenario node (root node in Figure 2). The students realize that graphs of rationale can become large and complex. Therefore, filtering is important. The next exercise addresses filtering: Exercise 4 Filter the element types so that only the scenario and decisions are shown in the rationale tree.

Figure 3: JIRA issue types available in the project.

Two views for rationale management are shown to the students: the decision knowledge view (Figure 1) and the JIRA issue view (Figure 2). The decision knowledge view is a separate view that holds all rationale elements and their links for the given project. In Figure 4: Filtered rationale tree. this view, a user can select single rationale elements and visualize the graph of rationale as a tree, called Figure 4 shows the solution of this exercise. Now, rationale tree. In the JIRA issue view, rationale at- students discuss rationale in their team: tached to JIRA issues can be explored. For example, Exercise 5 Create a new issue “How to persist data?”. Figure 2 shows the rationale tree for a scenario. Add the following alternatives: “JSON!”, “SQLite!”. Dis- Then, the instructor demonstrates how to create cuss and capture pro and cons of each persistence alter- and link rationale elements shown on the right side native in your team. Add more alternatives and make a of Figure 1. Afterwards, the students gather in teams decision. and perform the first exercise: To solve this exercise, the students can add rationale Exercise 1 Gather your team, open your JIRA project, elements collaboratively from different devices. This and find the scenario already documented in the project. exercise takes about 10 to 15 minutes. Answer the question: How many issues are linked to the Rationale can be captured in many places. JIRA scenario? issues are just one possible documentation location The students can answer the question via a poll. In to store rationale. In order to demonstrate that there our example, the correct answer is that two issues are are other possible documentation locations, the stu- linked to the scenario (Figure 2). The next exercise is dents are presented with capturing rationale in JIRA to discuss the content of the solution proposals, i. e., issue comments (Figure 6). In this lecture, this is the alternatives and decisions. for information only, but, as part of our future work, we integrate various documentation locations typical Exercise 2 Answer the question: Which of the proposed for continuous software engineering and support the alternatives and decisions focus on requirements, which identification of rationale elements with a supervised of them on implementation? text classifier.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 128 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

3.4 Results Two authors of this paper gave the lecture on Novem- ber 8, 2018. In this section, we present results of this first instantiation of the lecture. The first poll was to answer the question what team a student belongs to. With this poll, we wanted the students to get warmed up in voting and to get the number of participating students. In total, 88 students answered the poll, i. e., about 88 students participated in the lecture. This number serves as a reference point for the following, quantitative evaluation results. Exercise 1 was answered by 64 students, i. e., 73 % of the participating students, of whom 63 gave the correct answer. Regarding the content of the solution proposals, Figure 6: Explicit rationale in the comments of the i. e., the alternatives and decisions, we initially asked scenario. a different question than given in Exercise 2. We asked the students to describe the difference between the alternatives and decisions. Since this question seemed 3.3 Rationale-based Meeting Management to be hard to answer, we restated the question as given Capturing rationale pays off during sprint meetings. in Exercise 2. This exercise was verbally performed The meeting agenda has an information sharing sec- and we did not collect any results for it. tion that lists issues discussed and decisions made After performing Exercise 3, we asked students to during the last sprint. If meeting agendas are man- assess how easy it was to link an existing issue to aged in Confluence, the rationale elements captured a scenario via a poll. They were asked to rate the in JIRA can be easily imported. statement Linking an existing issue to a scenario is Exercise 6 Gather your team, open your Confluence easy with one answer from a five point Likert scale. 59 space and create a new page called students participated in this poll, of whom 6 disagreed, (one per team). Create a sub-page called 11 were neutral, and 32 agreed with the statement (every team member). Use the JIRA Issue/Filter macro (Figure 5). After the lecture, we checked whether the to display decisions from your JIRA project. Answer the teams correctly performed Exercise 3. In every team question: How many decisions do you see? project, the issue was correctly linked to the scenario. The JIRA Issue/Filter macro is used in the exercise We did not collect any results for or attitudes to- and the search string is expressed using the JIRA query wards Exercise 4. language (JQL). The JQL string is: For Exercise 5, we created a poll in which the students could rate the statement Discussing rationale project = AND using ConDec is simple. 56 students participated in issuetype = Decision AND this poll, of whom 7 disagreed, 13 were neutral, and created > -7d. 35 agreed with the statement (Figure 5). In our case, two decisions are shown.

I would apply presenting rationale in Conﬂuence pages.

I would apply capturing rationale in JIRA issue comments.

Discussing rationale using ConDec is simple.

Linking an existing issue to a scenario is easy.

20 0 20 40 Number of students

strongly disagree disagree neutral agree strongly agree

Figure 5: Students’ attitude towards the presented methods and tools for rationale management.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 129 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

We asked the students to provide written feedback The results of voting on the statements in Figure 5 on discussing rationale (Table 2) and we analyzed the lead us to conclude that the majority of the students rationale graphs. A total of 126 rationale elements liked applying rationale management. More impor- were documented, i. e., a mean value of 12.6 rationale tant than the votes, the written feedback summarized elements per team with a standard deviation of 9.4 in Table 2 encourages us to improve the visualization elements. That means that each student contributed and filtering components of the ConDec JIRA plugin. a mean value of 1.4 rationale elements. A mean value In general, we had the impression that the students of 3.3 alternatives were documented per team (stan- liked voting on the polls and performing the exercises, dard deviation 1.2). 61 % of the alternatives correctly since this made the lecture more interactive [13]. ended with an exclamation mark. Seven of the ten Studying the rationale trees that the students cre- issues correctly ended with a question mark. Four ated in Exercise 5, we noticed that we did not ask the teams documented the decision. The types of the el- students to make a decision. Thus, only four decisions ements were correctly chosen, e. g., arguments were were documented. As a result, we will restate the not accidentally classified as alternatives. exercise for future use. The students seem to understand the elements of the rationale model (Table 1), Student Feedback Our Rationale since they correctly classified the element types in their trees of rationale. Permission scheme in the Deletion of elements is not JIRA project forbids dele- possible. tion for non-admin users. 4 Evaluation During Semester If there are many alterna- Two teams continue to apply rationale management tives and arguments, it is during the agile project course. Thus, we will evalu- A better graph visualization hard to get an overview. ate the explained methods for rationale management, and better, easy-to-apply fil- The user needs to scroll especially the ConDec JIRA plugin. ter possibilities are needed. very far to the right to see We introduced the role of the rationale manager. all the content. The rationale manager is responsible for checking and Capturing rationale ele- improving the rationale quality, i. e., they make sure Rationale elements should ments in separate JIRA is- that important elements are documented and that not always be a single sues has the advantage that they are consistent. Further, the rationale manager ticket. This seems to end they can easily be imported imports issues and decisions important for the last up in a ticket overflow. Pro- into Confluence. We also sprint into the meeting agenda in Confluence. They and con-arguments should develop the ConDec Conflu- update and add rationale elements after the meeting be comments. ence plugin to import ratio- in JIRA. The role of the rationale manager is taken by nale from comments. one student per team. The role is passed on after a week to a different student, i. e., it is an interchanging Table 2: Summarized feedback provided by students. role. After the students have completed the role of the rationale manager, we ask them to give us feedback After demonstrating that rationale could also be cap- by filling in a questionnaire. We derive the questions tured in the comments of the scenario, we asked the in this questionnaire by considering the variables of students to rate the statement I would apply capturing the technology acceptance model [16]: We consider rationale in JIRA issue comments. 61 students partic- the perceived usefulness, the perceived ease of use, ipated in this poll, of whom 18 disagreed, 24 were and the intention to use. Next to rating statements as neutral, and 19 agreed with the statement (Figure 5). shown in Figure 5, it is important that the students After the students performed Exercise 6, we asked provide detailed feedback on the features for rationale them to rate the statement I would apply presenting management they applied. For example, students rationale in Confluence pages. 55 students participated should provide details on what they think is useful or in this poll, of whom 7 disagreed, 13 were neutral, useless, easy or difficult, and why they think so. and 35 agreed with the statement (Figure 5). A mean value of 58 students participated in the 5 Related Work polls analyzed in Figure 5, which represents 66 % of To the best of our knowledge there is no work that all students. reports on teaching rationale management. Thus, in 3.5 Discussion and Lessons Learned this section, we present related work on applying rationale management in student projects. Clearly, the results that we collected during the lecture While tools for rationale management have been only represent the students’ first impression about the evaluated in student projects before, e. g., in [8] and presented methods for rationale management and the [2], the following authors especially focus on the pos- ConDec JIRA plugin. As described in the next section, itive effects of rationale management for the success we will apply a more thorough evaluation process of the student course. during the semester.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 130 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

Dutoit et al. discuss experiences with an integrated, Acknowledgements rationale-based modeling environment in a variety This work was supported by the DFG (German Re- of software engineering courses [6]. By applying ra- search Foundation) under the Priority Programme tionale management, they aim to enhance the com- SPP1593: Design For Future – Managed Software munication between instructor and students, to sup- Evolution (CURES project). We thank the partici- port students in reﬂecting their own work, and to pants of the rationale management lecture for their enable the instructor to better monitor the students’ participation in the exercises as well as the ConDec progress. These are valid beneﬁts that we also expect developers, inter alia, Tim Kuchenbuch, Jochen Clor- when students apply rationale management during mann, and Lars Tralle. Furthermore, we would like to the semester as part of the agile project course. Simi- thank Dominic Henze, Matthias Linhuber, and Florian lar to their modeling environment, ConDec integrates Angermeir for their technical support and Doris Kei- the rationale elements with the system elements, such del–Mueller for providing valuable feedback on the pa- as requirements. In addition, we focus on linking ratio- per. The emojis are created by Yusuke Kamiyamane10 nale with development tasks since they represent the and licensed under a Creative Commons License. place where developers need to solve issues related to design and implementation. References Malloy and Burge developed the software engineering using rationale tool SEURAT_Edu as a web-based [1] Zoya Alexeeva, Diego Perez-Palacin, and Raf- system that replaces the former SEURAT Eclipse8 ex- faela Mirandola. Design decision documenta- tension [15]. Like our tool support, SEURAT_Edu tion: A literature overview. In Software Architec- aims to support students in making the best decision ture, volume 5292 of Lecture Notes in Computer for an issue under consideration by explicitly reason- Science, pages 84–101. Springer, Berlin, Heidel- ing about design alternatives. During their evalua- berg, 2016. tion, Malloy and Burge found that the students us- [2] Rana Alkadhi, Jan Ole Johanssen, Emitza Guz- ing their tool considered more alternatives and put man, and Bernd Bruegge. REACT: An approach more thought into decision-making. Similar to their for capturing rationale in chat messages. In tool, the ConDec JIRA plugin is web-based, which 11th ACM/IEEE International Symposium on Em- allows students to easily collaborate. Their tool in- pirical Software Engineering and Measurement tegrates with learning management systems such as (ESEM’17), Toronto, Canada, 2017. IEEE. Moodle9, which has the advantage that the learning management system takes care of authentication and [3] Manoj Bhat, Klym Shumaiev, Andreas Biesdorf, assignment creation. In our case, this is handled by Uwe Hohenstein, and Florian Matthes. Auto- JIRA. Similar as we do in the lecture on rationale matic extraction of design decisions from is- management, SEURAT_Edu enables the teacher to sue management systems: A machine learning supply students with incomplete rationale that they based approach. In 11th European Conference are asked to complete. In addition, SEURAT_Edu en- on Software Architecture (ECSA’17), pages 138– ables the teacher to create a set of “solution” rationale. 154, Cham, Switzerland, 2017. Springer. ISBN It displays the status to which students reached a so- 978-3-319-65830-8. lution, in order to encourage them during their tasks. SEURAT_Edu performs automatic error checks, e. g., [4] Bernd Bruegge, Stephan Krusche, and Lukas whether there are issues not solved by a decision. The Alperowitz. Software engineering project ConDec JIRA plugin provides a report page that lists courses with industrial clients. ACM Trans- quality metrics. We plan to integrate support to ensure actions on Computing Education, 15(4):17:1– the rationale quality in the development process. 17:31, 2015.

6 Conclusion [5] Michael Doyle and David Straus. How to Make Meetings Work: The New Interaction Method. We presented a lecture on rationale management that Berkley, 1993. ISBN 978-0425138700. teaches students to apply a rationale model as well as methods and tool support for rationale management. [6] Allen H. Dutoit, Timo Wolf, Barbara Paech, Lars The students’ feedback and the exercise results let us Borner, and Jürgen Rückert. Using rationale conclude that the students comprehend the usage of for software engineering education. In 18th the rationale model and that they are motivated to Conference on Software Engineering Education apply rationale management. To validate this ﬁrst and Training (CSEE&T), pages 129–136, Ottawa, impression, a more detailed evaluation will be part of Canada, 2005. IEEE. the remaining duration of the agile project course. [7] Allen H. Dutoit, Raymond McCall, Ivan Mistrík, and Barbara Paech. Rationale Management in 8https://eclipse.org 9https://moodle.de 10http://p.yusukekamiyamane.com

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 131 Teaching Rationale Management in Agile Project Courses Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München

Software Engineering: Concepts and Techniques. [14] Claudia López, Víctor Codocedo, Hernán As- Springer, 2006. ISBN 978-3-540-30998-7. tudillo, and Luiz Marcio Cysneiros. Bridging the gap between software architecture rationale [8] Davide Falessi, Giovanni Cantone, and Martin formalisms and actual architecture documents: Becker. Documenting design decision rationale An ontology-driven approach. Science of Com- to improve individual and team design decision puter Programming, 77(1):66–80, 2012. making. In ACM/IEEE International Symposium on Empirical Software Engineering (ISESE), pages [15] John Malloy and Janet Burge. SEURAT_Edu: A 134 – 143, Rio de Janeiro, Brazil, 2006. ACM. tool to assist and assess student decision-making [9] Tom-Michael Hesse and Barbara Paech. Support- in design. In 47th Technical Symposium on Com- ing the collaborative development of require- puting Science Education (SIGCSE), pages 669– ments and architecture documentation. In 3rd 674, Memphis, Tennessee, USA, 2016. ACM. International Workshop on the Twin Peaks of Re- [16] Nikola Marangunić and Andrina Granić. Tech- quirements and Architecture, pages 22–26, 2013. nology acceptance model: a literature review [10] Tom-Michael Hesse, Veronika Lerche, Marcus from 1986 to 2013. Universal Access in the Infor- Seiler, Konstantin Knoess, and Barbara Paech. mation Society, 14(1):81–95, 2015. Documented decision-making strategies and de- [17] Thorsten Merten, Bastian Mager, Paul Hüb- cision knowledge in open source projects: An ner, Thomas Quirchmayr, Simone Bürsner, and empirical study on firefox issue reports. Informa- Barbara Paech. Requirements communication tion and Software Technology, 79:36–51, 2016. in issue tracking systems in four open-source [11] Anja Kleebaum, Jan Ole Johanssen, Barbara projects. In 6th International Workshop on Re- Paech, Rana Alkadhi, and Bernd Bruegge. Deci- quirements Prioritization and Communication sion knowledge triggers in continuous software (RePriCo), pages 114–125, Essen, Germany, engineering. In 4th International Workshop on 2015. Rapid Continuous Software Engineering (RCoSE), [18] Benjamin Rogers, Yechen Qiao, James Gung, pages 23–26, Gotheburg, Sweden, 2018. ACM. Tanmay Mathur, and Janet E. Burge. Using [12] Anja Kleebaum, Jan Ole Johanssen, Barbara text mining techniques to extract rationale from Paech, and Bernd Bruegge. Tool support for de- existing documentation. In 6th International cision and usage knowledge in continuous soft- Conference on Design Computing and Cognition, ware engineering. In 3rd Workshop on Continu- pages 457–474. Springer, 2014. ous Software Engineering, pages 74–77, 2018. [19] Carlos Solis and Nour Ali. Distributed require- [13] Stephan Krusche, Nadine von Frankenberg, and ments elicitation using a spatial hypertext wiki. Sami Afifi. Experiences of a software engineer- In 5th IEEE International Conference on Global ing course based on interactive learning. In Software Engineering, pages 237–246, Princeton, 15. Workshop Software Engineering im Unterricht NJ, USA, 2010. IEEE. der Hochschulen (SEUH), pages 32–40, Hanover, Germany, 2017.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 132 A Syllabus for Usability Engineering in Multi-Project Courses

Jan Ole Johanssen, Dominic Henze, and Bernd Bruegge Technical University of Munich, Munich, Germany [email protected], [email protected], [email protected]

Abstract this does not scale and is not easy to apply in the given Usability engineering is an important activity in to- time frame of a semester, even when the students day’s application development, which raises the need know how to do it. Furthermore, it requires more to focus on its teaching efforts. However, in contrast steps beforehand, such as creating an understanding to theoretical concepts, learning usability engineering of the feature under test, how it can be measured, and is most successful in a hands-on environment. Fur- delivering the feature to the end user. thermore, a challenge exists in efﬁciently applying Problem 2: Usability engineering concepts cannot usability assessment techniques to carry out usability easily be applied by students due to high setup efforts. engineering over time. We developed the UE4MP syl- To approach both problems, our hypothesis is that labus, a four meeting-based teaching approach for ag- students require a well-aligned teaching concept and ile multi-project courses using cross-functional teams. tool support to enhance the effectiveness of teach- The syllabus enables students to gain usability engi- ing usability engineering. Furthermore, we argue neering knowledge and experience through hands-on that such a teaching concept needs to be set within a learning and to make use of a platform for usability project course that provides a hands-on environment engineering. The overall goal is to relate usability to apply usability engineering concepts over a con- concepts closely to applications that are developed siderably longer timeframe in a practical manner as by the students themselves. We applied the UE4MP already suggested by Wohlin and Regnell [29]. syllabus over the course of one semester and report We describe a teaching syllabus and present an ex- on our observations and challenges. perience report, in which we show how the teaching concept is interweaved with the usage of a usability 1 Introduction engineering platform. We build upon the assumption that the combination of theoretical concepts and prac- With the availability of software for a great range of tical elements helps to make the usability engineering platforms, reaching from desktop computers to mobile more tangible for students [18]. devices, usability engineering gained high importance. This paper makes the following contributions: Typically, software engineering classes focus only • Description of a cross-functional team for usability on teaching development practices and engineering engineering that allows to transfer knowledge into theory and miss out on the usability of an application, project teams, which reduces the need do this with which results in a situation in which developers design every individual team member. user interfaces [26]. Nevertheless, students usually • A teaching syllabus that can be applied in a multi- have a general understanding of usability engineering project course to promote the hands-on applica- (UE) that raises from different sources: (a) common tion of theoretical usability engineering concepts. knowledge, intention, or personal interest in the topic, The syllabus incorporates the use of a usability or (b) lectures, that either are focused on teaching engineering platform. usability concepts to the full extend or discuss usabil- • Results from the application of the syllabus over ity engineering as a subtopic [17]. In any case, the the course of a semester, which allows to derive students usually lack a real-world scenario in which useful insights for further teaching efforts. they can apply new knowledge. The presented work and its contributions are moti- Problem 1: Students are barely able to apply us- vated by the idea of encouraging interaction and col- ability engineering in real-world applications. laboration when teaching usability engineering as sug- In addition, many concepts require a well-deﬁned gested by [6]. Furthermore, we foster transparency environment to be applied, which is not easy to pro- by using collaborative tools and interactive teaching vide. For example, the Thinking Aloud protocol by units that have a high dependency on applications Nielsen [18] might require a time-consuming setup; that are developed by the students themselves.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 133 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

This paper is structured as follows. Section 2 3 Course Environment presents related work in the context of teaching us- The syllabus targets an agile, multi-project course en- ability engineering. Section 3 provides the descrip- vironment, the iPraktikum, which we describe in this tion of a multi-project capstone course. This course section. We further outline the role of cross-functional forms the environment for a syllabus consisting of four teams and the CUU platform. meetings that are described in Section 4. Section 5 reports on an experience report which we discuss in 3.1 The iPraktikum Section 6 through highlighting observations and chal- We describe the capstone course iPraktikum, which lenges. Section 7 concludes the paper. provides the environment for teaching usability engineering in agile project courses. The iPraktikum is a 2 Related Work multi-project course which takes place every semester We follow Nielsen’s advice on teaching usability en- with 70-90 student developers who work in up to gineering by ”bas[ing] the course firmly in the labo- 12 project teams to create an application with a mo- ratory” [18] and thus teach in applied, project-based bile context for real customers from industry solving courses to prepare students for their later careers their real problems [4]. While the mobile context [9, 23, 29]. Nielsen stresses that—besides learning a is realized using Apple’s iOS platform, resulting in required set of skills through theoretical lessons—the iPhone and iPad applications, most projects are not hands-on approach is indispensable for students to standalone solutions, but include application servers, not only learn and understand the concepts of usabil- sensors, actuators, or wearable devices. ity engineering, but also to trigger a ”revolutionary As shown in Figure 1, each Project Team consists of change in [their] attitudes” [18]. This hands-on ap- a Customer from industry, a Project Management Team proach is also supported by others, such as Basili et al. consisting of a Project Lead and a Coach, as well as and Ghezzi et al., who stress that students need to the Development Team. Both the project lead and the apply their theoretical knowledge in practical projects coach fulfill a role similar to a scrum master. While [2, 11] to benefit from them [3, 8, 10, 28]. the project lead is a teaching assistant who is experienced in leading projects, the coach is a student who Offering students the chance to acquire the basic already participated as a developer. Thus, they are fa- skills motivated our theory sessions at the beginning of miliar with the infrastructure and teaching methodol- the syllabus to be followed by hands-on exercises. Ac- ogy. The Developers are students from second Bachelor cording to Nielsen, this experience is in particular valu- semester up to their last Master semester. able if the students investigate the usability of applications they developed on their own [18]. Chan et al. present research on how to integrate teaching human- Project Team 1 Project Team 2 Project Team N computer interaction aspects into the curriculum of Customer Customer Customer master classes and highlight the importance of real customers and ongoing discussions [7]. As a result, Project Management Team Project Management Team Project Management Team we describe a syllabus that integrates usability engi- Project Lead Project Lead Project Lead neering in a project course in which students develop applications for real customers from industry. Team Coach Team Coach Team Coach The need for teaching usability engineering was highlighted by Perlman in 1988 [25]. The fact that he Development Team Development Team Development Team continued to work on teaching usability engineering Developer Developer Developer in 1995 [26]—almost 10 years after the initial work— … … … shows that teaching usability engineering needs both Developer Developer Developer continuous refinement and adjustments over time. We achieve this by adding agile concepts and incorporating state-of-the-art technology into our syllabus. Figure 1: Overview of the iPraktikum’s team struc- Newer research of teaching usability engineering is ture, which consists of multiple project teams that are presented by Ovad et al., who try to get developers composed of different roles and sub-teams. in an agile industry setting to perform basic usability tasks, such as A/B tests, on their own [24]. Bruun et al. The iPraktikum fosters an event-based methodology, use a similar approach in an industrial setting to teach which enables the students to continuously interact developers usability evaluations. With only three par- with the customer [15]. Furthermore, the iPraktikum ticipants, the level of generalizability is limited, but puts a special emphasize on the development of early nevertheless the results of developers quickly learning prototypes and their vivid presentation to customers the core concepts of usability engineering look promis- [31]. Over the course of multiple semesters, it has ing [5]. As shown by these researches and supported been shown that the iPraktikum’s format and pro- by others [20, 21], experienced developers are often cesses contribute to increased skills of students re- the audience to teach usability engineering. garding both technical and non-technical aspects [4].

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 134 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

3.2 The Cross-Functional Teams 3.3 The CUU Platform The iPraktikum uses cross-functional teams [4, 15, 31] To enable Continuous Software Engineering (CSE), the to focus on special topics. Each of these teams is iPraktikum makes use of tool support—one of which is run by multiple cross-functional coaches and led the CUU platform: It aims for supporting developers in by a cross-functional instructor (Figure 2). Cross- understanding user behavior [12]. The overall vision functional coaches are students experienced in the re- of the platform is to enable usability engineering in spective ﬁeld. A cross-functional instructor is a teach- a rapid development environment such as CSE. It is ing assistant who ensures the teaching methodology. available as an open source project.1 CUU does not impose a particular feature deﬁnition

Cross-Functional Team Project Team 1 Project Team N to usability engineers: everything that is developed … … Usability Engineering on a feature branch can be understood as a feature.

Usability Usability Usability We further address the deﬁnition of a feature and its Instructor Manager Manager meaning in the syllabus in Section 4.2. Generally, CUU Usability Coach 1 Modeling Modeling analyzes whether users started, ﬁnished, or canceled Manager Manager the usage of a feature and visualizes this information Usability Coach 2 in widgets [13], as shown in Figure 3. Release & Merge Release & Merge Manager Manager Usability Coach N Developer Developer Modeling Management

Release & Merge Management … …

Figure 2: The iPraktikum cross-functional team structure focusing on the usability engineering team.

The cross-functional coaches work almost independently with the cross-functional teams: They elaborate on relevant topics and spread that knowledge to the cross-functional managers. These managers are de- A velopers from each team that have—in addition to their development tasks—the responsibility to share the knowledge they acquired in the cross-functional teams with their fellow team members. While most of the work is concentrated at the beginning of the course, support and review sessions B are conducted until the end of the projects to ensure an adequate quality. This approach allows the course organizers to spread knowledge from instructors to Figure 3: A screenshots of the CUU dashboard. Users the cross-functional coaches, followed by an informa- select one or more commits for inspection in a graph- tion sharing via the cross-functional managers to all like representation (A). Related usage information is other students of the course. Major challenges are the then presented in one or more widgets below (B). timing and coordination between project and cross- functional teams, as well as with course-wide events, This is enabled by the Feature Crumbs concept [14], such as course-wide lectures, or intermediate and ﬁnal a lightweight approach to mark feature speciﬁcs for presentations, in which the project teams present their detection during run-time. Feature crumbs are a single current status to the whole course and all customers. line of code, similar to breakpoints during debugging So far, the iPraktikum addressed a variety of cross- of code. Feature crumbs form the basis for referenc- functional teams. For instance, a modeling manage- ing a variety of usability testing techniques, such as ment team was established to support the project an automated implementation of the Thinking Aloud teams with creating, reviewing, and refactoring soft- protocol [18]. In particular, we plan to add a widget ware models created during the iPraktikum [1]. Like- that displays a summary of processed user feedback wise, a release & merge management team helps de- in relation to a feature crumb. velopment teams to setup the basic infrastructure for Besides the extract shown Figure 3, CUU hosts a their team, including continuous integration and de- Project Overview screen; a CUU project acts as the livery as well as ensuring the branching model and counterpart of a code repository. Furthermore, a Ser- the code review process introduced in [16]. With this vices screen allows UE manager to connect external work, we introduce a syllabus that extends the iPrak- services; we elaborate on this aspect in Section 6. tikum by adding a dedicated usability engineering cross-functional team. 1https://github.com/cures-hub

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 135 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

First UE Meeting Second UE Meeting Third UE Meeting Course-Wide Lecture Fourth UE Meeting

Unit 1 Unit 3 Unit 7 Unit 13 Homework Unit 10 Presentation

Practice Organizational Usability Aspects CUU Platform Engineering Unit 4 Experience Setup Theory Usability Discussion Practice Basic Engineering Practice Unit 2 Theory Advanced Unit 11 Unit 5 CUU Platform Unit 8 Introduction Usability CUU Platform Unit 14 Homework Theory Engineering Introduction UE Cross-Functional Integration Basic Theory Theory Retrospective Basic Advanced Practice Unit 12 CUU Platform Unit 15 Usage Organizational Unit 6 Organizational Unit 9 Organizational Aspects Aspects Aspects Practice

Figure 4: Visual overview of the UE4MP syllabus, a schedule for teaching usability engineering in cross-functional teams. A column represents a full meeting, which lasts for approximately 90 minutes; the UE content in the course-wide lecture might be shorter. Every box represents a Unit U, which encapsulates related content and is presented as one block within a meeting. The order of units suggests their actual position within the meeting and the size correlates with the time required for the unit. Arrows indicate constrains: for instance, Unit 2 must precede Unit 3 and 4, while Unit 10 can be hold at any time. Units with blue, single-stroked lines address usability engineering content (4 units), while units with orange, dashed lines deal with the CUU platform (6 units). Units with double-stroked lines related to organizational aspects of the course. The Theory and Practice tags distinguish content presentation from hands-on units; theory units vary in their difﬁculty level: basic content includes overviews and topic introductions, while advanced content extends basic unit knowledge.

4 Teaching Usability Engineering in a later point in time of the project. Hereafter, we in- Multi-Project Courses troduce them to the role of the usability engineering manager. We summarize them as follows: In this section, we introduce the UE4MP syllabus, which provides a guideline for teaching usability engi- • Learn, repeat, and consolidate the general con- neering in cross-functional teams within multi-project cepts of usability engineering. courses. The UE4MP reads Usability Engineering (UE) • Integrate a framework for user understanding in for multi-project (MP) teams, while the number 4 teams’ project and promote its application. also represents the number of meetings during the • Drive the realization of new insights that they semester. A broad overview is provided in Figure 4. gained from usage data and usability testing. The goal of the syllabus is to step-wise introduce As the major element of the first UE meeting, the important concepts and to reduce the theory parts in UE coaches prepare and hold a presentation of the favor of practical elements over time. A course-wide usability engineering basics. This is roughly based on lecture, which all students of the course attend, serves the book Usability Engineering by Jakob Nielsen [18]. as a general point of reference and milestone for the The coaches are asked to focus the presentation on usability managers. More details about this lecture is the following key aspects: provided in Section 5.1, while in the following, we • overview of usability slogans; detail every meeting with its content and goals. • introduction to the usability engineering lifecycle; • different forms of prototyping and their benefits 4.1 First UE Meeting and challenges, including tools and best practices; The focus of the first UE meeting is the theory of • overview of usability heuristics to prepare the usability engineering, which we base on fundamental homework for the next meeting; work [18, 22]. The meeting should further clear up • how to use the Thinking Aloud protocol as one any organizational questions the UE managers might example of usability testing; have at the beginning of the course. • idea of discount usability engineering. The first UE meeting consists of many organiza- The presentation should be interactive, and the tional aspects (Unit 1) and starts with an introduction coaches are encouraged to invite the managers to round of all usability managers. Furthermore, they are contribute ideas and descriptions while presenting the asked to include a brief overview of the projects they slides; usually, the managers already have a common are working on. This should prepare them to provide sense of the concepts, however, they cannot formally feedback to any of the developed applications during refer to it (e.g., the Thinking Aloud Protocol.)

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 136 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

The homework is clarified at the end of the meeting; they create and maintain these pages, they actively it reflects a first step of applying theoretical concepts inform the usability managers about the availability to the team’s applications. We ask the managers to through the chat messaging platform. The coaches pick and research on one usability heuristic and share further ensure that the usability managers work on their results within the second UE meeting as part of their homework; this is achieved by issues that are a two-minute talk. In Figure 5, we outlined a wiki part of the issue tracking system. This should prevent page that we prepared for that purpose, in which each UE managers from forgetting the homework, which manager has to fill in one row. would reduce the learning effect for all of the others during the second UE meeting. 4.2 Second UE Meeting The second UE meeting starts with a short presentation of the usability heuristics homework by each UE A manager (Unit 3). During the presentation of this first homework, the UE instructor facilitates the presenta- B tions of the usability managers. This idea is based on the assumption that the usability instructors have a C D E F G broader perspective on the topic; they can assess the heuristic and know how to apply it and therefore can ask for typical problems and situations in which they occur, in case the UE manager did not mention that aspect as part of their summary. Furthermore, the UE instructors help to put the heuristic into context, e.g., by noticing relationships between them. Overall, the goal is to encourage discussions about the topics and

H thereby sharpen the usability managers’ senses and understanding for the topic. As part of Unit 4, the UE coaches again provide a Figure 5: Wiki page created for the Usability Heuris- theory session on other usability engineering topics. tics homework; figure modified for visualization. (A) This time, however, the information is notably shorter Description of homework. (B) Help on how to access (approximately half of the time invested as in Unit 2), supportive material. (C) Heuristic name. (D) Link focusing on the following topics: to further reading. (E) Brief summary of the heuristic. (F) Name of the team that worked on the heuris- • small repetition of the topics of Unit 2; tic. (G) Concrete example of the heuristic within the • an introduction to scenarios as an instrument; team’s application. (H) An instance for an entry of a • an open discussion on the definition of a feature; usability heuristic within the table. • common practices, with minor focus on UE testing approaches different from Thinking Aloud and We are particularly interested in the UE managers’ usability evaluation through heuristics. results on (G), the application of the usability heuristic The second and third aspects of these topics are to their application. We ask them to create mockups the most important ones. Typically, the UE managers of good and bad examples of the heuristics. Therefore, are familiar with scenarios as a way to capture and it is important to ensure that the UE managers have describe requirements of a system. They also receive access to the book, either by lending a copy from the a repetition of this topic in a proceeding course-wide university library or having access to an online version lecture, which is not solely focused on usability en- of the book. We enriched the wiki page, on which UE gineering. However, in this unit, we focus on the managers were asked to add their homework, with a usage of scenarios for usability engineering [19]. This brief introduction on how to access the online library. prepares their understanding of feature crumbs as de- The homework fits the setup of this course, since there scribed in Section 3.3. The open discussion intends to are usually 10 teams and 10 usability heuristics; how- strengthen their understanding of features, how they ever, other allocations will also work. might be represented, and to prove the point that the The meeting closes with more organizational as- feature understanding is often a question of definition. pects, i.e., discussion on the meeting time of the next They are defined by the way they are managed, e.g., meeting and an overview of the upcoming meetings, user stories, scenarios, epics, and that they vary in size as well as clarification of questions. as well as other characteristics, such as the involved Before and after the first UE meeting, the coaches systems, stakeholders, criticality, and more. are asked to publish additional content that is relevant The last major unit of the second UE cross- for the managers, such as information pages about functional meeting is an introduction to the CUU plat- prototyping and links to popular tools. Not only do form (Section 3.3) following these three aspects:

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 137 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

• Present the platform’s functionality theoretically. • Introduce the feature crumbs concept, in particular walk through the feature path and status. Fea- ture paths represent a concatenation of feature crumbs [14], which allows statements about the feature state using the Unique Devices per Feature Path Observation widget as shown in Figure 3. • Explain the platform’s goals and align them with the previously presented approaches for usability testing and evaluation. In particular, this includes A an introduction of how feature crumbs can be used to perform Heuristics Evaluation [18], based on the knowledge that the usability managers gained through the homework. To be able to respond to the managers’ questions about the platform and the crumbs, we ask the coaches to carefully inform themselves using relevant literature [13, 14]. We also provide a short, informal B summary of the two papers in form of a wiki page. We close the meeting with Unit 6, organizational aspects, which, for the most part, introduces the homework: For the next meeting, the UE managers are asked to prepare a feature path of a specific scenario in their application as a preparation for the third UE meeting. Therefore, we provide a wiki page, as depicted in Figure 6, which we ask every UE manager C to copy into their team’s space and provide a URL for reference in a shared table. Figure 6: Wiki page created for the feature crumbs The managers start by creating a table that is simi- homework; figure modified for visualization, i.e., the lar to a formal representation of a scenario as shown description text has been removed. (A) List of crumbs in Figure 6 (A). Each row describes a feature crumb, to describe the UE managers’ rationale when design- split by its name, a short description and the ratio- ing the crumbs. (B) Example of how to add the nale of the crumb, and under which circumstances crumbs on a code level. (C) A JSON file that allows the crumb is triggered. Then, we ask them to add them to formally specify the feature path. comments to their source code where they think the individual crumbs from the table should be triggered. We use the comments as a first step toward the actual feature (Unit 7), followed by the integration of their tracking of features. This dry run requires to put a first own application-related feature (Unit 8) that they focus on designing the feature, rather than starting prepared in their homework from the previous meet- with the tool that is able to track the execution of the ing. As a result, Unit 7 forms the basis for Unit 8. feature. We provide an example of how we expect As this meeting brings results from multiple units, this comment to look like in Figure 6 (B); we put an synchronization becomes a major challenge when emphasize on the naming, since it should follow the preparing this meeting. The teams require a code exact same spelling as in Figure 6 (A). This should basis which can be released and run on a device; highlight the requirement that the same name of one this puts out requirements for both, the code and the row needs to be exactly spelled as in the code. The workflow for its processing. Furthermore, in practical same holds true for the JSON file that needs to be pro- terms, the UE managers require the hardware (com- vided in Figure 6 (C). Here, the UE managers design puter and mobile device) to run the tasks described a machine-readable version of the feature represen- in the following to setup and use the platform. tation that they previously described as a wiki page. For Unit 7, we prepare seven wiki pages that de- As with the comment-styled crumbs, this prepares an scribe everything required to set up the platform and easy transition into using the tool in the next meeting. make use of it. Since they contain potential pitfalls, 4.3 Third UE Meeting we walk the UE managers through them step by step: The third UE meeting is mainly hands-on. It enables Step 1 Login and Navigate to Project. Since the man- each team to use the platform independently. We pro- agers have never used the platform before, it needs to vide step-wise guidance on how to setup the platform be ensured that they know where to find the platform and integrate the needed framework for an example and how to access it.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 138 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

Step 2 Define new Feature and link Feature Branch. new feature version, by replacing the prepared crumb This step ensures that the UE managers adhere to the comments with actual method calls. iPraktikum’s development process: Every feature and At the end of this meeting, every team has created its related branch is based on an issue. Therefore, we at least one feature that can be fully tracked using the repeat the steps to formally create a branch. Hereafter, CUU platform. This serves as the input for a hands-on the managers need to switch back to their CUU project exercise (Unit 12) in the course-wide lecture. and create a feature representation in the platform. The meeting is closed by another round of organi- This can be done by providing a feature name and the zational aspects (Unit 9). In particular, we explain to initial commit on which the branch is based on. the managers how they can invite their team members Step 3 Initialize Client in Code Project. The CUU to the project using a user management screen that framework requires a client-side software develop- is part of the CUU platform. As this is an important ment kit (SDK) that observes the execution of the ap- requirement for the course-wide lecture, we track this plication. The managers integrate this SDK into their progress in order to ensure the effectiveness of the projects. They need to register the SDK with a Track- lecture. Eventually, we encourage the managers to ing Token and Project ID; this information is extracted continue using feature crumbs from this meeting on, from the services screen (Figure 8) and ensures that collect and note down any observations, feedback, the SDK can push information to the platform. and lessons-learned, as a preparation for the fourth UE meeting. Step 4 Add Feature Crumbs to Code Project. In this step, we introduce the managers to the notation of 4.4 Fourth UE Meeting triggering a feature crumb. At the bottom line, this The fourth UE meeting serves as an opportunity to is a method call with the feature crumb name as a stimulate the discussion between the UE managers. string parameter. We ask them to seed a feature crumb The goals of this meeting are manifold, however, the called My First Crumb in the startup sequence of the focus lies on Unit 13, in which every UE manager application. Hereafter, the managers need to push all presents a feature in more depth. This includes the the latest changes to the remote server. presentation of individual feature paths. Since this UE Step 5 Add Commits to Branch. The latest changes meeting is set at a later point of the project, we expect lead to a new feature increment, which needs to be that the managers not only present the feature com- registered with the platform. Therefore, they need to position, but also report on how the tracking helped copy and paste the latest commit hash to their feature them in terms of usability evaluation and assessment. in the CUU platform. Ideally, the managers elaborate on knowledge gained from the feature crumbs observations and how it sup- Step 6 Add new Feature Path. Finally, to associate a ported them to solve a problem. These in-depth de- commit with a feature path, they select the commit scriptions of actual insights in real applications can be in the CUU platform and use a popup window to add beneficial for the UE managers of other teams. a feature path in the JSON format. In this case, we Unit 14 is a retrospective in which the managers ask them to only use a single-step path, with step in- provide feedback on both the work with the platform formation 1 and feature crumb name My First Crumb. and the overall composition of the UE cross-functional role and the composition of the syllabus. After they performed these six steps, the feature Eventually, Unit 15 closes the meeting with a set of is ready for usability assessment. To test whether information regarding the remaining semester, such the setup was correct, they need to release the latest as their responsibilities for future deliverables or how commit. We introduce them to the different widgets they can approach us if questions remain. and how they can be harnessed to derive information about the feature’s performance. By asking the managers to add only one crumb with the same name 5 Experience Report and at the same position, we eliminate any possible We applied the UE4MP syllabus from Section 4 during confounding factors that might distract the UE man- the summer term of 2018 in an instance of the iPrak- agers from their actual goal: setting up the feature tikum, as described in Section 3. We followed the for tracking. Only after they were successfully able to intention of a case study as defined by Wohlin et al. follow steps 1 to 6 and see a change in feature usage, by ”provid[ing] a deeper understanding of the phe- we can be sure that everything works as expected. nomena under study in its real context” [30]. To bring the focus back to their projects, we return Overall, we set out to ensure the applicability of the to their prepared tasks from the homework in Unit 8. UE4MP syllabus and in particular the acceptance of This is usually much more complex, but of actual tool usage and theory concepts by the usability man- relevance for the UE managers. As a side effect, they agers. Therefore, this section reports on the temporal get to know the inner workings of the platform even instantiation (Section 5.1), the results of the practi- better. They learn how to add new crumbs to a feature cal units, i.e., the homework, (Section 5.2), and the path and what this means for the analysis, i.e., a number of feature crumbs usage (Section 5.3).

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 139 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

W1 W2 W4 W5 W7 W8 W11 MS MS W3 UE UE W6 UE CW W9 W10 MS W12

W13 W15 W17 W18 W19 W20 W21 W22 W23 W24 UE W14 MS W16 SB SB SB SB SB SB SB SB

Figure 7: Chronological sequence of the iPraktikum in the summer term 2018. W1 is the ﬁrst week of the semester, while W24 the last one. Supported by abbreviations, different box colors are used to map iPraktikum milestones, semester events, and UE meetings of the syllabus to semester weeks as follows. Blue boxes indicate usability engineering meetings (UE) and red boxes iPraktikum course milestones (MS). The green box highlights the usability engineering course-wide lecture (CW), while grey boxes relate to the semester break (SB).

5.1 Temporal Instantiation an intermediate presentation of their work. In W13, To make the UE4MP syllabus transferrable to other two weeks after the intermediate presentation, but courses, we mapped the meeting units to a typical before the final presentation in W15, the fourth us- semester of six month as shown in Figure 7. ability engineering meeting (Section 4.4) took place, gathering feedback for the UE cross-functional team As stated in Section 4, the syllabus builds up on and discussing feature paths and the corresponding cross-functional teams. These cross-functional roles, feature crumbs. as described in Section 3, require project teams and therefore can only be assigned after the initial iPrak- 5.2 Practical Unit Results tikum student assignment to project teams has fin- In this section, we report on the results from the home- ished. As a result, the first two weeks of the semester work of the usability engineering meetings, since they W1, W2 were reserved for the iPraktikum setup, while can serve as an indicator whether the UE managers W3 got the projects started and the cross-functional understood the topic and were able to successfully managers of each project team assigned. In W4, apply the concepts. we ran the first usability engineering meeting (Sec- The first homework regarding the usability heuris- tion 4.1), in which we focused on the organization, tics (presentation in Unit 3) was well perceived by the usability engineering basics and a first homework the managers. Everyone was able to fill in the core assignment. In the following week W5, the second us- components of the heuristic table. However, apply- ability engineering meeting took place (Section 4.2), ing the heuristic to their actual application was only containing the first practical exercises and the intro- successfully performed by two teams; the other teams duction to the platform. In the third usability engi- chose to use examples from well-known applications neering meeting (Section 4.3) in W7, the tool support such as Microsoft Word. in form of the CUU platform was integrated in each In the second homework, we asked the managers team’s project by the usability managers, followed by to define a feature that could be tracked using feature a first contact with the platform within each project. crumbs and the platform (Section 4.2). We were able After finishing the setup and explaining all concepts to derive more quantitative data as shown in Table 1, to the usability managers of each team, in W8 all which allows to derive further assumptions in the course participants were introduced to the concepts discussion section (Section 6). of usability engineering and the platform as part of Table 1 shows that every team successfully defined a course-wide lecture. The course-wide lecture is an crumbs for one of their application’s features. At min- optional addition to the UE4MP syllabus; it intends imum, two feature crumbs were required, while 14 to provide an overview of the first three usability en- was the maximum amount of feature crumbs used to gineering meetings. As shown in Figure 4, Unit 10 describe a feature. On average, a feature consisted of ensures a short theoretical introduction that sets the more than five crumbs. Except for one team, all teams stage. In Unit 11, we introduce the platform, how successfully described the feature path within a JSON it can be used, and what it aims for. Finally, with file. However, as it can be seen in the following sec- Unit 12, we make use of the prepared features from tion, team 4 was able to track their feature at a later the third UE meeting, which allows all students to point in time, which suggests that they forget to define benefit from a pre-defined feature within their own the feature path, but did it within the platform. Out of application to experience the usability assessment and the twelve features, ten can be considered as a proper, evaluation methods of the platform. meaningful feature, which makes sense to be tracked The timing of the course-wide lecture left the teams and assessed for usability assessment. However, this enough time to use the offered features until the sec- was not the case for two features, highlighted with a ond milestone of the iPraktikum in W11, which is red background in Table 1.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 140 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

Regarding the disparity between the intended and Table 1: Each team described at least one feature as actual study observations, there might be the chance part of their homework; every row depicts a feature. that the UE4MP syllabus and the introduction did not Number of Feature Path Feature contribute to the gain of knowledge. Since there has Team Crumbs Correct? Meaningful? not been a dedicated focus of usability engineering 1 3 Yes Yes in the course before, we can assume that any infor- 2 12 Yes Yes mation to that topic is beneﬁcial to the students. In 3 3 Yes No addition, to ensure that the concepts are straightfor- 4 14 No No ward, easy-to-understand, and consistent, we involved 5 3 Yes Yes multiple instructors from other cross-functional teams 6 3 Yes Yes to mediate the risk of ambiguous knowledge transfer. 6 Yes Yes The correlation between investigated and other fac- 6 Yes Yes tors might become visible in the way the managers 7 6 Yes Yes made use of the taught concepts. In particular other 8 3 Yes Yes duties, such as the actual coding or other courses, 2 Yes Yes might have affected the extent to which they were 9 3 Yes Yes working in the role of a usability manager. We tried to mediate this effect by reducing extra efforts, as well Team 3 implemented the feature path as three in- as providing help whenever needed. dependent actions, that all started a new feature on The degree of generalizability of the study is low, their own. Team 4, on the other hand, described a since we can only report of one instantiation in the massive feature execution, which depicted almost all agile multi-project course iPraktikum. However, we ar- of the application’s features. This led to a situation in gue that the presented syllabus is in general highly re- which multiple consecutive features were described as lated to the structure of the iPraktikum, which makes one feature, which hinders the individual assessment. generalization difﬁcult. Still, we think that many observations and results can help other lectures to 5.3 Platform Usage improve their teaching efforts regarding usability en- To provide more quantitative data, we counted the gineering. To be able to report more generalizable number of features that were created by the teams results, we plan to repeat the application of UE4MP throughout the semester. Table 2 shows the results. to gain more reliable insights. With respect to reliability, the fact that only one instructor supervised the cross-functional team might Table 2: The number of features created in CUU have biased the application of the UE4MP syllabus. separated by team; 20 features were created in total. However, since this cross-functional team was inte- Team 1 2 3 4 5 6 7 8 9 grated in a broader course, we argue that the effect

Features 3 3 1 1 2 2 2 3 3 was rather low.

Comparing the numbers with the features that were 6 Discussion created during the third UE meeting, which can be This section discusses the results from the experience derived from Table 1, eight additional features were report, provides interpretations of the presented num- added over the course of the semester. Furthermore, bers, and points out challenges regarding various as- we collected more data: Of the 20 features listed in pects of teaching usability in cross-functional teams. Table 2, approximately 2200 feature executions were recorded successfully, more than 850 were stopped with the possibility to be successfully ﬁnished, and The Effect of Tool Support. In general, we can sum- more than 1500 were actually canceled. In total, more marize that the combination of the UE4MP syllabus than 6500 feature crumbs were triggered. and the tool support in form of the CUU platform Overall, the number of features created within CUU enabled the students to perform actual usability engi- fall short of our expectations. On average, every team neering in their real-world development setting. created two features in CUU—one of which originated At the same time, the quantitative analysis of the from the third UE meeting. We discuss this aspect in platform usage indicates that—after an initial phase The Effect of Tool Support in Section 6. of using the platform—the teams reduced their efforts in designing feature paths and working with feature 5.4 Threats to Validity crumbs. This might have various reasons; for one, This section brieﬂy outlines the threats to the validity they have additional tasks which can hinder them of the reported experiences centered around the four from doing usability engineering. Other reasons might dimensions of validity [27], namely the construct, be found in the challenge of designing features, as internal, external, and reliability validity. described in the next paragraph.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 141 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

The numbers suggest that we need to further support the teams in making use of the platform, pointing out the benefits which can encourage them to invest more time in usability engineering. We continue our efforts as part of our future work (see Section 7). A Usability Engineering is Difficult. A more detailed analysis of the homework illustrates that the students struggle in applying usability concepts to their own applications. Regarding the first homework, the fact that only two teams were able to create applied examples of good and bad usability heuristic cases within their own application might be an indicator that these B heuristics are difficult to understand. The challenges in defining and understanding features become more obvious when analyzing the two cases highlighted as Figure 8: Screenshot of the Services screen of the CUU ”No” in the column ”Feature Meaningful?” of Table 1. platform. Usability managers need to add the tracking The creation of a well-defined feature representation token to their mobile application to enable the flow in form of feature crumbs requires effort. of usage data from the SDK’s usage monitoring com- Notably, in case a team provided a name for their ponent to the CUU web platform (A). This requires a feature, they always correctly defined the feature. This mature code basis, which might need several weeks might explain the reason, why two teams created until it is available. Furthermore, the credentials for wrong feature path descriptions: They had a different connecting the code repository with the CUU project mental model of a feature definition. This allows us can be obtained from the services screen (B). to draw the conclusion that it is not enough to only provide a platform, which strengthens our goal of aligning the syllabus next to the platform usage. In general, we conclude that usability engineering can be taught better with hands-on examples, which are shared with others to collect different opinions. Synchronizing Efforts. Synchronizing the UE4MP An instant communication channel promotes the col- can become an issue regarding the following aspects: laboration, while wiki pages—that we used for the • communicating the teaching materials and home- homework to collect usability heuristics as described work between the project leader, coaches, usabil- in Figure 5—represent another point of interaction. ity managers, and the individual team members; However, we noticed that many UE managers still • aligning the four meetings across the semester, as contacted us directly in case of questions via a direct described in Section 5.1; message and refrained from using the ”public” channel • ensuring that the teams’ progress is mature to ask the questions to all the other students. We enough that it fits to the UE4MP syllabus; actively encouraged them to change this and continue • connecting UE managers with other cross- to work on this in future semesters. functional managers, such as the release and merge managers, to ensure that they have access to the repository when setting up CUU, or are al- Acknowledging Privacy Aspects of Users. Usabil- lowed to update third party repositories, which is ity engineering inherently relies on the interaction a requirement to make the CUU platform’s client- with users. With the CUU platform and SDK, the stu- side SDK work; Figure 8 provides more descrip- dents obtain access to a tool that allows for learning tion concerning this aspect. more about the way a user interacts with an application. This includes, besides the ability to determine Enable Collaboration. Besides setting up an instant whether a feature has been started, completed, or messaging channel for every project team, we also canceled, additional knowledge sources that provide created a channel for the usability engineering cross- fine-grained information about the application usage. functional team. It turns out that this is a very inter- Generally, no personal data is collected in a way that esting place for discussions, which is important for would allow for conclusions toward an individual user. usability engineering. Usability engineering is a collab- Within the units of UE4MP, we intend to sensitize the orative process, which requires multiple participants, students for these aspects and the responsibility as both experts and users. The students of other teams a consequence thereof. In particular, we ask the stu- can act as proxy users; while they only have a rough dents to let their end users, i.e., the customers, know idea of the topic of the other applications, they know about the addition of CUU before they start using it. just the right amount of details to assess the usability Technical mechanisms inform the users about the data of the application from the perspective of a user. collection and provide the ability to opt out.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 142 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

Providing the Environment. One challenge arises Acknowledgements in providing the environment that is required to make This work was supported by the DFG (German Re- use of the UE4MP syllabus. To take full advantage of search Foundation) under the Priority Programme the syllabus, an extensive set of tools in form of an SPP1593: Design For Future – Managed Software Evo- infrastructure is required: lution (CURES project). We thank the iPraktikum ’18 • an issue management system to enable tracking students for their feedback and Simon Lang, Jan Philip of tasks and development progress; Bernius, and Lara Marie Reimer for their support. • a wiki system to share information, as well as enable a space to collaborate on the homework; References • a version control, continuous integration, and con- [1] Lukas Alperowitz, Jan Ole Johanssen, Dora tinuous deployment system that covers the full de- Dzvonyar, and Bernd Bruegge. Modeling in agile velopment process before the CUU platform can project courses. In MODELS (Satellite Events), be utilized; pages 521–524, 2017. • an instant messaging service. Providing and maintaining this environment repre- [2] Victor R. Basili. The role of experimentation sents a major challenge and is only feasible for large- in software engineering: past, current, and fu- scaled project courses. ture. In International Conference on Software Engineering, pages 442–449. IEEE, 1996. 7 Conclusion and Future Work [3] Barry Boehm, Alexander Egyed, Dan Port, Ar- Usability engineering is an important activity during chita Shah, Julie Kwan, and Ray Madachy. A software engineering. However, usability engineering stakeholder win-win approach to software engi- can only be taught successfully in a hands-on environ- neering education. Annals of Software Engineer- ment, using real-world projects in which students use ing, 6(1/4):295–321, 1998. their own applications for usability assessment. There- [4] Bernd Bruegge, Stephan Krusche, and Lukas fore, additional, hands-on teaching approaches need Alperowitz. Software engineering project to be developed to further support students besides courses with industrial clients. ACM Trans- their general software engineering curriculum. actions on Computing Education, 15(4):17:1– In this paper, we introduced the UE4MP syllabus, 17:31, 2015. a teaching concept based on four meetings that aims [5] Anders Bruun and Jan Stage. Barefoot usability to integrate usability engineering into multi-project evaluations. Behaviour & Information Technology, courses. This is enabled by establishing a cross- 33(11):1148–1167, 2014. functional role, in which students take over the role of usability managers. Furthermore, it incorporates the [6] John M. Carroll and Mary Beth Rosson. A case CUU platform for usability engineering, which reduces library for teaching usability engineering: De- the effort for setting up usability assessment activities. sign rationale, development, and classroom ex- We applied the UE4MP syllabus during one semester perience. Journal on Educational Resources in in the iPraktikum. Our observations suggest that the Computing (JERIC), 5(1):3, 2005. syllabus can be applied to teach usability engineer- [7] Susy S. Chan, Rosalee J. Wolfe, and Xiaowen ing through cross-functional teams in a multi-project Fang. Issues and strategies for integrating hci course. We were able to apply the syllabus as de- in masters level mis and e-commerce programs. scribed and in particular the theory aspects were well- Int. Journal of Human-Computer Studies, 59(4): perceived by the students. Likewise, students success- 497 – 520, 2003. ISSN 1071-5819. fully applied the CUU platform. However, it requires major efforts to teach the tool and point out beneﬁts. [8] David Coppit and Jennifer M. Haddox-Schatz. Therefore, as part of our future work, we plan to Large team projects in software engineering extend both the UE4MP syllabus as well as the CUU courses. In Proceedings of the 36th SIGCSE Tech- platform. Regarding the syllabus, we plan to add nical Symposium on Computer Science Education, one-on-one meetings after or as a replacement of the pages 137–141, New York, USA, 2005. ACM. fourth UE meeting, in which the usability coaches [9] Norman Fenton, Shari L. Pﬂeeger, and Robert L. meet with the managers to discuss their work. Re- Glass. Science and substance: a challenge to garding the CUU platform, we intend to continue its software engineers. IEEE Software, 11(4):86–95, development to offer more usability assessment func- July 1994. tionalities that could be provided through additional widgets. This should increase the platform’s overall [10] Christopher K. Hobbs and Herbert H. Tsang. In- usefulness and thereby increase its usage. Further- dustry in the Classroom. In Proceedings of the more, we are working on simplifying the setup steps Western Canadian Conference on Computing Edu- described in Section 4.3. cation, pages 1–5, New York, USA, 2014. ACM.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 143 A Syllabus for Usability Engineering in Multi-Project Courses Jan Ole Johanssen, Dominic Henze and Bernd Bruegge, TU München

[11] Paola Inverardi and Mehdi Jazayeri. Software Root. Teaching experienced developers to de- Engineering Education in the Modern Age: Soft- sign graphical user interfaces. In Proceedings of ware Education and Training Sessions at the In- the SIGCHI Conference on Human Factors in Com- ternational Conference, on Software Engineering, puting Systems, CHI ’92, pages 557–564, New ICSE 2005, St. Louis, MO, USA, May 15-21, 2005, York, NY, USA, 1992. ACM. Revised Lectures, volume 4309. Springer, 2006. [22] Donald A. Norman and Stephen W. Draper. User [12] Jan Ole Johanssen. Continuous user understand- Centered System Design; New Perspectives on ing for the evolution of interactive systems. In Human-Computer Interaction. L. Erlbaum As- Proceedings of the ACM SIGCHI Symposium on sociates Inc., Hillsdale, NJ, USA, 1986. ISBN Engineering Interactive Computing Systems, EICS 0898597811. ’18, pages 15:1–15:6, New York, NY, USA, 2018. ACM. ISBN 978-1-4503-5897-2. [23] Tom Nurkkala and Stefan Brandle. Software studio: Teaching professional software engineer- [13] Jan Ole Johanssen, Anja Kleebaum, Bernd ing. In Technical Symposium on Computer Science Bruegge, and Barbara Paech. Towards the vi- Education, pages 153–158. ACM, 2011. sualization of usage and decision knowledge in continuous software engineering. In 2017 IEEE [24] Tina Øvad, Nis Bornoe, Lars Bo Larsen, and Jan Working Conference on Software Visualization Stage. Teaching software developers to perform (VISSOFT), pages 104–108, September 2017. ux tasks. In Proceedings of the Annual Meeting of the Australian Special Interest Group for Com- [14] Jan Ole Johanssen, Anja Kleebaum, Bernd puter Human Interaction, OzCHI ’15, pages 397– Bruegge, and Barbara Paech. Feature crumbs: 406, New York, NY, USA, 2015. ACM. Adapting usage monitoring to continuous software engineering. In Product-Focused Software [25] Gary Perlman. Teaching user interface develop- Process Improvement, pages 263–271, Cham, ment to software engineers. Proceedings of the 2018. Springer International Publishing. ISBN Human Factors Society Annual Meeting, 32(5): 978-3-030-03673-7. 391–394, 1988. [15] Stephan Krusche, Lukas Alperowitz, Bernd [26] Gary Perlman. Teaching user interface devel- Bruegge, and Martin O Wagner. Rugby: an agile opment to software engineers. In Conference process model based on continuous delivery. In Companion on Human Factors in Computing Sys- Proceedings of the 1st International Workshop on tems, CHI ’95, pages 375–376. ACM, 1995. ISBN Rapid Continuous Software Engineering, pages 0-89791-755-3. 42–50. ACM, 2014. [27] Per Runeson, Martin Host, Austen Rainer, and [16] Stephan Krusche, Mjellma Berisha, and Bernd Björn Regnell. Case Study Research in Software Bruegge. Teaching code review management Engineering: Guidelines and Examples. John Wi- using branch based workflows. In International ley & Sons, 2012. Conference on Software Engineering - Companion [28] Mary Shaw, Jim Herbsleb, Ipek Ozkaya, and Volume, pages 384–393, 2016. Dave Root. Deciding what to design: Closing [17] Stephan Krusche, Nadine von Frankenberg, and a gap in software engineering education. In Sami Afifi. Experiences of a software engineer- International Conference on Software Engineering, ing course based on interactive learning. In Soft- ICSE ’05, pages 607–608, 2005. ware Engineering im Unterricht der Hochschulen, [29] Claes Wohlin and Björn Regnell. Achieving in- SEUH ’17, pages 32–40, 2017. dustrial relevance in software engineering edu- [18] Jakob Nielsen. Usability Engineering. Interac- cation. In Conference on Software Engineering Ed- tive Technologies. Elsevier Science, 1994. ISBN ucation and Training, pages 16–25. IEEE, 1999. 9780080520292. [30] Claes Wohlin, Per Runeson, Martin Hst, Mag- [19] Jakob Nielsen. Scenarios in discount usability nus C. Ohlsson, Bjrn Regnell, and Anders engineering. In John M. Carroll, editor, Scenario- Wessln. Experimentation in Software Engineer- based Design, pages 59–83. John Wiley & Sons, ing. Springer Publishing Company, Incorporated, Inc., 1995. 2012. ISBN 3642290434, 9783642290435. [20] Jakob Nielsen and Rolf Molich. Teaching user [31] Han Xu, Stephan Krusche, and Bernd Bruegge. interface design based on usability engineering. Using software theater for the demonstration SIGCHI Bull., 21(1):45–48, August 1989. ISSN of innovative ubiquitous applications. In Joint 0736-6906. Meeting on Foundations of Software Engineer- ing, ESEC/FSE 2015, Bergamo, Italy, August 30 - [21] Jakob Nielsen, Rita M. Bush, Tom Dayton, September 4, 2015, pages 894–897, 2015. Nancy E. Mond, Michael J. Muller, and Robert W.

V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 144