Переписать автоматическую обработку доступа / sqlserver к .NET C#?

Что ж, если вы цените слово Джоэла, я бы сказал, что вы действительно очень сильно рискуете.

Переписывание материала было и никогда не будет безопасным занятием для делать для компании.

Проще говоря, задайте себе следующие вопросы:

1. Возникли ли у вас проблемы с программным обеспечением в настоящее время? Жалуются ли пользователи на пользовательский интерфейс или новичкам особенно сложно освоить программное обеспечение при его использовании? Данные теряются или повреждаются на каком-либо этапе, или у вас возникают проблемы с получением отчетов из базы данных?

2. Потребуются ли вам изменения в настоящее время или в будущем? Если ваше программное обеспечение написано плохо, модификации будут более дорогостоящими и, скорее всего, выйдут из строя и вызовут простои в целом.

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

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

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

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

Однако у вас есть вложения, которые могут нуждаться в обслуживании, и когда у вас есть базовый код и база данных в dis-array, вы понесете дополнительные расходы, потому что приложение не поддается изменению. Вы захотите почувствовать, сколько изменений вам нужно поддержать. Учитывая, что он находится в производстве 15 лет, у вас был хороший пробег, так что у вас нет особого риска.

Переписывание будет стоить вам, потому что вам нужно воссоздать то, что делает приложение, и поскольку вспомогательная база данных и программа кажутся "ненормализованными" и неструктурированными , это потребует больших усилий. У чистой модели базы данных есть свои преимущества, потому что будет проще составлять отчеты, экспортировать в Excel и т. Д. И если вы захотите ее изменить, разработчикам будет легче понять, что им делать.

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

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

Предложение заменить интерфейс ADP звучит для меня как чистое предубеждение / невежество - они не продают разработки для Access, поэтому хотят создать для вас совершенно новое приложение.

С другой стороны, совет по поводу серверной части звучит как нечто, что вам не следует ждать, чтобы исправить (хотя это может потребовать много работы, поскольку существующие данные, вероятно, не подходят для правильного RI).

Проблемы внешнего интерфейса и внутреннего интерфейса - это две отдельные проблемы, и их можно решать независимо (хотя приложение может нуждаться в обновлении, чтобы отразить изменения в RI - невозможно сказать без индивидуальной оценки).

Я бы нанял компетентного разработчика Access с опытом работы с ADP для выполнения проекта. Это будет намного дешевле, чем полная перезапись, и вы не пожертвуете никакими функциональными возможностями, а также не будете повторно вводить ошибки, которые уже были исправлены в вашем существующем приложении. Скорее всего, это можно делать постепенно (в зависимости от проблем и способов их решения).

Предложения, предлагаемые «более авторитетной ИТ-фирмой», довольно распространены для проектов серверов доступа / sql. Практически всегда предлагается переписывать их как веб-приложения.

Я сделал это сам в прошлом году - взял внешнее приложение MS Access / серверное приложение SQL Server и переписал часть доступа как C # / ASP. Интернет-сайт. Нам понравилась лучшая производительность и большая гибкость в результате перехода, но старый интерфейс просуществовал достаточно долго, и нам так и не удалось вернуть все функции, которые были у нас до перезаписи.

Фактически вы видите 70 одновременных пользователей, и ни один из них не испытывает проблем с производительностью, а ваша корпоративная сеть достаточно безопасна, тогда вы можете потерять больше, переписав приложение, по крайней мере, с точки зрения функциональности. С другой стороны,

Что побудило аудит? Решает ли их решение эту проблему?

Давайте посчитаем: Люди: 70 Avg. Часов использования программного обеспечения / день: 2 (консервативно) Заработная плата / час: 8 долларов США (очень консервативно) Рабочих дней / год: 250 (выезжал на выходные и в отпуск / по болезни)

Стоимость рабочей силы с использованием приложения: 70 * 2 * 8 * 250 = 280 000 долларов в год (может превышать 500 тысяч)

Насколько вы можете улучшить ? 5%, 10%, 25% Сколько будет стоить новое приложение? 50K, 100K, 200K

Если вы сможете сэкономить это время, освободятся ли ваши пользователи для деятельности, приносящей доход, или у них просто будет больше времени для серфинга в Интернете? Вы можете создать некоторый коэффициент эффективности рабочего: 90%, 75%

Простой ответ ... Большинство «рисков» использования Access преодолеваются за счет использования SQL-сервера в качестве бэкэнда. Вы уже сказали, что ваше текущее решение работает.

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

1. Являются ли они чем-то, что Access не может предоставить или хорошо работает (например, решения для выхода в Интернет)?
2. Какова потенциальная выгода от использования новых функций?
3. Каковы потенциальные затраты на ] без новых функций?
4. Можете ли вы поставить цифру в долларах на 1 и 2?
5. Сколько стоит разработать решение в Access?
6. Сколько стоит разработать решение на C #

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