Die Informatik-Curricula an Hochschulen und Universitäten sehen neben Softwaretechnik-Vorlesungen häufig auch praktische Projekte vor, in denen Studierende die Herausforderungen bei der Erstellung eines nicht-trivialen Softwaresystems in einem Team erfahren sollen. Spätestens seit der Bologna-Reform sind auch solche praktischen Studienleistungen zu benoten, was eine nicht unerhebliche Herausforderung für die Betreuer darstellt, da hochkomplexe und entsprechend unterschiedliche Arbeitsergebnisse transparent und nachvollziehbar bewertet werden müssen. Im vorliegenden Beitrag wird aus Kolloquien, einem Programmiertestat und der direkten Bewertung eingereichter Artefakte ein transparentes und verhältnismäßig einfach anwendbares System zur Bewertung von Softwareentwicklungsprojekten an Hochschulen und Universitäten entwickelt und von seiner praktischen Erprobung an der Universität Mannheim berichtet.
Teambasierte Softwareentwicklungsprojekte sind
seit Jahren ein fester Bestandteil des Curriculums
von Informatikstudiengängen an vielen
Hochschulen. Der vorliegende Beitrag zielt primär auf
praktische Entwicklungsprojekte im Fach
Softwaretechnik (bzw. engl. Software Engineering) an
Hochschulen und Universitäten, kann aber, mit
entsprechenden Abwandlungen, auch für andere
Fachgebiete der Informatik von Nutzen sein. Aus
technischer Sicht geht es in entsprechenden
Lehrveranstaltungen hauptsächlich um das Erlernen von
strukturierten Entwurfs- und
Modellierungstechniken für Software sowie deren Umsetzung in
lauffähige und getestete Programme. Dazu notwendig ist
das Erlernen grundlegender Techniken, Methoden
und Werkzeuge zur Entwicklung komplexer
Softwaresystemen
Bekanntlich existiert für die Entwicklung von
Softwaresystemen in verschiedensten Domänen kein
allgemein gültiges Patentrezept („No Silver Bullet“,
vgl. Brooks, 1995), so dass erlernte Verfahren von
den Ausführenden immer mit Augenmaß an die
jeweiligen Umstände angepasst werden müssen
Eigene Erfahrungen des Autors, der im Verlauf seines Studiums zwei Mal selbst an einem entsprechenden Projekt teilgenommen und einmal als studentische Hilfskraft an der Betreuung mitgewirkt hat, waren ähnlicher Art: In den ersten beiden Fällen war das Zustandekommen der Note für die Teilnehmer vollkommen intransparent (sie setzte sich „irgendwie“ aus der Leistung im Projekt und dem Abschlusskolloquium zusammen); im letztgenannten Fall haben gar die studentischen Hilfskräfte eigene Maßstäbe zur Bewertung von Anforderungs- und Designdokumenten, die sich hauptsächlich auf die Zählung von offensichtlichen Fehlern beschränkten, entwickelt und eingesetzt. Ziel dieses Beitrags ist es daher, ein nachvollziehbares und dennoch einfach handhabbares Bewertungsverfahren für praktische Softwareentwicklungsprojekte, das eine individuelle und transparente Bewertung der Studierenden ermöglicht, vorzustellen und von Erfahrungen aus seiner praktischen Erprobung an der Universität Mannheim zu berichten. Dazu werden im folgenden Abschnitt zunächst wichtige didaktische und organisatorische Rahmenbedingungen vorgestellt, bevor in aller gebotenen Kürze einige benötigte Hintergründe der Softwaretechnik dargelegt werden. Danach werden gängige Bewertungsverfahren auf ihre Verwendbarkeit in einem SoftwaretechnikProjekt analysiert. In den darauf folgenden Kapiteln werden das in diesem Beitrag thematisierte Bewertungsverfahren im Detail vorgestellt und aus ersten Erprobungen gewonnene Erkenntnisse diskutiert. Ein Vergleich mit anderen in der Literatur veröffentlichten Verfahren und eine Zusammenfassung runden diesen Beitrag schließlich ab.
Um die wichtigsten Herausforderungen eines Softwaretechnik-Projekts aus verschiedenen Blickwinkeln zu beleuchten, sollen im Folgenden weiterführende Einblicke gegeben werden, die nochmals die Notwendigkeit eines an der Aufgabenstellung orientierten Bewertungssystems unterstreichen sowie wichtige Hintergründe näher erläutern. Anschließend werden zentrale Anforderungen an ein solches Bewertungssystem zusammengetragen.
Aus didaktischer Sicht springen zunächst die
hohen Anforderungen, die sich an die Studierenden
in einem Softwaretechnik-Projekt auf Grund der
zuvor formulierten Lern- und Kompetenzziele
ergeben, ins Auge. Beispielsweise Böttcher et al.
(2011) halten eine detailliertere Aufschlüsselung
dazu notwendiger Kompetenzanforderungen aus
den vier Bereichen Sach-, Methoden-, Selbst- und
Sozialkompetenzen bereit. Grundsätzlich bleibt
festzuhalten, dass die hohe Komplexität von
Softwareprojekten von den Teilnehmern ohne Zweifel
ein tiefgehendes Verständnis zahlreicher Abläufe
und Techniken verlangt und Prüfer damit
regelmäßig vor die Herausforderung stellt, etwas zu
prüfen, was sich nicht direkt lehren lässt
In der Softwaretechnik wurde (und wird) für eine
solche Lehrform traditionell häufig der Begriff
Praktikum verwendet, der damit allerdings nicht
korrekt eingesetzt ist. Ein Praktikum an einer
Hochschule oder Universität ist zwar ebenfalls eine
praktische Unterrichtsform, in dieser setzen sich
Studierende allerdings mit vorgegebenen und klar
umrissenen Aufgaben, die innerhalb weniger
Stunden zu bearbeiten sind, auseinander
Aus studentischer Sicht erfahren Softwareentwicklungsprojekte häufig eine komplett konträre Einschätzung. Zum einen gibt es die leistungsstarken „Vollblut-Informatiker“, die gerne, gut und viel programmieren und oft privat bereits eigene kleine Softwareprojekte vorangetrieben oder gar als Praktikant Industrieerfahrung gesammelt haben. Für diese ist ein solches Projekt nicht selten einer der Höhepunkte ihres Studiums, den sie mit großer Motivation und Begeisterung angehen und oft mit beeindruckenden Leistungen abschließen, gerade wenn die Aufgabenstellung eventuell in Kooperation mit einem Industriepartner erfolgt ist. Zum anderen gibt es aber – gerade in interdisziplinären Studiengängen wie der Wirtschaftsinformatik – auch viele Studierende, die Softwareentwicklung und insbesondere Programmieren nur als notwendiges Übel ansehen und daher entsprechende Projekte nur als eine mit einem hohem Zeitaufwand verbundene Pflichtübung betrachten.
Dies führt in der Lehrpraxis häufig dazu, dass
studentische Teams sehr unterschiedliche
Leistungsniveaus aufweisen und schwächere Studierende
sich sehr leicht „abgehängt“ fühlen, während die
stärkeren diese vor allem als Belastung
wahrnehmen
Die im Folgenden beschriebenen SoftwaretechnikLehrveranstaltungen an der Universität Mannheim waren nach einem verbreiteten Muster organisiert: ein Professor trug als Prüfer die Hauptverantwortung für die Veranstaltung und vermittelte in Vorlesungen die theoretischen Hintergründe. Wissenschaftliche Mitarbeiter übernahmen die Aufgabe den Studierenden den Lehrstoff an Hand von einzelnen Übungsaufgaben mit direktem Projektbezug auch praktisch näher zu bringen. Die wissenschaftlichen Mitarbeiter waren ferner für die Steuerung des eigentlichen Projekts ebenso zuständig wie für die Klärung von offenen Fragen (z.B. bzgl. der Anforderungen). Die direkte Betreuung der Entwicklungsteams oblag auf Grund der recht hohen Teilnehmerzahlen von anfangs teilweise deutlich über fünfzig Studierenden einer Reihe von studentischen Tutoren. Diese hatten in der Regel bei mindestens wöchentlichen Treffen der Teams direkten Kontakt mit den Studierenden und trafen sich ebenso regelmäßig mit den Mitarbeitern, um über die Fortschritte ihrer Teams zu berichten. Von anderen Universitäten sind ähnliche Konstellationen mit teilweise noch weit höheren Teilnehmerzahlen bekannt (z.B. Kehrer et al., 2005). An Hochschulen sind Kohorten hingegen oft um einiges kleiner, so dass dort auch Projekte möglich sind, in denen Professoren die Studierenden persönlich betreuen und sich einen direkten Eindruck über ihre Leistungen verschaffen können.
Eine weitere Schwierigkeit bei der Koordination und auch Bewertung von Projekten stellt die meist geringe Erfahrung der beteiligten Mitarbeiter und Tutoren dar. Bedingt durch die naturgemäß sehr hohe Fluktuation innerhalb dieser Personengruppen kommt es häufig vor, dass Mitarbeiter oder Tutoren, die eine entsprechende Veranstaltung noch vor wenigen Monaten selbst besucht haben, sich in einer betreuenden Rolle wieder finden, das Wissen aus vorangegangenen Durchläufen aber nicht schriftlich dokumentiert worden ist. Sobald neue Tutoren bzw. Mitarbeiter entsprechende Erfahrungen angesammelt haben, schließen sie ihr Studium oder ihre Promotion ab und wenden sich neuen Aufgaben zu. Dieser Erfahrungsverlust gilt natürlich auch für den Bereich der Bewertung studentischer Abgaben, so dass ein klar definiertes Bewertungsschema fraglos allen Lehrenden die Betreuung erleichtern und dadurch zu einer deutlichen Erhöhung der Lehrqualität führen kann.
An dieser Stelle soll zunächst kurz auf die
allgemeinen Güteanforderungen an Prüfungen
eingegangen werden. Die Literatur
Aus den oben diskutierten Hintergründen und Erfahrungen sowie den eben genannten Testgütekriterien ergeben sich folgende grundlegende Anforderungen an die Benotung einer praktischen Softwaretechnik-Veranstaltung, die weitestgehend auf ähnliche Veranstaltungen in anderen Teilgebieten der praktischen Informatik übertragbar sind: 1. Die Benotung muss sowohl für Lehrende als auch für Studierende nachvollziehbar sein und sollte unabhängig von der Person des Bewerters bzw. des Bewerteten zum gleichen Ergebnis kommen. Auf Grund des relativ großen Aufwands, den Studierende in entsprechende Veranstaltungen investieren, werden idealerweise auch die erstellten Artefakte (ggf. in mehreren Teilschritten) benotet; generell erfasst das Bewertungsschema die in den Lernzielen formulierten Fertigkeiten. 2. Gemäß der Bologna-Kriterien (KMK, 2010) muss die Benotung für jeden Studierenden individuell erfolgen, es kann daher bei Teamarbeiten nicht automatisch eine einheitliche Note für alle Teammitglieder vergeben werden. Ein geeignetes Bewertungsverfahren muss die Zuordnung individueller Leistungen erlauben, dabei aber gleichzeitig Teamarbeit zulassen und fördern bzw. im Idealfall sogar in der Note abbilden. Dabei sollte auf Grund entsprechender Erfahrungen die Möglichkeit bestehen, „Trittbrettfahrer“ frühzeitig zu erkennen, um die übrigen Mitglieder eines Teams vor einer Überlastung und deren negativen Folgen für die eigenen Noten zu schützen.
Zum besseren Verständnis des später erklärten Bewertungsschemas sollen im Folgenden in aller Kürze einige Aspekte der Softwaretechnik und daraus abgeleitete Lernziele hervorgehoben werden. Ein zentraler Punkt ist dabei die Definition einer Software selbst. Laut Brooks (1995) umfasst „Software“ nicht nur den ablauffähigen Programmcode, den ein Endbenutzer einsetzt, sondern auch die zu seiner Erstellung notwendigen Anforderungen, daraus abgeleitete Analyse- und Entwurfsmodelle sowie Testfälle und weitere Dokumentation (wie z.B. auch das Benutzerhandbuch). Es ist daher bereits in mittelgroßen Projekten notwendig, eine ganze Reihe von Mitarbeitern mit verschiedenen Rollen miteinander zu koordinieren, um ein System mit möglichst wenigen Reibungsverlusten entwickeln zu können.
Dazu stehen in der Softwaretechnik verschiedene
Vorgehensmodelle zur Verfügung
Dieses Kapitel geht auf kurz gängige Bewertungsverfahren an Schulen bzw. Hochschulen ein und diskutiert, ebenfalls in aller Kürze, mögliche positive und negative Aspekte bezüglich der Anwendbarkeit innerhalb von praktischen SoftwaretechnikLehrveranstaltungen. Dazu fasst die folgende Tabelle neben den Bewertungsverfahren auch die jeweils wichtigsten positiven und negativen Aspekte zusammen:
Prakt. Leistungs- Die Studierenden bearnachweise beiten vorgegebene (Übungsaufgaben) Übungsaufgaben Vorträge
Kleinere Aufgaben zu einer spez. Fragestellung mit meist überschaubarem Arbeitsaufwand
Meist kein unmittelbarer Bezug zum Projekt; erhöhte Gefahr des Abschreibens gleicher Aufgaben Die Studierenden präsentieren ihr Vorgehen oder
Stärkung der Präsentationskompetenz; Vertiefung
Evtl. überdeckt der Vortragsstil inhaltliche Stärken Kolloquien Bewertung Systems
des Mündliche Prüfung(en) (Testate) des Fachwissens im entspr. oder Schwächen; hoher Themenbereich; ggf. Selbst- Zeitaufwand; mögl. Speziareflektion durch Vergleich lisierung auf das Themenmit anderen Studierenden gebiet Nachhaken und Klären von Verständnisfragen möglich Direkter Bezug zum Lernziel und damit direktes Feedback zum Lernerfolg
Bei großen Gruppen entsprechend hoher Zeitaufwand Kriterienkatalog notwendig, hoher Zeitaufwand in der Bewertung, Zuordnung der Leistung nicht immer einfach Prüfungsgespräch mit Planbarer Zeitaufwand für Bewertung spiegelt nicht einem oder mehreren den Prüfer, etablierte Prü- unbedingt den Beitrag zum Studierenden fungsform, individuelle Projekt wieder, hoher ZeitBenotung und Nachfragen aufwand, verwendete Framöglich gen verbreiten sich schnell Prü- Die klassische Klausur
Bekanntes Verfahren, Leistung ist klar zuzuordnen und gut vergleichbar
Erfordert mitunter einen hohen Vorbereitungsaufwand; kein direkter Bezug zur Leistung im Projekt „Programmierklausur“, Gute Überprüfung der Ausreichend große Rechidealerweise mit einer Lernziele in Bezug auf Pro- nerräume müssen verfügEntwicklungsumgebung grammierkenntnisse, am bar sein; bei autom. Bewerdirekt am Rechner ausge- Rechner über Testfälle au- tung kein Bewertungsspielführt tomatisch und damit objek- raum, minimale Programtiv bewertbar mierfehler können große
Auswirkungen haben Studierende dokumentieren Aufgabenverteilung und Vorgehen regelmäßig
Erleichtert Nachvollzieh- Overhead für Studierende barkeit des Vorgehens und Betreuer; Benotung schwierig; Gefahr unreflektierter Aufzählungen groß Studierende reflektieren über ihre Erfahrungen
Bei korrekter Ausführung relativ hoher Lerneffekt
Weiterer Overhead für die Studierenden bei ohnehin schon starker Belastung; dedizierte Benotung ebenfalls schwierig Mitarbeit der Studierenden in ihrer Gruppe wird bewertet
Motiviert zu regelmäßiger Generell nur schwer objekMitarbeit, geringer Auf- tiv einschätzbar, insbesonwand dere bei Heimarbeit Benotung Studierenden tereinander Assessment) der Studierende geben sich un- gegenseitig Noten oder (Peer verteilen eine begrenzte
Anzahl von Punkten an ihre Teamkollegen
Geringer Aufwand für den Validität & Legalität sehr Betreuer; Studierende re- fraglich, mögl. negative flektieren und lernen durch Auswirkungen auf die Bewertung ihrer Kommili- Gruppendynamik tonen Alle aufgeführten Bewertungsansätze sind im Kontext eines Softwareprojekts sicherlich sinnvoll aneine Kombination verschiedener Verfahren erforderlich, um alle zuvor genannten Anforderungen an die Benotung abdecken zu können und dabei möglichst wenig Mehraufwand für Studierende und Betreuer zu generieren. So eignet sich beispielsweise die Bewertung der abgegebenen Systemartefakte allein sehr gut als Feedback über die im Projekt erbrachte Leistung, stößt aber an Grenzen, sobald diese in Heimarbeit erstellt werden können und sollte daher durch Präsenzverfahren (wie Kolloquien o.ä.) ergänzt werden. Bewertungsansätze mit hoher Eigenverantwortung (wie Reflektionen oder Lerntagebücher) erzielen bei entsprechend motivierten Studierenden meist gute Ergebnisse, sind jedoch in einem ohnehin stressigen Projekt offensichtlich mit zusätzlichem Mehraufwand verbunden und ferner in Zweifelsfällen nur schwer als nicht ausreichend zu benoten. Sie erfordern daher, wie die meisten anderen Verfahren, ein klares und idealerweise im Voraus kommuniziertes Bewertungsschema, was den Aufwand für die Betreuenden weiter erhöht, insbesondere, wenn die Zusammenstellung der Inhalte individuell gestaltbar ist.
Aus den zuvor angestellten Überlegungen lässt sich
das folgende Bewertungsschema ableiten, das sich
im Wesentlichen aus fünf einzelnen
Bewertungsverfahren zusammensetzt:
1. Einfache Übungsaufgaben mit direktem
Projektbezug
2. Ein praktisches Programmiertestat (gegen
vorgegebene Testfälle am Rechner)
3. Führen von Stundenzetteln („Timesheets“)
4. Bewertung der abgegebenen
Modellierungsartefakte, Quellcodes und Binaries
5. Mehrere Kolloquien
Der zeitliche Ablauf einer entsprechenden
organisierten Veranstaltung gestaltet sich
folgendermaßen: zeitnah zu Semesterbeginn werden den
Studierenden, grobe Anforderungen an das zu
erstellende System mitgeteilt und sie erhalten erste
Aufgaben bzgl. der Erfassung und Modellierung der
Anforderungen mit direktem Projektbezug. Diese
sind einzeln oder in Zweiergruppen zu bearbeiten
und abzugeben. Somit ist gewährleistet, dass jeder
Teilnehmer sich individuell einen grundlegenden
Überblick über die Anforderungen an das zu
erstellende System erarbeiten muss. Idealerweise werden
die Lösungen der Studierenden kontrolliert oder
zumindest in einem Tutorium besprochen, aber
nicht benotet. Gleichzeitig werden erste (einfache)
Programmieraufgaben gestellt, die auch dazu
dienen, die Studierenden mit der verwendeten
Entwicklungsumgebung
Nach etwa drei bis vier Wochen wird ein (ebenfalls
einfaches) Programmiertestat mit großzügig
bemessener Bearbeitungszeit als erster harter
Leistungsnachweis zum Einstieg in das Projekt
verlangt. Es bietet sich an, dieses als
Programmierübung direkt am Rechner (mit Eclipse und den
Javadocs, aber ohne Internet-Zugang)
durchzuführen und den Studierenden Interfaces und
JUnitTests vorzugeben, gegen die sie entwickeln müssen
(vgl. testgetriebene Entwicklung nach Beck, 1999).
Somit wird Beschwerden, dass Programmieren in
Papierklausuren weitaus schwieriger als in einer
Entwicklungsumgebung (mit „Code-Completion“)
sei, von vorne herein der Wind aus den Segeln
genommen. Gleichzeitig entfällt das äußerst
zeitaufwändige Bewerten von zumeist
unübersichtlichem Programmcode für die Betreuer, da nur das
automatisierbare Ausführen der JUnit-Tests
notwendig wird. Idealerweise werden mehrere in etwa
gleichschwere Teilaufgaben gestellt, so dass die
Programme der Studierenden nicht alle Testfälle
erfüllen müssen, sondern beispielsweise nur drei
aus fünf, o.ä. Auf Grund von in Praxis und
Literatur bekannten extremen Leistungsunterschieden
bei Softwareentwicklern
Die Ergebnisse dieses Testats können im Anschluss
zur Einteilung der eigentlichen Projektgruppen
genutzt werden. Es bietet sich an, die Studierenden
gemäß ihrer Leistungen (also z.B. der Zeit, die bis
zur Erfüllung der Testkriterien benötigt wurde)
zusammen zu gruppieren, um zu große
Leistungsgefälle innerhalb der Teams und eine daraus
resultierende Demotivation aller Teilnehmer zu
vermeiden
Nach erfolgter Einteilung der Projektteams sind diese gehalten, sich vertieft in die Projektanforderungen einzuarbeiten und diese entsprechend zu analysieren und zu dokumentieren (durch Use Cases, System-Sequenzdiagramme oder Operation Contracts). Um die abschließende Benotung zu erleichtern, sind alle abzugebenden Artefakte mit dem Namen des Bearbeiters zu versehen und unter dem eigenen Benutzernamen in das verwendete Versionskontrollsystem hochzuladen. Ferner sollten alle Aktivitäten wie das Erstellen von Dokumenten, Modellen oder Quellcode, aber auch Team-Meetings o.ä. in sogenannten Timesheets gelistet werden, ähnlich, wie es auch zu Abrechnungszwecken in Industrieprojekten praktiziert wird.
Nach etwa weiteren zwei Wochen wird ein erstes Kolloquium durchgeführt, um sicherzustellen, dass jedes Teammitglied zum Projektziel beiträgt und alle Anforderungen vollständig verstanden wurden. Um den Studierenden etwaige Berührungsängste zu nehmen, bietet es sich an, dieses Kolloquium nicht zu benoten, sondern nur eine rudimentäre Mindestleistung zum Bestehen zu verlangen, die ggf. in einem Folgegespräch nochmals nachgefordert werden kann. Der Autor hat gute Erfahrungen damit gemacht, bis zum Ende des Projekts noch zwei weitere, benotete Kolloquien durchzuführen, eines nach etwa zwei Dritteln der Dauer, eines in Form einer Systempräsentation bzw. -abnahme ganz am Ende des Projekts.
Die Benotung des Softwaresystems und der mitgelieferten Artefakte erfolgt auf Basis des im Folgenden vorgestellten Bewertungsrasters. Dabei sind fett gedruckte Elemente zwingend zum Bestehen erforderlich (d.h. eine nicht ausreichende Leistung in einem entsprechenden Bereich führt direkt zum Nicht-Bestehen des gesamten Projekts). Ohne Auszeichnung gedruckte Kategorien werden vom Team verantwortet und für das gesamte Team einheitlich benotet, für kursiv gedruckte ist jeder Teilnehmer individuell verantwortlich und bekommt eine eigene Bewertung. Eine entsprechende Kennzeichnung der Dokumente ist dafür wie bereits beschrieben obligatorisch.
Im Sinne der agilen Softwareentwicklung
2. Geschäftsprozessmodelle * 1 (bei Wirtschaftsinformatik-Bezug) Anforderungsmodellierung 3. Use Cases *5 4. Use Case Diagram *1 Analysemodelle 5. System-Sequenzdiagramme *3 6. Contracts der Systemoperationen *3 Entwurfsmodelle
8. Interaktionsdiagramme (GRASP und Design Patterns) *5
10. UI Storyboard *1 Spezifikationsdokument 11. Lesbarkeit und Aufbau *1 12. Konsistenz der enthaltenen Modelle *2 Source Code 13. Ausführbarkeit (lauffähiges JAR-File) *1 14. Korrektheit *2 15. Einhaltung von Coding Guidelines *2 16. Verwendung von Javadoc und Kommentierung *1 17. Konsistenz mit der Spezifikation *2 Testfälle
19. Überdeckung *4 Benutzerschnittstelle 20. Ergonomie/Bedienbarkeit *3 21. Reaktivität *1 Insgesamt besteht das vorgestellte Bewertungsschema aus zwanzig Einzelleistungen n1 bis n20, die alle auf einer vierstufigen Skala mit 0 bis 3 Punkten wie folgt bewertet werden: • 0 Punkte (und ungenügend) werden vergeben, wenn ein Element komplett fehlt oder grob fehlerhaft bzw. unvollständig ist • 1 Punkt gibt es für Kategorien, die sinnvolle Inhalte haben, die aber noch deutlich fehlerhaft bzw. lückenhaft sind • 2 Punkte gibt es für weitgehend vollständige und überwiegend korrekte Elemente • 3 Punkte werden für vollständige, korrekte und sehr sorgfältig erarbeitete Artefakte vergeben Der Multiplikator am Ende jeder Bewertungskategorie gibt die vorgesehene Gewichtung wi innerhalb des gesamten Rasters an, so dass eine Gesamtpunktzahl leicht nach folgender Formel berechnet werden kann:
20 g = ∑ ni ⋅ wi
i=1 In der vorgestellten Form werden teambasierte Bewertungsanteile 18-fach gewichtet, individuelle Bewertungsanteile 27-fach, so dass sowohl die Teamarbeit gefördert, als auch individuelle Anstrengungen berücksichtigt werden und somit die geforderte individuelle Benotung sichergestellt ist.
Da auch bei Verwendung des gerade vorgestellten
Bewertungsschemas Täuschungsversuche der
Studierenden durch Abschreiben erfahrungsgemäß
nicht ausgeschlossen werden können, empfiehlt es
sich, das Bestehen des Projekts bzw. seine
Gesamtnote nicht alleine von der Artefakt-Bewertung
abhängig zu machen. Die vom Autor eingesetzte
Kombination mit anderen bereits angesprochenen
und vorgestellten Bewertungsverfahren gestaltet
sich im Detail wie folgt:
• Übungsaufgaben mit direktem Projektbezug
(unbenotet, nur abzugeben)
• Programmiertestat am Rechner (unbenotet,
aber zu bestehen)
• 1. Kolloquium (unbenotet, nur zu bestehen)
• 2. Kolloquium (15% der Endnote)
• Abschlusspräsentation und -kolloquium
(25% der Endnote)
• Bewertung des Systems, wie oben gezeigt
(60% der Endnote)
• Stundenzettel (unbenotet, glaubhaft und
nachvollziehbar geführt abzugeben)
Durch dieses Bewertungsmodell wird
gewährleistet, dass jeder Teilnehmer zumindest über
grundlegende Programmierkenntnisse verfügt, die ihn in
die Lage versetzen, konstruktiv zur Arbeit seines
Teams beizutragen. Durch die Kolloquien wird
ferner das Verständnis der geleisteten Arbeit
überprüft und eine soziale Kontrollinstanz eingefügt,
wodurch letztlich mit großer Wahrscheinlichkeit
davon ausgegangen werden kann, dass die
abgelieferten und benoteten Artefakte auch von den
entsprechenden Studierenden erstellt worden sind.
Natürlich sollte auch die Bewertung Kolloquien auf
bekannten Richtlinien und Bewertungskriterien,
wie z.B. aus
Unter der Verantwortung des Autors wurde das vorgestellte, kombinierte Bewertungssystem in drei Softwaretechnik-Lehrveranstaltungen (zwei Mal in einer einsemestrigen Bachelorveranstaltung mit je ca. 50 Teilnehmern in Vierergruppen und einmal in einem zweisemestrigen Masterprojekt mit vier Teilnehmern) erfolgreich eingesetzt und aufbauend auf vorherigen Erfahrungen immer wieder leicht verändert. Insbesondere hat sich gezeigt, dass die Verwendung der vollen Notenskala (also 1,0; 1,3; … 4,0 bzw. 5,0) für die Systembewertung nicht zielführend ist, da die entsprechend feinen Unterschiede zwischen den Notenstufen zu zeitaufwändig in der Ermittlung und im Nachhinein praktisch nicht mehr nachvollziehbar sind. Dies gilt insbesondere wenn mehrere Prüfer in den Bewertungsprozess involviert sein sollten. Basierend auf der recht hohen Zahl von ca. 20 Einzelbewertungen hat es sich als ausreichend erwiesen, nur die zuvor genannten vier Bewertungsstufen zu verwenden. Bei deren Verwendung ergeben sich für obiges Raster mit seinen 45 Gewichtungsfaktoren maximal 135 erreichbare Punkte, die mit Hilfe gängiger (teilweise sogar in Prüfungsordnungen festgelegten) Prozentskalen problemlos in entsprechendeNoten umgerechnet werden können.
Ein berechtigter Einwand gegen das vorgeschlagene Bewertungsraster ist sicher sein hoher Detaillierungsgrad, der den Studierenden deutliche Hinweise auf die verlangte Lösung liefern kann (also z.B. welche Modelle werden erwartet?). Sofern die sinnvolle Wahl von Modellen (d.h. das „Tailoring“ der Vorgehensweise und die Auswahl der erstellten Artefakte) ein Lernziel der Veranstaltung darstellt, ist das Bewertungssystem in seiner vorgestellten Form sicherlich nicht anwendbar. Zu diesem Einwand gibt es allerdings zwei wichtige Erwiderungen: zum einen die Feststellung, dass Anfänger im Software Engineering (die erstmals an einer entsprechenden Veranstaltung teilnehmen) häufig noch genug mit dem Erlernen und Einsetzen der vorgestellten Notationen und Techniken gefordert sind und entsprechend mit deren Auswahl noch weit überfordert wären. Konkretere Vorgaben werden somit ohnehin notwendig, um die Verunsicherung der Studierenden zu reduzieren und auch Tutoren und Mitarbeitern eine Orientierung zur Beantwortung entsprechender Rückfragen zu geben. Das vorgestellte Bewertungsraster transportiert somit die Erwartungen des Prüfers an die Studierenden und ermöglicht ihnen, ihre Arbeitsschwerpunkte entsprechend der gegebenen Gewichtungen zu setzen.
Für fortgeschrittenere Studierende, die bereits ein
Anfängerprojekt durchlaufen haben, gibt das
Raster in der gezeigten Form andererseits tatsächlich
zu viele Hinweise preis. Es besteht natürlich die
Möglichkeit, beispielsweise nur fünf
Hauptkategorien (wie Kontextmodellierung, Anforderungen,
Analyse, Entwurf und Sourcecode) und ihre
Gewichtungen zu nennen, nicht aber die konkret
darin erwarteten Modelle. Ferner könnte noch eine
zusätzliche Bewertungskategorie zur
Modellauswahl etabliert werden, die die Sinnhaftigkeit der
gewählten Modelle bewertet. Die Gewichtung
innerhalb dieser Kategorie kann beispielsweise
gleichmäßig auf die gelieferten Modelle verteilt
werden oder auch von den Studierenden
vorgeschlagen werden, wenn sie mit einem
entsprechenden Bewertungsschema bereits in einer
Grundlagenveranstaltung vertraut gemacht worden sind.
Ferner liegt es für länger laufende Projekte ohne
feste Funktionalitätsvorgabe nahe, auch einen
entsprechend hoch gewichteten Bewertungsfaktor für
die Menge der umgesetzten Funktionalität (also für
die Produktivität) einzuführen. Weiterhin besteht
natürlich die Möglichkeit, auch die Einhaltung des
gewählten Vorgehensmodells, die Erstellung und
Befolgung eines Projektplans oder auch Softskills,
wie z.B. die Teamfähigkeit zu bewerten bzw.
letztere evtl. durch Peer Assessments
Die in diesem Beitrag vorgestellte Kombination von Bewertungsverfahren erreicht eine gute Überdeckung der eingangs genannten Testgütekriterien. Da die Bewertung des vorgeschlagenen Programmiertestats automatisiert über die zu durchlaufenden Testfälle erfolgen kann, ist es ein sehr objektives Verfahren. Es misst zudem genau die Leistung, die auch gemessen werden soll, nämlich die Fähigkeit, ein gegebenes Problem innerhalb eines beschränkten Zeitraums in ein passendes Programm umzusetzen. Es gibt sowohl Studierenden als auch Lehrenden ein hilfreiches Feedback bei der Einschätzung der Programmierkenntnisse und ist zu dem noch günstig (da automatisiert) durchführbar. Auch eine gewisse Skalierbarkeit ist gegeben, solange genügend gleichzeitig verfügbare Arbeitsplätze in einem oder mehreren Rechnerpools zur Verfügung stehen.
Da es sich bei Kolloquien im Wesentlichen um
Präsentationen und Prüfungsgespräche handelt, ist die
Bewertung naturgemäß zu einem gewissen Grad
subjektiv
Das vorgestellte Raster zur Systembewertung ermöglicht eine hohe Objektivität, zumindest dann, wenn, wie oben beschrieben, nicht die volle Notenskala zur Bewertung der Teilleistungen verwendet wird. Die Unterscheidung zwischen beispielsweise einer 1,7 und einer 2,0 für ein Klassendiagramm ist nach Erfahrung des Autors objektiv oft nicht mehr möglich. Mit der vereinfachten, vierstufigen Benotungsvariante hingegen ist das Verfahren sehr zuverlässig und valide, da es wiederholbar genau die Leistung eines Studierenden oder eines Teams bei der Erstellung des Systems bewertet, die bewertet werden soll. Somit ergibt sich auch ein hoher Nutzen für Prüfer und Studierende, da beide ein gutes Feedback über den tatsächlichen Leistungsstand der Studierenden erhalten. Einzig signifikante Schwäche des Verfahrens ist der recht hohe Bewertungsaufwand, der sich bei einem einsemestrigen Projekt mit ca. vier Studierenden pro Team schnell auf vier und mehr Stunden pro Team belaufen kann. Legt man ca. fünf ECTS und damit insgesamt rund 600 Stunden Arbeitslast für eine Viergruppe von Studierenden zugrunde, relativiert sich diese Zahl allerdings wieder; wie auch im Vergleich zu einer Klausur, die oft einen noch höheren Korrekturaufwand benötigt. Zudem lässt sich durch klare Vorgaben für die geforderten Abgaben (z.B. direkt ausführbares System, Quellcode mit klarer Struktur in einem Versionierungssystem, Dokumente mit einer gewissen Struktur und klare Benennung der Urheber) signifikant Zeit bei der Bewertung einsparen.
In der Literatur ist zwar eine erkleckliche Menge von Berichten über Softwareentwicklungsprojekte an Hochschulen verfügbar, die dort gemachten Aussagen über das verwendete Bewertungsverfahren beschränken sich aber meist auf wenige Sätze. Systematische Vergleiche verschiedener Ansätze finden sich daher leider ebenso wenig, wie auch empirische Studien zur Zufriedenheit der Beteiligten mit den folgenden Bewertungsansätzen bisher nicht verfügbar sind.
Ein wenig detaillierter berichtet
Nach dem Kenntnisstand des Autors am nächsten an das in diesem Beitrag vorgestellte Bewertungsraster kommt der Vorschlag von Wikstrand und Börstler (2006) heran. In ihrem Bewertungsansatz erwirbt ein Team gemäß seiner Leistung eine Anzahl von Credits für verschiedenste Aufgaben im Projekt, dazu gehören die Erstellung von Artefakten und Projektplänen ebenso wie gehaltene Präsentationen. Am Ende des Projekts sind die Teammitglieder gefordert, diese Credits eigenständig untereinander zu verteilen, so dass sich gegebenenfalls individuelle Abstufungen in der Benotung ergeben. Für die Betreuer besteht bei offensichtlichen Ungerechtigkeiten eine Eingriffsmöglichkeit. Eine effektive Erkennung von Studierenden, die auf Grund mangelnder Vorkenntnisse nicht hinreichend zum Fortschritt des Teams beitragen konnten, gibt es bei diesem Vorschlag allerdings wiederum nicht, es wird allein auf gegenseitige soziale Kontrolle durch die Studierenden selbst gesetzt. Verschiedene Empfehlungen zur Verminderung dieses Problems, wie auch zur organisatorischen Durchführung von Softwaretechnik-Projekten insgesamt, geben beispielsweise van der Duim et al. (2007). Sie schlagen vor „Free Riders“, also Trittbrettfahrer, dadurch zu erkennen, dass die Studierende Stundenzettel zu führen und einen vordefinierten Prozess zu verwenden haben; ferner sind wöchentliche Feedback-Gespräche mit den Betreuern vorgesehen, konkrete Nachweise der Programmierfähigkeiten werden aber wiederum nicht verlangt.
Der vorliegende Beitrag beschreibt eine neuartige Zusammenstellung von Bewertungsverfahren zur Benotung von Softwareentwicklungsprojekten an Hochschulen und Universitäten. Durch die Kombination eines automatisierten Programmiertestats mit mehreren Kolloquien und einem gewichteten Bewertungsraster für im Verlauf des Projekts erstellte Artefakte ermöglicht es die Komposition von teambasierten und individuellen Benotungsanteilen sowie eine effektive Erkennung von sogenannten Trittbrettfahrern. Somit wird im Vergleich zu bisherigen Bewertungsansätzen eine wesentlich objektivere Bewertung möglich, zudem wird die Nachvollziehbarkeit der Benotung durch die Studierenden deutlich verbessert.
Das vorgestellte Bewertungsraster für in der Softwareentwicklung erstellte Artefakte ist sicherlich die Kerninnovation dieses Beitrags, die zuvor nur in der Arbeit von Wikstrand und Börstler (2006) in annähernd ähnlicher Form vorgeschlagen wurde. Es bewertet im Gegensatz zu zahlreichen anderen Verfahren wie Klausuren, Übungsaufgaben oder auch Kolloquien direkt die Ergebnisse der Projektarbeit und damit die Erreichung der Lernziele und versucht nicht, eine Benotung über „Umwege“ sicherzustellen. Somit wird die Motivation und Konzentration der Studierenden auf die wesentlichen Ziele des Projekts gerichtet, und sie werden in einem ohnehin schon komplexen Lernumfeld nicht zusätzlich mit weiteren Aufgaben wie der Vorbereitung auf eine Klausur belastet. Durch die Bewertung teambasierter und individueller Leistungsanteile wird sowohl die Zusammenarbeit im Team gefördert, als auch den Ansprüchen von Prüfungsordnungen und Akkreditierungsagenturen nach einer individuellen Benotung genüge getan. Ferner wird durch die Kombination mit einem automatisiert auswertbaren Programmiertestat und zwei Kolloquien sichergestellt, dass Trittbrettfahrer frühzeitig entdeckt werden und die Leistungen ihrer Teamkollegen nicht nachhaltig negativ beeinflussen können. Insgesamt ist die Bewertung der abgelieferten Systemartefakte allerdings mit einem recht hohen Bewertungsaufwand verbunden (nach bisherigen Erfahrungen ca. 4-5 h pro Team), dieser liegt allerdings in der Regel unter einem Prozent des auf Seiten der Studierenden geleisteten Gesamtaufwands und ist somit der Komplexität der Aufgabenstellung angemessen und auch mit dem Aufwand beim Einsatz einer Klausur vergleichbar. Ein weiterer Vorteil ist die hohe Flexibilität des vorgestellten Bewertungsrasters, da abweichende Schwerpunkte in der Lehre durch veränderte Gewichtungen oder eine veränderte Zusammensetzung relativ leicht abgebildet werden können. So sind beispielsweise Aspekte des Projektmanagements, wie ein Projekt- oder Iterationsplan und dessen Einhaltung, in fortgeschrittenen Lehrveranstaltungen problemlos bewertbar. Insgesamt erscheint das vorgestellte Bewertungsschema damit so flexibel, dass es prinzipiell auch für Projekte in anderen Fachgebieten der Informatik anwendbar sein sollte.
Bis dato wurde das Verfahren in jeweils leicht abgewandelter Form in drei Projekten an der Universität Mannheim mit insgesamt gut 100 Studierenden erprobt. Die Benotung und im Extremfall auch ein Durchfallen lassen von Studierenden waren insbesondere durch die angewendete vierstufige Systembewertung gut begründbar und letztlich auch für die Studierenden nachvollziehbar, so dass sich Detaildiskussionen über die Bewertung subjektiv deutlich reduzieren ließen (entsprechende Parameter wurden leider nicht systematisch erfasst). Neben kleineren Verbesserungen, wie einer weiteren Verfeinerung der Abgaberichtlinien oder eventuellen Anpassungen der Gewichtungsfaktoren, soll bei zukünftigen Projekten auch eine systematische Befragung der Projektteilnehmer durchgeführt werden, um Stärken und Schwächen des Verfahrens aus Sicht der Studierenden zu erkennen und gegebenenfalls identifizierte Probleme zu beheben.
Der Autor möchte Melanie Klinger vom Referat für Hochschuldidaktik sowie Colin Atkinson, Werner Janjic und Marcus Schumacher von der SoftwareEngineering-Gruppe der Universität Mannheim herzlich für zahlreiche konstruktive Diskussionen und Anregungen im Zusammenhang mit dem vorgestellten Bewertungsschema danken.
ACM (2004): Software Engineering Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, in Computing Curricula Series.
Beck, K. (1999): Extreme Programming Explained:
Embrace Change. Addison-Wesley.
Böttcher, A. & Thurner, V. (2011): Kompetenorientierte Lehre im Software Engineering, Proceedings des Workshops für Software Engineering im Unterricht der Hochschulen.
Brooks, F. (1995): The Mythical Man-Month. Essays on Software Engineering (2. Aufl.), AddisonWesley.