В основе Методологии лежит концепция, определяющая механизмы, правила и терминологию RUP. Для определения уникального процесса разработки ПО, RUP включает «конструктор», представленный библиотекой элементов.
Унифицированная системная архитектура: концепция RUP
В основе RUP лежит Унифицированная системная архитектура (Unified Method Architecture, UMA), метамодель, определяющая терминологию и механизмы для организации процессов и их компонентов. Текущая версия UMA является эволюцией метамодели RUP 2003 и разрабатывалась с учетом других ведущих стандартов в этой области и при участии многих заинтересованных лиц. По сравнению с RUP 2003, была несколько изменена терминология в пользу общепринятой, также изменениям подверглась сама структура элементов RUP.
Основная идея метамодели заключается в создании гибкого механизма для сборки процесса разработки под конкретный проект. Метамодель позволяет включать в процесс разработки различные модели жизненных циклов, например, модель водопада, итеративный и инкрементный подходы. UMA разделяет содержание процесса разработки от применения этого содержания.
Рисунок 5 — UMA: разделение содержания процесса разработки (окружность слева) от применения этого содержания (окружность справа)
Метамодель также не привязана к каким-либо средствам разработки (Tools) для реализации входящих в ее состав задач, однако может быть адаптирована для их применения.
Процесс: план, приводящий к готовому программному продукту
Процесс (process) представляет собой совокупность работ, состоящих из отдельных шагов, выполнение которых закреплено за ролями и в ходе выполнения которых результаты работ используются в качестве входных и выходных параметров.
В Методологии можно сразу использовать один из готовых процессов. Однако этот путь далеко не всегда правильный — двух абсолютно одинаковых проектов не существует, следовательно, универсального плана для реализации различных проектов тоже нет. Гораздо эффективнее сначала адаптировать один из готовых процессов.
Адаптация процесса представляет собой «сшивание»: выбираются только те элементы конструктора, которые нужны и выстраиваются в нужном порядке. Из доступного перечня работ определяют перечень, который необходимо выполнять в проекте, определяют результаты этих работ, также из доступного перечня. За работами закрепляют роли (например, тестировщик, системный аналитик). Работы, роли, результаты работ называют элементами наполнения (Method Content). Когда работы организуют в некоторые последовательности, они образуют деятельности, шаблоны и готовые процессы — элементы процесса (Process elements).
Общее представление элементов RUP и их группировка приведены на рисунке 6.
Рисунок 6 — Общее представление элементов RUP и их группировка
Элементы наполнения: детали конструктора
Элементы наполнения выполняют функцию, аналогичную деталям конструктора — они являются «исходным материалом» сборки процесса разработки. На этапе «сшивания» процесса определяют, какие элементы наполнения нужно использовать, а какие нет.
Основными элементами наполнения являются:
× Роли (Roles). RUP представляет собой набор деятельностей, закрепленных за ролями, их выполняющими. Подразумевается, что каждый участник проекта разработке берет на себя одну или более ролей, выполняя работы, включенные в конкретную сборку методологии;
× Результаты работ (Work Products). Термин содержит все виды результатов работ, создаваемых в процессе разработки: артефакты (Artifact), формальные документы (Deliverable), неформальные результаты работ (Outcome);
× Работы (Tasks). Работа — недлительная деятельность, закрепленная за ролью (или несколькими ролями), которая обеспечивает значимый результат.
Элементы процесса: что к чему крепить?
Структура работ, выполнение которых приводит к разработке системы, формирует процесс разработки (Development Process). Эта структура работ (как тип Work Breakdown Structure) составляется из элементов наполнения RUP — работ, ролей и результатов работ, организуется в условные последовательности и образует жизненный цикл конкретного проекта. Работы могут быть сгруппированы в Деятельности (Activities), назначением которых является достижение определенного результата вне зависимости от их фактического расположения в жизненном цикле проекта (например, разработка видения).
Особыми типами деятельностей являются фазы, итерации, целевые шаблоны (capability patterns) и готовые процессы разработки (delivery processes). Целевые шаблоны включают набор деятельностей, обеспечивающие определенный результат, часто, но не обязательно, в одной из дисциплин. Хорошей практикой является сборка целевых шаблонов, обеспечивающих выпуск определенных формальных документов. Примерами целевых шаблонов являются Управление требованиями на основе прецедентов, Анализ прецедентов или Модульное тестирование. Готовые процессы, в отличие от целевых шаблонов, покрывают жизненный цикл всего проекта.
Такая многоуровневая классификация нацелена на повышение повторного использования элементов и обеспечивает быструю сборку процесса разработки под проект.
Руководства: ресурс для специалиста
В помощь команде разработчиков в библиотеку RUP включены Руководства (Guidance) по элементам RUP, дающие рекомендации и пояснения по различным работам, результатам работ, ролям. Руководством может быть Контрольный список (Checklist), Теоретическая основа (Concept), Пример (Example), Указание (Guideline), Практика (Practice), Отчет (Report), Ресурс (Reusable Asset), Путеводитель (Roadmap), Справочный материал (Supporting Material), Шаблон (Template), Определение (Term Definition), Памятка по средствам разработки (Tool Mentor) , Описание (White Paper).
Группировка элементов: способ разобраться во множестве терминов
Во всем многообразии элементов RUP разобраться достаточно сложно. Однако, сгруппировав элементы, сразу становится ясно, что к чему относится. Группировка успешно применяется в спецификации Методологии, где она представлена в виде дерева для удобства навигации:
Рисунок 7 — Группировка элементов RUP, представленная в виде дерева
Для группировки элементов RUP применяют следующую классификацию:
× Дисциплина (Discipline) включает связанные по своему назначению элементы наполнения, то есть относящиеся к какой-либо области знаний или интересов и способствующие достижению общей цели дисциплины;
× Группа ролей (Role set) объединяет роли по виду основной деятельности и обладающие общими навыками: Аналитики (Analysts), Разработчики (Developers), Менеджеры (Managers), Тестировщики (Testers), Поддерживающие роли (Production & Support), Роли общего значения (General Roles);
× Домен (Domain) и Тип результата (Work Product Kind) группируют результаты работ по их принадлежности к предметной области (категории аналогичны дисциплинам) и их представлению-типу (Оценка (Assessment), Концепция (Concept), Модель инфраструктуры (Infrastructure), Модель (Model), Элемент модели (Model Element), План (Plan), Процесс (Process), Информация о проекте (Project Data), Решение (Solution), Описание (Specification)) соответственно;
× Представление (View) и Пользовательская классификация (Custom Category) позволяют определять настраиваемые представления по любому признаку.
Элементы RUP включаются в пакеты, пакеты составляют библиотеку элементов. Метамодель RUP обеспечивает гибкость инфраструктуры RUP, определяя ее как конструктор, представленный библиотекой элементов (Method Library), включающей элементы наполнения (Method Content Package) и элементы процессов (Process Content Package). Библиотека элементов может быть изменена Расширением библиотеки (Method Plugin).
На основе библиотеки элементов и ее расширений создаются выборки —конфигурации (Method Configuration), которые, в конечном счете, и являются отправной точкой для сборки уникальных процессов для разработки ПО.
Структура элементов RUP приведена на рисунке 8.
Рисунок 8 — Структура элементов RUP
Возможность многократного применения элементов библиотеки обеспечивается различными конфигурациями, это позволяет сопровождать целую группу связанных процессов (для схожих проектов). Механизм подключения плагинов, поддерживаемый расширениями библиотек, позволяет изменять элементы, не затрагивая оригинального содержания, описывая только различия.
Переопределение элементов: простота изменений
Механизм плагинов позволяет изменять элементы библиотеки RUP, не затрагивая оригинального содержания, описывая только различия. В методологии RUP выделяются четыре типа расширений элементов:
× Дополнение к процессу (Process Contribution). Это особый вид процесса, в котором определены измененные и добавленные функции существующего процесса. Дополнения позволяют модифицировать процессы, не изменяя их физически;
× Дескриптор (Descriptor). Дескриптор является отражением существующего элемента RUP и описывает использование и применение этого элемента в конкретном случае. Другими словами, является «надстройкой» какого-либо элемента наполнения RUP — роли, работы или результата работы. На рисунке 9 приведен пример реализации дескрипторов для элементов деятельности Prioritize Use Cases — эта деятельность выполняется по-разному на стадиях Inception и Elaboration;
× Составная роль (Composite Role). Составная роль инкапсулирует функции, работы и ответственность двух или более элементарных ролей RUP. Основное назначение составной роли — сокращение числа ролей, например, в небольшом проекте;
× Профиль распределения ответственности (Team Profile). Это особый вид структуры WBS, отражающий распределение ответственности за выполнение работ между выделенными ролями.
Рисунок 9 — Пример реализации дескрипторов
Скачать PDF-версию с оригинальным оформлением. © Для использования опубликованных на ресурсе материалов достаточно упоминания имени автора и адреса первоисточника. Дата обновления: 2008-10-21.
Комментариев нет:
Отправить комментарий