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

вторые понимают, что доработку системы под их специфику проводить, скорее всего, придется, и ожидают, что проект начнётся с подготовки технического задания (ТЗ);
третьи являются наиболее продвинутыми. Или они уже слышали об agile-методологиях, или понимают, что долго писать "большое и светлое" ТЗ – не самый эффективный путь. Эти люди хотят шаг за шагом, небольшими этапами, внедрять отдельные функции, чтобы быстрее получать полезный результат и контролировать его соответствие своим ожиданиям.

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

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

2-5% - предпроектное обследование


40-70% - моделирование

10-20% - доработка функционала (печатные формы, отраслевая специфика)

0-30% - перенос данных из старых систем, очистка от ошибок, унификация и т.п.

1-5% - документация

5-15% - обучение пользователей

Вместо послесловия

Олег Демиденко,
руководитель отдела внедрения ООО “Кодерлайн”