la migration de visual basic 6 vers .net

La migration de Visual Basic 6 vers .NET

Un 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.

La plupart des organisations qui sont dans cette situation se reconnaîtront dans ce résumé. Selon une étude récente1 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.


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.


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

n’est actuellement plus suivi en majeur par Microsoft. Bien que Microsoft se soit engagé à « le faire fonctionner »2 (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


http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx

http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx

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.


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

devrait se contenter de la laisser en l’état3 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

fonctionnalités améliorées. Dans ce cas, il est souvent nécessaire de mener un effort important de formation4 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.


Migrations VB6

Le schéma ci-dessous montre l’effort d’une migration par rapport à celui d’une réécriture.

Migration Réécriture

Test

Construction

Conception

Analyse

Figure 1 : Répartition de l’effort

4.2 Stratégie de migration La stratégie de migration devrait être abordée à deux niveaux différents. Le premier est l’évaluation exhaustive de la migration complète du portefeuille d’applications. Le second niveau porte sur chaque application du portefeuille. Ce livre blanc se concentre sur le niveau des applications, mais, en règle générale, il est 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 renouvellement est l’élaboration d’un inventaire des applications.

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.


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.


Migrations VB6

Le deuxième choix comporte moins de risques, mais il exige plus de travail pour permettre l’interopérabilité entre les parties

migrées et non-migrées de l’application5 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

actuelle est constituée de multiples composants distincts, clairement decouplés6 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.


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.

Au vu des critères énumérés ci-dessus, il est clair qu’une migration ne sera considérée réussie qu’à l’issue de la mise en œuvre correcte d’un processus qui couvre différents aspects, et pas uniquement après la simple transformation du système actuel en un autre système présentant des capacités similaires.


Figure 2 : Processus de migration

Préparer Migrer Evaluer

Planifier Analyser Concevoir Construire Tester Déployer Gérer

Motifs de la

migration

Architecture

du système

Stratégie de

migration

Adaptation

des outils

Déploiement en

environnement de

tests du système

Infrastructure

de

configuration

Opérations

métier

Gestion des

services

Préparation de

l’appli. Au

déploiement

Exécution des

tests système

finaux

Préparation

du code

Ordre de

migration

Fonctionnalités

de l’application

Plan

d’évolution

Délai prévu

Processus de

test existants Stratégie

d’intégration Pré-migration

Résolution des

anomalies

Déploiement

en production

Fourniture

des services

Périmètre Dépendances

externes

Approche de

test cible

Portage du

code

Exécution des

tests système

finaux

Transition

vers l’appli.

déployée

Gestion de la

qualité

Carte des

points

sensibles

Problème de

migration

Analyse des

rapports de

mise à niveau

Période de

gel du plan

Exécution

des tests de

recette

Gestion des

environnements

Correction du

code

Support à

l’environnement

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.


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 :


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.


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.

La base de code complète doit être disponible7 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.


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

manuellement ou par une personalisation8 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.


Migrations VB6

Revue de l’application

Lancement Assurance qualité

Architecture technique


Conclusion


Figure 3 : Présentation du processus d’évaluation

Le tableau qui suit donne une description de haut niveau des aspects couverts par les différents types d’entretien et des participants

nécessaires pour chaque type.

Domaine

Aspects impliqués

Participants

Lancement Présentation de l’entreprise

Évolution passée et plan d’évolution (par exemple âge et durée de vie des applications, nouveaux besoins, etc.)

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.)

Chef de projet Responsable technique

Responsable AQ

Présentation de l’environnement

Structure de gestion

Environnement de développement

Environnement d’exécution

Gestion des opérations Support et maintenance

Chef de projet

Responsable technique

Responsables du

développement des

applications Manager(s) Assurance qualité Stratégie générale d’assurance qualité

Principes de test fonctionnel

Principes de test des performances et de l’extensibilité

Outils de test

Chef de projet

Responsable AQ

Architecture technique Normes informatiques et meilleures pratiques

Conception technique de haut niveau

Conception du portefeuille d’applications de haut niveau

Sources de données et technologies

Intégration avec des systèmes externes

Responsable technique du

projet

Architecte(s) technique(s)

Architecte(s) fonctionnel(s)

Revue de l’application9 Processus et fonctions métier supportés

É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

Responsable de l’application

9 Ce type d’entretien est généralement mené uniquement pour les applications très prioritaires.


Présentation

de l’environnement

Migrations VB6

5.2.4 Enquête sur le portefeuille de migration

Dans la plupart des cas, la réalisation

d’entretiens de revue des applications

en tête-à-tête pour chaque application

du portefeuille n’est pas faisable pour

des motifs de délai ou d’indisponibilité

des responsables des applications.

Dans ce cas, la façon la plus efficace

de collecter l’ensemble minimal

d’informations nécessaires pour

profiler toutes les applications est de

réaliser une enquête.

Personnalisation de l’enquête

• Questionnaire de base

• Choix des questions

• Validation des

données

• Inventaire des

applications

Identification du public de l’enquête

• Identification des responsables des applications

• Découpage de l’inventaire des applications

• Instructions aux responsables des applications

Distribution de l’enquête Consolidation des données

Figure 4 : Enquête sur le portefeuille d’applications

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.


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.


Migrations VB6

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.


Imp

act

Méti

er

État de santé de l’application

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.) ;


Migrations VB6

Fonctions non traitées : L’outil

VBUC™ est statistiquement capable de traiter la migration d’un pourcentage élevé (jusqu’à 95 %) du code VB6, mais il existe des cas dans lesquelles le code source contient des situations qui ne peuvent pas être migrées automatiquement vers .NET. La raison peut être l’absence de fonction équivalente dans .NET, ou des problèmes potentiels de maintenabilité ou de performance du code résultant. Fort heureusement, la plupart des caractéristiques non traitées contenues dans le code VB6 sont automatiquement détectées pendant la migration par VBUC™.

Taille de l’application •Lignes de code utiles / totales

•Nombre de projets

•Nombre de composants

Complexité de la migration

•Nombre de composants

externes

•Appels à des API

•Accès à des bases de données

•Fonctions non migrables

Besoins complémentaires

•Intégration avec les

composants externes

•Remplacement des

composants externes

•Codage spécifique pour

respect des standards

Modèle d’estimation Avanade

Planification

Analyse

Conception

Construction

Test

Déploiement

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 :


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 ;

Validation du séquencement de la migration en termes de faisabilité générale et de cohérence des jalons entre eux11

;

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.


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 du

projet

Code du

jalon

VBUC

Personnalisations

Préparation du code

pour la migration

Exécution de la

migration

Figure 7 : Processus de migration

Tests de recette par

les utilisateurs


Résolution des

problèmes de

migration

Préparation de l’environnement

de migration

Recette

du jalon

Cycle de vie de migration des applications

Tests unitaires

Tests du système

Recette du

projet

Évolution de

l’application

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.


Migrations VB6

La durée de la phase de stabilisation dépend de la complexité de l’environnement de test, de la « taille » du plan de test et des délais de clarification. Elle peut aller d’une à deux semaines.

5.3.2 Conception et mise en œuvre de la personnalisation de l’outil

Différentes personnalisations possibles de VBUC™ peuvent être identifiées pendant la phase d’évaluation. La conception et la

mise en œuvre de ces personnalisations sont généralement effectuées au début du processus de migration. L’essentiel de la

charge de travail de cette activité est consacré à la première itération, au cours de laquelle les personnalisations identifiées

pendant les phases de préparation et d’évaluation sont traitées. Les itérations suivantes de cette activité comprennent des

possibilités d’automatisation plus avancées identifiées pendant l’activité de migration afin de minimiser les modifications manuelles

exigées pour mener à bien la migration.

D’un point de vue fonctionnel, les personnalisations de l’outil peuvent être classées en plusieurs catégories :

Personnalisations en vue d’améliorer l’automatisation : Lors d’une évaluation, les problèmes de migration les plus

fréquents, ou les situations qui exigent une intervention manuelle (par exemple, remplacement de contrôles externes

spécifiques), sont identifiés et les possibilités d’automatisation sont évaluées ;

Personnalisations en vue de satisfaire des besoins complémentaires : L’équivalence fonctionnelle pure n’est pas parfois

pas suffisante. Des besoins complémentaires, non fonctionnels peuvent être imposés et doivent alors être traités pendant la

migration (par exemple, respect de normes de codage). Certains de ces besoins peuvent être satisfaits au travers de

personnalisations de VBUC™.

Le processus de prise de décision concernant la réalisation de personnalisations de VBUC™ est commandé par le coût de

réalisation, le nombre d’événements à traiter et l’importance d’éviter les erreurs potentiellement générées par les interventions

manuelles.

La complexité (et le coût résultant) de réalisation d’une personnalisation peut varier significativement selon le choix de l’une

ou l’autre des techniques proposées pour VBUC™ :

Mises en correspondance personnalisées : Elles peuvent être utilisées pour réaliser des transformations simples, en une

seule étape (par exemple, mise en correspondance de bibliothèques VB6 avec des composants cible de .NET) et mises en place avec un effort très limité ;

Extensions de règles complexes : Elles sont utilisées pour réaliser des transformations complexes en plusieurs étapes dans

des modèles complexes. Elles exigent généralement une définition précise de la transformation grammaticale ou syntaxique.

Elles imposent également une charge de développement plus importante, et font intervenir l’équipe produit.

Une fois que les personnalisations de l’outil sont réalisées, elles sont contrôlées par l’équipe de migration sur la portion de la base

de code choisie et sur des échantillons de code créés spécifiquement pour tester un jeu de scénarios possibles.

Notre expérience nous a montré que ces personnalisations de l’outil peuvent être très efficaces (surtout dans les projets de

moyenne à grande ampleur) et permettent des économies de coût substantielles (jusqu’à 25 %), ainsi qu’une amélioration

de la cohérence du processus de migration.

5.3.3 Préparation du code à la migration

L’effort nécessaire pour migrer une application VB6 peut être réduit si le code source impliqué dans la migration est préparé avant la

migration elle-même. L’analyse réalisée pendant l’évaluation du code nous permet de déterminer, avec une très bonne précision, la

nature des problèmes qui remonteront pendant la migration.


Migrations VB6

Nos projets de migration passés nous montrent statistiquement que, pour certaines catégories de problèmes du code VB6, la

résolution d’un seul problème avant la migration peut permettre de supprimer environ cinq à huit problèmes après la migration. Il

s’agit par exemple de scénarios qui incluent l’utilisation de propriétés par défaut des objets dans des affectations, des variables non

déclarées ou non typées (variantes), etc.

5.3.4 Exécution de la migration

Pendant l’activité de planification de la phase d’évaluation, un séquencement recommandé de la migration a été défini. Il en résulte

une série de jalons séquentiels. Chaque jalon comprend une série d’applications interdépendantes à migrer selon la séquence

définie dans le plan de migration.

Au début de cette phase, VBUC™ peut être configuré de manière sélective pour activer ou désactiver certaines des règles de

traduction du code intégrées au moteur de migration. La migration de code automatisée est généralement exécutée plusieurs fois

afin de trouver la meilleure configuration et d’identifier d’autres cas à traiter avant la migration.

Une fois que la configuration de VBUC™ est définie, elle sera utilisée pour migrer tous les autres jalons. L’utilisation de différentes configurations de VBUC™ pour chaque jalon peut être source de problèmes d’intégration plus tard dans le processus, et doit donc être évitée.

Le code résultant de la migration automatisée avec une configuration optimale est appelé code vert. La qualité du code vert est

testée par le responsable de l’assurance qualité par rapport à toutes les exigences partagées (par exemple, respect des normes de

codage), avant de passer aux prochaines étapes du workflow de migration.

5.3.5 Résolution des problèmes de migration

Une croyance répandue affirme que l’indicateur le plus important dans un processus de migration automatisée est le degré

d’automatisation, le processus idéal n’exigeant pas de changements manuels et étant automatisé à 100 %.

Une automation à 100 % est possible en théorie, mais la qualité du code produit ne satisferait probablement pas les normes de

qualité habituelles. Certains éléments statistiques ou anecdotiques montrent que l’aspect le plus critique d’un processus de

migration est la capacité à prévoir ce qui devra être traité manuellement, plutôt que faire une recherche aveugle, ou d’adopter une

approche par essais-résolutions.

Comme dit plus haut, une des tâches que réalise VBUC™ pendant la migration du code est l’identification et le marquage par des

commentaires spécifiques des portions de code qui lèvent une question et qui doivent être traitées manuellement. Les situations qui

exigent une intervention manuelle peuvent être regroupées en deux catégories générales :

Non mis à niveau ou non pris en charge : Cette catégorie fait référence aux caractéristiques de VB6 pour lesquelles il n’est

pas possible de donner automatiquement un équivalent direct ou fonctionnellement bon dans .NET. Ce type de problème

empêche la compilation du code migré. Il a donc la plus haute priorité dans le workflow des activités post-migration.

L’expérience pratique montre qu’une fois que tous les cas de « non-prise en charge » sont réglés, 95 % des problèmes restants

dans cette catégorie peuvent être résolus par une analyse rapide. Les 5 % restants peuvent exiger quelques changements

mineurs à l’application, ou l’ajout de quelques petites fonctionnalités.

Comportement différent : Ce cas fait référence aux situations qui n’empêchent pas la compilation du code, mais qui peuvent

donner lieu à des comportements différents de celui de l’application existante (ou provoquer une erreur à l’exécution). Bien que

seule une fraction de ces situations doive être traitée manuellement, les indications fournies par VBUC™ apportent des

informations appréciables au processus de test.


Migrations VB6

Tous les problèmes identifiés pendant l’exécution de l’outil de migration sont aussi résumés dans un rapport de mise à niveau qui

permet de planifier les activités de résolution afin de garantir l’efficacité et la cohérence du processus.

Ces problèmes sont ensuite catégorisés et classés par nombre d’événements. L’étape suivante consiste à rechercher des solutions à

ces problèmes qui satisfassent toutes les exigences et à estimer la charge de travail de mise en œuvre de ces solutions. L’équipe de

migration doit constamment être à la recherche de possibilités d’automatisation supplémentaires, afin d’améliorer la migration

automatique des jalons suivants.

La méthodologie de migration est itérative par nature. C’est à cette étape qu’un effort spécifique est fait à chaque itération pour

améliorer la qualité du code vert produit et l’efficacité de l’équipe de migration.

La disponibilité à la demande de ressources de l’équipe de développement de l’application source et d’utilisateurs très compétents

pendant tous le processus est hautement recommandée. Comme l’équipe de migration n’a pas de connaissance préalable du code

source, ni de connaissance fonctionnelle de l’application à migrer, elle peut bénéficier de l’assistance d’un expert pour comprendre le

comportement de l’application et prendre les meilleures décisions face à un problème.

5.3.6 Tests

Contrairement à un projet normal de développement où l’essentiel de l’effort est réalisé pendant l’expression des besoins, la

conception et le développement, dans un projet de migration, ce sont les tests qui représentent la plus lourde charge.

Pour ce type de projet, les tests sont non seulement la conclusion naturelle du cycle de vie de développement, mais aussi la

meilleure façon de suivre l’avancement pendant la réalisation et de fournir des bases solides à une recette claire par les

responsables métier.

La méthodologie de test d’un projet de migration n’est pas très différente des meilleures pratiques de développement standard, à

l’exception du fait que le système actuel est disponible pour comparer les résultats. Cette section décrit les différentes activités de

test et se concentre sur les aspects indispensables pour démontrer que l’application migrée est équivalente fonctionnellement à

l’application source.

La dernière activité de test (les tests de performance) n’est pas toujours nécessaire, car dans la plupart des cas, la performance

d’une application migrée automatiquement de VB6 à .NET est comparable, voire meilleure que celle de l’original. Cependant,

des ajustements peuvent parfois être nécessaires.

Toutes ces activités ont une forte dépendance avec les cas de test fournis, qui doivent être validés (voir la section 5.3.1 Validation des cas de test) par rapport à l’application source avant d’exécuter le moindre test.

Tests unitaires

Une fois que le code migré passe en compilation, l’objectif suivant est de rendre fonctionnels les composants et les parties de

l’application sélectionnés. Ceci exige un effort important puisque le lancement de l’application doit être opérationnel. Le

lancement ou démarrage de l’application est l’étape où la plupart des applications exécutent des activités critiques (par exemple,

des contrôles de sécurité, des accès aux données, l’initialisation des sous-systèmes, etc.) et il exige généralement des

ajustements importants au code.

Une fois cette étape accomplie, l’équipe de migration exécute un sous-ensemble choisi des cas de test définis pour évaluer

l’équivalence fonctionnelle de l’application et pour garantir que la qualité est assez bonne pour lancer les tests du système.

Une autre bonne pratique dans le cadre de cette activité est de vérifier que tous les formulaires peuvent être chargés

correctement, afin de garantir que les testeurs peuvent naviguer dans l’application sans être interrompus fréquemment par les

arrêts anormaux.


Migrations VB6

Tests du système

Les applications et les composants pour lesquels les tests unitaires ont été exécutés avec succès sont validés par rapport à un jeu

de test complet défini en vue de l’équivalence fonctionnelle par l’équipe de test. On exécute en outre des tests supplémentaires

ad-hoc à l’aide de critères bien connus afin d’identifier tôt dans le processus les écarts typiques en termes d’équivalence

fonctionnelle (surtout du point de vue des utilisateurs).

Si besoin, les cas de test de performance sont aussi exécutés sur l’application migrée pour vérifier que les critères d’acceptation

des performances sont aussi respectés.

Toutes les différences fonctionnelles sont enregistrées dans la liste des anomalies. La correction et la résolution de ces anomalies

donnent lieu à de nouvelles versions du code. Les tests sont exécutés en cycles multiples, qui doivent tous être positifs pour

pouvoir transmettre l’application de l’équipe de test interne pour les tests de recette formelle par les utilisateurs.

Tests de recette par les utilisateurs

Les tests de recette par les utilisateurs sont exécutés en faisant passer les cas déjà utilisés dans les tests du système.

Contrairement aux tests du système, les tests de recette sont exécutés dans l’environnement de recette officiel par l’équipe

de test interne.

Les écarts fonctionnels sont signalés à l’équipe de test qui valide l’anomalie en vérifiant qu’elle peut être reproduite dans

l’environnement de test fonctionnel de référence. En cas de validation, l’anomalie est ajoutée à la liste, puis corrigée. Les anomalies

qui ne peuvent pas être reproduites sont analysées avec l’équipe de test interne et les équipes de développement. La reproduction

des anomalies est importante car elle garantit que l’équipe de migration ne perd pas de temps sur des anomalies liés à la

configuration de l’environnement.

6. Conclusion

L’identification de solutions viables pour la sortie des anciennes applications VB6 de l’obsolescence devient une priorité pour

beaucoup d’organisations en raison des forces qui les poussent à faire évoluer leurs systèmes informatiques.

Le renouvellement des applications de VB6 et ASP n’est pas une étape indispensable en elle-même ; mais c’est une façon

d’éliminer des sources de problèmes fréquents et de profiter des avantages liés à la transition vers une plate-forme plus

moderne.

Du point de vue tactique, les organisations visent les gains de productivité que permet la plate-forme .NET. Elles en attendent des

améliorations qui induiront une diminution des coûts de maintenance, une amélioration du délai de mise sur le marché des nouvelles

fonctionnalités et une réduction des risques associés à l’exploitation d’une plate-forme non supportée, avec une base de

compétences qui s’étiole chaque jour.

Du point de vue stratégique, elles cherchent des occasions de consolidation de leurs actifs sur des plates-formes modernes et

répandues, et des améliorations de la gestion des applications (facilité de déploiement, meilleure intégration, sécurité et fiabilité

renforcées).

La structure et la taille des projets réels de renouvellement de VB6 sont très variables, mais il est fréquent que les organisations

soient confrontées au défi que présente le traitement de portefeuilles composés d’applications interdépendantes, de moyenne ou

grande ampleur, plutôt que de composants monolithiques.

Le renouvellement d’un portefeuille d’applications VB6 est un processus complexe qui implique de nombreux choix critiques,

chacun ayant une influence significative sur l’issue du projet. Avanade et ArtinSoft ont mis au point l’approche décrite dans ce

livre blanc en réponse à la demande de clients qui souhaitent aller de l’avant sans investir à fonds perdus dans des compétences

et des outils dédiés à une initiative ponctuelle.


Migrations VB6

Enfin, comme le montre l’étude d’Aberdeen Group, le recours à un prestataire spécialisé dans ce domaine permet d’améliorer

les bénéfices de l’opération.

Une méthodologie complète de renouvellement ne se limite pas aux aspects techniques de la transformation des applications VB6 en .NET. Elle comprend également l’élaboration de la stratégie de migration optimale en fonction de nombreux entrants. Elle prend aussi en compte l’état des applications actuelles, le plan d’évolution technique et fonctionnel, les attentes vis-à-vis du programme de renouvellement et les éventuelles contraintes. Le choix d’un partenaire qui a l’expérience de la réalisation complète d’initiatives de ce type est recommandé.

Nous l’avons déjà mentionné, mais nous souhaitons insister sur ce point : au cours de nos nombreuses interventions auprès

d’organisations très diverses, nous avons fréquemment observé une tendance à préférer la réécriture combinant la transition vers

.NET, une opération de réingénierie et la mise en œuvre de nouvelles fonctionnalités dans le même lot de travail. L’objectif est

généralement de justifier plus facilement le business case par l’ajout de nouvelles fonctionnalités. Mais ce choix est rarement

approprié quand l’objectif essentiel est d’abandonner une plate-forme obsolète.

Cette approche rend le processus moins maîtrisable et expose l’entreprise à de multiples difficultés. De plus, son coût la

rend difficile à justifier et elle est souvent rejetée. L’organisation est alors amenée à repousser l’opération de

renouvellement, avec les conséquences que ce décalage implique.

Le même résultat pourrait pourtant être atteint par une migration suivie d’évolutions. Nous avons exposé ici le détail des avantages métier d’une migration à équivalence fonctionnelle, dont un coût plus faible et une meilleure maîtrise. Quand elle est suivie d’une évolution des applications migrées, son business case combiné est solide et les résultats sont les mêmes, avec un niveau de risque

nettement plus faible.


Notes

Migrations VB6

Pour plus d’informations :

Si votre organisation utilise des applications VB6 et si vous voulez mieux comprendre comment la méthodologie d’Avanade et l’offre produit d’ArtinSoft peuvent vous aider à trouver l’approche de renouvellement qui répond le mieux à vos besoins, contactez nous :

Avanade – www.avanade.com ArtinSoft – www.artinsoft.com

Avanade et ArtinSoft proposent des interventions pré-packagées qui facilitent un démarrage rapide du processus de migration :

Atelier sur le renouvellement VB6 : Atelier conçu pour couvrir la définition du périmètre du portefeuille d’applications VB6 à migrer, l’évaluation préliminaire des choix de migration pour chacun d’eux et la prise de connaissance de vos attentes ;

Évaluation du renouvellement d’un portefeuille VB6 : Évaluation formelle de la base de code actuelle, analyse détaillée des motifs métier de la migration, architecture actuelle et cible, capacités et processus actuels, fonctions métier prises en charge par le portefeuille d’applications, etc.

Ces ateliers, associés à notre expérience, peuvent vous aider à mener à bien votre mission de migration. Le choix du bon scénario et des bons partenaires fait toute la différence.

Avec plus de quinze ans d’expérience, ArtinSoft s’est révélé un acteur privilégié de la transformation de

logiciels, en permettant à ses clients dans le monde entier de garantir la continuité des activités et la

conformité grâce à ses solutions de migration et ses outils de développement. Basée sur les principes de

l’intelligence artificielle et animée par la passion de l’innovation, cette société est aujourd’hui le leader de facto

du renouvellement des applications VB6, avec un record mondial exceptionnel de nombre de projets de

migration réels, et une croissance permanente au travers d’un réseau de partenaires stratégiques. Les

solutions d’ArtinSoft permettent aux organisations de ne pas perdre des années d’investissements

intellectuels et financiers. De plus, les produits d’ArtinSoft peuvent être entièrement personnalisés. Ils sont

aussi accompagnés de formations et d’options d’assistance technique.

À propos d’Avanade Avanade fournit des services métier, fonctionnels et technologiques qui allient vision, expertise et innovation sur les technologies Microsoft afin d’aider ses clients à concrétiser leurs objectifs. Les solutions d’Avanade aident les entreprises dans tous les secteurs d’activité à améliorer leurs performances, leur productivité et leur chiffre d’affaires. Grâce à son réseau mondial de consultants experts

Microsoft, Avanade est à même de combiner de manière optimale la mobilisation de ses consultants onshore, offshore et nearshore et de délivrer au bon compromis entre délais, coûts et risques. Avanade, dont l’actionnaire majoritaire est Accenture, a été créée en 2000 par Accenture et Microsoft Corporation. Elle a des clients dans plus de 24 pays dans le monde et emploie plus de 9 700 personnes. Pour plus d’informations, consultez : http://www.avanade.com/fr/. ©2010 Avanade Inc. All rights reserved. Le nom et le logo d’Avanade sont des marques déposées aux États-Unis et dans d’autres pays. Les autres marques et noms de produit sont des marques de leurs propriétaires respectifs.

Amériques Seattle Téléphone : +1 206 239 5600 Europe Paris Avanade France 125, avenue de Paris 92320 Châtillon

Téléphone : +33 1 47 46 66 00 Fax : +33 1 47 46 66 01

Asie-Pacifique Sydney Téléphone : +612 9005 5900

http://www.avanade.com/

http://www.artinsoft.com/

http://www.avanade.com/fr/

la migration de visual basic 6 vers .net

Technology

renouvellement et squencement

approche et stratgie

code et conclusions

vif succs et

conception et mise en

rsum visual basic

migrations vb6 table

rcriture ou prennisation