Squale 6.0 est disponible

Début avril est sorti la nouvelle version 6.0 de Squale. C'est une solution (libre, licence LGPLv3), pour gérer la qualité des développements logiciels, avec pour objectifs de couvrir plusieurs langages et d'offrir une vision de la qualité logicielle adaptée à plusieurs profils avec reporting détaillés et agrégés, génération de plan d'actions, etc. Squale se focalise sur deux aspects principaux (voir la précédente dépêche de septembre 2009 pour plus de détails) :

• L'élaboration de modèles évolués d'évaluation, de visualisation et d'interprétation des résultats issus des outils de mesure ;
• Le développement d'une plate-forme logicielle mettant en œuvre les modèles ci-dessus et permettant ainsi de contrôler la qualité de son code.

Cette plate-forme logicielle que certains appelleront de "gouvernance de la qualité", ne réinvente pas les outils de production de métrique, mais se base sur ceux existants, par exemple : Checkstyle, PMD, JDepend, etc. pour le monde Java qui est très fourni en outils libres. Pour l'analyse de code C/C++ et Cobol, Squale propose des connecteurs (plugins) libres, vers des outils du marché, pour le moment essentiellement propriétaires (ex : McCabe?, RSM, etc.), mais il est tout à fait possible d'écrire son propre connecteur vers un autre outil de son choix.

La version 6.0 sortie récemment, outre son lot de corrections et d'amélioration variées, apporte principalement les fonctionnalités suivantes :

• ajout de commentaires sur les notes insérées manuellement,
• nouveau profil auditeur pour la saisie de ces notes manuelles,
• portage et test complet sur environnement Windows,
• finalisation du support de l'analyse Cobol via l'outil McCabe,
• meilleure caractérisation des applications dans Squale,
• implémentation de la visualisation Distribution Map,
• export de données anonymisées vers un référentiel mutualisé (permettant de comparer ses résultats à l'extérieur de son entreprise par exemple) et import des références générées pour comparaison des applications dans Squale.

Pour la suite, la feuille de route de Squale est composé pour le moment des sujets suivants

• Amélioration du plan d'action généré par Squale
• Ajout d'autres visualisations résultant des recherches de l'INRIA
• Gestion plus fine des rôles utilisateur et de la sécurité
• Interface REST pour la consultation des résultats
• Support d'autres langages en plus de Java/C/C++/Cobol (PHP pour commencer)

N'hésitez pas à l'essayer, Squale propose à cet effet une version autonome (configurée par défaut pour Java) contenant une base de donnée embarquée.

Dans la suite de la dépêche, vous trouverez un entretien avec Fabrice Bellingard, le chef de projet de Squale.

liens

Site du projet Squale http://www.squale.org/index.html
Page de téléchargement: https://project.squale.org/downloads?order=version&desc=1
Installeur Squale standalone pour test : https://project.squale.org/downloads/9
Captures d'écran http://www.squale.org/screenshots.html
Release Notes de la version 6.0 http://www.squale.org/squale-user-site/release-notes/6.0-release-notes.html
DLFP : Présentation de Squale, Software QUALity Enhancement project http://linuxfr.org/2009/09/17/25909.html

Seconde partie

LinuxFr : Bonjour Fabrice, peux-tu te présenter en quelques lignes

Bonjour ! Fabrice Bellingard, j'ai 31 ans et je travaille chez Qualixo, où je dirige depuis 3 ans le projet Squale. J'évolue dans le monde de l'open-source depuis bientôt une dizaine d'années. En 2001, au sein de l'équipe Eclipse Core, j'ai développé le module Ant pour la 1ère version d'Eclipse. En 2005, je suis devenu committer Apache (sur Maven et Archiva). Et depuis 2008, je m'occupe donc du projet Squale - Software QUALity Enhancement, une solution open-source de qualimétrie.
Je suis aussi membre de l'OSSGTP, une association d'open-sourceurs parisiens avec laquelle nous faisons des réunions de présentations et d'échanges techniques.

LinuxFr : Comment se positionne Squale par rapport à d'autres solutions comme XRadar, Sonar, le Maven Dashboard, etc. ?

Tous ces projets ont pour objectif de donner des indicateurs en terme de qualité logicielle, avec leur évolution dans le temps afin de pouvoir analyser des tendances et détecter des déviances.
Ils se basent sur des composants tiers d'analyse de code (Checkstyle, PMD, Findbugs, JavaNCSS?, CKJM, JDepend, ...), d'exécution de tests (JUnit &Co, TestNG?, ...) ou toute autre technologie sachant générer des informations qualité. Sauf pour les dernières versions de Sonar, qui développe maintenant son propre composant d'analyse de code, Squid, pour pallier aux problèmes d'intégration et d'évolution de certains composants que j'ai cités précédemment.

Il y a cependant certaines différences notables entre ces technologies. Par exemple, Sonar ou Squale sont ouverts à d'autres langages que Java. On peut aussi citer le mécanisme d'extension de Sonar ou de Squale (notamment pour faciliter l'ajout de nouvelles données qualité ou de nouveaux langages). Ou encore la possibilité de naviguer en profondeur dans les rapports d'analyse (drill-down) pour identifier précisément les portions de code à risque (voire même afficher le code pour Sonar).

Là où Squale se démarque des autres technologies, c'est dans sa volonté d'agréger les données qualité brutes en indicateurs de haut-niveau compréhensibles par des décideurs. Le but est de s'assurer que les décideurs ont bien une image de la qualité identique à celle des équipes de développement, bien que ne parlant pas du tout le même langage (facteurs haut-niveau vs. métriques techniques). Cela passe par un moteur d'agrégation utilisant des modèles évolués et customisables, sur lesquels nous travaillons avec des chercheurs de l'INRIA Lille et de Paris 8 (Squale est un projet du pôle de compétitivité System@tic Paris-Région).

LinuxFr : Qui est la cible de Squale ? En effet, n'est-il pas trop tourné vers les entreprises pour servir à des petites structures ou d'autres projets OpenSource ?

Squale cible en premier lieu les DSI et toute leur stack hiérarchique, depuis le développeur jusqu'au top-level manager. Par exemple, un chef de projet peut consulter les facteurs haut-niveau et observer leurs tendances, pendant que l'équipe de développement peut plonger dans Squale pour analyser de quelle partie du code provient telle dérive ou tel problème. Un autre exemple d'utilisation de Squale que l'on commence à observer est la contractualisation des niveaux d'exigence qualité des DSI avec leurs fournisseurs informatiques : s'il est difficile de définir des seuils au niveau de métriques techniques, cela devient trivial lorsque l'on parle de facteurs haut-niveau normalisés. Et Squale étant open-source, les DSI et leurs fournisseurs peuvent utiliser le même outil et les mêmes modèles sans problème de licence. On voit donc effectivement bien que Squale a été pensé dès le départ pour répondre à la gestion de patrimoine applicatif en entreprise.
Ce qui ne l'empêche pas d'être utilisé dans d'autres cas, bien au contraire. Par exemple, les consultants de Qualixo s'en servent en mode "one shot" lors de leurs missions d'audit d'application, tant pour l'analyse en profondeur du code (métriques techniques) que pour la restitution d'audit en réunion avec le client (présentation des facteurs haut-niveau). Les projets open-source peuvent tout aussi bien l'utiliser, même si j'imagine que la partie facteurs de haut-niveau est peut-être moins pertinente pour une population de commiiters.

LinuxFr : Concrètement, quel est l'intérêt pour un développeur d'utiliser Squale au quotidien par rapport à des outils (Checkstyle, PMD, etc.) directement intégrés dans un IDE tel Eclipse ?

Squale se base sur les technologies d'analyse de code comme Checkstyle ou PMD. Il n'y a donc pas d'opposition entre les deux, bien au contraire : il est d'ailleurs indispensable que les équipes de développement disposent de ces technologies dans leurs IDEs (via des plugins Eclipse, Netbeans, IntelliJ?, ...). Le tout est juste de s'assurer que les mêmes conventions et configurations sont utilisées sur le poste de développement que sur la plate-forme de qualimétrie Squale. On retrouvera donc les mêmes données de base (métriques) dans les IDEs et sur le serveur Squale.
Ce que Squale apporte en plus, c'est la notion de plan d'action qu'il génère à chaque audit de code qu'il réalise : un algorithme détermine les actions de correction à réaliser en priorité pour augmenter la qualité du code, en optimisant l'ordre par rapport au coût de correction. Cet algorithme est développé en collaboration avec les chercheurs de l'INRIA et se base sur des notions de coût unitaire de correction et de contextualisation de la portion de code à améliorer. L'idée est ensuite de pouvoir importer ce plan d'action au sein de l'IDE pour que l'équipe de développement puisse le consulter et en suivre les conseils.

LinuxFr : Merci Fabrice :)

---