Адаптация RUP для организации процесса управления и контроля разработки ПО на стороне заказчика

Буртный К.К.

Выпускник группы ITM-24
Школы IT-менеджмента
РАНХиГС при Президенте РФ

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

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

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

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

Сталкиваясь и анализируя описанные выше и подобные им проблемы, я пришел к выводу, что серьезно улучшить ситуации можно внедрив адаптированный под заказчика Rational Unified Process (RUP) – наиболее полную методологию разработки ПО, созданную компанией Rational Software.

Выбор склонился в сторону RUP по многим причинам. Основная из них заключается в том, что RUP – это проверенная временем и надежная методология, в основном разработанная еще в 1996 году. И, конечно же, ключевые принципы RUP, которые гораздо важнее при длительном жизненном цикле продукта, который, как правило, и имеет место быть у заказчика:

• Итеративность: улучшение понимания проблемы и принятие эффективных решений после каждой итерации, гибкость при появлении новых и изменении существующих требований.
• Управление изменениями и требованиями: сбор и организация изначальных требований, отслеживание изменений, оценка влияния таких изменений
• Компонентная архитектура: стабильная и расширяемая архитектура, использование компонентов в других системах или решениях.
• Визуальное моделирование: использование UML-диаграмм облегчает и формализует коммуникации между внешней (часто меняющейся) командой разработки и ИТ-специалистами заказчика.
• Управление качеством: различные виды тестирования, проводятся на всех итерациях жизненного цикла.

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

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

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

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