Стоимость перехода Axapta 2.5->3.0 - как оценить?

[EVGL]

Размер aod-файла ничего не дает. Нуль. Дело в том, что львиную долю в нем занимают измененные хотя бы в одной точке системные формы (типа формы заказов). Кроме того, его размер никогда не уменьшается: вы удаляете исполинскую форму, а файл - все равно 1 Мб.

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

[Михал Семенов]

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

[Megacrusher]

Да я это знал... Экспериментировал... Готов не согласится что aod он ничего не дает можно сдалать оценочный вывод какие элементы по сложности хотя бы правились (размер формы может говорить сам за себя о ее сложности построения)... Хотя конечно же это не точный метод оценки и готов признать что он подходит только для одного слоя. В случае с перекрытием конечно же здесь оценка трагически усложняется ...

Могу предложить Вам метод как повысить точность оценки. Вам нужно собрать все свои модификации в проект (можно сделать утилиткой по сравнению слоев). Сделать слой сравнения usr слоя с нижними слоями. Система сделает проект (накидает туда обьектов из usr слоя) и затем тоже самое сделать с var и bus слоем. Выкачать все три проекта и попытаться собрать их в единый проект. Где-нибудь в тестовой базе... Затем для чистоты эксперимента очистить usr слой и заэкспортировать туда собранный проект. Вы получите слой где у Вас будут находится все объекты когда-либо измененные Вами.

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

Мой прогноз (пессимитичный) выглядит примерно так 1500 часов = 25 mb в слоях, без описаний , сторонними разработчиками = около 800 измененных элементов ... порядка 500-600 часов группой разработчиков т.е около 3-х месяцев.
Мой прогноз (оптимистичный) выглядит примерно
1000 часов = 12 mb в слоях, без описаний , своими(знающими модификации) разработчиками = около 300 измененных элементов ... порядка 200 часов группой разработчиков т.е около 1 го месяца

Из чего это должно складываться
1) Анализ изменений (Выделить те вещи, которые можно перенести буквально руками, например добавление поля в форму) - сформировать список модификаций
2) Сопоставление изменений с функционалом 3.0 (Нужно определить существует ли это же функционал в 3.0) - отсечь не нужное.
3) Перенести модификации (часть с помощью проекта, часть ручками)
4) Провести тестовую конвертацию для проведения тестов на базе.
5) Тестирование - получение каких либо отчетов
6) Финальная конвертация
7) Запуск .... все должно работать

Какие комментарии?

[BOAL]

Слишком уж пессимистичны оптимистичные оценки

Такие оценки в самый раз для разработчиков, которые первый раз ахапту увидят как раз на проекте по подъему модификаций, причем в пессиместичном варианте они до того программировать вообще не умели

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

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

Вот оптисистичный прогноз, основанный лично на моем поднятии всего 4 проектов по разным сервиспакам и на ах30 (весь пренос занимал от одной до 4 недель)

P.S. 800 программных элементов обычно имеют EDT 20-30%, изменения в классах "одной строкой", просто новые (проектные) элементы, которые и править не нужно... и другую мелочевку...

[Vadik]

Цитата:

Слишком уж пессимистичны оптимистичные оценки

Все программисты - оптимисты (с) Фредерик Брукс


Мифический человеко-месяц

[Андре]

Цитата:

ля того чтобы проверить, не завышают ли поставщики время на обновление кода, используйте формулу кол-во часов = кол-во затронутых элементов / 4. Это - верхняя граница. На тестирование отводите от 30 до 50% времени, ушедшего на подъем кода.

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

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

[Megacrusher]

to: BOAL

Цитата:

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

Согласен, но с оговорками. Я и сам поднимал проекты по переводу за 2 недели с небольшим, но правда средний проект... НО дело здесь наверное в том, что на человеческий фактор это штука настолько непредсказуемая, что никакие "человеко-часы" не помогут точно оценить вермя нужное для перевода. Они могут только помочь определить сколько это будет стоить по финансам да и то приблизительно. Да и к тому же я не знаю входной информации ни кто будет переводить, ни кто будет контролировать перевод (а от этого достаточно много будет зависеть хотя бы время реакции на спорные запросы). Да и потом в это время заложено все + непредвиденные ситуации ( а таковых может быть достаточно много).

[Megacrusher]

Цитата:

Изначально опубликовано BOAL
P.S. 800 программных элементов обычно имеют EDT 20-30%, изменения в классах "одной строкой", просто новые (проектные) элементы, которые и править не нужно... и другую мелочевку...

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

[Михал Семенов]

Megacrusher, еще раз спасибо за ценную информацию. На самом деле, с вашей оценкой в 1-3 месяца я внутренне, интуитивно согласен.
Теперь вот что я сделаю. Забью продолжительность проекта - 3-4 месяца (по пессимистичному варианту и с запасом), трудоемкость со стороны Исполнителя (сторонеей фирмы) - 200 часов, т.е. по оптимистичному варианту. Вторая цифра будет непосредственно использоваться в оценках стоимости - больше чем на 200*средняя_ставка_программиста мы соглашаться категорически не будем. Все равно в процессе проекта, как обычно, Исполнитель потребует увеличения сметы раза в полтора-два - так во-первых это не будет неожиданностью, во-вторых, глядишь мы еще и выиграем по сравнению с 500-600 часами.

Вот такие вот мы хитрож...

[Megacrusher]

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

[Михал Семенов]

Как тоже бывший и тоже консалтер - могу сказать, что сколько б они ни раздували - мы это все будем брать с коэффициентом 0.5, а будут выделываться - понизим до 0.25, а то и до 0.1 А недостаток информации обо мне - по-моему, не моя, а их проблема . Раз они чего-то не знают - то пусть я за их незнание заплачу поменьше, а они поучатся.

[gnad]

Михал Семенов, как бывший консалтер вы ведь прекрасно знаете, что на всякую хитрож... , другая хитрож... найдется, и БКД сыграет . В кидаиграх есть своя прелесть, только вот исполнители на нее реагируют по другому

[Михал Семенов]

А это мы еще посмотрим, кто хитрожопЕЕ

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

Работать надо, господа хорошие! Трудиться в поте лица своего - как мы, скромные "производственники". Зарабатывать себе копейку малую, и тем довольствоваться. А то привыкли, панимаишь, циферки в ексель забивать, коэффициент "*3" подставлять - и радоваться жизни. Нееет, так не пойдет

[Pavel]

Цитата:

Изначально опубликовано Михал Семенов
Забью продолжительность проекта - 3-4 месяца (по пессимистичному варианту и с запасом), трудоемкость со стороны Исполнителя (сторонеей фирмы) - 200 часов, т.е. по оптимистичному варианту. Вторая цифра будет непосредственно использоваться в оценках стоимости - больше чем на 200*средняя_ставка_программиста мы соглашаться категорически не будем.

Вот такие вот мы хитрож...

Михаил,

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

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

[Pavel]

Цитата:

Изначально опубликовано EVGL
Кроме того, его размер никогда не уменьшается: вы удаляете исполинскую форму, а файл - все равно 1 Мб.

Размер уменьшается путем экспорта из системы всего USR слоя и последующего импорта в пустой USR.

[Михал Семенов]

Pavel,

Предложенный вами вариант - интересный. Однако встает два вопроса: выгоден ли будет И мне И Исполнителю? Я ведь не могу платить за специалиста даже среднюю зарплату, принятую в консалтинговой среде (про налоговую и прочие "добавки" я уж не говорю) - у нас "на земле", как вы понимаете, кусок масла на бутерброде значительно тоньше С другой стороны - какой резон Исполнителю "продавать" своего сотрудника за деньги меньше, чем он на него потратит (та же зарплата)? Разве что студента какого-нибудь ко мне пошлет, дак я его не возьму ни за что, у меня тут не учебное заведение...
И второе. Как всегда. Кто отвечать-то будет за все? "Посланный" сотрудник единолично?

Хотя, в общем, категорически я такой вариант не отвергаю. Так или иначе - спасибо за идею!

[Pavel]

Цитата:

Изначально опубликовано Михал Семенов
Предложенный вами вариант - интересный. Однако встает два вопроса: выгоден ли будет И мне И Исполнителю?

При зарплате технического специалиста $1500 (3 мес - $4500), слабо верится, что вам станут делать проект 3 месяца меньше, чем за $30 000. Допустим вы договорились за $15 000 "арендовать" соответствующего специалиста.
Вы экономите $15 000.
Исполнитель без "лишнего" напряга зарабатывает $10 500, получает лояльного клиента, референс и возможность дальнейшего сотрудничества.
Приблизительно так... почему бы нет?

Цитата:

Изначально опубликовано Михал Семенов
Кто отвечать-то будет за все? "Посланный" сотрудник единолично?

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

[gnad]

Цитата:

Изначально опубликовано Михал Семенов
Я ведь не могу платить за специалиста даже среднюю зарплату, принятую в консалтинговой среде (про налоговую и прочие "добавки" я уж не говорю)

Думаю о "сторонней" компании и "проекте" вам надо забыть. С таким подходом есть один путь - "зажечь" пару студентов "энтузазистов", и пусть поднимают. Когда поднимут скажите, я их выкуплю. Удачи!

[Михал Семенов]

Цитата:

Думаю о "сторонней" компании и "проекте" вам надо забыть. С таким подходом есть один путь - "зажечь" пару студентов "энтузазистов", и пусть поднимают. Когда поднимут скажите, я их выкуплю. Удачи!

Юноша!

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

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

Вам тоже от души удачи желаю, не забудьте открыточку послать оттуда, куда вас директор пошлет.