Chez NEOXIA, les agilistes laissent aussi la parole aux praticiens du cycle en V.

Par ce que chez NEOXIA nous aimons les échanges, les débats et la pluralité de pensées, en interne notre majorité dominante agiliste laisse aussi s’exprimer des pratiques plus formalisantes nécessaires dans certains contextes difficiles.

C’est pourquoi nous publions ce retour d’expérience d’un de nos consultants qui lors d’une situation projet très tendue utilisa cette approche non-agile.

————————————————————————————————————————


Vos projets informatiques respectent trop rarement l’enveloppe budgétaire allouée initialement ? Leur planning dérape systématiquement ? Chaque membre de l’équipe projet se justifie en accusant « l’autre » d’être responsable de la situation ?

Cette problématique, malheureusement trop courante, est générée par plusieurs facteurs :

  • Manque d’implication des utilisateurs,
  • Défaut de sponsoring des directions associées,
  • Mauvais énoncé des besoins…

Les deux premiers écueils peuvent être évités par une volonté collective de mener à bien le projet.

1

Le défaut le plus répandu est une mauvaise prise en compte des besoins.

Une bonne pratique simple, appelée « Ingénierie des Exigences » (Requirements Engineering), permet de fédérer l’équipe projet et de s’assurer de l’exactitude et de la complétude des besoins. L’expérience prouve qu’une communication efficace alliée à l’Ingénierie des Exigences dès la phase amont d’un projet est un facteur de succès incontestable.

RETOURS D’EXPERIENCE SUR L’ECHEC DES DEMARCHES EMPIRIQUES :

Les premières phases d’un projet sont primordiales pour anticiper son succès.

Beaucoup d’équipes se lancent d’emblée dans du développement applicatif avant d’avoir complètement saisi les enjeux du projet, de les avoir partagés, et d’avoir passé en revue l’ensemble des besoins. Le résultat évident est une solution qui n’est pas en adéquation avec les véritables besoins des utilisateurs.

De même, si les membres de l’équipe projet ont l’habitude de documenter les phases amont par un cahier des charges ou des spécifications, ces livrables respectent rarement un standard exploitable. Pourtant, la qualité de ces livrables est d’autant plus importante que la relation entre les protagonistes est contractuelle, ie si les acteurs qui réalisent sont prestataires de l’équipe formalisant les besoins (ex : cas d’un appel d’offres).

Par ailleurs, l’effort passé à rédiger une documentation exploitable ne doit pas figer des processus métiers dont la valeur ajoutée pour l’entreprise provient de leur pragmatisme.

Comment, dans ce cas, réussir et maintenir à jour l’inventaire des besoins ?

METHODOLOGIE DE L’INGENIERIE DES EXIGENCES :

Une « exigence logicielle » est l’expression formalisée d’un besoin émis par le ou les métiers qui utiliseront le futur système. Elle décrit soit le produit, soit le service rendu par le système. En phase amont de la conception d’un système d’information, on qualifie de « Spécification des Exigences Logicielles » (SEL) le livrable correspondant aux SFD classiques, basé sur l’utilisation d’exigences.

L’Ingénierie des Exigences est une méthode permettant à l’ensemble des parties prenantes d’un projet informatique de s’accorder sur l’ensemble des besoins auxquels devra répondre le système à construire.
Cette approche systématique et rigoureuse est basée sur la spécification et la gestion des exigences permettant :

  • de connaitre les besoins pertinents du métier, d’atteindre un consensus entre les parties prenantes sur ces besoins, de les formaliser en respectant une normalisation, et de les tracer tout au long du projet,
  • de comprendre et de formaliser les demandes des parties prenantes et leurs besoins,
  • de spécifier et de gérer les exigences pour minimiser le risque de livrer un système ne répondant pas aux attentes des parties prenantes.

2

Processus de développement des exigences

Le développement des exigences s’inscrit dans une série de quatre étapes :

  • « l’élicitation » ou collecte du besoin,
  • « l’analyse » ou formalisation des exigences selon des règles précises,
  • « spécification » : le business analyst doit s’assurer de la cohérence globale et de l’exhaustivité des besoins,
  • « la validation » : plusieurs approches permettent de contractualiser les besoins entre les parties prenantes.

La valeur ajoutée de l’ingénierie des exigences consiste à transformer un besoin brut émis en un livrable clair et complet. Les exigences peuvent être typées, priorisées et restent modifiables et traçables tout au long du projet.

Le principe de traçabilité des exigences consiste à mettre, en regard de chaque niveau de détail du besoin, une solution qui répondant à chaque exigence. Ainsi, chacune d’entre elles pourra être testée indépendamment.

INTERETS DE LA METHODE :

  • Diminuer les flous et ambiguïtés sur les besoins,
  • Contractualiser ce qui doit être réalisé (engagement du métier),
  • Donner une vision cohérente et globale du système.

Lorsque l’équipe projet est scindée en deux points de vue à priori opposées « MOA vs MOE », cette méthode est très utile. De même, dans le cas d’un SI dont les utilisateurs appartiennent à des métiers distincts, le pilotage du projet par les exigences facilite la validation de la cohérence globale du SI.