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

Думаю, здесь стоит пояснить, а зачем нам 2 (на текущий момент) ИТ - площадки:

▫️ во-первых, на тестовой площадке в течение данного этапа происходит не только добавление новой функциональности и ее показы заказчику. Тут же тестируются настройки системы, сюда же вносятся данные для тестирования. А это не только “пара тестовых записей в справочнике”, но и результаты передачи данных из других ИС, а также результаты тестирования механизмов массовой загрузки первоначальных данных;

▫️во-вторых, в конце данного этапа предполагается сквозное тестирование функциональности системы. Для этого нужно готовить тест-кейсы и вносить в систему данные, необходимые для проведения тестирования. При этом это лучше делать не после того, как абсолютно вся необходимая функциональность будет разработана, а по мере ее разработки. То же самое и с “чистовыми” настройками. И очень обидно будет, если в процессе тестирования эта работа будет испорчена;

▫️ в-третьих, по окончании настройки и тестирования “чистовой” площадки и показа функциональности у вас будет иметься возможность снять резервную копию, из которой вы можете относительно быстро развернуть площадку для обучения пользователей, не входящих в группу ОЭ, параллельно с проведением ОЭ.

Да, теоретически можно сэкономить. Т.е. после окончания разработки полностью зачистить тестовую площадку, затем сделать нужные настройки и загрузить данные для показа. Но в этом случае:

▫️ увеличивается общая продолжительность работ (т.к. теряем возможность параллелить работы); ▫️ увеличиваются трудозатраты (потому что появляются дополнительные работы по очистке и проверке результатов); ▫️ не факт, что очистка будет полной (например, в ходе тестов напрямую в таблицу БД внесли данные, часть данных отобразилась в объекте ИС, а часть - нет, поскольку строка из “подчинённой” таблицы не сопоставилась со строкой “главной” таблицы, а при удалении просто удалили записи штатными средствами ИС, в итоге часть записей не отображается в объекте ИС, но присутствует в БД).

А если ещё учесть, что для тестовой площадки можно не закупать “железные” сервера, а, например, арендовать ресурсы в ЦОДе (тем более, если у вас самих есть в наличии виртуальные ресурсы), то тогда вопрос экономии падает в приоритете.

Разумеется, в любом случае все варианты нужно считать, причем заранее. А параметры всех необходимых площадок прописывать в детальных технических требованиях (у меня была по этому поводу отдельная публикация в рамках этапа 1 “Обследование и анализ”). То есть системный подход к подготовке и проведению проекта может не только улучшить качество его продукта, но и сэкономить деньги.

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