Что Такое RUP и Зачем он Нужен в Вашем Проекте

RUP (Rational Unified Process) - это software development process framework (т.е. шаблон процесса разработки программ). Он был разработан Rational Software Corporation, которую в последствии купил IBM. Хотя сам по себе RUP несколько устарел, — это стандартная и понятная всем основа для организации вашего конкретного проекта. Хотя сегодня существует множество других frameworks (CMMI, ITIL и так далее, включая отраслевые ASPICE, eTom), RUP – это необходимый минимум и структура понятная всем в индустрии. Т.е. пакет документов RUP, особенно из Interception phase (см ниже) позволяет описать ваш продукт/сервис на понятном всем языке и сильно упростить взаимодействие с другими людьми. Шаблоны артефактов RUP на любом языке есть в инете.

1. RUP построен вокруг четырех основных ступеней (phases), у каждой из которых своя цель:

  • Inception – определить назначение (business case) проекта, его объем (scope) и основные архитектурные характеристики.
  • Elaboration - уточнить требования к проекту, оценить проектные риски и создать подробную архитектуру.
  • Сonstruction - собственно создание программного продукта, с использованием вашей любимой методологии.
  • Transition – запуск готового продукта, его дальнейшая поддержка и корректировка в соответствии с обратной связью от пользователей.

2. RUP определяете основные понятия:

  • Роль – кто делает и что делает (e.g., analyst, designer, tester).
  • Активность - что нужно сделать, чтобы достичь определенной цели (e.g., use case modeling, coding, testing). Набор активностей с ролями образуют процесс.
  • Артефакт – сущность (work product), которая должна образоваться в результате выполнения процесса.

3. RUP определяет шесть базовых практик:

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

4. Основные артефакты RUP

Для ступени Inception:

  • Vision Document – описывает высокоуровневые требования к системе, ключевые свойства и бизнес-задачи системы, и ее ограничения.
  • Business Case – описывает бизнес-потребности, которые закрывает проект, планируемые источники дохода и основные бизнес риски.
  • Initial Use Case Model - высокоуровневое описание способов использования продукта (Use Cases)
  • Project Plan – высокоуровневый план проекта, описывающий основные вехи, требуемые ресурсы и возникающие ограничения.
  • Risk List – список рисков с оценками их стоимости и вариантов работы с ними.
  • Stakeholder Request List – список всех интересантов (stakeholders) проекта, их ожиданий и требований.

Для ступени Elaboration:

  • Software Architecture Document (SAD) – архитектура проекта, включая выделение требований влияющих на архитектуру (ASR) и обоснование архитектурных решений.
  • Use Case Model – детальные сценарии использования продукта (Use Cases), включающие взаимодействие между разными участниками (actors) системы
  • Supplementary Specifications – описание нефункциональных требований и ограничений, включая регуляции.
  • Iteration Plan – план итеративной разработки, цели и артефакты каждой итерации.
  • Glossary, Roles and Responsibilities – основные термины проекта, роли проекта и их зона ответственности.

Для ступени Construction:

  • Design Model: Provides detailed design specifications, including class diagrams, sequence diagrams, and other design artifacts.
  • Implementation Model: Includes source code, component descriptions, and build instructions.
  • Test Plan: Outlines the approach for testing the system, including test cases, test scripts, and acceptance criteria.
  • Deployment Model: Describes the deployment architecture, including the environments, infrastructure, and deployment procedures.

Для ступени Transition:

  • User Manual – руководство пользователя.
  • Installation Guide - руководство по установке, настройке окружения и дальнейшему администрированию.
  • Release Notes - список основных особенностей конкретного релиза, включая список известных проблем с ассоциированными рисками.
  • Training Materials: материалы для обучения пользователей, системных администраторов и продавцов.
  • Support Documentation – правила и контакты технической поддержки.

Для всех ступенек (лучше это сделать в начале работы):

  • Change Request - описание формата запросов на изменение и порядка работы с ними.
  • Status Assessment – формат регулярного отчета о состоянии проекта и возникающих проблемах.
  • Configuration Management Plan – описание работы с артефактами проекта, кто будет из подписывать, как они будут версионироваться, архивироваться и так далее.