Bonjour,
Je rejoins l'observation faite par jp.gouigoux.
.NET est composé d'un ensemble de langages, frameworks et outils plus ou moins intégrés qui permettent de gagner en productivité.
Le choix de VB6 est effectivement justifiable en son temps car il avait l'avantage de mixer un IDE RAD et un langage de développement, d'où son gain de productivité basé sur la facilité à développer des applications Windows.
Comme souligné dans le post précédent, l'évolution doit être argumentée par l'inventaire des facteurs résultants et opportuns.
Pour VB6, les facteurs de migration observés sont:
- Raréfaction de la compétence
- Plus de support de l'IDE par Microsoft depuis mars 2008
- Les processus de développement ne "collent" plus aux standards actuels
- Besoin d'évoluer plus rapidement en fonction des technologies (SOA, RIA, etc...)
- Productivité des développements, time-to-market réduit et qualité améliorée
Ces facteurs doivent permettre de justifier aux décideurs le besoin de migrer vers .NET ou Java. Pour ma part, j'ai déjà fait mon choix ;-).
Ensuite, vous devez définir une architecture logicielle cible. Et là, vous avez le choix entre du full web, du RIA, du Desktop ou RDA, etc...
Encore une fois le post précédent est judicieux et prudent dans le sens où l'on remarque qu'il ne faut pas forcément succomber aux appels de la "mode" qui par définition est très volatile (sinon ce ne serait plus une mode mais un changement profond, chose sur laquelle, tant que les grands acteurs de l'informatique actuels n'ont pas clarifiés leurs visions, il ne serait pas prudent de miser). Des règles cependant: ne faites pas un choix qui va à l'encontre de la valeur ajoutée de votre logiciel (la concurrence ne vous laissera pas le temps de vous retourner pour corriger le tir), ni un choix qui vous empêchera d'évoluer vers de futures technologies. Ne soyez pas prisonnier de la "mode" pour ne pas être ensuite affublé du terme "passé de mode".
Pour ma part, quelques uns de mes clients qui ont des applications vieillissantes et qui ne peuvent investir massivement dans les nouvelles technologies (non souvent par manque d'investissement, mais plutôt par manque de compétences disponibles sur le marché), font le choix de rester en client/serveur avec un déploiement TS ou CITRIX. Sur ce point, sans vouloir faire de pub, j'orienterai aujourd'hui mon choix vers la solution Windows Server 2008 TS Web Acces et Remote Apps (nouveauté) qui permet un déploiement en 3-Tiers physiques avec contrôle d'accès sur l'application distante, comme l'aiment les DSIs et les RSIs.
Après, ce n'est que reculer pour mieux sauter. Votre projet de migration doit être plannifié le plus rapidement possible (que ce soit .NET ou Java) et les formations de vos développeurs aussi (que ce soit .NET ou Java, c'est le même combat: COO/POO - Conception/Programmation Orientée Objet). C'est certainement le saut quantique le plus difficile à réaliser et à ne pas sous-estimer lorsque l'historique est construit sur VB6.
Techniquement, si vous restez sur la même architecture que le produit actuel en VB6, il existe beaucoup de solutions techniques pour faire interopérer les développements VB6 et .NET (COM Interop par exemple ou autres mécanismes d'interopérabilité).
Pour plus d'informations, vous pouvez lire mon ancien blog sur le concept de "Migration Factory": http://blogs.msdn.com/fredeq/pages/article-the-migration-factory.aspx.
Frédéric Queudret
Bonjour,
Je rejoins l'observation faite par jp.gouigoux.
.NET est composé d'un ensemble de langages, frameworks et outils plus ou moins intégrés qui permettent de gagner en productivité.
Le choix de VB6 est effectivement justifiable en son temps car il avait l'avantage de mixer un IDE RAD et un langage de développement, d'où son gain de productivité basé sur la facilité à développer des applications Windows.
Comme souligné dans le post précédent, l'évolution doit être argumentée par l'inventaire des facteurs résultants et opportuns.
Pour VB6, les facteurs de migration observés sont:
- Raréfaction de la compétence
- Plus de support de l'IDE par Microsoft depuis mars 2008
- Les processus de développement ne "collent" plus aux standards actuels
- Besoin d'évoluer plus rapidement en fonction des technologies (SOA, RIA, etc...)
- Productivité des développements, time-to-market réduit et qualité améliorée
Ces facteurs doivent permettre de justifier aux décideurs le besoin de migrer vers .NET ou Java. Pour ma part, j'ai déjà fait mon choix ;-).
Ensuite, vous devez définir une architecture logicielle cible. Et là, vous avez le choix entre du full web, du RIA, du Desktop ou RDA, etc...
Encore une fois le post précédent est judicieux et prudent dans le sens où l'on remarque qu'il ne faut pas forcément succomber aux appels de la "mode" qui par définition est très volatile (sinon ce ne serait plus une mode mais un changement profond, chose sur laquelle, tant que les grands acteurs de l'informatique actuels n'ont pas clarifiés leurs visions, il ne serait pas prudent de miser). Des règles cependant: ne faites pas un choix qui va à l'encontre de la valeur ajoutée de votre logiciel (la concurrence ne vous laissera pas le temps de vous retourner pour corriger le tir), ni un choix qui vous empêchera d'évoluer vers de futures technologies. Ne soyez pas prisonnier de la "mode" pour ne pas être ensuite affublé du terme "passé de mode".
Pour ma part, quelques uns de mes clients qui ont des applications vieillissantes et qui ne peuvent investir massivement dans les nouvelles technologies (non souvent par manque d'investissement, mais plutôt par manque de compétences disponibles sur le marché), font le choix de rester en client/serveur avec un déploiement TS ou CITRIX. Sur ce point, sans vouloir faire de pub, j'orienterai aujourd'hui mon choix vers la solution Windows Server 2008 TS Web Acces et Remote Apps (nouveauté) qui permet un déploiement en 3-Tiers physiques avec contrôle d'accès sur l'application distante, comme l'aiment les DSIs et les RSIs.
Après, ce n'est que reculer pour mieux sauter. Votre projet de migration doit être plannifié le plus rapidement possible (que ce soit .NET ou Java) et les formations de vos développeurs aussi (que ce soit .NET ou Java, c'est le même combat: COO/POO - Conception/Programmation Orientée Objet). C'est certainement le saut quantique le plus difficile à réaliser et à ne pas sous-estimer lorsque l'historique est construit sur VB6.
Techniquement, si vous restez sur la même architecture que le produit actuel en VB6, il existe beaucoup de solutions techniques pour faire interopérer les développements VB6 et .NET (COM Interop par exemple ou autres mécanismes d'interopérabilité).
Pour plus d'informations, vous pouvez lire mon ancien blog sur le concept de "Migration Factory": http://blogs.msdn.com/fredeq/pages/article-the-migration-factory.aspx.
Frédéric Queudret