Transcript SE1_K07_Vorgehensmodelle - Software Engineering Research

Vorgehensmodelle: Wasserfallmodell
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Vorgehensmodelle: V-Modell

OO Softwareentwicklung
 inkrementell
 prototypisch
 iterativ
 Use-Cases driven
 Architekturbeschreibung durch Klassendiagramme
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Vorgehensmodelle: V-Modell
Fachgebiet Software Engineering
University
Übersicht

Submodule
 Projektmanagement
 Qualitätssicherung
 Softwareentwicklung
 KonfigurationsManagement

definiert Rollen

beschreibt Aktivitäten und
Produkte

definiert Werkzeuge
© 13.04.2015 Albert Zündorf, Kassel
Spiralmodel nach Barry W. Boehm
Anforderungen
Design
Test
Implementierung
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Vorgehensmodelle: Der Unified Process
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Requirements Capturing
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Requirements Refinement
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Story Driven Modeling
1.
requirements scenarios
2.
application scenarios
3.
story boards & GUI mockups
4.
class diagrams
5.
tests
6.
method development
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Quanten Metapher von Kurt Schneider
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Datenflussmodellierung mit FLOW (Kurt Schneider)
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Communication Patterns (Kurt Schneider)

Dokumente
 Reproduzierbar,
 Aufwendig
 Nachfragen schwierig

Gespräche
 Nicht reproduzierbar
 Billig
 Interaktiv
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Communication Patterns

Meetings
 Eingeschränkt reproduzierbar durch Minutes
 Mittlere Kosten
 Mittlere Interaktivität

Mail
 Reproduzierbar (auch wenn es sich privat anfühlt)
 Mittlere Kosten
 Mittlere Interaktivität
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Communication Patterns (Kurt Schneider)
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Übersicht

eXtreme Programming
 Das Planungsspiel
 Testen
 Pair Programming
 Raumaufteilung
 on-site customer
 Design
 Metapher
 Gemeinsamer Codebesitz
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Story Card
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Task Card
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Testen
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Raumaufteilung
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Einfaches / simples Design

Die Lehrmeinung
impliziert:

Kent Beck’s Meinung
impliziert
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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 TaskCard 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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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-StartUps)
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Rollen in einem XP-Projekt



Tester
 einer im Team
 unterstützt den Kunden beim Schreiben der funktionalen Tests
Tracker
 einer im Team
 schiebt die "Done" Markierungen auf dem Balkenplan weiter
 führt Produktivitätsstatistiken
Coach
 einer im Team
 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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
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
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Scrum / Agilo:

User Stories / Tasks wie XP

Product Owner == Onsite Customer

Kleine Releases

Burn Down Charts >== Planungsspiel

Scrum Master >== ?

Daily Scrum Meeting >== ?
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Kanban
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Semat Software Engineering Method and Theory

Ivar Jacobson

Comming soon …
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Das liebe Geld

Angebot

Bestellung / Vertrag

Rechnung

Festpreis Produkt
(Design by Budget)

Dienstleistung (Arbeitsstunden)
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Twenty dirty tricks to train software engineers; Ray Dawson ICSE 2000
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel
Fachgebiet Software Engineering
University
Übersicht
© 13.04.2015 Albert Zündorf, Kassel