Projektmanagement spielend lernen Alexander Nassal, Institut für Programmiermethodik und Compilerbau, Universität Ulm alexander.nassal@uni-ulm.de Zusammenfassung vom Projektmanagement unabhängigen Bearbeitung Um den Studierenden schon früh ein Gefühl für das der Projektinhalte. Daher sind solche Projekte als Projektmanagement und den damit verbundenen Auf- Grundlage einer Übung im Bereich des Projektma- gaben und Probleme zu vermitteln, haben wir ein nagements nur sehr bedingt geeignet. Spiel entwickelt, das auf dem Projektmanagement- Ein möglicher Lösungsansatz ist es, Ausschnitte aus werkzeug MS Project basiert. Unter Verwendung ei- einem fiktiven oder realen Projekt zu verwenden und ner umfangreichen Simulation können damit die in diese Teilprobleme als Übung zu bearbeiten. Da viele MS Project erstellten Projektpläne simuliert werden. Aspekte sich nicht nur auf einzelne Teile sondern auf Die Studierenden können dadurch sofort erkennen, das ganze Projekt beziehen, lässt sich damit allerdings wie gut ihre Planung ist und wo Probleme auftreten. nicht alles abdecken. Ziel dabei ist es, den Studierenden eine Möglichkeit Da Projektmanagement viel mit Mitarbeiterführung anzubieten, spielerisch und ohne Risiko verschiede- und den damit verbundenen weichen Faktoren ne Projektmanagementstrategien unter verschiedenen zu tun hat, ist es oft schwierig konkrete Regeln Bedingungen auszuprobieren. Dabei können die Spie- oder Handlungsvorgaben für einzelne Situationen ler alle in MS Project vorhandenen Funktionen und anzugeben. Die Studierenden müssen lernen, ent- Werkzeuge nutzen. sprechende Situationen zu erkennen, zu bewerten, In diesem Beitrag beschreiben wir das Spiel in sei- zu lösen und dabei das Projekt als Gesamtes zu nem Aufbau und Ablauf. Um unsere Arbeit besser be- berücksichtigen. Dabei geht es nicht nur um das zu werten zu können, haben wir das Spiel mittels einer erstellende Produkt, sondern auch um die beteiligten Befragung evaluiert. Eine kurze Zusammenfassung Mitarbeiter und weitere Aspekte, wie beispielsweise dieser Evaluation findet sich am Ende dieses Beitrags. die Marktreputation des Unternehmens. Als einen ersten Ansatz zur Bewältigung der oben Motivation beschriebenen Problematik haben wir das hier vor- Die Lehre im Bereich der Softwaretechnik, insbeson- gestellte Planspiel entwickelt. Dazu haben wir die dere im Bereich des Projektmanagements, stellt die eigentliche, sonst aufwändige und teure Projektarbeit Lehrenden vor die große Herausforderung, den Stu- als Simulation in das Projektmanagementwerkzeugs dierenden dieses wichtige Thema verständlich und Microsoft Project (Microsoft Corporation, 2013) von nachvollziehbar zu vermitteln. Neben der Kenntnis Microsoft (im Folgenden als MS Project bezeichnet) der verschiedenen Methoden und ihren Einsatzfeldern integriert. Damit ermöglichen wir den Studierenden, ist es vor allem die Erfahrung, die einen guten Soft- das in MS Project geplante Projekt auch tatsächlich wareingenieur ausmacht. Diese lässt sich jedoch nicht durchzuführen und durch geeignetes Feedback des durch Theorie im Rahmen einer Vorlesung vermitteln, Spiels zu sehen, wie erfolgreich die eigene Planung sondern setzt persönliche Aktivität der Lernenden vor- war. Im Gegensatz zu einem realen Projekt können aus. dabei problemlos und in kurzer Zeit verschiedene Lö- Vor allem im Bereich des Projektmanagements ist es sungsansätze ausprobiert und verglichen werden. aufwändig, den Studierenden dafür ein entsprechen- Durch die Integration des Spiels in eine umfang- des Übungsangebot zu machen. Ziel des Übungsbe- reiche und weit verbreitete Software stehen den triebs sollte es sein, den Studierenden die komplexen Spielern viele ausgereifte Werkzeuge der modernen Zusammenhänge in einem Projekt zu verdeutlichen Projektplanung zur Verfügung, ohne dass diese und es ihnen zu ermöglichen ein Gefühl für die Proble- speziell für das Spiel entwickelt werden müssen. Den me und Schwierigkeiten im Gesamten zu entwickeln. Spielern ist es so beispielsweise möglich, die in MS Im Gegensatz zu technischeren Fächern lassen sich Project vorhandene Ressourcenplanung zu verwen- für Projektmanagement nur schwer praxisnahe Bei- den, um zu sehen, wie gut die einzelnen Mitarbeiter spiele und Übungen finden, an denen die Teilneh- ausgelastet sind, und um schnell zu erkennen, ob mer das zuvor erworbene theoretische Wissen selbst einzelnen Mitarbeitern zu viele Aufgaben aufgetra- ausprobieren können. Ein reales Projekt benötigt ne- gen wurden. Als positiven Nebeneffekt lernen die ben dem organisatorischen Aufwand vor allem viel Studierenden dabei auch den Umgang mit MS Project. Zeit und zusätzliche Arbeitskapazität zur eigentlichen, Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 53 Dieser Beitrag ist wie folgt strukturiert: Nach einem gibt außerdem einen tieferen Einblick in die Vor- und kurzen Überblick über bestehende Ansätze und ver- Nachteile der einzelnen Spiele und zeigt ungenutztes wandte Arbeiten folgt eine Beschreibung der Plattform Potential auf. und des verwendeten Simulationsframeworks. Der Einer von Piepers Kritikpunkten ist die oft fehlen- Hauptteil beschreibt den Aufbau und Ablauf des Spiels de Integration von Werkzeugen aus der realen Soft- und liefert ein mögliches Beispielszenario, auf dem wareentwicklung in die Simulationsspiele. Für unser die anschließende Evaluation basiert. Zum Schluss Projekt haben wir den umgekehrten Weg gewählt und bilden wir ein kurzes Fazit und diskutieren mögliche die Simulation direkt in das Werkzeug MS Project Verbesserungen und Erweiterungen, die bislang noch integriert, um den Aspekt des Projektmanagements, nicht umgesetzt wurden. insbesondere der Aufgabenplanung, für die Studenten erfahrbar zu machen. Verwandte Arbeiten Vorhandene Arbeiten zeigen, dass die Idee, Simulatio- Plattform und Simulationsframework nen und Spiele in der Softwaretechniklehre einzuset- Um die Simulation nahtlos in MS Project zu integrie- zen, nicht neu ist. Die meisten Projekte fokussieren ren, wurde das Spiel als AddIn unter Verwendung dabei einen bestimmten Schwerpunkt. So konzentrie- der Office-API entwickelt. Nach der Installation des ren sich beispielsweise SimjavaSP (Shaw u. Dermoudy, AddIns stehen damit alle Funktionen direkt in MS 2005) auf Wasserfall- und Spiralmodell und SimVBSE Project zur Verfügung, weitere Werkzeuge werden (Jain u. Boehm, 2006) auf die Thematik des Value- nicht benötigt. Das AddIn kann über die API auf Based Engineering. nahezu alle Funktionen und Daten von MS Project Durch eine Storyline und zusätzliche Spielinhalte zugreifen und somit die Verbindung zwischen MS kann der Spielspaß entsprechend erhöht werden, wie Project und dem Simulationsframework herstellen. The Incredible Manager (de Oliveira Barros u. a., 2006) zeigt. Es gab in der Vergangenheit auch Versuche, Um eine umfassende und realitätsnahe Simulati- Lernaspekte in bestehende Spiele wie beispielsweise on der Vorgänge in einem Projekt durchführen zu Second Live zu integrieren (Ye u. a., 2007). können, haben wir das in (Nassal, 2014) vorgestell- Andere Projekte verfolgen den Ansatz, eine te Framework für Planspiele im Bereich des Softwa- Plattform zur Verfügung zu stellen, mit der eigene reengineering verwendet. Dieses Framework wurde Lerninhalte selbst gestaltet und – meist in Form eines speziell für den Einsatz in Lernspielen im Bereich der Simulationsmodells und zusätzlichem Inhalt für die Softwaretechniklehre entwickelt und enthält neben geeignete textuelle und graphische Präsentation – den notwendigen Simulationsmodellen alle weiteren zu einem Spiel zusammengesetzt werden können. Elemente, die wir für die Simulation in unserem Spiel Eines der ersten Projekte dieser Kategorie war das benötigen. SESAM Projekt (Ludewig u. a., 1992) mit einem Das Simulationsmodell des Frameworks geht deut- Schwerpunkt auf dem Qualitätssicherungsaspekt im lich über die einfachen Berechnungen hinaus, wie Softwareentwicklungsprozess. Das umfangreichste sie in einigen vergleichbaren Spielen zu finden sind. uns bekannte Projekt auf diesem Gebiet ist SimSE Stattdessen wurden Modelle basierend auf Erkennt- (Navarro, 2006) der University of California, Irvine, nissen der Arbeits- und Lernpsychologie verwendet, das neben vielen Beispielszenarien für die unter- und zu einem komplexeren Gesamtmodell kombiniert. schiedlichsten Vorgehensmodelle auch umfangreiche So werden beispielsweise die charakterlichen Eigen- Editoren zur Erstellung eigener Inhalte bereitstellt. schaften der Mitarbeiter, ihr Lernverhalten, ihr Ge- sundheitszustand und ihre Belastbarkeit berücksich- Alle oben genannten Arbeiten versuchen einen oder tigt. Ein eigenes Modell für die Motivation regelt die mehrere Schwerpunkte des Software Engineering mit Arbeitsleistung und das Verhalten der Mitarbeiter. Der Hilfe einer eigens dafür entwickelten Spielumgebung Projektplan wird dabei lediglich als Vorgabe verwen- zu vermitteln. Dabei können Schwierigkeitsgrad und det, das tatsächliche Verhalten der Mitarbeiter kann benötigte Hilfestellungen gut an die Vorkenntnisse je nach Situation entsprechend davon abweichen. Das und Bedürfnisse des Spielers angepasst werden. Durch spiegelt die Realität besser wider, als wenn der Pro- die künstlich geschaffene Spielumgebung wirkt ein jektplan strikt nach Vorgabe abgearbeitet wird. solches Spiel aber oft aufgesetzte und realitätsfern. Durch die Verwendung eines detaillierten Modells Dieser Effekt kann durch ein einfach gehaltenes Simu- wird es für den Spieler notwendig, sich neben der Auf- lationsmodell verstärkt werden, das sich auf den Kern wandsschätzung, Abhängigkeits- und Terminplanung des zu vermittelnden Schwerpunkts beschränkt und auch Gedanken über den richtigen Einsatz seiner keine Randeffekte berücksichtigt. Mitarbeiter zu machen, um ein vorgegebenes Problem In der Arbeit Alles nur Spielerei? Neue Ansätze für erfolgreich lösen zu können. digitales spielbasiertes Lernen von Softwareprozessen (Pieper, 2013) werden die oben genannten Projekte Das Framework arbeitet auf einer Datenstruktur, die anhand verschiedener Kriterien verglichen. Die Arbeit das Vorgehensmodell, die Rahmenbedingungen des 54 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 Projekts, die dazugehörigen Mitarbeiter mit ihrem je- Sind keine Mitarbeiter vorgegeben, muss der Spieler weiligen Charakter und weiteren Eigenschaften, sowie sich diese über den Arbeitsmarkt zusammenstellen. das zu entwickelnde Produkt festlegt. Die Datenstruk- Der Arbeitsmarkt wird ebenfalls über das Sze- tur wird dabei in Teilen von der Simulation bei deren nario konfiguriert. Hier können Parameter wie Ausführung fortgeschrieben. Des Weiteren kann diese Durchschnittsgehalt, Durchschnittsfähigkeiten, die Datenstruktur auch während der Simulation verän- Anzahl der verfügbaren Arbeitskräfte und Ähnliches dert werden, um beispielsweise besondere Ereignisse festgelegt werden. Der Arbeitsmarkt kann auch wie den Ausfall eines Mitarbeiters oder veränderte vollständig deaktiviert werden. In diesem Fall ist Anforderungen an das Produkt zu realisieren. der Spieler auf den vorgegebenen Mitarbeiterstamm Das Vorgehensmodell legt fest, welche Aktivitäten beschränkt und kann diesen nicht verändern. unter welchen Bedingungen durchgeführt werden können. Als Basisaktivitäten stehen Entwicklungsar- Eines der Lernziele des Spiels ist es, dem Spieler beit, Qualitätsarbeit und Kommunikation zur Verfü- ein bestimmtes Vorgehensmodell und die damit ver- gung. Jeder Aktivitätstyp wirkt sich unterschiedlich bundenen Aktivitäten und Rollen zu vermitteln. Das auf das zu entwickelnde Produkt und die Mitarbei- Vorgehensmodell ist im Szenario definiert und kann ter aus. Entwicklungsarbeit bewirkt einen Fortschritt vom Spieler im Spiel nachgeschlagen werden. Dafür bei den Produktartefakten. Qualitätsarbeit findet und kann im Szenario neben den Parametern der Akti- behebt Fehler, die durch Entwicklungsarbeit in den vitäten und Rollen jeweils ein Beschreibungs- und Artefakten entstanden sind und erhöht damit die Qua- Erklärungstext hinterlegt werden. Zusätzlich zu den lität der Artefakte. Kommunikationsarbeit hat keinen Texten werden auch alle relevanten Abhängigkeiten Einfluss auf das Produkt, sondern dient dazu, Wissen angezeigt. Dargestellt werden beispielsweise die Ar- zwischen den einzelnen Mitarbeitern oder Gruppen tefakttypen, die mittels einer bestimmten Aktivität von Mitarbeitern auszutauschen. bearbeitet werden können, die Rollen, die für eine Ak- Wir erzeugen die benötigte Datenstruktur aus ei- tivität zuständig sind und weitere Artefakttypen, die nem Szenario, das über das AddIn geladen werden einen potentiellen Einfluss auf die Bearbeitung haben kann. So können ohne großen zusätzlichen Aufwand können, falls das im Produkt entsprechend definiert unterschiedlichste Szenarien für unser Spiel erstellt wurde. werden, ohne das AddIn anpassen zu müssen. Abbildung 1 zeigt die Entwurfsaktivität des weiter unten beschriebenen Beispielszenarios. Bearbeitet Let’s play werden können hier sowohl Artefakte mit dem Typ Im Folgenden wird das Spiel in seinem Aufbau und Entwurfsdokument, als auch Artefakte mit dem Typ Ablauf beschrieben und die Entwurfsentscheidungen, UI Spezifikation. Außerdem ist zu erkennen, dass es die dazu geführt haben, erläutert. sich um eine Entwicklungsaktivität handelt und damit Da ein Wettbewerb zwischen den Studierenden oft ein Dokument neu erstellt oder weiterentwickelt wird. eine gute Motivation ist, haben wir für das Spiel ein Score entwickelt, der den Projekterfolg misst und ver- Analog zur Beschreibung des Vorgehensmodells gleichbar macht. Er liefert außerdem ein gutes Feed- kann der Spieler auch eine Beschreibung des Produkts back für die Studierenden und ermöglicht es ihnen, ihr einsehen. Hier werden alle Teilartefakte des Produkts Vorgehen besser zu bewerten. Der Aufbau dieses Sco- aufgelistet und beschrieben. re wird im Anschluss an die Beschreibung des Spiels erläutert. Neben dem Beschreibungstext – der erklärt, um Am Ende dieses Abschnitts steht ein Beispielszena- was für ein Dokument es sich handelt, für was es rio, das den Spielaufbau noch einmal verdeutlichen verwendet wird und wie es erstellt werden kann – ist soll und außerdem als Grundlage für die Evaluation auch der Artefakttyp angeben, der den Bezug zum des Spiels gedient hat. Vorgehensmodell herstellt. Weiterhin sind die im Szenario definierten Kon- Spielaufbau und Ablauf textartefakte und etwaige Voraussetzungen für die Zu Beginn eines Spiels muss ein vorgefertigtes Szena- Bearbeitung aufgelistet. Ein Kontextartefakt ist ein rio geladen werden. Ein Szenario enthält neben den anderes Artefakt, dessen Vollständigkeit und Quali- Simulationsparametern und den Rahmenbedingungen tät einen Einfluss auf die Erstellung des neuen Arte- des Projekts das zu verwendende Vorgehensmodell, fakts hat. So hat beispielsweise der Architekturent- welches wiederum die möglichen Aktivitäten, Rollen wurf einen Einfluss auf die Implementierung. Eine und Artefakttypen vorgibt. Es enthält außerdem das Voraussetzung ist eine Bedingung, die vorgibt, wel- zu entwickelnde Produkt und damit die Menge der chen Zustand andere Artefakte haben müssen, damit Artefakte, die während des Spiels erstellt werden müs- das neue Artefakt bearbeitet werden kann. So können sen. logische und zeitliche Abfolgen in der Entwicklung Je nach Lernziel kann im Szenario ein Projektteam sichergestellt werden. Beispielsweise kann Quellcode definiert sein, mit dem der Spieler das Spiel beginnt. erst dokumentiert werden nachdem er erstellt wurde. Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 55 Abbildung 1: Erläuterung zur Entwurfsaktivität in der Szenariobeschreibung Abbildung 2 zeigt das Produktartefakt Dialoggestal- Tätigkeit und Artefakt können dabei aus einer vor- tung aus dem unten beschriebenen Beispielszenario. gegebenen Liste ausgewählt werden, die über das Es liefert dem Spieler alle Informationen, die Szenario festgelegt ist. Mitarbeiter werden einem Vor- notwendig sind, um das zu entwickelnde Artefakt gang, wie in MS Project üblich, als Ressource zugeord- zu verstehen und es in den Produkt- und Projekt- net. Das erlaubt es, die in MS Project vorhandenen kontext einordnen zu können. Dazu werden neben Werkzeuge und Ansichten zur Ressourcenplanung zu einem beschreibenden Text auch die relevanten nutzen, um damit leichter eine optimale Auslastung Kontextartefakte des Produktartefakts, sowie die für zu erreichen und eine Überlastung der Mitarbeiter zu die Bearbeitung notwendigen Voraussetzungen und verhindern. relevanten Fachbereiche aufgeführt. Neben der Unterstützung zur Ressourcenplanung können auch alle anderen in MS Project integrier- Vorgangsplanung ten Werkzeuge zur Vorgangsplanung verwendet werden. Dazu gehören unter anderem die zeit- Der Kern des Spiels ist der Projektplan, anhand dessen lichen Abhängigkeiten der einzelnen Vorgänge, die Mitarbeiter entscheiden, wann sie welche Tätigkeit sowie deren Gruppierung und Hierarchisierung. durchführen. Die simulierten Mitarbeiter entscheiden Auch Hilfsmittel wie Beschriftung, Einfärbung und hauptsächlich anhand dieses Plans, welche Basisaktio- Kommentierung von Vorgängen stehen zur Verfügung. nen sie in der ihnen vorhandenen Zeit durchführen. Den Projektplan erstellen die Spieler mit den in Die Steuerung der Simulation ist sehr einfach. Der MS Project vorhandenen Werkzeugen. Das Ergebnis in MS Project vorhandene Cursor, der das aktuelle Da- ist die Menge der Vorgänge, welche in MS Project tum in einem Projektplan anzeigt und somit Vergan- typischerweise als Gantt-Diagramm dargestellt wird genheit und Zukunft voneinander trennt, markiert den (Abbildung 3). aktuellen Zeitpunkt der Simulation. Wird ein neues Das AddIn wandelt die Vorgänge aus MS Project Zeitintervall simuliert, läuft der Cursor bis zu diesem in simulationsinterne Aufgaben des Frameworks um. Zeitpunkt vor. Ein Vorgang in MS Project besitzt folgende für die Die Simulation wird über das Simulationsribbon Simulation wichtige Attribute: (siehe Abbildung 4) in MS Project gesteuert. Neben • Einen Start- und Endzeitpunkt der Möglichkeit ein neues Szenario zu laden, bzw. das • Eine Tätigkeit die ausgeführt werden soll geladene Szenario auf die Ausgangssituation zurück- • Ein Artefakt auf dem die Tätigkeit ausgeführt wer- zusetzen, beinhaltet es verschiedene Möglichkeiten den soll die Simulation bis zu einem gewünschten Zeitpunkt • Einen oder mehrere Mitarbeiter, die dem Vorgang auszuführen. Dabei werden die vom Spieler festge- zugewiesen wurden legten Vorgänge verwendet, um den Fortschritt und 56 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 Abbildung 2: Erläuterung zur Dialoggestaltung in der Szenariobeschreibung Abbildung 3: Vorgangsplanung in MS Project die Qualität der Artefakte entsprechend des Simula- der Vergangenheit besser hätte auslasten müssen, tionsmodells und der Parameter, welche im Szenario oder dass er einige Vorgänge besser in einer anderen festgelegt wurden, zu aktualisieren. Reihenfolge hätte planen sollen, kann er diese Fehler korrigieren und die Simulation erneut von Beginn an ausführen. Da sich die Simulation bei mehrfachem Ausführen jeweils gleich verhält, ist das Springen zu einem bestimmten Punkt in der Vergangenheit als zusätzliche Option nicht notwendig. Statt dessen Abbildung 4: Steuerelemente der Simulation kann die Simulation auf den Anfang zurückgesetzt und dann erneut bis zu dem gewünschten Zeitpunkt Um dem Spieler zu ermöglichen, aus seinen Fehlern ausgeführt werden. zu lernen, diese zu korrigieren und die Auswirkungen der Korrekturen zu sehen, kann die Simulation auf den Anfangszustand zurückgesetzt werden. Personalmanagement Geplante Vorgänge bleiben dabei, im Gegensatz zum Neben der Reihenfolge der Vorgänge und ihrer Dau- Zurücksetzen des Szenarios, erhalten. Merkt der er, hat auch die Auswahl der Mitarbeiter einen er- Spieler beispielsweise, dass er seine Mitarbeiter in heblichen Einfluss auf das Ergebnis. Jedem einzelnen Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 57 Mitarbeiter kann über eine Vielzahl verschiedener Pa- Wird ein Bewerber auf dem Arbeitsmarkt ausge- rameter ein ganz individueller Charakter zugewiesen wählt, werden statt den realen Werten die Werte werden. Dieser Charakter bestimmt das Arbeits- und aus dessen Portfolio angezeigt. Das Portfolio eines Lernverhalten, die soziale Interaktion mit der Umwelt Mitarbeiters entspricht einer Bewerbung, in der der und die Fähigkeiten in Bezug auf das Arbeitsfeld eines Mitarbeiter sich selbst beschreibt. Diese Beschreibung Mitarbeiters. Die Werte der Parameter können entwe- kann je nach Charakter des Mitarbeiters entsprechend der im Szenario definiert, oder von der Simulation von den tatsächlichen Werten abweichen. So kann ein während des Spiels zufällig gewählt werden. Mitarbeiter nicht in der Lage sein, seine Fähigkeiten entsprechend gut einzuschätzen, oder er stellt Im realen Leben sind diese Parameter nur schwer sich absichtlich besser oder schlechter dar, als er messbar und selten in irgendeiner Art direkt sicht- tatsächlich ist. Diese Diskrepanz zeigt sich erst nach bar. Ein Projektleiter muss deshalb seine Mitarbeiter der Einstellung des Mitarbeiters. Da eine Einstellung kennen und ein Gefühl dafür entwickeln, wie er sie immer mit einem finanziellen Aufwand und einer entsprechend ihres Charakters am besten einsetzt. Da zeitlichen Verzögerung verbunden ist, kann der in einem Spiel diese Art des Kennenlernens nur schwer Spieler nicht einfach alle Mitarbeiter ausprobieren. umsetzbar ist, müssen wir dem Spieler entsprechen- Es besteht deshalb – wie auch in der Realität – bei de Hilfestellungen geben. Das können beispielsweise der Einstellung eines neuen Mitarbeiters immer ein zusätzliche beschreibende Texte sein, die im Szena- gewisses Risiko, einen ungeeigneten Mitarbeiter rio enthalten sind. Eine weitere Möglichkeit ist das einzustellen. Anzeigen einiger ausgewählter Eigenschaften der Mit- arbeiter. Für unser Spiel haben wir eine Kombination aus beiden Wegen gewählt. Da die Fähigkeiten der Budget und Finanzen Mitarbeiter einen hohen Einfluss auf die Produktivität Ein relevanter Teilaspekt, der zunächst nichts mit der und die Qualität der Arbeit haben, kann zu jedem Softwareentwicklung an sich zu tun hat, aber in na- Mitarbeiter das Fähigkeitsprofil angeschaut werden. hezu jedem Projekt berücksichtigt werden muss, sind die Projektfinanzen. Vor allem bei Szenarien, in denen Abbildung 5 zeigt die Mitarbeiterverwaltung. Bei der Spieler seine Mitarbeiter selbst über den Arbeits- Auswahl eines Mitarbeiters werden rechts dessen Fä- markt bezieht, sind die dadurch entstehenden Kosten higkeiten zu den einzelnen Aufgaben und den pro- relevant und wirken sich teils erheblich auf den Pro- duktspezifisch relevanten Domänen als Balkendia- jekterfolg aus. gramme angezeigt. Zusätzlich wird rechts oben durch Jeder Mitarbeiter kostet Geld. Wie viel wird ent- ein Icon ein Hinweis auf den gesundheitlichen Zu- weder im Szenario festgelegt oder durch den Arbeits- stand des Mitarbeiters eingeblendet. So kann der Spie- markt definiert. Bessere Mitarbeiter kosten tendenziell ler erkennen, wie fit seine Mitarbeiter sind, und diese mehr als Mitarbeiter mit geringeren Fähigkeiten. Es Information bei der Planung der Arbeitspakete berück- gibt dabei allerdings auch Ausnahmen. Der Spieler sichtigen. muss lernen, die Fähigkeiten der Kandidaten in Bezug auf sein Projekt zu beurteilen, um so die richtigen Mitarbeiter auswählen zu können. Dabei muss er be- rücksichtigen, welche Vorteile ein Mitarbeiter für das Projekt hat, aber auch welche Kosten dabei entstehen. In manchen Fällen kann es sinnvoll sein, zwei günsti- gere Mitarbeiter einzustellen als einen teureren, oder umgekehrt. Der Spieler muss dabei auch berücksich- tigen, dass durch die Kommunikation zwischen den Mitarbeitern Arbeitsleistung verloren gehen kann. Mitarbeiter, die nicht ausgelastet sind, verursachen trotzdem Kosten. Daher muss der Spieler gut über- legen, wann er zusätzliche Mitarbeiter einstellt und wann er Mitarbeiter entlässt. Sowohl Einstellung als auch Entlassungen verursachen zusätzliche Kosten. Neben dem Gehalt der Mitarbeiter, das sich von Mitarbeiter zu Mitarbeiter unterscheiden kann und mitunter von deren Tagesarbeitszeit abhängig ist, ha- ben Mitarbeiter auch davon unabhängige, laufende Fixkosten. Zusätzlich gibt es weitere, laufende Fix- kosten für das Projekt an sich, z.B. für Büroräume, Softwarelizenzen und Büromaterial. Zusätzliche, ein- malige Kosten, ebenso wie zusätzliche Einnahmen, Abbildung 5: Mitarbeiterübersicht können im Szenario festgelegt werden. Zusätzliche 58 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 Einnahmen können beispielsweise die Anschubfinan- zierung des Projekts oder regelmäßige Zahlungen des Kunden sein. Alle Kosten und Einnahmen kann der Spieler über den Budgetdialog einsehen und mitver- folgen (siehe Abbildung 6). Abbildung 7: Score und Projektbericht werden die Bewertungen in einem Prozentsatz ausge- drückt. Dabei steht 100% für ein optimales Ergebnis. In wenigen Fällen, wenn beispielsweise beim Projekt- gewinn ein Optimum aufgrund der nach oben offenen Skala nicht definiert werden kann, sind auch Werte größer 100% möglich. Die Vollständigkeit c wird, wie in Formel (1) ge- Abbildung 6: Budgetdialog zeigt, anhand des bearbeiteten Umfangs der einzel- nen Artefakte und des Gesamtumfangs des Produkts Ein negatives Budget kostet zusätzliches Geld für berechnet. die dadurch fälligen Zinsen. Der Spieler sollte deshalb Die Qualität des Produkts wird als die mit dem Um- möglichst gut mit den ihm zur Verfügung stehenden fang der Artefakte gewichtete Summe der einzelnen Mitteln haushalten. Finanzielle Gewinne und Verluste Artefakte berechnet (2). Jedes Artefakt besitzt dabei haben keine direkte Auswirkung auf das Projekt an ein Qualitätslevel aq zwischen 0 und 1. Dabei steht 1 sich. Sie gehen aber in die abschließende Bewertung für absolute Fehlerfreiheit bzw. ein optimales Ergeb- des Projekts ein. nis, 0 für ein vollständig falsches, bzw. aufgrund der Wer gewinnt? – Score und Projektbericht hohen Fehlerzahl unbrauchbares Artefakt. Ein Qua- Der Spieler entscheidet selbst, wann das Projekt endet. litätswert von 1 bzw. 100% entspricht damit einem Typischerweise wurde entweder das Produkt vollstän- Produkt mit maximaler Qualität. dig und in einer annehmbaren Qualität entwickelt, Die Produktwertung ist die Kombination aus Qua- oder das im Szenario festgelegte Enddatum für das lität und Vollständigkeit der Artefakte (3). Da die Projekt wurde überschritten. Das Spiel selbst kann Vollständigkeit absolut in Arbeitsstunden angegeben trotz Projektende beliebig fortgesetzt werden. So kann ist, gehen die Artefaktattribute entsprechend ihres die Projektlaufzeit bei Bedarf auch überschritten wer- Umfangs gewichtet in die Produktwertung ein. Klei- den. ne Artefakte haben daher eine geringere Auswirkung Wichtig für den Lernerfolg ist ein konstantes auf die Produktwertung als Artefakte mit größerem Feedback an den Spieler. Dafür verwenden wir die Umfang. Projektbewertung. Sie besteht aus einem Score und Durch das Szenario wird für jedes Projekt eine Pro- einem zusätzlichen kurzen Projektbericht, der die jektlaufzeit mittels Starttermin und Endtermin vorge- einzelnen Teilaspekte zusammenfasst und bewertet. geben. Eine Überschreitung des Termins ist möglich, Dieser, in Abbildung 7 dargestellte Bericht, kann vom wirkt sich aber negativ auf die Wertung aus. Die Pro- Spieler jederzeit eingesehen werden. So bekommt jektdauer berechnet sich wie in (4) gezeigt, aus der der Spieler auch schon während des Spiels eine vorgegebenen und der tatsächlichen Projektlaufzeit. Rückmeldung, wo sein Projekt steht. Die Kostenwertung wird, wie in (5) gezeigt, anhand des aktuellen Kontostands berechnet. Dabei wird zu- Die Bewertung enthält die wesentlichen Projektbe- sätzlich der bereits umgesetzte Produktumfang be- wertungskategorien: Vollständigkeit, Qualität, Kosten rücksichtigt. Das verhindert eine hohe Wertung, die und Dauer. Vollständigkeit und Qualität können zu ei- zu Beginn des Projekts oder durch das Ansammeln ner Produktbewertung zusammengefasst werden. Um von Finanzmitteln, ohne die Investition in das Produkt einen, auch über mehrere Projekte hinweg vergleich- entstehen könnte. Entsprechend der Annahme, dass baren Wert für die einzelnen Aspekte zu erhalten, ein Produkt mit einem höheren Umfang auch einen Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 59 P veranschlagten Zeit nicht zusätzlich belohnt. Da durch ac ein frühes Beenden des Projekts die Kostenwertung c = Pa∈A (1) as verbessert werden kann, geht dieser Aspekt trotzdem Pa∈A a∈A aq · as indirekt in die Gesamtwertung ein. Qualität = P (2) Es besteht die Möglichkeit, Szenarien ohne Budget- as P a∈A aspekte zu definieren, wenn diese für das Lernziel a∈A ac · aq nicht relevant sind. In diesem Fall entfällt die Kosten- P rodukt = P (3) a∈A as wertung und die Gesamtwertung entspricht nur dem tHeute − tStart Quotienten aus Produktwertung und Projektdauer. Dauer = (4) tEnde − tStart    k·b c b>0 Kosten = max 0, 0.5 + P · Beispielszenario: Softwaregrundprojekt a∈A as 1 sonst (5) Ein wesentlicher Meilenstein der Informatikausbil- dung an der Universität Ulm ist das Softwaregrund- P rodukt · 0.5 Score = + Kosten · 0.5 (6) projekt. Hier kommen die Studierenden zum ersten max(1, Dauer) Mal mit der Softwaretechnik in Berührung. Während sie zu Beginn des Studiums lediglich kleinere Übungs- A : Menge aller Produktartefakte aufgaben implementiert haben, müssen sie im Soft- waregrundprojekt zum ersten Mal ein vollständiges ac : Fortschritt von Artefakt a in Arbeitsstunden System nach ausgewählten Prinzipien der Software- aq : Qualität des Artefakts ∈ [0,1] technik entwickeln. Dieses Praktikum geht über zwei as : Umfang von Artefakt a in Arbeitsstunden Semester und wird von einer Vorlesung zur Software- tHeute : Aktuelles Datum der Simulation technik begleitet. Wir verwenden im Softwaregrundprojekt eine an- tStart : Datum des Projektbeginns gepasste Form der Fusion-Methode nach Coleman et tEnde : Datum des vorgegebenen Projektendes al. (Coleman u. a., 1994) mit einer UML-Erweiterung b : aktueller Kontostand in e angelehnt an die Ideen in (Bittner, 2006). Da die Stu- k : Faktor entsprechend der Gewinnerwartung dierenden noch keinerlei Erfahrung mit Fusion oder anderen Methoden der Softwaretechnik gemacht ha- ben, fällt es ihnen anfänglich oft schwer, sich in der Vielzahl der unterschiedlichen Aktivitäten und zu er- entsprechend höheren Umsatz und Gewinn bedeu- stellenden Artefakte zurechtzufinden. tet, wird die Kostenwertung über den Produktumfang Um den Studierenden möglichst früh einen normiert. Überblick über die wichtigen Elemente des Projekts Um einen relativen Wert für die Wertung zu be- und deren Zusammenhänge zu ermöglichen, haben kommen, muss die Gewinnerwartung k berücksich- wir das Softwaregrundprojekt als Szenario für unser tigt werden. Diese ist im Szenario definiert und hängt Spiel modelliert. Während im Praktikum selbst ein maßgeblich von den Entwicklungskosten und den Zah- konkretes System entwickelt wird, ist das Produkt im lungen des Kunden ab. Ein kostenneutrales Projekt Spiel sehr abstrakt gehalten und von der konkreten wird mit 50% bewertet. Ein Projekt, das die Gewin- Aufgabenstellung des Praktikums unabhängig. nerwartung erfüllt mit 100%. Projekte, die Verluste verursachen, erhalten eine Wertung unter 50%. Wenn im Folgenden vom Softwaregrundprojekt ge- Die Gesamtwertung (6) setzt sich aus den oben be- sprochen wird, ist immer die tatsächliche Lehrveran- schriebenen Teilwertungen zusammen. Dabei enthält staltung gemeint. Dagegen beschreiben wir mit Spiel die Produktwertung die Vollständigkeit und Qualität, oder Szenario das simulierte Projekt in der Spielumge- die Kostenwertung die Vollständigkeit und den Pro- bung. Sowohl die Aktivitäten, als auch die Artefakte jektgewinn bzw. -verlust. Die Kostenwertung enthält des Szenarios leiten sich direkt aus der Aufgaben- indirekt die Projektdauer, da eine längere Projektlauf- stellung und den zu erstellenden Teilergebnissen im zeit aufgrund der laufenden Kosten den Gewinn redu- Softwaregrundprojekt ab. ziert. Produkt- und Kostenwertung gehen zu gleichen Vorgehensmodell Teilen in die Gesamtwertung ein. Da in der Produkt- Das Vorgehensmodell definiert die Rollen, Aktivitäten wertung die Projektlaufzeit nicht enthalten ist, muss und Artefakttypen im Projekt. Da das Softwaregrund- diese hier besonders berücksichtigt werden. Dazu wird projekt so ausgelegt ist, dass jeder der Studierenden die Produktwertung durch die zur veranschlagten Pro- jede der unterschiedlichen Aktivitäten selbst mindes- jektlaufzeit relativen tatsächlichen Laufzeit geteilt. tens einmal durchgeführt hat, benötigen wir kein Um zu verhindern, dass Anomalien in der Bewer- besonderes Rollenkonzept, welches die einzelnen tung entstehen, weil ein Projekt sehr früh beendet Mitarbeiter auf ihre Aufgaben einschränkt. wird, wird eine Projektlaufzeit unter der im Szenario 60 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 Die Studierenden müssen im Laufe des Projekts jekt erstellt werden. Sie bauen zum Teil aufeinander sieben unterschiedliche Aktivitäten ausführen: auf bzw. beeinflussen sich gegenseitig. Diese Abhän- • Kontextanalyse: Zu Beginn des Projekts muss an- gigkeiten sind auch im Szenario als Voraussetzungen hand von Produktskizzen und Kundengesprächen und Einflüsse modelliert worden. So beeinflussen bei- herausgefunden werden, was der Kunde für ein spielsweise die Programmierkonventionen die Quali- System wünscht. Diese Erkenntnisse müssen ge- tät der Implementierung und Tests können nicht ohne eignet dokumentiert bzw. modelliert werden. Die das vorherige Erstellen der entsprechenden Testpläne Kontextanalyse bearbeitet Artefakte des Typs An- durchgeführt werden. forderungsdokument und UI Spezifikation. Das Produkt besteht aus folgenden Artefakten: • Entwurf: Mittels der Entwurfsaktivitäten wird auf • Anforderungsdokumente: Überblick, Fachwis- Basis der Dokumente, die während der Kontext- sen, Anwendungsfälle, Szenarien, Systemaufga- analyse erstellt wurden, das Architekturdesign des ben, Nichtfunktionale Anforderungen, Domänen- Systems entwickelt. Beim Entwurf werden Arte- modell, Schnittstellenmodell und Pflichtenheft fakte des Typs Entwurfsdokument bearbeitet. • UI Spezifikationen: Dialogstruktur, Dialoggestal- • Implementierung: Die Implementierungsaktivi- tung und Nutzungskonzept tät beschreibt sowohl das Erstellen des Quellcodes, • Entwurfsdokumente: Datenbanklayout, Kommu- als auch dessen Dokumentation. Dabei werden Ar- nikationsmodell, Klassenmodell und Methodenbe- tefakte des Typs Implementierung bearbeitet. schreibung • Dokumentation: Neben der inhärenten Doku- • Implementierung: Systemkern, Tools, Datenban- mentation der einzelnen Artefakte, ist für vie- kanbindung, Übergreifende UI Konzepte und fünf le Bereiche eine zusätzliche Dokumentation, wie Komponenten mit jeweils einem Artefakt für Be- beispielsweise ein Benutzerhandbuch, notwendig. nutzeroberfläche und Logik. Dabei werden Artefakte des Typs Dokumentation • Controlling: Projektplan und Rollenverteilung erstellt. • Qualitätssicherung: Allgemeine Testrichtlinien • Projektplanung: Diese Aktivität befasst sich mit und jeweils ein Testplan zu jedem Implementie- allem, was zur Planung und Steuerung des Pro- rungsartefakt. jekts gehört. Der dazugehörige Artefakttyp ist Con- • Dokumentation: Programmierkonventionen, Ar- trolling. chitekturbeschreibung, Komponentendiagramm, • Qualitätssicherung: Vorbereitende und beglei- Beschreibung des Gesamtkonzepts, Produkt- und tende Maßnahmen zur Qualitätssicherung. Erstellt Lizenzlisten, Datenbankbeschreibung, Installati- werden Artefakte des Typs Qualitätssicherung. onsanleitung, Benutzerdokumentation und Pro- • Testen: Dient zur Verbesserung der Qualität von jekttagebuch. Artefakten des Typs Implementierung. Mitarbeiter Alle genannten Aktivitäten, mit Ausnahme von Tes- Das Softwaregrundprojekt wird in Teams zu jeweils ten, sind Entwicklungsaktivitäten, die dazu dienen, sechs Studenten durchgeführt. Zu Beginn arbeiten da- verschiedene Artefakte zu erstellen. Testen ist eine bei alle gemeinsam an der Kontextanalyse. Nachdem Qualitätssicherungsaktivität, die dazu dient, die Quali- diese Phase mit der Erstellung des Pflichtenhefts ab- tät von bestehenden Artefakten zu verbessern, indem geschlossen wurde, werden die Verantwortlichkeiten die darin enthaltenen Fehler aufgedeckt und behoben für die folgenden Aufgaben unter den Teammitglie- werden. dern aufgeteilt. Es gilt aber weiterhin, dass sich jedes Produkt Teammitglied an allen Aufgaben beteiligen soll, um Das zu entwickelnde Produkt besteht aus ca. 60 Ar- in jeden Bereich Einblick zu erhalten. Lediglich die tefakten. Jedes dieser Artefakte ist einem der Arte- Schwerpunkte der einzelnen Teammitglieder können fakttypen zugeordnet. Die einzelnen Artefakte haben sich unterscheiden. einen individuellen Schwierigkeitsgrad und stellen Die Verantwortlichkeitsbereiche sind Systemarchi- unterschiedliche Anforderungen an die fachlichen Fä- tektur, Qualitätssicherung, Verifikation und Validierung, higkeiten der Mitarbeiter. Der Umfang der einzelnen Dokumentation, Infrastruktur und Projektverwaltung Artefakte ist ebenfalls unterschiedlich. und Projektmanagement. Die Implementierung ist kein Den Artefakten sind teilweise ein oder mehrere eigener Bereich, da sich hier alle Studenten in glei- der vier Fachbereiche UML, Gestaltung, Relationale chem Umfang beteiligen sollen. Datenbanken und Objektorientierte Programmierung Im Szenario ist jeweils ein Mitarbeiter definiert, der als Schwerpunkt zugeordnet. Je besser sich diese von seinem Fähigkeitsprofil gut zu einem der Bereiche Fachbereiche mit den entsprechenden Fähigkeiten der passt. Der Bereich Projektmanagement wird vom Spie- zuständigen Mitarbeiter decken, umso besser sind die ler selbst übernommen und bedarf deshalb keinem Ergebnisse der Aktivitäten. simulierten Mitarbeiter. Die Projektverwaltung lässt sich im Szenario nicht sinnvoll umsetzen, da es sich Alle im Szenario definierten Artefakte müssen von hierbei um eine übergeordnete Aufgabe handelt. Da- den Studierenden später auch im Softwaregrundpro- her wurde Projektverwalter und Projektleiter jeweils Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 61 ein Fähigkeitsprofil zugewiesen, das die der anderen 7. Abschließende Fragen zur Darstellung der Infor- Mitarbeiter möglichst gut ergänzt. Dadurch steht dem mationen im Spiel und der Bedienbarkeit von Spieler ein ausgewogenes Team zur Verfügung. Spiel und MS Project. Da das Softwaregrundprojekt mit einem festen Pro- Im Folgenden liefern wir eine kurze Zusammenfas- jektteam und ohne Finanzplanung durchgeführt wird, sung der Ergebnisse der Befragung. wurden die Budgetplanung sowie der Arbeitsmarkt Der allgemeine Spielspaß wurde von den Teilneh- deaktiviert. mern als eher gering eingestuft. Dieses Ergebnis ist Dieses Szenario stellt die Grundlage für unsere Eva- nicht weiter überraschend, da sich das Spiel auf die luation dar. reinen Lernaspekte beschränkt und keine zusätzlichen Elemente eingebaut wurden, die dem Spielspaß die- nen. Der Aspekt des Lernens steht bei diesem Spiel ein- Evaluation deutig im Vordergrund und das wird von den Studie- Um den Lerneffekt, die Akzeptanz und die Bedienbar- renden auch so erkannt. Trotzdem würden die meis- keit des Spiels zu testen, haben wir eine Evaluation in ten Teilnehmer das Spiel mit einem anderen Szenario Form einer Onlinebefragung unter den Spielteilneh- erneut spielen und es auch ihren Kommilitonen wei- mern durchgeführt. terempfehlen. Das spricht in unseren Augen für die Da wir das Spiel bisher nur einer kleinen Gruppe Akzeptanz des Spiels als Lernmittel und lässt einen von 14 Studierenden zugänglich gemacht haben, sind gewissen Wiederspielwert erkennen. die quantitativen Ergebnisse dieser Befragung nicht Anhand der Fragen zu MS Project konnten wir fest- ausreichend belastbar und wurden deshalb durch ei- stellen, dass alle Spieler ihre Fähigkeiten in Bezug ne qualitative Evaluation in Form von detailliertem auf das Werkzeug nach dem Spiel höher einschätzen persönlichem Feedback ergänzt. als vor dem Spiel. Daraus schließen wir, dass die Be- nutzung von MS Project im Rahmen des Spiels auch Da die quantitative Auswertung der Ergebnisse der einen Trainingseffekt auf den Umgang mit diesem Onlinebefragung sowohl mit unseren Erwartungen, und ähnlichen Werkzeugen hat. Das wird auch von als auch mit den Ergebnissen des persönlichen den Spielern selbst so gesehen. Alle haben angegeben, Feedbacks nahezu übereinstimmt, sind wir momentan durch das Spiel im Umgang mit MS Project etwas ge- dabei, die Evaluation auf eine weitere Gruppe mit ca. lernt zu haben, wenn auch unterschiedlich viel. Alle 150 Studierenden auszuweiten. Ziel dabei ist es, die Teilnehmer trauen sich jetzt zu, ein einfaches Projekt vorliegenden Ergebnisse auch quantitativ bestätigen mit MS Project zu managen. Auch diejenigen, die an- zu können. gegeben haben, vor dem Spiel mit MS Project nicht zurechtgekommen zu sein. Der verwendete Fragebogen enthält 30 Fragen, die Ein ähnliches Ergebnis konnten wir bei den allge- in sieben Blöcke aufgeteilt sind: meinen Fähigkeiten ein Projekt zu planen beobachten. 1. Fragen zur Erfassung der Rahmensituation. Dazu Auch hier trauen sich jetzt alle Spieler zu, eigenstän- wurden Fragen zum allgemeinen Spielverhalten dig ein Projekt zu planen. Allerdings haben die meis- und zum Umgang mit komplexen Problemen ge- ten angegeben, diese Fähigkeit auch schon vor dem stellt. Spiel besessen zu haben. Trotzdem haben alle Spieler 2. Fragen zum Spielerlebnis. Dazu gehören beispiels- angegeben, durch das Spiel ihre Projektmanagement- weise Spielzeit, Spielspaß und Wiederspielwert fähigkeiten verbessert zu haben. des Spiels. Im Bezug auf die Aktivitäten und Dokumente, die 3. Fragen zur Erfassung des Lernfortschritts in Bezug im Softwaregrundprojekt benötigt werden, haben bei- auf das Werkzeug MS Project. Dazu wurde unter nahe alle Spieler nach Abschluss des Spiels angegeben, anderem der diesbezügliche Kenntnisstand vor die Aktivitäten und Artefakte benennen, erklären und und nach dem Spiel erfasst. in ihren Kontext einordnen zu können. 4. Fragen zur Erfassung des Lernfortschritts in Bezug Mit der Bedienung des Spiels sind die Teilnehmer auf das Vorgehensmodell. Dazu wurde wie bei 3. gut zurechtgekommen. Für die Darstellung des der entsprechende Kenntnisstand vor und nach Szenarios gab es einige Anregungen zur Verbesserung dem Spiel erfasst. Anschließend wurden Fragen der Übersichtlichkeit der Zusammenhänge von gestellt, bei denen die Spieler ihren Kenntnisstand Aktivitäten und Artefakten. Die Meinungen zur in Bezug auf das im Szenario verwendete Vorge- Bedienbarkeit von MS Project, unabhängig des Spiels, hensmodell einschätzen sollten. waren sehr unterschiedlich und gingen von problemlos 5. Analog zu 4. wurde der Lernfortschritt in Bezug bis hin zu nur schlecht bedienbar. auf das Produkt, d.h. die Dokumente und Modelle, die während des Softwaregrundprojekts erstellt Die Ergebnisse zeigen uns, dass die grundsätzliche werden müssen, evaluiert. Konzeption des Spiels erfolgversprechend ist. Es ist 6. Fragen zur Erfassung allgemeiner Lernerfolge im notwendig, einige kleinere Anpassungen vorzuneh- Projektmanagementbereich. men, um das Spiel und dessen Bedienbarkeit weiter 62 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 zu optimieren. Sollte eine umfangreichere Evaluati- eines Projekts. Die Wichtigkeit eines Artefakts ist on diese Ergebnisse bestätigen, ist geplant, das Spiel nicht ausschließlich an dessen Umfang zu erkennen, zusätzlich um neue Konzepte zu erweitern. Eines der sondern setzt zusätzliche Informationen über die Hauptziele wird es dann sein, den Spielspaß zu erhö- Bedeutung bzw. Aufgabe des Artefakts im Produkt hen. voraus. Ein möglicher Ansatz für eine Verbesserung der Berechnung der Score ist es, einen entspre- Fazit und Ausblick chenden zusätzlichen Gewichtungsfaktor für die einzelnen Artefakte einzuführen. Eine mögliche Die Ausbildung von Studierenden im Bereich des Pro- weitere Verfeinerung dieses Ansatzes ist es, die jektmanagements stellt für die Lehrenden eine große Qualität und den Umfang getrennt zu gewichten. Herausforderung dar, da die notwendige praktische So kann bei für das Produkt kritischen Artefakten Erfahrung nur durch geeignete eigenständige Projekt- ein höheres Augenmerk auf die Qualität gefordert arbeit gewonnen werden kann. werden. Mit unserem Planspiel haben wir eine Möglichkeit gefunden, praktische Erfahrung spielerisch zu ge- winnen. Ziel dabei war es, eine möglichst natürliche Am Ende des Spiels soll für den Spieler, neben Spielumgebung zu schaffen, die es dem Spieler dem kurzen Übersichtsbericht, ein zusätzlicher ermöglicht, neben den Erfahrungen im Bereich des Projektbericht über den Verlauf seines Projekts Projektmanagements gleichzeitig den Umgang mit erstellt werden. Je nach Szenario kann dieser dem den dazu benötigten Werkzeugen zu üben. Dazu Spieler auch schon während des Spiels zugänglich haben wir ein Simulationsframework als AddIn in gemacht werden. Ein solcher Bericht kann den MS Project integriert, so dass der Spieler die mit MS zeitlichen Fortschritts- und Qualitätsverlauf der Project geplanten Projektvorgänge direkt simulieren einzelnen Artefakte enthalten. Ebenso hilfreich ist und dadurch die Ergebnisse seiner Planung sofort eine Verfolgung der Eigenschaften der einzelnen sehen kann. Mitarbeiter. So kann schnell erkannt werden, wie sich Projektentscheidungen auf beispielsweise die Die von uns durchgeführte Evaluation hat gezeigt, Motivation, die Fitness oder die Fähigkeiten der dass wir mit dieser Art von Lernspiel einen erfolg- Mitarbeiter ausgewirkt haben. All diese Informationen versprechenden Weg gewählt haben. Um das volle müssen geeignet aufbereitet und dargestellt werden. Potential des Ansatzes nutzen zu können, muss diese Idee noch weiter verfeinert und ausgebaut werden. Bislang unterstützt das Spiel ausschließlich Szenari- Als erster Schritt soll das Feedback, das der Spieler en, die auf linearen Prozessmodellen basieren. Grund durch das Spiel erhält, erweitert werden. Um seine dafür ist die, über die Szenarien definierte, statische Mitarbeiter besser beobachten, einschätzen und steu- Konfiguration des Produkts, bestehend aus seinen ein- ern zu können, ist es sinnvoll, dem Spieler weitere zelnen Artefakten. Bei iterativen und agilen Prozess- Informationen über den Zustand der Mitarbeiter und modellen ist diese Aufteilung zu Beginn des Projekts dem Team im Gesamten zu geben. Dazu gehören zum noch nicht vollständig bekannt. Um nichtlineare Pro- Beispiel die Motivation der Mitarbeiter, das soziale zessmodelle zu unterstützen, muss der Spieler wäh- Gefüge im Team, Vorlieben und Abneigungen der ein- rend des Projekts entscheidet können, welche neuen zelnen Mitarbeiter für bestimmte Aufgaben, sowie di- Artefakte zu erstellen sind oder welche bestehenden verse weiche Eigenschaften wie Lerngeschwindigkeit Artefakte verworfen werden sollen. Damit gibt er vor, und Kommunikationsfähigkeit. All diese Parameter wie er die Entwicklung des Produkts strukturieren werden momentan zwar von der Simulation berück- möchte. Das kann beispielsweise durch das Erstellen sichtigt, dem Spieler aber nicht mitgeteilt. Durch eine einer neuen Iteration bei iterativen Prozessmodellen, geeignete Aufbereitung dieser Informationen und ei- oder innerhalb der Planung eines neuen Sprints bei ner Integration in die Spielumgebung wird das Spiel agilen Prozessmodellen wie SCRUM geschehen. für den Spieler realistischer und besser beherrschbar. In wie weit sich eine solche zusätzliche Funktionali- Ein ähnlicher Ansatz gilt für die Darstellung des tät in das Spiel integrieren lässt, haben wir bislang Produkts, den Anforderungen für die Erstellung der noch nicht getestet. Da das verwendete Simulati- einzelnen Artefakte, sowie deren Abhängigkeiten und onsframework die Möglichkeit bietet, die Struktur Einflüsse untereinander. Hier kann vor allem eine des Produkts während der Simulation zu verändern, geeignete Visualisierung helfen, das zu entwickelnde sind zumindest die technischen Grundlagen dafür Produkt besser zu verstehen und damit auch das vorhanden. Projekt besser steuern zu können. Die Evaluation hat uns gezeigt, dass noch Potential Die Berechnung der Gesamtwertung des Projekts zur Steigerung des Spielspaßes vorhanden ist. Beim berücksichtigt momentan lediglich den Umfang der Design unseres Testszenarios haben wir darauf einzelnen Produktartefakte. In der Realität sind bewusst keinen Wert gelegt. Langfristig macht es aber nicht alle Artefakte gleich wichtig für den Erfolg Sinn ein Spiel zu entwickeln, das dem Spieler auch Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015 63 Spaß macht. Ein möglicher Ansatzpunkt dafür ist eine [Ludewig u. a. 1992] L UDEWIG, J. ; B ASSLER, T. ; D EI - detailliertere Gestaltung der Szenarien. Diese können NINGER , M. ; S CHNEIDER, K. ; S CHWILLE , J.: SESAM- mit zusätzlichen Spielelementen, wie beispielsweise simulating software projects. In: Software Enginee- zufälligen Spielereignissen erweitert werden. Eine ring and Knowledge Engineering, 1992. Proceedings., weitere Möglichkeit das Spiel abwechslungsreicher Fourth International Conference on, 1992, S. 608– zu gestalten ist es, das Szenario um eine Storyline zu 615 ergänzen und diese medial mit Texten, Grafiken und Videos ansprechend zu gestalten. Diese Spielelemente [Microsoft Corporation 2013] M ICROSOFT C ORPORA - TION : Microsoft Project. Version 2013. 2013 zielen primär darauf ab, das Spiel abwechslungsrei- cher und spannender zu machen. [Nassal 2014] N ASSAL, Alexander: A General Frame- work for Software Project Management Simulation Die Erfahrungen, die wir mit diesem Projekt ge- Games. In: Information Systems and Technologies macht haben, zeigen uns, dass es sinnvoll ist, bei (CISTI) 2014, 9th Iberian Conference on Information der Entwicklung von Lernspielen eine möglichst rea- Systems and Technologies, 2014, S. 321–325 litätsnahe Spielumgebung zu schaffen. Es hat sich herausgestellt, dass sich dies durch das Einbeziehen [Navarro 2006] N AVARRO, Emily: SimSE: A Software der Werkzeuge, die in der realen Entwicklung ver- Engineering Simulation Environment for Software wendet werden, umsetzen lässt. Da diese Werkzeuge Process Education, University of California, Irvine, häufig eine gute Erweiterbarkeit mit entsprechenden Diss., 2006 Schnittstellen aufweisen, lässt sich eine Integration [de Oliveira Barros u. a. 2006] O LIVEIRA B ARROS, Már- häufig ohne großen Aufwand realisieren. cio de ; D ANTAS, Alexandre R. ; V ERONESE, Gusta- In unserem Spiel haben wir uns auf den Aspekt des vo O. ; W ERNER, Cláudia Maria L.: Model-driven Projektmanagements beschränkt. Ein interessanter An- Game Development: Experience and Model Enhan- satz für weitere Arbeiten ist es, andere Aspekte des cements in Software Project Management Educati- Software Engineering in ähnlicher Weise in die pas- on. In: Software Process: Improvement and Practice senden Werkzeuge zu integrieren, und diese auf einer 11 (2006), Nr. 4, S. 411–421 höheren Ebene zu einem gemeinsamen Softwarepro- jekt zusammenzufügen. So können die Studierenden [Pieper 2013] P IEPER, Jöran: Alles nur Spielerei? alle relevanten Aspekte im Bereich des Software En- Neue Ansätze für digitales spielbasiertes Lernen von gineering an einem einzigen durchgehenden Projekt Softwareprozessen. In: S PILLNER, Andreas (Hrsg.) ; praktisch üben. L ICHTER, Horst (Hrsg.): Tagungsband des 13. Work- shops “Software Engineering im Unterricht der Hoch- Literatur schulen” (SEUH) 2013, Aachen, CEUR Workshop [Bittner 2006] B ITTNER, M.: Enhancing the Fusion Proceedings Vol. 956, 2013, 131–139 Method to Fusion B: Requirements Engineering and [Shaw u. Dermoudy 2005] S HAW, Katherine ; D ER - Formal Specification, Technischen Universität Berlin, MOUDY , Julian R.: Engendering an Empathy for Diss., 2006 Software Engineering. In: Y OUNG, Alison (Hrsg.) ; [Coleman u. a. 1994] C OLEMAN, Derek ; A RNOLD, T OLHURST, Denise (Hrsg.): ACE Bd. 42, Australian Patrick ; B ODOFF, Stephanie ; D OLLIN, Chris ; Computer Society, 2005 (CRPIT), S. 135–144 G ILCHRIST, Helena ; H AYES, Fiona ; J EREMAES, Paul: Object-oriented Development: The Fusion Method. Up- [Ye u. a. 2007] Y E, En ; L IU, Chang ; P OLACK-WAHL, per Saddle River, NJ, USA : Prentice-Hall, Inc., 1994 J.A.: Enhancing Software Engineering Education Using Teaching Aids in 3-D Online Virtual Worlds. [Jain u. Boehm 2006] JAIN, Apurva ; B OEHM, Bar- In: Frontiers In Education Conference - Global Engi- ry W.: SimVBSE: Developing a Game for Value- neering: Knowledge Without Borders, Opportunities Based Software Engineering. In: CSEE&T, IEEE Without Passports, 2007 Computer Society, 2006, S. 103–114 64 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015