Exporter (0) Imprimer
Développer tout

Mise en œuvre d’une stratégie de migration de Visual Basic 6.0 vers Visual Basic .NET

Visual Studio .NET 2003
Paru le 1er Avril 2004

Auteurs :
Iván Sanabria, Alexander Gómez, Alvaro Rivera, Carlos Maroto, Héndel Valverde, Federico Zoufaly, ArtinSoft

S'applique à :
Microsoft Visual Basic 6.0
Microsoft Visual Basic .NET
Microsoft Visual Studio .NET 2003
Microsoft Visual Studio .NET 2005
Microsoft .NET Framework 1.1
Microsoft .NET Framework 2.0

Résumé : Cet article présente le processus de migration de Visual Basic 6.0 vers Visual Basic .NET. Il aborde tous les aspects de la migration, depuis l'analyse des exigences techniques et économiques aux recommandations pour choisir une solution de migration (recommandations qui intègrent les stratégies reconnues et les meilleures pratiques). Vous apprendrez comment réduire au minimum les délais et le travail nécessaires pour la migration, en adoptant des stratégies qui ont fait leurs preuves.

 http://msdn.microsoft.com/VBasic/Learning/Migrating/Default.Aspx?pull=/library/en-us/dv_vstechart/html/appmigrationstrat.aspLire l'article en anglais

 http://download.microsoft.com/download/D/5/D/D5DBD51B-D054-4D43-B483-96056EA505D1/strategie_migration_VB6_VBNET.docTéléchargez le document dans sa totalité au format Word

Introduction

De nombreuses idées fausses circulent sur la méthode la plus appropriée pour mettre à niveau une application Visual Basic 6.0 vers Visual Basic .NET et sur le travail nécessaire pour cette migration. L'objectif de ce document est de vous aider à préparer au mieux votre stratégie de migration. Il décrit notamment les facteurs dont vous devez tenir compte au cours des diverses étapes d'une migration réussie. Il recommande également les meilleures pratiques qui ont été identifiées à l'occasion de différents projets de migration.

Quelques facteurs courants motivent la modernisation des applications Visual Basic. Ils vont des facteurs de type « réaction », où l'application Visual Basic 6.0 doit pouvoir répondre à de nouveaux besoins métier, à ceux de type « anticipation », où l'entreprise veut optimiser l'application actuelle pour saisir une opportunité de se développer, d'élargir sa clientèle ou encore d'ajouter de nouveaux produits et services à son offre. Ces facteurs incluent également la nécessité d'augmenter l'efficacité opérationnelle pour contrebalancer les frais de maintenance élevés des applications obsolètes, tout en maximisant les avantages liés à l'utilisation de la technologie .NET.

Migrer, remplacer, réécrire ou réutiliser ?

Quand une entreprise est parvenue à la conclusion qu'une application Visual Basic ne répond plus à ses besoins et qu'elle ne peut plus l'ignorer, elle pense à la modernisation. Elle doit pourtant d’abord d'étudier les alternatives possibles à la modernisation. Les critères de décision sont (i) la qualité du code de l'application et (ii) la valeur économique de l'application. Dans ce cas précis, la qualité se rapporte à l'adéquation de l'application aux besoins métier et techniques. Elle doit être évaluée en fonction des paramètres suivants :

  • Efficacité actuelle : erreurs générées, solutions de rechange, niveau de support requis, etc.

  • Stabilité et exhaustivité des principales règles métier : la logique de l'application changera-t-elle dans un avenir proche ? Ce document part du principe que la valeur de l'application logicielle actuelle est prouvée. S'il s'avère que le modèle métier est appelé à être radicalement modifié, ce principe doit être remis en question. En pratique, le code représente souvent l’ensemble des règles métier. Par conséquent, si vous décidez de réécrire intégralement le code, vous devrez décrire et documenter les besoins pris en charge par le code actuel et utiliser votre document comme point de départ pour intégrer les nouveaux besoins.

  • Phases du cycle de vie : durant les phases initiales de son cycle de vie, une application offrira l'ensemble des fonctionnalités requises, même sur une plate-forme obsolète.

  • Environnement de développement : il est essentiel d'évaluer les capacités de l'équipe de développement et de l'environnement, requises pour mener à bien la modernisation. La familiarisation du développeur avec le code source de l'application et les technologies cibles, et sa capacité à résoudre les problèmes de modernisation identifiés durant l'évaluation du code sont primordiales. De façon générale, il est recommandé que les développeurs associés au projet soient des utilisateurs chevronnés de Visual Basic .NET. Par ailleurs, vous devez prendre en considération d'autres facteurs tels que l'existence de scénarios de test.

La valeur économique est un autre élément clé dont il faut tenir compte ; elle est fonction de l'unicité de l'application. Si l'application est de qualité médiocre et que d'autres logiciels tiers offrent les mêmes fonctionnalités, mieux vaut la remplacer.

Quatre possibilités de modernisation s'offrent à vous : la migration, la réutilisation, la réécriture ou le remplacement de l'application ou de certains de ses composants. La figure 1 illustre le rapport entre les critères de décision et le processus de modernisation.


Figure 1. Options de modernisation

  • Migrer : si l'application Visual Basic répond aux besoins actuels de l'entreprise et qu'elle est de bonne qualité, elle peut sans doute être modernisée afin de satisfaire les besoins futurs de l'entreprise. Dans ce cas, vous pouvez mettre en place un processus de migration. Il vous suffira ensuite d'ajouter de nouvelles fonctionnalités et d'étendre les capacités existantes, en fonction des besoins. Dans cet article, toute mention à une migration ou à une mise à niveau fait référence à une migration automatique exécutée à l'aide de l'Assistant Mise à niveau de Visual Basic, intégré dans Visual Studio .NET.

  • Réutiliser : deux cas de figure sont possibles ici : l'application est basée sur un logiciel tiers/SGBD ou elle a été intégralement développée par l'entreprise. Si le portefeuille des applications Visual Basic 6.0 est essentiellement centré sur un logiciel tiers, la meilleure façon d'évoluer peut consister à les mettre à niveau vers la dernière version du logiciel, puis à utiliser des techniques d'encapsulation (ou « wrapping ») pour étendre leur portée et apporter les améliorations souhaitées. Dans le cas d'une application développée en interne, vous pouvez encapsuler ses composants afin de les intégrer dans la nouvelle solution développée.

  • Réécrire : les règles métier et les structures de données sont ici les éléments clés. L'application est le problème. Le point de départ de l'opération de réécriture consiste à explorer l'application en analysant la logique du code et les structures de données.

  • Remplacer : identifiez un logiciel ou un prestataire approprié. Vous devrez peut-être modifier le modèle métier de manière à le faire coïncider avec le logiciel.

Afficher:
© 2014 Microsoft