Concept: Trouver un équilibre entre les priorités des parties prenantes
Ce principe traite de l'importance de l'équilibrage des besoins des parties prenantes.
Description principale

Introduction

Ce principe traite de l'équilibrage des besoins des parties prenantes et des besoins métier souvent conflictuels, ainsi que de  l'équilibrage du développement personnalisé par rapport à  la réutilisation des actifs concernant la satisfaction de ces besoins.

    
Avantages
  • Aligner les applications avec les besoins utilisateurs et métier
  • Réduire le développement personnalisé
  • Optimiser la valeur métier
Pattern
  1. Définir, comprendre et hiérarchiser les besoins métier et utilisateur
  2. Hiérarchiser les projets et les exigences et associer les besoins aux fonctionnalités du logiciel ;
  3. Connaître les actifs dont on peut tirer profit ;
  4. Equilibrer la réutilisation des actifs avec les besoins utilisateur
Anti-Patterns
  • Documenter avec précision les exigences au début du projet, forcer l'acceptation des exigences des parties prenantes.
    • Négocier les changements d'exigences, lorsque chaque changement peut accroître le coût ou la durée du projet.
    • Verrouiller à l'avance les exigences, réduisant ainsi la capacité à tirer profit des actifs existants.
    • Effectuer d'emblée un développement personnalisé.
  • Construire un système uniquement pour satisfaire les besoins des parties prenantes qui se font le plus entendre.

Discussion

Par exemple, la plupart des parties prenantes préféreront avoir une application qui effectuent exactement ce qu'elles veulent faire tout en minimisant le coût de développement de l'application et le temps de la planification. Cependant, ces priorités entrent souvent en conflit. De même, si nous tirons profit d'une application pré-intégrée, il est possible que nous puissions délivrer plus rapidement une solution et à un coût inférieur, mais cela impliquera des compromis sur de nombreuses exigences. Si, en revanche, nous choisissons de construire une application à partir de rien, il est possible que cette application gère toutes les exigences, mais que le budget et la date d'achèvement du projet dépassent les limites acceptables.

L'utilisation d'un composant peut réduire les coûts de manière radicale et le temps prévu pour délivrer un certain ensemble de fonctionnalités. Parfois, il faut aussi compromettre les exigences fonctionnelles ou techniques, comme la prise en charge de plateformes, les performances, les dimensions (taille physique de l'application).

Pour être en mesure d'équilibrer les besoins, il est tout d'abord nécessaire de gérer les exigences de manière efficace comme indiqué dans  Matériel de support : Gestion des exigences. Plutôt que d'affecter des équipes de programmation pour traiter chaque élément d'une liste d'exigences, il est nécessaire de comprendre et de hiérarchiser les besoins métier et des parties prenantes. Cela suppose la capture des processus métier leur mise en relation avec des fonctionnalités projets et logicielles, permettant de hiérarchiser de manière efficace les projets et les exigences et de modifier cette hiérarchisation à mesure que la compréhension de l'application s'accroît et que les parties prenantes évoluent. Cela signifie également qu'il est nécessaire d'impliquer le client ou le représentant du client dans le projet afin de connaître ses besoins.

Parallèlement, il est nécessaire de centrer les activités de développement autour des besoins des parties prenantes. Par exemple, en tirant profit d'un développement guidé par les cas d'utilisation et d'une conception centrée sur l'utilisateur, le processus de développement peut prendre en compte les besoins des parties prenantes tout au long du projet, en fonction des changements métier et d'une connaissance accrue des fonctionnalités qui sont fondamentaux pour l'entreprise et les utilisateurs finals. 

Enfin, il est nécessaire de connaître les actifs disponibles et d'équilibrer la réutilisation des actifs avec les besoins des parties prenantes. Les actifs sont par exemple des applications existantes, des services, des composants réutilisables ou des patterns. La réutilisation des actifs peut, dans la plupart des cas, conduire à une réduction des coûts du projet. La réutilisation d'actifs éprouvés se traduit souvent par une meilleure qualité des nouvelles applications. L'inconvénient est que, dans de nombreux cas, il est nécessaire de faire un compromis entre la réutilisation des actifs et la parfaite satisfaction des besoins de l'utilisateur. La réutilisation d'un composant peut minimiser les coûts de développement d'une fonction de 80 pourcent, mais ne satisfaire les exigences qu'à 75 pourcent. Par conséquent, une réutilisation efficace implique un équilibrage constant entre la réutilisation des actifs et l'évolution des besoins des parties prenantes.