Vorgehensmodelle: Wasserfallmodell

Präsentation zum Thema: "Vorgehensmodelle: Wasserfallmodell"—  Präsentation transkript:

1 Vorgehensmodelle: Wasserfallmodell
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

2 Vorgehensmodelle: V-Modell
OO Softwareentwicklung inkrementell prototypisch iterativ Use-Cases driven Architekturbeschreibung durch Klassendiagramme Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

3 Vorgehensmodelle: V-Modell
Submodule Projektmanagement Qualitätssicherung Softwareentwicklung Konfigurations-Management definiert Rollen beschreibt Aktivitäten und Produkte definiert Werkzeuge Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

4 Spiralmodel nach Barry W. Boehm
Anforderungen Design Test Implementierung Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

5 Vorgehensmodelle: Der Unified Process [JBR]
objektorientiert benutzt die UML Use-Case driven inkrementell und iterativ Architektur basiert Phasen Konzeptionsphase (englisch Inception) Entwurfsphase (englisch Elaboration) Konstruktionsphase (englisch Construction) Übergabephase (englisch Transition) Arbeitsschritte ähnlich dem Wasserfallmodell beschreibt Rollen / Aktivitäten / Dokumente / Produkte Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

6 Vorgehensmodelle: Der Unified Process
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

7 Requirements Capturing
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

8 Requirements Refinement
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

9 Story Driven Modeling requirements scenarios application scenarios
story boards & GUI mockups class diagrams tests method development Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

10 Quanten Metapher von Kurt Schneider
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

11 Datenflussmodellierung mit FLOW (Kurt Schneider)
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

12 Communication Patterns (Kurt Schneider)
Dokumente Reproduzierbar, Aufwendig Nachfragen schwierig Gespräche Nicht reproduzierbar Billig Interaktiv Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

13 Communication Patterns
Meetings Eingeschränkt reproduzierbar durch Minutes Mittlere Kosten Mittlere Interaktivität Mail Reproduzierbar (auch wenn es sich privat anfühlt) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

14 Communication Patterns (Kurt Schneider)
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

15 eXtreme Programming Lehrmeinung zur Softwaretechnik
Architektur ist ganz wichtig Process ist ganz wichtig Vollständige Anforderungsdefinition ist unabdingbar Alles in Dokumenten festhalten Kent Beck (Berater im Silicon Valley)’s Meinung zur Softwaretechnik: Der ganze Quatsch hält nur auf lasst uns lieber Programmieren . . . Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

16 Übersicht eXtreme Programming Das Planungsspiel Testen
Pair Programming Raumaufteilung on-site customer Design Metapher Gemeinsamer Codebesitz Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

17 eXtreme Programming Prinzipien / Elemente
Das Planungsspiel (The planning game) der Kunde schreibt „User Stories" auf Story-Karten (Use Cases mit kurzer textueller Beschreibung) Die Entwickler schätzen den Entwicklungsaufwand (basierend auf grober Zeiterfassung und Vergleich mit früheren Schätzungen, aber ohne besondere Techniken) Kunde wählt (begrenzt durch den gesteckten Zeit- und Kostenrahmen) zu realisierende Stories für das nächste Release aus Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

18 Story Card Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

19 Task Card Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

20 Testen Stories werden in Implementierungs-Tasks / (Teil-) Funktionalitäten runtergebrochen Kunde schreibt Tests für seine Stories / Tasks bevor man eine Funktionalität implementiert wird als erstes dafür ein "einfacher" Test (Test-first) geschrieben dann wird solange implementiert, bis der Test durchläuft fertig, nächste Funktionalität oder Test erweitern und Implementierung erweitern Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

21 Testen Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

22 Paar-Programmierung (Pair Programming)
Man sitzt immer zu zweit vor dem Rechner Einer tippt, erklärt, . . . Einer schaut, fragt, meckert, achtet auf Vorgehen und Standards, ... Paare werden Task-weise neu zusammengestellt Ersatz für Reviewing-Techniken Ziele sind die selben Paar-Programmierung ist eXtremer als Reviewing Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

23 Raumaufteilung großer Raum für das ganze Team
Rechner in der Mitte mit genügend Platz damit bis drei Leute davor sitzen können Hilfe auf Zuruf ist möglich Kein Teppich, damit die Stühle besser hin und her rollen können Cubicles an den Außenwänden Tisch für Besprechungen Kaffee Ecke mit (jeder Menge) Snacks und kleinen Spielen, ... Tafeln für Diskussionen Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik, Empowerment, ...) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

24 Raumaufteilung Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

25 Kunde vor Ort (on-site customer)
Ein Kundenvertreter sitzt die ganze Zeit beim Entwickler-Team (lebende Anforderungsdefinition) Der Kundenvertreter kennt die Anwendungsdomäne, ist selber zukünftiger Anwender oder Anwender des Vorgängersystems Der Kundenvertreter schreibt Stories (Use-Cases) Der Kundenvertreter implementiert Tests für die Stories Der Kundenvertreter priorisiert Anforderungen im Planungsspiel Der Kundenvertreter nimmt Releases ab und entscheidet über Projektfortsetzung (Wo kriegt man solche Kunden her?) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

26 Einfaches / simples Design
Lehrmeinung: Kosten für Änderungen steigen exponentiell mit Projektlaufzeit Kent Beck’s Meinung: Änderungen werden mit der Projektlaufzeit eher billiger Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

27 Einfaches / simples Design
Die Lehrmeinung impliziert: Kent Beck’s Meinung impliziert Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

28 Design in XP kein "Voraus-Design" kein Design für Wiederverwendung
kein Product-Line-Design immer nur die gerade notwendigsten Klassen und Methoden Refactoring Hilfen Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

29 Metapher eines der ungelösten Mysterien des XP
Metapher ist gemeinsame bildhafte Vorstellung des Systems z.B.: Bahnhof, Postamt, Markt, Agentensystem, ... Metapher sorgt für gemeinsame Sprachwelt im Team und mit dem Kunden Der Begriff bleibt im Buch ziemlich unklar Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

30 Kleine Releases frühes erstes Teil-Release in "Produktion" (z.B. nach drei Monaten) viele kleine Releases (z.B. monatlich) Im Prinzip "iterativen" Lebenszyklusmodells (wie beim Unified Process) frühes Feedback durch Kunden Steuerung noch möglich automatisches Testen  Funktionalität geht nicht verloren Achtung: Altdatenbestände / festgeschriebene Bedienungsabläufe können Redesign-Schritte behindern Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

31 Gemeinsamer Codebesitz
Keine Aufteilung des Programms in Verantwortungsbereiche Jeder ist für das gesamte verantwortlich Jeder darf überall beliebig ändern Aber: die Tests müssen weiter durchlaufen Das machen wir in Fujaba auch so funktioniert gut (obwohl wir bisher nur wenig automatische Tests haben) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

32 Coding Standards damit "gemeinsamer Code-Besitz" funktioniert muss Code möglichst überall gleich aussehen starke Coding Standards werden benötigt Paar-Programmierung stellt Einhaltung der Standards sicher das machen wir in Fujaba mit Eclipse Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

33 Refactoring Refactoring heißt Code-Reorganisation / kleiner Redesign-Schritte Copy-Paste Code in Methoden auslagern Klassenhierarchie überarbeiten Hilfsklassen, -methoden, -strukturen einführen . . . Immer wenn man was sieht, was man mal überarbeiten sollte, auf die Task-Card schreiben bevor man neue Funktionalität implementiert, gegebenenfalls Desginänderungen vornehmen während der Implementierung nicht gleichzeitig refactorn nach der Implementierung Refactoring-Tasks abarbeiten Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

34 Kontinuierliche Systemintegration
fertige Teilfunktionalitäten werden so früh wie möglich (täglich) in die Team-Master-Kopie integriert dafür gibt es einen extra Integrations-PC das machen wir mit SVN Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

35 40 Stunden Woche müde Leute machen Fehler müde Leute sind unproduktiv
Kent möchte genügend Zeit für seine Kinder haben entspricht allen allgemeinen Empfehlungen zur Produktivität von Arbeitskräften widerspricht der industriellen Praxis (gerade bei IT-Start-Ups) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

36 Rollen in einem XP-Projekt
Programmierer: fast alle sind Programmierer Tests schreiben Refactoring Tests implementieren kommunizieren pairen Kunde ein Kundenvertreter vor Ort "lebende" Anforderungsdefinition funktionale Anforderungen als Stories formulieren funktionale Tests schreiben Funktionalität für die Releases auswählen Verbindung nach Hause halten Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

37 Rollen in einem XP-Projekt
Tester einer im Team unterstützt den Kunden beim Schreiben der funktionalen Tests Tracker schiebt die "Done" Markierungen auf dem Balkenplan weiter führt Produktivitätsstatistiken Coach verantwortlich für die Einhaltung / Umsetzung der XP Prinzipien wichtig beim Einstieg in die XP-Arbeitsweise etwas auch für die Architektur verantwortlich: wenn nötig, Refactoring initiieren Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

38 Rollen in einem XP-Projekt
Consultant XP fördert / produziert "allround" Programmierer für komplizierte / neue Technik(en) braucht man gegebenenfalls einen Berater Big Boss der "Projektmanager" vertritt / beschützt das Team nach außen hin trifft gelegentlich Personalentscheidungen mischt sich nicht in technische Sachen / die eigentliche Arbeit ein Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

39 Bewertung XP hat viele gute Elemente / "Best Practices"
Test-First Prinzip Paar-Programmierung (Reviewing funktioniert oft schlecht) Planungsspiel und On-Site-Kunde (wenn das der Kunde mit macht) XP hat klare Beschränkungen kleine Projekte keine sicherheitskritischen Systeme wo zertifizierte Entwicklungsprozesse verlangt werden XP und Softwaretechnik sind eigentlich kein Widerspruch Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

40 Scrum / Kunagi: User Stories / Tasks wie XP
Product Owner == Onsite Customer Kleine Releases Burn Down Charts >== Planungsspiel Scrum Master >== ? Daily Scrum Meeting >== ? Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

41 Kanban Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

42 Semat Software Engineering Method and Theory
Ivar Jacobson Comming soon … Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

43 Das liebe Geld Angebot Bestellung Rechnung
Festpreis Produkt (Design by Budget) Dienstleistung (Arbeitsstunden) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

44 Twenty dirty tricks to train software engineers; Ray Dawson ICSE 2000
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

45 Fachgebiet Software Engineering. Übersicht. © 28. 03
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University