Projektplan: Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University.

Präsentation zum Thema: "Projektplan: Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University."—  Präsentation transkript:

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

2 eXtreme Programming Lehrmeinung zur Softwaretechnik
Architektur ist ganz wichtig Process ist ganz wichtig Vollständige Anforderungsdefinition ist unabdingbar 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

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

4 eXtreme Programming Prinzipien / Elemente
Das Planungsspiel (The planning game) der Kunde schreibt "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

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

6 Testen Stories werden in Implementierungs-Tasks / (Teil-) Funktionalitäten runtergebrochen Kunde schreibt Tests für seine Stories 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

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

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

9 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

10 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 herrollen können Cubicles an den Außenwänden Tisch für Besprechungen Kaffee Ecke mit (jeder Menge) Snacks und kleine Spiele, ... Tafeln für Diskussionen Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik, Empowerment, ...) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

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

12 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

13 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

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

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

16 Metapher eines der ungelösten Mysterien des XP
Metapher ist gemeinsame bildhafte Vorstellung des Systems z.B.: Bahnhof, Postamt, Markt, Agentensystem, ... Methapher 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

17 Kleine Releases sobald wie eben möglich wird das erste Teil-Release an den Kunden ausgeliefert und geht dort in "Produktion" (z.B. nach drei Monaten) dann folgen viele kleine Releases in kurzen Abständen (z.B. monatlich) Im Prinzip die Idee des "iterativen" Lebenszyklusmodells (wie beim Unified Process) frühes Feedback durch den Kunden Steuerung noch möglich Gefahr fehlerhafter neuer Releases wird durch automatisches Testen minimiert Achtung: Altdatenbestände / festgeschriebene Bedienungsabläufe können Redesign-Schritte behindern Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

18 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 nicht mal automatische Tests haben) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

19 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 einem Indentierungstool Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

20 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 refactorieren nach der Implementierung Refactoring-Tasks abarbeiten Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

21 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 CVS Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

22 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

23 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

24 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

25 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

26 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

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

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

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

30 Fachgebiet Software Engineering. Übersicht. © 27. 03
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University