Практическая часть Создание упрощенного Процесса Разработки в rmc*

В практической части необходимо создать с помощью RMC упрощенный Процесс Разработки. Придумайте самостоятельно себе тему для описания вашего процесса разработки.

Скачать пробную версию на 30 дней можно с сайта:

http://www-01.ibm.com/software/awdtools/rmc/

Или взять у преподавателя дистрибутив с возможностью постоянной лицензии.

Режимы работы с RMC

Существует 2 режима работы с RMC:

Режим разработки (Authoring perspective). Режим разработки предоставляет функции и представления для навигации по Содержанию Методик и Процессов Разработки, а также их изменению, Рисунок 4.

Рисунок 4 Режим разработки

*Описывается IBM Rational Method Composer версии 7.0.1.

Для того, чтобы изменить или создать любой тип элемента нужно выбрать режим разработки. В режиме разработки RMC содержит 2 представления: Представление библиотеки (Library View) и Представление конфигурации (Configuration View).

Режим просмотра (Browsing perspective). Режим просмотра позволяет просмотреть публикуемую Конфигурацию Методик без возможности внесения, каких либо изменений. В режиме просмотра RMC содержит только Представление конфигурации. Для изменения режима работы можно использовать пиктограмму Open Perspective.

Рисунок 5.

Пример создания Процесса Разработки и последующей его публикации с помощью 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 и сохраняем роль.

Таблица 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 и сохраняем Рабочий Продукт.

Таблица 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).

Таблица 3 Задачи

Задача	Вкладка	Поле	Значение
Создать концепцию системы	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 Добавление к процессу Дескриптора Таблица 4 Дескрипторы

Фаза	Задача
Начало	Создать концепцию системы
	Определить требования к системе
	Создать архитектуру системы
	Создать план тестирования
	Создать план проекта
Проектирование	Создать концепцию системы
	Создать прототип
	Протестировать разработанный код
	Определить требования к системе
	Создать архитектуру системы
	Создать план тестирования
	Создать план проекта
Построение	Закодировать требования
	Протестировать разработанный код
Внедрение	Установить продукт в среде заказчика
	Протестировать разработанный код

Можно заметить, что мы добавили к разным Фазам процесса Дескрипторы одних и тех же Задач. Это сделано для иллюстрации переопределения свойств и взаимосвязей элементов Методик в Процессе посредством Дескрипторов.

Для переопределения свойств нужно выделить Дескриптор в окне редактора и изменить его свойства в окне 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).