Développement basé sur les fonctionnalités
Cet article est une ébauche concernant le management et l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Pour les articles homonymes, voir FDD.
Le développement basé sur les fonctionnalités (de l'anglais feature-driven development ou FDD) est un processus de développement de logiciel itératif et incrémental.
Il est l'une des méthodes légères ou Agile pour le développement de logiciels. FDD regroupe un certain nombre de meilleures pratiques reconnues par l'industrie en un tout cohérent. Ces pratiques sont toutes issues d'une perspective de fonctionnalité valorisée par le client. Son objectif principal est de fournir des logiciels de travail tangibles et répétés en temps opportun.
Histoire[modifier | modifier le code]
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.
Vue d'ensemble[modifier | modifier le code]
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.
Développer le modèle général[modifier | modifier le code]
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.
Liste de fonctions de construction[modifier | modifier le code]
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.
Plan par fonctionnalité[modifier | modifier le code]
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.
Conception par fonction[modifier | modifier le code]
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.
Construire par fonctionnalité[modifier | modifier le code]
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.
Étapes importantes[modifier | modifier le code]
Étant donné que les fonctionnalités sont petites, compléter une fonction est une tâche relativement petite.
