Iterative Prozessmodelle/SCRUM Marcus Hörger Seminar Iterative Prozessmodelle/SCRUM 14. Dezember 2010

Transkript

1 Iterative Prozessmodelle/SCRUM Marcus Hörger Seminar Iterative Prozessmodelle/SCRUM 14. Dezember Zusammenfassung - In dieser Arbeit wird zunächst der Begriff des Prozesses erläutert, und anhand des Software- Entwicklungsprozesses vorgestellt. Anschließend folgt eine Einführung in den Bereich der Prozessmodelle, wobei die linearen Prozessmodelle anhand des Phasenmodells erläutert werden. Bei den iterativen Prozessmodellen wird SCRUM ausgeführt. Es folgt eine kurze Einführung in das Risikomanagement anhand des Risikomamangement-Modells, bevor schließlich der Bezug zum Studienprojekt LaVida hergestellt wird U I. EINLEITUNG m zu verstehen, was ein Prozessmodell ist, wie es definiert wird, wozu man es in der Softwareentwicklung benötigt, welches Konsequenzen dadurch in den Entwicklung entstehen, muss man sich zunächst den Begriff des Prozesses vor Augen führen. Das Institute of Electrical and Electronics Engineers (IEEE) definiert den Prozess als A sequence of steps performed for a given purpose; for example, the software development process. (IEEE Standard) also eine Folge von Schritten, die für einen bestimmen Zweck durchgeführt werden. Im Folgenden wird der in der Softwareentwicklung wichtigste Prozess betrachtet, der Software-Entwicklungsprozess. A. Software-Entwicklungsprozess Die Grundlage aller Prozessmodelle ist der Software- Entwicklungsprozess. Er dient als Vorlage für die Aktivitäten, welche in den einzelnen Prozessmodellen definiert werden. Der Software-Entwicklungsprozess ist dabei definiert als Der Software-Entwicklungsprozess bestimmt also die einzelnen Schritte der Softwareentwicklung, von den Benutzerwünschen, bis hin zum fertigen Produkt. B. Prozessmodelle Der Software-Entwicklungsprozess ist die Grundlage für die Durchführung von Projekten. Um diesen Prozess in seiner Komplexität beherrschbar zu machen, bedient man sich verschiedener Prozessmodelle. Sie stellen eine Beschreibung dieses Prozesses als präskriptives Modell für die Durchführung der Projekte dar. Ein Prozessmodell beschreibt also das Vorgehen zur Organisation und Durchführung des Software-Entwicklungsprozess. Der Inhalt eines Prozessmodells besteht dabei zunächst aus den durchzuführenden Aktivitäten und der Definition der daraus entstehenden Teilprodukte. Gleichzeitig wird die Reihenfolge und Abhängigkeiten dieser Aktivitäten definiert. Prozessmodelle erlauben es, die Planung für jedes Projekt nicht von Grund auf neu durchführen zu müssen, sondern Planungen von der Stange zu verwenden. So lässt sich für jeden Projekttyp das passende Prozessmodell finden. Gleichzeitig können die Methoden der Softwareentwicklung standarisiert, und in das Prozessmodell mit aufgenommen werden. Ein weiterer Aspekt der Prozessmodelle und spezielle der iterativen Prozessmodelle ist die stetige Weiterentwicklungsmöglichkeiten der Modelle. So können Erfahrungen aus früheren Projekten in das Prozessmodell einfließen und dabei helfen, es zu verbessern und mögliche Schwachstellen zu erkennen, um diese in zukünftigen Projekten zu vermeiden. The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design into code, testing the code, and sometimes, installing and checking out the software for operational use (IEEE Standard) Abb.: Software-Entwicklungsprozess

2 II.LINEARE PROZESSMODELLE Lineare Prozessmodelle weisen, im Gegensatz zu iterativen Prozessmodellen, ein streng sequenzielles Vorgehen vor. Dabei wird die Reihenfolge der Aktivitäten durch das Prozessmodell fest vorgegeben. Die Dokumentation ist in linearen Prozessmodellen durch das Prozessmodell definiert. Das bedeutet, es wird genau vorgegeben, welche Dokumente während des Projekts entstehen. Dadurch ist die Anpassung des Prozessmodells and das Projekt (Tayloring) nur im geringen Maße möglich. Sollte ein Prozessmodell für einen bestimmten Projekttyp ungeeignet sein, bleibt nur die Möglichkeit ein anderes, passenderes Prozessmodell zu wählen. Man spricht bei linaren Prozessmodellen auch von aktivitäten-orientierten Prozessmodellen, da die genaue Durchführung der durch das Prozessmodell vorgegebenen Aktivitäten im Mittelpunkt steht. A. Das Phasenmodell Abb.: Phasenmodell 2 freigegeben. Anschließend wird das geänderte Dokument erneut nach den Kriterien geprüft, welche für das Dokument festgelegt wurden. Da eine solche Fehlerkorrektur einen großen Mehraufwand darstellt, ist es in einigen Fällen ratsam, den Fehler hinzunehmen und zu versuchen, dessen Auswirkungen zu minimieren. Durch die Einteilung des Projekts in Phasen und Meilensteine, kann das Projekt zu Beginn relativ präzise geplant und organisiert werden. Budget und Personalbedarf stehen dann schon nach der Planungsphase fest. Allerdings sind die Anforderungen selten schon zu Beginn des Projekts vollständig bekannt. Während der Entwicklung ändert der Kunde oft seine Anforderungen, es kommen neue hinzu, oder bereits erhobene Anforderungen fallen wieder weg. In linearen Prozessmodellen, und speziell im Phasenmodell, ist es nur mit erheblichem Aufwand möglich, während der Entwicklung grundlegende Änderungen der Anforderungen zu realisieren. Ein weiterer Nachteil linearer Prozessmodelle ist die Tatsache, dass sich Fehler häufig erst in späteren Phasen des Projekts bemerkbar machen, häufig mit großen Auswirkungen auf bereits entstandene Dokumente. Korrekturen erforden dadurch einen deutlichen Mehraufwand. Dies hat zur Folge, dass Risiken vertärkt gegen Projektende auftreten ( Big Bang ). Aus diesen Gründen findet man heute in der Praxis häufig iterative Prozessmodelle vor. Ein typisches lineares Prozessmodell ist das Phasenmodell. In ihm werden die einzelnen Schritte des Software-Entwicklungsprozesses in Phasen eingeteilt. Zwei aufeinanderfolge Phasen werden dabei von Meilensteinen getrennt. Dadurch überlappen die einzelnen Phasen nicht und werden streng sequentiell abgearbeitet. Dabei ist durch den Meilenstein genau festgelegt, wann die eine Phase endet, und die nächste Phase beginnt. Es wird daher für jeden Meilenstein genau definiert III. ITERATIVE PROZESSMODELLE Bei iterativen Prozessmodellen verläuft die Entwicklung nicht in linearen, sequentiellen Phasen, sondern in mehreren geplanten Iterationsschritten. Ein Iterationsschritt durchläuft dabei die Tätigkeiten 1. Welche Ergebnise (Dokumente) vorliegen müssen 2. Wer nach welchen Kriterien welche Prüfung vornimmt 3. wer entscheidet, ob der Meilenstein erreicht ist. Erst wenn alle für den Meilenstein festgeschriebenen Dokumente vorliegen und geprüft wurden, ist ein Meilenstein erreicht. Dadurch wird sichergestellt, dass alle während des Projekts entstehenden Dokumente den Qualitätsanforderungen entsprechen. Da jedoch keine Prüfung Fehler komplett ausschließen kann, ist es unvermeidbar, bereits geprüfte und freigegebene Dokumente zu korrigieren, um den Fehler zu beseitigen. Dies geschieht allerdings unter Berücksichtigung des Budgets und der akutellen Phase. Änderungen werden zunächst untersucht und anschließend durch den Projektleiter Abb.: Iteration Jeder Iterationsschritt mündet dabei in einem Release, einem überabeiteten, verbesserten und erweiterten System, welches in seiner Funktionalität gegenüber dem vorhergehenden Release verfeinert wurde. Jedes dieser Releases ist voll funktionsfähig. Änderungen, die während der Entwicklung des Projekts aufkommen, werden im nächsten Iterationsschritt vorgenommen, womit es sehr einfach ist, auf die Änderungen zu reagieren.

3 Gleichzeitig fließen die Erfahrungswere einer Iteration in den nächsten Iterationsschritt mit ein. Es findet also eine stetige Verbesserung des Prozesses statt. 3 Die folgenden Rollen, Artefakte und Methoden von SCRUM stellen eine Implementierung dieser Grundsätze und Annahmen dar. Sie sind keinesfalls in dieser Form vorgegeben, sondern lassen sich an das Projekt anpassen. A. Rollen in SCRUM 1) Product Owner Abb.: Iterationsprozess Beispiele solcher iterativer Prozessmodelle sind das in jüngster Zeit populär gewordene extreme Programming, das teiliterative Feature-Driven-Development und das hier vorgestellte SCRUM. IV. SCRUM SCRUM (engl. für Gedränge) ist ein Prozessmodell, welches von Ken Schwaber, Jeff Sutherland und Mike Beedle entwickelt wurde, und erstmals in dem Buch Wicked Problems, Righteous Solutions (1991) Erwähnung fand. Bevor sich SCRUM in Softwareentwicklungsprojekten etabliert hat, wurde das Prozessmodell zunächst von den beiden Professoren Hirotaka Takeuchi und Ikujirō Nonaka; beides bedeutende Vertreter des Wissensmanagements; in ihrem Werk The New Product Development Game als Produktentwicklungsmethode eingeführt. Im Mittelpunkt von SCRUM steht die Philosophie der ständigen Weiterentwicklung und Verbesserung von Prozessen, Methoden und Mitarbeitern, um stets höchste Qualität bei niedrigsten Kosten zu erreichen. SCRUM ist ein Prozessmodell, welches durch seine Methoden diese Weiterentwicklung aller Entwicklungsbereiche fördert und fordert. Dabei erfüllt SCRUM stehts das von Ken Schwaber und Jeff Sutherland formulierte Agile Manifest: 1. Individuen und Interaktionen sind wichtiger als Prozesse und Wekzeuge 2. Funktionierende Programme sind wichtiger als ausführliche Dokumentation 3. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen 4. Der Mut und die Offenheit stehen über dem Befolgen eines festgelegten Plans Eine der im Agilen Manifest festgelegten Richtlinien besagt, dass die ständige Einbeziehung des Kunden in die Entwicklung des Projekts ausschlaggebend für dessen Erfolg ist. Diese Einbeziehung des Kunden wird in SCRUM durch die Rolle des Product Owner realisiert. Der Product Owner vertritt während der gesamten Projektdauer den Kunden, und hält ihn stets auf dem Laufenden. Der Product Owner stellt also eine Art Schnittstelle zwischen dem Entwicklungsteam und dem Kunden dar. Dabei legt der Product Owner die gemeinsamen Ziele fest, die das Team mit ihm erreichen muss. Er priorisiert die Elemente des Product Backlogs anhand der Prioritäten des Kunden. Dabei ist der Product Owner NICHT der Vorgesetzte des Teams. Er besitzt keine Managementrechte und greift nicht in die Teamorganisation ein. 2) SCRUM-Master Der SCRUM-Master hat die Aufgabe, den SCRUM Prozess zu überwachen, zu unterstützen und dessen Produktivität zu gewährleisten. Er sorgt dafür, dass keine störenden Einflüsse von aussen (z.b. Abwerbung der Mitarbeiter durch andere Projektteams; Bürokratische Hürden des Managements) auf die Entwicklung einwirken und diese negativ beeinflussen. Er hält den Entwicklern in dieser Hinsicht den Rücken frei und sorgt dafür, dass sich diese möglichst ungestört dem Projekt widmen können. Gleichzeitig macht der SCRUM-Master Vorschläge zur Verbesserung des SCRUM-Prozesses und versucht diese gemeinsam mit dem Product Owner und dem Entwicklungsteam umzusetzen. Er nimmt dabei keinen Einfluss auf die eigentliche Softwareentwicklung, unterstützt das Entwicklungsteam aber bei der ordnungsgemäßen Durchführung der Entwicklung. 3) Team Das eigentliche Entwicklungsteam, welches die im Sprint- Backlog definierten Aufgaben im nächsten Sprint realisiert. Es ist in der Regel interdisziplinär (Architekten, Entwickler, Tester, etc.) zusammengesetzt und besteht idealerweise aus fünf bis neun Personen, um eine effiziente Kommunikation innerhalb des Teams aufrecht zu erhalten. Größere Teams sollten daher in mehrere kleinere Teams aufgeteilt werden. Das Team organisiert sich selbst und verteilt die Aufgaben des Sprint-Backlogs autonom an die einzelnen Teammitglieder. Daher wird vom Team erwartet, intuitiv für jede Aufgabe eine optimale innere Organisationsstruktur zu bilden. Der SCRUM-Master achtet dabei darauf, dass der

4 Product-Owner nicht in diesen Selbstorganisationsprozess eingreift. B. Artefakte in SCRUM 1) Product-Backlog Der Product-Backlog enthält alle funktionalen Anforderungen des Kunden in Form von Features. Der Kunde ist stets über den Inhalt informiert und hat idealerweise lesenden Zugriff auf das Dokument. Dadurch werden Konflike zwischen den Anforderungen des Kunden und dem fertigen Produkt vermieden. Um noch besser auf die Wünsche des Kunden einzugehen, werden die Elemente des Product-Backlogs vom Product-Owner priorisiert. Auf Elemente mit hoher Priorität wird während der Entwicklung ein besonders großes Augenmerk gelegt. Da während der Entwicklung häufig Änderungen bezüglich der Funktionalität des Projekts auftreten, können Elemente zwischen den Sprints neu priorisiert, hinzugefügt und entfernt werden. Es ist somit gewährleistet, dass geänderte Anforderungen des Kunden ohne große Hürden realisiert werden können. 2) Selected-Backlog Der Selected-Backlog wird vor jedem Sprint vom Product- Owner zusammen mit dem Team gepflegt. Er enthält jene Einträge des Product-Backlogs, welche im nächsten Sprint realisiert werden sollen. Der Umfang des Selected-Backlogs richtet sich dabei nach der Sprintlänge und der Kapazität des Teams. Der Selected-Backlog dient als Grundlage für die Abnahme der im nächsten Sprint inkrementell verbesserten Software. 3) Sprint-Backlog Um die Einträge des Selected-Backlogs realisieren zu können, werden diese in Aufgaben zerlegt und im Sprint- Backlog erfasst. Dabei sollte das Erledigen einer Aufgabe nicht länger als einen Tag benötigen. Komplexere Aufgaben werden daher in mehrere kleinere Aufgaben zerlegt. Neben den Aufgaben, die vom Team im nächsten Sprint realisiert werden sollen, enthält der Sprint-Backlog die Aufgabenverteilung und die Verantworlichkeiten für die einzelnen Aufgaben. So ist stets nachvollziehbar, welches Teammitglied welche Aufgabe zu erledigen hat. 4) Burndown Chart Das Burndown-Chart ist eine grafische Repräsentation des noch zu erbringenden Aufwands innerhalb des Sprints. Es wird täglich aktualisiert. Dabei wird der Restaufwand in einer t-a-achse aufgetragen. Anhand dieser entstehenden Kurve kann durch die negative Steigung schon früh beurteilt werden, ob der Aufwand innerhalb des Sprints zu bewältigen ist. Das Burndown-Chart wird dokumentiert und in der Retroperspektive analysiert. 5) Impediment-Backlog Im Impediment-Backlog werden alle Hindernisse und Probleme aufgerlistet, welche die Arbeit an dem Projekt behindern. Diese Probleme, seien sie organisatorischer, technischer oder personeller Natur, sind meist vielfältig. Es ist die Aufgabe des SCRUM-Masters diese Probleme zu erkennen und gemeinsam mit dem Team auszuräumen. C. SCRUM-Zyklus 1) Sprint-Planugsmeetings Die Sprint-Planungsmeetings sind zwei Meetings, welche vor jedem Sprint abgehalten werden. Im ersten Meeting präsentiert der Product-Owner dem Team die höchstpriorisierten Einträge des Product-Backlogs. Anschließend übernimmt der Product-Owner in Absprache mit dem Team die Elemente in den Selected-Backlog, welche im nächsten Sprint realisiert werden sollen. Im zweiten Meeting werden diese Elemente in Aufgaben zerlegt und an die Teammitglieder verteilt. Das Ergebnis des zweiten Planungsmeetings ist der Sprint-Backlog. 2) Sprint Der Sprint ist das zentrale Element des Scrum-Zyklus. Er dauert meist zwischen einer und vier Wochen. Während des Sprints werden die Elemente des Sprint-Backlogs von den einzelnen Teammitglieder abgearbeitet. Dabei organisiert sich das Team selbst, ohne Einflüsse durch den SCRUM- Master oder den Product-Owner. Das Ziel des Sprints ist eine inkrementell verbesserte, lauffähige und getestete Software. Das bedeutet, dass innerhalb des Sprints für jedes Element des Selected-Backlogs der Software- Entwicklungsprozess, von der Analyse, bis zum Test, durchlaufen wird. 3) Daily SCRUM Der Daily-SCRUM ist ein kurzes, 15 minütiges Meeting, welches täglich vor Arbeitsbeginn stattfindet. In ihm berichten Teammitglieder, was sie seit dem letzten Daily- SCRUM geleistet haben und was sie bis zum nächsten Daily- SCRUM erreichen wollen. Dabei berichten sie auch von eventuell aufgetretenen Problemen, welche in den Impediment-Backlog aufgenommen werden. Auch wenn der Daily-SCRUM grundsätzlich ein offenes Meeting ist, haben lediglich der SCRUM-Master und das Team eigenständiges Rederecht. 4

5 4) Review D. Zusammenfassung 5 Um eine möglichst hohe Qualität der während des Sprints enstehenden Dokumente zu erreichen, werden diese; wie in vielen anderen Prozessmodellen ebenfalls; einem Review unterzogen. Das Review wird vom Team zusammen mit dem Product-Owner abgehalten. Dabei prüft der Product-Owner, ob das Ergebnis des Sprints den Vorgaben des Selected- Backlogs entspricht. Sollte dies nicht der Fall sein, so werden Änderungen in den Product-Backlog aufgenommen, wo sie neu priorisiert werden. 5) Retroperspective SCRUM basiert auf einer Philosophie der ständigen Weiterentwicklung, nicht nur der Mitarbeiter und des Arbeitsprozesses, sondern auch des SCRUM-Prozesses an sich. Um dem gerecht zu werden, gibt es nach jedem Sprint eine Retroperspective, in der die vergangene Sprint Phase von allen in SCRUM beteiligten Personen betrachtet wird. Dabei werden wichtige Ereignisse notiert. Dadurch wird versucht, Verbesserungspotentiale für den SCRUM-Prozess zu finden und Misstände jeglicher Art aufzudecken. Verbesserungspotential, welches die Teamorganisation betrifft wird im Impediment-Backlog festgehalen, projektbezogenes Verbesserungspotential im Product- Backlog. SCRUM ist, wenn es richtig eingesetzt wird, ein mächtiges Prozessmodell, dass allen am Projekt beteiligten Personen hilft, sich stets weiterzuentwickeln um somit das bestmögliche Ergebnis zu erzielen. SCRUM hat in den letzten Jahren stark an Bedeutung gewonnen, was nicht zuletzt dem Umstand der besseren Kundennähe im Gegensatz zu anderen Prozessmodellen geschuldet ist. Allerdings ist SCRUM sowohl für unerfahrene, als auch für fest eingespielte Teams nicht leicht zu realisieren, da sich viele Methoden von SCRUM von anderen Prozessmodellen unterscheiden. Es benötigt daher etwas Zeit, um die Vorteile von SCRUM ausschöpfen zu können. Abb.: SCRUM-Zyklus

6 V. RISIKOMANAGEMENT B. Analyse 6 Die Wahl eines geeigneten Prozessmodells für die Projektdurchführung... Um diesen Risiken und deren Auswirkungen auf das Projekt möglichst zu minimieren, oder bestenfalls komplett auszuräumen betreibt man Risikomanagement. Dabei versteht man unter einem Risiko: In der Analysephase werden die zuvor identifizierten Risiken auf ihre Eintrittswahrscheinlichkeit und den Schaden, den sie bei Eintreten verursachen, bewertet. Dies erfolgt anhand einer dreiwertigen Skala. Ein Problem, das noch nicht eingetreten ist, aber wichtige Projektziele oder Projektergebnisse gefärdet, falls es eintritt. Ob es eintreten wird, kann nicht sicher vorraus gesagt werden. (Hindel et. al.) Die Ziele eines effektiven Risikomanagements bestehen zunächst in der Identifikation von Risiken. Ein Risiko, welches nicht bekannt ist, kann auch nicht gemanaged werden. Die identifizierten Risiken werden anschließend analysiert und quantifiziert, um daraus geeignete Gegenmaßnahmen zu entwerfen. Dieser Prozess des Risikomanagements wird durch das von Marvin J. Carr entworfene Risikomanagement-Modell beschrieben: Abb.: Risikobewertung Zunächst untersucht man die Eintrittswahrscheinlichkeit des Risikos und weist ihm einen Wert gemäß obiger Sakal zu. Hat beispielsweise die Untersuchung des Risikos r ergeben, dass es nicht überraschend wäre, dass das Risiko eintritt, so wird dem Risiko r der Wert 2 zugewiesen. Genauso verfährt man mit dem Schadenausmaß, wodurch das Risiko nun zwei Werte erhält. Diese Werte werden miteinander Multipliziert und in folgende Skala eingetragen: Abb.: Risikomanagement-Modell A. Identify In dieser Phase werden die Risiken, welche das Projekt behindern, oder gefärden, identifiziert, bevor diese eintreten. Um eine möglichst umfassende Liste von Risiken zu erhalten, müssen alle am Projekt beteiligten Experten zugezogen werden. Die Identifikation der Risiken findet meist in moderierten Workshops statt. Diese Identifikationsphase findet dabei nicht nur zu Beginn des Projekts statt, sondern ist ein fortlaufender Prozess, da Risiken oftmals erst während der Projektdurchführung auftreten (z.b. durch personelle Veränderungen). Abb.: Risikoskala Dadurch lassen sich Risiken nach ihrer Eintrittswahrscheinlichkeit und dem verursachten Schadenausmaß quantifizieren. Risiken mit großen Werten müssen folglich stärker betrachtet werden als Risiken mit kleinen Werten.

7 C. Plan In dieser Phase des Risikomanagments werden für die zuvor identifizierten und quantifizierten Risiken Gegenmaßnahmen entwickelt. Dabei unterscheidet man 3 Arten von Maßnahmen. 1) Notfallmaßnahme Eine Notfallmaßnahme ist eine Gegenmaßnahme, sollte das Problem bereits eingetreten sein. 2) Präventivmaßnahme Die Präventivmaßnahme zield darauf, ein gewisses Risiko von vornherein zu vermeiden. Besteht beispielsweise das Risiko, dass ein fähiger Mitarbeiter während des Projekts abgeworben werden könnte, so bestünde eine Präventivmaßnahme darin, ein großzügiges Honorar für den Projektabschluss zu garantieren. 3) Risiko in Kauf nehmen und nichts unternehmen Hat ein Risiko während der Analyse einen sehr kleinen Risikowert erhalten, ist der Aufwand entsprechende Gegenmaßnahmen zu entwickeln unter Umständen größer, als der Nutzen, den man durch die Vermeidung des Risikos zieht. In diesem Fall nimmt man das Risiko in kauf, ohne Gegenmaßnahmen zu entwickeln. Wichtig bei der Entwicklung von Gegenmaßnahmen ist, dessen Konsequenzen zu betrachten. Oftmals bergen Maßnahmen, die gegen ein bestimmtes Risiko gerichtet sind, neue Risiken. Hier gilt abzuwägen, ob die Maßnahme dem Risikomanagement wirklich nützt, oder ob sie durch neue Risiken im Endeffekt eher schadet. Alle so entwickelten Gegegmaßnahmen werden im Projektplan festgehalten. D. Track In den seltensten Fällen bleiben Risiken und die zugehörigen Risikowerte während der gesamten Projektphase konstant. Daher ist eine stetige und fortlaufende überwachung der Risiken und deren Werte vonnäten. Diese Überwachung ist dabei Aufgabe des Projektmanagements. E. Control Nicht nur Risiken müssen fortlaufend überwacht werden, auch die entsprechenden Gegenmaßnahmen müssen kontrolliert werden, da sich Maßnahmen und dessen Auswirkungen ändern können. Hat beispielsweise eine Maßnahme zu Beginn des Projekts einen hohen Nutzen, kann dies sich im Verlauf des Projekts ins Gegenteil umkehren und eine Maßnahme würde dem Projekt eher Schaden. Es ist daher nötig, die Maßnahmen in regelmäßigen Abständen zu kontrollieren und bewerten und gegebenenfalls zu ändern. 7 Im Zentrum des Risikomanagement-Modells liegt der Communicate Begriff. Dies soll die Durchziehung durch alle Phasen des Risikomanagements verdeutlichen. Ohne funktionierende Kommunikation ist ein effektives Risikomanagement nicht möglich. Es muss möglich sein, zwischen den einzelnen Phasen des Risikomanagements Risiken austauschen zu können, um den Zusammenhalt des Modells zu gewährleisten. Gleichzeitig muss zwischen jeder Ebene des Projekts, vom Management bis zu den Entwicklern eine Kommunikation stattfinden, ohne die das Risikomanagement-Modell seinen Nutzen einbüßen würde. VI. BEZUG ZU LAVIDA Um zu entscheiden, welche Art von Prozessmodell für das Studienprojekt LaVida geeignet ist, müssen zunächst die Ausgangsbedingungen des Projekts betrachtet werden. Das Team besteht aus zwölf Studenten mit insgesamt geringer Berufserfahrung, woraus folgt, dass die Entwicklung anhand eines iterativen Prozessmodells für die meisten Teammitglieder neu ist. Daher würde es ein Risiko darstellen ein rein iteratives Prozessmodell für die Projektentwicklung zu wählen. Das Team wurde nur für dieses Studienprojekt zusammengestellt, was bedeutet, dass es sich hierbei um kein eingespieltes Team, welches bereits an mehreren Projekten gemeinsam gearbeitet hat, handelt. Die Teamgröße wird sich während des Projekts sehr wahrscheinlich nicht ändern, es werden also weder Teammitglieder durch andere Projektgruppen abgeworben, noch werden andere Entwickler hinzugezogen. Es existieren also insgesamt wenig personelle Risiken, was es einfacher macht, den einzelnen Teammitgleidern feste Rollen zuzuweisen. Die Teamstruktur ist zunächst nicht vorgegeben, wird aber vor Projektbeginn vereinbart. Durch die freie Wahl der Teamstruktur, werden der Wahl eines Prozessmodells diesbezüglich alle Freiheiten eingeräumt. Für das Projekt gilt, dass dessen Auslieferungsdatum bereits fest steht, der Zeitrahmen also sehr starr ist, was das Projekt gut planbar macht. Die Anforderungen stehen bereits vor Projektbeginn fest. Es wird diesbezürlich während des Projekts wenig Änderungen geben. Somit spielt die Notwendigkeit, optimal auf geänderte Anforderungen des Kunden reagieren zu müssen, eine eher geringe Rolle. Für die Realisierung der Anforderungen gibt es wenig Bestimmungen und große Freiräume. So werden weder die Architektur, noch die Entwicklungsumgebung und deren Programmiersprache vorgegeben. Weiterhin ist das Projekt an keinerlei Budgetbeschränkungen gebunden, wodurch das Team alle ihm zur Verfügung stehenden Arbeitsmittel optimal ausschöpfen kann. Ausgehend von diesen Grundannahmen wird hier für das Studienprojekt LaVida ein teiliteratives Prozessmodell vorgeschlagen.

8 8 Das Projekt wird dabei in zwei Phasen eingeteilt, der sequentiellen Phase und der teiliterativen Phase. In der sequentiellen Phase werden die wichtigsten Dokumente (Analyse, Spezifikation, Grobentwurf) in einer linearen Vorgehensweise entwickelt. Dabei wird jedes entstehende Dokument nach anerkannten Richtlinien geprüft und abgenommen. Anschließend kommt das Projekt in die iterative Phase, in der die Aktivitäten Feinentwurf, Codierung und Test iterativ durchgeführt werden. Es ist dabei stets möglich, von der iterativen Phase in die sequentielle Phase zurückzukehren. Dadurch wird gewährleistet, dass Fehler ohe großen Aufwand korrigiert werden können. Alle Änderungen, die dadurch an den in der iterativen Phase entstehenden Dokumente gemacht werden müssen, werden dann im nächsten Iterationsschritt durchgeführt. Dieses teiliterative Prozessmodell kombiniert die Vorteile beider Prozessmodellarten. Durch die Einteilung in Phasen kann das Projekt zu Beginn relativ präzise geplant werden. Der Aufwand, welcher bei linearen Prozessmodellen für die Fehlerkorrektur erbracht werden muss, fällt hier größtenteils weg. Gleichzeitig machen sich Risiken gleichmäßig während der gesamten Entwicklung bemerkbar, nicht erst gegen Ende des Projekts ( Big Bang ). Für das Team ist das teiliterative Modell einfacher zu realisieren, als ein rein iteratives Prozessmodell, da der große Organisatorische Aufwand, der ein iteratives Vorgehen nach sich zieht, auf die iterative Phase beschränkt wird. Dadurch sind die einzelnen Iterationen weniger komplex und können gut bewältigt werden. Desweiteren kann sich das Team in der sequentiellen Phase dank des gewohnten linearen Vorgehens auf die Qualität der kritischsten Dokumente konzentrieren. LITERATUR [1] Carr et al., Taxonimy-Based Risk Identification, Carnegie Mellon University, 1993, Juni, S. 3-5 [2] Lichter, Horst/Ludewig, Jochen, Software-Engineering Grundlagen, Menschen, Prozesse, Techniken., 1. Aufl, Heidelberg, dpunkt.verlag GmbH, 2007 [3] Szabo, Lazlo l., Iterative Softwareentwicklung in der mobilden Welt: Alternativen zu traditionellen Prozessmodellen, 2008, S. 1-3 [4] Wikipedia, Scrum, [5] Wirsing,Martin, Vorlesung Projektmanagement: Prozessmodelle, LMU München, Prozess.pdf