=Paper=
{{Paper
|id=Vol-2358/paper-04
|storemode=property
|title=Software-Projektmanagement lernen ohne Projekt
(Learning Software Project Management without a Project)
|pdfUrl=https://ceur-ws.org/Vol-2358/paper-04.pdf
|volume=Vol-2358
|authors=Mario Winter
|dblpUrl=https://dblp.org/rec/conf/seuh/Winter19
}}
==Software-Projektmanagement lernen ohne Projekt
(Learning Software Project Management without a Project)==
https://ceur-ws.org/Vol-2358/paper-04.pdf
Projektmanagement lernen
ohne Projekt
Mario Winter, TH Köln
mario.winter@th-koeln.de
Zusammenfassung Dabei sollen sie die PM-Methoden, -Techniken und
-Werkzeuge zielgerichtet einsetzen und auch die er-
Das Modul "Projektmanagement" (PM) wird seit
forderlichen soziologischen und kommunikativen
dem Studienjahr 2003 an der Fakultät Informatik
Aspekte berücksichtigen können. Sie sollen mit dem
und Ingenieurwissenschaften der TH Köln (bis
Ziel einer menschengerechten und soziologisch fun-
09/2015 FH Köln) für alle Informatik-Studiengänge
dierten Menschenführung eine wirkliche und opti-
angeboten. Besondere Herausforderungen sind die
male Produktivität bei komplexen Projekten erreicht
seit 2012 zunehmend hohen Studierendenzahlen
können.
und die inhaltlichen und strukturellen Unterschiede
Besondere Herausforderungen sind die seit 2012
der Curricula der vier beteiligten Bachelor-Studien-
zunehmend hohen Studierendenzahlen und die in-
gänge. Zudem lassen es unterschiedliche Gründe
haltlichen und strukturellen Unterschiede der Cur-
nicht zu, das PM unmittelbar auf ein reales (studen-
ricula der vier beteiligten Studiengänge (Informatik,
tisches Lehr-) Software-Entwicklungsprojekt ange-
Medieninformatik, Technische Informatik, IT Ma-
wendet wird.
nagement und Wirtschaftsinformatik.
Dieser Beitrag beschreibt die Entwicklung des
Die unterschiedliche Positionierung des Moduls
grundsätzlichen Lehr-/ Lern-Arrangements von PM
in den Bachelor-Studiengängen – tw. im dritten, tw.
hin zu einer kompetenzorientierten "Team-
im fünften Semester – lässt es nicht zu, das die In-
Teaching"-Veranstaltung für alle Studiengänge, den
halte des Moduls von den Studierenden unmittelbar
didaktischen Hintergrund und die Lehr-Erfahrun-
auf reale (studentische Lehr-) Software-Entwick-
gen sowie -Aufwände in der PM-Lehre mit über 350
lungsprojekte angewendet werden. Dies erscheint
Studierenden.
auch aufgrund der großen Abhängigkeiten zwi-
Abstract schen Projektmanagement, Erfahrung in der Soft-
Since the academic year 2003, the module "Pro- wareentwicklung und Projekterfolg als zu riskant.
ject Management" (PM) has been offered at the Fac- Der Beitrag beschreibt die Entwicklung des
ulty of Computer Science and Engineering of the grundsätzlichen Lehr-/ Lern-Arrangements, also der
Technical University of Cologne (until 09/2015 FH Lehr-, Hausarbeits- und Prüfungsformate des Mo-
Köln) for all computer science courses. Particular duls Projektmanagement von eher inhaltsorientier-
challenges are the increasing number of students ten "Single-Teacher"-Veranstaltungen pro Studien-
since 2012 and the content and structural differences gang hin zu einer gemeinsamen kompetenzorien-
in the curricula of the four participating Bachelor tierten "Team-Teaching"-Veranstaltung für alle Stu-
programs. In addition, there are several reasons why diengänge, den didaktischen Hintergrund und die
PM is not applied directly to a real-world (student) Lehr -Erfahrungen sowie -Aufwände in der Projekt-
software development project. management-Lehre mit über 350 Studierenden.
This article describes the development of the
basic teaching / learning arrangement of PM to- Historie und Inhalte
wards a competence-oriented "Team Teaching" Im Sommersemester 2003 wurde PM im 6. Semester
event for all study programs, the didactic back- des damaligen Diplom-Studiengangs „Allgemeine
ground, and the teaching experience and efforts in Informatik“ der FH Köln erstmals vom Autor und
PM teaching with more than 350 students. einer Mitarbeiterin1 durchgeführt. Die Veranstal-
tung war im damaligen Curriculum mit 2 SWS Vor-
Kurze Vorstellung lesung und 2 SWS Praktikum verankert. Teilgenom-
Ziel des Moduls "Projektmanagement" (PM, 5 ECTS men haben 53 Studierende.
CP) ist die Befähigung der Studierenden, die grund- ________________
legenden Aufgaben des PMs, insbesondere in IT-
1 Im Folgenden meint „wir“ die an PM beteiligten Kolle-
Projekten, zu charakterisieren und durchzuführen. gen und Mitarbeiterinnen sowie Mitarbeiter.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 44
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Einführung und Überblick, 1. Vorlesung: 20.03.2003
Organisatorische Aspekte der Vorlesung und insbesondere des Praktikums (Einteilung der Studierenden in-
Teams). Danach werden Definitionen zentraler Begriffe wie „(Software-) Projekt“ und „Management“ erar-
beitet und ein Überblick über die Aktivitäten beim Management von Softwareprojekten – und damit den wei-
teren Inhalt der Vorlesung – gegeben.
Die „menschliche Komponente“ 2. Vorlesung: 27.03.2003
Gegenstand dieser Vorlesung sind die – nicht nur für Softwareprojekte – zentralen Fragen der Team Bildung,
der Zusammenarbeit im Team und der Motivation von Kollegen und Mitarbeitern. Grundlegende für diese
Fragen ist, die Individualität der Menschen anzuerkennen, ihre Stärken zu nutzen und mit den Schwächen
umzugehen. Da hierzu die “richtige“ Kommunikation wesentlich ist, werden zunächst Kommunikationsmo-
delle und -muster vorgestellt. Darauf – und auf dem Phänomen “Motivation“ – aufbauend werden typische
Merkmale der Gruppenbildung erläutert und Hinweise zum Krisenmanagement gegeben.
Kosten/Nutzen-Analysen und Entscheidungstechniken3. Vorlesung: 03.04.2003
Diese Vorlesung betrachtet Kosten/Nutzen-Analysen und Entscheidungstechniken für Softwareprojekte. Den
Ausgangspunkt bildet eine Klassifikation der Kosten- und der Nutzenarten. Ein besonderes Augenmerk liegt
hierbei auf der Differenzierung in quantifizierbare und nicht quantifizierbare Kosten- und insbesondere Nut-
zenarten sowie auf dem Aspekt der Unsicherheit der Plandaten. Anschließend werden statische Verfahren
der Investitionsrechnung auf Investitionen in Software angewendet. Zur Einbeziehung nicht-monetärer Ent-
scheidungskriterien runden eine Einführung in ein Entscheidungsmodell sowie Entscheidungstechniken wie
z.B. die Nutzwertanalyse unter Sicherheit, Risiko und Unsicherheit diese Vorlesung ab.
Organisation 4. Vorlesung: 10.04.2003 Aufbauorganisation, 5. Vorlesung: 17.04.2003 Ablauforganisation
Bei der Projektorganisation geht es zum einen um die Aufbauorganisation, bei der die Integration des Projekts
in das Unternehmen und die projektinterne Aufbauorganisation unterschieden wird. Andererseits wird die
Ablauforganisation im Rahmen von Softwareprojekten in der Regel durch Vorgehensmodelle beschrieben.
Wir skizzieren “klassische“ Vorgehensmodelle, bei denen die Aktivitäten in strenger Reihenfolge jeweils voll-
ständig durchgeführt werden, als auch modernere Vertreter, die iterativ vorgehen und das Produkt in kleinen
Schritten – sozusagen inkrementell – entwickeln.
Aufwandsschätzung 6. Vorlesung: 08.05.2003 Projektumfang 7. Vorlesung: 15.05.2003 Entwicklungszeit
Als Grundlage der Projekt-Durchführungsentscheidung sowie -Planung betrachten wir in diesen Vorlesun-
gen Verfahren zur Aufwandsschätzung für Software-Entwicklungsprojekte. Ziel ist zum einen, konkrete Zah-
len zu liefern und zum anderen, eine fundierte Ressourcenplanung für das Projekt zu ermöglichen. Nach ein-
fachen Verfahren wie der Prozentsatzmethode gehen wir auf die Function-Point-Analyse zur Schätzung der
Produktkomplexität anhand der im Lastenheft skizzierten Produktanforderungen ein. Es folgt das COCOMO-
Verfahren zur Abschätzung der Entwicklungszeit anhand des - vorher zu schätzenden – Produktumfangs.
Planung und Risikomanagement 8. Vorlesung: 22.05.2003 Projektplanung I 9. Vorlesung: 05.06.2003 Projektpla-
nung II 10. Vorlesung: 12.06.2003 Risikomanagement
Inhalt dieser Vorlesungen sind die detaillierte Projektplanung und das Risikomanagement für Softwarepro-
jekte. Für die Projektplanung werden u.A. die Verfahren der Netzplantechnik und ihre Anwendung in einem
Software-Entwicklungsprojekt behandelt. Grundlage ist die vorgangsorientierte Zeit- und Ressourcenpla-
nung. Risiken verbleiben auch bei bester Planung - im Rahmen des Risikomanagements versucht man, die
wichtigsten Risiken zu identifizieren, zu priorisieren und Möglichkeiten zu ihrer Beherrschung zu finden.
Controlling und Abschluss 11. Vorlesung: 26.06.2003 Projektcontrolling und Projektabschluss
Im Hinblick auf die Steuerung und das Controlling von Softwareprojekten besprechen wir Möglichkeiten, die
Zeit- und Ressourcenplanung auf aktuelle Planabweichungen anzupassen. Dabei betrachten wir auch den
Einsatz von Kennzahlen und das Berichtswesen. Im letzten Teil befassen wir uns mit dem für die „lernende
Organisation“ wichtigen Projektabschluss.
Querschnittsthemen 12. Vorlesung: 03.07.2003
Diese Vorlesung widmet sich den ergänzenden Bereichen Dokumentation sowie Versions- und Konfigurati-
onsmanagement. Einige Aspekte der Mitarbeiterführung wie die Einstellung neuer Projektmitarbeiter sowie
die Personalentwicklung runden die Vorlesung ab.
Abb. 1 PM-Inhalte (Auszüge aus dem Skript des Autors von 2003)
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 45
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Die Inhalte der Vorlesungen orientierten sich an ver- Die Teilnehmerzahlen seit Wintersemester
breiteten Lehrbüchern wie z.B. (Feyhl & Feyhl 1996), 2010/2011 zeigt die Tabelle 1.
(Balzert 1998), (Grupp 1998) und (Friedlein 2003) so-
wie den Lerneinheiten zum Fernstudienkurs „Ma- Semester Studierende
nagement von Softwareprojekten“ der FernUniver-
2010/11 143
sität Hagen (Henrich, 2001). Im Praktikum wurden
diese an einem vorgegebenen Fallbeispiel angewen- 2011/12 102
det (s.U.). Im Laufe der Jahre wurden immer wieder 2012/13 150
aktuellere Werke wie z.B. (Aichele, 2014), (Broy &
Kuhrmann, 2013) und (Kerzner, 2009) einbezogen. 2013/14 182
In Abb. 1 sind die in den wöchentlichen Frontalvor- 2014/15 303
lesungen behandelten Themenbereiche skizziert 2015/16 261
(Auszüge aus dem Skript des Autors von 2003).
2016/17 263
Bereits im Sommersemester 2004 wurde die Veran-
2017/18 359
staltung von zwei weiteren Lehrenden parallel auch
in den beiden Studiengängen „Medieninformatik“ 2018/19 286
und „Technische Informatik“ durchgeführt. Aus
den drei beteiligten Studiengängen nahmen insge- Tabelle 1 PM Teilnehmerzahlen seit 2010
samt 164 Studierende teil.
Ab 2006 waren alle Studiengänge auf das Ba-
Entwicklung des Lehr-/Lernarrange-
chelor-Modell umgestellt. Die Straffung der Curri-
cula auf 6 Semester führte auch zu einer Vereinheit- ments
lichung der Studienverlaufspläne, mit einem fast Entwicklungsphase I: Inhaltsorientierung und
identischen „Stamm“ in den ersten beiden Semes- Single-Teacher-Setting
tern und spezialisierenden „Ästen“ in den Semes- Die erste Durchführung von PM im Sommersemes-
tern 3-6. PM war nun in allen Bachelor-Curricula im ter 2003 für den Diplom-Studiengang „Allgemeine
5. Semester mit 5 ECTS-Punkten angesiedelt, nach Informatik“ erfolgte durch den Autor im "Single-
wie vor mit 2 SWS Vorlesung und 2 SWS Praktikum. Teacher"- Lehr-/ Lern-Arrangement. Über die ge-
Mit der ersten Reakkreditierung der Studien- samte Vorlesungszeit wurden die Inhalte der in
gänge im Jahr 2012 erfolgte eine Differenzierung der Abb. 1 skizzierten Frontalvorlesungen im Prakti-
Studienverlaufspläne: PM blieb in drei Bachelor- kum in praktischen Übungen vertieft und in einer
Curricula im 5. Semester, in einem (Wirtschaftsin- Klausur „abgeprüft“.
formatik) jedoch nun im 3. Semester. Der studenti- Dazu bildeten die Studierenden Teams mit 6
sche Aufwand betrug weiterhin 5 ECTS-Punkte, wie Team-Mitgliedern, in denen Sie die Übungsaufga-
zuvor mit 2 SWS Vorlesung und 2 SWS Praktikum. ben bearbeiteten. Jede Aufgabe erforderte die An-
wendung einer bestimmten Technik auf einen vor-
Studierendenzahlen gegebenen Projektgegenstand. Grundlage bildete
Nachdem im Sommer 2004 noch 164 Studie- ein vom Autor erstelltes Lastenheft für eine Anwen-
rende aus den vier Studiengängen teilgenommen dung zur Seminarverwaltung, angelehnt an das be-
haben, nahm deren Zahl in den darauffolgenden kannte Fallbeispiel aus (Balzert, 1996). Durch eine
Jahren tw. aufgrund der Erhebung von Studienge- inhaltliche Verzahnung der Aufgaben über den Pro-
bühren in NRW bis 2009 tendenziell eher ab. Begin- jektgegenstand wurde angestrebt, die Planungs-
nend mit dem Studienjahr 2010 führten die Ausset- und Überwachungstätigkeiten im Projektmanage-
zung der allg. Wehrpflicht zum 1. Juli 2011, die Ab- ment realitätsnah abzubilden.
schaffung der Studiengebühren in NRW zum Win- Abnahmen der Lösungen zu den Übungsaufga-
tersemester 2011/12 sowie der „Doppel-Abiturjahr- ben inklusive formativem Feedback der Projekter-
gang“ im Jahr 2013 (inkl. Hochschulpakt NRW) zu gebnisse erfolgten im 2-wöchigen Rhythmus durch
einem stark ansteigenden Trend der Zahlen, der sich den Autor und eine Mitarbeiterin.
seitdem fortsetzt und nun um ein Plateau von ca. 300
Studierenden pendelt. Spitzenreiter war das Winter-
semester 2017/18 mit 359 Studierenden.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 46
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Das summative Feedback – also die Modulprü- Projektgegenstand geplant und auch durchge-
fung – erfolgte in Form einer 120-minütigen Klau- führt und gesteuert werden müssen (während
sur. Neben einigen Wissensfragen mussten die Stu- die Arbeitspakete für den vorgegebenen Pro-
dierenden 3 bis 4 „konstruktive“ Aufgaben z.B. zur jektgegenstand in PM nur geplant, aber nicht ge-
Nutzwert-Analyse, Aufwandschätzung mit Func- steuert und durchgeführt werden müssen).
tion-Point-Analyse oder Netzplanung bearbeiten (s. • Last but not least waren viele Studierende nicht
Abb. 2). wirklich motiviert dabei, da die vorgegebene
Aufgabenstellung (Anwendung zur Seminar-
verwaltung, s.O.) eher angestaubt, akademisch
und fachlich sowie technisch uninteressant er-
schien.
Ein erstes Brainstorming konzentrierte sich auf den
Projektgegenstand. Schnell kam die Frage auf, wa-
rum wir in PM nicht ein wirkliches Studierenden-
projekt planen und dann tatsächlich auch durchfüh-
ren lassen? Dagegen sprach, dass im Rahmen der 5
ects cp zusätzlich zum Erlernen von PM kein noch
so bescheidenes „Entwicklungsprojekt“ möglich ist.
Eine Verknüpfung von PM mit den im Curriculum
verankerten Studien- und Praxisprojekten war nicht
in der Breite durchführbar, da viele solcher Projekte
in Zusammenarbeit mit externen Projektpartnern
Abb. 2 Klausurthemen 2003 durchgeführt werden und eben fundierte PM-
Entwicklungsphase II: Realitätsnähe und Team- Kenntnisse bereits voraussetzen. Das Risiko, dass
Teaching „Fehlplanungen“ den Projekterfolg gefährden, war
uns einfach zu groß 2.
Unsere Diskussionen vor der ersten parallelen
Durchführung von PM ab dem Sommersemester Beschlossen wurde, die Studierenden-Teams im-
2004 in den vier Studiengängen „Allgemeine Infor- merhin einen eigenen Projektgegenstand im Bereich
matik“, „Medieninformatik“, „Technische Informa- Softwareentwicklung definieren zu lassen, um da-
tik“ und „Wirtschaftsinformatik“ basierten i.W. auf mit die intrinsische Motivation zu fördern.
den Eindrücken während der Praktikum-Abnah- Diese und einige weitere Diskussionen zum
men und den Ergebnissen der ersten Klausuren. Wir „Team-Setting“ führten schließlich zu folgenden
identifizierten folgende Probleme des initialen Lehr- Veränderungen der Praktika:
/Lernformates: 1. Die Teams wurden heterogen mit 6 Studie-
• Die Studierenden bearbeiteten die Praktikum- renden aus mindestens 3 Studiengängen ge-
Aufgaben nicht wirklich als Team, sondern ge- bildet. Dies sollte die „Diversität“ in der Be-
mäß „Teile und Herrsche“ eher in Einzelarbeit. setzung realer Projektteams widerspiegeln.
Dadurch wurden Querbezüge in den Aufgaben- 2. Es sind 6 Projektaufgaben zu bearbeiten:
stellungen und der Anwendung der Methoden I) Erstellung des Lastenheftes;
bzw. Techniken oft nicht erkannt, worunter die II) Aufwandsschätzung;
Konsistenz der Lösungen erheblich litt. III) Kosten-/Nutzen-Betrachtung;
• Zusätzlich waren viele Studierende „Experten“ IV) Risikomanagement;
genau für die PM-Methode bzw. PM-Technik, V) Vorgehensmodell-Tailoring;
welche sie selbst im Praktikum aktiv angewen- VI) Zeit- und Ressourcenplanung.
det haben, zeigten aber tw. erhebliche Lücken in 3. Für jede dieser 6 Projektaufgaben musste
anderen Bereichen. das Team eine Rollenzuteilung festlegen:
• Auch wurde vielen Studierenden nicht bewusst, - Ein Projektleiter (PL);
dass die Bearbeitung jeder einzelnen Aufgabe - Ein Repräsentant (PR);
selbst ein „Mini-Meta-Projekt“ darstellt. „Meta“ - 2-4 Mitarbeiter (Bearbeiter, Recher-
in dem Sinne, dass dabei Arbeitspakete für das cheur, Reviewer, …).
PM von Arbeitspaketen für den vorgegebenen
2 Dies haben u.A. auch Fleischmann und Spies an den TU’s Darmstadt und München festgestellt. Sie schreiben dazu, „dass die größten
Herausforderungen für die beteiligten Studierenden dabei weniger in der Bewältigung technischer oder fachlicher Fragestellungen liegen: Diese Prob-
lematik ist ihnen aufgrund ihrer Lernerfahrung im Studienverlauf bereits geläufig. Vielmehr stellt der Umgang mit organisatorischen und sozialen
Problemen eine viel größere Herausforderung dar und führt daher oft zu für die Studierenden unvorhergesehenen Problemen im Projekt.“ (Fleisch-
mann & Spies, 2005, S. 26)
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 47
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Damit sollte die Bearbeitung der Aufgaben
als „Mini-Meta-Projekt“ im Team gefördert Die Studierenden sollen befähigt werden,
werden. • die grundlegenden Aufgaben des Projektmana-
4. Jedes Team definierte einen eigenen Projekt- gements, insb. in IT-Projekten, zu charakterisie-
gegenstand gemäß der groben Vorgabe, ren und durchzuführen;
dass dieser innerhalb vorgegebener Budget- • die Projektmanagement-Methoden, -Techniken
(500.000 € bis 1.000.000 €) und Aufwands- und -Werkzeuge zielgerichtet einzusetzen;
bzw. Zeit-Grenzen (36 bis 72 PM, 6 bis 12 • die erforderlichen soziologischen und kommuni-
Monate) liegt. Dies sollte einerseits die Mo- kativen Aspekte zu berücksichtigen, insb. mit dem
tivation der Studierenden steigern und an- Ziel einer menschengerechten und soziologisch
dererseits den „Ergebnisaustausch“ zwi- fundierten Menschenführung zur Erreichung einer
schen den Teams mindern. wirklichen und optimalen Produktivität bei kom-
In einem Team-Teaching-Setting mit drei Lehr-Tan- plexen Projekten.
dems aus Kollege und Mitarbeiterin bzw. Mitarbei-
Abb. 3 Modulziel von PM 2006
ter wurden die Vorlesungen dann zwar nach wie
vor über die gesamte Vorlesungszeit, jetzt aber im Ende 2006 waren dann alle Informatik-Studien-
Wechsel von den drei beteiligten Kollegen gehalten. gänge vom Diplom auf den Bachelor umgestellt. Das
In dieser Zeit wurde die Bearbeitung der Aufgaben oben genannte Feedback der Studierenden, die Ver-
im Praktikum je Team von einem Kollegen und ei- ständigung auf das explizit formulierte Lernziel so-
ner Mitarbeiterin oder einem Mitarbeiter betreut. wie unsere zunehmende Erfahrung mit der Ein-
Die Bearbeitung der Praktika bestand aus zwei schätzung und Bewertung der von den Studieren-
Teilen: den im Team erzielten Praktikum Ergebnisse und
1. Jedes Team erstellte jeweils unter der Pro- Präsentationen ermutigten uns dann ab dem Som-
jektleitung eines/einer Studierenden die Ar- mersemester 2007, die Modulnote anhand der
tefakte inkl. der Begründung der Vorge- Teamleistung und der individuellen Leistung (als
hensweise und Ergebnisse zu jeder der Auf- PL und PR) im Praktikum und im Abschluss-Kollo-
gaben I) bis VI); quium zu ermitteln. (Inhaltlich wurde 2007 das bis
2. In einem Abschluss-Kolloquium präsentier- dahin für die Ablaufplanung verwendete V-Modell
ten die Team-Mitglieder nacheinander in je- 97 durch den Nachfolger V-Modell XT ersetzt.)
weils 5 Minuten die Ergebnisse einer der Zur besseren Einschätzung der Teamleistung
sechs Aufgaben, wobei einige Verständnis- musste nun jedes Team zu den Aufgaben neben den
fragen gestellt wurden. Bearbeitungsergebnissen auch Protokolle abgege-
ben. Diese sollten das Zustandekommen der jeweili-
Die selbstdefinierten Projektgegenstände waren in
gen Ergebnisse im Vorfeld der Präsentation doku-
der Regel reine Softwareentwicklungen (z.B. Park-
mentieren, insbesondere Informationen zur Team-
platz-Reservierung im Web, Client-/Server-Anwen-
/Rollenaufteilung, zur Bearbeitung der Aufgaben
dung zur Raumreservierung) und nur einige wenige
(evtl. mit den jeweiligen Teilschritten) und zum je-
HW/SW-Systementwicklungen. Die Motivation der
weiligen Arbeitsfortschritt. Auch für ein angemesse-
Studierenden stieg durch den selbstgewählten Pro-
nes Layout der Protokolle war zu sorgen.
jektgegenstand merklich, wobei die Präzisierung
Die gesamte Bewertung der einzelnen Studie-
der Projektvision durch das Lastenheft für viele
renden ergab sich zum einen aus der Bewertung der
„Aha-Momente“ bzgl. unterschiedlicher Interpreta-
Dokumentation zu der als PL bearbeiteten Aufgabe
tionen der Projektidee sorgte. Die Modulnote ergab
(Hausarbeit). Es wurden jedoch im Verlaufe des
sich weiterhin alleine aus einer Klausur.
Praktikums durch die Präsentationen, die Protokolle
Ein wesentlicher Punkt des eingeholten Feed-
und in den Fragerunden „Punkte“ gesammelt, die
backs der Studierenden war der Wunsch, die team-
sich positiv in der Gesamtbewertung niederschlu-
basierten Leistungen bei der Bearbeitung der Pro-
gen.
jektaufgaben auch in die summative Bewertung,
Insgesamt wählten wir folgende Gewichtung
also die Modulnote einließen zu lassen.
der einzelnen Prüfungsbestandteile:
Entwicklungsphase III: Lernziel-Orientierung und • Dokument (Hausarbeit) 40 Punkte.
veranstaltungsbegleitende Prüfungsformate • Präsentation und Fragen 40 Punkte
Im Rahmen der Umstellung auf das Bachelor-Mo- • Protokolle/Teamleistung 20 Punkte
dell wurde erstmals eine Modulbeschreibung mit Die Bewertung der Dokumente erfolgte separat für
den Lernzielen bzw. den „von den Studierenden zu jedes Team alleine durch den Kollegen im betreuen-
erlangenden Kompetenzen“ gefordert. Das von uns den Lehr-Tandem. Dies bedeutete für jeden von uns
formulierte Modulziel zeigt Abb. 3. drei Kollegen die Bewertung der im Praktikum er-
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 48
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
stellten Arbeitsergebnisse, begründenden Doku- der Bepunktung der Protokolle wurde das in den
mente sowie Protokollen von ca. 10 Praktikum- Protokollen beschriebene Vorgehen des Teams inkl.
Teams. Teilaufgaben-Zuteilung, Zeitplanung und „Kon-
Die Präsentationen der Studierenden fanden ge- fliktlösungen“ gewertet.
blockt an drei Tagen am Ende der Vorlesungszeit In diesem Lehr-/Lernarrangement wurde die
statt und wurden pro Team separat vom Kollegen Veranstaltung dann mehrfach durchgeführt. Das
und der Mitarbeiterin bzw. dem Mitarbeiter des be- Feedback der Studierenden war durchaus positiv,
treuenden Lehr-Tandems bewertet. allerdings wurden insbesondere unsere Mitarbeite-
Zum Schluss wurden die Bewertungen zusam- rinnen und Mitarbeiter von einzelnen Studierenden
mengeführt und ergaben die Modulnote. Die hierbei „hinter vorgehaltener Hand“ auf die teilweise eher
unvermeidlichen Unterschiede in den subjektiven „gefühlte“, tw. aber auch nachvollziehbare Diskre-
Einschätzungen wurden durch das in Tabelle 2 ge- panz der Benotungen durch die drei Lehr-Tandems
zeigte Gesamt-Bewertungsschema für die Projekter- hingewiesen.
gebnisse sowie eine grobe Kriterienliste für die Prä-
sentationen und Fragen (Tabelle 3) abgemildert. Bei
Tabelle 2 Gesamt-Bewertungsschema SoSe 2007
Fragen Stil
A____F____: _________________ Rede: Sicher / Flüssig / Stockend / Zum Zuhörer / Unterhaltsam
A____F____: _________________
Inhalt: Vollständig + Richtig / Sachkundig / Überlegt / tw. falsch
A____F____: _________________
A____F____: _________________ Sprache: Fachsprachlich / Teils-Teils / Umgangssprachlich
A____F____: _________________
A____F____: _________________ Dialog: Geht auf Fragen ein / Weicht aus / Chaotisch
A____F____: _________________
Tabelle 3 Bewertungsschema Präsentation und Fragen SoSe 2007
Im Rahmen der 2009 beginnenden Vorbereitungen Wir präzisierten zunächst unsere bis dahin nur
der Reakkreditierung der Studiengänge stand zu- implizit im Lehr-/Lern-Arrangement vorhandenen
nächst die Lernzielorientierung der Curricula im Ansätze zur Erreichung der Lernziele von PM.
Vordergrund. Insbesondere hatten wir Probleme, Schnell wurde klar, dass die bislang von den Lehr-
mit den „herkömmlichen“, eher inhaltsorientierten Tandems unterschiedliche Handhabung der Veran-
Beschreibungsmitteln begründet die übergeordne- staltungs-Bestandteile vereinheitlicht und den Stu-
ten Lernziele (learning outcomes, vgl. Thurner & dierenden explizit zu Beginn des Semesters verdeut-
Böttcher et al. 2015) der Studiengänge auf deren licht werden muss.
Curricula herunter zu brechen bzw. deren Erfüllung Die erste Veränderung bestand somit in einer ex-
(oder Erfüllbarkeit) aus den Lernzielen der einzel- pliziten Formulierung der Modalitäten für die ver-
nen Module abzuleiten. Dies erforderte eine erneute anstaltungsbegleitenden Prüfungsformate in Form
Fokussierung auf die für PM formulierten Lernziele.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 49
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
eines „Lehr-/Lern-Vertrages“ (Abb. 4). Das (posi- In den beiden darauffolgenden Semestern be-
tive) Feedback der Studierenden hierzu ergab sich wertete daher jedes Lehr-Tandem zwei unmittelbar
implizit dadurch, dass die Abgabe-Meilensteine zu aufeinanderfolgende Aufgaben. Daraus ergab sich
den Projektaufgaben von deutlich weniger Projekt- eine deutlichere, jeweils nach einem Drittel der Vor-
leitungen „gerissen“ wurde wie in den früheren Se- lesungszeit geblockte „Prüfungsbelastung“. Auch
mestern. bei dieser Aufteilung war für die beiden Lehr-Teams
Die zweite Veränderung betraf die Bewertung zu den Aufgaben 3 und 4 bzw. 5 und 6 ein Einblick
der Dokumente aus den Aufgabenlösungen der in die davorliegenden Aufgabenlösungen der
Teams. Hier versuchten wir, durch unterschiedliche Teams notwendig.
Zuteilungen der Aufgaben zu den Lehr-Tandems zu Die dritte Veränderung führte zu einer Entzer-
einer gleichen Bewertung aller Teams zu gelangen. rung der Präsentationstermine, die nun nicht mehr
Zunächst erstellten wir zur möglichst objektiven geblockt am Ende der Vorlesungszeit, sondern ge-
Bewertung der Aufgabenlösungen feingranulare blockt nur noch für jeweils zwei Aufgaben nach der
„Controlling“ Bewertungsformulare. Dann teilten Meilenstein-Abgabe zu den Projektaufgaben er-
wir die Aufgabenlösungen aller Teams abwechselnd folgte. Dadurch wurde eine zeitnahe „Prüfung“ der
jeweils einem den Lehr-Tandems zu, so dass z.B. erreichten Kenntnisse möglich, allerdings auf Kos-
Lehr-Tandem A die Aufgaben 1 und 3 bewertete. ten einer gewissen „Ungleichbehandlung“ der Stu-
Die „Lücke“ zwischen den beiden zu bewertenden dierenden, da ja die Repräsentanten der ersten bei-
Aufgabenstellungen und die bereits genannten Ab- den Aufgaben nicht auf Erfahrungen aus vorherigen
hängigkeiten erforderten jedoch bei der Bewertung Präsentationsterminen aufbauen konnten.
der zweiten Aufgabe auch eine nähere Ansicht der
Lösung zur unmittelbar davorliegenden Aufgabe.
Hausarbeit (Dokumentation der Ergebnisse einer Aufgabe)
Zu den 6 Aufgaben muss das Team eine Dokumentation (Hausarbeit) erstellen. Für die Erstellung der Dokumentation ist dasje-
nige Teammitglied verantwortlich, das für die jeweilige Aufgabe die Rolle Projektleiter ausfüllt. Es muss in der Rolle des Projekt-
leiters dafür sorgen, dass das Team ihm bei der Erstellung der Dokumentation tatkräftig zur Seite steht und die richtigen Teil-
aufgaben jeweils an die anderen Teammitglieder verteilen. In diesem Sinne ist jeder aus dem Team für eine Aufgabe als „Pro-
jektleiter“ verantwortlich und muss deren Ergebnisse in einer Hausarbeit dokumentieren.
Auf dem Weg bis zur endgültigen Abgabe der Hausarbeiten müssen die Ergebnisse in insgesamt 3 Abnahmeterminen präsentiert
werden. Hierzu wird jedes Teammitglied die Ergebnisse einer Aufgabe bei der er/sie nicht die Rolle Projektleiter spielt, in der
Rolle als Repräsentant präsentieren. Die 6 Dokumentationen werden dann zum 3. Abnahmetermin abgegeben.
Abnahmen der Praktika
Die Projektergebnisse werden zu je zwei Aufgaben in insgesamt 3 Abnahmeterminen (siehe Terminplan) vor den verantwortli-
chen Professoren präsentiert und das gesamte Team muss sich einer Reihe von Fragen hierzu stellen.
Präsentation der Ergebnisse durch Repräsentanten
In den Abnahmeterminen sind die Ergebnisse zu den beiden jeweils betroffenen Aufgaben zu präsentieren. Bei der Präsentation
zu einer Aufgabe stellt ein Repräsentant (nicht der Projektleiter selber) die Ergebnisse zur Aufgabe anhand einiger Folien in
genau 5 Minuten vor.
Fragerunde
Nach der Präsentation zu den beiden Aufgaben wird in einer ca. 20 minütigen Fragerunde das gesamte Team mit einer Reihe
von Fragen zu den beiden Aufgaben konfrontiert und die einzeln befragten Teammitglieder müssen diese beantworten.
Protokolle
Zusätzlich müssen vom Team zu den beiden in der Abnahme zu präsentierenden Aufgaben und zu den zugehörigen Einstim-
mungsaufgaben Protokolle abgegeben werden, die das Zustandekommen der jeweiligen Ergebnisse im Vorfeld der Präsentation
dokumentieren. Die Protokolle enthalten insbesondere Informationen zur Team-/Rollenaufteilung, zur Bearbeitung der Aufga-
ben (evtl. mit den jeweiligen Teilschritten) und dokumentieren den jeweiligen Arbeitsfortschritt. Auch für ein angemessenes
Layout der Protokolle ist zu sorgen.
Abgabe der Hausarbeiten eine Woche nach der 3. Abnahme
Die dokumentierten Endergebnisse zu allen 6 Aufgaben werden dem jeweiligen Prüfer eine Woche nach dem
3. Abnahmetermin als ausgedrucktes finales Dokument übergeben.
Abb. 4 Explizite Veranstaltungsmodalitäten ab WiSe 2010/11
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 50
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Entwicklungsphase IV: Kompetenzorientierung Kompetenzbegriff sein, welcher folgende Punkte
umfasst (Reis 2010):
Im Rahmen seiner hochschuldidaktischen Weiter- • Die wissenschaftliche Modellierung komplexer
bildung zum Fakultäts- Multiplikator für kompe- Anforderungskontexte (Kenntnisse, Fertigkeit,
tenzorientierte Prüfungen im Sommer 2014 konnte Fähigkeit);
der Autor die bisherigen Ansätze und Erfahrungen • Die Erschaffung und Gestaltung innovativer
im Modul PM reflektieren. Konzepte und Problemlösungen;
Die Kompetenzorientierung ist ein wichtiges • Die anschlussfähige Kommunikation von wis-
Mittel, Lehre und Prüfung voneinander zu trennen senschaftlichen Wissensbeständen, Konzepten
und gleichzeitig sowohl Lehre als auch Prüfungen und Methoden;
zielgerichtet, effektiv, transparent, valide und zu- • Die Selbstregulation und Reflexion des eigenen
verlässig zu gestalten. Abb. 5 zeigt den damit entste- problemlösungs- und erkenntnisgeleiteten Han-
henden Dreiklang von Lernziel, Lehr-/Lern-Arran- delns.
gement und Prüfungsform(en) nach (Biggs & Tang,
2011). Nach Meinung des Autors wurde seinerzeit insbes.
Insbesondere bei Lernzielen auf höheren kogni- im Fachhochschulbereich der Bereich der Kennt-
tiven Stufen, wie sie ja in PM erreicht werden sollen, nisse, Fähigkeiten und Fertigkeiten inhaltlicher Art
bietet die Kompetenzorientierung einen begründe- immer noch überbetont, es zählte „der Stoff“. Hier
ten Handlungsrahmen, in dem sich auch genügend möchte der Autor dazu beitragen, auch die weiteren
Spielraum für die individuelle Ausgestaltung findet. Anteile des akademischen Kompetenzbegriffes an-
Für projektorientierte SE-Lehrveranstaltungen zei- gemessen mit in die Gestaltung der Curricula sowie
gen dies z.B. (Böttcher & Thurner 2011 und Hum- der einzelnen Module der Informatik einzubringen.
mel, 2013). Ein weiteres Argument gegen die Kompetenzor-
ientierung zielt gerade vor dem Hintergrund hoher
Lernziele Studierendenzahlen auf die ökonomische (Durch-
führungs-)Ebene. Gerade in Grundlagenveranstal-
tungen werden Lernziele oft rein auf Inhaltsebene
bzw. auf den „unteren Taxonomiestufen“ (Ander-
son & Krathwohl 2001) formuliert. Die Pragmatik,
also das „Warum bzw. Wofür“ wird außer Acht ge-
lassen, da berufsfeldnahe Beispiele oder Probleme
Lehr-/Lern-Arrangement Prüfungsform(en) als zu komplex erachtet werden. In Prüfungen
(i.d.R. Klausuren) werden dann eher Wissens-, Ver-
Abb. 5 Constructive Alignment ständnis- und algorithmisch lösbare Handlungsfra-
gen gestellt, die eine fest umrissene „Musterlösung“
Gegen die Kompetenzorientierung wird oft da- und damit eine „objektive“ Aus- und Bewertung er-
hingehend argumentiert, dass es i.S. der Freiheit von möglichen.
Forschung und Lehre nicht in erster Linie darum ge- Hier ermuntert der Autor dazu, zunächst einmal
hen kann, „berufsfähige“ Absolventen zu „produ- die Lernziele der eigenen Veranstaltung ehrlich, mit
zieren“. Diese Argumentation greift m.E. zu kurz, hoher Formulierungsqualität, nach dem Dreiklang
da hierbei der Begriff Kompetenz i.d.R. nur i.S.d. Be- „Was, Womit, Wozu?“ und taxonomisch eindeutig
rufsbildungsforschung gesehen wird 2. Kurz gefasst zu formulieren. Wenn diese eben tatsächlich nur auf
meint Kompetenz hier genau solche Fähigkeiten den „unteren Kompetenzstufen“ liegen und das so
und Fertigkeiten, die in der heutigen industriellen ausreichend auf die curricularen Lernziele „ein-
bzw. beruflichen Praxis gefordert werden. zahlt“, ist es OK. Sollen aber auch Lernziele auf hö-
Darüber hinaus werden oft kommunikative und herer Taxonomiestufe erreicht werden, muss oft der
reflexive Fähigkeiten sowie „höhere“ Fähigkeiten Stoffumfang gekürzt und auf andere Lehr- und
wie evaluieren und synthetisieren nicht betrachtet. Prüfmethoden zurückgegriffen werden.
Hierzu sollte man sich §2 (1) des HRG vor Augen Im Sinne des „Constructive Alignment“ unter-
halten: „Die Hochschulen […] bereiten auf berufli- suchten wir zunächst, ob sowohl die Lehrveranstal-
che Tätigkeiten vor, die die Anwendung wissen- tung als auch die Prüfung(en) konsequent auf die zu
schaftlicher Erkenntnisse und wissenschaftlicher erreichenden Lernziele hin ausgerichtet sind. Insbe-
Methoden oder die Fähigkeit zu künstlerischer Ge- sondere bei der Bewertung der Aufgabenlösungen
staltung erfordern.“ Grundlage der Kompetenzori-
entierung in der Hochschule sollte der akademische
2 S. A. die aktuelle Kritik an der Kompetenzorientierung in der
gymnasialen Oberstufe und der zentralen Abiturprüfung in
(Weiss & Kaenders, 2018).
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 51
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
und der Präsentationen konnten wir deutlichen Ver- werden. Im Rahmen der Aufgabe zur Vorgehens-
besserungsbedarf ausmachen. modellierung müssen die Studierenden im Kontext
Hier wurde die bisherige, eher feingranulare ihres Projektgegenstandes diskutieren, ob das von
und quantitative Bewertung der Aufgabenlösungen ihnen „zugeschneiderte“ V-Modell XT oder ein agi-
zu Gunsten eines gröberen Bewertungsrasters auf- les Vorgehen zielführender erscheint.
gegeben (Tabelle 5). Das zu grobe Bewertungsraster Letztendlich führten wir, um die Inhaltsvalidität
für die Präsentationen inklusive der zu erstellenden der Prüfung zu erhöhen, ab dem Wintersemester
Präsentationsfolien hingegen verfeinerten wir zu 2016/17 einen einstündigen Wissenstest ein, in dem
dem in Tabelle 6 gezeigten fünfstufigen Raster. die erlangten Kenntnisse und (Technik-)Fertigkeiten
Mit diesen Handreichungen erfolgt seitdem die der Studierenden „in der Breite“ beobachten. Hier
Bewertung in den zwei Schritten 1.) Beobachten und verwenden wir das MC-Format als effektives Prü-
2.) Bewerten (vgl. Szczyrba, Wildt & Dany 2008). Die fungsformat für Kenntnisse und Fertigkeiten bis zur
Benotung wird seitdem von den Studierenden als vierten kognitiven Ebene des Wissenserwerbs
objektiver und nachvollziehbarer angesehen. („Analysieren“, s. Anderson & Krathwohl et al.
Als weitere Änderung wurden die Präsentati- 2001, Miller, Linn & Gronlund 2008).
onstermine wieder am Ende des Semesters geblockt, Tabelle 4 fasst die Entwicklung des Moduls PM von
so dass alle Studierenden auch für diesen Prüfungs- 2003 bis heute zusammen.
teil die gleichen Voraussetzungen haben.
Inhaltlich haben wir insbesondere bei der Ab-
lauforganisation die agilen Vorgehensweisen einbe-
zogen, da diese in der Praxis zunehmend eingesetzt
Entwicklungsphase Auslöser Lehr-/Lernarrangement Prüfungsform
I.) 2003: Inhaltsorientierung Erste PM-Veranstaltung Single-Teacher, Praktikum Klausur
und Single-Teacher-Setting des Autors nach der Beru- eher i.S. von Übungsaufga-
fung, Diplomstudiengang ben.
„Allgemeine Informatik“
II.) 2004-2006: Realitäts- Gemeinsame PM-Veran- Team-Teaching, Praktikum Klausur
nähe und Team-Teaching staltung mit zwei Kollegen mit vorgegebenem Projekt-
für alle 4 Informatik-Diplom- gegenstand, studiengangs-
Studiengänge der FH Köln übergreifende Teams, Ab-
nahme am Ende der Vorle-
sungszeit
III.) 2007-2014: Lernziel- Umstellung auf Bachelor Team-Teaching, Praktikum Schriftliche Dokumentation
Orientierung und veranstal- und Akkreditierung, Formu- mit selbst gewähltem Pro- der Lösung einer Aufgabe,
tungsbegleitende Prü- lierung des Lernziels jektgegenstand, studien- Präsentation und mdl.
fungsformate gangsübergreifende Kurzprüfung
Teams, Meilenstein-Abga-
ben und Präsentationen in Protokolle/Teamleistung
der Vorlesungszeit
IV.) Seit 2015: Kompetenz- Reakkreditierung und neue Team-Teaching, Praktikum Meilenstein-Einhaltung,
orientierung Erkenntnisse zu kompe- mit selbst gewähltem Pro- PM-Artefakte
tenzorientierter Lehre und jektgegenstand, studien- Präsentation und mdl.
Prüfung gangsübergreifende Kurzprüfung,
Teams, Meilenstein-Abga-
ben und Feedback-Gesprä- MC-Wissenstest
che in der Vorlesungszeit,
Präsentationen geblockt
am Ende der Vorlesungs-
zeit
Tabelle 4 Entwicklungsphasen des Moduls Projektmanagement
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 52
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Team 1 4
AT4-AY9 Bew ertung! Kriterien-
Schlüssel in Kom m ent. bei
Aufg.Nr. Projekt auto_lo Living Reality
Aufgabe Bewertungskriterien Faktor Kommentar Note Kommentar Note
G& 19F& ?Do 1So 1U+ stdN+ G+ 20F+ 3D+ 0S! 3U& stdN+ 0T!
Lastenheft 0,5 2,4 2,5
1 10T+ 0FR! 2FR&
Deckbl. unvollst., D in use cases, Personae gut, Fremdp. Unstrukt.
Eindruck 0,5 1,7 1,7
sauber. Fremdprod. Fehlen! Abb-Quelle?
Lastenheft
Inhalt - 35S, zt sehr ausführlich 2,0 14 S., Seitennum., Links! 2,1
_Lastenheft.pdf
Ampelfeedback und Note :-) 2,0 :-) 2,1
(460RFP 50SI 529FP 60PMfp) (212RFP 44SI 231FP 13PMfp)&
FPA, CoCoMo 0,5 11KLOC (Cbs CmdOrg Cim)+ 1,8 21KLOCo (Cbs ?Cmd ?Cim)o 2,5
(30PMco 9TDEVc)+ (60PMc 11TDEVc)o
2
Fundiert, FPA u CoCoMo tw. FPA gut, etw. umstdl., Coc basis,
Eindruck 0,5 1,3 2,3
Begründung unvollst.; Diff nicht diskutiert
Aufwandsschätzung
Inhalt - Gut strukturiert 1,5 2,4
Ampelfeedback und Note :-) 1,5 :-| 2,4
(2PdR 8PjR)+ Prio Mit+ NtfP+
RisikoAnalyse 0,5 2,0 (#PdR #PjR) Pri Mit NtfP AE 0,0
4 AE&
Fundiert, aber keine RPZ-
Eindruck 0,5 Berechnung. Zu wenig 2
Risikomanagement Produktrisiken.
Inhalt - knapp 2,0 0,0
Ampelfeedback :-) 2,0 0,0
Tabelle 5 Bewertungsschema Hausarbeiten im WiSe 2017/2018 (Ausschnitt)
PROJEKTMANAGEMENT WS 2017-2018 Bewertungskriterien für Folien und Präsentation
MW 20171114
Bereich Note Kriterien
F Inhalt mangelhaft 5 Inhaltlicher Zusammenhang und Aufgabenbezug nicht erkennbar
Ausreichend 4 Inhaltlicher Zusammenhang und Aufgabenbezug erkennbar, aber implizit
Durch- Inhaltlicher Zusammenhang, Aufgabenbezug und roter Faden erkennbar, Ergebnisse
3
schnittlich werden vermittelt
Über dem Kurze und im Wesentlichen nachvollziehbare Darstellung, Aufgabenstellung und
2
Durchschnitt Ergebnisse werden klar vermittelt
Kreative, jederzeit nachvollziehbare Darstellung von Zielen, Aufgabenstellung und
Exzellent 1
Ergebnissen
F Darstellung mangelhaft 5 Themenstellung verfehlt, viele nebensächliche Details
Ausreichend 4 Einige Inhalte erkennbar, ausschweifend oder viel zu kurz
Durch-
3 Erläuterung einiger Ergebnisse und Details
schnittlich
Über dem Kurze Erläuterung einiger wichtiger, begründet ausgewählter Ergebnisse,
2
Durchschnitt Darstellungsformen korrekt, Details sinnvoll
Prägnante Erläuterung, Begründung und eigene Interpretation der zentralen
Exzellent 1
Ergebnisse, Details helfen bei Verständnis
Tabelle 6 Bewertungsschema Präsentation im WiSe 2017/2018 (Ausschnitt)
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 53
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Abb. 6 Evaluierungsergebnisse aus dem Wintersemester 2016/17 (Ausschnitt)
Wir führen das Modul PM nun seit dem Winterse- Erste Versuche mit SESAM waren zwar ermutigend,
mester 2016/17 in der oben beschriebenen kompe- wurden aber eher im „single-player“ Modus in der
tenzorientierten Form durch. Einige Ergebnisse der Rolle „Projektleitung“ absolviert und dienten dabei
ersten studentischen Evaluierung nach der Umstel- weniger der Sensibilisierung der Studierenden für
lung sind in Abb. 6 zusammengefasst. die Arbeit in einem Team.
Speziell für den Bereich der Teamarbeit konzi-
pieren wir zur Zeit mit einer Kollegin und einem
Ausblick Kollegen aus dem Betriebswirtschaftlichen Institut
Nach wie vor ist es für die Studierenden schwierig, Gummersbach ein Simulationsspiel zur Einführung
sich für das Modul PM in neuen, studiengangsüber- in die Dynamik der Teamarbeit (Stumpf & Thomas
greifenden Teams zusammen zu finden und mög- 2003). Hiermit sollen die Studierenden einerseits auf
lichst zügig als Team zu arbeiten. die bevorstehende Teamarbeit bei der Bearbeitung
Viele Ergebnisse zeigen, dass für das Projektma- der PM-Projektaufgaben vorbereitet werden. Ande-
nagement die Simulation von Projekten einen guten rerseits möchten wir sie damit für kritische Team-
Einstiegspunkt darstellt (Mandl-Striegnitz, 2001 prozesse in der Praxis sensibilisieren.
und die vielen Folgeveröffentlichungen zu SESAM).
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 54
Software-Projektmanagement lernen ohne Projekt
Mario Winter, TH Köln
Danksagung Henrich, A. (2001). Management von Softwarepro-
jekten. Kurs 1895. Hagen: FernUniversität.
Der Autor dankt den Kollegen Holger Günther und
Lutz Köhler sowie unseren Mitarbeiterinnen und Hummel, O. (2013). Transparente Bewertung von
Mitarbeitern Beate Breiderhoff, Konstantin Dimit- Softwaretechnik-Projekten in der Hochschul-
riou, Guido Münster, Alex Maier, Patrick Oden- lehre. Proc. SEUH 11. dpunkt.verlag, Heidel-
wald, Beate Otztronsek, Uwe Poborski, Pascal berg.
Schönthier und Marc Schwede für die vielen leben- Kerzner, H. (2009). Projekt-Management. Bonn:
dig geführten Diskussionen und das konstruktive mitp-Verlag.
Miteinander bei der Durchführung und Entwick-
Mandl-Striegnitz, P. (2001) Qualifizierte Software-
lung unserer Veranstaltung Projektmanagement!
Projektmanager durch simulationsbasierte Aus-
Wertvolle Unterstützung bei der Umsetzung der
bildung. Proc. SEUH 7. dpunkt.verlag, Heidel-
kompetenzorientierten Lehre und Prüfungformen
berg.
(Constructive Alignment) in Phase IV leistete das
Zentrum für Lehrentwicklung der TH Köln, insbe- Miller, M. D.; Linn, R. L. & Gronlund, N. E. (2008).
sondere Susanne Gotzen, Birgit Sczyrba sowie Oli- Measurement and Assessment in Teaching.
ver Reis von der Universität Paderborn während der (10th Edition), New York, Pearson Education
Multiplikatoren-Ausbildung zu kompetenzorien- Ltd.
tierten Prüfungen. Reis, O. (2010). Kompetenzorientierte Prüfungen –
Wer sind sie und wenn ja wie viele? In: Ter-
Literatur buyken, G. (Hg.) In Modulen lehren, lernen und
prüfen.. Loccum: S. 157-183.
Aichele, C. &. S. M. (2014). IT-Projektmanagement.
Berlin: Springer Vieweg. Stumpf, S. & Thomas, A. (Hrsg.) (2003) Teamarbeit
und Teamentwicklung. Reihe: Psychologie für
Anderson, L. W.; Krathwohl, D. R. et al. (2001). A
das Personalmanagement - Band 22, Hogrefe,
Taxonomy for Learning, Teaching, and As-
Göttingen.
sessing: A Revision of Bloom's Taxonomy of Ed-
ucational Objectives. Complete Edition. New Szczyrba, B.; Wildt, J. & Dany, S. (2008). Prüfungen
York, Pearson/Longman. auf die Agenda! Bielefeld, AHD/wbv, Verlag W.
Bertelsmann.
Balzert, H. (1996). Lehrbuch der Software-Technik
(Bd. 1). Software-Entwicklung. 1. Aufl., Spekt- Thurner, V.; Böttcher, A.; et al. (2015): Lernziele für
rum-Akademischer Verlag, Heidelberg. die Kompetenzentwicklung auf höheren Taxo-
nomiestufen. Proc. SEUH 12. http://ceur-
Balzert, H. (1998). Lehrbuch der Software-Technik
ws.org/Vol-1332/
(Bd. 2). Software-Management. 1. Aufl., Spek-
trum-Akademischer Verlag, Heidelberg. Walzik, S. (2012). Kompetenzorientiert prüfen: Leis-
tungsbewertung an der Hochschule in Theorie
Biggs, J.; Tang, C. (2011). Teaching for Quality
und Praxis, Opladen & Toronto, UTB GmbH.
Learning at University. Maidenhead, Open Uni-
versity Press/McGraw Hill. Weiss, Y.; Kaenders, R. (2018). Die Kompetenzfalle.
Spektrum der Wissenschaft, Ausgabe 9/18, S. 80-
Böttcher, A. & Thurner, V. (2011). Kompetenzorien-
85.
tierte Lehre im Software Engineering. Proc.
SEUH 10. dpunkt.verlag, Heidelberg.
Broy, M. & Kuhrmann, M. (2013). Projektorganisa-
tion und Management im Software Engineering.
Berlin: Springer Vieweg.
Feyhl, A. & Feyhl, E. (1996). Management und Con-
trolling von Softwareprojekten. Gabler Wirt-
schaftsverlag, Wiesbaden.
Fleischmann, A. & Spies, K. (2005). Teamtraining für
Software-Ingenieure. Proc. SEUH 9. dpunkt.ver-
lag, Heidelberg.
Friedlein, A. (2003). Web-Projektmanagement.
dpunkt.verlag, Heidelberg.
Grupp, B. (1998). Qualifizierung zum Projektleiter:
DV-Projektmanagement im Wandel. 4. Auflage,
Computerwoche-Verlag, München.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 55