Upload
doanhanh
View
224
Download
0
Embed Size (px)
Citation preview
2
Überblick: Feature Driven DevelopmentWoher kommt FDD?
Voraussetzungen
5 (Teil-)Prozesse
Rollenmodell
Vorteile von FDD
Wie passt das ins V-Modell XT?
Fazit
Überblick
3
Jeff De Luca
1997 Singapore-Projekt17 Monate, 50 Entwickler
mit Peter Coad
Kontinuierliche Weiterentwicklung
http://www.featuredrivendevelopment.com
Beschreibung auf 10 Seiten:http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf
Woher kommt FDD?
Jeff De Luca
4
5 (Teil-)Prozesse
RollenmodellProjektleiterEntwicklungsleiterChefarchitekt (Chefmodellierer)Chef-ProgrammiererEntwicklerFachexperten
Was ist FDD?
5
Ziele:Domäne kennenlernenund verstehen
Fachliches Klassenmodell
Ggf. auch Sequenzdiagramme
Beteiligte: Chefarchitekt = Moderator
(Chef-)Programmierer
Fachexperten
Vorgehen:Meist Modeling In Color
Entwickle Gesamtmodell
6
Ziele:Alle Anforderungen in Form von Features liegen vor
Basis für weiteres Vorgehen und Schätzung
Beteiligte: Chef-Programmierer
Anschließend Abstimmung mit Fachexperten
Erstelle Featureliste
Feature-Schema:
<Aktion> <Ergebnis> <Objekt>
Beispiel:„Berechne Summe der Rechnungspositionen.“
Hierarchie der Features:Major Feature Set (Geschäftsbereich)
Feature Set (Geschäftstätigkeit)
Feature (Systemfunktion)
7
Ziele:Projektplan erstellen
Aufwände und Termine klären
„Flow“ für alle Entwickler herstellen
Beteiligte: Projektleiter
Entwicklungsleiter
Chef-Programmierer
Plane je Feature
Vorgehen:Feature-Klassen-Beziehungen ermitteln
Class-Owner festlegen
Arbeitsbelastung ausbalancieren
Es ergeben sich Feature-Teams: Alle Class-Owner der beteiligten Klassen.
9
Ziele:Gemeinsamen Entwurf erstellen
Aus gemeinsamen Entwürfen lernen
Beteiligte: Feature-Team
ggf. Chefarchitekt
ggf. Chef-Programmierer
Entwirf je Feature
Vorgehen:Im Team
Klassen- und Sequenzdiagramme erstellen
Design-Inspektionen
Nach „Entwirf je Feature“ folgt immer direkt
„Konstruiere je Feature“ desselben Features!
10
Ziele:Produktivklassen erstellen
Tests erstellen
Programmieren verbessern/lernen
Beteiligte: Feature-Team
ggf. Chefarchitekt
ggf. Chef-Programmierer
Konstruiere je Feature
Vorgehen:Class-Owner programmieren Produktivklassen
Class-Owner erstellen Tests
Im Team erfolgen Code-Inspektionen
Je Feature dauert „Entwirf je Feature“ und „Konstruiere je Feature“ nicht länger als 2 Wochen!
12
Hierarchisches Rollenmodell
Projekt-leiter
Chef-Entwickler
Chef-Entwickler
Chef-Entwickler
Entwick-lungs-leiter
Chef-Model-lierer
Entwickler Entwickler EntwicklerEntwickler EntwicklerEntwickler Entwickler Entwickler Entwickler
DynamischesFeatureteam
13
Wasserfall vs. Feature-Wirbel
Analyse
Entwurf
Konstruktion
Test
Feature 1
Feature 2
Feature n
…
Feature 1
Feature 2
Feature n
…
Feature 1
Feature 2
Feature n
…
14
Wasserfall vs. Feature-Wirbel
Analyse (grob)
Feature 1
Feature 2
Feature n
Entwurf
Konstruktion
Test Entwurf
Konstruktion
Test Entwurf
Konstruktion
Test
15
Klar beschrieben
Weniger Hürden für viele Organisationen(im Vergleich zu anderen agilen Methoden)
Skaliert gut
Auch für große Projekte geeignet
Initiale Modellierungsphase explizit vorgesehen(und auf angenehmer Abstraktionsebene)
Passt gut zu Festpreiskonstellationen
Vorteile von FDD
20
Und bestehen aus:UML-Color-Model (der Kernkonzepte)
Feature-Liste (feingranular)
Das hat große Vorteile:Erstellung im direkten Dialog
Unklarheiten können wechselseitig sofort geklärt werden
Erleichtert Aufwandsschätzungen
Granularität ist direkt zur Strukturierung des Projektes geeignet(deshalb „feature-driven“)
Schneller Entwicklungsstart möglich
Bei FDD fallen Lastenheft und Pflichtenheft zusammen
21
FDD bietet leichtgewichtige ModelleFeature-Listen zur AnforderungsbeschreibungColor-Modeling zur Kern-ArchitekturbeschreibungEin einfaches ProzessmodellEin klares Rollenmodell
FDD kann mit leichten An-passungen auch V-Modell-XT-konform werden
Für manches Projektsetting(Team, Kunde, Größe) ist FDD eine Alternative!
Fazit