Mehr Praxisbezug im Bachelor-Studium Der Einsatz von Computern in Prüfungen der praktischen Informatik

Transkript

1 6. TAG DER LEHRE 24. NOVEMBER 2005 FACHHOCHSCHULE ULM Mehr Praxisbezug im Bachelor-Studium Der Einsatz von Computern in Prüfungen der praktischen Informatik Sven Klaus / Peter Knauber Um einen stärkeren Praxisbezug der Lehre spürbar zu machen, sollten sich auch Klausuren dem heute typischen Arbeitsumfeld eines Informatikers anpassen. Dazu gehört die Nutzung der Möglichkeiten, die integrierte Entwicklungsumgebungen bei der Entwicklung von Software bieten. Dieser Beitrag berichtet von den Erfahrungen mit einer Klausur, die Studierende auf freiwilliger Basis direkt am Rechner durchgeführt haben, vergleicht sie mit den Erfahrungen aus rein papierbasierten Klausuren und zeigt Konsequenzen auf. 1. Einleitung Die im Rahmen des Bologna-Prozesses eingeführten Bachelor-Studiengänge sind grundständig und vermitteln einen ersten berufsbefähigenden Anschluss. Dabei ist die Forderung nach dem konkreten Praxisbezug inzwischen sogar noch stärker betont als sie es bei dem bisherigen Fachhochschuldiplom war. Das heutige Arbeitsumfeld eines Informatikers in der Softwareentwicklung umfasst neben einem Standard-PC eine Vielzahl von Hilfsmitteln wie z. B. integrierte Entwicklungsumgebungen. Diese Hilfsmittel überprüfen für den Programmierer die Syntax, generieren einen bestimmten Code usw. Die Vorgehensweise beim Programmieren selbst hat sich so in den letzten Jahrzehnten tiefgreifend geändert. Diese Veränderung sollte sich auch bei der Abnahme von Prüfungsleistungen widerspiegeln. Rein papierbasierte Klausuren können diesem Anspruch nur schlecht gerecht werden. Ziel dieser Untersuchung war zu prüfen, wie sich gegenüber der traditionellen Papier- Klausur die Ergebnisse ändern, wenn bei der Lösung der Aufgaben eine integrierte Entwicklungsumgebung herangezogen werden kann. Hierzu wurde einer Gruppe von Freiwilligen in einem Rechnerraum an je einem PC eine Klausur zur Bearbeitung bei vorgegebenem Zeitrahmen zur Verfügung gestellt. Gleichzeitig konnte die Klausur auch über das World Wide Web geladen werden. Da hier die Einhaltung der Zeitgrenze nicht kontrolliert werden konnte, wurden diese Ergebnisse separat erfasst. 2. Randbedingungen für eine Klausur am Rechner Beim Entwickeln einer Klausur am Rechner sind diverse technische und organisatorische Dinge zu berücksichtigen: Es ist eine geeignete Entwicklungsumgebung zu wählen, die den Studierenden bekannt und vertraut ist. Die verwendeten Rechner müssen einheitlich konfiguriert sein und mit der verwendeten Software stabil laufen. Die Rechner müssen komplett voneinander und von der Außenwelt abgeschottet sein: Die Klausurteilnehmer dürfen keine Möglichkeit haben, untereinander oder mit der Außenwelt zu kommunizieren. Das gilt für explizite Kommunikationsmechanismen wie , IRC oder Talk, aber auch der Missbrauch von Dienstprogrammen wie telnet oder ftp muss 104

2 verhindert werden, da es sonst sehr einfach möglich wäre, fertige Lösungen an beliebige Teilnehmer weiterzuleiten. Aus diesem Grund müssen auch einheitliche Zugänge eingerichtet werden. In unserem Fall haben wir uns für das folgende Umfeld entschieden: Die Klausur sollte nicht leichter oder schwieriger als eine konventionelle Klausur sein, nur etwas umfangreicher, weil wir erwarteten, dass Tippen und Korrigieren meist schneller geht als von Hand zu schreiben, und weil Möglichkeiten bestehen, Teile des geforderten Codes zu generieren. Aufgaben haben wir existierenden Klausuren entnommen (s. Abschnitt 3). Da in unserem Bachelor-Studiengang ab dem ersten Semester Java gelehrt wird, wird die OpenSource-Entwicklungsumgebung Eclipse [1] eingesetzt, die den Studierenden vertraut ist und daher auch in der Testklausur eingesetzt wurde. Motivation der Studierenden für die freiwillige Teilnahme an der Testklausur war die Verbesserung der Ausbildung hin zu mehr Praxisnähe; die Ergebnisse der Klausur wurden nicht als Prüfungsleistung gewertet. Aus diesem Grund haben wir auf die geschilderten Vorsichtsmaßnahmen verzichtet. 3. Auswertung der Testklausur Die Aufgaben für die Testklausur wurden drei existierenden Klausuren entnommen, waren also bereits in der traditionellen Form zur Bearbeitung gestellt worden. Die Teilnehmer der Testklausur hatten an jeweils einer dieser Klausuren teilgenommen; ihr jeweiliges Abschneiden war bekannt, so dass die Ergebnisse verglichen werden konnten. Abbildung 1 zeigt, dass die Teilnehmer in der Testklausur durchweg schlechter abgeschnitten haben als in ihrer ursprünglichen Klausur, was sicherlich auf die fehlende Vorbereitung zurückgeführt werden kann. Auch die Notenverteilung fiel in der Testklausur schlechter aus, der Durchschnitt der Teilnehmer lag in der Testklausur mit 2,8 deutlich schlechter als mit 2,2 in der Original-Klausur. 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Original-Klausur Testklausur Abb. 1: Abschneiden der Teilnehmer im Vergleich Diese Zahlen sollen hier allerdings nur der Vollständigkeit halber genannt werden, da das Augenmerk auf der Arbeit am Rechner lag und darauf, wie die Studierenden in einer Prüfungssituation damit umgehen. Die verschiedenen Möglichkeiten der eingesetzten Entwicklungsumgebung Eclipse waren den Studierenden im Rahmen von Laborstunden am Rechner demonstriert worden. 105

3 Es galt jedoch in allen Fällen, dass diese Möglichkeiten nicht genutzt werden mussten! Wie bereits bemerkt, wurden die gestellten Aufgaben aus existierenden Klausuren entnommen und nicht etwa auf Eclipse abgestimmt. 3.1 Besonderheiten der Bearbeitung Die folgenden Abschnitte beschreiben einige Besonderheiten, die uns auffielen: Fehlererkennung und -vermeidung Eclipse zeigt im Editorfenster Fehler, aber auch Warnungen präzise an und bietet an manchen Stellen sogar Vorschläge für eine automatische Korrektur. In den bearbeiteten Aufgabenteilen fanden sich dennoch in fünf Lösungen (teils massive) Übersetzungsfehler sowie fünf Warnungen in formal korrekten Programmen, von denen zwei zu ernsthaften Laufzeitproblemen geführt hätten. In mehreren dieser Fälle hätte die von Eclipse angebotene automatische Korrektur zu einer korrekten Lösung geführt, wurde aber nicht genutzt. Modifikation der Aufgabenstellung An insgesamt sechs Stellen nahmen Studierende Modifikationen am vorgegebenen Programmcode vor, damit ihre Ergänzungen keine Fehler mehr aufweisen sollten; sie lösten also Aufgaben, die so nicht gestellt worden waren. Wir vermuten, dass den Studierenden die Probleme im Falle einer konventionellen Klausurbearbeitung auf Papier gar nicht erst bewusst geworden wären. Test der entwickelten Programme Einer der Hauptvorteile, eine Klausur, in der programmiert werden muss, am Rechner zu lösen, besteht sicher darin, dass man die erstellten Programme unmittelbar ausführen und testen kann. Bei drei von sieben Aufgaben war bereits ein Hauptprogramm vorgegeben, das zu Testzwecken ausgeführt werden konnte. Um so erstaunlicher ist die Tatsache, dass nur drei der Studenten für insgesamt vier Aufgabenteile, einen eigenen Testcode entwickelten. Dabei hätte es sich einige Male angeboten, das zu tun, wie bei der in Abbildung 2 dargestellten Teilaufgabe: Eine einfache Schleife, welche die beiden test -Methoden mit den gleichen Werten aufruft, könnte sogar zum Probieren statt zum systematischen Programmieren verleiten. Aber nur einer der Teilnehmer hatte hier überhaupt eine Testroutine vorgesehen, welche die Eingabe von zu testenden Werten erlaubte. Andererseits erreichten die Teilnehmer bei dieser Aufgabe im Schnitt nur vier von neun möglichen Punkten, weil die Lösungen fehlerhaft waren. Abb. 2: Teil einer Aufgabe mit guten Testmöglichkeiten 106

4 Codegenerierung Eclipse bietet viele Möglichkeiten, um den Entwickler von Routineaufgaben zu entlasten. Dazu gehören unter anderem verschiedene Formulare zum Anlegen von Klassen, aber auch zum Generieren von Konstruktoren und Methoden. Eine der Aufgaben bot ideale Voraussetzungen, um diese Möglichkeiten einzusetzen: Es war eine Klasse mit mehreren Unterklassen inklusive ihrer Konstruktoren und einer überladenen Methode zu erstellen. Abbildung 3 illustriert das Eclipse-Formular zum Generieren eines Konstruktors und den daraus auf Knopfdruck generierten Code. Auch diese Möglichkeiten wurden von den Studierenden nur wenig genutzt: Drei der Teilnehmer ließen Konstruktoren, einer auch die geforderte Methode generieren, die anderen erstellten den gesamten Code erkennbar manuell. Abb. 3: Codegenerierung in Eclipse 3.2 Interpretation der Erfahrungen Aus Sicht der meisten Studierenden ist die Bearbeitung einer Klausur mit programmiertechnischen Inhalten am Rechner eine gute Sache (vgl. auch Abschnitt 4). Es ist daher erstaunlich, wie wenig die Möglichkeiten der vorhandenen Entwicklungsumgebung tatsächlich genutzt wurden. Indem diese Möglichkeiten die Entwickler vor allem bei Routineaufgaben unterstützen und entlasten sollen, bedeutet eine Nicht-Nutzung einen Produktivitätsverlust mit dem Risiko, dass sich Flüchtigkeitsfehler einschleichen und zu einer schlechten Gesamtqualität führen. Gleichzeitig wird die Aufmerksamkeit von wirklich wichtigen und schwierigen Aufgaben abgelenkt. Solche Effekte müssen unter allen Umständen bereits früh in der Ausbildung thematisiert und unterbunden werden, um die berufliche Qualität der angehenden Informatiker entscheidend zu verbessern! Wir sind der Meinung, dass Klausuren durchaus ein geeignetes Mittel darstellen, um diesen Aspekten Gewicht zu geben. Selbstverständlich darf die Beschäftigung mit einer Entwicklungsumgebung nicht zum Selbstzweck verkommen, und selbstverständlich müssen als Gegengewicht auch konzeptionelle Themen (mit und ohne Rechner) geübt werden. Es ist aber wichtig, den Rechner als Werkzeug (und nicht als Spielzeug) anzusehen, das man beherrschen und dessen Möglichkeiten man nutzen sollte. 4. Meinungen der Studierenden Das Experiment wurde den Studierenden in der entsprechenden Informatik- Vorlesung vorgestellt und durch eine kleine Webseite [2] begleitet. Auf dieser Webseite wurde auch eine Umfrage durchgeführt: 107

5 Die Frage lautete: Sind praktische Anteile in Klausuren sinnvoll? Insgesamt wurden 28 Stimmen abgegeben, wovon 17 (entsprechen 60,7%) mit Ja, damit wird die Prüfung praxisnäher, acht (entsprechen 28,6%) mit Nein, damit wird alles nur umständlicher und drei (entsprechen 10,7%) mit Weiß nicht stimmten. Insgesamt wurde die Webseite des Projekts innerhalb eines Monats mehr als 350 mal abgerufen. Jeder Testklausur war ein Meinungsbogen beigefügt, der außerhalb der Zeitbegrenzung ausgefüllt werden sollte. Viele Studenten empfanden den Stoff als zu viel bei der entsprechenden Zeitvorgabe, andere sahen die Gefahr, dass man noch eher bei einer Aufgabe hängen bleibt, bis sie endlich läuft. Der Einsatz von Computern für Klausuren fand breiten Zuspruch. Da die Aufgabenstellungen in elektronischer Form vorlagen, konnte durch Kopieren über die Zwischenablage deutlich Zeit gespart werden. Hierdurch wurde die Fähigkeit des schnellen Tippens nicht überbewertet. Die Unterstützung durch die integrierte Entwicklungsumgebung und die Verfügbarkeit der Online-Hilfe wurde durchweg positiv bewertet. 5. Zusammenfassung und Ausblick Die Durchführbarkeit von computerunterstützten Klausuren konnte anhand der Testklausur gezeigt werden. Auch war die Akzeptanz des Modells sehr groß. Das Experiment hat wertvolle Erfahrungen geliefert und kann so empfehlenswerte Hilfestellungen für den späteren Regelfall liefern. Die Einführung von begleitenden computerunterstützten Klausuren im Bereich der praktischen Informatik darf somit als empfehlenswert angesehen werden. Nicht verschwiegen werden dürfen aber die noch offenen Punkte: Die Rechner müssen bei identischer Software-Ausstattung absolut stabil laufen, und diverse Kommunikationsmöglichkeiten müssen sicher abgeschottet sein. Fehler in den Aufgabenstellungen haben (nicht zuletzt im Hinblick auf eine Durchführung von webbasierten Wissensprüfungen) schnell katastrophale Folgen. Der Dozent hat so eine wesentlich höhere Sorgfaltspflicht bei der Konzeption seiner Prüfungsleistungen. [1] Eclipse SDK, Informationen und Download unter [2] Webseite zur Testklausur: Autoren Prof. Dr. Sven Klaus Prof. Dr. Peter Knauber Fachhochschule Mannheim Hochschule für Technik und Gestaltung {s.klaus, 108