Источник: http://wa.artel.by/
Очевидно, что выбор методологии дело непростое, особенно когда нет опыта использования ни одной из них. Для начала неплохо бы познакомиться с ними поближе.
На сегодняшний день это одна из самых известных методологий. Разработана она
компанией Rational Software
RUP, как и любой современный продвинутый процесс, является итеративным. Это значит, что создание продукта происходит за несколько итераций. В конце каждой итерации получается работающая версия продукта, но с неполным функционалом. В последующих итерациях функционал дорабатывается и в конце последней итерации получается полностью готовый продукт. Идею итеративного процесса можно показать следующим образом:
Каждый виток спирали является итерацией. Таким образом система постепенно обрастает функционалом.
У итеративной разработки много плюсов. Большое количество релизов сильно влияет на качество конечного продукта, который тестируется в каждой итерации. Также уже на ранних стадиях можно проверить ожидания пользователей и внести изменения в продукт, если требуется. Кроме того, планировать проект гораздо проще, потому что уже после первой итерации все становится более предсказуемым, и управляющий проектом сможет с большей достоверностью прогнозировать реальные сроки окончания следующих итераций.
Надо сказать, что в RUP прямо не сказано о корректной итеративности процесса. Так что RUP можно успешно использовать и для водопадного процесса, где все стадии следуют строго друг за другом и готовый продукт выходит в самом конце. Поэтому при настройке RUP надо обязательно обратить внимание на итеративность и внедрить ее корректно.
Кроме того, RUP управляется сценариями
пользователей
В RUP сценариям пользователей отведено почетное место, процесс является use-case driven, то есть управляемый сценариями пользователей.
Процесс имеет четыре фазы:
На каждой из фаз основное внимание уделяется разным процессам. На фазе исследования идет сбор и анализ требований, на фазе уточнения плана - анализ требований и проектирование системы, на фазе построения - разработка и кодирование, на фазе развертывания - тестирование и распространение.
Методология RUP основана на 9-ти основных потоках:
Все эти девять потоков и четыре фазы изображают в виде затасканной картинки,
которую аккуратно вставляют в любую статью о RUP
Любой проект в RUP проходит четыре фазы. Через эти фазы проходят и все девять потоков. Каждая фаза в свою очередь разбивается на итерации. Если взять, например, первую итерацию на фазе Исследования, то основное внимание на этой итерации уделяется бизнес-анализу, сбору требований и моделированию, но кодирование тоже есть. Если взять одну из последних итераций на фазе Построения, то основное внимание уделяется кодированию, тестированию и управлению конфигурацией. Иными словами, по мере развития проекта в каждой итерации смещаются акценты. Это и правильно, ближе к концу особо анализировать нечего, а требования собирать как-то поздно.
Неотъемлемую часть RUP составляют артефакты и роли. При разработке программы создаются разные артефакты, и за создание того или иного артефакта отвечает определенная роль. Например, диаграмму классов создает Архитектор, а сценарии тестирования пишет Дизайнер тестов.
Все визуальное моделирование осуществляется с помощью CASE-средств. Основой
для него служит язык UML
Сама RUP основывается на шести лучших практиках (best practices):
Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса.
Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки, кроме того, в итоге продукт получается более качественным, потому что база тестируется столько раз, сколько итераций проходит продукт.
Управление требованиями - один из важнейших процессов при разработке более-менее серьезных продуктов. Благодаря ему продукт более точно соответствует ожиданиям заказчика. Инструментальная поддержка обеспечивается Requisite Pro
В теории модульная архитектура позволяет повторно использовать код и система получается более гибкой. На практике это практически невозможно реализовать.
Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом работает система, что она делает и как она это делает. Кроме того, модели являются средствами коммуникаций между разработчиками, но для этого они должны быть понятны каждому. Вот для этого в RUP используется UML, который позволяет разработчикам говорить на одном языке. Инструментальная поддержка обеспечивается Rational Rose.
Качество продукта - одна из важнейших его характеристик. Заявляется, что RUP ориентирован на достижение приемлемого уровня качества, однако в процессе адаптации этой методологии с качеством могут возникать проблемы, если адаптация будет не совсем удачной. Инструментальная поддержка обеспечивается целым рядом программ: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot.
Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика, либо на изменяющиеся условия внешней среды. RUP имеет процессы, которые позволяют эффективно отслеживать изменения. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest.
RUP является адаптируемым процессом, то есть его можно настраивать под нужды конкретной команды и под конкретный проект. Более того, это делать совершенно необходимо, поскольку в противном случае эффективность использования RUP будет стремиться к нулю.
В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов. Естественно, что если команда состоит из 5 человек, то просто нет смысла вводить все эти роли и создавать все артефакты. Вообще чем меньше команда, тем легче должен быть процесс. То есть надо создавать минимум артефактов и вводить минимум ролей.
Так вот RUP позволяет настроить процесс. Из общего описания RUP можно взять только те процессы, роли и артефакты, которые действительно нужны команде для разработки качественного продукта в срок и в пределах бюджета.
Например, возьмем управление требованиями. В общем описании RUP присутствуют следующие артефакты: план управления требованиями, модель сценариев пользователей, спецификация требований системы, видение, репозиторий требований. Для маленького проекта вполне достаточно спецификации требований и набора отдельных сценариев. Но для крупного проекта совершенно необходим репозиторий, потому что без него отслеживание и изменение требований превратиться в головную боль системного аналитика.
Однако настройка RUP под конкретный проект - нетривиальная задача. Если решать ее будет тот, кто до этого внедрением RUP не занимался, есть риск получить на выходе совершенно неподходящий процесс, состоящий из бестолкового нагромождения артефактов, потоков и ролей, на которые тяжелым грузом лягут продукты Rational Software.
Вообще считается, что RUP достаточно тяжелая методология, которая лучше подходит для больших команд. Одной из попыток облегчить RUP является методология dX. Она объединяет в себе RUP и XP, о которой мы поговорим в следующий раз.