Projektmanagement spielend lernenAlexander Nassal, Institut für Programmiermethodik und Compilerbau, Universität Ulm

alexander.nassal@uni-ulm.de

ZusammenfassungUm den Studierenden schon früh ein Gefühl für dasProjektmanagement und den damit verbundenen Auf-gaben und Probleme zu vermitteln, haben wir einSpiel entwickelt, das auf dem Projektmanagement-werkzeug MS Project basiert. Unter Verwendung ei-ner umfangreichen Simulation können damit die inMS Project erstellten Projektpläne simuliert werden.Die Studierenden können dadurch sofort erkennen,wie gut ihre Planung ist und wo Probleme auftreten.Ziel dabei ist es, den Studierenden eine Möglichkeitanzubieten, spielerisch und ohne Risiko verschiede-ne Projektmanagementstrategien unter verschiedenenBedingungen auszuprobieren. Dabei können die Spie-ler alle in MS Project vorhandenen Funktionen undWerkzeuge nutzen.

In diesem Beitrag beschreiben wir das Spiel in sei-nem Aufbau und Ablauf. Um unsere Arbeit besser be-werten zu können, haben wir das Spiel mittels einerBefragung evaluiert. Eine kurze Zusammenfassungdieser Evaluation findet sich am Ende dieses Beitrags.

MotivationDie Lehre im Bereich der Softwaretechnik, insbeson-dere im Bereich des Projektmanagements, stellt dieLehrenden vor die große Herausforderung, den Stu-dierenden dieses wichtige Thema verständlich undnachvollziehbar zu vermitteln. Neben der Kenntnisder verschiedenen Methoden und ihren Einsatzfeldernist es vor allem die Erfahrung, die einen guten Soft-wareingenieur ausmacht. Diese lässt sich jedoch nichtdurch Theorie im Rahmen einer Vorlesung vermitteln,sondern setzt persönliche Aktivität der Lernenden vor-aus.

Vor allem im Bereich des Projektmanagements ist esaufwändig, den Studierenden dafür ein entsprechen-des Übungsangebot zu machen. Ziel des Übungsbe-triebs sollte es sein, den Studierenden die komplexenZusammenhänge in einem Projekt zu verdeutlichenund es ihnen zu ermöglichen ein Gefühl für die Proble-me und Schwierigkeiten im Gesamten zu entwickeln.

Im Gegensatz zu technischeren Fächern lassen sichfür Projektmanagement nur schwer praxisnahe Bei-spiele und Übungen finden, an denen die Teilneh-mer das zuvor erworbene theoretische Wissen selbstausprobieren können. Ein reales Projekt benötigt ne-ben dem organisatorischen Aufwand vor allem vielZeit und zusätzliche Arbeitskapazität zur eigentlichen,

vom Projektmanagement unabhängigen Bearbeitungder Projektinhalte. Daher sind solche Projekte alsGrundlage einer Übung im Bereich des Projektma-nagements nur sehr bedingt geeignet.

Ein möglicher Lösungsansatz ist es, Ausschnitte auseinem fiktiven oder realen Projekt zu verwenden unddiese Teilprobleme als Übung zu bearbeiten. Da vieleAspekte sich nicht nur auf einzelne Teile sondern aufdas ganze Projekt beziehen, lässt sich damit allerdingsnicht alles abdecken.

Da Projektmanagement viel mit Mitarbeiterführungund den damit verbundenen weichen Faktorenzu tun hat, ist es oft schwierig konkrete Regelnoder Handlungsvorgaben für einzelne Situationenanzugeben. Die Studierenden müssen lernen, ent-sprechende Situationen zu erkennen, zu bewerten,zu lösen und dabei das Projekt als Gesamtes zuberücksichtigen. Dabei geht es nicht nur um das zuerstellende Produkt, sondern auch um die beteiligtenMitarbeiter und weitere Aspekte, wie beispielsweisedie Marktreputation des Unternehmens.

Als einen ersten Ansatz zur Bewältigung der obenbeschriebenen Problematik haben wir das hier vor-gestellte Planspiel entwickelt. Dazu haben wir dieeigentliche, sonst aufwändige und teure Projektarbeitals Simulation in das ProjektmanagementwerkzeugsMicrosoft Project (Microsoft Corporation, 2013) vonMicrosoft (im Folgenden als MS Project bezeichnet)integriert. Damit ermöglichen wir den Studierenden,das in MS Project geplante Projekt auch tatsächlichdurchzuführen und durch geeignetes Feedback desSpiels zu sehen, wie erfolgreich die eigene Planungwar. Im Gegensatz zu einem realen Projekt könnendabei problemlos und in kurzer Zeit verschiedene Lö-sungsansätze ausprobiert und verglichen werden.

Durch die Integration des Spiels in eine umfang-reiche und weit verbreitete Software stehen denSpielern viele ausgereifte Werkzeuge der modernenProjektplanung zur Verfügung, ohne dass diesespeziell für das Spiel entwickelt werden müssen. DenSpielern ist es so beispielsweise möglich, die in MSProject vorhandene Ressourcenplanung zu verwen-den, um zu sehen, wie gut die einzelnen Mitarbeiterausgelastet sind, und um schnell zu erkennen, obeinzelnen Mitarbeitern zu viele Aufgaben aufgetra-gen wurden. Als positiven Nebeneffekt lernen dieStudierenden dabei auch den Umgang mit MS Project.

53Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Dieser Beitrag ist wie folgt strukturiert: Nach einemkurzen Überblick über bestehende Ansätze und ver-wandte Arbeiten folgt eine Beschreibung der Plattformund des verwendeten Simulationsframeworks. DerHauptteil beschreibt den Aufbau und Ablauf des Spielsund liefert ein mögliches Beispielszenario, auf demdie anschließende Evaluation basiert. Zum Schlussbilden wir ein kurzes Fazit und diskutieren möglicheVerbesserungen und Erweiterungen, die bislang nochnicht umgesetzt wurden.

Verwandte ArbeitenVorhandene Arbeiten zeigen, dass die Idee, Simulatio-nen und Spiele in der Softwaretechniklehre einzuset-zen, nicht neu ist. Die meisten Projekte fokussierendabei einen bestimmten Schwerpunkt. So konzentrie-ren sich beispielsweise SimjavaSP (Shaw u. Dermoudy,2005) auf Wasserfall- und Spiralmodell und SimVBSE(Jain u. Boehm, 2006) auf die Thematik des Value-Based Engineering.

Durch eine Storyline und zusätzliche Spielinhaltekann der Spielspaß entsprechend erhöht werden, wieThe Incredible Manager (de Oliveira Barros u. a., 2006)zeigt. Es gab in der Vergangenheit auch Versuche,Lernaspekte in bestehende Spiele wie beispielsweiseSecond Live zu integrieren (Ye u. a., 2007).

Andere Projekte verfolgen den Ansatz, einePlattform zur Verfügung zu stellen, mit der eigeneLerninhalte selbst gestaltet und – meist in Form einesSimulationsmodells und zusätzlichem Inhalt für diegeeignete textuelle und graphische Präsentation –zu einem Spiel zusammengesetzt werden können.Eines der ersten Projekte dieser Kategorie war dasSESAM Projekt (Ludewig u. a., 1992) mit einemSchwerpunkt auf dem Qualitätssicherungsaspekt imSoftwareentwicklungsprozess. Das umfangreichsteuns bekannte Projekt auf diesem Gebiet ist SimSE(Navarro, 2006) der University of California, Irvine,das neben vielen Beispielszenarien für die unter-schiedlichsten Vorgehensmodelle auch umfangreicheEditoren zur Erstellung eigener Inhalte bereitstellt.

Alle oben genannten Arbeiten versuchen einen odermehrere Schwerpunkte des Software Engineering mitHilfe einer eigens dafür entwickelten Spielumgebungzu vermitteln. Dabei können Schwierigkeitsgrad undbenötigte Hilfestellungen gut an die Vorkenntnisseund Bedürfnisse des Spielers angepasst werden. Durchdie künstlich geschaffene Spielumgebung wirkt einsolches Spiel aber oft aufgesetzte und realitätsfern.Dieser Effekt kann durch ein einfach gehaltenes Simu-lationsmodell verstärkt werden, das sich auf den Kerndes zu vermittelnden Schwerpunkts beschränkt undkeine Randeffekte berücksichtigt.

In der Arbeit Alles nur Spielerei? Neue Ansätze fürdigitales spielbasiertes Lernen von Softwareprozessen(Pieper, 2013) werden die oben genannten Projekteanhand verschiedener Kriterien verglichen. Die Arbeit

gibt außerdem einen tieferen Einblick in die Vor- undNachteile der einzelnen Spiele und zeigt ungenutztesPotential auf.

Einer von Piepers Kritikpunkten ist die oft fehlen-de Integration von Werkzeugen aus der realen Soft-wareentwicklung in die Simulationsspiele. Für unserProjekt haben wir den umgekehrten Weg gewählt unddie Simulation direkt in das Werkzeug MS Projectintegriert, um den Aspekt des Projektmanagements,insbesondere der Aufgabenplanung, für die Studentenerfahrbar zu machen.

Plattform und SimulationsframeworkUm die Simulation nahtlos in MS Project zu integrie-ren, wurde das Spiel als AddIn unter Verwendungder Office-API entwickelt. Nach der Installation desAddIns stehen damit alle Funktionen direkt in MSProject zur Verfügung, weitere Werkzeuge werdennicht benötigt. Das AddIn kann über die API aufnahezu alle Funktionen und Daten von MS Projectzugreifen und somit die Verbindung zwischen MSProject und dem Simulationsframework herstellen.

Um eine umfassende und realitätsnahe Simulati-on der Vorgänge in einem Projekt durchführen zukönnen, haben wir das in (Nassal, 2014) vorgestell-te Framework für Planspiele im Bereich des Softwa-reengineering verwendet. Dieses Framework wurdespeziell für den Einsatz in Lernspielen im Bereich derSoftwaretechniklehre entwickelt und enthält nebenden notwendigen Simulationsmodellen alle weiterenElemente, die wir für die Simulation in unserem Spielbenötigen.

Das Simulationsmodell des Frameworks geht deut-lich über die einfachen Berechnungen hinaus, wiesie in einigen vergleichbaren Spielen zu finden sind.Stattdessen wurden Modelle basierend auf Erkennt-nissen der Arbeits- und Lernpsychologie verwendet,und zu einem komplexeren Gesamtmodell kombiniert.So werden beispielsweise die charakterlichen Eigen-schaften der Mitarbeiter, ihr Lernverhalten, ihr Ge-sundheitszustand und ihre Belastbarkeit berücksich-tigt. Ein eigenes Modell für die Motivation regelt dieArbeitsleistung und das Verhalten der Mitarbeiter. DerProjektplan wird dabei lediglich als Vorgabe verwen-det, das tatsächliche Verhalten der Mitarbeiter kannje nach Situation entsprechend davon abweichen. Dasspiegelt die Realität besser wider, als wenn der Pro-jektplan strikt nach Vorgabe abgearbeitet wird.

Durch die Verwendung eines detaillierten Modellswird es für den Spieler notwendig, sich neben der Auf-wandsschätzung, Abhängigkeits- und Terminplanungauch Gedanken über den richtigen Einsatz seinerMitarbeiter zu machen, um ein vorgegebenes Problemerfolgreich lösen zu können.

Das Framework arbeitet auf einer Datenstruktur, diedas Vorgehensmodell, die Rahmenbedingungen des

54 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Projekts, die dazugehörigen Mitarbeiter mit ihrem je-weiligen Charakter und weiteren Eigenschaften, sowiedas zu entwickelnde Produkt festlegt. Die Datenstruk-tur wird dabei in Teilen von der Simulation bei derenAusführung fortgeschrieben. Des Weiteren kann dieseDatenstruktur auch während der Simulation verän-dert werden, um beispielsweise besondere Ereignissewie den Ausfall eines Mitarbeiters oder veränderteAnforderungen an das Produkt zu realisieren.

Das Vorgehensmodell legt fest, welche Aktivitätenunter welchen Bedingungen durchgeführt werdenkönnen. Als Basisaktivitäten stehen Entwicklungsar-beit, Qualitätsarbeit und Kommunikation zur Verfü-gung. Jeder Aktivitätstyp wirkt sich unterschiedlichauf das zu entwickelnde Produkt und die Mitarbei-ter aus. Entwicklungsarbeit bewirkt einen Fortschrittbei den Produktartefakten. Qualitätsarbeit findet undbehebt Fehler, die durch Entwicklungsarbeit in denArtefakten entstanden sind und erhöht damit die Qua-lität der Artefakte. Kommunikationsarbeit hat keinenEinfluss auf das Produkt, sondern dient dazu, Wissenzwischen den einzelnen Mitarbeitern oder Gruppenvon Mitarbeitern auszutauschen.

Wir erzeugen die benötigte Datenstruktur aus ei-nem Szenario, das über das AddIn geladen werdenkann. So können ohne großen zusätzlichen Aufwandunterschiedlichste Szenarien für unser Spiel erstelltwerden, ohne das AddIn anpassen zu müssen.

Let’s playIm Folgenden wird das Spiel in seinem Aufbau undAblauf beschrieben und die Entwurfsentscheidungen,die dazu geführt haben, erläutert.

Da ein Wettbewerb zwischen den Studierenden ofteine gute Motivation ist, haben wir für das Spiel einScore entwickelt, der den Projekterfolg misst und ver-gleichbar macht. Er liefert außerdem ein gutes Feed-back für die Studierenden und ermöglicht es ihnen, ihrVorgehen besser zu bewerten. Der Aufbau dieses Sco-re wird im Anschluss an die Beschreibung des Spielserläutert.

Am Ende dieses Abschnitts steht ein Beispielszena-rio, das den Spielaufbau noch einmal verdeutlichensoll und außerdem als Grundlage für die Evaluationdes Spiels gedient hat.

Spielaufbau und AblaufZu Beginn eines Spiels muss ein vorgefertigtes Szena-rio geladen werden. Ein Szenario enthält neben denSimulationsparametern und den Rahmenbedingungendes Projekts das zu verwendende Vorgehensmodell,welches wiederum die möglichen Aktivitäten, Rollenund Artefakttypen vorgibt. Es enthält außerdem daszu entwickelnde Produkt und damit die Menge derArtefakte, die während des Spiels erstellt werden müs-sen.

Je nach Lernziel kann im Szenario ein Projektteamdefiniert sein, mit dem der Spieler das Spiel beginnt.

Sind keine Mitarbeiter vorgegeben, muss der Spielersich diese über den Arbeitsmarkt zusammenstellen.

Der Arbeitsmarkt wird ebenfalls über das Sze-nario konfiguriert. Hier können Parameter wieDurchschnittsgehalt, Durchschnittsfähigkeiten, dieAnzahl der verfügbaren Arbeitskräfte und Ähnlichesfestgelegt werden. Der Arbeitsmarkt kann auchvollständig deaktiviert werden. In diesem Fall istder Spieler auf den vorgegebenen Mitarbeiterstammbeschränkt und kann diesen nicht verändern.

Eines der Lernziele des Spiels ist es, dem Spielerein bestimmtes Vorgehensmodell und die damit ver-bundenen Aktivitäten und Rollen zu vermitteln. DasVorgehensmodell ist im Szenario definiert und kannvom Spieler im Spiel nachgeschlagen werden. Dafürkann im Szenario neben den Parametern der Akti-vitäten und Rollen jeweils ein Beschreibungs- undErklärungstext hinterlegt werden. Zusätzlich zu denTexten werden auch alle relevanten Abhängigkeitenangezeigt. Dargestellt werden beispielsweise die Ar-tefakttypen, die mittels einer bestimmten Aktivitätbearbeitet werden können, die Rollen, die für eine Ak-tivität zuständig sind und weitere Artefakttypen, dieeinen potentiellen Einfluss auf die Bearbeitung habenkönnen, falls das im Produkt entsprechend definiertwurde.

Abbildung 1 zeigt die Entwurfsaktivität des weiterunten beschriebenen Beispielszenarios. Bearbeitetwerden können hier sowohl Artefakte mit dem TypEntwurfsdokument, als auch Artefakte mit dem TypUI Spezifikation. Außerdem ist zu erkennen, dass essich um eine Entwicklungsaktivität handelt und damitein Dokument neu erstellt oder weiterentwickelt wird.

Analog zur Beschreibung des Vorgehensmodellskann der Spieler auch eine Beschreibung des Produktseinsehen. Hier werden alle Teilartefakte des Produktsaufgelistet und beschrieben.

Neben dem Beschreibungstext – der erklärt, umwas für ein Dokument es sich handelt, für was esverwendet wird und wie es erstellt werden kann – istauch der Artefakttyp angeben, der den Bezug zumVorgehensmodell herstellt.

Weiterhin sind die im Szenario definierten Kon-textartefakte und etwaige Voraussetzungen für dieBearbeitung aufgelistet. Ein Kontextartefakt ist einanderes Artefakt, dessen Vollständigkeit und Quali-tät einen Einfluss auf die Erstellung des neuen Arte-fakts hat. So hat beispielsweise der Architekturent-wurf einen Einfluss auf die Implementierung. EineVoraussetzung ist eine Bedingung, die vorgibt, wel-chen Zustand andere Artefakte haben müssen, damitdas neue Artefakt bearbeitet werden kann. So könnenlogische und zeitliche Abfolgen in der Entwicklungsichergestellt werden. Beispielsweise kann Quellcodeerst dokumentiert werden nachdem er erstellt wurde.

55Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Abbildung 1: Erläuterung zur Entwurfsaktivität in der Szenariobeschreibung

Abbildung 2 zeigt das Produktartefakt Dialoggestal-tung aus dem unten beschriebenen Beispielszenario.Es liefert dem Spieler alle Informationen, dienotwendig sind, um das zu entwickelnde Artefaktzu verstehen und es in den Produkt- und Projekt-kontext einordnen zu können. Dazu werden nebeneinem beschreibenden Text auch die relevantenKontextartefakte des Produktartefakts, sowie die fürdie Bearbeitung notwendigen Voraussetzungen undrelevanten Fachbereiche aufgeführt.

VorgangsplanungDer Kern des Spiels ist der Projektplan, anhand dessendie Mitarbeiter entscheiden, wann sie welche Tätigkeitdurchführen. Die simulierten Mitarbeiter entscheidenhauptsächlich anhand dieses Plans, welche Basisaktio-nen sie in der ihnen vorhandenen Zeit durchführen.

Den Projektplan erstellen die Spieler mit den inMS Project vorhandenen Werkzeugen. Das Ergebnisist die Menge der Vorgänge, welche in MS Projecttypischerweise als Gantt-Diagramm dargestellt wird(Abbildung 3).

Das AddIn wandelt die Vorgänge aus MS Projectin simulationsinterne Aufgaben des Frameworks um.Ein Vorgang in MS Project besitzt folgende für dieSimulation wichtige Attribute:• Einen Start- und Endzeitpunkt• Eine Tätigkeit die ausgeführt werden soll• Ein Artefakt auf dem die Tätigkeit ausgeführt wer-

den soll• Einen oder mehrere Mitarbeiter, die dem Vorgang

zugewiesen wurden

Tätigkeit und Artefakt können dabei aus einer vor-gegebenen Liste ausgewählt werden, die über dasSzenario festgelegt ist. Mitarbeiter werden einem Vor-gang, wie in MS Project üblich, als Ressource zugeord-net. Das erlaubt es, die in MS Project vorhandenenWerkzeuge und Ansichten zur Ressourcenplanung zunutzen, um damit leichter eine optimale Auslastungzu erreichen und eine Überlastung der Mitarbeiter zuverhindern.

Neben der Unterstützung zur Ressourcenplanungkönnen auch alle anderen in MS Project integrier-ten Werkzeuge zur Vorgangsplanung verwendetwerden. Dazu gehören unter anderem die zeit-lichen Abhängigkeiten der einzelnen Vorgänge,sowie deren Gruppierung und Hierarchisierung.Auch Hilfsmittel wie Beschriftung, Einfärbung undKommentierung von Vorgängen stehen zur Verfügung.

Die Steuerung der Simulation ist sehr einfach. Derin MS Project vorhandene Cursor, der das aktuelle Da-tum in einem Projektplan anzeigt und somit Vergan-genheit und Zukunft voneinander trennt, markiert denaktuellen Zeitpunkt der Simulation. Wird ein neuesZeitintervall simuliert, läuft der Cursor bis zu diesemZeitpunkt vor.

Die Simulation wird über das Simulationsribbon(siehe Abbildung 4) in MS Project gesteuert. Nebender Möglichkeit ein neues Szenario zu laden, bzw. dasgeladene Szenario auf die Ausgangssituation zurück-zusetzen, beinhaltet es verschiedene Möglichkeitendie Simulation bis zu einem gewünschten Zeitpunktauszuführen. Dabei werden die vom Spieler festge-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-tionsmodells und der Parameter, welche im Szenariofestgelegt wurden, zu aktualisieren.

Abbildung 4: Steuerelemente der Simulation

Um dem Spieler zu ermöglichen, aus seinen Fehlernzu lernen, diese zu korrigieren und die Auswirkungender Korrekturen zu sehen, kann die Simulationauf den Anfangszustand zurückgesetzt werden.Geplante Vorgänge bleiben dabei, im Gegensatz zumZurücksetzen des Szenarios, erhalten. Merkt derSpieler beispielsweise, dass er seine Mitarbeiter in

der Vergangenheit besser hätte auslasten müssen,oder dass er einige Vorgänge besser in einer anderenReihenfolge hätte planen sollen, kann er diese Fehlerkorrigieren und die Simulation erneut von Beginn anausführen. Da sich die Simulation bei mehrfachemAusführen jeweils gleich verhält, ist das Springenzu einem bestimmten Punkt in der Vergangenheitals zusätzliche Option nicht notwendig. Statt dessenkann die Simulation auf den Anfang zurückgesetztund dann erneut bis zu dem gewünschten Zeitpunktausgeführt werden.

Personalmanagement

Neben der Reihenfolge der Vorgänge und ihrer Dau-er, hat auch die Auswahl der Mitarbeiter einen er-heblichen Einfluss auf das Ergebnis. Jedem einzelnen

57Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Mitarbeiter kann über eine Vielzahl verschiedener Pa-rameter ein ganz individueller Charakter zugewiesenwerden. Dieser Charakter bestimmt das Arbeits- undLernverhalten, die soziale Interaktion mit der Umweltund die Fähigkeiten in Bezug auf das Arbeitsfeld einesMitarbeiters. Die Werte der Parameter können entwe-der im Szenario definiert, oder von der Simulationwährend des Spiels zufällig gewählt werden.

Im realen Leben sind diese Parameter nur schwermessbar und selten in irgendeiner Art direkt sicht-bar. Ein Projektleiter muss deshalb seine Mitarbeiterkennen und ein Gefühl dafür entwickeln, wie er sieentsprechend ihres Charakters am besten einsetzt. Dain einem Spiel diese Art des Kennenlernens nur schwerumsetzbar ist, müssen wir dem Spieler entsprechen-de Hilfestellungen geben. Das können beispielsweisezusätzliche beschreibende Texte sein, die im Szena-rio enthalten sind. Eine weitere Möglichkeit ist dasAnzeigen einiger ausgewählter Eigenschaften der Mit-arbeiter. Für unser Spiel haben wir eine Kombinationaus beiden Wegen gewählt. Da die Fähigkeiten derMitarbeiter einen hohen Einfluss auf die Produktivitätund die Qualität der Arbeit haben, kann zu jedemMitarbeiter das Fähigkeitsprofil angeschaut werden.

Abbildung 5 zeigt die Mitarbeiterverwaltung. BeiAuswahl eines Mitarbeiters werden rechts dessen Fä-higkeiten zu den einzelnen Aufgaben und den pro-duktspezifisch relevanten Domänen als Balkendia-gramme angezeigt. Zusätzlich wird rechts oben durchein Icon ein Hinweis auf den gesundheitlichen Zu-stand des Mitarbeiters eingeblendet. So kann der Spie-ler erkennen, wie fit seine Mitarbeiter sind, und dieseInformation bei der Planung der Arbeitspakete berück-sichtigen.

Abbildung 5: Mitarbeiterübersicht

Wird ein Bewerber auf dem Arbeitsmarkt ausge-wählt, werden statt den realen Werten die Werteaus dessen Portfolio angezeigt. Das Portfolio einesMitarbeiters entspricht einer Bewerbung, in der derMitarbeiter sich selbst beschreibt. Diese Beschreibungkann je nach Charakter des Mitarbeiters entsprechendvon den tatsächlichen Werten abweichen. So kann einMitarbeiter nicht in der Lage sein, seine Fähigkeitenentsprechend gut einzuschätzen, oder er stelltsich absichtlich besser oder schlechter dar, als ertatsächlich ist. Diese Diskrepanz zeigt sich erst nachder Einstellung des Mitarbeiters. Da eine Einstellungimmer mit einem finanziellen Aufwand und einerzeitlichen Verzögerung verbunden ist, kann derSpieler nicht einfach alle Mitarbeiter ausprobieren.Es besteht deshalb – wie auch in der Realität – beider Einstellung eines neuen Mitarbeiters immer eingewisses Risiko, einen ungeeigneten Mitarbeitereinzustellen.

Budget und FinanzenEin relevanter Teilaspekt, der zunächst nichts mit derSoftwareentwicklung an sich zu tun hat, aber in na-hezu jedem Projekt berücksichtigt werden muss, sinddie Projektfinanzen. Vor allem bei Szenarien, in denender Spieler seine Mitarbeiter selbst über den Arbeits-markt bezieht, sind die dadurch entstehenden Kostenrelevant und wirken sich teils erheblich auf den Pro-jekterfolg aus.

Jeder Mitarbeiter kostet Geld. Wie viel wird ent-weder im Szenario festgelegt oder durch den Arbeits-markt definiert. Bessere Mitarbeiter kosten tendenziellmehr als Mitarbeiter mit geringeren Fähigkeiten. Esgibt dabei allerdings auch Ausnahmen. Der Spielermuss lernen, die Fähigkeiten der Kandidaten in Bezugauf sein Projekt zu beurteilen, um so die richtigenMitarbeiter auswählen zu können. Dabei muss er be-rücksichtigen, welche Vorteile ein Mitarbeiter für dasProjekt hat, aber auch welche Kosten dabei entstehen.In manchen Fällen kann es sinnvoll sein, zwei günsti-gere Mitarbeiter einzustellen als einen teureren, oderumgekehrt. Der Spieler muss dabei auch berücksich-tigen, dass durch die Kommunikation zwischen denMitarbeitern Arbeitsleistung verloren gehen kann.

Mitarbeiter, die nicht ausgelastet sind, verursachentrotzdem Kosten. Daher muss der Spieler gut über-legen, wann er zusätzliche Mitarbeiter einstellt undwann er Mitarbeiter entlässt. Sowohl Einstellung alsauch Entlassungen verursachen zusätzliche Kosten.

Neben dem Gehalt der Mitarbeiter, das sich vonMitarbeiter zu Mitarbeiter unterscheiden kann undmitunter von deren Tagesarbeitszeit abhängig ist, ha-ben Mitarbeiter auch davon unabhängige, laufendeFixkosten. 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,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 desKunden sein. Alle Kosten und Einnahmen kann derSpieler über den Budgetdialog einsehen und mitver-folgen (siehe Abbildung 6).

Abbildung 6: Budgetdialog

Ein negatives Budget kostet zusätzliches Geld fürdie dadurch fälligen Zinsen. Der Spieler sollte deshalbmöglichst gut mit den ihm zur Verfügung stehendenMitteln haushalten. Finanzielle Gewinne und Verlustehaben keine direkte Auswirkung auf das Projekt ansich. Sie gehen aber in die abschließende Bewertungdes Projekts ein.

Wer gewinnt? – Score und ProjektberichtDer Spieler entscheidet selbst, wann das Projekt endet.Typischerweise wurde entweder das Produkt vollstän-dig und in einer annehmbaren Qualität entwickelt,oder das im Szenario festgelegte Enddatum für dasProjekt wurde überschritten. Das Spiel selbst kanntrotz Projektende beliebig fortgesetzt werden. So kanndie Projektlaufzeit bei Bedarf auch überschritten wer-den.

Wichtig für den Lernerfolg ist ein konstantesFeedback an den Spieler. Dafür verwenden wir dieProjektbewertung. Sie besteht aus einem Score undeinem zusätzlichen kurzen Projektbericht, der dieeinzelnen Teilaspekte zusammenfasst und bewertet.Dieser, in Abbildung 7 dargestellte Bericht, kann vomSpieler jederzeit eingesehen werden. So bekommtder Spieler auch schon während des Spiels eineRückmeldung, wo sein Projekt steht.

Die Bewertung enthält die wesentlichen Projektbe-wertungskategorien: Vollständigkeit, Qualität, Kostenund Dauer. Vollständigkeit und Qualität können zu ei-ner Produktbewertung zusammengefasst werden. Umeinen, auch über mehrere Projekte hinweg vergleich-baren Wert für die einzelnen Aspekte zu erhalten,

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 offenenSkala nicht definiert werden kann, sind auch Wertegrößer 100% möglich.

Die Vollständigkeit c wird, wie in Formel (1) ge-zeigt, anhand des bearbeiteten Umfangs der einzel-nen Artefakte und des Gesamtumfangs des Produktsberechnet.

Die Qualität des Produkts wird als die mit dem Um-fang der Artefakte gewichtete Summe der einzelnenArtefakte berechnet (2). Jedes Artefakt besitzt dabeiein Qualitätslevel aq zwischen 0 und 1. Dabei steht 1für absolute Fehlerfreiheit bzw. ein optimales Ergeb-nis, 0 für ein vollständig falsches, bzw. aufgrund derhohen Fehlerzahl unbrauchbares Artefakt. Ein Qua-litätswert von 1 bzw. 100% entspricht damit einemProdukt mit maximaler Qualität.

Die Produktwertung ist die Kombination aus Qua-lität und Vollständigkeit der Artefakte (3). Da dieVollständigkeit absolut in Arbeitsstunden angegebenist, gehen die Artefaktattribute entsprechend ihresUmfangs gewichtet in die Produktwertung ein. Klei-ne Artefakte haben daher eine geringere Auswirkungauf die Produktwertung als Artefakte mit größeremUmfang.

Durch das Szenario wird für jedes Projekt eine Pro-jektlaufzeit mittels Starttermin und Endtermin vorge-geben. Eine Überschreitung des Termins ist möglich,wirkt sich aber negativ auf die Wertung aus. Die Pro-jektdauer berechnet sich wie in (4) gezeigt, aus dervorgegebenen und der tatsächlichen Projektlaufzeit.

Die Kostenwertung wird, wie in (5) gezeigt, anhanddes aktuellen Kontostands berechnet. Dabei wird zu-sätzlich der bereits umgesetzte Produktumfang be-rücksichtigt. Das verhindert eine hohe Wertung, diezu Beginn des Projekts oder durch das Ansammelnvon Finanzmitteln, ohne die Investition in das Produktentstehen könnte. Entsprechend der Annahme, dassein Produkt mit einem höheren Umfang auch einen

59Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

c =

∑a∈A ac∑a∈A as

(1)

Qualitat =

∑a∈A aq · as∑

a∈A as(2)

Produkt =

∑a∈A ac · aq∑

a∈A as(3)

Dauer =tHeute − tStart

tEnde − tStart(4)

Kosten = max

(0, 0.5 +

k · b∑a∈A as

·{

c b > 01 sonst

)(5)

Score =Produkt · 0.5max(1, Dauer)

+Kosten · 0.5 (6)

A : Menge aller Produktartefakte

ac : Fortschritt von Artefakt a in Arbeitsstunden

aq : Qualität des Artefakts ∈ [0,1]

as : Umfang von Artefakt a in Arbeitsstunden

tHeute : Aktuelles Datum der Simulation

tStart : Datum des Projektbeginns

tEnde : Datum des vorgegebenen Projektendes

b : aktueller Kontostand in e

k : Faktor entsprechend der Gewinnerwartung

entsprechend höheren Umsatz und Gewinn bedeu-tet, wird die Kostenwertung über den Produktumfangnormiert.

Um einen relativen Wert für die Wertung zu be-kommen, muss die Gewinnerwartung k berücksich-tigt werden. Diese ist im Szenario definiert und hängtmaßgeblich von den Entwicklungskosten und den Zah-lungen des Kunden ab. Ein kostenneutrales Projektwird mit 50% bewertet. Ein Projekt, das die Gewin-nerwartung erfüllt mit 100%. Projekte, die Verlusteverursachen, erhalten eine Wertung unter 50%.

Die Gesamtwertung (6) setzt sich aus den oben be-schriebenen Teilwertungen zusammen. Dabei enthältdie Produktwertung die Vollständigkeit und Qualität,die Kostenwertung die Vollständigkeit und den Pro-jektgewinn bzw. -verlust. Die Kostenwertung enthältindirekt die Projektdauer, da eine längere Projektlauf-zeit aufgrund der laufenden Kosten den Gewinn redu-ziert. Produkt- und Kostenwertung gehen zu gleichenTeilen in die Gesamtwertung ein. Da in der Produkt-wertung die Projektlaufzeit nicht enthalten ist, mussdiese hier besonders berücksichtigt werden. Dazu wirddie Produktwertung durch die zur veranschlagten Pro-jektlaufzeit relativen tatsächlichen Laufzeit geteilt.

Um zu verhindern, dass Anomalien in der Bewer-tung entstehen, weil ein Projekt sehr früh beendetwird, wird eine Projektlaufzeit unter der im Szenario

veranschlagten Zeit nicht zusätzlich belohnt. Da durchein frühes Beenden des Projekts die Kostenwertungverbessert werden kann, geht dieser Aspekt trotzdemindirekt in die Gesamtwertung ein.

Es besteht die Möglichkeit, Szenarien ohne Budget-aspekte zu definieren, wenn diese für das Lernzielnicht relevant sind. In diesem Fall entfällt die Kosten-wertung und die Gesamtwertung entspricht nur demQuotienten aus Produktwertung und Projektdauer.

Beispielszenario: SoftwaregrundprojektEin wesentlicher Meilenstein der Informatikausbil-dung an der Universität Ulm ist das Softwaregrund-projekt. Hier kommen die Studierenden zum erstenMal mit der Softwaretechnik in Berührung. Währendsie zu Beginn des Studiums lediglich kleinere Übungs-aufgaben implementiert haben, müssen sie im Soft-waregrundprojekt zum ersten Mal ein vollständigesSystem nach ausgewählten Prinzipien der Software-technik entwickeln. Dieses Praktikum geht über zweiSemester und wird von einer Vorlesung zur Software-technik begleitet.

Wir verwenden im Softwaregrundprojekt eine an-gepasste Form der Fusion-Methode nach Coleman etal. (Coleman u. a., 1994) mit einer UML-Erweiterungangelehnt an die Ideen in (Bittner, 2006). Da die Stu-dierenden noch keinerlei Erfahrung mit Fusion oderanderen Methoden der Softwaretechnik gemacht ha-ben, fällt es ihnen anfänglich oft schwer, sich in derVielzahl der unterschiedlichen Aktivitäten und zu er-stellenden Artefakte zurechtzufinden.

Um den Studierenden möglichst früh einenÜberblick über die wichtigen Elemente des Projektsund deren Zusammenhänge zu ermöglichen, habenwir das Softwaregrundprojekt als Szenario für unserSpiel modelliert. Während im Praktikum selbst einkonkretes System entwickelt wird, ist das Produkt imSpiel sehr abstrakt gehalten und von der konkretenAufgabenstellung des Praktikums unabhängig.

Wenn im Folgenden vom Softwaregrundprojekt ge-sprochen wird, ist immer die tatsächliche Lehrveran-staltung gemeint. Dagegen beschreiben wir mit Spieloder Szenario das simulierte Projekt in der Spielumge-bung. Sowohl die Aktivitäten, als auch die Artefaktedes Szenarios leiten sich direkt aus der Aufgaben-stellung und den zu erstellenden Teilergebnissen imSoftwaregrundprojekt ab.

VorgehensmodellDas Vorgehensmodell definiert die Rollen, Aktivitätenund Artefakttypen im Projekt. Da das Softwaregrund-projekt so ausgelegt ist, dass jeder der Studierendenjede der unterschiedlichen Aktivitäten selbst mindes-tens einmal durchgeführt hat, benötigen wir keinbesonderes Rollenkonzept, welches die einzelnenMitarbeiter auf ihre Aufgaben einschränkt.

60 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Die Studierenden müssen im Laufe des Projektssieben unterschiedliche Aktivitäten ausführen:• Kontextanalyse: Zu Beginn des Projekts muss an-

hand von Produktskizzen und Kundengesprächenherausgefunden werden, was der Kunde für einSystem wünscht. Diese Erkenntnisse müssen ge-eignet dokumentiert bzw. modelliert werden. DieKontextanalyse bearbeitet Artefakte des Typs An-forderungsdokument und UI Spezifikation.

• Entwurf: Mittels der Entwurfsaktivitäten wird aufBasis der Dokumente, die während der Kontext-analyse erstellt wurden, das Architekturdesign desSystems entwickelt. Beim Entwurf werden Arte-fakte des Typs Entwurfsdokument bearbeitet.

• Implementierung: Die Implementierungsaktivi-tät beschreibt sowohl das Erstellen des Quellcodes,als auch dessen Dokumentation. Dabei werden Ar-tefakte des Typs Implementierung bearbeitet.

• Dokumentation: Neben der inhärenten Doku-mentation der einzelnen Artefakte, ist für vie-le Bereiche eine zusätzliche Dokumentation, wiebeispielsweise ein Benutzerhandbuch, notwendig.Dabei werden Artefakte des Typs Dokumentationerstellt.

• Projektplanung: Diese Aktivität befasst sich mitallem, was zur Planung und Steuerung des Pro-jekts gehört. Der dazugehörige Artefakttyp ist Con-trolling.

• Qualitätssicherung: Vorbereitende und beglei-tende Maßnahmen zur Qualitätssicherung. Erstelltwerden Artefakte des Typs Qualitätssicherung.

• Testen: Dient zur Verbesserung der Qualität vonArtefakten des Typs Implementierung.

Alle genannten Aktivitäten, mit Ausnahme von Tes-ten, sind Entwicklungsaktivitäten, die dazu dienen,verschiedene Artefakte zu erstellen. Testen ist eineQualitätssicherungsaktivität, die dazu dient, die Quali-tät von bestehenden Artefakten zu verbessern, indemdie darin enthaltenen Fehler aufgedeckt und behobenwerden.

ProduktDas zu entwickelnde Produkt besteht aus ca. 60 Ar-tefakten. Jedes dieser Artefakte ist einem der Arte-fakttypen zugeordnet. Die einzelnen Artefakte habeneinen individuellen Schwierigkeitsgrad und stellenunterschiedliche Anforderungen an die fachlichen Fä-higkeiten der Mitarbeiter. Der Umfang der einzelnenArtefakte ist ebenfalls unterschiedlich.

Den Artefakten sind teilweise ein oder mehrereder vier Fachbereiche UML, Gestaltung, RelationaleDatenbanken und Objektorientierte Programmierungals Schwerpunkt zugeordnet. Je besser sich dieseFachbereiche mit den entsprechenden Fähigkeiten derzuständigen Mitarbeiter decken, umso besser sind dieErgebnisse der Aktivitäten.

Alle im Szenario definierten Artefakte müssen vonden Studierenden später auch im Softwaregrundpro-

jekt erstellt werden. Sie bauen zum Teil aufeinanderauf bzw. beeinflussen sich gegenseitig. Diese Abhän-gigkeiten sind auch im Szenario als Voraussetzungenund Einflüsse modelliert worden. So beeinflussen bei-spielsweise die Programmierkonventionen die Quali-tät der Implementierung und Tests können nicht ohnedas vorherige Erstellen der entsprechenden Testplänedurchgeführt werden.

Das Produkt besteht aus folgenden Artefakten:• Anforderungsdokumente: Überblick, Fachwis-

sen, Anwendungsfälle, Szenarien, Systemaufga-ben, Nichtfunktionale Anforderungen, Domänen-modell, Schnittstellenmodell und Pflichtenheft

• UI Spezifikationen: Dialogstruktur, Dialoggestal-tung und Nutzungskonzept

• Entwurfsdokumente: Datenbanklayout, Kommu-nikationsmodell, Klassenmodell und Methodenbe-schreibung

• Implementierung: Systemkern, Tools, Datenban-kanbindung, Übergreifende UI Konzepte und fünfKomponenten mit jeweils einem Artefakt für Be-nutzeroberfläche und Logik.

• Controlling: Projektplan und Rollenverteilung• Qualitätssicherung: Allgemeine Testrichtlinien

und jeweils ein Testplan zu jedem Implementie-rungsartefakt.

• Dokumentation: Programmierkonventionen, Ar-chitekturbeschreibung, Komponentendiagramm,Beschreibung des Gesamtkonzepts, Produkt- undLizenzlisten, Datenbankbeschreibung, Installati-onsanleitung, Benutzerdokumentation und Pro-jekttagebuch.

MitarbeiterDas Softwaregrundprojekt wird in Teams zu jeweilssechs Studenten durchgeführt. Zu Beginn arbeiten da-bei alle gemeinsam an der Kontextanalyse. Nachdemdiese Phase mit der Erstellung des Pflichtenhefts ab-geschlossen wurde, werden die Verantwortlichkeitenfür die folgenden Aufgaben unter den Teammitglie-dern aufgeteilt. Es gilt aber weiterhin, dass sich jedesTeammitglied an allen Aufgaben beteiligen soll, umin jeden Bereich Einblick zu erhalten. Lediglich dieSchwerpunkte der einzelnen Teammitglieder könnensich unterscheiden.

Die Verantwortlichkeitsbereiche sind Systemarchi-tektur, Qualitätssicherung, Verifikation und Validierung,Dokumentation, Infrastruktur und Projektverwaltungund Projektmanagement. Die Implementierung ist keineigener Bereich, da sich hier alle Studenten in glei-chem Umfang beteiligen sollen.

Im Szenario ist jeweils ein Mitarbeiter definiert, dervon seinem Fähigkeitsprofil gut zu einem der Bereichepasst. Der Bereich Projektmanagement wird vom Spie-ler selbst übernommen und bedarf deshalb keinemsimulierten Mitarbeiter. Die Projektverwaltung lässtsich im Szenario nicht sinnvoll umsetzen, da es sichhierbei um eine übergeordnete Aufgabe handelt. Da-her wurde Projektverwalter und Projektleiter jeweils

61Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

ein Fähigkeitsprofil zugewiesen, das die der anderenMitarbeiter möglichst gut ergänzt. Dadurch steht demSpieler ein ausgewogenes Team zur Verfügung.

Da das Softwaregrundprojekt mit einem festen Pro-jektteam und ohne Finanzplanung durchgeführt wird,wurden die Budgetplanung sowie der Arbeitsmarktdeaktiviert.

Dieses Szenario stellt die Grundlage für unsere Eva-luation dar.

EvaluationUm den Lerneffekt, die Akzeptanz und die Bedienbar-keit des Spiels zu testen, haben wir eine Evaluation inForm einer Onlinebefragung unter den Spielteilneh-mern durchgeführt.

Da wir das Spiel bisher nur einer kleinen Gruppevon 14 Studierenden zugänglich gemacht haben, sinddie quantitativen Ergebnisse dieser Befragung nichtausreichend belastbar und wurden deshalb durch ei-ne qualitative Evaluation in Form von detailliertempersönlichem Feedback ergänzt.

Da die quantitative Auswertung der Ergebnisse derOnlinebefragung sowohl mit unseren Erwartungen,als auch mit den Ergebnissen des persönlichenFeedbacks nahezu übereinstimmt, sind wir momentandabei, die Evaluation auf eine weitere Gruppe mit ca.150 Studierenden auszuweiten. Ziel dabei ist es, dievorliegenden Ergebnisse auch quantitativ bestätigenzu können.

Der verwendete Fragebogen enthält 30 Fragen, diein sieben Blöcke aufgeteilt sind:

1. Fragen zur Erfassung der Rahmensituation. Dazuwurden Fragen zum allgemeinen Spielverhaltenund zum Umgang mit komplexen Problemen ge-stellt.

2. Fragen zum Spielerlebnis. Dazu gehören beispiels-weise Spielzeit, Spielspaß und Wiederspielwertdes Spiels.

3. Fragen zur Erfassung des Lernfortschritts in Bezugauf das Werkzeug MS Project. Dazu wurde unteranderem der diesbezügliche Kenntnisstand vorund nach dem Spiel erfasst.

4. Fragen zur Erfassung des Lernfortschritts in Bezugauf das Vorgehensmodell. Dazu wurde wie bei 3.der entsprechende Kenntnisstand vor und nachdem Spiel erfasst. Anschließend wurden Fragengestellt, bei denen die Spieler ihren Kenntnisstandin Bezug auf das im Szenario verwendete Vorge-hensmodell einschätzen sollten.

5. Analog zu 4. wurde der Lernfortschritt in Bezugauf das Produkt, d.h. die Dokumente und Modelle,die während des Softwaregrundprojekts erstelltwerden müssen, evaluiert.

6. Fragen zur Erfassung allgemeiner Lernerfolge imProjektmanagementbereich.

7. Abschließende Fragen zur Darstellung der Infor-mationen im Spiel und der Bedienbarkeit vonSpiel und MS Project.

Im Folgenden liefern wir eine kurze Zusammenfas-sung der Ergebnisse der Befragung.

Der allgemeine Spielspaß wurde von den Teilneh-mern als eher gering eingestuft. Dieses Ergebnis istnicht weiter überraschend, da sich das Spiel auf diereinen Lernaspekte beschränkt und keine zusätzlichenElemente eingebaut wurden, die dem Spielspaß die-nen. Der Aspekt des Lernens steht bei diesem Spiel ein-deutig im Vordergrund und das wird von den Studie-renden auch so erkannt. Trotzdem würden die meis-ten Teilnehmer das Spiel mit einem anderen Szenarioerneut spielen und es auch ihren Kommilitonen wei-terempfehlen. Das spricht in unseren Augen für dieAkzeptanz des Spiels als Lernmittel und lässt einengewissen Wiederspielwert erkennen.

Anhand der Fragen zu MS Project konnten wir fest-stellen, dass alle Spieler ihre Fähigkeiten in Bezugauf das Werkzeug nach dem Spiel höher einschätzenals vor dem Spiel. Daraus schließen wir, dass die Be-nutzung von MS Project im Rahmen des Spiels aucheinen Trainingseffekt auf den Umgang mit diesemund ähnlichen Werkzeugen hat. Das wird auch vonden Spielern selbst so gesehen. Alle haben angegeben,durch das Spiel im Umgang mit MS Project etwas ge-lernt zu haben, wenn auch unterschiedlich viel. AlleTeilnehmer trauen sich jetzt zu, ein einfaches Projektmit MS Project zu managen. Auch diejenigen, die an-gegeben haben, vor dem Spiel mit MS Project nichtzurechtgekommen zu sein.

Ein ähnliches Ergebnis konnten wir bei den allge-meinen Fähigkeiten ein Projekt zu planen beobachten.Auch hier trauen sich jetzt alle Spieler zu, eigenstän-dig ein Projekt zu planen. Allerdings haben die meis-ten angegeben, diese Fähigkeit auch schon vor demSpiel besessen zu haben. Trotzdem haben alle Spielerangegeben, durch das Spiel ihre Projektmanagement-fähigkeiten verbessert zu haben.

Im Bezug auf die Aktivitäten und Dokumente, dieim Softwaregrundprojekt benötigt werden, haben bei-nahe alle Spieler nach Abschluss des Spiels angegeben,die Aktivitäten und Artefakte benennen, erklären undin ihren Kontext einordnen zu können.

Mit der Bedienung des Spiels sind die Teilnehmergut zurechtgekommen. Für die Darstellung desSzenarios gab es einige Anregungen zur Verbesserungder Übersichtlichkeit der Zusammenhänge vonAktivitäten und Artefakten. Die Meinungen zurBedienbarkeit von MS Project, unabhängig des Spiels,waren sehr unterschiedlich und gingen von problemlosbis hin zu nur schlecht bedienbar.

Die Ergebnisse zeigen uns, dass die grundsätzlicheKonzeption des Spiels erfolgversprechend ist. Es istnotwendig, einige kleinere Anpassungen vorzuneh-men, um das Spiel und dessen Bedienbarkeit weiter

62 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

zu optimieren. Sollte eine umfangreichere Evaluati-on diese Ergebnisse bestätigen, ist geplant, das Spielzusätzlich um neue Konzepte zu erweitern. Eines derHauptziele wird es dann sein, den Spielspaß zu erhö-hen.

Fazit und AusblickDie Ausbildung von Studierenden im Bereich des Pro-jektmanagements stellt für die Lehrenden eine großeHerausforderung dar, da die notwendige praktischeErfahrung nur durch geeignete eigenständige Projekt-arbeit gewonnen werden kann.

Mit unserem Planspiel haben wir eine Möglichkeitgefunden, praktische Erfahrung spielerisch zu ge-winnen. Ziel dabei war es, eine möglichst natürlicheSpielumgebung zu schaffen, die es dem Spielerermöglicht, neben den Erfahrungen im Bereich desProjektmanagements gleichzeitig den Umgang mitden dazu benötigten Werkzeugen zu üben. Dazuhaben wir ein Simulationsframework als AddIn inMS Project integriert, so dass der Spieler die mit MSProject geplanten Projektvorgänge direkt simulierenund dadurch die Ergebnisse seiner Planung sofortsehen kann.

Die von uns durchgeführte Evaluation hat gezeigt,dass wir mit dieser Art von Lernspiel einen erfolg-versprechenden Weg gewählt haben. Um das vollePotential des Ansatzes nutzen zu können, muss dieseIdee noch weiter verfeinert und ausgebaut werden.

Als erster Schritt soll das Feedback, das der Spielerdurch das Spiel erhält, erweitert werden. Um seineMitarbeiter besser beobachten, einschätzen und steu-ern zu können, ist es sinnvoll, dem Spieler weitereInformationen über den Zustand der Mitarbeiter unddem Team im Gesamten zu geben. Dazu gehören zumBeispiel die Motivation der Mitarbeiter, das sozialeGefüge im Team, Vorlieben und Abneigungen der ein-zelnen Mitarbeiter für bestimmte Aufgaben, sowie di-verse weiche Eigenschaften wie Lerngeschwindigkeitund Kommunikationsfähigkeit. All diese Parameterwerden momentan zwar von der Simulation berück-sichtigt, dem Spieler aber nicht mitgeteilt. Durch einegeeignete Aufbereitung dieser Informationen und ei-ner Integration in die Spielumgebung wird das Spielfür den Spieler realistischer und besser beherrschbar.

Ein ähnlicher Ansatz gilt für die Darstellung desProdukts, den Anforderungen für die Erstellung dereinzelnen Artefakte, sowie deren Abhängigkeiten undEinflüsse untereinander. Hier kann vor allem einegeeignete Visualisierung helfen, das zu entwickelndeProdukt besser zu verstehen und damit auch dasProjekt besser steuern zu können.

Die Berechnung der Gesamtwertung des Projektsberücksichtigt momentan lediglich den Umfang dereinzelnen Produktartefakte. In der Realität sindnicht alle Artefakte gleich wichtig für den Erfolg

eines Projekts. Die Wichtigkeit eines Artefakts istnicht ausschließlich an dessen Umfang zu erkennen,sondern setzt zusätzliche Informationen über dieBedeutung bzw. Aufgabe des Artefakts im Produktvoraus. Ein möglicher Ansatz für eine Verbesserungder Berechnung der Score ist es, einen entspre-chenden zusätzlichen Gewichtungsfaktor für dieeinzelnen Artefakte einzuführen. Eine möglicheweitere Verfeinerung dieses Ansatzes ist es, dieQualität und den Umfang getrennt zu gewichten.So kann bei für das Produkt kritischen Artefaktenein höheres Augenmerk auf die Qualität gefordertwerden.

Am Ende des Spiels soll für den Spieler, nebendem kurzen Übersichtsbericht, ein zusätzlicherProjektbericht über den Verlauf seines Projektserstellt werden. Je nach Szenario kann dieser demSpieler auch schon während des Spiels zugänglichgemacht werden. Ein solcher Bericht kann denzeitlichen Fortschritts- und Qualitätsverlauf dereinzelnen Artefakte enthalten. Ebenso hilfreich isteine Verfolgung der Eigenschaften der einzelnenMitarbeiter. So kann schnell erkannt werden, wiesich Projektentscheidungen auf beispielsweise dieMotivation, die Fitness oder die Fähigkeiten derMitarbeiter ausgewirkt haben. All diese Informationenmüssen geeignet aufbereitet und dargestellt werden.

Bislang unterstützt das Spiel ausschließlich Szenari-en, die auf linearen Prozessmodellen basieren. Grunddafür ist die, über die Szenarien definierte, statischeKonfiguration des Produkts, bestehend aus seinen ein-zelnen Artefakten. Bei iterativen und agilen Prozess-modellen ist diese Aufteilung zu Beginn des Projektsnoch nicht vollständig bekannt. Um nichtlineare Pro-zessmodelle zu unterstützen, muss der Spieler wäh-rend des Projekts entscheidet können, welche neuenArtefakte zu erstellen sind oder welche bestehendenArtefakte verworfen werden sollen. Damit gibt er vor,wie er die Entwicklung des Produkts strukturierenmöchte. Das kann beispielsweise durch das Erstelleneiner neuen Iteration bei iterativen Prozessmodellen,oder innerhalb der Planung eines neuen Sprints beiagilen Prozessmodellen wie SCRUM geschehen.

In wie weit sich eine solche zusätzliche Funktionali-tät in das Spiel integrieren lässt, haben wir bislangnoch nicht getestet. Da das verwendete Simulati-onsframework die Möglichkeit bietet, die Strukturdes Produkts während der Simulation zu verändern,sind zumindest die technischen Grundlagen dafürvorhanden.

Die Evaluation hat uns gezeigt, dass noch Potentialzur Steigerung des Spielspaßes vorhanden ist. BeimDesign unseres Testszenarios haben wir daraufbewusst keinen Wert gelegt. Langfristig macht es aberSinn ein Spiel zu entwickeln, das dem Spieler auch

63Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015

Spaß macht. Ein möglicher Ansatzpunkt dafür ist einedetailliertere Gestaltung der Szenarien. Diese könnenmit zusätzlichen Spielelementen, wie beispielsweisezufälligen Spielereignissen erweitert werden. Eineweitere Möglichkeit das Spiel abwechslungsreicherzu gestalten ist es, das Szenario um eine Storyline zuergänzen und diese medial mit Texten, Grafiken undVideos ansprechend zu gestalten. Diese Spielelementezielen primär darauf ab, das Spiel abwechslungsrei-cher und spannender zu machen.

Die Erfahrungen, die wir mit diesem Projekt ge-macht haben, zeigen uns, dass es sinnvoll ist, beider Entwicklung von Lernspielen eine möglichst rea-litätsnahe Spielumgebung zu schaffen. Es hat sichherausgestellt, dass sich dies durch das Einbeziehender Werkzeuge, die in der realen Entwicklung ver-wendet werden, umsetzen lässt. Da diese Werkzeugehäufig eine gute Erweiterbarkeit mit entsprechendenSchnittstellen aufweisen, lässt sich eine Integrationhäufig ohne großen Aufwand realisieren.

In unserem Spiel haben wir uns auf den Aspekt desProjektmanagements beschränkt. Ein interessanter An-satz für weitere Arbeiten ist es, andere Aspekte desSoftware Engineering in ähnlicher Weise in die pas-senden Werkzeuge zu integrieren, und diese auf einerhöheren Ebene zu einem gemeinsamen Softwarepro-jekt zusammenzufügen. So können die Studierendenalle relevanten Aspekte im Bereich des Software En-gineering an einem einzigen durchgehenden Projektpraktisch üben.

Literatur[Bittner 2006] BITTNER, M.: Enhancing the Fusion

Method to Fusion B: Requirements Engineering andFormal Specification, Technischen Universität Berlin,Diss., 2006

[Coleman u. a. 1994] COLEMAN, Derek ; ARNOLD,Patrick ; BODOFF, Stephanie ; DOLLIN, Chris ;GILCHRIST, Helena ; HAYES, Fiona ; JEREMAES, Paul:Object-oriented Development: The Fusion Method. Up-per Saddle River, NJ, USA : Prentice-Hall, Inc., 1994

[Jain u. Boehm 2006] JAIN, Apurva ; BOEHM, Bar-ry W.: SimVBSE: Developing a Game for Value-Based Software Engineering. In: CSEE&T, IEEEComputer Society, 2006, S. 103–114

[Ludewig u. a. 1992] LUDEWIG, J. ; BASSLER, T. ; DEI-NINGER, M. ; SCHNEIDER, K. ; SCHWILLE, J.: SESAM-simulating software projects. In: Software Enginee-ring and Knowledge Engineering, 1992. Proceedings.,Fourth International Conference on, 1992, S. 608–615

[Microsoft Corporation 2013] MICROSOFT CORPORA-TION: Microsoft Project. Version 2013. 2013

[Nassal 2014] NASSAL, Alexander: A General Frame-work for Software Project Management SimulationGames. In: Information Systems and Technologies(CISTI) 2014, 9th Iberian Conference on InformationSystems and Technologies, 2014, S. 321–325

[Navarro 2006] NAVARRO, Emily: SimSE: A SoftwareEngineering Simulation Environment for SoftwareProcess Education, University of California, Irvine,Diss., 2006

[de Oliveira Barros u. a. 2006] OLIVEIRA BARROS, Már-cio de ; DANTAS, Alexandre R. ; VERONESE, Gusta-vo O. ; WERNER, Cláudia Maria L.: Model-drivenGame Development: Experience and Model Enhan-cements in Software Project Management Educati-on. In: Software Process: Improvement and Practice11 (2006), Nr. 4, S. 411–421

[Pieper 2013] PIEPER, Jöran: Alles nur Spielerei?Neue Ansätze für digitales spielbasiertes Lernen vonSoftwareprozessen. In: SPILLNER, Andreas (Hrsg.) ;LICHTER, Horst (Hrsg.): Tagungsband des 13. Work-shops “Software Engineering im Unterricht der Hoch-schulen” (SEUH) 2013, Aachen, CEUR WorkshopProceedings Vol. 956, 2013, 131–139

[Shaw u. Dermoudy 2005] SHAW, Katherine ; DER-MOUDY, Julian R.: Engendering an Empathy forSoftware Engineering. In: YOUNG, Alison (Hrsg.) ;TOLHURST, Denise (Hrsg.): ACE Bd. 42, AustralianComputer Society, 2005 (CRPIT), S. 135–144

[Ye u. a. 2007] YE, En ; LIU, Chang ; POLACK-WAHL,J.A.: Enhancing Software Engineering EducationUsing Teaching Aids in 3-D Online Virtual Worlds.In: Frontiers In Education Conference - Global Engi-neering: Knowledge Without Borders, OpportunitiesWithout Passports, 2007

64 Axel Schmolitzky, Anna Sabine Hauptmann (Hrsg.): SEUH 2015