Développement basé sur les fonctionnalités

L'approche FDD a été initialement conçue par Jeff De Luca (en) pour répondre aux besoins spécifiques d'un projet de développement logiciel de 15 mois et 50 personnes dans une grande banque de Singapour en 1997. Jeff De Luca a livré un ensemble de cinq processus couvrant le développement d'un modèle global et la liste, la planification, la conception et la construction des fonctionnalités. Le premier processus est fortement influencé par l'approche de la modélisation d'objets de Peter Coad (en). Le deuxième processus intègre les idées de Peter Coad sur l'utilisation d'une liste de fonctionnalités pour gérer les exigences fonctionnelles et les tâches de développement. Les autres processus et l'assemblage des processus en un tout cohérent est le résultat de l'expérience de Jeff De Luca. Depuis son utilisation réussie sur le projet de Singapour, il y a eu plusieurs implémentations de FDD.

La description de FDD a d'abord été introduite dans le monde dans le chapitre 6 du livre Java Modeling in Color with UML de Peter Coad, Eric Lefebvre et Jeff De Luca en 1999. En 2002, dans le livre de Stephen Palmer et Mac Felsing A Practical Guide to Feature-Driven Development, une description plus générale de FDD a été donnée, découplée de la modélisation Java.

Les processus FDD originaux et les plus récents peuvent être trouvés sur le site de Jeff De Luca sous la rubrique « Article ». Il existe également un site Web communautaire où les gens peuvent en apprendre davantage sur les DM, les questions peuvent être posées, et les expériences et les processus eux-mêmes sont discutés.

FDD est un processus d'itération à courte durée qui se compose de cinq activités de base. Pour obtenir des rapports d'état précis et suivre le projet de développement logiciel, les étapes qui marquent les progrès réalisés sur chaque fonctionnalité sont définies. Cette section donne un aperçu de haut niveau des activités. Dans la figure de droite, le modèle de métaprocessus pour ces activités est affiché. Durant les deux premières activités séquentielles, une forme de modèle globale est établie. Les trois dernières activités sont itérées pour chaque caractéristique.

Le projet FDD commence par une visite guidée de haut niveau de la portée du système et de son contexte. Ensuite, des modèles de domaine détaillés sont créés pour chaque domaine de modélisation par petits groupes et présentés pour examen par les pairs. L'un des modèles proposés, ou une combinaison de ceux-ci, est choisi pour devenir le modèle pour chaque domaine de domaine. Les modèles de zone de domaine sont progressivement fusionnés en un modèle global.

Les connaissances recueillies lors de la modélisation initiale sont utilisées pour identifier une liste de caractéristiques en décomposant le domaine en domaines. Les domaines thématiques contiennent chacun des activités commerciales et les étapes de chaque activité constituent la base d'une liste de caractéristiques catégorisées. Les caractéristiques à cet égard sont de petites pièces de fonctions valorisées par le client exprimées sous la forme <action> <result> <object>, par exemple : « Calculer le total d'une vente» ou «Valider le mot de passe d'un utilisateur ». Les fonctionnalités ne devraient pas prendre plus de deux semaines à compléter, sinon ils devraient être ventilés en petits morceaux.

Une fois la liste de fonctions terminée, l'étape suivante consiste à produire le plan de développement; Attribution de la propriété des fonctionnalités (ou ensembles de fonctionnalités) en tant que classes aux programmeurs.

Un package de conception est produit pour chaque fonctionnalité. Un programmeur en chef choisit un petit groupe de caractéristiques qui doivent être développées dans les deux semaines. En collaboration avec les propriétaires de classes correspondants, le programmeur en chef établit des diagrammes de séquence détaillés pour chaque caractéristique et affine le modèle global. Ensuite, les prologues de classe et de méthode sont écrits et finalement une inspection de conception est tenue.

Après une inspection de conception réussie, une activité de caractéristique pour produire une fonction (caractéristique) à valeur client est planifiée. Les propriétaires de classe, chacun développent le code pour leurs classes. Après les tests unitaires et l'inspection du code réussie, la fonctionnalité terminée est promue à la construction principale.

Étant donné que les fonctionnalités sont petites, compléter une fonction est une tâche relativement petite.