Рациональный унифицированный процесс (rup)

Рациональный унифицированный процесс(РУП,RUP – Rational Unified Process) – унифицированный каркасный подход, предлагаемый фирмойRational Software Corporation(с 2003 г. – подразделениеIBM Corporation); поэтому возможен и другой перевод названия:Унифицированный процесс [от] Rational Software.

Исторически РУП является развитием подхода Объекторный Процесс (Objectory Process), принятого в компанииEricssonв 70‑х – 80‑х гг. XX в. Объекторный Процесс был создан А. Якобсоном как дальнейшее развитие его методики Объектно-ориентированная инженерия ПО. Впоследствии, в 1987 г., автор основал собственную компаниюObjectory ABименно для развития своего технологического подхода разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливанияObjectory ABвRationalв 1995 г. подход Якобсона был объединён с Рациональным Подходом (Rational Approach). Рациональный подход основан на работах У. Ройса, Ф. Крухтена и Г. Буча.

Объединённый подход вначале получил название Рациональный Объектный Процесс (РОП, ROP – Rational Objectory Process), затем, после включения поддержки бизнес-моделирования, переименован в РУП. Кроме этого в подход была включена развивавшаяся в это время сотрудникамиRationalобъектно-ориенти­рованная методика анализа и проектирования, получившая название языкаUML.

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

Rational Unified Processявляется также продуктом, предоставляемымIBMRational. В этом качестве он представляет собой структурированную интерактивную базу знаний с шаблонами артефактов и подробным описанием различных типов действий, которое включает в себя общие принципы, конкретные рекомендации и примеры по эффективной разработке систем. База знаний регулярно обновляется и совершенствуется с учётом передового опыта.

Этот продукт входит как составная часть в набор инструментальных средств IBMRationalдля поддержки РУП. Некоторые из этих средств благодаря возможности их расширения оказываются применимыми в качестве инструментария для других подходов. В частности, подходMSFдолгое время основывался на этом наборе до разработки собственного набора средств.

Основы подхода

Исследование различных неудачных проектов привело авторов РУП к выявлению признаков и первопричин их провала.

Основными считаются следующие первопричины:

1. Непланируемое управление требованиями.

2. Неоднозначное и неопределённое взаимодействие.

3. Хрупкая архитектура (архитектура, не работающая в стрессовых условиях).

4. Непреодолимая сложность.

5. Необнаруженные несогласованности между требованиями, дизайном и реализацией.

6. Недостаточное тестирование.

7. Субъективная оценка состояния проекта.

8. Провал из-за накопившихся рисков.

9. Неконтролируемое распространение изменений.

10. Недостаточная автоматизация.

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

1. Неточное понимание потребностей конечных пользователей.

2. Неспособность иметь дело с изменяющимися требованиями.

3. Не соответствующие друг другу модули.

4. Тяжёлое для сопровождения и расширения ПО.

5. Позднее обнаружение серьёзных недостатков в проекте.

6. Плохое качество ПО.

7. Неприемлемая производительность ПО.

8. Невозможность участников проекта даже совместно определить (или вспомнить), кто что изменил, когда, где и почему.

9. Ненадёжный процесс построения и выпуска.

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

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

Лучшая практика– практика разработки ПО, проверенная на многих реальных проектах и позволяющая в комплексе с другими лучшими практиками повысить эффективность проекта и обеспечить успех организации.

Лучшими считаются следующие практики, используемые в РУП: 1. Итеративная разработка;2. Управление требованиями;3. Использование компонентной архитектуры;4. Визуальное моделирование;5. Проверка качества;6. Контроль изменений.

Итеративная разработка заключается в создании требуемой системы итерациями, что обеспечивает:

– снижение воздействия серьёзных рисков на ранних этапах проекта, пока это ещё можно сделать с минимальными затратами;

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

– концентрация усилий на наиболее важных направлениях проекта;

– непрерывное итеративное тестирование продукта, позволяющее оценить успешность всего проекта в целом;

– раннее обнаружение несогласованностей между требованиями, дизайном и реализацией;

– равномерное распределение ресурсов проекта;

– реальная оценка текущего состояния проекта.

Управление требованиями включает в себя выявление, организацию и документирование требований к системе и подразумевает:

– организованный подход к управлению требованиями;

– взаимодействие участников проекта на базе выявленных и утверждённых требований;

– ранжирование требований по приоритету, фильтрация их по необходимым параметрам и выявление зависимости между ними;

– объективная оценка состояния проекта на основе реализованной функциональности и текущей производительности системы;

– раннее обнаружение различных несоответствий и расхождений;

– использование инструментальных средств для организации более эффективного процесса управления требованиями.

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

– повышения гибкости архитектуры создаваемой системы;

– чёткого определения изменений, требующихся при доработке системы;

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

– упрощения задач по управлению конфигурацией продукта;

– использования средств визуального моделирования, опирающихся на компонентный подход.

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

– однозначно описать функциональное поведение разрабатываемой системы;

– определить архитектурно значимые компоненты системы и сосредоточится на их реализации;

– обеспечить построение гибкой и надёжной архитектуры и системы в целом;

– исключить из рассмотрения второстепенные детали, не влияющие на решение задачи;

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

Проверка качества реализуется с помощью тестирования сценариев. Непрерывная проверка качества обеспечивает следующие выгоды:

– производит оценку состояния проекта по объективным показателям;

– позволяет на ранних стадиях проекта обнаружить несоответствия в требованиях, дизайне и реализации;

– акцентирует внимание на тех сторонах работы системы, которые имеют наибольшую важность и повышенный риск;

– дефекты выявляются на ранних этапах, снижая затраты на их устранение;

– автоматизированное тестирование обеспечивает снижение влияния «человеческого фактора» и повторяемость результатов.

Контроль изменений включает в себя управление запросами на изменение, управление конфигурацией и управление измерением и обеспечивает:

– контроль состояния проекта в целом и отдельных задач на основании статусов запросов на изменение;

– хранение историй изменений по каждому запросу на изменение;

– актуальную информацию по загрузке участников проекта;

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

– учёт трудозатрат участников проекта по выполняемым изменениям;

– упрощение коммуникаций между участниками проекта: необходимые данные об изменениях всегда доступны и актуальны.

Лучшие практики послужили основой для создания подхода РУП.

РУП основан на наборе из 6 ключевых принципов бизнес-управляемой разработки, сокращённо называемый ABCDEF:

1. Адаптация процесса.

2. Баланс приоритетов заинтересованных лиц.

3. Сотрудничество между командами.

4. Демонстрация результата итерационно.

5. Эволюция (рост) уровня абстракции.

6. Фокусировка непрерывно на качестве.

Эти принципы были определены П. Кроллом и У. Ройсом.