qualimétrie logiciel - Entreprise Software Analytic - nov 2015
4 j'aime1,443 vues
Le document traite de la qualité des logiciels et de son évaluation dans le contexte de l'entreprise, en se concentrant sur des outils et normes spécifiques. Il présente All4test, une entreprise spécialisée dans les services liés à la qualité logicielle, et compare les outils Kiuwan et Sonar pour leur efficacité en matière d'analyse de code. L'approche de l'analytics logiciel est décrite comme essentielle pour valoriser les processus IT et assurer la satisfaction des objectifs business.
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
- 1. Qualimétrie logiciel / Entreprise Software Analytic : son impact sur le business de l’entreprise Telecom Valley Nov 2015
- 2. • A /- Comment définir et mesurer la qualité d’un logiciel ? • B / Les différents types d’outils • C/ La notion de Entreprise Software Analytics • D/ Focus sur 2 outils • E /inclure cette approche pour évaluer les livrables d’un sous-traitaint, ex de projets
- 3. 1 – Présentation de la société • ALL4TEST est une SSII Française proposant des prestations de services à forte valeur ajoutée dans le domaine des projets aux forfaits et de la qualité logiciel. • Date de création : 2006 à Sophia-Antipolis • Effectif : 20 p en France, 20 p en NearShore
- 4. 3 niveaux d’intervention CONSEIL Audit TMMi, CMMi FORMATION Outils de tests adaptés au métier client ASSISTANCE TECHNIQUE INGENIERIE Mise en œuvre de solutions Développements Test/ Recette OUTSOURCING FORFAIT Tierce recette
- 5. Suite … • Présence : Paris, PACA, Tunis, UK • Membre du pôle de compétitivité SCS, de Telecom Valley, habilitation CIR, • Partenaire de plusieurs éditeurs dont Microsoft et HP sur les outils de test.
- 6. A /- Comment définir et mesurer la qualité d’un logiciel ? • La notion de qualité du logiciel peut prendre des formes diverses en fonction du point de vue que l’on adopte : • un utilisateur final se basera sur son expérience directe, la stabilité, la fiabilité, les performances, • Un développeur jugera le logiciel par rapport à la rapidité de développement, la pertinence de la conception, la facilité de maintenance, la testabilité, la compréhensibilité du code source. • Un exploitant s’attachera davantage à la facilité d’installation et de mise à jour, à la simplicité du diagnostic et de la supervision. • Un architecte fera attention à l’interopérabilité, à la portabilité, à l’intégration harmonieuse de la solution dans le système d’information. • Un DSI prendra en compte les coûts de développement puis de maintenance et d'évolution.
- 7. • Enfin, il y a beaucoup de critères possibles quand on parle de l’évaluation de la qualité logiciel. Dans ce contexte on peut rappeler des normes conçues pour contrôler la conformité d’un produit. Ainsi, on peut faire la différence entre : • • la qualité du processus de production - ISO 9000-3 – référencée sur la série de normes d’exigences pour l’assurance qualité ISO 9000 - ISO/CEI 12207 sur les modèles du processus du cycle de vie du logiciel. • et la qualité du produit - ISO/CEI 9126 ou désormais ISO 25000 – norme qui définit un vocabulaire pour classifier l’ensemble des attributs d’un logiciel relevant de la qualité. Elle se présente sous la forme d’une arborescence de caractéristiques et sous-caractéristiques qui décrivent des aspects de la qualité logiciel.
- 8. • Selon cette norme, les 6 grandes caractéristiques de la qualité logiciel sont les suivantes : • • Capacité fonctionnelle : Le logiciel répond-il aux besoins de ses utilisateurs ? • Fiabilité : Le logiciel est-il en mesure d’assurer un niveau de qualité de service suffisant pour satisfaire les besoins opérationnels de ses utilisateurs ? • Facilité d'utilisation : Le logiciel peut-il être utilisé à moindre effort ? • Maintenabilité : Est-il facile d’adapter le logiciel à de nouveaux besoins ou à de nouvelles contraintes ? • Rendement / Scalabilité : Les ressources matérielles nécessaires à l’exécution du logiciel sont-elles en rapport avec sa rentabilité ? • Portabilité : Le logiciel peut-il être transféré facilement d’une plate forme ou d’un environnement à un autre ?
- 9. Lorsqu’on effectue l'évaluation de la qualité du logiciel on tient compte des facteurs de qualité attendus, définis lors de la commande • (spécifications). Voici quelques exemples de facteurs de qualité logiciel: • cohérence – état du logiciel tel que les conventions préétablies ont été respectées. • complétude – état du logiciel tel que toutes les exigences spécifiées sont réalisées. • compréhensibilité – facilité avec laquelle un programme peut être compris par la lecture de son code source. • contrôle des accès - existence de dispositifs qui permettent une protection contre les accès non autorisés. .
- 10. modularité - aptitude d'un logiciel à être structuré en composants ou modules indépendants. Evaluer la modularité revient à juger de la pertinence de la fonction de chaque module et de ses interactions avec les autres modules. • protection des accès - existence de dispositifs destinés à protéger le code et les données contre toutes dégradations. • simplicité – caractéristique d'un logiciel qui exprime la manière (avec simplicité ou complexité) dont sont implémentées ses différentes fonctions et qui représente la difficulté que peut rencontrer un individu pour analyser et comprendre un programme
- 11. B / Les différents types d’outils • Les Rule Checker - Vérificateur de règles. • Ex : QAC/QaC++ de chez PRQA. • Les Static Analyzer - Analyse statique de code. • Ex : CodeSonar de chez Gammatech. Le premier vérifie les bonnes pratiques de codage, y compris les règles de codage en vigueur dans l'entreprise. Ce genre d'outil trouve peu de bugs, mais plutôt des faiblesses dans la maintenabilité, la portabilité, et un peu la robustesse. Le second est plus orienté robustesse (puisqu'il compile et simule le code), il vérifie les chemin possibles et l'excursion des données pour détecter des problèmes mémoire, de non-initialisation de donnée, d'overflow et de code mort.
- 12. Autres ex d’outils • FindBugs : pour l'analyse du code • Acunetix : pour les failles de sécurité • Checkstyle, PMD …
- 13. Un outils unique ? • Un outil unique permet de construire des indicateurs qualité homogènes, comparables d'un projet à l'autre • Un seul outil à maintenir, c'est plus économique • Un outil commun permet d'accélérer la montée en compétence des développeurs sur le sujet, par un dialogue commun, des fonctionnalités partagées.
- 14. Un outils dédié / type de code ? • Chaque projet est unique et nécessite des règles différentes, donc des outils différents. FindBugs sera plus orienté "bug", alors qu'un PMD fait le focus sur les bonnes pratiques de programmation. • Je maitrise bien tel outil…. J'y suis habitué et j'ai pas envie d'utiliser un autre outil. Je serais d'ailleurs moins productif... • Avec un outil trop généraliste, il sera difficile d'adresser les problématiques qualité propre à un langage, un framework, un aspect qualité précis... on aura pas les règles qui identifient les vrais problèmes de qualité.
- 15. OU • Bénéficier des meilleures règles de chaque outil dans une interface unique
- 16. Test dans le Cloud ? Ex d’outil venu du Cloud : Kiuwan • Disponible aux États-Unis, en Espagne et France, KIUWAN permet á l´utilisateur de créer différents scénarios en fonction de sa stratégie et ce afin d'établir un plan d'action identifiant les efforts nécessaires pour son exécution - • Commercialisé en cloud, Kiuwan permet une rapide implémentation, est disponible en essai gratuit sur simple demande sur https://www.kiuwan.com/all4test/ • C’est approche est bien adapté aux projets Agile (rapidité de mise en œuvre, y compris avec intégration continue) • Kiuwan offre également l'option de télécharger un analyseur en local pour protéger au maximum la confidentialité du code
- 17. « Le software analytics a pour objectif de fournir des données, indicateurs et conclusions qui donnent de la valeur à la fois à l’IT et au business » Enterprise software analytics Toutes les dimensions de l’entreprise sont à considérer
- 18. Le monde économique actuel Métier et Technologies : de plus en plus intriqués L’IT n’est plus seulement un services de support à l’entreprise, mais devient un atout qui apporte de la valeur à l’activité même de l’entreprise.
- 19. • Le concept d’entreprise software analytique dépasse le strict périmètre de l’analyse technique de code. L’objectif est de fournir de véritables outils décisionnels s’appuyant sur les données issues du code et des caractéristiques de chaque application du patrimoine. • Cela implique plusieurs dimension 1)La prise en compte des objectifs Business 2)L’organisation d’axes d’analyse multiples 3)L’exhaustivité de l’analyse (comme pour une analyse de vente, on doit prendre tous les produits) 4)La prise en comptes de l’attente de chaque profil concerné 5)L’homogénéité des restitutions 6)L’efficacité de l’interface de manipulation C’est ce que nous allons voir dans la suite
- 21. • • • • • •
- 22. • • • • • • •
- 25. D/ Focus sur 2 outils Kiuwan & Sonar (open source )
- 26. Temps Coûts Fonctionnalité Précision De tous les angles
- 27. Temps AVEC SONAR: • Télécharger le produit. • Installer le produit (tas de plugins de plusieurs sources). • Configurer le produit. • Gérer les centaines de faux positifs trouvés. • Migrer le produit. • Coût d´achat et de maintenances de l´infrastructure hardware.
- 28. Temps “Kiuwan est une nouvelle génération d´outils, en quelques secondes et sans aucune formation, nous pouvons détecter et corriger les erreurs de nos logiciels. Nous disposons d´une très bonne équipe de développement, mais Kiuwan nous a permis d´atteindre un très bon ratio de productivité. Pedro Tabernero CEO - BKOOL
- 29. Temps Avec Kiuwan: Pas d´installation. Pas de configuration. Pas de migration. Pas de coût d´infrastructure , ni de maintenance. Avec Kiuwan: Plus de temps à perdre!!
- 30. Coûts • “Time is Money”. • Sonar se dit “gratuit”. • Le coût du support technique et du pack Enterprise atteint annuellement 50.000 €.
- 31. Coûts • Avec Sonar il faut prendre en compte les coûts “cachés”: – Personnel dédié à installer, maintenir et migrer chaque version. – Les coûts d´infrastructure. – Le temps employé dans la mise en place, normalement plusieurs semaines voir plusieurs mois. • Kiuwan n´a pas de coûts cachés et permet à chaque entreprise de payer suivant les besoins déterminés. À partir de 35$ par application et par mois en mode Enterprise.
- 32. Coûts ¿Connaissez vous toute la fonctionnalité de la partie de paiement de SONAR?
- 33. Exemples de Coûts • Pack Enterprise con 100 applications avec différentes technologies. – Sonar Enterprise Edition: 50.000€/ année – Kiuwan Enterprise: 26.124€/ année • Pack Basic 10 applications en Java, PL/SQL. – Sonar : 3.200 € année • Java Gratis • PL/SQL: 3.200 € année – Kiuwan: 1.200€ année • Pack Basic Cobol 20 applications. – Sonar 7.500€ – Kiuwan 2.400€
- 34. Fonctionnalité • Dans Sonar il faut construire certains éléments que Kiuwan vous donne automatiquement: – Rapports. – Plans d´actions. – Tableaux de bord : Portefeuille ou vues d´ensemble. – Editeur de règles. • Par exemple, pour obtenir un rapport avec Sonar, il faut acheter le Plugin approprié, puis programmer son propre rapport. Avec Kiuwan, c´est aussi simple que d´appuyer sur un bouton pour avoir des rapports et ce à n´importe quel niveau de visibilité.
- 35. Fonctionnalité • Sonar est un outil qui se veut orienté pour une utilisation technique, mais avec un manque de fonctionnalités pour la gouvernance, fonctionnalités que l´on retrouve au sein de Kiuwan. • Sonar génère beaucoup d´erreurs mais dans beaucoup des cas, ce sont des “faux positifs” qui sont ingérables. • Kiuwan offre la fonctionnalité du “What if analysis” qui permet de savoir exactement ce sur quoi nous devons travailler après avoir fait une analyse, en fonction de nos besoins ou nos disponibilités dans le temps. • ¿Avez vous déjà essayé de créer ou de personnaliser un modèle de qualité avec Sonar? Et avec Kiuwan? • ¿Connaissez vous la fonctionnalité “Defect Muter” de Kiuwan? En quelques secondes, et sans relancer l´analyse, vous pouvez calculer quels seraient les résultats de votre analyse si vous décidiez de mettre en “Pause”, une règle ou une erreur. Avec Sonar, il vous sera impossible de le faire.
- 36. Fonctionnalité • Les tableaux de bord de Sonar sont orientés pour les développeurs, alors que ceux de Kiuwan permettent d´être choisis selon le profil. • Dans Sonar les tableaux de bord sont donnés suivant la technologie. Une application ayant du Java avec PL/SQL aura 2 tableaux de bord , un pour chaque technologie, avec Kiuwan un seul pour les deux technologies. • Kiuwan est structuré par application ou groupes d´applications.
- 37. Fonctionnalité • Sonar compte avec des analyseurs venant de multiples sources. • Bien qu´il ait un support pour le langage Cobol, il ne recommande seulement que 49 règles et ne contient pas d´analyseurs pour des éléments importants comme JCLs. • Sonar ne supporte pas des langages comme Objective C , RPG, ASP ou JSP. • Le support pour ABAP ou PHP est presque inexistant, il ne gère qu´un petit ensemble de règles de ‘maintenabilité’.
- 38. Fonctionnalité • Kiuwan, contrairement a Sonar et à autres solutions, permet de travailler de manière collaborative entre les fournisseurs ou les centres de développement, peu importe leurs localisations. Code Reposito ry Quality and Security Office Development Centers
- 39. Précision • ¿Avez vous comparé une analyse faite par Sonar avec celle faite par Kiuwan? • Sonar se compose de plugins venant de sources très différentes. Chaque analyseur provient donc de sources différentes, il n´y a donc pas d´homogénéité. • ¿Avez vous vu le nombre de Faux positifs que contiennent les règles de Sonar? • Les règles de Sonar sont très génériques et manquent de précision. • L´analyse de Sonar est orientée ‘maintenabilité’. • ¿Avez vous comparé une analyse de vulnérabilités de sécurité entre Sonar et Kiuwan? Voici les résultats :
- 40. Précision ¿ Connaissez vous WebGoat?
- 41. Précision Résultats pour Sonar avec WebGoat et du code Java
- 42. Précision
- 43. En voici une de taille: le support • La grande majorité des utilisateurs qui quittent Sonar, le font à cause du support technique. • Comme indiqué, il n´existe pas de support pour la partie gratuite. • Le pack Enterprise n´inclut même pas de support par téléphone, il se fait par courrier et en Anglais.
- 44. E /inclure cette approche pour évaluer les livrables d’un sous-traitaint • Lorsqu’on soustraite la réalisation d’un logiciel stratégique ou complexe, il peut être très utile de définir des critères de qualité de code à monitorer à chaque livraisons avant même de commencer la phase de test fonctionnel … • Voici deux exemples clients
- 45. Cas d’étude Teléfonica Opérateur télécom basé en Espagne Présent partout dans le monde, 345 millions de clients 8 Factories pour l’outsourcing dans 8 pays différents
- 46. Question posées par Téléfonica Mon fournisseur respecte t-il les bonnes pratiques de développement et ses engagement en terme de qualité et sécurité ? Comment detecter les régressions et éviter la dette technique ? Comment éviter le dérapage des coûts de maintenance ?
- 47. Modèle Client-Partenaire Centre de pilotage des Partenaires Partenaires Développement Analyse avec KiuwanContrôle SLA Réception et Recette Non: 20% Pénalité Conforme? Oui Demande Validation du modèle de contrôle Amélioration Continue
- 48. Un des clients d’ALL4TEST à Monaco dans le domaine de l’industrie, demande à ALL4TEST d’intervenir sur un projet de réalisation d’une application de pricing en .NET, devant se connecter à SAP.
- 49. Le fournisseur à du mal à finaliser le projet (application instable, retard de planning…) Le client à du mal à savoir ce que fait le fournisseur, à organiser et structurer la recette (méthode, outils). ALL4TEST propose les actions suivantes dans une approche globale.
- 50. Contexte : – Application de pricing réalisée en DotNet par un prestataire – Taille de l’application estimée à 150 000 lignes de code – Nombre important de défauts constatés en phase de recette – Beaucoup de régression lors des corrections de bug (instabilité) – Manque d’organisation et d’expérience du client pour structurer la recette / fournisseur Objectifs exprimés par le client / codes – Analyser les risques pour le business en se basant sur les indicateurs remontés par un outils dédié – Identifier les défauts d’architecture – Proposer différents axes d’amélioration pour stabiliser l’application Demande client
- 51. - Audit du code (voir détails dans slides suivantes) - Mise en place d’une équipe QA/Recette chez le client - Formalisation d’un stratégie de test - Formation des experts métiers au métier du test (ISTQB). - Mise en place d’un outil de gestion de campagne de test (Microsoft TFS/ MTM) - Mise à jour des exigences, rédaction des plans de test et recette L’objectif étant de maitriser et quantifier la qualité de l’application afin de voir s’il était possible de faire aboutir le projet et redonner confiance au client.
- 52. • L’indicateur de risque est élevé, à cause des défauts de Maintenabilité et de Stabilité Vue Globale
- 53. Développement de nouvelles règles • Développement de deux règles d’architecture complexes en moins de 2 jours: • Règle de contrôle de l’architecture en couche • Règle de dépendances entre classes: Cette règle permet d’identifier des problèmes d’architecture Objet
- 54. • Nous constatons un risque élevé pour la maintenabilité, la stabilité et la testabilité du système: • Architecture en couche partiellement respectée + dépendances cycliques • Dépendances élevées entre objets • Les règles de gestion sont concentrées dans peu d’objets => Complexité élevée • Les composants complexes sont peu documentés • La gestion des exceptions n’est pas optimale => Diagnostic des problèmes en production difficile • Difficulté de transférabilité de la maintenance en cas de turn-over ou changement de prestataire 21/04/15 Bilan Stabilité + Maintenabilité
- 55. Bilan Stabilité + Maintenabilité • Risques: • Augmentation des coûts de maintenance en raison d’une faible maintenabilité • Augmentation des bugs en production en raison d’une faible satbilité
- 56. 21/04/15 Plan d’actions: Recommandations court terme • Objectif: Résoudre les problèmes de conception pour réduire les risques de maintenabilité, robustesse et testabilité et en profiter pour re- documenter les composants • Etapes: – Réparer les problèmes d’architecture tout en réduisant la complexité. Améliorer la gestion des exceptions pour améliorer la traçabilité. – Documenter le code pour éviter rapidement la perte de compétences (ex: due à un turnover)
- 57. Plan d’actions: Recommandations court terme • Principales actions: – Résoudre les dépendances cycliques. Déterminer le périmètre de la couche DAL (data access layer) et déplacer tous les accès directs et références vers System.Data.* vers cette nouvelle couche. – Réduire la complexité – Déterminer le périmètre de la couche métier ensuite déplacer les règles de gestion – Augmenter la cohérence des classes en: réduisant la taille des méthodes et les dépendances entre classes – Rajouter une hiérachie d’exceptions spécifiques et les utiliser. – Documenter les composants complexes C# et SQLSupprimer Paramètres non utilisés
- 58. Plan d’actions: Recommandations moyen Terme • Objectif: Poursuivre le chantier d’amélioration de la qualité et de la réduction des risques • Etapes: – Réduire le nombre de défauts critiques pour un gain immédiat • Principales actions: – Documenter les composants complexes C# et SQLSupprimer Paramètres non utilisés – Supprimer les colonnes NTEXT et TEXT – Contrôler les valeurs de retour – Rajouter de la log dans les catchs vides et traiter correctement les re-throws – Fermer les curseurs proprement – Vérifier que l’utilisation du TOP dans le SQL ne cause pas des effets indésirables – Remplacer les Writeline dans les batchs par des écriture de logs
- 59. Plus d’informations ? • Julien Van Quackebeke [email protected] www.all4test.fr 0671594711 0489829224