Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Größe: px
Ab Seite anzeigen:

Download "Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik"

Transkript

1 Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Einfluss agiler Softwareentwicklung auf die Kompetenzentwicklung in der universitären Informatikausbildung Analyse und Bewertung empirischer Studien zum Pair Programming Diplomarbeit zur Erlangung des Grades Diplom Informatiker vorgelegt von cand. Dipl.-Inform. Wolfgang Reinhardt Mühlenteichstraße Paderborn Matr.Nr Betreuer Prof. Dr. phil. Johann S. Magenheim Prof. Dr.-Ing. Reinhard Keil Paderborn, 27. November 2006

2

3 Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Paderborn, den 27. November Wolfgang Reinhardt

4

5 Zusammenfassung Agile Softwareentwicklung ist mehr als ein weiteres neues Schlagwort der Softwaretechnik. Bereits in zahlreichen Praxisprojekten konnte die Leistungsfähigkeit des leichtgewichtigen Ansatzes erfolgreich nachgewiesen werden. Die konsequente Rückbesinnung auf erfolgreiche und bewährte Planungs-, Arbeits- und Programmiertechniken sowie die aufmerksame Beachtung und Nutzung ihrer gegenseitigen Einflüsse bieten neue Chancen zu einer erfolgreicheren und effektiveren Entwicklung hochwertiger Software. Agile Methoden der Softwareentwicklung eröffnen zusätzliche Möglichkeiten, die Risiken und Kosten von Projekten besser zu steuern und die zukünftige Wartbarkeit zu verbessern. Pair Programming (PP) ist eine zentrale Arbeitstechnik der leichtgewichtigen Methoden und integrale Praktik des Extreme Programming. Zwei Entwickler erstellen beim PP zusammen ein Artefakt und sind dabei zu jeder Zeit gleichberechtigte und aktive Teilnehmer des Prozesses. Sowohl in der nationalen wie internationalen Diskussion werden verstärkt spezifische fachliche und methodische Kompetenzen sowie ausgeprägte kommunikative und soziale Fähigkeiten in das Zentrum einer ganzheitlichen Informatikausbildung gestellt. Agile Methoden einerseits und die Praxis der paarweisen Softwareentwicklung andererseits scheinen für die Vermittlung solcher Kompetenzen gut geeignet, verbinden sie doch aktuelle wirtschaftliche Trends der Softwaretechnik mit verschiedensten kommunikativen Techniken, Aspekten der gemeinsamen Arbeit und Problemlösung. Die vorliegende Arbeit führt in agile Vorgehensmodelle zur Softwareentwicklung ein, betrachtet diese kritisch und gibt Hinweise für die Integration in die universitäre Realität. Die Erarbeitung eines klaren Kompetenzbegriffs und die Betrachtung der internationalen Kompetenzdiskussion führt hin zur Analyse und Bewertung verschiedener empirischer Studien zum Pair Programming. Abschließend gibt die Arbeit Handlungsempfehlungen für den Einsatz von Pair Programming in universitären Veranstaltungen der Softwaretechnik.

6

7 Inhaltsverzeichnis 1 Einleitung 1 2 Methoden der Softwareentwicklung und deren Vorgehensmodelle Qualitätsanforderungen an Softwareprodukte Vorgehensmodelle der Softwareentwicklung Vorgehensmodelle der klassischen Softwareentwicklung Spiralmodell Wasserfallmodell V-Modell Rational Unified Process Vorgehensmodelle der agilen Softwareentwicklung Lean Software Development Adaptive Software Development Methodenfamilie Crystal Scrum Feature Driven Development Extreme Programming Was bieten agile Methoden? Extreme Programming in der Übersicht Personen und Rollen in XP Werte, Prinzipien und Aktivitäten Variablen in Softwareprojekten Werte Prinzipien Aktivitäten Versionsplanung Planspiel, Benutzergeschichten und Storycards Iterationsplanung und Releases Entwicklung Pair Programming Testen Refactoring Dokumentation XP in der universitären Realität v

8 vi Inhaltsverzeichnis 4 Pair Programming als zentrale Praktik von XP Historie des Pair Programming Annahmen über Pair Programming Positive Annahmen zum Pair Programming Vorbehalte gegenüber Pair Programming Synergieeffekte des Pair Programming Verhaltensregeln im Pair Programming Die Dos des Pair Programming Die Don ts des Pair Programming Softwaretechnische Aspekte des Pair Programming Pair Programming in studentischen Softwareprojekten Leitbilder und Kompetenzentwicklung in der Informatikausbildung Basiselemente einer ganzheitlichen Informatikausbildung Kompetenzbegriff und -konzepte Die berufliche Handlungskompetenz Informatik-Curricula aus internationaler Perspektive Kerngebiete der internationalen Informatikausbildung Empirische Studien zum Pair Programming Status der empirischen Untersuchung von Pair Programming Quantitative Studien Nosek (1998) Williams et al. (2000) Nawrocki et al. (2001) Hulkko & Abrahamsson (2005) Qualitative Studien Nosek (1998) Thomas et al. (2003) Katira et al. (2004) Puus et al. (2004) Schlussfolgerungen und Ergebnisse Handlungsempfehlungen zum Einsatz von Pair Programming Arbeitsplatzorganisation beim Pair Programming Pairing Guidelines Pair Rotation Organisatorische Aspekte Zielgruppen für Pair Programming Projektdauer Gruppengröße Bewertung individueller Leistungen Coding Standards

9 Inhaltsverzeichnis vii Namenskonventionen Formatierung Einsatz von Kontrollstrukturen Sichtbarkeit Kommentare Abwandlungen des PP-Ansatzes Schlussbetrachtung und Ausblick 147 A Manifesto for Agile Software Development III B The Pair Programming Questionnaire V Abbildungsverzeichnis Tabellenverzeichnis Listings Literaturverzeichnis Abkürzungsverzeichnis Personenregister IX XI XIII XV XXIX XXXI

10 viii

11 1 Einleitung Softwareprojekte unterliegen sowohl im wirtschaftlichen wie auch im universitären Umfeld ständigem Wandel. Die zentralen Fragen der modernen Softwareentwicklung lauten 1. Wie erhalte ich schneller bessere Software? 2. Wie passe ich meinen Entwicklungsprozess an den ständigen Wandel an? Unter wirtschaftlichen Gesichtspunkten muss zusätzlich nach einer möglichst effizienten Verteilung der zur Verfügung stehenden menschlichen Arbeitskraft; im wissenschaftlich-didaktischen Umfeld nach einer nachhaltigen Vermittlung grundlegender Theorien und aktueller Entwicklungen gefragt werden. Während die Wirtschaft seit Jahren nach theoretisch wie praktisch hoch qualifizierten Fachkräften ruft, ist die Praxis der Softwaretechnik sowohl in den althergebrachten Diplom-, wie auch den hoch beworbenen Bachelor- und Masterstudiengängen zumeist auf einige wenige praktische Kernprojekte begrenzt. Grundlegende Programmierparadigmen und -konzepte werden den Studierenden in der Regel in einführenden Veranstaltungen zur Softwareentwicklung vermittelt; die Praxis dergleichen durch kleine Programmieraufgaben, die in Heimarbeit oder Übungsgruppen zu erstellen sind. Bis auf wenige Ausnahmen wird so das Bild des zurückgezogenen und allein entwickelnden Programmierers vermittelt, das in der Realität der wirtschaftlichen Softwareentwicklung längst veraltet und durch vielfältige Teamarbeit ersetzt ist. Auch hat die Mehrzahl der graduierten Informatiker während des Studiums keine Veranstaltung zu Techniken des Projektmanagements, der Führung und Durchführung von Projekten oder aktueller Vorgehensmodelle der Softwareentwicklung besucht oder besuchen müssen. Falls solche Aspekte Teil einführender oder weiterführender Veranstaltungen waren, so sind nur selten aktuelle Entwicklungen wie agile Methoden, schlankes Management oder individuelle und gruppenbasierte Softwareprozesse vermittelt. Pair Programming (PP) ist ein Konzept der gemeinsamen softwaretechnischen Arbeit und in der industriellen Softwareentwicklung bereits seit Jahren wohl bekannt und eingesetzt. Unter wissenschaftlichen und didaktischen Aspekten gewann Pair Programming durch seine feste Integration in die agile Methode Extreme Programming (XP) an Bedeutung und zählt mittlerweile zu einem der meist untersuchten agilen Teilprozesse. Ziel dieser Arbeit ist es, Handlungsempfehlungen für den Einsatz von Pair Programming in universitären Informatik-Lehrveranstaltungen zu geben, deren Einhaltung positive Auswirkungen auf die Kompetenzentwicklung bei Studenten hat. Dazu wird Pair Programming als Teil von XP zunächst in die Methodiken der Softwareentwicklung eingeordnet und die Konzepte von Extreme Programming vermittelt, Pair Programming von Grund auf erläutert und eine 1

12 2 Einleitung Einführung in die vielschichtige Thematik der internationalen Kompetenzdiskussion gegeben. Weiter werden Teile der nationalen und internationalen Publikationslandschaft zum Extreme und Pair Programming untersucht, um fundierte Handlungsempfehlungen für den Einsatz von Pair Programming in der universitären Informatikausbildung herauszuarbeiten. Der Arbeit liegen dabei mehrere Hypothesen zu Grunde, die durch die Analyse und Bewertung empirischer Untersuchungen überprüft und bewertet werden. Zum einen verfolgt die Arbeit die Haupthypothese Pair Programming hat positive Auswirkungen auf die studentische Kompetenzentwicklung. Abgeleitet davon wird folgendes vermutet: Speziell Sozial- und Methodenkompetenz der beteiligten Studenten werden durch die Paararbeit stärker ausgeprägt. Durch den Einsatz von Pair Programming in studentischen Projekten ist die Qualität der erstellten Software deutlich höher als bei Projekten mit klassischer Methodik. Gemeinsame Arbeit in universitären Softwareprojekten hat nichts mit Betrug oder Täuschung zu tun hat, sondern steht für moderne, wirtschaftsnahe Softwareentwicklung. Die vorliegende Arbeit ist wie folgt gegliedert: Kapitel 2 (Methoden der Softwareentwicklung und deren Vorgehensmodelle) führt an das Thema heran, indem klassische und agile Methoden der Softwareentwicklung und ausgewählte Vorgehensmodelle vorgestellt werden. Die Entstehung agiler Methoden wird untersucht und kritisch auf ihren Mehrwert hin geprüft. Kapitel 3 (Extreme Programming in der Übersicht) ordnet XP in die Methodik der agilen Softwareentwicklung ein und stellt ausführlich Variablen, Werte und Prinzipien des Extreme Programming vor. Darüber hinaus werden die Kernprozesse Planung und Entwicklung vorgestellt und die Chancen und Grenzen einer Integration in die universitäre Lehr-Wirklichkeit analysiert. Pair Programming als fester Bestandteil von XP einerseits und effiziente Entwicklungsmethode andererseits wird in Kapitel 4 (Pair Programming als zentrale Praktik des Extreme Programming) vorgestellt. Die Ausführungen geben einen Einblick in Synergieeffekte, die durch die Anwendung von Pair Programming entstehen können und liefert Verhaltensregeln für die Partner eines Programmierpaars. Um der Frage, ob Pair Programming zu einer besseren Kompetenzentwicklung bei Studenten führt, nachgehen zu können, müssen Grundlagen des Kompetenzbegriffs und der vielschichtigen Kompetenzdiskussion erarbeitet werden. In Kapitel 5 (Leitbilder und Kompetenzentwicklung in der Informatikausbildung) werden die Kernelemente einer ganzheitlichen Informatikausbildung mit einem erarbeiteten Kompetenzbegriff und der internationalen Diskussion um optimale Wege zur Vermittlung informatischer Inhalte abgeglichen. Zusammen mit dem folgenden Kapitel werden hier die Grundlagen für die späteren Handlungsempfehlungen und die objektive Auswertung der aufgestellten Hypothesen ermöglicht.

13 3 Kapitel 6 (Empirische Studien zum Pair Programming) gibt einen ausführlichen Überblick über den Status der vielfältigen Untersuchungen zum Pair Programming und stellt ausgewählte Studien mit ihren qualitativen und quantitativen Aussagen vor. In Kapitel 7 (Handlungsempfehlungen zum Einsatz von Pair Programming) werden die Erkenntnisse der vorhergehenden Untersuchungen und entwickelten Begrifflichkeiten verwendet, um Aussagen und Hinweise für den wirksamen Einsatz von Pair Programming in universitären Lehrveranstaltungen zu geben. Das Kapitel gibt u. a. Empfehlungen in Bezug auf die ergonomische Gestaltung von Paar-Arbeitsplätzen und dem Einsatz von Codestandards. Darüber hinaus werden organisatorische Aspekte im Hinblick auf die Anwendung des PP-Ansatzes in universitären Umgebungen betrachtet. Mit Kapitel 8 (Schlussbetrachtung und Ausblick) werden die Ideen, Werte und Praktiken der umfangreichen Thematik abschließend eingeschätzt und die untersuchten Hypothesen bewertet. Zudem wagt das Abschlusskapitel einen Blick in die Zukunft des Pair Programming und sucht nach dem Platz der Arbeit in der Forschungslandschaft.

14

15 2 Methoden der Softwareentwicklung und deren Vorgehensmodelle 2.1 Qualitätsanforderungen an Softwareprodukte Vorgehensmodelle der Softwareentwicklung Vorgehensmodelle der klassischen Softwareentwicklung Spiralmodell Wasserfallmodell V-Modell Rational Unified Process Vorgehensmodelle der agilen Softwareentwicklung Lean Software Development Adaptive Software Development Methodenfamilie Crystal Scrum Feature Driven Development Extreme Programming Was bieten agile Methoden? Softwareentwicklung ist in besonderem Maße durch tiefgreifende Fehleinschätzungen geprägt. Sehr häufig werden die Dauer für die Projektorganisation, Kommunikationsbedarf, Programmierung sowie Wartung und Betreuung zu kurz geschätzt (vgl. auch [May01]). Vorgehensmodelle zur Softwareentwicklung dienen dazu, den Prozess der Softwareentwicklung übersichtlicher zu gestalten und in der Komplexität beherrschbarer zu machen. Dabei gehen die Meinungen zum optimalen Vorgehen in Softwareentwicklungsprojekten sehr weit auseinander. Einige häufig wiederkehrende Forderungen sind unter anderem: klares, schriftlich festgehaltenes Ziel des Softwareprojekts von Anfang an Änderungen der Anforderungen einplanen möglichst einfaches, gut strukturiertes Design und Architektur kontinuierliche und intensive Einbindung des Kunden inkrementelle Entwicklung mit kurzen Zyklen und häufigen automatisierten Testdurchläufen frühe Entwicklung von Prototypen 5

16 6 Methoden der Softwareentwicklung und deren Vorgehensmodelle frühes und häufiges Testen (manchmal sogar zuerst Testfälle und dann Entwicklung) nicht zu viel und nicht zu wenig Dokumentation Jedes Softwareentwicklungsprojekt betätigt sich dabei in einem Spannungsfeld zwischen Qualität, Kosten und Zeit. Die vorherrschenden Fragen sind 1. Warum kostet Softwareentwicklung so viel? 2. Warum dauert die Entwicklung so lange? Während der Kostenfaktor in universitären Softwareprojekten keine vordergründige Rolle spielt 1, ist der Faktor Zeit einer der wichtigsten überhaupt. Oft stehen für Konzeption, Implementierung und Dokumentation nur wenige Wochen bis Monate zur Verfügung und es wird kaum in Vollzeit an dem Projekt gearbeitet. Wichtig für einen erfolgreichen Abschluss eines Projektes ist also in jedem Fall der Aufbau eines gemeinsamen Denkmodells bei allen Entwicklern, eine ausgeprägte Kommunikation unter den Entwicklern und mit dem Auftraggeber und die gleichberechtigte, kooperative Arbeit im Projekt. Um Pair Programming als Programmierstil korrekt in verschiedene Vorgehensmodelle einordnen zu können, müssen zunächst die Unterschiede in den verschiedenen Entwicklungsmethoden betrachtet werden. Wie Abbildung 2.1 zeigt, unterteilen sich diese zunächst in solche mit und solche ohne Methode. Die Softwareentwicklungsmethoden mit Methode untergliedern sich nochmals in klassische und agile Methoden. Jedes Vorgehensmodell der Softwareentwicklung hat seine eigene Art mit Anforderungen umzugehen, wobei der Grad der Erfüllung dieser Anforderungen ein gutes Maß für die Beurteilung des Erfolgs einer Methode ist. Softwareentwicklung Softwareentwicklung ohne Methode Methodische Softwareentwicklung Klassische Methoden Agile Methoden Abbildung 2.1: Klassifikation von Softwareentwicklungsmethoden Softwareentwicklung ohne Methode ist auch als Hacking oder Code & Fix bekannt und wird zumeist von unerfahrenen Entwicklern eingesetzt. In vielen universitären Projekten fehlt eine klare Struktur und eine definierte Methode zur Softwareentwicklung, so dass auch hier oft einfaches Code & Fix betrieben wird. Die Softwareentwicklung ohne Methode ist vom Gefühl der Entwickler geleitet jede neue Anforderung an die zu erstellende Software zunächst einmal in Programmcode umzusetzen ohne ein grundlegendes Design zu entwickeln und den 1 Zumeist sind die Projektmitglieder Studierende und erhalten daher keine finanzielle Vergütung für ihre Arbeit.

17 Kapitel 2 Qualitätsanforderungen an Softwareprodukte 7 Programmcode systematisch zu testen oder zu dokumentieren. In der Folge ist der Programmcode weder für den Entwickler selbst, noch für Außenstehende zu verstehen, kaum wartbar und im schlimmsten Fall nur für einen statischen Spezialfall einsetzbar. Die methodische Softwareentwicklung wird momentan in zwei Kategorien eingeteilt: auf der einen Seite stehen die klassischen und auf der anderen Seit die agilen Methoden. Der zentrale Unterschied der Methodiken besteht in der Planbarkeit der Entwicklungsarbeit; Ziel klassischer Methoden ist es, den Ablauf der Entwicklung so gut wie möglich vorauszuplanen, während die agile Softwareentwicklung auf Pläne verzichtet und so eine hohe Flexibilität hinsichtlich möglicher Unvorhersehbarkeiten gewährleistet. Die Planbarkeit und Stabilität der Anforderungen bestimmt daher maßgeblich die Wahl der Entwicklungsmethode. In Tabelle 2.1 sind typische Annahmen über Methoden der klassischen und agilen Softwareentwicklung gegenübergestellt. Softwareentwicklungsmethoden stellen die eigentliche Implementierung in den Kontext eines mehr oder weniger disziplinierten Prozesses, um so eine besser plan- und vorhersehbare Entwicklung gewährleisten zu können. Diese Eingliederung bietet einen organisatorischen Rahmen, der den Gesamtablauf der Softwareentwicklung in kleinere Schritte einteilt, eine Reihenfolge für deren Abarbeitung und Verantwortlichkeiten definiert. Darüber hinaus geben Methoden zumeist Standards, Richtlinien, Praktiken und Werkzeuge für den Einsatz vor. Während die klassischen (Ingenieur-)Methoden einen detaillierten Prozess definieren, dessen Schwerpunkt auf der bürokratischen Planung liegt, suchen leichtgewichtigte, agile Methoden einen brauchbaren Kompromiss zwischen dem Chaos des Code & Fix und einer zu starken Prozessorientierung. Das folgende Kapitel führt ein in objektive Qualitätsstandards für Softwareprodukte und betrachtet Vorgehensmodelle der klassischen und agilen Softwareentwicklung. Der propagierte Mehrwert agiler Methoden wird kritisch betrachtet, um anschließend Pair Programming in die agile Methode des Extreme Programming einordnen zu können. 2.1 Qualitätsanforderungen an Softwareprodukte Softwarequalität ist in universitären wie wirtschaftlichen Projekten von zentraler Bedeutung. Unter Softwarequalität versteht man die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. [Bal01, S. 257]. Diese Definition bezieht sich ausschließlich auf die Qualität des Softwareprodukts (Produktqualität) und nicht auf den Prozess der Softwareherstellung (Prozessqualität). Diese Arbeit beschäftigt sich vorrangig mit Verbesserungsmöglichkeiten der studentischen Softwareentwicklung im Rahmen der universitären Informatikausbildung und legt daher den Fokus auf Prozessqualität. Wenn auch die Qualität der entwickelten Software von hoher Bedeutung ist, so muss es Ziel der Ausbildung sein, großen Wert auf eine realitätsnahe Vermittlung des Prozesses der Softwareentwicklung zu geben.

18 8 Methoden der Softwareentwicklung und deren Vorgehensmodelle Tabelle 2.1: Bekannte Annahmen hinsichtlich klassischer und agiler Softwareentwicklung klassische Softwareentwicklung agile Softwareentwicklung Hauptziel hohe Sicherheit der Entwicklung, schnelle und regelmäßige Ergebnisse, ausgiebige Dokumentation für den Kunden Einbeziehung des Kunden in den Prozess Projektgröße Kunden mittlere bis große Teams und Projekte Kunde als Geldgeber und Dokumentationsempfänger kleinste bis mittlere Teams und Projekte Kunde als Teil des Entwicklungsteams Planung genaue und umfassende Planung, deutlich geringere Planung und Dokumentation, Ergebnisse können leicht kontrolliert werden, Gefahr für Architekturfehler zeitaufwändige und teure Anpassung des Plans an Veränderungen Anforderungen Entwickler müssen Anforderungen abschätzen, diese dürfen sich nicht nennenswert ändern oder frühzeitig mit bedacht werden gemacht für schnelle Anforderungsänderungen Architektur genau geplante Architektur, Betonung der Einfachheit, Probleme bei sich ändernden Anforderungewareentwurfs auch späte Änderungen des Soft- möglich Refactoring zumeist sehr aufwendig und teuer bei kleineren Projekten meist kaum aufwendig Trotz des Fokus auf Softwareentwicklungsprozesse soll ein kurzer Exkurs zu Qualitätsmodellen für die Software-Produktqualität gemacht werden. Ein Qualitätsmodell operationalisiert den allgemein geltenden Begriff von Qualität 2 durch die Ableitung von Unterbegriffen wie 1. Qualitätsmerkmale, 2. Qualitätskriterien und 3. Qualitätsindikatoren. 2 Qualität ist ein mehr als relativer Begriff. Je nach Kontext, Wirtschaftszweig oder Forschungsgebiet spiegelt er verschiedene Sichten auf einen Gegenstand oder eine Dienstleistung wider. ISO 8402 definiert Qualität als die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebenener Erfordernisse bezieht.

19 Kapitel 2 Qualitätsanforderungen an Softwareprodukte 9 Software als komplexes technisches Produkt hat meist Prototypcharakter, da es einem stetigen Anpassungs- und Wartungsprozess unterliegt. Die ISO/IEC 9126 definiert sechs Qualitätsmerkmale (siehe Abbildung 2.2) für Software, um die Produktqualität zu einem bestimmten Zeitpunkt feststellen zu können. Funktionalität Übertragbarkeit Zuverlässigkeit ISO/IEC 9126 DIN Wartungsfreundlichkeit Benutzbarkeit Effizienz Abbildung 2.2: Qualitätsmerkmale für Softwareprodukte nach ISO 9126 Funktionalität Funktionalität meint das Vorhandensein bestimmter Softwarefunktionen mit festgelegten Eigenschaften, welche die zuvor definierten Anforderungen erfüllen. Als Teilmerkmale werden u. a. Sicherheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Angemessenheit und Korrektheit genannt. Zuverlässigkeit Die Fähigkeit des Softwareprodukts unter bestimmten Randbedingungen (z. B. Fehleingaben oder Ausfälle von Teilen des Systems) die Leistungsfähigkeit zu erhalten wird als Zuverlässigkeit bezeichnet. Teilaspekte von zuverlässigen Softwareprodukten sind unter anderem Fehlertoleranz, Konformität, und Wiederherstellbarkeit. Benutzbarkeit Die Benutzbarkeit von Software definiert den Aufwand, der zur Einarbeitung und Benutzung des Produkts notwendig ist. Darüber hinaus spiegelt sie das individuelle Urteil über diese Kriterien einer festgelegten Gruppe wider. Verständlichkeit, Erlernbarkeit und Bedienbarkeit der Software werden im Allgemeinen als Teilmerkmale der Benutzbarkeit genannt. Effizienz Effizienz beschreibt das Verhältnis zwischen Leistung der Software und den dafür aufgewendeten Betriebsmitteln (CPU-Zeit, Festplattenspeicher). Spezielles Augenmerk wird

20 10 Methoden der Softwareentwicklung und deren Vorgehensmodelle hier auf die Aspekte Zeitverhalten, Verbrauchsverhalten und Konformität mit Normen oder Vereinbarungen gelegt. Wartbarkeit Je geringer der Aufwand für die Durchführung vorgegebener Änderungen, also Korrekturen, Verbesserung oder Anpassungen an die Umgebung, dem Softwareprodukt an sich oder der funktionalen Spezifikation ist, um so besser ist die Änderbarkeit der entwickelten Software. Teilmerkmale sind Modifizierbarkeit, Analysierbarkeit und Stabilität. Übertragbarkeit Übertragbarkeit meint die Migrationsfähigkeit des Softwareprodukts in eine neue organisatorische Hard- oder Softwareumgebung. Kernfrage dieses Qualitätsmerkmals ist die Einfachheit der Übertragung und damit auch Teilaspekte wie Anpassbarkeit, Installierbarkeit und Konformität. Während Qualitätsmodelle wie die ISO/IEC 9126 die Software-Produktqualität aus- und bewerten, dienen Vorgehensmodelle zur Planung, Überwachung und Lenkung der Prozessqualität. Es ist davon auszugehen, dass ein hochwertiger Prozess der Softwareentwicklung mit hochwertigen Qualitätsmerkmalen des Softwareprodukts korreliert. Darüber hinaus bleibt zu zeigen, dass es Indikatoren für bessere Lernergebnisse durch agile Vorgehensmodelle bei Studierenden gibt. 2.2 Vorgehensmodelle der Softwareentwicklung Um Software sinnvoll, in einem angemessenen Zeitrahmen und qualitativ hochwertigen Prozess entwickeln zu können, wurden bereits frühzeitig Vorgehensmodelle geschaffen, um Arbeit und Ergebnisse effizient und effektiv zu gestalten. Ein Vorgehensmodell beschreibt theoretisch den Lebenszyklus einer Software, indem ein Plan zur Fertigstellung aufgestellt wird. In der klassischen Softwareentwicklung untergliedert dieser Plan den Softwareentwicklungsprozess in zeitlich und inhaltlich beschränkte Phasen. Eine statische Sicht auf den Prozess der Softwareentwicklung mit einer starren Abarbeitung der vorgegebenen Phasen hat jedoch wenig mit der Praxis der Systemgestaltung und Programmierung gemein. Die agile Softwareentwicklung zeigt Methoden auf, um dieses Paradigma aufzulösen. Entwickler können kreativ und befreit vom Korsett des strikt geplanten Vorgehens entwickeln und die Funktionsfähigkeit der Software in den Mittelpunkt ihrer Arbeit stellen. Das Manifest für agile Softwareentwicklung stellt den Wert von Individuen und Interaktionen über Prozesse und Tools, funktionierende Programme über komplexe Dokumentationen, die Zusammenarbeit mit Kunden über Vertragsverhandlungen und Flexibilität über strikte Ablaufpläne (siehe Kapitel A). Im Folgenden werden klassische und agile Softwareentwicklung charakterisiert und ausgewählte Vorgehensmodelle der beiden Methoden vorgestellt.

21 Kapitel 2 Vorgehensmodelle der klassischen Softwareentwicklung Vorgehensmodelle der klassischen Softwareentwicklung Bekannte Beispiele für klassische Vorgehensmodelle sind Spiralmodell, Wasserfallmodell, V- Modell und der Rational Unified Process (RUP). Allen klassischen Modellen gemein ist die Aufteilung der Softwareentwicklung in eine Folge von Tätigkeiten, in welchen bestimmte Ergebnisse erarbeitet werden. Diese Tätigkeiten werden je nach Modell ein- oder mehrmals iterativ durchlaufen. Für alle klassischen Vorgehensmodelle gilt, dass sie im gesamten Ablauf der Entwicklung eine Abfolge weniger Phasen beschreiben. Das Hauptproblem der klassischen Softwareentwicklung stellt der große zeitliche Abstand zwischen der Anforderungsanalyse sowie der Fertigstellung und Einführung des Systems beim Kunden dar. Zudem lassen die Methoden der klassischen Softwareentwicklung nur in begrenztem Maße ein Feedback der Kunden während des Entwicklungsprozesses zu eine bekannte Metapher ist die Mondrakete, deren Kurs bereits vor dem Start feststeht und während der Reise nur noch geringfügig und mit sehr großem Aufwand geändert werden kann. Im Allgemeinen werden die Anforderungen zu Beginn detailliert analysiert, genau dokumentiert und vertraglich abgesichert. Daraus resultiert oft das allgemein bekannte Problem einer Softwarelösung, die zwar die Anforderungen aus der Vergangenheit treffend erfüllt, die aktuellen Bedürfnisse des Kunden jedoch nicht abdeckt. Nachfolgend werden die bekanntesten klassischen Vorgehensmodelle kurz vorgestellt und ihre Ziele, ihr Vorgehen und mögliche Probleme skizziert Spiralmodell Das risikogetriebene Spiralmodell (siehe Abbildung 2.3) von Barry W. Boehm [BEP + 82] entstand in einer Zeit, in der man mit Softwareentwicklungsprojekten noch mehrheitlich schlechte Erfahrungen machte. Softwareteile wurden auf Grund mangelnder Kommunikation oft mehrfach entwickelt, die Anforderungen der Kunden wurden nur mangelhaft berücksichtigt oder die Kosten der Softwareentwicklung stiegen ins Unermessliche. Das ursprüngliche Spiralmodell als Erweiterung des Wasserfallmodells [BEP + 82] und seine Erweiterung [Boe88] setzen genau dort an Kostentransparenz, Flexibilität, damals neue Softwaremanagement-Theorien und Ansätze zur Code-Wiederverwendbarkeit finden Platz in Boehm s Vorgehensmodell. Ziel sollte es sein Kundenwünsche besser in den Prozess der Softwareentwicklung einfließen zu lassen und den Entwicklern ein Werkzeug an die Hand zu geben, welches ihnen Zeit und Arbeit ersparen sollte. Die risikogetriebene Vorgehensweise des Ansatzes findet in sehr großen Projekten Anwendung, da nur hier der Administrationsaufwand für die Implementierung des Spiralmodells in einer akzeptablen Relation zum Nutzen steht. Im Spiralmodell wird der Softwareentwicklungsprozess als iterativer Prozess verstanden. Jede Windung der Spirale (also jeder zyklische Durchlauf des Prozesses) enthält die Aktivitäten Festlegung der Ziele, Beurteilung der Alternativen und Rahmenbedingungen, Erkennen und Reduktion von möglichen Risiken und Entwicklung von Prototypen, Design, Entwicklung und Test des Zwischenproduktes und

22 12 Methoden der Softwareentwicklung und deren Vorgehensmodelle Festlegen der Ziele, Beurteilen von Alternativen kummulierte Kosten Risikoanalyse, Prototyping Risikoanalyse Risikoanalyse Zustimmung durch Überprüfung Lebenszyklus planen Risikoanalyse Prototyp Prototyp einsatzfähiger Prototyp (Review) Konzept Grobentwurf Anforderungen Feinentwurf Entwicklungsplan Verifikation Validation Code Testplanung Verifikation Validation Integration Planung des nächsten Zyklus Abnahme Implementierung Test Design, Entwicklung und Test Abbildung 2.3: Ein Spiralmodell nach [Boe88] Planung des nächsten Prozesszyklus. Am Ende jeder Wendung steht ein Review, der den letzten Durchlauf des Prozesses bewertet und die Pläne für den nächsten Zyklus verabschiedet. Dabei werden die verfügbaren Ressourcen festgelegt oder im schlimmsten Fall die Entwicklung abgebrochen. Die in den 1980er Jahren vorhandenen Vorgehensmodelle zur Softwareentwicklung hatten alle einen gemeinsamen Nachteil; den starren Durchlauf der einzelnen Prozessphasen. Durch unabhängige Planung, Prototyping und Risikoanalyse kann in jedem Spiralzyklus auf den aktuellen Projektstand reagiert werden und Budgets für einen Durchlauf aufgestellt werden. Im Gegensatz zu den streng phasischen Vorgehensmodellen werden hier jedoch die Anforderungen nicht a priori festgelegt, sondern entwickeln sich in jedem Zyklus neu. Dennoch ist die Reaktionsfähigkeit hinsichtlich auftretender Änderungen eingeschränkt, eine Anpassung der Softwarearchitektur und Planung zeitraubend und teuer Wasserfallmodell Das Wasserfallmodell wurde in seiner ursprünglichen Form erstmals von Winston Royce im Jahre 1970 präsentiert [Roy87] und ist streng genommen eine verbesserte Weiterentwick-

23 Kapitel 2 Vorgehensmodelle der klassischen Softwareentwicklung 13 lung des einfachen Phasenmodells von Herbert Benington aus dem Jahr 1956 [Ben87]. Royce teilte die Phasen so ein, dass es strenge inhaltliche Abhängigkeiten zur jeweils vorhergehenden Phase gab. Dieses ursprüngliche Modell setzte sich jedoch nicht durch, da es keinen Informationsfluss entgegen des eigentlichen Phasenverlaufs gab. Barry W. Boehm erweiterte das Wasserfallmodell schließlich durch Verifikations- und Validierungsaspekte durch Rücksprungmöglichkeiten (vgl. Abbildung 2.4). Trotz dieser sehr eingeschränkten Agilität im Softwareentwicklungsprozess ist das Wasserfallmodell das traditionell am weitesten verbreitete Vorgehensmodell der klassischen Softwareentwicklung. Voruntersuchung Analyse Entwurf Implementierung Test Betrieb Abbildung 2.4: Ein Wasserfallmodell nach [Roy87] Jede Phase des Wasserfallmodells besitzt eindeutig definierte Start- und Endpunkte; am Ende jeder Phase gibt es Meilensteinsitzungen und ausführliche Dokumentationen. Zu den relevantesten Dokumenten gehören Pflichten- und Lastenheft. Aus der heutigen Betrachtung fällt auf, dass dieses konventionelle und zunächst plausibel wirkende Modell einige schwerwiegende Schwächen aufweist. Zunächst geht das Modell davon aus, dass alle Anforderungen an die zu entwickelnde Software im Voraus festgeschrieben werden können. Während der konzeptionellen ersten drei Phasen des Modells werden keinerlei Prototypen erstellt, um die Plausibilität der Anforderungsdefinition zu überprüfen und etwaige Irrtümer zu identifizieren. Tests in einer solch späten Phase des Entwicklungsprozesses äußern sich oft im einfachen Debuggen, also einem Funktionstest gegenüber den eigenen Anforderungen. Ein Test auf Gebrauchstauglichkeit mit den Endanwendern kommt erst dann zustande, wenn das Produkt fast fertig ist. In real-wirtschaftlichen Projekten kommt es durch das Aufkommen von Änderungen in der Ausgangssituation oder Änderungswünschen hinsichtlich der Funktionaliät zu hohen zusätzlichen Kosten des Softwareprojekts. Die Limitation der strikt nacheinander

24 14 Methoden der Softwareentwicklung und deren Vorgehensmodelle abzuarbeitenden Phasen führt in solchen Fällen oft zu einem Neustart des Projekts in Phase 1. Trotz der genannten Probleme ist das Wasserfallmodell gerade in universitären Softwareentwicklungsprojekten der Standard für Vorgehensmodelle. Entscheidend dafür sind die ausgiebige Dokumentationsarbeit und die Orientierung an Meilensteinen. Die vorliegende Arbeit will zeigen, dass sich leichtgewichtige Methoden zur Softwareentwicklung auf Grund ihrer realwirtschaftlichen Relevanz deutlich besser für die universitäre Informatikausbildung eignen. Agile Methoden und bekannte Vorgehensmodelle werden nachfolgend ab Seite 18 vorgestellt V-Modell Das V-Modell 3 wurde 1986 als Weiterentwicklung des Wasserfallmodells vom Bundesministerium für Verteidigung (BMVg) in Auftrag gegeben und in Zusammenarbeit des Bundesamts für Wehrtechnik und Beschaffung (BWB) und der Industrieanlagen Betriebsgesellschaft mbh (IABG) entwickelt. Ziele der Entwicklung waren 1. die Möglichkeit der Begrenzung der Softwareentwicklungskosten durch erhöhte Transparenz der Kosten während des gesamtem Entwicklungs- und Wartungsprozesses, 2. die Schaffung von Möglichkeiten zur Garantie von Mindeststandards der Softwarequalität und 3. die Softwareentwicklung innerhalb des Aufgabenbereiches des Bundes zu standardisieren, vergleichbar und transparent zu gestalten. Vorgesehen war es zunächst nur für den Einsatz in Softwareentwicklungsprojekten des Bundes und wurde 1992 erstmalig im Bundesministerium des Inneren (BMI) eingesetzt. Seit 1996 ist es verbindlicher Standard für alle IT-Entwicklungen des Bundes 4. Heute ist das V-Modell in vielen Unternehmen Standard für die Softwareentwicklung, da es durch ständige Weiterentwicklungen und Finanzierungen durch BMVg und BMI ein lebendiger Standard ist. Das V-Modell ist grundsätzlich mit dem Wasserfallmodell vergleichbar, jedoch werden frühe Phasen mittels Testdaten mit späteren verbunden (vgl. Abbildung 2.5). Das V-Modell ist iterativ anwendbar und sowohl mit OOAD 5 und UML 6 einsetzbar. Das V-Modell ist als typisch klassisches Vorgehensmodell stark formalisiert und dokumentenbasiert. Vor seiner Anwendung auf ein spezifisches Softwareprojekt muss es angepasst werden. Dieser Vorgang wird als Tailoring bezeichnet. Das V-Modell umfasst drei Standardisierungsebenen, auf denen die entsprechenden Regelungen wiederum in Untermodelle eingeteilt werden. Die drei Ebenen des Standards sind: 3 Der ursprüngliche Name während der Entwicklung war Entwicklungsstandard für IT-Systeme des Bundes (EstdIT). 4 Seit 1996 gab es Weiterentwicklungen des Standards zum V-Modell 97 und V-Modell XT (extreme Tailoring). 5 Object Oriented Analysis and Design. Vgl. auch 6 Unified Modeling Language. Vgl. auch

25 Kapitel 2 Vorgehensmodelle der klassischen Softwareentwicklung 15 Anwendungsszenarien Abnahmetest Grobentwurf Testfall Systemtest Feinentwurf Testfall Integrationstest Anforderungsdefinition Modulimplementation Testfall Modultest Abbildung 2.5: Ein V-Modell Vorgehensmodell: Art der Ergebnisse fest. Das Vorgehensmodell legt durchzuführende Tätigkeiten, Ergebnisse und Methodenzuordnung: Die Methodenzuordnung definiert, mit welchen Methoden die Tätigkeiten des Vorgehensmodells durchzuführen und welche Darstellungsmittel in den Ergebnissen zu verwenden sind. Werkzeuganforderungen: In dieser Ebene werden die funktionalen Eigenschaften der benötigten Werkzeuge festgelegt. Auf jeder dieser Ebenen kommen dann die vier angesprochenen Submodelle Projektmanagement, Qualitätssicherung, Systementwicklung und Konfigurationsmanagement zum Tragen. Abbildung 2.6 zeigt das grobe Zusammenspiel der Submodelle. Systementwicklung Konfigurationsmanagement Projektmanagement Qualitätssicherung Abbildung 2.6: Submodelle der V-Modell-Standardisierungsebenen

26 16 Methoden der Softwareentwicklung und deren Vorgehensmodelle Projektmanagement (PM): drei anderen Submodelle. Das Projektmanagement plant, informiert und kontrolliert die Systemerstellung (SE): implementiert. Im Submodell Systemerstellung werden Software und Systeme Qualitätssicherung (QS): Die Qualitätssicherung gibt einerseits spezifische Qualitätsanforderungen, Prüffälle und Kriterien vor, andererseits unterstützt sie hinsichtlich deren Einhaltung und überprüft schließlich die Ergebnisse der Systemerstellung. Konfigurationsmanagement (KM): Das Konfigurationsmanagement verwaltet die Produkte. Es stellt sicher, dass Produkte eindeutig identifizierbar sind und Produktänderungen kontrolliert, modell-konform durchgeführt werden. Dieser streng formalisierte Prozess führt nach dem Tailoring zu einem eindeutigen, projektspezifischen V-Modell. Dieses enthält Vorgehensbausteine, Produkt- und Aktivitätstypen sowie verschiedenste Rollen. In der Projektdurchführungsstrategie werden schließlich Meilensteine, Entscheidungspunkte und -träger, der zeitliche Ablauf und so genannte Projektfortschrittsentscheidungen dokumentiert. Als Dokumentationsminimum erwartet das V-Modell folgende Ergebnisprodukte nach Abschluss des Tailorings: Projekthandbuch: Hier wird vom Projektleiter eine Kurzbeschreibung des Projekts niedergeschrieben. Darüber hinaus werden Ergebnisse des Tailoring-Prozesses, ein grundlegender Projektdurchführungsplan, die vereinbarte Unterstützung des Auftraggebers, Organisation und Vorgaben für die Durchführung des Projekts sowie die anstehenden Entwicklungsaufgaben, Vorgaben für Projektstatusberichte, Risikolisten und Verträge beigefügt. Projektplan: Der Projektplan ist eine vom Projektleiter erstellte Basis für die Kontrolle und Steuerung des Projekts. Er beschreibt die ausgewählte Vorgehensweise des Projekts und schreibt detailliert fest, was wann von wem zu tun ist. Handbuch der Qualitätssicherung: Die vom Qualitätssicherungsbeauftragten erstellte Kurzbeschreibung der Qualitätsziele im Projekt enthält u. a. auch die Festlegung der zu prüfenden Produkte und Prozesse, Organisation und Vorgaben für die Planung und Durchführung der Qualitätssicherung sowie Vorgaben für externe Firmen und Zulieferer. Produktbibliothek: Die Produktbibliothek umfasst alle im Prozess entstehenden Produkte in allen Versionen sowie die zugehörigen Dokumentationen. Die Sicherung und Archivierung der Produktbibliothek ist entsprechend den Vorgaben im Projekthandbuch durchzuführen. Für das Vorgehen hinsichtlich der Softwareentwicklung sind Dokumente wie Gesamtsystemspezifikation, Systemspezifikation, Systemarchitektur und Prüfspezifikation zu erstellen. Auch

27 Kapitel 2 Vorgehensmodelle der klassischen Softwareentwicklung 17 hier gilt ähnlich zu den Ausführungen über die Problematiken des Wasserfallmodells dass zu Beginn eines Softwareprojekts kaum alle Anforderungen in allen Einzelheiten bekannt sein können. So ist es nicht verwunderlich, dass Softwareprojekte, deren Vorgehen mit Hilfe des V-Modells geplant werden, oft eine Laufzeit von mehreren Jahren haben Rational Unified Process Auch das 1998 durch die Firma Rational entwickelte Vorgehensmodell Rational Unified Process (RUP) bedient sich schwergewichtiger Methodologie. Der objektorientierte Ansatz des RUP setzt sich dabei aus den best practices der Softwareentwicklung zusammen: neben iterativer, objektorientierter Softwareentwicklung und gutem Anforderungsmanagement, wird Wert auf die visuelle Softwaremodellierung, begleitende Qualitätsprüfung, Use-Case-gesteuerte Softwareentwicklung und kontrolliertes Änderungsmanagement gesetzt. UML als Sprache des RUP dokumentiert das Projekt und erstellt Artefakte als Grundlage. Der Softwareentwicklungsprozess wird in vier Phasen (Konzeptions-, Entwurfs-, Implementierungs- und Auslieferungsphase) aufgeteilt, wobei jede Phase mit speziellen Meilensteinen 7 abgeschlossen wird. In jeder Phase werden Kernarbeitsschritte (Core Workflows) 8 und unterstützende Arbeitsschritte (Supporting Workflows) 9 mit unterschiedlichem Arbeitsaufwand bearbeitet. In jeder Phase werden mehrere inkrementelle Iterationen durchlaufen, die zum Teil ähnlich zum Vorgang im Wasserfallmodell abgearbeitet werden. Ähnlich zur Anpassung des V-Modells dem Tailoring muss auch der Rational Unified Process an ein konkretes Projekt angepasst werden. Der komplette RUP sieht mehr als 30 Rollen und 130 Aktivitäten vor, die erzeugt, dokumentiert und verwaltet werden müssen. Auch wenn der inkrementelliterative Ansatz des RUP für mittlere bis große Softwareentwicklungsprojekte gute Planungsund Dokumentationssicherheiten bietet, so ist auch er mit seinen Phasen, Meilensteinen und vordefinierten Workflows starr hinsichtlich der Anpassung an neue Kundenwünsche, Softwareanforderungen oder Technologiewechsel. Vorgehensmodelle mit klar voneinander abgegrenzten und linear abzuarbeitenden Phasen sind nicht nur für kleine bis mittlere Softwareentwicklungsprojekte unrealistisch. Die Realität der Softwareentwicklung ist inkrementell-iterativ. Weder können alle Anforderungen zu Beginn der Planung eines Softwaresystems aufgenommen werden (da sie zum Teil noch nicht offensichtlich sind), noch ist es möglich ohne Rückschritte zu vorhergehenden Phasen durch den Softwareentwicklungsprozess zu schreiten. Agile Methoden der Softwareentwicklung versprechen den Softwarearchitekten und -entwicklern mehr Freiheiten und Gestaltungsmöglichkeiten, den Kunden frühe Prototypen und eine starke Einbindung in den Prozess der Softwareerstellung. 7 Die vier Meilensteine des RUP sind: Life Cycle Objective Milestone, Life Cycle Architecture Milestone, Initial Operational Capability Milestone und Release Milestone. 8 Die Kernarbeitsschritte des RUP sind 1) Geschäftsprozessmodellierung, 2) Anforderungsanalyse, 3) Analyse & Design, 4) Implementierung, 5) Test und 6) Auslieferung. 9 Als unterstützende Arbeitsschritte werden im RUP 1) Konfigurations- und Änderungsmanagement, 2) Projektmanagement und 3) Infrastruktur aufgezeigt.

28 18 Methoden der Softwareentwicklung und deren Vorgehensmodelle 2.4 Vorgehensmodelle der agilen Softwareentwicklung Agile Methoden der Softwareentwicklung entstanden als Gegenbewegung zu den klassischen, hoch bürokratisierten und ingenieurmäßigen Methoden, deren Ziel es ist, Softwareentwicklung in das Korsett eines festen Plans zu zwängen. Die bekannten Vorgehensmodelle der agilen Softwareentwicklung sind unter anderem: Lean Software Development (LSD), Scrum, Adaptive Software Development (ASD), Crystal, Feature Driven Development (FDD) und Extreme Programming (XP). Die agile Methodik legt größeren Wert auf die kooperative Zusammenarbeit zwischen Kunden und Entwicklern als auf die Aushandlung eines unumstößlichen Vertrages; zugunsten einer höheren Flexibilität wird auf eine detaillierte Dokumentation der Anforderungen zu einem bestimmten Projektstart verzichtet und die Änderung bestehender Anforderungen von Anfang an eingeplant. Manche agile Methoden beschreiben den prinzipiellen Gesamtablauf ähnlich wie klassische Methoden durch eine Abfolge von Phasen, deren zeitliche Ausführung jedoch nicht so strikt vorgegeben ist und zwischen denen agil gewechselt werden kann. Andere Vorgehensmodelle arbeiten mit einem Wertemodell, grundlegenden Techniken und Prinzipien. Wichtigstes Anliegen aller agilen Modelle ist jedoch dem Kunden möglichst schnell einen wirtschaftlichen Nutzen zu bringen, wobei der primäre Fokus auf den Funktionalitäten liegt, die für den Kunden am wichtigsten sind. Erst in späteren Entwicklungsschritten kommen sekundäre Funktionen hinzu, die vom Kunden jederzeit spezifiziert werden können. Vorgehensmodelle der leichtgewichtigen, agilen Softwareentwicklung können positiv auf die Ausbildung von Studenten der Informatik wirken. Neben der Vermittlung bekannter klassischer Methoden, ihres Vorgehens und den bekannten Dokumenten zur gegenseitigen Auftragsbeschreibung sollten in geeigneten Veranstaltungen die aktuellen wirtschaftlichen Tendenzen in der Softwaretechnik gelehrt werden, um die Studenten besser auf ihre zukünftige Tätigkeit vorzubereiten. Die zentralen Techniken der agilen Softwareentwicklung automatisiertes Testen, Pair Programming, kurze Iterationszyklen und starke Kundeneinbindung werden bereits in vielen großen Firmen eingesetzt und scheinen auch außerhalb spezifischer Vorgehensmodelle die Fach- und Methodenkompetenzen besser herauszubilden, zu deutlich besserer Codequalität zu führen und die Entwickler in sozialen Fähigkeiten stärker zu trainieren. Die folgenden Abschnitte geben Einblicke in die verschiedenen Ansätze zur agilen Softwareentwicklung und führen die zentralen Werte und Praktiken der modernen Softwareentwicklung ein Lean Software Development Lean Software Development (LSD) ist die Anwendung der Techniken des Lean Management in der Softwareentwicklung. Lean Management (LM) bedeutet die Steigerung von Effizienz durch den Verzicht von Ballast und Abfall und kommt aus Japan. Die Verschlankung der Produktion wurde bekannt durch Taichii Ohno und Shigeo Shingo am Beispiel des Toyota Pruduction System (vgl. auch [Ohn88, Shi92, Mon98]).

29 Kapitel 2 Vorgehensmodelle der agilen Softwareentwicklung 19 Tom und Mary Poppendieck übertragen in [PP03] die Ansätze des Lean Management auf die Softwareentwicklung. Die Verschlankung betrifft im LSD nicht das Team, sondern die Entscheidungen, wie, wann und was das Team genau tut. Lean Software Development baut auf sieben einfachen und dennoch wirksamen Prinzipien auf, die sich in abgewandelter Form, unter anderem Namen und mit zum Teil reduzierten oder erweiterten Aussagen wie ein rotes Band durch die Theorie der agilen Softwareentwicklung ziehen: 1. Eliminiere Abfall 2. Lerne kontinuierlich 3. Entscheide spät 4. Liefere schnell 5. Baue Integrität ein 6. Stärke das Team 7. Sieh das Ganze Besonders bemerkenswert ist eine von Poppendieck angeführte Studie von Jim Johnson auf der XP-Konferenz 2002 (vgl. dazu [Joh03]). Demnach werden 64% der Features und Funktionen eines typischen Softwareprodukts nie oder nur selten genutzt. Nur 20% werden oft oder stetig genutzt (siehe Abbildung 2.7). Niemals 45% Selten 19% Manchmal 16% Oft 13% Immer 7% 5% 10% 15% 20% 25% 30% 35% 40% 45% Abbildung 2.7: Features und Funktionen, die in einem typischen System genutzt werden Neben den so genannten Extra-Features gehören jedoch laut Poppendieck auch a) halb beendete Arbeit, b) übermäßige Dokumentation, c) Task-Switching sowie d) Verspätungen und Defekte zu den Abfällen der Softwareentwicklung. Durch die willentliche und konsequente Orientierung am Auftrag, der schnellen und lokalen Kommunikation vor Ort sowie dem Verzicht auf überbordende Dokumentation kann mit Hilfe von LSD schneller und effektiver zu funktionaler und korrekter Software gekommen werden.

30 20 Methoden der Softwareentwicklung und deren Vorgehensmodelle Lean Software Development ist keine Softwareentwicklungmethode, sondern ein Vorgehensmodell, eine Art zu denken und zu handeln. Je nach dem betreffenden Problem gibt es Unterstützungswerkzeuge und -modelle, die das Team unterstützen. Feature Driven Development (vgl. Abschnitt 2.4.5) und Extreme Programming (siehe Kapitel 3) wenden das schlanke Denken des Lean Management in ähnlicher Art und Weise auf die agile Softwareentwicklung an Adaptive Software Development Das von Jim Highsmith vorgestellte Adaptive Software Development (ASD) (siehe dazu auch [Hig00]) ist streng genommen eher eine philosophische Sicht auf die agile Softwareentwicklung als eine konkrete Methodik. ASD erfindet die Softwareentwicklung nicht neu 10, sondern reagierte auf die Überbürokratisierung in den klassischen Modellen. Entsprechend dem Manifesto for Agile Software Development (vgl. Anhang A) geht Highsmith davon aus, dass starre Abläufe in der Softwareentwicklung die Anpassung an die sich ständig ändernden Anforderungen des Marktes verhindern. Als Schlussfolgerung dieser Annahmen werden in ASD die Entwicklungsprozesse nur so weit geplant, wie es gerade notwendig ist. Adaptive Software Development bedeutet jedoch nicht den Verzicht auf Planung oder den Einsatz von Entwicklungswerkzeugen. ASD beruht auf der Einhaltung weniger Grundregeln, durch welche die Systemtransformation deutlich einfacher und schneller vonstatten geht. Dieses Phänomen wird als Emergenz bezeichnet (vgl. dazu die Arbeit in [Ste04]). Highsmith setzt in seinen Ausführungen Softwareentwicklung gleich mit Innovation, Problemlösen und Kreativität. In [Hig00] wird ein dreistufiges Framework 11 zur erfolgreichen Durchführung eines adaptiven Softwareprojekts aufgebaut. Dieses muss einer grundlegenden Reglementierung folgen, stets etwas Ungewissheit und Spannung aufkommen lassen, um Kreativität und Motivation im Team zu erzeugen. Highsmith unterscheidet innerhalb von Adaptive Software Development nach: Adaptive Conceptual Model (ACM) Adaptive Development Model (ADM) Adaptive (Leadership-Collaboration) Management Model (AMM) Das konzeptuelle Modell eines adaptiven Projekts (ACM) zeichnet sich vor allem durch die Definition einer Projektmission aus. Dazu stellt man sich am besten die Fragen: 1. Worum geht es im Projekt? 2. Warum sollen wir das Projekt durchführen? und 3. Wie sollen wir das Projekt durchführen? Auch Adaptive Software Development kann nicht vollkommen auf Dokumentation verzichten, Highsmith empfiehlt jedoch die Reduktion auf die Dokumente Project Vision 12, Project Data 10 Im Übrigen machen die wenigsten Neuerfindungen etwas komplett Neuartiges, zumeist wird Bewährtes neu kombiniert oder in einen neuen Kontext gebracht. 11 Highsmith bezeichnet dieses als Adaptive Development Framework (ADF). 12 Die Project Vision beantwortet auf bis zu 10 Seiten die Fragen nach a) dem Hauptvorteil des Projekts, b) den späteren Anwendern, c) dem Projekthintergrund, d) Zeitrahmen, Budget und Personalbedarf sowie e) dem Risko und der Projektvision.

31 Kapitel 2 Vorgehensmodelle der agilen Softwareentwicklung 21 Sheet 13 und Product Specification Outline 14. Oftmals hilft es sich bewusst zu machen, was mit dem Projekt nicht erreicht werden soll und kann, um den zahlreichen anzunehmenden Änderungen in den Anforderungen bereits im Voraus Luft aus den Segeln zu nehmen. Wie bereits angesprochen, stellt Highsmith mit Adaptive Software Development keinen spiralförmig aufwärtsfließenden Wasserfall vor, sondert kombiniert evolutionäre Methoden (siehe Abschnitt 2.3.1) mit dem Verzicht auf strikte Aufgabenverteilung und überbordende Kontrollstrategien. Die klassischen Phasen des iterativen Ansatzes Plan, Revise, Build werden im Adaptive Development Life Cycle (ADLC) zu Speculate, Collaborate und Learn (vgl. Abbildung 2.8). Softwaretechnische Emergenz also soll zur gesuchten Lösung führen. Collaborate Adaptive Development Life Cycle Learn Speculate Abbildung 2.8: Phasen des ADLC Die Speculate-Phase drückt die vorhersehende Abänderung des Plans aus und distanziert sich somit deutlich von der klassischen Planungsphase. Nur durch die Möglichkeit spekulieren zu können, kann in der Collaborate-Phase als Team zusammengearbeitet und das angestrebte Ziel gemeinsam erreicht werden. Die folgende Phase des Lernens beschreibt die Reaktionen auf Tests, Reviews und Befragungen. Das ADM beschreibt, wie die einzelnen Projektzyklen zu organisieren sind und gibt einen verbindlichen Zeitrahmen pro Zyklus vor. Ähnlich zum Konzept des Feature Driven Development (siehe Abschnitt 2.4.5) soll jeder Zyklus ein Stück vorführbare Software hervorbringen. Natürlich benötigt ein solches Projekt einen starken und im Umgang mit Menschen talentierten Projektleiter, da auch kein agiles Softwareprojekt vollständig auf Hierarchieebenen verzichten kann (vgl. dazu auch [Hig00, S. 264 ff.]). Doch bereits die Bezeichnung des Management Modells als Leadership-Collaboration-Modell drückt aus, dass es nicht Befehle oder eine starre Kontrolle, sondern Zusammenarbeit, Gemeinschaft und Führung sind, die zur Erreichung des 13 Das Product Data Sheet fasst auf einer Seite die wichtigsten Fakten zum Projekt zusammen. Zumeist stellt sich die Erstellung des Dokuments als sehr schwierig heraus. 14 Die Product Specification Outline steckt den Projektrahmen ab und nennt oftmals Punkte, die vom Projekt nicht realisiert werden und was das Projekt nicht ist. Auf zu detaillierte Spezifikationen ist jedoch auf Grund der anzunehmenden Änderungen zu verzichten.

32 22 Methoden der Softwareentwicklung und deren Vorgehensmodelle Ziels, einem starken Team und vielleicht sogar zum angestrebten Ziel der softwaretechnischen Emergenz beitragen Methodenfamilie Crystal Crystal ist eine agile Familie von Softwareentwicklungsmethoden, die von Alistair Cockburn in [Coc01] eingeführt wurde. Die Mitglieder der Familie werden mit Farben bezeichnet (vgl. Abbildung 2.9), die einfachste Variante heißt Crystal Clear. Risko L6 L20 L40 L80 E6 E20 E40 E80 D6 D20 D40 D80 C6 C20 C40 C80 Beteiligte clear yellow orange red Abbildung 2.9: Varianten der Crystal Family Crystal ist nicht eine Methode zur Softwareentwicklung, sondern ein vielfältiges Repertoire von Vorgehensvarianten, die je nach Projektauftrag, -größe und Risiko passgenau ausgewählt werden können. Risiken eines Softwareprojekts teilt die Crystal Familie in 4 Stufen ein: 1. Verlust von Kundenzufriedenheit (C; Loss of Comfort), 2. Verlust von bestimmten Geld-Einnahmen (D, Loss of discretionary monies), 3. Gefährdung der Firmenexistenz (E, Loss of essential monies) und 4. Verlust von Leben (L, Loss of Life). Weiterhin wird die Größe des Entwicklerteams in die Auswahl der richtige Variante mit einbezogen: Ein Projekt mit 20 Personen und geringem Risko (C20) wäre demnach mit der Variante Crystal Yellow gut beraten. Cockburn beschreibt die Softwareentwicklung als cooperative game of Invention and Communication [Coc01, S. 34]. Ziel eines guten Projektmanagement muss es ein, dieses Spiel zu gewinnen und am Ende alle Mitspieler im Team halten zu können. Auf dem Weg zum erfolgreichen Ende des Projekts sind Menschen, Kommunikation und Effizienz die Schlüssel zum Erfolg. Während kleine Teams die Möglichkeit zur spontanen und agilen Kommunikati-

33 Kapitel 2 Vorgehensmodelle der agilen Softwareentwicklung 23 on am Arbeitsplatz haben, ergeben sich in einem 80-Mann-Projekt klare Anforderungen an kontrolliertes Kommunikations- und Dokumentationsmanagement. Zentral für das Verständnis von Crystal (und auch dem Verständnis agiler Methoden im Ganzen) sind Cockburn s 7 Prinzipien zur Entwicklung neuer Methoden der Softwareentwicklung: 1. Interaktive, persönliche Kommunikation ist die billigste und schnellste Art des Informationsaustauschs! 2. Übergewichtige Methoden sind teuer! 3. Je größer das Team, desto schwerer die Methode! 4. Je kritischer ein Projekt, desto schwerer die Methode! 5. Je mehr Feedback und Kommunikation stattfinden, desto geringer ist die Notwendigkeit für Dokumentation! 6. Unterscheide Disziplin, Fähigkeiten und Wissen von Prozessen, Formalismus und Dokumentation! 7. Effizienz ist erweiterbar in Aktivitäten! Die Crystal Methodenfamilie gibt keine konkreten Arbeitsweisen vor, sondern beschreibt auf einer Metaebene Handlungsempfehlungen für das Projektmanagement. Durch die Kombination der Kriterien Projektgröße und Risiko und der damit verbundenen spezifischen Variante ist eine schnelle Anpassung der Methodik an die Projektumstände gegeben, ohne dass man lange aushandeln müsste, welche Regeln denn im vorliegenden Fall angewendet werden müssen. Crystal gibt jedoch noch immer genügend Spielraum, um bei der letztendlichen Implementierung Teile von XP (siehe Kapitel 3) oder von klassischen Methoden zu übernehmen. Die Unterstützung von Crystal zeigt sich vor allem in der Kooperation und Kommunikation der Projektmitglieder, der Auslieferung funktionierender Software und der Möglichkeit aufbauender Projekte durch ausreichende Dokumentation Scrum Scrum ist eine Ansammlung von Projektmanagement-Techniken, um mit kontinuierlichen Änderungen der Anforderungen in Softwareprojekten umzugehen. Es besteht dabei aus einer Serie von Sprints. Sprints sind meist 30-tägige Iterationen an deren Ende ein lauffähiges Produkt vorliegt, das dem Kunden ausgeliefert werden könnte. Oft wird Scrum als Erfindung von Ken Schwaber und Mike Beedle (vgl. dazu [SB01]) angesehen. Dabei wurde Scrum als Vorgehensmethode zur Softwareentwicklung erstmals 1990 von Peter DeGrace in [DS90] beschrieben. Scrum trifft sehr wenige Festlegungen hinsichtlich der Projektorganisation und überlässt den Entwicklerteams die Auswahl der einzusetzenden Methoden zur Softwareentwicklung. Dabei nimmt Scrum an, dass der Prozess der Softwareentwicklung so komplex ist, dass er sich im Voraus nicht in Phasen oder konsekutive Schritte einteilen lässt. Die Scrum-Philosophie geht davon aus, dass sich die besten Arbeitsergebnisse durch relative Selbstorganisation kleiner Teams im Rahmen einer äußeren zeitlichen Beschränkung erzielen lassen.

34 24 Methoden der Softwareentwicklung und deren Vorgehensmodelle Scrum knüpft an Grundpositionen des Lean Management (vgl. den Abschnitt zu Lean Software Development, 2.4.1) und legt im Gegensatz zu den klassischen Softwareentwicklungsmethoden starken Fokus auf das Team und die einzelnen Personen. Scrum kennt drei zentrale Rollen: 1. den Product-Owner, 2. das Team und 3. den Scrum-Master. Letzterer hat die Aufgabe Rollen und Rechte an das Team zu vergeben; er ist kein Team- Mitglied und kein Vermittler. Team und Product-Owner kommunizieren selbstorganisiert und direkt miteinander. Das so genannte Product-Backlog enthält während aller Iterationen die vom Kunden gewünschten Leistungsmerkmale und die daraus resultierenden technischen Abhängigkeiten. Durch die Aktualisierung des Product-Backlogs zu Beginn jedes Sprints kann auf veränderte Prioritäten, hinzugekommene oder weggefallene Anforderungen des Projekts rasch reagiert werden. Typischer Weise setzen sich Scrum-Teams aus fünf bis acht Personen zusammen, was die Größe eines durchführbaren Projekts zu stark einschränken würde. Die Lösung ergibt sich durch den Einsatz mehrerer Teams, die gleichzeitig mit ihren Sprints starten. Durch den primären Fokus auf die Managementebene der Softwareentwicklung, lässt sich Scrum leicht mit anderen agilen Methoden kombinieren, die Entwicklungspraktiken fokussieren. So sind bereits mehrfach Kombinationen von Aktivitäten des Extreme Programming (siehe Abschnitt 2.4.6) und Scrum erfolgreich durchgeführt worden und neue Produkte wie 15 oder Agile Enterprise (AE) 16 entstanden Feature Driven Development Feature Driven Development (FDD) ist eine kundenorientierte Softwareentwicklungsmethode, die ihre Agilität in kurzen Entwicklungsschritten, starker Zentrierung des Menschen und zahlreicher kleiner Software-Releases zeigt. Angetrieben von immer kürzer werdenden Entwicklungszyklen, Softwareprodukten, die zum Abschluss ihrer Entwicklung nicht mehr den Marktbefürfnissen entsprechen und zunehmender Frustration von Entwicklern in großen Softwareprojekten entwickelten Peter Coad und Jeff De Luca Mitte der 1990er Jahre die Entwicklungsmethode, welche sich an Features 17 und somit dem Kunden orientiert (vgl. dazu [Luc06]). Ausgelegt ist FDD für den Einsatz einer objektorientierteten Programmiersprache und UML als Modellierungssprache. FDD orientiert sich stark an den Kundenwünschen und versucht gleichzeitig die Motivation der Programmierer über den gesamten Projektverlauf hoch zu halten. Durch die Umsetzung von kleinen Teilresultaten für die nicht mehr als zwei Wochen benötigt werden dürfen 15 ist ein Produkt von Ken Schwaber und Martin Fowler und wurde zuerst erfolgreich bei der Trans Canada Pipeline Ltd. eingeführt. Siehe dazu auch [Met06]. 16 Agile Enterprise (zuvor XBreed) ist eine Mischung aus Extreme Programming, Scrum und anderen Methodiken der Softwareentwicklung. Entwickelt wurde AE von Mike Beedle (vgl. [Bee06]), um wiederverwendbare Software in Rekordzeit zu entwickeln. 17 Features sind nach [CLL99] small useful in the eyes of the client results.

35 Kapitel 2 Vorgehensmodelle der agilen Softwareentwicklung 25 werden häufig brauchbare und sichtbare Resultate erzeugt. Dieser Umstand ist sowohl für die Dokumentation des Projektfortschritts beim Kunden als auch die Motivation der Programmierer sehr wichtig. Darüber hinaus lässt sich der Aufwand für feingranulare Ziele besser schätzen und führt somit implizit zu einer besseren Projektkontrolle. Auch die Autoren von FDD orientieren sich am Manifesto for Agile Software Development (siehe Kapitel A) und sprechen sich gegen eine Überspezifikation des Softwareentwicklungsprozesses aus. Auf die Ausrichtung an einer groben Prozessabfolge wird dennoch nicht verzichtet. Zum einen findet dies Begründung in der Herausbildung eines guten Prozessdenkens bei den Projektbeteiligten, zum anderen im Setzen von Prioritäten und letztlich in der vereinfachten Einarbeitung neuer Projektmitarbeiter. Der FDD-Prozess wird nach dem ETVX-Template 18 beschrieben und beinhaltet die fünf Prozesse in Abbildung Gesamtmodell entwicklen Feature-Liste aufstellen Planung je Feature Design je Design Feature je Design Feature je Feature Implementierung Implementierung je Feature Implementierung je Feature je Feature Abbildung 2.10: Die Prozessabfolge beim Feature Driven Development Dabei ist zu beachten, dass die ersten drei Prozesse nur einmal für das gesamte Projekt durchgeführt werden. Die beiden letzten Schritte werden hingegen für jedes identifizierte Feature erneut durchgeführt. Dabei werden Features in FDD nach einem speziellen Template beschrieben: <a c t i o n > t h e <r e s u l t > <by f o r o f to> a ( n ) <o b j e c t > Beispiele für derartige Features sind: Calculate the total of a sale. Calculate the total purchase of a customer. Einzelne Features können zu einem Feature Set gruppiert werden. Auch dafür kommt ein eigenes Template zur Anwendung. <a c t i o n > < ing > a ( n ) <o b j e c t > So könnte ein Feature Set zum Beispiel making a product sale sein. Die letzte und höchste Abstraktionsstufe in FDD wird als Major Feature Set beschrieben und folgt der Namenskonvention, <o b j e c t > management 18 ETVX steht für Entry, Tasks, Verification, Exit und umfasst die Schritte: 1.) Entry: Vorbedingungen des Prozesses 2.) Tasks: Liste der Aufgaben, die im Prozess durchgeführt werden müssen 3.) Verification: Mittel, wie die Umsetzung des Prozesses nachgehalten werden kann und 4.) Exit: Schlussbedingungen und Ergebnisse des Prozesses

36 26 Methoden der Softwareentwicklung und deren Vorgehensmodelle also beispielsweise: sales management. Als agiler Prozess der Softwareentwicklung ist FDD personenzentriert. Die zentralen Rollen sind hierbei der Chefprogrammierer (chief programmer), die Klassenverantwortlichen (class owner) sowie das Feature Team. Der Chefprogrammierer leitet ein Feature Team während der zwei Wochen der Implementierung, stellt die Teams je nach Klasse zusammen und bestimmt Klassenverantwortliche. Er trägt die Verantwortung für Implementierung und Test des zu entwickelnden Features. Für jede einzelne Klasse der Applikation gibt es einen einzelnen Klassenverantwortlichen, der diese Klasse entwirft und implementiert. Durch dieses Konzept gibt es eindeutige Kompetenzen innerhalb des Teams und stets einen Ansprechpartner im Falle von auftretenden Fehlern. Ein Feature Team besteht höchstens zwei Wochen in einer gleichen Konstellation. Klassenverantwortliche können dabei Mitglied in mehreren Teams sein (vgl. Abbildung 2.11). Für jede Iteration der Prozesse 4 und 5 in Abbildung 2.10 werden die Feature Teams neu zusammengesetzt. Abbildung 2.11: Die Bildung von Feature Teams in FDD FDD scheint auf den ersten Blick wenig mit agilen Methodiken zu tun zu haben, da es sich an festen Prozessen und Plänen orientiert. Das Manifest für agile Softwareentwicklung besagt jedoch nicht, dass man in der agilen Softwareentwicklung nicht planen soll, sondern offen für Änderungen und Anpassungen sein sollte. Feature Driven Development bietet durch seine Kundenorientierung und Featurezentrierung die Möglichkeit schnell und unkompliziert neue Anforderungen in den Arbeitsprozess zu integrieren. Darüber hinaus steigert das Rotationsprinzip die Motivation der Teammitglieder und senkt das Risiko einer überlangen Projektdauer. Für den Einsatz in studentischen Projekten, zur Verbesserung sozialer und methodischer Kompetenzen wird die regelmäßig Rotation der Projektbeteiligten dringend empfohlen (vgl. dazu auch die Ausführungen in 7.2.1) Extreme Programming Extreme Programming (XP) ist das wohl am besten dokumentierte und meist untersuchte agile Vorgehensmodell zur Softwareentwicklung (vgl. [Mar03, S. 18]). Anders als die meisten anderen hier vorgestellten Methoden regelt Extreme Programming nicht den genauen Ablauf eines Projekts. XP legt eine Menge von flexiblen Aktivitäten fest, über deren Abfolge, Intensität

37 Kapitel 2 Was bieten agile Methoden? 27 und Einsatz die Entwickler und Projektleiter situativ entscheiden können. Eine umfassende Vorstellung der XP-Paradigmen findet sich in Kapitel Was bieten agile Methoden? Jens Coldewey beschreibt in [Col02] die Philosophie agiler Methoden mit der Installation so genannter Meta-Pozesse, die die Softwareentwicklung mehr oder weniger offen durch das Team gestaltbar machen. Allen vorgestellten agilen Methoden liegen diese Meta-Prozesse zu Grunde, weshalb oft von einer Familie agiler Softwareentwicklungsmethoden gesprochen wird, was die Ähnlichkeiten zwischen diesen Methoden erklärt. Doch hinter derselben Idee Kollaboration statt Formalismus, kurze Inkremente statt jahrelanger Meditation, Flexibilität statt Planungsorgien, Einbindung des Kunden statt Absicherung [ebd., S. 76] stehen sehr unterschiedliche Geschwister, die jedes für sich in bestimmten Umgebungen besser einsetzbar sind, als in anderen. Eine neue Technologie (hier ist es eine neue Familie von Softwareentwicklungsmethoden) muss nach McLuhan Antworten auf vier zentrale Fragen geben können (siehe auch [MM88]): Was erweitern oder verbessern agile Methoden? Agile Methoden verknüpfen die Entwicklung von Softwaresystemen viel stärker mit den tatsächlichen Vorgängen des Kunden; eine Abkehr vom ingenieurmäßigen Vorgehen, hin zu einer flexiblen und schnell reagierenden Entwicklung deckt sich besser mit divergierenden Anforderungen, veränderten Zeitplänen und einer andauernden Anforderungsanalyse. Was wird durch agile Methoden überflüssig? Klassische Methoden zeichnen sich oft durch langwierige Planungen, nicht eingehaltene Fristen, überlange Projektdauer und überholter Anforderungen zu Projektabschluss aus. Die Anwendung agiler Methoden muss einhergehen mit einem Umdenken bei den Entwicklern und vor allem den Kunden. Auf ein dickes Projekthandbuch oder die Verhandlungen um Preise und Liefertermine zu verzichten, bedeutet nicht den Verlust an Sicherheit oder Seriosität, sondern erhöht die Chancen auf die termingerechte, hochwertige Lieferung des gewünschten Produkts. Was kommt durch agile Methoden zurück? Der Faktor Mensch und die direkte, persönliche Kommunikation wird durch agile Methoden wieder in den Mittelpunkt der Softwareentwicklung gestellt. Die Loslösung von einengenden Plänen fordert wieder die Kreativität aller Projektbeteiligten, die in klassischen Projekten oftmals verloren gegangen und durch die bloße Abarbeitung des Plans verdrängt zu sein scheint. Welche unbeabsichtigten Konsequenzen könnten agile Methoden auslösen? Letztendlich steht und fällt jede neue Technologie und jeder Ansatz zu effektiverer Softwareentwicklung mit den Menschen, die sie anwenden. Unter dem Deckmantel der Agilität und aus reiner Bequemlichkeit könnte auf unliebsame Aktivitäten wie die konsequente testgetriebene Entwicklung oder der ständigen Paararbeit verzichtet werden. Der Einsatz agiler Methoden bringt von sich aus keine engagierteren Entwickler und keine begeistert mitarbeitende Kunden; je-

38 28 Methoden der Softwareentwicklung und deren Vorgehensmodelle der Beteiligte muss vom subjektiven Mehrwert überzeugt werden und dies kann ausschließlich durch positive Erfahrungen beim Einsatz agiler Methoden geschehen. Vorgehensmodelle der Softwareentwicklung ermöglichen die effiziente Planung und Durchführung komplexer Softwareprojekte. Während klassische Ansätze großen Wert auf eine ausgiebige Anforderungsanalyse in Verbindung mit der umfangreichen Dokumentation aller identifizierten Aspekte, Probleme und technischen Lösungsansätze legen, fokussieren agile Methoden eine möglichst flexible Gestaltung der Softwareentwicklung. Die methodische Softwareentwicklung zielt auf die Definition spezifischer Rahmenbedingungen ab, die zu qualitativ hochwertigen Softwareprodukten führen soll die Ansätze unterscheiden sich in ihrer Flexibilität und dem Umgang mit Anforderungsänderungen; das letztliche Ziel ist jedoch gleich. Für die universitäre Vermittlung von Fach- und Methodenkompetenzen in der Softwaretechnik ist die Integration der verschiedenen Ausbildungsansätze in reale, wirtschaftliche Szenarien ein anstrebenswertes Ziel, da so neben theoretischen Ansätzen vor allem reale Praxiserfahrung vermittelt werden kann. Leider können weder alle Studenten in ihrer universitären Ausbildung in den Genuss real-wirtschaftlicher Softwareprojekte kommen, noch ist es möglich die umfangreichen Praktiken, Prinzipien und Techniken der agilen Softwareentwicklung in praktische Lehrveranstaltungen umzusetzen. Eine ganzheitliche Informatikausbildung sollte jedoch einen Praxisersatz schaffen, der die Vorteile realer Projekte mit realen Anforderungen und echten Problemen so nachbildet, dass den Studenten eine angemessene Vorbereitung auf ihre spätere berufliche Position gegeben wird 19. Die Leistungsfähigkeit agiler Methoden wurde bereits in vielen Praxisprojekten nachgewiesen und entwickelt sich zunehmend zum de facto Standard in der professionellen Softwareentwicklung. Die Einbettung agiler Softwareentwicklung in die universitäre Informatikausbildung verknüpft die traditionelle Vermittlung von softwaretechnischen Werten mit aktuellen praktischen Entwicklungen und scheint sich positiv auf die Kompetenzentwicklung der beteiligten Studenten auszuwirken. Die so erlangte Realitätsnähe kann keinesfalls die unverfälschten Erfahrungen in authentischen Softwareprojekten nachbilden. Doch wie die folgenden Ausführungen zeigen, haben Studenten durch agile Praktiken mehr Freude am Prozess der Softwareentwicklung, finden leichter Zugang zu komplexen Themen der Softwaretechnik und entwickeln bessere Anwendungen in kürzerer Zeit. Entwickler, die Projekte mit Pair Programming durchführten, entwickeln mehr Vertrauen in die eigene Arbeit und trainierten ihre sozialen und kommunikativen Fähigkeiten besser als solche, die klassische Einzelarbeit betrieben. 19 In den Wirtschaftswissenschaften werden seit Jahren so genannte Business Games durchgeführt, die als strategische Simulation faktisches Wissen und Handlungskompetenz vermitteln (siehe auch [Gar95, BGBK01]). Die Übertragung solcher Ansätze in die Informatik ist eine zu evaluierende Möglichkeit der Ausbildung.

39 3 Extreme Programming in der Übersicht 3.1 Personen und Rollen in XP Werte, Prinzipien und Aktivitäten Variablen in Softwareprojekten Werte Prinzipien Aktivitäten Versionsplanung Planspiel, Benutzergeschichten und Storycards Iterationsplanung und Releases Entwicklung Pair Programming Testen Refactoring Dokumentation XP in der universitären Realität Dieses Kapitel führt in die Theorie und Paradigmen des Extreme Programming (XP) ein. XP und andere agile Softwareentwicklungsmethoden haben in der Wirtschaft bereits einen starken Standpunkt, eine Vielzahl von Befürwortern und empirisch belegte Vorteile gegenüber klassischen Vorgehensmodellen (vgl. [Nos98, WU01, MHW03] u.v.m.). Im akademischen Umfeld hingegen haben agile Methoden bis auf wenige Ausnahmen noch nicht denselben Erfolg. Einerseits liegt das wohl an den verschiedenen Anforderungen von wissenschaftlichen Betreuern und Studenten im Vergleich zu wirtschaftlichen Softwareentwicklern, zum anderen an der vermeintlich besser bewertbaren prozessorientierten Softwareentwicklung der klassischen Modelle. Das vorliegende Kapitel gibt eine Übersicht über Extreme Programming im universitären Kontext, stellt die Rollen im und Werte von XP vor und schildert die Versions- und Iterationsplanung. Weiter werden die zentralen Techniken zur Entwicklung in XP-basierten Projekten vorgestellt und die Methodik kritisch in die universitäre Wirklichkeit eingeordnet. Extreme Programming ist ein agiles Modell der Softwareentwicklung und wurde ursprünglich von Kent Beck in Zusammenarbeit mit seinen Kollegen Ward Cunningham und Ron Jeffries entwickelt. Die Kernkonzepte sind in [Bec99] vorgestellt. Im Gegensatz zu vielen 29

40 30 Extreme Programming in der Übersicht anderen agilen Vorgehensmodellen (vgl. die Ausführungen in Abschnitt 2.4) gibt XP konkrete Handlungsempfehlungen zur schnelleren, effektiveren und softwaretechnisch besseren Umsetzung kleiner bis mittlerer Softwareprojekte. Nachdem im Chrysler Comprehensive Compensation Projekt (C3) schwerwiegende Entwicklungsprobleme festgestellt wurden, wurde das gesamte Projekt von Beck und Jeffries unter Zuhilfenahme der XP-Prinzipien neu gestartet. Mit Klassen und über Methoden (vgl. [ABB + 98]) war das C3-Projekt eines der größten XP-Projekte und wurde letztendlich fast rechtzeitig fertig und ist noch heute im Einsatz. Studien beweisen, dass durch den Einsatz von Extreme Programming besserer und lesbarerer Code in weniger Zeit entsteht und die beteiligten Programmierer dabei mehr Spaß haben und mit ihrer eigenen Arbeit zufriedener sind [Nos98]. Doch welche Auswirkungen hat XP auf die Lernerfolge von Studierenden? Kann man die positiven Erkenntnisse der Wirtschaft auf Kompetenzentwicklung und -verstärkung in der universitären Softwareentwicklung übertragen? Zunächst ist es wichtig die Grundfeste der XP-Methodik zu kennen und zu verstehen, um später Aussagen über die Auswirkungen auf Studenten machen zu können. 3.1 Personen und Rollen in XP Das Manifest der agilen Softwareentwicklung von 2001 (siehe Anhang A) stellt Individuen und Kommunikation über Prozesse und Werkzeuge. XP als eine der bekanntesten agilen Methoden legt großen Wert auf die Rolle der Menschen und die Kommunikation innerhalb des Projekts, mit den Kunden und Auftraggebern. Im universitären Kontext bedeutet der Fokus auf Menschen und Kommunikation vor allem höhere Zufriedenheit und Spaß am Projekt auf Seiten der Studierenden (vgl. [Nos98]) sowie einen geringeren Betreuungsaufwand auf Seite der wissenschaftlichen Betreuer (vgl. [WK00b]). Die nachfolgend vorgestellten Rollen und deren Aufgaben innerhalb eines XP-Projekts orientieren sich weitestgehend an den Ausführungen in [Bec03, S. 141 ff.] und [WK00a]. Vom Kunden 1 wird in einem XP-Projekt mehr verlangt als in typischen Softwareentwicklungsprojekten. Zum einen muss er vor Ort sein 2, um den Entwicklern zur Seite zu stehen und die Entwicklungsziele vorzugeben. Zum anderen geschieht dieser Austausch von Anforderungen mittels User-Stories auf so genannten Storycards (vgl. dazu auch Abschnitt 3.3.1). Neben der Formulierung der User-Stories muss der Kunde diese priorisieren und die Reihenfolge der Abarbeitung festlegen. Der Kunde muss Akzeptanztests formulieren, um die Ergebnisse der Entwickler beurteilen zu können und jederzeit für eine offene, ehrliche und kritikfähige Kommunikation mit den Entwicklern offen sein. 1 Diese Arbeit versteht als Kunden im Rahmen von XP-Projekten stets die wissenschaftliche Administration eines Projekts. In universitären Projekten ist der Auftraggeber diejenige Fachgruppe, welche den Auftrag für ein Projekt gibt. 2 Beck bezeichnet diese Bedingung als On-Site Customer. In der vielfältigen Literatur werden oft auch die Begriffe Vor-Ort-Kunde oder Kunde-vor-Ort verwendet.

41 Kapitel 3 Personen und Rollen in XP 31 Die Entwickler müssen in hohem Maße teamfähig sein, um die ständige Interteamkommunikation wie auch die Kommunikation mit Kunden aufrecht zu erhalten. Für die Absolvierung von Pair Programming ist darüber hinaus eine hohe Sozialkompetenz im Sinne einer rationalen und verantwortungsbewussten Koordinierung der gemeinschaftlichen Aufwandsabschätzung und Testplanerstellung von den Entwicklern gefordert (siehe die Ausführungen in Abschnitt 5.2.1). Gerade für nicht besonders kommunikative Personen ist es schwierig in einem XP-Team Fuß zu fassen und eigene Ängste 3 zu überwinden. Jedoch sind auch egozentrische Entwickler, die den eigenen Erfolg über den des Teams stellen nicht für agile Projekte geeignet. Im Kontext von XP ist die Auswahl der richtigen Mitarbeiter also noch schwerer als in einem typischen Softwareprojekt. Die Erziehung zu selbstständiger Arbeit ist nicht nur das Ziel eines Studiums; es ist auch Ziel der agilen Methoden zur Softwareentwicklung. Die zu starke Führung eines XP-Teams verhindert zu einem hohen Maß die Selbstständigkeit und Reflektionsfähigkeit des Teams, weshalb der Projektleiter oder Coach genau über Interventionen nachdenken und sich sorgsam für oder gegen sie entscheiden sollte. Dennoch ist der Coach für die Einhaltung des gesamten Softwareentwicklungsprozesses und die Disziplin im Team zuständig. Der Coach muss mit Feingefühl und Erfahrung wieder die richtige Richtung einschlagen, sollte das Projekt diese verlassen haben. Ebenso muss er die konsequente Einhaltung der XP-Prinzipien überwachen. Der Terminmanager (Tracker) verfolgt ständig den Status des Projekts und sammelt Informationen über den Arbeitsaufwand der einzelnen Entwickler. Der reell geleistete Aufwand muss mit dem geplanten abgeglichen und Abweichungen protokolliert und begründet werden. Bei unerwarteten Verzögerungen ist es Aufgabe des Trackers entsprechende Gegenmaßnahmen einzuleiten. Neben der Schwierigkeit der Gewinnung der Informationen bei den Entwicklern ohne deren Arbeit zu stören, muss der Terminmanager auch ein gutes Gespür für die richtigen Zeiträume zum Vergleich der Kennzahlen besitzen. Wertet er die Zahlen zu spät aus, so kann der Zeitpunkt für ein adäquates Eingreifen bereits verstrichen sein. Wichtige Entscheidungen werden in einem XP-Projekt von Kunde und Entwicklungsteam gleichermaßen getroffen. Zu den Aufgaben des Projektmanagers gehört die Präsentation der Projektergebnisse und die allfällige Verteidigung bei Vorgesetzten. Der Projektmanager als zusätzliches Bindeglied zwischen Management und Entwicklern ist zudem für ein gutes zwischenmenschliches Klima verantwortlich. Dieses soll sich in einem funktionierenden Team durch Angstfreiheit und konstruktive Kritikfähigkeit auszeichnen. Fehler sollten in jedem Fall als Chancen für stetige Lernprozesse und nicht als Rückschläge gesehen werden. Durch die ausgiebigen und ausgefeilten automatisierten Unit-Tests der Entwickler beschränkt sich die Aufgabe der Tester darauf, den Kunden in einem XP-Projekt zu unterstützen. Die Tester formulieren zusammen mit dem Kunden die Akzeptanztests und führen diese gemeinsam mit dem Kunden durch. 3 Gemeint sind hier Ängste sich zu blamieren, veraltete Ansichten zu vertreten, nicht herausragend programmieren zu können oder den hohen Anforderungen nicht gerecht zu werden (siehe dazu auch [San03]).

42 32 Extreme Programming in der Übersicht Nach Beck benötigt ein XP-Projekt eine Vielzahl von Generalisten und wenige Spezialisten [Bec03, S. 146]. Durch die Konzepte des Extreme Programming und vor allem den Einsatz von Pair Programming erfolgt ein breiter Wissens- und Erfahrungsaustausch. Berater spielen daher in XP-Projekten eine eher untergeordnete Rolle und werden nur in seltenen Fällen zur Lösung sehr spezieller Probleme hinzugezogen. In einem solchen Fall ist der Consultant Ansprechpartner für technische Problemstellungen und erarbeitet zusammen mit den Entwicklern Lösungen. Im universitären Umfeld kommen sicher nicht alle der aufgeführten Rollen in einem agilen Softwareprojekt mit Extreme Programming zum Einsatz. Dennoch ist es im Sinne der Vermittlung einer soliden Berufsbefähigung sinnvoll, den Studenten im Laufe eines Projekts verschiedene Rollen mit ihren Aufgaben zuzuteilen. Empfehlenswert ist in jedem Fall die Anwendung 3 zentraler Rollen in universitären Softwareprojekten: Projektleiter, Kunde und natürlich Entwickler sollten unter den Studenten zu finden sein, um einen Begriff für die Agilität der Entwicklung und die spezifischen Aufgaben der einzelnen Rollen zu erhalten. Der folgende Abschnitt führt ein in die grundlegenden Werte, die dem Extreme Programming zu Grunde liegen, beschreibt fundamentale Prinzipien, Techniken und Prinzipien. Die vorgestellten Aspekte sind nicht neu, sie sind ins Extreme geführt, um so eine umfassende Wirkung zu erzielen. Um ein XP-Projekt erfolgreich zu beenden, müssen die alle Beteiligten Kenntnis über diese Aspekte haben, sie bereitwillig akzeptieren und anwenden. 3.2 Werte, Prinzipien und Aktivitäten Extreme Programming wird oft als radikale Variante der Softwareentwicklung dargestellt. Doch bei genauerer Betrachtung ist die Methode eine Sammlung der Best Practices der klassischen und agilen Softwareentwicklung. Ein zumeist falsch verstandener Punkt der XP-Methodik betrifft die Dokumentation: XP isn t about not writing documents it is about writing more effective documentation. In most cases this results in not writing a document, because a more effective form can be used instead [Wel03, S. 6]. Der folgende Abschnitt gibt einen Einblick in die Variablen eines jeden Softwareprojekts, gibt Aufschluss über die zentralen Werte der XP-Philosophie, seine fundamentalen Prinzipien und Entwicklungspraktiken Variablen in Softwareprojekten Die vier Variablen eines jeden Softwareprojekts egal ob nach klassischer oder agiler Methodik sind: 1. Kosten 2. Qualität 3. Entwicklungsdauer 4. Umfang

43 Kapitel 3 Werte, Prinzipien und Aktivitäten 33 Offensichtlich besteht zwischen diesen Faktoren ein fundamentaler Zusammenhang sind drei Faktoren festgelegt, so ist auch der vierte implizit vorgegeben. Als Konsequenz dieser Tatsache (vgl. auch [BF01, Kapitel 7]) können maximal drei Faktoren vom Auftraggeber bestimmt werden. Der Zusammenhang der Faktoren wird oft als Regel bezeichnet und ist unabhängig vom Einsatz von XP. Kent Beck vergleicht das Zusammenspiel der Faktoren mit vier Hebeln einer großen viktorianischen Dampfmaschine (ebd. S. 25f.): bewegt man einen Hebel, so bewegen sich auch die anderen. Jeder beliebige Hebel kann arretiert werden, sind jedoch drei Hebel fest, so ist es auch der vierte. Die Auswirkungen der Hebelbewegungen erfolgen zeitversetzt und nicht-linear. Es ist also nicht möglich die Kosten zu verdoppeln, die anderen Faktoren konstant zu lassen und die Zeit zu halbieren 4. Die Regel kann gut am Teufelsquadrat von Sneed in Abbildung 3.1 verdeutlicht werden. Qualität + + Umfang Entwicklungsdauer Kosten Abbildung 3.1: Das Teufelsquadrat nach Sneed [Sne87] Für den Softwareentwicklungsprozess werden die Faktoren Qualität, Umfang, Entwicklungsdauer und Kosten gemessen und auf den vier Skalen eingetragen. Die abgetragenen Punkte werden verbunden und ergeben die Produktivität als Fläche des Quadrats (grünes Quadrat zur Verdeutlichung einer ausgewogenen Verteilung der 4 Faktoren). Soll das Projekt nun in weniger Zeit eine höhere Softwarequalität erreichen und die Kosten gleich bleiben, so ist dies ausschließlich unter Inkaufnahme eines reduzierten Funktionsumfangs möglich (orange Einfärbung). Da es in studentischen Projekten im universitären Umfeld (zumeist) keine Kosten einzuhalten gilt, bleiben nur die übrigen 3 Faktoren zur Betrachtung. Nach Beck bietet der Hebel Zeit die größten Möglichkeiten zur Anpassung. Doch auch der zeitliche Rahmen ist in studentischen Projekten oft relativ eng vorgegeben. Typischer Weise dauern softwaretechnische Abschlussprojekte ein bis 2 Semester, bei einem durchschnittlichen Aufwand von 12 bis 15 Stunden pro 4 An dieser Stelle sei auf Brooks Gesetz verwiesen: Einem verspäteten Projekt mehr Personen zur Verfügung zu stellen, verspätet es noch mehr. [Bro95]

44 34 Extreme Programming in der Übersicht Woche je Student. Problematisch am Faktor Zeit ist, dass man oft die zur Umsetzung benötigte Zeit unterschätzt oder sich der genauen Problematik nicht bewusst ist. Zusätzliche Zeit kann positive Auswirkungen auf die Qualität haben oder den umsetzbaren Umfang erhöhen. Bei der Variable Qualität muss nach interner und externer Qualität unterschieden werden. Äußere Qualitätsmerkmale sind solche wie die Gestaltung der Benutzeroberfläche, die Performanz des Systems oder auftretende Fehler innere Qualität zeigt sich an der Güte des Designs und er Einfachheit der softwaretechnischen Umsetzung [BF01, S. 27f]. Wird auf innere Qualität verzichtet, so können kurzfristig Zeitzugewinne erzielt werden; langfristig betrachtet wird so die effiziente Erweiterbarkeit des Systems verhindert und so negativer Einfluss auf die anderen 3 Faktoren genommen. Die Qualität eines Softwareprodukts hat direkte Auswirkungen auf die Motivation der Entwickler: je schlechter die Qualität, je mehr Fehler das Produkt besitzt, je unzufriedener der Kunde ist, um so demoralisierter sind die Entwickler. XP führt durch die Besinnung auf zentrale Werte, konsequente Tests und das Einplanen von Veränderungen zu hoch akzeptierten Softwarelösungen, die sowohl hohe interne und externe Qualität aufweisen. Die Entwickler identifizieren sich mit diesem Ergebnis und sind motiviert weiter zu arbeiten. Die Variable Umfang ist der Hebel, der am einfachsten verändert werden kann. Auf der einen Seite haben die Kunden oft (leider) keine genaue Vorstellung, welche Funktionalitäten in einer finalen Softwarelösung umgesetzt sein sollen. Auf der anderen Seite lässt sich durch intelligentes Iterations- und Releasemanagement starken Einfluss auf den Umfang der Anwendung nehmen und reduzierte Funktionen zusammen mit dem Kunden erarbeitet werden. Im universitären Umfeld muss auf Grund der relativen Starrheit in der Entwicklungsdauer und den irrelevanten (wirtschaftlichen) Kosten vor allem Einfluss auf den Umfang des Projekts und der damit verbundenen Funktionsfülle genommen werden. Die wichtigste Schlussfolgerung aus dem fundamentalen Zusammenhang der 4 Variablen Kosten, Qualität, Entwicklungsdauer und Umfang ist der, dass er allen Beteiligten am Prozess der Softwareentwicklung bewusst vor Augen geführt werden muss. Im universitären Umfeld kann nicht davon ausgegangen werden, dass die Entwickler exklusiv am Projekt arbeiten; soll die Arbeit dennoch hohen Qualitätsansprüchen genügen, so muss entweder die Projektdauer verlängert oder der Funktionsumfang verringert werden. XP kann mit seinen Ansätzen helfen, die Zusammenhänge zu transportieren und die Softwareentwicklung so zu vereinfachen Werte Die Ziele von XP sind nicht neu oder kreativ jeder Projektleiter versucht qualitativ hochwertige Software auf effiziente Art und Weise unter Einhaltung aller Budgets zu entwickeln. Neu an Extreme Programming ist die Besinnung auf einige wenige Werte, deren stetige Einhaltung die erfolgreiche Softwareentwicklung unterstützt. Kommunikation, Einfachheit, Feedback, Respekt und Mut sind die zentralen Werte von XP (vgl. [Bec99, Bec03]); ihr Zusammenhang ist in Abbildung 3.2 dargestellt.

45 Kapitel 3 Werte, Prinzipien und Aktivitäten 35 Die meisten Probleme in einem Softwareprojekt können darauf zurückgeführt werden, dass jemand nicht oder nicht ausreichend mit jemand Anderem über eine wichtige Information spricht. Entwickler informieren das Team nicht über eine veränderte Schnittstelle, Projektleiter stellen dem Team nicht die richtigen Fragen oder das Team bekommt die falschen Informationen vom Kunden. Im universitären Bereich sind Studenten seit jeher begründet durch individuelle Bewertungen auf alleinige und individuelle Arbeit konditioniert und wie Gerald M. Weinberg bereits 1971 in The Psychology of Computer Programming feststellt: most programmers would say they preferred to work alone in a place where they wouldn t be disturbed by other people [Wei71]. Doch erst die informelle Diskussion mit anderen Entwicklern z. B. beim Kaffee, Rauchen oder in Pausen ermöglicht den Ideen- und Erfahrungsaustausch, weist auf logische Fehler oder einfachste Erweiterungen hin. Kommunikation ist mehr als ein Bestandteil des XP-Konzepts Kommunikation macht XP erst möglich. Pair Programming, das Planspiel, User-Stories und der Kunde vor Ort bedingen Teammitglieder mit ausgezeichneten kommunikativen Kompetenzen. Einfachheit Kommunikation Respekt Mut Feeback Abbildung 3.2: Zentrale Werte im Konzept des Extreme Programming Gerade im universitären Umfeld ist der zweite Wert des Extreme Programming radikal. Einfachheit in der Softwareentwicklung bedeutet nach der XP-Methode die einfachste Möglichkeit zu wählen, die ausreicht, um ein vorliegendes Problem zu lösen. Es ist alles andere als einfach nicht an die Funktionalitäten zu denken, die später noch Eingang in die Software finden müssen. Es ist jedoch besser etwas Einfaches zu beenden, als etwas Kompliziertes zu beginnen und nie abzuschließen. Die Beschränkung auf die einfachste Möglichkeit bedeutet zwar, dass es bei veränderten Anforderungen unter Umständen zu Neuentwicklungen kommen kann, doch je einfacher die Funktionen, um so schneller kann man sie anpassen. Es besteht ein offensichtlicher kausaler Zusammenhang zwischen Einfachheit und Kommunikation: je einfacher eine Architektur, eine Klasse oder eine einzelne Methode gebaut ist, um so weniger Kommunikationsaufwand muss für die Erklärung der Funktionalität betrieben werden. Je mehr und je besser innerhalb eines Teams kommuniziert wird, um so schneller werden benötigte Funktionen offensichtlich und um so schneller kommen diese in den produktiven Einsatz. Neben mangelnder Kommunikation ist auch fehlendes Feedback für verzögerte und fehlerhafte Softwareprojekte verantwortlich. In XP bekommen sowohl Entwickler als auch Projektleiter und Kunde ständig Feedbacks der Entwickler von seinem Partner beim Pair Programming,

46 36 Extreme Programming in der Übersicht den automatisierten Unit-Tests und die Ergebnisse der Akzeptanztests des Kunden. Der Projektleiter bekommt ebenfalls durch die Akzeptanztests und zusätzlich durch tägliche Stand-up Meetings Einblicke in den Stand des Projekts und die Leistung eines jeden Entwicklers. Der Kunde erhält durch die hohe Zahl an Releases und den engen Kontakt zum Entwicklerteam in regelmäßigen Abständen Feedback. Bei neu zu implementierenden Funktionen des Kunden schätzen die Entwickler sofort den dafür erforderlichen Aufwand an Hand der Storycards. Konkrete Feedbacks ergänzen Kommunikation und Einfachheit, denn je mehr Feedback man bekommt, um so einfacher ist es zu kommunizieren. Sollte jemand aus dem Team Einwände gegen eine bestimmte Komponente haben, so muss er nur einen Testfall ermitteln, der einen Fehler eben dieser Komponente aufdeckt. Einfache Systeme sind einfacher zu testen als komplizierte und ermöglichen eine schnellere Kommunikation. In einem offenen Arbeitsklima fällt es dann auch leichter Feedback zum System zu geben. Die ersten drei Werte des XP-Modells zielen auf die Erhöhung der Entwicklungsgeschwindigkeit ab. Mut in Extreme Programming bedeutet eigenverantwortlich zu handeln, (in der klassischen Softwareentwicklung) unpopuläre Entscheidungen zu treffen und aktiv im Projekt mitzuarbeiten. Es verlangt Mut und Umdenken im eigenen Vorgehen nur Probleme zu lösen, die heute anstehen und nicht in die Zukunft zu sehen. Es erfordert Mut dem Team zu sagen, dass der Code schlecht ist und man Teile davon wegwerfen und neu implementieren sollte. Verantwortungsbewusstsein bedeutet aber auch, den Überblick über den Projektfortschritt zu behalten und sich Änderungen am Code der Teammitglieder zuzutrauen. Wie in Abbildung 3.2 zu sehen, wird Mut von allen anderen Werten in XP gespeist. Kommunikation fördert Mut, da Riskikobereitschaft und Experimentierfreudigkeit unterstützt werden. Auch durch einfache Systeme wird Mut gefördert, da das Risiko der Beschädigung des Systems in einfachen Architekturen viel geringer ist als in komplizierten. Mut wiederum fördert die Einfachheit eines Systems, da man versuchen kann, darf und soll das System zu vereinfachen, sobald man eine Idee dafür hat. Schnelle und konkrete Feedbacks machen Mut, indem man durch einen Tastendruck nach einer umfassenden Codeveränderung sofort sieht, ob sich der Aufwand gelohnt hat. Der Partner im Programmierteam gibt während des gesamten Re-Implementierungsprozesses Feedback und verringert mögliche Defekte. Spätestens am nächsten Tag erfährt man dann im Stand-up Meeting, wie der Rest des Teams auf die Änderungen reagiert. In seiner 2. Auflage des XP-Klassikers Extreme Programming Explained [Bec03] fügt Kent Beck einen fünften und nicht so offensichtlichen Wert zur XP-Methodik hinzu: Respekt. Respekt ist ein tieferer Wert als die anderen vier, er spielt sich unter der Oberfläche des Projekts ab und beeinflusst dennoch die anderen Werte. Wenn sich die Teammitglieder nicht füreinander und die gemeinsame Arbeit interessieren, wird auch ein XP-Projekt scheitern. Diese Aussage lässt sich wahrscheinlich auf alle kollaborativen Arbeitsprozesse ausweiten, doch XP ist in dieser Hinsicht sehr empfindlich. Wird in einem Projekt versucht seine eigene Arbeit über die der Anderen zu stellen oder die Wünsche, User-Stories und Akzeptanztests des Kunden nicht ernst zu nehmen oder wird im universitären Bereich das individuell ausgerichtete Programmierverhalten nicht abgelegt, so kann nichts in der Welt dieses Projekt zu einem erfolgreichen Ziel führen.

47 Kapitel 3 Werte, Prinzipien und Aktivitäten 37 Der kommende Abschnitt versucht den genannten abstrakten Werten konkrete, nachvollziehbare Richtlinien hinzuzufügen, um die Werte des Extreme Programming in Aktivitäten aufgehen zu lassen Prinzipien Kommunikation, Einfachheit, Feedback, Mut und Respekt sind zu abstrakt und vage, um in der Praxis umgesetzt zu werden. Daher wurden aus ihnen konkrete Prinzipien abgeleitet, die helfen sollen die Werte in die Praxis umzusetzen und zu konkretisieren. Diese lassen sich in fundamentale und sekundäre Prinzipien einteilen. Die Grundprinzipien sind: Unmittelbares Feedback (Rapid Feedback) Aus der Lernpsychologie weiß man, dass der zeitliche Abstand zwischen Aktion und Feedback eine entscheidende Rolle für den Lernerfolg spielt [WRL05, S. 6]. Daher lautet eines der fundamentalen Prinzipien möglichst schnell Feedback zu geben und zu berücksichtigen. Je eher man über eine falsche Entwicklungsrichtung informiert wird, um so besser kann das Projekt gesteuert und Anforderungen besser priorisiert werden. Einfachheit anstreben (Assume Simplicity) In der klassischen Vermittlung von Methoden und Techniken der Softwareentwicklung wird großen Wert auf die Planung zukünftiger Ereignisse gelegt. Durch einen möglichst komplexen, alles umfassenden Plan zu Beginn der Implementierung sollen möglichst alle Benutzungsfälle abgedeckt werden. Kernaussage der agilen Vorgehensmodelle und auch Realität jeglicher Art von Softwarekonstruktion ist jedoch die Unvorhersagbarkeit zukünftiger Ereignisse. Die Beschränkung auf die einfachste momentane Lösung für eine gegebene Anforderung stellt die meisten Entwickler zunächst vor Probleme, sichert jedoch nachhaltig die Änder- und Erweiterbarkeit der Lösung durch bestechende Einfachkeit, Klarheit und Eleganz des Codes. Inkrementelle Veränderung (Incremental Change) Selbst unter Berücksichtigung des Einfachheits-Prinzips entstehen mit zunehmender Projektdauer relativ komplexe Softwaresysteme. Es liegt in der Natur der Sache, dass Änderungen Nebeneffekte mit sich bringen, die nicht gewünscht sind. Große Veränderungen bedeuten demnach eine Vielzahl möglicher Nebeneffekte; kleine, inkrementelle Änderungen minimieren das Risiko der Beschädigung des Systems und erlauben einen messbaren Fortschritt. Kent Beck schreibt in [Bec03, S. 38]: Sogar in der Schweiz, dem Zentrum pedantischer Planung [...] versucht man nicht, radikale Veränderungen vorzunehmen. Veränderungen wollen (Embracing Change) Fortschritt bedeutet Veränderung. Diese kollektive Weisheit bedeutet gerade im Kontext agiler Softwareentwicklung mit Extreme Programming, dass Entwickler neue Arbeitsweisen (Pair Programming, Planspiel, kurze Iterationen) akzeptieren, ihre comfort zone [WK00b, S. 10] verlassen und sogar Rückschläge akzeptieren

48 38 Extreme Programming in der Übersicht müssen. Für wissenschaftliche Betreuer eines XP-Projekts bedeutet die Zuwendung zu XP ein Umdenken in der Bewertung von Studenten, einen teilweise erhöhten Betreuungsaufwand (öftere Treffen, Simulation des Kunden, Nachhalten der einzelnen Aktivitäten) aber auch die Vermittlung besserer Fähigkeiten in Kommunikation, Implementierung und sozialen Kompetenzen. Qualitätsarbeit (Quality Work) Von den Variablen eines Softwareprojekts in Abschnitt ist Qualität keine wirklich freie. Absichtlich will kein Programmierer schlechte Software entwickeln, sondern den eigenen Anspruch der inneren Qualität mit den Qualitätsansprüchen des Kunden abgleichen. Die weiteren, sekundären XP-Prinzipien ermöglichen die Entscheidung, was in einer speziellen Situation zu tun ist und heißen: Lernen lehren (Teach Learning) Kleine Anfangsinvestition (Small Initial Investment) Spielen, um zu gewinnen (Play to win) Gezielte Experimente (Concrete Experiments) Offene, ehrliche Kommunikation (Open, honest Communication) Die Instinkte der Mitarbeiter nutzen, nicht dagegen arbeiten (Work with people s instincts, not against them) Verantwortung übernehmen (Accepted Responsibility) An örtliche Gegebenheiten anpassen (Local Adaptions) Mit leichtem Gepäck reisen (Travel light) Ehrliches Messen (Honest Measurement) Lernen lehren findet sich in den Beschreibungen vieler agiler Methoden wieder (z. B. beim Adaptive Software Development, Seite 20) und drückt einen Prozess individueller Verbesserung aus. In der Vermittlung einzelner Konzepte soll Abstand genommen werden von doktrinären Aussagen. So sollen die Entwickler durch einen ständigen Lernprozess wissen, welches die angemessene Zahl von Tests ist, um genügend Feedback über den Zustand des Systems zu bekommen, anstatt vom Projektleiter den Auftrag zu bekommen, eine bestimmte Anzahl zu implementieren. Große Budgets verleiten dazu die Anforderungen an ein Projekt zu hoch anzusetzen und nicht den Weg der einfachsten momentanen Lösung zu beschreiten. Kleine Anfangsinvestitionen bringen eine Fokussierung auf die wichtigsten Aspekte des Projekts und vermeiden so oft ein auswüchsiges, nicht zu beendendes Projekt. Die Philosophie in XP-Teams muss darauf aus sein das Spiel zu gewinnen 5. In der klassischen Softwareentwicklung wurde zu oft gespielt, um nicht zu verlieren. Während ein XP-Team offensiv versucht die anstehenden Aufgaben zu bewältigen, versuchen klassische Teams oft 5 Natürlich ist es auch in klassischen Softwareprojekten das Ziel, die Anforderungen zu erfüllen. Die Softwareentwicklung als Spiel zu sehen, in dem man einen Zug gewinnt und einen anderen eventuell nicht, kommt erst durch die agilen Methoden klar zum Ausdruck (vgl. Alistair Cockburn auf Seite 22).

49 Kapitel 3 Werte, Prinzipien und Aktivitäten 39 nur keine Fehler zu machen und nach Vorschrift zu entwickeln. Klassische Teams schreiben Dokumentationen, halten Meetings ab und schieben sich gegenseitig Verantwortlichkeiten hin und her, nur um beim Scheitern sagen zu können, sie seien sich keiner Schuld bewusst. Das offensive XP-Team wird natürlich Fehler machen, es nimmt diese jedoch als Grundlage für eine Verbesserung, es lernt aus den Fehlern. Sollte das Projekt trotz allem nicht mehr gewonnen werden können, so wird der Mut erwartet dies offen auszusprechen und das Projekt zu beenden. Mit jeder getroffenen Entscheidung geht ein Risiko einher, dass die Entscheidung falsch war. Je mehr Entscheidungen getroffen werden, um so höher ist auch das getragene Risiko. Durch gezielte Experimente wird innerhalb der XP-Methodik versucht Klarheit zu erlangen, ob eine Entscheidung positive oder negative Auswirkungen auf das Gesamtprojekt hat. Es gilt der Grundsatz, dass jede abstrakte Entscheidung durch Tests und Experimente begründet werden sollte. Offene und aufrichtige Kommunikation ist der zentrale Wert von Extreme Programming und streng genommen jeder funktionierenden Zusammenarbeit. Ängste, Eitelkeiten, Rivalitäten und Egoismus führen in jeder Art von Projekt dazu, irgendwann in einer Sackgasse zu stecken. Kommunikation ist der Schlüssel zum Erfolg des Projekts. Zunächst scheint es ungewöhnlich und wirtschaftlich unrentabel zu zweit an einem Rechner zu sitzen und gemeinsam zu entwickeln. Es mag unproduktiv klingen Studenten sich selbst zu überlassen, um ihre Leistungsfähigkeit zu fördern. Doch andererseits finden sich Programmierer seit jeher in Kleingruppen zusammen, um bestimmte Probleme zu besprechen. Es kann also durchaus nützlich sein, sich der Instinkte des Teams zu bedienen anstatt durch Regeln und Kontrolle das Verhalten und Denken einzuschränken. Leider verläuft die Aufgabenverteilung in klassischen Softwareprojekten zumeist streng autoritär. Der Projektleiter verteilt Aufgaben auf Arbeitsgruppen oder Einzelpersonen, die dann in einem vorgegebenen Zeitrahmen umgesetzt werden müssen. Nicht nur Engagement und Freude am Projekt, sondern auch die selbstgesteuerte Übernahme von Verantwortung bleibt so auf der Strecke. Nur wenn das Team die Möglichkeit und Freiheit dazu hat, Verantwortung zu übernehmen, kann jeder Einzelne sich mit seiner Aufgabe identifizieren und auch unangenehme Aufgaben erledigen. Kent Beck stellt mit Extreme Programming kein allgemeingültiges Vorgehensmodell der Softwareentwicklung vor, auf das ein Team umschwenken kann, um verspätete Projekte in den Griff zu bekommen. XP ist eine Philosophie mit vielen ineinander greifenden Rädern. Dennoch ist es notwendig und angemessen die Methode, Werte und Praktiken genau zu untersuchen und eine für die örtlichen Gegebenheiten praktikable Teilmenge aus XP auszuwählen. Niemand kann für einen Anderen entscheiden, wie dessen Projekte geführt werden müssen, um erfolgreich zu sein. Es ist eine Abwägung zwischen Instinkt und Erfahrung, zwischen Hinweisen und Eigenverantwortung, die XP zu einem nützlichen Instrument der eigenen Projektverbesserung werden lässt. Neben dem Spiel, das es zu gewinnen gilt, ist die Reise mit leichtem Gepäck eine weitere häufig genutzte und verständliche Metapher des Extreme Programming. Mit schwerem Gepäck

50 40 Extreme Programming in der Übersicht ist man nicht sehr flexibel und beweglich. Das Reisegepäck eines XP-Teams sollte daher aus wenigen, aber nützlichen Dingen bestehen: Tests und Code. Softwareentwicklung ist neben der Kunst der Wertschöpfung und dem kooperativen Arbeitsprozess vor allem durch das Streben nach Kontrolle gekennzeichnet. Die Messung von Zeilen geschriebenen Codes (Lines of Code, LOC), der Erfassung von geleisteten Arbeitsstunden und der Anzahl verfasster Dokumentationsseiten kann oft als Sicherheit verstanden werden, die so im Projekt nicht vorliegt. Ist die Hälfte des Codes auskommentiert oder nur ein Drittel der dokumentierten Funktionen umgesetzt, so geben diese Kennzahlen keinen wirklichen Aufschluss über ein Projekt. In dem Maße, wie man lernt besser zu programmieren, besser zu schätzen und erfolgreicher zu werden, wird auch ehrlicher gemessen, an welchem Punkt sich das Projekt befindet. Neben den eingehend erläuterten Werten sowie den fundamentalen und sekundären Prinzipien, besteht XP aus einer Zahl von Techniken, die unterstützend für die Teammitglieder wirken. Bei Beck werden die Techniken als Pratices bezeichnet, was immer auch auf die Erfahrung mit dem Umgang einer Technik beinhaltet. Abbildung 3.3 zeigt einen Überblick über die einzelnen Techniken, die zum Teil später im Kapitel detailliert beschrieben werden. Kunde vor Ort Gemeinsame Verantwortlichkeit Testen Programmierstandards Retrospektive Pair Programming Refactoring Planspiel Fortlaufende Integration Stand-up Meeting Einfaches Design Metapher Nachhaltiges Tempo Kurze Releasezyklen Abbildung 3.3: Die XP-Techniken im Überblick nach [Jef06] Die Werte und Prinzipien der vorhergehenden Seiten bilden die Grundlage für eine stabile, vorhersagbare und anspruchsvolle Softwareentwicklung. Mit Hilfe der Techniken aus Abbildung 3.3 ist es sowohl für Entwickler als auch für Kunden einfacher die Grundregeln einzuhalten, da sie konkrete Arbeiten haben, an denen sie sich orientieren können. In der Softwareentwicklung im Allgemeinen und in der Methodik des XP im Speziellen gibt es Arbeitsschritte, die das Rüstzeug für alle Arbeiten bilden.

51 Kapitel 3 Werte, Prinzipien und Aktivitäten Aktivitäten Die vier zentralen Aktivitäten der Softwareentwicklung sind: Programmieren, Testen, Zuhören und Entwerfen. Je nach Art des Vorgehens lassen sich die Aktivitäten unterschiedlich priorisieren. Was sich jedoch als essentiell identifizieren lässt, ist der Code. Programmieren ist daher die Aktivität, auf welche keinesfalls verzichtet werden kann. Programmieren bedeutet mehr als einfaches Schreiben von Anweisungen, das Schreiben von (gutem) Code bedeutet Kommunikation, denn mit den Anweisungen können Ideen, Algorithmen, Tests oder Ansätze für Verbesserungen ausgedrückt werden. Diese vielfältige Einsetzbarkeit von Quellcode macht ihn zum wichtigsten Teil der Softwareentwicklung. Neben der eigentlichen Programmierung steht in agilen Vorgehensmodellen und besonders in XP das Testen von Programmen, Methoden und Funktionen im Blickpunkt der Aktivitäten. Teilweise geht dies so weit, dass Entwickler erst dann beginnen zu programmieren, wenn es für den entsprechenden Code Tests gibt. Zumeist versteht man unter Tests nichts anderes als die funktionale Überprüfung von Quellcode hinsichtlich seiner Korrektheit. Doch Tests können durchaus auch nicht-funktionale Schwächen wie Performanzprobleme oder Verstöße gegen Codestandards aufdecken. Aus betriebswirtschaftlicher Sicht sind Tests langfristig nützlich, da sie die zugehörigen Programme länger am Leben halten. Der kurzfristige Mehrwert für die Entwickler liegt im erhöhten Vertrauen in die eigene Arbeit. Doch Tests bergen auch Gefahren. Schlechte Tests verleiten dazu den Eindruck zu bekommen, dass das System funktioniert, obwohl dem nicht so ist. Tests sind also mehr als ein Werkzeug guter Softwareentwicklung, sie bedeuten auch die Verantwortung für eine umfassende Auseinandersetzung mit dem Problembereich der Software. Tests werden auf funktionaler Ebene vom Entwickler beschrieben und festgelegt; der Kunde hingegen spezifiziert Akzeptanztests, um sich davon überzeugen zu können, dass das System als Ganzes so arbeitet, wie er es sich vorstellt. Als dritte wesentliche Aktivität des Extreme Programming führt Beck Zuhören ein. Kommunikation und Zuhören sind zwar eng verbunden, es besteht jedoch kein kausaler Zusammenhang zwischen ihnen. Genau dies ist das Problem in vielen Projekten man spricht zwar miteinander, hört sich aber nicht zu und versteht sich damit nicht. Das Erkennen dieses Problems bringt die Softwareentwicklung jedoch nicht weiter und schafft vor allem die Problematik nicht aus der Welt. XP versucht die Kommunikation in einer Art und Weise zu strukturieren, dass wichtige Dinge kommuniziert und von beiden Seiten (Kunde und Entwickler) verstanden werden. Darüber hinaus wird versucht Kommunikation zu vermeiden, die das Projekt nicht weiter bringt oder die durchgeführt wird, bevor verstanden werden kann, welcher Teil wichtig ist. Nimmt man klassische Vorgehensmodelle zum Vergleich, so wird vor allem auf eine ausgedehnte Spezifikations- und Dokumentationsphase verzichtet, in welcher der Kunde zumeist noch keine spezifischen Vorstellungen vom zu erstellenden System hat. Auch die vierte Aktivität Design entwerfen korreliert mit den Werten, Prinzipien und Aktivitäten in Extreme Programming. So wie nicht alle Anforderungen an ein Projekt im Vorfeld bekannt sind, so kann auch zu Beginn kein vollendetes Design stehen. Das Design des Systems wird im Laufe des Projekts fortwährend verfeinert, wobei mit einem möglichst

52 42 Extreme Programming in der Übersicht einfachen Design begonnen wird. Ein zu detailliertes Design würde in den frühen Iterationen Flexibilität vermeiden und Visionen unterdrücken. Wenn jedoch im System jederzeit so einfach wie möglich die geforderte Funktionalität umgesetzt wird, kann auch jede spätere Erweiterung schnell und unter Erhaltung der Einfachheit umgesetzt werden. Beginnend beim Design sollte darauf geachtet werden, dass Einfachheit angestrebt, Testgetrieben im Team entwickelt und einander aktiv zugehört wird. Die Einhaltung der fundamentalen Werte, aufgestellten Prinzipien und grundlegenden Aktivitäten ist komplizierter, als man annehmen könnte, der Aufwand ist jedoch die Mühe wert. XP belohnt die Entwickler mit einem besseren Verständnis der erstellten Software, einer engen Kunden-Entwickler-Bindung und herausragendem Wir-Gefühl. Die Vermittlung dieser Aspekte sollte auch Eingang in die universitäre Vermittlung von Softwareentwicklung finden. 3.3 Versionsplanung Agile Methoden gehen von Anfang an davon aus, dass Vorgehenspläne keinen Bestand haben. Ständig neue Anforderungen an ein Softwareprodukt, Marktdruck und stetig neue Termine machen eine feste Planung des Vorgehens nahezu unmöglich. Das einzige, wovon man bei einem Plan ausgehen kann, ist, dass die Softwareentwicklung sich nicht daran halten wird. Die Versionsplanung und das weitere Vorgehen findet agil zu jeder Zeit statt, wenn sich etwas ändert. Jeder neue Kundenwunsch und jede veränderte Priorität eines bestimmten Features verändert den Plan; ein einfacheres Design oder effizientere Algorithmen lassen eine schnellere Entwicklung zu und beeinflussen so die weitere Planung. Ein Plan zur weiteren Entwicklung der geforderten Softwarelösung kann also nur als Momentaufnahme dessen gesehen werden, was zu tun ist und hilft allen bei der Realisierung von Möglichkeiten, Zielen und Problemen. Jeder Beteiligte Projektleiter, Kunde und Entwickler muss diese kontinuierliche Veränderung akzeptieren und mit den daraus resultierenden Umständen umgehen können Planspiel, Benutzergeschichten und Storycards Die Versionsplanung in XP ist eine streng gemeinschaftliche Arbeit des Kunden und der Entwickler. Der Kunde führt indirekt die Versionsplanung selbst durch, indem er den Entwicklern den gewünschten Funktionsumfang der Software mit Hilfe von Geschichten 6 erklärt, von den Entwicklern unmittelbar Feedback zur Dauer der Implementierung erhält und schließlich Prioritäten für die Umsetzung einzelner Geschichten vergibt. Im Detail kommen dem Kunden die Aufgaben Schreiben der Benutzergeschichten, 6 Geschichten werden oft auch als Benutzergeschichten oder User-Stories bezeichnet und sind im Grunde nichts anderes als eine Verbindung von Feature-Requests und Use-Cases. Durch die Erstellung der Geschichten muss der Kunde sich sehr genau mit seinen Anforderungen auseinandersetzen und spezifische Wenn-Dann-Fragen beantworten können.

53 Kapitel 3 Versionsplanung 43 Beschreibung des Geschäftswert der einzelnen Geschichten, Entscheidung, welche Geschichten in welcher Version umgesetzt werden zu, während die Entwickler die Entwicklungszeit für jede Geschichte abschätzen, den Kunden vor wichtigen technischen Risiken warnen und den jeweiligen Teamfortschritt messen müssen, um den Kunden auf dem Laufenden zu halten. Um die Entwicklungszeit für die Geschichten des Kunden abschätzen zu können, müssen die Entwickler die Komplexität einer Geschichte aufbrechen und in mehrere kleine Leistungsmerkmale so genannte Tasks zerlegen. Für jeden Task wird festgehalten, zu welcher Geschichte er gehört, wer ihn umsetzt und wie lang die optimale Entwicklungszeit dafür ist. Diese Informationen werden auf Taskcards festgehalten, welche zusammen mit den Storycards der nachhaltigen Archivierung des Planungsprozesses dienen. Die Abbildungen 3.4(a) und 3.4(b) zeigen echte Story- und Taskcards aus dem C3-Projekt (siehe auch [ABB + 98]). Nachdem die Systemanforderungen durch den Kunden in Form von Benutzergeschichten formuliert und von den Entwicklern in einzelne Tasks zerlegt wurden, muss bestimmt werden, welche Geschichten als erstes bearbeitet werden. XP setzt wie alle agilen Vorgehensmodelle auf viele kurze Iterationen und häufige Releases, um den Kunden stark einzubinden und nicht an ihm vorbei zu entwickeln. Der nächste Schritt muss nun sein, festzulegen in welcher Reihenfolge also in welcher Iteration die Geschichten abgearbeitet werden und welchen Funktionsumfang die Releases haben sollen Iterationsplanung und Releases Die Iterationsplanung dient der Ordnung der vorhandenen Geschichten und Tasks, um einen ersten, einfachen Plan für die bevorstehende Softwareentwicklung zu erhalten. Dazu müssen die einzelnen Geschichten vom Kunden genau nach Wichtigkeit und Geschäftswert 7 geordnet werden. Die Entwickler müssen Abhängigkeiten zwischen den extrahierten Tasks herausstellen 8 und mögliche technische Risiken bei der softwaretechnischen Realisierung einschätzen. Aus diesen Informationen wird dann ein erster Plan aufgestellt, der einen Kompromiss der beiden Kriterien in einem zeitlichen Ablauf darstellen muss. Iterationen sollten in der Tradition der agilen Methoden kurz sein: typisch sind Längen zwischen zwei Tagen und drei Wochen. Eine Umfrage der egroup Extreme Programming ergab, dass Längen von zwei bis drei Wochen am beliebtesten sind (vgl. [egr06]). Jede Iteration muss funktionsfähigen, vollständig getesteten Code liefern, der vom Kunden akzeptiert werden muss. Je länger eine Iteration ist, um so höher ist das Risiko, dass sie nicht korrekt verläuft, 7 Der englische Originalbegriff business value ist klarer und dennoch vielschichtiger; er meint sowohl den Wert als auch den tatsächlichen Nutzen einer Sache. 8 Entgegen der hinlänglichen Annahme, dass die Sortierung von Aufgaben nach ihrer technischen Abhängigkeit wertvoll für die spätere Implementierung sei, weisen Beck, Fowler und Jeffries unabhängig darauf hin, dass die Beachtung der technischen Abhängigkeit weit weniger wichtig ist, als der Geschäftswert für den Kunden [BF01, JAH01, Bec03].

54 44 Extreme Programming in der Übersicht (a) Storycard (b) Taskcard Abbildung 3.4: Originale Story- und Taskcards aus dem C3-Projekt (entnommen aus: [Jef06]) Aufgaben vergessen oder nicht zur Zufriedenheit aller gelöst werden. Ein Iterationsplan sollte eine Aufstellung darüber geben, welche Geschichte mit welchem Arbeitsaufwand veranschlagt wurde und in welcher Iteration der Kunde eine Umsetzung wünscht. Weiterhin muss der Kunde Termine setzen, an denen bestimmte Geschichten in einem testfähigen Release gebündelt und an ein größeres Publikum verteilt werden sollen. Der Iterationsplan sollte auf einfache Weise die benannten Abhängigkeiten darstellen 9 ; ein Beispiel aus [BF01, S. 68] ist in Tabelle 3.1 dargestellt. 9 Die Erfinder von XP sprechen sich bei der Modellierung solcher Abhängigkeiten bewusst gegen den Einsatz klassischer Abhängigkeitsdiagramme wie PERT aus. Durch die eng verzahnte, offene und ehrliche Kommunikation in XP-Teams, kann davon ausgegangen werden, dass solche Abhängigkeiten schnell bei allen Entwicklern bekannt sind.

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

1.2 System- und Softwareentwicklungsprozesse

1.2 System- und Softwareentwicklungsprozesse 1.2 System- und Softwareentwicklungsprozesse Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Vorgehensmodelle und UML Um Systeme und Software

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle)

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap 8.1 http://homepages.cs.ncl.ac.uk/brian.randell/nato/ The first International Conference

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Softwaretechnik Prozessmodelle

Softwaretechnik Prozessmodelle Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Projektmanagement V-Modell XT-konform gestalten

Projektmanagement V-Modell XT-konform gestalten Projektmanagement V-Modell XT-konform gestalten PMI Munich Chapter Meeting 20. März 2007 Dr. Marc Sihling 2007 4Soft GmbH Agenda Überblick V-Modell XT Projektinitialisierung Tailoring Rollenbelegung Projektplanung

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Softwarequalität: Einführung. 15. April 2015

Softwarequalität: Einführung. 15. April 2015 Softwarequalität: Einführung 15. April 2015 Überblick Warum ist Softwarequalität wichtig? Was ist Softwarequalität? Wie erreicht man Softwarequalität? Taentzer Softwarequalität 2015 8 Berühmte Software-Fehler

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

Mehr

Kapitel 1 Software-Prozessmodelle

Kapitel 1 Software-Prozessmodelle Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung

Mehr

Vorgehensmodelle zur Entwicklung mobiler Applikationen. Eine Status-quo Analyse. Bachelorarbeit

Vorgehensmodelle zur Entwicklung mobiler Applikationen. Eine Status-quo Analyse. Bachelorarbeit Vorgehensmodelle zur Entwicklung mobiler Applikationen - Eine Status-quo Analyse Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Softwarequalität - Qualitätsmodelle

Softwarequalität - Qualitätsmodelle Softwarequalität - Qualitätsmodelle Proseminar IT-Kennzahlen und Codemetriken Clara Lange 17.05.2010 TU München Inhalt 1. Was ist Softwarequalität? 2. Sichten auf Softwarequalität 3. Messen von Qualität

Mehr

Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS

Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS Prof. Dr. Roland Petrasch Dipl.-Inform., M.Sc. Florian Fieber Fachbereich VI Informatik und Medien Technische Fachhochschule Berlin Luxemburger

Mehr

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Überblick Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution Evolutionsprozesse Techniken für Software-Evolution

Mehr

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Bernd Oestereich (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Christian Weiss (Geschäftsführer) Copyright by oose GmbH 2006 Das Wasserfallmodell ein historisches Mißverständnis. Der Wasserfallprozess-

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

Die Phasen der Software-Entwicklung

Die Phasen der Software-Entwicklung Die Phasen der Software-Entwicklung c OSTC GmbH, T. Birnthaler 2011-2015 V1.7 [sw-entwicklung-phasen.txt] 1 Übersicht Die Entwicklung von Software im Rahmen eines Projekts umfasst im wesentlichen die Phasen

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Vorgehensmodelle. Wie erstellt man hochwertige Software?

Vorgehensmodelle. Wie erstellt man hochwertige Software? Vorgehensmodelle Wie erstellt man hochwertige Software? Qualitätssicherung im Software- Entwicklungsprozess Quelle: Kühnel B.: Praxis einer integrierten Software-Qualitätssicherung. In: Softwaretechnik-Trends,

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Vorgehen im Softwareentwicklungsprozess

Vorgehen im Softwareentwicklungsprozess Der Softwareentwicklungsprozess Für die Entwicklung von Software, namentlich für große Projekte, ist ein systematisches Vorgehen notwendig. Dieses Vorgehen, der Softwareentwicklungprozess, wird strukturiert

Mehr

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3 Projektmanagement Kompetenztraining V-Modell XT Das V-Modell XT ist urheberrechtlich geschützt, Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten m.e.d. concept methode erfolg datenverarbeitung

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

Software Engineering. Prozessmodelle zur Softwareentwicklung

Software Engineering. Prozessmodelle zur Softwareentwicklung Software Engineering Prozessmodelle zur Softwareentwicklung Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Qualitätssicherung[QS] von Torsten Lindner

Qualitätssicherung[QS] von Torsten Lindner Qualitätssicherung[QS] von Torsten Lindner Gliederung [I] [II] [III] [IV] Softwarequalität Qualitätssicherung Zusammenfassung Literatur Gliederung [I] Softwarequalität [A] Begriffserklärung [B] Qualitätsmaß

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Lernziele Die Bedeutung und Ziele von Vorgehensmodellen im Software Engineering Die Entstehung unterschiedlicher Vorgehensmodelle Vorlesung Der Unterschied

Mehr

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013!

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Sie wollen alles über agile Softwareentwicklung wissen? Wie können Sie agile Methoden

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr