Программное решение 2000-х, я должен попытаться исправить или переделать все это?

Меня послали обсудить систему, которую в настоящее время использует определенная компания, и что с ней делать.

Компания производит различные картонные дисплеи. Эта система была разработана для отслеживания клиентов, заказов и цен. Многое произошло с тех пор, как система была создана, и теперь система, как ее описал менеджер, « заблокирована » и « проблематична », что я перевожу как «не динамический» и «нестабильный».

Некоторая информация о системе

• Он был разработан около 2000 года
• Довольно маленькая система, 2-5 пользователей, 6 форм, ~ 8 таблиц со средним количеством данных
• Построенные на ранних версиях Visual Basic, формы, созданные с помощью перетаскивания. Интерфейс в основном просто окно с меню и некоторыми формами
• Использует базу данных MSSQL (сервер SQL2005) для хранения данных и драйвер ODBC для запроса, данные были перенесены из Excel до этой системы, а до того, как Excel был обработан, рассчитан и записан вручную и на бумаге
• Пользователи работают в среде Microsoft XP (и выше)

Их главная проблема заключается в том, что они не могут корректировать и рассчитывать цены, не могут добавлять новые типы картонных коробок и т. Д., Правильно, потому что они не могут (или, скорее, они не знают, как) касаться данных на сервере.

Я предложил 3 возможных решения

1. Попытка исправить текущую систему
2. Создать новый новый интерфейс (желательно аналогичную среду на основе VB.net или VB)
3. Верните его в решение Excel, учитывая, что это такая маленькая система

Там может быть больше вариантов, но это те, которые я мог придумать.

Мои вопросы

• Что я должен рекомендовать и почему?
• Каковы или могут быть плюсы и минусы этих альтернатив?
• Есть ли другие (возможно, лучшие) альтернативы?

Что-то с только 6 формами и тому подобное должно быть легко перестроено на более современной основе. Я работал с миграцией проектов VB6, которые имели около 200 форм, а также десятки классов и таблиц базы данных. Не похоже, что вы смотрите на что-то грязное, но внешность может быть обманчива.

Мне пришлось бы проанализировать код, базу данных и бизнес-требования, чтобы сказать, будет ли лучше переписать или реорганизовать существующую базу кода. Учитывая то, что вы сказали, я склоняюсь к переписыванию. Но могут быть скрытые трудности, которых вы сейчас не видите.

У меня немного другой совет, большинство ответов до сих пор.

Попытка исправить текущую систему

По крайней мере, я бы достаточно хорошо изучил текущую систему, чтобы объяснить клиенту, как ее использовать. Я бы взял это время, чтобы объяснить недостатки в их нынешней системе, избежать негативных слов, просто сказать им, что он не может сделать, даже если все известные ошибки были исправлены.

Создать новый новый интерфейс (желательно аналогичную среду на основе VB.net или VB)

После того, как вы узнали все, что вы можете с их текущей настройкой. Предоставьте им варианты, если вы можете решить их проблемы с их текущей системой, в их текущей системе нет ничего плохого. Единственная проблема, конечно, заключается в том, что поддержка Visual Basic 6 может отсутствовать в течение 5 лет.

Другой проблемой является то, как он взаимодействует с базой данных. Microsoft постепенно избавляется от некоторых старых способов взаимодействия со своими продуктами баз данных (Access, MSSQL), поэтому способ взаимодействия с этими продуктами будет определять, будет ли решение использоваться в Windows 9 и Windows 10 в будущем.

Этот ответ полностью зависит от того, что у них есть источник для самого приложения. Если у них нет источника, тогда будет сложно решить их проблемы, исправить текущие серьезные ошибки или даже сделать его инструментом, который они действительно могут использовать.

Я не чувствую, что в приложении Visual Basic 6 есть что-то «не так», кроме того, его поддержка будущих версий неизвестна. Даже сегодня с Windows 7 и 64-битными операционными системами его становится все труднее поддерживать. Это основная причина, по которой переписывание на современный язык с надлежащей 64-битной поддержкой может быть хорошей идеей.

Если у них нет источника на тот момент, переписывание действительно является их единственным решением.

Переписать интерфейс - отличный вариант, учитывая, что система относительно мала. Преимущества -

1. Улучшена стабильность (если вы делаете это хорошо!)
2. Улучшенная ремонтопригодность
3. Современный интерфейс

Основным недостатком является то, что он все равно будет стоить немного дороже, чем взлом существующего кода.

Я также хотел бы переписать, но вы должны быть на 100% уверены, что полностью понимаете текущую функциональность, а также любую функциональность, которая сломана, отсутствует или неадекватна. Последние два важны, как вы упомянули, корректировки и расчета цен. Вы полностью понимаете последствия добавления этой функции?

Когда-то я работал над тем, что должно было быть «веб-сайтом», но на самом деле с конца 1990-х годов брал на вооружение инструмент в стиле CRM, основанный на Access, и переносил его в современный веб-мир. Первоначальный разработчик давно ушел, база данных была изменена множество раз, поэтому оригинальная документация устарела, и никто не понимал, как работает система. Но они знали, как им пользоваться, просто. Вероятно, 80% бюджета на этот проект ушло на три вещи:

• сбор требований
• понимание существующей системы
• придумать осмысленную схему базы данных о том, как они намеревались использовать программное обеспечение

Проект в финансовом отношении не имел успеха!

Другим вариантом может быть компромисс между переписыванием всего этого и взломом существующего приложения.

Дайте им новую функциональность в новом приложении, построенном с нуля.

Это может быть легче сделать, и не будет стоить столько, сколько полная перезапись.

Как только это будет сделано, и они счастливы, что могут добавлять / обновлять данные, это открывает точку для второго этапа, который может заменить существующую функциональность в новом приложении.

Это может быть более приемлемый подход.

Перезаписи часто имеют тенденцию исчерпывать бюджет ... Плохо.

Но наличие современного каркаса для приложения может быть хорошим вложением, особенно если никто не знает, как работает старая система, и если что-то сломается, как только вы начнете касаться их.

Кроме того, VB6 плохо для поддержки. Когда через 10 лет вам нужно будет найти специалистов, это будет довольно проблематично.