Lade Inhalt...

Auswahl und Einführung eines Vorgehensmodells für die Softwareentwicklung

©2007 Magisterarbeit 126 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
Vorgehensmodelle zur Softwareentwicklung zielen darauf ab, dass mit ihrer Hilfe Softwareprodukte mit den gewünschten Funktionalitäten zu den geplanten Kosten und innerhalb der erwarteten Zeit erstellt werden. Projekte scheitern insbesondere wegen unklarer Projektziele und unklarer Formulierung der Anforderungen sowie unmethodischem Vorgehen. Die Risiken eines Projektscheiterns werden durch den Einsatz eines Vorgehensmodells reduziert.
Im Laufe der Zeit haben sich verschiedene Modelle etabliert, wobei seit 2000 vermehrt so genannte agile Modelle angewendet werden. Frühere Modelle basieren auf einem Vorgehen, bei welchem das Hauptaugenmerk auf umfassender Planung liegt und die Softwareentwicklung als ein an die Produktion angelehnter Fertigungsprozess betrachtet wird. Agile Modelle vertreten die Auffassung, dass ein adaptives Vorgehen zielführender ist. In agilen Modellen wird dementsprechend eine schrittweise Umsetzung in kurzen Zyklen bevorzugt, wodurch ein schnelles Reagieren auf sich ändernde Anforderungen möglich wird. Das Ergebnis im Sinne von lauffähiger Software wird als oberstes Ziel definiert. Die Planungsphase wird als weniger wichtig angesehen und es erfolgt hingegen eine besondere Berücksichtigung der menschlichen Komponente. Softwareentwicklung wird in Anlehnung an die Produktentwicklung als innovativer und kreativer Prozess gesehen, was sich auch auf den Aufbau der Modelle und der verwendeten Steuerungsmechanismen auswirkt.
Diese Arbeit beschreibt die relevanten Vorgehensmodelle, welche im Anschluss verglichen werden, um die Unterschiede zwischen den Modellen festzustellen. […]

Leseprobe

Inhaltsverzeichnis


Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1. Problemstellung
1.2. Zielsetzung
1.3. Aufbau der Arbeit/Vorgehensweise

2. Kontext und Definitionen
2.1. Informationsmanagement
2.2. Software
2.3. Individual- und Standardsoftware
2.4. Service Orientierte Architektur (SOA)
2.5. Eigenschaften von Software
2.6. Qualität von Software
2.7. Softwareentwicklung
2.8. Softwareentwicklungsprozess

3. Vorgehensmodelle im Überblick
3.1. Build-and-Fix-Cycle
3.2. Wasserfallmodell
3.3. V-Modell
3.4. Prototypen Modell
3.5. Spiral-Modell
3.6. Unified Process (Rational Unified Process – RUP)
3.7. Microsoft Solutions Framework
3.8. Agile Vorgehensmodelle
3.8.1. Adaptive Software Development (ASD)
3.8.2. Crystal Methodenfamilie
3.8.3. Dynamic Systems Development Model (DSDM)
3.8.4. eXtreme Programming (XP)
3.8.5. Feature Driven Development (FDD)
3.8.6. Lean Software Development (LSD)
3.8.7. Scrum

4. Gegenüberstellung der Modelle
4.1. Vergleich nach Kriterien
4.1.1. Allgemeine Kriterien
4.1.2. Spezifische Kriterien
4.2. Basis-Stil der Modelle bezogen auf Kernelemente
4.3. Vergleich nach der Ausrichtung an Agilität
4.4. Vergleich nach Verwendung und Reife

5. Auswahl eines Vorgehensmodells
5.1. Empirische Sozialforschung
5.1.1. Grundlagen der empirischen Sozialforschung
5.1.2. Qualitative und Quantitative Methoden der empirischen Sozialforschung
5.1.3. Empirische Datenerhebung
5.1.4. Empirische Datenauswertung
5.1.5. Vorgehen im gegenständlichen Fall
5.2. Forschungsdesign
5.2.1. Aufbau und Struktur des Forschungsprojektes
5.2.2. Design der Datenerhebung
5.2.3. Durchführung der Befragungen
5.2.4. Auswertung

6. Einführung des Vorgehensmodells
6.1. Präzisierung des Modells Scrum
6.1.1. Scrum Basis
6.1.2. Scrum Rollen
6.1.3. Scrum Flow
6.1.4. Scrum Arbeitsergebnisse
6.1.5. Vorgaben, Standards und Konventionen
6.1.6. Hintergrundinformationen zu Scrum
6.2. Ausgangssituation
6.2.1. Unternehmensbeschreibung
6.2.2. Rahmenbedingungen
6.3. Beschreibungen einer Modell-Einführung
6.3.1. Prinzipien für agiles Methodendesign
6.3.2. Vorgehensbeschreibungen für die Einführung
6.4. Leitfaden zur Einführung
6.4.1. Vorgehen bei der Leitfaden-Erstellung
6.4.2. Vorbereiten der Einführung
6.4.3. Anwendung des Modells Scrum
6.4.4. Nachbetreuung der Einführung
6.4.5. Daueraufgaben zur Pflege des Vorgehensmodells
6.4.6. Zeitplan für die Scrum-Einführung
6.4.7. Vorteile für die Organisation

7. Schlussbemerkung und Ausblick

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abbildung 1: Zusammenhang Unternehmensstrategie und Informationsmanagement

Abbildung 2: Wasserfallmodell mit Rücksprüngen und Ergebnissen

Abbildung 3: V-Modell mit Sichtendarstellung

Abbildung 4: Spiralmodell nach Boehm

Abbildung 5: Phasen, Schritte und Prozesse des Unified Process

Abbildung 6: Matrix der Crystal Methoden

Abbildung 7: Ablauf eines Zyklus lt. Scrum

Abbildung 8: Gegenüberstellung der Modelle nach spezifischen Kriterien

Abbildung 9: Ausmaß der Ausrichtung der Modelle an Agilität

Abbildung 10: Modell-Vergleich nach Status im Lebenszyklus

Abbildung 11: Ausmaß der Übereinstimmung der Modelle mit den erhobenen Anforderungen an ein Vorgehensmodell

Abbildung 12: Scrum-Flow — Überblick über das Scrum-Prozessmodell

Abbildung 13: Schema für die WM-Implementierung nach CEN

Abbildung 14: Vorgehen für die Einführung von Scrum

Abbildung 15: Zeitplan für Scrum-Einführung

Tabellenverzeichnis

Tabelle 1: Qualitätsmerkmale für Software nach DIN ISO 9126

Tabelle 2: Fachliteratur für die Auswahl der dargestellten Vorgehensmodelle

Tabelle 3: Nennungen der Vorgehensmodelle in der Fachliteratur

Tabelle 4: MSF Schlüssel-Ziele und Rollen

Tabelle 5: Phasen des MSF Prozessmodells

Tabelle 6: 12 Prinzipien agiler Softwareentwicklung

Tabelle 7: 9 Prinzipien von DSDM

Tabelle 8: Praktiken von XP

Tabelle 9: Gegenüberstellung der Modelle nach allgemeinen Kriterien

Tabelle 10: Basis-Stil für agile and plangetriebene Methoden

Tabelle 11: Phasen für den Modell-Vergleich nach Status im Lebenszyklus

Tabelle 12: Phasen eines Forschungsprozesses

Tabelle 13: Gütekriterien der Sozialforschung

Tabelle 14: Gütekriterien der qualitativen Sozialforschung

Tabelle 15: Kombinationsmodelle für qualitative und quantitative Methoden

Tabelle 16: Gemeinsame Forschungslogik für qualitative und quantitative Methoden

Tabelle 17: Grundformen qualitativer Inhaltsanalyse

Tabelle 18: Ansprüche an ein Kategoriesystem

Tabelle 19: Dimensionen und Indikatoren zur Erstellung des Leitfadens zur Ermittlung der Anforderungen an ein Vorgehensmodell

Tabelle 20: Vorgehen bei der strukturierenden Inhaltsanalyse

Tabelle 21: Ergebnis der Auswertung der Interviews

Tabelle 22: Prüfung des Forschungsprozesses nach Gütekriterien

Tabelle 23: Anforderungen an das Vorgehensmodell

Tabelle 24: Erfolgskriterien der Produktentwicklung

Tabelle 25: Leitfaden für das Interview zur Erhebung der Anforderungen an ein Vorgehensmodell (Pretest)

Tabelle 26: Leitfaden für das Interview zur Erhebung der Anforderungen an ein Vorgehensmodell

Tabelle 27: Ergebnis der qualitativen Inhaltsanalyse (strukturierende Inhaltsanalyse)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1. Problemstellung

Diese Arbeit beschäftigt sich mit dem Thema „Vorgehensmodelle in der Softwareentwicklung“. Ausgangspunkt ist die Problemstellung, dass Software-Entwicklungsprojekte häufig scheitern. Unklare Ziele, widersprüchliche Anforderungen, Fehler in der Kommunikation und Koordination zwischen den Beteiligten[1] und fehlendes Verständnis für die Anwendungsdomäne vonseiten des Projektteams[2] tragen zum Misserfolg eines Projektes bei.

Der Chaos Report der Standish Group — eine Erhebung aus dem Jahr 1995, aktualisiert 2004, in welcher Softwareprojekte untersucht und Erfolgsquoten ermittelt wurden — zeigt folgendes Ergebnis (Werte von 1995 in Klammer):[3]

- 29 % (16 %) erfolgreich, d. h. das Projekt wurde zeit- und kostengerecht im geplanten Ausmaß abgeschlossen
- 53 % (53 %) teilweise erfolgreich, d. h. das Projekt wurde abgeschlossen, es konnten jedoch Kosten, Zeit oder Funktionsumfang nicht eingehalten werden
- 18 % (31 %) erfolglos, d. h. das Projekt wurde während der Umsetzung abgebrochen
Eine detaillierte Betrachtung der abgeschlossenen Projekte zeigt, dass 2/3 dieser Projekte signifikant die angesetzten Kosten überschreiten, über 60 % der in der Software eingebauten Funktionen selten oder gar nicht genutzt werden und die durchschnittliche Entwicklungsdauer das Doppelte vom ursprünglich veranschlagten Zeitraum beträgt.[4]

Als häufigste Gründe für das Scheitern von Projekten werden genannt:[5]

- unklare Projektziele und unklare Formulierung der Anforderungen
- schlechte Beteiligung der späteren Anwender
- mangelnde Management-Unterstützung
- mangelnde Erfahrung der Projektmanager
- zu hoher Funktionsumfang und unrealistische Erwartungen
- zu große Umsetzungspakete (Meilensteine)
- zu wenig qualifizierte und zu wenig fokussierte Mitarbeiter
- unmethodisches Vorgehen

In einer Veröffentlichung von Gartner werden als Gründe für das Scheitern genannt:[6]

- das System erweist sich als ungeeignet
- das Projekt bringt keinen Business-Vorteil
- die Anwender lehnen das System ab
- das System wird zu spät ausgeliefert
- die Technik funktioniert nicht

Mithilfe eines geeigneten Vorgehensmodells sollen die Risiken eines Projektscheiterns reduziert werden. Ein Vorgehensmodell soll dazu beitragen, dass Softwareprojekte erfolgreich abgeschlossen werden und dass das Softwareprodukt mit den gewünschten Funktionalitäten zu den geplanten Kosten und innerhalb der erwarteten Zeit erstellt wird.

1.2. Zielsetzung

In dieser Arbeit werden relevante Vorgehensmodelle für die Softwareentwicklung dargestellt. Aufbauend auf diese Übersicht werden die Modelle verglichen und Kriterien ermittelt, welche in weiterer Folge für die Auswahl eines bestimmten Modells für ein Entwicklungsvorhaben herangezogen werden können. Anhand dieser Kriterien wird am Beispiel der Softwareentwicklung der Hypo Tirol Bank unter Rücksichtnahme auf die dort vorhandene Ausgangssituation und die dortigen Rahmenbedingungen ein Modell ausgewählt. Schließlich wird für das gewählte Modell ein Leitfaden zur Umsetzung ausgearbeitet.

In dieser Arbeit werden folgende Leitfragen beantwortet:

- Wie sind die relevanten Vorgehensmodelle aufgebaut?
- Welche Unterschiede zwischen den Modellen lassen sich feststellen?
- Wie wählt man ein geeignetes Modell aus?
- Wie geht man die Einführung des gewählten Modells an?

1.3. Aufbau der Arbeit/Vorgehensweise

Es werden zuerst die in diesem Zusammenhang wichtigen Begriffe wie Software, Softwareentwicklung bzw. Entwicklungsprozess näher betrachtet. Daraufhin erfolgt eine Darstellung der in der Fachliteratur[7] am häufigsten erwähnten Vorgehensmodelle. Anschließend werden diese Modelle verglichen. Diese Gegenüberstellung bildet die Basis für den Auswahlprozess. Mithilfe des Auswahlprozesses erfolgt die Ermittlung des geeigneten Modells im gegenständlichen Beispielfall. Nach der Auswahl eines Modells wird dieses näher präzisiert und ein Leitfaden für die Einführung ausgearbeitet.

2. Kontext und Definitionen

2.1. Informationsmanagement

Informationsmanagement beschäftigt sich mit der ganzheitlichen und umfassenden Informationsversorgung eines Unternehmens. Das bedingt den direkten Zusammenhang zwischen Unternehmensstrategie und Informationsmanagement:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Zusammenhang Unternehmensstrategie und Informationsmanagement[8]

Im Rahmen der strategischen Planung wird aus der Unternehmensstrategie die Geschäftsplanung abgeleitet. Die Geschäftsplanung initiiert eine Anpassung der Informations­systemarchitektur an die Geschäftsziele, um diese bestmöglich IT-seitig zu unterstützen. Der Einfluss neuer IT-Möglichkeiten kann andererseits wiederum künftige strategische Planungen beeinflussen, wenn es darum geht, aufgrund technischer Möglichkeiten neue Geschäftspotenziale zu nutzen. Die Systemarchitektur kann jedoch auch die IT-technologischen Möglichkeiten begrenzen. Es ist daher sinnvoll, die Systemarchitektur in direkter Beziehung zur Unternehmensstrategie zu sehen und zusätzlich eine Anpassung der IT an die Unternehmensprozesse auf einer tieferen Detaillierungsebene vorzusehen.[9]

Durch die Ausrichtung der IT an die Unternehmensstrategie bekommt IT die Funktion eines „Enablers“. Das heißt, die IT liefert die Voraussetzung dafür, dass andere Organisationseinheiten Erfolgspotenziale entwickeln und nutzen. Für diese Ausrichtung kann eine so genannte Strategy Map dazu dienen, um die Beziehungen zwischen den verschiedenen strategischen Zielen und den einzelnen IT-Komponenten aufzuzeigen. Daraus kann das zu gestaltende IT-Portfolio abgeleitet und die Verwendung der IT-Investitionen gesteuert werden. Der Wert der IT wird in diesem Zusammenhang daran bestimmt, in welchem Ausmaß die IT dazu beiträgt, die strategischen Ziele zu erreichen bzw. um Wettbewerbsvorteile zu schaffen.[10]

Software stellt einen wesentlichen Teil des IT-Portfolios dar. Der zielgerichtete Einsatz der passenden Software trägt zum Erfolg des Informationsmanagements eines Unternehmens bei.

2.2. Software

Unter Software im engeren Sinn versteht man Programme für Rechensysteme. Im Allgemeinen wird zwischen systemorientierter Software (Systemsoftware) und problemorientierter Software (Anwendersoftware) unterschieden. Die Systemsoftware dient zum Betrieb oder der Unterstützung des Systems. Zu ihr gehören Betriebssystem, Programmentwicklungssysteme (Integrierte Entwicklungsumgebungen), Dienst­pro­gram­me und systemnahe Software, wie z.B. Netzsoftware. Die Anwendungssoftware wird zur Unterstützung oder Durchführung betriebswirtschaftlicher, technischer oder wissenschaftlicher Aufgaben eingesetzt und wird weiters in Individual- und Standardsoftware unterteilt.[11]

Im weiteren Sinn zählen alle mit Software verbundenen Produkte wie Dokumentationen, Handbücher und Arbeitsanleitungen zu Software.[12]

2.3. Individual- und Standardsoftware

Individualsoftware wird für eine bestimmte Problemstellung bzw. für einen bestimmten Anwender erstellt. Standardsoftware wird für den Gebrauch bei mehreren Anwendern entwickelt. Als Branchensoftware bezeichnet man eine Standardsoftware, die für den Einsatz in einem bestimmten Bereich, z.B. im Finanzsektor, entwickelt wird.[13]

Anwendungssoftware wird bezogen auf den Standardisierungsgrad in kundenindividuelle Neuentwicklung (= Individualsoftware), kundenindividuelle Anpassungsentwicklung (= Anpassung einer Standardsoftware) sowie konfigurierbare und nicht konfigurierbare Standardprodukte (= Standardsoftware) unterteilt.[14]

Die in einem Unternehmen zum Einsatz gelangenden Anwendungsprogramme dienen der Lösung eines bestimmten Problems oder der Unterstützung verschiedener Unternehmensprozesse. Bei der Umsetzung einer Idee für ein Anwendungsprogramm steht am Anfang die Make-or-Buy-Entscheidung. Eine Software-Eigenentwicklung wird dann eingesetzt, wenn keine adäquate Lösung auf dem Markt erhältlich ist. Vom Einsatz der Standardsoftware erwartet man sich niedrigere Kosten, Gewährleistung von Programmwartung und –weiterentwicklung und schnellere Einsatzfähigkeit. Andererseits muss berücksichtigt werden, dass eventuell unternehmensspezifische Anforderungen unvollständig abgedeckt werden und eine Integration in eine vorhandene Systemlandschaft aufwendig sein kann, weil zusätzliche Schnittstellen nötig sind.[15] Außerdem wird es durch die Verwendung von Standardsoftware schwierig, sich im Bereich der IT strategisch zu differenzieren.

2.4. Service Orientierte Architektur (SOA)

Eine aktuelle (2007) Tendenz in der Systemarchitektur, die von namhaften Herstellern wie IBM und SAP forciert wird, geht in Richtung Service- und Komponenten-Orientierung. Dieser Ansatz versucht die Softwareentwicklung in Richtung Innovationsstärke, Flexibilität und Produktivität gleichermaßen zu optimieren. Software wird hier in Form von wiederbenutzbaren Komponenten bzw. Services entworfen, welche die Geschäftslogik enthalten. Diese werden dann über einer gemeinsamen, auf Standardformaten basierenden Plattform (Middleware-Server bzw. Business Process Plattform) zu verschiedenen Anwendungen zusammengebaut. Damit wird das Ziel verfolgt, die IT flexibel zu halten und sich schnell an sich ändernde Geschäftsprozesse anzupassen. Die IT entwickelt sich vom daten-zentrierten- zum prozess-zentrierten-computing.[16]

Für die Softwareentwicklung ergibt sich daraus auf längere Sicht, dass künftig weniger Software neu entwickelt wird, sondern dass vermehrt neue Software aus Mustern, Vorlagen bzw. Komponenten zusammengebaut wird und durch die Kombination vorhandener Elemente neue Softwareprodukte entstehen. Dieser Weg der Software-Entstehung stellt eine Vermischung von Standard- und Individualsoftware dar, da einzelne Komponenten aus einer Standardsoftware-Bibliothek stammen und andere Komponenten individuell entwickelt werden können. In letzter Zeit prägt sich dafür der Begriff „Composition“. Diese „neue“ Art der Softwareentwicklung hat zwar Auswirkungen auf die Art und Weise des Entwurfes und der Architektur der Software, der Softwareentwicklungsprozess an sich bleibt jedoch unverändert.

2.5. Eigenschaften von Software

Software hat bezogen auf die Entwicklung folgende charakteristische Eigenschaften:[17]

- Komplexität: Software besteht immer aus mehreren Elementen, welche zueinander vielschichtige Beziehungen haben. Bei einem Hinzufügen von Funktionen steigert sich die Komplexität des Gesamtsystems viel stärker als linear.
- Immaterialität: Software besteht aus Programmtexten, die in speziellen Sprachen verfasst sind. Diese Texte können nahezu beliebig strukturiert sein, was für den Entwickler eine hohe Gestaltungsfreiheit mit sich bringt.
- Fehlerhaftigkeit: Software ist meist fehlerhaft. Das Auffinden und Beseitigen von Fehlern ist aufgrund der hohen Systemkomplexität besonders schwierig.
- Digitalität: Software ist digital und kann demzufolge unzählige mögliche Systemzustände einnehmen.

Diese Eigenschaften haben einen starken Einfluss auf die Gestaltung des Softwareentwicklungsprozesses.

2.6. Qualität von Software

Ein Ziel eines Softwareentwicklungsprojektes ist es, möglichst qualitativ hochwertige Software zu erstellen. Qualität ist nach der DIN ISO 8402-Norm „Die Gesamtheit von Eigenschaften und Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen“.[18] Bezogen auf Software werden weiters Qualitätsmerkmale beschrieben, für welche mit der DIN ISO 9126-Norm ein Standard festgelegt wurde.[19] In diesem Standard sind als Merkmale Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit angeführt. Die einzelnen Merkmale werden durch weitere Ausprägungen näher spezifiziert:[20]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Qualitätsmerkmale für Software nach DIN ISO 9126[21]

Je nach den individuellen Anforderungen sind verschiedene Kriterien wichtig. Es können einzelne Kriterien untereinander auch konkurrieren, was zum Beispiel im Hinblick auf Effizienz und Übertragbarkeit der Fall ist – ein hoch performantes System muss auf eine bestimmte Systemumgebung abgestimmt werden, was dem Anspruch der Portabilität widerspricht. Es müssen daher die einzelnen Kriterien zusätzlich priorisiert und daraufhin die Qualität der Software im Einzelfall beurteilt werden.

Die o. a. Kriterien und Merkmale beziehen sich ausschließlich auf das Produkt Software. Um ein qualitativ hochwertiges „Produkt“ Software zu erstellen, ist bereits bei der Entwicklung darauf zu achten, dass Methoden und Verfahren zum Einsatz gelangen, die auf Qualität Wert legen.[22] Diese Prozessqualität wird von den unterschiedlichen Vorgehensmodellen durch verschiedene Ansätze, wie zum Beispiel eigene Testläufe, Meilenstein-Abnahmen oder Rückkoppelungs-Schleifen, erreicht.

2.7. Softwareentwicklung

Softwareentwicklung beschäftigt sich mit der Herstellung von Software und den damit verbundenen Prozessen. Sie bildet den gesamten Software-Lebenszyklus ab und schließt neben dem Entwickeln auch das Betreiben, Ändern und Optimieren der Software ein.[23]

Softwareentwicklung – auch Software Engineering oder Software-Technik genannt – verwendet dazu Methoden, Werkzeuge, Normen und Hilfsmittel, die es ermöglichen, die technischen und organisatorischen Problemstellungen zu bewältigen, um Software mit hoher Qualität zu wirtschaftlich vertretbarem Aufwand zu erstellen.[24]

2.8. Softwareentwicklungsprozess

Der Entwicklungsprozess von Software umfasst mehrere Teildisziplinen der Informatik und des Managements. Diese Disziplinen sind während des ganzen Entwicklungsprozesses eng miteinander verzahnt. Die Prozesse werden wie folgt unterteilt:[25]

- Kernprozesse der Softwareentwicklung:
- Analyse: Erhebung, Analyse und Schätzung der Anforderungen
- Entwurf: Festlegen der Architektur und des Programmaufbaus
- Codierung und Implementierung: Umsetzung in ausführbares Programm
- Test und Inbetriebnahme: Test und Einsatz der Software
- Unterstützungsprozesse der Softwareentwicklung:
- Projektmanagement (inkl. Risiko- und Teammanagement)
- Qualitätsmanagement
- Konfigurationsmanagement (Versions- und Änderungskontrollen)
- Dokumentation (Entwickler-, Administration- und Benutzerdokumentation)

Zur Strukturierung und Beherrschung des Entwicklungsprozesses haben sich Vorgehensmodelle herausgebildet, um eine vorhersehbare, überschaubare, planbare und kontrollierbare Gestaltung der Software-Entwicklung zu erreichen. Es handelt sich hierbei um Prozessmodelle, welche den Gestaltungsprozess — von der Konzeption bis zum Einsatz im Echtbetrieb — in überschaubare, zeitlich und inhaltlich begrenzte Schritte oder Phasen unterteilen. Dies erlaubt es, ein System, das insgesamt sehr komplex erscheint, Schritt für Schritt zu realisieren. Weiters bringen Vorgehensmodelle diese Vorteile:[26]

- Ein Vorgehensmodell erzwingt die Abfolge notwendiger Entwicklungsschritte und sichert die Einheitlichkeit von Methoden und Werkzeugen
- Es macht teilweise die Entwicklung vom individuellen Entwicklungsingenieur unabhängig
- Die Lehr- und Lernbarkeit des in einem Unternehmen verwendeten Entwicklungsprozesses wird erleichtert
- Der Entwicklungprozess kann theoretisch betrachtet, analysiert und durch Erfahrung verbessert werden
Gemein ist allen Vorgehensmodellen, dass durch den Einsatz von Regeln vorhandenes Wissen genutzt und neu erworbenes Wissen während eines Entwicklungsvorhabens künftig nutzbar gemacht werden soll. Im Vordergrund steht stets die Unterteilung eines großen Systems in kleinere Einheiten, wobei hier eine Unterteilung je nach Entwicklungsablauf und –inhalt wie folgt möglich ist:[27]
- nach Funktionalität (Zerlegung des Systems in Teile nach Funktionen)
- Ausprägung (das System wird komplett realisiert, allerdings mit reduzierten Funktionalitäten, welche schrittweise erhöht werden)
- Implementierungsphasen (Erstellung des Systems nach Realisierungsphasen, wie Analyse, Entwurf, Programmierung usw.)
- Arbeitsteams (Erstellung in Teams, wobei jedes Team einen abgegrenzten Aufgabenteil übernimmt)

In den im Folgenden beschriebenen Vorgehensmodellen finden sich Mischformen dieser elementaren Ansätze wieder.

3. Vorgehensmodelle im Überblick

Im Nachfolgenden werden Vorgehensmodelle für die Entwicklung von Software dargestellt. Die Auswahl der dargestellten Modelle erfolgte aufgrund der Häufigkeit der Erwähnung in der Fachliteratur. Zur Feststellung dieses Wertes wurde jene Fachliteratur herangezogen, welche sich allgemein mit dem Thema Softwareentwicklung beschäftigt und sich nicht bereits vorab auf ein bestimmtes Modell konzentriert. Folgende Literatur wurde analysiert und brachte das darunter stehende Ergebnis:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Fachliteratur für die Auswahl der dargestellten Vorgehensmodelle[28]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Nennungen der Vorgehensmodelle in der Fachliteratur[29]

Im Weiteren werden alle Modelle betrachtet, welche zumindest zweimal genannt wurden. Von den einmal genannten Modellen wird zusätzlich MSF mit behandelt, weil dieses Modell als vollständig ausformuliert angesehen werden kann, während die anderen nur einmalig erwähnten Modelle (AM — Agile Modeling, ADP — Agile Database Techniques und PP — Pragmatic Programming) als unvollständige Modelle aufgeführt sind.[30] Außerdem kann vermutet werden, dass MSF aufgrund des kommerziellen Hintergrundes (Microsoft ist Entwickler des Modells) in der Literatur weniger häufig erwähnt wird.

Im Folgenden werden jeweils der Aufbau des Modells, die Bestandteile und Elemente sowie an relevanter Stelle der Hintergrund bzw. die Entstehung des Modells erklärt.

3.1. Build-and-Fix-Cycle

Dieses einfache Vorgehen verzichtet auf jegliche Dokumentation, Struktur oder Einteilung in Arbeitsschritten. Es werden alle Tätigkeiten vom Programmierer zum Zeitpunkt der Erstellung der Software durchgeführt. Änderungswünsche, die während des Betriebs auftreten, werden vom Programmierer direkt in das System eingebaut. Software, die so entsteht, kann durchaus von hoher Qualität sein, allerdings ist ihr Umfang begrenzt, die Wartung schwierig bzw. nur vom Programmierer möglich und die Wiederverwendbarkeit von Teilen aus dieser Software ist meist schlecht.[31]

Dieses Vorgehen entspricht im Grunde keinem Modell. Es ist jedoch diese Art der Softwareentwicklung durchaus in der Praxis zu finden.

3.2. Wasserfallmodell

Das Wasserfall-Modell wurde aus einem allgemeinen sequenziellen Phasenmodell, dem Software Life Cycle Modell, abgeleitet. Im Life Cycle Modell geht man von einer Zeitspanne aus, in der eine Software strukturiert der Reihe nach zuerst geplant, dann entwickelt, im weiteren eingesetzt, eventuell angepasst und letztlich die Nutzung wieder beendet wird.[32] Das Phasenmodell beruht auf dem Prinzip, dass für jede Phase fest steht, welche Ergebnisse in welcher Phase erreicht werden müssen. Erst nach Abschluss der vorhergehenden Phase wird mit der darauf folgenden Phase begonnen.[33] Jede Phase liefert ein wohldefiniertes Produkt ab, welches in der darauf folgenden Phase weiter verfeinert wird.[34] „Es kann als Darstellung der Tätigkeiten bei der Softwareentwicklung interpretiert werden“.[35]

Die Erfahrungen in der Anwendung haben gezeigt, dass ein sequenzielles Vorgehen oft nicht zielführend ist, da die Wechselwirkungen zwischen den Phasen zu stark sind und Rücksprünge in frühere Phasen bzw. eine Wiederholung von einzelnen Schritten notwendig sind.[36] Erste Varianten des Wasserfall-Modells hielten sich strikt an die sequenzielle Abfolge, wie das Modell nach Boehm.[37] Spätere Vatianten wie das Wasserfall-Modell nach Royce (1970) haben als Antwort auf die o. a. Problemfelder im Modell Rückkoppelungen zwischen Phasen vorgesehen. Dies allerdings eingeschränkt auf die Vorgängerphase, um teure Nacharbeit, die aufgrund dieser Iterationen entstehen könnte, zu vermeiden. Weiters wurde eine Validierung des Phasenergebnisses eingefordert, um sicherzustellen, dass die Arbeiten der nächsten Phasen auf ein gültiges und richtiges Ergebnis aufbauen.[38] In der folgenden Abbildung sind die einzelnen Phasen dieses Modells abgebildet:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Wasserfallmodell mit Rücksprüngen und Ergebnissen[39]

3.3. V-Modell

Beim V-Modell werden die Phasen zueinander in Korrelation gesetzt. Es werden die Ergebnisse aus den Phasen der ersten Hälfte in den Phasen der zweiten verifiziert bzw. validiert. Zur Qualitätssicherung werden die Erzeugungsphasen (Spezifikation, Entwurf) den Nachweisphasen (Integration, Abnahme) gegenübergestellt.[40] Weiters erfolgt eine Strukturierung des Entwicklungsprozesses in Anwender-, Architektur- und Implementierungssicht, wie in der folgenden Abbildung dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: V-Modell mit Sichtendarstellung[41]

Das V-Modell findet vor allem bei öffentlichen Aufträgen Anwendung, da es dort als Vorgehensmodell eingefordert wird. Im Jahr 2005 ist eine erweiterte Version des Modells namens V-Modell XT veröffentlicht worden. Diese Variante berücksichtigt die Notwendigkeit, dass – wie bereits beim Wasserfallmodell festgestellt – ein einmaliger Durchlauf der Phasen selten zielführend ist. Dementsprechend werden Rücksprünge zu vorigen Phasen und wiederholte Durchläufe vorgesehen. Neben dem Modell für die Softwareentwicklung bzw. Systemerstellung können innerhalb des V-Modells Submodelle für Projektmanagement, Qualitätssicherung und Konfigurations­manage­ment definiert werden.[42]

3.4. Prototypen Modell

Bei sequentiellen Modellen wird unterstellt, dass durch Kontrollen ein einmaliger Durchlauf der Phasen genügt, um das System zu entwickeln. „Das Wasserfallmodell machte ein Dilemma deutlich: In der strengen Interpretation als Einbahnstraßenmodell ist es nicht durchzuhalten“.[43] In der Praxis erzwingen Korrekturen und Änderungen Rücksprünge in frühere Phasen. Der wiederholte Durchlauf von einzelnen Phasen führt zu einem deutlich erhöhten Aufwand, wie dies bei den neueren Modellvarianten des Wasserfall- und V-Modells der Fall ist. Es bleibt das Risiko bestehen, dass durch zu spätes Erkennen der Korrekturnotwendigkeit zu viel Geld und Zeit verbraucht werden, um das Entwicklungsprojekt erfolgreich zu Ende führen zu können.[44]

Im Prototyping-Modell wird durch Iteration und kurze Entwicklungszyklen das Verständnis über die geforderte Software vom Kunden und Entwickler schrittweise erhöht. Der Kunde bekommt auf diese Weise früh eine Vorstellung von der späteren Anwendung und kann frühzeitig mögliche Fehlentwicklungen erkennen.[45]

Es gibt folgende Herangehensweisen zur Erstellung eines Prototypen:[46]

Demonstrationsprototyp: Wird dazu verwendet, um dem Auftraggeber die wichtigsten Produkteigenschaften verständlich darzustellen. Die Erstellung eines solchen Prototyps erfolgt oft ohne ein Software-Entwicklungsinstrument, sondern mit einem Grafik- bzw. Zeichenprogramm.

Exploratives Prototyping bzw. Wegwerfprototyp: Es wird darauf geachtet, dass in kurzer Entwicklungszeit ein Prototyp zur Darstellung möglichst vieler Funktionen vorliegt, um die Lösungswege für die Anforderung zu diskutieren. Die Qualität des Prototypen ist nachrangig. Der Prototyp dient in erster Linie zur Unterstützung der Problemanalyse und Spezifikation. Eine spätere Weiterverwendung des Prototypen ist nicht geplant. Stehen alle Anforderungen fest, wird mit der eigentlichen Entwicklung, beispielsweise nach dem Wasserfallmodell, begonnen.

Experimentelles Prototyping: Setzt sich eine Software aus mehreren Teilsystemen zusammen, wird das experimentelle Prototyping dazu verwendet, um die Funktionalität der Schnittstellen und die Flexibilität bezüglich möglicher Erweiterungen zu erproben. Dieser Prototyp wird vorrangig in der Phase des System- und Komponentenentwurfs eingesetzt. Eine spätere Weiterverwendung ist bei positiven Testergebnissen wahrscheinlich.

Evolutionäres Prototyping: Diese Variante gelangt am häufigsten zum Einsatz; hier wird die Software schrittweise aufbauend entwickelt. Es wird zunächst ein Prototyp mit den bereits klar vorhandenen Benutzeranforderungen erstellt. Auf Basis dieses Prototypen werden weitere Benutzeranforderungen integriert und auf diese Weise wird, in sich wiederholenden Schleifen, der Prototyp immer weiter ausgebaut. Innerhalb dieser Kategorie unterscheidet man weiter in horizontales Prototyping (der Prototyp beschränkt sich vorerst auf nur eine Systemschicht, wie zum Beispiel die Benutzerschnittstelle; die weiteren Funktionen/Schichten werden schrittweise hinzugefügt) und vertikales Prototyping (die gesamte Software wird in allen Ebenen mit vermindertem Funktionsumfang entwickelt und reift schrittweise zum Endprodukt).

Es gilt beim Prototyping darauf zu achten, dass die Anforderungen nicht mit dem Prototypen mitwachsen. Außerdem muss bei der Entwicklung darauf geachtet werden, dass nicht qualitativ minderwertige Systembestandteile aus den Prototypen in das Endprodukt übernommen werden. Für ein Entwicklungsprojekt stellt Prototyping meist ein Vorgehen innerhalb eines anderen Vorgehensmodells, wie z.B. dem im Folgenden erläuterten Spiral-Modell, dar.

3.5. Spiral-Modell

Im Spiral-Modell nach Boehm (1988) werden die oben erwähnten Modelle (Wasserfallmodell, V-Modell und Prototyping) kombiniert. Es entsteht damit ein Metamodell, welches es ermöglicht, je nach Projekt ein geeignetes Vorgehen zu verwenden.[47] Der gesamte Prozess ist in vier Phasen gegliedert, welche mehrmals durchlaufen werden. Die Ergebnisse des vorgehenden Durchlaufs sind jeweils die Basis für den nächsten Durchlauf. Jeder Zyklus enthält folgende Aktivitäten:[48]

- Festlegung von Zielen: Die Ziele und geforderten Ergebnisse des Durchlaufs werden festgelegt.
- Risikoanalyse: Evaluierung der Alternativen und das Erkennen und Reduzieren von Risiken.
- Entwicklung und Test: Realisierung der geforderten Umsetzungsschritte und Überprüfung des Zwischenprodukts.
- Planung des nächsten Zyklus: Betrachten des Projektfortschritts und Verabschieden des weiteren Projektfortganges.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Spiralmodell nach Boehm[49]

Im Spiral-Modell nach Pomberger und Pree wird das Vorgehensmodell für Entwicklungsvorhaben, bei welchen die Make-or-Buy-Entscheidung noch zu treffen ist, erweitert. Dieses Modell startet dementsprechend mit einer Ausschreibung, gefolgt von Angebotsevaluierung, Prototypingwettbewerb und Auftragnehmerwahl.[50]

Da es sich beim Spiral-Modell um ein Meta-Modell handelt, ist darauf zu achten, dass das Modell vor Anwendung entsprechend den Projektanforderungen angepasst werden muss. „Das Spiralmodell kann für sehr große und komplexe Projekte verwendet werden, da es der Komplexität durch das risikogesteuerte Vorgehen Rechnung trägt.“[51]

3.6. Unified Process (Rational Unified Process – RUP)

Der Unified Process wurde von der Firma Rational (inzwischen eine Division von IBM) entwickelt. „It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget”.[52]

Der UP ist zusammengesetzt aus Entwicklungsschritten und Unterstützungsprozessen, welche in vier Phasen unterteilt sind.[53]

Die Entwicklungsschritte (Disciplines) sind wie folgt definiert:

- Business Modeling (Geschäftsprozessmodellierung): Verstehen der Probleme der Zielorganisation und Klarheit über die Vorstellungen.
- Requirements (Anforderungsanalyse): Erarbeiten einer gemeinsamen Sicht, was das System leisten soll.
- Analysis & Design (Analyse & Entwurf): Überleiten der Anforderungen in einen Entwurf.
- Implementation (Implementierung): Erstellen eines ausführbaren Systems oder Systemkomponenten.
- Test & Deployment (Test & Softwareverteilung): Testfälle ausführen, Qualität sichern und Software verteilen.

Die Unterstützungsprozesse sind Konfigurations- und Änderungsmanagement zur Verfolgung und Verwaltung von Änderungen sowie Projekt- und Umgebungsmanagement.

Die Phasen sind gegliedert in Interception Phase (Anfangsphase), Elaboration Phase (Ausarbeitung), Construction Phase (Implementierung-/Konstruktionsphase) und Transition Phase (Inbetriebnahme bzw. Übergangsphase).

Innerhalb jeder Phase werden die Entwicklungsschritte mehrfach durchgeführt und auf diese Weise die Ergebnisse und die Qualität schrittweise gesteigert. Je nach Projektumfang sind unterschiedlich viele Iterationen nötig. Jede Phase endet als Meilenstein mit einem definierten (Teil-)Ergebnis.[54]

In der dargestellten Grafik ist das Zusammenwirken der Entwicklungsschritte und Unterstützungsprozesse während der Projektphasen ersichtlich. Die Größe der Flächen zeigt, wie aufwendig welcher Entwicklungsschritt in welcher Phase ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Phasen, Schritte und Prozesse des Unified Process[55]

In der Umsetzung ist eine enge Bindung an UML[56] (Unified Modeling Language) vorgesehen. Insbesondere soll die Anforderungsanalyse mit Use Cases (Anwendungsfälle) erhoben werden.[57] Diese werden in weiterer Folge verwendet, um die Leistungsmerkmale der Anwendung weiter zu definieren und letztlich die Implementierung zu unterstützen.[58]

Der Unified Process versucht, für jedes mögliche Projekt eine Vorgehensweise bereitzuhalten, und zwar durch ein jeweils angepasstes Zusammenspiel zwischen Rollen, Aktivitäten und Artefakten. In diesem Zusammenhang wird mit Rollen definiert, wer welchen Arbeitsschritt zu erledigt hat. Die Aktivitäten enthalten die einzelnen Arbeitsschritte, und die Artefakte definieren, welche Ergebnisse zu liefern sind. Damit werden sehr viele Abhängigkeiten zwischen den Elementen des Prozesses erzeugt, die zu einer hohen Komplexität führen. Daher ist auch eine Anpassung an das jeweilige Projekt unerlässlich.[59]

dX — ein minimaler RUP: Unter dem Namen dX gibt es eine Variation des RUP, welche den RUP verschlankt und als Minimalversion implementiert. Auf diese Weise wird versucht, aus dem RUP eine Methode zu machen, die auf Prinzipien und Werte der agilen Softwareentwicklung (siehe Kapitel 4.) aufbaut.[60] Es ist jedoch darauf hinzuweisen, dass hinter dem RUP die Denkhaltung eines stark strukturierten Vorgehens steht, um das System in Arbeitspakete zu zerlegen und Teilergebnisse zu erstellen. Agile Methoden setzen hingegen oft auf formlose, teamorientierte Zusammenarbeit zur schnellstmöglichen Erstellung von lauffähiger Software. Inwieweit RUP als agile Methode Anerkennung findet ist daher fraglich. Die dX-Variante scheint jedenfalls für Teams interessant zu sein, die bereits RUP im Einsatz haben und sich in Richtung Agilität bewegen möchten.

3.7. Microsoft Solutions Framework

Das MSF besteht aus Modellen zur Planung, Erstellung und Bereitstellung von Technologielösungen.[61] MSF setzt sich aus einem Team- und Prozessmodell sowie aus unterstützenden Disziplinen zusammen.[62]

Das MSF Teammodell definiert die Rollen und Verantwortlichkeiten sowie die Beziehungen zwischen den Team-Mitgliedern. MSF definiert Ziele, genannt "Key-Quality goals", und weist diesen verantwortliche Rollen zu. Innerhalb der Rollen sind eine intensive Kommunikation und ein breiter Erfahrungsaustausch vorgesehen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: MSF Schlüssel-Ziele und Rollen[63]

Die Struktur des MSF Prozessmodells sieht vier Phasen vor, welche hintereinander durchlaufen werden und jeweils mit einem Meilenstein-Ergebnis enden.[64]

Beim MSF wird die Software schrittweise in mehreren Phasenzyklen entwickelt:[65]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Phasen des MSF Prozessmodells[66]

Nach der Auslieferung der Software empfiehlt Microsoft einen Betrieb derselben entsprechend dem MOF (Microsoft Operations Framework). MOF ist ein Ansatz, mit dessen Hilfe Zuverlässigkeit, Verfügbarkeit und einfache Administration der Produktionssysteme gewährleistet werden soll. Microsoft beschreibt den Zusammenhang der Modelle wie folgt: "MSF = build it right", "MOF = run it right".[67]

Das Modell kann um die Disziplinen Readiness-, Projekt- und Risikomanagement erweitert werden. Diese Disziplinen, welche ursprünglich nicht Teil des MSF waren, dienen als Unterstützung zur Steuerung des Projektes und wurden zum MSF hinzugenommen, um den Erfolg der Projekte zu steigern.[68]

Innerhalb der Microsoft Produktfamilie ist ein Einbinden des MSF vorgesehen und wird durch Tools unterstützt. Insbesondere besteht die Möglichkeit einer direkten Integration der MSF-Tools in die Microsoft Entwicklungsumgebung Visual Studio.

3.8. Agile Vorgehensmodelle

Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität in der Softwareentwicklung. Sie entstand als Gegenbewegung zu den als schwergewichtig und bürokratisch angesehenen Softwareentwicklungsprozessen wie dem klassischen Wasserfall- oder V-Modell.[69] „Agility is the ability to both create and respond to change in order to profit in a turbulent business environment“.[70] Agile Entwicklung ist gekennzeichnet durch geringen bürokratischen Aufwand, schwache Formalisierung und wenige, flexible Regeln. Die Änderbarkeit der Software bzw. das Reagieren auf sich ändernde Anforderungen wird in den Mittelpunkt gestellt.[71] Der Entwicklungsprozess soll verschlankt und die für die Zielerreichung unterstützenden Werte, Prinzipien und Methoden betont werden. Es gilt, einen sinnvollen Kompromiss zwischen keinen und zu vielen Prozessvorgaben zu finden.[72] Agile Entwicklung geht davon aus, dass die Produktziele erreichbar, aber nicht (vollständig) vorhersagbar sind und dass der Entwicklungsprozess ähnlich ablaufen kann, jedoch nicht wiederholbar ist.[73]

In den meisten agilen Prozessen wird die reine Entwurfsphase auf ein Mindestmaß reduziert. Es wird versucht, so früh wie möglich im Entwicklungsprozess zu ausführbarer Software zu gelangen, welche dann in regelmäßigen, kurzen Abständen dem Kunden zur gemeinsamen Abstimmung vorgelegt werden kann. Somit wird es möglich, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen. Die wertvollsten Funktionen werden oft erst erkannt, wenn der Kunde eine frühe Version der Software gesehen und damit „gespielt“ hat[74]. Dies führt zu einer direkten Mitarbeit des Kunden. Jeder Beteiligte bringt so seine Sicht auf das System ein und es wird gemeinsam die effektivste Lösung ausgearbeitet. Ein Abweichen des Verständnisses über das Gewünschte zwischen Entwickler, Kunde bzw. Benutzer wird dadurch ebenfalls vermieden.[75]

Die agile Softwareentwicklung setzt sich aus folgenden Bestandteilen zusammen:[76]

- agile Werte als Fundament und darauf basierend agile Prinzipien als Handlungsgrundsätze
- agile Methoden als konkrete Verfahren während der Softwareentwicklung, die sich auf die Werte und Prinzipien stützen

Die agilen Werte und Prinzipien sind im so genannten agilen Manifest, welches von namhaften Entwicklern und Begründern der agilen Bewegung entworfen wurde, niedergeschrieben. Die Kernaussagen und Werte dieses Manifests sind:[77]

- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
- Funktionierende Software ist wichtiger als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
- Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen

Es wird betont, dass die rechts stehenden Werte geschätzt werden, das Linksstehende wird jedoch höher bewertet.

Zur Unterstützung der agilen Werte sind 12 Prinzipien formuliert, welche Handlungsansätze bieten um die Werte umzusetzen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: 12 Prinzipien agiler Softwareentwicklung[80]

Für die Anwendung dieser Prinzipien bestehen Praktiken, welche je nach der im Folgenden beschriebenen agilen Methoden unterschiedlich gestaltet sind.

Agile Methoden sind Verfahren, die bei der Softwareentwicklung angewendet werden und die Struktur für das Entwicklungsprojekt vorgeben. Diese Methoden bauen auf den oben skizzierten Werten und Prinzipien auf.[81]

3.8.1. Adaptive Software Development (ASD)

Der von Jim Highsmith im Jahr 2000 veröffentlichte Ansatz basiert auf der Grundidee, dass nichts beständiger ist als der Wandel. Wenn Änderungen der Normalfall sind, dann sollte weniger geplant und vorhergesagt werden, sondern aus der Entwicklung heraus gelernt und das Gelernte stets in die weitere Gestaltung des Projektes einbezogen werden. „We have become so enamored of precise planning, we forget that products evolve from a little planning and a lot of learning as we proceed”.[82] Dementsprechend steht im Mittelpunkt von ASD ein adaptiver Lebenszyklus für Software-Entwicklung.[83]

Am Beginn wird mit dem Kunden und dem Entwicklerteam gemeinsam eine Vision für das Produkt erarbeitet. Im darauf folgenden Entwicklungszyklus wird dann alle vier Wochen das entwickelte System mit dem Kunden abgeglichen und mögliche Probleme oder Verbesserungspotenziale werden bei der nächsten Iteration berücksichtigt.[84]

Der Entwicklungszyklus setzt sich bei ASD aus „Spekulieren“, „Zusammenarbeiten“ und „Lernen“ zusammen. Beim Spekulieren wird mit dem Auftraggeber abgestimmt, was mit dem nächsten Inkrement umgesetzt werden soll. Beim Zusammenarbeiten wird implementiert, das heißt, die zuvor definierten Anforderungen werden programmiert, wobei die Art der Umsetzung offen gelassen wird. Das Lernen dient der Rückkoppelung und dem Verbessern des Vorgehens für die nächste Iteration.[85]

3.8.2. Crystal Methodenfamilie

Dieses Vorgehen wurde von Alistair Cockburn, einem Mitgründer der agilen Allianz, erstellt. Bei den Crystal-Methoden werden die Menschen in den Mittelpunkt gestellt. Das Team, gute Zusammenarbeit, vertrauensvolle Kommunikation, die Gemeinschaft, Talente und Fähigkeiten aller Beteiligten sind der Schlüssel zum Projekterfolg. Für Cockburn ist eine Methode dann erfolgreich, wenn sie zum Ergebnis geführt hat und das Team es wieder so machen würde. Crystal setzt stark auf Selbstorganisation des Entwicklungsteams und dementsprechend auf wenig Kontrolle.[86]

Hinter der Crystal Methodenfamilie steht der Ansatz, dass es keine einzige für jedes Projekt passende Methode gibt. Es bestehen daher mehrere Varianten des Crystal-Ansatzes, wobei sich die Wahl der Crystal-Variante nach der Anzahl der beteiligten Personen und der Kritikalität (Höhe der Risiken) richtet.[87]

Die Methoden sind mit Farben benannt, wobei die Farbe im Wesentlichen die Anzahl der beteiligten Person am Projekt angibt. Kritikalität hingegen bildet die Risiken ab, das heißt, welche Art und welches Ausmaß von Schaden im Falle eines Scheiterns des Projektes zu erwarten ist. Abhängig von der Kritikalität wird ein "Härtungsgrad" der jeweiligen Crystal-Variante gewählt. Als Stufen der Kritikalität sind Gefährdung von Komfort (Anwenderzufriedenheit), Verlust von Geld, Gefährdung des Unternehmens und als höchste Stufe Verlust von Menschenleben vorgesehen. Je nach Crystal-Variante ändern sich die Anzahl der Rollen, die Menge der einzusetzenden Praktiken und der Dokumentationsumfang. Die Gruppierung nach Mitarbeitergröße wird damit begründet, dass der Kommunikationsablauf bei steigender Mitarbeiterzahl unterschiedlich strukturiert werden muss. Während ein kleines Team formlos kommuniziert, muss bei einem Team von beispielsweise 20 Personen ein Regelwerk bestehen. Für jede der Gruppengrößen werden daher unterschiedliche Kommunikationsformen und -mittel vorgeschlagen. Die Gruppierung nach Kritikalität wirkt sich darauf aus, wie formal und genau vorgegangen wird. Je schwerwiegender die Risiken, umso mehr Zusatzaufwand wird für Korrektheit und Sicherheit des Programms in Kauf genommen. Auch hier gibt es eine Staffelung der einzusetzenden Methoden. Durch die Kombination der beiden Kriterien kann die passende, spezifische Variante gefunden werden, deren Details sich dann direkt eindeutig nachschlagen lassen. Dadurch ist eine Anpassung an die Projektumstände gegeben und es ist klar, welche Regeln im vorliegenden Fall dann zur Anwendung kommen sollten.[88] Crystal erlaubt viel Toleranz im Einsatz der Methode und gibt als Regeln lediglich vor, dass inkrementell entwickelt wird sowie dass pre- und postinkrementelle Reflexions-Workshops abgehalten werden müssen.[89]

Derzeit bestehen ausformulierte Methoden für die Varianten Crystal Clear, Crystal Orange und Crystal Orange Web. Für alle anderen Varianten sowie generell für die Kritikalitätsstufe „Gefährdung von Leben“ sind keine Publikationen vorhanden, was darauf zurückzuführen ist, dass der Begründer der Crystal-Methodenfamilie selbst keine Erfahrungen in diesem Bereich hat.[90]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Matrix der Crystal Methoden[91]

3.8.3. Dynamic Systems Development Model (DSDM)

DSDM entstand Mitte der 90er Jahre in Großbritannien und ist vor allem in Europa verbreitet.[92] DSDM entstand aus dem Ansatz des Entwickelns mithilfe von Prototypen, auch RAD — Rapid Application Development — genannt. Dieses Vorgehen baut auf folgenden 9 Prinzipien auf, welche eine starke Ähnlichkeit mit den allgemeinen Prinzipien der agilen Methoden aufweisen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: 9 Prinzipien von DSDM[93]

Der DSDM-Prozess sieht für ein Entwicklungsprojekt fünf Phasen vor[94], wobei die ersten zwei sequenziell und die restlichen iterativ durchlaufen werden:

- Feasability Study (Machbarkeitsstudie): Es wird überprüft ob DSDM die geeignete Methode für das Projekt ist. Weiters werden die technischen Möglichkeiten abgeklärt sowie die zu erwartenden Risiken erhoben. Als Ergebnis dieser Phase liegen ein Machbarkeitsbericht und ein grober Rahmen für die Entwicklung vor.

[...]


[1] vgl. Scholz, 2004, S. 1

[2] vgl. Gruhn, 2005, S. 2-3

[3] vgl. Standish Group, 1995: S. 2; vgl. Standish Group, 2004, S. 1 ff.

[4] vgl. Cohn, 2006, S. 11

[5] vgl. Standish Group, 2004, S. 1 ff ; vgl. Standish Group, 1995, S. 8; vgl. Standish Group, 1996, S. 1 ff.

[6] vgl. Gartner, 2004, S. 8

[7] Bezogen auf die in dieser Arbeit im Literaturverzeichnis genannten Publikationen

[8] Quelle: modifiziert nach Krcmar, 2003, S. 30

[9] vgl. Krcmar, 2003, S. 30 ff.

[10] vgl. Kaplan/Norton, 2004, S. 199 ff., S 250 ff.

[11] vgl. Heinrich, 1993, S. 29

[12] vgl. Pomberger/Pree, 2004, S. 3

[13] vgl. Heinrich, 1993, S. 29

[14] vgl. Lang, 2004, S.15-16

[15] vgl. Krcmar, 2003, S. 113

[16] vgl. SAP AG, 2005, S. 2 ff.; vgl. Noel, 2005, S. 1 ff.; vgl. Sprott, 2004, S. 2 ff.

[17] vgl. Ludwig/Lichter, 2006, S. 35-38; vgl. Pomberger/Pree, 2004, S. 2-3

[18] Pomberger/Pree, 2004, S. 51

[19] vgl. Pomberger/Pree, 2004, S. 53 ff.

[20] vgl. Krcmar, 2003, 142 ff.

[21] Quelle: modifiziert nach Pomberger/Pree, 2004, S. 54

[22] vgl. Ludwig/Lichter, 2006, S. 64 ff.

[23] vgl. Lang, 2004, S. 13 ff.

[24] vgl. Pomberger/Pree, 2004, S. 5

[25] vgl. Zuser/Grechenig/Köhle, 2004, S. 49; vgl. Ludewig/Lichter, 2006, S. 335 ff.

[26] vgl. Chroust, 2003, S. 1; vgl. Zuser/Grechenig/Köhle, 2004, S. 33-34

[27] vgl. Gerlich/Gerlich, 2005, S. 152

[28] Quelle: eigene Darstellung

[29] Quelle: eigene Darstellung

[30] vgl. Dogs/Klimmer, 2005, S. 165 ff.

[31] vgl. Zuser/Grechenig/Köhle, 2004, S. 70

[32] vgl. Pomberger/Pree, 2004, S. 11, S. 17; vgl. Zuser/Grechenig/Köhle, 2004, S. 70

[33] vgl. Pomberger/Pree, 2004, S. 11

[34] vgl. Pomberger/Pree, 2004, S. 14

[35] Ludewig/Lichter, 2006, S. 9

[36] vgl. Pomberger/Pree, 2004, S. 17

[37] vgl. Gerlich/Gerlich, 2005, S. 153

[38] vgl. Pomberger/Pree, 2004, S. 17; vgl. Zuser/Grechenig/Köhle, 2004, S. 71

[39] Quelle: modifiziert nach Zuser/Grechenig/Köhle, 2004, S. 71

[40] vgl. Gerlich/Gerlich, 2005, S. 153

[41] Quelle: modifiziert nach Pomberger/Pree, 2004, S. 19

[42] vgl. Pomberger/Pree, 2004, S. 19

[43] Ludewig/Lichter, 2006, S. 153

[44] vgl. Gerlich/Gerlich, 2005, S. 154

[45] vgl. Gerlich/Gerlich, 2005, S. 155

[46] vgl. Pomberger/Pree, 2004, S. 27 ff.

[47] vgl. Pomberger/Pree, 2004, S. 32 ff; vgl. Boehm, 2022, S. 64 ff.

[48] vgl. Sommerville, 2001, S. 65, 66; vgl. Zuser/Grechenig/Köhle, 2004, S. 73 ff.

[49] Quelle: modifiziert nach Pomberger/Pree, 2004, S. 33

[50] vgl. Pomberger, 2003, S. 3

[51] Zuser/Grechenig/Köhle, 2004, S.73

[52] Kruchten, 2000, S. 17

[53] vgl. Zuser/Grechenig/Köhle, 2004, S. 93 ff.; vgl. Kruchten, 2000, S. 45 ff.

[54] vgl. Pomberger/Pree, 2004, S. 39 ff.

[55] Quelle: Galic/Macisaac/Popescu, 2004, S. 4

[56] Eine Übersicht und Erklärung zu UML ist im Anhang angeführt.

[57] vgl. Galic/Macisaac/Popescu, 2004, S. 14

[58] vgl. Zuser/Grechenig/Köhle, 2004, S. 81

[59] vgl. Zuser/Grechenig/Köhle, 2004, S. 83 ff.

[60] vgl. Booch/Martin/Newkirk, 1998, S. 104 ff.

[61] vgl. Zuser/Grechenig/Köhle, 2004, S. 96

[62] vgl. Microsoft, 2003, S. 16 ff

[63] Quelle: modifiziert nach Micorosoft, 2003, S. 17

[64] vgl. Zuser/Grechenig/Köhle, 2004, S. 98, S. 99

[65] vgl. Zuser/Grechenig/Köhle, 2004, S. 101

[66] Quelle: in Anlehnung an Microsoft, 2003, S. 6 ff.

[67] vgl. Microsoft, 2003, S. 7

[68] vgl. Microsoft, 2003, S. 19

[69] vgl. Pomberger/Pree, 2004, S. 45

[70] Highsmith, 2002, S. 29

[71] vgl. Coldeway, 2003, S. 46

[72] vgl. Fowler, 2005, S. 3

[73] vgl. Highsmith, 2002, S. xxv (Preface)

[74] vgl. Fowler, 2005, S. 8

[75] vgl. Coldeway, 2003, S. 47

[76] vgl. Dogs/Klimmer, 2005, S. 29

[77] vgl. Dogs/Klimmer, 2005, S. 32 ff.; Coldeway, 2003, S. 48

[78] vgl. Coldeway, 2003, S. 52

[79] vgl. Fowler, 2005, S. 12

[80] Quelle: vgl. Dogs/Klimmer, 2005, S. 40 ff.

[81] vgl. Coldeway, 2003, S. 48

[82] Highsmith, 2002, S. 310

[83] vgl. Hruschka/Rupp /Starke, 2004, S. 60 ff.

[84] vgl. Coldeway, 2002, S. 71

[85] vgl. Highsmith, 2002, S. 314-316, Coldeway, 2003, S. 48

[86] vgl. Hruschka/Rupp/Starke, 2004, S.53

[87] vgl. Dogs/Klimmer, 2005, S. 145

[88] vgl. Dogs/Klimmer, 2005, S. 145

[89] vgl. Cockburn, 2003, S. 267

[90] vgl. Dogs/Klimmer, 2005, S. 146

[91] Quelle: modifiziert nach Dogs/Klimmer, 2005, S. 145

[92] vgl. Highsmith, 2004, S. 251

[93] Quelle: vgl. Dogs/Klimmer, 2005, S. 114; vgl. Highsmith, 2004, S. 254

[94] vgl. Abrahamsson/Salo/Ronkainen/Warsta, 2002, S.62 ff.

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2007
ISBN (eBook)
9783836622608
DOI
10.3239/9783836622608
Dateigröße
982 KB
Sprache
Deutsch
Institution / Hochschule
Management Center Innsbruck Internationale Fachhochschulgesellschaft mbH – Informationsmanagement
Erscheinungsdatum
2008 (November)
Note
1,0
Schlagworte
softwareentwicklung projektmanagement scrum software
Zurück

Titel: Auswahl und Einführung eines Vorgehensmodells für die Softwareentwicklung
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
book preview page numper 20
book preview page numper 21
book preview page numper 22
book preview page numper 23
book preview page numper 24
book preview page numper 25
book preview page numper 26
126 Seiten
Cookie-Einstellungen