Content

Janine Golov, Jens Bendisposto, 3 (Teil)-Invertierung der Programmierausbildung in:

Sabrina Zeaiter, Jürgen Handke (Ed.)

Inverted Classroom - The Next Stage, page 29 - 38

Lehren und Lernen im 21. Jahrhundert

1. Edition 2017, ISBN print: 978-3-8288-4015-7, ISBN online: 978-3-8288-6782-6, https://doi.org/10.5771/9783828867826-29

Tectum, Baden-Baden
Bibliographic information
(Teil)-Invertierung der Programmierausbildung Janine Golov & Jens Bendisposto Students learning to program need to test and improve their knowledge hands-on at the computer. A classical lecture is not well suited to teach these skills. As part of a restructuring of the curriculum, we decided to partially invert some of the practical courses. In this paper, we describe the challenges we faced and the modifications we made to the courses as well as some preliminary results. We identified parts of the lecture which can be learned easier when tried out during watching videos or reading tutorials. We partly moved the programming homework to practical exercise groups and structured the learning material in smaller chunks.As a result, we could observe that our students continually work on their assignments. Furthermore, students de‐ scribe the new courses as demanding but helpful. Beyond that, we could more preci‐ sely observe the problems of our students and now, have the ability to act on these specific problems. Hintergrund Seit dem Wintersemester 2015 werden im Bachelor Studium Informatik an der Hein‐ rich-Heine-Universität eine Reihe von Verbesserungsmaßnahmen durchgeführt. Ein Schwerpunkt dieser Änderungen ist die Verbesserung der Programmierausbildung. Im Wintersemester 2016/17 gingen diese Änderungen in eine neue Prüfungsordnung ein. Tabelle 1 zeigt als Ausschnitt aus der umfassenden Änderung des Curriculums, wie die Pflichtveranstaltungen, welche zur Programmierausbildung beitragen, sich verändert haben. Die beschriebenen Veranstaltungen liegen im Studienablaufplan nach der Veranstaltung Programmierung, in welcher die Grundlagen der Program‐ mierung in Java vermittelt werden. Im Folgenden wird beschrieben welche Probleme mit den alten Veranstaltungs‐ formaten beobachtet wurden, zu welchen Änderungen diese Beobachtungen führten und an welchen Stellen jetzt auf Invertierung gesetzt wird. 3 3.1 29 Veranstaltungen (bis WS 2016/17) Veranstaltungen (ab WS 2016/17) Programmierpraktikum (10 LP) Professionelle Softwareentwicklung (8 LP) Softwareentwicklung im Team (8 LP) Informatik 2 mit C-Projekt (10 LP) Rechnerarchitektur (9 LP) Hardwarenahe Programmierung (4 LP) Vergleich der Programmierveranstaltungen vor und nach dem WS 2016/17 Programmierpraktika Dieser Abschnitt beschreibt die Probleme, die bei dem alten Veranstaltungsformat auffielen, sowie die Umstrukturierung hin zu einem teilweise invertierten Lehrmodell und den bisherigen Erfahrungen aus dem laufenden Semester. Das alte Programmierpraktikum Vor dem Sommersemester 2017 gab es ein einsemestriges Programmierpraktikum in dem Studierende in Gruppen von 4-6 Personen ein Softwareprojekt entwickeln soll‐ ten. Begleitend dazu wurde eine Vorlesung angeboten, in der Studierende mit der Entwicklung von graphischen Benutzerschnittstellen und Teamarbeit vertraut ge‐ macht wurden. Eine Teilnahmevoraussetzung für das Praktikum gab es nicht, die Stu‐ dierenden sollten aber bereits aus dem ersten Semester über Programmierkenntnisse in Java verfügen. Ein beobachtetes Problem war die nicht unbeträchtliche Zahl von Studierenden, die trotz mangelhafter Programmierkenntnisse am Praktikum teilgenommen haben. Durch die Konstruktion als Gruppenarbeit führte das zu mehreren Problemen. Ganze Gruppen kamen in zeitliche Bedrängnis, da die Minderleistung Einzelner vom Team kompensiert werden musste und besagte Studierende konnten sich hinter einer ge‐ lungenen Teamarbeit verstecken und bekamen ungerechtfertigter Weise einen Leis‐ tungsnachweis. Ein weiteres Problem war die mangelnde Programmiererfahrung, um eine größe‐ re Programmieraufgabe im Team zu bewältigen. Die Arbeit in einem Team stellt für sich bereits eine hohe Herausforderung dar. Die Mehrfachbelastung durch Team-Ko‐ ordination, Vertiefen ihrer Javakenntnisse sowie Sammlung von Erfahrungen schien die Studierenden zu überfordern. Es scheint eine gewisse Zeit für die Verarbeitung der neu gewonnenen Kenntnisse erforderlich zu sein, bevor sie in einem Gruppen‐ projekt effektiv eingesetzt werden können. Es fehlte die Zeit, um mit unterschiedlichen Ansätzen zu experimentieren und auch Standardlösungen für Probleme auszuprobieren. Das mangelnde Wissen konnte im späteren Verlauf des Studiums, vor allem bei Abschlussarbeiten, oft beobachtet werden. Anstatt eine Standardlösung für ein Problem zu verwenden, haben Studie‐ Tabelle 1: 3.2 3.2.1 3 (Teil)-Invertierung der Programmierausbildung 30 rende oft eigene (schlechte) Lösungen implementiert. Hier fehlte eine essentielle Fä‐ higkeit: Zu wissen, wann etwas nicht programmiert werden muss. Eine weitere Beobachtung war, dass Studierende die Aufgaben aufgeschoben und erst kurz vor der Deadline erledigt haben. Das ist vermutlich nicht ungewöhnlich, aber bei einem größeren Softwareprojekt, selbst wenn es mit Hilfe von Meilensteinen gegliedert ist, kann ein Unterschätzen des Aufwands leicht zum Nichtbestehen der Veranstaltung führen. Professionelle Softwareentwicklung Mit der neuen Prüfungsordnung werden diese Probleme adressiert. Seit dem Som‐ mersemester 2017 müssen Studierende, die an dem Praktikum teilnehmen wollen, nachweisen, dass sie über die notwendigen Programmierfertigkeiten verfügen. Dies geschieht über den Leistungsnachweis der Veranstaltung Programmierung. Das Programmierpraktikum wurde in zwei Veranstaltungen aufgeteilt. Die erste Veranstaltung vertieft die Programmierkenntnisse und dient dem Sammeln weiterer Erfahrungen mit Java. Die zweite Veranstaltung befasst sich mit der Entwicklung von Software in einem Team. Diese zweite Veranstaltung findet erstmals im Wintersemes‐ ter 2017/18 statt und wird in diesem Artikel nicht diskutiert. Die Ziele des ersten Praktikums und der zugehörigen Vorlesung Professionelle Softwareentwicklung sind: – Erlangen von Wissen über Strukturierungsprinzipien großer Software-Systeme – Vertiefung von spezifische Themen der Programmiersprache Java – Vermittlung eines breiten Wissens über bestehende Lösungen für häufig auftreten‐ den Probleme – Förderung des Experimentierens mit Software – Einführung in industrielle Praktiken und Qualitätsstandards Die Themen Strukturierungsprinzipien und industrielle Praktiken werden in einer klassischen Vorlesung vermittelt, die zusätzlich auf Video aufgezeichnet und den Stu‐ dierenden zugänglich gemacht wird. Die Vertiefung von technischen Themen, das Experimentieren mit Code und das Kennenlernen von Standardlösungen sind aller‐ dings nicht gut geeignet für eine Vorlesung. Für diese Lernziele verwenden wir Screencasts und Rechercheaufgaben. Jede Woche erhalten die Studierenden den Auf‐ trag sich ein Lehrvideo anzusehen und eine Rechercheaufgabe auszuführen. Beide Aufgaben werden durch Arbeitsaufträge ergänzt, die die Studierenden durcharbeiten sollen. Abbildung 1 zeigt die Videolektion der ersten Woche. 3.2.2 3.2 Programmierpraktika 31 Ausschnitt aus dem Arbeitsauftrag für die erste Videolektion Die Studierenden werden mit Hilfe einer Demonstration an ein Standardwerkzeug der Softwareentwicklung herangeführt und sollen dann einige leichte Experimente durchführen. Die Verwendung der vorgestellten Software wird in anderen Videos und Rechercheaufgaben aufgegriffen und vertieft. Die Videos sind zwischen 20 und 40 Minuten lang und es wird immer eine bestimmte Technik oder ein Werkzeug prak‐ tisch vorgeführt. Einer der Vorteile dieses Formats ist, dass Studierende parallel zur Erklärung das Dargestellte ausprobieren können. Die Videos werden auf einem Macbook Pro mit Hilfe der Software Camtasia 3 aufgenommen und geschnitten. Erfahrungsgemäß ist das eingebaute Mikrofon des Macbook Pro absolut ausreichend, um Screencasts in guter Audio-Qualität aufzuneh‐ men. Erfahrungen mit dem neuen Format Die Videos werden über Youtube zur Verfügung gestellt, sind aber nicht über die Su‐ che zu finden, da in diesem Semester die Akzeptanz der Screencasts überprüft werden soll und daher sichergestellt werden musste, dass nur Teilnehmer der Veranstaltung in den Youtube Statistiken erfasst werden. In Tabelle 2 sind die bisherigen Videos auf‐ geführt. Woche Titel Länge (min) Views (314 Studierende) 1 Einführung in Gradle 19:14 700 2 Eine erste Tour durch Eclipse 32:38 415 3 Dateien und Verzeichnisse in Ja‐ va 22:28 380 4 Datum und Zeitfunktionen 22:44 260 5 Refactoring des Parrot Katas 27:31 214 Videolektionen im Sommersemester 2017 Abbildung 1: 3.2.3 Tabelle 2: 3 (Teil)-Invertierung der Programmierausbildung 32 Um sicherzustellen, dass die Studierenden kontinuierlich mitarbeiten, müssen die Studierenden jede Woche 75% der Fragen eines Online-Tests korrekt lösen. Die Fra‐ gen stehen den Studierenden vorab zur Verfügung und umfassen die Themen der Vorlesung, der Rechercheaufgaben und der Videos. Zum Teil gehen die Fragen auch über den vermittelten Stoff hinaus, so dass die Studierenden zum Experimentieren angeregt werden. Der Test hat primär den Zweck, zu einer kontinuierlichen Mitarbeit zu bewegen. Es hatten sich 314 Studierende für die Veranstaltung angemeldet, den fünften Wochentest lösten davon 266 Studierende korrekt. Auch die Klickzahlen der Videos legen nahe, dass sich der Großteil der Studierenden mit dem Stoff auseinandersetzte. An den Klickzahlen des ersten Videos erkennt man, dass das vorgestellte Werkzeug auch in späteren Aufgaben verwendet wird und die Studierenden das Video als Refe‐ renz verwenden. Entgegen vorheriger Befürchtungen konnte keine Abnahme der Vorlesungsteilnahme durch die Aufzeichnungen beobachtet werden. Hardwarenahe Programmierung In diesem Abschnitt werden zunächst die alten Veranstaltungen und die identifizier‐ ten Probleme beschrieben und anschließend die Umstrukturierung, sowie die damit gesammelten Erfahrungen. Informatik 2 In der Informatik 2 sollten die Studierenden die Programmiersprache C, mit zugehö‐ rigen Werkzeugen (insbesondere ein Speicheranalysetool), und die Assemblersprache NASM lernen. Die Programmierung in C sollten die Studierenden im Selbststudium erlernen. In der vorlesungsfreien Zeit bekamen die Studierenden eine etwas größere Aufgabe gestellt, deren Schwerpunkt die Speicherverwaltung in C war. Die Aufgabe wurde durch die Studierenden bearbeitet und musste bestanden werden, um die Klausurzulassung zu erreichen. Während der Bearbeitungszeit wurden regelmäßige Sprechstunden angeboten. Die Kenntnisse in Assemblerprogrammierung wurden klassisch mittels Vorlesung und anschließenden vertiefenden Übungsaufgaben, sowie Besprechung dieser Übungsaufgaben in den Übungsgruppen vermittelt. In den ver‐ gangenen Jahren sind einige Probleme im bisherigen Ablauf aufgefallen: 1. Technische Probleme Die Studierenden hatten häufig Schwierigkeiten Ihre Programmierumgebung ein‐ zurichten. Häufig wurden deshalb ungetestete, nicht einmal übersetzbare Pro‐ gramme abgegeben. 2. Organisatorische Probleme Viele Studierende haben den ersten Teil der Zulassung (über Punkte in den Übungsblättern) geschafft, bestanden aber das C-Projekt nicht. Die Studierenden, 3.3 3.3.1 3.3 Hardwarenahe Programmierung 33 die das Projekt abgaben, bestanden in der Regel. Problematisch daran ist, dass es keinerlei Anhaltspunkte dazu gab, wann und weshalb Studierende verloren gingen. Obwohl die Studierenden Ihre Projekte frühzeitig einreichen konnten, automati‐ sierte Rückmeldungen über Ihre Programme bekamen und bis zum Abgabe‐ schluss nachbessern konnten, fand die erste Abgabe eines Studierenden oft erst kurz vor Abgabeschluss statt. 3. Schwächen bei der Programmierung Die Studierenden wissen häufig, dass Ihre Programme fehlerhaft sind, sind aber nicht in der Lage diese Fehler systematisch zu suchen und dann zu beheben. Außerdem war die Codequalität häufig schlecht. Die Assembleraufgaben in der Klausur wurden von vielen Studierenden nicht oder nur schlecht bearbeitet. Man kann folglich davon ausgehen, dass viele Studierende hier erhebliche Probleme hatten, die sie aber sowohl in der Klausur als auch in den Übungen durch andere Themenbereiche kompensieren konnten. Erste Umstrukturierung: Das C-Praktikum Die Identifizierung der oben genannten Probleme führte zu den im Folgenden be‐ schriebenen Umstrukturierungen. Diese fand in zwei Schritten statt: Zunächst wurde bereits im vergangenen Jahr das C-Projekt durch ein C-Praktikum ersetzt, welches bereits zweimal durchgeführt wurde. Es werden zunächst die Änderungen, die für das C-Praktikum im ersten Durch‐ lauf durchgeführt wurden, betrachtet. Wichtige Ziele hierbei waren die Selbstständig‐ keit beim Erlernen der Programmiersprache zu erhalten, aber besser zu unterstützen, und einen besseren Einblick in die Probleme der Studierenden zu erhalten. Für die Veranstaltung wurde ein invertiertes Format, bestehend aus acht Einheiten, gewählt. Jede Einheit bestand aus Vorbereitungs- und Präsenzzeit. Hierbei wurde den Studie‐ renden mitgeteilt, dass sie für die Vorbereitung etwa genauso viel Zeit einplanen soll‐ ten wie für die Präsenzphasen. Informationen und Links zu zusätzlichen Materialien wurden über Ilias bereitgestellt. Die Studierenden bereiteten sich anhand der genannten Literatur (Lehrbuch, Tu‐ torials, Handbücher) auf jede Einheit vor. Weiterhin wurde für jede Einheit ein Ilias Test angeboten. Die Testfragen bezogen sich auf das Material, welches die Studieren‐ den für den jeweiligen Tag vorbereiten sollten und wurden alle automatisch bewertet. Es handelte sich um Single oder Multiple Choice Fragen sowie Lückentexte. Die Stu‐ dierenden bekamen Rückmeldung darüber, welche Ihrer Antworten korrekt und wel‐ che falsch sind. Zusätzliches Feedback konnten die Studierenden sich persönlich im Laufe der Präsenzphasen von den Tutoren einholen – hiervon wurde jedoch nur sel‐ ten Gebrauch gemacht. Auf Basis des Tests sollen die Studierenden feststellen, welche Fragen bzw. Verständnisprobleme sie noch haben. Die Bearbeitung der Tests war frei‐ willig und die Studierenden konnten diese beliebig oft wiederholen. Die Tutoren der 3.3.2 3 (Teil)-Invertierung der Programmierausbildung 34 einzelnen Gruppen konnten auf die Ergebnisse zugreifen, sollten jedoch vorrangig dann agieren, wenn die Studierenden selbstständig nachfragten. Im Durchschnitt wurden die Tests im Wintersemester 2016/17 von 46% der Teil‐ nehmer durchgeführt, wobei der Test zu Tag 1 von fast 80% der Studierenden ge‐ macht wurde, die Teilnehmerzahl mit steigendem Schwierigkeitsgrad aber auf etwa 32% an Tag 7 (zu Tag 8 gab es keinen Test, da kein neuer Stoff hinzukam) gesunken ist. Dies entspricht in etwa der Zahl der Studierenden, die das Praktikum auch be‐ standen haben, es gibt aber sowohl Studierende, die keine Tests gemacht haben, die bestanden haben als auch anders herum. Im Wintersemester wurde die Veranstaltung nur von Studierenden belegt, welche eine zu dem Modul gehörige Prüfung bereits be‐ standen hatten, in der Regel waren dies also Studierende höherer Fachsemester, die das Praktikum oder seine Vorgängerveranstaltung bereits mindestens einmal erfolg‐ los belegt hatten. Zum Sommersemester 2016 – in welchem auch eine große Menge Erstteilnehmer die Veranstaltung belegten - existieren leider keine Zahlen mehr. Auch hier gab es jedoch den Eindruck, dass nur wenige Studierende die Selbsttests durch‐ führten. Die Studierenden wurden für die Präsenzphase in Gruppen mit maximal 20 Teil‐ nehmern eingeteilt, so dass für jeden ein Rechner zur Verfügung stand. In der Prä‐ senzphase hatten die Studierenden in den ersten Minuten Zeit Fragen zu stellen, bei‐ spielsweise zu den Selbsttests. Diese Fragerunden wurden von den Tutoren der jewei‐ ligen Gruppe geleitet. Eine zeitliche Begrenzung war nicht notwendig, da zu den meisten Themen nur wenige Fragen gestellt wurden. Anschließend bekamen die Stu‐ dierenden die Aufgaben des jeweiligen Tages, welche am Rechner bearbeitet werden mussten. Obwohl es keine Anwesenheitspflicht gab, bearbeiteten fast alle Studieren‐ den die Aufgaben im Rechnerraum. Während der Bearbeitungszeit war dort immer ein Tutor anwesend, welcher bei Problemen und Fragen weiterhelfen konnte. Verein‐ zelt kamen auch Studierende, welche das Praktikum nicht mehr bestehen konnten weiterhin zu den Präsenzphasen, um für eine Wiederholung besser gerüstet zu sein. Die Aufgaben mussten bis zum Ende der Bearbeitungszeit beim Tutor abgegeben werden. An zwei Tagen innerhalb des Praktikums sowie am letzten Tag durften die Studierenden Gebrauch von einem Joker machen, der eine verspätete Abgabe bis zum Beginn der nächsten Präsenzphase erlaubte. Diese Joker wurden eingeführt, um den Stressfaktor, welche die zeitliche Begrenzung für die Studierenden bringt, zu verrin‐ gern. Die Tutoren machten während der Bearbeitungszeit auf Fehler und Verletzun‐ gen der Coderichtlinien aufmerksam und halfen bei deren Einhaltung. Die Code‐ richtlinien sind so gestaltet, dass Sie die Lesbarkeit und Struktur des Codes verbes‐ sern. Auch wenn diese Regeln theoretisch einfach zu verstehen sind, bereitete deren sinnvolle Umsetzung den Studierenden häufig ähnlich viele Schwierigkeiten wie die Lösung der Aufgabe an sich. Aus diesen Gründen ist die Verlagerung der Program‐ mierzeit in eine Präsenzphase mit Hilfe von Tutoren sehr sinnvoll. Insgesamt konnten die Punkte 1 und 2 der oben genannten Probleme bereits gut gelöst werden. Technische Probleme wurden umgangen, da die Studierenden die Möglichkeit hatten, mit institutseigenen Rechnern zu arbeiten. Die Studierenden mussten kontinuierlich arbeiten und es konnte wesentlich genaueres Wissen darüber 3.3 Hardwarenahe Programmierung 35 gewonnen werden, welche Probleme auftraten. Darüber hinaus wurden folgende Er‐ fahrungen gemacht: – Es konnte wesentlich mehr Einfluss auf die Codequalität gewonnen werden. Das stetige Einhalten der Coderichtlinien schon in kleinen Programmen half den Stu‐ dierenden diese auch in längeren Programmen zu wahren und sie sahen nach und nach die Vorteile lesbaren Codes. Die Ergebnisse waren erheblich besser als der bisherige Standard. – Es konnte viel genauer gesteuert werden, welches Wissen die Studierenden verin‐ nerlichen, anstatt dass sie auf Umwegen mit bereits bekanntem Wissen zur Lö‐ sung kamen. – Die Probleme der Studierenden begannen viel früher als erwartet. Häufig hatten sie Probleme bei Programmen, die im Prinzip identisch zu denen waren, welche sie in der ihnen bekannten Programmiersprache Java bereits schreiben können sollten. Die Probleme scheinen demnach in den zugrundeliegenden Konstrukten und nicht in der Wahl der Programmiersprache begründet zu sein. – Studierenden, die Joker einsetzten, fehlte Zeit für die Vorbereitung der nächsten Einheit. – Viele Studierende taten sich schwer Prinzipien der Programmerstellung, die ihnen bekannt waren (kleinschrittiges Vorgehen, häufiges Testen, Compilerwarnungen beachten) umzusetzen. – Nur wenige Studierende führten die Selbsttests durch. Bereits im zweiten Durchlauf konnte die Problematik der Joker dadurch gelöst wer‐ den, dass die acht Praktikumstage nicht mehr direkt aufeinander folgten, sondern das Praktikum auf 15 Tage gestreckt wurde. Weitere Umstrukturierungen im Sommersemester 2017 Für das neue Praktikum soll nun in der kommenden vorlesungsfreien Zeit die As‐ semblerprogrammierung integriert werden. Man erhält dadurch zehn Einheiten, die auf vier Wochen gestreckt werden. Innerhalb dieser vier Wochen gibt es an jedem zweiten Werktag eine Präsenzzeit für die Studierenden. Da die vorhandenen Materia‐ lien zur Assemblerprogrammierung noch nicht ausreichend sind, um den Stoff zu vermitteln, wird es vor dem Praktikum eine Vorlesung geben. Diese Vorlesung wird aufgezeichnet. Diese Aufzeichnung soll, so denn möglich, als Grundlage für die wei‐ tere Invertierung des Kurses dienen. Darüber hinaus ist es vorgesehen die Erfahrun‐ gen aus den vergangenen Praktika zu nutzen, um die festgestellten Probleme zu adressieren. Hierzu sind folgende Maßnahmen geplant: – Die Studierenden noch deutlicher darauf hinweisen, dass Programmierkenntnisse einer (anderen) Programmiersprache mit ähnlichen Konzepten vorausgesetzt wer‐ den. 3.3.3 3 (Teil)-Invertierung der Programmierausbildung 36 – Es werden, ähnlich wie in der Veranstaltung Professionelle Softwareentwicklung, Videos erstellt, die die kleinschrittige Bearbeitung von Programmieraufgaben zei‐ gen. – Die Selbsttests, Informationen und Materialien werden innerhalb eines Ilias Lern‐ moduls gebündelt, wobei die nächsten Einheiten jeweils erst nach korrekter Bear‐ beitung aller Testfragen geöffnet werden können. Nach wie vor ist die Bearbeitung der Testfragen freiwillig, die Studierenden haben aber erhebliche Nachteile (z.B. kein Zugriff auf die Lernvideos zu Programmieraufgaben), wenn sie die Testfra‐ gen nicht beantworten. Das Praktikum fand in dieser Form im August und September 2017 statt. Fazit Die Erfolge dieser Änderungen können leider noch nicht in Zahlen gefasst werden, es konnte aber beobachtet werden, dass die Studierenden in beiden Veranstaltungen kontinuierlicher mitarbeiten (mussten). Studierende berichteten im Feedback zu bei‐ den Veranstaltungen mehrheitlich, dass die Praktika sehr anstrengend, aber ebenso hilfreich waren. Weiterhin schienen die Teilnehmerzahlen im Programmierprakti‐ kum ab dem Ende der ersten Woche relativ konstant zu bleiben. Im C-Praktikum konnten bereits erste Erfolge, insbesondere bezüglich der Codequalität beobachtet werden. Dies alles führt zu der Überzeugung, dass die Teilinvertierung der Veranstal‐ tungen sowohl für die Studierenden als auch für das Erreichen der gesetzten Lernziele förderlich ist. Kontakt Wir sind an einem Austausch zur Invertierung von Veranstaltungen in ähnlichen Kontexten interessiert. Sie können uns gerne per Email kontaktieren. – Janine Golov (golov@cs.uni-duesseldorf.de) – Jens Bendisposto (bendisposto@cs.uni-duesseldorf.de) 3.4 3.4.1 3.4 Fazit 37

Chapter Preview

References

Zusammenfassung

Nun schon zum sechsten Mal fand die „Inverted Classroom Konferenz“ statt, seit 2016 im jährlichen Wechsel zwischen der Philipps-Universität Marburg und der Fachhochschule St. Pölten in Österreich. Die Konferenz hat sich als fester Bestandteil der deutschsprachigen Community von Lehrkräften und Interessenten, die sich der Digitalisierung der Lehre verschrieben haben, etabliert und wird mit jeder Durchführung thematisch ausgebaut und erweitert. Der Organisator der „Inverted Classroom Konferenz“, Jürgen Handke, wurde 2013 mit dem 2. Projektpreis des hessischen Hochschulpreises für Exzellenz in der Lehre ausgezeichnet, im Oktober 2015 wurde ihm dann mit dem Ars legendi-Preis für digitales Lehren und Lernen der am höchsten dotierte und renommierteste deutsche Lehrpreis verliehen. Der Erfolg der „Inverted Classroom Konferenz“ mit all ihren Community-Mitgliedern dürfte bei diesen Errungenschaften einen wichtigen Beitrag geleistet haben. Neben speziellen Themen zum Inverted Classroom in all seinen Facetten standen bei der 6. Inverted Classroom Fachtagung 2017 unter anderem Anwendungsbeispiele aus den Fächern Wirksamkeitsstudien, Fragen nach der Erzeugung digitaler Inhalte sowie Open Educational Resources oder auch Roboter zur Nutzung in digital unterstützten Lehrszenarien zur Debatte. Der Tagungsband „Inverted Classroom – The Next Stage“ fasst nicht nur die Ergebnisse dieser 6. Fachtagung zusammen, sondern er bietet anhand ausgewählter Fallstudien und Untersuchungen auch einen Einblick in die Arbeit all derjenigen, die sich mit der Digitalisierung der Lehre im Allgemeinen und mit dem Inverted Classroom im Speziellen befassen.