Ответ 1

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

В некоторых проектах и ​​платформах, которые я создал, и что я построил около 25 000 долларов, стоимость замены этого приложения и его переписывание привела к тому, что другая команда людей взяла на себя этот проект, и в результате стоимость была в избытке от 750 000 долларов.

Вы также делаете предположение, что текущую систему необходимо заменить. Вы ДОЛЖНЫ иметь четкое представление о том, каковы реальные цели перемещения и замены текущей платформы и программного обеспечения. Просто переписывая что-то и перекладывая функциональность на другую платформу, вы получаете очень мало, за исключением траты больших денег, которые действительно не приносят пользу вашему бизнесу (но эти разработчики возьмут деньги, если они убедят вас в необходимости делая это)

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

Вещи, которые вы не должны делать, часть I

Джоэл Спольский

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

Они решили переписать код с нуля.

Статья здесь: http://www.joelonsoftware.com/articles/fog0000000069.html

Джоэл продолжает замечать, что за последние 10 лет эта статья по-прежнему остается одной из его более популярных (и несколько противоречивых)

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

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

Я могу только сказать, что редко можно увидеть приложение с множеством таблиц. На самом деле эта проблема вызывает тревожные звонки с места в карьер.

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

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

В иронии судьбы судьбы это уловка 22, потому что, вероятно, если бы у этой системы были действительно фантастические великолепные модели данных, возможно, вам даже не понадобилось перепроектировать и переместить ее в .net. Доступ и SQL-сервер могут масштабироваться до 100 пользователей с легкостью. И доступ поддерживает использование объектов класса и даже контроль исходного кода.

Другими словами, помните, что люди могут попросить переписать это в .net, потому что они полагают, что приложение тогда волшебным образом увеличит гибкость и сможет быть быстрее изменено, чем изменение их бизнес-правил. На самом деле часто происходит обратное, потому что доступ - очень RAD-инструмент. Это означает, что люди на фронте могут часто вносить изменения из-за изменения бизнес-правил, быстрее, чем ИТ-отдел и их команда разработчиков, работающих на следующей отличной версии приложения. И что еще хуже, вы не хотите оседлать ИТ-отдел и тех разработчиков с плохой моделью данных.

Я имею в виду, теперь вы нанимаете ИТ-отдел для создания каждой отдельной таблицы и преуспеете для людей, потому что текущие бизнес-процессы недостаточно гибки? Было бы замечательно, если бы ИТ-отдел обошел бы весь стол, держит их за руку и строит превосходные листы ПРАВИЛЬНО для всех, но это не практично в реальном мире. Таким образом, помимо того, что вы получаете доступ от этих людей, вы также можете отвлечься от них.

Я просто указываю, что мой смысл паука подсказывает мне, что модели данных здесь будут настоящей проблемой. Помните, что я всегда принимал плохой код и отличные модели данных по сравнению с обратным (отличный код, но ужасные модели данных). Причина этого в том, что с большими проектами данных, тогда код и приложения практически пишут сами. И с большими моделями данных, тогда легкость, которую вы можете изменить для постоянно меняющихся бизнес-правил, снова способствует созданию больших конструкций данных по сравнению с отличным кодом. Вы также можете использовать коэффициент пересчета кода КОГДА у вас есть хорошие модели данных. Таким образом, с хорошими моделями данных вы можете перемещать формы и функциональные возможности и пользовательский интерфейс в .net, и вы можете делать это легко и просто, КОГДА существующие модели данных имеют смысл сохранять.

Также нет смысла переходить к этим новым технологиям, и меньше вы собираетесь внедрить возможность внедрения таких вещей, как собственные веб-порталы для существующих бизнес-процессов. Таким образом, сегодня мы можем позволить клиентам манипулировать и использовать часть этой информации, которая в настоящее время заблокирована в системе. Это может быть просто, поскольку они проверяют статус своих заказов, а не тратят драгоценное время на телефон клиента. Или это может быть что-то простое, как то, как крупная упаковочная компания в Канаде сэкономила примерно 10 000 000 долларов США в первый год реализации своей системы отслеживания пакетов. Или может быть что-то столь же просто, как позволить клиенту найти баланс своего аккаунта.

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

Как уже упоминалось, вы должны спросить: где находится Персонал и персонал, собирающийся приступить к созданию и обслуживанию этого приложения? Очевидно, что существующая система с огромным количеством форм и таблиц, которые вы выбрасываете, должна быть каким-то образом создана и представляет собой значительные инвестиции времени и усилий. Ключевой концепцией, которую вы должны задать, являются ли эти значительные инвестиции и ресурсы для создания этого существующего приложения? Кто будет поддерживать новую систему? Другими словами, вам необходимо разработать новую систему для снижения затрат на техническое обслуживание. (новые версии моего программного обеспечения могут снизить затраты на обслуживание до 10 или 15 часов в год для клиента).

В конце концов, хорошая разработка программного обеспечения и хорошие проекты - хорошие проекты. Использование Access или VB6 или vb.net не имеет значения, соответствует ли система вашим потребностям бизнеса.

Я должен также указать, что новая версия доступа 2010 может создавать формы .web. Это XAML (формы zammel.net). Я указываю на это, потому что изменение внешнего интерфейса от доступа к .net дает вам ОЧЕНЬ мало, если базовые структуры данных и проекты также не будут модифицированы, чтобы использовать преимущества новых возможных бизнес-процессов, которые могут быть достигнуты с помощью новых технологий (таких как ячейки обслуживают веб-порталы). Просто перерисуйте конец шрифта с помощью .net-форм, на самом деле, это очень большая часть денег в моем скромном мнении, ЕСЛИ не будут рассмотрены другие проблемы, такие как модель данных или какой-либо веб-портал, который улучшит гибкость здесь.

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

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

Ответ 2

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

1) Начните с перемещения всего, что вы можете, из MS Access и в MS SQL. Это означает, что таблицы, хранимые процедуры, представления и т.д. Если вы сделаете этот шаг правильно, ваше приложение MS Access станет интерфейсом для реальной базы данных, которая уже является победой.

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

3) Заманчиво порт от VBA к VB.NET, по теории, что он более схож, но я не рекомендую это.

Ответ 3

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

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

Сначала бизнес-аналитик присваивается проекту. Его ответственность - отобразить текущее решение и обсудить проблемы текущего решения и ожидания для нового решения. Я не видел проекта, где "клиент" хотел только заменить текущее решение. Каждому клиенту также нужны новые функции и расширения, которые не были доступны в Access.

Бизнес-аналитик создает некоторое начальное описание ожидаемого решения, которое передается архитекторам. Архитекторы решают, какой тип приложения будет создан, какой тип инфраструктуры HW потребуется и как приложение будет подключено к другим системам (при необходимости). После этого начального этапа ИТ имеют общую картину о приложении и о необходимых изменениях. Здесь делается некоторая начальная оценка, поэтому проект можно планировать и выделять ресурсы. Эта оценка является границей для проекта. Чем моя команда начинает выполнять эту работу.

Мы используем гибкий подход, поэтому наш клиент (внутренняя команда) постепенно видит новые функции в приложении. Сначала мы собираем начальный набор (отставание) пользовательских историй (специальная форма требований), и мы оцениваем эти истории пользователей, и мы позволяем клиенту определять их приоритетность. Мы выбираем подмножество пользовательских историй для итерации (обычно 2-4 недели). Новые истории пользователей могут быть добавлены в отставание в любое время, но наши избранные истории пользователей не могут меняться во время итерации. После итерации мы представляем клиентскую часть программного обеспечения. На основе рабочей части клиент может решить изменить приоритеты в отставании или создать новые истории пользователей. Мы повторяем этот подход до тех пор, пока клиент не скажет о прекращении или бюджете подразделения. Важным моментом является то, что не все истории пользователей должны быть сделаны. Проект был запланирован с некоторым бюджетом, и некоторые низкоприоритетные истории пользователей не должны обгонять.

С технической точки зрения это проект как любой другой, кроме нескольких отличий:

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

Ответ 4

650 форм/подформ больших по любым стандартам. Это представляет собой крупный проект конверсии, а "медленный" порт станет кошмаром.

Я бы предложил разработать новый "spike" приложения .NET, который содержит основные функциональные возможности, которые абсолютно необходимы, а затем основываются на нем. В то же время заморозить приложение Access из всех, кроме основных исправлений.

Существует несколько инструментов, которые преобразуют формы MS Access в .NET, но они, скорее всего, не скомпрометируют сложные формы с подформами.

"Без усилий" Преобразование форм доступа в объекты VB

Ответ 5

Итак, если пользователь находится в Access и они принимают действие, чтобы открыть форму, которая является другим исполняемым файлом, написанным на С#, не будет ли это "отображаться" как одно приложение?

Должна быть группа пользователей, которая будет любить отдельное приложение, которое имеет только 5-10 форм, которые они используют.

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