Преимущества Rational Unified Process

Методология RUP была целенаправленно разработана для разработки больших программных систем.

Новация №1, заложенная в её основу, это «Бизнес-моделирование» и связанные с ним Сценарии Использования (Use Case).

Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.

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

Пример остановки торгов Московской биржей

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

Новация №2: На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)

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

Новация №3: Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.

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

Вот так выглядит концепт RUP в упрощенном виде:

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

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