Posted:
3 weeks, 4 days ago
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 – описание работы с артефактами проекта, кто будет из подписывать, как они будут версионироваться, архивироваться и так далее.