Rational Unified Process

RUP использует объектно-ориентированный подход при проектировании и документировании, применяя нотацию UML (Unified Modeling Language) для иллюстрации процессов. Методика опирается на коммерчески апробированные технологии и практики.

Данный процесс считается «тяжёлым» и используется преимущественно для крупных команд и масштабных проектов, однако его адаптивность позволяет применять RUP и к проектам различной сложности и размера. Для управления проектом RUP обеспечивает дисциплинированный способ определения задач и распределения ответственности между участниками команды.

RUP является программным продуктом: он модульный, автоматизированный, а вся методология поддерживается различными интегрированными средствами разработки, реализуемыми и распространяемыми IBM в составе Rational Suites^[1].

Конкурирующие подходы в данной области: Cleanroom, относящийся к тяжелым процессам, и гибкие методологии ("лёгкие" процессы), такие как экстремальное программирование (XP), Scrum, FDD и другие.

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

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

Пользовательские сценарии и сценарии использования служат артефактами процесса, эффективно помогающими фиксировать функциональные требования.

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

RUP предлагает систематичный подход к созданию подобных систем, сосредотачиваясь на разработке рабочей архитектуры ещё на ранних этапах проекта, до масштабного расходования ресурсов.

Подобные компоненты обычно реализуются с использованием существующих инфраструктур, таких как CORBA и COM.

Абстрагирование программного кода и его визуальное представление в виде графических блоков позволяет получить наглядное понимание решения.

Визуальное моделирование дает возможность немедленно осознать архитектуру даже менее техническим участникам, что способствует их вовлечению в работу над проектом.

Язык моделирования UML стал промышленным стандартом представления проектных решений и широко используется в RUP.

Отсутствие управления качеством ПО — одна из частых причин провалов проектов. Обычно вопросами качества занимаются после завершения разработки либо перекладывают ответственность на отдельные команды.

RUP позволяет управлять качеством на всех этапах, включая в этот процесс всю команду — контроль строится во время выполнения всех стадий производства.

Изменения — неотъемлемая часть любого проекта. RUP определяет процедуры контроля и отслеживания изменений, что очень важно: даже небольшое изменение способно повлиять на итоговую работу непредсказуемым образом.

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

Основные концепции распространяются на весь жизненный цикл проекта, а фазы обозначают, на каком именно этапе акцентируется основное внимание.^[2] Временное развитие проекта отображается делением процесса на четыре фазы:

1. Инициация (или концепция): определение области охвата системы;
2. Элаборация: детальное проектирование архитектуры;
3. Конструкция: активная разработка;
4. Переход: внедрение и развёртывание.

Также выделяют четыре ключевых аспекта («4P»):

1. Люди
2. Проект
3. Продукт
4. Процесс

Фазы состоят из итераций — временных отрезков с определёнными целями; фазы задают глобальные цели, а итерации имеют жёсткие временные рамки.

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

На этапе инициации (концепции) проводится согласование ключевых целей заинтересованных сторон по задачам, архитектуре и плану проекта. Если заказчики хорошо осведомлены, анализа требуется немного — при недостаточном понимании анализ будет более глубоким.

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

Итерационный подход (разбиение на этапы) в этой фазе также рекомендуется: итерации должны быть чётко определены по числу и целям.

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

На этапе конструирования стартует собственно программирование: написание кода, альфа-тестирование. Бета-тестирование осуществляется в начале фазы перехода.

Результаты этой фазы включают как выполненные тесты и их стабильные процедуры, так и «базовые» версии исходного кода системы.

На переходной фазе осуществляется развёртывание продукта, создание плана внедрения, обучение пользователей и контроль качества итоговой версии. Итогом являются релизы/версии продукта и удовлетворённость клиента.

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

Бизнес-моделирование описывает, как формализовать видение разрабатываемой организации и использовать это видение при определении процессов, ролей и ответственности.

Данная дисциплина определяет, как отобрать запросы пользователей (stakeholders) и превратить их в совокупность требований, по которым строится система, а также обеспечить детальную спецификацию поведения системы.

Цель анализа и проектирования — показать, каким образом будет реализована система. Основные задачи:

• Обеспечить выполнение системой всех задач, определённых в пользовательских сценариях;
• Удостовериться, что требования удовлетворены полностью;
• Обеспечить простоту поддержки в случае изменения требований.

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

Основные задачи на этапе реализации:

• Структурирование исходного кода в виде слоёв и модулей;
• Реализация классов и объектов как компонентов (исходные файлы, библиотеки, исполнимые модули и т. д.);
• Тестирование компонентов как самостоятельных единиц;
• Интеграция отдельных результатов (или команд) для получения работоспособной системы.

При этом описывается, как максимально переиспользовать существующие компоненты или разрабатывать новые с чётко ограниченной ответственностью.

Основные цели дисциплины тестирования:

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

Rational Unified Process строится на итеративном подходе, что означает повторное тестирование проекта на каждом этапе, позволяя выявлять дефекты как можно раньше и существенно снижать стоимость их устранения. Тесты проводят по четырём основным направлениям: надёжность, функциональность, производительность приложения, производительность системы. Для каждого направления RUP предлагает последовательность планирования, проектирования, реализации, выполнения и анализа результатов тестирования.

Цель дисциплины внедрения — успешный выпуск (релиз) продукта и доставка программного обеспечения конечным пользователям. Это включает создание внешних релизов, упаковку и распространение ПО, установку и техническую поддержку при освоении пользователями. Хотя большинство задач внедрения сосредоточено в фазе перехода, многие мероприятия должны планироваться и в ранних фазах для оптимальной подготовки развертывания.

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

Дисциплина управление изменениями охватывает три направления: управление конфигурацией, управление запросами на изменения и управление статусом/метриками изменений.

• Управление конфигурацией — систематизация версий артефактов (документов и моделей), контроль их изменений и зависимостей.
• Управление запросами на изменения — отслеживание предложенных изменений на всех этапах проекта.
• Управление статусом и метриками — фиксация состояния изменений, анализ первопричин, приоритетов, хранение информации в специальной базе для формирования аналитических отчетов. IBM Rational предлагает для этого отдельный продукт (ClearQuest).

Планирование в RUP ведётся на двух уровнях: фазы (низкая детализация, охват всего проекта) и итерации (высокая детализация, шаги внутри фазы). Эта дисциплина концентрируется на специфике работы с итеративным проектом: управление рисками, планирование и сопровождение проекта по метрикам. Некоторые аспекты (такие как кадровое и финансовое управление, заключение договоров) RUP не регламентирует.

RUP строится на ряде принципов и проверенных временем лучших практик. Ключевые из них:

1. Итеративная разработка
2. Управление требованиями
3. Использование архитектуры на основе компонентов
4. Визуальное моделирование
5. Верификация качества программного обеспечения
6. Управление изменениями

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

RUP использует итеративную и инкрементальную разработку по ряду причин:

• Интеграция осуществляется пошагово, охватывая небольшие фрагменты;
• Простота интеграции снижает стоимость и облегчает процесс;
• Легко выделить отдельные модули для повторного использования;
• Все изменения требований фиксируются и могут быть учтены;
• Возможность идентификации и проверки рисков на ранних этапах;
• Архитектура улучшается за счёт постоянных пересмотров.

Итерационный подход предполагает как общий проектный план, так и планы на каждую отдельную итерацию. Активное вовлечение заказчиков происходит после каждой поставки — это способствует закреплению договорённостей и постоянной синхронизации требований и степени их реализации.

Управление требованиями в RUP направлено на выявление реальных нужд пользователя — описание и согласование списка требований, а также обеспечение учёта изменений. Преимущества:

• Корректно определённые требования обеспечивают корректное функционирование итогового продукта;
• Своевременное включение важных характеристик снижает вероятность дополнительных затрат впоследствии.

В рамках RUP управление требованиями включает:

• анализ проблемы и выработку критериев, по которым оценивается полезность решения для организации;
• определение основных заинтересованных сторон, описание их нужд;
• формализацию требований и описание сценариев использования, выявление высокоуровневых и уточнение детальных требований;
• управление областью охвата — фиксация и изменение объёма работ на основании промежуточных результатов;
• детализацию (формирование спецификаций требований) в работе с заказчиками, что в дальнейшем служит договором между сторонами и основой для деятельности по тестированию и проектированию;
• управление изменениями — отслеживание и учёт новых требований по ходу реализации проекта.^[3]

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

Чем сложнее и более масштабна система, тем важнее её архитектурное проектирование — RUP уделяет особое внимание построению базовой архитектуры с первых итераций, превращая её затем в конечную архитектуру продукта.

Поддерживаются также повторно используемые инфраструктуры — например, CORBA, COM, JavaEE, PHP.

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

Унифицированный язык моделирования (UML) используется для построения пользовательских сценариев, диаграмм классов и других объектов. RUP описывает и другие подходы к созданию визуальных моделей.

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

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