Oprogramowanie z 2000 roku, czy powinienem próbować załatać lub przerobić całość?

Wysłano mnie, aby omówić system, z którego obecnie korzysta pewna firma i co należy z tym zrobić.

Firma produkuje różne wyświetlacze kartonowe. System ten został opracowany w celu śledzenia klientów, zamówień i cen. Wiele się wydarzyło od czasu utworzenia systemu, a system jest teraz, jak to opisał menedżer, „ zamknięty ” i „ problematyczny ”, co tłumaczę jako „niedynamiczny” i „niestabilny”.

Kilka informacji o systemie

• Został opracowany około 2000 roku
• Dość mały system, 2-5 użytkowników, 6 formularzy, ~ 8 tabel ze średnimi ilościami danych
• Zbudowane na wczesnych wersjach Visual Basic formularze utworzone za pomocą metody przeciągnij i upuść. Interfejs to po prostu okno z menu i niektórymi formularzami
• Używa bazy danych MSSQL (serwer SQL2005) do przechowywania danych i sterownika ODBC do zapytań, dane były migrowane z programu Excel przed tym systemem, a przed programem Excel były obsługiwane, obliczane i zapisywane ręcznie i na papierze
• Użytkownicy pracują w środowisku Microsoft XP (i nowsze)

Ich głównym problemem jest to, że nie mogą już korygować i obliczać cen, nie mogą już poprawnie dodawać nowych rodzajów kartonów itp., Ponieważ nie mogą (a raczej nie umieją) dotykać danych na serwerze.

Zasugerowałem 3 możliwe rozwiązania

1. Spróbuj załatać bieżący system
2. Utwórz nowy nowy interfejs (najlepiej podobne środowisko, oparte na VB.net lub VB)
3. Wróć do rozwiązania Excel, biorąc pod uwagę, że jest to tak mały system

Może być więcej opcji, ale o tych mogę pomyśleć.

Moje pytania są

• Co powinienem polecić i dlaczego?
• Jakie są lub mogą być zalety i wady tych alternatyw?
• Czy istnieją inne (być może lepsze) alternatywy?

Coś z tylko 6 formularzami i takie powinno być łatwe do przebudowania na bardziej nowoczesnym frameworku. Pracowałem przy migracji projektów VB6, które miały około 200 formularzy wraz z dziesiątkami klas i tabel baz danych. Nie brzmi to tak, jakbyś patrzył na coś tak niechlujnego, ale wygląd może być mylący.

Musiałbym przeanalizować kod, bazę danych i wymagania biznesowe, aby stwierdzić, czy przepisywanie lub refaktoryzacja istniejącej bazy kodu byłaby najlepsza. Biorąc pod uwagę to, co powiedziałeś, skłaniam się ku przepisaniu. Ale mogą istnieć ukryte trudności, których teraz nie widzisz.

Do tej pory mam nieco inną radę na większość odpowiedzi.

Spróbuj załatać bieżący system

Chciałbym przynajmniej nauczyć się obecnego systemu wystarczająco dobrze, aby wyjaśnić klientowi, jak go używać. Poświęcę ten czas na wyjaśnienie wad w ich obecnym systemie, unikanie negatywnych słów, po prostu powiedz im, czego nie może zrobić, nawet jeśli wszystkie znane błędy zostaną naprawione.

Utwórz nowy nowy interfejs (najlepiej podobne środowisko, oparte na VB.net lub VB)

Po nauczeniu się wszystkiego, co możesz przy ich bieżącej konfiguracji. Zapewnij im opcje, jeśli możesz poradzić sobie z ich obawami w ich obecnym systemie, naprawdę nie ma nic złego w ich obecnym systemie. Jedynym problemem jest oczywiście to, że obsługa Visual Basic 6 może nie istnieć za 5 lat.

Innym problemem jest sposób, w jaki komunikuje się z bazą danych. Microsoft powoli pozbywa się niektórych starszych sposobów komunikowania się ze swoimi produktami bazodanowymi (Access, MSSQL), więc sposób interakcji z tymi produktami określi, czy rozwiązanie będzie można stosować w systemie Windows 9 i Windows 10 w przyszłości.

Ta odpowiedź zależy całkowicie od tego, czy mają one źródło samej aplikacji. Jeśli nie mają źródła, trudno będzie rozwiązać ich problemy, naprawić bieżące poważne błędy, a nawet uczynić z niego narzędzie, którego faktycznie mogą używać.

Nie wydaje mi się, żeby w aplikacji Visual Basic 6 było coś „nie tak”, poza tym jej obsługa przyszłych wersji jest nieznana. Nawet dzisiaj z Windows 7 i 64-bitowymi systemami operacyjnymi jest coraz trudniej go obsługiwać. Jest to główny powód, dla którego przepisanie na nowoczesny język z odpowiednią obsługą 64-bitową może być dobrym pomysłem.

Jeśli nie mają źródła w tym momencie, przepisywanie jest naprawdę ich jedynym rozwiązaniem.

Przepisanie interfejsu jest doskonałą opcją, biorąc pod uwagę, że system jest stosunkowo mały. Zalety to -

1. Poprawiona stabilność (zakładając, że robisz to dobrze!)
2. Poprawiona łatwość konserwacji
3. Nowoczesny interfejs

Główną wadą jest to, że prawdopodobnie nadal będzie kosztować nieco więcej niż włamanie się do istniejącego kodu.

Chciałbym również napisać od nowa, ale musisz być w 100% pewien, że w pełni rozumiesz obecną funkcjonalność, a także wszelkie funkcje, które są zepsute, brakujące lub nieodpowiednie. Dwa ostatnie są ważne, jak wspomniałeś o dostosowywaniu i obliczaniu cen. Czy w pełni rozumiesz konsekwencje dodania tej funkcji?

Kiedyś pracowałem nad czymś, co miało być „stroną internetową”, ale w rzeczywistości przejmowałem niestandardowe narzędzie CRM oparte na Accessie od późnych lat 90. i wprowadziłem je do nowoczesnego świata opartego na sieci. Pierwotnego programisty już dawno nie było, Baza danych była kilkakrotnie modyfikowana, oryginalna dokumentacja była więc nieaktualna i nikt tak naprawdę nie rozumiał, jak działa system. Ale wiedzieli, jak go używać, tylko. Prawdopodobnie 80% budżetu tego projektu przeznaczono na trzy rzeczy:

• zbieranie wymagań
• zrozumienie obecnego systemu
• wymyślenie sensownego schematu bazy danych dotyczącego tego, jak zamierzali korzystać z oprogramowania

Projekt nie był finansowo sukcesem!

Inną opcją może być kompromis między przepisaniem całości a zhakowaniem istniejącej aplikacji.

Daj im nową funkcjonalność w nowej aplikacji zbudowanej od podstaw.

Może to być potencjalnie łatwiejsze do zrobienia i nie kosztuje tyle, co pełne przepisanie.

Gdy to zrobiono i są szczęśliwi, że mogą dodawać / aktualizować dane, otwiera to doot ro, a faza druga może zastąpić istniejącą funkcjonalność w nowej aplikacji.

To może być bardziej smaczne podejście.

Przepisania często mają tendencję do wyczerpywania budżetu ... Źle.

Ale posiadanie nowoczesnego szkieletu dla aplikacji może być dobrą inwestycją, szczególnie jeśli nikt nie wie, jak działa stary system i jeśli coś się zepsuje, gdy tylko zaczniesz go dotykać.

Ponadto VB6 źle wpływa na wsparcie. Kiedy za 10 lat będziesz musiał znaleźć specjalistów, będzie to dość problematyczne.