Développement basé sur les fonctionnalités

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

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'un d'un certain nombre de 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]

FDD a été initialement conçu par Jeff De Luca 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 qui ont couvert 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 Peter Coad approche de la modélisation d'objets. 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 le mélange 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 avec UML [1] de Peter Coad, Eric Lefebvre et Jeff De Luca en 1999. Plus tard, dans Stephen Palmer et Mac Felsing livre A Practical Guide À Feature-Driven Development [2] (publié en 2002), une description plus générale de FDD a été donnée, découplé 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. Pour plus d'informations sur les différentes sous-activités, consultez le tableau 2 (dérivé de la description du processus dans la section «Article» du site Web de Jeff De Luca). Les concepts impliqués dans ces activités sont expliqués dans le Tableau 3.

Modèle de processus pour les FDD

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.