1. www.mind-testing.fr Par Jean-Christophe Rodrigues Practice Leader Testing
2. COCOMO (acronyme de l'anglais COnstructive COst MOdel) Conçu en 1981 par Barry Boehm, COCOMO est une méthode statistique permettant d'estimer le coût d'un développement logiciel. Boehm, Barry W., Software Engineering Economics, (1981)
   1. COCOMO établit une estimation des coûts et une répartition des charges d'un projet par phase en prenant en compte dans son modèle de "Base": -> un niveau de complexité -> une taille de code (en millier de ligne) Le deuxième modèle, appelé "Intermédiaire", comprenant 15 facteurs de productivité appelés aussi "cost drivers" venant en ajustement du modèle de "Base" (cf ci-contre). Le troisième modèle, dit "Expert", inclue toutes les caractéristiques du modèle "Intermédiaire" avec une estimation de l'impact de la conduite des coûts sur chaque étape du cycle de développement.
      1. Modèle "Intermédiaire" - Les 15 "Cost drivers" Chacun des 15 "Cost drivers" reçoit un classement sur une échelle de 6 niveaux d'importance allant de "très faible" à "très élevée" permettant de générer un coefficient appelé "facteur d'ajustement d'effort" venant s'appliquer à l'équation de base COCOMO.
         1. Attributes
            1. Run-time performance constraints Memory constraints Volatility of the virtual machine environment Required turnabout time
            2. Required software reliability Size of application database Complexity of the product
            3. Analyst capability Applications experience Software engineer capability Virtual machine experience Programming language experience
            4. Application of software engineering methods Use of software tools Required development schedule
   2. Répartition des charges par phase selon la "Complexité" et la "Taille du code".
   3. Equation de base de COCOMO
3. Oui mais...
   1. Remarque 1] Une des difficultés de cette méthode est de parvenir à estimer le nombre de ligne de code de la future application avant même d'en avoir démarré le projet! Elle a tout de même permis (et le permet encore) d'obtenir une enveloppe budgétaire "grosse maille" assez réaliste pour de nombreux projet. Mais dans notre cas, les charges de tests dépendent de cette estimation. (à noter que la version COCOMO II intégre dans son mode de calcul, les langages orientés objets)
   2. Remarque 2] Dans le Modèle de "Base": Si le pourcentage de la charge de conception générale ne change pas au sein d'un même niveau de complexité, quelque soit le nombre de ligne de code que comprendra le futur programme, nous pouvons en revanche constater que l'impact se portera sur les charges de développement et de test, les premières se réduisant au profit des secondes. Pour COCOMO => plus votre application devient complexe et aura de ligne de code, plus il sera nécessaire de faire des tests (hors Tests Unitaires compris dans les développements)...
      1. Complexité "Simple"
      2. Complexité "Moyenne"
      3. Complexité "Forte"
      4. Comparaison des phases de tests entre elles selon la complexité et la taille du code
   3. Remarque 3] Aucun des "Cost driver" de la méthode "Intermédiaire, ni le modèle "Expert", ne tiennent compte des Risques en Production or, si vous vous en souvenez, un des critères majeurs pour calculer l'effort de test, c'est bien la prise en compte de la notion de Risque ! (cf sujet "Pas de risque, pas de test… Vrai ou Faux?" et "Questions clés concourant à l’estimation des charges de test")
4. COCO - RI - MO où comment ajouter la notion de Risque au modèle COCOMO pour ajuster l'équation de calcul de l'effort lié plus spécifiquement au Test
   1. Qu'est-ce qu'un Risque? Définition du Larousse : Possibilité, probabilité d'un fait, d'un événement considéré comme un mal ou un dommage : Les risques de guerre augmentent. En informatique, un risque est une probabilité d'échec liée à une fréquence d'utilisation d'une fonction métier et d'un potentiel défaut dans le code de celle-ci majorée par les dommages potentiels causés en production (perte de chiffre d'affaire, perte d'image de marque, ...). Si par exemple, sur un site de e-commerce, la fonction de constitution d'un panier d'achat ne fonctionne alors que nous sommes en pleine période d'achat de Noël, le dommage pour cette entreprise pourra être considérable, alors que pour autant, constituer un panier d'achat n'est pas une fonction métier complexe et ne doit pas nécessiter de nombreuses lignes de code de programmation. Une attention toute particulière au niveau des tests est toutefois fortement nécessaire.
   2. Mais alors, quelle estimation des tests par COCOMO dans ce cas là ? A priori, elle sera faible car la notion de Risque en tant que tel n'intervient dans aucun de ses modèles et équations.
   3. La considération du Risque devrait être prise comme une pondération supplémentaire (en plus ou en moins) dans les équations d'estimation des charges à l'heure où il est important de rationaliser l'effort de test.
   4. Proposition: Création d'une matrice d'aversion permettant de catégoriser chacune des Exigences à développer selon des critères de risques. L'effort de Test COCOMO est ensuite pondéré par la note moyenne obtenue au travers de notre analyse de risque.
   5. L'effort de Test COCOMO est maintenant pondéré par la note moyenne obtenue au travers de notre analyse de risque. Comment cela se traduit-il? Si nous reprenons l'exemple de la fonctionnalité de notre panier d'achat (l'exercice est à faire sur l'ensemble des fonctionnalités à développer), il s'agit d'une fonction métier simple avec peu de ligne de code mais l'impact pourrait être fort en termes de dommage si celle-ci ne fonctionne pas. La potentialité que cela se produise n'est pas neutre non plus au vue de la diversité et de l'hétérogénéité des différents navigateurs existants (IE, Google Chrome, Firefox, Safari, etc.) Selon COCOMO, l'effort de test en pourcentage du développement, serait de 16% pour cette fonction comme pour toutes les autres sans différentiation de risque. Tel que je l'aborde aujourd'hui, majoré par les risques, l'effort de test au regard des développements devient pour cette fonction de: 16% * 1,5 = 24% Cette exercice demande peu de travail mais une très bonne relation avec la MOA, la MOE et la Production pour que l'équipe de Test puisse ajuster ses charges à une réelle analyse de risque.