Het is in 1997 door Jeff De Luca bedacht om aan de specifieke eisen van een grote Singaporese bank te voldoen, met een project van vijftien maanden lang en 50 man groot. De Luca leverde een set van vijf processen die de ontwikkeling van een globaal model, de registratie, planning, ontwerp en implementatie van features beschrijven. FDD is voor het eerst beschreven in het boek “Java Modeling in Color with UML” uit 1999 waarvan Jeff De Luca mede-auteur is. In 2002 wordt een meer algemene beschrijving gegeven in het boek “A Practical Guide to Feature-Driven Development”.
Fases
Meta-process model voor FDD
FDD is een model-driven-ontwikkelmethode die uit vijf basistaken bestaat. De eerste drie zijn opeenvolgend en hierin wordt het globale model gemaakt. De laatste twee werkzaamheden worden voor elke feature herhaald. De werkzaamheden zijn als volgt:
Develop overall model
Het project start met een walkthrough van de scope en de context van het systeem. Dit dient als basis voor een aantal modellen die door kleine groepen gemaakt zijn en ter feedback worden vrijgegeven. Van deze modellen wordt een globaal model gemaakt.
Build feature list
De kennis die tijdens het modelleren is verzameld wordt gebruikt voor een lijst van alle features. Features zijn in dit geval gedeeltes van functies die door de klant als waardevol getaxeerd zijn met de vorm “<actie> <uitkomst> <object>”. Een voorbeeld hier van is: “Uitprinten factuurregels van een factuur”. Features kunnen niet meer dan twee weken duren, anders moeten ze in kleinere componenten opgedeeld worden.
Plan by feature
Nadat de featurelijst gemaakt is, kan er met het ontwikkelingsplan begonnen worden. Features worden naar classes vertaald, zodat class ownership aan de hoofdprogrammeurs gekoppeld kan worden.
Design by feature
Voor elke feature wordt er een ontwerp gemaakt. De hoofdprogrammeur kiest een aantal features uit die binnen twee weken ontwikkeld kunnen worden. Hierna werken de class owners samen met de hoofdprogrammeurs het ontwerp uit tot sequence diagrammen en als laatst wordt er een ontwerpinspectie gehouden.
Build by feature
Als de inspectie van het ontwerp gelukt is worden de features geïmplementeerd. De class owners implementeren hun eigen classes en na een unittest en code inspection kan de voltooide feature als main build fungeren.
Practices
FDD is ontstaan uit een set van best practices uit de software-industrie. Door deze practices te gebruiken kan men eigenlijk niet om FDD heen.
Domain object modeling: dit is het onderzoeken en uitleggen van het probleemgebied dat opgelost dient te worden. Hieruit resulteert een domain object model dat een globaal framework weergeeft.
Developing by feature: alle features die niet binnen twee weken geïmplementeerd kunnen worden, moeten opgesplitst worden totdat elke feature minder dan twee weken kost.
Component/class ownership: ownership houdt in dat stukken code en classes een eigenaar toegewezen krijgen, die verantwoordelijk is voor de consistentie, performance en de integriteit hiervan.
Feature teams: een feature team is een klein, dynamisch team, dat elke ontwerpbeslissing goed overweegt door alle meningen te evalueren.
Inspections: inspecties zorgen voor een goede kwaliteit van het ontwerp en de code, hoofdzakelijk door het detecteren van fouten.
Configuration management: configuratiemanagement zorgt ervoor dat de broncode van de features eenvoudig geïdentificeerd kan worden aan de hand van de datum en er zo ook een versie- en wijzigingengeschiedenis beheerd wordt.
Regular builds: deze regelmatige builds moeten ervoor zorgen dat het systeem altijd up-to-date is en aan de klant gedemonstreerd kan worden. Hierdoor worden integratiefouten sneller ontdekt.
Visibility of progress and results: door de voortgang veelvuldig naar iedereen te rapporteren, moeten de managers inzicht hebben in het werk en daardoor het project goed kunnen sturen.
Tools
FDD maakt gebruik van verschillende tools die speciaal voor deze softwareontwikkelmethode gemaakt zijn.
FDD Manager (wordt sinds oktober 2006 niet meer ondersteund)
