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.

Blockers et Critical

Un coup d’oeil aux violations maintenant. Rappelez vous que nous avons orienté notre modèle Qualité vers l’identification de défauts de robustesse et de performance, impactant les utilisateurs.

Le nombre de défauts bloquants est peu élevé. On retrouve le ‘SORT’ dont nous avons parlé précédemment, et 5 ‘OPEN’ de fichiers dans une boucle. Ce traitement coûteux pour le système d’exploitation doit bien sûr être réalisé avant la boucle. Ces violations présentent un risque élevé pour la performance mais sont faciles à corriger.

Les défauts critiques portent sur la robustesse :

• Un code de ‘status’ déclaré pour un fichier n’est pas testé lors d’une opération sur celui-ci (OPEN, READ, WRITE, …). Une tentative d’écrire dans un fichier non ouvert, de lire dans un fichier en écriture (Output file), une taille d’enregistrement (RECORD) incorrecte sont des erreurs qui passeront inaperçues.
• Un GOTO qui aiguille le traitement hors du module courant rompt la logique d’exécution de celui-ci.
• Le EVALUATE sans WHEN OTHER est classique : si aucune des conditions du EVALUATE n’est vérifiée, la logique du programme devient imprévisible.
• La dernière règle concernant la taille de fichier ne s’applique qu’au Cobol Microfocus, pas z/OS ou autre.

Il est très vraisemblable qu’il existe une norme Qualité imposant la déclaration et donc la gestion du code ‘status’ du fichier, mais que cette ‘best practice’ est parfois oubliée. En l’absence de test sur ce code, une opération incorrecte peut conduite à une incohérence de données sans que celle-ci soit détectée. La recherche de la cause de l’erreur sera également plus difficile. De même pour le EVALUATE sans WHEN OTHER.

Toute violation à ces règles de gestion des erreurs impacte non seulement les utilisateurs mais également les coûts de maintenance. Ici, leur nombre suffisamment élevé nous amène à penser que ces bonnes pratiques doivent être rappelées aux développeurs.

Coûts de remédiation

Vous vous rappelez du widget employé dans notre dernier post, qui listait les défauts les plus fréquemment rencontrées ?

Nous retrouvons le IF sans END-IF dont nous avons déjà parlé, des GOTOs intempestifs, plus de 4 500 paragraphes non documentés et du code copié-collé. Ces règles impactent la maintenabilité de l’application, comme on peut le voir sur ce diagramme:

Nous n’allons pas rentrer dans le détail de ces défauts puisque notre objectif est d’identifier ceux qui impactent les utilisateurs. Or les 45 violations de type ‘Blockers’ et les 292 ‘Critical’ représentent respectivement 5.6 jours et 50.5 jours de correction.

Environ 2 semaines de travail pour une équipe de 5 ou 6 personnes. Par contre, il faudrait plus de 10 années homme pour corriger les violations qui pèsent sur les coûts de maintenance.

Plan d’actions

Bien évidemment, il nous faudra présenter ces résultats à l’équipe de projet et les commenter avec eux afin de vérifier nos hypothèses. Cependant, notre objectif n’est pas de réaliser un audit exhaustif mais de montrer comment il est possible de tirer quelques conclusions sur la base de ces quelques données, et formuler une ébauche de plan d’actions.

Actions à court terme :

• Corriger les défauts ‘Blockers’ qui affectent la performance : 5 jours.
• Corriger les défauts ‘Critical’, source potentielle de bugs : 55 jours.
• Rappeler aux équipes Cobol l’interdiction des GOTOs – notamment en exception à la logique du module – et les bonnes pratiques en matière de gestions des erreurs, comme l’obligation de tester le statut d’un fichier après toute opération sur celui-ci et le EVALUATE sans WHEN OTHER.
• Effectuer une analyse régulière de cette application et vérifier qu’aucune règle bloquante ou critique ne réapparaisse.

Ces actions sont peu coûteuses et peuvent s’effectuer à court terme, pour un bénéfice maximal. Elles conduisent à la mise en place d’un processus d’amélioration continue. Les utilisateurs vous en remercieront.

Cette application présente des coûts de maintenance élevés. Vérifier auprès du management si c’est bien le cas et leur opinion à ce sujet. Il se peut très bien que cette application connaisse peu ou pas d’évolution auquel cas, la maintenance n’est pas un problème.

Vérifiez également les hypothèses que nous avons émises dans notre post précédent (application batch ou orientée fichiers de données, peu critique) et expliquez bien qu’elle ne peut être outsourcée sans danger.

Proposez le plan d’action suivant:

• Identifier et supprimer les 184 fichiers dupliqués, qui pèsent énormément sur la maintenabilité.
• Effectuer à nouveau une analyse afin de recalculer la dette technique et une estimation de coût de refactoring.

Stratégie applicative

Le refactoring d’une application Cobol est une opération rarement envisagée, car les coûts sont trop élevés. Généralement, on laisse l’application mourir de sa belle mort, et l’on recherche une autre solution (ERP par exemple).

Comme nous souhaitons effectuer des préconisations réalistes, voici ce que je fais : je regarde quels sont les programmes qui comportent le plus grand nombre de lignes et de défauts.

Ici, nous avons 3 programmes qui totalisent à eux seuls plus de 27 000 lignes, soit 15% de la taille totale de l’application (en LOC).

 

Ils sont également dans le top 5 des programmes les plus complexent, avec un total de 5 900 points de Complexité Cyclomatique, soit 26% de la complexité totale de l’application.

Et ce sont les 3 programmes qui concentrent le plus de violations, quelques une Critical mais la plupart de type Major.

Au total, plus de 6 700 violations donc prés du quart (24%) du nombre total de défauts rencontrés dans cette application.

Certes, le coût de remédiation de ces 3 programmes est très élevé: 735 jours, soit environ 3 années-homme.

Quelles informations pouvons-nous donc délivrer ?

Un refactoring partiel portant sur ces 3 programmes représentant 15% de la taille de l’application et 26% de sa complexité, permettrait de supprimer un quart du nombre de défauts total, ceux-ci portant quasi exclusivement sur la maintenabilité.

Si l’on imagine que ce refactoring partiel permettrait de diminuer les coûts de maintenabilité dans la même proportion (25%), cela représente pour une équipe de 6 personnes un gain de 1.5 personne à l’année. Contre un coût de refactoring de 3 années-homme, donc avec un retour sur investissement au bout de 2 ans.

Certes il s’agit d’une estimation rapide pour ne pas dire grossière. Mais je souhaite illustrer de cette manière que la valeur d’un assessment consiste à délivrer des informations objectives qui permettent au management de prendre des décisions. Le chiffre de la dette technique globale sur toute l’application n’aboutit qu’à une seule décision possible : jeter cette application. Une estimation de gains / coûts et ROI sur un refactoring partiel permet d’imaginer une stratégie alternative et même si vos chiffres supposent une certaine marge d’erreur, le management comprendra bien quelle est votre intention et l’appréciera à sa valeur.

Vendez la valeur

Le post d’aujourd’hui conclue notre série sur l’analyse de code Cobol avec Sonar. Notre intention dans cette série était de démontrer qu’il est possible d’évaluer la qualité des applications Cobol sans être un expert du monde Mainframe. De la même manière, nul besoin d’être un guru du monde Open Source ou un expert J2EE pour réaliser cette analyse avec Sonar.

En définitive, avec un minimum de connaissances de la technologie Cobol et de Sonar, nous pouvons proposer aux équipes de projet, stakeholders et au management un plan d’actions à court et moyen terme qui permettent d’améliorer la performance et la robustesse de l’application, mais également le respect des bonnes pratiques et la qualité de l’application.

Nous pouvons également fournir au management ce dont il est le plus demandeur : l’information pour une meilleure prise de décision. Lá se trouve la valeur de vos analyses. Vendez cette valeur, pas des métriques ou vos connaissances techniques.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.