Тема 3.2 Технология rup

Rational Unified Process (RUP) представляет собой целостную методологию организации процессов разработки программного обеспечения, которая включает в себя несколько заранее сформированных реферативных реализаций. Процессы, организуемые на основе RUP, варьируются от наиболее простых - предназначенных для небольших проектов с коротким циклом разработки - до более сложных процессов, покрывающих более широкий спектр потребностей больших, возможно даже распределенных, групп разработчиков. RUP успешно применяется в проектах любых типов и объемов. Данная статья описывает, как применять упрощенную версию RUP в небольших проектах. Мы описываем эффективные способы применения приемов экстремального программирования (XP - eXtreme Programming) в более широком контексте полного цикла проекта.

Мы посмотрим, как выбирать правильный уровень процессов, используя две популярные методологии: RUP (Rational Unified Process) фирмы Rational и XP (eXtreme Programming - экстремальное программирование). Мы покажем, как можно применять RUP в небольших проектах, и как это решает многие вопросы, не рассматриваемые в XP. Комбинация дает команде разработчиков методику, необходимую для устранения рисков и достижения своих целей по поставке программного продукта.

RUP - это схема процессов, разработанная в Rational Software. Это итеративная методология, основанная на шести признанных в отрасли лучших технологиях (см. RUP appendix). Разворачиваясь во времени, проект на основе RUP проходит через четыре фазы:

• фаза обследования (Inception),

• фаза проработки проекта (Elaboration),

• фаза построения системы (Construction),

• фаза передачи в эксплуатацию (Transition).

Каждая фаза включает одну или несколько итераций. На каждой итерации вы прилагаете различные усилия для выполнения нескольких задач (или последовательностей работ), таких как определение требований, анализ и проектирование, тестирование и так далее. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.

Для понимания того, как учет риска может влиять на формирование процесса, мы можем спросить себя, должны ли мы моделировать бизнес? Если существует сколько-нибудь значительный риск того, что отсутствие понимания бизнеса может привести к разработке неадекватной системы, мы, вероятно, должны потратить некоторые усилия на моделирование бизнеса. Должны ли мы придерживаться формальностей во время моделирования? Это зависит от нашей аудитории - если небольшая команда будет использовать результаты неформально, мы можем обойтись несколькими документами в свободной форме. Если другие сотрудники организации будут использовать эти результаты, или анализировать их, мы, возможно, должны приложить дополнительные усилия и уделить больше внимания корректности и понятности представления модели.

Вы можете адаптировать RUP для соответствия нуждам практически любого проекта. Если ни один из реферативных процессов или шаблонов не подходит к вашим конкретным требованиям, вы можете легко сформировать свою собственную схему. Схема описывает, как планировать проект на основе процессов, и таким образом представляет конкретную реализацию процессов для данного проекта. Это значит, что методология RUP может быть упрощена или усложнена по необходимости, что мы и проиллюстрируем в данной статье.

XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Это интеллектуальное детище Кента Бека и привлекло внимание программной индустрии в результате выполнения проекта С3 в Chrysler Corporation где-то в 1997 году. Также как и RUP, эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. XP предлагает несколько подходов, которые эффективны для соответствующих проектов и обстоятельств, но содержит неочевидные предположения, работы и роли.

RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. Наш опыт показывает, что большинство программных проектов находится где-то посередине - в попытке достичь правильного уровня процессов для своей ситуации. Ни одна из границ спектра для них не является достаточной.

Когда вы объединяете универсальность RUP с некоторыми из техник XP, вы достигаете правильного соотношения процессов, что является привлекательным для всех членов команды проекта и служит предотвращению всех основных рисков проекта. Для команды небольшого проекта, работающей в окружении с относительно высоким уровнем доверия, где пользователь является участником команды, XP подходит чрезвычайно хорошо. По мере того, как команда становится более распределенной и объем кода возрастает, или при плохой проработке архитектуры, вам требуется что-то иное. Вам нужно нечто большее, чем XP, для проектов, в которых принят "контрактный" стиль взаимодействия с пользователем. RUP является базой, на которой вы можете построить XP с более надежным набором техник, чем обычно требуется для этого подхода.

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

Начало проекта - Inception

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

Во время первоначального обследования вы формируете бизнес прецеденты для разработки программного обеспечения. Ключевым артефактом, производимым в результате первоначального обследования, является концепция системы (Vision). Это описание системы на верхнем уровне. Оно объясняет всем, что собой представляет система, а также может определять, кто и для чего будет ее использовать, какие возможности должны в ней присутствовать и какие существуют ограничения. Концепция системы может быть очень короткой, возможно всего один - два параграфа. Часто в концепции сформулированы критически важные возможности программы, которые должны быть предоставлены заказчику.

В следующем примере показано очень короткая концепция, созданная для проекта по реинжинирингу внешнего Web-сайта компании Rational.

Поддержание позиции Rational в качестве мирового лидера в автоматизации разработки (средства, услуги и передовые технологии) за счет упрочения связей с потребителями через динамическое, персонализированное Web-присутствие, обеспечивающее посетителю самообслуживание, поддержку и целевой контент. Новый процесс и обеспечивающие технологии дадут возможность поставщикам информации ускорить публикацию и качество контента за счет простого в использовании автоматизированного решения.

RUP специфицирует четыре важных задачи, решаемых на этапе начального обследования:

• Формулировка рамок проекта. Если мы собираемся разрабатывать систему, мы должны знать, что она собой представляет, и как она будет удовлетворять требованиям заказчиков. При решении этой задачи мы определяем контекст и наиболее важные требования с достаточной степенью детализации для формирования критериев приемки продукта.

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

• Синтез предварительной архитектуры. Если в рассматриваемой системе достаточно мало новшеств, и она имеет ясную архитектуру, вы можете пропустить этот шаг. Как только нам становятся известны требования заказчика, мы выделяем время на рассмотрение потенциально возможных архитектурных решений. Новые технологии приносят возможность новых и улучшенных решений для проблем программного обеспечения. Требуемое время на ранних стадиях проекта на сравнительный анализ затрат на приобретение или собственную разработку, так же как и на выбор технологий и, возможно, разработку первоначального прототипа, могут снизить некоторые из значительных рисков проекта.

• Подготовка инфраструктуры проекта. Для любого проекта требуется инфраструктура. Используете ли вы некоторые из техник XP, такие как парное программирование, или более традиционные подходы, вам необходимо определить физические ресурсы, программные средства и процедуры, которым должна следовать команда разработчиков.

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