Продолжаю серию заметок о различиях заказного ПО и программного продукта. Я уже упоминал о том, что причиной долго времени внесения изменений в ИТ системы может являться сам процесс внесения изменений. Все мы учились на унифицированном процессе разработки ПО. Потому верим в цикл разработки, включающий сбор и анализ требований, проектирование, разработку, тестирование и развертывание решения. Большинство попыток оптимизации этого цикла сводятся к сокращению времени этих фаз. Гибкие методологии, такие как SCRUM предлагают зафиксировать вместо объема работ длительность итерации, т.е. цикл (sprint) разработки составляет всегда X недель (2 или 4), а объем требований для каждого цикла разработки определяется исходя из их сложности. В любом случае, внесение изменений в систему осуществляется только посредством разработки.
Готовые программные продукты должны отказаться от идеи внесения изменений только посредством доработок. Иначе не очень понятно, зачем покупать дорогие лицензии, если любое изменение потребует программирования. Впрочем, в продуктах зачастую и программирования никакого не требуется. Разработчик в красивом редакторе рисует бизнес-процессы, пишет бизнес-правила, создает модели данных и т.п. Довольно расточительно использовать для управления такой деятельностью традиционный цикл разработки ПО. Программный продукт кроме непосредственно кода и документации должен предоставлять документированный и принимаемый заказчиком процесс внесения таких изменений. Не следует путать этот процесс с [software] configuration management. Это разные процессы.
Как должен выглядеть этот процесс? Сохраняются ли в нем работы из unified process. Некоторые, безусловно, сохраняются. Например, требования собирать надо. Но делать это следует не формате IEEE 830 или SRS в стиле RUP. Требования следует формулировать на языке программного продукта, в специализированных шаблонах. А еще лучше это делать внутри самого программного продукта (Social BPM – это как раз об этом). Возьмем, кстати, BPMS для примера. Очевидно, что изменение в BPMS может включать в себя: появление новых ролей, добавление или изменение непосредственно процессов, появление новых типов активностей, как пользовательских (новый тип задачи), так и автоматических (вызов нового web-сервиса). Если мы даже не используем BPMS для сбора и согласования требований, то несложно сделать простой шаблон документа, с соответствующими полями и просить заполнить его в запросе на изменение. Нет никакого смысла писать функциональные требования в формате русскоязычной прозы или техническое задание по ГОСТу.
То же самое относится к повторно-используемым компонентам. Компонент не станет повторно-используемым, если вы не сопроводите его процедурой повторного использования. Администраторы давно придумали чек-листы для управления подключениями к своим системам. Выдача connection string для доступа к базе данных, заведение учетной записи для технологического подключения по HTTР к web-сервису у хорошего администратора сопровождается заполнением такого чек-листа. В нем, кроме функциональных характеристик взаимодействия указываются и нефункциональные: количество обращений, ожидаемое время отклика и т.п. У программиста другая логика. В его картине мире новое подключение к базе данных почти наверняка будет сопровождаться написанием новой процедуры или view. А это, автоматически, новая итерация разработки, со всеми сопровождающими её активностями
Настройка готовых программных продуктов и повторно-используемых компонент должна осуществляться по специальным процедурам, отличающимся от процедуры девелопмента. Согласование требований, тестирование, развертывание(лучше сказать внесение изменений в продуктивную среду) должны вести по другому процессу, основанному на других документах нежели процесс разработки ПО.