Ein Framework zur Erstellung von Planspielen zur Softwaretechnik Alexander Nassal und Matthias Tichy, Universität Ulm {alexander.nassal, matthias.tichy}@uni-ulm.de Zusammenfassung Studierenden so, zu experimentieren und unterschied- liche Strategien auszuprobieren. Die Entwicklung von Software ist ein komplexer Pro- Um optimale Lerneffekte zu erzielen, müssen die zess, der von einer Vielzahl an Aspekten aus unter- eingesetzten Planspiele gut auf die eigentlichen Leh- schiedlichen Disziplinen beeinflusst wird. Planspiele, rinhalte abgestimmt werden, was häufig die Entwick- die Softwareentwicklung und das dazugehörige Pro- lung eines neuen Spiels erforderlich macht. Eine sol- jektmanagement adäquat veranschaulichen, müssen che Entwicklung ist oft mit erheblichem Aufwand ver- diese Aspekte entsprechend berücksichtigen. bunden. Das gilt vor allem für Spiele, die nicht nur Eine der schwierigsten Aufgaben bei der Entwicklung einen konkreten Sachverhalt veranschaulichen, son- solcher Planspiele ist es, den Projektverlauf korrekt dern ein allgemeines Gefühl für Softwareprojekte und zu simulieren. Bestehende Planspiele nutzen dafür die damit verbundenen Probleme und Herausforde- speziell auf sie abgestimmte Simulationsmodelle, die rungen vermitteln sollen. nur schlecht für andere Planspiele wiederverwendet werden können. So muss bislang für jedes neue Plan- Unserer Erfahrung nach liegt der Hauptaufwand in spiel auch ein neues Modell entwickelt werden. der Entwicklung des Simulationsmodells, das für die Wir haben eine Repräsentation der Aspekte und Struk- Berechnung des Projektverlaufs benötigt wird, und turen von Softwareprojekten entwickelt, die es er- mit dem der Spieler interagieren muss. Dieses Mo- laubt, von einem konkreten Projekt zu abstrahieren. dell muss so realitätsnah sein, dass die Erfahrungen Damit sind wir in der Lage, ein allgemeineres Simula- die der Spieler macht, später auch auf reale Projekte tionsmodell zu bauen, das für unterschiedliche Plan- übertragen werden können. Dazu müssen nicht nur spiele im Softwaretechnikbereich eingesetzt und an- die Aspekte der Softwareentwicklung berücksichtigt gepasst werden kann. werden, sondern beispielsweise auch der Einfluss von Dieses Simulationsmodell haben wir zusammen mit psychologischen Faktoren wie Motivation, Lernverhal- weiteren Werkzeugen zu einem Framework zusam- ten und soziale Interaktion, oder arbeitswissenschaft- mengefasst. In diesem Beitrag stellen wir dieses Fra- liche Aspekte wie die Gestaltung von Arbeitszeit und mework vor, und zeigen anhand von Beispielen, wie Leistungsdruck. es verwendet werden kann, um die Entwicklung von Die Modelle in existierenden Planspielen sind spezi- Planspielen zu unterstützen. ell auf ihren jeweiligen Einsatz angepasst und decken genau die Aspekte ab, die im jeweiligen Planspiel the- matisiert werden. Aspekte, die nicht direkt mit dem 1 Einleitung Lernziel in Verbindung stehen, werden ignoriert. Eine Planspiele sind ein bewährtes Mittel, Ausbildung pra- Wiederverwendung der Modelle in neuen Planspielen xisnah zu unterstützen. Das gilt auch für die Hoch- und mit anderen Lernzielen ist meist nicht sinnvoll, da schullehre im Bereich Softwaretechnik, und dort be- der Anpassungsaufwand den Aufwand der Entwick- sonders beim Thema Projektmanagement. Durch das lung eines neuen Modells überschreitet. spielerische Leiten eines simulierten Projekts können Um die Entwicklung neuer Planspiele besser zu un- die Studierenden eigene Erfahrungen sammeln, und terstützen, haben wir ein Simulationsmodell entwi- das zuvor erlernte theoretische Wissen anwenden. Da- ckelt, das von einem konkreten Planspiel abstrahiert, durch wird ein tieferes Verständnis ermöglicht, da die und so einen flexibleren Einsatz erlaubt, als es mit den Studierenden die Problematik selbst erkennen und bisher in Planspielen verwendeten Modellen möglich erfahren, anstatt sie von außen erzählt zu bekommen ist. (Reich, 2008). Planspiele haben den Vorteil, dass sie Das Modell ist in ein Framework eingebettet, wel- im Gegensatz zu richtigen Projekten deutlich weni- ches es ermöglicht, Spiele in C# zu entwickeln. Die ger Zeit in Anspruch nehmen. Fehler, die im Planspiel Gestaltungsmöglichkeiten sind durch diesen Ansatz gemacht werden, gefährden außerdem kein reales weniger eingeschränkt, als durch die Verwendung von Projekt, in dem viele Arbeitsstunden von unterschied- Editoren und Generatoren zur Erstellung von Spielen. lichen Entwicklern stecken, und ermöglichen es den Unser Modell enthält vor allem die allgemeinen Aspek- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 51 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik te der Projektarbeit, und kann entsprechend erweitert, mit dem Ziel eine hochwertige Software in möglichst angepasst oder verändert werden, um spezielles Spiel- kurzer Zeit zu entwickeln. verhalten zu erzeugen. Neben den Projekten, die ein konkretes Planspiel In diesem Beitrag stellen wir unseren Simulations- zum Ziel haben, gibt es auch Arbeiten, die sich mit ansatz und die gewählte Abstraktion vor, und zeigen, deren Entwicklung auf einer allgemeineren Ebene be- wie beides verwendet werden kann, um eigene Plan- schäftigen. Ein Beispiel dafür ist SESAM (Ludewig spiele zu entwickeln. Nach einem kurzen Überblick u. a., 1992). Hier wurde eine konzeptionelle Basis für über schon existierende Planspiele und Lösungen zur die Planspielentwicklung geschaffen, und die Erstel- Unterstützung der Planspielentwicklung, erläutern wir lung neuer Simulationsmodelle durch eine eigene Mo- unser Framework mit den dazugehörigen Werkzeugen. dellierungssprache unterstützt. SESAM enthält neben Anschließend schlagen wir eine konkrete Vorgehens- den Konzepten und einer dazu passenden Methodik, weise vor, um damit neue Spiele zu erstellen, und auch die dafür benötigten Werkzeuge, um neue Simu- verdeutlichen diese an einem Beispiel. In einem wei- lationsmodelle zu erstellen. teren Abschnitt zeigen wir beispielhaft, wie konkrete Ein weiteres Projekt, das die Entwicklung von Plan- Aspekte der Softwareentwicklung mit unserem Ansatz spielen unterstützt, ist SimSE (Navarro, 2006). Ob- umgesetzt werden können. Zum Schluss bilden wir wohl dort die Untersuchung der didaktischen Wirk- ein kurzes Fazit und diskutieren mögliche Erweite- samkeit von Planspielen im Softwaretechnikbereich rungen und Verbesserungen, die bislang noch nicht im Vordergrund stand, ist in diesem Projekt ein Bau- umgesetzt wurden. kasten entstanden, mit dem Planspiele entwickelt wer- den können. Dazu wird ein Editor bereitgestellt, mit 2 Verwandte Arbeiten dem sich Spielinhalte und Simulationsmodelle erstel- len, und anschließend mittels eines Generators in ein Neben Planspielen in anderen Bereichen, wie dem interaktives Spiel transformieren lassen. Finanzwesen, der Betriebswirtschaft oder dem Militär, Alle uns bekannten Arbeiten liefern entweder ein existieren auch im Bereich der Softwareentwicklung fertiges Planspiel, oder geben Hilfestellung bei der schon einige Projekte, um die Lehre zu unterstützen. Entwicklung eines eigenen Spiels. Keine der Arbeiten Ein Beispiel dafür ist SimVBSE (Jain u. Boehm, liefert ein einsatzbereites Simulationsmodell, das für 2006), das entwickelt wurde, um Studierenden die den Einsatz in neuen Spielen konzipiert ist. Projekte Möglichkeit zu bieten, eigene Erfahrungen auf dem wie SESAM liefern jedoch zumindest die notwendigen Gebiet des Value-Based Software Engineering zu sam- Grundlagen, um eigene Modelle zu konzipieren und meln. Bei SimVBSE kann der Spieler mittels unter- umzusetzen. schiedlicher Aktionen den Projektverlauf eines fiktiven Neben den Projekten zur Planspielentwicklung gibt Softwareprojekts beeinflussen. Aktionen sind dabei es auch Arbeiten, die sich mit den Aspekten der Soft- häufig mit Kosten verbunden, die es zu berücksichti- wareentwicklung an sich beschäftigen und diese in gen gilt. Der Projektverlauf wird auf Basis der gewähl- Form von Modellen beschrieben haben. Ein bekanntes ten Aktionen mittels eines Regelsystems simuliert, und Beispiel sind die System Dynamics Modelle von Abdel- dem Spieler grafisch und textuell angezeigt. Hamid et. al. (Abdel-Hamid u. Madnick, 1991). In SimjavaSP (Ye u. a., 2007) ist ein interaktives, web- (Madachy, 2007) wurde die Arbeit von Abdel-Hamid basiertes Planspiel, bei dem der Spieler ebenfalls die weitergeführt und um Modelle ergänzt, welche die Rolle des Projektleiters einnimmt, um ein Software- in den letzten Jahren hinzugekommenen Aspekte der projekt zum Erfolg zu führen. Dabei lernt er, Projek- Softwareentwicklung abdecken. Diese Modelle behan- te nach dem Wasserfall- und Spiralmodell durchzu- deln die Vorgänge allerdings auf einer sehr abstrakten führen. Das Ziel des Spiels ist es, eine hypothetische Ebene, die für Planspiele oft ungeeignet ist. So wird Software in einem vorgegebenen Zeitrahmen, sowie beispielsweise nicht zwischen den einzelnen Mitarbei- in einer akzeptablen Qualität zu entwickeln, und da- tern und deren Eigenschaften unterschieden, sondern bei auf unterschiedliche außergewöhnliche Ereignisse, werden diese lediglich gesammelt als Arbeitskraft be- wie Mitarbeiterausfall oder geänderte Anforderungen, trachtet. Diese wird in Form der Produktivität als ein zu reagieren. SimjavaSP setzt bei der Simulation des einzelner Wert dargestellt und fließt so in die Simula- Projektverlaufs auf einen ereignisorientierten Ansatz. tion ein. Außerdem sind die Prozesse und Strategien, Ein drittes Beispiel ist das Projekt The Incredible Ma- nach denen das simulierte Projekt geführt wird, Teil nager (de Oliveira Barros u. a., 2006). Dieses Spiel des Modells; der Projektleiter wird quasi mitsimuliert. basiert auf System Dynamics Modellen. Dazu wurde Daher sind diese Modelle für den Einsatz in Planspie- der Ansatz der System Dynamics so erweitert, dass len meist ungeeignet. die Modelle während der Simulation durch den Spie- ler manipuliert werden können. Um Einfluss auf den Spielverlauf zu nehmen, verändert der Spieler die 3 Framework und Parameter der Modelle, indem er diverse Entschei- Simulationsumgebung dungen bezüglich seines Entwicklerteams, des Pro- Im Folgenden beschreiben wir unseren Ansatz zur jektplans und anderer projektrelevanter Aspekte trifft, Strukturierung von Planspielen, der Abstraktion von Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 52 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik konkreten Projekten, und den grundlegenden Simula- es dem Spielentwickler zum einen, die darauf auf- tionsansatz den wir für das auf diesen Konzepten ba- bauenden Schichten auch algorithmisch zu erzeugen, sierende Simulationsmodell gewählt haben. Unser Ziel und so beispielsweise Szenarien zu generieren, und war es, eine Repräsentation von Softwareprojekten zum anderen, Aspekte, die in unserem Modell nicht zu finden, die unabhängig von konkreten Prozessen, vorgesehen sind, leichter ergänzen zu können. Außer- Produkten und weiteren planspielspezifischen Eigen- dem schränkt unser Ansatz die weitere Gestaltung der schaften ist. Gleichzeitig muss es möglich sein, auf Spiele nur minimal ein. So können zum Beispiel auch Basis dieser Struktur den Projektverlauf zu berechnen Mehrspielerkonzepte und verteilte Spiele umgesetzt und diesen auf ein konkretes Planspiel zu übertragen. werden. Wir schlagen vor, Planspiele, wie in (Nassal, 2014) 3.1 Datenmodell beschrieben, als vier aufeinander aufbauende Schich- ten zu entwickeln: Das Simulationsmodell besteht aus zwei Teilen: einem Datenmodell, welches die statische Struktur beschreibt, 1. Die unterste Schicht enthält mit der Simulations- und einem Regelwerk, über das die operationale Se- engine alle zur Simulationsausführung benötigten mantik definiert ist und mit dem sich der Verlauf eines Funktionen. Sie kümmert sich um den grundsätz- auf Basis des Datenmodells definierten Projekts be- lichen Ablauf der Simulationsberechnung, und rechnen lässt. stellt weitere hilfreiche Funktionen, wie die Über- Eines der Ziele bei der Entwicklung des Frame- wachung und Protokollierung des Simulationsver- works war es, dem Entwickler die Verwendung des laufs, zur Verfügung. Simulationsmodells zu ermöglichen, ohne dass er das 2. Darauf aufbauend definiert das Simulationsmodell umfangreiche und teilweise komplexe Regelwerks im mit seiner statischen Struktur das Datenmodell, Detail verstehen muss. Aus diesem Grund, und weil welches dem Spiel zugrunde liegt, und die ope- das Regelwerk den hier gegebenen Rahmen deutlich rationale Semantik, die vorgibt, wie sich die so überschreiten würde, verzichten wir hier auf dessen abgelegten Daten über die Zeit verändern. Beschreibung und beschränken uns auf das Datenmo- 3. Mittels eines Szenarios, wird auf Basis der im Si- dell. mulationsmodell beschriebenen statischen Struk- tur, ein konkretes Projekt erstellt und somit das Projektbeteiligter allgemeine Modell an das konkrete Planspiel an- Erfahrung und Fähigkeiten Projekt gepasst. Die so definierten Daten werden als Start- Wissensstand Charaktereigenschaften Fortschrittsarbeit zustand der Simulation verwendet. Dazu werden Physischer und psychischer Zustand Quantitätsmodifikator die im Datenmodell festgelegten Elemente instan- Produkt Rolle Qualitätsmodifikator Defektspektrum ziiert, deren Parameter auf konkrete Werte fest- Qualitätsarbeit gelegt, und die Beziehungen zwischen ihnen defi- Prozessmodell Aktivität Quantitätsmodifikator niert. Vorbedingung Kontext Qualitätsmodifikator Defektspektrum Zum Szenario gehört außerdem die Storyline des Artefakt Kontext Kommunikation Spiels. Neben dem Projekt selbst, das die Rahmen- Anwendung Umfang / Aufwand Artefaktkategorie Defekte / Qualität Quantitätsmodifikator bedingungen und die Ausgangssituation des Spiels Basisschwierigkeit Disziplin Fertigstellungsgrad beschreibt, können hier Ereignisse im Projektver- Vorbedingung lauf definiert werden, die das Projekt zusätzlich beeinflussen. Abbildung 1: Datenmodell 4. Die oberste Schicht enthält die Benutzerschnitt- stelle. Dazu gehören vor allem die Repräsentation Abbildung 1 zeigt ein UML-Klassendiagramm des der Simulation, die es dem Spieler erlaubt das Datenmodells. Auf Basis dieses Modells werden Sze- Spielgeschehen zu beobachten, und die Interak- narien modelliert, die anschließend simuliert werden tionsmöglichkeiten, die der Spieler hat, um das können. Ein Szenario besteht im Wesentlichen aus Spielgeschehen zu beeinflussen. Produkt, Team und Prozessmodell. Da durch die Architektur klare Schnittstellen de- Produkt Das Produkt beschreibt die Software, die finiert sind, lassen sich die Teile relativ unabhängig der Spieler entwickeln soll. Modelliert wird dazu das voneinander entwickeln, warten, erweitern und wie- Endprodukt, bestehend aus den verschiedenen Arte- derverwenden. Insbesondere existiert eine klare Tren- fakten, in die es sich unterteilen lässt. Die Granulari- nung zwischen allgemeinem Simulationsmodell und tät ist dabei dem Planspielentwickler überlassen und konkretem Szenario bzw. Planspiel. hängt stark vom Spieldesign und Lernziel des Spiels Um einen flexiblen Einsatz zu ermöglichen, haben ab. Es kann beispielsweise jede einzelne Anforderung wir darauf verzichtet, eine eigene Simulationssprache, als ein eigenständiges Artefakt modelliert werden, es spezielle Editoren oder andere Entwicklungsumge- besteht aber auch die Möglichkeit, nur ein Artefakt bungen für Planspiele zu erstellen. Stattdessen wur- für das gesamte Pflichtenheft zu erstellen. den Ausführungsumgebung und Simulationsmodell Jedes Artefakt verfügt über verschiedene Parame- als reine C# Bibliotheken konzipiert. Das ermöglicht ter, die unter anderem dessen Umfang und Schwie- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 53 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik rigkeit festlegen. Artefakte können für sie relevanten fakt wird außerdem einem Artefakttyp zugeordnet. Disziplinen zugeordnet werden, die zusätzliche An- Aktivitäten können auf einzelne Artefakttypen ein- forderungen an die bearbeitenden Entwickler stellen. geschränkt werden, um beispielsweise eine Anforde- Beispielsweise kann es von Bedeutung sein, dass ein rungsanalyse auf dem Entwurf zu verbieten. Entwickler neben der Fähigkeit grundsätzlich Anforde- Ein Prozessmodell legt normalerweise neben den rungen zu erheben, auch in der Lage sein muss, diese Aktivitäten und Rollen auch fest, wie diese anzuwen- als UML-Modell zu dokumentieren. Der Umgang mit den sind. Dieser Teil des Prozessmodells wird nicht UML ist somit eine hierfür relevante Disziplin. modelliert, da er vom Spieler, in seiner Rolle als Pro- Artefakte können untereinander in Beziehung ste- jektleiter, umgesetzt werden muss. hen, um die Abhängigkeiten zwischen ihnen auszu- drücken. Diese werden beispielsweise als harte Vorbe- 3.2 Ausführungsumgebung dingungen beschrieben, um auszudrücken, dass ein Die Simulationsausführung berechnet den Projektver- Artefakt erst bearbeitet werden kann, wenn ein an- lauf anhand der Regeln des Simulationsmodells. Wir deres abgeschlossen wurde, oder sich in einem be- haben dafür den Ansatz eines Multiagentensystems ge- stimmten Zustand befindet. Artefakte können mittels wählt, der schon erfolgreich in anderen Arbeiten zur Beziehungen auch als Kontext eines anderen Artefakts Simulation von Softwareentwicklungsprozessen einge- festgelegt werden, sodass Vollständigkeit und Qualität setzt wurde (Cherif u. Davidsson, 2010; Wickenberg des einen Artefakts, die Fortschrittsgeschwindigkeit u. Davidsson, 2002). Dieser Ansatz hat den Vorteil, und Qualität bei der Bearbeitung des anderen Arte- dass sich mit der ihm zugrundeliegenden Struktur fakts beeinflussen. die Vorgänge aus der Realität sehr direkt nachbilden Team Das Team ist die Menge der am Projekt be- lassen. teiligten Personen. Dazu gehört neben den Entwick- Das System setzt sich aus Elementen dreier Klassen lern beispielsweise auch der Kunde. Der Projektleiter zusammen: wird typischerweise nicht modelliert; diese Rolle über- • Die Umgebung repräsentiert die Grenzen der Simu- nimmt später der Spieler. lation und deren Schnittstelle zur Außenwelt. Sie Jeder Projektbeteiligte enthält eine Vielzahl an Pa- definiert die benötigten Rahmenparameter und rametern, die unter anderem seine Fähigkeiten in Be- abstrahiert Aspekte, die nicht Teil der Simulation zug auf die vorhandenen Aktivitäten und Disziplinen, sind, diese jedoch beeinflussen. Sie enthält außer- sein Wissen über das Produkt, Charaktereigenschaf- dem die Agenten und Ressourcen. ten und seinen physischen sowie psychischen Zustand • Ressourcen sind die passiven Elemente der Simu- beschreiben. Durch die Belegung der Parameter kann lation. Sie sind Teil des Simulationszustands und gesteuert werden, wie sich das Teammitglied im Team können von den Agenten verändert werden. Alle verhält, und wie sich seine Arbeit auf das Projekt aus- Artefakte des Produkts sind als solche Ressour- wirkt (Nassal u. Tichy, 2016). Zu den Charaktereigen- cen realisiert, aber auch Werkzeuge, Arbeitsgegen- schaften gehören unter anderem, wie der Mitarbeiter stände oder der Projektplan können so umgesetzt mit Zeitdruck umgeht, welche Aktivitäten er gerne werden. durchführt, mit welchen Kollegen er gerne zusam- • Die Agenten sind der einzige aktive Teil der Si- menarbeitet, was ihn motiviert, und nach welchen mulation. Agenten agieren zunächst unabhängig Kriterien er sein Arbeitsumfeld einschätzt. voneinander. Das Gesamtverhalten der Simulati- Prozessmodell Mit dem Prozessmodell werden die on ergibt sich allein aus dem Zusammenspiel der Aktivitäten festgelegt, die die einzelnen Teammitglie- einzelnen Agenten. Jeder Projektbeteiligte wird der durchführen können, um das zuvor definierte Pro- als ein eigenständiger Agent umgesetzt. Wie auch dukt zu entwickeln. Dazu stehen drei Basisaktivitäten in der Realität, ergibt sich so die Leistung des zur Definition weiterer Aktivitäten zur Verfügung: Teams aus den Einzelleistungen der Projektbetei- • Aktivitäten, die auf Fortschrittsarbeit basieren, ha- ligten. Diese werden nicht zentral gesteuert, son- ben das Ziel, die Artefakte des Produkts weiter zu dern agieren selbstständig und koordinieren sich vervollständigen. Darunter fällt beispielsweise die über die Kommunikation untereinander und die Codierung eines zuvor definierten Moduls. Wahrnehmung des Projektzustands, zu dem bei- • Mittels Aktivitäten der Qualitätsarbeit, wie bei- spielsweise auch der Projektplan gehört. spielsweise dem Testen, lassen sich Defekte fin- Die Simulationsberechnung erfolgt in diskreten Zeit- den, die über Fortschrittsarbeit in die Artefakte schritten. Die Schrittgröße ist dabei zunächst variabel, gekommen sind. was auch durch das Simulationsmodell unterstützt • Kommunikationsaktivitäten dienen zum Austausch wird. Die benötigte Rechenzeit steigt linear mit der von Wissen zwischen den Teammitgliedern. Anzahl der Zeitschritte. Es hat sich herausgestellt, dass Aktivitäten können über Rollen, die die Teammit- eine Schrittgröße von einer Stunde ein guter Kompro- glieder einnehmen, auf diese beschränkt werden. So miss zwischen Performance und Genauigkeit der Si- kann beispielsweise verhindert werden, dass der Kun- mulationsergebnisse darstellt. Mit dieser Schrittgröße de an der Implementierung teilnimmt. Jedes Arte- lässt sich ein vollständiges Projekt in wenigen Minu- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 54 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik ten berechnen. Bei längeren Schrittgrößen reagieren statistisch ausgewertet werden können. So lassen sich die simulierten Mitarbeiter in manchen Fällen nicht eine Vielzahl an Konfigurationen und unterschied- schnell genug auf veränderte Situationen. So kann es lichen Projektverläufen, trotz großer Parameterzahl beispielsweise sein, dass eine Aufgabe deutlich weni- und vielen Freiheitsgraden, überprüfen. Dazu werden ger Zeit in Anspruch nimmt als durch den Zeitschritt mehrere Simulationsläufe durchgeführt, und dabei zur Verfügung steht, und der Mitarbeiter so viel Zeit diejenigen Parameter zufällig belegt und verändert, ungenutzt verstreichen lässt, bevor er im nächsten die der Spieler während des Projektverlaufs beein- Zeitschritt eine andere Aufgabe bearbeiten kann. flussen kann. Jeder Versuchslauf entspricht so einem möglichen Projektverlauf, wie er später im Planspiel 3.3 Werkzeugunterstützung bei entsprechender Spielereingabe auftreten kann. Die Wir haben mehrere Werkzeuge entwickelt, um die Versuchsläufe können mittels Regeln, die im Frame- Verwendung, Anpassung und Weiterentwicklung des work enthalten sind, oder selbst definiert werden kön- Simulationsmodells zu unterstützen. nen, einzeln oder in ihrer Gesamtheit überprüft und Dateiformat für Szenarien Um Szenarien leichter ausgewertet werden. handhaben zu können, wird ein XML-Format und ein dazugehöriges Modul für das Speichern und Laden 4 Vorgehen bei der Erstellung eines dieses Formats bereitgestellt. Standardszenarien kön- nen damit ohne Programmiertätigkeit einfach erstellt neuen Planspiels und bearbeitet werden. In diesem Abschnitt beschreiben wir das grundsätz- Grafische Oberfläche Mittels einer grafischen Ober- liche Vorgehen bei der Erstellung eines neuen Plan- fläche können Szenarien geladen, und die Simulation spiels mit unserem Framework. Dazu schlagen wir ein ausgeführt und überwacht werden. Abbildung 2 zeigt Vorgehen in 10 Schritten vor: einen Ausschnitt der Oberfläche. 1. Auswahl und Formulierung des Lernziels. 2. Auswahl des Rahmenszenarios: Welches Produkt soll mit welchem Team und welchem Vorgehen unter welchen Bedingungen entwickelt werden? 3. Definition des konkreten Szenarios mit Produkt, Team und Aktivitäten. 4. Auswahl der nicht benötigten Aspekte des Modells und Deaktivierung der entsprechenden Modelltei- le. 5. Zusätzliche Definitionen speziellen Verhaltens oder spezieller Eigenschaften, die nicht im Fra- mework vorgesehen sind. 6. Definition der Storyline und zusätzlicher externer Ereignisse. Abbildung 2: Grafische Oberfläche zur Simulationsbe- 7. Entwicklung von expliziten Testfällen und statisti- obachtung schen Tests zur Validierung des Modellverhaltens in Bezug auf die Lernziele. Die Oberfläche ist in drei Bereiche gegliedert. Auf 8. Design und Implementierung der Rahmenanwen- der rechten Seite werden die Elemente des aktuell dung und anschließende Integration von Modell geladenen Szenarios angezeigt. Durch Auswahl der und Ausführungsumgebung. einzelnen Elemente werden im linken oberen Bereich 9. Anreicherung des Spiels um zusätzliches Spiel- entsprechende Darstellungen und Interaktionsmög- material, wie Storyelemente, Erklärungen, oder lichkeiten bereitgestellt. Unter anderem wird so für Hilfestellungen. die meisten Parameter, wie beispielsweise Artefakt- 10. Probelauf mit kleinen Testgruppen, ggf. mit Eva- fortschritt und -qualität oder Motivation und Wissens- luation, und entsprechende Anpassungen der vor- stand der Mitarbeiter, deren Verlauf über die Simulati- herigen Schritte auf Basis der Ergebnisse. onszeit in Form von Liniendiagrammen dargestellt. So Im Folgenden werden die einzelnen Punkte anhand lassen sich Trends, Muster und markante Veränderun- des in (Nassal, 2015) beschriebenen Projekts näher gen leichter erkennen und nachvollziehen. Im linken erläutert. Dabei handelt es sich um ein Spiel, das unteren Bereich wird der aktuelle Projektplan in Form wir entwickelt haben, um den Studierenden die Pla- eines Gantt-Diagramms angezeigt. Dieser Plan kann nungsaspekte des Softwaregrundpraktikums spiele- jederzeit verändert werden, um die Auswirkungen auf risch näher zu bringen. In diesem Praktikum entwi- die Simulation beobachten zu können. ckeln die Studierenden über zwei Semester hinweg Testunterstützung Um sicherzustellen, dass ein ihr erstes vollständiges Softwaresystem anhand einer Szenario auch die gewünschten Aspekte aufweist, stel- realen Problemstellung. Dabei werden neben den tech- len wir ein Framework bereit, mit dem sich automati- nischen Aspekten auch Projektmanagement und Team- sierbare Tests entwickeln lassen, die unter anderem arbeit gelehrt. Um das zu unterstützen, haben wir mit Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 55 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik dem hier beschriebenen Framework Szenario und Si- Produkt, Team und Aktivitäten Unser Produkt be- mulation erstellt, und in Microsoft Project (Microsoft steht aus 64 einzelnen Artefakten, die jeweils einem Corporation, 2013) integriert. Mit dem entstandenen von 8 Artefakttypen zugeordnet sind. Diese sind: Spiel können die Studierenden erste praktische Erfah- • Vorgabedokument für Dokumente, welche das rungen im Projektmanagement gewinnen, und dabei Projektteam vor Projektbeginn ausgehändigt be- gleichzeitig den Umgang mit den dazu benötigten kommt. Werkzeugen üben. • Anforderungsdokument für Artefakte, die während Lernziel Im ersten Schritt werden die Lernziele de- der Anforderungsanalyse entstehen. finiert, die mit dem Spiel erreicht werden sollen. Je • UI-Spezifikation für Artefakte, die die Benutzer- genauer die Ziele beschrieben werden, umso einfacher schnittstelle beschreiben. ist später deren Überprüfung. • Entwurfsdokument für Artefakte, die den Architek- Für unser Beispielprojekt haben wir folgende Ziele turentwurf enthalten. festgelegt: • Implementierung für die zu codierenden Artefakte. • Die Studierenden lernen die Artefakte kennen, • Qualitätssicherung für alle Tests und Reviews. die sie in ihrem Praktikum erstellen müssen. Sie • Dokumentation für die zusätzlich zu erstellenden können deren Bedeutung für das Projekt, den Zu- Dokumente, wie Handbuch und Installationsanlei- sammenhang mit anderen Artefakten, und deren tung. Umfang und den damit verbundenen Erstellungs- • Controlling für die Dokumente, die für das Pro- aufwand einschätzen. jektmanagement erstellt werden müssen, wie bei- • Die Studierenden lernen das verwendete Prozess- spielsweise der Arbeitszeitnachweis. modell kennen. Sie kennen anschließend dessen Die unterschiedlichen Artefakte stehen untereinan- Aktivitäten, und wissen wann und wofür diese der in Beziehung. So ist es beispielsweise in unse- eingesetzt werden. rem Szenario nicht möglich, etwas zu entwerfen, für • Die Studierenden lernen, dass die gegebene Zeit das die Anforderungen nicht bekannt sind, und etwas nur ausreicht, wenn sie die Aufgaben sinnvoll auf zu implementieren, für das der Entwurf fehlt. Damit die einzelnen Teammitglieder verteilen und paral- stellen wir sicher, dass das Prozessmodell im Wesent- lel arbeiten. lichen eingehalten wird. Für Einflüsse zwischen den • Die Studierenden lernen, dass kontinuierliche Artefakten wurden Kontextbeziehungen festgelegt, die Qualitätssicherung notwendig ist, um gute Pro- bestimmen, wie sich die Qualität und Vollständigkeit jektergebnisse zu erzielen. der Kontextartefakte auf die Entwicklung anderer Ar- • Die Studierenden lernen mit Microsoft Project ein- tefakte auswirken. fache Projektpläne zu erstellen und zu pflegen. Rahmenszenario Das Rahmenszenario ist durch Abbildung 3 zeigt die Beziehungen für die Artefak- die Vorgaben des Projekts, das die Studierenden im te der Anforderungsanalyse. Rechtecke stehen dabei Rahmen des Praktikums durchführen müssen, in den für die Artefakte, durchgezogene Pfeile zeigen deren meisten Punkten vorgegeben. Folgende Aspekte wur- vorgegebene Bearbeitungsreihenfolge an. Gepunktete den für das Szenario festgelegt: Pfeile zeigen auf diejenigen Artefakte, die die Bearbei- • Die Projektlaufzeit beträgt neun Monate und geht tung des betrachteten Artefakts durch ihren Zustand von Anfang November bis Ende Juli. beeinflussen können. Das Artefakt Produktskizze und • Das Entwicklerteam besteht aus sechs Mitarbei- Kundengespräch stellt den Ausgangspunkt der Anfor- tern, die verschiedene Rollen einnehmen und für derungsanalyse dar. Auf seiner Basis werden die ein- die unterschiedlichen Gebiete der Softwaretechnik zelnen Aspekte des Pflichtenhefts erarbeitet, und am zuständig sind. Ende zu einem vollständigen Dokument in Form des • In der Simulation wird ein abstraktes Produkt ent- Artefakts Pflichtenheft zusammengesetzt. wickelt, das unabhängig von einem konkreten Ein- satzzweck ist. So können die Studierenden die verschiedenen Artefakte kennen lernen, die grund- sätzlich bei der Softwareentwicklung vorkommen. Es ist zum Beispiel unerheblich, was die einzelnen Module der Software enthalten; wichtig ist nur, dass Module implementiert werden müssen. • Da wir im Praktikum die an das Wasserfallmodell angelehnte Fusion-Methode (Coleman u. a., 1994) verwenden, sind die Aktivitäten und deren Reihen- folge durch diese vorgegeben. • Weitere Managementaspekte, wie beispielsweise das Budget, werden nicht berücksichtigt, da sie Abbildung 3: Beziehungen der Artefakte der Anforde- im Praktikum keine Rolle spielen. rungsanalyse Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 56 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik Die Umfänge der Artefakte wurden so gewählt, dass Da sich der Spieler auf die Lernziele konzentrieren die dafür benötigte Zeit im Spiel dem Aufwand ent- soll, wurden für alle anderen Parameter der Mitarbei- spricht, den wir im echten Projekt dafür vorgesehen ter die Standardwerte belassen. Die Mitarbeiter ent- haben. Da die Studierenden nicht Vollzeit am Projekt sprechen somit durchschnittlichen Mitarbeitern und arbeiten, die Mitarbeiter im Spiel aber schon, haben der Spieler muss sich nicht mit deren besonderen Ei- wir die Umfänge entsprechend dahingehend ange- genschaften auseinandersetzen. passt. Zusätzliche Anpassungen Das Simulationsmodell Einige Artefakte haben wir zusätzlich mit einer oder deckt alle Aspekte ab, die für unser Planspiel notwen- mehreren der Disziplinen UML, Gestaltung, Relationale dig sind. Daher wurde kein weiteres spezielles Verhal- Datenbanken und Objektorientierte Programmierung ten und keine besonderen Eigenschaften definiert. In verknüpft, um besser zu verdeutlichen, wo die entspre- unserem Spiel setzen wir das vollständige Modell mit chenden Schwerpunkte bei der jeweiligen Artefaktent- allen Aspekten ein. Für manche Zwecke kann es je- wicklung liegen. So werden im realen Projekt bei- doch sinnvoll sein, bestimmte Aspekte des Modells zu spielsweise Anwendungsfälle durch UML-Diagramme deaktivieren, um die Vorgänge einfacher zu gestalten. dokumentiert. Passend dazu wird im Spiel dem Arte- Bestimmte Zusammenhänge, wie beispielsweise der fakt Anwendungsfälle die Disziplin UML zugeordnet. Einfluss von Fähigkeiten auf die Produktivität, können so besser beobachtet werden, da sie nicht von anderen Im tatsächlichen Projekt besteht das Team aus sechs Effekten, wie beispielsweise dem Einfluss von Motiva- Mitgliedern, die die Rollen Projektleiter, Projektver- tion auf die Produktivität, überlagert werden. Welche walter, Architekt, Dokumentator, Qualitätssicherungs- Modellteile deaktiviert werden sollen, hängt von den ingenieur und Verifikations- und Validierungsingenieur jeweiligen Lernzielen ab. schwerpunktmäßig einnehmen. Entsprechend wurden im Spiel sechs Projektbeteiligte erstellt, die nach die- Für das Spiel wurden keine zusätzlichen Ereignisse, sen Rollen benannt wurden, und deren Fähigkeiten wie beispielsweise der Ausfall eines Mitarbeiters hin- dazu passen. Die Rolle des Projektleiters wurde nicht zugefügt, da sich die Spieler auf den grundsätzlichen vergeben, da diese durch den Spieler eingenommen Ablauf konzentrieren sollen. Es wurde jedoch für al- wird. le Mitarbeiter zwei Wochen Urlaub an Weihnachten festgelegt, da auch im Praktikum in diesem Zeitraum Abbildung 4 zeigt als Beispiel die Verteilung der keine Projektarbeit der Studierenden vorgesehen ist. Fähigkeiten des Architekten. Die ersten vier Balken be- Validierung Das Framework enthält eine Vielzahl schreiben seine Fähigkeiten in Bezug auf die Diszipli- an Basistests, die die unterschiedlichen Eigenschaften nen, die anderen acht beziehen sich auf die einzelnen unseres Modells zeigen. Diese Tests können verwendet Aktivitäten. Fähigkeiten beeinflussen die Geschwin- werden, um sicherzustellen, dass auch das erstellte digkeit und Qualität, mit der ein Projektbeteiligter ein Szenario diese Eigenschaften erfüllt. Tests sind beson- entsprechendes Artefakt bearbeiten kann. Hat ein Mit- ders wichtig, wenn das Modell geändert, erweitert, arbeiter einen Wert von 0 für eine Fähigkeit, so besitzt oder einzelne Aspekte davon deaktiviert wurden. er keinerlei Wissen, Erfahrung und Talent auf diesem Unser Szenario kann mit mehreren zusätzlichen Gebiet. Ein Wert von 1 hingegen steht für optimale Fä- Tests validiert werden. Da die Parameter des Sze- higkeiten auf dem Gebiet, die nicht weiter gesteigert narios vom Spieler nicht verändert werden können, werden können. Man kann sehen, dass insbesondere werden diese dabei als konstant betrachtet und nicht die für das Erstellen des Architekturentwurfs notwen- verändert. Da automatische Tests ohne einen Spieler digen Fähigkeiten Entwurf, Objektorientierte Program- auskommen müssen, wird dieser durch zusätzlichen mierung und UML beim Architekten besonders hoch Agenten ersetzt, die in die Simulation eingefügt wer- sind, während er Schwächen im Bereich Dokumentati- den und die Interaktion des Spielers mit der Simula- on, Projektmanagement und Qualitätssicherung hat. tion ersetzen. Dabei setzen die Agenten unterschied- liche Strategien um, um zu testen, wie sich diese auf 1 den Projektverlauf und das Projektergebnis auswir- ken. Fähigkeit 0.8 In unserem Beispielprojekt ist es sinnvoll, bezogen 0.6 auf die Lernziele, vor allem die folgenden Strategien 0.4 in unterschiedlichen Kombinationen zu testen: 0.2 • Die Reihenfolge, in der die Artefakte bearbeitet werden, entspricht der Reihenfolge, die im tat- UML Gestaltung Datenbank OOP RE Entwurf Codierung Doku. PM QS Review Testen sächlichen Projekt vorgesehen ist. • Die Reihenfolge der Artefakte wird beliebig ge- wählt. Es wird dabei darauf geachtet, dass die jeweiligen Vorbedingungen erfüllt sind. • Die Reihenfolge der Artefakte wird rein zufällig Abbildung 4: Fähigkeitenprofil des Architekten gewählt. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 57 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik • Die Mitarbeiter werden entsprechend ihrer Rolle Zu den einzelnen Artefakten, Aktivitäten, Diszipli- den Aktivitäten zugeordnet. nen und Rollen wurden ausführliche Hilfetexte erstellt, • Die Mitarbeiter werden zufällig den Aktivitäten die direkt im Spiel angezeigt werden können. Die Stu- zugeordnet. dierenden können sich damit selbstständig einarbei- • Die Aktivitäten werden einzeln nacheinander aus- ten und lernen, was die einzelnen Artefakte enthalten, geführt. wie sie zusammenhängen, und wie sie erstellt werden • Die Aktivitäten werden möglichst parallel ausge- müssen. Weiterhin gibt es Hilfetexte zum Projekt, dem führt. Prozessmodell, der Aufgabenstellung und der Bedie- • Qualitätssicherungsaktivitäten werden regelmä- nung des Spiels. Das Spiel kann so ohne tutorielle ßig nach der Erstellung der Artefakte eingesetzt. Unterstützung eingesetzt werden. • Qualitätssicherungsaktivitäten werden erst am En- Testlauf Im letzten Schritt der Entwicklung haben de des Projekts eingesetzt. wir das Spiel mit einer Testgruppe von 14 Studieren- • Es werden keine Qualitätssicherungsaktivitäten den evaluiert und die Ergebnisse mittels eines Frage- eingesetzt. bogens erfasst. Es hat sich dabei gezeigt, dass die Kon- Die Simulationsläufe werden aufgezeichnet und aus- zeption des Spiels grundsätzlich erfolgversprechend gewertet. Dabei wird unter anderem betrachtet, wie ist und zu den gewünschten Lerneffekten führt. Die hoch die Qualität des Produkts ist und in welcher Zeit Studierenden fanden den simulierten Projektverlauf es entwickelt wurde. Im tatsächlichen Projekt sind realistisch, und konnten die Zusammenhänge zwi- mehrere Meilensteine definiert, an denen gewisse Ar- schen ihren Entscheidungen und deren Auswirkungen tefakte vollständig vorliegen müssen. Zusätzlich zum nachvollziehen. Beim Spielspaß wurden jedoch Defizi- Gesamtergebnis des Projekts, wird daher ermittelt, te festgestellt. Eine ausführlichere Zusammenfassung wie lange vor oder nach einem Meilenstein die dazu- der Ergebnisse findet sich in (Nassal, 2015). gehörigen Artefakte vollständig waren und in welcher Qualität sie vorgelegen haben. 5 Beispielszenarien Anhand der Ergebnisse dieser Tests werden die Pa- In diesem Abschnitt zeigen wir anhand von Beispielen, rameter des Szenarios, insbesondere die Fähigkeiten wie Szenarien definiert werden können, um bestimm- der Mitarbeiter, die Schwierigkeit der Artefakte, und te Aspekte der Softwareentwicklung zu simulieren. deren Umfang angepasst. Dazu werden mehrere Itera- Die hier gezeigten Szenarien sind Minimalbeispiele tionen von Testdurchläufen und Parameteranpassung und jeweils als Ausschnitt eines umfangreicheren Sze- durchgeführt, bis die Ergebnisse der Tests zu den an- narios zu verstehen. Zu jedem Aspekt erläutern wir, fangs definierten Lernzielen passen. Das bedeutet, das wie eine mögliche Umsetzung aussehen kann, und Projektergebnis ist am besten, wenn die Artefakte in beschreiben anschließend, zu welchen Simulationser- der richtigen Reihenfolge und durch die richtigen Mit- gebnissen diese Umsetzung führt. arbeiter möglichst parallel erstellt werden und konti- 5.1 Schnittstellenentwurf und Integration nuierliche Qualitätssicherung durchgeführt wird. Der Entwurf einer Systemarchitektur mit wohldefinier- Rahmenanwendung Wir haben uns entschieden, ten Schnittstellen ist die Grundvoraussetzung einer das Planspiel in Form eines AddIns in Microsoft Pro- erfolgreichen Integration (Sommerville, 2001). Die ject einzubetten. So können die Studierenden auf alle Studierenden sollen die Relevanz der Schnittstellen- dort vorhandenen Werkzeuge der Projektplanerstel- spezifikation begreifen, und lernen, welche negati- lung und -pflege zurückgreifen. Sie lernen gleichzei- ven Konsequenzen eine schlechte oder gar fehlende tig mit einer professionellen Projektplanungssoftware Schnittstellenspezifikation für die Integration hat. umzugehen, anstatt sich in eine künstlich geschaffene Umsetzung Um diesen Sachverhalt darzustellen, Spieloberfläche einarbeiten zu müssen, die sie später werden vier Artefakte betrachtet, die Teil des zu ent- nicht mehr benutzen werden. Dieser Weg erspart uns wickelnden Produkts sind. Der Entwurf wird auf zwei zudem die Entwicklung einer eigenen Oberfläche und einzelne Artefakte aufgeteilt: Der Schnittstellenent- eigener Werkzeuge. wurf beinhaltet gesammelt die Spezifikationen zu den Das AddIn enthält zusätzliche Schaltflächen zur Be- Schnittstellen der einzelnen Komponenten, der Kom- dienung der Simulation, und verschiedene Dialoge ponentenentwurf die restlichen Spezifikationen, die zur Anzeige der Artefakte, Aktivitäten und Mitarbei- notwendig sind, um diese zu implementieren. Passend ter. Der Standardprojektplan von Project wurde um dazu enthält die Komponentenimplementierung den zwei zusätzliche Spalten erweitert, in denen zu jedem Code zu den einzelnen Komponenten, und die Inte- Vorgang die Aktivität und das Artefakt, das bearbei- gration den Code, der diese Komponenten zu einem tet wird, festgelegt werden muss. Die Zuordnung der Gesamtsystem integriert. Zwischen den einzelnen Ar- Mitarbeiter geschieht, wie in Project üblich, über die tefakten bestehen unterschiedliche Beziehungen, die Ressourcenzuteilung. Am Ende des Spiels bekommt in Abbildung 5 dargestellt sind. der Spieler eine Übersicht über das Projektergebnis, Um sicherzustellen, dass Komponentenentwurf, das er erzielt hat. Komponentenimplementierung und Integration in der Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 58 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik tefakte. Diese wird auf ein Intervall zwischen 0 und 1 abgebildet, wobei 1 für vollständige Defektfreiheit bzw. ein optimales Ergebnis steht, und 0 für ein gänz- lich unbrauchbares Artefakt. Tabelle 1 zeigt die Simu- lationsergebnisse des oben beschriebenen Szenarios. V1 V2 V3 Dauer Schnittst.entwurf 72h 32h – Qualität Schnittst.entwurf 0,89 0,57 – Dauer Integration 40h 144h 256h Abbildung 5: Artefakte des Integrationsszenarios und Gesamtdauer Projekt 248h 312h 392h deren Beziehungen Tabelle 1: Vergleich der unterschiedlichen Vorgehens- richtigen Reihenfolge bearbeitet werden, werden da- weisen im Integrationsszenarios für entsprechende Vorbedingungen eingeführt, die sicherstellen, dass ein Artefakt erst bearbeitet werden Man kann beobachten, dass sich ein guter Schnitt- kann, wenn sein Vorgänger vollständig ist. stellenentwurf positiv auf die Projektzeit auswirkt, Da wir die Rolle des Schnittstellenentwurfs unter- bzw. bei fehlendem oder qualitativ unzureichendem suchen wollen, wird dieser nicht durch eine Vorbe- Schnittstellenentwurf erheblicher Mehraufwand be- dingung gefordert, sondern durch eine Beziehung trieben werden muss. Bei einem fehlenden Schnitt- zwischen Schnittstellenentwurf und Komponenten- stellenentwurf ist der Mehraufwand so groß, dass es implementierung realisiert, die sicherstellt, dass bei sich lohnt, den Schnittstellenentwurf nachträglich zu einer Änderung der Schnittstelle auch die Komponen- erstellen, und die entsprechenden Teile der Kompo- tenimplementierung angepasst werden muss. Solche nenten neu zu entwickeln, um anschließend eine gute Beziehungen bezeichnen wir als speziellen Einfluss. Integration durchführen zu können. Spezielle Einflüsse sind frei durch eine entsprechende Der Effekt im hier beschriebenen Szenario ist dras- Implementierung definierbar. Im Fall dieses Szenarios tischer dargestellt, als es in der Realität vermutlich wird bei einem Fortschritt des Schnittstellenentwurfs der Fall ist, um ihn besser sichtbar zu machen. Die ein gegebenenfalls schon vorhandener Fortschritt der Effektgröße wird durch den Faktor der Kontextbezie- Komponentenimplementierung um einen entsprechen- hung zwischen Schnittstellenentwurf und Integration den Anteil reduziert. bestimmt, der als einfacher Wert vorliegt und leicht Der Schnittstellenentwurf wird als Kontext der Inte- angepasst werden kann, um ein realistischeres Bild zu gration angegeben, um die Beziehung zwischen diesen erzeugen. beiden Artefakten zu realisieren. Somit wirkt sich des- sen Qualität und Vollständigkeit auf die Umsetzung 5.2 Referenzdokumente für Reviews der Integration aus. Ebenso wird eine Kontextbezie- Die Effektivität, mit der Fehler durch ein Review gefun- hung zwischen Komponentendesigns und Komponen- den werden, hängt maßgeblich von der Qualifikation tenimplementierung eingefügt. der Inspektoren, und der Vollständigkeit und Korrekt- Ergebnisse Um die Auswirkungen des Schnittstel- heit der Referenzdokumente ab (Weller, 1993). lenentwurfs du zeigen, betrachten wir drei beispiel- Dieser Sachverhalt soll in einem Planspiel verdeut- hafte Vorgehensweisen, für die sich ein Spieler bei der licht werden. Das dazugehörige Szenario kann dazu Erstellung der Artefakte entscheiden könnte: wie folgt aussehen: V1 Das vorbildliche Vorgehen, bei dem zuerst der Umsetzung Um den Sachverhalt nachzubilden, wer- Schnittstellenentwurf entwickelt, und anschlie- den zwei Artefakte, Prüfling und Referenzdokument, ßend durch Qualitätssicherungsmaßnahmen auf benötigt. Diese beiden Artefakte werden mittels ei- Fehler und Probleme untersucht und korrigiert ner Beziehung in einen Kontext gesetzt, sodass der wird. Zustand des Referenzdokuments einen entsprechen- V2 Ein Vorgehen, bei dem der Schnittstellenentwurf den Einfluss auf die Bearbeitung des Prüflings hat. zwar erstellt, jedoch keine Qualitätssicherungs- Außerdem erstellen wir eine Reviewaktivität, die es maßnahmen vorgenommen werden. dem Spieler erlaubt, sein Team mit dem Review des V3 Ein Vorgehen, bei dem kein Schnittstellenentwurf Prüflings zu beauftragen. Dieses Team besteht aus erstellt wird. vier Mitarbeitern. Der simulierte Prüfling wurde so Der betrachtete Projektteil wird von einem Mitarbei- konfiguriert, dass er 66 Defekte enthält, die mit unter- ter bearbeitet, der die jeweiligen Aufgaben der Reihe schiedlicher Schwierigkeit zu entdecken sind. nach durchführt. Um den Zusammenhang zwischen Ergebnisse Um den oben beschriebenen Aspekt zu Schnittstellenentwurf und Integration zu beobachten, untersuchen, betrachten wir die durchschnittliche An- betrachten wir die Arbeitszeit in Stunden, die der Mit- zahl der gefundenen Defekte pro Tag und die Anzahl arbeiter für die Durchführung der einzelnen Aufgaben der insgesamt aufgedeckten Defekte unter verschie- benötigt, und die Qualität der dabei entstehenden Ar- denen Voraussetzungen. Dazu variieren wir die Voll- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 59 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik ständigkeit und Korrektheit des Referenzdokuments, wird, die anderen drei Tage werden von den Inspekto- und die Fähigkeit der Mitarbeiter, ein Review durch- ren genutzt, um sich in den umfangreichen Prüfling zuführen. Eine Qualität des Referenzdokuments von und das Referenzdokument einzuarbeiten. Am Tag 1,0 entspricht dabei einem Dokument ohne Defekte, 5 beginnt das Team erste Defekte zu identifizieren. eine Qualität von 0,7 dem, was durchschnittliche Do- Im Verlauf des weiteren Prozesses steigt die Qualität kumente an Defekten aufweisen, und eine Qualität des Prüflings, während der Umfang der unentdeckten von 0,2 einem sehr fehlerbehafteten und somit unge- Defekte sinkt. Zu Beginn werden die Defekte dabei eigneten Dokument. Die Fähigkeiten der Inspektoren schneller entdeckt, da die Defektdichte im Prüfling werden im Intervall von 0 bis 1 abgebildet, wobei 0,5 höher ist als am Ende des Prozesses. Außerdem wer- einer durchschnittlichen Fähigkeit auf diesem Gebiet den die einfacher zu entdeckenden Defekte schneller entspricht. Tabelle 2 zeigt die Ergebnisse der Simulati- gefunden und beseitigt als die schwierigeren Defekte. onsläufe. Ein weiterer Aspekt, der bislang noch nicht betrach- tet wurde, ist die Anzahl der Mitarbeiter, die am Re- Referenzdok. Fähigkeit gefundene Defekte view teilnehmen. Abbildung 7 visualisiert die Ergeb- Vollst. Qualität Inspekt. p. Tag insgesamt nisse des zu diesem Szenario gehörigen Tests, bei dem 100% 0,7 0,5 8,0 48 die Auswirkung der Teamgröße auf die Effizienz des 50% 0,7 0,5 3,5 42 Reviews untersucht wird. Sie zeigt die gefundenen 0% 0,7 0,5 2,7 36 Defekte pro Inspektor und Zeiteinheit in Abhängigkeit 100% 0,2 0,5 4,2 42 der Größe des Reviewteams. Der dazugehörige Test 100% 1,0 0,5 13,2 66 variiert neben der Teamgröße auch die meisten an- 100% 0,7 1,0 16,5 66 deren Parameter des Szenarios, wie Artefaktumfang, 100% 0,7 0,1 1,4 18 Fähigkeiten der Inspektoren oder die Schwierigkeit der Defekte im Prüfling. Zu jeder dieser zufällig er- Tabelle 2: Ergebnisse des Reviews unter verschiedenen zeugten Konfigurationen existiert ein Punkt im Schau- Bedingungen bild. Während die Geschwindigkeit, mit der Defekte gefunden werden, mit der Teamgröße steigt, lässt sich An den Daten lassen sich die oben beschriebenen bezogen auf die Effizienz ein Optimum bei einer Team- Effekte erkennen. Je besser das Referenzdokument ist, größe von vier Inspektoren erkennen, was sich mit umso schneller werden die im Prüfling vorhandenen der Aussage in (Weller, 1993) deckt. Defekte aufgedeckt. Die Qualität des Referenzdoku- ments hat außerdem, genauso wie die Fähigkeit der Inspektoren, einen Einfluss darauf, welche Defekte ● nicht entdeckt werden, weil sie zu schwierig zu finden ● 3 sind. Um tatsächlich alle Defekte zu finden, müssen ● ● Gefundene Fehler pro Inspektor und Zeiteinheit entweder die Referenzdokumente vollständig und in ● optimaler Qualität vorliegen, oder alternativ die Fä- higkeiten der Inspektoren entsprechend hoch sein. 2 Abbildung 6 zeigt den zeitlichen Verlauf einer simu- ● lierten Reviewaktivität. Gezeigt wird die Qualität des ● ● ● Prüflings (durchgezogene Linie) und der Umfang der ● ● Defekte im Artefakt (gestrichelte Linie). 1 1,0 Qualität Defektumfang 0,8 0 ● ● ● 1 2 3 4 5 6 7 8 9 10 0,6 Anzahl der Inspektoren 0,4 Abbildung 7: Boxplot der Effizienz in Abhängigkeit 0,2 der Anzahl der Inspektoren 0,0 5.3 Brooks’ Law 0 2 4 6 8 10 12 14 16 Vergangene Projekttage Neben den oben gezeigten Beispielen lassen sich mit unserem Simulationsmodell einige weitere Aspekte Abbildung 6: Veränderung des Prüflings während ei- darstellen, von denen viele keine explizite Modellie- nes Reviewprozesses rung benötigen, sondern direkt durch das Simulati- onsmodell erzeugt werden. Auffällig ist hier, dass in den ersten fünf Tagen kein Da wir mit unserem Modell Wissen und Kommu- erkennbarer Fortschritt stattfindet. Zwei der Tage ent- nikation simulieren, entsteht beispielsweise der Ef- fallen auf ein Wochenende, an dem nicht gearbeitet fekt, der in Brooks’ Law (Brooks, 1975) beschrieben Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 60 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik wird: Werden einem Projekt zu einem späten Zeit- relative Veränderung der Produktivität nach Hinzufügen der Mitarbeiter punkt neue Mitarbeiter hinzugefügt, sind diese nicht sofort produktiv, sondern müssen sich zuerst in das Projekt einarbeiten. Dabei benötigen sie die Hilfe der schon länger im Projekt arbeitenden Mitarbeiter und 2.0 halten diese dadurch von ihrer eigentlichen Arbeit ab. So verzögert sich das Projekt insgesamt, da diese Zusatzaufwände in der kurzen Projektrestzeit nicht mehr durch das größere Team kompensiert werden können. Zusätzlich bedeutet ein größeres Team einen 1.0 höheren Kommunikationsaufwand, der sich negativ auf die Produktivität auswirkt. Im Gegensatz zu anderen Modellen, wie beispiels- weise das System Dynamic Modell in (Madachy, 2007), 0.5 beschreiben wir diesen Effekt nicht, indem wir die 0.25 0.50 0.75 Anzahl der neuen Mitarbeiter zählen und darauf ba- Zeitpunkt des Hinzufügens neuer Mitarbeiter sierend für einen bestimmten Zeitraum die Produk- tivität des Teams reduzieren, sondern erzeugen ihn Abbildung 8: Änderung der durchschnittlichen Pro- so, wie er laut Brooks zustande kommt. Dazu enthält duktivität durch das Hinzufügen neuer Mitarbeiter unser Simulationsmodell unter anderem Teilmodelle für Kommunikation, Lernen und soziale Interaktion. ten auf dem Problemgebiet besitzt als das bisherige Um den Effekt zu erzeugen betrachten wir das für Team, oder sich die Aufgaben so gut vom restlichen die Durchführung einer bestimmten Aktivität benötig- Projekt trennen lassen, dass eine Einarbeitung in die te Wissen, und die Möglichkeiten, dieses Wissen zu bisherigen Teile nicht notwendig ist. erwerben. Eine davon besteht in der Kommunikati- on mit den Mitarbeitern, die schon länger im Projekt 6 Fazit und Ausblick sind. Eine andere ist die Begutachtung der im Projekt Um die Planspielentwicklung zu unterstützen, haben vorhandenen Dokumente. Auch weitere Maßnahmen, wir ein Simulationsmodell entwickelt, das als Basis wie Schulungen sind denkbar. Welche Möglichkeiten neuer Spiele verwendet werden kann. Dieses Modell gewählt werden entscheiden die neuen Mitarbeiter ist zusammen mit weiteren Werkzeugen in ein Fra- selbstständig, oder legt der Spiel in seiner Rolle als mework eingebettet. In diesem Beitrag haben wir Projektleiter fest. beschrieben, wie dieses Framework eingesetzt wer- Abbildung 8 zeigt den durch die Simulation erzeug- den kann. Das vorgeschlagene Vorgehen wurde in 10 ten Zusammenhang zwischen dem Zeitpunkt, zu dem einzelne Schritte unterteilt, die wir anhand eines Bei- neue Mitarbeiter einem Projekt hinzugefügt werden, spielprojekts erläutert haben. In weiteren Beispielen und der Veränderung der Produktivität des Teams. Da- haben wir gezeigt, wie man mit dem Modell andere zu wurden 2.000 Projektverläufe mit zufällig gewähl- Aspekte der Softwareentwicklung nachbilden kann. ten Parametern simuliert. Zu einem zufällig gewählten Unser Framework ermöglicht es, Planspiele zu ent- Zeitpunkt des Projekts wurde die Mitarbeiterzahl ver- wickeln, ohne sich ausführlich mit allen einzelnen doppelt. Anschließend wurde die durchschnittliche Aspekten der Projektarbeit auseinandersetzen zu müs- Produktivität des Teams vor und nach dem Hinzu- sen, da diese in unserem Modell schon enthalten sind. fügen der Mitarbeiter gemessen. Am Schaubild lässt Das Modell kann an die jeweiligen Bedürfnisse an- sich erkennen, dass eine Verdopplung der Anzahl der gepasst werden; Aspekte, die wir nicht vorgesehen Teammitglieder zu Beginn des Projekts die Produktivi- haben, können dem Modell hinzugefügt werden. Das tät um ca. 80% steigert. Die Differenz zu einer Steige- Framework bietet Schnittstellen an, die direkt über rung um 100% wird vom zusätzlichen Kommunikati- C# angesprochen werden können, um den Entwickler onsaufwand verursacht. Die Produktivitätssteigerung bei der Gestaltung des Spiels alle Freiheiten zu bieten. nimmt umso mehr ab, je später die neuen Teammit- Eigene Erfahrungen zeigen, dass sich unser Frame- glieder zum Projekt hinzugefügt werden. Der Effekt work und Vorgehen gut eignen, um neue Planspiele ist so stark, dass die im letzten Viertel des Projektzeit- zu entwickeln. Eines unserer Ziele ist es, in Zukunft raums hinzugefügten Mitarbeiter, die Produktivität mehrere neue Spiele zu entwickeln, um zu sehen, ob senken anstatt sie zu erhöhen. sich diese Erfahrung weiterhin bestätigen lässt. Da wir den Effekt implizit erzeugen, berücksichti- Obwohl unser Simulationsmodell schon viele Aspek- gen wir auch, dass er in bestimmten Fällen schwächer te der Softwareentwicklung enthält, gibt es noch eini- oder gar nicht auftritt. Das passiert beispielsweise, ge offene Punkte, wie beispielsweise die Arbeitsumge- wenn die neuen Mitarbeiter schon Wissen über das bung und Gestaltung des Arbeitsplatzes, die bislang Projekt mitbringen, die Einarbeitung besonders leicht bei der Berechnung des Projektverlaufs noch nicht ist, das neue Personal über deutlich bessere Fähigkei- berücksichtigt werden. Unser Ziel ist es, das Modell Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 61 Alexander Nassal und Matthias Tichy - Ein Framework zur Erstellung von Planspielen zur Softwaretechnik kontinuierlich zu erweitern und dabei immer besser [Madachy 2007] M ADACHY, R.J.: Software Process auf die Realität abzustimmen. Das kann neben dem Dynamics. Wiley, 2007 Hinzufügen neuer Aspekte, auch durch die Verfeine- rung bestehender Aspekte geschehen. [Microsoft Corporation 2013] M ICROSOFT C ORPORA - TION : Microsoft Project. Version 2013. 2013 Des Weiteren wollen wir die Werkzeugunterstüt- zung ausbauen. Momentan ist die grafische Oberflä- [Nassal 2014] N ASSAL, Alexander: A General Frame- che nur für Szenarien verfügbar, die sich im XML- work for Software Project Management Simulation Format speichern lassen. Spezielle Ereignisse und Ver- Games. In: Information Systems and Technologies änderungen, die nur durch ausführbaren Code de- (CISTI) 2014, 9th Iberian Conference on Information finiert werden können, werden von der Oberfläche Systems and Technologies, 2014, S. 321–325 momentan nicht unterstützt. Ein Ziel ist es, unabhän- gig vom XML-Format auch anders definierte Szenarien [Nassal 2015] N ASSAL, Alexander: Projektmanage- mit dem Werkzeug analysieren zu können. ment spielend lernen. In: Tagungsband des 14. Work- Das Evaluationsframework wird im derzeitigen shops ”Software Engineering im Unterricht der Hoch- Stand rein über Quellcode konfiguriert und über die schulen"2015, Dresden, Deutschland, 26. - 27. Febru- Kommandozeile ausgeführt. Ziel ist es, auch hierfür, ar 2015, 2015, 53–64 soweit möglich, eine grafische Oberfläche bereitzustel- [Nassal u. Tichy 2016] N ASSAL, Alexander ; T ICHY, len, welche die Tests ausführen und deren Auswer- Matthias: Modeling Human Behavior for Software tung entsprechend aufbereiten kann. Hier bietet sich Engineering Simulation Games. In: Proceedings of auch die Möglichkeit, eine noch genau zu definieren- the 5th International Workshop on Games and Soft- de Methodik zur Evaluation von Planspielszenarien ware Engineering. New York, NY, USA : ACM, 2016 und Modellen in das Werkzeug zu integrieren, um (GAS ’16). – ISBN 978–1–4503–4160–8, 8–14 diesen Schritt auch methodisch besser unterstützen zu können. [Navarro 2006] N AVARRO, Emily: SimSE: A Software Engineering Simulation Environment for Software Literatur Process Education, University of California, Irvine, [Abdel-Hamid u. Madnick 1991] A BDEL -H AMID, Ta- Diss., 2006 rek K. ; M ADNICK, Stuart E.: Software Project Dyna- [de Oliveira Barros u. a. 2006] O LIVEIRA B ARROS, Már- mics: An Integrated Approach. Englewood Cliffs, NJ cio de ; D ANTAS, Alexandre R. ; V ERONESE, Gusta- : Prentice Hall, 1991. – 264 S. vo O. ; W ERNER, Cláudia Maria L.: Model-driven Game Development: Experience and Model Enhan- [Brooks 1975] B ROOKS, Frederick P. Frederick P.: The cements in Software Project Management Educati- Mythical Man-Month: Essays on Software Enginee- on. In: Software Process: Improvement and Practice ring. Reading, Mass. Addison-Wesley Pub. Co., 1975. 11 (2006), Nr. 4, S. 411–421 – ISBN 0–201–00650–2 [Reich 2008] R EICH, K.: Konstruktivistische Didaktik: [Cherif u. Davidsson 2010] C HERIF, Redha ; D AVIDS - Lehr- und Studienbuch mit Methodenpool. Beltz, SON , Paul: Software Development Process Simu- 2008 (Beltz Pädagogik). – ISBN 9783407254924 lation: Multi Agent-Based Simulation versus Sys- tem Dynamics. In: Proceedings of the 10th Interna- [Sommerville 2001] S OMMERVILLE, Ian: Software En- tional Conference on Multi-Agent-Based Simulation, gineering (6th Ed.). Boston, MA, USA : Addison- Springer-Verlag, 2010 (MABS’09), S. 73–85 Wesley Longman Publishing Co., Inc., 2001. – ISBN 0–201–39815–X [Coleman u. a. 1994] C OLEMAN, Derek ; A RNOLD, Patrick ; B ODOFF, Stephanie ; D OLLIN, Chris ; [Weller 1993] W ELLER, E. F.: Lessons from three years G ILCHRIST, Helena ; H AYES, Fiona ; J EREMAES, Paul: of inspection data (software development). In: IEEE Object-oriented Development: The Fusion Method. Up- Software 10 (1993), Sept, Nr. 5, S. 38–45. – ISSN per Saddle River, NJ, USA : Prentice-Hall, Inc., 1994 0740–7459 [Jain u. Boehm 2006] JAIN, Apurva ; B OEHM, Bar- [Wickenberg u. Davidsson 2002] W ICKENBERG, Tham ry W.: SimVBSE: Developing a Game for Value- ; D AVIDSSON, Paul: On Multi Agent Based Simu- Based Software Engineering. In: CSEE&T, IEEE lation of Software Development Processes. In: In Computer Society, 2006, S. 103–114 Sichman, 2002, S. 104–113 [Ludewig u. a. 1992] L UDEWIG, J. ; B ASSLER, T. ; D EI - [Ye u. a. 2007] Y E, En ; L IU, Chang ; P OLACK-WAHL, NINGER , M. ; S CHNEIDER, K. ; S CHWILLE , J.: SESAM- J.A.: Enhancing Software Engineering Education simulating software projects. In: Software Enginee- Using Teaching Aids in 3-D Online Virtual Worlds. ring and Knowledge Engineering, 1992. Proceedings., In: Frontiers In Education Conference - Global Engi- Fourth International Conference on, 1992, S. 608– neering: Knowledge Without Borders, Opportunities 615 Without Passports, 2007 Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 62