Skip to content
Ilya edited this page Dec 5, 2021 · 34 revisions

Методология RUP (Rational Unified Process). Основные части описания прецедентов (Use Case) и их изображение на диаграммах прецедентов

Выполнил: Крупенко Илья, ИДБ-18-08

Проверил: Козарезов Денис, ИДБ-18-08

Что такое унифицированный процесс Rational (RUP)?

Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.

RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.

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

RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.

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

Шесть основополагающих принципов RUP

В основе RUP лежит шесть главных принципов:

  1. Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
  2. Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений (как в процессе разработки, так и при ведении бизнеса);
  3. Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
  4. Визуальное моделирование ПО – RUP методология разработки показывает, как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
  5. Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
  6. Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.

Структура RUP

Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:

Работники – «Кто»

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

Действия – «Как»

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

Артефакты (искусственные объекты) – «Что»

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

Рабочий процесс – «Когда»

Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:

Clone this wiki locally