Fachhochschule Brandenburg

Onlinestudiengang Medieninformatik

Modul: Einführung in wissenschaftliche Projektarbeit

Prof. Dr. Friedhelm Mündemann

Sommersemester 2011

Seminararbeit

Wie kann man risikoorientiert Software entwickeln?

Brauchen wir einen Paradigmenwechsel in der Software-Entwicklung?

28. Juni 2011

Oliver Seibert

Ringseisstraße 8

80337 München

seibert@fh-brandenburg.de

Matrikelnummer: 20082923

Ich versichere, dass ich diese Seminararbeit ohne fremde Hilfe selbständig verfasst und nur

die angegebenen Quellen und Hilfsmittel benutzt habe. Wörtlich oder dem Sinn nach aus

anderen Werken entnommene Stellen sind unter Angabe der Quellen deutlich kenntlich

gemacht.

München, 29. Juni 2011

Oliver Seibert

I

I Inhaltsverzeichnis

I Inhaltsverzeichnis I

II Abkürzungsverzeichnis II

1. Einführung 3

2. Software-Entwicklung 4

3. Vorgehensmodelle für die Software-Entwicklung 5

3.1 Wasserfallmodell 7

3.2 Spiralmodell 8

3.3 V-Modell und V-Modell XT 9

3.4 Rational Unified Process (RUP) 10

3.5 Agile Modelle 11

3.5.1 Das Agile Manifest 11

3.5.2 Extreme Programming (XP) 12

3.5.3 Scrum 13

3.6 Kombinationen 15

4. Risikoorientierung in der Software-Entwicklung 15

4.1 Definitionen 16

4.2 Risiken in der Softwareentwicklung 16

4.3 Minimierung von Risiken in den verschiedenen Vorgehensmodellen 17

4.3.1 Risikofaktor Personal 17

4.3.2 Risikofaktor Projektumfang 18

4.3.3 Risikofaktor Anforderungsänderung 19

4.3.4 Risikofaktor Kunde 20

4.3.5 Weitere Risikofaktoren 21

5. Fazit 21

6. Literaturverzeichnis 24

III Abbildungsverzeichnis III

II

II Abkürzungsverzeichnis

iSSE: Institut for Software & Systems Engineering

RUP: Rational Unified Process RUP

SOA: Serviceorientierte Architektur

XP: Extreme Programming

3

1. Einführung

Die Entwicklung von Software ist ein Prozess, der von der ersten Idee des Kunden, eines

Auftraggebers, Entwicklers oder innovativen Gedankenblitzes eines kreativen Menschen über

diverse Stufen, in mehr oder weniger unterteilten Phasen, Schritt für Schritt zu einem fertigen

Produkt verläuft.

Prozesse besitzen im Allgemeinen eine lineare, zeitlich orientierte Struktur. Dadurch wird die

Gesamtheit in von einander abhängige und aufeinanderfolgende Teilschritte mit bestimmten

Aufgaben aufgeteilt. Diese Teilschritte werden nach definierten Methoden ausgeführt. Durch

verbindliche Vorgaben der anzuwendenden Methode werden die zu erzielenden

Projekterfolge nachvollziehbar und wiederholbar gemacht [SÄF10, S. 343].

In all diesen Schritten, Phasen und Entwicklungsstufen stecken Risiken. Risiken sind nicht

vermeidbar, Risiken sind immer da. Bei der Entwicklung von Software gilt es Probleme, die

aufgrund der vorhandenen Risiken entstehen können, nicht eintreten zu lassen und im

Eintrittsfall möglichst gering zu halten.

In dieser Arbeit sollen vor allem die methodischen Trends im Bereich der Vorgehensmodelle

näher betrachtet werden. Darüber hinausgehende Tendenzen, wie neuen

Softwarearchitekturen (z.B. SOA), Komponentenwiederverwendbarkeit, oder

Entwicklungstools sollen hierbei nicht dargestellt werden, da sie auf die Methodenauswahl

keinen oder nur geringen Einfluss haben.

In der Geschichte der Softwareentwicklung wurden die verschiedensten Vorgehensmodelle

entwickelt, die einzelnen Stufen, Phasen und Schritte zu kategorisieren und zu beschreiben.

Aufgaben, Herangehensweisen, Richtlinien wurden festgelegt, die mehr oder weniger

variabel, frei verwendbar oder sehr streng anzuwenden sind. Die Reihenfolge der

Entwicklungsschritte, die Ausführung und Umsetzung wird in der Theorie durch diese

Vorgehensmodelle beschrieben. In der praktischen Anwendung wählen sich Firmen und

Entwicklerteams bestimmte Modelle aus, je nach Projektgröße, vorhandener Zeit und

Ressourcen, wie Geld, Akteure, Technologien, oder passen diese durch das sogenannte

„tailoring“ an ihre Vorgaben an. Jedes Vorgehensmodell hat dabei eine andere

Vorgehensweise und versucht mit anderen Methoden Probleme zu vermeiden.

Allen Vorgehensmodellen gemeinsam ist das Entgegenwirken einer mangelnden

Kommunikation zwischen einzelnen Mitarbeitern und Abteilungen bzw. Projektteams. Dies

liegt vor allem daran, dass Prozessmodelle den Softwareentwicklungsprozess in seiner

Gesamtheit betrachten und nicht zwischen den einzelnen Entwicklungsphasen und -Stufen

unterscheiden [VER00, S. 25]. Der große Unterschied findet sich im Bereich der

Risikobetrachtung.

Aus einer großen Anzahl gescheiterter Projekte wurde in der Softwarebranche ein

Lernprozess angestoßen, der eine zunehmende Etablierung von Methoden-,

Qualitätssicherungs- und Testabteilungen zur Folge hatte [VER00, S. 18]. Diese

4

„Entwicklungen schlagen sich auch in der Ablauforganisation von Software-

entwicklungsprojekten nieder. Generell kann dabei ein Trend zu risikominimierenden

Entwicklungsprozessen (z.B. inkrementelle Prozesse) festgestellt werden. Bekanntester

Vertreter dieser inkrementellen Prozessmodelle ist der Rational Unified Process (RUP)“

[FÜR11, S.26f].

Um zu erkennen welches Modell mit welchen Ergebnis risikoorientiert auf bestimmte

Situationen reagiert und welche Vor- und Nachteile darin stecken, werden vom Risiko

ausgehend über die jeweilige Situation in einem Entwicklungsschritt die Modelle verglichen.

Das Ergebnis soll zeigen ob und wie vorhandene Modelle risikoorientiert anwendbar sind und

angewendet werden. Ob die Software-Entwicklung effektiv und effizient stattfindet oder in

wieweit ein Paradigmenwechsel sinnvoll oder notwendig ist, oder dieser gar schon längst

begonnen hat.

2. Softwareentwicklung

Softwareentwicklung ist die deutsche Bezeichnung für software engineering. Es beschreibt

Herstellung und Entwicklung von Software, Organisation und Modellierung der

Datenstrukturen, Betrieb von Softwaresystemen. Helmut Balzert definiert

Softwareentwicklung wie folgt: „Zielorientierte Bereitstellung und systematische

Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige,

ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.“

[BAL96, S.36]

Um zu verstehen wo Risiken vorhanden sind muss man sich die einzelnen Phasen der

Softwareentwicklung betrachten und vor Augen führen welche Aufgaben diese haben. Die

Einteilung der Phasen folgt der Einteilung von Helmut Balzert [BAL98]:

Analysephase

In der Analysephase wird eine Ausgangssituation beschrieben. Hier werden Ziele definiert,

die im Anwendungsbereich des zu entwickelnden Systems erreicht werden wollen. Am Ende

einer Analysephase sollen die einzusetzenden Ressourcen (Akteure, Finanzen, Zeit und

Techniken) geplant sein. Es werden diverse Voruntersuchungen wie Marktanalysen und

Kundenanfragen durchgeführt. Die einzelnen Bestandteile des geplanten Systems werden

grob dargestellt. Ebenso werden Durchführbarkeitsuntersuchungen und

Wirtschaftlichkeitsbetrachtungen durchgeführt. Diese Betrachtungen und Untersuchungen

sollen eine Vorstellung vom Zweck des zu erstellenden Produkts vermitteln. Das Resultat der

Analysephase bringt eine Situationsstudie, eine Projektkalkulation und einen Projektplan

hervor, er stellt die jeweiligen Projektschritte mit den notwendigen Ressourcen in der

vorgegeben Zeit dar.

Definitionsphase

Ziel der Definitionsphase ist es die Anforderungen des zu erstellenden Produktes aus der

Sicht des Anwenders festzulegen. Weiterhin werden Voraussetzungen zur Umsetzung der

5

Entwicklung definiert. Um dies zu erreichen werden Anforderungen ermittelt, beschrieben

und festgelegt. Die definierten Anforderungen werden auf Vollständigkeit, Konsistenz und

technische Durchführbarkeit definiert und in Datenmodellen und Funktionsmodellen

dargestellt. Als Ergebnis erhält man eine Produktdefinition mit den Produktanforderungen

bezogen auf Daten, Funktionen, Verhalten, Schnittstellen und Benutzeroberflächen.

Entwurfsphase

In der Entwurfsphase werden Umgebungs-, Rand- und Einsatzbedingen analysiert. Die innere

Struktur mit Klassen und Komponenten des Softwareentwurfs, die Zusammensetzung des

Programms, die Hierarchie und die Module werden beschrieben Diese Phase wird auch als

Designphase bezeichnet. Die Systemkomponenten werden definiert und daraus eine

Systemarchitektur entworfen mit den Schnittstellend des Systems und deren

Wechselwirkungen.

Implementierungsphase

Die Ergebnisse der Entwurfsphase werden in eine vom Rechner ausführbare Form umgesetzt

und anschließend auf Fehlerfreiheit getestet und gesichert. Dazu werden die einzelnen

Systemkomponenten verfeinert. Daten werden vom logischen in ein physisches

Datenbankkonzept überführt, die Syntax wird getestet und bei Bedarf korrigiert. Das System

wird schließlich unter realen Bedingungen getestet. Als Ergebnis erhält man Quelltexte für

die Komponenten, Testprotokolle und generierte Datenobjekte und -strukturen.

Abnahme- / Einführungsphase

Das fertige Produkt wird inkl. Dokumentation an den Auftraggeber übergeben. Es werden

Abnahmetests durchgeführt. Das System wird in der Zielumgebung installiert, die Anwender

werden auf das System geschult und das Produkt wird in Betrieb genommen.

Wartungs- und Pflegephase

In der Wartungs- und Pflegephase soll gewährleistet werden dass das System produktiv

genutzt werden kann. Fehler die in der Betriebsphase entstehen werden beseitigt.

Änderungswünsche werden realisiert. Optimierungen werden vorgenommen. Als Ergebnis

haben der Auftraggeber ein für ihn optimal funktionierendes System und der Auftragnehmer

einen zufriedenen Kunden und motivierte, erfolgs- und honorarbelohnte Mitarbeiter.

3. Vorgehensmodelle für die Software Entwicklung

Vorgehensmodelle regeln den gesamten Prozess der Softwareentwicklung. Insbesondere

werden dabei Aktivitäten, Ergebnisse dieser Aktivitäten und die Reihenfolge der Abarbeitung

festgelegt [VER00, S. 21]. In einer Studie der GFK Marktforschung in Zusammenarbeit mit

dem Fraunhofer Institut wird das Vorgehensmodell wie folgt definiert: „In der

Softwaretechnik beschreibt ein Vorgehensmodell die Aktivitäten (Tätigkeiten) und Produkte

(Ergebnisse), die während des gesamten Lebenszyklus von Software durchzuführen bzw. zu

6

erstellen sind. Sie definieren systematische Wege zum gewünschten Anwendungssystem. Ziel

ist es durch eine einheitliche Entwicklungsmethode die Kooperation innerhalb von Teams zu

vereinfachen, die Einhaltung von Terminen und Kosten zu gewährleisten, die

Nachvollziehbarkeit von Entwicklungsentscheidungen herzustellen und langfristige Pflege zu

ermöglichen“. [GFK00]

Die Vorgehensmodelle beantworten für die Softwareentwicklung also die Fragen: In welche

Teile kann der Prozess der Softwareentwicklung gegliedert werden, in welcher Reihenfolge

werden diese ausgeführt und welche Ergebnisse sollen dabei erzielt werden. Welche

Informationen sollen als Eingangsgrößen vorliegen. Welche Ressourcen (Akteure, Finanzen,

Zeit und Techniken) werden daraufhin benötigt. Aus den Vorgehensmodellen lassen sich

Prozessleitfäden ableiten, die konkrete Anleitungen und Teilschritte zur Umsetzung liefern.

Dazu zählen die Phasen und Ergebnisse, Iterationen, Meilensteine, Aktivitäten, Prozesse,

Akteure, Artefakte. Phasen legen Zeitabschnitte fest in denen gleiche Aktivitäten angesiedelt

werden, Phasen führen gewöhnlich zu bestimmten Ergebnissen die dann weitere Phasen nach

sich ziehen. Iterationen können Rücksprünge auf oder Wiederholungen von ausgeführten

Phasen sein. In Meilensteinen werden bestimmte Zielvorgaben zeitlich und zustandsabhängig

festgelegt. Aktivitäten beschreiben sämtliche Tätigkeiten die durchgeführt werden. Als

Prozess ist in den Vorgehensmodellen der Arbeitsablauf während der Software-Entwicklung

beschrieben und festgelegt. Akteure sind alle handelnden Personen, deren zugeordnete

Funktion, Aufgabenbereiche und daraus resultierende Tätigkeiten. Als Artefakte werden die

am Ende einzelner Phasen oder im Endergebnis vorliegenden Dokumente bezeichnet.

Je nach Vorgehensart kann man die Modelle in drei Grundformen unterteilen: Sequenzielles,

Evolutionäres und Iteratives Vorgehen. In allen Modellen steckt die Idee ein Projektvorhaben

in die Einzelbereiche Konzept, Analyse, Design, Implementation und Test aufzuteilen.

[SÄF10, S. 343ff] In den klassischen, sequenziellen Vorgehensmodellen startet eine neue

Entwicklungsphase erst, nachdem eine vorangegangene abgeschlossen wurde. Die Prozesse in

diesen Modellen sind einfach zu steuern und gut zu planen. Entscheidend ist die Vorgabe oder

Annahme, dass die Anforderungen bereits in einer sehr frühen Phase vollständig erfasst

werden und sich im Laufe der Entwicklung nicht mehr ändern. Beim evolutionären Modell

wird ein Produkt stufenweise entwickelt. Ausgangspunkt ist ein Kernsystem, die sogenannte

Nullversion. Die Weiterentwicklung erfolgt anhand der gemachten Erfahrungen mit dem

bisher entwickelten System.

Iterative Modelle nähern sich schrittweise dem Endergebnis an. Die einzelnen Phasen

überlappen sich und werden in mehreren Iterationen durchlaufen. Mit jedem Durchlauf

wächst das Produkt um ein bestimmtes Inkrement. Risiken können in frühen Phasen erfasst

werden. Iteratives Vorgehen ist eine Aneinanderreihung von Projektabschnitten, die in sich

geschlossen sind. In jeder Iteration wird der gesamte Zyklus von Analyse bis zu

abschließenden Tests durchlaufen. Je nach Projektstand werden die Aktivitäten in

unterschiedlicher Intensität ausgeführt. Bei frühen Iterationen liegt die Konzentration auf die

Erarbeitung einer gemeinsamen Vision vom zukünftigen System und vom Entwurf einer

7

ersten Lösungsvariante. In den späteren Phasen stehen spezifizierte Komponenten und

abschließende Systemtest im Vordergrund.

Laut der Studie aus dem Jahr 2000 „Analyse und Evaluation der Softwareentwicklung in

Deutschland“, entwickelt ungefähr die Hälfte aller softwareproduzierenden Unternehmen in

Deutschland nach einem definierten Vorgehensmodell. „Überwiegend handelt es sich dabei

um unternehmenseigene Vorgehensmodelle.“ Allerdings lehnen diese sich in ihren

Grundzügen an klassische Modelle der sequentiellen oder iterativen Entwicklung an. Für

Deutschland werden der RUP (Rational Unified Process) und das V-Modell als wichtigste

Prozessmodelle in der Softwareentwicklung genannt. [GFK00]

3.1 Wasserfallmodell

Das Wasserfallmodell war das erste Modell welches zur systematischen Beschreibung eines

kompletten Softwareentwicklungsprozesses erstellt wurde. Es ist auch die Basis der später

entwickelten Modelle, da diese auf die Elemente des Wasserfallmodell zurückgreifen, wieder

verwenden, abwandeln oder in anderer Form beschreiben und nutzen. [VER00, S. 70]

Das Wasserfallmodell greift auf die Entwicklungen von Winston Royce zurück. Die

Entstehung der rein sequenziellen Abfolge war jedoch so nicht geplant und beruhte auf einem

Missverständnis. Das Modell sollte mit einer signifikanten Prototypenphase starten um die

Kerntechnologie und die Bedürfnisse der Stakeholder zu erkennen. Das amerikanische

Verteidigungsdepartment hat jedoch nur den heute allgemein als Wasserfallmodell bekannten

Teil zum Standard erklärt. [SÄF10, S. 346]

Im Wasserfallmodell werden die Aktivitäten in einer streng vorgegebenen Reihenfolge

ausgeführt. Das Ende jeder Aktivität wird durch ein fertiggestelltes Dokument festgelegt und

damit die die nächste Aktivität eingeleitet. Man spricht daher von dokumentengetrieben. Das

Wasserfallmodell basiert auf einem Top-Down-Vorgehen. Die Aufgaben und Phasen des

Modells sind eindeutig dargestellt. Es ist daher einfach zu planen und leicht zu managen. In

der Konzept- und Analysephase werden die Anforderungen erhoben und das Endsystem als

Blackbox spezifiziert. Die Abklärung von technischen Rahmenbedingungen wird jedoch erst

in der Designphase durchgeführt. Risiken und falsche Annahmen werden daher erst sehr spät

erkannt. Im Hinblick auf nachträgliche Änderungen ist das Modell unflexibel und träge.

[SÄF10, S. 346]

Das Wasserfallmodell entspricht einem ingenieurmäßigen Vorgehen bei der

Projektabwicklung. Für den Erfolg des nach Wasserfallmodell durchgeführten Projektes ist

entscheidend, dass von Anfang an alle Anforderungen feststehen und keine Änderungen mehr

zugelassen werden. [VER00, S. 28]

Ein Kernrisiko für das Scheitern von Softwareentwicklungsprojekten sind jedoch

Anforderungsänderungen. Da sich während eines laufenden Projektes Kundenanforderungen

häufig ändern oder Technologiewechsel stattfinden, werden aktuell immer weniger Projekte

nach dem Wasserfallmodell abgewickelt werden. [FÜR11, S. 45]

8

Die fehlende Möglichkeit sich an eine Lösung oder einen Lösungsweg heranzuarbeiten

kennzeichnet die Schwäche des Wasserfallmodells. Das Modell ist daher eher für einfache

oder komplexe Projekte mit geringen Anforderungsänderungen und Planungsunsicherheiten

geeignet.

3.2 Spiralmodell

Das Spiralmodell als ein Vertreter des evolutionären Vorgehens, wurde 1988 von B. W.

Boehm entwickelt. Im Spiralmodell werden alle Phasen der Entwicklung einmal durchlaufen

um ein erstes Modell einen Prototypen zu erstellen. Im zweiten Durchlauf wird die

Entwicklung verfeinert. Das Spiralmodell verfolgt einen risikoorientierten Ansatz. Es ist

risikogetrieben, was bedeutet, dass mit jedem Durchlauf ein spezifiziertes Risiko analysiert

und in Bezug auf das fertige Produkt entsprechend umgesetzt wird. Das Spiralmodell setzt

bereits in frühen Phasen auf Prototypen. Das Modell nutzt die Simulation und die

Verwendung von Modellen. Mit jedem Zyklus wird die Implementierung erweitert, um im n-

ten Durchlauf von einem Detail Design zum Operativen Prototypen über durchzuführende

Tests zum fertigen Produkt zu kommen. [SÄF10, S. 348ff].

Abbildung 1: Darstellung des Spiralmodells

(Quelle: Online-Studienmodul Softwaretechnik, Beuth-Hochschule für Technik Berlin)

Zu Beginn eines Durchlaufs sind die benötigten Ressourcen und verbleibenden Risiken

schwer abzuschätzen. Das Spiralmodell ist mit einem generischen Ansatz vergleichbar, es

steuert und entwickelt sich von Risiko zu Risiko und verzichtet auf eine umfassende

Spezifikation. Die fehlende Steuer- und Vorhersagbarkeit führen zum Nachteil des

Spiralmodells. [SÄF10, S. 349]

Der Grundgedanke des Spiralmodells, in mehreren Durchgängen das zu entwickelnde

Endprodukt schrittweise zu verfeinern und dabei die Risiken zu adressieren gilt als

Grundstein für die iterativen, inkrementellen Vorgehensmodelle, wie dem Rational Unified

Process (RUP). Vor allem die agilen Methoden greifen die Grundidee des Spiralmodells auf

und bauen diese Idee in den agilen Ansatz ein. [SÄF10, S. 349]

9

3.3 V-Modell und V-Modell XT

Das V-Modell „existiert in seiner ersten Version seit 1992 und wird seitdem im öffentlichen

Bereich als Standard für die Softwareentwicklung eingesetzt“ [VER00, S. 32]. Seit 1996 gilt

es als verbindlich einzusetzende Vorschrift für die standardisierte Durchführung von

Projekten des Bundesinnenministeriums. Es ist wie das Wasserfallmodell

dokumentenzentriert und beschreibt Sequenzen von Aktivitäten, die durch bestimmte

Auftraggeber oder Leistungserbringer auszuführen sind. Das V-Modell gliedert sich in ein

dreistufiges Standardisierungskonzept mit den Ebenen Vorgehen (Wann), Methoden (Wie),

Werkzeuge (Womit). Hier wird eine Folge von Aktivitäten und deren Ergebnissen

beschrieben. Die Aktivitäten werden in die vier Tätigkeitsbereiche Systemerstellung,

Projektmanagement, Konfigurationsmanagement und Qualitätssicherung gegliedert. [IAB10]

Das V steht für eine hierarchische Ordnung die stufenweise, vertikal vom Konzept zur

Implementierung führt und von dort aus über Tests bis hin zur Abnahme geht. Die erzeugten

Artefakte und Ergebnisse werden stufengerecht überprüft. Jede Stufe verfeinert die

Spezifikation und den Lösungsentwurf der vorangehenden Ebene. Horizontal findet eine

stufenweise Validierung der Ergebnisse der gegenüberliegenden Seite statt. Das V-Modell ist

ein sehr umfangreich beschriebenes Modell, was eine umfangreiche Anpassungsmöglichkeit

an verschiedene Projekte und Projekttypen ermöglichen soll. Diese Anpassung wird als

„Tailoring“ bezeichnet. [SÄF10, S. 347f]

Abbildung 2: Darstellung des V-Modell XT

(Quelle: msdn - microsoft.com - Team Foundation Server)

[IAB10] Seit 2006 existiert eine überarbeitete und ergänzte Fassung als V-Modell XT. Das

XT steht für „Extreme Tailoring“. Da die Vorgängerversion durch die Weiterentwicklung von

Methoden und Technologien den aktuellen Anforderungen nicht mehr in geeigneter Weise

Rechnung trug. Dies führte dazu, dass das V-Modell im Jahr 2004 nicht mehr im

gewünschten Umfang genutzt wurde. Das V-Modell XT geht dabei von Inhalt und Umfang

der Vorgängerversion V-Modell 97 aus und erweitert dieses v.a. um verbesserte

Möglichkeiten in der Anpassung. In der aktuellen Fassung des V-Modells XT wird explizit

auf die Möglichkeiten von Iterationen hingewiesen und gefordert. Diese Iterationen sollen die

10

Anforderungen durch Prüfen auf Vollständigkeit und Korrektheit, analysieren, bewerten und

durch das Setzen von Prioritäten ständig verfeinern und verbessern.

Das V-Modell XT findet im Vergleich zu seiner Vorgängerversion in der Literatur noch

relativ geringe Beachtung.

3.4 Rational Unified Process (RUP)

Der Rational Unified Process (RUP) ist ein Modell des iterativen-inkrementellen Vorgehens.

Der RUP ist ein rein objektorientiertes Prozessmodell, was ein Vorteil im objektorientierten

Ansatz gegenüber dem V-Modell mit sich bringt, da das V-Modell für die Verwendung

strukturierter Methoden entwickelt und nur in Richtung Objektorientierung erweitert wurde.

Der Rational Unified Process zeichnet sich dadurch aus, dass nach jeder Iteration eine

Integration der entwickelten Teilergebnisse erfolgt [VER00, S. 61].

Der RUP gestaltet sich über die verschiedenen bereits genannten Softwareentwicklungsstufen,

die jedoch nicht sequentiell, sondern parallel über die vier Phasen ablaufen:

Konzeptualisierungsphase (Inception), Entwurfsphase (Elaboration), Konstruktionsphase

(Construction), Übergangsphase (Transition). Die Phasen selbst werden zeitlich

aufeinanderfolgend definiert und enthalten eine oder mehrere Iterationen [VER00, S. 39].

Abbildung 3: Darstellung der Phasen im RUP

(Quelle: IBM/Rational Software)

Am Ende jeder Phase befindet sich ein Meilenstein. Dieser ist nach qualitativen Kriterien zu

erfüllen. Nur bei Erfüllung darf die nächste Phase begonnen werden. Die Phasen sind in

11

Iterationen von 4-6 Wochen unterteilt. Für diese Iterationen sind messbare Ziele wie

ausführbare und testbare Software zu definieren. Beim RUP wird eine maximale

Projektlaufzeit von 18 Monaten empfohlen, alles was darüber hinausgeht soll auf mehrere

Projekte verteilt werden. [DIR11, S. 173f]

Das Risikomanagement bezieht sich beim RUP auf technische Risiken und Risiken im

Kontext bezüglich der richtigen Lösung. In der Konzeptualisierungsphase soll als Hauptziel

eine Vision erarbeitet werden. Ein Team soll die Bedürfnisse der Stakeholder, in diesem Falle

sind die Kunden, Benutzer bzw. Auftraggeber gemeint, und die wichtigsten Eigenschaften des

Endproduktes erarbeiten und dokumentieren. Die mit den Stakeholdern erzielte Einigkeit in

dieser Phase soll das Risiko minimieren, dass die erstellte Lösung am Ende des Projekts nicht

akzeptiert wird. In der Entwurfsphase soll eine ausführbare und testbare, eine sogenannte

verifizierbare Architektur erstellt werden. Als Ausgangspunkt hat das Team die Vision aus

der Konzeptualisierungsphase und verfeinert die Anforderungen mit Anwendungsfällen. Die

Vision kann dabei auch weiter aktualisiert werden. Am Ende dieser Phase steht beim RUP

eine Lösung, die inhaltlich und technisch zumindest im Groben bekannt ist und auf

Richtigkeit überprüft und mit den Beteiligten vereinbart werden kann. [DIR11, S. 173f]

Die Konstruktionsphase zielt nun auf die Umsetzung der Anforderungen. Die in der

Entwurfsphase in der Architektur erzielten Use-Cases werden auf Iterationen in 4-6 Wochen

aufgeteilt und dann nacheinander, sich ergänzend implementiert. Dieses Verfahren wird als

inkrementell bezeichnet. In der Konstruktionsphase werden die Anforderungen aus der

Entwurfsphase weiter verfeinert, Algorithmen und Datenstrukturen entwickelt,

Testumgebungen werden erweitert und verbessert. Am Ende dieser Phase gibt es ein fertig

implementiertes Produkt. In der letzten Phase, der Übergangsphase, wird das Produkt in den

Betrieb überführt. [DIR11, S. 173f]

3.5 Agile Modelle

Als eine Gegenbewegung zu den traditionellen und formalen Prozessen, entstanden

Vorgehensmodelle, die sich durch kurze Iterationszyklen, eine Nähe zum Auftraggeber und

ein Minimum an Dokumentation kennzeichneten. Hier stehen die beteiligten Personen und

das Endprodukt im Vordergrund nicht mehr der Prozess. Agilität fordert eine Fokussierung

auf eine lauffähige Software. Zwischenprodukte die dahin führen, wie Dokumente und

Modelle sollen reduziert werden. Agile Methoden passen sich den jeweiligen Gegebenheiten

an, dies wird als evolutionär und adaptiv bezeichnet. Die bewusste räumliche Nähe von den

beteiligten Personen, die gefordert wird, sollen die Kommunikationsdefizite ausräumen und

einen Großteil der Dokumentation von plangetriebenen Prozessen überflüssig machen.

[SÄF10, S. 353f]

3.5.1 Das Agile Manifest

[AGI01] 2001 wurde von 14 führenden unabhängigen Software-Ingenieuren in Utah das

Agile Manifest erdacht und verfasst. Es bricht mit den Prinzipen der traditionellen

Softwareentwicklung. Das agile Manifest umfasst vier Prinzipien:

12

Individuen und Interaktion sind wichtiger als Prozesse und Tools.

Funktionierende Software ist wichtiger als überbordende Dokumentation.

Enge Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

Auf Änderungen reagieren ist wichtiger, als einem Plan zu folgen.

Die Formulierungen sind sehr genau zu nehmen. Die jeweils erst genannten Werte, auf der

linken Seite, werden höher eingeschätzt als die auf der rechten Seite. Was allerdings nicht

bedeutet, dass die anderen Dinge unwichtig oder überflüssig wären.

[DIR11, S. 11] Die agilen Vorgehensmodelle setzen die Prinzipien des agilen Manifests um.

Dies zeigt sich in folgenden Punkten:

Es gibt keine Arbeitsteilung mittels Disziplin, im Vordergrund steht das gemeinsam

arbeitende Team. Einen sequenziellen Prozess mit definierten genau zu folgenden Schritten

gibt es nicht. Der Kunde ist der Einzige, der Qualität und Ziellerreichung des Produkts

beurteilen kann. Der Kunde muss daher eng in dem Entwicklungsprozess integriert werden.

Der Planungshorizont wird stark verkürzt um schnelleres Feedback und regelmäßige

Berücksichtigung von Änderungen zu ermöglichen. Der verkürzte Planungshorizont ist den

Risiken der Komplexität im Entwicklungsprozess geschuldet.

3.5.2 Extreme Programming (XP)

Extreme Programming (XP) wurde von Kent Beck, Ward Cunningham und Ron Jeffries

entwickelt. Es gilt als eines der bedeutsamsten Vertreter von agilen Vorgehensmodellen

[ARN09, S. 11]. Kommunikation, Einfachheit in der Lösung, Feedback geben, Mut die Dinge

beim Namen zu nennen und Respekt gegenüber Kollegen und Mitmenschen sind die

Grundwerte auf denen Extreme-Programming basiert [SÄF10, S. 383].

Abbildung 4: Darstellung des Extreme Programming Modells

(Quelle: http://www.extremeprogramming.org)

13

[SÄF10, S. 383f] XP setzt auf Praktiken, die sich bewährt haben, deren Befolgung jedoch

nicht zwingend ist. Schwerpunkte hierbei sind:

User Stories, sie erfassen die Anforderungen des zu erstellenden Projektes. Pair

Programming, ein Vorgehen, das den Wissenstransfer steigert. Dabei sitzen jeweils zwei

Entwickler zusammen und entwickeln gemeinsam. Kunden werden in den

Entwicklungsprozess eng eingebunden. Testgetriebene Entwicklung ermöglicht Lücken in der

Anforderung bereits vor der Implementierung zu erkennen. Durch einfaches Design soll

vermieden werden unnötige Features zu implementieren. Kurze Iterationen ermöglichen den

Kunden in regelmäßigen Zeitabständen einen Projektstand zu liefern. Refactoring und

Fortlaufende Integration.

Unter Refactorierung ist die systematische Verbesserung der Struktur eines Softwaresystems

unter gleichzeitiger Beibehaltung seiner Funktionalität gemeint. Martin Fowler entwickelte

den Ansatz zur Codestrukturierung, er stellte fest, dass Softwaresysteme durch die

zahlreichen Änderungen, Anpassungen und Erweiterungen im Entwicklungsprozess eine

unüberschaubare und chaotische Struktur annahmen [FOW05]. Die Folge dieser

undurchschaubaren Programmstruktur ist ein erhöhtes Risiko im Bereich der Integration und

der Erweiterbarkeit des Softwaresystems.

Die Fortlaufende Integration schließt sich dieser Risikoorientierung an. Durch fortlaufende

und vor allem frühzeitige Integration sollen Fehler im Zusammenspiel von einzelnen

Komponenten frühzeitig aufgedeckt werden, da zu einem frühen Zeitpunkt Korrekturen noch

mit einem geringeren Aufwand durchgeführt werden können. Jede Integration soll eine

lauffähige Version des Softwaresystems zum Ergebnis haben. [ARN09, S. 11ff]

Extreme Programming wird vor allem für kleinere und mittlere Projekte empfohlen mit

maximal 15 Entwicklern [ARN09, S. 15].

3.5.3 Scrum

[SWA02] Scrum zählt zu den Prozessmodellen der agilen Softwareentwicklung. Entwickelt

wurde Scrum von Ken Schwaber, Jeff Sutherland und Mike Beedle. Scrum hat seine

Schwerpunkte in den Managementtechniken. Praktiken zur eigentlichen Software

Entwicklung enthält es keine. Diese werden bei Scrum dem Team überlassen. Das Team und

mit ihm die einzelnen Personen stehen bei Scrum im Fokus. Scrum besteht aus einer von 30

Tagen dauerenden Iteration, den sogenannten Sprints. Zu Beginn eines Sprints wird der

Umfang festgelegt der in dieser Iteration entwickelt werden soll. Das Ergebnis soll in einer

neuen lauffähigen Version vorliegen, die dem Kunden ausgeliefert werden kann. Das geplante

Ziel des Sprints wird während der Laufzeit eines Sprints nicht geändert.

Alle Anforderungen eines Projektes werden in dem sogenannten Produkt Backlog aufgeführt.

Der Produkt Backlog ist eine priorisierte Liste die die Anforderungen aufführt und den dafür

eingeplanten Aufwand enthält. Der Produkt Backlog kann von jedem Projektbeteiligten

14

eingesehen werden und jeder Projektbeteiligte kann Anregungen zur Aufnahme neuer

Anforderungen geben. Anforderungswünsche können sehr vage formuliert sein, je

priorisierter die Anforderung ist desto detaillierter sollte sie aber beschrieben sein. Die

Dynamik eines Projektes spiegelt sich in dieser Liste wieder und fängt sie damit auch auf, da

sich die Anforderungen eines Produktes während seiner Entwicklung meist ändern.

Zu Beginn eines Projektes sollte die Liste mindestens so viele Anforderungen enthalten, dass

diese einen ersten Sprint rechtfertigen. Weiterhin ist im Produkt Backlog festgehalten welche

Probleme vor der Entwicklung bestimmter Elemente gelöst werden müssen. Diese Probleme

werden im Laufe der Entwicklung entweder in reguläre eigenständige Anforderungen des

Projektes umgewandelt oder in einzusetzende Technologien umgewandelt.

Der Product Backlog wird vom Product Owner verwaltet. Der Product Owner entscheidet

über Aufnahme in den Backlog und Priorisierung im Backlog, er hat auch die Aufgabe

sinnlos gewordene Anforderungen zu entfernen. Product Owner und Team legen zusammen

fest welche Elemente im nächsten Sprint erledigt werden. Der Product Owner ist eine

Schnittstelle von Kundenbedürfnissen und dem konkreten Produkt-Konzept.

Weiterhin gibt es noch einen Scrum Master, eine eigens für Scrum entwickelte Management

Rolle. Er ist dabei nicht für Zeit-, Kosten-, und Personalmanagement zuständig. Diese

Aufgaben übernimmt der Product Owner in Zusammenarbeit mit dem Team. Der Scrum

Master ist dafür verantwortlich, dass das Team erfolgreich zusammenarbeitet. Der

Grundgedanke dabei ist „Dienen statt Führen“. Der Scrum Master ist die Schnittstelle

zwischen Management und Team, er soll das Team während der Sprints von Einflüssen von

außen abschirmen und er ist für die Einhaltung der grundsätzlichen Scrum-Regeln

verantwortlich.

Abbildung 5: Darstellung eines Scrum Prozesses

(Quelle: http://microtool.de)

15

Eine wichtige Regel ist dabei das Daily Scrum. Ein tägliches Meeting des Teams, bei dem

jedes Mitglied kurz Auskunft gibt, was es seit dem letzten Meeting getan hat, was es dabei

eventuell behindert hat und was es sich bis zum nächsten Daily Scrum vorgenommen hat.

3.6 Kombinationen

Da Scrum sich mehr auf die Management Methoden im Entwicklungsprozess ausrichtet, ist es

auch mit anderen Modellen kombinierbar. So wird es bei agilen Entwicklungspraktiken mit

Extreme Programming versucht. Es zeigte sich, dass sich die Methoden dabei gut ergänzen.

Das Planning Game von XP und das Sprint Planning Meeting (Scrum) führt zwar dabei zu

einer Überschneidung, die jedoch vernachlässigt werden kann. Ein Kombinationsbeispiel sind

die User Stories von XP, die als Backlog Element für den Product Backlog in Scrum

eingesetzt werden können. [INF02]

Auch eine Kombination von V-Modell XT mit Scrum wird praktiziert. Damit wird versucht

bei öffentlichen Aufträgen, wo der Einsatz des V-Modells vorgeschrieben ist, agile Methoden

zu integrieren. Das V-Modell XT gibt einem diese Freiheiten in seinen Tailoring Ansätzen

[LEW].

4. Risikoorientierung in der Software-Entwicklung

Absolute Sicherheit und absolute Qualität sind mit endlichen Ressourcen nicht realisierbar.

Daher wurden die Methoden des Risikomanagement entwickelt, um ein gewisses Maß an

Sicherheit und Qualität zu gewährleisten. Risikobehaftung wird als grundsätzliches Merkmal

von Projekten gesehen. Dies wird dadurch bedingt, dass durch Komplexität, Umfang und

Innovationsgehalt des Projektvorhabens auf Risiken bei dessen Durchführung geschlossen

werden darf. [GAU04, S.6]

In einem Risikomanagementsystem bauen dabei die Elemente ineinander auf und

beeinflussen sich gegenseitig. Die vier wesentlichen Elemente eines allgemeinen

Regelkreislaufs in einem Risikomanagementsystem sind: Risikoidentifikation, Risikoanalyse

und –bewertung, Risikokommunikation und Risikoüberwachung. [GAU04, S. 7ff]

Das Risikomanagementsystem in der Software-Entwicklung baut auf diese vier Elemente auf.

Der hierfür verwendbare Kreislauf besteht aus fünf Schritten: Projektrisiken erkennen und

beurteilen, Projektkontrollen aufnehmen und beurteilen, verbleibende Projektrisiken

analysieren, Maßnahmen bewerten und umsetzen, Projektrisiken und –maßnahmen

überwachen. [GAU04, S. 55f]

Ein wichtiger Unterschied zum Standard Risikomanagement-Kreislauf ist die klare Trennung

von Risiken und Kontrolle. Diese Vorgehensweise ermöglicht ein effizientes Vorgehen in der

Risikoanalyse bei der Softwareentwicklung. Ziel ist es die Anzahl der verbleibenden

Projektrisiken, die einer genaueren Überwachung bedürfen gering zu halten. Außerdem gilt es

mit Hilfe dieser Elemente alle Maßnahmen ergreifen zu können, um vorausschauend Risiken

im Umfeld des Projekts zu erkennen, gleichzeitig die Eintrittswahrscheinlichkeit und die

16

Auswirkungen beurteilen zu können und dabei diese Risiken laufend zu kommunizieren

sowie bei Bedarf geeignete Gegenmaßnahmen einzuleiten und permanent zu überwachen.

[GAU04, S. 56]

4.1 Definitionen

Der strukturierte Umgang mit Risiken wird als Risikomanagement bezeichnet. Allgemein

wird Risikomanagement in DIN 62198 definiert als „systematische Anwendung von

Managementgrundsätzen, -verfahren und -praktiken zwecks Ermittlung des Kontexts sowie

Identifikation, Analyse, Bewertung, Steuerung/Bewältigung, Überwachung und

Kommunikation von Risiken“. In der DIN 69905 wird Risikomanagement als „Ausschaltung,

Vermeidung oder Verringerung von Projektrisiken“ definiert. Gaulke definiert

Risikomanagement wie folgt „Aus betrieblicher Sicht umfasst Risikomanagement alle

systematischen Maßnahmen zur rechtzeitigen Erkennung, Bewertung und Bewältigung von

potentiellen Risiken. Risikomanagement soll die Unternehmensführung unterstützen,

wesentliche Risiken, die den Unternehmenserfolg oder –bestand gefährden können,

rechtzeitig zu erkennen und zu bewältigen.“ [GAU04, Seite 6].

Risikomanagement besteht nach Balzert aus sechs Schritten: Risiko-Identifikation, Risiko-

Analyse, Risiko-Prioritätenbildung, Risiko-Managementplanung, Risiko-Überwindung,

Risiko-Überwachung [BAL98]. Anhand von Checklisten können diese Risiken identifiziert

und projektbezogen spezifiziert werden.

Für eine Risikoanalyse werden die Eintrittswahrscheinlichkeit und die Folgekosten bei Eintritt

abgeschätzt. Daraus lässt sich der Risikofaktor ableiten:

Risikofaktor = Eintrittswahrscheinlichkeit * Folgekosten

Der Risikofaktor ist ein hilfreiches Element die Risiken zu sortieren und damit die Prioritäten

fest zu legen. Der Risikomanagementplan wird zur Kontrolle der notwendigen Aktivitäten zur

Risikominimierung eingesetzt. Mit Risikoüberwindung ist die tatsächliche Ausführung dieser

Aktivitäten gemeint.

4.2 Risiken in der Softwareentwicklung

Die typischen Risiken einer Software-Entwicklung sind:

Personelle Defizite, Unrealistische Termin- und Kostenvorgaben, Entwicklung von falschen

Funktionen und Eigenschaften, Entwicklung der falschen Benutzerschnittstelle, „Vergolden“

– Realisierung nicht geforderter Features, Kontinuierliche Anforderungsänderung, Defizite

bei extern gelieferten Komponenten, Defizite bei extern gelieferten Aufträgen, Defizite in der

Echtzeitleistung, Überfordern der Software-Technik [ARN09, S. 22].

[SÄF10, S. 370] Schäfer teilt die Risiken in die einzelnen Phasen der Software-Entwicklung

auf: Risiken in der Konzeptphase entstehen bei der Abschätzung des Gesamtaufwands oder in

Unstimmigkeiten unter den Stakeholdern. Im Entwurf sind Risiken auf die technische

17

Machbarkeit, einer funktionsfähigen Architektur und der Umsetzung innerhalb des zeitlichen

und finanziellen Rahmens adressiert. Im Bereich der Konstruktion sind alle Risiken der

Erstellung einer lauffähigen Konstruktion angesiedelt. Im Übergang werden die Risiken beim

Wechsel von Betaversion zur Auslieferung des fertigen Produkts geführt.

4.3 Minimierung von Risiken in den verschiedenen Vorgehensmodellen

Bei Risiken wird von Risikenminimierung gesprochen und nicht von Risikovermeidung. Der

Begriff Risikovermeidung kann in Prozessen der Software-Entwicklung nicht verwendet

werden. Risiken müssen als gegeben betrachtet werden. Bei Gaulke ist Risikovermeidung nur

durch den vollständigen Abbruch des Projektes zu erreichen. [GAU04, S.185]

Die in den verschiedenen Vorgehensmodellen vorhandenen Projektsteuerungs- und

Kontrollverfahren sollen die Minimierung von Risiken sicherstellen. Die überschaubaren

Phasen in den Vorgehensmodellen sollen ein frühzeitiges Erkennen von nicht umsetzbaren

fachlichen und technischen Anforderungen sicherstellen. [GAU04, S.150f]

Welche Strategien und Methoden sind nun in den verschiedenen Vorgehensmodellen

berücksichtigt und wie Versuchen die Modelle diese Risiken zu minimieren?

4.3.1 Risikofaktor Personal

Die Minimierung des personellen Risikofaktors beinhaltet qualifizierte Mitarbeiter

einzustellen und die Teams richtig zusammen zu stellen und dabei den Grad an Zielvorgaben

fest zu legen. Ein Auftraggeber kann eine strategische Ausrichtung im Team verankern,

indem er entsprechende Zielvorgaben wie Zeit, Budget, Qualität und Funktionsumfang macht

[DIR11, S. 197].

Ein Beispiel ist Design-to-Cost, was ein festes Budget mit akzeptabler Qualität und genügend

Funktionalität bedeutet. Wenn diese Vorgaben falsch gesetzt werden, indem zum Beispiel

zwei Ziele maximiert werden, dann trägt das Entwicklungsteam diesen Konflikt aus. Auch

kann ein zu enger Zeitrahmen einen Zeitdruck erzeugen, der keinen Raum für

Weiterentwicklung lässt, was wiederum eine Verschlechterung der Qualität des Ergebnisses

nach sich zieht.

Scrum ist eines der Modelle das diesen Punkt aufgreift. Bei Scrum legt nicht die Aufgabe den

Druck auf das Team, sondern das Team verpflichtet sich, die Aufgabe in einem selbst

geschätzten Aufwandsrahmen zu entwickeln.

Es sollte bei Beachtung der Risiken von personellen Defiziten beachtet werden, dass der

Prozessablauf beim V-Modell klar gegeben und schnell erfassbar ist, während iterative

Modelle wesentlich komplexere Modelle sind und damit auch eine höhere Anforderung an

das Prozess-Know-How der Beteiligten stellt.

Auch setzt Scrum ein Team mit bereits sehr gut entwickelten Teameigenschaften voraus. Dies

ist nicht überall oder in vielen Fällen gar nicht gegeben und muss erst aufgebaut werden. Der

18

Daily Scrum ist ein Beispiel dafür. In der Praxis wird in vielen Fällen ein tägliches Meeting

abgehalten, meist streben diese Meetings aber eher in die Richtung Reporting oder zu

Rechtfertigungsübungen.

4.3.2 Risikofaktor Projektumfang

Der Projektumfang in Bezug auf Entwicklungslaufzeit und Funktionsumfang gilt als größter

Risikofaktor für Softwareprojekte. Zu diesem Punkt zählen Risiken aus den oben genannten

Bereichen der unrealistischen Termin- und Kostenvorgaben, Entwicklung von falschen

Funktionen und Eigenschaften, Überforderung der Softwaretechnik, Kontinuierliche

Anforderungsänderungen und die Realisierung nicht geforderter Features.

Nach einer empirischen Studie von T. Capers Jones steigt die Abbruchwahrscheinlichkeit

überproportional mit zunehmender Funktionalität der zu realisierenden Software. [CAP98]

„Je länger die Entwicklungsarbeit dauert, desto schwieriger wird es, eine produktive

Anwendung mit den erwarteten Erträgen zu realisieren“ [OEC04, S. 3]

Oechtering stellt die Projektrealisierungsrisiken anhand einer Grafik dar:

Abbildung 6: Projekt-Realisierungsrisiko in Abhängigkeit von

Zielunklarheit und Planungshorizont [OEC04]

Man erkennt, dass unklare Ziele bei kurzen Planungshorizont oder Funktionsumfang

vertretbar sind. Anders verhält es sich, wenn der Planungshorizont oder der Umfang zu

nehmen. In der Praxis kommen jedoch langer Planungshorizont und ungenaue Zielvorstellung

meist zusammen [OEC04]. Dabei ist es unerheblich woher diese Probleme kommen.

19

Hier setzen die iterativ-inkrementellen und agilen Vorgehensmodelle an. Ein agiles Team

strebt die minimale notwendige Komplexität der Lösung an. Nach einer Iteration soll ein

entwickeltes Produktinkrement stehen, das benutzbar ist. Das Produktinkrement soll inklusive

Benutzerhandbuch, Installationsanweisung und Testumgebung erstellt sein. Dadurch gibt es

einen kürzeren Planungshorizont und kleineren Funktionsumfang und damit ein minimiertes

Risiko. Auch die Zielsetzung, nach maximal vier Wochen ein Inkrement erstellt zu haben,

zielt zusätzlich darauf, ein Ziel als geringer veränderlich umzusetzen. [DIR11, S. 188]

In iterativ-inkrementellen Modellen wird fortlaufend geplant. Erfahrungen aus früheren

Iterationen werden eingesetzt um weitere Planungen zu verfeinern. Bei reinen linearen

Vorgehensmodellen wie auch beim V-Modell liegt der Hauptansatz der Planung im Vorfeld

der Entwicklung. Die oben beschriebenen Risiken sollen also im Vorfeld der Entwicklung

bereits definiert und mittels Planung und den damit verbundenen Dokumentationsrichtlinien

minimiert werden. Dies ermöglicht für den Kunden und für das Management auch eine

ständige Kontrolle der Einhaltung des Entwicklungsfortschritts. Dieser Ansatz kann auch zum

Erfolg führen und die oben genannten Risiken minimieren, aber nur in dem Umfang in dem

kaum Anforderungsänderungen auftreten. Als Beispiel kann man hier Wartungsarbeiten,

bestimmte Erweiterungen an bestehenden Systemen oder wirklich überschaubare

Entwicklungen, die in einem engen Zeitrahmen stattfinden aufzählen.

Bei großen Projekten setzen die agilen Modelle dabei auf eine Zerlegung der komplexen

Probleme in weniger komplexe Teilprobleme. Lineare Vorgehensweisen und der RUP

betrachten die zu liefernde Lösung immer als Ganzes. Lineare Modelle bleiben auch während

der gesamten Entwicklung bei diesem Verfahren. Im RUP wird eine Vision für die

Komplettlösung erstellt und dann diese Lösung in funktional unabhängige Teile zerlegt.

4.3.3 Risikofaktor Anforderungsänderungen

[DIR11, S. 182f] Es gibt kaum ein Projekt dass es vermeiden kann, sich veränderten

Situationen anzupassen. Es benötigt einen gewissen Grad an Evolution. Evolution ist hier

gemeint mit fortlaufender Weiterentwicklung und stückweise eine vordefinierte Lösung zu

bauen. Dabei auch bereits entwickelte Abschnitte später zu überarbeiten. Dies kann auch eine

kontrollierte Evolution sein. Kontrolliert bedeutet in diesem Fall, dass das Team in bewussten

Schritten vorgeht, die das vorhandene Wissen über die Lösung oder den Zusammenhang des

Kontexts nicht übersteigt. Zum Beispiel, wenn eine Aufgabe ansteht, deren Lösung noch

unklar ist oder die eine große Veränderung im Kontext nach sich zieht oder deren Kontext

sich fortlaufend wandelt.

Die agilen Modelle entsprechen am ehesten dem evolutionären Gedanken. Nach jeder

Iteration wird bis zum Testing vorgegangen und mit möglichst kurzen Releasezyklen die

Benutzung erreicht. Die erarbeitenden Ergebnisse können bei Bedarf auch wieder geändert

werden. Das oben beschriebene Refactoring zählt zu diesen Methoden.

20

Beim RUP ist Evolution nur in Ansätzen möglich. Hier sind Änderungen nur im Rahmen der

zuvor vereinbarten Vision möglich. Eine Überarbeitung von Funktionalität und Design sind

während der Konstruktionsphase nur beschränkt möglich.

In linearen Modellen ist Evolution nur in sehr kleinen Details möglich. Hier wird davon

ausgegangen, dass das Endprodukt vor der Entwicklung spezifiziert ist.

4.3.4 Risikofaktor Kunde

In den traditionellen Vorgehensmodellen spielt der Kunde hauptsächlich während der

Analysephase und der Abnahmephase, also zu Beginn und am Ende des

Entwicklungsprozesses eine Rolle. Mindestens vier der oben genannten Risiken in der

Softwareentwicklung sind aber direkt mit dem Kunden behaftet. Daher stellt eine geringe

Involvierung des Kunden während des eigentlichen Entwicklungszeitraums ein enormes

Risiko dar. [KIR01]

XP versucht dieses Risiko zu minimieren, in dem es den On-Site-Customer fordert. Ein vom

Kunden ernannter Vertreter wird in das Entwicklungsteam integriert, er arbeitet mit dem

Entwicklungsteam vor Ort und im gleichen Raum mit den Entwicklern [KIR01]. Eine

Hauptaufgabe des Vorortkunden ist bei der Steuerung des Entwicklungsprozesses zu helfen.

Schnelle Feedbacks über aktuelle oder geplante Richtungsänderungen sind so möglich.

[KIR01]

Allen Vorgehensmodellen gemeinsam ist, dass das Projektteam die Stakeholder, also die

Gruppen, die an der Fertigstellung eines qualitativ hochwertigen Endprodukts interessiert

sind, einzubeziehen. Dies gelingt durch ständiges Anfordern von Informationen und

Feedbacks. Dafür werden Zeitpunkte definiert, wann dies zu erfolgen hat. Lineare Prozesse

holen Feedbacks am Ende einer Phase von den dafür definierten Personen ein. Dabei wird ein

Review der erstellten Ergebnisse, meist in Form von Dokumenten erstellt. Hier entsteht ein

Problem was den Risikofaktor Kunde ausmacht: Die Rückmeldung von Kundenseite erfolgt

nicht oder erst verspätet. Die Rückmeldung erfolgt unter Zeitdruck. Der Zeitdruck wird auf

die Personen weitergereicht, die die erstellten Review-Dokumente prüft, wodurch die

Aussagekraft von dokumentenbasierten Reviews in der Aussagekraft nicht sehr zuverlässig

wird.

RUP geht hier einen Schritt weiter: In der Konstruktionsphase holen Teams Feedback nach

jeder Iteration mit Tests, ob das ausgeführt wurde, was mit dem Kunden vereinbart wurde.

Agile Modelle definieren von Anfang an Feedbacks. Als Schnittstelle wird der oben

beschriebene On-Site-Customer eingesetzt. Der Nachteil hierbei kann sein, dass dies

möglicherweise nur eine Person ist. Diese Person kann ausfallen, ersetzt werden oder nicht

mehr der geforderten Philosophie des Kunden entsprechen und damit zu einem erheblichen

Risiko im Bereich des Faktors Kunde führen. Abhilfe könnte hier eine Erweiterung durch

Usability Engineering, also benutzerzentrierte Vorgehenstechniken schaffen. Zum Beispiel

kann eine Feedbackschleife zwischen Benutzer und Entwicklungseinheiten eingebaut werden.

[RIC10]

21

4.3.5 Weitere Risikofaktoren

Risikofaktor Technologie

[GAU04, S.93] Projektrisiken im Bereich Technologie können im Zusammenhang mit der

Verwendung bestehenden Technik, wie zum Beispiel Risiken die sich aus der Komplexität

der technischen Bestandteile eines IT-Projektes ergeben. Ein weiterer wichtiger Risikofaktor

ergibt sich bei der Einführung neuer Technologien. Dies betrifft Risiken aus der Neuartigkeit

der Technologie und der Integration neuer Technologie in bestehende Bestandteile und

Infrastrukturen.

[GAU04, S.151ff] Technische Risiken können in den Planungstools der Vorgehendmodellen

aufgenommen werden. Es gilt hier die technische Umgebung für die Entwicklung ausreichend

zu dimensionieren um ein effizientes Arbeiten der Entwickler zu ermöglichen und die

Produktivität der Entwicklung nicht zu behindern. Dazu zählt zum Beispiel die Anzahl, die

Umgebung und Dokumentation der Entwicklerarbeitsplätze. Bei Projekten mit neuen

Technologien kann es notwendig sein, häufig die bisher verwendeten Entwicklungsmethoden

und –werkzeuge an neue Techniken und Technologien anzupassen und dabei flexibel

reagieren zu können. Dies muss bereits bei der Projektplanung berücksichtigt werden. Zur

Anwendung neuer Technologien gehört auch die Einplanung des daraus resultierenden

Weiterbildungsbedarfs. Die neuen Werkzeuge sollten vor Projektbeginn ausgiebig getestet

sein.

In den inkrementellen Methoden werden die vermuteten technischen Risiken bei den

Anwenderfunktionen in den ersten Inkrementen adressiert. Dies hilft um am Ende eines

Projektes vor unüberwindlichen technischen Problemen zu stehen. Probleme der Integration

können so in frühen Phasen erkannt werden, da frühzeitiger und häufiger integriert wird.

[OEC04]

Risikofaktor Architektur

Bei rein inkrementeller Vorgehensweise tritt ein Problem auf, wenn die Architektur mit der

Weiterentwicklung des Projektes nicht Schritt halten kann und die bisher erstellten

Inkremente komplett überarbeitet werden müssen. Sie haben damit den Status eines

Wegwerfprototyps. Dies sieht Oechtering allerdings wiederum als Vorteil, da dieser Prototyp

die verifizierten und auch validierten funktionalen Anforderungen auf dem konkretesten aller

Level sieht. [OEC04]

5. Fazit

Laut iSSE, Institut for Software & Systems Engineering, hat sich der relative Anteil der

erfolgreichen (20 – 25 %), problematischen (50 %) und total abgestürzten Projekte in den

letzten 40 Jahren nicht signifikant verschoben. Dem ist entgegenzuhalten, dass die

Softwareprojekte von heute wesentlich komplexer als vor 40 Jahren sind. Es kann auch

22

angenommen werden, dass dem Fortschritt in den Methoden einen Zuwachs von Komplexität

in den Methoden entgegensetzte. [iSE09, S. 5]

Die Risiken können in Risikoanalysen ziemlich gut identifiziert werden, Techniken zur

Minimierung der Risiken gibt es, die Vorgehensmodelle berücksichtigen die

Risikoorientierung und legen je nach Modell ihre Methoden auf die Minimierung von Risiken

fest.

Ein Paradigmenwechsel von den klassischen Modellen zu den Agilen hat allem Anschein

nach bereits eingesetzt. Die agilen Modelle werden in Fachartikeln bereits als Mainstream

bezeichnet [iXM10]. Nach einer Studie aus dem Jahr 2010 des Forrester Research können

Agile Softwareentwicklungsprozesse als „Mainstream“ bezeichnet werden. Die Analysten

konnten aber feststellen, dass es mehr eine Kombination aus agilen und nicht agilen

Methoden ist, die auf die organisatorischen Voraussetzungen in den Unternehmen abgestimmt

ist. 35 Prozent nutzen agile Methoden. Weitere 11 Prozent nutzen die iterative Praktiken aus

dem RUP und das Spiralmodell. Das in vielen Veröffentlichungen als nicht mehr

praxistaugliche klassische Wasserfallmodell wird noch von 8,4 Prozent der Befragten

eingesetzt. Insgesamt 30 Prozent gehen nach keinem der hier beschriebenen formalen

Modelle vor. Scrum wird als meist genutzte agile Methode genannt. [iXM10]

Die Vorgehensmodelle werden sich weiter entwickeln, im Bereich der Risikoorientierung

werden die Möglichkeiten noch lange nicht ausgeschöpft sein. Eine weitere Einbindung der

Benutzer, das Usability Engineering scheint dabei ein entscheidender Schritt zu sein. Eine

bessere Kombination der vorhandenen Modelle ist aber angebracht, mit dem Blick auf das

Projekt und die Menschen im Kunden- und im Entwicklungsbereich.

Die vorgestellten Modelle nehmen stets für sich heraus für alle Projekte geeignet zu sein. Der

Wettbewerb zwischen den Modellen aber zeigt in der Praxis, dass es offenbar noch nicht die

Allzweckwaffe im Vorgehensmodell zur Minimierung der Risiken und damit zu erfolgreicher

Software-Entwicklung gibt. Jedes Modell hat seinen Ansatz von Risikominimierung.

Der Paradigmenwechsel sollte also nicht ein kompletter Wechsel hin zu den agilen Modellen

sein, sondern hin zu den Kombinationen aus prozessorientierten und agilen Methoden. Nicht

die strengen Grenzen in den Philosophien der vorgegebenen Modelle einzusetzen, sondern

Möglichkeiten zur Einbindung weiterer Methoden suchen, wie stärker benutzerzentrierter

Methoden. und vor allem dabei nicht nur das Projekt, sondern auch die Umsetzbarkeit im

eigenen Team zu berücksichtigen.

Softwareentwicklung findet nicht in einem losgelösten Raum statt. Jedes Entwicklungsteam

steht in einem Kontext zu Auftraggebern, Benutzern und auch den Umweltbedingungen im

eigenen Umfeld. Dieser Kontext ist nicht statisch, er verändert sich ständig. Es gibt auch

keine Rezepte die immer funktionieren. Es gibt Erfahrungen, Prinzipen, Empfehlungen,

Fallstudien und vieles mehr, was helfen kann einen eigenen Entwicklungsprozess zu finden

und Risikoorientierung zu betreiben und damit für das jeweilige Projekt und das jeweilige

Team eine optimale Risikominimierung vorzunehmen. Eine vorgegebene Arbeitsweise sollte

23

nicht als statisch gesehen werden, sondern die eigene Arbeitsweise sollte kontinuierlich

hinterfragt und verbessert werden. So kann ein für sich und dem Endprodukt optimaler

Vorgehensprozess mit erfolgsversprechender Risikoorientierung in der Software-Entwicklung

gefunden werden.

24

6. Literaturverzeichnis

[AGI01] http://agilemanifesto.org, Beck, K. u.a., 2001

[ARN09] Arndt C., Hermanns C., Kuchen H., Poldner M., Best Practices in der

Softwareentwicklung, Förderkreis der Angewandten Informatik an der Westfälischen

Wilhelms-Universität Münster, 2009

[AUE02] Auer K., Miller R., Extreme Programming Applied - Playing to Win, Addison-

Wesley, 2002

[BAL96] Balzert H., Lehrbuch der Software-Technik, Band 1: Software-Entwicklung,

Spektrum Akademischer Verlag, 1996

[BAL98] Balzert H., Lehrbuch der Software-Technik, Band 2: Software-Management,

Software-Qualitätssicherung. Spektrum Akademischer Verlag, 1998

[CAP98] Capers T. J., Estimating Software Costs, McGraw-Hill, 1998

[DIR11] Dirbach J., Flückiger M., Lentz S., Software entwickeln mit Verstand,

dpunkt.Verlag, 2011

[FOW05] Fowler M., Refactoring - Oder wie Sie das Design vorhandener Software

verbessern, Addison-Wesley, 2005

[FÜR11] Fürst A., Abbruchentscheidungen in Softwareentwicklungsprojekten, 2011

[GAU04] Gaulke M., Risikomanagement in IT-Projekten, 2.Auflage, 2004

[GFK00] GfK / IESE /ISI, Analyse und Evaluation der Softwareentwicklung in Deutschland,

Eine Studie für das Bundesministerium für Bildung und Forschung, Projektgemeinschaft:

GfK Markforschung GmbH, Fraunhofer-Institut für Experimentelles Software Engineering

IESE, Fraunhofer- Institut für Systemtechnik und Innovationsforschung ISI, 2000

[IAB10] http://v-modell.iabg.de, o. V., Letztes Update: November 2010

[INF02] http://www.informit.com/articles/, Software Development & Management, Agile,

Scrum with XP, Mar K., Schwaber K., 22. März 2002

[iSE09] iSSE Institut for Software & Systems Engineering, Advanced Software Engineering,

Dr. Haneberg D., November 2009

[iXM10] iX – Magazin für Informationstechnik, Agile Software ist Mainstream, 03/2010

[KIR01] Kircher M., Die Evolution von eXtreme Programming - Wieso XP so ist wie es ist,

JavaSpektrum, Januar 2001

[LEW] Lewitz O., Das Sporthemd unterm Anzug – V-Modell XT with Scrum inside,

microTool GmbH Berlin

25

[OEC04] Oechtering R., Softwareprojekte: Risiko senken durch inkrementelle Entwicklung,

Projekt Magazin 21/2004

[RIC10] Richter M., Flückiger M., Usability Engineering kompakt – Benutzbare Software

gezielt entwickeln, Spektrum Akademischer Verlag, 2010

[SÄF10] Schäfer W, Softwareentwicklung, Einstieg für Anspruchsvolle, Addison-Wesley in

Kooperation mit Pearson Studium, 2010

[SWA02] Schwaber K., Beedle M., Agile Software Development with Scrum, 2002

[VER00], Versteegen G., Projektmanagement mit dem Rational Unified Process,

Berlin/Heidelberg, 2000

III

III Abbildungsverzeichnis

Abbildung 1: Darstellung des Spiralmodells 8

Abbildung 2: Darstellung des V-Modell XT 9

Abbildung 3: Darstellung der Phasen im RUP 10

Abbildung 4: Darstellung des Extreme Programming Modells 12

Abbildung 5: Darstellung eines Scrum Prozesses 13

Abbildung 6: Projekt-Realisierungsrisiko 18