View
823
Download
1
Category
Tags:
Preview:
DESCRIPTION
Plateforme la plus répandue dans l'histoire de Microsoft, Visual Basic 6 a été progressivement supplantée par la nouvelle plateforme, .NET, avant de voir son support cesser courant 2008. Un problème sérieux se pose pour les nombreuses entreprises utilisant des applications sous VB6. La solution la plus simple et la plus adaptée est sans aucun doute la migration de ces applications vers un environnement .NET. C'est l'objet de ce livre blanc que de présenter une métoodologie de migration pensée conjointement par ArtinSoft et Avanade, intégrateur expert de solutions Microsoft.
Citation preview
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.
© 2011 Avanade Inc. All Rights Reserved. 4
Migrations VB6
L’expérience d’Avanade et d’ArtinSoft a été mise à l’épreuve dans des scénarios très variés, depuis les plus petites applications
autonomes jusqu’au renouvellement de portefeuilles complets d’applications d’entreprise. Ce processus est suffisamment souple
pour s’adapter à la migration d’applications monolithiques, multi-tiers ou d’applications Web ASP. Cependant, pour des raisons de
simplification, nous ferons référence à la source sous le terme de « VB6 » dans tout le reste de ce document.
3. Les motifs de renouvellement des applications
Les motifs de la modernisation des applications VB6 sont multiples et la plupart d’entre eux s’applique à tous les renouvellements
d’applications. Ils vont de considérations tactiques liées à l’obligation de réagir à l’évolution des besoins métier, jusqu’à des objectifs
plus stratégiques qui exigent l’introduction de changements radicaux dans le cadre du processus de renouvellement.
Parmi les motifs de renouvellement les plus fréquents rencontrés sur nos projets (et confirmés par l’étude d’Aberdeen Group), on peut citer :
Des raisons tactiques :
o Minimiser le délai de mise sur le marché ;
o Assurer le respect des normes et standards et la conformité avec les plates-formes prises en charge, et donc
éliminer le risque lié à l’exécution d’applications sur des plates-formes non supportées ;
o Réduire les coûts d’exploitation et de maintenance ;
o Atténuer le risque lié au manque de ressources compétentes en VB6 ;
o Améliorer la conformité de la solution existante aux exigences techniques et fonctionnelles.
Stratégiques
o Consolider et standardiser les technologies sur lesquelles s’appuient les actifs logiciels ;
o Rationaliser le processus de développement ;
o Faciliter et simplifier l’intégration effective avec les technologies SOA et les diverses normes du secteur ;
o Simplifier le déploiement ;
o Améliorer la fiabilité et l’extensibilité ;
o Augmenter la productivité des développeurs ;
o Améliorer la sécurité.
Dans cette méthodologie, la phase d’évaluation comprend un aspect important de compréhension de la pertinence des motifs du
renouvellement pour l’entreprise concernée. Cette compréhension est déterminante dans l’identification d’une stratégie de
renouvellement optimale en fonction des besoins de l’organisation et d’une approche assurant la mise en valeur des bénéfices de la
migration.
Notre expérience des programmes de renouvellement de grande ou moyenne ampleur nous montre que la transition d’un portefeuille
d’applications de VB6 vers .NET est complexe, mais que l’application d’une méthodologie adaptée et une planification anticipée
permettent d’en assurer la faisabilité et de répondre aux motifs exprimés ci-avant, avec un niveau de coût et de risque minimaux.
Les études statistiques réalisées dans le cadre de l’étude d’Aberdeen Group et les retours de nos clients encouragent à la migration
de VB6 vers .NET pour de multiples raisons :
Délai de mise sur le marché : L’adoption d’un environnement de développement très efficace et la simplification de l’intégration avec
des technologies standard ont dans certains cas permis une réduction de 50 % du délai de mise en œuvre de nouvelles
fonctionnalités.
© 2011 Avanade Inc. All Rights Reserved. 5
Migrations VB6
Coûts de développement : La meilleure disponibilité de ressources compétentes et motivées, associée à une amélioration
de la gestion du cycle de vie des applications que facilite des outils tels que Visual Studio Team System, a permis des
économies sur les coûts de développement et de programmation pouvant atteindre 20 %.
Performance : Le passage à .NET peut être source d’une amélioration de la performance des solutions migrées pouvant atteindre
40%, ce qui permet de réduire les coûts d’exploitation et les interruptions de service.
Sécurité : Grâce à des fonctions complètes de sécurité, .NET améliore la sécurité de la solution migrée sans alourdir la
tâche des développeurs.
Déploiement : Avant le lancement de .NET, le déploiement d’applications clientes exigeait souvent d’utilisation de privilèges élevés
dans le système, ce qui mettait en péril sa stabilité et sa sécurité. Avec .NET, le déploiement peut être effectué de manière plus
isolée, ce qui simplifie considérablement le processus et réduit les coûts d’assistance à long terme.
Une autre conclusion intéressante de l’étude d’Aberdeen Group est le fait que les bénéfices de la migration sont quasiment
doubles si l’organisation décide d’avoir recours à l’expérience de prestataires externes pour une assistance ou une prise en
charge complète de la migration (80 % contre 42 %).
Avanade et ArtinSoft sont déjà investi des dizaines de millions d’euros dans la conception d’une technologie de migration
efficace en affinant leur méthodologie et en développant les compétences de plusieurs centaines de personnes.
Pour de nombreuses organisations, il est plus logique d’exploiter ce capital de connaissances que d’entreprendre son
développement ex-nihilo. La priorité stratégique est généralement la focalisation des ressources sur le développement de
compétences nécessaires à la plate-forme cible, plutôt que la migration en elle-même, qui constitue un effort ponctuel.
Comme nous allons le montrer dans la section qui suit, une autre approche consiste à laisser les applications VB6 en l’état,
cette approche n’étant pas dépourvue de risques.
Pour beaucoup d’organisations, l’infrastructure applicative et logicielle sur laquelle s’appuie l’activité métier est un patchwork
d’applications comprenant des systèmes vieillissants qui ne sont plus pris en charge par aucun fournisseur, ni par les équipes
internes. La valeur métier inhérente à la plupart des anciens systèmes est parfois discutable car les entreprises ont consacré
beaucoup d’énergie aux travaux liés à la conformité et ont repoussé indéfiniment les projets de modernisation de l’informatique, en
négligeant leur importance à long terme.
Les organisations les plus visionnaires savent qu’un système informatique robuste, moderne et extensible est une base
indispensable pour répondre aux besoins métier de manière efficace et réactive. Aujourd’hui, il est à la fois possible et urgent de se
libérer des contraintes des anciens systèmes informatiques en migrant vers une plate-forme moderne.
Dans le cas particulier de VB6, le maintien en production des systèmes basés sur cette technologie représente de multiples risques.
1. Absence de support à l’environnement de développement : L’environnement de développement intégré (IDE) de VB6
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
© 2011 Avanade Inc. All Rights Reserved. 6
Migrations VB6
2. Composants tiers : Bien que Microsoft assure encore le support de l’environnement d’exécution de VB6, ce n’est pas
forcément le cas des fournisseurs de composants. La plupart des applications VB6 contiennent des composants fournis par
des tiers, et, à mesure que leurs fournisseurs transfèrent leurs ressources vers des composants .NET, le niveau de support
et de compatibilité diminue.
3. Conformité réglementaire : La loi Sarbanes-Oxley aux États-Unis, et les réglementations similaires comprennent des règles
implicites sur la question de l’exécution de systèmes sur des plates-formes non prises en charge par leur fournisseur. VB6
est, au mieux, sur la limite dans ce domaine, voire en passe d’être exclus.
4. Compatibilité 64-bit : L’environnement d’exécution Visual Basic a été conçu pour des systèmes 32-bit et Microsoft est déjà
en train de retirer progressivement ses systèmes d’exploitation 32-bit du marché. Par exemple, l’exécution d’applications
32-bit sur Windows Server 2008 R2 n’est pas l’option par défaut.
4. Approche et stratégie de renouvellement
Cette section décrit les différentes options de renouvellement généralement envisagées pour un portefeuille d’applications
existantes, ainsi que les aspects évalués pour prendre la meilleure décision en termes de stratégie et d’approche de
renouvellement.
4.1 Migration, remplacement, réécriture ou pérennisation
Une fois qu’il a été décidé qu’un portefeuille d’applications ne répond plus aux besoins métier, et que l’entreprise a compris que
l’inaction n’était pas envisageable, l’étape suivante est l’évaluation des applications et la décision de son éventuelle modernisation. Il
est généralement préférable de prendre cette décision application par application, et d’analyser ainsi tout le portefeuille.
Dans le cas d’une application indispensable à l’activité, il y a quatre possibilités de modernisation :
La migration : L’utilisation d’un outil semi-automatique tel que Visual Basic Upgrade Companion™ (également appelé VBUC™)
d’ArtinSoft permet d’assurer l’équivalence fonctionnelle, ce qui est la première étape de l’effort de modernisation. Les avantages de
cette approche sont liés à l’exploitation des investissements antérieurs (en particulier, s’il existe des règles métier importantes mais
mal documentées) et à la réduction du risque dans le processus de modernisation.
Le remplacement : Il s’agit de la recherche d’une application commercialisée sur le marché et à même de remplacer la fonctionnalité
métier. L’organisation doit dans ce cas être prête à accepter des changements dans ses processus pour s’adapter à l’application
choisie. En retour, elle bénéficiera d’une approche fonctionnelle élaborée par des spécialistes.
La réécriture, ou tout recommencer ex-nihilo. La réécriture d’une application couvre l’ensemble du cycle de vie, depuis l’expression
des besoins jusqu’à la formation des utilisateurs et au déploiement. L’avantage de cette approche est que l’organisation peut intégrer
de nombreuses modifications, depuis les règles métier jusqu’à l’architecture technique de l’application. Mais c’est aussi l’option la
plus coûteuse et la plus risquée. Ce choix est souvent la cause d’une explosion du périmètre, des budgets et des délais.
La pérennisation. C’est aussi le choix de « ne rien faire », ou l’option par défaut. Il n’y a pas d’investissement immédiat, mais à long
terme, les risques d’obsolescence et le coût potentiel d’une décision augmentent.
Il convient de se poser un certain nombre de questions afin d’évaluer chaque application et de décider du meilleur choix de modernisation :
Dans quelle mesure les fonctionnalités de l’application sont-elles uniques dans ce métier ? Existe-t-il un logiciel tiers
disposant de fonctionnalités comparables ? Par exemple, si l’entreprise utilise une application de comptabilité générale qui
ne présente pas caractéristiques spécifiques à son métier, ou une application banale qui ne lui apporte pas d’avantage
concurrentiel particulier, alors la décision d’acheter un progiciel du commerce doit être envisagée.
© 2011 Avanade Inc. All Rights Reserved. 7
Migrations VB6
Toutefois, si l’application est source d’un avantage concurrentiel, il y a des chances qu’elle soit unique et qu’elle contienne
une logique spécialisée qui devrait être migrée.
Quelle est la qualité technique de l’application ? Quel est le nombre moyen d’anomalies qui ont dû être réparées au cours
des derniers mois ? Quelle est la fiabilité des résultats produits par l’application ? L’application est-elle extensible, ou quel est
l’investissement nécessaire pour la rendre plus extensible ? L’application est-elle facilement maintenable? Si les réponses
aux questions ci-dessus sont négatives, alors la migration de l’application vers un nouveau langage avec une approche semi-
automatique n’est probablement pas la meilleure approche, et il serait préférable d’envisager plutôt une réécriture. Dans le
cas contraire, l’entreprise doit envisager une migration pour pouvoir profiter de tous les avantages liés à une plate-forme de
développement logiciel moderne.
Les fonctionnalités de l’application changent-elles rapidement avec les objectifs métier ? Le processus métier auquel
s’adresse l’application est-il stabilisé ? Le service informatique ne prévoit-il que des changements très mineurs avant la mise
hors service ? Qu’en est-il des erreurs générées, du nombre de solutions de contournement, du niveau d’assistance
nécessaire ? Si l’application est très stable et qu’elle ne changera pas beaucoup dans un futur proche, alors l’entreprise
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.
© 2011 Avanade Inc. All Rights Reserved. 8
Migrations VB6
Le schéma ci-dessous montre l’effort d’une migration par rapport à celui d’une réécriture.
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.
© 2011 Avanade Inc. All Rights Reserved. 9
Migrations VB6
Une fois que toutes les applications qui exigent une migration ont été identifiées, avec leurs dépendances, alors les plans de
migration individuels peuvent être élaborés.
4.2.2 Équivalence fonctionnelle et évolution des applications
Le processus de migration d’une application selon la méthodologie de semi-automatique doit comprendre deux étapes clairement définies : l’équivalence fonctionnelle et l’évolution de l’application.
L’équivalence fonctionnelle exige de migrer une application vers la nouvelle technologie en conservant exactement les mêmes
fonctionnalités. Une fois l’équivalence fonctionnelle atteinte, le processus de migration est terminé et l’application tourne sur la
nouvelle plate-forme. Les fonctionnalités ont été testées et leur équivalence a été vérifiée. L’application peut être déployée auprès
des utilisateurs qui remarqueront à peine la différence.
Le fait de viser l’équivalence fonctionnelle pour une application que vous avez l’intention de modifier ensuite peut sembler paradoxal
au premier abord, mais notre expérience nous a montré que cela permet de disposer d’une base solide pour une approche contrôlée
et de réduire le niveau de risque.
Différents facteurs contribuent à rendre la transition à équivalence fonctionnelle attirante, le principal étant l’idée de remettre de l’ordre
dans les systèmes le plus tôt possible. Le délai et le coût correspondant d’une réécriture totale de l’application rendent souvent
impossible l’élaboration d’un business case de renouvellement viable. Par conséquent, la décision d’abandonner l’ancienne
technologie est remise à plus tard. Avec des systèmes développés au fil des ans, il faut souvent du temps aux développeurs pour
comprendre les subtilités de l’application et les reproduire sur une plate-forme différente. De plus, le risque d’explosion du périmètre
est important.
En outre, il y a des avantages à adopter une approche par étape, en migrant d’abord l’application automatiquement vers .NET à
équivalence fonctionnelle parfaite. D’un point de vue opérationnel, .NET simplifie de façon très importante le déploiement et améliore
les performances générales, l’extensibilité et la fiabilité. Du point de vue du développement, il y a une amélioration très nette de
l’ensemble de la solution et de son cycle de vie, avec des outils plus pratiques de gestion de configuration, une automatisation de la
construction, des tests, de l’analyse et de la refactorisation, etc. De plus, certaines organisations sont dans l’obligation de migrer vers
.NET. C’est le cas des éditeurs indépendants qui ont de plus en plus de mal à vendre des logiciels basés sur VB6, ou encore, des
sociétés soumises à des réglementations strictes qui imposent que toutes les applications essentielles fonctionnent sur des plates-
formes prises en charge.
Une fois l’équivalence fonctionnelle atteinte, l’application est prête pour sa prochaine refonte ou son évolution applicative. Si une
application est migrée, c’est parce qu’elle est encore au début de son cycle de vie et fournira des années de service au métier. Il
est donc probable qu’elle va évoluer encore après la migration, même si ce n’est pas nécessairement immédiat. L’évolution d’une
application implique à la fois l’intégration de nouvelles fonctionnalités et la modification/prolongation des parties de l’application
aptes à bénéficier des nombreuses améliorations que .NET offre.
4.2.3 Atteindre l’équivalence fonctionnelle
L’équivalence fonctionnelle pour une application donnée peut passer par une migration complète ou progressive.
Avec une stratégie de migration complète, l’organisation met à niveau toutes ses applications en même temps et ne met pas de code
en production tant que l’application complète n’est pas migrée et opérationnelle sur la nouvelle plate-forme. La stratégie de migration
progressive permet la mise à niveau de certaines parties de l’application avant d’autres.
© 2011 Avanade Inc. All Rights Reserved. 10
Migrations VB6
Le deuxième choix comporte moins de risques, mais il exige plus de travail pour permettre l’interopérabilité entre les parties
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.
© 2011 Avanade Inc. All Rights Reserved. 11
Migrations VB6
Sur la base de leur expérience, Avanade et ArtinSoft recommandent dans ces scénarios d’éviter de traiter la migration des
applications et la migration des données en même temps. Une migration conjointe rend les tests plus complexes, présente
des risques supplémentaires de perturbation des opérations courantes et accroit les difficultés techniques en cas d’obligation
de retour en arrière.
Il est préférable d’exécuter la migration des bases de données une fois que les applications VB6 sont migrées vers .NET.
5. Processus de migration des applications
Un effort de migration doit viser plusieurs objectifs. Ces objectifs sont liés aux critères utilisés dans la plupart des cas pour mesurer
le succès d’un projet de migration :
Réalignement sur les programmes informatiques en cours et à venir ;
Réalignement avec le plan d’évolution métier ;
Minimisation des risques et des perturbations ;
Minimisation des coûts ;
Minimisation de la durée.
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.
© 2011 Avanade Inc. All Rights Reserved. 12
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.
© 2011 Avanade Inc. All Rights Reserved. 13
Migrations VB6
5.1.1 Collecte des informations de contexte
Il est essentiel de disposer d’une compréhension claire des raisons pour lesquelles une organisation prévoit un programme de
renouvellement. Ces informations aident à définir la meilleure stratégie de renouvellement et à planifier l’approche d’évaluation la
plus efficace, et donc à collecter toutes les données pertinentes à une prise de décision informée.
La première question à poser au début du processus de migration est évidemment : « Pourquoi ? »
La compréhension des raisons de la migration exige la compréhension des facteurs qui imposent le programme de renouvellement.
Ils appartiennent d’ordinaire à deux catégories générales :
Métier : Par exemple, changement considérable des conditions du marché, conformité à de nouvelles réglementations,
meilleure adéquation avec la vision à long terme de l’organisation, etc.
Technologie : Par exemple, absence de support, ou coût de support trop élevé, réduction du coût total de possession (TCO),
consolidation dans le cadre d’une fusion/acquisition, etc.
Un autre aspect à envisager dès le début est l’ensemble des attentes de l’organisation vis-à-vis du programme de renouvellement
et les contraintes qui s’appliquent au scénario considéré. La liste non exhaustive qui suit indique certains des éléments à
considérer :
Approche de migration préférentielle : Elle est d’ordinaire déterminée suite à une évaluation détaillée, mais il peut exister
des contraintes et des situations à prendre en compte.
Langage et/ou plate-forme cible : Par exemple, choix du langage vers lequel faire migrer l’application (VB .NET ou C#,
etc.).
Délai : Contraintes sur la durée et sur le calendrier de l’effort de renouvellement en vue de minimiser l’impact sur les
activités actuelles ou planifiées.
Besoins supplémentaires : Les attentes vis-à-vis d’un effort de migration ne sont pas limitées à l’équivalence fonctionnelle.
Elles incluent aussi des besoins complémentaires (fonctionnels ou non).
Périmètre : L’ensemble des applications concernées par le programme de renouvellement doit être défini, car c’est sur cet
ensemble que sera menée l’évaluation. Outre la connaissance de la liste des applications à migrer, il est aussi nécessaire de
prendre en compte toute contrainte ou alternative possible en termes de périmètre de la migration (par exemple, la migration
partielle d’une application est-elle envisageable ?)
5.1.2 Analyse préliminaire du code et conclusions
Bien qu’une évaluation formelle du code soit prévue plus tard dans le processus, quelques indicateurs de haut niveau liés aux
applications incluses dans le périmètre peuvent être recueillis avec une charge de travail limitée. Il est préférable ne pas tirer de
conclusions trop hâtives des indicateurs sur le code disponibles à ce moment-là. Cependant, ils peuvent aider à estimer le délai
nécessaire pour réaliser une évaluation plus précise. Parfois, ils peuvent même fournir les données nécessaires à une estimation
grossière de l’effort de migration complet.
5.1.3 Planification de l’évaluation
La phase de préparation est normalement suivie de l’évaluation. L’évaluation détaillée est un projet en elle-même. Il est donc
nécessaire d’élaborer un plan de travail. Celui-ci doit être partagé afin de confirmer que les attentes sont prises en compte. Il doit
aussi exposer clairement certains points :
© 2011 Avanade Inc. All Rights Reserved. 14
Migrations VB6
Les activités couvertes par l’évaluation ;
La participation des parties prenantes à chaque étape ;
L’estimation de la charge de travail des activités planifiées ;
Les hypothèses émises sur les exigences et nécessaires à l’exécution de l’évaluation.
5.2 Planification de l’évaluation
La réussite du renouvellement d’un grand portefeuille d’applications dépend de plusieurs facteurs :
L’approche de renouvellement choisie pour chaque application ;
Le mode de réalisation (onshore/nearshore/offshore/multi-sites) ;
Le calendrier et le séquencement des activités ;
La stratégie de gestion des versions (progressive ou complète).
D’un point de vue métier comme technique, la variété des choix possibles et les conséquences potentielles de chacun impose
une évaluation précise avant le lancement de toute activité de renouvellement sur le portefeuille d’applications actuel.
L’objectif principal d’une évaluation est de générer une stratégie détaillée de renouvellement. Cette stratégie doit esquisser le
déroulement optimal de la transition, avec une indication claire des processus, des outils et des compétences nécessaires à chaque
étape. Elle doit aussi donner une estimation précise du coût, de la charge de travail et de la durée.
Une évaluation complète implique à la fois une analyse statique de la base de code lié aux applications visées par le renouvellement,
et l’étude d’informations supplémentaires obtenues au travers d’entretiens et d’enquêtes. Les étapes qui suivent donnent un bon
aperçu du contenu d’une évaluation :
Identification du périmètre de l’évaluation ;
Évaluation du code ;
Entretiens avec les parties prenantes ;
Enquête sur le portefeuille d’applications ;
Approche et séquencement du renouvellement ;
Estimation de la charge de travail ;
Planification ;
Présentation des résultats.
5.2.1 Identification du périmètre de l’évaluation
Un aspect essentiel dès le départ est la définition du périmètre exact de l’évaluation. Elle implique l’énumération des applications
(et des composants correspondants) visées par la migration et la collecte de l’ensemble des fichiers de code source associés.
À première vue, cela peut sembler une activité mineure, mais elle est parfois très consommatrice de temps et sujette à erreurs.
Il est recommandé d’y impliquer des ressources expérimentées et d’utiliser des outils à même d’automatiser certaines étapes.
Ceci réduira la durée de l’activité et les risques associés.
© 2011 Avanade Inc. All Rights Reserved. 15
Migrations VB6
Une des tâches nécessaires est l’identification des délimitations précises entre les applications par la séparation des composants
appartenant à chaque application. La notion d’application n’est pas universellement partagée. Il est donc important de définir et
d’appliquer une approche cohérente qui correspond au contexte.
Voici quelques règles qui ont fait leurs preuves :
Les applications et les composants identifiés définissent le niveau de granularité de l’analyse réalisée pendant l’évaluation ;
Les tâches telles que la planification de la migration, ou l’estimation de la charge de travail s’appuient sur les délimitations
entre applications identifiées pendant cette étape. Ceci confirme leur importance.
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.
© 2011 Avanade Inc. All Rights Reserved. 16
Migrations VB6
Complexité de la migration
Toutes les lignes de code ne naissent pas égales ! Par conséquent, certaines applications peuvent exiger plus d’effort à la
migration que d’autres. Il existe des facteurs bien connus qui peuvent contribuer à rendre la migration d’un composant VB6 vers
.NET plus ou moins complexe :
1. L’utilisation de composants externes ;
2. Le nombre d’appels à des API Windows natives ;
3. La présence de mots-clés VB obsolètes ;
4. La technologie d’accès aux données utilisée ;
5. La taille de l’application ;
6. La complexité des interactions avec les autres applications, etc.
La complexité d’un composant spécifique est calculée en attribuant une note à chacun de ces facteurs et en calculant un
niveau de complexité général par la pondération des notes individuelles en fonction de notre expérience.
Besoins complémentaires
Comme nous l’avons déjà dit, la migration automatisée produit une application fonctionnellement et architecturalement équivalente
dans laquelle le flux et la logique du code sont conservés. Parfois, certains besoins complémentaires et non fonctionnels viennent
pourtant s’y ajouter (par exemple, le respect de normes de codage, l’utilisation de composants architecturaux déjà disponibles dans
l’architecture cible .NET, etc.).
Ces besoins sont précisément évalués en fonction de l’application actuelle afin de déterminer s’ils doivent être pris en compte
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.
© 2011 Avanade Inc. All Rights Reserved. 17
Migrations VB6
Revue de l’application
Lancement Assurance qualité
Architecture technique
Revue de l’application
Conclusion
Revue de l’application
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.
© 2011 Avanade Inc. All Rights Reserved. 18
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.
© 2011 Avanade Inc. All Rights Reserved. 19
Migrations VB6
5.2.5 Approche et séquencement du renouvellement
Un des aspects de la stratégie de renouvellement traité pendant l’évaluation est la définition d’une approche de renouvellement et
son séquencement pour chacune des applications identifiés dans le portefeuille. Un ensemble de critères affiné par des experts au fil
des projets nous aide à traiter toutes les informations et les constatations tirées de l’évaluation, afin d’émettre des recommandations
raisonnables.
En premier lieu, toutes les applications sont évaluées selon différents aspects, y compris :
L’état de santé de l’application : Il est déduit de la combinaison de l’adéquation fonctionnelle et technique de l’application. L’adéquation fonctionnelle couvre (entre autres) le degré de complétude des fonctions fournies par l’application actuelle par rapport aux exigences de l’activité, le délai de déploiement des nouvelles fonctions nécessaires pour satisfaire de nouveaux besoins, le niveau de service, l’adéquation future aux besoins métier, et d’autres aspects similaires. L’adéquation technique couvre la performance, l’extensibilité, l’interopérabilité, le respect des normes de l’entreprise, la disponibilité et d’autres facteurs techniques.
Impact métier : C’est une façon de mesurer le degré de priorité de l’application pour l’entreprise. Il est déterminé par l’évaluation
de la capacité de chaque application à prendre en charge une ou plusieurs exigences générales fonctionnelles ou techniques
(par exemple, l’orientation stratégique, l’innovation, la productivité du personnel, la réduction des coûts de maintenance, etc...)
Complexité du renouvellement : Il s’agit d’une évaluation qualitative de la complexité de l’effort de renouvellement pour une
application spécifique. Différents facteurs doivent être considérés, selon l’approche de renouvellement. Par exemple, dans un cas
de réécriture (ou de réingénierie), l’analyse se concentre sur des données liées à la complexité et à la taille de chaque
application (par exemple, nombre de modules, complexité cyclomatique, etc.). En outre, dans une migration automatisée, la
complexité est surtout liée aux situations qui ne peuvent pas être migrées automatiquement (voir la section Évaluation du code).
Dépendances : Dans l’opération de répartition des composants visés par la migration afin de définir les limites de l’application, il
convient d’être particulièrement attentif à la définition d’un ensemble cohérent. Dans la plupart des cas, il est impossible d’éviter
complètement que des composants appartenant à une application dépendent de composants appartenant à une autre, et
inversement. Ces interdépendances peuvent affecter de manière significative le séquencement de la migration des applications
dans le portefeuille. C’est la raison pour laquelle il faut consacrer du temps pendant l’évaluation à l’identification des
dépendances et à l’enregistrement des données pertinentes, en particulier la gestion des interactions, le type d’informations
échangées, le protocole d’échange, etc...
Les critères de choix de l’approche de migration et de son séquencement s’appuient sur l’évaluation des combinaisons
suivantes pour chaque application (voir la figure 5) :
Impact métier et Complexité de la migration ;
Impact métier et État de santé de l’application.
© 2011 Avanade Inc. All Rights Reserved. 20
Migrations VB6
Figure 5 : Critères de détermination de l’approche et du séquencement de la migration
Comme l’explique la section 4 (Approche et stratégie de renouvellement), le principe majeur de choix de l’approche de migration
est que les applications dont la complexité de migration est raisonnable et qui sont en bonne santé sont de bons candidats à la
migration. En revanche, une approche de réécriture est plutôt recommandée pour les applications qui fonctionnent mal ou qui sont
trop complexes à migrer.
Pour ce qui concerne le séquencement de la migration, les facteurs de choix sont surtout liés à la priorité (impact métier) de
l’application et à sa santé actuelle, une priorité élevée et une mauvaise santé contribuant à faire remonter une application dans la
séquence de migration. Il convient également de réfléchir aux dépendances entre les applications (couplage) pendant la
détermination du séquencement.
© 2011 Avanade Inc. All Rights Reserved. 21
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.) ;
© 2011 Avanade Inc. All Rights Reserved. 22
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 :
© 2011 Avanade Inc. All Rights Reserved. 23
Migrations VB6
Périmètre du programme ;
Approche de renouvellement choisie pour chaque application ;
Calendrier de renouvellement des différentes applications ;
Dépendances avec les programmes informatiques en cours ou à venir ;
Périodes de gel du code ;
Mode de réalisation (onshore/nearshore/offshore/multi-sites).
La description du cadre complet d’élaboration d’une stratégie optimale de renouvellement n’est pas l’objet de ce document.
Cependant certaines recettes importantes et principes généraux issus de notre expérience sont donnés ci-dessous :
Minimiser les perturbations en alignant le projet sur les initiatives informatiques en cours et sur le plan d’évolution de
l’entreprise. La période de gel du code doit être minimisée, surtout pour les applications à maintenance courante lourde et
critique ;
Le séquencement de la migration devrait être déterminé en fonction d’un équilibre entre les priorités fonctionnelles et
techniques. Il doit prendre en compte les perturbations possibles et la charge supplémentaire dues au traitement préalable
des dépendances entre les applications ;
Un pilote de l’approche de migration permet d’ajuster le moteur de renouvellement sur tout le cycle de vie, et donc de
réduire les risques et de maximiser la productivité des développeurs ;
Si possible, migrer quelques applications « quick-win » dès le début, puis passer aux applications à impact/bénéfice élevé.
Cela aidera à maximiser le retour sur investissement de la migration et aidera à obtenir un consensus. Cette approche peut
faciliter une adoption précoce des applications migrées, ce qui contribue de manière significative au succès du programme ;
Définir une stratégie prudente de gestion des versions (une approche progressive est souvent préférable à un big-bang qui
peut comporter beaucoup de risques en cas de systèmes critiques).
Par ailleurs, certains principes supplémentaires concernent l’exécution de très grands programmes de renouvellement VB6 :
Adopter un « modèle industriel » pour réaliser des économies d’échelle : optimisation de l’utilisation des ressources sur
l’ensemble du cycle de réalisation, meilleur respect des standards et des processus, amélioration l’efficacité, etc.
Mettre en place un processus « industriel » efficace qui garantira le suivi des activités quotidiennes et des indicateurs de
performance, l’amélioration de l’efficacité des opérations et la coordination avec les fonctions métier du client.
Mettre en place un comité de gouvernance, incluant des parties prenantes internes et externes et chargé de fixer
l’orientation de la gestion de l’usine (hiérarchisation, gestion des changements, remontée des problèmes, etc.).
5.2.9 Présentation des résultats
Toutes les conclusions pertinentes et les livrables créés pendant les travaux d’évaluation sont résumés dans un rapport qui est
alors présenté. La présentation des résultats matérialise le lancement d’une phase du projet destinée à recueillir des retours et à
mettre au point l’approche de migration recommandée. Voici les activités généralement incluses dans ce processus
d’ajustement :
Revue du calendrier définitif du projet et acceptation ;
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.
© 2011 Avanade Inc. All Rights Reserved. 24
Migrations VB6
Confirmation de la stratégie de génération des cas de test et de l’approche générale de test ;
Revue et acceptation des besoins complémentaires qui s’ajoutent à l’équivalence fonctionnelle (par exemple, normes de codage, architecture cible, etc.) ;
Accord sur la fréquence des réunions et d’autres aspects du processus de communication.
Cette étape aboutit à la définition d’une approche générale et consensuelle de l’exécution du projet de migration.
5.3 Migration
Il est indispensable de disposer des bons outils et des bonnes compétences pour mener à bien un projet de migration
d’applications. Cependant, les lignes de conduite et les bonnes pratiques collectées au fil de projets précédents sont aussi
nécessaires afin d’exploiter au mieux ces outils et ressources. C’est la combinaison de tous ces éléments qui constitue une
méthodologie de migration.
Les paragraphes qui suivent décrivent les principaux lots d’activités inclus dans la méthodologie de migration conçue par Avanade et
ArtinSoft au fil d’années d’expérience. Cette méthodologie est destinée à permettre l’atteinte des objectifs définis pendant l’évaluation
du projet.
Lancement 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
© 2011 Avanade Inc. All Rights Reserved. 25
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.
© 2011 Avanade Inc. All Rights Reserved. 26
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.
© 2011 Avanade Inc. All Rights Reserved. 27
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.
© 2011 Avanade Inc. All Rights Reserved. 28
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.
© 2011 Avanade Inc. All Rights Reserved. 29
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.
© 2011 Avanade Inc. All Rights Reserved. 30
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.
© 2011 Avanade Inc. All Rights Reserved. 31
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
Recommended