Software-Lösung aus den 2000er Jahren, sollte ich versuchen, das Ganze zu patchen oder neu zu erstellen?

Ich wurde ausgesandt, um ein System zu besprechen, das ein bestimmtes Unternehmen derzeit verwendet, und was damit zu tun ist.

Das Unternehmen stellt verschiedene Kartonauslagen her. Dieses System wurde entwickelt, um Kunden, Bestellungen und Preise zu verfolgen. Seit der Erstellung des Systems ist viel passiert, und das System ist jetzt, wie der Manager es beschrieben hat, " gesperrt " und " problematisch ", was ich als "nicht dynamisch" und "instabil" übersetze.

Einige Infos zum System

• Es wurde um das Jahr 2000 entwickelt
• Ziemlich kleines System, 2-5 Benutzer, 6 Formulare, ~ 8 Tabellen mit durchschnittlichen Datenmengen
• Auf frühem Visual Basic basierende Formulare, die mit dem Drag & Drop-Design erstellt wurden. Die Benutzeroberfläche ist im Grunde nur ein Fenster mit einem Menü und einigen Formularen
• Verwendet die MSSQL-Datenbank (SQL2005-Server) zum Speichern von Daten und den ODBC-Treiber zum Abfragen. Daten wurden vor diesem System von Excel migriert und vor Excel von Hand und Papier verarbeitet, berechnet und geschrieben
• Benutzer arbeiten in einer Microsoft XP-Umgebung (und höher).

Ihr Hauptproblem ist, dass sie die Preise nicht mehr korrekt anpassen und berechnen, keine neuen Kartontypen usw. hinzufügen können, weil sie die Daten auf dem Server nicht berühren können (oder besser gesagt nicht wissen, wie sie zu berühren sind).

Ich schlug 3 mögliche Lösungen vor

1. Versuchen Sie, das aktuelle System zu patchen
2. Erstellen Sie eine neue Schnittstelle (vorzugsweise ähnliche Umgebung, VB.net oder VB-basiert)
3. Bringen Sie es zurück zu einer Excel-Lösung, da es sich um ein so kleines System handelt

Es gibt vielleicht mehr Optionen, aber diese sind diejenigen, an die ich denken könnte.

Meine Fragen sind

• Was soll ich empfehlen und warum?
• Was sind oder könnten die Vor- und Nachteile dieser Alternativen sein?
• Gibt es andere (möglicherweise bessere) Alternativen?

Etwas mit nur 6 Formen und dergleichen sollte auf einem moderneren Rahmen leicht wieder aufzubauen sein. Ich habe mit der Migration von VB6-Projekten gearbeitet, die ungefähr 200 Formulare zusammen mit Dutzenden von Klassen und Datenbanktabellen hatten. Es hört sich nicht so an, als würden Sie etwas so Unordentliches betrachten, aber das Aussehen kann täuschen.

Ich müsste den Code, die Datenbank und die Geschäftsanforderungen analysieren, um zu sagen, ob das Umschreiben oder Umgestalten der vorhandenen Codebasis am besten wäre. Angesichts dessen, was Sie gesagt haben, würde ich mich zu einem Umschreiben neigen. Es kann jedoch versteckte Schwierigkeiten geben, die Sie derzeit nicht sehen.

Ich habe die meisten Antworten bisher etwas anders beraten.

Versuchen Sie, das aktuelle System zu patchen

Ich würde zumindest das aktuelle System gut genug lernen, um dem Kunden zu erklären, wie man es benutzt. Ich würde mir diese Zeit nehmen, um die Fehler in ihrem aktuellen System zu erklären, negative Wörter zu vermeiden und ihnen einfach zu sagen, was es nicht kann, selbst wenn alle bekannten Fehler behoben wurden.

Erstellen Sie eine neue Schnittstelle (vorzugsweise ähnliche Umgebung, VB.net oder VB-basiert)

Nachdem Sie alles gelernt haben, können Sie mit ihrem aktuellen Setup. Stellen Sie ihnen Optionen zur Verfügung. Wenn Sie ihre Bedenken mit ihrem aktuellen System ausräumen können, ist mit ihrem aktuellen System wirklich nichts falsch. Das einzige Problem ist natürlich, dass die Unterstützung für Visual Basic 6 in 5 Jahren möglicherweise nicht mehr besteht.

Ein weiteres Problem ist die Art und Weise, wie mit der Datenbank kommuniziert wird. Microsoft entfernt langsam einige der älteren Kommunikationsmethoden mit seinen Datenbankprodukten (Access, MSSQL), sodass die Art und Weise, wie Sie mit diesen Produkten interagieren, bestimmt, ob die Lösung in Zukunft unter Windows 9 und Windows 10 verwendet werden kann.

Diese Antwort hängt vollständig von der Tatsache ab, dass sie die Quelle für die Anwendung selbst haben. Wenn sie nicht über die Quelle verfügen, ist es schwierig, ihre Bedenken auszuräumen, die aktuellen Hauptfehler zu beheben oder sie sogar zu einem Tool zu machen, das sie tatsächlich verwenden können.

Ich glaube nicht, dass mit einer Visual Basic 6-Anwendung etwas "falsch" ist, abgesehen von der Tatsache, dass die Unterstützung für zukünftige Versionen unbekannt ist. Selbst heute mit Windows 7- und 64-Bit-Betriebssystemen wird die Unterstützung immer schwieriger. Dies ist ein Hauptgrund dafür, dass ein Umschreiben in eine moderne Sprache mit angemessener 64-Bit-Unterstützung eine gute Idee sein könnte.

Wenn sie zu diesem Zeitpunkt nicht über die Quelle verfügen, ist ein Umschreiben wirklich ihre einzige Lösung.

Das Umschreiben der Schnittstelle ist eine hervorragende Option, da das System relativ klein ist. Vorteile sind -

1. Verbesserte Stabilität (vorausgesetzt, Sie machen es gut!)
2. Verbesserte Wartbarkeit
3. Moderne Schnittstelle

Der Hauptnachteil ist, dass es wahrscheinlich immer noch ein gutes Stück mehr kostet als das Hacken des vorhandenen Codes.

Ich würde auch dazu neigen, neu zu schreiben, aber Sie müssen 100% sicher sein, dass Sie die aktuelle Funktionalität vollständig verstehen sowie alle Funktionen, die defekt, fehlend oder unzureichend sind. Die beiden letzteren sind wichtig, wie Sie bereits erwähnt haben, um die Preise anzupassen und zu berechnen. Verstehen Sie die Konsequenzen des Hinzufügens dieser Funktion vollständig?

Ich habe einmal an einer angeblichen "Website" gearbeitet, aber tatsächlich ein benutzerdefiniertes Access-basiertes CRM-Tool aus den späten 1990er Jahren übernommen und in die moderne, webbasierte Welt gebracht. Der ursprüngliche Entwickler war schon lange nicht mehr da, die Datenbank wurde unzählige Male geändert, die Originaldokumentation war daher veraltet und niemand verstand wirklich, wie das System funktionierte. Aber sie wussten einfach, wie man es benutzt. Wahrscheinlich 80% des Budgets für dieses Projekt flossen in drei Dinge:

• Anforderungen sammeln
• das aktuelle System verstehen
• Entwicklung eines aussagekräftigen Datenbankschemas für die beabsichtigte Verwendung der Software

Das Projekt war finanziell kein Erfolg!

Eine andere Option könnte ein Kompromiss zwischen dem Umschreiben des Ganzen und dem Hacken der vorhandenen App sein.

Geben Sie ihnen die neuen Funktionen in einer neuen Anwendung, die von Grund auf neu erstellt wurde.

Dies könnte möglicherweise einfacher sein und nicht so viel kosten wie ein vollständiges Umschreiben.

Sobald dies geschehen ist und sie froh sind, Daten hinzufügen / aktualisieren zu können, wird der Doot Ro geöffnet. Eine zweite Phase könnte die vorhandene Funktionalität in der neuen App ersetzen.

Dies könnte ein schmackhafterer Ansatz sein.

Umschreibungen neigen oft dazu, kein Budget mehr zu haben ... Schlecht.

Ein modernes Skelett für die Anwendung zu haben, könnte jedoch eine gute Investition sein, insbesondere wenn niemand weiß, wie ein altes System funktioniert, und wenn Dinge kaputt gehen, sobald Sie anfangen, sie zu berühren.

Außerdem ist VB6 schlecht für die Unterstützung. Wenn Sie in 10 Jahren Spezialisten finden müssen, ist das ziemlich problematisch.