La qualité structurelle à travers le globe La qualité structurelle se réfère aux caractéristiques intrinsèques et non fonctionnelles d une application, c est-à-dire à l aplomb de son architecture et à la tenue de son code source plutôt que son alignement à ses exigences fonctionnelles. Les caractéristiques de qualité structurelle sont cruciales, car elles sont à la fois difficiles à mettre en évidence au moyen des techniques classiques du test et en même temps la cause la plus fréquente des problèmes de fonctionnement des applications telles des pannes, des dégradations de performance, des intrusions par des utilisateurs non autorisés ou des altérations de données. Les données de l étude ont été recueillies sur une période de trois ans, proviennent de 288 applications, totalisant 108 millions de lignes de code (équivalant à 3,4 millions de points de fonction), soumises par 75 entreprises ou organismes publics. Les résultats de ces analyses sont consignés dans Appmarq, un référentiel de données sur la qualité structurelle maintenu par CAST. Ces 75 organisations relèvent de huit secteurs d activité, à savoir l énergie, la finance, l assurance, les services informatiques, les technologies, les télécommunications, l industrie et l administration publique. Ces organisations sont basées principalement en Amérique du Nord, en Europe et en Inde. La taille des applications analysées s étale de 10 000 à 5 millions de lignes de code, 26 % des applications contenant moins de 50 000 lignes de code et 32 % comportant entre 50 000 et 150 000 lignes de code. Ces données sont le fruit d un travail d analyse et de mesure de la qualité structurelle sur l éventail d applications de différentes technologies le plus large jusqu à présent jamais étudié. L article se concentre sur quatre caractéristiques de la qualité structurelle : robustesse, performance, sécurité et évolutivité. L évaluation de chaque caractéristique provient d une analyse du code source visant à détecter des violations de bonnes pratiques en matière d architecture et de codage. Les notes de chaque caractéristique de qualité structurelle sont agrégées sur plusieurs niveaux (du module à l application) et sont calculées, sur une échelle allant de 1 (risque le plus élevé) à 4 (risque le plus faible), en utilisant un algorithme qui apprécie la sévérité de chaque violation et sa pertinence quant à chacune de ces caractéristiques. Six enseignements majeurs pour les applications La dette technique s élève à plus d un million de dollars par application moyenne La dette technique étant un concept relativement nouveau, ne sont disponibles que peu de données quantitatives sur ce sujet. La base de données Appmarq de CAST constitue un matériau de premier choix pour produire une estimation de la dette technique basée sur le nombre de malfaçons de qualité structurelle dans le code source. Mesurer & gérer la dette technique des portefeuilles applicatifs La société CAST a conçu une série de rapports visant à dégager les tendances actuelles relatives à la qualité structurelle des applications de gestion (robustesse, performances, sécurité, facilité de modification...). En se basant sur ces travaux, l'auteur expose les principaux enseignements qu'il en a tiré. Ces données offrent un cadre objectif et empirique de référence pour la communauté du développement. Elles fournissent également une base de référence pour apprécier les compromis possibles entre coût de correction des malfaçons du code source et risque que ces défauts peuvent entraîner en termes de pannes ou de failles de sécurité. Dette technique : Coût de l effort requis pour corriger les malfaçons dans le code source au moment de la mise en production d une application. À l instar d une dette financière, la dette technique induit des coûts croissants dans le temps des intérêts par le biais de la charge de maintenance et d évolution elle aussi croissante à cause des malfaçons de qualité structurelle du code. En utilisant un modèle d estimation conservateur, nous estimons que la dette technique de notre échantillon d applications s élève à 2,82 dollars par ligne de code. Pour une application de taille moyenne de 374 000 lignes de code, cela correspond approximativement à une dette technique de 1,055 million de dollars. Le coût d apurement de cette dette technique représente donc le poste principal de coût total de possession d une application (TCO) et est donc à ce titre l un des principaux facteurs du coût de l informatique. 32 33
Les analyses préliminaires résumées dans la figure 1 montrent que les applications C/C++ présentent une dispersion dans la dette technique beaucoup plus importante que celle des applications élaborées avec d autres technologies, bien qu un échantillon d applications C/C++ plus grand eût été nécessaire pour caractériser de façon fiable cette répartition. En examinant la dette technique selon les différentes technologies, il apparait que plus le niveau d abstraction d une technologie est élevé, plus la dette technique est faible. Ainsi, plus le niveau d abstraction est élevé, moins le développeur risque de commettre des erreurs, car la plate-forme ou les frameworks de base prennent à leur charge davantage de tâches de bas niveau. Sécurité : ensemble des attributs qui limitent le risque d intrusions non autorisées dans les données gérées par une application. Des analyses supplémentaires résumées dans la figure 3 montrent que les applications présentant le niveau de sécurité le plus élevé ont été développées en COBOL et en environnement mainframe dans le domaine des services financiers, où les exigences en matière de sécurité et de respect de la confidentialité des informations sont élevées. Les applications mainframe sont par ailleurs moins exposées aux problèmes de sécurité auxquels ont à faire face les applications web. Néanmoins, les scores de sécurité moindres affichés par les autres types d applications sont surprenants. En particulier, les applications en.net affichent les scores de sécurité les plus bas. Ces données suggèrent que la prise en compte des considérations de sécurité par la communauté du développement serait principalement liée aux contraintes réglementaires imposées à certaines industries. Figure 1 : La dette technique par technologie Calcul de la dette technique 1. Le taux de violations des règles de codage par millier de lignes de code est fourni par une analyse effectuée au moyen de la solution «CAST Application Intelligence Platform». Ces violations des règles de codage permettent de mettre en évidence des problèmes relatifs à la sécurité, à la performance, à la robustesse et à l évolutivité du code. 2. Les violations des règles de codage sont classées en trois niveaux de sévérité (haut, moyen, faible). Dans l élaboration de l estimation de la dette technique, il est fait l hypothèse que seulement 50 % des problèmes de sévérité haute, 25 % de sévérité moyenne et 10 % de sévérité faible seront corrigés au cours de la vie opérationnelle d une application. 3. Il est également fait l hypothèse conservatrice que la correction de chaque malfaçon prendra seulement une heure pour un coût horaire chargé de 75 dollars. D autres études indiquent que ces chiffres peuvent être plus élevés, notamment quand la correction intervient lorsque l application est entrée en phase d exploitation. 4. Dette technique = (10 % des violations de faible sévérité + 25 % des violations de sévérité moyenne + 50 % des violations de sévérité élevée) x (Nombre d heures de correction) x Coût horaire. Figure 2 : Répartition des scores de sécurité COBOL présente le meilleur niveau de sécurité Figure 3 : Scores de sécurité par technologie La figure 2 montre la répartition des scores de sécurité dans l échantillon. Cette répartition bimodale traduit le fait que les applications se rangent en deux types distincts : le groupe des applications présentant un très haut niveau de sécurité et le groupe des applications présentant un niveau de sécurité médiocre et un long étalement vers les scores de sécurité très faibles. La répartition des scores de sécurité est la plus dispersée de toutes les répartitions relatives aux caractéristiques de la qualité. Cela traduit des disparités significatives dans la prise en compte des exigences de sécurité selon les types d applications ou les secteurs d activité considérés. Les systèmes de l administration publique sont les moins maintenables Les scores d évolutivité montrés en figure 4 répondent à une répartition bimodale, traduisant des variations importantes dans la maintenabilité des applications de l échantillon. Comme l évolutivité d une application est une composante majeure de son coût total de possession (TCO), cette répartition suggère des différences importantes de coût total de possession (TCO) entre les applications dont le score d évolutivité est élevé et celles dont le score est faible. 34 35
Évolutivité : ensemble des attributs qui rendent la modification d une application plus facile et plus rapide. Figure 6 : Proportions d applications externalisées pour les secteurs public et privé Les langages récents sont moins bien notés en performance et robustesse Figure 4 : Score d'évolutivité Performance : ensemble des attributs qui influent sur les temps de réponses et l efficacité des applications. Robustesse : ensemble des attributs qui influent sur la stabilité d une application et la probabilité d introduire de nouveaux défauts lors de modifications. En comparant les scores d évolutivité par secteur d activité (figure 5), on constate que les scores sont significativement plus bas dans le secteur public. Notre échantillon comprenait des applications d organismes publics situés à la fois aux États-Unis et dans l Union européenne. Bien que nous ne disposions pas de données de coût, ces résultats suggèrent que les organismes publics consacrent une part significativement plus élevée de leur budget informatique à la maintenance des applications qu à la création de nouvelles fonctionnalités. Dès lors, il n est pas surprenant que, dans son rapport «IT Staffing & Spending Report» de 2010, le cabinet Gartner rapporte que le secteur public dépense environ 75 % de son budget pour la maintenance, ratio le plus élevé de tous les secteurs d activités. Figure 5 : Niveau d évolutivité par secteur d activité Comme le montre la figure 7a les scores de performance sont fortement dispersés et plutôt denses vers les niveaux élevés. À l opposé, la répartition des scores de robustesse est la plus resserrée de toutes les répartitions relatives aux caractéristiques de la qualité, avec une légère dissymétrie négative. La tendance observée dans les scores de performance relève d hypothèses impliquant à la fois des facteurs technologiques et des facteurs humains. Primo, la disponibilité et l utilisation d outils automatisés de test de performance ont facilité la détection des problèmes de performance et leur traitement au cours du développement. La plupart des plates-formes modernes de test intègrent des modules de test de performance. Bien que ces modules n opèrent pas au niveau du code source, ils mettent en évidence les engorgements et sensibilisent les développeurs aux problèmes qui pourraient ralentir une application ou causer son arrêt intempestif. On s attend à ce que les entreprises utilisant ces outils affichent des scores de performance élevés. Deuxio, la performance est l une des caractéristiques de la qualité les plus saillantes, en particulier chez les utilisateurs dont elle impacte la productivité. Il n est pas rare que les utilisateurs finaux se plaignent à grands cris auprès des équipes de développement à propos de mauvaises performances, donnant une priorité haute à la résolution de ces problèmes au détriment d autres tels qu une mauvaise maintenabilité. Une analyse plus approfondie de ces données, résumée par la figure 8a, montre que les applications Java EE affichent des scores de performance nettement plus bas que celles développées dans d autres langages. Les applications.net montrent la même tendance, mais pas aussi forte que pour Java EE. Toutefois, la modularité pourrait expliquer en partie les scores de performance pour.net et Java EE, comme évoqué à propos de l enseignement 4, car une conception médiocre ou une modularité excessive peuvent avoir un impact négatif sur les performances d une application. Les scores médiocres d évolutivité dans le secteur public peuvent s expliquer en partie par la forte proportion d applications externalisées dans ce secteur en comparaison du secteur privé. La figure 6 montre que 75 % des applications du secteur public figurant dans l échantillon étaient externalisés comparés à 51 % pour le secteur privé. Lorsqu on retire les applications du secteur public de l échantillon, on constate peu de différence entre les scores d évolutivité entre applications externalisées et non externalisées. Le faible niveau d évolutivité des applications du secteur public peut résulter également de leurs conditions d acquisition. De multiples prestataires travaillant sur une application au cours du temps, l absence dans les contrats de mesures incitatives à l élaboration de code facilement maintenable et des pratiques d acquisition plus délicates peuvent expliquer ces résultats. À l opposé, le secteur des services informatiques présente une médiane plus élevée et une variation plus étroite pour les applications qu il élabore pour son propre usage interne. Figure 7a : Répartition des scores de performance 36 37
Une explication de cette corrélation négative repose sur le fait que le langage COBOL ne favorise pas la modularité. En conséquence, les applications sont constituées de composants volumineux et complexes. Les langages plus récents encouragent la modularité et d autres techniques qui atténuent l effet de la complexité lorsque la taille des applications augmente. Par exemple, la figure 10 montre que la proportion des composants très complexes (ceux dont la complexité cyclomatique est supérieure à 30) dans les applications COBOL est bien plus élevée que dans les autres langages, alors que pour les nouvelles technologies orientées objet, comme Java EE et.net, cette proportion est plus faible, ce qui est totalement cohérent avec les objectifs de la conception orientée objet. La modularité peut aussi expliquer les faibles scores de performance dans.net et Java EE, comme déjà indiqué dans le quatrième enseignement, car des niveaux élevés de modularité peuvent impacter négativement les performances d une application. Figure 7b : Répartition des scores de robustesse Figure 9 : Corrélation entre l indice de qualité totale et la taille des applications COBOL Figure 8a : Scores de performance par technologie Figure 10 : Proportion de composants fortement complexes dans les applications L indéboulonnable GoTo (et autres violations) Les deux enseignements suivants soulignent deux erreurs communément commises par les développeurs. Figure 8b : Scores de robustesse par technologie La modularité réduit l impact de la taille sur la qualité Les données d Appmarq contredisent l opinion classique selon laquelle la qualité d une application décroît lorsque sa taille augmente ; avec une exception, l indice de qualité totale (une combinaison de quatre mesures de la qualité) n a pas une corrélation significative avec la taille des applications dans l échantillon. Toutefois, l indice de qualité totale est corrélé négativement avec la taille des applications COBOL, comme le montre la figure 9 dans laquelle les données sont reportées sur une échelle logarithmique pour mieux faire apparaître la corrélation. Le GoTo considéré comme éternel : Cela fait plus de 40 ans que l éminent informaticien Edsger Dijkstra s est insurgé contre l instruction GoTo en déclarant que cette dernière rend les programmes inutilement complexes et sujets à bugs. La lettre de Dijkstra adressée en 1968 au rédacteur de la revue Communications of the ACM et intitulée «GoTo considered harmful» est souvent considérée comme le point de départ du mouvement de la programmation structurée, un ensemble de pratiques désormais systématiquement enseignées dans tout cours de programmation. Bien que la plupart des langages de programmation modernes aient éliminé l instruction GoTo, des langages plus anciens comme COBOL l autorisent toujours. Il est alors choquant de constater qu il y avait 334 249 instructions GoTo dans les 33,4 millions de lignes de code contenues dans les 30 applications COBOL analysées dans le cadre de l étude soit grosso modo une instruction GoTo pour cent lignes de code! Même après des années de maintenance et de remaniements, ces instructions néfastes infestent toujours les applications COBOL, ce qui laisse penser que les GoTo sont éternels. 38 39
40 Complexité cachée : Une violation courante dans la plupart des technologies est le nombre élevé d appels sortants vers d autres composants d une même application. Cette violation figure fréquemment en Java EE,.NET, COBOL, ABAP et C/C++. La complexité de l application associée à un grand nombre d appels sortants augmente alors de façon spectaculaire le temps requis pour faire évoluer une application. Plus les interconnexions entre composants sont complexes, plus longue est la conception, la mise en œuvre et le test d une évolution, ceci se traduisant alors par une inflation du coût de possession et des délais plus longs pour mettre à disposition des métiers de nouvelles fonctionnalités. De telles observations indiquent que l adoption des meilleures pratiques de conception et de codage est lente. Des réticences à réduire la complexité d un code qui semble fonctionner correctement perdurent, même si le coût total de possession (TCO) et le temps pour livrer des améliorations pourraient être substantiellement réduits en remaniant le code. Ces observations peuvent traduire un besoin de formation continue des développeurs en matière de pratiques de codage et de conception. Ces mêmes observations suggèrent également que les équipes de développement persistent à se focaliser sur les performances et la sécurité de certaines applications critiques, ce au détriment de l élimination des problèmes de maintenabilité qui augmentent pourtant le coût total de possession et pénalisent lourdement la réactivité aux besoins des métiers. Enfin, ces résultats suggèrent que les responsables informatiques sont toujours enfermés dans un mode réactif privilégiant la satisfaction des exigences court terme des métiers au détriment d un mode plus proactif qui s attaquerait aux causes à long terme des coûts de l informatique. n Bill Curtis, Directeur Scientifique et Directeur du CAST Research Labs Bill Curtis a rejoint CAST en 2007 en tant que Directeur Scientifique, et dirige maintenant le CAST Research Labs. Il est un des experts mondiaux les plus réputés dans le domaine de l ingénierie et de la qualité logicielle. Il est reconnu pour avoir développé le CMM (Capability Maturity Model) lorsqu il était Directeur du Software Process Program au SEI dans les années 90, le standard mondial d évaluation de la maturité des processus et de l organisation des entités de développement logiciel. Il a été nommé Directeur du Consortium pour la Qualité Logicielle des Systèmes d Information (CISQ) par le SEI (Software Engineering Institute, université de Carnegie Mellon) et l OMG, l organisme mondial de définition de standards logiciels. Le CISQ a pour objectif de définir un standard de mesure de la qualité logicielle des systèmes d information et de la performance des équipes informatiques pour en permettre une évaluation précise et objective. Avant de rejoindre CAST, Bill Curtis avait co-fondé TeraQuest, leader mondial des services autour du CMM, racheté par Borland. Avant TeraQuest, il a dirigé le Software Process Program au SEI, après avoir conduit les recherches sur les technologies intelligentes d interface utilisateur et le processus de conception d'un logiciel au MCC, la cinquième génération du consortium de recherche en informatique à Austin, Texas. Avant le MCC, il a développé un système de mesure de la qualité et de la productivité d un logiciel pour la TIT, a mené des recherches sur les métriques et les pratiques logicielles chez GE Space Division, et a enseigné les statistiques à l Université de Washington. CAST, leader mondial du marché de l analyse et de la mesure des logiciels, permet d automatiquement mesurer la qualité structurelle des applications et la productivité des équipes de développement. Fondée en 1990, CAST a aidé plus de 250 grandes entreprises à améliorer la satisfaction des utilisateurs de leurs systèmes d informations et à réduire les risques informatique, tout en en diminuant les coûts de développement et de maintenance. La plupart des grandes SSII ont également adopté CAST dans le cadre de leur industrialisation et d offres de services innovantes. CAST est cotée sur le compartiment C d Eurolist Paris (Euronext : CAS) et commercialise ses produits au travers d une force de vente directe solidement implantée aux Etats-Unis, dans les principaux pays Européen et en Inde, ainsi qu au travers d un réseau de partenaires intégrateurs. Site web : www.castsoftware.com Interface pivot entre l utilisateur et le SI, le poste de travail est un élément clé du système d information. Il est au cœur des processus d échanges et de travail. Si la multiplicité des terminaux modifient la forme du poste de travail, les attentes de l utilisateur deviennent de plus en plus nombreuses. IDC France vous donne rendez-vous Conférence organisée par Avec le soutien de IDC, filiale du leader mondial du conseil, et des études dans les technologies de l information. le mercredi 11 mai 2011 (9h 15h30) à Paris 9 ème à la conférence IDC POSTE DE TRAVAIL 2011 Les nouveaux usages et enjeux du poste de travail Enterprise Au programme : VISION ET ANALYSE IDC : ETAT DES LIEUX ET TENDANCES 2011-2015 LA MULTIPLICITE DES TERMINAUX AU SEIN DE L ENVIRONNEMENT DE TRAVAIL CLOUD (SAAS, IAAS), VIRTUALISATION, CONVERGENCE FIXE MOBILE REVOLUTIONNENT L INFRASTRUCTURE DE POSTE DE TRAVAIL ET SON ADMINISTRATION TRANSFORMATION DE L ENVIRONNEMENT ET DES METHODES DE TRAVAIL : QUEL IMPACT SUR LES APPLICATIONS? Chaque thème sera agrémenté d un retour d expérience : Fabrice de BIASIO, DSI, Europe Airpost Antonio da SILVA, information manager, Roche SAS Thierry MENARD, knowledge management manager, Bureau Veritas Le poste de travail prend une nouvelle dimension. Au cœur des processus de travail, d échanges, de communication et de collaboration, il devient un réel outil stratégique. Pour participer à la conférence IDC Poste de travail le 9 mars 2011, consultez le programme détaillé et inscrivez-vous sur : http://www.idc.com/france/postetravail2011 Code invitation : ITX Contact : Valérie Rolland vrolland@idc.com tel : 01.56.26.26.85 Cette conférence gratuite est uniquement réservée aux entreprises utilisatrices.