qualimétrie logiciel - entreprise software analytic - 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

Plus d’informations ?

• Julien Van Quackebekecontact@all4test.com

www.all4test.fr06715947110489829224