Feature Driven Development

Feature Driven Development (FDD) wurde 1997 von Jeff De Luca und Peter Coad als schlanke Methode für die Softwareentwicklung entworfen. Im Laufe der Zeit wurde die Methode kontinuierlich weiterentwickelt. FDD stellt den Begriff "Feature" in den Mittelpunkt der Entwicklung. Ein Feature ist dabei definiert als etwas, was in den Augen des Kunden nützlich ist. Jedes Feature stellt somit einen Mehrwert für den Kunden dar. Die Beschreibung eines Features erfolgt in einem Satz nach dem Schema:

  • Action: Berechne
  • Result: das Saldo
  • Object: des Kontos

Features sind also sehr feingranulare Funktionen. Oftmals bestehen zwischen den Features Abhängigkeiten. Zusammenhängende Features werden zu so genannten Feature Sets gruppiert. Die Beschreibung eines Feature Sets folgt dabei dem Muster:

  • Action: Mak- -ing: -ing 
  • object: a product sale

Feature Sets wiederum werden zu übergeordneten fachlichen Gruppen, den Major Feature Sets, zusammengefasst. Die Major Feature Sets werden beschrieben nach dem Schema:

  • <object>management - Beispiel (in Englisch): "product sale management"

Für die Umsetzung dieser Features sieht FDD Prozesse, Rollen und Best Practices vor. Alle drei Bereiche werden auf den folgenden Seiten ausführlich beschrieben. Hier vorab die Bewertung des FDD-Vorgehens durch BQI Research.

Bewertung BQI Research

FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.

  • Bekanntheitsgrad und Verbreitung bewegen sich insgesamt im mittleren Bereich.
  • Es existiert spezielle Tool-Unterstützung.
  • Die Methode ist nicht normiert/standardisiert, aber zertifiziert.
  • Keine Lizenzierung erforderlich.
  • Support ist vorhanden.

zurück zur Studie