{"partition": "head_middle", "source_domain": "www.slideshare.net", "digest": "sha1:2LWQNVIOPPPOFLHG4LNT6G5ELLBYOSC4", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00025.parquet"}
La migration de Visual Basic 6 vers .NET
Modes économiseurs des systèmes de ...
by ZDNet France
Bandwidth Efficiency Improvement fo...
by Jose Saldana
QoS and Admission Probability Study...
Latitude et longitude
by hg-langlois
Surveillance vidéo : les questions ...
Des tensions à toutes les échelles ...
Plateforme la plus répandue dans l'histoire de Microsoft, Visual Basic 6 a été progressivement supplantée par la nouvelle plateforme, .NET, avant de voir son support cesser courant 2008. Un problème sérieux se pose pour les nombreuses entreprises utilisant des applications sous VB6. La solution la plus simple et la plus adaptée est sans aucun doute la migration de ces applications vers un environnement .NET. C'est l'objet de ce livre blanc que de présenter une métoodologie de migration pensée conjointement par ArtinSoft et Avanade, intégrateur expert de solutions Microsoft.
La migration de Visual Basic 6 vers .NETUn livre blanc par Avanade & ArtinSoft®
Migrations VB6 Table des matières 1. Résumé .......................................................................................................................................................... 3 2. Introduction .................................................................................................................................................... 4 3. Les motifs de renouvellement des applications ............................................................................................... 5 4. Approche et stratégie de renouvellement ........................................................................................................ 7 4.1 Migration, remplacement, réécriture ou pérennisation ............................................................................ 7 4.2 Stratégie de migration ............................................................................................................................ 9 4.2.1 Planification du portefeuille de migration ...................................................................................... 9 4.2.2 Équivalence fonctionnelle et évolution des applications ................................................................ 10 4.2.3 Atteindre l’équivalence fonctionnelle ............................................................................................. 10 4.2.4 Migration des bases de données .................................................................................................. 11 5. Processus de migration des applications ......................................................................................................... 12 5.1 Préparation ............................................................................................................................................ 13 5.1.1 Collecte des informations de contexte .......................................................................................... 14 5.1.2 Analyse préliminaire du code et conclusions .................................................................................. 14 5.1.3 Planification de l’évaluation .......................................................................................................... 14 5.2 Planification de l’évaluation .................................................................................................................... 15 5.2.1 Identification du périmètre de l’évaluation ..................................................................................... 15 5.2.2 Évaluation du code ...................................................................................................................... 16 5.2.3 Entretiens avec les parties prenantes ........................................................................................... 17 5.2.4 Enquête sur le portefeuille de migration ........................................................................................ 16 5.2.5 Approche de renouvellement et séquencement du renouvellement ............................................... 17 5.2.6 Conception de l’approche de test .................................................................................................. 19 5.2.7 Estimation de la charge ................................................................................................................ 19 5.2.8 Planification ................................................................................................................................. 20 5.2.9 Présentation des résultats ............................................................................................................ 21 5.3 Migration ............................................................................................................................................... 22 5.3.1 Préparation de l’environnement de migration ................................................................................ 23 5.3.2 Conception et mise en œuvre de la personnalisation de l’outil ...................................................... 24 5.3.3 Préparation du code à la migration ............................................................................................... 24 5.3.4 Exécution de la migration ............................................................................................................. 25 5.3.5 Résolution des problèmes de migration ........................................................................................ 25 5.3.6 Tests ............................................................................................................................................ 26 6. Conclusion ..................................................................................................................................................... 27 Pour plus d’informations : ............................................................................................................................. 29 © 2011 Avanade Inc. All Rights Reserved.
Migrations VB6 1. Résumé Visual Basic 6 (VB6) a connu un vif succès et a été la plate-forme de développement la plus répandue dans l’histoire de Microsoft. Certaines études indiquent que le nombre de lignes de code VB6 en production pourrait atteindre plusieurs milliards et qu’il y a plus de 3 millions de développeurs VB6 actifs dans le monde. Suite au lancement de .NET en 2002, Microsoft a sensiblement transféré ses investissements vers cette nouvelle plate-forme. Le plan d’évolution de VB6 a été stoppé et Microsoft a annoncé l’abandon progressif de cet environnement de développement en avril 2008. Les organisations qui ont des applications VB6 en production ont commencé à subir différents désagréments, qui ont empiré avec le temps : Des coûts de maintenance élevés en raison de l’inefficacité de l’environnement de développement et de la pénurie de développeurs VB6 compétents ; Un manque de souplesse qui rend difficile le respect de délais de mise sur le marché acceptables ; Les risques associés à l’exécution d’applications sur une plate-forme non prise en charge ; Des performances et une extensibilité limitées. 1 La plupart des organisations qui sont dans cette situation se reconnaîtront dans ce résumé. Selon une étude récente réalisée par Aberdeen Group, elles recherchent des solutions viables pour sortir leurs applications VB6 de l’impasse de l’obsolescence. La migration de ces applications vers .NET est une solution évidente et, dans la plupart des cas, comme le montre aussi cette étude, cette migration apporte des avantages concrets et permet diverses économies : délai de mise sur le marché, coûts de développement et performances. Cependant, beaucoup d’organisations repoussent indéfiniment la décision de migration en raison de son coût élevé et des risques de perturbations de l’activité. Afin de proposer des solutions à la situation que nous venons de décrire, Avanade et ArtinSoft ont élaboré ensemble une méthodologie de migration. Elle s’appuie sur les technologies développées par ArtinSoft et sur l’expérience acquise par les deux entreprises sur des projets concrets de migration. Elle est conçue pour prendre en charge l’ensemble du cycle de migration VB6, depuis la définition initiale du périmètre et l’évaluation du portefeuille, jusqu’à la migration en elle-même. Elle ne se limite pas aux aspects techniques de la transformation mécanique du code VB6 vers .NET. Elle couvre également le processus plus général qui intègre toutes les exigences, les objectifs et les contraintes applicables afin de garantir que la solution est conforme aux enjeux de l’entreprise et maximise les bénéfices. Le reste du présent document expose en détail le processus complet de migration vers .NET et en couvre de très nombreux aspects. Bien que ce document puisse être lu du début à la fin, certaines sections s’adressent plutôt à des publics spécifiques : Les sections d’introduction (1, 2 et 3) décrivent les situations récurrentes rencontrées dans des scénarios réels de migration de VB6. Elles exposent en particulier les motifs de la migration, les alternatives au renouvellement à envisager et le business case. Elles comprennent également une description générale du cadre utilisé pour déterminer la meilleure approche de renouvellement, avec une focalisation spécifique sur les solutions qui permettent de sécuriser la migration et de la rendre plus rentable. Ces sections s’adressent plutôt à des décideurs qui souhaitent comprendre les options de renouvellement disponibles et leurs conséquences respectives. La section 4 donne une description détaillée de notre méthodologie de migration. Elle est structurée en fonction des jalons principaux et des activités essentielles d’un cycle de migration VB6 classique : préparation, évaluation et migration. Les phases de préparation et d’évaluation sont conçues de manière à anticiper les éventuels problèmes liés à la migration et à minimiser les coûts et les risques associés. La phase de migration est un processus itératif conçu pour assurer une transition aisée des applications VB6 vers .NET. 1 « Migrating from VB6 to .NET: the Challenge of Software Agility in a Volatile Economy » – Aberdeen Group © 2011 Avanade Inc. All Rights Reserved. 3
Migrations VB6 Cette méthodologie est le résultat de l’expérience acquise sur les nombreux projets de migration menés à bien par Avanade et ArtinSoft. Cette section s’adresse aux DSI et aux responsables du développement intéressés par les détails du processus de renouvellement. Les sections 5 et 6 résument nos réflexions et expériences et décrivent comment Avanade et ArtinSoft peuvent aider les clients à sortir leurs applications VB6 de l’obsolescence de la manière la plus économique possible. Avanade et ArtinSoft interviennent actuellement auprès de nombreux clients pour les aider dans leur passage de VB6 à .NET. Nous faisons en permanence évoluer notre méthodologie et nos actifs de manière à améliorer les performances et les résultats de nos travaux de renouvellement de VB6. Bien que chacun de ces scénarios de renouvellement ait ses propres spécificités, Avanade et ArtinSoft peuvent vous apporter leur expérience et vous aider. L’étude d’Aberdeen Group montre en effet que les entreprises qui s’appuient sur des prestataires expérimentés tirent plus de bénéfices de leur migration VB6 (80 % contre 42 %). 2. Introduction Personne ne niera que l’alignement des systèmes informatiques sur les besoins métier a toujours été une priorité des DSI et des directeurs informatiques. Cette obligation se fait plus forte aujourd’hui en raison de la réduction permanente des budgets informatiques et des exigences de délai de mise sur le marché de plus en plus ambitieuses imposées par l’environnement économique actuel. Dans ce contexte, les coûts de maintenance des applications métier vitales représentent une part importante des dépenses. Mais le prix à payer pour l’incapacité à faire évoluer ou à maintenir ces applications au rythme imposé par le métier est encore plus élevé. Ceci est particulièrement vrai pour les systèmes anciens. En effet, en raison , entre autres, de l’absence d’outils de développement et de gestion à forte productivité, du coût et de la difficulté de recrutement des ressources compétentes et du manque de support de la part des fournisseurs, la charge de travail liée à leur exploitation a augmenté. Ces coûts sont difficiles à justifier et à supporter dans le contexte actuel. Selon l’étude d’Aberdeen Group, cette préoccupation est partagée par les entreprises qui utilisent des applications Visual Basic 6 (VB6) et qui veulent les sortir de l’obsolescence. VB6 a été le langage de programmation de Microsoft qui a connu le plus grand succès, en grande partie en raison de l’abondance de ressources compétences et de la richesse de l’environnement de développement. Les applications VB6 sont très faciles à créer et à distribuer. C’est pourquoi on les trouve partout. Selon des études récentes, neuf ans après l’abandon de VB6 par Microsoft, plus de 50 % des entreprises dans le monde l’utilisent encore dans des aspects essentiels de leur activité. Ce livre blanc décrit le processus de renouvellement de VB6 selon Avanade et ArtinSoft. Il synthétise l’expérience issue d’un grand nombre de projets menés à bien pour des entreprises dans de nombreuses régions et des secteurs très variés. Le processus de renouvellement ne couvre pas uniquement le mécanisme de transformation du code VB6 en .NET. Il comprend aussi une approche structurée qui aide les organisations à optimiser les bénéfices du transfert de leurs anciennes plates-formes vers des technologies modernes : Minimisation des perturbations liées au renouvellement ; Définition de la meilleure approche de renouvellement en fonction de la situation actuelle et du plan d’évolution du système en question ; Anticipation des problèmes liés au processus de migration et établissement du plan de mitigation ; Estimation précise des coûts, de la charge et de la durée ; Présentation de l’approche de modernisation la plus rentable et la moins coûteuse. © 2011 Avanade Inc. All Rights Reserved. 4
Migrations VB6 L’expérience d’Avanade et d’ArtinSoft a été mise à l’épreuve dans des scénarios très variés, depuis les plus petites applications autonomes jusqu’au renouvellement de portefeuilles complets d’applications d’entreprise. Ce processus est suffisamment souple pour s’adapter à la migration d’applications monolithiques, multi-tiers ou d’applications Web ASP. Cependant, pour des raisons de simplification, nous ferons référence à la source sous le terme de « VB6 » dans tout le reste de ce document. 3. Les motifs de renouvellement des applications Les motifs de la modernisation des applications VB6 sont multiples et la plupart d’entre eux s’applique à tous les renouvellements d’applications. Ils vont de considérations tactiques liées à l’obligation de réagir à l’évolution des besoins métier, jusqu’à des objectifs plus stratégiques qui exigent l’introduction de changements radicaux dans le cadre du processus de renouvellement. Parmi les motifs de renouvellement les plus fréquents rencontrés sur nos projets (et confirmés par l’étude d’Aberdeen Group), on peut citer : Des raisons tactiques : o Minimiser le délai de mise sur le marché ; o Assurer le respect des normes et standards et la conformité avec les plates-formes prises en charge, et donc éliminer le risque lié à l’exécution d’applications sur des plates-formes non supportées ; o Réduire les coûts d’exploitation et de maintenance ; o Atténuer le risque lié au manque de ressources compétentes en VB6 ; o Améliorer la conformité de la solution existante aux exigences techniques et fonctionnelles. Stratégiques o Consolider et standardiser les technologies sur lesquelles s’appuient les actifs logiciels ; o Rationaliser le processus de développement ; o Faciliter et simplifier l’intégration effective avec les technologies SOA et les diverses normes du secteur ; o Simplifier le déploiement ; o Améliorer la fiabilité et l’extensibilité ; o Augmenter la productivité des développeurs ; o Améliorer la sécurité. Dans cette méthodologie, la phase d’évaluation comprend un aspect important de compréhension de la pertinence des motifs du renouvellement pour l’entreprise concernée. Cette compréhension est déterminante dans l’identification d’une stratégie de renouvellement optimale en fonction des besoins de l’organisation et d’une approche assurant la mise en valeur des bénéfices de la migration. Notre expérience des programmes de renouvellement de grande ou moyenne ampleur nous montre que la transition d’un portefeuille d’applications de VB6 vers .NET est complexe, mais que l’application d’une méthodologie adaptée et une planification anticipée permettent d’en assurer la faisabilité et de répondre aux motifs exprimés ci-avant, avec un niveau de coût et de risque minimaux. Les études statistiques réalisées dans le cadre de l’étude d’Aberdeen Group et les retours de nos clients encouragent à la migration de VB6 vers .NET pour de multiples raisons : Délai de mise sur le marché : L’adoption d’un environnement de développement très efficace et la simplification de l’intégration avec des technologies standard ont dans certains cas permis une réduction de 50 % du délai de mise en œuvre de nouvelles fonctionnalités. © 2011 Avanade Inc. All Rights Reserved. 5
Migrations VB6 Coûts de développement : La meilleure disponibilité de ressources compétentes et motivées, associée à une amélioration de la gestion du cycle de vie des applications que facilite des outils tels que Visual Studio Team System, a permis des économies sur les coûts de développement et de programmation pouvant atteindre 20 %. Performance : Le passage à .NET peut être source d’une amélioration de la performance des solutions migrées pouvant atteindre 40%, ce qui permet de réduire les coûts d’exploitation et les interruptions de service. Sécurité : Grâce à des fonctions complètes de sécurité, .NET améliore la sécurité de la solution migrée sans alourdir la tâche des développeurs. Déploiement : Avant le lancement de .NET, le déploiement d’applications clientes exigeait souvent d’utilisation de privilèges élevés dans le système, ce qui mettait en péril sa stabilité et sa sécurité. Avec .NET, le déploiement peut être effectué de manière plus isolée, ce qui simplifie considérablement le processus et réduit les coûts d’assistance à long terme. Une autre conclusion intéressante de l’étude d’Aberdeen Group est le fait que les bénéfices de la migration sont quasiment doubles si l’organisation décide d’avoir recours à l’expérience de prestataires externes pour une assistance ou une prise en charge complète de la migration (80 % contre 42 %). Avanade et ArtinSoft sont déjà investi des dizaines de millions d’euros dans la conception d’une technologie de migration efficace en affinant leur méthodologie et en développant les compétences de plusieurs centaines de personnes. Pour de nombreuses organisations, il est plus logique d’exploiter ce capital de connaissances que d’entreprendre son développement ex-nihilo. La priorité stratégique est généralement la focalisation des ressources sur le développement de compétences nécessaires à la plate-forme cible, plutôt que la migration en elle-même, qui constitue un effort ponctuel. Comme nous allons le montrer dans la section qui suit, une autre approche consiste à laisser les applications VB6 en l’état, cette approche n’étant pas dépourvue de risques. Pour beaucoup d’organisations, l’infrastructure applicative et logicielle sur laquelle s’appuie l’activité métier est un patchwork d’applications comprenant des systèmes vieillissants qui ne sont plus pris en charge par aucun fournisseur, ni par les équipes internes. La valeur métier inhérente à la plupart des anciens systèmes est parfois discutable car les entreprises ont consacré beaucoup d’énergie aux travaux liés à la conformité et ont repoussé indéfiniment les projets de modernisation de l’informatique, en négligeant leur importance à long terme. Les organisations les plus visionnaires savent qu’un système informatique robuste, moderne et extensible est une base indispensable pour répondre aux besoins métier de manière efficace et réactive. Aujourd’hui, il est à la fois possible et urgent de se libérer des contraintes des anciens systèmes informatiques en migrant vers une plate-forme moderne. Dans le cas particulier de VB6, le maintien en production des systèmes basés sur cette technologie représente de multiples risques. 1. Absence de support à l’environnement de développement : L’environnement de développement intégré (IDE) de VB6 2 n’est actuellement plus suivi en majeur par Microsoft. Bien que Microsoft se soit engagé à « le faire fonctionner » (du moins jusqu’à Windows 7), l’éditeur ne traitera plus les anomalies. De plus, Microsoft n’a pris aucun engagement explicite sur la compatibilité entre l’IDE de VB6, ou l’environnement d’exécution associé, et les versions futures de Windows. 2 Déclaration sur la prise en charge de VB6 sur Windows Vista, Windows Server 2008 et Windows 7 http://msdn.microsoft.com/en- us/vbrun/ms788708.aspx © 2011 Avanade Inc. All Rights Reserved. 6
Migrations VB6 2. Composants tiers : Bien que Microsoft assure encore le support de l’environnement d’exécution de VB6, ce n’est pas forcément le cas des fournisseurs de composants. La plupart des applications VB6 contiennent des composants fournis par des tiers, et, à mesure que leurs fournisseurs transfèrent leurs ressources vers des composants .NET, le niveau de support et de compatibilité diminue. 3. Conformité réglementaire : La loi Sarbanes-Oxley aux États-Unis, et les réglementations similaires comprennent des règles implicites sur la question de l’exécution de systèmes sur des plates-formes non prises en charge par leur fournisseur. VB6 est, au mieux, sur la limite dans ce domaine, voire en passe d’être exclus. 4. Compatibilité 64-bit : L’environnement d’exécution Visual Basic a été conçu pour des systèmes 32-bit et Microsoft est déjà en train de retirer progressivement ses systèmes d’exploitation 32-bit du marché. Par exemple, l’exécution d’applications 32-bit sur Windows Server 2008 R2 n’est pas l’option par défaut. 4. Approche et stratégie de renouvellement Cette section décrit les différentes options de renouvellement généralement envisagées pour un portefeuille d’applications existantes, ainsi que les aspects évalués pour prendre la meilleure décision en termes de stratégie et d’approche de renouvellement. 4.1 Migration, remplacement, réécriture ou pérennisation Une fois qu’il a été décidé qu’un portefeuille d’applications ne répond plus aux besoins métier, et que l’entreprise a compris que l’inaction n’était pas envisageable, l’étape suivante est l’évaluation des applications et la décision de son éventuelle modernisation. Il est généralement préférable de prendre cette décision application par application, et d’analyser ainsi tout le portefeuille. Dans le cas d’une application indispensable à l’activité, il y a quatre possibilités de modernisation : La migration : L’utilisation d’un outil semi-automatique tel que Visual Basic Upgrade Companion™ (également appelé VBUC™) d’ArtinSoft permet d’assurer l’équivalence fonctionnelle, ce qui est la première étape de l’effort de modernisation. Les avantages de cette approche sont liés à l’exploitation des investissements antérieurs (en particulier, s’il existe des règles métier importantes mais mal documentées) et à la réduction du risque dans le processus de modernisation. Le remplacement : Il s’agit de la recherche d’une application commercialisée sur le marché et à même de remplacer la fonctionnalité métier. L’organisation doit dans ce cas être prête à accepter des changements dans ses processus pour s’adapter à l’application choisie. En retour, elle bénéficiera d’une approche fonctionnelle élaborée par des spécialistes. La réécriture, ou tout recommencer ex-nihilo. La réécriture d’une application couvre l’ensemble du cycle de vie, depuis l’expression des besoins jusqu’à la formation des utilisateurs et au déploiement. L’avantage de cette approche est que l’organisation peut intégrer de nombreuses modifications, depuis les règles métier jusqu’à l’architecture technique de l’application. Mais c’est aussi l’option la plus coûteuse et la plus risquée. Ce choix est souvent la cause d’une explosion du périmètre, des budgets et des délais. La pérennisation. C’est aussi le choix de « ne rien faire », ou l’option par défaut. Il n’y a pas d’investissement immédiat, mais à long terme, les risques d’obsolescence et le coût potentiel d’une décision augmentent. Il convient de se poser un certain nombre de questions afin d’évaluer chaque application et de décider du meilleur choix de modernisation : Dans quelle mesure les fonctionnalités de l’application sont-elles uniques dans ce métier ? Existe-t-il un logiciel tiers disposant de fonctionnalités comparables ? Par exemple, si l’entreprise utilise une application de comptabilité générale qui ne présente pas caractéristiques spécifiques à son métier, ou une application banale qui ne lui apporte pas d’avantage concurrentiel particulier, alors la décision d’acheter un progiciel du commerce doit être envisagée. © 2011 Avanade Inc. All Rights Reserved. 7
Migrations VB6 Toutefois, si l’application est source d’un avantage concurrentiel, il y a des chances qu’elle soit unique et qu’elle contienne une logique spécialisée qui devrait être migrée. Quelle est la qualité technique de l’application ? Quel est le nombre moyen d’anomalies qui ont dû être réparées au cours des derniers mois ? Quelle est la fiabilité des résultats produits par l’application ? L’application est-elle extensible, ou quel est l’investissement nécessaire pour la rendre plus extensible ? L’application est-elle facilement maintenable? Si les réponses aux questions ci-dessus sont négatives, alors la migration de l’application vers un nouveau langage avec une approche semi- automatique n’est probablement pas la meilleure approche, et il serait préférable d’envisager plutôt une réécriture. Dans le cas contraire, l’entreprise doit envisager une migration pour pouvoir profiter de tous les avantages liés à une plate-forme de développement logiciel moderne. Les fonctionnalités de l’application changent-elles rapidement avec les objectifs métier ? Le processus métier auquel s’adresse l’application est-il stabilisé ? Le service informatique ne prévoit-il que des changements très mineurs avant la mise hors service ? Qu’en est-il des erreurs générées, du nombre de solutions de contournement, du niveau d’assistance nécessaire ? Si l’application est très stable et qu’elle ne changera pas beaucoup dans un futur proche, alors l’entreprise 3 devrait se contenter de la laisser en l’état et d’absorber le coût d’assistance. Toutefois, si l’application exige des améliorations et des adaptations continues, alors la migration est le bon choix pour minimiser le délai de mise sur le marché. En résumé, si une application fournit à l’organisation un avantage concurrentiel, si elle est de bonne qualité technique est si elle est à même de relever les nouveaux défis du métier, alors elle constitue un bon candidat pour le type d’approche de modernisation que proposent Avanade et ArtinSoft. Pour les applications qui présentent les caractéristiques ci-dessus, il y a de nombreuses raisons qui font que la migration est le meilleur de choix (par rapport aux autres) : Le coût : Les comparaisons de coût peuvent être analysées selon deux axes :  Le coût du processus de migration : Une migration automatique à équivalence fonctionnelle peut être réalisée à environ 20 % du coût d’une réécriture. L’essentiel de ce coût est consacré aux tests, et aux adaptations de l’application à la nouvelle plate-forme (voir la figure 1), alors que les phases d’analyse, de conception et de construction sont largement simplifiées.  La formation des utilisateurs finaux : À l’issue de travaux de réécriture, l’application résultante dispose généralement de 4 fonctionnalités améliorées. Dans ce cas, il est souvent nécessaire de mener un effort important de formation des utilisateurs pour minimiser la perte de productivité. Après une migration semi-automatique, en revanche, le besoin en formation supplémentaire est très réduit en raison de l’équivalence fonctionnelle. Le délai : Une migration automatique est réalisée en environ 20 % du temps nécessaire à une réécriture. Cela signifie que les ressources peuvent être libérées plus rapidement et utilisées pour développer de nouvelles fonctionnalités, au lieu de tenter de recopier celles qui existent déjà. Les risques : Si les critères d’identification d’un candidat à la migration décrits plus haut dans cette section sont satisfaits, les applications issues d’une migration automatique seront de bonne qualité et prêtes pour des évolutions ultérieures. Elles seront par exemple préparées aux travaux de réingénierie nécessaires pour aligner l’application sur une architecture cible différente, ou pour intégrer des besoins complémentaires à des portions de code sélectionnées. Au contraire, si toutes ces activités sont réalisées simultanément, les dépassements de périmètre sont probables et le coût du projet risque d’exploser. 3 Il faut noter ici que dans certains secteurs, les organisations peuvent avoir à migrer de toute façon pour se conformer à des réglementations qui imposent que les applications tournent sur les plates-formes prises en charge. 4 Pour les systèmes complexes, les coûts de formation peuvent être considérables, et parfois dépasser l’équivalent d’un mois de travail des utilisateurs finaux. © 2011 Avanade Inc. All Rights Reserved. 8
Migrations VB6 Le schéma ci-dessous montre l’effort d’une migration par rapport à celui d’une réécriture. 4.2 Stratégie de migration La stratégie de migration devrait être abordée à deux niveaux différents. Le premier est Test l’évaluation exhaustive de la migration complète du portefeuille d’applications. Le second niveau Construction porte sur chaque application du portefeuille. Ce livre blanc se concentre sur le niveau des Conception applications, mais, en règle générale, il est Analyse recommandé d’avoir aussi une perspective sur le portefeuille, et de replacer la migration dans le contexte de votre stratégie informatique générale. 4.2.1 Planification du portefeuille de migration La première tâche de l’évaluation d’un portefeuille d’applications en vue de son Migration Réécriture renouvellement est l’élaboration d’un Figure 1 : Répartition inventaire des applications. de l’effort Lors de cet inventaire, il est aussi important de recueillir des informations détaillées sur les relations et les dépendances entre les composants appartenant à des applications différentes (par exemple, si un composant est utilisé dans plusieurs applications ou si une application a des interfaces avec une autre). Ces relations affecteront le choix du meilleur ordre de migration. L’étape d’inventaire est particulièrement critique pour les applications VB6 en raison de la façon dont ces applications se sont développées dans beaucoup d’organisations. La planification d’une migration est une bonne occasion de ramener toutes les applications différentes (dont certaines sont essentielles) sous un même toit. Cela justifie un effort supplémentaire d’élaboration d’un catalogue général, comprenant aussi les applications qui n’ont jamais été correctement décrites. La durée de cette activité va de quelques jours à une ou deux semaines. Elle dépend de plusieurs facteurs, dont la complexité du portefeuille et les standards de gestion de configuration utilisés. Une fois l’inventaire des applications terminé, l’étape suivante est l’identification de leur position dans le cycle de vie des applications. Il est important pour justifier quelles sont les applications qui méritent une migration et quelles sont celles qui devront être mises hors service, et ne devraient donc pas être intégrées au projet. © 2011 Avanade Inc. All Rights Reserved. 9
Migrations VB6 Une fois que toutes les applications qui exigent une migration ont été identifiées, avec leurs dépendances, alors les plans de migration individuels peuvent être élaborés. 4.2.2 Équivalence fonctionnelle et évolution des applications Le processus de migration d’une application selon la méthodologie de semi-automatique doit comprendre deux étapes clairement définies : l’équivalence fonctionnelle et l’évolution de l’application. L’équivalence fonctionnelle exige de migrer une application vers la nouvelle technologie en conservant exactement les mêmes fonctionnalités. Une fois l’équivalence fonctionnelle atteinte, le processus de migration est terminé et l’application tourne sur la nouvelle plate-forme. Les fonctionnalités ont été testées et leur équivalence a été vérifiée. L’application peut être déployée auprès des utilisateurs qui remarqueront à peine la différence. Le fait de viser l’équivalence fonctionnelle pour une application que vous avez l’intention de modifier ensuite peut sembler paradoxal au premier abord, mais notre expérience nous a montré que cela permet de disposer d’une base solide pour une approche contrôlée et de réduire le niveau de risque. Différents facteurs contribuent à rendre la transition à équivalence fonctionnelle attirante, le principal étant l’idée de remettre de l’ordre dans les systèmes le plus tôt possible. Le délai et le coût correspondant d’une réécriture totale de l’application rendent souvent impossible l’élaboration d’un business case de renouvellement viable. Par conséquent, la décision d’abandonner l’ancienne technologie est remise à plus tard. Avec des systèmes développés au fil des ans, il faut souvent du temps aux développeurs pour comprendre les subtilités de l’application et les reproduire sur une plate-forme différente. De plus, le risque d’explosion du périmètre est important. En outre, il y a des avantages à adopter une approche par étape, en migrant d’abord l’application automatiquement vers .NET à équivalence fonctionnelle parfaite. D’un point de vue opérationnel, .NET simplifie de façon très importante le déploiement et améliore les performances générales, l’extensibilité et la fiabilité. Du point de vue du développement, il y a une amélioration très nette de l’ensemble de la solution et de son cycle de vie, avec des outils plus pratiques de gestion de configuration, une automatisation de la construction, des tests, de l’analyse et de la refactorisation, etc. De plus, certaines organisations sont dans l’obligation de migrer vers .NET. C’est le cas des éditeurs indépendants qui ont de plus en plus de mal à vendre des logiciels basés sur VB6, ou encore, des sociétés soumises à des réglementations strictes qui imposent que toutes les applications essentielles fonctionnent sur des plates- formes prises en charge. Une fois l’équivalence fonctionnelle atteinte, l’application est prête pour sa prochaine refonte ou son évolution applicative. Si une application est migrée, c’est parce qu’elle est encore au début de son cycle de vie et fournira des années de service au métier. Il est donc probable qu’elle va évoluer encore après la migration, même si ce n’est pas nécessairement immédiat. L’évolution d’une application implique à la fois l’intégration de nouvelles fonctionnalités et la modification/prolongation des parties de l’application aptes à bénéficier des nombreuses améliorations que .NET offre. 4.2.3 Atteindre l’équivalence fonctionnelle L’équivalence fonctionnelle pour une application donnée peut passer par une migration complète ou progressive. Avec une stratégie de migration complète, l’organisation met à niveau toutes ses applications en même temps et ne met pas de code en production tant que l’application complète n’est pas migrée et opérationnelle sur la nouvelle plate-forme. La stratégie de migration progressive permet la mise à niveau de certaines parties de l’application avant d’autres. © 2011 Avanade Inc. All Rights Reserved. 10
Migrations VB6 Le deuxième choix comporte moins de risques, mais il exige plus de travail pour permettre l’interopérabilité entre les parties 5 migrées et non-migrées de l’application durant les étapes intermédiaires. Avec une migration complète, tous les composants d’une application sont migrés et déployés ensemble. Cela ne signifie pas qu’elles sont migrées en parallèle. Cela signifie uniquement qu’il n’y a pas d’effort de déploiement de l’application en production tant que tous ses composants n’ont pas été transférés sur .NET. Pour les applications qui ne s’appuient pas sur des technologies obsolètes et qui sont de taille raisonnable, une migration complète peut être rapide. C’est souvent le meilleur choix parce qu’il permet d’apporter des évolutions plus tôt et à un coût plus faible. La stratégie de migration progressive permet cependant une mise à niveau plus contrôlée et graduelle. Les applications sont migrées partie par partie, ou composant par composant. Chaque composant récemment mis à niveau peut être déployé tel que migré, au lieu d’attendre la fin de la migration de l’application complète. Cette stratégie n’est possible que si l’application 6 actuelle est constituée de multiples composants distincts, clairement decouplés et développés dans le cadre de projets séparés. Une migration progressive est un compromis raisonnable à une migration complète. C’est, selon toute probabilité, le meilleur choix pour les applications anciennes de grande échelle, composées de sous-systèmes modulaires, avec un fort degré de réutilisation. Les migrations progressives peuvent être verticales ou horizontales : Migration verticale : Elle implique l’isolation et la migration de toutes les couches d’un même module d’une application, sans modifier les autres parties de l’application. Plus concrètement, une tranche de l’application qui a peu d’interaction avec les autres tranches est extraite et migrée de manière indépendante du reste de l’application. La tranche choisie doit être détachée du reste de l’application à chaque couche. Migration horizontale : Il s’agit de migration une couche complète d’une application sans modifier les autres couches. En mettant à niveau une seule couche à la fois, l’équipe de migration peut profiter des caractéristiques spécifiques que le framework .NET fournit à cette couche-là, souvent sans modifier le code de l’application ni affecter le fonctionnement des autres couches de l’application. C’est l’architecture de l’application qui détermine le choix entre une approche horizontale ou verticale en cas de migration progressive. Les architectes de l’équipe doivent être fortement impliqués dans le choix de ces stratégies. Chacune présente des avantages et des inconvénients selon l’application concernée. La prise de décision exige généralement une évaluation de la conception et de la mise en œuvre de l’application. 4.2.4 Migration des bases de données La migration des bases de données présente un autre aspect généralement indispensable dans le renouvellement des applications VB6 car celles-ci incluent, dans la plupart des cas, des composants d’accès aux données conçus pour stocker et extraire des données dans des bases de données relationnelles. Parfois, le SGDB utilisé par les applications actuelles fait aussi partie du problème, soit parce qu’il est considéré obsolète également, soit parce qu’il et incapable de répondre aux futurs objectifs de performance, soit les deux. Dans de tels scénarios, le périmètre de l’effort de renouvellement doit inclure la migration de la base de données actuelle vers un SGBD différent et l’adaptation de l’application à ce changement, en particulier pour en exploiter au mieux les avantages. 5 Il ne faut pas confondre la migration progressive avec la migration partielle, dans laquelle seules certaines portions d’une application VB6 sont migrées vers .NET, alors que d’autres restent sous VB6. 6 Des techniques d’interopérabilité doivent être mise en œuvre afin d’assurer le fonctionnement conjoint des composants migrés et non migrés. © 2011 Avanade Inc. All Rights Reserved. 11
Migrations VB6 Sur la base de leur expérience, Avanade et ArtinSoft recommandent dans ces scénarios d’éviter de traiter la migration des applications et la migration des données en même temps. Une migration conjointe rend les tests plus complexes, présente des risques supplémentaires de perturbation des opérations courantes et accroit les difficultés techniques en cas d’obligation de retour en arrière. Il est préférable d’exécuter la migration des bases de données une fois que les applications VB6 sont migrées vers .NET. 5. Processus de migration des applications Un effort de migration doit viser plusieurs objectifs. Ces objectifs sont liés aux critères utilisés dans la plupart des cas pour mesurer le succès d’un projet de migration : Réalignement sur les programmes informatiques en cours et à venir ; Réalignement avec le plan d’évolution métier ; Minimisation des risques et des perturbations ; Minimisation des coûts ; Minimisation de la durée. Préparer Evaluer Migrer Au vu des critères énumérés ci-dessus, il est Planifier Analyser Concevoir Construire Tester Déployer Gérer clair qu’une migration ne sera considérée réussie Déploiement en Infrastructure Motifs de la Architecture Stratégie de Adaptation Opérations qu’à l’issue de la mise en environnement de de migration du système migration des outils métier œuvre correcte d’un tests du système configuration processus qui couvre différents aspects, et pas Plan Fonctionnalités Ordre de Préparation Exécution des Préparation de Gestion des tests système l’appli. Au uniquement après la simple d’évolution de l’application migration du code finaux services déploiement transformation du système actuel en un autre système Résolution Délai Processus de Stratégie Déploiement Fourniture présentant des capacités prévu test existants Pré-migration des d’intégration en production des services similaires. anomalies Approche de Portage du Exécution des Transition Dépendances Gestion de la Périmètre test cible code tests système vers l’appli. externes qualité finaux déployée Carte des Analyse des Exécution Problème de Période de Gestion des points rapports de des tests de migration gel du plan environnements sensibles mise à niveau recette Correction du Support à © 2011 Avanade Inc. All Rights Reserved. 12 code l’environnement Figure 2 : Processus de migration
Migrations VB6 Bien que chaque scénario réel ait ses besoins et contraintes spécifiques, l’expérience accumulée par Avanade et ArtinSoft au fil des projets montre qu’un processus optimal comprend un certain nombre d’activités principales pour chaque étape de la migration. La figure 2 décrit la mise en œuvre classique d’un effort de migration au fil des différentes étapes du cycle de vie du projet, sur la base de la méthodologie de réalisation d’Avanade, Avanade Connected Methods (ACM). Ce schéma est fourni uniquement à titre de référence. Une explication détaillée de toutes les activités impliquées sortirait du cadre du présent document. Le reste de ce chapitre donne une description simplifiée des étapes de haut niveau d’un projet typique de renouvellement d’application. Préparer Évaluer Migrer Plus précisément, les sections qui suivent donnent une description de haut niveau des activités principales exécutées à chaque étape, avec une focalisation spécifique sur l’approche de migration semi-automatisée basée sur VBUC™ (voir la section 4.1 - Migration, remplacement, réécriture ou pérennisation). 5.1 Préparation Les objectifs de la phase de préparation sont doubles : 1. Acquérir une connaissance préliminaire des motifs fonctionnels et techniques du renouvellement du portefeuille d’applications visé ; 2. Comprendre les attentes de l’organisation vis-à-vis du renouvellement lui-même. Elle comprend les activités listées ci-dessous : Collecte des informations de contexte ; Analyse préliminaire du code et conclusions ; Planification de l’évaluation. © 2011 Avanade Inc. All Rights Reserved. 13
Migrations VB6 5.1.1 Collecte des informations de contexte Il est essentiel de disposer d’une compréhension claire des raisons pour lesquelles une organisation prévoit un programme de renouvellement. Ces informations aident à définir la meilleure stratégie de renouvellement et à planifier l’approche d’évaluation la plus efficace, et donc à collecter toutes les données pertinentes à une prise de décision informée. La première question à poser au début du processus de migration est évidemment : « Pourquoi ? » La compréhension des raisons de la migration exige la compréhension des facteurs qui imposent le programme de renouvellement. Ils appartiennent d’ordinaire à deux catégories générales : Métier : Par exemple, changement considérable des conditions du marché, conformité à de nouvelles réglementations, meilleure adéquation avec la vision à long terme de l’organisation, etc. Technologie : Par exemple, absence de support, ou coût de support trop élevé, réduction du coût total de possession (TCO), consolidation dans le cadre d’une fusion/acquisition, etc. Un autre aspect à envisager dès le début est l’ensemble des attentes de l’organisation vis-à-vis du programme de renouvellement et les contraintes qui s’appliquent au scénario considéré. La liste non exhaustive qui suit indique certains des éléments à considérer : Approche de migration préférentielle : Elle est d’ordinaire déterminée suite à une évaluation détaillée, mais il peut exister des contraintes et des situations à prendre en compte. Langage et/ou plate-forme cible : Par exemple, choix du langage vers lequel faire migrer l’application (VB .NET ou C#, etc.). Délai : Contraintes sur la durée et sur le calendrier de l’effort de renouvellement en vue de minimiser l’impact sur les activités actuelles ou planifiées. Besoins supplémentaires : Les attentes vis-à-vis d’un effort de migration ne sont pas limitées à l’équivalence fonctionnelle. Elles incluent aussi des besoins complémentaires (fonctionnels ou non). Périmètre : L’ensemble des applications concernées par le programme de renouvellement doit être défini, car c’est sur cet ensemble que sera menée l’évaluation. Outre la connaissance de la liste des applications à migrer, il est aussi nécessaire de prendre en compte toute contrainte ou alternative possible en termes de périmètre de la migration (par exemple, la migration partielle d’une application est-elle envisageable ?) 5.1.2 Analyse préliminaire du code et conclusions Bien qu’une évaluation formelle du code soit prévue plus tard dans le processus, quelques indicateurs de haut niveau liés aux applications incluses dans le périmètre peuvent être recueillis avec une charge de travail limitée. Il est préférable ne pas tirer de conclusions trop hâtives des indicateurs sur le code disponibles à ce moment-là. Cependant, ils peuvent aider à estimer le délai nécessaire pour réaliser une évaluation plus précise. Parfois, ils peuvent même fournir les données nécessaires à une estimation grossière de l’effort de migration complet. 5.1.3 Planification de l’évaluation La phase de préparation est normalement suivie de l’évaluation. L’évaluation détaillée est un projet en elle-même. Il est donc nécessaire d’élaborer un plan de travail. Celui-ci doit être partagé afin de confirmer que les attentes sont prises en compte. Il doit aussi exposer clairement certains points : © 2011 Avanade Inc. All Rights Reserved. 14
Migrations VB6 Les activités couvertes par l’évaluation ; La participation des parties prenantes à chaque étape ; L’estimation de la charge de travail des activités planifiées ; Les hypothèses émises sur les exigences et nécessaires à l’exécution de l’évaluation. 5.2 Planification de l’évaluation La réussite du renouvellement d’un grand portefeuille d’applications dépend de plusieurs facteurs : L’approche de renouvellement choisie pour chaque application ; Le mode de réalisation (onshore/nearshore/offshore/multi-sites) ; Le calendrier et le séquencement des activités ; La stratégie de gestion des versions (progressive ou complète). D’un point de vue métier comme technique, la variété des choix possibles et les conséquences potentielles de chacun impose une évaluation précise avant le lancement de toute activité de renouvellement sur le portefeuille d’applications actuel. L’objectif principal d’une évaluation est de générer une stratégie détaillée de renouvellement. Cette stratégie doit esquisser le déroulement optimal de la transition, avec une indication claire des processus, des outils et des compétences nécessaires à chaque étape. Elle doit aussi donner une estimation précise du coût, de la charge de travail et de la durée. Une évaluation complète implique à la fois une analyse statique de la base de code lié aux applications visées par le renouvellement, et l’étude d’informations supplémentaires obtenues au travers d’entretiens et d’enquêtes. Les étapes qui suivent donnent un bon aperçu du contenu d’une évaluation : Identification du périmètre de l’évaluation ; Évaluation du code ; Entretiens avec les parties prenantes ; Enquête sur le portefeuille d’applications ; Approche et séquencement du renouvellement ; Estimation de la charge de travail ; Planification ; Présentation des résultats. 5.2.1 Identification du périmètre de l’évaluation Un aspect essentiel dès le départ est la définition du périmètre exact de l’évaluation. Elle implique l’énumération des applications (et des composants correspondants) visées par la migration et la collecte de l’ensemble des fichiers de code source associés. À première vue, cela peut sembler une activité mineure, mais elle est parfois très consommatrice de temps et sujette à erreurs. Il est recommandé d’y impliquer des ressources expérimentées et d’utiliser des outils à même d’automatiser certaines étapes. Ceci réduira la durée de l’activité et les risques associés. © 2011 Avanade Inc. All Rights Reserved. 15
Migrations VB6 Une des tâches nécessaires est l’identification des délimitations précises entre les applications par la séparation des composants appartenant à chaque application. La notion d’application n’est pas universellement partagée. Il est donc important de définir et d’appliquer une approche cohérente qui correspond au contexte. Voici quelques règles qui ont fait leurs preuves : Les applications et les composants identifiés définissent le niveau de granularité de l’analyse réalisée pendant l’évaluation ; Les tâches telles que la planification de la migration, ou l’estimation de la charge de travail s’appuient sur les délimitations entre applications identifiées pendant cette étape. Ceci confirme leur importance. 7 La base de code complète doit être disponible dès que possible afin d’éviter de perdre du temps sur plusieurs analyses statiques du code, en raison de fournitures successives des fichiers. Le code source doit être issu des branches les plus récentes du système de contrôle des versions, afin de garantir que les chiffres donnés par l’analyse reflètent bien la situation actuelle. Une partie de l’analyse réalisée pendant d’évaluation du code exige que ce dernier passe à la compilation sans erreur. Ceci implique la fourniture de tous les composants binaires externes référencés par les applications. 5.2.2 Évaluation du code Le code source du portefeuille d’applications actuel est un des entrants les plus importants de l’évaluation du renouvellement, car il contient une masse inestimable de connaissances sur le système actuel. La méthodologie adoptée pour l’évaluation du code dépend de l’approche de migration. En cas de migration automatisée, l’évaluation du code s’appuie d’ordinaire sur les bases suivantes : Éléments non migrables (Non-Migrateable-Features, ou NMF) Le délai nécessaire à la traduction automatisée du code est négligeable par rapport à la charge de travail générale de migration d’une application importante. Dans un projet de migration VB6, l’essentiel de l’effort est consacré au travail manuel nécessaire au traitement des fonctions (ou situations) que l’outil de migration ne peut pas traiter automatiquement. Avanade et ArtinSoft ont une connaissance détaillée de ces situations et ont réalisé des investissements importants dans des actifs qui peuvent accélérer le processus d’identification de ces situations dans le code. L’outil VBUC™ peut exécuter non seulement la conversion de code VB6 existant vers VB .NET ou C# avec un haut degré d’automatisation, mais il peut aussi identifier aussi la majorité des situations qui ne peuvent pas être automatiquement migrées et qui exigent une intervention manuelle. Plus généralement, ces situations appartiennent à deux catégories : 1. Les caractéristiques qui empêchent la compilation de l’application ; 2. Les caractéristiques qui empêchent l’application de fonctionner comme prévu en environnement d’exécution. La façon de les traiter pendant la migration diffère, et cette différence se répercute sur l’évaluation. 7 Afin d’assurer la confidentialité du code source partagé, Avanade a conçu et mis en place une infrastructure qui respecte des normes très exigentes de sécurité physique et logique. © 2011 Avanade Inc. All Rights Reserved. 16
Migrations VB6 Complexité de la migration Toutes les lignes de code ne naissent pas égales ! Par conséquent, certaines applications peuvent exiger plus d’effort à la migration que d’autres. Il existe des facteurs bien connus qui peuvent contribuer à rendre la migration d’un composant VB6 vers .NET plus ou moins complexe : 1. L’utilisation de composants externes ; 2. Le nombre d’appels à des API Windows natives ; 3. La présence de mots-clés VB obsolètes ; 4. La technologie d’accès aux données utilisée ; 5. La taille de l’application ; 6. La complexité des interactions avec les autres applications, etc. La complexité d’un composant spécifique est calculée en attribuant une note à chacun de ces facteurs et en calculant un niveau de complexité général par la pondération des notes individuelles en fonction de notre expérience. Besoins complémentaires Comme nous l’avons déjà dit, la migration automatisée produit une application fonctionnellement et architecturalement équivalente dans laquelle le flux et la logique du code sont conservés. Parfois, certains besoins complémentaires et non fonctionnels viennent pourtant s’y ajouter (par exemple, le respect de normes de codage, l’utilisation de composants architecturaux déjà disponibles dans l’architecture cible .NET, etc.). Ces besoins sont précisément évalués en fonction de l’application actuelle afin de déterminer s’ils doivent être pris en compte 8 manuellement ou par une personalisation de VBUC™. 5.2.3 Entretiens avec les parties prenantes L’analyse de code seule, bien que précise, ne pas fournit toutes les données nécessaires à l’élaboration d’une stratégie de renouvellement optimale. Des informations de contexte supplémentaires sont nécessaires pour obtenir une vision complète de la situation actuelle et pour comprendre les attentes en termes de situation cible. Ces informations doivent être recueillies par des entretiens, sous la forme de différents types de réunions ciblées, chacune ayant des participants sélectionnés et des objectifs spécifiques (voir la figure 3). 8 Visual Basic Upgrade Companion peut être personnalisé afin d’automatiser des modèles de conversion spécifiques par ajout de nouvelles règles de transformation. © 2011 Avanade Inc. All Rights Reserved. 17
Migrations VB6 Revue de l’application Lancement Présentation Assurance Architecture Revue de de Conclusion qualité technique l’application l’environnement Revue de l’application Figure 3 : Présentation du processus d’évaluationLe tableau qui suit donne une description de haut niveau des aspects couverts par les différents types d’entretien et des participantsnécessaires pour chaque type. Domaine Aspects impliqués Participants Lancement Présentation de l’entreprise Chef de projet Évolution passée et plan d’évolution (par exemple âge et durée de vie des Responsable technique applications, nouveaux besoins, etc.) Responsable AQ Motifs de renouvellement du portefeuille (par exemple, métier ou techniques) Périmètre et attentes (par exemple, stratégie de renouvellement, estimation des coûts, etc.) Présentation de Structure de gestion Chef de projet l’environnement Environnement de développement Responsable technique Environnement d’exécution Responsables du Gestion des opérations développement des Support et maintenance applications Assurance qualité Stratégie générale d’assurance qualité Manager(s) Chef de projet Principes de test fonctionnel Responsable AQ Principes de test des performances et de l’extensibilité Outils de test Architecture technique Normes informatiques et meilleures pratiques Responsable technique du Conception technique de haut niveau projet Conception du portefeuille d’applications de haut niveau Architecte(s) technique(s) Sources de données et technologies Architecte(s) fonctionnel(s) Intégration avec des systèmes externes Revue de l’application9 Processus et fonctions métier supportés Responsable de l’application Évolution passée et plan d’évolution Architecture de haut niveau de l’application Interfaces avec des systèmes et applications externes Sources de données et technologies Définition du périmètre 9 Ce type d’entretien est généralement mené uniquement pour les applications très prioritaires. © 2011 Avanade Inc. All Rights Reserved. 18
Migrations VB6 5.2.4 Enquête sur le portefeuille de Personnalisation de migration l’enquête Identification du public de l’enquête Distribution de l’enquête Consolidation des données Dans la plupart des cas, la réalisation • Questionnaire de base d’entretiens de revue des applications • Choix des • Identification des questions responsables des en tête-à-tête pour chaque application • Validation des applications • Découpage de du portefeuille n’est pas faisable pour données l’inventaire des • Inventaire des des motifs de délai ou d’indisponibilité applications applications • Instructions aux des responsables des applications. responsables des applications Dans ce cas, la façon la plus efficace de collecter l’ensemble minimal Figure 4 : Enquête sur le d’informations nécessaires pour portefeuille d’applications profiler toutes les applications est de réaliser une enquête. Cet exercice utilise un cadre standard d’étude basé sur des évaluations antérieures, selon une méthodologie éprouvée (voir la figure 4). Voici quelques leçons tirées de l’exécution de ce type d’activité : L’utilisation d’une enquête standard permet d’accélérer le processus, mais des personnalisations sont nécessaires pour s’assurer que la structure de l’enquête convient aux objectifs de l’évaluation générale et qu’elle est compatible avec le type d’audience et le temps disponible L’enquête est menée au niveau de l’application. Il est extrêmement important que le découpage des composants évalués soit en phase avec les critères utilisés pour l’évaluation du code (voir la section 4.1.3 - Planification de l’évaluation). Il faut fournir des instructions détaillées aux personnes destinataires de l’enquête, par une réunion ou par e-mail, pour s’assurer qu’elles comprennent bien le sens des informations demandées et pour en garantir l’homogénéité. Une bonne préparation permet de gagner du temps dans la consolidation des données incohérentes. Voir ci-dessous un échantillon des informations généralement demandées pendant une enquête sur les applications, ainsi que les aspects couverts : Information Concerne généralement... Fonction métier La carte des points sensibles10 Priorité métier Le plan d’évolution Coût annuel estimé Le plan d’évolution Degré de changements dans les n prochaines années L’approche de migration Nombre d’utilisateurs L’approche de migration Âge de l’application L’approche de migration Durée de vie prévue de l’application migrée L’approche de migration Solutions spécifique/progiciel L’approche de migration, le plan d’évolution Adéquation fonctionnelle Le plan d’évolution Adéquation technique L’approche de migration 10 Une carte des points sensibles est une représentation graphique de la manière dont les applications du portefeuille répondent aux différents événements métier. Un code de couleurs est utilisé pour différencier les fonctions qui sont plus ou moins prises en charges par les applications, afin de souligner un éventuel manque de cohésion. © 2011 Avanade Inc. All Rights Reserved. 19
Migrations VB6 5.2.5 Approche et séquencement du renouvellement Un des aspects de la stratégie de renouvellement traité pendant l’évaluation est la définition d’une approche de renouvellement et son séquencement pour chacune des applications identifiés dans le portefeuille. Un ensemble de critères affiné par des experts au fil des projets nous aide à traiter toutes les informations et les constatations tirées de l’évaluation, afin d’émettre des recommandations raisonnables. En premier lieu, toutes les applications sont évaluées selon différents aspects, y compris : L’état de santé de l’application : Il est déduit de la combinaison de l’adéquation fonctionnelle et technique de l’application. L’adéquation fonctionnelle couvre (entre autres) le degré de complétude des fonctions fournies par l’application actuelle par rapport aux exigences de l’activité, le délai de déploiement des nouvelles fonctions nécessaires pour satisfaire de nouveaux besoins, le niveau de service, l’adéquation future aux besoins métier, et d’autres aspects similaires. L’adéquation technique couvre la performance, l’extensibilité, l’interopérabilité, le respect des normes de l’entreprise, la disponibilité et d’autres facteurs techniques. Impact métier : C’est une façon de mesurer le degré de priorité de l’application pour l’entreprise. Il est déterminé par l’évaluation de la capacité de chaque application à prendre en charge une ou plusieurs exigences générales fonctionnelles ou techniques (par exemple, l’orientation stratégique, l’innovation, la productivité du personnel, la réduction des coûts de maintenance, etc...) Complexité du renouvellement : Il s’agit d’une évaluation qualitative de la complexité de l’effort de renouvellement pour une application spécifique. Différents facteurs doivent être considérés, selon l’approche de renouvellement. Par exemple, dans un cas de réécriture (ou de réingénierie), l’analyse se concentre sur des données liées à la complexité et à la taille de chaque application (par exemple, nombre de modules, complexité cyclomatique, etc.). En outre, dans une migration automatisée, la complexité est surtout liée aux situations qui ne peuvent pas être migrées automatiquement (voir la section Évaluation du code). Dépendances : Dans l’opération de répartition des composants visés par la migration afin de définir les limites de l’application, il convient d’être particulièrement attentif à la définition d’un ensemble cohérent. Dans la plupart des cas, il est impossible d’éviter complètement que des composants appartenant à une application dépendent de composants appartenant à une autre, et inversement. Ces interdépendances peuvent affecter de manière significative le séquencement de la migration des applications dans le portefeuille. C’est la raison pour laquelle il faut consacrer du temps pendant l’évaluation à l’identification des dépendances et à l’enregistrement des données pertinentes, en particulier la gestion des interactions, le type d’informations échangées, le protocole d’échange, etc... Les critères de choix de l’approche de migration et de son séquencement s’appuient sur l’évaluation des combinaisons suivantes pour chaque application (voir la figure 5) : Impact métier et Complexité de la migration ; Impact métier et État de santé de l’application. © 2011 Avanade Inc. All Rights Reserved. 20
Migrations VB6 Impact Métier État de santé de l’application Figure 5 : Critères de détermination de l’approche et du séquencement de la migration Comme l’explique la section 4 (Approche et stratégie de renouvellement), le principe majeur de choix de l’approche de migration est que les applications dont la complexité de migration est raisonnable et qui sont en bonne santé sont de bons candidats à la migration. En revanche, une approche de réécriture est plutôt recommandée pour les applications qui fonctionnent mal ou qui sont trop complexes à migrer. Pour ce qui concerne le séquencement de la migration, les facteurs de choix sont surtout liés à la priorité (impact métier) de l’application et à sa santé actuelle, une priorité élevée et une mauvaise santé contribuant à faire remonter une application dans la séquence de migration. Il convient également de réfléchir aux dépendances entre les applications (couplage) pendant la détermination du séquencement. © 2011 Avanade Inc. All Rights Reserved. 21
Migrations VB6 Il faut en particulier être attentif aux applications migrées en premier et à celles qui seront traitées plus tard, car certaines dépendances peuvent imposer une modification du séquencement en raison de la complexité des activités de contournement nécessaires. 5.2.6 Conception de l’approche de test Comme un effort de migration a pour objectif d’assurer l’équivalence fonctionnelle, la phase de test dans ce type de projet doit garantir que l’application migrée se comporte exactement comme la version originale. Plusieurs principes commandent la définition de l’approche de test pendant la phase d’évaluation. En voici quelques uns : Les bonnes pratiques d’Assurance qualité (AQ) actuellement adoptées par l’organisation doivent être évaluées : o Les cas de test existants pour les applications cible doivent être collectés ; o Des spécifications formelles des cas de test et une infrastructure de test adaptée doivent être en place ; o Les écarts potentiels relatifs aux exigences ci-dessus doivent être immédiatement signalés afin de les prendre en compte dans l’estimation et la planification. La participation des différents acteurs au cours du processus de test doit être clairement exprimée en termes d’activités et de calendrier, pour pouvoir planifier une approche mutuellement acceptable (par exemple, les propriétaires des applications existantes doivent prévoir du temps pour tester l’application migrée) ; Le principal critère de succès d’un projet de renouvellement par migration automatisée est l’équivalence fonctionnelle entre application source et cible. C’est pourquoi il faut créer des environnements de test de référence afin de valider les cas de test par rapport à l’application actuelle et d’évaluer l’équivalence fonctionnelle des applications migrées ; Il convient également de vérifier si des critères de test supplémentaires doivent être ajoutés au périmètre de test, en plus de l’équivalence fonctionnelle (par exemple, test des performances). 5.2.7 Estimation de la charge Une estimation précise de la charge et du coût de l’exécution du renouvellement est nécessaire dans le cadre d’une décision informée sur la meilleure approche de renouvellement, mais aussi afin de fournir des données essentielles au business case. Avanade et ArtinSoft disposent d’une méthodologie éprouvée d’estimation de cette charge en fonction d’indicateurs de productivité recueillis sur des projets passés, ainsi que d’outils conçus pour améliorer la fiabilité de l’estimation. L’ensemble des techniques utilisées pour l’estimation de la charge varie sensiblement en fonction de l’approche de migration. Pour la migration automatisée, la charge dépend de la complexité de la migration, et non de la complexité de l’application ou de sa taille. En d’autres termes, c’est le nombre de fonctions qui ne sont pas migrées automatiquement par l’outil et le coût de leur traitement manuel qui constituent la plus grande partie de la charge d’une migration automatisée, et non la taille ou la complexité de l’application elle- même. Une description détaillée du procédé d’estimation de la charge sortirait du champ du présent document, mais le reste de cette section donne une description de haut niveau des principes d’estimation et des activités principales associées. Tout d’abord, commençons par décrire les principaux facteurs qui participent à la détermination de la charge : Taille de l’application : Même dans un scénario où la migration s’appuie fortement sur un outil automatisé, il existe des tâches manuelles de « préparation » du code et des activités post-migration. Ces activités exigent un effort proportionnel à la taille de la base de code migrée (par exemple, vérification de la complétude du code, compilation correcte, résolution des questions spécifiques de migration, etc.) ; © 2011 Avanade Inc. All Rights Reserved. 22
Migrations VB6 Taille de l’application Fonctions non traitées : L’outil •Lignes de code utiles / totalesVBUC™ est statistiquement capable de Modèle d’estimation •Nombre de projets Avanadetraiter la migration d’un pourcentage élevé •Nombre de composants(jusqu’à 95 %) du code VB6, mais il existedes cas dans lesquelles le code source Planificationcontient des situations qui ne peuvent pas Complexité de la migrationêtre migrées automatiquement vers .NET. Analyse •Nombre de composantsLa raison peut être l’absence de fonction externeséquivalente dans .NET, ou des problèmes •Appels à des API Conceptionpotentiels de maintenabilité ou de •Accès à des bases deperformance du code résultant. Fort données Construction •Fonctions non migrablesheureusement, la plupart descaractéristiques non traitées contenues Test Besoins complémentairesdans le code VB6 sont automatiquementdétectées pendant la migration par •Intégration avec les DéploiementVBUC™. composants externes •Remplacement des composants externes •Codage spécifique pour respect des standards Figure 6 : Méthode d’estimation L’outil VBUC™ insère dans le code migré des commentaires spécifiques afin d’indiquer les portions de code qui exigent des activités manuelles ou qui méritent une attention particulière pendant les tests. Ces commentaires aident aussi à affecter les fonctions à des catégories, puis à consulter le nombre d’événements pour chaque catégorie. C’est un entrant fondamental du processus d’estimation. Besoins complémentaires : Dans certains scénarios, certains besoins de migration complémentaires exigent des interventions manuelles supplémentaires. Par exemple, il peut être nécessaire que le code issu de la migration vers .NET respecte des normes de codage qui n’existaient pas dans le code original. Un autre exemple serait l’ajout manuel de plus amples transformations de code que celles que VBUC™ réalise automatiquement (par exemple, remplacement de certains contrôles tiers utilisés via COM-interop, mise en correspondance entre des appels aux API Windows et des appels aux bibliothèques natives de .NET, etc.). Tous les indicateurs pertinents liés aux facteurs décrits ci-dessus, ainsi que les conclusions supplémentaires tirées de l’évaluation seront utilisés en entrée de la méthode d’estimation générale. La combinaison de ces indicateurs permet de produire une estimation précise de la charge de travail (voir la figure 6). Cette méthode s’appuie sur l’estimateur projet Avanade Estimating Model (AEM). AEM cumule notre expérience issue de la réalisation de milliers de solutions critiques. Ce modèle est utilisé partout dans le monde comme base de nos estimations à toutes les étapes du cycle de vie de migration (planification, analyse, conception, tests, etc.). 5.2.8 Planification Un autre composant de la stratégie de renouvellement est le plan d’évolution recommandé qui donne une vision de haut niveau du programme d’ensemble. Le plan d’évolution doit décrire clairement certains aspects fondamentaux : © 2011 Avanade Inc. All Rights Reserved. 23
Migrations VB6 Périmètre du programme ; Approche de renouvellement choisie pour chaque application ; Calendrier de renouvellement des différentes applications ; Dépendances avec les programmes informatiques en cours ou à venir ; Périodes de gel du code ; Mode de réalisation (onshore/nearshore/offshore/multi-sites). La description du cadre complet d’élaboration d’une stratégie optimale de renouvellement n’est pas l’objet de ce document. Cependant certaines recettes importantes et principes généraux issus de notre expérience sont donnés ci-dessous : Minimiser les perturbations en alignant le projet sur les initiatives informatiques en cours et sur le plan d’évolution de l’entreprise. La période de gel du code doit être minimisée, surtout pour les applications à maintenance courante lourde et critique ; Le séquencement de la migration devrait être déterminé en fonction d’un équilibre entre les priorités fonctionnelles et techniques. Il doit prendre en compte les perturbations possibles et la charge supplémentaire dues au traitement préalable des dépendances entre les applications ; Un pilote de l’approche de migration permet d’ajuster le moteur de renouvellement sur tout le cycle de vie, et donc de réduire les risques et de maximiser la productivité des développeurs ; Si possible, migrer quelques applications « quick-win » dès le début, puis passer aux applications à impact/bénéfice élevé. Cela aidera à maximiser le retour sur investissement de la migration et aidera à obtenir un consensus. Cette approche peut faciliter une adoption précoce des applications migrées, ce qui contribue de manière significative au succès du programme ; Définir une stratégie prudente de gestion des versions (une approche progressive est souvent préférable à un big-bang qui peut comporter beaucoup de risques en cas de systèmes critiques). Par ailleurs, certains principes supplémentaires concernent l’exécution de très grands programmes de renouvellement VB6 : Adopter un « modèle industriel » pour réaliser des économies d’échelle : optimisation de l’utilisation des ressources sur l’ensemble du cycle de réalisation, meilleur respect des standards et des processus, amélioration l’efficacité, etc. Mettre en place un processus « industriel » efficace qui garantira le suivi des activités quotidiennes et des indicateurs de performance, l’amélioration de l’efficacité des opérations et la coordination avec les fonctions métier du client. Mettre en place un comité de gouvernance, incluant des parties prenantes internes et externes et chargé de fixer l’orientation de la gestion de l’usine (hiérarchisation, gestion des changements, remontée des problèmes, etc.). 5.2.9 Présentation des résultats Toutes les conclusions pertinentes et les livrables créés pendant les travaux d’évaluation sont résumés dans un rapport qui est alors présenté. La présentation des résultats matérialise le lancement d’une phase du projet destinée à recueillir des retours et à mettre au point l’approche de migration recommandée. Voici les activités généralement incluses dans ce processus d’ajustement : Revue du calendrier définitif du projet et acceptation ; 11 Validation du séquencement de la migration en termes de faisabilité générale et de cohérence des jalons entre eux ; 11 Les jalons définissent la granularité du plan de migration. Chacun est composé de la liste des applications à migrer pendant une même phase du projet. © 2011 Avanade Inc. All Rights Reserved. 24
Migrations VB6 Confirmation de la stratégie de génération des cas de test et de l’approche générale de test ; Revue et acceptation des besoins complémentaires qui s’ajoutent à l’équivalence fonctionnelle (par exemple, normes de codage, architecture cible, etc.) ; Accord sur la fréquence des réunions et d’autres aspects du processus de communication. Cette étape aboutit à la définition d’une approche générale et consensuelle de l’exécution du projet de migration. 5.3 Migration Il est indispensable de disposer des bons outils et des bonnes compétences pour mener à bien un projet de migration d’applications. Cependant, les lignes de conduite et les bonnes pratiques collectées au fil de projets précédents sont aussi nécessaires afin d’exploiter au mieux ces outils et ressources. C’est la combinaison de tous ces éléments qui constitue une méthodologie de migration. Les paragraphes qui suivent décrivent les principaux lots d’activités inclus dans la méthodologie de migration conçue par Avanade et ArtinSoft au fil d’années d’expérience. Cette méthodologie est destinée à permettre l’atteinte des objectifs définis pendant l’évaluation du projet. Lancement Figure 7 : Processus de du migration projet Préparation de l’environnement de migration Préparation du code pour la Code du migration jalon Exécution VBUC Personnalisations de la migration Résolution des Cycle de vie de problèmes de Recette migration des migration applications du jalon Tests de recette par Tests unitaires les utilisateurs Tests du système Recette du projet Évolution de l’application © 2011 Avanade Inc. All Rights Reserved. 25
Migrations VB6 Cette méthodologie est itérative par nature. La plupart des activités sont reproduites à chaque itération suivante. La liste qui suit donne les étapes dans un projet de migration typique. Le workflow correspondant est décrit en figure 7. Préparation de l’environnement de migration ; Conception et mise en œuvre des personnalisations des outils ; Préparation du code à la migration ; Exécution de la migration ; Résolution des problèmes de migration. 5.3.1 Préparation de l’environnement de migration La préparation de l’environnement de migration est une activité qui est souvent sous-estimée. Si elle est menée correctement, elle peut améliorer significativement la productivité. Le principe est de préparer et de valider tous les éléments qui doivent être disponibles avant de commencer la migration du code source. On réduit ainsi le risque de dégradation de la productivité de la migration en raison d’informations manquantes. Les entrants principaux de cette activité sont : Le plan de test qui sera utilisé pour valider l’équivalence fonctionnelle des applications migrées ; La dernière version du code source (pour toutes les applications du périmètre de migration) et les éléments complémentaires (par ex., les composants externes appelés) nécessaires à la compilation des applications ; Un environnement fonctionnel ou des instructions complètes pour en créer et configurer un. Les résultats de cette activité sont les suivants : Un environnement de référence pour les tests entièrement fonctionnel ; Des cas de test validés qui seront utilisés pour vérifier l’équivalence fonctionnelle de l’application migrée. Les deux activités qui suivent font partie de la préparation de l’environnement et sont décrites en détail en raison de leur importance. Création de l’environnement fonctionnel Un environnement de test fonctionnel doit être disponible. Cet environnement est soit préparé par l’équipe de développement des applications, soit créé à partir des instructions fournies. Il sera utilisé pour générer, compiler et contrôler les applications migrées. Une fois que l’environnement fonctionnel est opérationnel, il est utilisé pour compiler toutes les applications source. Cela contribue à valider l’environnement et aussi à vérifier que le code source fourni est complet. Validation des cas de test Si la migration est conçue dans un objectif d’équivalence fonctionnelle, les cas de test qui seront exécutés comme critères de succès doivent être validés par rapport à l’application actuelle avant de commencer leur exécution. Pour cela, ils doivent être exécutés dans un environnement fonctionnel qui a été créé en utilisant les applications source compilées dans ce même environnement. Les situations de non-validation des cas de test sont dues soit à des erreurs de configuration de l’environnement, soit à des problèmes de spécifications des cas de test (ou à un bug dans le code original). Ils sont traités soit en en stabilisant la configuration, soit en émettant des demandes de clarification à l’équipe de développement de l’application. © 2011 Avanade Inc. All Rights Reserved. 26
Modes économiseurs des systèmes de refroidissement des datacenters
Bandwidth Efficiency Improvement for Online Games by the use of Tunneling, Co...
Jose Saldana
QoS and Admission Probability Study for a SIP-based Central Managed IP Teleph...
hg-langlois
Surveillance vidéo : les questions les plus fréquentes en 2014
Des tensions à toutes les échelles : le cas bolivien
La notion d'aire urbaine
Recommander un projet BPM à sa direction
Mobilité : tendances et cas d'entreprise
PDHPE Rationale
JayEl91