Как создать атрибут с множественным выбором

<< Перейти в раздел “IBM Rational Team Concert Work Item Tracking FAQ”

Для создания поля с множественным выбором необходимо выполнить следующие шаги (на примере списка браузеров):

1. Создать атрибут с типом большая, малая или средняя строка.

1. Добавить перечисления для браузеров.

1. Добавить на форму задания презентацию и указать вид «Переключатель со списком с множественным выбором» или «Список с множественным выбором».

1. Указать перечисление для поля в презентации

1. В результате будет следующий вид на форме.

Традиционное планирование: Управление формальными проектами в Rational Team Concert 4.0

Оригинал: https://jazz.net/library/article/657/

Перевод Шамрай А.В.

Традиционные планы

Компонент планирования Rational Team Concert позволяет планировать полный выпуск проекта, а также его различные фазы. Традиционная модель планирования разработана, чтобы поддерживать планирование проекта на основе формального шаблона процесса управления проектами, который включает ряд последовательных фаз (Требования, Проектирование, Реализация и Тестирование). Чтобы использовать традиционную модель планирования, используйте формальный шаблон процесса управления проектами, который поддерживает формальный или традиционный процесс планирования.

Формальный шаблон процесса управления проектами обеспечивает следующие настраиваемые задания:

• Запрос на изменения проекта: Определяет изменение в согласованные объем и цели проекта для вставки требований, которые не были первоначально определены как часть проекта.
• Бизнес-потребность: Описывает функцию, API или улучшения, которые добавляются к продукту. Бизнес-потребность описывает работу на высоком уровне так, чтобы все могли понять, что нужно сделать, глубоко не вникая в детали.
• Риск: Идентифицирует возможное событие, которое может негативно повлиять на проект. Этот тип задания включает матрицу для вычисления вероятности и влияния риска.
• Действие с риском: Определяет то, что должно быть выполнено, чтобы смягчить риск. Действие с риском – это элемент работы и оценивается в часах.
• Проблема: Идентифицирует непредвиденные события, которые произошли в проекте.
• Стадия: Определяет важный момент или событие в плане, где событие — возникновение чего-либо или результат.

Планировщик для традиционной планов планирует задачи последовательно. Расписание плана определяется по следующей информации:

• Оценка рабочих элементов
• Даты фактическое начало или окончание заданий, определяются изменением состояния задания
• Даты начала и завершения итерации, связанной с планом
• График ограничений и зависимостей заданий
• Проектные рабочие дни и часы
• Доступность ресурсов, которые назначены на задания

Когда следует использовать традиционное планирование

Используйте процесс традиционный планирования для проекта, в котором работа выполняется последовательно и следует по расписанию, который определен с помощью графика зависимости, ограничений, доступности ресурсов и длительности. Не используйте процесс традиционного планирования для проектов, которые используют agile практики.

Традиционные планы для формальных проектов

С шаблоном формального процесса управления проектами поставляется три типа плана:

• План выпуска: этот тип плана является планом самого высокого уровня. Она обеспечивает краткий обзор целей проекта. Хотя можно создать для любого этапа план выпуска, лучше использовать этот тип плана для общего выпуска.
• План этапа: этот тип плана показывает цели, которые должны быть достигнуты в этапе. Вы можете создать план этапа и назначить задания, которые должны быть завершены на этом этапе.
• Кросс проектный план: этот тип плана отслеживает расписание заданий в других проектах. Вы можете создать кросс проектный план, создать задания для отслеживания и добавить ссылки Отслеживание на задания из различных проектов/планов.

Дополнительные сведения о различных типах плана см. в Типы планов.

Например, Интернет-магазин музыки – это проект, который имеет традиционный план со следующими артефактами:

• Запроса на изменение проекта: Добавить возможность скопировать существующий список воспроизведения.
• Бизнес потребность: Пользователь должен иметь возможность управлять списком воспроизведения.
• Задачи: Реализовать удаление элементов из списка воспроизведения.
• Стадии: Beta 1, Beta 2 и eGA

Запрос на изменение проекта и бизнес потребность типы заданий определены как элементы плана по умолчанию. Оценки для элементов плана формируются от их дочерних заданий. Диаграмма Ганта по-разному отображает элементы плана и элементы выполнения. Стадия в диаграмме Ганта отображается в виде черного рубина.

Зависимости и ограничения

Можно создать график зависимости между двумя заданиями. Зависимости используются для вычисления расписания заданий в плане. В настоящее время поддерживается только один тип зависимости:

• Окончание-начало: В этой зависимости начало следующего задания зависит от завершения другого задания: предшественника.

На следующем рисунке показана зависимость окончание-начало между задачей «Список всех вариантов использования для удаления», который является предшественником, и задача «Технический проект для управления элементами в списке воспроизведения», которая является последователем. Зависимость указывает, что задача «Технический проект для управления элементами в списке воспроизведения» может начаться только после завершения задачи «Список всех вариантов использования для удаления». В представлении График работ и расписание по умолчанию добавлен столбец предшественника. Этот столбец показывает все ссылки предшественники для задания. Аналогично столбец последователь может быть добавлен, чтобы показать все ссылки последователи для задания.

Кроме того можно применять ограничения для расписания заданий. Ограничения также используются для вычисления расписания заданий в плане. Доступны три типа ограничений:

• Как можно быстрее: этот тип является типом ограничения по умолчанию. Это означает, что задание планируется на ближайшее время, в которое оно может начаться на основе существующего графика проекта.
• Начать не ранее чем: этот тип ограничения ограничивает начало задания на дату или после даты заданной ограничением.
• Завершить не позже чем: этот тип ограничения ограничивает окончание задания на дату или до даты заданной ограничением.

Критический путь

Критический путь — это самый длинный путь в проекте или итерации. Он определяет кратчайшие сроки завершения мероприятий в рамках плана. Самый длинный путь в плане основывается на самой поздней дате окончания всех заданий в плане. Критический путь рассчитывается, используя следующую информацию:

• Плановые даты
• Оценки заданий
• Ограничения
• Зависимости
• Настройки рабочей среды проекта
• Для заданий без назначенного ресурса:
  • Настройки проектного уровня, такие как рабочее время на каждый день, время выхода и отсутствия
• Для рабочих элементов с назначенным ресурсом:
  • Календарь ресурса
  • Доступность, в том числе по расписанию, отсутствию и распределений в проекте

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

Пометка потенциальных проблем в плане

Задания в представлении плана с отсутствующими или недопустимыми данными отмечены с помощью иконок (информационные, предупреждения или ошибки), которые расположены рядом с заданием. Подсказки над значком описывают источник потенциальной проблемы. Существует три типа потенциальных проблем, которые помечаются для традиционных планов:

• Отсутствуют необходимые атрибуты
• Неверная оценка
• Неверные данные, включая зависимости или нарушения ограничений

Предложенные моментальные копии

Во время начального планирования, менеджер проекта создает предложенную моментальную копию, отражая первоначальное, предлагаемое расписание. Этот тип моментальной копии доступен по умолчанию с шаблоном формального процесса управления проектами. Дополнительные сведения о том, как управлять моментальными копиями, см. Эффективное планирование с использованием моментальных копий в RTC 4.0.

Риски и действия с риском

Руководитель проекта может определить Риски, которые могут негативно сказаться на ходе выполнения проекта, вместе с Действиями с риском для отслеживания последствий и сдерживания этих рисков. Риски могут быть определены при создании плана или в ходе выполнения плана. Подробные сведения о том, как определить риски, см. определение рисков.

Представление График работ и расписание по умолчанию отфильтровывает все риски из представления плана. Удалите фильтр по умолчанию для просмотра рисков в плане.

После выявления и определения рисков, можно создать задание Действие с риском для отслеживания мероприятий по уменьшению риска. Вы уменьшаете риск, используя стратегию. Например, после того, как задание риск «Требуемый виджет не поддерживаются во всех браузерах» определен, можно создать задание действие с риском, такое как «Исследовать планы поставщиков для поддержки виджета в будущем». Дополнительные сведения о создании заданий действие с риском, см. Создание действий с риском.

Можно связать задания Риск и Действие с риском с помощью ссылки «Кем исправлено» и «Исправляет». Вы можете использовать эти ссылки для отслеживания какие действия с риском исправляют какие риски.

Ресурсы

Следующим шагом после завершения первоначального планирования является выявление ресурсов, необходимых для завершения работы. Можно искать ресурсы в течение конкретных периодов времени (соответствующие даты начала и окончания задания) и добавить их в проект.

Ресурсами управляют на вкладке Ресурсы в плане.

Вы можете также выделить ресурсы для проекта на вкладке рабочей среды редактора пользователя.

Сведения об управлении ресурсами в рамках проекта приведены в разделе Управление ресурсами проекта.

После того, как ресурсы выделяются для проекта, менеджер проекта может назначить задания в плане для этих ресурсов.

Доступность ресурсов и расписание плана

Доступность ресурсов является одним из критериев, которые обеспечивает расчет расписания. Если изменить доступность ресурсов или запланированное отсутствие, расписание автоматически обновляется для отражения изменений. Например, после того, как ресурс добавляет запланированное отсутствие (см. рисунок ниже)…

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

Запланированные моментальные копии

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

После создания запланированной моментальной копии, руководитель проекта может следить, глядя на различия между текущим планом и запланированной моментальной копии (совершенного плана). Просмотр моментальных копий включает в себя возможность видеть различия между копией и текущим планом. Менеджер проекта может также использовать обычные моментальные копии на протяжении выполнения проекта, чтобы смотреть на состояние проекта в определенное время и сравнивать эти обычные копии с запланированной копией (совершенным планом) и фактическим планом.

Дополнительные сведения о том, как управлять моментальными копиями, см. Эффективное планирование с использованием моментальных копий в RTC 4.0.

Отслеживание времени заданий

Члены команды могут записывать время, затраченное на задание на каждый день. Записи времени на вкладке Отслеживание времени задания синхронизированы со значением в поле Затраченное время задания. Если вы используете шаблон формального процесса управления проектами, то поле Затраченное время задания доступно только для чтения.

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

Проблемы во время выполнения плана

В ходе выполнения проекта могут возникнуть непредвиденные события. Для идентификации и описания таких проблем, используйте задание Проблема. Основное различие между проблемой и риском, что риск выявляется и определяется перед тем, как произойдет. Проблема регистрируется после того, как она произошла.

Создание итерации из плана

В ходе выполнения проекта, если руководитель проекта хочет добавить дополнительный этап в структуре итерации, это можно сделать в представлении плана выпуска.

Сведения о добавлении дочерних итераций в родительской итерации из представления планов содержатся в разделе Создание дочерней итерации.

Об авторе

Sharoon Shetty Kuriyala лидер команды, которая разрабатывает компонент планирования для Rational Team Concert. С ней можно связаться по адресу sshettyk@us.ibm.com.

Сравнение концепции ClearCase UCM и RTC

Оригинал: Comparing concepts between ClearCase UCM and RTC

Введение

Некоторые путаются в сходствах и различиях между Rational ClearCase и Rational Team Concert. В основном это связано с изменениями в терминологии, а в некоторых случаях это связано с различными моделями использования и возможностями продуктов. Данная статья направлена на прояснение некоторых моментов.

Демонстрация будет выполняться на основе UCM, так как многие из наших клиентов используют ClearCase UCM. Если вы используете ClearCase UCM интегрированный с ClearQuest, то настоятельно рекомендуется также прочитать Сравнение концепции ClearQuest и Rational Team Concert.

Базовая терминология

Давайте рассмотрим различия между ClearCase UCM и Rational Team Concert (RTC). ClearCase является системой управления конфигурацией. Клиенты могут использовать его отдельно или с функциональностью UCM. UCM дает пользователям создавать программные Компоненты (Component), а затем создавать Базовые линии (Baseline) на эти компоненты. Файлы для изменения Извлекаются на редактирование (Checked Out), изменяются, а затем Регистрируются (Checked In) в рамках представления, которое является рабочим пространством для разработки. Наборы изменений (Change Sets) составляются из отдельных изменений, внесенных в рамках Активности (Activity). Эти Наборы изменений затем становятся общедоступными для других членов команды через операцию Доставки (Delivery) этих Наборов изменений. ClearCase хранит эти артефакты в собственном формате и сохраняет все свои данные в репозитории, который называется VOB. Каждый VOB может содержать один или более компонентов UCM. Каждый VOB может хранить артефакты в любой структуре каталогов, которую пользователь хочет использовать. ClearCase поддерживает параллельную разработку и, когда возникают конфликты между версиями одного и того же файла, то они разрешаются с помощью операции Слияния (Merge). В базовом ClearCase, VOB-файлы могут содержать Ветви (Branch), которые обеспечивают логическое «разделение» кода для параллельной разработки, которая выполняется изолированно. В UCM эти Ветви имеют некоторые формальные ограничения и называются UCM-потоки (UCM Streams). Участник команды разработки выполняет Доставку его или ее изменений из их рабочего пространства, называемого Представлением (View), в Поток (Stream). Другие члены команды будут выполнять Обновление (Rebase) их Потока и забирать изменения, которые доставлены в родительский Поток.

ClearCase есть такое понятие как Динамическое представление (Dynamic View), это рабочее пространство, которое обновляется без вмешательства пользователя, на основе пользовательских настроек. ClearCase есть также концепция Статических представлений (Snapshot View), которое является копией рабочего пространства, ассоциированного с состоянием репозитория в определенный момент времени. Статическое представление приводится к «текущему состоянию»с помощью операции Обновить (Updating) представление. В любом из этих типов представлений, Базовые линии и Наборы изменений могут быть доставлены из потока в поток, при этом любые необходимые операции Слияния по отдельным файлам будут обнаружены системой, а затем их должен будет разрешить пользователь. Также как Компоненты получают Наборы изменений, применяемые к ним, отдельные Компоненты могут иметь Базовые линии (в основном как метка для всех артефактов в рамках Компонента или VOB), применяемые к ним. «Основная базовая линия» с набором базовых линий нескольких Компонентов называется Композитная базовая линия (Composite Baseline).

В RTC SCM есть многие из этих же понятий, но есть некоторые незначительные отличия. Jazz имеет единое хранилище, в котором хранятся его артефакты как REST ресурсы. Эти ресурсы хранятся в базе данных. Jazz поддерживает использование многих баз данных, включая Oracle, DB2 и SQL Server. Это, в общем, используется как Jazz Репозиторий (Jazz Repository). В Jazz разрабатываемая программа разбивается на программные Компоненты (Component). Эти Компоненты могут содержать артефакты в любой структуре каталогов, и параллельная разработка поддерживается с использованием Jazz Потоков (Jazz Streams). Пользователи, работающие с Jazz Компонентой, присоединяются к проекту и создают своё собственное Рабочее пространство Репозитория (Repository Workspace) (которое содержит копии всех их Наборов изменений (Change Set)), а также Личное Рабочее пространство (Sandbox) на своем локальном компьютере. Все изменения файлов отслеживаются клиентом Jazz, и пользователь в дальнейшем будет Регистрировать (Check In) свои изменения. В Jazz нет понятия изъять на редактирование, но Jazz поддерживает Блокировку (Locking) ресурсов. Когда пользователь видит изменения в своем Личном рабочем пространстве, он будет Регистрировать изменения и связывать их с Набором изменений, который собирает отдельные изменения и сохраняет их в Рабочем пространстве Репозитория. Эти Наборы изменений могут быть Доставлены (Deliver) в один или несколько Потоков Jazz. Другие члены команды будут Принимать (Accept) изменения в свои Рабочие пространства Репозитория из этого потока, и поставлять сделанные изменения на Родительский поток.

Личное рабочее пространство пользователя или Рабочее пространство Eclipse (Eclipse Workspace), может иметь свой проверяемый в любое время статус, с помощью интерфейса указывающего на все потенциальные исходящие Наборы изменений (работу, которую пользователь хочет Доставить), а также входящие Наборы изменений (работа, которая выполнена другими членами команды). Пользователи имеют возможность выбрать Наборы изменений либо для Доставки (Наборы изменений становятся доступными для всех членов команды), либо для Принятия (применение Наборов изменений в Поток в свои Рабочие пространства Репозитория и Личное) на индивидуальной основе. Базовые линии (Baselines) для Компонентов также можно создавать, и набор Базовых линий для нескольких Компонентов называется Снимком (Snapshot). Его не следует путать со Статическим представлением в ClearCase, т.к. эти понятия совершенно различны.

Есть ряд тонких различий в том, как системы работают, и это отражается на механизмах взаимодействия пользователей с этими системами. В ClearCase пользователи часто создают Потоки и Ветви для изолирования своей работы. Часто пользователи создают несколько Представлений (рабочих пространств), и один набор изменений выполняется в своем Представлении. С помощью этого изменения могут быть изолированы друг от друга, и обеспечивается отсутствие зависимостей артефактов создаваемых между Наборами изменений. В Jazz пользователь выполняет одно изменение в одно время, в рамках своего Локального рабочего пространства. Пользователи, работающие с несколькими изменениями, имеют выбор, они могут либо создать несколько Локальных рабочих пространств и Рабочих пространств Репозитория или они могут Приостановить (Suspend) работу над одним Набором изменений прежде чем приступить к другим. Возможность Приостановить работу по существу принимает все изменения, связанные с Набором изменений, и сохраняет их в Репозитории, после этого пользователь может Возобновить (Resume) (или вернуться) к этим изменениям в дальнейшем. Рабочее пространство при этом возвращается в состояние, в котором оно находилось, когда был применен предыдущий Набор изменений. Это помогает сократить количество Рабочих пространств, которые разработчику нужно поддерживать.

При использовании ClearCase с ClearQuest и UCM можно связывать с Запись ClearQuest (ClearQuest Record) с Набором изменений. Это требует некоторой настройки и доступности Репозитория ClearCase (VOB) и базы данных CQ. В Jazz/RTC вся эта информация находится в том же хранилище, тут связь создается между Рабочими элементами (Work Item) и Набором изменений. Так как все это построено на основе REST, различные типы объектов Jazz могут быть связаны друг с другом, обеспечивая большую гибкость в связях между артефактами разработки.

Понятие ClearCase	Эквивалент Jazz	Описание
Check Out/Check In	Check In	Регистрация изменений в Репозиторий
Activity	Change Set	Собирает набор изменений файлов в один пакет изменений, обычно связанных с Записью CQ/Рабочим элементом
VOB	Jazz Repository	Хранит данные в системе управления версиями – один Jazz Репозиторий, несколько VOB-ов
Dynamic View	n/a	Виртуальное рабочее пространство, содержание которого является динамическим
View Storage	Repository Workspace	Это не очень хорошее сравнение для Рабочего пространства Репозитория, но хранилище представления на сервере представлений приблизительно похоже
Snapshot View	Sandbox/Eclipse Workspace	Рабочее пространство, основанное на копировании, используется для разработки
Updating	Synchronizing/Accept	Обновление рабочего пространства пользователя, когда изменения от других членов команды загружаются в личное рабочее пространство пользователя
Deliver	Deliver	Продвижение набора изменений из рабочей области в поток, где они становятся общими для всей команды
Rebase	Accept	Изменения, выполненные другими членами команды, загружаются в личный рабочий поток пользователя
Reserved Check Out	Locked	Возможность «зарезервировать» ресурс, вы будете являться единственным пользователем, который может изменить ресурс
Baseline	Baseline	Набор файлов (конфигурация) в рамках компонента в определенный момент времени
Composite Baseline	Snapshot	Набор различных компонентов, а также конкретная базовая линия в этих компонентах
UCM	Process Templates (как Scrum)	Стандартно поставляемый процесс, который определяет типы записей/рабочих элементов, связи и процессы, связанные с ними
Stream/Branch	Stream	Логическое «разделение» кода, обеспечивающее параллельную разработку и изоляцию
Merge	Merge	Взятие версий одного и того же файла в двух различных ветвях и сопоставление изменений, внесенных в эти файлы
n/a	Suspend/Resume	Возможность временного хранения или восстановления изменений, сделанных в рабочем пространстве, чтобы вернуть рабочее пространство в некоторую известную конфигурацию

Дополнительная информация

• Basic SCM functionality – быстрый обзор базовой функциональности SCM
• Confessions of a new Jazz developer, Part 2: Getting things done – сценарий «один день из жизни разработчика» с RTC и Jazz
• Implementing the «Remote Development Line» pattern using Jazz SCM – более ранняя статья о возможностях распределенной разработки с Jazz SCM
• Working on the SCM Command Line – ссылка на документацию по командной строке SCM.
• Jazz Administration Guide
• Jazz Deployment Guide

Об авторе

Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.

Сравнение концепции ClearQuest и Rational Team Concert

Оригинал: Comparing concepts between ClearQuest and RTC

Основная терминология

Давайте начнем с некоторых основных терминов и сравнения с ClearQuest. В ClearQuest у Вас есть понятие Тип записи. Типы записей определяют различные типы для записей, которые Вы можете иметь в ClearQuest. Они могут без состояний или с состояниями. Каждый Тип записи имеет несколько Полей, и эти Поля могут быть различных типов (например, перечисление, текст, числовой и т.д.). Поля могут быть обязательными или необязательными, и они часто используются, чтобы помочь классифицировать работы. Они также могут быть связаны друг с другом. Записи с состояниями используются для моделирования технологического процесса разработки ПО организации. Весь набор этих различных Типов записей, а также перечисляемые данные, используемые как значения для списков, представляют собой то, что обычно называют схемой ClearQuest. CQ схемы могут быть экспортированы и импортированы, но формат информации специализирован и является проприетарным. Когда пользователи взаимодействуют с системой, они создают CQ записи, которые являются экземплярами типов с данными, специфичными для некоторых запросов на изменение или выполняемой работы.

В Rational Team Concert (RTC) у нас есть Шаблон процесса, который используется, чтобы устанавливать структуры и операции RTC. В RTC у нас есть Типы рабочих элементов, которые эквиваленты Типам записей в ClearQuest. Рабочий элемент всегда имеет связанную с ним модель состояний, тут не существует понятия типа без состояний. Рабочий элемент Jazz имеет Атрибуты, которые эквиваленты Полям в ClearQuest. Это все определяется в процессе, который используется проектом. Когда проект RTC инициируется, он использует Шаблон процесса для определения Типов рабочих элементов. Это определяет их модели Жизненного цикла и состояний, их Атрибуты, а также различные процессные операции, которые воздействуют на эти Рабочие элементы (об этом будет немного подробнее). Все это делается на основе пользовательского интерфейса по типу «указать и нажать». Выполненные выборки и конфигурации этого интерфейса хранятся в виде XML представления этого процесса. Это представление может быть использовано для создания новых Шаблонов процессов для других проектов. Когда пользователи взаимодействуют с системой, они создают Рабочие элементы, которые являются экземплярами типов с данных, специфичных для некоторых запросов на изменение или выполняемой работы.

В ClearQuest Жизненный цикл можно охарактеризовать как ряд состояний. Отдельные переходы записей между этими состояниями выполняется с помощью ряда действий. В RTC понятия состояния и действия те же, действия используются для перехода между различными определенными состояниями. Но далее RTC и ClearQuest начинают немного отличаться. ClearQuest позволяет пользователям просматривать различные хранящиеся записи (данные) в виде отчетов, результатов запроса или диаграмм на основе результатов запроса. Форматы этих отчетов могут быть встроенными, поставляться вместе с продуктом, но часто настраиваются и определяются в Crystal Reports. RTC позволяет пользователям просматривать различные хранящиеся рабочие элементы (данные) в виде отчетов, результатов запроса или диаграмм на основе результатов запроса. Форматы отчетов могут быть встроенными, поставляться вместе с продуктом, но они настраиваются и определяются с помощью BIRT. Он также представляет эту информацию в виде Планов. План показывает Рабочие элементы (данные) в формате, который может использоваться для планирования и мониторинга хода спринта или итераций. Отдельные Планы могут быть представлены как окна на те же данные, но которые просто показывают их по-другому. Разница между отчетами и графиками является еще одним примером представления тех же данные в разных форматах.

ClearQuest поддерживает историю переходов CQ записей, и большинство пользователей могут использовать возможности Audit Trail в ClearQuest. Данные и отчеты истории строятся с использованием данных из отдельных записей истории. В RTC Рабочие элементы имеют свою историю с полным отслеживанием изменения полей и состояний. Еще одно дополнительное свойство, RTC собирает эти данные в свое внутренние хранилище данных в разрезе времени, получая и накапливая данные из Рабочих элементов. Это хранилище данных используется для получения данных для всех ориентированных на время отчетов и графиков отображаемых в RTC. Таким образом, когда просматривается отчет за период времени (например, диаграммы выполнения работы), данные, которые отображаются, поступают из хранилища данных RTC. Это наиболее значительная разница между RTC и ClearQuest с точки зрения основных функции представления данных.

Настройка процесса

Итак, что можно сказать о настройке и бизнес-логике процесса? При использовании ClearQuest, пользователи более активно реализуют бизнес-логику на основе «Хуков» написанных в Perl или Visual Basic, Perl является более популярным. Хук связан с определенными событиями, которые происходят с CQ записью или с одним из его Полей. Существует широкий набор API вызовов, которые позволяют разработчику схемы выполнять различные операции для этих CQ записей и Полей. В RTC возможность изменить поведение Рабочих элементов и Атрибутов основывается на встраивании в модель безопасности (которую также можно настроить), а также существует ряд это общих операций, которые клиенты часто выполняют. Они представляются в виде набора операционного поведения и параметров, которые разработчик Шаблона процесса может изменять. Для тех вещей, которые еще не доступны в инструменте, разработчики Шаблон процесса могут писать расширения на любом языке, Java является наиболее популярным. Существует богатый API и SDK, с которыми можно взаимодействовать и использовать для манипулирования Рабочими элементами и их Атрибутами, например, показать руководство пользователя и сообщения об ошибках.

Следующий выпуск RTC содержит дополнительную функциональность, которая должна закрыть некоторые пробелы между RTC и ClearQuest, а также предоставит дополнительные возможности. Вы можете прочитать об этом в разделах M4 New and Noteworthy и M7 New and Noteworthy.

Небольшой обзор того, что было сказано:

Концепт ClearQuest	Эквивалент RTC	Что оно делает
CQ схемы	Шаблон процесса	Определяет процесс и как инструмент предоставляет процесс
Жизненный цикл	Жизненный цикл	Модель состояний, которая определяет направления и переходы артефакта
CQ тип записи	Тип рабочего элемента	Определяет тип объекта для хранения данных с его собственной моделью состояний, определенными полями, а также представлением данных
CQ запись	Рабочий элемент	Экземпляр типа записи / типа рабочего элемента, с его собственными уникальными данными
CQ поле	Атрибут	Одно из полей ввода данных, часть записи и рабочего элемента
Хук	Расширение	Код, направленный на более гибкую реализацию
CQ база данных	Репозиторий	Где хранится информация
Не применимо	Планы	Различные представления или визуализация данных текущих рабочих элементов, полезных при планировании проектов

Дополнительная информация

• Getting Started with Work Items — a tutorial that provides an introduction to RTC work items
• Work Item customization in RTC — a guide showing you many of the different ways that work items can be customized with RTC
• Work item editor presentations — a guide on how to modify how your work item data is presented to the RTC user
• Work Item attribute providers — one of the ways to customize Jazz choice lists.
• Jazz Administration Guide
• Jazz Deployment Guide

Об авторе

Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.