RUP: коротко · Конспекты по бизнес-анализу

Главные идеи#

Что такое RUP#

RUP — процесс разработки ПО и управления проектами от компании Rational Software, позже вошедшей в IBM. Его создали Филипп Крачтен, Ивар Якобсон и другие как дополнение к языку моделирования UML. RUP описывает обобщённый процесс, который организация или команда адаптирует под свои нужды. Его можно вести довольно последовательно, с большим объёмом документов, или в более лёгком итеративном режиме.

Маглинец относит RUP к методологиям, созданным специально для разработки информационных систем (см. Методологии бизнес-анализа и ARIS). Ракурс «Информационные технологии» в Руководстве BABOK® описывает Унифицированный процесс (Unified Process) как адаптивный, но не гибкий и отмечает, что для бизнес-аналитиков важнее всего его фазы начала и уточнения.

Шесть принципов#

RUP опирается на шесть принципов. Кратко:

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

Фазы и дисциплины#

RUP делит проект на четыре фазы: Начало (Inception), Уточнение (Elaboration), Построение (Construction) и Внедрение (Transition). Базовые версии требований обычно фиксируют на границах фаз. Внутри каждой фазы работа организована по дисциплинам: бизнес-моделирование, требования, анализ и проектирование, реализация, тестирование и другие. Работа аналитика сосредоточена в дисциплине «Требования», особенно в фазах начала и уточнения.

Артефакты аналитика#

Видение: краткое описание продукта — проблема, заинтересованные стороны и пользователи, ключевые потребности и список высокоуровневых функций (features) с атрибутами: статус, выгода, трудоёмкость, риск, стабильность, целевой релиз. На него опираются при принятии решений на протяжении всего проекта и при приёмке в конце.
План управления требованиями: как требования собирают, идентифицируют, трассируют, снабжают атрибутами, фиксируют в базовых версиях и изменяют, включая работу совета по управлению изменениями.
Спецификация требований к ПО: детальные требования. RUP предлагает два варианта: один строится на модели вариантов использования плюс дополнительные спецификации для нефункциональных требований, другой — «традиционный», на основе IEEE 830.

Шаблоны RUP также показывают типичную цепочку трассировки: запросы заинтересованных сторон → потребности заинтересованных сторон (в «Видении») → функции (в «Видении») → варианты использования → дополнительные требования.

Почему «Видение» важно#

Статья о документе «Видение» в RUP обосновывает его данными отчёта CHAOS от Standish Group: ясные цели и минимальные границы проекта входят в число главных факторов успеха ИТ-проектов. Краткое согласованное «Видение» работает на оба фактора.

Как применять#

Даже если ваша команда не работает по RUP:

Напишите краткое «Видение». Формулировка проблемы, заинтересованные стороны, ключевые потребности и список высокоуровневых функций. Шаблон RUP советует ограничивать список для полного продукта примерно 25–99 функциями, чтобы он оставался обозримым; небольшому проекту нужно меньше. Используйте «Видение» как ориентир для решений о границах.
Позаимствуйте атрибуты функций. Статус, выгода, трудоёмкость, риск и целевой релиз подходят как поля бэклога в любом инструменте.
Возьмите на вооружение цепочку трассировки. Связывайте запросы с потребностями, потребности — с функциями, функции — с вариантами использования или историями. Так анализ влияния делается быстро. Подробнее — в разделе о трассировке требований.
Продумайте вопросы фаз начала и уточнения заранее, даже в гибких командах: определитесь с проблемой, границами и архитектурными рисками до того, как бэклог разрастётся.
Адаптируйте без жалости. Сам RUP требует, чтобы его адаптировали. Отбросьте артефакты, которые никто не читает.

Пример#

Аналитик «Мастерской», вымышленной сети из 12 веломастерских, пишет краткое «Видение» и список функций для внешней команды разработки:

Функция	Выгода	Трудоёмкость	Риск	Целевой релиз
Онлайн-запись на ремонт	Критическая	Средняя	Низкий	1
SMS о статусе ремонта	Критическая	Средняя	Средний	2
Учёт запчастей, использованных в каждом заказе	Важная	Средняя	Высокий	2
Ежемесячный дашборд по каждой мастерской	Полезная	Низкая	Низкий	3

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

Подводные камни#

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

Источники и что почитать#

Шаблоны документов IBM Rational Unified Process (RUP): Vision, Software Requirements Specification, Requirements Management Plan.
Разработка видения системы в методологии IBM Rational Unified Process (статья).
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Разд. 11.3 (ракурс «Информационные технологии»: Унифицированный процесс).
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекции 3–4 (классификация методологий).
Standish Group, CHAOS report, по данным, приведённым в статье о документе Vision в RUP.