IBM Rational Unified Process (RUP)

Многие организации-разработчики программных продуктов год за годом накапливали профессиональные знания в области технологий создания ПО, которые материализовались в виде практических рекомендаций, документации, обучающих программ и книг. Поскольку документация и книги быстро устаревают, со временем эти технологии стали приобретать электронную форму, превращаясь, таким образом, в программный продукт. Как правило, они поставляются вместе с CASE-средствами и включают библиотеки процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, который ориентирована технология. Электронные технологии включают также средства, которые должны обеспечивать их адаптацию для конкретных пользователей и развитие по результатам выполнения конкретных проектов.

На сегодняшний день практически все ведущие компании - разработчики технологий и программных продуктов (IBM, Microsoft, Oracle, Computer Associates, Sybase и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями.

Rational Unified Process-это одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта. RUP представляет собой программный продукт, разработанный компанией IBM Rational Software. RUP является результатом объединения подходов Rational Approach и Objectory Process, происшедшего после слияния в 1995 году компаний Rational Software и Objectory AB (созданной Иваром Якобсоном).

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.).

ISO - это стандарт качества любых процессов, будь то выпуск мороженного или разработка программного обеспечения, а CMM - модель качества, специально соотнесенная с процессом разработки ПО. CMM - большой многоступенчатый стандарт качества, охватывающий весь цикл разработки программного обеспечения: от проектирования и до внедрения. Он годиться и для оптимизации и для улучшения качества выпускаемого ПО.

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

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

Рис. 1.

1.Начальный уровень - это основной стандарт. К данному уровню, как правило,

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

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

3. Определенный уровень. Уровень характеризуется наличием формального подхода к управлению (то есть описаны все типичные действия, необходимые для многократного повторения: роли участников, форматы документов, производимые действия и пр.) Для создания и поддержания подобного стандарта в актуальном состоянии в организации уже подготовлена специальная группа. Компания постоянно проводит специальные тренинги для повышения профессионального уровня своих сотрудников. Начиная с этого уровня организация перестает зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни. Абстрагирование от разработчиков обусловлено продуманным механизмом постановки задач и контроля исполнения. Описание каждого процесса включает в себя условия его выполнения, выходные данные, стандарты и процедуры выполнения, механизмы проверки (например, экспертные оценки), выходные данные и условия завершения. В описании процесса также включаются сведения об инструментальных средствах, необходимых для его выполнения, и указание на роль, ответственную за его выполнение.

4. Управляемый уровень. На этом уровне добавляются следующие процессы:

• управление производительностью и продуктивностью
• количественное управление проектом

На этом уровне, на практике применяется детальная оценка качества как процессов создания, так и самого создаваемого программного продукта. При этом применяются количественные критерии оценки.  Результаты выполнения процессов на четвертом уровне становятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных ограничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.

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

• внедрение технологических и организационных  инноваций
• причинно-следственный анализ и разрешение проблем

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

Из градации уровней видно, что технологические требования сохраняются только до третьего уровня, далее же в основном следуют требования к административному управлению. То есть уровни 4 и 5 по большей части управленческие и для их достижения важно не только выпустить программный продукт, но и проанализировать ход проекта, а также построить планы на будущий проект, основываясь на текущих шаблонах. Применение данных подходов должно обеспечить планомерно-плавное улучшение используемых процессов. Применение RUP и рабочих инструментов IBM Rational гарантирует получение как минимум третьего уровня CMM. Основными принципами методологии RUP являются:

1. Итерационный и инкрементный (наращиваемый) подход к созданию ПО.
2. Планирование и управление проектом на основе функциональных требований к системе - вариантов использования.
3. Построение системы на базе архитектуры ПО.

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

Итерационный цикл основывается на постоянном расширении и дополнении системы в процессе нескольких итераций с периодической обратной связью и адаптацией добавляемых модулей к существующему ядру системы. Система постоянно разрастается шаг за шагом, поэтому такой подход называют итерационным и инкрементным. Такой подход исключает и слишком быстрое написание кода (без детальной проработки) и чрезмерно длительный этап детального проектирования и построения моделей без обратной связи.

Рис. 2. Общее представление RUP.

На рисунке показано общее представление RUP в двух измерениях:

• горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки;
• вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Итерационный (итеративный) и инкрементный (наращиваемый) подход к созданию ПО

Большая часть команд, разрабатывающих программное обеспечение, до сих пор использует в своих проектах каскадную разработку (waterfall process), при фазы выполняются в четкой последовательности: сначала требования, затем анализ и проектирование, потом реализация/интеграция и затем тестирование. Или, что более обычно, модифицированную каскадную разработку с добавлением к вышеописанному ходу действий циклов обратной связи. Такой подход заставляет ключевых членов группы простаивать довольно продолжительное время, а тестирование откладывается на самый конец жизненного цикла проекта, когда проблемы, как правило, являются серьезными, исправлять их дорого и это ставит под угрозу сроки выхода конечного продукта.

В противоположность этому RUP использует итеративных подход (итерация = повторение), то есть последовательность нарастающих шагов или итераций. Каждая итерация включает в себя некоторые или большую часть дисциплин разработки (выявление требований, анализ, проектирование, реализация и т.п.). У каждой итерации есть четко определенный набор целей, и она создает частично работающую реализацию конечной системы. Каждая последующая итерация строится на результатах предыдущих, развивает и усовершенствует систему до тех пор, пока не будет создан конечный продукт. Более ранние итерации больше концентрируются на требованиях, анализе и проектировании, более поздние - на реализации и тестировании.

Рис. 3. Итеративная разработка в RUP.

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

• Итеративный подход приспособлен к меняющимся требованиям. Изменение требования и «распознавание функциональности», - добавление свойств, определяемое заказчиком или нуждами технологии - всегда было самым главным источником проблем проектов. Это приводило к опозданию с выпуском, нарушению графиков, неудовлетворению заказчиков и т.п. Итеративная разработка концентрирует внимание группы на создании и демонстрации исполняемой программы в течение нескольких недель, что заставляет сосредоточится на наиболее существенных требованиях.
• Своевременная интеграция. Оставить интеграцию на самый конец означает получить переработки с большими затратами времени - иногда до 40% всего объема проекта. Чтобы избежать этого, итеративный подход разбивает проект на небольшие итерации, каждая из которых заканчивается интеграцией, при которой строительные блоки постепенно и непрерывно интегрируются, что сводит к минимуму позднейшую переработку.
• Риски обнаруживаются и устраняются на ранних итерациях. Итеративный подход RUP минимизирует риск на ранних итерациях, когда тестируются все компоненты. Поскольку каждая итерация задействует многие аспекты проекта, такие как инструменты, готовое программное обеспечение и навыки членов группы, в можете быстро обнаружить, является ли предполагаемый риск реальным, а также выявить новые, неожиданные риски в то время, когда их легче и не так дорого снять.
• Менеджеры имеют возможность внесения тактических изменений в продукт. Итеративная разработка быстро создает исполняемую архитектуру (хотя и с ограниченной функциональностью), которую можно использовать для быстрого выпуска продукта с некоторыми ограничениями, чтобы ответить на действия конкурента.
• Облегчается повторное использование. Гораздо легче определить общие части тогда, когда они уже частично спроектированы или реализованы в итерациях, чем распознавать их при планировании.
• Дефекты можно найти и исправить за несколько итераций. Это обеспечивает создание четкой архитектуры и высококачественного приложения. Просчеты обнаруживаются еще в ранних итерациях, а не в ходе массированной тестовой фазы в конце. Узкие места производительности обнаруживаются тогда, когда на них еще можно повлиять, а не перед самым выпуском продукта.
• Лучшее использование персонала в проекте. Многие организации совмещают использование каскадного подхода с организацией по типу конвейера: аналитики посылают готовые требования проектировщикам, которые отсылают свой продукт программистам, которые посылают компоненты специалистам по интеграции, которые отсылают систему тестировщикам. Такие многочисленные переходы являются источниками ошибок и недопонимания и заставляют людей меньше чувствовать ответственность за конечный продукт. Итеративный процесс расширяет области компетенции членов группы, разрешая им выполнять много ролей, позволяя менеджеру проекта лучше использовать имеющийся персонал, и одновременно убивает вредные передачи.
• Члены команды учатся на ходу. Участники проекта на протяжении цикла разработки получают возможность учиться на своих ошибках от одной итерации к другой. В результате изучения более ранних итераций можно получить больше возможностей для обучения. При использовании каскадного подхода у вас есть только одна попытка для проектирования, кодирования и тестирования.
• Улучшается процесс разработки сам по себе и становится по ходу работы более совершенным. Оценка в конце итерации позволяет не только изучить состояние проекта с точки зрения продукта или графика, но также проанализировать, что можно улучшить в организации и технологии в следующей итерации. 

Структура процессов в RUP

На рис.2 показана общая архитектура  Rational Unified Process. У процесса есть два аспекта, или, если угодно, два измерения:

Динамическое измерение

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

• начальная стадия (inception)
• стадия разработки (elaboration)
• стадия конструирования (construction)
• стадия ввода в действие (transition)

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и принимаются критически важные решения о дальнейшей разработке.

Первыми двумя стадиями являются начальная стадия проекта и разработка. Начальная стадия может принимать множество разных форм. Для крупных проектов  начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии  вырабатывается бизнес-план проекта - определяется, сколько приблизительно он будет стоить и какой доход принесет. Определяются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта. В результате начальной стадии получается:

• общее описание системы: основные требования к проекту, его характеристики и ограничения
• начальная модель вариантов использования (степень готовности 10-20%)
• начальный проектный глоссарий (словарь терминов)
• начальный бизнес-план
• план проекта, отражающий стадии и итерации
• один или несколько прототипов

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

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

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

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

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

Помимо конструирования, итерации могут присутствовать во всех стадиях, однако конструирование - это ключевая стадия. Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Как минимум, он содержит:

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

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

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

На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсолютно необходимой). Здесь только вылавливаются ошибки. Хорошим примером для стадии ввода в действие может служить период времени между выпуском бета-версии и окончательной версии продукта.

Статическое измерение

Статический аспект RUP представлен четырьмя основными элементами:

• роли
• виды деятельности
• рабочие продукты
• дисциплины

Понятие «роль» (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.

Под видом деятельности конкретного исполнителя понимается единица выполняемой им работы. Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах получения или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план. Каждый вид деятельности связан с конкретной ролью. Продолжительность вида деятельности составляет от нескольких часов до нескольких дней, он обычно выполняется одним исполнителем и порождает только один или весьма небольшое количество рабочих продуктов. Любой вид деятельности должен являться элементом процесса планирования. Примерами видов деятельности могут быть планирование итерации, определение вариантов использования и действующих лиц, выполнение теста на производительность. Каждый вид деятельности сопровождается набором руководств (guidelines), представляющих собой методики выполнения технологических операций.

Дисциплина (discipline) соответствует понятию технологического процесса и представляет собой последовательность действий, приводящую к получения значимого результата. В рамках RUP определены шесть основных дисциплин:

• построение бизнес - моделей
• определение требований
• анализ и проектирование
• реализация
• тестирование
• развертывание

и три вспомогательных:

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

Теперь, когда мы рассмотрели основу структуры Rational Unified Process, можно перейти к непосредственной разработке в RUP. Значительная часть RUP связана с разработкой и эксплуатацией моделей разрабатываемой системы. Модели помогают понимать и очерчивать как проблему, так и ее решение. Модель - это упрощение действительности, помогающее охватить большую, сложную систему, не поддающуюся пониманию во все своей полноте.

Унифицированный язык моделирования UML (Unified Modeling Language) - это графический язык визуализации спецификации и документирования артефактов преимущественно программной системы. Язык UML представляет собой стандартное средство создания чертежной системы, а также конкретные понятия, такие как классы, написанные на определенных языках программирования, схемы баз данных и программные компоненты с возможностью повторного использования.

UML - это стандартный язык изображения различных моделей; он не может подсказать, как разрабатывать программное обеспечение. Этот язык предоставляет словарь, но не объясняет, как написать книгу. Поэтому наряду с языком UML корпорация IBM Rational Software разработала взаимодополняющий продукт - Rational Unified Process. RUP  -  это консультант по вопросам эффективного использования языка UML в моделировании. Он рассказывает, какие модели необходимы, почему они необходимы и как их создавать.

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