Dynamic systems development method

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article ne cite pas suffisamment ses sources (juillet 2025).

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 ?

Dynamic systems development method (DSDM) est une méthode de gestion de projet de la catégorie des méthodes agiles. Cette méthode a été développée en Grande-Bretagne à partir de 1994.

Principes

La méthode DSDM s'appuie sur 9 principes de base :

Implication des utilisateurs durant tout le cycle de développement. Ils sont considérés comme des membres à part entière de l'équipe projet ;
Autonomie. L'équipe projet doit avoir un pouvoir de prise de décision concernant l'évolution des besoins ;
Visibilité du résultat. L'application doit être livrée le plus souvent possible afin de permettre un retour d'expérience rapide. Les délais entre les livraisons doivent être le plus court possible ;
Adéquation. L'objectif est de livrer une application en adéquation avec le besoin métier du client ;
Développement itératif et incrémental. L'évolution du développement est basée sur le retour d'expérience des utilisateurs ;
Réversibilité. Toute modification effectuée durant le développement doit être réversible ;
Synthèse. Un schéma directeur défini de manière préalable fixe les grandes lignes du projet, notamment son périmètre ;
Tests. Les tests sont continus durant tout le développement. Ils permettent de garantir le bon fonctionnement de l'application, à chaque étape du développement ;
Coopération. Les acteurs du projet doivent faire preuve de souplesse concernant les modifications des fonctionnalités demandées.

Processus

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Étude de faisabilité : Le but de cette étape est de déterminer s'il est opportun de faire le projet en question. On évalue les coûts, la valeur ajoutée attendue. Dans cette étape, on produit un Rapport de Faisabilité ainsi qu'un Plan Global de Développement. On développe parfois un prototype afin de démontrer la faisabilité technique.
Étude business (ou analyse fonctionnelle) : Cette étape sert à la définition des spécifications. On définit quelles sont les fonctionnalités que l'application doit apporter, en les priorisant, dans un document appelé Définition du Domaine Industriel, mais aussi quels types d'utilisateurs sont concernés par l'application, de manière à pouvoir les impliquer. On définit également l'architecture du système, dans un document appelé Définition de l'Architecture Système. Enfin, à partir du Plan Global de Développement, on définit un Plan Global de Prototypage.
Modèle fonctionnel itératif :
Conception et réalisation itératives :
Mise en œuvre :

Voir aussi

Liens externes

(en) Site officiel central

Portail de l’informatique

A PHP Error was encountered