Le JUG (Java User Group) de Lausanne organisait ce jeudi 10 février une soirée autour de la qualité logicielle, avec une démarche originale : les principaux acteurs du marché étaient conviés à réaliser l’analyse d’un même projet OpenSource, IceScrum, et à présenter leur outil au travers des résultats de cette analyse.
Nous nous sommes prêtés au jeu et avons passé ce projet sur notre plateforme. Voici une synthèse de notre analyse destinée à mieux appréhender notre solution. Comme nous avons réalisé l’analyse sur notre plateforme Cloud, nous avons également ouvert un accès avec un compte générique sur ce projet. Pour y accéder et consulter l’ensemble des résultats:
- URL : https://cockpit.kalistick.com
- Login : jug.ch
- Mot de passe : lausanne
Notre plateforme génère aussi automatiquement des rapports d’audit, synthétiques ou détaillés, au format MS Word, MS Powerpoint ou PDF. Voici le rapport détaillé pour le projet IceScrum:![]()
Si vous souhaitez analyser votre propre projet, vous pouvez également créer votre accès dédié en quelques minutes sur cette page (évaluation complète et gratuite de 30 jours).
Nous présentons notre analyse en 4 parties :
- Description du projet et du processus d’analyse
- L’analyse qualité
- Evolution et analyse d’impacts
- Le plan d’action
Le projet analysé : IceScrum
IceScrum est un outil collaboratif destiné à piloter des projets suivant la méthodologie Scrum. C’est à la base un projet universitaire développé sous l’impulsion de Claude Aubry, célèbre agiliste français. Le JUG nous a demandé d’analyser la version 2 du projet, qui date de mai 2010. Depuis, le projet a été entièrement refondu et une version 3 est disponible. IceScrum se positionne désormais dans les produits phares du marché agile.
Le processus d’analyse
Le processus d’analyse de la plateforme Kalistick est entièrement automatisable. Nous avons simplement récupéré les sources du projet (à partir de https://icescrum.svn.sourceforge.net/svnroot/icescrum) et paramétré l’exécution Maven pour utiliser notre plugin Maven.
Le plugin Maven construit une archive du projet (à partir des sources, des sources compilés, des librairies, des informations SVN et des rapports de tests unitaires) puis le télécharge sur le serveur Kalistick, ce qui déclenche l’analyse. Chacun peut mettre en oeuvre ce processus sur notre version Cloud en quelques minutes.
Comme la plateforme Kalistick n’est pas un simple outil d’audit mais une solution destinée à être utilisée en continu, nous avons également analysé une version précédente à titre d’exemple, la R2#13 (de mai 2009). Ceci permet de mettre en oeuvre les indicateurs liés à l’évolution ou aux impacts métiers des modifications.
Modélisation de l’application
Le Cockpit (la console web) permet de réprésenter une application selon des modélisations techniques et fonctionnelles, ce qui est utile pour :
- mieux comprendre de quoi est constitué l’application, et comment les différentes briques sont organisées
- fournir un support synthétique de restitution des résultats à tous les acteurs du projet, même ceux qui n’ont pas de connaissance technique sur le code
- vérifier l’architecture technique, en comparant son état actuel avec le modèle d’architecture cible
Le Cockpit fournit un assistant pour générer et aider à la maintenance des modèles (voir le How to design customized views of your application). Voici ceux qui ont été créés pour le projet IceScrum :
- La vue métier. L’analyse Kalistick génère un corpus lexical du vocabulaire métier du code, ce qui permet de créer facilement ce type de modèles. Ces modèles servent notamment de support pour présenter les impacts des modifications et les risques de régression entre deux versions. Sur IceScrum, le découpage réalisé reste assez macroscopique, mais le niveau de détail peut être plus fin.
- L’architecture technique. Le modèle technique est généré automatiquement à partir d’une analyse basée sur les dépendances, l’organisation, ou le nommage du code. Outre la représentation synthétique de l’application, les modèles techniques permettent également de définir des contraintes de communication entre les briques techniques, internes à l’application, ou externes (librairies tierces). On voit rapidement que le modèle technique de IceScrum est basé sur JSF (Java Server Faces), avec un modèle en couches pour rendre étanche la communication avec la base de données.
Ces modèles seront exploités par la suite pour restituer les résultats, que ce soit pour l’analyse de qualité, ou pour l’analyse d’impact.
La prochaine partie présente les résultats de l’analyse qualité.



Pingback: OCTO talks ! » Retour sur le JUG de Lausanne sur l’analyse de la qualité du code Java