Qualimétrie logiciel / Entreprise Software Analytic : son impact sur le business de l’entreprise Telecom Valley Nov 2015
Qualimétrie logiciel /
Entreprise Software Analytic :
son impact sur le business de l’entreprise
Telecom Valley
Nov 2015
• 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
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
3 niveaux d’intervention
CONSEIL
Audit TMMi, CMMi
FORMATION
Outils de tests adaptés au métier client
ASSISTANCE TECHNIQUEINGENIERIE
Mise en œuvre de solutions
Développements
Test/ Recette
OUTSOURCING
FORFAIT
Tierce recette
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.
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.
• 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.
• 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 plateforme ou d’un environnement à un autre ?
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. .
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
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.
Autres ex d’outils
• FindBugs : pour l'analyse du code• Acunetix : pour les failles de sécurité• Checkstyle, PMD …
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.
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é.
OU
• Bénéficier des meilleures règles de chaque outil dans une interface unique
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
« 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 analyticsToutes les dimensions de l’entreprise sont à considérer
Le monde économique actuelMé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.
ITIL v3
• 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 multiples3)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 restitutions6)L’efficacité de l’interface de manipulationC’est ce que nous allons voir dans la suite
Enterprise software analyticsSur quoi est-il nécessaire de se concentrer ?
Optimiser
Les couts
Améliorer
L’agilité
Prévenir
Les
risques
Enterprise software analyticsSur quoi est-il nécessaire de se concentrer ?
• Risque d’interruption de
service
• Problèmes de sécurité
• Ralentissement d’exécution
• Non conformité du code
• Livraisons défectueuses
• Risques associés au cycle de
développement
Business
IT
Prévenir
Enterprise software analyticsSur quoi est-il nécessaire de se concentrer ?
• Time to market• Cout des nouvelles
fonctionnalités
• Arbitrer les priorités
• Cycle de décision
• Cout de maintenance
• Dette technique
• Défauts applicatifs
Business
IT
Optimiser
Enterprise software analyticsSur quoi est-il nécessaire de se concentrer ?
• Expérience utilisateur final
• Valeur apportée par les
applications
• Adéquation métier des applications
• Agilité pour supporter les
nouveaux produits
• Disponibilité des applications
•Qualité des logiciels• Robustesse
• Sécurité
• Architecture
•Productivité des développements
Business
IT
Améliorer
CIOs
QA / Security
ManagersResponsables
développements
Développeurs
Enterprise software analytics pour tout
le mondeA chaque rôle des besoins différents
Achats
Responsable métier
D/ Focus sur 2 outils Kiuwan & Sonar (open source )
Temps Coûts
Fonctionnalité Précision
De tous les angles
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.
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
Témoignage Kiuwan
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!!
Coûts
• “Time is Money”.• Sonar se dit “gratuit”.• Le coût du support technique et du pack Enterprise
atteint annuellement 50.000 €.
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.
Coûts
¿Connaissez vous toute la fonctionnalité de la partie de paiement de SONAR?
Pour le coût d´une Edition Summary
de Sonar vous pouvez utiliser
Kiuwan en mode Enterprise
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€
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é.
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.
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.
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é’.
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 Repository
Quality and Security Office
Development Centers
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 :
Précision
¿ Connaissez vous WebGoat?
Précision
Résultats pour Sonar avec WebGoat et du code Java
15 vulnérabilités
Précision
Resultats pour Kiuwan avec WebGoat et du code Java
465 vulnérabilités
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.
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
Cas d’étude Teléfonica
Opérateur télécom basé en EspagnePrésent partout dans le monde, 345 millions de
clients
8 Factories pour l’outsourcing dans 8 pays différents
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 ?
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
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.
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.
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
- 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.
• L’indicateur de risque est élevé, à cause des défauts de Maintenabilité et de Stabilité
Vue Globale
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
• 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é
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é
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)
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
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