Gestion des Exigences, du plan de tests et des divergences

Exigences - Tests - Divergences

1 - Gestion des Exigences

Les « exigences » sont de diverses catégories (besoins fonctionnels, contraintes techniques, contraintes de ressources, etc.). La gestion des exigences se base sur les principes RAD de «validation permanente » et de « mode opératoire des communications ».

Durant la phase de Cadrage, un projet informatique doit prouver sa rentabilité qui n'est pas uniquement financière. La qualité et la réactivité qui sont liées aux conditions de travail doivent s'évaluer méthodiquement. Cette analyse ne se limite pas au niveau global du projet, mais s'applique dans la mesure du possible à chaque fonctionnalité pour en justifier la nécessité et en déterminer la priorité.

Une méthode d'évaluation et de pilotage par les enjeux s'organise autour de quatre grandes catégories quantifiables ou au minimum identifiables : qualité de service, productivité, impacts financiers, conditions de travail. La pratique démontre que ces effets sont en général conjoints. C’est un postulat de la réingénierie des procédés. Dans les grands projets, durant la phase de cadrage stratégique, le recours à un spécialiste des enjeux est conseillé.

Toujours suivant le principe du « nécessaire et suffisant », le groupe d’animation et de rapport formalise l’expression des exigences lors des entretiens de Cadrage. Les fonctions du futur produit doivent être caractérisées par des critères d'évaluation. On distingue les fonctions d'usage des fonctions d'estime ainsi que les fonctions de services des fonctions techniques (contraintes). Lors de l'analyse fonctionnelle, on spécifie exhaustivement les contraintes (environnement, technologie, performance, etc.).

Toutes les fonctions n'ont pas la même importance, cette importance s'exprime par un poids. La définition des fonctions, de leur importance, de leur valeur ajoutée et de leur coût est la base de calcul d'un poids qui justifie leur priorisation . L'analyse du rapport valeur ajoutée/coût détermine les anomalies comme la présence ou la demande de fonctions secondaires à des coûts anormalement élevés.

L’information basique d’une gestion formelle des exigences se structure ainsi :

  • l’identification et la description des exigences,
  • leur regroupement et leur structuration hiérarchisée,
  • leur priorisation suivant divers critères,
  • leur évaluation suivant deux approches (manuelle arbitraire ou justifiée en détail).

    L’évaluation ROI (retour sur investissement) comprend deux parties : les gains attendus, les investissements à réaliser (charges, matériel, exploitation, etc.).

    Note : cela peut sembler simpliste, mais dans la pratique l’efficacité d’une approche de ce type est évidente. Bien rares sont les projets bénéficiant de telles informations pour justifier leur rentabilité et pour prioriser ou réduire leurs fonctionnalités.

    2 - Gestion du plan de tests

    Le plan de tests a pour objectif de vérifier l’adéquation des composants d’une application avec les exigences exprimées par les utilisateurs et formalisées dans le document de Cadrage. Les éléments de vérification composant le plan de test découlent naturellement de l’expression des exigences. L’exécution du plan de tests met en évidence des anomalies, des évolutions et de nouvelles exigences qui activent les procédures de gestion des divergences.

    Une détection précoce des erreurs ou des problèmes permet une correction immédiate, un développement moins coûteux, une recette plus rapide et une maintenance moins coûteuse par la suite. Aussi, intégrer les tests au développement dès le début d’un projet s’avère une des solutions des plus efficaces pour réduire la recette traditionnelle.

    Eléments majeurs de la mise en œuvre de cette pratique, les outils de pilotage des campagnes de tests sont proposés par plusieurs acteurs : Microsoft, Compuware, Mercury, Rational, etc. Parmi les divers outils du marché, certains proposent de gérer simultanément les « exigences » de l' application. C'est alors à partir de la gestion de ces exigences que les cas de tests sont envisagés. Le produit permet alors de présenter des matrices croisées (spécification / cas de test) grâce auxquelles on pourra vérifier la couverture de validation.

    Avec la méthode RAD, les tests unitaires et d'enchaînements sont permanents durant toutes les étapes de la phase de Construction.

  • Etude de Yphise sur les outils de Tests

    3 - Gestion des divergences

    Les divergences résultent d'un dysfonctionnement du logiciel par rapport à ce qui est attendu au moment de la validation. Ce problème résulte en général d’une anomalie de développement ou d’une évolution (prévisible ou non). Les divergences sont de type technique ou de type fonctionnel. Le traitement des divergences donne lieu à :

  • la production d’une fiche de « suivi »,
  • l’évaluation de la charge induite par la correction,
  • l’opération de réduction de la divergence,
  • l’ordonnancement d’un test de non-régression.

    Une divergence provient d’une anomalie signalée ou d’une évolution demandée. Outre la distinction pouvant être faite entre les divergences de type technique ou les divergences de type fonctionnel, les écarts qui peuvent intervenir entre les attentes de l’utilisateur et le produit proposé à la livraison (ou en cours d’élaboration) sont généralement de trois types :

  • évolution du besoin ou émergence d’un nouveau besoin,
  • réalisation divergente du besoin fonctionnel exprimé,
  • anomalie de caractère technique (problème ou non-respect d’une contrainte). Les techniques de « validation permanente » et de « prototypage actif » qui sont à la base de la levée naturelle du risque inhérente à la méthode RAD rendent théoriquement impossible la notion « réalisation divergente du besoin fonctionnel exprimé ».

    De même, le cycle itératif caractéristique de cette méthode permet naturellement la prise en compte des évolutions durant les phases initiales du projet. Néanmoins, malgré la souplesse et le dynamisme de l’approche RAD, il est nécessaire de gérer les évolutions et les anomalies dans la rigueur.

  • www.RAD.fr ® © Jean-Pierre Vickoff