Archives de l’auteur : Jean-Pierre FAYOLLE

À propos Jean-Pierre FAYOLLE

Freelance consultant, blogger.

Complexité et effort de test

Laisser un commentaire

Dans le post précédent, je posais la question ‘Qu’est ce qu’une grosse application ?’ et je proposais deux tables de mesures, basées sur le nombre de lignes de codes (LOC) ou le nombre d’objets afin de catégoriser les applications en ‘simple’, ‘moyenne’, ‘grosse’ et ‘très grosse’.

Evidemment, comme je m’y attendais, la discussion sur les forums traitant d’analyse de code ou de métriques software s’est immédiatement orientée sur les points de fonction, sur la définition de ce qu’est une application (unité de code ou unité organisationnelle) ou sur le type de mesure utilisée par chacun afin d’estimer la taille d’une application. Les nombres que j’ai avancés n’ont pas prêté à discussion.

Cette semaine encore, un autre ‘quizz’ du même type : ‘Qu’est ce qu’une application complexe ?’ et surtout ‘Est-il possible de prévoir l’effort de test en fonction de la complexité d’une application ?’.

Continuer la lecture →

Taille d’une application

Laisser un commentaire

De retour de vacances, c’est la rentrée.

Plein d’idées d’articles pour cette nouvelle saison, mais je vais commencer simplement avec un petit ‘quizz’.

Imaginons que l’on vous demande de catégoriser une application en fonction de sa taille, en nombre de lignes de code (LOC) ou en nombre d’objets. Quelle est votre estimation d’une application de petite taille ? Quand dites-vous qu’une application est grosse ? A partir de quels nombres pensez-vous qu’elle est ‘monstrueuse’ ou hors normes ?

Continuer la lecture →

Benchmark d’applications

Laisser un commentaire

Je pensais que le post précédent sur l’évaluation de la qualité d’une application était le dernier de notre série sur l’analyse de code Cobol avec Sonar. Mais j’ai découvert cette semaine un nouveau plugin de eXcentia, très utile dans le cadre d’un assessment : Sonar Benchmark Plugin.

Ce plugin permet une évaluation comparative – un benchmark – d’une application par rapport à l’ensemble du code présent dans votre référentiel Sonar.

Vous vous rappelez que j’ai analysé différentes applications Cobol, avec lesquelles j’ai créé une View Sonar. Sur la base de cette vue, nous avons effectué une évaluation de la qualité d’une application, pas forcément la plus volumineuse, mais qui présentait un nombre important de violations.

Pour celle-ci, nous avons mis en avant un ensemble de valeurs qui nous ont permis d’effectuer notre assessment et formuler plusieurs recommandations. Mais que vaut-elle par rapport aux autres applications existantes ?

C’est ce que nous allons voir avec ce plugin Sonar Benchmark. Continuer la lecture →

Evaluation de la qualité du code Cobol avec Sonar (2/2)

Laisser un commentaire

Nous poursuivons aujourd’hui notre évaluation de la qualité du code Cobol analysé avec Sonar.

Dans le post précédent, nous avons étudié les métriques mesurant la taille du code, sa complexité, le niveau de documentation et de duplication, ce qui nous a permis de formuler quelques premières préconisations aux responsables de cette application. Continuer la lecture →

Evaluation de la qualité du code Cobol avec Sonar (1/2)

Laisser un commentaire

La qualité du code applicatif est un souci constant depuis des lustres. Les ‘bad practices’ de programmation génèrent des défauts qui impactent les utilisateurs et les coûts de maintenabilité des applications. La Dette Technique, simple métaphore à ses débuts, est devenue depuis un outil de mesure de cette qualité et de ces coûts.

Il y a quelques années encore, les logiciels qui permettaient d’identifier ces défauts étaient rares et chers. Aujourd’hui, les outils Open Source tels que Sonar permettent á chacun – équipes de projets, providers, consultants Qualité, etc. – de détecter de manière aisée et à moindre coût ces ‘bad practices’.

Le monde Open Source a longtemps souffert de son image de ‘geek’ parce que ces outils sont d’abord utilisés par des passionnés issus du monde J2EE, technologie majoritaire dans le monde applicatif. Mais les temps changent, et il est maintenant possible d’analyser du code Legacy, tel que Cobol et ABAP avec Sonar.

C’est là l’objectif de notre série de posts : montrer qu’il est possible d’évaluer la qualité d’applications Cobol sans rien connaître du monde Mainframe. Continuer la lecture →

Votre propre modèle Qualité

Laisser un commentaire

Une règle est connue ou elle ne l’est pas. Une ‘best practice’ est appliquée ou ne l’est pas. Mais si elle n’est pas appliquée, serait-ce parce qu’elle n’est pas applicable ?

Vous devez présenter les résultats de vos premières analyses Cobol et bien sûr, vous souhaitez que ceux-ci soient les plus pertinents possible afin de prouver la valeur de ces analyses aux équipes de projet, providers, stakeholders, etc.

Ceci suppose de définir un modèle qualimétrique – un ensemble de règles et de niveaux de criticité de celles-ci – qui permette d’identifier rapidement les ‘bad practices’ les plus coûteuses et les plus dangereuses. Evidemment, vous devez éviter de dénoncer comme défaut grave une violation à une ‘best practice’ qui n’est pas en vigueur– par exemple, l’utilisation de code SQL (cf. notre dernier post).

Quelles sont les règles applicables ou non ? Quels seuils de criticité choisir ? Comment ajuster le modèle qualimétrique en un Quality profile Sonar pour nos applications Cobol ?

Nous allons montrer dans ce post comment définir votre propre modèle Qualité, à l’aide d’une View Sonar et d’un widget bien utile. Continuer la lecture →

Sonar Cobol – Règles Cobol

Laisser un commentaire

Les précédents posts sur la préparation et l’analyse de code Cobol avec Sonar et Jenkins ont attiré quelques commentaires impatients au sujet du résultat des analyses et des règles disponibles dans le dashboard Sonar.

Ces résultats permettent-ils une évaluation de la qualité des applications Cobol ? Quelle valeur pouvons-nous délivrer aux équipes, aux partenaires et au management ? Et pour ceux qui ne sont pas familiers du monde Mainframe, quelles sont les ‘best/bad practices’ en matière de code Cobol ?

Beaucoup de questions, et nous n’allons pas pouvoir répondre á toutes en un seul post. Celui-ci sera donc dédié à la présentation de différentes règles et défauts de qualité, fréquemment rencontrés dans les applications Cobol.

L’objectif est le suivant : vous avez effectué une analyse, les résultats apparaissent dans le tableau de bord Sonar. Et maintenant, par où commencer ? Continuer la lecture →

Quality profile

Laisser un commentaire

Nous avons vu dans le post précédent comment créer une analyse de code Cobol avec Sonar et Jenkins.

Mais en fait, nous n’avons pas utilisé toutes les régles Cobol existantes dans Sonar. Pourquoi ? Parce que certaines règles sont désactivées car spécifiques à un contexte particulier ou alors nécessitent un certain paramétrage. Par exemple, les règles de nommage ne sont pas standardisées en Cobol, et seront souvent différentes entre différents départements informatiques, voire entre équipes d’un même département.

Il nous faut donc pouvoir gérer différents modéles Qualité, c’est-à-dire différents ensembles de règles selon les projets. Sonar nous offre cette possibilité, grace aux ‘Quality profiles’ qui regroupent les règles actives lors d’une analyse de code.

Nous allons voir, dans ce post, comment créer un nouveau Quality profile comportant toutes les règles Cobol, et l’affecter à un projet existant. Continuer la lecture →

Analyse de code Cobol avec Sonar et Jenkins

Laisser un commentaire

Let’s continue our serie about the analysis of Cobol code, with the objective to demonstrate that it is simple and easy to initiate a process of evaluation of the quality of this Legacy code, without being a Mainframe expert.

You already have a platform of code analysis with Sonar and Jenkins. If this is not the case, an earlier serie of posts will explain you how to install these tools:

in our environement.

You are used to analyze Java code or .NET with this platform and you got the idea, or you were asked, to do the same for Cobol applications. The problem: you know nothing of the Mainframe world.

Don’t panic. Our two previous posts explained:

Now is time to implement the process of analysis in our platform Sonar-Jenkins. Let’s play. Continuer la lecture →