Akelaï

La maîtrise des projets de développement IT

Projets IT


Visitez notre site Web dédié à l'ingéniérie logicielle et aux projets IT : software.akelai.fr

logo Akelaï Visitez notre site WEB : www.akelai.fr

Le deuxième projet : Revues & Tests

On prétend que la variable d'ajustement (le degré de liberté) du projet doit être coût, délai, ou contenu (fonctionnel).
La réalité est souvent plus prosaïque : quand on a pas le temps, on raccourcit les phases de tests.

Les erreurs

Il n'existe pas en informatique de méthode qui permettent d'éviter l'introduction d'erreurs.

Les progrès du génie logiciel consiste à ce jour à proposer des outils ou méthodes qui permettent de minimiser ces erreurs. Ce seront par exemple:

Il est intéressant de noter que ce sont des outils qui facilitent le travail de reflexion.

Hormis la compilation, qui permet effectivement d'identifier des erreurs de codage (code syntaxiquement incorrect), il n'existe pas en informatique de moyen automatique de détecter les erreurs.

Celles-ci peuvent être de tous ordres:

Le coût des erreurs

On conçoit, et des études l'on montré, que le coût de correction croisse exponentiellement avec le temps mis pour détecter l'erreur.

Ainsi, une erreur d'expression de besoin pourra être détectée et corrigée avant les spécifications au prix de quelques échanges et réunions, puis une reprise de document.
Si elle est détectée en cours de phase de spécification l'impact délai sur le projet sera déjà significatif. Le travail de spécification aura pu prendre une mauvaise direction. Cela pourra nécessiter plusieurs réunions de clarification client/fournisseur ainsi que des réunions internes, et il faudra réviser tout ou partie du travail. Le coût est clairement plus élevé d'un facteur 10.
Si elle est détectée en phase de codage, il faut alors interrompre le codage et réouvrir la reflexion sur les spécifications, alors que le personnel en charge des specs pourra être déjà affecté à d'autres tâches. Selon le cycle de développement, la préparation de la phase de test sera aussi impactée. Le côut global de reprise est à nouveau multiplié par 10.

On peut pousuivre l'exemple en considérant la phase de test, puis la phase de déploiement site et enfin la prise en main par le client.
En fait, c'est souvent sur site que le client va s'impliquer à nouveau dans le projet: il verra enfin le produit alors qu'en amont il trouvait souvent indigestes les centaines de pages de spécification qui lui étaient soumises. C'est le grand écart du cycle en V ou se correspondent horizontalement les deux phases extrêmes besoin / recette client.
Le prototypage est une réponse possible: réaliste, le prototypage sollicite le retour du client non sur une montagne de papier mais sur un aperçu du futur produit.

Revues et Tests

La réponse usuelle à l'absence de moyen systématique de détection des erreurs est l'introduction de revues et de tests. Toutes les méthodes de développements documentées en font mention (Cycle en V, ISO 12207, CMMI ...). Mêmes les méthodes dites agiles sont parfois injustement attaquées sur ce point, bien que relevant d'une approche différente, mais peut-être plus extrêmiste [1].

La pratique des revues est ancienne. Elle a même été renforcée sous le vocable d'"inspection" [2]. La pratique des tests date des débuts de l'informatique: la première méthodologie de Génie Logiciel étant réduite à "code and debug" !

Mais qu'en est-il des pratiques réelles ? Si les "inspections" ont succédé aux "revues", c'est dans l'espoir de pallier l'inefficacité des revues. Sans grand effet car l'efficacité d'une revue dépend de la disponibilité et de l'implication des participants. Or ceux-ci découvrent souvent en réunion le document à revoir ...
Si les phases de tests sont bien là, elles sont souvent écourtées pour livrer sous la pression des délais.
Le résultat est systématiquement contre-productif : défauts détectés plus tard dans le cycle de développement, avec l'impact mécanique sur les coûts, et le délai final.

C'est la rationalité économique du projet qui est mise en jeu: au lieu de dépenser 100 en développement et 50 en qualification, on alloue toutes les ressources au developpement -- soit 150 -- puis on est contraint de dépenser à nouveau 200 en qualification trop tardive accompagnée des reprises nécessaires.

Le Deuxième Projet

Le "deuxième projet" désigne le projet de qualification ("revue et test") dont l'objectif unique est de vérifier et valider le système développé. Sa justification est d'abord économique: toute lacune ou délai dans les activités de contrôle entraînera à terme un surcoût global. Mais il sera aussi justifié par le respect des délais et la qualité du produit.

Le deuxième projet repose sur les deux principes:

Le Projet de Qualification est responsable de la stratégie de test, des outils de tests (y compris leur développement s'il y a lieu), de la description et de l'exécution des tests, de leur revue, du suivi des anomalies. C'est un projet parallèle et lié au projet de développement. Il a notamment devoir et pouvoir de s'assurer de la prise en compte, par le projet de développement, des contraintes de testabilité.

Son cycle de vie est le suivant:

En prenant l'analogie d'un moule qui définit la pièce que l'on veut créer, le projet de qualification définit le moule dans lequel pourra être coulé le produit. La qualité du moule déterminera la qualité du produit. Le moule est ici le jeu de tests auquel devra se conformer le produit. Le moule et la pièce doivent tous les deux être conformes aux spécifications, et il peut arriver que l'erreur soit le fait du moule et non du produit. Cela est sans importance, car tout écart entre les deux donnera lieu à analyse et confrontation aux spécifications si nécessaire.
De la même façon que le moule doit pré-exister à la pièce, il est important que le jeu de test soit disponible très tôt car dès que les développements commenceront, le moule incarnera les spécifications.

Le deuxième projet a la responsabilité de la testabilité du produit :

Intégrer toutes ses activités dans un cadre projet dédié doit garantir leur bonne exécution et les protéger d'une dilution (délai, resources) dans le planning projet.

Références

[1] Kent Beck, Test-Driven Development, Addison-Wesley

[2] M. E. Fagan, Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal Vol15, N°3, 1976, Reprint Vol38, N°2&3, 1999


© Akelaï Conseil 2006-2018. Akelaï Conseil encourage l'usage de navigateurs internet respectueux des normes : Google Chrome, Firefox, Opera, Safari.

Valid CSS Valid XHTML 1.0