Service d inspection automatisée des logiciels

Transcription

1 Service d inspection automatisée des logiciels A - Introduction: qualité du logiciel, le rôle de l inspection du code Pour toute l industrie du logiciel, la qualité reste encore un objectif difficile à atteindre. La conviction commune est qu il n existe aucun moyen d améliorer la qualité sans augmenter significativement la longueur du cycle de vie du développement logiciel, sans accroître les coûts, ou les deux ensemble. Livrer un logiciel de qualité dans les délais et dans le budget impartis est souvent perçu comme quasiment impossible. Ces dernières années des cycles de vie toujours plus courts, des ressources de développement et de contrôle qualité limitées, et la complexité croissante des logiciels se sont combinés pour conduire au déclin de la qualité du logiciel et à l accroissement du nombre des défauts. L impact économique de ces défauts est très élevé; les défauts du logiciel sont la principale cause de pannes ou défaillances des applications logicielles critiques et peuvent occasionner directement ou indirectement des dommages importants à leur utilisateurs et aux organisations les ayant développé. La communauté des ingénieurs logiciels sait depuis longtemps (1976, Michael Fagan, Design and Code Inspection to reduce errors in program development ) que l inspection du logiciel est une technique efficace pour retirer les défauts et aussi pour induire des bénéfices à long terme. L inspection réussit parce qu elle est efficace pour détecter et retirer les erreurs critiques tôt dans le processus de développement, avant que celles-ci n atteignent les étapes de tests et de mise en oeuvre. Les technologies de l inspection automatisée des logiciels émergent depuis quelques années (années ) et permettent de surmonter les désavantages inhérents aux inspections manuelles. Ces technologies, délivrées à la fois comme outillages et prestations de services, permettent de localiser automatiquement un grand nombre de défauts de programmation - les mêmes défauts qui peuvent occasionner des pannes ou défaillances graves. La stratégie de l inspection automatisée des logiciels consiste à analyser les codes avant qu ils ne soient testés et d identifier les problèmes potentiels afin de les corriger avant qu ils n apparaissent sous forme de bogues programmatiques. L aspect le plus innovant de l inspection automatisée est sa capacité à déboguer très rapidement de grandes quantités de codes. Ce document analyse les raisons expliquant pourquoi l inspection automatisée des logiciels est nécessaire, décrit le type de défauts détectés par l inspection automatisée et comment ils sont localisés, décrit la technologie supportant l inspection automatisée et comment elle complète les techniques traditionnelles de tests, et enfin compare et singularise les solutions disponibles pour l inspection automatisée. B - L inspection L inspection logicielle ou la revue de code est un examen visuel des codes sources pour détecter les défauts; elle est aussi utile à la vérification de leur adhérence aux standards de programmation. Copyrights Asetechs Page 1 of 12

2 Il est important de noter que l inspection n est pas la même activité que celle des tests - les deux sont indispensables à l obtention d un logiciel de qualité - et il y a de nombreuses différences importantes: 1. Quand on teste on exécute le code, 2. Quand on inspecte on passe en revue le code. L activité de tests ne permet pas de tester tous les chemins du code, et consiste fréquemment à toucher ou manquer. Avec l inspection, des défauts peuvent être identifiés sur des chemins de codes rarement exécutés, et qui sont par suite probablement exclus des plans de tests même s ils peuvent être exécutés dans la réalité. L inspection logicielle n exécute pas le code, est indépendante du matériel, ne requière aucune plate-forme système cible ou de modifications au comportement opérationnel du programme, et peut être engagée longtemps avant que les ressources systèmes cibles soient disponibles en vue de tests. La figure l indique le positionnement des inspections dans le cycle de vie du logiciel. En inspectant visuellement le code source et en trouvant et en retirant les défauts tôt dans le cycle de vie, la qualité du code est améliorée significativement et des coûts inférieurs du cycle de vie sont obtenus. Puisque l inspection est un examen du code, un code exécutable ou des plans de tests ne sont pas pré-requis. Les codes soumis à une inspection rentreront en phase de tests avec un meilleur niveau de qualité et permettront une réduction de la durée et des efforts requis pour réaliser des tests satisfaisants. C - Limites des activités de tests L une des meilleures lignes de défense dans l amélioration de la qualité des logiciels est d améliorer les activités de tests. Les tests sont nécessaires pour l assurance qualité mais ils présentent un certain nombres de limitations, en particulier les suivantes: Créer, exécuter, valider et maintenir des plans de tests et des processus de tests est coûteux et demande beaucoup de temps, Page 2 of 12 pmjtoca@asetechs.com

3 La couverture des tests (le pourcentage d instructions d un programme testées) diminue rapidement dès que la taille du logiciel croît, signifiant que les tests qualifient une part moindre du système. Il peut être difficile et très long de tracer une défaillance découverte à partir d un jeu d essai et de remonter à sa cause programmatique pour permettre au développeur de savoir ce qu il doit corriger. Les tests ne peuvent pas permettre d identifier tous les défauts. Une étude conduite par Capers Jones (1999, Software Quality: what works and what doesn t ) concluait que les activités de tests en moyenne ne permettent de retirer que 50% des défauts existant dans un code, et dans les meilleurs des cas n atteignaient que 85%. Une étude par Briand (Briand, L., El Emam, K., Laitenberger, O., and Fussbroich, T., Using Simulation to Build Inspection Efficiency Benchmarks for Development Projects, Proceedings of the 20th International Conference on Software Engineering, 1998, pp ) indique même que les tests sont moins efficaces que l inspection de code pour la détection des défauts. La première table ci-dessous montre l efficacité comparée des activités d inspections, en pourcentage de défauts identifiés, d après les données disponibles dans la littérature. Les activités de tests apparaissent 4 fois moins efficaces pour la détection de défauts que l inspection des codes (voir ci-dessous, effort moyen pour détecter un défaut: 1.46 versus 6, en heure par personne). De nombreux autres travaux apportent des preuves complémentaires dans le même sens, concernant le retour sur investissement comparés entre les activités d inspection des codes et de tests. Des analyses financières permettent de présenter ces données de diverses façons. Les figures présentées ci-après, montrent que la valeur actuelle nette des projets d inspection de codes est meilleure que celle des projets de tests dans le contexte de délais de réalisation et de taux de rendements réalistes. Le schéma n implique pas qu il faille se passer des activités de tests. Trouver des défauts n est pas le seul objectif des tests, les tests sont utiles aussi à évaluer la fiabilité du logiciel. Copyrights Asetechs Page 3 of 12

4 Bien que des tests robustes soient un aspect décisif d un programme d assurance qualité, ils restent insuffisants pour atteindre la très haute qualité. L exigence toujours plus grande de haute fiabilité pour les logiciels rend les tests inadéquats à y répondre seuls (même si leur valeur reste grande). Et finalement, l étude indique clairement qu ils ne peuvent seuls aider à atteindre une qualité logiciel de haut niveau. Les outils d aide au déboguage construits sur le code mis en oeuvre, tels que Purify, BoundsChecker, et Insure++ ne permettent pas de trouver des erreurs qui ne sont pas ciblées par des plans de tests. Ils nécessitent que l application soit complète et exécutable (ou opérationnelle vis à vis d un plan de tests) pour être utilisables. Ils peuvent ne pas supporter facilement l utilisation Copyrights Asetechs Page 4 of 12

5 de routines d allocation mémoire maison (e.g., cas où le programme testé dispose de ses propres versions de fonctions comme malloc ou free ). Ces outils augmentent la taille du code (x2 - x6) ou des données (nombreux mégabytes), ce qui les rend rapidement inutilisables en cas de contraintes sur les ressources de tests ou d exploitation. La vitesse d exécution des programmes testés peut aussi être affectées (x10 - x100 plus lente) rendant la surcharge due aux tests insupportable. D - Les tests ne sont jamais terminés, seulement abandonnés Pour saisir la portée de cette citation tirée de l Encyclopedia of Software Engineering il est nécessaire d aborder les concepts de code coverage et de path coverage. Les schémas ci-après illustrent le problème invoqué. La figure 2 représente une fonction (il pourrait tout aussi bien s agir d un module, d une tâche ou d une transaction) dotée d un seul point d entrée, et pour la simplicité, d un seul point de sortie. L exécution commence au sommet et se termine au bas. Même si le code coverage (couverture de code) est totalement réalisé, il sera insuffisant pour assurer qu il n existe aucun défaut sérieux. Outre le code coverage, des tests exhaustifs imposent que le path coverage (couverture des chemins) soit lui aussi totalement assuré; tous les chemins qui connectent 2 instructions doivent être testés, en sus de toutes les instructions du programme! La différence est illustrée sur la figure 3, où les lignes soulignées en noir montrent des chemins non pris en compte par les plans de tests. Réaliser un path coverage complet et exhaustif est plus difficile que réaliser un code coverage total. Le code constituant une application industrielle contient littéralement des milliards de chemins. Même si une suite de tests très robuste était élaborée, le temps et les coûts de sa mise en oeuvre serait sans doute prohibitifs. En réalité, les tests ne pouvant que très exceptionnellement atteindre une couverture (de code et de chemins) complète et exhaustive, et impliquant des coûts de conception, de mise en oeuvre et de maintenance très élevés, il est nécessaire des les associer à des techniques complémentaires pour délivrer des logiciels de haute qualité dans des conditions économiques et de délais réalistes. L inspection des codes permet de combler les limitations présentées par les tests. Copyrights Asetechs Page 5 of 12

6 E - Les techniques de l inspection L inspection des codes est une idée ancienne, lancée dès 1976 par Michael Fagan dans son papier Design and Code Inspections to Reduce Errors in Program Development. Depuis lors, un grand nombre d expériences et d études, utilisant une grande variété de méthodes, ont démontré combien l inspection des codes pouvait être efficace. Une bibliographie récente est disponible dans Eickelmann, 2003 An Empirical Study of Modifying the Fagan Inspection Process and the Resulting Main Effects and Interaction Effects Among Defects Found, Effort Required, Rate of Preparation and Inspection, Number of Team Members and Product 1st Pass Quality, Proceedings of the 27th Annual NASA Goddard/IEEE Software Engineering Workshop. L inspection de code, est à l origine une activité consommatrice de ressources humaines, impliquant des revues manuelles de codes, des réunions de validation et d autres techniques similaires. Il a toujours été admis que les programmeurs, chargés de soigneusement relire et examiner leur code, sont les mieux qualifiés pour détecter les défauts. Les résultats des inspections peuvent être impressionnants mais, trop souvent, les inspections ne sont pas réalisées correctement et même pas du tout. Le management perçoit l inspection comme trop exigeante en terme de ressources, et les programmeurs se sentent contraints par le formalisme du processus d inspection traditionnel. Le volume même de codes à inspecter est intimidant, sachant que les applications modernes contiennent des millions de lignes de codes. En réalité, les inspections manuelles de codes ne peuvent être appliquées efficacement que pour des échantillons de l application. Jusqu à ces dernières années (années ) seules 2 techniques étaient utilisées: l inspection formelle et les revues de codes indépendantes. L inspection automatisée de code est une approche rendue possible récemment et automatisant les activités les plus consommatrice de temps et de ressources du processus d inspection. Nous présentons ci-après les 3 types d inspection envisageables de nos jours. E.1 - Inspection formelle L inspection formelle est la plus répandue des 3 techniques d inspection. Les inspections formelles n ont qu un seul objectif: trouver les défauts. Elles réalisent des examens rigoureux du code sur les points d instabilité en ayant recours à des inspecteurs chevronnés qui suivent un protocole formel en vue de localiser tout défaut de programmation. De plus, les résultats de l inspection formelle sont utilisés pour mesurer et aider à améliorer le processus de développement/maintenance. L inconvénient de cette technique est qu elle n est pas compétente pour évaluer la performance d une équipe, ni pour réviser les styles de programmation ou explorer des solutions alternatives. D autre part, les inspections formelles peuvent être mises en défaut pour de nombreuses raisons. L une des erreurs les plus communes est d inviter le management aux activités d inspections, ce qui se traduit immanquablement par la naissance d un manque d engagement des programmeurs soupçonnant le management de pouvoir utiliser les données capturées sur les défauts pour mesurer leurs performances. Un autre aspect est la lourde dépendance de l inspection formelle sur les individus la conduisant ce qui pose le problème de sa consistance. Enfin, l investissement temps n est pas négligeable et se révèle souvent comme un inhibiteur sérieux de la motivation des développeurs à réaliser des inspections de façon systématique; sans surprise, les développeurs préfèrent créer du code nouveau que de passer en revue les codes existants. Copyrights Asetechs Page 6 of 12

7 E.2 - Revues indépendantes de codes Dans le cadre de revues indépendantes de codes, un inspecteur passe en revue un petit échantillon représentatif de codes, en s appuyant sur un modèle bien défini et indépendant du langage de programmation. Des aspect de conception ou des séquences de codes particulières peuvent être ainsi inspectés: par exemple, est-ce que telle ou telle fonctionnalité est réutilisée au sein d une application? Le programmeur a-t-il introduit des séquences de codes en vue du déboguage? Des possibilités particulières du langage inspecté ont-elles été utilisées? Lorsqu une revue indépendante de code a été réalisée, les résultats sont documentés et présentés au chef de projet, aux concepteurs et aux développeurs. Ces documents sont passés en revue, et un ensemble de priorités est défini. Finalement, un plan de changements est créé et planifié. Le processus est systématique; toutefois, le risque ici aussi existe de voir les programmeurs se sentir visés et perdre leur confiance. E.3 - Inspection automatisée des codes L inspection automatisée des codes offre une efficacité plus grande que les techniques manuelles précédentes, d autant plus que les contraintes de développement rapide et de time to market se sont alourdies. Parce qu elle évite l écueil des jugements individualisés, l inspection automatisée s approche un peu plus du concept de programmation sans ego... Des outils du type de Lint (ex.: Flexelint de Gimpel Software ou QAC de Programming Research), ou d autres outils plus sophistiqués (fondés sur des analyses sémantiques sophistiquées comme les outils de Coverity, CodeSonar de GrammarTech ou KRIS d Asetechs) sont couramment utilisés pour équiper les acteurs de l inspection. Ils facilitent la validation que les logiciels respectent certains standards de programmation et génèrent des messages d alertes à propos de défauts probables. Asetechs propose un service outsourced, spécialisé (conduit par des inspecteurs langages chevronnés) et permanent d inspection automatisée des codes, délivrant des rapports indiquant la cause et la localisation dans le code des défauts logiciels identifiés pour des programmes écrits en Cobol, PL1, C, C++ et Java impliquant des dialectes comme SQL, CICS, IMS/DB, IMS/DC ou JCL (cas des mainframes IBM) et permet la capture de données et mesures en vue d un pilotage et d un contrôle de la qualité dans le temps. F - Inspection Automatisée des logiciels: technologie et méthodologie La question décisive est la suivante: comment réussir une analyse approfondie du logiciel qui inspecte automatiquement l intégralité d une application afin d identifier les défauts critiques? La réponse est de mettre en oeuvre des techniques d analyses statiques et d interprétations abstraites des codes. Ces techniques sont brièvement présentées ci-après, en même temps que quelques manières de les exploiter efficacement. F.1 - Techniques d analyse des codes Le point de départ est la représentation des codes sources sous la forme d arbres syntaxiques abstraits. Un logiciel (nommé Parser) lit le code source et produit un arbre syntaxique abstrait, qui modélise toutes les informations structurelles (grammaire du langage) contenues par la code source, tout en retirant tous les détails syntaxiques inutiles (comme le formattage du texte). Par exemple, une instruction if telle que if (a<b) q=c+d else q=e+f serait représentée sous la forme d un arbre syntaxique abstrait, comme il suit: Copyrights Asetechs Page 7 of 12

8 Le noeud initial représenterait l instruction if entière. Il y aurait 3 sous-arbres sous le noeud représentant l instruction if : - Un sous-arbre pour modéliser la condition a < b serait sous le noeud de l instruction if via l attribut if-condition, - Le sous-arbre qui modélise l affectation q = c + d se trouverait sous l attribut if-then - actions, - Le sous-arbre qui modélise l affectation q = e + f se trouverait sous l attribut if-else action. L étape suivant consistera à annoter (attribuer des significations aux noeuds et liens de l arbre) cette représentation abstraite d informations complémentaires tirées des codes sources, telles que les structures grammaticales de contrôle (Control Flow) ou les flots d informations (Data Flow) mis en oeuvre au sein de l application. La Figure 4 (page suivant) présente un extrait de l arbre produit par un Parser et du control flow du programme suivant: sum = sum - 10; if (sum < 0) { x = 3; } else {x = 4; } sum = sum + x; Selon la complexité des techniques d analyses et de représentations mise en oeuvre, cette approche permet d identifier des défauts réels et souvent impossibles à détecter autrement. Des exemples simples d alertes générées de cette façon sont ceux produits par des compilateurs ou des outils comme Lint (voir Aho, Sethi, Ullman, Compilers, Principles, Techniques and Tools, Addison Wesley, 1988 pour une revue des techniques utilisables). Copyrights Asetechs Page 8 of 12

9 F.2 - Type de défauts identifiables par l Inspection Automatisée des codes L inspection automatisée peut découvrir une gamme de défauts structurels pouvant causer des comportements anormaux ou des pannes ( crashes ) et des corruptions de données dans les applications en production. Certaines constructions autorisées et disponibles dans les langages de programmation exigent que des constructions associées soient définies avant ou après dans le même programme. Si les constructions associées ne sont pas définies, ou ne peuvent pas être exécutées sous certaines conditions, le programme présente alors un défaut structurel souvent difficile à identifier. Ces défauts structurels réduisent la fiabilité de l application et sont indépendants du langage de programmation et des fonctionnalités de l application. Des exemples de défauts structurels pour les langages C/C++ inclus les types d erreurs suivants: NULL pointer dereference - un déréférencement d une expression qui est un pointer NULL. Out of bounds array access - une expression accède à une valeur qui est au delà de la fin d un tableau (array). Memory leak - une référence à une mémoire allouée est perdue. Bad deallocation - une désallocation n est pas appropriée pour un type de données. Uninitialized variable - variable non initialisée avant son utilisation. Dead code - code ne pouvant être atteint ou exécuté. Object management leaks - du à des constructeurs incomplets ou à des opérateurs en anomalies. etc... Plus de 200 types de défauts sont documentés dans la littérature spécialisée. F.3 - Méthode pour supporter l inspection automatisée Les outils de l inspection automatisée ne supportent qu une partie des activités du processus d inspection. Ces outils génèrent un volume important de messages d alerte de défauts parmi lesquels ceux qu on dénomme des false positives ; en d autres mots, les outils pensent avoir détecter une situation présentant un défaut, qu une analyse approfondie du contexte rend irrecevable. Tout un chacun est familier avec les alertes souvent non pertinentes émises par les compilateurs. Ce problème des false positives est habituel avec les outils d inspection automatisée et typiquement on reçoit 50 false positives pour chaque vrai défaut. La plupart du temps, ces messages false positives peuvent être éliminés en créant des filtres d expérience. Un travail d audit manuel complémentaire reste nécessaire pour traiter les false positives restant après le filtrage expert. Les inspecteurs ont besoin d un protocole précis et historicisé pour déterminer selon les contextes si un vrai défaut a été trouvé ou s il s agit d un false positive. Pour utiliser efficacement les outils de l inspection automatisée, les organisations de développement doivent embaucher ou former des experts et mettre en oeuvre une méthodologie pour l évaluation et le filtrage des false positives afin d assurer une inspection automatisée pertinente et efficace. Le coût et l effort pour identifier de vrais défauts en utilisant l inspection automatisée reste élevé sans une automatisation complémentaires, celle du traitement et du filtrage des false positives. F.4 - Intégration dans le cycle de vie du logiciel Une étude conduite par Capers Jones a démontré que le coût de correction d un défaut est réduit très significativement si le défaut est découvert tôt dans le cycle de vie du processus de développement (C.Jones, Software quality in 1999: What works and what doesn t ). Par suite, pour un bénéfice maximum, les inspections automatisées devraient être réalisées très tôt et juste avant la fin de la phase de codage, avant que le logiciel n entre en phase de QA/Test (QA: quality assurance). Comme l inspection automatisée ne nécessite pas une application complète (compilable) pour être engagée, des sous-systèmes peuvent être inspectés avant même leur Copyrights Asetechs Page 9 of 12

10 intégration avec d autres composants de l application. La Figure ci-après (tirée de Fagan 1976) décrit l effet mesuré de l inspection sur le processus de développement. L introduction des activités I 0, I 1 et I 2 (inspection) sur le schéma est faite très tôt. Le coût du re-travail est réduit de manière très significative. L information sur la qualité est rendue disponible beaucoup plus rapidement. La plupart des efforts de développement sont aujourd hui globaux, impliquant des équipes contribuant aux différentes parties d un logiciels à partir de différents lieux. Avec l inspection automatisée des logiciels, l organisation de développement peut évaluer la qualité de ses logiciels à chaque étape de sa construction. Chaque partie du logiciel peut être inspectée indépendamment et les composants intégrés peuvent aussi être inspectés en fin de production. Le résultat sera une solution robuste du début à la fin du processus. Des inspections périodiques sont le meilleur moyen d assurer que le logiciel restera libre de défauts pendant les phases de développement puis de maintenance. Les inspections doivent être planifiées pour atteindre le taux de retrait des défauts le plus optimal. G - Service Asetechs d inspection automatisée Ces dernières années, Asetechs a développé des logiciels automatisant les activités d inspection, de normalisation et de contrôle qualité des codes et a été amené à automatiser un service d inspection des logiciels conçu pour améliorer la qualité logiciels et pour améliorer la productivité des processus de développements en Cobol, PL1, C, C++ et Java. Le processus traditionnellement coûteux et consommateur de temps de la détection des défauts peut être désormais réalisé sur de courtes périodes (10 à 15 jours) et sur des volumes importants de codes. Asetechs délivre deux types de rapports d inspection: ceux qui localisent précisément et Copyrights Asetechs Page 10 of 12

11 indique les raisons d un défaut, et d autres qui identifient les catégories de problèmes pouvant être rencontrés par une application. G.1 - La technologie Asetechs Les moteurs d analyses d Asetechs (mais aussi d autres moteurs construits par d autres éditeurs), mis en oeuvre dans une inspection automatisée, utilisent plusieurs représentations d un programme pour vérifier que les pre-requis nécessaires aux opérations d une application sont satisfaits. Par exemple les types de règles (pré-requis) suivants peuvent être vérifiés: Si un pointer est dé-référencé, alors la valeur du pointer au moment du dé-référencement doit être une adresse valide pour le type de données ciblé par ce pointer. Si un tableau ( array ) est indexé, alors la valeur de l index doit être comprise dans les limites de définition du tableau. Si un pointer est libéré, alors il doit pointer vers une zoné mémoire allouée dynamiquement. etc... Les moteurs d analyse doivent prouver que les pré-requis sont vrais pour tous les chemins constituant l opération mise en oeuvre. Ils utilisent un algorithme d évaluation symbolique capable de générer les chemins (control flow analysis) et de tracer les valeurs des variables le long de ce chemin (data flow analysis), et de valider que les pré-requis (rules checking) sont satisfaits. Si un pré-requis n est pas satisfait, alors un message de violation (de la règle ou du pré-requis) est signalé. G.2 - La méthodologie d Asetechs Même si ce type de technologies d analyses est un élément clé de l inspection automatisée, d autres aspects doivent être pris en compte. Asetechs délivre son service d inspection automatisée comme un service outsourced. Un engagement de service combine une analyse automatique et complète de chaque application et une expertise de l inspection de codes assurée par des spécialistes des langages de programmation. Les organisations de développement n ont pas besoin de disposer en interne d experts ou de la méthodologie de validation des défauts versus les false positives. Les deux avantages de ce modèle de service sont les suivants. Premièrement, cela a permis à Asetechs de développer un ensemble de technologies propriétaires, un processus et des outils, qui facilitent le retrait des false positives. Ensuite, Il n y a pas d impact sur les ressources de l organisation de développement. Le temps qu aurait du consacré les développeurs pour inspecter manuellement les codes ou pour retirer les false positives d une inspection automatisée ainsi épargné peut être consacré à leurs autres activités de développement. H - Conclusion Les pannes logiciels sont coûteuses et requièrent beaucoup de temps pour être détectées, causent des dommages significatifs aux utilisateurs, et peuvent sérieusement compromettre l activité d une organisation de développement. L inspection automatisée des logiciels fournit une solution rapide et économique pour l amélioration de la qualité du logiciel. L industrie du développement logiciel a aujourd hui l opportunité grâce au recours systématique et habituel à l inspection automatisée d atteindre des niveaux de qualité qui étaient quasiment inatteignables il y a quelques années. Les technologies de l inspection automatisée sont désormais une réalité éprouvée, elle permettent de réaliser des inspections rapidement et de produire des résultats excellents. De nouvelles Copyrights Asetechs Page 11 of 12

12 méthodologies (comme celle d Asetechs pour l inspection automatisée de Cobol, PL1, C, C++ et Java) sont bien positionnées pour offrir tous les avantages de l inspection automatisée à toute organisation de développement souhaitant vraiment renforcer la qualité de ses logiciels et tirer profit d une productivité accrue. Lorsqu il s agit d améliorer l assurance qualité et les tests pour les applications, l introduction au plus tôt, dans le cycle de vie du processus développement, de l inspection automatisée des codes apporte des économies réelles et démontrées. L inspection automatisée est une activité facilement et efficacement externalisable et elle s avère toujours très rapidement rentable. En utilisant une ressource d inspection spécialisée il est possible de réduire sérieusement les temps de détection des défauts et de filtrage des messages dits false positives, et d améliorer la fiabilité et la qualité des applications. Le service d inspection automatisée proposé par Asetechs peut être engagé très tôt dans le processus de développement, avant même que l application ne soit intégrée et exécutée. Il permet d identifier les défauts au niveau du code source et de les localiser avec précision, facilitant ainsi le re-travail de correction (qui peut parfois être lui aussi automatisé, voir processus de normalisation ). Il délivre des rapports sur les défauts qui facilitent le travail de correction des développeurs. Le processus d inspection automatisée n implique aucune ressources internes et facilite la mise en oeuvre des travaux de correction avant que le code n entre dans les activités d Assurance Qualité et de Tests, et finalement crée l infrastructure de capture des mesures et de contrôle ( measurement process ) de la qualité (voir les autres articles Automated Defects Measurements and Analysis process d Asetechs). Copyrights Asetechs Page 12 of 12