=Paper=
{{Paper
|id=Vol-1790/paper06
|storemode=property
|title=Ein Framework zur Erstellung von Planspielen zur Softwaretechnik
|pdfUrl=https://ceur-ws.org/Vol-1790/paper06.pdf
|volume=Vol-1790
|authors=Alexander Nassal,Matthias Tichy
|dblpUrl=https://dblp.org/rec/conf/seuh/NassalT17
}}
==Ein Framework zur Erstellung von Planspielen zur Softwaretechnik==
https://ceur-ws.org/Vol-1790/paper06.pdf
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