Лекция 10

Подходы разработки ПО

Rational Unified Process

•Рациональный унифицированный

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

Унифицированный процесс

[от] Rational Software.

Rational Unified Process

•Исторически РУП является развитием подхода Objectory Process, созданный А. Якобсоном как развитие его методики Объектно-ориентированная инженерия ПО. В 1987 г. автор основал компанию Objectory AB. После вливания Objectory AB в Rational в 1995 г. подход Якобсона был объединён с Rational Approach. Этот подход основан на работах У. Ройса,

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

методика анализа и проектирования, получившая название языка UML.

Rational Unified Process

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

•Rational Unified Process является также продуктом, предоставляемым IBM Rational. В этом качестве он представляет собой структурированную интерактивную базу знаний с шаблонами артефактов

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

Rational Unified Process

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

В частности, подход MSF долгое время основывался на этом наборе до разработки собственного набора средств.

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

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

Rational Unified Process

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

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

Лучшими считаются следующие практики, используемые в РУП:

1.Итеративная разработка;

2.Управление требованиями;

3.Использование компонентной архитектуры;

4.Визуальное моделирование;

5.Проверка качества;

6.Контроль изменений.

Итеративная

разработка

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

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

сминимальными затратами;

•возможность организовать устойчивую обратную связь

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

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

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

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

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

Управление требованиями

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

иподразумевает:

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

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

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

ивыявление зависимости между ними;

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

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

ирасхождений;

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

Компонентная

архитектура

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

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

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

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

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

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

Визуальное моделирование

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

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

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

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

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

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