SE1_K07_Vorgehensmodelle - Software Engineering Research
Download
Report
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