Обзор продукта
RMC является инструментом позволяющим инженерам-технологам (process engineers) создавать, изменять, развертывать и поддерживать Процессы Разработки организации и отдельных проектов.
Назначение RMC:
- Создание базы знаний процессов, которую можно просматривать, управлять и публиковать. Эта база может включать как информацию, предоставляемую IBM (RUP, RUP для небольших проектов, …) и внешними поставщиками так и из базы знаний процессов организации, включающей в себя Руководства, Шаблоны, Инструкции, Процедуры, Учебные Материалы, Чек-Листы и другие компоненты Методик организации. Эта база знаний служит основой для построения Процессов Разработки. RMC разрабатывался как система управления содержанием (content management system), предоставляющая единую структуру управления и отображения всей базы знаний процессов организации. Все содержание баз знаний процессов может быть опубликовано в виде html-файлов и выложено на веб-сервера для распределенного использования.
- Предоставить возможность управления процессной методологией инженерам-технологам и менеджерам проектов посредством выбора, адаптации и быстрой сборки Процессов для конкретных проектов разработки. RMC предоставляет предопределенный набор Процессов для типичных проектных ситуаций, которые могут быть адаптированы под конкретные нужды. Он также предоставляет блоки построения процессов разработки, называемые Процессы Ключевых Областей разработки (capability patterns), которые представляют собой лучшие практики разработки для конкретных дисциплин, технологий или стилей управления проектами. Эти строительные блоки формируют инструментарий, для быстрого создания Процесса разработки основываясь на специфических нуждах проекта. RMC также позволяет настраивать специфические для организации Процессы Ключевых Областей разработки. Наконец, Процессы разработки созданные с помощью RMC могут быть опубликованы в виде веб-сайтов.
Обзор основных концепций RMC
Перечень основных отличий RMC от RUP2003 представлен во врезке Отличия в метамоделях RUP2003 и RMC
Содержание Методик и Процессов
Фундаментальным принципом RMC является разделение Содержания Методик (Method content), которое может быть повторно используемо от конкретных Процессов разработки, в которых оно используется. Содержание Методик описывает, что должно быть создано, необходимые навыки и приводит пошаговое объяснение, как достигаются конкретные цели разработки. Это описание методик не зависит от описания жизненного цикла разработки. На основе Содержания Методик создаются Процессы в виде последовательностей действий, которые адаптируются к типам конкретных проектов. На Рисунок 1 показано такое разделение для RUP. Содержание Методик сгруппировано по дисциплинам вдоль оси Y, и описывает выполнение задач по разработке (не показанных на рисунке). Работа, описанная как Процесс в течении времени представлена вдоль оси Х. Это жизненный цикл проекта разработки ПО. Он отображает, когда и какие задачи должны быть выполнены. Графики на рисунке представляют приблизительный объем работ для каждой из дисциплин. Таким образом, жизненный цикл (Процесс) отображает изменения работы выполняемой в рамках различных дисциплин (Методики).
Рисунок 1 Разделение содержания Методик и Процесса
Для создания Методик в RMC используется стандартизированный подход, упрощенное представление которого показано на Рисунок 2. В этой метамодели выделяется набор Ролей (Roles), представляющих совокупность связанных навыков, знаний и ответственностей команды разработчиков. Эти Роли ответственны за определенные типы Рабочих Продуктов (Work Product), например тестировщики за план тестирования, а менеджеры проектов за проектный план. Для создания или изменения Рабочих Продуктов Ролям присваиваются Задачи (Tasks), которые на входе и выходе имеют специфичные типы Рабочих Продуктов.
Рисунок 2 Упрощенная модель основных элементов Методики
На Рисунок 3 представлены ключевые элементы RMC с разбиением на Содержание Методик и Процесса. Из рисунка видно, что Содержание Методик в основном описывается через Рабочие Продукты, Задачи, Роли и Руководства. Руководства (Guidance), такие как Чек-Листы (check-list), Примеры (example) или Планы Действий (roadmap) могут также быть созданы для предоставления дополнительной информации о Процессе. В правой части рисунка отображены элементы RMC используемые для описания Процессов. Основным элементом являются Активности (activity), которые могут быть вложены друг в друга для представления декомпозиции Работ (Пример вложенностей Активностей: Инициализация проекта\Создание проектной среды\ Создание Outlook папок). Также могут быть определены связи Активностей между собой для определения потока работ (workflow). Активности в свою очередь содержат Дескрипторы(descriptor), которые ссылаются на Содержание Методик. Активности используются для создания Процессов, которых в RMC два типа: Процесс Разработки (delivery process) и Процесс Ключевой Области разработки(capability pattern). Процессы Разработки это полные, интегрированные процессные шаблоны для специфичных типов проектов. Они описывают жизненный цикл проекта от начало до конца и используются в качестве ссылки для текущих проектов с похожими характеристиками. Процессы Ключевых Областей разработки это Процессы определяющие процессные знания для определенных ключевых областей разработки таких как дисциплина или лучшая практика (best practice). Они также используются для сборки Процессов Разработки или более крупных Процессов Ключевых Областей разработки. Это гарантирует оптимальное повторное использование и применение лучших практик при разработке Процесса в RMC.
Рисунок 3 Ключевые элементы RMC
Дескрипторы
Ключевой концепцией разделения Методик (базы знаний процессов) и Процесса разработки является Дескриптор (Descriptor). Дескриптор является Элементом Процесса, который представляет использование элемента Содержания Методик в Процессе. Дескриптор представляет вхождение одного конкретного элемента Методик, такого как Роль, Задача или Рабочий Продукт в Активности. Дескрипторы являются прокси-подобными представлениями этих элементов внутри декомпозиции работ. Кроме установления ссылки на элементы Методик они позволяют переопределять структуру связей с другими элементами Методик путем определения собственной структуры ссылок Дескриптора.
Дескриптор может быть характеризован как объект-ссылка на один конкретный элемент Методик, у которого есть собственные взаимосвязи и свойства. Когда Дескриптор создается, он имеет те же взаимосвязи и свойства, что и элемент Методик, на который он ссылается. Однако эти взаимосвязи и свойства могут быть переопределены для конкретной Процессной ситуации, для которой был создан Дескриптор. Концепция Дескриптора позволяет определять новые взаимосвязи и специфичные процессные свойства. Дескрипторы не являются элементами Методик и поэтому не имеют полного описания и свойств присущих им. На Рисунок 4 представлена диаграмма в нотации UML2.0, на которой Дескрипторы были определены для Задач, выполняющих их Ролей а также Рабочих продуктов на входе и выходе.
Рисунок 4 Пример использования Дескрипторов
Ситуация выраженная этим примером состоит в том, что Задача "Определить приоритет сценариев использования" выполняется различным образом (различные шаги, используются различные входные данные и.т.д.) на фазах Начало(Inception) и Проектирование(Elaboration). В частности мы можем увидеть следующее:
- Задача на фазе Начало имеет дополнительную ассистирующую Роль (assisting role) - Менеджер проекта со стороны Заказчика и не имеет связи с Рабочим Продуктом Риски проекта, который был определен как опциональный вход в содержании Методик (Шаги Задачи использующие документ Риски проекта опускается на этой фазе)
- Разделяются два типа Рабочего Продукта Модель сценариев использования: Модель сценариев использования так как она обычно используется на фазе Начало, с кратко описанными сценариями использования и детально описанными как это имеет место на фазе Проектирование.
Создание упрощенного Процесса Разработки в RMC*
В этом разделе мы создадим с помощью RMC упрощенный Процесс Разработки и таким образом на практике познакомимся с основными концепциями описанными выше.
Режимы работы с RMC
Существует 2 режима работы с RMC:
Режим разработки (Authoring perspective). Режим разработки предоставляет функции и представления для навигации по Содержанию Методик и Процессов Разработки, а также их изменению, Рисунок 5.
*В статье описывается IBM Rational Method Composer версии 7.0.1.
Для того, чтобы изменить или создать любой тип элемента нужно выбрать режим разработки. В режиме разработки RMC содержит 2 представления: Представление библиотеки (Library View) и Представление конфигурации (Configuration View).
Режим просмотра (Browsing perspective). Режим просмотра позволяет просмотреть публикуемую Конфигурацию Методик без возможности внесения, каких либо изменений. В режиме просмотра RMC содержит только Представление конфигурации. Для изменения режима работы можно использовать пиктограмму Open Perspective.
Пример создания Процесса Разработки и последующей его публикации с помощью RMC
Для того, чтобы охватить возможности RMC по созданию Содержания Методик и Процесса Разработки, мы будем создавать с нуля Содержание Методик и основанный на нем Процесс Разработки. Таким образом, возможности RMC по адаптации и изменению существующих Методик и Процессов Разработки в основном останутся за рамками статьи.
Для получения представления о работе с RMC при ограниченных размерах статьи мы рассмотрим максимально упрощенный Процесс Разработки.
Итак, начинаем с запуска RMC. При запуске инструмента выбираем Библиотеку Методик, предлагаемую по умолчанию. Надо убедиться, что текущий режим работы с RMC это режим разработки (Authoring perspective).
Создание Библиотеки Методик
Библиотека Методик (Method library) является контейнером содержащим в себе Подключаемые Методики (Method plug-in) и определения Конфигураций Методик (Method configuration). Все элементы Методик сохраняются в Библиотеке Методик.
Для создания с нуля Процесса Разработки первым шагом создадим Библиотеку Методик. Для этого выберем в меню File\New\Method Library и заполним название библиотеки и путь, по которому она будет храниться.
Рисунок 6 Диалог открытия Библиотеки Методик
Создание Подключаемой Методики
Подключаемая Методика (Method Plug-In) является контейнером содержания методик и процессов. Подключаемые Методики, Содержания Методик и Пакеты Содержаний (Content Package) позволяют организовать ваши Методики с уровнем детализации подходящим для создания и повторного использования.
В результате предыдущего действия у нас создалась пустая Библиотека Методик в которой теперь нужно создать Подключаемую Методику. В меню выбираем File\New\Method Plug-in . Выбираем имя и сохраняем Методику. Обратите внимание на поле Referenced Plug-ins . В этом поле выбираются Методики, содержимое которых мы хотим повторно использовать в создаваемой Подключаемой Методике. Так как мы создаем первую Подключаемую Методику в пустой Библиотеке Методик, то в нашем случае это поле пустое.
Создание Пакета Содержаний
Пакет Содержаний (Content Package) состоит из элементов Методик, таких как Роли, Задачи, Рабочие Продукты и Руководства.
В контекстном меню листа Content Packages в Представлении библиотеки, открывающемуся по щелчку правой кнопкой мыши выбираем New\Content Package . Именуем и сохраняем Пакет Содержаний. В результате выполненных шагов у нас сформировалась структура для создания и редактирования содержания Методик, Рисунок7.
Рисунок 7 Структура подключаемой методики
Создание элементов Методик
Начнем наполнять нашу Методику содержанием.
Создание Ролей. Для создания Роли выбираем лист Roles и в контекстном меню, открывающемся по щелчку правой кнопкой мыши выбираем New\Role . В открывшемся редакторе (Content Editor) для каждой Роли заполняем поля значениями, указанными в Таблице 1 и сохраняем роль.
|
Роль |
Поле |
Значение |
|
Разработчик |
Name |
Разработчик |
|
Presentation Name |
Разработчик | |
|
Brief description |
Разработчик выполняет разработку программных компонентов в соответствии с функциональными требованиями и стандартами кодирования принятыми в организации. Также Разработчик ответственен за модульное тестирование разрабатываемых компонентов. | |
|
Заказчик |
Name |
Заказчик |
|
Presentation Name |
Заказчик | |
|
Brief description |
Эта роль представляет группу, чьи потребности будут удовлетворенны в результате выполнения проекта. | |
|
Main description |
Заказчик отвечает за определение своих потребностей и установление их приоритетов, своевременное предоставление комментариев по предоставляемым ему рабочим продуктам и проведение приемочного тестирования. | |
|
Руководитель команды |
Name |
Руководитель команды |
|
Presentation Name |
Руководитель команды | |
|
Brief description |
Руководитель команды отвечает за общий успех проекта. | |
|
Main description |
Руководитель команды отвечает за общий успех проекта. В его основные задачи входит выяснения представления о системе и ее функциях, планирование проекта, разработка общей архитектуры, участие в разработке системы в течении всего проекта и коммуникации достигнутых промежуточных результатов заказчику. | |
|
Тестировщик |
Name |
Тестировщик |
|
Presentation Name |
Тестировщик | |
|
Brief description |
Тестировщик отвечает за соответствие разрабатываемой системы потребностям заказчика. | |
|
Main description |
Тестировщик должен на ранних этапах проекта понять потребности заказчика, ограничения, накладываемые на систему и выполнять проверку выполнения этих требований и соответствия ограничениям в ходе всего жизненного цикла продукта от выработки архитектуры и создания прототипа системы до окончательной поставки системы заказчику. |
Обратите внимание на существование 2-х различных полей: Namе и Presentation Name . Имя Роли Name используется при разработке Методологии внутри RMC, а имя Роли Presentation Name отображается на опубликованном сайте или в RMC в режиме просмотра. Это удобно использовать при достаточно большом объеме Методики или при повторном использовании содержания Подключаемых Методик. Например, Задача по тестированию сборки из Методики 1 может иметь внутреннее имя meth1_tst_Test build .
Создание Рабочих Продуктов. Для создания Рабочего Продукта выбираем лист Work Products и в контекстном меню, открывающемся по щелчку правой кнопкой мыши выбираем New и в зависимости от типа создаваемого продукта либо Artifact либо Deliverable либо Outcome . В открывшемся редакторе (Content Editor) заполняем для каждого Рабочего Продукта поля значениями, указанными в Таблице 2 и сохраняем Рабочий Продукт.
|
Рабочий продукт |
Тип рабочего продукта |
Поле |
Значение |
|
Концепция системы (Vision) |
Deliverable |
Name |
Концепция системы |
|
Presentation Name |
Концепция системы | ||
|
Brief Description |
Концепция системы описывает систему с точки зрения заказчика, обращая внимание на необходимые функции системы и приемлемый уровень качества. Концепция система должна описывать функции, которые будут включены в систему, а также функции, которые рассматривались, но не будут включены в систему. Также документ должен описывать операционные качества системы (объемы информации, время отклика, точность расчетов), профили пользователей (кто будет использовать систему), интерфейсы предоставляемые за пределы системы, если такие имеются. | ||
|
Архитектура системы |
Deliverable |
Name |
Архитектура системы |
|
Presentation Name |
Архитектура системы | ||
|
Brief Description |
Архитектура Системы представляет собой подробный архитектурный обзор системы, использует различные представления для иллюстрации разных аспектов системы | ||
|
Требования |
Artifact |
Name |
Требования |
|
Presentation Name |
Требования | ||
|
Brief Description |
Требования описывают возможности, которые должна предоставлять система для удовлетворения потребностей пользователей. | ||
|
План проекта |
Deliverable |
Name |
План проекта |
|
Presentation Name |
План проекта | ||
|
Brief Description |
План проекта представляет собой временную последовательность действий и задач с указанием ресурсов выполняющих задачи, содержащий зависимости между задачами. | ||
|
Прототип системы |
Deliverable |
Name |
Прототип системы |
|
Presentation Name |
Прототип системы | ||
|
Brief Description |
Прототип системы представляет собой выполняемую часть системы с ограниченной функциональностью. Позволяет получить комментарии заказчика по поводу понимания концепции системы заказчиком, разрешить основные риски связанные с требованиями и (или) технологиями. | ||
|
План тестирования |
Deliverable |
Name |
План тестирования |
|
Presentation Name |
План тестирования | ||
|
Brief Description |
План тестирования определяет цели и стратегию тестирования в рамках проекта, а также необходимые ресурсы. | ||
|
Тестовые сценарии |
Artifact |
Name |
Тестовые сценарии |
|
Presentation Name |
Тестовые сценарии | ||
|
Brief Description |
Этот артефакт определяет набор тестовых сценариев, которые представляют из себя набор входных параметров, параметров выполнения теста и ожидаемые результаты | ||
|
Сборка |
Artifact |
Name |
Сборка |
|
Presentation Name |
Сборка | ||
|
Brief Description |
Этот артефакт представляет собой выполняемую версию системы или части системы и демонстрирует часть возможностей финальной системы | ||
|
Результаты тестирования |
Artifact |
Name |
Результаты тестирования |
|
Presentation Name |
Результаты тестирования | ||
|
Brief Description |
Результаты тестирования содержат заключение о качестве протестированной сборки вместе с суммарной статистикой проведенного тестирования. | ||
|
Дефекты занесенные в систему отслеживания дефектов |
Artifact |
Name |
Дефекты |
|
Presentation Name |
Дефекты | ||
|
Brief Description |
Дефекты занесенные в систему отслеживания дефектов | ||
|
Продукт |
Deliverable |
Name |
Продукт |
|
Presentation Name |
Продукт | ||
|
Brief Description |
Система поставляемая заказчику | ||
|
Продукт установлен в среде заказчика |
Outcome |
Name |
Продукт установлен в среде заказчика |
|
Presentation Name |
Продукт установлен в среде заказчика | ||
|
Заказчик принял продукт |
Outcome |
Name |
Заказчик принял продукт |
|
Presentation Name |
Заказчик принял продукт |
В нашем случае Тестовые сценарии будут поставляться на рассмотрение Заказчику в составе Плана тестирования . Чтобы отразить это в нашей модели надо открыть План тестирования , перейти на вкладку Deliverable Parts , нажать кнопку Add и выбрать Тестовые сценарии из дерева Рабочих Продуктов.
Создание Задач. Для создания Задачи выбираем лист Tasks и в контекстном меню, открывающемся по щелчку правой кнопкой мыши выбираем New\Task . В открывшемся редакторе (Content Editor) заполняем для каждой Задачи поля значениями, указанными в Таблице 3 и сохраняем Задачу. Для того, чтобы указать, кто выполняет Задачу надо перейти на закладку Roles и выбрать Роль ответственную за выполнение Задачи (Primary performer), которая может быть только одна и Роли участвующие в выполнении Задачи (Additional performers). Для указания Рабочих Продуктов надо перейти на вкладку Work Products и выбрать Рабочие Продукты, которые являются основной входной информацией (Mandatory inputs), дополнительной входной информацией (Optional inputs) и информацией на выходе из Задачи (Outputs).
|
Задача |
Вкладка |
Поле |
Значение |
|
Создать концепцию системы |
Description |
Name |
Создать концепцию системы |
|
Presentation Name |
Создать концепцию системы | ||
|
Roles |
Primary performer |
Заказчик | |
|
Work products |
Outputs |
Концепция системы | |
|
Определить требования к системе |
Description |
Name |
Определить требования к системе |
|
Presentation Name |
Определить требования к системе | ||
|
Roles |
Primary performer |
Руководитель команды | |
|
Additional performers |
Заказчик, Тестировщик, Разработчик | ||
|
Work Products |
Mandatory inputs |
Концепция системы | |
|
Outputs |
Требования | ||
|
Создать архитектуру системы |
Description |
Name |
Создать архитектуру системы |
|
Presentation Name |
Создать архитектуру системы | ||
|
Roles |
Primary performer |
Руководитель команды | |
|
Additional performers |
Тестировщик, Разработчик | ||
|
Work products |
Mandatory inputs |
Требования | |
|
Optional inputs |
Концепция системы | ||
|
Outputs |
Архитектура Системы | ||
|
Создать план тестирования |
Description |
Name |
Создать план тестирования |
|
Presentation Name |
Создать план тестирования | ||
|
Roles |
Primary performer |
Тестировщик | |
|
Additional performers |
Заказчик, Разработчик, Руководитель команды | ||
|
Work products |
Mandatory inputs |
Требования | |
|
Optional inputs |
Концепция системы, Архитектура Системы | ||
|
Outputs |
План тестирования | ||
|
Создать прототип |
Description |
Name |
Создать прототип |
|
Presentation Name |
Создать прототип | ||
|
Roles |
Primary performer |
Руководитель команды | |
|
Additional performers |
Разработчик, Тестировщик | ||
|
Work products |
Mandatory inputs |
Архитектура Системы, Требования | |
|
Optional inputs |
Концепция системы | ||
|
Outputs |
Прототип | ||
|
Закодировать требования |
Description |
Name |
Закодировать требования |
|
Presentation Name |
Закодировать требования | ||
|
Roles |
Primary performer |
Разработчик | |
|
Additional performers |
|||
|
Work products |
Mandatory inputs |
Требования | |
|
Optional inputs |
|||
|
Outputs |
Сборка | ||
|
Протестировать разработанный код |
Description |
Name |
Протестировать разработанный код |
|
Presentation Name |
Протестировать разработанный код | ||
|
Roles |
Primary performer |
Тестировщик | |
|
Additional performers |
|||
|
Work products |
Mandatory inputs |
Сборка, План тестирования | |
|
Optional inputs |
|||
|
Outputs |
Дефекты, Результаты тестирования | ||
|
Установить продукт в среде заказчика |
Description |
Name |
Установить продукт в среде заказчика |
|
Presentation Name |
Установить продукт в среде заказчика | ||
|
Roles |
Primary performer |
Руководитель команды | |
|
Additional performers |
Разработчик, Тестировщик | ||
|
Work products |
Mandatory inputs |
Продукт | |
|
Optional inputs |
|||
|
Outputs |
Продукт установлен в среде заказчика | ||
|
Description |
Name |
||
|
Presentation Name |
|||
|
Roles |
Primary performer |
||
|
Additional performers |
|||
|
Work products |
Mandatory inputs |
||
|
Optional inputs |
|||
|
Outputs |
Создание Конфигурации Методик (Method configuration)
Конфигурация Методик позволяет определить рабочий набор из Содержания Методик и Процессов для специфичного контекста. Все Содержание Методик и Процессы в RMC организованы в виде Подключаемых Методик и Пакетов Методик. Таким образом, Конфигурация Методик представляет собой выборку из Подключаемых Методик и Пакетов Методик.
Выбираем лист Configurations в дереве Представления Библиотеки Методик. Выбираем New\Method Configuration в контекстном меню, появляющемся по щелчку правой кнопкой мыши. Вводим имя Конфигурации Упрощенная методология в поле Name и переходим в редакторе на вкладку Plug-in and Package Selection . Выбираем все элементы нашей Подключаемой Методики для использования в созданной Конфигурации, как на Рисунок 8. Мы вернемся к редактированию Конфигурации Методик позже, когда нам будет нужно опубликовать сайт процесса.
Рисунок 8 Подключение элементов Методики и Процессов к Конфигурации
Создание Процесса Разработки (Delivery process)
Процесс Разработки представляет собой полный и интегрированный подход к выполнению определенного вида проектов. Он представляет модель полного жизненного цикла проекта, который детализируется путем выстраивания последовательности ссылок на Содержание Методик в структуре декомпозиции (breakdown structure).
Выбираем лист Delivery Processes в дереве Представления Библиотеки Методик. Выбираем New\ Delivery Process в контекстном меню. Вводим имя Процесса Упрощенный процесс и выбираем Упрощенная методология как Default Configuration в появившемся диалоге New Process Component . В появившемся диалоговом окне Switch Configuration выбираем Yes . Если диалоговое окно не появилось, то выбираем нашу Конфигурацию в списке конфигураций, расположенном в панели инструментов. Сохраняем наш Процесс и переходим к его редактированию.
Для начала в Представлении Конфигураций находим Упрощенный процесс и дважды кликаем по нему для начала редактирования. Переходим на закладку Work Breakdown Structure .
Создадим фазы Процесса. Для этого в редакторе выберем Упрощенный процесс и в контекстном меню выберем New Child\Phase . Создадим фазы Начало, Проектирование, Построение и Внедрение.
Теперь добавим к фазам Дескрипторы Задач, определенных в нашей Методике. Для примера добавим Задачу Создать концепцию системы в фазу Начало . Для этого в Представлении Конфигурации Методик откроем лист Disciplines\Uncategorized Tasks\Создать концепцию системы и перенесем его (drug and drop) на фазу Начало в редакторе, см. Рисунок9. Аналогичным образом добавим Дескрипторы, перечисленные в Таблице 4.
Рисунок 9 Добавление к процессу Дескриптора
|
Фаза |
Задача |
|
Начало |
Создать концепцию системы |
|
Определить требования к системе | |
|
Создать архитектуру системы | |
|
Создать план тестирования | |
|
Создать план проекта | |
|
Проектирование |
Создать концепцию системы |
|
Создать прототип | |
|
Протестировать разработанный код | |
|
Определить требования к системе | |
|
Создать архитектуру системы | |
|
Создать план тестирования | |
|
Создать план проекта | |
|
Построение |
Закодировать требования |
|
Протестировать разработанный код | |
|
Внедрение |
Установить продукт в среде заказчика |
|
Протестировать разработанный код |
Можно заметить, что мы добавили к разным Фазам процесса Дескрипторы одних и тех же Задач. Это сделано для иллюстрации переопределения свойств и взаимосвязей элементов Методик в Процессе посредством Дескрипторов.
Для переопределения свойств нужно выделить Дескриптор в окне редактора и изменить его свойства в окне Properties (Для активации окна выберите Window \ Show View \ Other \ Properties ). Для иллюстрации переопределим свойства нескольких Дескрипторов как показано в Таблице 5. (В приложенном к статье примере можно ознакомится с переопределением свойств остальных Дескрипторов)
Таблица 5 Переопределение свойств Дескрипторов
|
Фаза |
Дескриптор |
Вкладка |
Поле |
Значение |
|
Начало |
Создать концепцию системы |
Documentation |
Brief description |
Заказчик определяет свою основную проблему, которую должен решить продукт, как он будет выглядеть и кем использоваться |
|
Проектирование |
Создать концепцию системы |
Documentation |
Brief description |
Руководитель команды уточняет концепцию системы: границы системы, кому нужна система и во что она обойдется, а также ограничения, которых нужно придерживаться |
|
Roles |
Primary Performer |
Руководитель команды | ||
|
Additional Performers |
Заказчик | |||
|
Начало |
Определить требования к системе |
Нужно определить несколько (3-5) наиболее критичных требований к системе, без которых конечный продукт не будет приносить пользы заказчику. | ||
|
Проектирование |
Протестировать разработанный код |
Documentation |
Brief description |
На этой фазе тестируется прототип относительно возможности предоставления уже определенных наиболее критичных требований и ограничений. |
|
Work Products |
Mandatory Input |
Прототип системы; План тестирования | ||
|
Внедрение |
Протестировать разработанный код |
Documentation |
Brief description |
Заказчик проводит приемочное тестирование продукта |
|
Roles |
Primary Performer |
Заказчик | ||
|
Work Products |
Mandatory Input |
Продукт | ||
|
Output |
Дефекты;Заказчик принял продукт |
В данный момент модель жизненного цикла нашего Процесса представляет водопад, но мы можем добавить в него элементы итеративности. Например, мы можем добавить Итерации на фазе Построение . Для этого создадим в фазе Построения Итерацию Итерации Разработки - с помощью контекстного меню Child \ Iteration . Далее вырежем Дескрипторы Закодировать требования и Протестировать разработанный код и скопируем их в Итерацию. Также можно ввести Итерации по уточнению требований в фазу Проектирование для Дескрипторов Создать прототип , Протестировать разработанный код и Определить требования к системе.
Добавление диаграмм
Для упрощения восприятия Процесса можно создать диаграммы. Для этого, выделяем в редакторе Процесса Процесс, Фазу, Итерацию или Активность, выбераем в контекстном меню Diagrams \ Open Activity Diagram , Diagrams \ Open ActivityDetail Diagram , или Diagrams \ Open Work Product Dependency Diagrams и в появившемся редакторе создадаем диаграмму. На Рисунок 10 показаны диаграммы Activity и Activity Details для фазы Проектирование .
Рисунок 10 Диаграммы для фазы Проектирование
Публикация сайта процесса
Для публикации сайта, необходимо добавить в определение Конфигурации представление, которое будет отображаться на сайте.
Для начала создадим произвольную категорию (Custom category). В Представлении Библиотеки выделяем лист Custom Categories и в контекстном меню выбираем New\Custom Category . Называем новую категорию Представление методологии . Переходим на вкладку Assign и добавляем в поле Content Elements созданный нами Упрощенный процесс. Теперь в контекстном меню категории Представление методологии выбираем меню New\Custom Category , называем новую категорию Роли , переходим на вкладку Assign и добавляем в поле Content Elements Роли: Заказчик , Разработчик , Руководитель Команды , Тестировщик . Аналогичным образом создаем категории Задачи , Рабочие продукты , Шаблоны . У вас должна получиться структура, аналогичная показанной на Рисунок 11.
Рисунок 11 Структура публикации сайта
Отредактируем Конфигурацию Упрощенная методология . В редакторе переходим на вкладку Views и нажимаем кнопку Add View . В появившемся дереве выбираем созданную нами категорию Представление методологи. Для того чтобы созданное нами представление отображалось по умолчанию, нажимаем на кнопку Make default , сохраняем изменения. Выбираем в меню Configuration\Publish , в первом окне нажимаем Next , указываем название сайта и путь где будет размещен набор html-страниц на диске, нажимаем Finish. В результате должен получится сайт процесса аналогичный показанному на Рисунок 12.
Рисунок 12 Опубликованный сайт процесса
Обратите внимание, что для корректной работы опубликованного сайта на клиентской машине необходимо установить Java Runtime Environment (JRE) [2]
Отличия в метамодели RUP 2003 и RMC
Отличия в метамодели основном связаны с переходом в RMC на новую схему организации содержания методик - Unified Method Architecture (UMA), базирующуюся на стандарте SPEM 1.1 (Software Process Engineering Metamodel ) [3]
Activities были переименованы в Tasks . Переименование связано с лучшим отражением терминов принятых в индустрии разработки ПО.
Task"и теперь могут выполняться больше чем одной ролью . В RUP2003 активность моделировалась как операция, выполняемая ролью. Это оказалось достаточно ограниченным способом моделирования человеческой деятельности. Такой подход не позволял выразить некоторые виды работ, выполняемые взаимодействием различных ролей. UMA разрешила эту проблему выделив Task в независимый элемент модели, к которому как ресурсы могут присваиваться выполняющие ее роли. Теперь задаче могут быть присвоены основной исполнитель (для совместимости с предыдущей версией RUP) и несколько дополнительных исполнителей.
Улучшение концепции артефакта . В RUP для продуктов используемых и производимых в процессе разработки ПО применялось только понятие артефакта. UMA расширяет таксономию RUP введением общей концепции рабочего продукта. Рабочие продукты могут быть 3-х типов: Artifact (материальные и не тривиальные рабочие продукты), Deliverable(рабочий продукт, поставляемый заказчику для ревью) и Outcome (рабочий продукт, не имеющий осязаемой формы. Например: Изменены настройки веб-сервиса, ПО установлено в тестовую среду заказчика).
Различная категоризация рабочих продуктов и ролей. В RUP все роли и категории были категорированы по дисциплинам. Однако случается, что артефакты используются в рамках нескольких дисциплин и привязка только к одной дисциплине приводит к путанице. В UMA определены различные категоризации для определений работы (дисциплины(disciplines)), рабочих продуктов (домены (domains) и типы рабочих продуктов (work product kinds)) и ролей (наборы ролей(role sets)).
Процессные компоненты переименованы в Пакеты Методик ( Method Package ). Концепция компонента широко используется во многих стандартах и методологиях. В большинстве случаев компонент используется как абстракция, инкапсулирующая компонент как черный ящик, который можно использовать посредством определенных интерфейсов. RUP определение компонента не удовлетворяет этому критерию черного ящика. Также SPEM стандарт определяет концепцию пакета (package). Для того чтобы быть совместимым с SPEM и следовать общему употреблению концепции компонента в RMC Process component был переименован в Method Content.
Разделение элементов описания процесса и элементов описания методик . В RUP 2003 новый процесс создавался путем определения новой конфигурации и ручного документирования в артефактах отклонений от стандартного RUP. UMA добавляет новые концепции к концепции конфигурации используемой для адаптации процесса. UMA позволяет выбирать для моделируемого процесса какие именно рабочие продукты из пакета методик войдут в каждую фазу, так как можно легко добавлять, удалять и менять порядок элементов в структуре процесса, используя или не используя любые компоненты пакета методик. Такие возможности достигаются путем более четкого отделения элементов методик (например, задач определенных для дисциплин) и применения элементов методик в процессе (выраженного через диаграммы активностей и WBS) также как моделирование процесса (т.е. создание новых или адаптация диаграмм активностей или WBS"ов). Это вводит несколько новых концепций, таких как дескрипторы (work product descriptor, task descriptor), которые поддерживают разделение и достижение новых возможностей по поддержке и повторному использованию различных семей и подпроцессов внутри одной конфигурации.
Workflow details переименованы в Activities . Из за того, что слово Activity наиболее часто используется для элементов диаграмм активности и для самих этих диаграмм.
Заключение
В статье рассмотрено применение Rational Method Composer для создания упрощенного процесса разработки и его публикации.
Автор не претендует на точность использования терминологии. Рассматриваемый пример является учебным и может содержать неточности, его целью является быстрое введение в моделирование процесса, а не создание полноценной модели процесса разработки.