Présentation en français Comment évaluer la qualité d'un logiciel ? Quels outils de qualimétrie logiciel choisir ? Entreprise Software Analitic Comment valider les livrables de vos fournisseurs avec le support d'ALL4TEST et de ces outils de qualimétrie ?

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. •
•
•
•
•
•
•

23. •
•
•
•
•
•
•
•
•
•

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
contact@all4test.com
www.all4test.fr
0671594711
0489829224