(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Моделирование процессов разработки ПО и создание сайтов процессов с помощью Rational Method Composer

Обзор продукта

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.

Рисунок 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 и сохраняем роль.

Таблица 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) [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 для создания упрощенного процесса разработки и его публикации.

Автор не претендует на точность использования терминологии. Рассматриваемый пример является учебным и может содержать неточности, его целью является быстрое введение в моделирование процесса, а не создание полноценной модели процесса разработки.



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 20.03.2013 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
IBM Rational Method Composer Authorized User License
Rational ClearQuest Floating User License
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM Rational Functional Tester Floating User License
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
Вопросы и ответы по MS SQL Server
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Мастерская программиста
Все о PHP и даже больше
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
проблемы с установкой Rational Rose Enterprise Edition (11)
Привет! Есть проблема, прошу совета. Скачал с rational.com Rational Rose Enterprise Edition,...
 
Бесплатные видео-уроки по работе в AutoCAD (3)
Бесплатные видео-уроки по работе в AutoCAD http://store.techcourses.ru/ad/152929/
 
помогите Config spec ClearCase (2)
Добрый день! Мальчики, пожалуйста, объясните для блондинки, очень силюсь понять, но...
 
Настройка e-mail уведомлений. Аутентификация (1)
Добрый день! Надеюсь на вашу помощь в поиске решения моей проблемы. Не получается настроить...
 
Как в IBM Rational DOORS сделать заголовки не жирным шрифтом? (1)
Измучился уже, когда идет иерархия уровнем ниже, чем Х.Х., мне нужно, чтобы заголовки не...
 
 
 



    
rambler's top100 Rambler's Top100