Methoden der Softwareentwicklung

Transkript

1 Dipl. Wirtsch. Ing. Alexander Werth 3-1

2 Software vs. Brückenbau Softwareentwicklung Neues Problem. Die einzelnen Komponenten sind entweder neu oder können kopiert werden. Fast alle Aufwände unbekannt. Autobahnbrücke Bekanntes Problem. Ähnliche Brücken wurden vorher schon gebaut. Nur wenige einzigartige Merkmale pro Brücke. Arbeitsaufwand der bekannten Arbeitsschritte im Vorfeld bekannt. 3-2

3 Software Engineering Kann man Software so bauen wie Architekten, Bauingenieure und Handwerker ein Gebäude bauen? Kann Verfahren zur Produktentwicklung aus dem Automobilbau auf Software übertragen? 3-3

4 Brückenbau Tacoma Narrows Brücke im US-Bundesstaat Washington Gebaut 1940 Einsturz nach 4 Monaten Wind nicht ausreichend berücksichtigt Torsionsschwingungen führten zum Einsturz Diese Datei ist in den Vereinigten Staaten public domain, da sie von einem Bediensteten einer Bundesbehörde in Ausübung seiner dienstlichen Pflichten erstellt wurde und somit ein Werk der Regierung der Vereinigten Staaten ist. 3-4

5 Engineering Es ist schwierig unbekannte Probleme zu berücksichtigen. Neuland gibt es überall. Bei bekanntem reicht es die Software zu kopieren. Der Anteil an Neuland ist im Software Engineering höher. 3-5

6 Komplexität von Softwareprojekten Unbekanntes Softwareproblem Weitestgehend bekanntes Softwareproblem A C Komplexität B D Minimalperformance muss erfüllt werden Mehr Performance ist Kaufkriterium Komplexität der Software sollte bei der Wahl des Entwicklungsmodels berücksichtigt werden. 3-6

7 Beobachtungen zur Komplexität Ein an sich bekanntes Problem kann einem Software Entwickler unbekannt sein. Research von erfolgreichen Lösungen. A C, B D. Midrange, Low End. B A, D C. A&B nur schlecht planbar wegen großer Unsicherheit. A C B D 3-7

8 Software Engineering Software Engineering zeichnet sich aus durch den Einsatz von geeigneten Methoden, Werkzeugen und Vorgehensmodellen 3-8

9 Entwicklungsmodelle Sequenzielle Phasenmodelle Wasserfall-Modell V-Model Spiralmodell Prototyping Inkrementelle Entwicklung Agile development Rational Unified Process RUP Open Source 3-9

10 Phasen der Softwareentwicklung Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung 3-10

11 Entwicklungsmodelle Wasserfall Modell 3-11

12 Wasserfall Modell Schritte werden nacheinander ausgeführt Spezifikation Entwurf Information fließt nur in eine Richtung. Wie Wasser bei einem Wasserfall Implementierung Entwurf Problemdefinition Zielforschung Anforderungsanalyse Analyse Implementierung Test Einführung Erprobung Betrieb / Betrieb Wartung 3-12

13 Wasserfall Modell Erhebungsbericht (Business Case) Lastenheft Spezifikation Pflichtenheft Entwurf Detailiertes Design Am Ende jedes Schrittes steht ein Ergebniss, in der Regel ein Dokument Problemdefinition Anforderungsanalyse Implementierung Erprobung Quellcode, Dokumentation Betrieb / Wartung Endprodukt 3-13

14 Wasserfall Modell Allgemeines Entwicklungsmodell für neue Produkte. Phasenmodell. Dokument am Ende jeder Phase. Dokumentgetrieben. Einfach zu verstehen. Klare Trennung von Aufgaben. Top Down 3-14

15 Wasserfall Modell Gut geeignet für bekannte Probleme bei gegebenen Mindestanforderungen. Sequenzielles Vorgehen oft nicht nötig. Keine Möglichkeit Fehler die in vorhergehenden Stufen gemacht wurden zu korrigieren. Phasen benötigen unterschiedliche Qualifikation und können von unterschiedlichen Teams erledigt werden. Stark unterschiedliche Auslastung der Teams. Phasen als Dienstleistung einkaufen. 3-15

16 Modifiziertes Wasserfall Modell Bei Problemen wird zum vorherige Schritt zurückgekehrt Spezifikation Entwurf Problemdefinition Anforderungsanalyse Implementierung Ermöglicht Iterationen Erprobung Betrieb / Wartung 3-16

17 Entwicklungsmodelle V Modell 3-17

18 Fehler im Entwurf zu vermeiden ist schwer These: Ein in der Entwurfsphase gefundener Fehler verursacht weniger Kosten als ein erst später gefundener. Fehler in der Entwurfsphase zu vermeiden ist schwer. Viele der Designfehler würde man nur mit überproportional erhöhtem Aufwand bereits in der Entwurfsphase finden. Daher ist es zwar eine Naheliegende aber nicht unbedingt praktikable Lösung den Aufwand der Entwurfsphase zu erhöhen. 3-18

19 V Modell Abnahmetest Grobentwurf Systemtest Feinentwurf Integrationstest Anforderungsdefinition Modulimplementation Modultest 3-19

20 V Modell Stark erweitertes Wasserfall Modell. Entwickelt ca für die Bundeswehr. Entwickelt für Embedded Systems. Vorgabe bei öffentlichen Aufträgen. D.h. Phasenmodell bei typischen Großprojekten. Anforderungen der einzelnen Schritte ausgearbeitet. Anpassen des Modells in ein Projektspezifisches Modell. Abstrakt bezüglich der Ausführung der Tätigkeiten. 3-20

21 V Modell Unterteilung in Submodelle: Systemerstellung (SE) Entwurf und Implementierung Qualitätssicherung (QS) Spezifikation von Qualitätskriterien, Test Konfigurationsmanagement (KM) Administration der Zwischen- und Endprodukte Projektmanagement (PM) Planung, Kontrolle, Informationsverteilung 3-21

22 Entwicklungsmodelle Spiralmodell 3-22

23 Spiralmodell Große Unsicherheit bei der Software Entwicklung Schritte der Phasenmodelle zu komplex. Wiederholen der Schritte mit gewonnener Erfahrung. Wiederholte Risikoanalyse Wiederholtes Untersuchen von Alternativen Implementierung und Test der favorisierten Lösung 3-23

24 Implementieren und Testen Spiralmodell Abnahme Planung des folgenden Zyklus Risikoanalyse Festlegen der Ziele und Alternativen 3-24

25 Spiralmodell Entwicklung als Folge von Entwicklungszyklen. Iteratives Modell. Nicht absehbare Risiken haben Einfluss auf das Projekt. Fokus auf Risiko als Treiber für Iterative Vorgehensweise. Keine Aussage über Organisation der einzelnen Phasen. Unsicherheit akzeptieren und nicht vertuschen. Geeignet bei unbekannter Problemstellung. 3-25

26 Spiralmodell Nenne einen Vorteil des Spiralmodells. Nenne einen Nachteil des Spiralmodells. 3-26

27 Entwicklungsmodelle Prototyping 3-27

28 Prototyping Kommunikation erlaubt unterschiedliche Interpretation. Kunden haben Schwierigkeiten ihre eigenen Anforderungen zu erkennen. Andere haben ebenfalls Schwierigkeiten die Anforderunen des Kunden zu erkennen. Dokumente sind zu abstrakt. Beschreibung enthält Fachbegriffe die für den Kunden oder Software Entwickler schwer verständlich sind. Begriffe können unterschiedlich Definiert sein. 3-28

29 Prototyping Entwickeln eines oder mehrerer Prototypen. Prototypen werden dem Kunden vorgestellt. Gut geeignet bei unbekanntem Softwareproblem. Man unterscheidet zwischen Evolutionärem Prototyping Wegwerfprototyping 3-29

30 Wegwerfprototyping Höherer Entwicklungsaufwand. Programmiersprache kann sich zwischen Prototypen unterscheiden. Rapid Prototyping. Gefahr, daß ein Wegwerfprototyp nicht weggeworfen wird. Gefahr, daß ein zu großer Schritt zwischen Prototypen angestrebt wird. 3-30

31 Evolutionäres Prototyping Prototyp wird nach und nach verbessert. Gewählte Programmiersprache muss von anfang an der finalen Programmiersprache entsprechen. Komponenten können nach und nach verbessert werden. Refactoring, Continious Integration 3-31

32 Entwicklungsmodelle Inkrementelle Entwicklung 3-32

33 Inkrementelle Entwicklung Aufteilen des Produkts in Komponenten. Komponenten können nacheinander entwickelt und getestet werden. Schrittweise Verfeinerung mit Test der einzelnen Komponenten. 3-33

34 Inkrementelle Entwicklung Top-down Getestete Komponente Getestete Komponente Getestete Komponente Simulation/ Dummy Code Getestete Komponente Simulation Dummy Code Viele Dummy Funktionen nötig. Dummy Code kann z.b. Hardware ersetzen. Simulation von Hardware Fehlern möglich. 3-34

35 Inkrementelle Entwicklung Bottom-up Testbench 1 Testbench 2 Testbench 3 Komponente 1 im Test Komponente 2 im Test Komponente 3 im Test Komponente 1 getestet Komponente 2 getestet Einsatz in der Mikroelektronik Entwicklung. Problematisch wenn Hardware benötigt wird. Ansatz bei Testautomation. 3-35

36 Inkrementelle Entwicklung Middle-out Testbench 2 Testbench 7 Komponente 2 im Test Komponente 7 im Test Simulation/ Dummy Code Komponente 1 getestet Simulation/ Dummy Code Hinzufügen von mehr und mehr angrenzenden Komponenten. Jedes Team kann an einer anderen Komponente arbeiten. 3-36

37 Inkrementelle Entwicklung Keine Aussage über frühe Phasen der Software Entwicklung. Fokus auf Implementierungs und Testphase Ergänzt damit Lücken in anderen Entwicklungsmodellen. Test Driven Development fordert die Entwicklung einer Testbench vor der Entwicklung des Codes. Eine Testbench beinhaltet mehrere Tests. Man kann diese Tests auch als Einzelprogramme implementieren. 3-37

38 Entwicklungsmodelle Agile Development 3-38

39 The greatest Picture Sunrise by: Pablo Picasso, Vincent van Gogh, Marc Chagall, Rembrandt Entwurf: 3-39

40 The greatest Picture Sunrise by: Pablo Picasso, Vincent van Gogh, Marc Chagall, Rembrandt Projekt Status: 95% fertig! Vincent van Gogh Marc Chagall Pablo Picasso Rembrandt 3-40

41 Agile Development Neuere Entwicklungsmethode. Berücksichtigt Besonderheiten der Softwareentwicklung stärker. Extreme Lösung für Probleme andere Entwicklungsmodelle. Fokus auf Implementierung und Test. Neue Techniken für Implementierung und Test. 3-41

42 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation. Zusammenarbeit mit Kunden statt Vertragsverhandlung. Auf Veränderungen reagieren statt einem Plan folgen. 3-42

43 Agile Development Individuen und Interaktion statt Prozessen und Tools. Einsicht, daß Programmierer nicht austauschbar sind. Funktionierende Software statt umfangreicher Dokumentation. Kunden haben keine Zeit eine umfangreiche Dokumentation zu lesen. Solange alles funktioniert braucht man keine Dokumentation. Zusammenarbeit mit Kunden statt Vertragsverhandlung. Zufriedene Kunden zahlen und bleiben Kunden. Auf Veränderungen reagieren statt einem Plan folgen. Bei komplexen Problemen ist ein Plan sowieso unvollständig. 3-43

44 Agile Development Agile Development ist ein Satz von Methoden. Freiheit bei der Wahl der Entwicklungstools. Extreme programming (XP), Paarweise programmieren Test Driven Development Refactoring Scrum User stories Neuartige Aufgabenplanung 3-44

45 Agile Development Aufgabenplanung Team diskutiert Einzelaufgaben. Alle Teammitglieder schätzen spontan den Aufwand wenn sie diese Aufgabe durchführen würden. Mittelwert dieser Schätzwerte wird gebildet und ist die Punktzahl der Aufgabe. Aufgaben werden grob nach Relevanz sortiert. Im Scrum Meeting erklärt jeder an welcher Aufgabe er arbeitet. Abschätzen wieviele Punkte pro Monat abgearbeitet werden können. Guter Schätzwert was wann implementiert sein kann. 3-45

46 Agile Development Extreme programming Abkürzung XP: XP Team, XP Methode, Zwei Programmierer arbeiten als Team und Programmieren jeweils gemeinsam an einem Bildschirm und einer Tastatur. Vier Augen sehen mehr als zwei. 3-46

47 Agile Development Extreme programming Den Wald vor lauter Bäumen nicht sehen. Beim Programmieren löst man viele Probleme sehr schnell und einige wenige dauern sehr lange. Der Aufwand pro Problem ist nicht normalverteilt. Die meiste Zeit steckt in wenigen Problemen die lange dauern und nicht in den vielen die kurz dauern. Wenn zwei Programmieren bei jeweils anderen Problemen lange brauchen, dann sind sie unter Umständen mehr als doppelt so schnell wenn sie zusammenarbeiten. 3-47

48 Agile Development Extreme programming Die Teams müssen aus etwa gleich guten Software Entwicklern bestehen. Die Software Entwickler müssen sehr eng zusammenarbeiten ohne sich auf die Nerven zu gehen. Es ist nicht leicht zu vermitteln wieso zwei Leute an ein Problem gesetzt werden. Programmieren wird in XP primär als kreative Tätigkeit und nicht als Ingenieurstätigkeit gesehen. Effizienter Erfahrungsaustausch zwischen Entwicklern. 3-48

49 Agile Development Test driven development Um Veränderungen schnell durchführen zu können darf man keine Angst vor Veränderungen haben. Umfangreiche, automatisierte Tests garantieren, daß eine Veränderung keine Nebeneffekte hat. Tests werden vor dem Programmcode entwickelt. Aber: Vollständige Tests sind bei komplexen Problemen nicht möglich. Viele Produkte setzen Hardware voraus. Eine vom Test steuerbare Simulation der Hardware ist nötig. 3-49

50 Agile Development Akzeptanz Akzeptanz von Agile Methoden schwierig: Programmieren als kreative Tätigkeit. Programmierer nicht austauschbar. Plannung von nicht wesentlichen Features. Komplizierter als Wasserfall Modell. Zumindest ein Manager in der Hierarchie wird Wasserfallartige Dokumente einfordern. Verschiedene Abteilungen an einem Projekt beteiligt. Abteilungen arbeiten an mehreren Projekten. 3-50

51 Entwicklungsmodelle Open Source 3-51

52 Open Source Aktueller Quellcode ist jedem zugänglich. Mitarbeit erwünscht. Forken des Projekts möglich. 3-52

53 Open Source Da der Quellcode jedem zugänglich ist, kann jeder das komplette Programm compilieren. Das Programm ist kostenlos. Verkauf von Hardware (Router, NAS, Android,...) Verkauf von Service (Installation, Wartung,...) 3-53

54 Open Source Vision existiert und dient als Kriterium welche Beiträge erwünscht oder unerwünscht sind. Fokus auf Implementierung. Forken statt Konsens um jeden Preis. Qualität der Beiträge bestimmt den Einfluß auf das Projekt. 3-54

55 Open Source Kommt eine Diskussion über ein Design zu keinem klaren Ergebnis, wird von den Stakeholdern ein Prototyp eingefordert. Anhand des Prototyps läßt sich leichter entscheiden ob und was an der Idee gut oder schlecht ist. Dadurch wird eine komplexe Designphase vermieden. 3-55

56 Open Source in Firmen Einsatz problematisch: Lizenzbedingungen passen nicht zu Firmenprozessen. Software Entwicklung ist teuer. Nicht offensichtlich wieso es vorteilhaft ist den Quellcode zur Verfügung zu stellen. Firmenhierarchien passen nicht gut zu den flachen Hierarchien von Open Source Projekten. Wenig Spielraum für Firmenpolitik Konkurenz kann leicht Fehler finden und für Marketing auschlachten. 3-56

57 Entwicklungsmodelle Alle aktuellen Entwicklungsmodelle haben iterative Komponenten Aber: Aufträgen für die klassischen Entwicklungsphasen werden einzeln vergeben. Iterationen verursachen erheblichen Overhead in der Praxis: Review Prozesse, Wasserfall Dokumente, Verschiedene Teams und Verantwortlichkeiten,

58 Entwicklungsmodelle Entwicklungsmodelle sind ein grober Leitfaden zur Durchführung von Software Entwicklungen. Entwicklungsmodelle geben nur selten Ihren Gültigkeitsbereich an. Wahl eines ungeeigneten Entwicklungsmodells kann ein Projekt gefährden. z.b. Phasenmodell bei hoher Unsicherheit. 3-58