Deux mondes pour l'estimation de projets logiciels

Il apparaît à première vue qu'il existe deux mondes pour l'estimation de projet logiciel qui, pour la simplicité, J'appellerai les mondes «chaotique» et «contrôlé». Le monde chaotique se caractérise par la majorité des organisations dont les projets dépassent fréquemment les délais et le budget, ou qui échouent complètement. Le monde contrôlé a une population beaucoup plus petite d'organisations exemplaires dont les projets sont censés être livrés dans les délais et le budget de manière routinière. La question intéressante est de savoir pourquoi les organisations du monde chaotique n'apprennent pas ou ne peuvent pas simplement apprendre et copier le comportement de celles du monde contrôlé et économiser beaucoup d'argent..
Cet article explore les deux mondes et vise à expliquer les différences qui sont en partie intrinsèques et dans une certaine mesure inévitables, et en partie à cause d'un mélange de cultures, processus et facteurs techniques, dont plusieurs peuvent être surmontés avec suffisamment d'effort et de persévérance.
Premier, la preuve des deux mondes.

Le monde chaotique

Il y a eu plusieurs sondages, couvrant le résultat de milliers de projets logiciels, principalement aux États-Unis et au Royaume-Uni et principalement de projets dans le domaine des logiciels d'application métier, dans le secteur public ou privé. Strictement parlant, nous devrions parler de « projets de systèmes à forte intensité de logiciel », étant donné que pour de nombreux projets de ce type, la livraison du logiciel n'est qu'une partie d'un projet qui doit fournir un système matériel/logiciel et souvent un changement organisationnel également. J'utilise des "projets logiciels" pour plus de simplicité. Les résultats varient mais indiquent qu'entre 10% – 30% des projets logiciels échouent complètement, c'est à dire. ils sont arrêtés avant de livrer quoi que ce soit d'utile. Un autre à peu près 50% dépassement de temps et/ou de budget d'au moins 10%. Cela ne laisse que 20% – 40% des projets livrés dans les délais et le budget.

pourtant, ces chiffres ne reflètent pas le fait que de nombreux projets offrent moins de fonctionnalités ou de valeur commerciale que prévu initialement. Plus loin, une proportion inconnue de ces projets qui se sont terminés "dans les délais et le budget" pourraient bien avoir été surestimés en premier lieu et auraient donc pu être livrés plus rapidement et à moindre coût. Abdel-Hamid a observé que la loi de Parkinson s'applique aux projets logiciels comme à toute autre activité, c'est à dire. le travail s'étend pour remplir le temps mis à disposition pour son achèvement.

Le coût de ces dépassements et pannes est énorme. Une analyse bien documentée de 105 projets logiciels sous contrat réalisés au cours des dix années jusqu'à 2007 entre les clients du secteur public britannique et les fournisseurs externes avaient une valeur totale de 29,5 milliards de livres sterling. Parmi ceux-ci, 30% ont été résiliés, 57% dépassements de coûts en moyenne 30.5% (totalisant 9 milliards de livres sterling de dépassements), alors que 33% subi des retards importants. Un point important à noter est que tous ces projets ont été entrepris par des fournisseurs externes qui opèrent dans le monde entier et prétendraient dans leur marketing être « de classe mondiale ».. Plus loin, la marge bénéficiaire des fournisseurs sur les contrats était presque toujours supérieure 10%, allant jusqu'à 25%.

Les mêmes raisons de ces échecs et dépassements sont citées à plusieurs reprises, revenir au moins 30 ans comme décrit dans le livre Crash! Ils se divisent en deux groupes principaux.

1. Manque d'engagement de la haute direction et d'implication des utilisateurs, entraînant des objectifs peu clairs, ce qui conduit à des conflits entre les parties prenantes, et des exigences floues et changeantes.
2. Mauvaise gestion de projet (par exemple. dans la gestion du progrès et des changements), inexpérience du personnel, surtout quand une nouvelle technologie est impliquée, et rotation du personnel.

Alors que le coût des pannes et des dépassements peut être fortement pondéré par les amortissements sur le matériel, le coût de l'embauche de personnel supplémentaire, avantages perdus, etc., les causes sont presque toujours dues à des problèmes de spécification et de développement du logiciel.

Dans toutes les diverses analyses des raisons pour lesquelles les projets logiciels échouent ou dépassent, il est rare de voir une « mauvaise estimation » répertoriée comme l'une des causes. Ce n'est pas surprenant pour les projets qui échouent. Une mauvaise estimation semble une cause peu probable d'abandon d'un projet. Plus probablement, il a été arrêté parce que les priorités ont changé depuis qu'il a commencé et il ne fournira plus rien d'utile, ou il a duré si longtemps au-delà du budget initial que la direction décide de réduire ses pertes. Mais si, dire, 57% de tous les projets logiciels dépassés en moyenne de plus de 30%, on doit se demander 'y a-t-il quelque chose qui ne va pas systématiquement avec le processus d'estimation dans ces environnements?»

Le monde contrôlé

De temps en temps, nous avons un aperçu de cet autre monde lorsqu'une organisation publie des résultats montrant ses succès dans l'estimation de projets logiciels.. L'exemplaire que j'utiliserai est Renault, le constructeur automobile français, qui a publié ses progrès dans l'estimation de projets logiciels réussis, le plus récemment dans 2014.

Une voiture familiale moyenne moderne a environ 50 Unités de contrôle électronique (ECU), petits processeurs qui forment un réseau distribué pour surveiller et/ou contrôler presque toutes les fonctions, par exemple. moteur, lumières, climatisation, pression des pneus, la navigation, informations sur le conducteur, etc. Les calculateurs et leurs logiciels embarqués sont majoritairement achetés auprès de fournisseurs de composants avec leurs capteurs associés, sous réserve d'un cahier des charges émis par Renault.
Renault collecte depuis quelques années des données sur les coûts et les performances de ses fournisseurs de logiciels de calculateurs. Le processus par lequel il s'engage à se procurer des écus est brièvement:

• Départements logiciels Renault, spécialisé par domaine fonctionnel du véhicule (par exemple. groupe motopropulseur), développer des spécifications pour un logiciel ECU nouveau ou amélioré et les stocker dans l'outil Matlab Simulink;
• Un outil développé par Renault calcule ensuite automatiquement une taille fonctionnelle de chaque spécification (ou l'augmentation de la taille si une amélioration) en utilisant la norme ISO COSMIQUE méthode;
• Les mesures passées et les relations établies statistiquement sont utilisées pour prédire l'effort dont le fournisseur aura besoin pour développer le logiciel (voir figure. 1) et sa taille mémoire (figue. 2);
• Cette information est utilisée par le service des achats pour négocier le prix de l'ECU. Plus loin, les informations dont dispose Renault sont désormais suffisamment bien établies pour pouvoir être utilisées pour négocier les évolutions annuelles des prix de la même manière que les constructeurs automobiles négocient périodiquement les prix d'autres matériaux tels que l'acier, peintures etc, et autres composants. (figue. 3);
• Les tailles fonctionnelles COSMIC sont également utilisées pour surveiller les performances du service logiciel interne, puisque Renault a établi une relation cahier des charges-taille/effectifs pour leur travail.

Renault précise qu'à l'issue d'un nouveau développement logiciel, la différence entre l'effort initialement estimé à partir de la corrélation établie et la valeur réelle « doit être inférieure à 5 % » (voir figure. 4).

figue. 1 Effort vs taille COSMIC pour le logiciel ECU

figue. 2 Utilisation de la mémoire par rapport à la taille COSMIC

figue. 3 Négociation Service Achats

figue. 4 Contrôle de la précision des estimations de coûts

Différences entre les mondes chaotique et contrôlé de l'estimation de projet logiciel

Dans ce qui suit, étant donné que des estimations de projet sur toute la durée de vie sont requises quelle que soit l'approche de gestion de projet, J'utiliserai un modèle en cascade des phases du projet pour plus de commodité. Les différences lors de l'utilisation d'un modèle itératif ou agile seront mentionnées au fur et à mesure de leur apparition. Nous devons également supposer que dans les comparaisons des mondes Chaotique et Contrôlé, les organisations des deux mondes ont des processus raisonnablement reproductibles et utilisent une technologie avec laquelle elles sont raisonnablement familières, c'est à dire. nous ignorerons les environnements où l'immaturité des processus et les risques associés à l'utilisation de nouvelles technologies laissent peu de chances de développer des méthodes d'estimation précises.

Différentes conditions pour l'estimation. Dans un sens, il est injuste de faire une comparaison entre les deux mondes car il y a quelques différences intrinsèques entre eux.

La première et la plus évidente différence est que dans le monde chaotique, une estimation des coûts sur toute la durée de vie est généralement nécessaire pour un projet d'application métier au début de sa vie, avant que les exigences ne soient connues en détail, afin d'éclairer l'analyse coûts/bénéfices du logiciel.

En revanche, les projets de devis à achever dans le Monde Contrôlé de Renault ne sont pas réalisés tant que la conception logicielle n'est pas complètement spécifiée, c'est à dire. ce ne sont pas vraiment des estimations sur la vie entière. A ce stade, des estimations peuvent également être faites à un faible niveau de décomposition (Blocages Simulink dans le cas de Renault) avant d'agréger au coût de l'ensemble de l'ECU.

Il est clair que l'on s'attendrait à ce que les estimations de Renault soient beaucoup plus précises que celles faites dans les premières étapes d'un projet d'application métier typique.. Ayant dit cela, il est alors légitime de se demander pourquoi des estimations faites si tôt dans la vie d'un projet, quand il y a encore tant d'incertitude, être accepté comme fixe de sorte que des dépassements sont fréquemment rencontrés. Plus loin, les coûts de maintenance et de support continus qui contribuent à l'analyse de rentabilisation s'avèrent souvent beaucoup plus élevés que prévu à ce stade précoce.

Les différences culturelles. Une étude des pratiques d'estimation par Jorgensen nous en dit long sur la culture du monde chaotique. Ses recherches ont révélé que «l'estimation d'expert» est la stratégie dominante pour estimer l'effort de projet de développement tout au long de la vie. Il a défini l'expertise comme "un travail effectué par une personne reconnue comme experte sur la tâche, et qu'une partie importante du processus d'estimation repose sur un processus de raisonnement non explicite et non récupérable, c'est à dire. 'intuition''. Bien que cette recherche ait été publiée dans 2004, Jorgensen m'a récemment dit qu'il n'avait connaissance d'aucune donnée publiée qui modifierait cette opinion selon laquelle l'estimation d'experts domine toujours l'estimation de l'effort du projet..

En revanche, mon observation informelle est que les organisations du monde contrôlé qui publient des données indiquant une grande précision pour les estimations de projet sont pour la plupart des entreprises de fabrication de haute technologie, produisant souvent des logiciels critiques pour la sécurité ou pour la mission. Ces projets nécessitent une grande attention à la qualité, ils commencent donc avec l'avantage d'une "véritable" mentalité d'ingénieur, s'appuyer sur des données plutôt que sur un simple jugement.

Ces différences culturelles affectent la précision de l'estimation du projet. Daniel Kahneman, un psychologue qui a remporté le 2002 Le prix Nobel d'économie décrit deux modes de pensée humaine, intuitif et rationnel. La plupart du temps, nous pensons intuitivement; il faut une vraie discipline pour penser sur le mode rationnel. Sa découverte la plus importante concernant l'estimation est que la pensée intuitive est presque toujours optimiste et a tendance à ignorer les statistiques et l'expérience passée. (par exemple. croire "cette fois, nous allons bien faire les choses"). Il recommande que les décisions prédictives finales soient laissées aux formules, et de préférence simples avec peu de variables.

Appliquer cette recommandation à une estimation des coûts d'un projet basée sur la pensée intuitive, par exemple. par analogie, suggère que si l'environnement a les antécédents cités ci-dessus pour les projets du secteur public britannique, alors l'analyse de rentabilisation doit tenir compte de la 30% risque d'échec total, et toute estimation de coût intuitive devrait être automatiquement augmentée de 15% – 20% avec une augmentation correspondante de l'incertitude.

Kahneman a d'autres recommandations importantes pour estimer le manque de données concrètes, par exemple. l'utilisation de processus tels que Delphi large bande (ou ‘Planning Poker’ dans le monde agile), plutôt que de compter sur l'expertise d'un individu.

Comprendre les rôles des différents acteurs impliqués dans l'estimation. La responsabilité d'un estimateur est de produire un chiffre d'effort de projet basé sur les meilleures données disponibles, avec un énoncé approprié de la plage d'incertitude de l'estimation. C'est tout.

C'est le travail du gestionnaire de comprendre les hypothèses de l'estimateur, évaluer le risque et l'incertitude, et finalement décider du budget du projet. Si la mentalité du manager est de se fier à l'estimateur et d'ignorer le risque (par exemple. avec l'attitude du manager de Dilbert de "donnez-moi juste un numéro") le projet est voué à manquer son budget.

Plus loin, lorsqu'un client émet un ITT pour se procurer un logiciel auprès d'un fournisseur externe, le client doit comprendre d'autres facteurs qui affectent la façon dont un fournisseur arrive à ses estimations et à ses offres de prix.

Les fournisseurs de systèmes logiciels externalisés dépendent d'une estimation fiable pour leur survie - et nous avons noté ci-dessus qu'ils ont normalement de bons antécédents en matière de rentabilité. Ils prennent donc normalement très au sérieux la collecte de métriques logicielles et leur utilisation pour estimer, beaucoup plus que ne le fait un service informatique interne typique ou la fonction informatique retenue par un client qui gère ses fournisseurs informatiques externalisés.

Chez un fournisseur, l'estimation des coûts basée sur les informations sur les exigences contenues dans l'ITT du client est convertie par son équipe de vente en un prix à gagner. Dans ce processus, ils prendront en compte de nombreux facteurs évidents tels que le budget prévu du client, la concurrence probable, trésorerie future, rentabilité souhaitée, etc.

Deux autres facteurs moins appréciés mais importants sont également pris en compte. Premier, au fur et à mesure de l'avancement du projet, le client pensera inévitablement à des exigences nouvelles ou modifiées qui peuvent être facturées en plus du prix de l'offre. Seconde, le gagnant du projet de développement initial est le mieux placé pour remporter les travaux de maintenance et de support continus tout au long de la vie du système. Ces activités supplémentaires et continues peuvent être beaucoup plus rentables que le travail de développement initial. Par conséquent, un fournisseur peut faire une offre basse pour le développement initial afin d'assurer une victoire.

Malheureusement, lorsque la première grande vague d'externalisation informatique du secteur public britannique a commencé il y a plus de vingt ans, la majeure partie de l'expérience des métriques et de l'estimation des logiciels a été sous-traitée aux fournisseurs dans le cadre de contrats à long terme. Cela a conduit à une grave «asymétrie d'information» entre les clients et leurs fournisseurs et est presque certainement une cause majeure du niveau élevé de dépassements budgétaires des projets informatiques du secteur public britannique..

Pour un constructeur automobile, les achats sont l'une de ses fonctions les plus importantes. Dans le cas de l'approvisionnement informatique du secteur public britannique, effectivement, le garde-chasse a transmis son expertise en matière de métrique aux braconniers.

Une autre cause de dépassement de projet peut provenir de la gestion des réserves pour imprévus. Ceux-ci doivent être détenus par un responsable au niveau du portefeuille de projets et communiqués aux chefs de projet au besoin, plutôt que d'être affecté à des projets individuels dès leur lancement. Premier, la connaissance de l'éventualité incluse dans une estimation rassure le chef de projet et la loi de Parkinson garantit qu'elle sera utilisée. Il en va de même pour une relation externalisée, où Kahneman cite "une réserve budgétaire est aux entrepreneurs comme la viande rouge aux lions; ils le dévorent'.

Techniques d'estimation. De nombreux logiciels d'estimation de projet dans le monde Contrôlé, comme l'illustre Renault, tente de répondre à la question dominante axée sur les coûts de « quelle est la taille ??' en faisant des estimations basées sur l'expérience du nombre de lignes de code source (SLOC). La méthode d'estimation COCOMO II bien connue et la plupart des outils d'estimation disponibles dans le commerce ont été calibrés en utilisant les tailles SLOC comme entrée. Malgré les nombreux, inconvénients souvent médiatisés des tailles de SLOC, la précision de l'estimation basée sur le jugement d'experts à partir de conceptions détaillées est généralement déclarée exacte à l'intérieur 10% au niveau des composants.

Dans le monde chaotique, si plus que l'intuition ou le jugement d'un expert est nécessaire pour les estimations alors qu'il n'existe que des exigences générales, il est plus courant d'estimer d'abord la taille des exigences à l'aide de l'analyse des points de fonction (FPA). La taille est ensuite convertie en effort à l'aide de repères de productivité dérivés de projets similaires antérieurs. L'idée originale de FPA d'Albrecht à la fin des années 1970 consistant à proposer une mesure de la taille d'un système logiciel en fonction de ses exigences fonctionnelles était une brillante réflexion latérale.. Mais cette méthode, maintenant développé et soutenu par l'organisation IFPUG, montre son âge.

le Méthode COSMIQUE utilisé par Renault a été conçu par un groupe international d'experts en métriques logicielles pour être applicable aux entreprises, logiciel temps réel et d'infrastructure, basé sur les principes fondamentaux du génie logiciel. Des variations de la méthode pour produire des tailles approximatives sont disponibles pour mesurer les exigences avant qu'elles ne soient connues avec suffisamment de détails pour une mesure précise, et le procédé a été automatisé ou est en cours d'automatisation par divers moyens. (La mesure automatisée est essentielle pour Renault; le comptage manuel serait trop lent pour leur processus de développement.) La méthode est parfaitement adaptée à la mesure des exigences à n'importe quel niveau d'agrégation dans les développements agiles, par exemple. Histoires d'utilisateurs. Itérations, communiqués, etc., et pour les composants des systèmes distribués.

Un exemple de problème pouvant être évité en utilisant la méthode COSMIC s'est présenté dans un grand fonds de pension européen qui avait utilisé la méthode IFPUG FPA pour le dimensionnement comme base d'estimation. L'échelle FPA n'offre qu'une gamme étroite de tailles pour les transactions; la méthode COSMIC mesure sur une échelle de rapport sans limite supérieure. Un projet a fait l'objet d'une enquête pour savoir comment il avait été sérieusement sous-estimé. Certaines transactions qui ont marqué le maximum IFPUG de 6 ou 7 Les PF ont été re-mesurés à l'aide de la méthode COSMIC et se sont avérés supérieurs à 60 COSMIC FP. Les transactions dont la taille dépasse 40 Les PF COSMIC représentaient près de 80% du dépassement budgétaire.

Que peut-on faire pour combler l'écart d'estimation entre le monde chaotique et le monde contrôlé?

Les conseils de Jorgensen sur la façon de tirer le meilleur parti de l'estimation par jugement d'expert sont fortement recommandés et les observations de Kahneman sur la prévision basée sur le jugement intuitif doivent être prises en compte.. Mais si le monde chaotique doit combler le fossé, il doit faire plus que se fier à une estimation intuitive. Il doit collecter des données de performance concrètes sur les projets achevés et développer des méthodes d'estimation simples à l'aide de méthodes modernes de mesure des exigences. Si vous achetez auprès d'un fournisseur externe, les clients doivent apprendre comment les fournisseurs déterminent leurs prix d'offre.

Même avec ces étapes, il reste le problème intrinsèque dans le monde chaotique que des estimations sont souvent nécessaires et que les budgets doivent être établis tôt dans la vie d'un système logiciel avant que les exigences ne soient connues en détail. A ce stade, une estimation doit inévitablement avoir une plage d'incertitude très large. Alors, que peut-on faire pour atténuer les effets de ce défi?

La réponse est un processus qui a été développé 15 il y a des années par le gouvernement de l'État de Victoria en Australie, mais n'a jamais été largement appliqué.
En schéma simplifié, lorsqu'un client émet un ITT avec un énoncé initial des exigences, les fournisseurs sont invités à estimer la taille totale éventuelle et à proposer un prix fixe par unité de taille fonctionnelle. Le prix total de l'offre est alors le produit de ces deux facteurs. Lorsqu'un contrat est attribué et que les exigences évoluent, le prix unitaire reste fixe, mais le prix total variera proportionnellement à la taille des besoins. La taille réelle est contrôlée par un Scope Manager indépendant, un « métreur » de logiciels. Le client supporte donc le risque de faire varier la taille des exigences; le fournisseur assume le risque de proposer le juste prix unitaire en fonction de sa connaissance des besoins du client et de ses propres capacités. Avec ce processus, les asymétries d'information et de risque entre client et fournisseur sont considérablement réduites.

Le procédé australien a été affiné en Finlande où il est connu sous le nom de « Northern Scope ». Il est appliqué ou expérimenté dans divers pays. Les partisans de la méthode affirment que les dépassements de coûts peuvent être réduits à moins 10%.

Mais les plus grands avantages revendiqués sont des réductions très substantielles des coûts unitaires des logiciels et des améliorations de la vitesse de livraison des projets logiciels. La capacité à mesurer les besoins joue ici un rôle plus large qu'on ne l'imagine, à savoir comme facteur de contrôle de la qualité. Si les exigences ne sont pas suffisamment précises pour pouvoir être mesurées, le logiciel ne peut certainement pas être construit et testé de manière fiable! On verra que le processus de Renault pour gérer l'approvisionnement en logiciels embarqués pour ses calculateurs et le processus Northern Scope reposent sur la tarification unitaire du logiciel comme une caractéristique clé..

En conclusion, les outils sont disponibles pour le monde chaotique afin de combler largement l'écart avec le monde contrôlé sur l'estimation de projet logiciel. Mais il n'y a pas de solution miracle, pas de réponses rapides et prêtes. Une mentalité d'ingénieur et une volonté d'investir dans la collecte et l'analyse de données de performances réelles sont essentielles.

A propos de l'auteur

Charles Symons est fondateur et ancien président de la Consortium international de mesure des logiciels communs. Vous pouvez le contacter à cr.symons@btinternet.com. Ce message a déjà paru dans le 2015 bulletin d'hiver du Société d'analyse et de prévision des coûts.

Un article de blog représente l'opinion personnelle de l'auteur
et ne coïncide pas nécessairement avec les politiques officielles de Nesma.