Blockers et Critical<\/strong><\/h3>\nUn coup d\u2019oeil aux violations maintenant. Rappelez vous que nous avons orient\u00e9 notre mod\u00e8le Qualit\u00e9<\/a> vers l\u2019identification de d\u00e9fauts de robustesse et de performance, impactant les utilisateurs.<\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV1.jpg\" "\\"QualCobolAssesV1\\"")
<\/a><\/p>\nLe nombre de d\u00e9fauts bloquants est peu \u00e9lev\u00e9. On retrouve le \u2018SORT\u2019 dont nous avons parl\u00e9 pr\u00e9c\u00e9demment, et 5 \u2018OPEN\u2019 de fichiers dans une boucle. Ce traitement co\u00fbteux pour le syst\u00e8me d\u2019exploitation doit bien s\u00fbr \u00eatre r\u00e9alis\u00e9 avant la boucle. Ces violations pr\u00e9sentent un risque \u00e9lev\u00e9 pour la performance mais sont faciles \u00e0 corriger.<\/p>\n
Les d\u00e9fauts critiques portent sur la robustesse :<\/p>\n
\n- Un code de ‘status’ d\u00e9clar\u00e9 pour un fichier n\u2019est pas test\u00e9 lors d\u2019une op\u00e9ration sur celui-ci (OPEN, READ, WRITE, \u2026). Une tentative d\u2019\u00e9crire dans un fichier non ouvert, de lire dans un fichier en \u00e9criture (Output file), une taille d\u2019enregistrement (RECORD) incorrecte sont des erreurs qui passeront inaper\u00e7ues.<\/li>\n
- Un GOTO qui aiguille le traitement hors du module courant rompt la logique d\u2019ex\u00e9cution de celui-ci.<\/li>\n
- Le EVALUATE sans WHEN OTHER est classique : si aucune des conditions du EVALUATE n\u2019est v\u00e9rifi\u00e9e, la logique du programme devient impr\u00e9visible.<\/li>\n
- La derni\u00e8re r\u00e8gle concernant la taille de fichier ne s\u2019applique qu\u2019au Cobol Microfocus, pas z\/OS ou autre.<\/li>\n<\/ul>\n
Il est tr\u00e8s vraisemblable qu’il existe une norme Qualit\u00e9 imposant la d\u00e9claration et donc la gestion du code ‘status’ du fichier, mais que cette ‘best practice’ est parfois oubli\u00e9e. En l’absence de test sur ce code, une op\u00e9ration incorrecte peut conduite \u00e0 une incoh\u00e9rence de donn\u00e9es sans que celle-ci soit d\u00e9tect\u00e9e. La recherche de la cause de l’erreur sera \u00e9galement plus difficile. De m\u00eame pour le EVALUATE sans WHEN OTHER.<\/p>\n
Toute violation \u00e0 ces r\u00e8gles de gestion des erreurs impacte non seulement les utilisateurs mais \u00e9galement les co\u00fbts de maintenance. Ici, leur nombre suffisamment \u00e9lev\u00e9 nous am\u00e8ne \u00e0 penser que ces bonnes pratiques doivent \u00eatre rappel\u00e9es aux d\u00e9veloppeurs.<\/strong><\/p>\nCo\u00fbts de rem\u00e9diation<\/strong><\/p>\nVous vous rappelez du widget employ\u00e9 dans notre dernier post, qui listait les d\u00e9fauts les plus fr\u00e9quemment rencontr\u00e9es ?<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV2.jpg\" "\\"QualCobolAssesV2\\"")
<\/a><\/p>\nNous retrouvons le IF sans END-IF dont nous avons d\u00e9j\u00e0 parl\u00e9, des GOTOs intempestifs, plus de 4 500 paragraphes non document\u00e9s et du code copi\u00e9-coll\u00e9. Ces r\u00e8gles impactent la maintenabilit\u00e9 de l\u2019application, comme on peut le voir sur ce diagramme:<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV21.jpg\" "\\"QualCobolAssesV21\\"")
<\/a><\/p>\nNous n\u2019allons pas rentrer dans le d\u00e9tail de ces d\u00e9fauts puisque notre objectif est d\u2019identifier ceux qui impactent les utilisateurs. Or les 45 violations de type \u2018Blockers\u2019 et les 292 \u2018Critical\u2019 repr\u00e9sentent respectivement 5.6 jours et 50.5 jours de correction.<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV22.jpg\" "\\"QualCobolAssesV22\\"")
<\/a><\/p>\nEnviron 2 semaines de travail pour une \u00e9quipe de 5 ou 6 personnes. Par contre, il faudrait plus de 10 ann\u00e9es homme pour corriger les violations qui p\u00e8sent sur les co\u00fbts de maintenance.<\/p>\n
Plan d’actions
\n<\/strong><\/h3>\nBien \u00e9videmment, il nous faudra pr\u00e9senter ces r\u00e9sultats \u00e0 l\u2019\u00e9quipe de projet et les commenter avec eux afin de v\u00e9rifier nos hypoth\u00e8ses. Cependant, notre objectif n\u2019est pas de r\u00e9aliser un audit exhaustif mais de montrer comment il est possible de tirer quelques conclusions sur la base de ces quelques donn\u00e9es, et formuler une \u00e9bauche de plan d\u2019actions.<\/p>\n
Actions \u00e0 court terme :<\/p>\n
\n- Corriger les d\u00e9fauts \u2018Blockers\u2019 qui affectent la performance : 5 jours.<\/li>\n
- Corriger les d\u00e9fauts \u2018Critical\u2019, source potentielle de bugs : 55 jours.<\/li>\n
- Rappeler aux \u00e9quipes Cobol l\u2019interdiction des GOTOs \u2013 notamment en exception \u00e0 la logique du module \u2013 et les bonnes pratiques en mati\u00e8re de gestions des erreurs, comme l’obligation de tester le statut d\u2019un fichier apr\u00e8s toute op\u00e9ration sur celui-ci et le EVALUATE sans WHEN OTHER.<\/li>\n
- Effectuer une analyse r\u00e9guli\u00e8re de cette application et v\u00e9rifier qu\u2019aucune r\u00e8gle bloquante ou critique ne r\u00e9apparaisse.<\/li>\n<\/ul>\n
Ces actions sont peu co\u00fbteuses et peuvent s\u2019effectuer \u00e0 court terme, pour un b\u00e9n\u00e9fice maximal. Elles conduisent \u00e0 la mise en place d’un processus d’am\u00e9lioration continue. Les utilisateurs vous en remercieront.<\/p>\n
Cette application pr\u00e9sente des co\u00fbts de maintenance \u00e9lev\u00e9s. V\u00e9rifier aupr\u00e8s du management si c\u2019est bien le cas et leur opinion \u00e0 ce sujet. Il se peut tr\u00e8s bien que cette application connaisse peu ou pas d\u2019\u00e9volution auquel cas, la maintenance n\u2019est pas un probl\u00e8me.<\/p>\n
V\u00e9rifiez \u00e9galement les hypoth\u00e8ses que nous avons \u00e9mises dans notre post pr\u00e9c\u00e9dent<\/a> (application batch ou orient\u00e9e fichiers de donn\u00e9es, peu critique) et expliquez bien qu\u2019elle ne peut \u00eatre outsourc\u00e9e sans danger.<\/p>\nProposez le plan d\u2019action suivant:<\/p>\n
\n- Identifier et supprimer les 184 fichiers dupliqu\u00e9s, qui p\u00e8sent \u00e9norm\u00e9ment sur la maintenabilit\u00e9.<\/li>\n
- Effectuer \u00e0 nouveau une analyse afin de recalculer la dette technique et une estimation de co\u00fbt de refactoring.<\/li>\n<\/ul>\n
Strat\u00e9gie applicative
\n<\/strong><\/p>\n<\/strong>Le refactoring d’une application Cobol est une op\u00e9ration rarement envisag\u00e9e, car les co\u00fbts sont trop \u00e9lev\u00e9s. G\u00e9n\u00e9ralement, on laisse l’application mourir de sa belle mort, et l’on recherche une autre solution (ERP par exemple).<\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV3.jpg\" "\\"QualCobolAssesV3\\"")
<\/a>Comme nous souhaitons effectuer des pr\u00e9conisations r\u00e9alistes, voici ce que je fais : je regarde quels sont les programmes qui comportent le plus grand nombre de lignes et de d\u00e9fauts.<\/p>\nIci, nous avons 3 programmes qui totalisent \u00e0 eux seuls plus de 27 000 lignes, soit 15% de la taille totale de l’application (en LOC).<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF1.jpg\" "\\"QualCobolAssesRF1\\"")
<\/a><\/p>\n <\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF2.jpg\" "\\"QualCobolAssesRF2\\"")
<\/a>Ils sont \u00e9galement dans le top 5 des programmes les plus complexent, avec un total de 5 900 points de Complexit\u00e9 Cyclomatique, soit 26% de la complexit\u00e9 totale de l’application.<\/p>\n
Le nombre de d\u00e9fauts bloquants est peu \u00e9lev\u00e9. On retrouve le \u2018SORT\u2019 dont nous avons parl\u00e9 pr\u00e9c\u00e9demment, et 5 \u2018OPEN\u2019 de fichiers dans une boucle. Ce traitement co\u00fbteux pour le syst\u00e8me d\u2019exploitation doit bien s\u00fbr \u00eatre r\u00e9alis\u00e9 avant la boucle. Ces violations pr\u00e9sentent un risque \u00e9lev\u00e9 pour la performance mais sont faciles \u00e0 corriger.<\/p>\n Les d\u00e9fauts critiques portent sur la robustesse :<\/p>\n Il est tr\u00e8s vraisemblable qu’il existe une norme Qualit\u00e9 imposant la d\u00e9claration et donc la gestion du code ‘status’ du fichier, mais que cette ‘best practice’ est parfois oubli\u00e9e. En l’absence de test sur ce code, une op\u00e9ration incorrecte peut conduite \u00e0 une incoh\u00e9rence de donn\u00e9es sans que celle-ci soit d\u00e9tect\u00e9e. La recherche de la cause de l’erreur sera \u00e9galement plus difficile. De m\u00eame pour le EVALUATE sans WHEN OTHER.<\/p>\n Toute violation \u00e0 ces r\u00e8gles de gestion des erreurs impacte non seulement les utilisateurs mais \u00e9galement les co\u00fbts de maintenance. Ici, leur nombre suffisamment \u00e9lev\u00e9 nous am\u00e8ne \u00e0 penser que ces bonnes pratiques doivent \u00eatre rappel\u00e9es aux d\u00e9veloppeurs.<\/strong><\/p>\n Co\u00fbts de rem\u00e9diation<\/strong><\/p>\n Vous vous rappelez du widget employ\u00e9 dans notre dernier post, qui listait les d\u00e9fauts les plus fr\u00e9quemment rencontr\u00e9es ?<\/p>\n Nous retrouvons le IF sans END-IF dont nous avons d\u00e9j\u00e0 parl\u00e9, des GOTOs intempestifs, plus de 4 500 paragraphes non document\u00e9s et du code copi\u00e9-coll\u00e9. Ces r\u00e8gles impactent la maintenabilit\u00e9 de l\u2019application, comme on peut le voir sur ce diagramme:<\/p>\n Nous n\u2019allons pas rentrer dans le d\u00e9tail de ces d\u00e9fauts puisque notre objectif est d\u2019identifier ceux qui impactent les utilisateurs. Or les 45 violations de type \u2018Blockers\u2019 et les 292 \u2018Critical\u2019 repr\u00e9sentent respectivement 5.6 jours et 50.5 jours de correction.<\/p>\n Environ 2 semaines de travail pour une \u00e9quipe de 5 ou 6 personnes. Par contre, il faudrait plus de 10 ann\u00e9es homme pour corriger les violations qui p\u00e8sent sur les co\u00fbts de maintenance.<\/p>\n Bien \u00e9videmment, il nous faudra pr\u00e9senter ces r\u00e9sultats \u00e0 l\u2019\u00e9quipe de projet et les commenter avec eux afin de v\u00e9rifier nos hypoth\u00e8ses. Cependant, notre objectif n\u2019est pas de r\u00e9aliser un audit exhaustif mais de montrer comment il est possible de tirer quelques conclusions sur la base de ces quelques donn\u00e9es, et formuler une \u00e9bauche de plan d\u2019actions.<\/p>\n Actions \u00e0 court terme :<\/p>\n Ces actions sont peu co\u00fbteuses et peuvent s\u2019effectuer \u00e0 court terme, pour un b\u00e9n\u00e9fice maximal. Elles conduisent \u00e0 la mise en place d’un processus d’am\u00e9lioration continue. Les utilisateurs vous en remercieront.<\/p>\n Cette application pr\u00e9sente des co\u00fbts de maintenance \u00e9lev\u00e9s. V\u00e9rifier aupr\u00e8s du management si c\u2019est bien le cas et leur opinion \u00e0 ce sujet. Il se peut tr\u00e8s bien que cette application connaisse peu ou pas d\u2019\u00e9volution auquel cas, la maintenance n\u2019est pas un probl\u00e8me.<\/p>\n V\u00e9rifiez \u00e9galement les hypoth\u00e8ses que nous avons \u00e9mises dans notre post pr\u00e9c\u00e9dent<\/a> (application batch ou orient\u00e9e fichiers de donn\u00e9es, peu critique) et expliquez bien qu\u2019elle ne peut \u00eatre outsourc\u00e9e sans danger.<\/p>\n Proposez le plan d\u2019action suivant:<\/p>\n Strat\u00e9gie applicative <\/strong>Le refactoring d’une application Cobol est une op\u00e9ration rarement envisag\u00e9e, car les co\u00fbts sont trop \u00e9lev\u00e9s. G\u00e9n\u00e9ralement, on laisse l’application mourir de sa belle mort, et l’on recherche une autre solution (ERP par exemple).<\/p>\n Ici, nous avons 3 programmes qui totalisent \u00e0 eux seuls plus de 27 000 lignes, soit 15% de la taille totale de l’application (en LOC).<\/p>\n <\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nPlan d’actions
\n<\/strong><\/h3>\n\n
\n
\n<\/strong><\/p>\n<\/a>Comme nous souhaitons effectuer des pr\u00e9conisations r\u00e9alistes, voici ce que je fais : je regarde quels sont les programmes qui comportent le plus grand nombre de lignes et de d\u00e9fauts.<\/p>\n<\/a><\/p>\n<\/a>Ils sont \u00e9galement dans le top 5 des programmes les plus complexent, avec un total de 5 900 points de Complexit\u00e9 Cyclomatique, soit 26% de la complexit\u00e9 totale de l’application.<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF3.jpg\" "\\"QualCobolAssesRF3\\"")
<\/a><\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF4.jpg\" "\\"QualCobolAssesRF4\\"")
<\/a>