Методология RUP

Рациональный унифицированный процесс (Rational Unified Process, RUP) — одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

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

RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

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

Для успешного процесса разработки необходимы три составляющие (рис. 1): процесс (process), нотация (notation) и набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом; нотация является средством общения; набор утилит помогает автоматизировать процесс и управлять им.

Рис. 6.1. Треугольник успеха

В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые производят следующие действия:

• осуществляет «склеивание» процесса в единое целое;

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

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

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

Фактически нотация охватывает разработку программного обеспечения, начиная с анализа и заканчивая внедрением продукта. Нотация в случае RUP–UML — формальное языковое средство описания процесса (об UML речь пойдет ниже). Далее рассмотрим структуру процесса, а также приведем набор утилит, используемых в процессе управления разработкой проекта согласно RUP.

RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем использовать английские термины, сопровождая их переводом на русский язык. На рис. 2 представлено широко распространенное изображение фаз RUP. Целями каждой из данных фаз являются:

• Inception — понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;

• Elaboration — понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;

• Construction — создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);

• Transition — создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

Рис. 6.2. Фазы RUP

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

Методология RUP основана на девяти основных потоках (workflow), являющихся элементами итерации жизненного цикла ПО:

• Business modeling (бизнес-анализ) — предполагает анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей;

• Requirements (требования) — формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases (пользовательских историй) — формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента;

• Analysis and design (анализ и моделирование) — предполагает перевод собранных требований в формализованную программную модель. Результатом является описание системы на фазе реализации (технический проект) — это документы уровня разработчиков системы. Язык формализации — Unified Modelling Language (UML), о котором речь пойдет ниже. В процессе итеративной разработки эволюционировать будет продукт именно этого потока — модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является не модель, а исполняемый код, поэтому заказчик обычно не очень любит платить за моделирование, так как модели не являются продуктом, который ему нужен);

• Implementation (реализация, кодирование) — предполагает собственно написание кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство реализации UML — Rational Rose — позволяет создавать элементы кода на нескольких языках программирования. Методология — объектно-ориентированное программирование;

• Test (тестирование) — предполагает тестирование продукта на данной итерации. Стоит специально отметить, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы;

• Deployment (внедрение) — предполагает установку продукта на полигоне заказчика, подготовку персонала, запуск системы плюс приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).

Приведенные выше элементы не являются новыми в плане жизненного цикла разработки ПО, поскольку имеют место практически в любой методологии — возможно, за исключением XP (где они, тем не менее, представлены в весьма оригинальном виде). Особенностью реализации RUP являются временные акценты, а именно — на каких итерациях будут доминировать те или иные потоки, а также наличие универсального языка и набора утилит, позволяющего описывать процесс разработки. Как мы видим на рис. 6. 2, на начальных этапах эволюции продукта основное внимание уделяется формализации проекта (анализ, моделирование), что направлено на сокращение коммерческих рисков и снижение стоимости ошибок дизайна. Когда картина более или менее ясна, начинаются собственно разработка, тестирование и, наконец, внедрение продукта.

Preliminary interna — это фактически документы, выпускаемые техническим советом для менеджеров предприятия. Основная цель начальных этапов — заключение контракта или соглашения о намерениях. Дальнейшие итерации — собственно начало работы коллектива разработчиков, который имеет время и ресурсы для построения формальных моделей. UML в данном случае имеет средства, позволяющие отображать модель на элементы кода. Например, дерево объектов отображается непосредственно, вариации зависят от мощности реализации выбранного разработчиками языка программирования, а также от совпадения взглядов Г.Буча и разработчиков данного языка на объектную модель. То же самое относится к методам.

Теперь рассмотрим элементы, касающиеся поддержки продукта, — core supporting workflows:

• Configuration management (управление конфигурацией и изменениями) — мощный слой административных действий, направленных на управление версиями продукта, что предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, корпоративные стандарты разработки кода и документации, отслеживание изменений и ошибок (bug tracking); тесно связан с тестированием и поддержкой пользователей (customers support);

• Management (управление проектом) — предполагает набор административных действий управления проектом согласно идеологии RUP, используются средства управления проектом (см. ниже список продуктов Rational);

• Environment (окружение) — предполагает создание и поддержку средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).

В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект:

• итеративная разработка;

• управление требованиями;

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

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

• проверка качества;

• отслеживание изменений.

Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы к использованию. Часть практик прямо вытекает из идеологии RUP. Так, итеративная разработка заложена в структуру RUP, поскольку этот процесс является одной из реализаций «спирали». Управление требованиями в RUP появляется на самых ранних стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать код, и система получается более гибкой. В силу того что UML является объектным языком, игнорировать модульность можно, но… несколько затруднительно. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Кроме того, модели являются средствами коммуникации между разработчиками, но для этого разработчики должны говорить на UML, что предполагает определенный тренинг. Визуальное моделирование часто осуществляется с помощью инструмента Rational Rose, что позволяет получать набор весьма полезных документов для менеджеров, системных администраторов, разработчиков, тестировщики, генерировать элементы кода. Данное средство не является единственной реализацией UML — доступны как коммерческие альтернативы (например, Microsoft Visio), так и бесплатные. Следует отметить, что диалекты UML, реализованные в средствах моделирования, не всегда совпадают: диалект Rational имеет некоторые серьезные различия, описанные как в документации, так и в книгах по UML.