Estimation des projets logiciels : science ou magie ? En choisissant ainsi ce sujet récurrent pour thème de son séminaire de la mi-juin cette année, le Centre de maîtrise des systèmes et du logiciel pose d’emblée la question de la fiabilité des méthodes.Du modèle d’appréciation de l’effort Cocomo (Constructive Cost Model) de Boehm à celui d’Albrecht, dit “points de fonction” – les deux les plus utilisés -, en passant par le Slim de Putnam, les responsables de l’assurance qualité n’ont que l’embarras du choix.La plupart du temps, la mise en ?”uvre se révèle, en effet, très délicate dès lors que l’on s’écarte des modèles sans les maîtriser. Et l’arrivée des projets de commerce électronique ou de développement web n’a rien simplifié en imbriquant le marketing ou la gestion de la chaîne logistique au cycle de vie logiciel traditionnel.
“Entre sorcellerie et n’importe quoi”
En pratique, les modèles d’estimation sont assez peu employés. Même s’ils constituent des outils performants pour surveiller les dépenses réalisées sur les systèmes d’information.Pour Benoît Blot, directeur informatique du groupe Flo, “la bonne méthode se situerait entre la sorcellerie et le n’importe quoi. On pourrait l’appeler expérience. Mais le plus difficile à estimer, c’est l’arrivée – et notamment la gestion – du changement. Sur un projet de six mois, par exemple, nous ne sommes pas à l’abri d’une réorganisation chez les utilisateurs qui travaillent avec nous. “Ainsi, la direction informatique du traiteur et restaurateur ne peut prévoir les multiples aléas de ce type qu’à l’aide d’une connaissance empathique du groupe. Donc, le plus souvent, on s’adapte. Y compris chez les prestataires, qui peuvent, eux, travailler sur des bases de projets beaucoup plus importantes.Consultant chez Atos-Origin, Jean-François Baillot se spécialise dans l’évaluation des charges de maintenance : “Sur ce sujet, il y a peu d’études, déplore-t-il. Cocomo n’en parle pas beaucoup, mais demande d’évaluer le pourcentage de code modifié dans l’année. Ce qui est très difficile. “Ainsi, c’est l’expérience ou les échanges avec des clients rusés qui fournissent ce genre d’observations : “Lorsque les dépenses en maintenance atteignent la valeur de celles en développement, je commence à envisager de récrire le produit. ” Au fil du temps, la méthodologie s’affine, et une batterie de nombres “magiques” apparaît. Malgré tout, les techniques se renouvellent, se précisent, et ne doivent donc pas être jetées aux orties. La dernière version de Cocomo se décompose désormais en trois sous-modèles – un pour chaque phase du projet: la faisabilité, la définition, et le développement proprement dit.
Incertitude sur les projets de type internet
Au lieu d’entrer d’emblée dans le détail, chaque étape permet de procéder à un affinage supplémentaire. De plus, les facteurs d’ajustement de la formule d’effort (voir encadré Modélisation) prennent en compte les nouvelles typologies de projets, comme les applications de commerce électronique, les sites internet ou intranet.C’est peut-être sur celles-ci que l’incertitude demeure. Peut-on leur appliquer des méthodes de pronostic alors que les retours d’expérience quantifiés restent peu nombreux ? D’un point de vue technique, la réponse est oui, car bon nombre d’applications internet sont conçues comme des applications client-serveur. “Le passage vers une architecture à trois ou n niveaux n’est pas fondamentalement différent de celui vers une architecture client-serveur “, complète Hani Wazni, directeur de projet chez Valtech, société de services.En revanche, d’un point de vue pratique, la réponse est non, car les programmes internet ou de commerce électronique intègrent aussi bien le marketing, la publicité et la logistique que la réorganisation des processus au cycle de développement logiciel traditionnel. Cette fusion des tâches devrait peser sur de nombreux facteurs, tels que la productivité ou la complexité, définissant les modèles.Mais l’utilisation concrète de méthodologies d’estimation reste ardue. La première difficulté concerne l’absence de métriques satisfaisantes. “Entre le début et la fin d’un projet, la population peut changer, les technologies aussi. Et, en général, les deux le font en même temps “, souligne François de Verdière, directeur de la société de services IMR Global. Il est ainsi très difficile de définir correctement des hypothèses de recueil de métriques.La deuxième difficulté touche la délimitation. “Au moment de l’estimation, les besoins ne sont pas exprimés. Ou alors, ils le sont mal, insiste François de Verdière. D’ailleurs, les appels d’offre pour des projets aux périmètres flous sont suicidaires pour ces derniers !” En outre, les charges peuvent se dissimuler dans les recoins les plus inattendus.On en découvre dans les interactions entre les différents modules logiciels, les portions de code mort, les tests d’intégration, l’efficacité des équipes, la ma”trise de la technologie, ou, de plus en plus, dans un cahier des charges en perpétuelle évolution. Enfin, le troisième problème réside dans la forte variabilité de la productivité. Si l’on s’est aperçu que les outils causent rarement des retards, il n’en va pas de même pour les équipes.
Des modèles plutôt difficiles à utiliser
Au sein d’un projet, la productivité individuelle peut varier de 1 à 5. On s’est aussi rendu compte qu’un expert ne codait pas plus qu’un débutant, voire moins, mais avec une qualité supérieure. Les baisses de productivité s’expliquent également par la découverte, lors d’un projet, d’un domaine fonctionnel ou technique. Enfin, les modèles restent incomplets. Ils ne couvrent pas bien les systèmes à l’algorithmique complexe – par exemple, les entrepôts de données.Quant aux deux les plus connus, Cocomo et les points de fonction, l’un ne dit pas comment trouver les lignes de code – à la base du calcul -, tandis que l’autre ne mesure ni la qualité ni la complexité technique.Ces écueils ne doivent pas cacher les bénéfices tangibles d’une bonne estimation, notamment en termes de gestion.Arnaud Hertz, vice-directeur d’une entité d’EDF chargée du pilotage opérationnel des projets, juge la pratique nécessaire, mais trop juste: “Elle n’est pas suffisante pour qu’ils finissent bien, mais elle est indispensable pour ceux qui nécessitent plusieurs mois. ” C’est notamment le cas quand il s’agit d’argumenter une révision à la baisse des desiderata – en cas de délais trop tendus, par exemple. Ou encore pour décider de fractionner un projet qui prendra trop d’ampleur. Mais l’utilisation des modèles reste sans doute le meilleur moyen d’entrer dans l’intimité d’un projet logiciel. Et, ainsi, d’en identifier les pièges.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
