Rational Unified Process (RUP) как методология разработки программного обеспечения кратко

Привет, Вы узнаете о том , что такое rational unified process, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое rational unified process, rup , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

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

RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

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

Для успешного процесса разработки необходимы три составляющие (рис. 1): процесс (process), нотация (notation) и набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом; нотация является средством общения; набор утилит помогает автоматизировать процесс и управлять им.

Рис. 1. Треугольник успеха

В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые производят следующие действия:

осуществляет «склеивание» процесса в единое целое;

является языковым средством принятия решений, которые не очевидны из исходного кода;

предоставляет семантику для отображения важных стратегических и тактических решений;

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

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

Принципы

В основе RUP лежат следующие принципы:

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

Процессы и стадии RUP

RUP использует итеративную модель разработки. Об этом говорит сайт https://intellect.icu . В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Первые идеи итеративной модели разработки были заложены в "спиральной модели"

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

Графическое представление процесса разработки по RUP

1. Начальная стадия (Inception)

В фазе начальной стадии:

• Формируются видение и границы проекта.
• Создается экономическое обоснование (business case).
• Определяются основные требования, ограничения и ключевая функциональность продукта.
• Создается базовая версия модели прецедентов.
• Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

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

Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

Артефакты и роли RUP

Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов — начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор артефактов (моделей, документов и т.п.) для каждого из потоков.

Business modeling

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, Microsoft Project:

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

• Requirements

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

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

Analysis and design

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• архитектура программного обеспечения;
• спецификации программных компонентов;
• рекомендации на этапе анализа и проектирования;
• план работ на этапе анализа и проектирования;
• запросы на изменение.

Implementation

Артефакты-модели — используется Rational Rose:

• компонентная модель приложения.

Артефакты-код — используются Rational Rose, средства программирования, текстовые процессоры:

• элементы генерации кода, полученные в Rational Rose;
• собственно код приложения;
• документация.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• план сборки приложения;
• план работ на этапе реализации.

Test

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• описание тестовых примеров;
• план тестирования;
• план работ на этапе тестирования;
• запросы на изменение.

Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Артефакты-модели — используется Rational Rose:

• модель размещения — описание размещения компонентов по узлам обработки.

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• обучающие материалы;
• документы по инсталляции;
• описание версий системы;
• план внедрения.

Вау!! 😲 Ты еще не читал? Это зря!

• Бизнес - моделирование
• OpenUP
• Спиральная модель
• виды методологий , разработка программного обеспечения , цикл разработки , жизненный цикл программы ,
• техническое задание , спецификация задания , бриф , тз ,
• SRS
• UML

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