|
|
|
Evaluation "Betriebssystem-Entwicklung mit Literate Programming", WS 2014/15
Auswertung der Zwischenevaluation vom 25.11.2014
Spalten 1-5, N: Prozentangaben.
Wo nicht gekennzeichnet, haben die Noten 1-5 die folgenden Bedeutungen:
- Aussagen: 1: Diese Aussage stimmt absolut, 3 ist neutral, 5: Diese Aussage stimmt überhaupt nicht;
2 und 4: Zwischentöne
- Bewertungen: 1 = sehr gut, 2 = gut, 3 = befriedigend, 4 = ausreichend, 5 = ungenügend
- Spalte "N/W": nicht anwendbar bzw. weiß nicht
Durchschnittsbildung bei Fragen 22-24 nicht sinnvoll (Optimalwert: 3, kleinere und größere
Werte sind schlechter)
28. Was gefällt Ihnen an der Veranstaltung besonders gut?
- 2x Dozent kennt sich mit dem Thema sehr gut aus / Dozent hat Ahnung davon, was er tut
- 2x Tiefe und praktische Einblicke in den BS-Aufbau und -Funktionsweise / Man erhält tiefen Einblick in OS-Entwicklung
- Dozent ist sehr engagiert
- Veranstaltungen haben immer gleichen Aufbau: Buch lesen, Vorlesung, Übung
- Veranstaltung ist sehr praxisorientiert (neben Konzepten werden Implementierungen gezeigt)
- Dozent gibt häufig und schnell Feedback, z. B. via E-Mail
- In den Übungen ist alles sehr ausführlich beschrieben
- Interessant, Literate Programming kennen zu lernen
- Bereitstellung der VM sehr sinnvoll
- Gut nummerierte Folien und Aufgabenblätter
- Prüfung als Projekt
- Lernen von LaTeX
- Gut, dass die Übungen (nicht Projekt) nicht vom Code aufeinander aufbauen, sondern immer ein "frischer Code" bereitgestellt wird
- Video-Aufnahmen super Idee (auch wenn ich sie selber noch nicht gebraucht habe)
- transparentes Bewertungsschema
- Ich persönlich weiß nun, was ich in Zukunft nicht beruflich machen möchte (dieses Uralt-Literate-Programming und OS-Entwicklung)
29. Was finden Sie an der Veranstaltung besonders schlecht? / Was könnte der Dozent besser machen?
- 2x Im Quellcode ist das Nutzen von Abkürzungen (Variablen-, Methodennamen), z. B. KMAPD, sehr schwer zu verstehen. Man muss häufig zurück blättern. Besser: sprechendere Namen wählen / Zu viele Abkürzungen (auch im Code), die permanent mentales Mapping erfordern
- Für Konzepte/Abläufe zu Beginn der Veranstaltung eine Grafik oder ein Ablaufdiagramm bereitstellen, um die oft ähnlichen und/oder komplexen Abläufe besser nachvollziehen zu können
- 40+ Seiten als Vorbereitung sind für eine Stunde deutlich zu umfangreich, evtl. muss man ja zusätzlich noch an der Übung weiterarbeiten. Für mich ist der Zeitaufwand hierfür zu hoch
- Im Gegensatz zu Systemprogrammierung (dort war Umfang viel, aber absolut schaffbar) finde ich den Umfang zu groß
- Keine geeigneten Tools für Literate Programming. Arbeiten im Text-Editor ist mühsam
- Den kompletten Code in nur einer Datei zu halten, schränkt meiner Meinung nach die Lesbarkeit stark ein. Dies ist zwar den verwendeten Tools geschuldet, das ändert an der Validität des Arguments aber nichts
(Statistische Basis: 8 Fragebögen)
|
