Рациональный унифицированный процесс - Rational Unified Process

В рациональный унифицированный процесс (RUP) является итеративный процесс разработки программного обеспечения рамки, созданные Рациональное программное обеспечение Корпорация, подразделение IBM с 2003 года.^[1] RUP - это не отдельный конкретный предписывающий процесс, а скорее адаптируемый процесс. рамки, предназначенные для адаптации организациями-разработчиками и группами разработчиков программного обеспечения, которые выберут элементы процесса, соответствующие их потребностям. RUP - это конкретная реализация Единый процесс.

История

Rational Software изначально разработала рациональный унифицированный процесс как программный продукт. Продукт включает гиперссылку базы знаний с образцом артефакты и подробные описания для множества различных видов деятельности. RUP включен в IBM Rational Method Composer (RMC) продукт, который позволяет настраивать процесс.

Филипп Крюхтен опытному техническому представителю Rational было поручено возглавить первоначальную команду RUP. Это путешествие началось с создания Rational Objectory Process (ROP) в 1996 году, когда Rational приобрела Objectory Process, который был написан Ивар Якобсон и компания. В последующих выпусках он был переименован в Rational Unified Process (RUP), отчасти для того, чтобы согласовать название с названием Unified Modeling Language.

Эти начальные версии объединили обширный практический опыт организации Rational Software в создании объектно-ориентированных систем (называемых полевыми сотрудниками Rational как Rational Approach) с руководством Objectory по таким практикам, как варианты использования, и включили обширный контент из книги Джима Рамбо. Технология объектного моделирования (OMT) подход к моделированию, Grady Booch's Метод Буча, и недавно выпущенный UML 0.8.^[2]^[3]

Чтобы сделать эту растущую базу знаний более доступной, Филипп Крюхтен была поставлена задача собрать явную структуру процесса для современной программной инженерии. В этих усилиях использовались HTML механизм доставки процессов, разработанный Objectory. Получившийся в результате «Rational Unified Process» (RUP) стал стратегической треногой для Rational:

а адаптируемый процесс это направляло развитие
инструменты что автоматизировало применение этого процесса
Сервисы это ускорило внедрение как процесса, так и инструментов.

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

В 1997 году к подходу были добавлены требования и дисциплина тестирования, большая часть дополнительных материалов была получена из метода Requirements College, разработанного Дином Леффингвеллом и др. в Requisite, Inc., и метод SQA Process, разработанный в SQA Inc., обе компании были приобретены Rational Software.

В 1998 году Rational Software добавила две новые дисциплины:

бизнес-моделирование, большая часть этого контента уже была в Objectory Process
дисциплина управления конфигурациями и изменениями, полученная в результате приобретения Pure Atria Corporation.

Эти дополнения приводят к всеобъемлющему набору принципов, которые были определены Rational и сформулированы в RUP как шесть лучшие практики для современной программной инженерии:

Итеративная разработка, с риском в качестве основного драйвера итерации^[4]
Управляйте требованиями
Использовать компонентную архитектуру
Визуальное моделирование программного обеспечения
Постоянно проверять качество
Изменения в управлении

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

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

В 1999 г. была введена дисциплина управления проектами, а также методы поддержки разработки программного обеспечения в реальном времени и обновлений для отражения UML 1.3. Кроме того, первая книга, описывающая этот процесс, The Unified Software Development Process (ISBN 0-201-57169-2), вышла в том же году.

Между 2000 и 2003 годами был внесен ряд изменений, основанных на текущем полевом опыте Rational в области итеративной разработки, в дополнение к инструментальной поддержке для внедрения экземпляров RUP и настройки структуры RUP. Эти изменения включали:

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

IBM приобрела Rational Software в феврале 2003 года.

В 2006 году IBM создала подмножество RUP, предназначенное для предоставления Гибкий проекты - выпущены как метод с открытым исходным кодом, называемый Открыть сквозь Затмение интернет сайт.^[5]

Темы рационального единого процесса

Строительные блоки RUP

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

Роли (кто) - роль определяет набор связанных навыков, компетенций и обязанностей.
Рабочие продукты (что) - Рабочий продукт представляет собой нечто, являющееся результатом задачи, включая все документы и модели, созданные во время работы в процессе.
Задачи (как) - задача описывает единицу работы, назначенную роли, которая обеспечивает значимый результат.

В рамках каждой итерации задачи разделены на девять дисциплин:

Шесть «инженерных дисциплин»
- Бизнес-моделирование
- Требования
- Анализ и дизайн
- Выполнение
- Тест
- Развертывание
Три вспомогательных дисциплины

Четыре фазы жизненного цикла проекта

Фазы и дисциплины RUP.

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

Начальная фаза

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

Акционер согласование определения объема работ и оценки стоимости / графика.
Понимание требований, подтвержденное верностью основных вариантов использования.
Достоверность оценок затрат / графика, приоритетов, рисков и процесса разработки.
Глубина и широта любого разработанного архитектурного прототипа.
Установление базового уровня для сравнения фактических расходов с запланированными.

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

Фаза проработки

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

Результатом этапа разработки является:

Модель вариантов использования, в которой были определены варианты использования и субъекты, а также разработано большинство описаний вариантов использования. Модель варианта использования должна быть завершена на 80%.
Описание архитектуры программного обеспечения в процессе разработки программной системы.
An исполняемая архитектура который реализует архитектурно значимые варианты использования.
Пересмотренное экономическое обоснование и список рисков.
План развития всего проекта.
Прототипы, которые наглядно снижают каждый выявленный технический риск.
Предварительное руководство пользователя (необязательно)

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

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

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

Ключевым предметным анализом для разработки является архитектура системы.

Этап строительства

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

Переходный этап

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

Если все цели достигнуты, этап выпуска продукта достигнут и цикл разработки завершен.

Продукт IBM Rational Method Composer

Продукт IBM Rational Method Composer - это инструмент для создания, настройки, просмотра и публикации процессов. Видеть IBM Rational Method Composer и версия с открытым исходным кодом Структура процессов Eclipse (EPF) для более подробной информации.

Сертификация

В январе 2007 г. новый сертификационный экзамен RUP для Сертифицированный дизайнер решений IBM - Rational Unified Process 7.0 был выпущен на замену предыдущей версии курса под названием Сертифицированный специалист IBM Rational - Rational Unified Process.^[6] Новый экзамен будет проверять не только знания, относящиеся к содержанию RUP, но и к элементам структуры процесса.^[7]

Чтобы сдать новый сертификационный экзамен RUP, человек должен сдать экзамен IBM Тест 839: Rational Unified Process v7.0. На экзамен из 52 вопросов дается 75 минут. Проходной балл 62%.^[8]

Шесть лучших практик

Шесть лучших программная инженерия Для программных проектов определены методы, позволяющие свести к минимуму ошибки и повысить производительность. Это:^[9]^[10]

Развивайте итеративно: Все требования лучше всего знать заранее; однако часто это не так. Существует несколько процессов разработки программного обеспечения, которые связаны с предоставлением решений для минимизации затрат на этапах разработки.
Управляйте требованиями: Всегда помните о требованиях, установленных пользователями.
Используйте компоненты: Разрушение продвинутого проекта не только предлагается, но и неизбежно. Это дает возможность тестировать отдельные компоненты, прежде чем они будут интегрированы в более крупную систему. Кроме того, повторное использование кода является большим плюсом, и его легче достичь с помощью объектно-ориентированного программирования.
Модель визуально: Используйте диаграммы для представления всех основных компонентов, пользователей и их взаимодействия. "UML", сокращение от Единый язык моделирования, это один из инструментов, который можно использовать, чтобы сделать эту задачу более выполнимой.
Проверить качество: Всегда делайте тестирование основной частью проекта в любое время. По мере продвижения проекта тестирование становится более сложным, но оно должно быть постоянным фактором при создании любого программного продукта.
Изменения в управлении: Многие проекты создаются многими командами, иногда в разных местах, могут использоваться разные платформы и т. Д. В результате важно обеспечить постоянную синхронизацию и проверку изменений, вносимых в систему. (Видеть Непрерывная интеграция ).

Смотрите также

дальнейшее чтение

Ивар Якобсон, Грейди Буч, и Джеймс Рамбо (1999). Единый процесс разработки программного обеспечения
Гэри Поллис, Лиз Августин, Крис Лоу и Джас Мадхур (2003). Разработка программного обеспечения для небольших команд: подход, ориентированный на RUP
Пер Кролл, Филипп Крюхтен (2003). Rational Unified Process Made Easy, The: Практическое руководство по RUP
Пер Кролл, Брюс Мак Айзек (2006). Гибкость и дисциплина стали проще: практики OpenUP и RUP
Филипп Крухтен (1998). Рациональный унифицированный процесс: введение
Ахмад Шуджа, Йохен Кребс (2007). Справочное руководство и руководство по сертификации RUP
Уокер Ройс, Управление программными проектами, унифицированная структура

внешняя ссылка

Веб-сайт IBM Rational Unified Process

[1] IBM приобретает Rational

[rop-overview-2] Якобсон, Стен (19 июля 2002 г.). «Процесс Rational Objectory - процесс разработки программного обеспечения на основе UML». Rational Software Scandinavia AB. Получено 2014-12-17.

[rup-introduction-history-3] Крухтен, Филипп (2004-05-01). Рациональный унифицированный процесс: введение. Эддисон-Уэсли. п. 33. ISBN 9780321197702. Получено 2014-12-17.

[rup-in-brief-4] Акед, Марк (25 ноября 2003). «Коротко о RUP». IBM. Получено 2011-07-12.

[5] ttp://epf.eclipse.org/wikis/openup/

[rupcert-6] Кребс, Йохен (15 января 2007 г.). «Ценность сертификации RUP». IBM. Получено 2014-05-05.

[rup7-7] "Spacer Сертифицированный дизайнер решений IBM - IBM Rational Unified Process V7.0". IBM. Получено 2008-05-13.

[test389-8] «Тест 839: Rational Unified Process v7.0». IBM. Получено 2008-05-13.

[9] Стивен Шах (2004). Классическая и объектно-ориентированная разработка программного обеспечения. 6 / e, WCB McGraw Hill, Нью-Йорк, 2004.

[10] Официальный документ Rational Unified Process В архиве 2009-05-01 на Wayback Machine

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]