Sind Software Projektsimulationen auch an Berufsbildenden Höheren Schulen einsetzbar?

Transkript

1 Sind Software Projektsimulationen auch an Berufsbildenden Höheren Schulen einsetzbar? Dipl.-Ing. Susanne Nusser Institut für Informatik-Systeme Universität Klagenfurt Universitätsstraße Klagenfurt Extended Abstract: Die Durchführung eines Softwareentwicklungsprojektes ist ein komplexer Vorgang. Darum wird in der universitären Informatik-Ausbildung versucht auf diese Problematik einzugehen. Softwareprojektmanagement kann aber leider meist nur in Form von theoretischen Lehrveranstaltungen und unterstützt durch Fallstudien vermittelt werden. Die Durchführung eines praxisnahen Projektes ist nicht möglich, da der Umfang eines durchschnittlichen realen Softwareprojektes den Rahmen jeder Lehrveranstaltung sprengen würde. Um Studierenden trotzdem eine praxisnähere Ausbildung im Bereich Softwareentwicklung bieten zu können, wird seit einigen Jahren an der Universität Klagenfurt ein Simulator eingesetzt, der es den Studierenden ermöglicht ein virtuelles Softwareprojekt in der Rolle des Projektleiters durchzuführen. Auf diese Weise kann der Studierende seine Fähigkeiten als Projektleiter in einer geschützten Umgebung unter Beweis stellen. Die theoretischen Grundlagen können durch den Einsatz des Simulators praktisch belegt und für Studierende am eigenen Leib erlebbar gemacht werden. Sie erfahren welche Schwierigkeiten während eines Softwareentwicklungsprojektes auftreten und welche Auswirkungen bestimmte Managemententscheidungen mit sich bringen. Außerdem haben junge Projektleiter durch die Simulation die Möglichkeit unterschiedliche Vorgehensweisen bei der Projektdurchführung auszuprobieren, was in realen Projekten zu schmerzhaften Erfahrungen führen könnte. Diese Arbeit stellt den an der Universität Klagenfurt verwendeten SESAM- Simulator vor, beschäftigt sich aber auch mit den Erweiterungen des Systems, die im Rahmen des AMEISE-Projektes durchgeführt wurden, um einen Einsatz in der Lehre überhaupt erst möglich zu machen. Dabei wird der Fokus vor allem auf die neuen Komponenten (Ratgeber, Schutzengel und Online-Auswertung) gesetzt, die den Studierenden während der Simulationsläufe unterstützen bzw. den Lehrveranstaltungsleiter entlasten sollen.

2 Da die Erfahrungen mit dem System gezeigt haben, dass der Lernerfolg nur dann eintritt, wenn die simulierten Projekte anschließend analysiert und in einer Feedback-Sitzung zusammen mit dem Lehrveranstaltungsleiter diskutiert werden, geht die Arbeit auch darauf ein wie das Projektsimulationssystem AMEISE in der Lehre eingesetzt wird. Dazu wird die Gliederung der Lehrveranstaltung vorgestellt, die sich aus einer Einführungseinheit, in der die Simulationsumgebung erklärt wird, sowie zwei Simulationsläufen mit anschließender Feedback-Sitzung zusammensetzt. In den Feedback-Sitzungen werden interessante Aspekte unterschiedlicher Simulationsläufe gegenübergestellt, wodurch den Studierenden der Zusammenhang zwischen einzelnen Managemententscheidungen und deren Auswirkungen auf das Projekt vor Augen geführt wird. Die Durchführung einer weiteren Simulation soll es den jungen Projektleitern erlauben ihre Projektentscheidungen aus der ersten Simulation zu überdenken und ihre Taktik im zweiten Simulationslauf zu verbessern. Schlussendlich beleuchtet diese Arbeit die Frage, ob der Einsatz des AMEISE- Systems auch im schulischen Rahmen denkbar wäre. Dazu wird der Lehrplan der Handelsakademie für Digital Business (Wirtschaftsinformatik) vorgestellt, wobei speziell auf das Unterrichtsfach Softwareentwicklung, Projektmanagement und Projektarbeit eingegangen wird. Basierend auf den Erfahrungen, die in den vergangenen Jahren an der Universität Klagenfurt gemacht wurden, werden unterschiedliche Aspekte des AMEISE-Systems diskutiert, die den Einsatz des Simulators im schulischen Unterricht positiv oder negativ beeinflussen könnten. 1 Motivation Die Durchführung eines Softwareentwicklungsprojektes erfordert aufgrund seiner Komplexität ein Fingerspitzengefühl des Projektleiters 1 in unterschiedlichsten Bereichen. Viele Aspekte müssen beachtet werden, damit ein Projekt erfolgreich beendet werden kann. Untersuchungen von Softwareprojekten haben eine Vielzahl von Problemen aufgezeigt, die während der Entwicklung auftreten können. Diese reichen von nahe liegenden terminlichen oder budgetären Problemen über fehlende Ressourcen im Personalbereich bis hin zu Fehlern, die bei der Anforderungsanalyse oder im Design geschehen. Die universitäre Ausbildung versucht zwar in Form von verschiedenen Lehrveranstaltungen Studierende für unterschiedliche Bereiche des Softwareprojektmanagements auszubilden, kann aber in vielen Fällen nur theoretisch auf Vorgehensweisen und Probleme eingehen, die während des Software-Entwicklung auftreten, da es kaum möglich ist alle Eventualitäten in einem Laborprojekt nachzustellen. Die Durchführung eines durchschnittlichen Softwareentwicklungsprojekts würde aufgrund des Umfangs sowohl zeitlich als auch inhaltlich jeden Lehrveranstaltungsrahmen sprengen. 1 Der einfacheren Formulierung halber werden in dieser Arbeit ausschließlich männliche Bezeichnungen verwendet, sie gelten dem Sinn gemäß jedoch beidgeschlechtlich.

3 An der Universität Klagenfurt werden zwar Studenten-Projekte durchgeführt, allerdings handelt es sich dabei nicht um vergleichbare Größenordnungen. Lange wurde überlegt, wie den Studierenden eine bessere Ausbildung in diesem Bereich geboten werden kann. Im Zuge dieser Überlegungen stieß man auf den SESAM-Simulator [MHB03] durch dessen Einsatz die Lücke in der Ausbildung der Studierenden laut Untersuchungen [Man01] geschlossen werden kann. Die Idee ist es die Studierenden in die Rolle des Projektleiters schlüpfen zu lassen, um in einer sicheren Simulationsumgebung die Durchführung von Softwareprojekten trainieren zu können. Zu den Aufgaben der jungen Projektleiter zählen: Personalmanagement, Projektorganisation und die Qualitätssicherung zur Feststellung der Qualität von Dokumenten. Das Ziel der Simulation ist es das Projekt in einem festgelegten Zeitrahmen und mit vorgegebenem Budget fertig zu stellen, wobei der geforderte Produktumfang und die vom Kunden gewünschte Produktqualität erreicht werden müssen. Die Simulationsläufe werden anschließend analysiert. Die sichere Simulationsumbebung ermöglicht es, dass Studierende unterschiedliche Vorgehensweise bei der Softwareentwicklung trainieren können, da ein Scheitern des Projektes keine Konsequenzen mit sich bringt. Auf diese Weise kann der Zusammenhang zwischen falschen Projektentscheidungen und deren Auswirkungen besser verstanden werden. Außerdem erfahren die Studierenden am eigenen Leib welche Probleme während der Entwicklung von Software auftreten können. Die Erfolge, die der Einsatz des Simulators in der universitären Ausbildung mit sich brachte, führten zu der Überlegung, ob der Einsatz nicht auch in Berufsbildenden Höheren Schulen möglich wäre. Diese Arbeit fasst die Überlegungen dazu zusammen. Dazu wird in Kapitel 2 wird SESAM und dessen Erweiterungen vorgestellt. Die bisherige Verwendung des erweiterten Simulators in Lehrveranstaltungen an der Universität Klagenfurt wird in Kapitel 3 beleuchtet. Unter Berücksichtigung der dort genannten Erfahrungen wird ein möglicher Einsatz in der Handelsakademie mit Spezialzweig digital business in Kapitel 4 diskutiert. Kapitel 5 fasst abschließend die wichtigsten Erkenntnisse nochmals zusammen. 2 Projektsimulation mit der AMEISE Das folgende Kapitel beschreibt den SESAM-Simulator sowie die Erweiterungen daran, die im Rahmen des AMEISE-Projekts durchgeführt wurden.

4 2.1. Der SESAM-Simulator Der SESAM-Simulator (Software Engineering Simulation by Animated Models) wurde an der Universität Stuttgart von Prof. Ludewig und seinen Mitarbeitern entwickelt. Relevante Objekte eines Projekts (Kunde, Entwickler, Dokumente) werden simuliert, während der Studierende in Form des Projektleiters mit dem System interagiert. SESAM wurde im Rahmen des AMEISE-Projekts durch zahlreiche nützliche Komponenten erweitert, die im Abschnitt 2.2. genauerer erläutert werden. Bevor die Simulation gestartet werden kann, muss ein Modell eingespielt werden. Der Projektleiter in Form eines Studierenden kann dann Kommandos in natürlicher Sprache absetzen. Diese werden vom System interpretiert und anschließend im Simulator verarbeitet. Das Absetzen von Kommandos ändert den internen Zustand des Simulators. Nach der Verarbeitung eines Kommandos wird der neue Zustand des Simulators berechnet und eine Antwort an den Studierenden zurückgegeben. Gleichzeitig werden diese Informationen in einer Log-Datei gespeichert, die nach Beendigung der Simulation unter Zuhilfenahme von Analysewerkzeugen ausgewertet werden kann. Dadurch wird eine Bewertung der Simulationsläufe möglich. Theoretisch könnte man jedes erdenkliche Projekt mit Hilfe von SESAM simulieren. Dazu müssen vorab alle Objekte und Abhängigkeiten in Form eines Modells dargestellt werden. In dieser Arbeit wird jedoch nur auf das Qualitätssicherungsmodell Bezug genommen. Das Qualitätssicherungsmodell Aufgrund von empirischen Daten wurde ein Modell entwickelt, dass realitätsnah nahezu alle Aspekte eines Softwareentwicklungsprojekts widerspiegelt. Das Qualitätssicherungsmodell repräsentiert Projekte mit einem Umfang von 200 bis 1200 AFPs (adjusted function points) und simuliert typische Probleme, die während der Projektlaufzeit auftreten können. Allerdings wurde das Modell sehr stark nach dem Wasserfallmodell ausgerichtet, dass Studierende belohnt, die ein derartiges Vorgehen an den Tag legen. Ein weiterer wichtiger Aspekt ist die Qualitätssicherung, die sich im Modell verbirgt. So können einmal erstellte Dokumente nur durch das Durchführen von Reviews verbessert werden. Das Modell lehrt die Studierende aber nicht nur die Phasen des Vorgehensmodells, sondern auch das Treffen der richtigen Personalentscheidungen. Das Projekt beginnt mit einem Projektauftrag, der dem jungen Projektleiter die Eckdaten (Budget, Zeit, Qualitätsanforderungen und Projektumfang) zum gewünschten Softwareprodukt liefert. Im ersten Schritt muss der Projektleiter Personalentscheidungen treffen, d.h. die notwendigen Mitarbeiter einstellen, die er zur Durchführung des Projektes benötigt. Um entscheiden zu können wer welche Aufgaben im Projekt übernehmen kann, sollten vorerst die Lebensläufe (enthalten Fähigkeiten und Kosten) der am virtuellen Arbeitsmarkt verfügbaren Personen genauer unter die Lupe genommen werden.

5 Hat der Projektleiter alle Aufgaben für einen Arbeitstag vergeben, kann er zum nächsten Tag weiterschalten. Das System berechnet den Projektfortschritt und verhält sich so, als wäre der Projektleiter am nächsten Werktag wieder ins Büro gekommen. Sofern am vergangenen Arbeitstag Dokumente von den Mitarbeitern fertig gestellt wurden, werden dem Projektleiter nun dementsprechende Meldungen angezeigt. Um so realitätsnah wie möglich zu sein, werden nur die Informationen an den Projektleiter weitergegeben, die er auch in einem realen Projekt bekommen würde. Nun kann der Studierende sein weiteres Vorgehen überlegen und die Aufgaben für den aktuellen Arbeitstag an seine Mitarbeiter verteilen. Sofern die Mitarbeiter aber noch vom Vortag mit Aufgaben betraut sind, d.h. diese noch nicht fertig gestellt haben, arbeiten sie eigenständig daran weiter. Die Kontrolle der Qualität sowie die Auslastung der Mitarbeiter sind zusätzliche Aufgaben, die die jungen Projektleiter bewältigen müssen. Für den erfolgreichen Abschluss des Projekts genügt es nicht nur den vorgegebenen Zeitplan einzuhalten und den budgetären Rahmen nicht zu überziehen. Es müssen auch festgelegte Qualitätsziele erreicht werden. Eine umfassende Zusammenfassung zu SESAM und dem Qualitätssicherungsmodell findet sich in [Jäg03]. Lernziele des Qualitätssicherungsmodells Das Modell konzentriert sich vor allem auf konstruktive, analytische und korrigierende Maßnahmen. Studierende können damit nicht nur die Durchführung von Qualitätssicherungsmaßnahmen trainieren, sondern auch die Auswirkungen von Personalmanagemententscheidungen am eigenen Leib erfahren. Das Erlernen von Projektmanagementfähigkeiten steht aber im Vordergrund. Die Studierenden sollen lernen, dass Projekte im Voraus gründlich geplant und vorbereitet werden müssen. Außerdem sollen sie merken, wie wichtig es ist die richtigen Mitarbeiter aus dem Personalangebot auszuwählen und sie dann entsprechend ihrer Qualifikationen einzusetzen. Ebenso soll der zukünftige Projektleiter lernen, welche Entscheidungen in welchen Situationen getroffen werden müssen, damit auch kritische Projekte noch zu einem erfolgreichen Abschuss gebracht werden können Erweiterungen im Rahmen des AMEISE-Projekts Bevor der Simulator in einer Lehrveranstaltung eingesetzt werden konnte, musste er um einige Hilfsmittelkomponenten erweitert werden. Dazu wurde das Projekt AMEISE (A Media Education Initiative for Software Engineering) [MHB03] ins Leben gerufen. Im Rahmen des Projektes wurde der Simulator um Komponenten erweitert, die zum einen die Studierenden während der Simulationsläufe unterstützen sollen und zum anderen den Lehrveranstaltungsleiter bei der Betreuung und Auswertung der Simulationsläufe entlasten sollen. Die Abbildung 1 zeigt den alten SESAM-Kern und die AMEISEspezifischen Erweiterungen. Einen Überblick über die unterschiedlichen Erweiterungen, die im Rahmen des AMEISE-Projekts durchgeführt wurden bietet [JHM05]. Auf einige dieser Erweiterungen wird hier näher eingegangen.

6 Abb. 1.: SESAM-Simulator und AMEISE-Erweiterungen [Jäg05] Da die Kommunikation mit dem Simulator über eine textbasierte Schnittstelle erfolgt kam es häufig aufgrund von Tippfehlern dazu, dass es dem Simulator nicht möglich war den Befehl auszuwerten. Deshalb wurde zuerst an einer Verbesserung der Befehlseingabe gearbeitet. Durch das Zusammenbauen von Befehlen mit einigen wenigen Mouse-Klicks konnte der Zeitaufwand für einen Simulationslauf drastisch reduziert werden. Zu den wichtigeren Erweiterungen zählen aber der Schutzengel, der Ratgeber und die Online-Auswertung (Evaluation). Der Schutzengel sowie der Ratgeber sind Komponenten, die den Studierenden während der Simulation unterstützen sollen. Weiß der Studierende in einer bestimmten Situation nicht, wie er vorgehen soll, dann kann er den Ratgeber um Hilfe bitten. Der Ratgeber ist wie ein guter Freund zu verstehen, der dem Studierenden zwar nicht die Entscheidung abnimmt, aber ihm vielleicht einen Tipp gibt der ihm bei der Entscheidung hilft. Im Gegensatz dazu steht der Schutzengel, der dem Studierenden ständig aber unbemerkt, über die Schulter schaut und aktiv wird, wenn der Studierende offensichtlich eine Fehlentscheidung getroffen hat. Allerdings erinnert der Schutzengel erst im Nachhinein, dass es aufgrund der letzten Entscheidung zu Problemen kommen könnte. Der Studierende hat aber die Möglichkeit durch seine weiteren Entscheidungen den Schaden zu begrenzen. Man kann an dieser Stelle kritisieren, dass die beiden Komponenten dazu führen, dass der Studierende durch das Projekt geführt wird, d.h. rechtzeitig vor Fehlern gewarnt wird und somit nicht in die Verlegenheit gerät, ein Projekt in den Sand zu setzen. Diese Kritik ist sicherlich berechtigt, es wurde aber darauf geachtet, dass der Lehrveranstaltungsleiter die Möglichkeit hat diese Komponenten für einen Simulationslauf zu- oder wegzuschalten. Auf diese Weise können Studierende geführt oder eigenständig als Projektleiter agieren. Eine besonders für den Lehrveranstaltungsleiter wichtige Komponente ist die Online- Auswertung, die es den Studierenden ermöglicht ihrer Simulationsläufe gleich nach Beendigung der Simulation selbst auszuwerten. Allerdings ist es für die Erreichung des maximalen Lernerfolges trotzdem notwendig die Simulationsläufe verschiedener Teilnehmer in einer Feedback-Sitzung vorzustellen.

7 Das Gegenüberstellen von guten und schlechten Projektverläufen sowie die Diskussion warum es zu bestimmten Problemen gekommen ist und wie man diese noch rechtzeitig verhindern hätte können, sind entscheidend für den Lernerfolg. 3 Der Einsatz des AMEISE-Systems an der Universität Das AMEISE-System wurde das erste Mal im Sommersemester 2002 im Rahmen der Pflichtlehrveranstaltung Systementwicklungsprozess an der Universität Klagenfurt eingesetzt [JHM04]. Da für die Durchführung der simulierten Softwareprojekte ein gewisses Vorwissen notwendig ist, wurde bewusst der Rahmen einer Lehrveranstaltung für Studierende höherer Semester ausgewählt. Aufgrund der Erfahrungen, die dort gesammelt wurden, gab es ständige Erweiterungen und Verbesserungen der Simulationsumgebung. Nach der Fertigstellung der Hilfsmittelkomponenten (Ratgeber, Schutzengel und Online-Auswertung) wurde die AMEISE in der Wahl- Lehrveranstaltung Management von SW-Projekten im Wintersemester 2003/04 mit einer Gruppe von 27 Studierenden getestet Einbettung der AMEISE in eine Lehrveranstaltung Ziel der Lehrveranstaltung Management von SW-Projekten war der Versuch das AMEISE-System in einer Lehrveranstaltung mit durchschnittlicher Teilnehmerzahl und betreut von lediglich einem Lehrveranstaltungsleiter durchzuführen. Die Lehrveranstaltung wurde dazu in fünf Blöcke (Einführung, erster Simulationslauf, Zwischenbesprechung, zweiter Simulationslauf und Abschlussbesprechung) unterteilt. Die Auswertung der Projektverläufe wurde damals wie heute mit Hilfe eines Analysewerkzeuges, aber in einem recht zeitaufwändigem Verfahren, vorgenommen. Dazu werden Eckdaten der Spielverläufe erhoben, die dann vom Lehrveranstaltungsleiter (einem AMEISE-Experten) interpretiert werden müssen. Er kann damit interessante Aspekte des Projektes auswerten und in der Zwischen- bzw. Abschlussbesprechung gegenüberstellen. Im Folgenden werden die einzelnen Lehrveranstaltungsblöcke genauer vorgestellt. Einführungsveranstaltung Der erste Block wird dazu genutzt, um den Studierenden die Simulationsumgebung näher zu bringen und einige Eigenheiten des Simulators sowie des Modells, das dem simulierten Software-Projekt zugrunde liegt, vorzustellen.

8 Erste Simulation Im ersten Simulationslauf ist der Lehrveranstaltungsleiter anwesend und unterstützt die Studierenden bei eventuellen Problemen. Allerdings ist es wichtig, dass der Betreuer nicht in die Projektplanung der Studierenden eingreift, da sonst die Ergebnisse verfälscht werden. Der Lehrveranstaltungsleiter ist also angehalten nur Fragen zur Simulationsumgebung nicht aber zum eigentlichen Projekt zu beantworten. Für die erste Projektsimulation benötigen die Studierenden rund viereinhalb Stunden, was vor allem durch den ungeschulten Umgang mit dem Simulator erklärt werden kann. Zwischenbesprechung In der folgenden Feedback-Sitzung werden die zuvor vom Lehrveranstaltungsleiter ausgewerteten Projekte vorgestellt und interessante Aspekte genauer beleuchtet. Ziel sollte es sein sowohl Probleme zu diskutieren, die während des Projekts aufgetreten sind, als auch deren Ursachen zu ergründen. Der Vergleich von guten und schlechten Projektverläufen soll den Studierenden in dieser Phase zeigen, wie unterschiedlich ein Projekt durchgeführt werden kann und welche Vor- bzw. Nachteile bestimmte Managemententscheidungen mit sich bringen. Zweite Simulation Im zweiten Simulationslauf haben die Studierenden die Möglichkeit das gleiche Projekt nochmals durchzuführen und ihre Vorgehensweisen aufgrund der in der Zwischenbesprechung diskutierten Punkte zu verändern. Das Ziel ist es, dass die Studierenden im zweiten Spiel eine deutliche Verbesserung zeigen. Da den Studierenden nun der Umgang mit dem Simulator geläufig ist und häufig auch eine Vorbereitung in Form eines Projektplans vorliegt, benötigen sie für die Projektsimulation nur mehr ungefähr drei Stunden. Abschlussbesprechung Nach der Auswertung der zweiten Simulationsläufe werden die Verbesserungen in der Vorgehensweise besprochen und hinterfragt warum bestimmte Managemententscheidungen anders als in der ersten Simulation getroffen wurden. In den vergangenen Jahren wurde die Abschussbesprechung auch dazu benutzt, um Ideen und Anregungen für die Verbesserung der Simulationsumgebung zu diskutieren.

9 Die Erfahrungen aus der Lehrveranstaltung Management von SW-Projekten sowie viele positive Rückmeldungen von den Studierenden haben dazu geführt, dass die AMEISE seit dem Sommersemester 2004 ein wichtiger Bestandteil der Lehrveranstaltung IT-Projektmanagement und Change geworden ist, die sich mit den theoretischen Grundlagen von Softwareentwicklungsprojekten, aber auch mit Fallstudien zu diesem Thema beschäftigt. Der Einsatz der AMEISE rundet diese Lehrveranstaltung perfekt ab, weil die Studierenden auch die Möglichkeit haben ihre Projektmanagementfähigkeiten unter Beweis zu stellen. Aufgrund des enormen Aufwands bei der Auswertung werden allerdings nur kleine Gruppen von maximal fünfzehn Studierenden in die Lehrveranstaltung aufgenommen Erfahrungen mit dem Einsatz des AMEISE-Systems An dieser Stelle muss zwischen Erfahrungen unterschieden werden, die die Simulationsumgebung oder das Modell betreffen. Im Folgenden werden nur exemplarisch einige, für diese Arbeit relevante, Aspekte beschrieben. Eine ausführliche Beschreibung der Erfahrungen findet sich in [JHM04]. Sehr positiv wurde die Online-Auswertung bewertet, die es den Studierenden ermöglicht ihre Projektverläufe selbst zu analysieren. Diese Komponente wurde allerdings eher für den zweiten Simulationslauf als hilfreich empfunden, da die Studierenden bereits wussten welche Aspekte interessant sind und wie die unterschiedlichen Diagramme gedeutet werden müssen. Die Zwischenbesprechung, in der der Lehrveranstaltungsleiter den Studierenden die interessanten Punkte vorstellt, wurde von Seiten der Studierenden als unerlässlich empfunden. Die Besprechung des zweiten Simulationslaufs hingegen wäre aus der Sicht der Studierenden nicht unbedingt nötig, da in diesem Fall die Online- Auswertung der AMEISE ausreichen würde, um eigenständig eine Analyse des Simulationslaufs vorzunehmen. Das Zu- bzw. Wegschalten von Hilfskomponenten wie Schutzengel und Ratgeber wurde von den Lehrveranstaltungsleitern als großer Vorteil gesehen, da dadurch die Vorkenntnisse der Gruppe besser berücksichtigt werden können. Bei Studierenden, die bereits Projektmanagementerfahrungen haben, müssen diese Hilfsmittel nicht aktiviert werden. Entscheidender für den Einsatz an Schulen sind aber die folgenden Erfahrungen, die das Modell betreffen. Ein Hemmschuh ist sicherlich die lange Simulationszeit, die trotz der Erweiterungen, die es ermöglichen mittels einigen Mouse-Klicks die Befehle zusammenzusetzen im Durchschnitt dreieinhalb Stunden beträgt. Nach etwa zwei Drittel des Simulationslaufes konnte ein Nachlassen der Aufmerksamkeit und Motivation bemerkt werden. Studierende empfanden die lange Simulationszeit als kaum noch zumutbar.

10 Um gegen dieses Problem vorzugehen, wurde versucht die Simulation auf zwei Termine zu verteilen. Das war möglich, da ein Speichern und Laden von Projektzuständen im Simulator vorgesehen ist. Allerdings trat dann ein anderes Problem auf. Wurde die Simulation länger als nur für eine Mittagspause unterbrochen, oder wurde die Simulation erst am nächsten Tag fortgesetzt, so war es für die Studierenden schwierig wieder den Anschluss zu finden. Fragen wie Wer macht gerade was? und Welche Dokumente sind schon korrigiert worden? führten nachweislich dazu, dass sich die Qualität der Projekte gegen Ende der Simulation verschlechterte. Eine weitere interessante Beobachtung betraf die Art und Weise der Projektplanung. Die Studierenden wurden zwar in der Einführungsveranstaltung darauf hingewiesen, dass die Erstellung eines Projektplans vor Simulationsstart sinnvoll ist, dennoch hat die Mehrheit der Studierenden bei Ihrem ersten Simulationslauf beinahe gänzlich auf einen Projektplan verzichtet. Spätestens nach Ablauf der Hälfte der Projektlaufzeit, wenn die Komplexität einen Punkt überschreitet, der für die Studierenden noch überschaubar ist, konnten viele Projekte aufgrund der chaotischen Projektorganisation nicht mehr erfolgreich beendet werden. Nach Diskussion dieses Problems in der Zwischenbesprechung haben die Studierenden die Notwendigkeit eines Projektplans erkannt und in der zweiten Simulation diesen auch vorab erstellt. 4 AMEISE an Schulen? Die positiven Erfahrungen vom Einsatz des Simulators in der Universität Klagenfurt führten zu der Überlegung, ob man diese Trainingsmöglichkeit nicht auch an Schulen einsetzen könnte. Aufgrund der Komplexität der Aufgaben, die ein Projektleiter übernehmen muss und der Kenntnisse über das Vorgehen bei der Durchführung eines Softwareentwicklungsprojektes ist ein Einsatz des SESAM-Simulators prinzipiell nur in Schulen mit Informatikschwerpunkt und dort nur in den Oberstufen denkbar. Zur Untersuchung, ob der Umgang mit dem Simulator im Unterricht zielführend wäre, wurde die Handelsakademie mit Spezialzweig digital business ausgewählt, da hier der Einsatz nicht wie bei Schulen mit rein technischer Ausbildung auf der Hand liegt Überlegungen zum Lehrplan Analysiert man den Lehrplan der Handelsakademie mit Spezialzweig digital business [Leh01] kann man feststellen, dass im vierten und fünften Jahrgang das Fach Softwareentwicklung, Projektmanagement und Projektarbeit dafür notwendige Themen behandelt (siehe folgender Auszug aus dem Lehrplan des vierten Jahrgangs):

11 Methoden des Projektmanagements: Zielformulierung (Teambildung, Funktionen, Verantwortungen); Steuerung und Kontrolle; Kommunikation und Dokumentation. Anwendung der Methoden des Projektmanagements auf die SW-Entwicklung: Planungsphase (Machbarkeitsstudie, Lastenheft); Definitionsphase (Produktspezifikation unter Berücksichtigung ergonomischer Anforderungen, Pflichtenheft); Entwurfsphase (Einsatz von CASE Tools, Produktentwurf, Prototyping); Implementierungsphase (Modellierung, Programmierung, Technische Dokumentation, Test und Qualitätssicherung, Testprotokoll, Produkt); Abnahme (Übergabe, Abnahmetest, Abnahmeprotokolle); Einführungsphase (Schulung, Manual); Wartungs- und Pflegephase (Helpdesk). Unterteilt man das Schuljahr in drei Schwerpunktbereiche so kann im vierten Jahrgang das Vorwissen, das zur Durchführung einer Software-Projektsimulation notwendig ist, erarbeitet werden. Den Beginn macht der Schwerpunkt Projektmanagement, wobei hier zuerst auf Projektziele, Beteiligte und Projektaufgaben sowie andere einführende Themen eingegangen werden sollte. Anschließend sollten unterschiedliche Methoden zu den Themen Zielfindung, Organisation, Projektstrukturierung, Projektplanung, etc. mit den Schülern erarbeitet werden. Wichtig ist in diesem Zusammenhang auch das Verständnis um die Komplexität des Faktors Mensch in einem Projekt, denn die Schüler haben noch keine Kenntnisse darüber, dass die Projektbeteiligten einen sehr starken Einfluss auf die erfolgreiche Durchführung eines Projektes haben. Den zweiten Schwerpunkt bildete das Software-Engineering, wobei hier zuerst einführende Begriffe wie Produktlebenszyklus, Projektphasen sowie Vorgehensmodell diskutiert werden sollten. Aufgrund der Themenvielfalt können kaum alle Phasen des Entwicklungsprozesses im Detail erläutert werden. Es sollte aber darauf geachtet werden, dass den frühen Phasen, also der Analyse und dem Entwurf, vermehrt Aufmerksamkeit zukommt, da Fehler in diesen Phasen gravierende Auswirkungen auf das Projekt haben. Die Schüler sollen zum einen Werkzeuge, wie UML erlernen, um damit Softwaresysteme modellieren zu können, zum anderen müssen sie aber auch die Notwendigkeit verstehen, die hinter dem Entwurf eines Systems steht. Andere Phasen wiederum, wie zum Beispiel die Implementierung oder die Testphase, können theoretisch im Schnelldurchlauf behandelt und erst im Rahmen eines anschließend durchgeführten Referenzprojektes auch praktisch erprobt werden. Zum Festigen der Theorie und der erlernten Methoden bildet ein Referenzprojekt den dritten Schwerpunkt des Schuljahres. Die Schüler bekommen die Aufgabe ein erstes eigenes Softwareprojekt durchzuführen, das allerdings noch während der einzelnen Projektphasen von der Lehrperson betreut wird.

12 Dazu wird in Kleingruppen gearbeitet, wobei zum einen Projektmanagement-Methoden angewendet werden müssen und zum anderen die Projekte alle klassischen Phasen der Software-Entwicklung durchlaufen. Diese Vorgehensweise ermöglicht den Schülern das erlernte theoretische und praktische Wissen im eigenen Projekt einzusetzen und zu festigen. Der Lehrplan des fünften Jahrgangs ist recht offen und kann für weitere Projekte und Vertiefungen in unterschiedliche Themengebiete genutzt werden Grenzen für den schulischen Einsatz Aufgrund der fehlenden Vorkenntnisse kann man schließen, dass der Einsatz der AMEISE in den vierten Jahrgängen verfrüht wäre, da die Schüler erst nach der Durchführung eines Softwareprojektes die Theorie besser begreifen und in die Praxis umsetzten können. Im fünften Jahrgang weisen die Schüler bereits ein Vorwissen über Projektmanagementaufgaben, Softwareentwicklung und auch ein paar praktische Erfahrungen durch die Durchführung des Referenzprojektes auf. Auch der Lehrplan des fünften Jahrgangs bietet genügend Platz für eine Vertiefung der Managementfähigkeiten in der Softwareentwicklung. Allerdings müssten die fünf Stunden geblockt abgehalten werden, um einen Simulationslauf zu ermöglichen. Andernfalls wäre es notwendig die Projektzustände zwischenzuspeichern und erst in der nächsten Unterrichtseinheit fortzusetzen. Da bereits an der Universität Klagenfurt Erfahrungen mit dem Unterbrechen von Simulationsläufen gemacht wurden und diese negative Auswirkungen auf die Qualität der Projekte hatten, ist von dieser Variante abzuraten. Würden die fünf Stunden zumindest für die Projektsimulation geblockt abgehalten, könnte diesen Motivationsproblemen entgegengewirkt werden. Anzunehmen ist aber, dass die Schüler mehr Zeit für die Simulation benötigen als die Studierenden. Laut Lehrplan stünde einem Simulatoreinsatz im fünften Jahrgang nichts im Wege. Untersucht man aber das Modell etwas genauer, welches das simulierte Softwareprojekt beschreibt, zeigen sich andere Schwierigkeiten. Die Modellbauer haben versucht den Entwicklungsprozess mit all seinen Eigenheiten so realitätsnah wie möglich zu simulieren. Dies spiegelt sich zum Beispiel in der Korrektheit von Informationen wider. Beispielsweise ist es möglich dem Verfasser eines Dokuments nach dessen Einschätzung über den Fertigstellungsgrad zu fragen. Man bekommt eine Aussage über die Seiten und eine ungefähre Abschätzung wie viel Prozent des Dokuments fertig gestellt wurden. Diese Angaben können stimmen oder auch nicht. Ob der Mitarbeiter dem Chef die Wahrheit sagt und in Wirklichkeit erst die halbe Arbeit erledigt hat ist unklar. Der Projektleiter muss seiner Aussage glauben. Diese und ähnliche Aspekte entsprechen zwar der Realität, erschweren aber die Arbeit des Projektleiters; vor allem junger unerfahrener Projektleiter.

13 Der Einsatz der AMEISE ist zwar auch im schulischen Umfeld möglich, allerdings kann nur dann ein hoher Lernerfolg erreicht werden, wenn das Modell einen Teil seiner Komplexität verliert. Die Aspekte, die zwar realitätsnahe sind, aber die Schüler aufgrund ihrer fehlenden Erfahrungen auf dem Gebiet nur verwirren, sollten aus dem Modell entfernt werden. Der Einsatz des bestehenden Modells würde geradewegs dazu führen, dass die Aufmerksamkeit von der eigentlichen Aufgabe, d.h. der Softwareentwicklung nach dem Wasserfallmodell unter Berücksichtigung der Qualitätssicherung, abgelenkt wird. Sinnvoller wäre es ein neues Modell zu entwickeln, dass speziell auf die Bedürfnisse der schulischen Ausbildung abgestimmt ist und sich nur auf das Trainieren der Projektdurchführung nach einem Vorgehensmodell und dem Einsatz von Qualitätssicherungsmaßnahmen beschränkt. Dieses Modell würde aufgrund der geringeren Komplexität auch zu einer kürzeren Simulationszeit führen und damit den schulischen Einsatz des Simulators ermöglichen. 5 Zusammenfassung Die praktische Durchführung von Softwareentwicklungsprojekten in Simulationsumgebungen stellt eine Verbesserung der universitären Ausbildung dar. Studierende können am eigenen Leib erfahren, welch schwierige Aufgaben ein Projektleiter meistern muss, um ein Projekt erfolgreich abschließen zu können. Eine bereits erprobte Umgebung stellt der SESAM-Simulator zur Verfügung, der außerdem ein auf empirischen Daten beruhendes Modell eines Softwareentwicklungsprojektes anbietet. Der Projektleiter muss dabei nicht nur auf zeitliche und budgetäre Rahmenbedingungen achten, sondern auch auf die Qualität der erstellten Dokumente. Der Einsatz des Simulators in einer eigenen Lehrveranstaltung an der Universität Klagenfurt hat die Lücke zwischen Theorie und Praxis geschlossen. Die Erfahrungen, die mit diesem System gemacht wurden, zeigen einen deutlichen Lernerfolg bei den Studierenden. Die theoretischen Grundlagen für die Durchführung erfolgreicher Softwareentwicklungsprojekte finden sich aber auch in den Lehrplänen der Berufsbildenden Höheren Schulen. Analysiert man aber den SESAM-Simulators und das relevante Modell genauer, wird deutlich, dass ein Simulatoreinsatz an Schulen nicht vorgenommen werden kann ohne Änderungen am Modell vorzunehmen. Die Komplexität des bestehenden Modells ist für eine schulische Anwendung zu hoch. Zielführender wäre die Entwicklung eines neuen Modells, das sich nur mit den Software-Entwicklungsphasen und der Qualitätssicherung beschäftigt, nicht aber mit Personal-, Kosten- und Krisenmanagement.

14 6 Literatur [MHB03] [JHM05] [Jäg05] [JHM04] [Man01] [Jäg03] [Leh01] Mittermeir R., Hochmüller E., Bollin A., Jäger S., Nusser M.: AMEISE - A Media Education Initiative for Software Engineering: Concepts, the Environment and Initial Experiences. In: M. E. Auer, U. Auer. (Hrsg.): Proceedings International Workshop ICL - Interactive Computer Aided Learning, Villach, Sept. 2003, electr. Proc. Kassel: Kassel Univ. Press September Jäger S., Hochmüller E., Mittermeir R., Bollin A., Wakounig D.: AMEISE - Didaktische Vielfalt für SESAM. In: Löhr K., Lichter H. (Hrsg.): Software Engineering im Unterricht der Hochschulen, SEUH 9 - Aachen Heidelberg: dpunkt.verlag 2005, S Jäger S.; Tutorial-Unterlagen zur didaktischen Vielfalt der AMEISE; SEUH'05 Konferenz, Aachen, Februar 2005; Jäger S., Hochmüller E., Mittermeir R., Bollin A., Wakounig D.: Systemunterstützung der Software-Projektmanagement- Ausbildung; TR-ISYS 01/11/04, Univ. Klagenfurt, Mandl-Striegnitz P.: Qualifizierte Software-Projektmanager durch simulationsbasierte Ausbildung; in: Lichter H., Ginz, M. (Hrsg.): Proc. Software Engineering im Unterricht der Hochschulen/SEUH Zürich, Jäger, S. Entwicklung eines elektronischen Tutors zur Analyse von Projektverläufen; Universität Klagenfurt, Institut für Informatik- Systeme, Lehrplan Schulversuch: Handelsakademie für Digital Business (Wirtschaftsinformatik); Modell II; Bundesministerium für Bildung, Wissenschaft und Kultur; Sektion Berufsbildung; Abteilung II/3; Wien