Brontekst bekijken van Feature-driven development

'''Feature-driven development''' ('''FDD''') is een [[agile-softwareontwikkeling]]smethode.

Het is in 1997 door Jeff De Luca bedacht om aan de specifieke eisen van een grote [[Singapore]]se 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 ==
[[Afbeelding:Fdd process diagram.png|thumb|250px|Meta-process model voor FDD]] 
FDD is een model-driven-[[softwareontwikkelmethode|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 [[Unittesten|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)
*FDD Project Manager Application
*FDD Tools
*FDD Tracker
*FDD Viewer
*TechExcel DevSuite

==Externe links==
*{{en}}[http://www.featuredrivendevelopment.com/ Featuredrivendevelopment.com/]
*{{en}}[https://web.archive.org/web/20080314071540/http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/APGTFDDChapter02.html Feature-Driven Development:Projects and People]
*{{en}}[https://web.archive.org/web/20090430130421/http://www.designit.com.au/articles/fdd_web_development FDD & Web Development]
*{{en}}[http://www.methodsandtools.com/archive/archive.php?id=19 Delivering Real Business Value using Feature Driven Development]

[[Categorie:Agile-softwareontwikkeling]]