H o c h s c h u l e    M ü n c h e n

Evaluierung von Lehrveranstaltungen
von Prof. Jürgen Plate

Hintergrundinformation

Aufgabe war die Entwicklung eines Systems für die Evaluierung der Lehre. Der bisher existierende Papier-Fragebogen soll in ein Web-Formular umgesetzt werden, das dann per CGI-Skript ausgewertet wird. Das Formular zeigt einen ersten Entwurf und ist recht schnell erstellt. Man sollte annehmen, daß ein CGI-Skript zum aufsummieren der einzelnen Items auch relativ einfach zu programmieren ist - also insgesamt keine besondere Herausforderung.

Einige Randbedingungen machen die Sache jedoch komplexer. Es sollen ja nicht Hinz und Kunz eine Lehrveranstaltung bewerten, sondern die Studenten, die daran teilgenommen haben. Also muß ein Autorisierungssystem hinzugefügt werden. Das hätten wir ja bereits, beispielsweise in Form von Username und Passwort für den Hochschul-Internetzugang oder auch mit den Praktikums-Accounts. Jedoch ist damit die Bewertung der Lehrveranstaltung nicht mehr anonym - und das sollte sie sein. Um einen Lösungsweg für dieses Problem zu finden, greifen wir auf einen Artikel von Lincoln D. Stein aus dem Perl-Journal zurück, der seinerseits auf einer Veröffentlichung von Kryptologie-Papst Bruce Schneier beruht. In diesem Artikel geht es um die Realisierung eines sicheren Internet-Wahlverfahrens:


About Secure Elections

The guiding principles of a secure election are to maintain privacy and prevent cheating. Schneier lays out six minimal requirements for a good election protocol:
  1. Only authorized voters can vote.
  2. No one can vote more than once.
  3. No one can determine for whom anyone else voted.
  4. No one can duplicate anyone else's vote.
  5. No one can change anyone else's vote without being discovered.
  6. Every voter can verify that his vote has been taken into account in the final tabulation.

Conventional paper ballots satisfy requirement 1 by voter registration, a process that ensures that only American citizens of a certain age can vote. Requirements 2 and 4 are satisfied by crossing the registered voter's name off a list when the voter enters the polling location, and 3 is satisfied by using an anonymous ballot. The last two requirements, however, are not completely satisfied by paper ballots too.
Schneier's book describes several cryptographic protocols which meet these six requirements for secure elections. Some of them are quite elaborate and require new software at the voter's side of the connection. Here we will use one of the simpler ones that happens to be well suited for web-based voting.
This protocol requires two independent central facilities to work, called the CEA and the CLA. The CEA is the Central Enumeration Agency. It is responsible for collecting and tallying ballots, and publishing the results on election night. The CLA is the Central Legitimization Agency. It is responsible for registering and credentialing voters.

  1. Before the election, the CLA supervises voter registration. Each registered voter is issued a Voter Registration Number (VRN), which is simply a large random number. VRNs are issued electronically, for example, by email or floppy as shown below.
  2. The CLA maintains a list of all VRNs, and a list of who VRNs were issued to, in order to prevent someone from registering twice. There is no record of who a particular VRN was issued to.
  3. Prior to election day, the CLA sends the CEA the list of VRNs.
  4. On election day, the voter sends in an electronic ballot that contains his choices for elected office. The ballot contains his VRN from step 1.
  5. The CEA checks that the VRN is valid, and crosses it off the list in order to prevent someone from voting twice.
  6. The CEA generates a large random confirmation number (CN) for the voter, and uses it to enter the voter's choices into the vote tally.
  7. The CEA returns the CN to the voter.
  8. After all votes have been received, the CEA publishes the outcome, along with the lists of CNs and for whom their owners voted.

The voter registration number

 
Dear Registered Voter,
 
Attached is your voter registration number. PLEASE KEEP A COPY OF THIS E-MAIL; 
YOU WILL NEED IT IN ORDER TO VOTE. DO NOT BEND, FOLD OR SPINDLE.



REGISTRATION-START--
8334290304185989711211356
0784480602526249967749323
7190985476311629502773466
9927297350189474428770582
--REGISTRATION-END--

The privacy of the ballot is ensured by the separation of the CLA and the CEA. One facility knows the identity of the voters, but not who they voted for. The other has access to their vote, but not their identity.
This protocol discourages election fraud in a number of ways. If a registered voter tries to vote twice, he will be caught in step 5. We can discourage non-registered voters from trying to guess valid VRNs by using large random numbers (in this example, we use 100-digit numbers). If the CEA itself tries to cheat by stuffing the ballot box or "losing" ballots, this can be detected in step 8. By publishing a list of CNs and their votes, the protocol allows voters to check the list to make sure that their votes were tallied correctly.

There are still ways to defraud this protocol. For example, the CEA and CLA can collude to figure out the identity of a voter; if voting is being done over the web, the CEA can use the voter's IP address to figure out who he is. The first of these problems can be addressed by election auditors and statutory law. The second can be addressed using proxy servers or by having the balloting take place in central polling places equipped with ATM-like web browsers. It is also important to note that the protocol described here is a slight departure from the one described by Schneier. The original protocol is built along an email model, in which the voter himself generates the CN, rather than letting the CEA do it for him...


Für das aktuelle Projekt wird auf die Bestätigung der Wahl an den Wähler verzichtet (wir wollen's ja nicht übertreiben) - also auf die letzten beiden der vorgenannten Punkte. Es geht darum,

  1. Zufalls-Schlüssel an die Studenten zu verteilen,
  2. die Formulardaten entgegenzunehmen,
  3. den entsprechenden Schlüssel zu entwerten,
  4. und das Ergebnis zu aktualisieren.
Nach Ablauf der Bewertungsperiode werden alle Schlüssel ungültig und das Ergebnis visualisiert.

Zur Lösung können die oben geschilderten Prinzipien angewendet werden.

Gesamtkonzept des Abstimmungsverfahrens

Das System Tallyman besteht grundsätzlich aus drei Teilen:

 • Erzeugung von Registrierungsnummern (RN)
 • Abstimmung und Sammeln der Ergebnisse
 • Anzeige der Ergebnisse

Es versteht sich von selbst, daß die Teile I und III nur von der jeweils berechtigten Person aufgerufen werden dürfen.

I. Erzeugung von Registrierungsnummern (RN)

Um einen Block von Zufalls-Schlüsseln zu erzeugen, dient das erste Programm. Um zu verhindern, daß jeder eine Satz von "Wahlscheinen" erzeugen kann, wird ein Passwort abgefragt, das nur den Lehrpersonen bekannt ist. Des weiteren gibt man an, wieviele Schlüssel gebraucht werden. Die Schlüssel-Länge ist auf 10 oder mehr Ziffern festgelegt. Lehrperson und Fach sind gleich bei der Erzeugung der Registrierungsnummer mit dieser verknüpft - jedoch nur als Nummern. Der Name der Lehrperson wird nirgends gespeichert.

Ausserdem wird zusammen mit beliebig vielen RN auch eine eindeutige ID erzeugen, die dem Abrufen der Ergebnisse dient. In einer Datenbank werden die RN gespeichert, um später die Wahlberechtigung überprüfen zu können. Nach der Wahl verfällt der jeweilige Datensatz; jeder Studierende kann also nur einmal abstimmen.

Die Lehrpersonen-ID wird auf die gleiche Weise erzeugt, jedoch in einer zweiten Datei gespeichert. Auf diese Weise kann man sicherstellen, daß nur die berechtigte Lehrperson die Ergebnisse abrufen kann und nicht ein Kollege oder gar ein Student.

Als Interface dient ein Formular, das die Auswahl von Lehrperson und Fach sowie die Eingabe der gewünschten Anzahl der zu generierenden RN erlaubt. Das Skript zu diesem Formular gibt die Lehrpersonen-ID und entsprechende Anzahl von RN-"Schnipseln" als HTML-Antwort aus. Die kann dann entweder zur weiteren Verarbeitung abgespeichert oder ausgedruckt und zerschnitten werden.

II. Abstimmung und Sammeln der Ergebnisse

Im Abstimmungs-Programm genügt nun die Eingabe der RN. Danach generiert das Programm ein Abstimmformular, in dem die fixen Angaben (Lehrperson, Fach, Studiengruppe) bereits aufgeführt sind. So kann die/der Abstimmende gleich überprüfen, zu welchem Fach sie/er abstimmt. Die Abstimmungsergebnisse werden wieder in einer Datenbank festgehalten.

III. Anzeige der Ergebnisse

Das Programm zur Ergebnisanfrage präsentiert zuerst ein Formular für die Eingabe der Lehrpersonen-ID. Mit dieser ID werden Lehrpersonen-ID, Lehrfach und Studiengruppe ermittelt und die entsprechenden Sätze der Datenbank extrahiert. Nun wird für jede Frage die Häufigkeit der Antworten ermittelt und ansprechend formatiert als Histogramm dargestellt. Die Kommentare der letzten drei Fragen werden gesammelt und in einer eigenen Seite als Aufzählung ausgegeben.

Die folgenden Dateien bilden das Evaluationssystem:

"tallykey.cgi" liest die variablen Daten aus der Datenbank-Tabelle mit den Verwaltungsinfos: Professorenliste und Fächerliste sowie das Passwort zum Erstellen der Wahlzettel.

Das Masterpasswort des Studiendekans wird von "tallylog.cgi", "tallyall.cgi" und "tallyadmin.cgi" abgefragt.

Schlussbemerkungen

Eine vollständige Anonymisierung ist bei dieser aktuellen Anwendung gegenüber einer elektronischen Wahl nicht möglich, denn manche Fächer werden nur von einem oder zwei Kollegen vertreten. Hier wäre beim Zugriff auf die Dateien mit den Rohdaten ein Rückschluß auf die Kollegen möglich (wohlgemerkt: die Rohdaten, die von außen nicht zugänglich sind). Hier muß dem Rechner-Administrator einfach ein gewisses Vertrauen entgegengebracht werden - was letztendlich auch bei einer Wahl für die Wahlhelfer zutrifft.

Bei der Akkreditierung für den Bachelorstudiengang Elektrotechnik und Informationstechnik sowie für den Masterstudiengang Electrical Engineering wurde eine anonymisierte Evaluierung explizit gefordert, zur Auswahl stehen das Ausfüllen der Papier-Fragebögen und Abgabe derselben bei der Studiendekanin (nicht bei der entsprechenden Lehrperson) oder ein elektronisches Verfahren wie dieses hier.

Die Programme wurden nach einem ersten Probelauf noch leicht modifiziert. Neben "kosmetischen" Änderungen wurde ein Problem in der Ausgabe behoben: Da manche Browser die als Histogramm-Balken zweckentfremdeten HTML-Tabellen nicht gedruckt haben, wenn die Option "Hintergrund auch drucken" im Browser abgeschaltet war, arbeitet die jetzige Produktions-Version mit einer Grafikausgabe. Eine schmale Grafik (GIF-Bild) wird jeweils passend "gedehnt".

Damit das System auch von anderen Fakultäten genutzt werden kann, wurde es recht bald entsprechend erweitert. Beim Generieren der Wahlzettel wird nun zuerst die Fakultäten ausgewählt. Diese Information sorgt dann für die Bereitstellung der passenden Dozenten- und Fächerlisten. Ebenso hat jede Fakultät und jeder Studiendekan ein eigenes Passwort.

Wegen des regen Zuspruchs wurde 2012 das ursprünglich zugrunde liegende Flatfile-System zur Datenspeicherung durch eine MySQL-Datenbank ersetzt. Die Datenbank besteht aus folgenden Tabellen:

  1. Liste der Dozenten, die Wahlabschnitte erstellt haben. 'profid' erlaubt das Abrufen der Ergebnisse und damit das Zuordnen der Evaluationen zu einer bestimmten Dozenten-Fach-Kombination.
    CREATE TABLE `dozenten` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fakultaet` int(11),
      `semester` varchar(10) NOT NULL DEFAULT '',
      `profid` varchar(20) NOT NULL DEFAULT '',
      `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '',
      `studiengruppe` varchar (20) NOT NULL DEFAULT '',
      `datum` timestamp,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=latin1;
    
  2. Liste der Studierenden-Abschnitte zum Feststellen der Abstimmberechtigung ('key'). Bei der Abstimmung wird 'evaluiert' aus 1 gesetzt, wodurch nur einmal abgestimmt werden kann.
    CREATE TABLE `waehler` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fakultaet` int(11),
      `semester` varchar(10) NOT NULL DEFAULT '',
      `key` varchar(20) NOT NULL DEFAULT '',
      `profid` varchar(20) NOT NULL DEFAULT '',
      `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '',
      `studiengruppe` varchar (20) NOT NULL DEFAULT '',
      `evaluiert` char(1) NOT NULL DEFAULT '0',
      `datum` timestamp,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=latin1;
    
  3. Protokoll-Tabelle für den Studiendekan. Gleichzeitig "Fallback" für Dozenten, die ihren Abruf-Id vergessen haben.
    CREATE TABLE `log` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fakultaet` int(11),
      `semester` varchar(10) NOT NULL DEFAULT '',
      `lehrperson` varchar(30) NOT NULL DEFAULT '',
      `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '',
      `studiengruppe` varchar (20) NOT NULL DEFAULT '',
      `profid` varchar(20) NOT NULL DEFAULT '',
      `datum` timestamp,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=latin1;
    
  4. Diese Tabelle enthält alle Evaluierungsdaten. Die Zuordnung zu Dozenten/Fächern erfolgt über 'profid'. in 'info' sind die Antworten zu einem Fragebogen gespeichert.
    CREATE TABLE `tally` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `fakultaet` int(11),
      `semester` varchar(10) NOT NULL DEFAULT '',
      `profid` varchar(20) NOT NULL DEFAULT '',
      `lehrveranstaltung` varchar(100) NOT NULL DEFAULT '',
      `studiengruppe` varchar (20) NOT NULL DEFAULT '',
      `info` text NOT NULL DEFAULT '',
      `datum` timestamp,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=latin1;
    
  5. Diese Tabelle enthält alle Verwaltungsinfo: Professorenliste und Fächerliste sowie das Passwort zum Erstellen der Wahlzettel und das Passwort des Studiendekans zum Abrufen der Gesamtstatistik. Das Passwort bei Fakultät "00" erlaubt das selektive Löschen älterer Daten.
    CREATE TABLE `admin` (
      `id` int(20) unsigned NOT NULL AUTO_INCREMENT,
      `fakultaet` varchar(10) NOT NULL,
      `evalpw` varchar(20) NOT NULL,
      `masterpw` varchar(20) NOT NULL,
      `Dozenten` text NOT NULL,
      `Faecher` text NOT NULL,
      `datum` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=latin1;
    

Weiterhin muss ein neuer User in der Datenbank eingetragen werden, der den Namen 'eva-user' trägt. Dies kann beispielsweise mittels eines SQL-Befehls erfolgen:

INSERT INTO `user` (`Host`, `User`, `Password`, `Select_priv`, `Insert_priv`, 
`Update_priv`, `Delete_priv`, `Create_priv`, `Drop_priv`, `Reload_priv`, 
`Shutdown_priv`, `Process_priv`, `File_priv`, `Grant_priv`, `References_priv`, 
`Index_priv`, `Alter_priv`, `Show_db_priv`, `Super_priv`, `Create_tmp_table_priv`, 
`Lock_tables_priv`, `Execute_priv`, `Repl_slave_priv`, `Repl_client_priv`, 
`Create_view_priv`, `Show_view_priv`, `Create_routine_priv`, `Alter_routine_priv`, 
`Create_user_priv`, `Event_priv`, `Trigger_priv`, `ssl_type`, `ssl_cipher`, 
`x509_issuer`, `x509_subject`, `max_questions`, `max_updates`, `max_connections`, 
`max_user_connections`) VALUES
('localhost', 'eva-user', '', 'Y', 'Y', 'Y', 'N', 'N', 'N', 'N', 'N', 'N', 'N',
 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N',
 'N', 'N', '', '', '', '', 0, 0, 0, 0);
UPDATE `user` SET `Password`=PASSWORD('irgendeinpasswort');
FLUSH PRIVILEGES;

Der Username und das Passwort werden dann im Modul "Tallyman.pm" eingetragen. In diesem Perl-Modul sind auch alle gemeinsamen Daten und Funktionen für die Programme zusammengefaßt. Das betrifft auch die Definition des Fragebogens. Diese besteht aus drei Arrays, wobei das erste die Fragetexte enthält, z. B.:

our @DefA = (
   "Konzept der Lehrveranstaltung",                                # 1
   "Fachliches Niveau",                                            # 2
   "Vermittlung des Lehrstoffes durch den/die Hochschullehrer/in", # 3
   "Hilfsmittel zur Lehrveranstaltung",                            # 4
      ...
   );
Das zweite Array ist ein "Array of Hashes", das für jede Frage alle Auswahlmöglichkeiten auflistet, und zwar die Codierung innerhalb der Datenbank. Normalerweise ist '1' die beste Antwort und '5' die schlechteste. Für "k. A." wird die Null verwendet. Bei Fragen mit nur drei Antwortmöglichkeiten werden '2', '3' und '4' verwendet. Ein 'A' kennzeichnet Fragen mit freier Antwort.
our @DefF = (
          {'1' => 0,  # ++
           '2' => 0,  # +
           '3' => 0,  # o
           '4' => 0,  # -
           '5' => 0,  # --
           '0' => 0}, # keine Antwort
          {'1' => 0,  # viel zu hoch
           '2' => 0,  # zu hoch
           '3' => 0,  # angemessen
           '4' => 0,  # zu niedrig
           '5' => 0,  # viel zu niedrig
           '0' => 0}, # keine Antwort
          {'1' => 0,  # ++
           '2' => 0,  # +
           '3' => 0,  # o
           '4' => 0,  # -
           '5' => 0,  # --
           '0' => 0}, # keine Antwort
          {'1' => 0,  # ++
           '2' => 0,  # +
           '3' => 0,  # o
           '4' => 0,  # -
           '5' => 0,  # --
           '0' => 0}, # keine Antwort
              ...

          {'A' => ''},  # Kommentar
          {'A' => ''},  # Kommentar
          {'A' => ''},  # Kommentar
         );
Das dritte Array ist genauso wie das vorhergehende aufgebaut. Auch hier gibt es für jede Frage einen Hash, nur dass diesmal die Texte der Untertitel im Fragebogen bzw. im Balkendiagramm der Auswertung zu den o. a. "Noten" angegeben werden:
our @DefFC = (
          {'1' => '+ +',
           '2' => '+',
           '3' => 'o',
           '4' => '-',
           '5' => '- -',
           '0' => 'keine Antwort'},
          {'1' => 'viel zu hoch',
           '2' => 'zu hoch',
           '3' => 'angemessen',
           '4' => 'zu niedrig',
           '5' => 'viel zu niedrig',
           '0' => 'keine Antwort'},
          {'1' => '+ +',
           '2' => '+',
           '3' => 'o',
           '4' => '-',
           '5' => '- -',
           '0' => 'keine Antwort'},
          {'1' => '+ +',
           '2' => '+',
           '3' => 'o',
           '4' => '-',
           '5' => '- -',
           '0' => 'keine Antwort'},
              ...
      );
Für die Fragen mit freier Antwort ist hier kein Arrayelement vorhanden, da diese Fragen am Schluss kommen.

Das komplette Programmpaket (Stand März 2013) kann HIER herunter geladen werden.