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

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

История [ править ]

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

Филиппу Крухтену , опытному техническому представителю Rational, было поручено возглавить первоначальную команду RUP.

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

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

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

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

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

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

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

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

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

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

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

В 1999 году была введена дисциплина управления проектами, а также методы поддержки разработки программного обеспечения в реальном времени и обновлений для отражения UML 1.3. Кроме того, первая книга, описывающая этот процесс, «Унифицированный процесс разработки программного обеспечения» ( англ. 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, предназначенное для реализации проектов Agile , выпущенное как метод OpenSource под названием OpenUP через Eclipse . веб-сайт ^[5]

Темы Rational Unified Process [ править ]

Строительные блоки RUP [ править ]

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

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

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

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

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

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

Начальный этап [ править ]

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

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

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

Этап разработки [ править ]

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

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

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

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

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

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

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

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

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

Переходный этап [ править ]

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

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

Продукт IBM Rational Method Composer [ править ]

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

Сертификация [ править ]

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

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

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

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

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

См. также [ править ]

Ссылки [ править ]

^ IBM приобретает Rational
^ Джейкобсон, Стен (19 июля 2002 г.). «Процесс Rational Objectory — процесс разработки программного обеспечения на основе UML» . Рациональное программное обеспечение Скандинавия AB . Архивировано из оригинала 27 мая 2019 г. Проверено 17 декабря 2014 г.
^ Крухтен, Филипп (1 мая 2004 г.). Rational Unified Process: Введение . Аддисон-Уэсли . п. 33. ISBN 9780321197702 . Проверено 17 декабря 2014 г.
^ Акед, Марк (25 ноября 2003 г.). «Коротко о РУП» . ИБМ . Проверено 12 июля 2011 г.
^ "Открыть" . Архивировано из оригинала 6 января 2014 г. Проверено 3 августа 2013 г.
^ Кребс, Йохен (15 января 2007 г.). «Ценность сертификации RUP» . ИБМ . Проверено 5 мая 2014 г.
^ «Spacer сертифицированный IBM Solution Designer — IBM Rational Unified Process V7.0» . ИБМ . Проверено 13 мая 2008 г.
^ «Тест 839: Rational Unified Process v7.0» . ИБМ . Проверено 13 мая 2008 г. ^{[ постоянная мертвая ссылка ]}
^ Стивен Шах (2004). Классическая и объектно-ориентированная разработка программного обеспечения . 6/e, WCB McGraw Hill, Нью-Йорк, 2004 г.
↑ Технический документ Rational Unified Process. Архивировано 1 мая 2009 г. на Wayback Machine.

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

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

^ Шимковяк, Пол; Крухтен, Филипп (февраль 2003 г.). «Тестирование: философия RUP» . Академия.Образование . Программное обеспечение Rational (электронный журнал Rational Edge). п. 11 . Проверено 13 октября 2022 г.

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

[rop-overview-2] Джейкобсон, Стен (19 июля 2002 г.). «Процесс Rational Objectory — процесс разработки программного обеспечения на основе UML» . Рациональное программное обеспечение Скандинавия AB . Архивировано из оригинала 27 мая 2019 г. Проверено 17 декабря 2014 г.

[rup-introduction-history-3] Крухтен, Филипп (1 мая 2004 г.). Rational Unified Process: Введение . Аддисон-Уэсли . п. 33. ISBN 9780321197702 . Проверено 17 декабря 2014 г.

[rup-in-brief-4] Акед, Марк (25 ноября 2003 г.). «Коротко о РУП» . ИБМ . Проверено 12 июля 2011 г.

[5] "Открыть" . Архивировано из оригинала 6 января 2014 г. Проверено 3 августа 2013 г.

[rupcert-6] Кребс, Йохен (15 января 2007 г.). «Ценность сертификации RUP» . ИБМ . Проверено 5 мая 2014 г.

[rup7-7] «Spacer сертифицированный IBM Solution Designer — IBM Rational Unified Process V7.0» . ИБМ . Проверено 13 мая 2008 г.

[test389-8] «Тест 839: Rational Unified Process v7.0» . ИБМ . Проверено 13 мая 2008 г. ^{[ постоянная мертвая ссылка ]}

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

[10] Технический документ Rational Unified Process. Архивировано 1 мая 2009 г. на Wayback Machine.

[test-11] Шимковяк, Пол; Крухтен, Филипп (февраль 2003 г.). «Тестирование: философия RUP» . Академия.Образование . Программное обеспечение Rational (электронный журнал Rational Edge). п. 11 . Проверено 13 октября 2022 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[1]