Прошу прощения, что пропал - не было возможности ответить по существу.
Цитата:
Сообщение от
trud
Что-то мне кажется вы сделали допущение что у вас в данный момент есть кто-то кто знает как это делать плюс свободен, кроме того опустили момент развертывания
...
Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее
Во-первых я оставил за скобками бюрократию сознательно, потому что считаю, что любая бюрократия всегда может "съесть" любую разработку ("Сколько нужно программистов чтобы поменять лампочку?"). При наличии такой бюрократии - уже неважна система
Все равно любое обновление будет идти "по процедуре".
Во-вторых это допущение применимо как только заказчик захочет иметь своего человечка для разработки и этому человечку дадут команду "сделать", т.е. он обучится как это делать, плюс будет свободен (ему выделят время), плюс он будет заниматься развертыванием (по крайней мере контролировать процесс).
В-третьих из представленной схемы с партнером никак не следует, чем все-таки работа с D365 отличается от работы с AX2012. Наличие облака совершенно не связано с тем, что клиент не захочет контролировать содержимое обновления и не попросит присылать ему модели. Локальная установка системы совершенно не связана с тем, что клиенту обязательно нужно контролировать содержимое обновления и он не может дать доступ партнеру на свой терминальный сервер для проведения обновления.
Цитата:
Сообщение от
Vadik
sukhanchik, тысяча извинений - отредактировал Ваше
сообщение вместо того чтобы процитировать
Это восстановимо, да и я не контролирую какие слова пропали
Цитата:
Сообщение от
Vadik
Из лично Вашей практики - каковы были трудозатраты и длительность проектов по обновлению версий, накату сервис-паков, хотфиксов, расширенной функциональности распространяемой в фиде хотфиксов в 2012. Если были таковые, разумеется. Спасибо
Тут я признаюсь честно - таких проектов именно на AX 2012 у меня не было. Я судил по проектам в АХ 2009, предполагая, что в 2012 процедура усложнилась пересборкой CILа, получением хотфиксов через LCS и нормализованной структуры данных. По AX 2009 обычно это 2-4 человеко-недели на подъем кода (в зависимости от количества пересечений и сложности тестирования; половина времени отнимает непосредственно подъем кода и половина - тестирование) и 1-2 человеко-месяцев на подготовку обновляющих скриптов, инструкции и тестовых прогонов (разброс сильно зависит от объема БД и количества обновляемых таблиц; я не рассматриваю классы ReleaseUpdate*, в роли держателей скриптов, т.к. они хорошо работают только для небольшого объема данных и повторяют свою работу в каждой компании, в то время как для некоторых скриптов можно сэкономить и запускать обновляющий скрипт всего один раз по всем компаниям)
В маленьких базах (15 пользователей) весь подъем вообще можно сделать за человеко-месяц (из опыта).
В больших базах (больше 100 пользователей) только подготовка данных может занять 3 месяца работы нескольких человек (также из опыта)
Все вышеперечисленное относится к подъему на один или два сервис-пака (т.е. нечто глобальное)
Однако, тут надо сделать одну очень существенную оговорку. Объективно нет смысла обновляться, если в новой версии нет нового функционала, ради которого происходит обновление. За исключением, когда обновляться заставляют технические причины (к примеру, Windows 10 не поддерживает приложения, написанные для DOS
))
А если обновление производится ради функционала, то этот функционал нужно внедрить и, вполне вероятно, сделать пересмотр использование существующего функционала (давно-давно у меня была ситуация, когда я программировал функциональность на 4.0, которая впоследствии в очень сильно похожем варианте появилась в AX2009 в виде причин возврата в заказах на возврат. В этом случае нужно было бы выбросить мое "творение" и подкорректировать стандарт, если бы он не подошел напрямую). Т.о. по сути глобальное обновление должно сопровождаться мини-внедрением, а это уже целый проект и как ты не крути, программируя с прошлой версией и заботясь о будущем апгрейде, но перевнедрение превратит прошлую версию всего-лишь в систему-источник информации, какой является 1С или какая другая система, когда на предприятие приходит AX / D365. И перетягивание информации из одной системы в другую сведется к написанию таких же классов-загрузчиков данных в новой версии.
Поэтому очень сложно корректно сравнить в общем случае потенциальные затраты на обновление системы с потенциальными затратами на перевнедрение. Если, к примеру, смотреть на АХ2012 - D365, то лично мое мнение, что здесь нужно делать именно перевнедрение, а не обновление. Т.е. усложнять разработку ради потенциального облегчения обновления конкретно на этой смене нет экономического смысла