La prédiction exacte de la taille des logiciels, des délais et charges de développement et de test sont des préoccupations récurrentes de l’industrie du logiciel. Certaines ESN

 

utilisent des abaques inter

 

nes, d’autres des standards ou de pseudo bonnes pratiques fournissant des estimations plus ou moins exactes. Ces inexactitudes sont normales, les projets étant soumis à de nombreuses contraintes – techniques, budgétaires ou calendaires – imposées, rarement anticipées ou mesurées. Les prédictions servent principalement à définir les coûts et les délais de réalisation, pour des offres financières. Si les prévisions sont irréalistes et/ou intenables il en résultera insatisfactions et litiges.

À partir des objectifs du projet, une bonne prévision permet de définir les charges de toutes les phases du projet ; de bonnes mesures permettent d’en suivre l’accomplissement jusqu’à son terme.

Un projet a pour objet de réaliser un produit ; une bonne prévision permet, à la fois pour les modèles séquentiels (cycle en V) ou agiles (Scrum) de :

• Mesurer le produit – en termes de qualité et de complétude
• Évaluer les processus (en termes d’efficience et d’efficacité)

 

 

Prévoir : pourquoi et comment ?

 

Les prévisions de charges et de délais peuvent être requises (les niveaux de maturité CMMI 2 et 3 exigent une estimation des charges) ou utiles afin de créer un consensus entre les parties sur le projet à partir de données objectives. Cela permet de les comparer, dans le temps ou vis-à-vis d’autres projets.

Une bonne prévision informera sur toutes les charges de conception, de réalisation et de test de systèmes logiciels. Il sera nécessaire d’identifier les charges et les délais, mais aussi toutes les suppositions, les hypothèses et leurs impacts.

Diverses méthodes existent pour estimer les charges, certaines sont empiriques et incomplètes, d’autres ont des adeptes plus ou moins nombreux, d’autres encore sont basées sur un corpus de standards internationaux et de normes reconnues.

 

Prévision et Qualité

 

Diverses méthodes de prévision utilisées :

• Des abaques « maison » existent dans beaucoup d’ESN, souvent limitées aux projets et expériences spécifiques de l’ESN.
• COCOMO (Common Cost Model) et COCOMO2 introduits par Dr. Barry BOEHM (cf. [BOEHM00]), fournit une estimation en nombre de lignes de code (KLOC Milliers de Lignes de Code) et en déduit des charges de développement.
• FPA (Function Point Analysis) proposé en 1979 par Allan ALBRECHT d’IBM, qui estime la taille selon les fonctionnalités, indépendamment du langage de programmation utilisé.

 

Les abaques « maison » ont leur utilité, mais sujettes à caution vu leur confidentialité et le petit nombre de projets sur lesquelles elles portent.

Pour COCOMO, la reproductivité des résultats n’est pas assurée, les critères de pondération du calcul variant selon les individus pour un même projet et le nombre de lignes de code variant selon les langages de programmations (certains sont plus verbeux que d’autres), les techniques utilisées (Orienté Objet), les modes de développement (TDD, ATDD et BDD ajouteront du code de test), les habitudes individuelles des développeurs (certains écriront plus de lignes de code écrites pour réaliser une même fonctionnalité).

Les points de fonction (FP) sont basés sur des standards internationaux : OMG, CISQ, COSMIC (ISO19761), FiSMA (ISO29881), IFPUG (ISO20926), NESMA(ISO 24570), Mark-II (ISO 20968). Des estimations par des personnes différentes d’un même projet donneront des résultats similaires, indépendants du langage, de la technique ou du développement utilisé.

 

Regarder devant ou derrière ?

 

Paraphrasons Niels Bohr : « les prédictions sont toujours difficiles, surtout si elles concernent le futur ». Certaines entreprises mesurent la taille en Points de Fonction (FP) des logiciels développés pour elles. Ceci est utile pour estimer le volume du patrimoine informatique et en tirer une charge de maintenance. Une telle mesure « à postériori » permet aussi comparer des développements et de vérifier l’exactitude de la méthode de prévision utilisée (efficace dans le cadre d’un retour d’expérience). Dans le cadre de nouveaux développements, il faut faire des prévisions pour :

• prendre des décisions d’investissement, correctement dimensionner les équipes et s’assurer du réalisme des charges et délais de réalisation ;
• tout au long du projet, de comparer le réalisé avec le planifié (identifié par ces prévisions) ;
• identifier rapidement les tendances et les corriger afin de guider le projet vers le succès.

 

L’utilisation des points de fonction peut donc servir à regarder le passé ou à anticiper le futur.

 

Quoi inclure ?

 

Le calcul de Points de Fonction est associé à de nombreuses hypothèses portant sur :

• Le projet : sa taille, sa complexité, son type et sa criticité,
• Les méthodes de développement : cycles séquentiels, itératifs ou incrémentaux (lotissement), agiles ou livraison continue,
• Le type et la maturité des activités d’assurance qualité, de façon à éviter l’introduction de défauts en amont du code, et des activités de test pour filtrer les défauts en aval du code,
• Les compétences et expériences des équipes et leur répartition géographique,
• Le nombre et la complexité des fichiers et transactions, en entrée ou en sortie,
• La facilité d’utilisation, de modification, d’installation, de paramétrage, etc.

 

Une fois ces hypothèses définies, nous obtenons un ensemble de prévisions associées au projet (durée, effort de réalisation…) au produit (nombre d’anomalies, durée de réalisation, taille de l’équipe…) et aux processus qui le réalisent (efficacité et efficience).

 

Prédire quoi ?

 

Pour un produit, nous devrions pouvoir prédire un ordre de grandeur en nombre de lignes de code (selon le type de langage – des facteurs de conversion permettent la conversion de FP en Lignes de Code (LOC) selon le langage). La taille et la complexité influencent le nombre de défauts générés lors de la conception. Ce nombre de défauts permettra d’anticiper l’effort de test nécessaire pour les identifier et le nombre d’itérations pour les corriger.

La prévision basée sur les Points de Fonction porte sur un projet entier. Des informations permettent de chiffrer les grandes phases d’un projet (Conception Générale, Conception Détaillées, Codage, Tests d’Intégration, Tests Système, etc.), mais il restera à détailler chacune des activités du projet. D’autres techniques d’estimation de charge seront alors nécessaires (Delphi à 3 points, User Stories, WBS, expérience de projets similaires, etc.). La somme des charges individuelles pourra être validée par comparaison avec les valeurs identifiées par le calcul des points de fonction.

 

Points de Fonction ou Story Points ?

 

Les Story Points, utilisés en Agile, s’approchent des cas d’utilisation tout en ne se référant pas à une méthode de calcul standardisée. Les membres de l’équipe Agile définissent l’effort de réalisation en se basant sur une estimation individuelle de toutes les tâches à réaliser (par exemple avec du Planning Poker). Deux estimations d’une même charge de travail pourront avoir des résultats différents alors qu’ils seraient identiques avec un calcul des points de fonction.

L’estimation en Points de Fonction est utile en début de projet pour définir un budget / effort global.

 

 

Prévisions

 

Prenons quelques exemples pour des tailles de projets différents :

 

Tableau 1 : Données par Points de Fonction

 

Prévisions d’incertitude

 

La prévision des charges existe depuis de nombreuses années et le niveau d’incertitude va en se réduisant au fur et à mesure de l’avancement du projet. L’incertitude varie de x4 à x0,25 en début de projet, pour se réduire à zéro en fin de projet. À partir d’une prévision calculée sur base de Points de Fonction, il est possible de représenter ces incertitudes.

Figure 1 Trompette d’Incertitude

Prévisions sur base des Points de Fonctions

 

Diverses informations peuvent être déduites d’un calcul de Points de Fonction, par exemple :

• L’effort de réalisation (en Mois/homme), la taille de l’équipe et la durée du projet
• Le nombre de cas de test ainsi que la durée de conception de ces cas de test
• Le nombre de défauts (produit du nombre de FP et du taux de défauts par FP)
• Le ratio entre Développement, Tests et autres activités (exigences, encadrement, etc.)

 

Sur la base des données du Tableau 1 et des activités incluses dans le projet (variant selon le type et la taille du projet, cf. [JONES07]), la durée des activités ainsi que leurs impacts sur la qualité du produit (injection ou suppression de défauts) peuvent être estimées. Ceci nous permet d’estimer le DDP (pourcentage de détection des défauts ) qui anticipe le niveau de qualité du produit (cf. Figure 2).

 

 

Figure 2 Prévision du nombre de défauts

 

Prévision d’Efficacité sur base des Défauts

 

L’efficacité des processus de détection des défauts (revues, inspections ou tests  manuel ou automatisés) peut être mesurée si l’on connait le nombre total de défauts. Nous pouvons prédire la répartition des défauts sur les divers livrables et activités.

Étudions la Figure 3 : à l’étape TS (tests système) et nous pouvons voir que seul 54% des défauts ont été détectés alors que l’objectif était de près de 80%. Sur base de cette information, il est évident que :

–  nous ne devrions pas livrer le logiciel dans l’état actuel,

–  que nos processus de détection de défauts sont à améliorer,

–  que nous devons rajouter du test.

 

Figure 3 Pourcentage de Détection des Défauts

 

Prévision de charge sur base des défauts

 

Vous connaissez certainement le coût et la charge moyenne de correction des défauts de vos projets. Elle varie probablement entre 2 et 4 heures par défaut. Lors du calcul de la charge du projet, anticipez-vous l’impact de ce nombre de défauts ? Multiplier le nombre total de défauts prévu par la charge moyenne de chacun des défauts permet d’anticiper la charge de correction et de retest nécessaire.

Certaines activités sont bénéfiques sur le projet et réduisent significativement le nombre de défauts. Des informations statistiques (cf. [JONES08] et [JONES12]) permettent d’identifier la réduction de charge totale sur le projet qu’il est possible d’obtenir en mettant en œuvre certaines activités (revues de code, inspection d’exigences, etc.). Un calcul de retour sur investissement justifie fréquemment de mettre en œuvre ces activités sur le projet.

 

Autres prévisions

 

Les points de fonction nous permettent de prédire de nombreux autres éléments :

• La taille des livrables autres que le code (exigences, spécifications, cas de test, etc.)
• L’effort de maintenance pour garder l’application à jour,
• L’effort d’encadrement, les charges de réunions, etc.

Même si l’imprécision est de l’ordre de 5% à 10%, cela permet une estimation globale suffisante.

 

Prévisions Agiles

 

Qu’en est-il dans les projets agiles ? Des mesures statistiques publiées manquent. Il sera donc nécessaire pour chaque équipe de mesurer ses propres métriques et d’en tirer des enseignements. Ceci est prévu dans les pratiques agiles lors des retours d’expérience qui doivent avoir lieu à la fin de chaque itération. Notre expérience nous pousse à noter que seulement un nombre réduit de projets remontent et utilisent ces métriques.

Utilisation des prévisions

 

Que le projet soit Agile ou séquentiel, les prévisions peuvent être comparées aux résultats obtenus. L’identification de différences importantes peut nécessiter :

• Une analyse des causes à l’origine de ces différences (causes racines), afin de déterminer s’il s’agit d’une aberration ou d’une estimation trop optimiste ou trop pessimiste ;
• Une mise à jour des abaques et règles de calcul pour avoir une meilleure estimation lors de l’itération ou du projet suivant ;
• Des décisions sur l’amélioration ou la modification des activités pour tenir les objectifs définis pour ces activités ;
• Des modifications de processus (introduction de revues, inspections ou analyses statiques) afin de réduire les défauts introduits dans le produit en amont des tests.

 

Les mesures remontées tout au long du projet peuvent aussi être utilisées pour identifier des tendances, remonter des informations aux parties prenantes et comparer des projets entre eux.

 

Améliorations continues

 

Dans les projets agiles, la fin de chaque itération devrait comprendre une activité de « retour sur expérience » ou de « leçons apprises », afin de permettre aux itérations suivantes de bénéficier de l’expérience de l’itération actuelle. L’itération initiale – itération zéro – permet de déterminer une référence pour la vélocité initiale de l’équipe.

Dans le cas de projets traditionnels, l’amélioration continue est souvent laissée à l’initiative du chef de projet et souvent personne n’effectue ces analyses. Quand elles ont lieu, les résultats de ces analyses ne sont pas partagés avec les autres équipes de réalisation. Il en résulte que les abaques et leurs critères d’ajustement ne sont ni mis à jour, ni améliorés.

Quel que soit le mode de développement, une amélioration continue est nécessaire (même exigée sur les niveaux supérieurs de CMMi) pour maitriser processus et charges et pour améliorer l’efficience des activités.

 

Conclusions

 

L’utilisation de Points de Fonction (des outils gratuits ou commerciaux existent pour en faciliter le calcul) permet de prévoir non seulement les charges de développement, mais aussi d’obtenir de nombreuses autres informations utiles sur le projet. Ces informations aident à guider les projets vers le succès avec une définition d’objectifs mesurables, une comparaison du planifié et du réalisé, une identification de tendances et à améliorer l’efficacité et l’efficience des processus.

 

 

 

Pour en savoir plus :

[BOEHM00] Software Cost Estimation with COCOMO II, Barry Boehm

[COHN06] Agile Estimating and Planning, Mike Cohn,

[ISO24748-3] ISO/IEC 24748-3:2011 Ingénierie des systèmes et du logiciel — Gestion du cycle de vie,

[JONES08] Applied Software Measurement 3rd Edition, Capers Jones

[JONES07] Estimating Software Costs 2^nd Edition, Capers Jones,

[JONES12] The Economics of Software Quality, Capers Jones, Olivier Bonsignour

[LAIRD06] Software Measurement and Estimation : A Practical Approach, Linda Laird

Consortium for IT Software Quality  : http://it-cisq.org/

 

 

Bernard Homès               
PDG TESSCO sas              
Fondateur et ex-président du Comité Français des Tests Logiciels         
( bhomes@tesscogroup.com )

Bernard Homès bénéficie d’une expérience de plus de 35 ans dans le domaine de la Qualité et des Tests de logiciels. Il a occupé différents postes clefs à dimension internationale, en Amérique du Nord et en Asie. Depuis 2000, il exerce en qualité de Consultant Senior pour le compte d’entreprises renommées : Eurocopter, Thalès Alénia Space ou encore Orange France. Bernard possède de nombreuses certifications en test (ISTQB CTFL, CTAL-TM, CTAL-TA, CTAL-TTA, CMAP) et en gestion des exigences (IREB et REQB), et se spécialise en audits et mesures.

Bernard est également intervenu en dernière année du Mastère au sein de l’École des Mines de Paris et de HEC, dispense de nombreuses conférences chaque année.

Auteur de deux ouvrages sur les tests de logiciels, il s’implique au sein de nombreuses organisations professionnelles (jury de l’Académie d’experts de FT R&D, auteur et éditeur des Syllabus Avancés de l’ITQSB, membre du bureau exécutif de l’IEEE France, membre fondateur de l’Association for Software Testing aux USA, du GASQ et du CFTL).

 

source : http://www.it-expertise.com/previsions-et-mesure-des-charges-avec-les-points-de-fonctions/