При этом готовые методики обследования Заказчика совершенно не учитывают, что формальное описание функций надо подгонять под готовую программу. Они рассчитаны на свободное творчество программистов. А реальное ТЗ учетной системы должно не просто описать требования, но и выполнить стыковку требований Заказчика с имеющимся в типовой программе функционалом. То есть некий анализ должен быть проделан для всех пересечений функций типовой программы и требований Заказчика. Скажем, если у Заказчика 100 требований, а во внедряемой программе 1 000 функций, для подготовки ТЗ нужно проделать 100 000 операций анализа требований в разрезе функционала программы.
С другой стороны, можно упереться в полное ТЗ, и мы получим проекты внедрения западных ERP-систем с их безумными бюджетами и бесконечными сроками. И даже такие бюджеты и сроки возможны только потому, что проектирование западных учетных систем по-максимуму использует шаблоны и типовые методики. Когда можно один раз написать ТЗ на систему и только годами дополнять его описанием новых функций.
В наших же условиях, никаких типовых методик и шаблонов быть не может. Учетные системы жестко ориентируются на законодательство, которое постоянно меняется. И в этих условиях разработчики типовых программ вообще махнули рукой на преемственность функционала, постоянно выпуская новые платформы и редакции, творчески экспериментируя с вариантами программной реализации одних и тех же функций.
Комментариев нет:
Отправить комментарий