{"id":2195,"date":"2014-11-08T07:57:53","date_gmt":"2014-11-08T06:57:53","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2195"},"modified":"2014-11-17T05:12:58","modified_gmt":"2014-11-17T04:12:58","slug":"application-legacy-objectifs-reengineering","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/application-legacy-objectifs-reengineering\/","title":{"rendered":"Application Legacy &#8211; Objectifs d&rsquo;un reengineering"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-2197\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/11\/LegacyApp_ReengineeringObjectives.jpg\" alt=\"Application Legacy - Objectifs d'un reengineering\" width=\"239\" height=\"360\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/11\/LegacyApp_ReengineeringObjectives.jpg 239w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/11\/LegacyApp_ReengineeringObjectives-199x300.jpg 199w\" sizes=\"(max-width: 239px) 100vw, 239px\" \/><\/a>Un reengineering ne signifie pas toujours dans l\u2019esprit de chacun, la r\u00e9\u00e9criture de notre application Legacy dans un autre langage g\u00e9n\u00e9ralement plus r\u00e9cent, mais c\u2019est n\u00e9anmoins <a title=\"Application Legacy en C \u2013 Refactoring ou r\u00e9ing\u00e9nierie ? (I)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-c-refactoring-reingenierie-1\/\" target=\"_blank\">l\u2019option que nous avons choisie<\/a>.<\/p>\n<p>Lorsqu\u2019il s\u2019agit \u2018simplement\u2019 de r\u00e9organiser le code afin de rendre celui-ci plus maintenable, mais sans le porter sur une nouvelle plate-forme logicielle ou hardware \u2013 comme par exemple la migration d\u2019une application Mainframe-Cobol vers une architecture Unix \u2013 je pr\u00e9f\u00e8re parler de refactoring.<\/p>\n<p>Je vous rappelle que ce blog n\u2019a pas de pr\u00e9tentions acad\u00e9miques, donc je ne vais pas m\u2019embarrasser de d\u00e9finitions m\u00e9ticuleusement exactes, qui d\u00e9bouchent le plus souvent sur des discussions quadripilotectomiques (1) de sp\u00e9cialistes qui n\u2019ont rien d\u2019autre \u00e0 faire que de gloser sur la moindre virgule. <!--more--><\/p>\n<p>Mais ceci n\u2019interdit pas un minimum de pr\u00e9cision, afin d\u2019\u00e9viter pr\u00e9conceptions et autres malentendus. Nous avons d\u2019abord regard\u00e9 quelles <a title=\"Application Legacy \u2013 Refactoring avec le plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">actions de refactoring<\/a> nous pouvions envisager pour notre <a title=\"Audit d\u2019une application Legacy en C \u2013 Microsoft Word 1.1a (I)\" href=\"http:\/\/qualilogy.com\/fr\/audit-application-legacy-c-microsoft-word-1-1a-1\/\" target=\"_blank\">application Legacy en C (Word 1.1a)<\/a> \u00e0 l\u2019aide du plugin SQALE. Puis nous avons tent\u00e9 une <a title=\"Application Legacy \u2013 Refactoring avec le plugin SQALE (II)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-plugin-sqale-2\/\" target=\"_blank\">estimation du co\u00fbt de ces actions<\/a> et un <a title=\"Application Legacy \u2013 Dette technique et ROI d\u2019un refactoring\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-dette-technique-roi-refactoring\/\" target=\"_blank\">calcul de ROI<\/a>.<br \/>\nAujourd\u2019hui, je vais \u00e9voquer quelques \u00e9l\u00e9ments \u00e0 prendre en compte lorsque l\u2019on envisage un reengineering.<\/p>\n<h2>Objectifs<\/h2>\n<p>La strat\u00e9gie produit ou applicative est \u00e9videmment au c\u0153ur d\u2019un plan de r\u00e9ing\u00e9nierie : plateforme logicielle et\/ou hardware trop co\u00fbteuse ou en fin de vie, raret\u00e9 des comp\u00e9tences informatiques pour maintenir l\u2019application sur cette plate-forme, co\u00fbts de maintenance trop \u00e9lev\u00e9s, etc. Mais dans tous les cas, on souhaite conserver l\u2019application, ou le produit logiciel dans le cas d\u2019un vendeur de software, et non pas l\u2019abandonner en le rempla\u00e7ant par un progiciel ou le d\u00e9veloppement d\u2019une nouvelle application, ou en le sortant du catalogue pour un \u00e9diteur.<\/p>\n<p>L\u2019\u00e9tape pr\u00e9alable \u00e0 une r\u00e9ing\u00e9nierie consiste donc en une identification claire des objectifs.<\/p>\n<p>Or, contrairement \u00e0 ce que l\u2019on pourrait croire, un reengineering n&rsquo;est pas toujours un objectif conscient. Bien s\u00fbr, si votre Directeur Informatique en a assez de voir chaque ann\u00e9e des commerciaux lui annon\u00e7aient :<\/p>\n<ul>\n<li>la fin proche de tel logiciel ou plateforme ET,<\/li>\n<li>la n\u00e9cessit\u00e9 d\u2019acqu\u00e9rir en remplacement tel nouveau software ET,<\/li>\n<li>de d\u00e9marrer un projet d\u2019impl\u00e9mentation avec leurs consultants, tous aussi experts que on\u00e9reux, ET<\/li>\n<li>la n\u00e9cessit\u00e9 d\u2019upgrader son infrastructure informatique afin de conserver un niveau de performance acceptable pour cette nouvelle plateforme logicielle ET<\/li>\n<li>une nouvelle tarification \u00e0 la hausse, ALORS<\/li>\n<\/ul>\n<p>il pourrait bien envisager un bouleversement technologique majeur afin de remettre la main sur son informatique et qu\u2019on cesse de le traiter comme une vache \u00e0 lait.<\/p>\n<p>Cependant, j\u2019ai vu nombre de cas o\u00f9 le reengineering n\u2019\u00e9tait pas envisag\u00e9 \u00e0 l\u2019origine, mais s\u2019est impos\u00e9 comme un choix n\u00e9cessaire et incontournable \u00e0 la suite d\u2019une s\u00e9rie de d\u00e9couvertes, de r\u00e9flexions et de d\u00e9cisions plus ou moins bien formalis\u00e9es.<\/p>\n<h3>Reengineering et portefeuilles applicatifs<\/h3>\n<p>J\u2019ai fait un audit pour une banque, ou plut\u00f4t pour sa division \u2018Asset Managemet\u2019 qui s\u2019occupe de la gestion d\u2019actifs financiers, avec une application dont le nombre de clients devait \u00eatre multipli\u00e9 par trois. Qui dit 3 fois plus d\u2019utilisateurs dit \u00e9galement 3 fois plus de donn\u00e9es, et 3 fois plus (en moyenne) de connexions \u00e0 une base de donn\u00e9es 3 fois plus importante. D\u2019o\u00f9 un souci de performance de la part de cette banque. Leur premi\u00e8re r\u00e9action a \u00e9t\u00e9 de chercher un outil de tests de charge, puis ils ont commenc\u00e9 \u00e0 se demander s\u2019il \u00e9tait possible de d\u00e9tecter dans le code d\u2019\u00e9ventuels d\u00e9fauts de programmation qui pourraient menacer les futurs temps de r\u00e9ponse.<\/p>\n<p>Si me souviens bien, il s\u2019agissait d\u2019une application en Visual Basic et, pour les raisons habituelles de confidentialit\u00e9, ils ne souhaitaient pas me confier le code entier de leur application. Ce qui pose toujours un probl\u00e8me car moins vous avez de code, moins vous pouvez rencontrer de d\u00e9fauts dans le code et plus il est difficile de d\u00e9montrer la valeur que vous pouvez apporter.<\/p>\n<p>Je leur donc ai propos\u00e9 d\u2019analyser un module de leur application, mais \u00e9galement de me livrer du code J2EE et Cobol, avec un objectif principal centr\u00e9 sur l\u2019identification de risques potentiels pour la performance, et un second objectif sur la mesure de la maintenabilit\u00e9. Qui ne les int\u00e9ressait pas beaucoup, il m\u2019a vraiment fallu insister. Mais quand j\u2019ai pr\u00e9sent\u00e9 les r\u00e9sultats, ils sont rest\u00e9s assez impressionn\u00e9s, et quelqu\u2019un dans la pi\u00e8ce a dit : \u00ab il faut pr\u00e9senter cela au CIO \u00bb.<\/p>\n<p>En fait, outre leur souci de performance sur cette application, le CIO avait surtout une pr\u00e9occupation de r\u00e9novation de son portefeuille applicatif, dont il ressentait bien qu\u2019il d\u00e9bordait d\u2019applications pas toujours tr\u00e8s critiques, mais souvent peu maintenables, et sans savoir par o\u00f9 commencer. Nous avons eu une seconde r\u00e9union \u00e0 laquelle il a particip\u00e9, et dans laquelle nous avons pratiquement construit en \u2018live\u2019 un plan de refactoring de l\u2019application Cobol et la r\u00e9ing\u00e9nierie de l\u2019application Visual Basic.<\/p>\n<p>Conclusion : certains \u2018use cases\u2019 peuvent mener \u00e0 un refactoring et un reengineering qui n\u2019\u00e9taient pas initialement un objectif. Un outil d\u2019analyse et de mesure de la qualit\u00e9 de code est n\u00e9cessaire pour savoir quelles applications de votre portefeuille applicatif pourront b\u00e9n\u00e9ficier d\u2019une r\u00e9ing\u00e9nierie, et par o\u00f9 commencer.<\/p>\n<h3>Reengineering d\u2019outils maison<\/h3>\n<p>Parfois le reengineering portera simplement sur une partie de l\u2019application. Au d\u00e9but des ann\u00e9es 90, avec la survenance du client-serveur et des premi\u00e8res applications \u00e0 interface graphique, nombre d\u2019entreprises ont d\u00e9velopp\u00e9 leur propre middleware afin d\u2019assurer des \u00e9changes (asynchrones ou non) entre leur mainframe et ces nouvelles applications. Une \u00e9quipe d\u00e9di\u00e9e se chargeait de d\u00e9velopper et de maintenir ce middleware, en d\u00e9livrant r\u00e9guli\u00e8rement les APIs et la documentation qui permettaient son utilisation par les \u00e9quipes de projet.<\/p>\n<p>Le probl\u00e8me est que, comme toute application, ce code accumulait de la dette technique, et la maintenance de cet outil devenait de plus en plus lourde, les corrections et les \u00e9volutions demand\u00e9es par les projets de plus en plus longues et co\u00fbteuses \u00e0 impl\u00e9menter, la documentation plus difficile \u00e0 maintenir, et la connaissance se perdait au fur et \u00e0 mesure que les membres de l\u2019\u00e9quipe progressaient vers d\u2019autres postes ou simplement quittaient l\u2019entreprise. Donc est arriv\u00e9 un moment o\u00f9 ce middleware maison a laiss\u00e9 place \u00e0 un outil de type MOM, ESB, EAI, voire \u00e0 une nouvelle architecture type SOA ou EDA (2). Non, ne me demandez pas de d\u00e9finition, j\u2019ai dit en d\u00e9but de ce post que ce blog n\u2019\u00e9tait pas un dictionnaire !<\/p>\n<p>Bien \u00e9videmment, il a fallu encapsuler ce nouvel outil dans les APIs existantes, afin d\u2019impacter le moins possible les applications qui utilisaient ces derni\u00e8res. Comme le middleware maison \u00e9tait le plus souvent programm\u00e9 avec un langage de type L3G, mais aussi il faut bien le dire, face \u00e0 l\u2019enthousiasme de l\u2019\u00e9quipe \u2018middleware\u2019 pour les nouvelles technologies, bon nombre de ces APIs ont \u00e9t\u00e9 r\u00e9\u00e9crites, souvent \u00e0 l\u2019identique, mais en tout cas avec des langages Orient\u00e9s Objet.<\/p>\n<h3>Reengineering et interfaces utilisateur<\/h3>\n<p>Un cas tr\u00e8s fr\u00e9quent de r\u00e9ing\u00e9nierie concerne les applications avec une interface utilisateur vieillotte ou obsol\u00e8te. Cela a \u00e9t\u00e9 le cas de nombre d\u2019applications mainframe avec une interface caract\u00e8re, qui ont \u00e9t\u00e9 port\u00e9es (non sans mal) sous Windows. Il existait m\u00eame \u00e0 une certaine \u00e9poque, des outils de g\u00e9n\u00e9ration d\u2019\u00e9crans, qui reprenaient des \u2018grilles\u2019 mainframe pour les transformer en \u00e9crans Windows, avec des r\u00e9sultats assez comiques (sauf pour les utilisateurs finals).<\/p>\n<p>La bulle Internet et les sites Web ont caus\u00e9 beaucoup de d\u00e9g\u00e2ts en ce qui concerne le respect des normes d\u2019interface graphiques, mais avec les applications pour smartphone, on d\u00e9couvre \u00e0 nouveau l\u2019importance de ces normes, m\u00eame si sous un vocable plus moderne de UX (User Experience).<\/p>\n<p>Donc nombre d\u2019applications connaissent une r\u00e9ing\u00e9nierie de leur couche de pr\u00e9sentation afin d\u2019\u00eatre accessibles aussi bien sur le Web que sur votre mobile. Les \u00e9diteurs logiciels doivent \u00e9galement effectuer ce type de projet assez fr\u00e9quemment. Une interface HTML d\u00e9pass\u00e9e est un v\u00e9ritable poids mort lorsqu\u2019il s\u2019agit de vendre un software et n\u00e9cessitera un relooking dans une nouvelle technologie : Flex ou HTML5 par exemple.<\/p>\n<p>Ce qui pose parfois des probl\u00e8mes. Essayez donc de s\u00e9lectionner une ou plusieurs lignes d\u2019un tableau Flex pour effectuer un copier-coller : les utilisateurs vont avoir du mal \u00e0 comprendre que vous ayez adopt\u00e9 une technologie plus r\u00e9cente qui ne lui permette pas des op\u00e9rations aussi basiques.<\/p>\n<p>Bien souvent, un \u00e9diteur logiciel ne va pas interpr\u00e9ter cette \u00e9volution de l\u2019interface graphique comme un reengineering mais simplement comme une nouvelle version de son software, avec des \u00e9crans plus jolis. S\u2019il le faisait, s\u2019il l\u2019identifiait comme un objectif clair de migration vers une nouvelle technologie et une interface graphique diff\u00e9rente, il pourrait peut-\u00eatre r\u00e9fl\u00e9chir aux impacts pour les utilisateurs en termes de modes op\u00e9ratoires au lieu d\u2019attendre que ceux-ci les d\u00e9couvrent quand il est trop tard.<\/p>\n<h2>P\u00e9rim\u00e8tre<\/h2>\n<p>Comme on peut le voir \u00e0 travers les exemples pr\u00e9c\u00e9dents, il est important d\u2019avoir des objectifs clairs et m\u00eame formalis\u00e9s, afin d\u2019\u00e9viter des cons\u00e9quences inattendues. Notamment parce que ces objectifs vont conditionner la question suivante : r\u00e9ing\u00e9nierie \u00e0 l\u2019\u00e9quivalent, c&rsquo;est-\u00e0-dire avec un m\u00eame p\u00e9rim\u00e8tre fonctionnel, ou avec de nouvelles fonctionnalit\u00e9s ?<\/p>\n<p>Un reengineering est un projet souvent complexe, qui n\u00e9cessite une bonne connaissance de l\u2019application originale et des parties de code plus difficiles \u00e0 lire et \u00e0 comprendre, une bonne expertise de la nouvelle plateforme cible, une estimation pr\u00e9cise de la dette technique afin de proc\u00e9der \u00e0 une \u00e9valuation correcte de l\u2019effort et du planning, un minimum de documentation et si possible, de couverture de tests.<\/p>\n<p>Comme c\u2019est rarement le cas, l\u2019\u00e9quipe de projet va souhaiter limiter les risques en \u00e9vitant d\u2019introduire des nouvelles fonctionnalit\u00e9s dans l\u2019application. Or les utilisateurs vont probablement se montrer tr\u00e8s insistants sur ce point puisque, dans le cas contraire, ils devront non seulement attendre la fin du reengineering mais \u00e9galement le d\u00e9veloppement d\u2019une version suivante qui incorpore ces nouvelles fonctionnalit\u00e9s.<\/p>\n<p>Malheureusement pour l\u2019\u00e9quipe de projet, ce sont souvent les utilisateurs qui auront gain de cause, tout simplement parce qu\u2019il est g\u00e9n\u00e9ralement impossible de r\u00e9\u00e9crire une application sans se heurter \u00e0 des probl\u00e8mes techniques qu\u2019il faudra contourner par de nouveaux processus et\/ou une nouvelle conception des fonctionnalit\u00e9s m\u00e9tier.<\/p>\n<p>Par exemple, si vous modifiez l\u2019interface utilisateur, vous modifiez vraisemblablement les donn\u00e9es disponibles \u00e0 l\u2019\u00e9cran. Combien de fois ai-je vu, lors d&rsquo;un reengineering, de multiples \u00e9crans remplac\u00e9s par un \u00e9cran unique compos\u00e9 de multiples onglets ? Evidemment, il faut alors modifier en cons\u00e9quence les traitements d\u2019acc\u00e8s \u00e0 la couche de donn\u00e9es, ce qui peut provoquer des probl\u00e8mes de temps de r\u00e9ponse. S\u2019il n\u2019est pas possible de r\u00e9gler ceux-ci d\u2019un point de vue technique (avec un upgrade de l\u2019infrastructure technique par exemple), alors vous devez demander aux utilisateurs s\u2019il serait possible de r\u00e9aliser cette op\u00e9ration m\u00e9tier de mani\u00e8re diff\u00e9rente, afin de charger moins de donn\u00e9es dans l\u2019\u00e9cran.<\/p>\n<p>Autre cas \u00e0 prendre en compte : une r\u00e9ing\u00e9nierie ne porte pas que sur le code et les traitements, mais aussi sur les donn\u00e9es. Un nouveau design des classes et des programmes aura pour corollaire les modifications correspondantes en termes de structures de donn\u00e9es.<br \/>\nSi un programme unique attaque une table monstre en base de donn\u00e9es, vous allez souhaitez d\u00e9couper ce programme et cette table en entit\u00e9s de granularit\u00e9 plus petite, pour une meilleure maintenabilit\u00e9 et probablement une performance accrue.<\/p>\n<p>Plus simplement, vous allez profiter de la r\u00e9-\u00e9criture de l\u2019application pour modifier certains types de donn\u00e9es. Parce que l\u2019utilisateur a d\u00e9j\u00e0 demand\u00e9 certaines \u00e9volutions faciles \u00e0 prendre en compte, comme modifier la taille d\u2019un champ ou la pr\u00e9cision de certains chiffres. Ou c\u2019est vous qui allez le trouver pour lui demander s\u2019il a r\u00e9ellement besoin d\u2019un champ de commentaires aussi large alors qu\u2019il n\u2019est pratiquement jamais utilis\u00e9.<\/p>\n<p>Donc, pour votre plan projet de r\u00e9ing\u00e9nierie :<\/p>\n<ul>\n<li>Planifiez bien le re-design des traitements mais \u00e9galement des donn\u00e9es.<\/li>\n<li>Pr\u00e9voyez des modifications au niveau des processus m\u00e9tier.<\/li>\n<li>Associez un ou plusieurs utilisateurs au projet, afin qu\u2019ils soient disponibles pour toute question de processus, de traitements m\u00e9tier ou de r\u00e9ing\u00e9nierie des donn\u00e9es.<\/li>\n<li>N\u2019\u00e9cartez pas toutes les demandes d\u2019\u00e9volution fonctionnelle, mais \u00e9tudiez bien celles qui sont susceptibles d\u2019impacter votre projet ou d\u2019\u00eatre r\u00e9alis\u00e9es facilement au cours de celui-ci.<\/li>\n<\/ul>\n<p>Et surtout, soyez toujours bien conscient des objectifs de votre reengineering.<\/p>\n<p>1. <a href=\"http:\/\/fr.wiktionary.org\/wiki\/t%C3%A9trapilectomie\" target=\"_blank\">T\u00e9trapilectomie<\/a> Coupage de cheveux en 4. N\u00e9ologisme invent\u00e9 par Umberto Eco et son groupe de pataphysiciens. Form\u00e9 du pr\u00e9fixe grec t\u00e9tra- (&lsquo;quatre &lsquo;), du latin pilus (&lsquo;poil, cheveu&rsquo;) et de -ectomie (coupe, inciser).<\/p>\n<p>2. MOM : Message Oriented Middleware. ESB : Enterprise Service Bus. EAI : Enterprise Application Integration. SOA : Service Oriented Architecture. EDA : Event-Driven Architecture.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un reengineering ne signifie pas toujours dans l\u2019esprit de chacun, la r\u00e9\u00e9criture de notre application Legacy dans un autre langage g\u00e9n\u00e9ralement plus r\u00e9cent, mais c\u2019est n\u00e9anmoins l\u2019option que nous avons choisie. Lorsqu\u2019il s\u2019agit \u2018simplement\u2019 de r\u00e9organiser le code afin de rendre celui-ci plus maintenable, mais sans le porter sur une nouvelle plate-forme logicielle ou hardware [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2195","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2195"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=2195"}],"version-history":[{"count":23,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2195\/revisions"}],"predecessor-version":[{"id":2228,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2195\/revisions\/2228"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=2195"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=2195"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=2195"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}