Solution logicielle des années 2000, dois-je essayer de corriger ou de refaire le tout?

J'ai été envoyé pour discuter d'un système qu'une certaine entreprise utilise actuellement et de ce qu'il faudrait en faire.

L'entreprise fabrique divers présentoirs en carton. Ce système a été développé pour garder une trace des clients, des commandes et des prix. Beaucoup de choses se sont passées depuis la création du système et le système est maintenant, comme le directeur l'a décrit, " verrouillé " et " problématique ", que je traduis par "non dynamique" et "instable".

Quelques informations sur le système

• Il a été développé vers l'an 2000
• Système assez petit, 2 à 5 utilisateurs, 6 formulaires, ~ 8 tableaux avec des quantités moyennes de données
• Construit sur les premiers Visual Basic, les formulaires créés avec la conception glisser-déposer. L'interface est simplement une fenêtre avec un menu et quelques formulaires
• Utilise la base de données MSSQL (serveur SQL2005) pour stocker les données et le pilote ODBC pour interroger, les données ont été migrées d'Excel avant ce système, et avant Excel, elles ont été gérées, calculées et écrites à la main et sur papier
• Les utilisateurs travaillent dans un environnement Microsoft XP (et supérieur)

Leur principal problème est qu'ils ne peuvent pas ajuster et calculer les prix, ne peuvent plus ajouter de nouveaux types de cartons, etc., correctement car ils ne peuvent pas (ou plutôt, ils ne savent pas comment) toucher les données sur le serveur.

J'ai proposé 3 solutions possibles

1. Tenter de patcher le système actuel
2. Créez une nouvelle interface (de préférence un environnement similaire, basé sur VB.net ou VB)
3. Ramenez-le à une solution Excel, étant donné qu'il s'agit d'un si petit système

Il pourrait y avoir plus d'options, mais ce sont celles auxquelles je pouvais penser.

Mes questions sont

• Que dois-je recommander et pourquoi?
• Quels sont ou pourraient être les avantages et les inconvénients de ces alternatives?
• Existe-t-il d'autres alternatives (peut-être meilleures)?

Quelque chose avec seulement 6 formulaires et ceux-ci devraient être faciles à reconstruire sur un cadre plus moderne. J'ai travaillé avec des projets de migration VB6 qui avaient environ 200 formulaires avec des dizaines de classes et de tables de base de données. Il ne semble pas que vous regardiez quelque chose de désordonné, mais les regards peuvent être trompeurs.

Je devrais analyser le code, la base de données et les exigences commerciales pour dire si la réécriture ou la refactorisation de la base de code existante serait la meilleure. Compte tenu de ce que vous avez dit, je pencherais pour une réécriture. Mais, il pourrait y avoir des difficultés cachées que vous ne voyez pas en ce moment.

Jusqu'à présent, j'ai des conseils légèrement différents pour la plupart des réponses.

Tenter de patcher le système actuel

J'apprendrais au moins assez bien le système actuel pour expliquer au client comment l'utiliser. Je prendrais ce temps pour expliquer les failles de leur système actuel, éviter les mots négatifs, juste leur dire ce qu'il ne peut pas faire même si tous les bugs connus ont été corrigés.

Créez une nouvelle interface (de préférence un environnement similaire, basé sur VB.net ou VB)

Après avoir appris tout ce que vous pouvez avec leur configuration actuelle. Donnez-leur des options, si vous pouvez répondre à leurs préoccupations avec leur système actuel, il n'y a vraiment rien de mal avec leur système actuel. La seule préoccupation est bien sûr que la prise en charge de Visual Basic 6 pourrait ne pas exister dans 5 ans.

Une autre préoccupation est la façon dont il communique avec la base de données. Microsoft se débarrasse lentement de certaines des anciennes façons de communiquer avec ses produits de base de données (Access, MSSQL), de sorte que la façon dont vous interagissez avec ces produits déterminera si la solution peut être utilisée sur Windows 9 et Windows 10 à l'avenir.

Cette réponse dépend entièrement du fait qu'ils ont la source de l'application elle-même. S'ils n'ont pas la source, il sera difficile de répondre à leurs préoccupations, de corriger les principaux bogues actuels ou même d'en faire un outil qu'ils peuvent réellement utiliser.

Je ne pense pas qu'il y ait quelque chose de "mal" avec une application Visual Basic 6, outre le fait que son support pour les futures versions est inconnu. Même aujourd'hui, avec les systèmes d'exploitation Windows 7 et 64 bits, il devient de plus en plus difficile à prendre en charge. C'est une raison majeure pour laquelle une réécriture dans un langage moderne avec un support 64 bits approprié pourrait être une bonne idée.

S'ils n'ont pas la source à ce stade, une réécriture est vraiment leur seule solution.

La réécriture de l'interface est une excellente option, étant donné que le système est relativement petit. Les avantages sont -

1. Amélioration de la stabilité (en supposant que vous le faites bien!)
2. Amélioration de la maintenabilité
3. Interface moderne

Le principal inconvénient est qu'il coûtera probablement un peu plus cher que le piratage du code existant.

J'aurais également tendance à réécrire, mais vous devez être sûr à 100% de bien comprendre la fonctionnalité actuelle ainsi que toute fonctionnalité cassée, manquante ou inadéquate. Les deux derniers sont importants car vous avez mentionné l'ajustement et le calcul des prix. Comprenez-vous parfaitement les conséquences de l'ajout de cette fonctionnalité?

J'ai déjà travaillé sur ce qui était censé être un "site Web", mais en réalité, je prenais en charge un outil de style CRM basé sur Access personnalisé de la fin des années 1990 et le faisais entrer dans le monde moderne basé sur le Web. Le développeur d'origine avait disparu depuis longtemps, la base de données avait été modifiée énormément de fois, la documentation d'origine était donc obsolète et personne ne comprenait vraiment le fonctionnement du système. Mais ils savaient comment l'utiliser, juste. Probablement 80% du budget de ce projet a été consacré à trois choses:

• collecte des exigences
• comprendre le système actuel
• venir avec un schéma de base de données significatif pour la façon dont ils avaient l'intention d'utiliser le logiciel

Le projet n'a pas été, financièrement, un succès!

Une autre option pourrait être un compromis entre réécrire le tout et pirater l'application existante.

Donnez-leur les nouvelles fonctionnalités dans une nouvelle application conçue à partir de zéro.

Cela pourrait être plus facile à faire et ne coûterait pas autant qu'une réécriture complète.

Une fois que cela a été fait et qu'ils sont heureux de pouvoir ajouter / mettre à jour des données, cela ouvre la porte à une phase deux qui pourrait remplacer la fonctionnalité existante dans la nouvelle application.

Cela pourrait être une approche plus acceptable.

Les réécritures ont souvent tendance à manquer de budget ...

Mais avoir un squelette moderne pour l'application peut être un bon investissement, surtout si personne ne sait comment fonctionne l'ancien système et si les choses se cassent dès que vous commencez à les toucher.

En outre, VB6 est mauvais pour le support. Lorsque vous aurez besoin de trouver des spécialistes dans 10 ans, ce sera assez problématique.