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

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

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

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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

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

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

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

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

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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 © 28.03.2017 Albert Zündorf, Kassel University

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

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

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

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

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