А как бы вы организовали контроль проекта?

[gl00mie]

Цитата:

Сообщение от Morpheus

Оценить примерный объем работы поможет стандартный отчет Tools > Development tools > Code upgrade > Estimation report запущенный с параметрами по умолчанию Tools > Development tools > Code upgrade > Parameters. Не забудьте перед запуском отчета запустить Tools > Development tools > Code upgrade > Detect code upgrade conflict для каждого слоя (layer), где выполнены модификации.

Небольшая ремарка: создание проекта выявления конфликтов при обновлении кода по всему AOT'у может так и не доработать до конца - клиент тупо будет сваливаться, не успев создать проект...

Цитата:

Сообщение от Morpheus

Второй этап миграции кода характерен творческой работой от результатов которой и зависит успешность всего проекта. Программистам необходимо выяснить в мельчайших подробностях алгоритм работы сильно измененных классов в AX 3.0 и AX 2009 для того чтобы правильно перенести модификации.

Ага, а еще предстоит напороться на многочисленные грабли - что в стандартном приложении (sys/syp), что в локализации (gls/glp): id-шники полей таблиц, заезжающие в диапазон usr-слоя, id-шники расширенных типов и enum'ов (!), заезжающие в диапазон usr-слоя (вот веселуха-то будет с синхронизацией!), изменившиеся id-шники классов, из-за чего модификации, сделанные для них в 3-ке, перестают видеться ядром в 2009-й, значения стандартных енумов, из-за непонятно с чего взявшегося изменения (было 5, стало 200) "наехавшие" на те значения, которые добавлялись в ходе модификаций... Это на вскидку.

Цитата:

Сообщение от Morpheus

По моему субъективному мнению наиболее качественно и за разумные деньги выполнить аудит поможет сторонний разработчик имеющий опыт выполнения upgrade(ов).

Да, только следует учесть, что по заявлениям представителей тех же консалтинговых компаний проектов на 2009-й в России - не больше десятка (из них в промышленной эксплуатации - 3-4), так что надо либо искать очень немногочисленных сторонних разработчиков, которые имеют реальный опыт, либо обращаться в консалтинговые компании с международным опытом проведения проектов обновления.

[fed]

Ну я бы обозначил следующий основной риск при апгрейде с 3ки на 2009ую. В 2009ой локальный микрософт реализовал много функциональности, которая раньше была в партнерских решениях каждого партнера. На вскидку - профиль разноски по складу, товары в пути, комисионная торговля, загрузка курсов с сайта ЦБ, накладняк от третей организации и тп.
И при переходе надо будет по каждой такой фиче принять решение - использовать ли партнерскую версию функционала (то есть то что партнер во времена 3.0 напрограммировал), или микрософтовскую.
Если использовать микрософтовскую версию, то скорее всего возникнут очень большие проблемы с конвертацией старых данных (может оказаться что нужных для новой микрософтовской функциональности данных просто нет в системе). И может оказаться что проще залить в систему остатки и запуститься с нуля, чем пытаться сконвертировать исторические данные.
Если использовать партнерскую версию - то во первых не понятно зачем тогда вообще переход начинать, во вторых - трудозатраты на выкашивание новой микрософтовской функциональности могут превзойти затраты на перевнедрение.
И вот этот риск явно значительно серьезнее чем технические риски связанные с id объектов и временем апгрейда БД.

Так что, IMNSHO, Vals прав однако. Либо проект перевнедрения (с затратами порядка 40-60% от стоимости начального проекта), либо проект апгрейда, но с совершенно непредсказуемым бюджетом и сроками и падучим монстром сшитыми из кусочков партнерского и микрософтовского кода в результате.

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