Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l'analyse

Mise en œuvre d’une stratégie de migration de Visual Basic 6.0 vers Visual Basic .NET   Iván Sanabria Alexander Gómez Alvaro Rivera Carlos Maroto Héndel Valverde Federico Zoufaly ArtinSoft Avril 2005 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. (23 pages imprimées) 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 Table des matières Introduction Migrer, remplacer, réécrire ou réutiliser ? Savoir prendre la bonne décision Mettre en œuvre un projet de migration automatisée Conclusion Références 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. EMBED PBrush 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. Prendre la bonne décision Lors du lancement du projet, il est important de réaliser une étude de faisabilité pour évaluer la qualité technique et économique de l'application. Les listes de contrôle ci-après répertorient certains points à prendre en compte tandis que vous comparez les options disponibles. Liste de contrôle : migration L'application existante répond aux besoins actuels de l'entreprise. Peu de modifications de fonctionnalités requises dans l'application existante. Coûts d'exploitation de l'application existante élevés. Migration vers la technologie .NET Framework requise pour des raisons stratégiques. Utilisation de services Web ou accès Web prévus dans une version future. Base de code stable avec scénarios de test à l'appui. Ressources inexistantes pour la maintenance et la réparation des applications sur la plate-forme existante. Liste de contrôle : réutilisation Règles métier adéquates. Coûts d'exploitation de l'application existante peu élevés. Accès Web de base requis, avec possibilité de solution d'encapsulation. Ressources disponibles pour la maintenance de l'application Visual Basic 6.0 principale. L'application existante repose sur un logiciel disponible dans le commerce, dont la maintenance et le support sont assurés par un tiers. Liste de contrôle : réécriture Les fonctionnalités ne répondent pas aux besoins de l'entreprise. Aucune solution disponible dans le commerce n'est en mesure de répondre correctement aux besoins de l'entreprise. Code de mauvaise qualité dans la plate-forme existante et coûts de maintenance élevés. Possibilité de gérer les délais, les coûts et les interruptions engendrés par la réécriture. Utilisation du Microsoft .NET Framework requise pour des raisons stratégiques. Utilisation envisagée des services Web. Liste de contrôle : remplacement L'application est inadaptée aux besoins de l'entreprise. L'entreprise est disposée à modifier le modèle métier afin de l'adapter à une solution disponible dans le commerce, ou il existe une solution disponible dans le commerce qui répond précisément aux besoins de l'entreprise. Possibilité de gérer les délais, les coûts et les interruptions engendrés par le remplacement du logiciel. Les points ci-dessus peuvent s'appliquer à des applications complètes ou à certains de leurs composants. En règle générale, lorsqu'il s'agit d'une application de taille importante, plusieurs solutions de modernisation devront être combinées. En choisissant la méthode la plus appropriée pour un composant d'application spécifique, gardez à l'esprit que de nombreux développeurs affirmeront invariablement que la meilleure solution consiste à réécrire toute application nécessitant une mise à niveau. Ils estiment en effet que l'expérience acquise leur permettra d'écrire une seconde mouture plus performante. Il va sans dire que la réécriture d'une application mal conçue peut sembler une évidence, car elle permettra d'en corriger les lacunes. Toutefois, analysez tous les arguments pour la mise à niveau, la réécriture, le remplacement ou le maintien de l'application en Visual Basic 6.0 afin de vous faire la meilleure idée de ce qu'il convient de faire. Si l'application répond déjà aux besoins de votre entreprise, qu'elle ne requiert pas d'améliorations et que votre personnel connaît déjà Visual Basic 6.0, le maintien de l'application au format Visual Basic 6.0 est une bonne solution. Votre entreprise doit néanmoins en évaluer les risques en tenant compte des considérations sur le cycle de vie des produits Microsoft et des opportunités offertes par Visual Basic .NET et le .NET Framework à votre entreprise (sites en anglais). Si les besoins de l'entreprise exigent une mise à niveau de l'application vers Visual Basic .NET, il faut alors approfondir davantage la comparaison entre réécriture et mise à niveau. La mise à niveau à l'aide de l'outil de migration de Visual Basic 6.0 vers Visual Basic .NET permet de migrer vos applications à moindre coût. L'une des raisons les plus fréquemment invoquées pour migrer une application vers Visual Basic .NET est le souhait d'en faire une application Web, ou d'optimiser une application Web existante en tirant parti de fonctionnalités ASP.NET telles que la trace, la gestion souple des états, l'accès aux données capable de monter en puissance et des performances améliorées. Comme mentionné plus haut, la réécriture génère parfois une application plus performante. Les coûts de développement sont néanmoins beaucoup plus élevés que ceux d'une mise à niveau. Selon les conseils d'ArtinSoft et le Software Research Institute (http://www.spr.com), un développeur Visual Basic expérimenté écrit entre 500 et 1 000 lignes de code Visual Basic .NET déployable par mois. Lors de la mise à niveau d'une application, ce même programmeur sera en mesure de traiter entre 3 500 et 4 000 lignes de code par mois. La mise à niveau est donc de trois à sept fois plus rapide. Cette énorme différence s'explique par le fait que lors de la réécriture, le programmeur doit écrire puis tester et déboguer un nouvel algorithme. Lors d'une mise à niveau, il lui suffit de s'assurer que le code s'exécute comme dans la version précédente. La réécriture offre plusieurs avantages. Elle permet de rectifier une application mal conçue à l'origine et de remplacer les objets COM par des objets .NET plus flexibles, dont l'inscription n'est plus requise durant le déploiement. Il convient toutefois de noter que la mise à niveau est beaucoup plus rapide et qu'il est tout à fait possible de remplacer les objets COM par des objets .NET après la mise à niveau. En résumé, c'est à vous qu'il appartient de choisir la solution la plus appropriée pour votre projet de modernisation. Si vous décidez de laisser l'application en Visual Basic 6.0, inutile d'aller plus loin ! En revanche, s'il ressort que la réécriture de l'application est la meilleure solution, nous ne pouvons que vous recommander de suivre une méthodologie de développement reconnue. Examinez également de près les problèmes connus de votre application afin d'exploiter ces informations plus tard. Si vous estimez que votre application actuelle, de même que son code source, sont exploitables et qu'il est possible d'étendre son cycle de vie en la mettant à niveau vers Visual Studio NET, une migration automatique est la meilleure solution pour votre code. Enfin, comme dans la plupart des projets de modernisation, peut-être déciderez-vous que la meilleure méthode consiste à associer plusieurs des solutions présentées ci-dessus. Mettre en œuvre un projet de migration automatisée Le reste de cet article est consacré à la mise en œuvre d'un projet de migration, une fois qu'il a été décidé de mettre l'application à niveau à l'aide de l'Assistant Mise à niveau Microsoft Visual Basic, en suivant la méthodologie recommandée. À l'instar d'un projet de développement classique, un projet de migration logicielle requiert une phase initiale de planification et de conception. Cette section décrit comment analyser, préparer et faire migrer une application Visual Basic 6.0 ; elle propose la marche à suivre pour mieux planifier votre projet de migration, notamment définir sa portée, estimer son coût et exécuter la migration proprement dite. Équivalence fonctionnelle Dans ce type de projet, un principe important, utilisé dans les projets de migration automatique et connu sous le nom d'équivalence fonctionnelle, est particulièrement recommandé. Dans le contexte d'une migration Visual Basic, il s'agit de faire migrer une application Visual Basic 6.0 vers une application Visual Basic .NET, en conservant exactement toutes les fonctionnalités d'origine. De nouvelles fonctionnalités sont ajoutées par la suite. La logique de l'application n'est pas modifiée et les règles métier demeurent opérationnelles dans la nouvelle application. L'équivalence fonctionnelle est généralement considérée comme une étape intermédiaire dans un projet de migration. Parvenir à l'équivalence fonctionnelle ne constitue généralement pas un avantage métier important ; tout projet de migration doit par conséquent inclure les actions et les fonctionnalités que vous envisagez d’exploiter une fois cette étape intermédiaire terminée. La création d'un système dont les fonctions sont identiques à 100 % à celles du système d'origine est parfois considérée comme une étape peu constructive. Elle offre néanmoins plusieurs avantages dont les entreprises ne prennent trop souvent conscience qu'une fois le projet de réécriture d'une application déjà bien avancé. L’existant représente un cahier des charges idéal pour le système. Une anomalie de comportement ou de résultat est aisément détectée, et l'entreprise peut mesurer avec précision la réussite du projet de migration. Seule cette approche permet d'éviter la phase longue, coûteuse et difficile, de rédaction des spécifications pour les fonctionnalités existantes de l'application. Elle permet d'éviter le danger que représente l'accroissement de la portée et facilite les phases de test du projet. Avant d'entamer cette procédure, il vous faudra néanmoins définir les spécifications des nouvelles fonctionnalités. Elle représente pour l'entreprise une méthode précise, facile à suivre, idéale pour assurer le suivi de l'avancée du projet. Elle évite aux utilisateurs d'avoir à s'adapter à un nouveau système, consignant le processus de gestion des modifications au seul service informatique de l'entreprise. Pour une entreprise, elle représente la méthode de transition la plus rapide entre ancienne et nouvelle technologies. En outre, elle lui permet très rapidement de reprendre le contrôle et les activités de maintenance applicables au système.

similaire:

	3 tiers d’architecture, 100% de Visual Basic Les composants «bout code» qu’il faut rajouter dans le code d’une application principale. IL arrive, d’ailleurs, fréquemment qu’un composant soit...		Introduction à ado. Net avec Visual Basic 2005
	Ied java jee «Visual Basic vers Java» de l'application de gestion des sinistres de la société		Java 2ee (Jsp Servlet Ejb jpa/Hibernate Spring Jsf “Seam : notions”...
	Résumé Ce guide décrit la connexion et la migration des systèmes...		Comment bien préparer sa migration de Microsoft Online Services (bpos) vers Office 365
	I déploiement d’application Windows avec Visual Studio. Net ...		Résumé Cet article aborde la question de la nouvelle gouvernance... «un ordre inventé», résultant de la confrontation de l’économique et du politique. (Donzelot, 1984; Castel, 1995)
	Calendrier de migration 34		Curriculum vitae «La migration et les relations internationales contemporaines en Europe (entre le xx° et xxi° siècles)»