Унифицированный процесс Rational (RUP)
Унифицированный процесс Rational — это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation, которую в 2003 году купила IBM.
Невероятный успех предложенного в рамках RUP подхода помог многим компаниям понять, насколько важно иметь чётко прописанный и задокументированный процесс разработки.
Методология RUP предназначена для крупных проектов разработки, поэтому многие менеджеры уверены, что она не подойдёт для небольших задач, не требующих большого объёма ресурсов. Но есть множество примеров, когда небольшие проекты значительно выигрывали от внедрения RUP.
К примеру, RUP используется в системе управления онлайн-обучением TAP University. Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.
Хотя это был небольшой проект, внедрение методологии RUP показало отличные результаты. Она помогла выстроить набор принципов, необходимых для организации сценариев использования сервисов TAP University, помогла увидеть направления для перехода к третьей, самой важной фазе RUP — построению.
Что такое унифицированный процесс Rational (RUP)?
Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.
RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.
RUP ориентирован на создание и поддержание моделей – вместо написания большого количества бумажной документации при использовании RUP методологии создаются модели – семантические представления разрабатываемого командой программного обеспечения.
RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.
RUP – это конфигурируемый процесс, он подходит как небольшим группам разработчиков, так и крупным организациям.
Шесть основополагающих принципов RUP
В основе RUP лежит шесть главных принципов:
- Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
- Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений (как в процессе разработки, так и при ведении бизнеса);
- Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
- Визуальное моделирование ПО – RUP методология разработки показывает, как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
- Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
- Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.
Структура RUP
Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:
Работники – «Кто»
Элемент «работник» определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов (артефактов). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.
Действия – «Как»
Действие — это единица работы, которую может выполнить работник. У каждого действия есть чётко обозначенная цель. Каждое действие назначено определённому работнику. Действия могут включать в себя создание или обновление артефактов, таких как модель, класс или план.
Артефакты (искусственные объекты) – «Что»
В методологии RUP объекты или информация, производимая и изменяемая в процессе работы над финальным результатом. Артефакты служат как вводными данными для действий работников, так и результатами этих действий.
Рабочий процесс – «Когда»
Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:
Жизненный цикл RUP
Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.
- Фаза начала проекта
В этой фазе команда определяет структуру и основную идею проекта. Команда решает, стоит ли вообще заниматься этим проектом, исходя из его предполагаемой стоимости, необходимых ресурсов и цели, которую нужно достичь.
- Уточнение
Цель этой фазы — анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения (разработке и написанию кода) или нет.
- Построение
В этой фазе RUP методологии команда начинает разработку всех компонентов и функций программного обеспечения, интегрирует их в конечный продукт. Это производственный процесс, в рамках которого команда сосредоточена на управлении ресурсами, чтобы оптимизировать расходы, время и качество продукта.
- Внедрение
Фаза, когда продукт готов и доставлен покупателям. Но после того как пользователи получают продукт, могут возникнуть новые трудности. Команде нужно будет исправить ошибки, отловить баги и доделать функции, которые не были реализованы в первично установленный срок.
В конце каждой фазы существует отметка завершения этапа (Project Milestone) — момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы:
Преимущества RUP
- Методология RUP позволяет справляться с изменениями в требованиях, независимо от того, исходят они от клиента или возникают в ходе работы над проектом;
- RUP подчёркивает необходимость точной документации.
- Интеграция требований происходит на протяжении всего процесса разработки, и в частности в фазе построения.
Недостатки RUP
- RUP опирается на способность экспертов и профессионалов назначить действия определённым работникам, которые затем обязаны выдать запланированные результаты в виде артефактов.
- Интеграция в процесс разработки может негативно сказаться на другой более фундаментальной деятельности на этапах тестирования.
Хотя RUP методология разработки показывает отличные результаты, особенно в сфере создания ПО, это довольно сложный метод, который трудно внедрить в свой проект, особенно если у вас небольшая команда или компания.