Жизненный цикл системы rup

Этапы и вехи проекта

С точки зрения управления проектом жизненный цикл программного обеспечения в Rational Unified Process (RUP) состоит из четырех последовательных этапов, в конце каждого из которых находится большая веха. Таким образом, каждый этап представляет собой промежуток времени между двумя большими вехами. В конце каждого этапа выполняется проверка того, были ли достигнуты цели, которые были поставлены для данного этапа. Если будет получен положительный ответ, начинается выполнение следующего этапа проекта.

Планирование этапов

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

графически это выглядит следующим образом:

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

Планирование стратегий

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

Шаблон жизненного цикла: инкрементальный

“Инкрементальная стратегия заключается в выявлении потребностей пользователей, формулировке требований к системе и разработке программного продукта в несколько циклов компоновки. Первый цикл компоновки охватывает часть функций конечной системы, следующий – еще часть функций, и так далее вплоть до построения полной системы”. [DOD94]

Характерны следующие итерации:

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

Эта стратегия применяется в следующих случаях:

• Предметная область знакома.
• Риски хорошо известны.
• Над проектом работает опытный коллектив.

Шаблон жизненного цикла: эволюционный

“Эволюционная стратегия отличается от стратегии дополнения предположением о том, что потребности пользователей понимаются не в полном объеме, поэтому невозможно заранее предусмотреть все требования, и поэтому требования уточняются в каждом цикле компоновки”. [DOD94]

Характерны следующие итерации:

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

Эта стратегия применяется в следующих случаях:

• Предметная область незнакома или нова.
• Разработку ведет неопытный коллектив.

Шаблон жизненного цикла: Дополняющее внедрение

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

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

Характерны следующие итерации:

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

Эта стратегия применяется в следующих случаях:

• Предметная область знакома:

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

Шаблон жизненного цикла: “полномасштабная разработка”

Традиционный водопадный метод можно рассматривать в качестве упрощенной модели с одной итерацией на этапе построения. Этот метод называется “полномасштабной разработкой” (“grand de”) в книге [DOD94]. На практике избежать дополнительных итераций на этапе внедрения довольно непросто.

Характерны следующие итерации:

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

Эта стратегия применяется в следующих случаях:

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

Шаблон жизненного цикла: Гибридная стратегия

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

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

Переход к следующему циклу

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

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

Источник

Унифицированный процесс Rational – это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation, которую в 2003 году купила IBM.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.

1. Фаза начала проекта

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

3. Уточнение

Цель этой фазы – анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения (разработке и написанию кода) или нет.

3. Построение

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

4. Внедрение

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

В конце каждой фазы существует отметка завершения этапа (Project Milestone) – момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы:

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

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

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

Источник