Vorgehensmodelle Wasserfallmodell Fachgebiet Software Engineering University Übersicht

Vorgehensmodelle: Wasserfallmodell Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

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

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

Vorgehensmodelle: Der Unified Process Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Requirements Capturing Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Requirements Refinement Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Quanten Metapher von Kurt Schneider Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

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

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

Communication Patterns (Kurt Schneider) Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

Übersicht m e. Xtreme Programming l Das Planungsspiel l Testen l Pair Programming l Raumaufteilung l on-site customer l Design l Metapher l Gemeinsamer Codebesitz Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

Story Card Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Task Card Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

Testen Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

Raumaufteilung m m m m m 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 kleine Spiele, . . . Tafeln für Diskussionen Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik, Empowerment, . . . ) Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Raumaufteilung Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

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

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

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

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

Kleine Releases m m m m 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 University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

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

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

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

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

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

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

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

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

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

Scrum / Agilo: m Story Cards / Task Cards wie XP m Product Owner == Onsite Customer m Kleine Releases m Burn Down Charts >== Planungsspiel m Scrum Master >== ? m Daily Scrum Meeting >== ? Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Kanban Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel

Semat Software Engineering Method and Theory m Ivar Jacobson m Comming soon … Fachgebiet Software Engineering University Übersicht © 16. 03. 2018 Albert Zündorf, Kassel