LES 9 PRINCIPES FONDAMENTAUX DE DSDM L'implication active des utilisateurs est impérative DSDM se présente comme une approche centrée sur les utilisateurs. Si les utilisateurs ne sont pas fortement impliqués pendant tout le cycle de vie, on aura des retards dans la prise de décisions. Les utilisateurs ne sont plus seulement des fournisseurs d'information et des recetteurs de modules extérieur à l'équipe, mais de véritables acteurs du développement. Les équipes DSDM doivent être autorisées à prendre des décisions Les équipes DSDM sont constituées des développeurs et d'utilisateurs. Ils doivent être capables de prendre des décisions concernant l'évolution des besoins, et leur éventuelle modification. Ils doivent disposer d'un pouvoir pour déterminer le niveau de fonctionnalité sans avoir recours à la direction. Le produit est rendu tangible aussi souvent que possible Une approche basée sur la livraison régulière de fournitures est plus flexible qu'une approche orientée activités. L'équipe DSDM vise la livraison de fournitures dans un délai limité ; et l'équipe détermine la meilleure approche pour aboutir aux résultats souhaités dans le temps imparti. Des périodes de délais très courts permettent de définir les activités nécessaires pour atteindre les résultats prioritaires. L'adéquation au besoin métier est le critère essentiel pour l'acceptation des fournitures DSDM vise la livraison dans les délais des fonctions métier nécessaire pour satisfaire les objectifs de l'entreprise. Si on le souhaite, le système complet peut être élaboré plus tard. L'approche traditionnelle consiste à répondre aux exigences d'un cahier de charges en restant cohérent avec des produits en place. Trop souvent, on perd de vue le fait que le cahier de charges est inexact et que les produits existants sont imparfaits. Un développement itératif et incrémental permet de converger vers une solution appropriée DSDM permet une évolution incrémentale des systèmes. Par conséquent, l'équipe de développement exploite à fond le contact avec les utilisateurs. De plus, des solutions partielles peuvent être livrées pour satisfaire des besoins immédiats. L'itération est inhérente à la réalisation informatique. DSDM le reconnaît, et pour le rendre explicite, renforce l'emploi de l'itération. Lorsque les rebuts ne sont pas explicitement admis, le retour en arrière est entouré de procédures de contrôle qui ralentissent le développement. Grâce à l'intégration du principe de rebuts dans la démarche DSDM, le développement peut avancer plus rapidement lors des itérations. Toute modification pendant la réalisation est réversible Les retours en arrière font partie du DSDM. Cependant, en certaines circonstances, une reconstruction peut s'avérer plus facile qu'un retour en arrière. Tout dépend de la nature du changement et de l'environnement. Cette réversibilité nécessite une bonne maîtrise de la gestion de configuration du logiciel en développement. Les besoins sont définis à un niveau de synthèse Le schéma directeur fixe les exigences du système à un niveau suffisamment élevé pour permettre une évolution itérative des niveaux plus détaillés. Les tests sont intégrés pendant tout le cycle de vie Les tests ne sont pas traités comme une activité à part. Au fur et à mesure que le système évolue, les tests servent à valider que la réalisation est en cours sur le plan technique et fonctionnel. En amont, les tests assurent que les priorités du développement sont bien prises en compte. Vers la fin d'un projet, les tests assurent les utilisateurs et les développeurs que le système fonctionne efficacement. Un esprit de coopération entre tous les acteurs est primordial Dans la démarche DSDM les fonctions détaillées ne sont pas figées dès le départ. Le fil conducteur doit être défini sans recours à une procédure de gestion de modifications trop contraignante. Le demandeur et le réalisateur doivent faire preuve d'une capacité de souplesse pendant la phase préalable et une fois que le contrat est en cours.