Download CSV

No transcript

Very short / questions incoherent

Sloppy transcript, otherwise good / summarizing transcript

some formal flaws, otherwise good

Perfectly prepared, perfect transcript

       

Interview mit »anonym« (11.05.2021) (INT-10)

Acronym

nnWMA2

Stakeholder

anonym

History

(v1)   2021-05-24 - initially created

Interviewleitfaden

Der folgene Interviewleitfaden wurde vorbereitend für das Interview erstellt.

Ablauf

1. Begrüßung und Vorstellung der Interviewer
   1. Kurze Erläuterung des Moduls
   2. Grund für das Interesse am Interview
2. Starten der Aufnahme für das Transkript
   1. Mündlich die schriftliche Einwilligung bestätigen
   2. Befragung beginnen

Fragen

Fragen zur Rolle in der Lehre

1. Welche Aufgaben hast du derzeit in der Lehre an der TH?
   1. An welchen Modulen bist du beteiligt?
   2. Wie ist deine Verantwortung in den einzelnen Modulen?

Fragen zur digitalen Lehre

1. Welche Medien und Tools verwendest du aktuell in der Lehre?
2. Gibt es Unterschiede zwischen den einzelnen Lehrveranstaltungen?
3. Was sind die größten Herausforderungen im digitalen Lehrbereich und was würdest du dir an Verbesserung wünschen?

Fragen zu Aufgaben

1. Welche Aufgabentypen stellst du? Stellst du die Aufgaben selbst?
2. Werden die Aufgaben individuell für jeden Studierenden erstellt? Wenn nicht, wäre dies wünschenswert?
3. Wer kontrolliert die Abgaben? Gibt es hierzu eine Automatisierung?
4. Wie könnte ein Tool für die Aufgabenstellung und Verwaltung der Abgaben den Arbeitsalltag mitgestalten und verbessern?Anforderungsmanagement SoSe 2021
5. Gibt es Aufgaben, die du gerne stellen würdest, aber aufgrund von beschränkten Möglichkeiten auslässt? Welche Möglichkeiten fehlen dir dazu?

Fragen spezifisch zu Divekit

1. Welche Kenntnisse besitzt du über den aktuellen Stand des Tools? Hast du schon einmal damit gearbeitet?
2. Für welche Module, in welchen du tätig bist, ließe sich das Tool einsetzen?
3. Welche Features wären noch nützlich, um das Tool für deine Zwecke noch besser einsetzbar zu machen?
4. Welche Fehlertoleranz hast du bezüglich einer automatisierten Aufgabenkontrolle? (aufgrund von Klausurzulassung, Richtigkeit der Praktikumsinhalte)
5. Wie würde das Tool die Bearbeitung von Aufgaben für Studierende verbessern? Wie hoch denkst du ist die Akzeptanz für das Tool? Wo siehst du potentielle Zweifel?
6. Wie ist die Haltung von Professoren gegenüber der Verwendung eines Tools wie Divekit? (z.B. Rechtssicherheit, da verantwortlich für Klausurzulassung)
7. Warst du schon vorher an einem Tool wie Divekit interessiert und hast nach so etwas gesucht? Wenn ja, warum?
8. Wäre eine Schnittstelle des Divekits zu den anderen Tools der TH sinnvoll? Wenn ja, welche?
9. Hast du generelle Vorschläge und Wünsche für die Zukunft des Divekits?

Verabschiedung und Vielen Dank!

Ergebnisprotokoll

Zum Interviewten

Der Interviewte ist im Lehrbereich der TH Köln an diversen Modulen beteiligt. Einige davon leitet er selbst hauptverantwortlich. Dazu gehören die Module „Visualisierung“, „Paradigmen der Programmierung“, die Mastervorlesung „Beautiful Code“, „Compilerbau“ und „Algorithmen der Programmierung 1+2“.

Bisherige digitale Lehre und möglicher Einsatz von Divekit

Als sinnvolle Einsatzgebiete für Divekit sieht er primär „Paradigmen der Programmierung“ und „Algorithmen und Programmierung 2“. Dort werden die Vorlesungen über Screencasts abgehandelt und für die Praktika werden freiwillige Übungsblätter ausgeteilt. Der Wissenstand wird in einem Ilias Test für die jeweilige Übungsaufgabe abgefragt. Das Bestehen der Tests ist verpflichtend für die Klausurzulassung. Daneben gibt es noch zur Unterstützung Live-Coding Termine, wo Studierende Fragen zu dem Gelehrten und den Übungen stellen können.

In den Wahlpflichtfächern „Visualisierung“ und „Compilerbau“, sowie dem Mastermodul „Beautiful Code“ werden keine Zwischenleistungen abgefragt, sodass der Interviewte hier keine Einsatzmöglichkeit von Divekit sieht.

Als bisheriges Problem bei der digitalen Lehre sieht er die fehlenden Feedback-Kanäle für das Praktikum an. Bei den Tests kann den Studierenden, die nur knapp bestanden haben, kaum Rückmeldung über mögliche Probleme ihres Tests gegeben werden, da eine Übersicht über die Tests fehlt. Die Studierenden müssen proaktiv eigene Wissenslücken oder Verständnisprobleme erkennen und auf den Lehrenden selbständig zugehen. Dies wird gerade von den kritischen Fällen kaum bis gar nicht in Anspruch genommen. Somit bekommen Studierende meist nur eine generelle Lösung und kein individuelles Feedback, wie sie sich selbst noch entsprechend ihren Fehlern und Probleme verbessern können.

Ein weiteres Problem ist die hohe Rate an Studierenden, die bei den Tests betrügen. Auch wenn es Variationen in den Aufgaben gibt, werden in den WhatsApp-Gruppen der Studierenden Lösungen ausgetauscht. Damit kann schwieriger festgestellt werden, ob die Studierenden die Aufgaben selbständig lösen können oder ob diese nur von Anderen übernommen wurden.

Wissenswertes zu den Aufgabenstellungen

Bisher laufen die Aufgaben über Ilias-Tests. Dort bestehen 60 bis 70 Prozent der Aufgaben aus Freitextaufgaben, in welchen die Studierenden Code schreiben müssen. Der Rest sind Fragen zur Theorie, welche über Single-Choice, Multiple Choice und Diagramme, in denen Lücken aufgefüllt werden müssen, abgefragt werden. Die Aufgaben beinhalten jeweils leichte Variationen, welche händisch eingefügt wurden. Die Korrektur der Theorieaufgaben wird automatisiert von dem Ilias-Test durchgeführt. Die Freitextaufgaben lassen sich nicht automatisiert überprüfen, wenn auch die Lösungsansätze und Intentionen der Studierenden mit Teilpunkten benotet werden sollen. Auf dem automatisierten Weg lässt sich nur die Funktionstüchtigkeit des Programmcodes im Ganzen bewerten. Daher werden diese von Betreuern des Moduls korrigiert.

Für das Divekit wünscht er sich Unit-Tests, welche die Studierenden mit ihren Aufgaben zu den jeweiligen Abgaben erfüllen müssen. Diese sollen für einfache Programmieraufgaben und Abfragen von theoretischen Fragen genutzt werden. Studierende, welche 70 bis 80 Prozent der Tests nicht bestanden haben, sollen zusätzlich Feedback zu ihren Aufgaben bekommen können.

Zudem wünscht er sich komplexere Aufgaben stellen zu können. Damit sind vor allem Aufgaben gemeint, welche Bibliotheken zusätzlich zur Standardbibliothek benutzen. Um solche Aufgaben stellen zu können, wünscht er sich eine Umgebung, in welche er Projekte hochladen kann, welche die geforderten Bibliotheken bereits enthalten. Zudem soll der zeitliche Rahmen für diese Aufgaben, wie derzeit bei einem Ilias-Test, nicht mehr auf eine Stunde begrenzt sein, sodass die Studierenden genug Zeit haben auch komplexere Aufgaben zu bearbeiten.

Stand von Divekit und weiterführende Anforderungen an das Tool

Der Interviewte hat bisher noch nicht mit Divekit gearbeitet und sich bis auf die Blogposts zu den Domain-Modellen noch nicht groß mit Divekit beschäftigt. Er denkt allerdings aufgrund von dem, was er bisher kennt, dass sich Divekit für „Algorithmen und Programmierung 2“ sowie „Paradigmen der Programmierung“ einsetzen lässt.

Zusätzlich zu den zuvor ausgeführten Anforderungen an das Tool wünscht er sich Projekte in das Tool einzustellen zu können, deren Lösung die Studierenden auch dort hochladen, sodass die jeweiligen Lösungen damit automatisch den richtigen Studierenden zugeordnet sind.

Ein weiterer Wunsch ist die Einführung einer Plagiatsdetektion. Wenn die Studierenden die Lösung komplett gleich haben oder Aufgaben einer anderen Gruppe abgeben, weil sie diese einfach übernommen haben, soll das von dem Tool entdeckt und entsprechend geahndet werden. Das kann möglicherweise auch so ausgeweitet werden, dass die Studierenden etwas von anderen übernehmen dürfen, solange sie die Stellen entsprechend zitieren. In diesem Fall könnten die oft zitierten Studierenden mit Bonuspunkten oder Ähnlichem entlohnt werden.

Die Variation der Aufgaben soll zudem dadurch erhöht werden können, indem ein Pool semantisch gleicher Fragen aus verschiedenen Kontexten angelegt wird, anstatt nur die Variablennamen zu ändern. Diese sollen den Studierendengruppen zufällig zugewiesen werden können.

Solange nicht alle Aufgaben des Praktikums über das Divekit erstellt werden können, soll es eine Schnittstelle zwischen Divekit und dem E-Assessment-Tool des Ilias geben oder alternativ ein übergeordnetes Tool, dem die Tools die Ergebnisse berichten. Dort sollen sie zusammengeführt werden, sodass sich das Gesamtergebnis automatisch erstellen und einsehen lässt.

Als letzte Anforderungen sind APIs gewünscht, mit denen man selbst die Funktionalitäten mit eigenen Tests und Tools für die jeweiligen Bedürfnisse anpassen kann. Dazu sollte das Tool in Sprachen erstellt sein, welche von den meisten Programmierern beherrscht werden und die eigenen Erweiterungen mit einfachen Forks des Divekit-Repositories erstellt werden können.

Für die automatisierte Auswertung sollte eine Fehlerquote von 95 Prozent nicht überschritten werden. Die Ergebnisse und Entscheidungen des Tools sollten nach außen einsehbar sein, damit bei Beschwerden aufgrund einer falschen Auswertung die Bewertung manuell überprüft werden kann.

Das Tool wird seiner Meinung nach auf Widerstand bei den Lehrenden stoßen und von vielen zunächst nicht eingesetzt werden, da es eine Umstellung bedeutet und bei fehlenden Funktionalitäten einen zu großen Mehraufwand hat. Dort muss mit Möglichkeiten zum beratenden Austausch entgegengewirkt werden. Auch bei Studierenden könnte es aufgrund von fehlendem Feedback und der verpflichtenden Einführung in GitHub auf Ablehnung stoßen. Da die Technologie Industriestandard ist, ist es allerdings als Vorteil für die Studierenden zu betrachten. Der Interviewte erwartet, dass die Studierenden das Tool gerne annehmen und damit indirekt Druck auf die Lehrenden aufbauen werden.

Für Klausuren lässt sich das Tool laut des Interviewten aus rechtlichen Gründen nicht nutzen. Als Tool für die Praktika schon, unter der Voraussetzung, dass es langfristig weiterentwickelt wird.

Das Transkript des Interviews kann hier gefunden werden:

Transkript des Interviews