Table des matières - Sommaire - Dernières modifs - Site DSDM France - Page imprimable

Principes de base

Ce chapitre décrit les principes de base sur lesquels repose la méthode DSDM. Chacun de ces principes est appliqué, de façon appropriée, au cours des différentes étapes de cette méthode.

1. L'implication active des utilisateurs est indispensable.

   L'approche DSDM est centrée sur l'utilisateur. En effet, si les utilisateurs ne sont pas fortement impliqués tout au long du cycle de vie du développement, un fossé peut se creuser au fur et à mesure que les décisions sont prises. Les utilisateurs peuvent alors ressentir que la solution finale leur est imposée par les développeurs et/ou leur encadrement. La place des utilisateurs n'est pas en dehors de l'équipe de développement, fournissant des informations et contrôlant les résultats mais au contraire directement au sein du processus de développement et en y participant activement.

2. Pouvoir de décision des équipes DSDM.

   Les équipes DSDM sont formées à la fois de développeurs et d'utilisateurs. Elles doivent être capables de prendre des décisions lorsque les besoins évoluent ou sont modifiés. Ces équipes doivent être en mesure de statuer et d'accepter certains niveaux de fonctionnalité, d'utilisation, etc. sans avoir recours trop fréquemment à leurs supérieurs hiérarchiques.

3. Livraison fréquente de produits.

   Une approche basée sur les produits est plus flexible qu'une approche basée sur les activités.

   Une équipe DSDM travaille essentiellement sur des produits pouvant être livrés dans un délai négocié. Ceci permet à l'équipe de choisir la meilleure façon de réaliser les produits demandés dans le laps de temps alloué. En utilisant des délais courts, l'équipe peut facilement décider quelles activités sont nécessaires et suffisantes pour réaliser de bons produits.

   Remarque : le terme "produits" comprend les produits de développement intermédiaires, et pas uniquement les systèmes livrés.

4. L’adéquation aux besoins est le critère essentiel pour que les produits livrés soient acceptés.

   L'objectif principal de DSDM est de livrer la fonctionnalité nécessaire en temps voulu. Si ce principe est acceptable, le système pourra être amélioré ultérieurement. Les pratiques habituelles privilégient plutôt l'application d'un cahier des charges et la conformité aux éléments déjà livrés, même si les besoins sont souvent imprécis, que les éléments précédemment livrés peuvent être imparfaits et que les besoins de gestion peuvent avoir changé depuis le début du projet.

5. Il est nécessaire d'utiliser un développement itératif et incrémental pour obtenir une solution adaptée aux besoins.

   La méthode DSDM permet de développer des systèmes de façon incrémentale. Ainsi, les développeurs peuvent tirer pleinement profit des retours utilisateurs. De plus, il est possible de livrer des solutions partielles pour répondre à des besoins de gestion urgents.

   L'itération est propre à tous les développements de logiciels. DSDM en tient compte de façon explicite et utilise donc l'itération pour améliorer en permanence le système en cours de développement.

   Lorsque le travail de reprise n'est pas pris en compte de façon explicite dans le cycle de vie du développement, il est nécessaire de revenir à une étape antérieure "terminée" d'un travail et les procédures de contrôle requises alors retardent le développement. Comme le travail de reprise est intégré dans le processus DSDM, le développement peut continuer plus rapidement pendant le processus d'itération.

6. Toutes les modifications effectuées au cours du développement sont réversibles.

   Pour contrôler l'évolution de tous les produits (documents, logiciels, produits de test, etc.), l'état de chaque élément doit être connu à tout instant. Ce qui signifie que la gestion de la configuration doit être omniprésente.

   Le "backtracking" (retour en arrière) est une caractéristique de DSDM. Cependant, il est parfois préférable de recommencer plutôt que de revenir en arrière. Ceci dépend de la nature de la modification et du contexte dans lequel elle a été effectuée. L'annulation de modifications n'est possible qu'au sein d'une étape incrémentale de développement.

7. Les besoins sont définis à un niveau global.

   La spécification et l’initialisation d’une référence des besoins JB9x à un niveau global sert à déterminer et à « geler » les objectifs et le périmètre du système, permettant ainsi une étude approfondie des implications de ces besoins. D’autres actualisations de la référence peuvent être effectuées en cours du développement mais le périmètre ne doit pas être modifié sauf de façon limitée.

8. Les tests sont intégrés à toutes les étapes du cycle de vie.

   Les tests ne sont pas traités comme des activités indépendantes. Développé de façon incrémentale, le système est également testé et révisé de manière incrémentale par les développeurs ainsi que les utilisateurs. Grâce à cette approche, non seulement le développement évolue dans la bonne direction par rapport aux besoins industriels, mais il est techniquement adéquat. En amont dans la démarche DSDM, les tests permettent surtout de vérifier la conformité aux besoins du business et le respect des priorités. Vers la fin du projet, l’accent est mis plutôt sur le bon fonctionnement de tout le système.

9. Une approche basée sur la collaboration et la coopération entre toutes les personnes intéressées par le projet est essentielle.

   De par la nature même des projets DSDM, les spécifications détaillées n’ont pas nécessairement été définies lorsque les développeurs sont initialement sollicités pour effectuer le travail. La direction à court terme que doit prendre le projet devra donc être décidée rapidement, sans recourir à des procédures de contrôle, des modifications restrictives.

   Les personnes concernées par le projet incluent non seulement le métier et l’équipe de développement directement concernés, mais aussi d’autres équipes telles que celles de support et de gestion des ressources.

   Lorsque le développement est assuré par une société externe, le fournisseur et le sous-traitant doivent avoir pour objectif la mise en œuvre d’un processus aussi efficace que possible et offrant toute la souplesse voulue durant la phase d’avant-contrat et durant l’exécution des travaux faisant l’objet de ce contrat.

© 1997-2002 Dynamic Systems Development Method France - Une réalisation Pilot Systems - Powered by Zope