Seminararbeit Wie kann man risikoorientiert Software entwickeln? Brauchen wir einen Paradigmenwechsel in der Software-Entwicklung? 28.

Transkript

1 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 München seibert@fh-brandenburg.de Matrikelnummer:

2 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

3 I Inhaltsverzeichnis I Inhaltsverzeichnis II Abkürzungsverzeichnis I II 1. Einführung 3 2. Software-Entwicklung 4 3. Vorgehensmodelle für die Software-Entwicklung Wasserfallmodell Spiralmodell V-Modell und V-Modell XT Rational Unified Process (RUP) Agile Modelle Das Agile Manifest Extreme Programming (XP) Scrum Kombinationen Risikoorientierung in der Software-Entwicklung Definitionen Risiken in der Softwareentwicklung Minimierung von Risiken in den verschiedenen Vorgehensmodellen Risikofaktor Personal Risikofaktor Projektumfang Risikofaktor Anforderungsänderung Risikofaktor Kunde Weitere Risikofaktoren Fazit Literaturverzeichnis 24 III Abbildungsverzeichnis III I

4 II Abkürzungsverzeichnis isse: Institut for Software & Systems Engineering RUP: Rational Unified Process RUP SOA: Serviceorientierte Architektur XP: Extreme Programming II

5 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 3

6 Entwicklungen schlagen sich auch in der Ablauforganisation von Softwareentwicklungsprojekten 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 4

7 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 5

8 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 6

9 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] 7

10 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] 8

11 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 9

12 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 10

13 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] 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: 11

14 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 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: 12

15 [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] 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 13

16 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: 14

17 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 15

18 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 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 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 16

19 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? 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 17

20 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 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. 18

21 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 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. 19

22 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 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] 20

23 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 21