Управление жизненным циклом приложения при помощи ClearQuest 7.1.0.0, часть 3

Из журнала Rational Edge. Предлагаемое описание концепций и задач, лежащих в основе готового решения по управлению жизненным циклом приложений (appication lifecycle management, ALM) для IBM Rational ClearQuest, является прекрасной иллюстрацией преимуществ использования ClearQuest и пакета ALM в качестве решения для управления изменениями (change management, CM). В данной, третьей статье серии мы расскажем об администрировании и требованиях к безопасности и предложим ряд советов по поводу того, как приступить к работе и интегрировать ClearQuest ALM в рабочую среду. Из журнала The Rational Edge.

Кэролин Пампино, разработчик архитектуры решений в рабочей группе Rational Green Threads, IBM

Кэролин Пампино (Carolyn Pampino) является разработчиком архитектуры решений в рабочей группе Rational cross-product Green Threads; в настоящее время занимается, главным образом, вопросами управления жизненным циклом территориально рассредоточенных приложений. Она принимала участие в приобретении компании Build Forge, исполняя обязанности менеджера по управлению продукцией во время переходного периода. Кроме того, она участвовала в разработке решений и стратегий, связанных с интеграцией портфеля Tivoli. До IBM Кэролин работала директором по управлению, разработке продукции и конкурентной разведке в компании BroadVision, Inc, возглавляя территориально рассредоточенный коллектив. До BroadVision она занимала должность директора по разработке в компании Interleaf и была членом группы, которая занималась подготовкой компании Interleaf к переходу в собственность компании BroadVision. Кэролин с отличием закончила университет Карнеги-Меллона (Carnegie-Mellon University).



Роб Пирс, разработчик консультационной информации, ClearTeam Group, IBM

Роб Пирс (Rob Pierce) получил ученую степень в области компьютерного программирования в 1982 г., затем несколько лет с успехом занимался бегом на длинные дистанции (включая два марафона на Кубок Мира), прежде чем посвятить себя карьере технического документирования. В настоящее время он документирует IBM Rational ClearQuest API Reference (справочник по программному интерфейсу приложения IBM Rational ClearQuest) и Schema Developer role-based Help (помощь в разработке схем на основе ролей), а также Rational Team API. Он также работает в компании IBM и является членом совета IBM Software Group Councils в области разработки информации (ID), фокусирующейся на дизайне и разработке ID-процессов, включая работу над поддержкой для улучшения взаимодействия и целостности информации.



06.03.2009

illustrationЭта статья, состоящая из трех частей, представляет собой описание концепций и проектных задач готового решения для управления жизненным циклом приложений (application lifecycle management, ALM) для IBM® Rational® ClearQuest®. В первой части статьи мы продемонстрировали преимущества использования ClearQuest и пакета ALM в качестве решения для управления изменениями (change management, CM) и рассказали о проектных целях и основных концепциях, относящихся к ALM-схеме в ClearQuest. Во второй части статьи мы рассказали о решении ClearQuest ALM и о концепции взаимодействия пользователя с программой на основе ролей, которая в равной степени относится и к управлению изменениями в контексте разработки продуктов IBM Rational, и к сценариям использования ClearQuest потребителями.

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

Администрирование и безопасность

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

Системные настройки

ALM-решение поставляется с набором системных параметров (рисунок 1), которые позволяют изменить решение таким образом, чтобы его можно было встроить в систему организации, не изменяя базовую схему. Эти параметры позволяют использовать существующий глоссарий для определения объектов в системе, причем вследствие системного характера параметров этот глоссарий смогут использовать все пользователи системы.

figure 1

Рисунок 1. Системные параметры

Политика безопасности

Политики безопасности определяются путем добавления одной или более групп ClearQuest в запись ALM Security Policy (Политика безопасности). После того как политики безопасности настроены, проект-менеджеры смогут спокойно создавать новые проекты и выбирать политики безопасности, необходимые для этих проектов. При этом в привлечении администраторов нет никакой необходимости. Если понадобится новая политика, то для ее создания достаточно просто определить новую политику безопасности, как показано на рисунке 2.

figure 2

Рисунок 2. Создание политики безопасности

Если всем членам коллектива разработчиков разрешено просматривать все записи в базе данных, то можно создать одну политику безопасности для группы Everyone (Все). В результате вся система остается открытой для всех сотрудников этой рабочей группы. Это самый простой способ приступить к работе. Однако по мере возникновения более серьезных требований к безопасности можно создать новые политики безопасности для ограничения доступа. Например, можно создать группу, представляющую стороннего поставщика, которому разрешено видеть только те проекты, над которыми он работает. В эту группу добавляются все пользователи этого поставщика. Мы создаем политику безопасности и добавляем к ней группу пользователей стороннего поставщика. Затем данная политика безопасности назначается для всех проектов, с которыми работает этот поставщик. Члены этой группы не имеют информации об остальных записях в системе кроме тех, которые разрешаются их политикой безопасности.

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

Категория

Мы уже говорили о категориях в части 1 данной серии; сейчас важно отметить, что записи CategoryTypeLabel доступны на системном уровне. Для категорий можно задать политику безопасности и тем самым сделать их доступными или скрыть от определенных пользователей. Благодаря этому мы получаем возможность многократного использования и согласованной классификации категорий в нескольких проектах.

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

figure 3

Рисунок 3. Два дерева категорий – одно для проекта, другое для сервисов

Чтобы упростить создание записей Request и Task, в записи Catеgory в секции "Current Project" (Текущий проект) можно указать имя проекта. При создании новой записи Request или Task и выборе категории поле проект будет заполнено автоматически. На рисунке 4 показана запись Category. Секция Current Project выделена.

figure 4

Рисунок 4. Запись Category. Секция Current Project выделена

Запись Type

Запись Type используется для идентификации характера задания. Типы применяются к записям Request, Task и Activity и настраиваются для всей системы. Проектные группы могут конфигурировать используемые типы путем создания записи Work Configuration (рисунок 5).

figure 5

Рисунок 5. Запись Type

Запись Type не отличается сложностью. Выберите ALMRecordType, затем выберите или создайте TypeLabel. Добавлять описание в поле Description не обязательно. Некоторые (но далеко не все) примеры типов: Enhancement (Усовершенствование), Defect (Дефект), New Feature (Новая функция) и т. д.

Стандартные имена (запись Label)

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

Большинство записей Labels состоит из полей Name (Имя) и Description (Описание), как показано на рисунке 6.

figure 6

Рисунок 6. Пользовательский интерфейс записей Label

Записи Label для перечисленных ниже стандартных имен создаются и совместно используются в пределах экземпляра базы данных:

  • Стандартное имя типа категорий (Category Type Label). Категории представляют собой эффективное средство классификации проектов, тем не менее определяя категории, вы обнаружите, что неплохо бы иметь более одного "дерева" категорий. Запись Category Type Label как раз и предоставляет вам эту возможность. Определив более одного типа категорий, вы сможете создавать иерархии категорий, принадлежащих к разным типам. Например, можно определить такие типы категорий как Solution (Решение), Product (Продукт), SOA Service (SOA-сервис), Re-Usable Component (Компонент многократного использования), Business Unit (Бизнес-подразделение) и т. д.;
  • Стандартное имя фазы (Phase Label)) и Стандартное имя итерации (Iteration Label). Многие процессы, в том числе, унифицированный процесс Rational (IBM Rational Unified Process®, RUP®) рекомендуют разбивать проекты на фазы, причем каждая фаза может иметь одну или более итераций. Такая практика помогает разбить проект на более удобные в управлении модули. Например, RUP предлагает следующие стандартные имена для фаз: Inception (начальная фаза), Elaboration (фаза уточнения), Construction (фаза конструирования) и Transition (фаза передачи). Итерация представляет собой планируемый, ограниченный во времени интервал, обычно измеряемый неделями. Итерации ориентируют коллектив на поставку постепенно возрастающей экономической ценности заинтересованным лицам предсказуемым образом. При помощи стандартных имен фаз и итераций можно обеспечить согласованное применение терминологии во всей организации. В динамичных коллективах фаза может считаться контрольной точкой;
  • Стандартное имя релиза (Release Label). Стандартные имена релизов используются для идентификации "версии" разрабатываемого программного обеспечения. В некоторых организациях порядок назначения имен или номеров версий стандартизуется. Используйте это поле для идентификации Стандартного имени релиза, которое будет использоваться другими специалистами организации. Например, в IBM для всех продуктов принят стандарт на схему назначения номеров версий, состоящих из четырех цифр, например, ClearQuest 7.1.0.0;
  • Стандартное имя резолютивного кода (Resolution Code Label). После выполнения единицы работы ей присваивается резолютивный код для описания истории и контекста данного типа резолюции. Например, в проекте выполнены не все задания. Иногда мы сталкиваемся с дублирующими Запросами или невозможностью воспроизведения проблемы, о которой сообщается в отчете, т.е. все работает в соответствии с проектом. Можно определить набор резолютивных кодов, которые будут использоваться во всей организации;
  • Стандартное имя роли (Role Label). Стандартные имена ролей помогают добиться согласованного использования ролей во всей организации. Примеры стандартных имен ролей – Analyst (Аналитик), Architect (Разработчик архитектуры), Project Manager (Проект-менеджер), Developer (Разработчик) и Tester (Тестировщик);
  • Стандартные имена состояний (Status Label). Стандартные имена состояний используются для обозначения состояния проекта. Они отображаются в записях Project, Phase и Iteration. Примеры: Healthy (Нормальное), Suspect (Сомнительное) и Critical (Критическое). В некоторых организациях используется цветовое кодирование, например "Зеленый" (вместо нормальный), "Желтый" (вместо сомнительный) и "Красный" (вместо критический);
  • Стандартное имя типа задания (Work type label). Запросы, Задачи и Деятельности могут быть разными в разных организациях, поэтому в каждой из этих записей предусмотрен раскрывающийся список Type. Имена, отображаемые в этом списке, взяты из записи Work Type. Сначала определяют запись Work Type Label. Это просто имя данного типа, например, "Enhancement." Затем для объединения типа записи с данным стандартным именем используется запись Work Type. Пример: тип записи Request с именем "Enhancement".

Интеграции и сосуществование

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

Управление требованиями при помощи IBM Rational RequisitePro

Многие организации используют IBM Rational Rational RequisitePro® для управления требованиями, а ClearQuest – в качестве системы управления изменениями в коллективах разработчиков. Между тем, решения RequisitePro и ClearQuest уже интегрированы между собой. При помощи ClearQuest Designer примените пакет RequisitePro к вашей схеме, если это не было сделано ранее (рисунок 7). Затем выберите типы записей, которые должны использоваться в данной интеграции.

figure 7

Рисунок 7. Применение пакета RequisitePro к существующей схеме ClearQuest

Выбор типов записей зависит от того, как вы планируете управлять требованиями. Очень часто к нескольким проектам можно применить одно требование, в этих случаях рекомендуется активировать запись ALMRequest. Альтернативный вариант заключается в активации записей ALMTask или ALMActivity. В соответствующую запись добавляется вкладка requirements, позволяющая ассоциировать с записью требования RequisitePro. Записи ALMRequests будут содержать контекст, "обнаруженный в проекте", и ссылку на требование (требования). Записи ALMTasks будут удовлетворять запросы в контексте одного или более проектов.

По поводу UCM

Деятельность ALMActivity – это то же самое, что Деятельность UCM (Unified Change Management, унифицированная система управления изменениями). Отличие от ALM-решения заключается в том, что определение "деятельности" было расширено за счет включения единицы работы для любого члена рабочей группы. Это означает, что все типы ALM-деятельностей ALMActivity (рисунок 8) задействованы в UCM.

figure 8

Рисунок 8. ALM -Деятельности задействованы в UCM

Обратите внимание на показанную выше вкладку Unified Change Management в записи ALMActivity. Это дополнительный параметр для рабочих групп, использующих UCM.

Инструмент Rational Team Concert

Для небольших динамичных коллективов доступна программа IBM Rational Team Concert Express.1 Когда потребители других продуктов Rational выполняют развертывание и ввод в эксплуатацию инструмента Rational Team Concert, возникает вопрос функциональной совместимости. Для этого инструмента доступны специальные коннекторы, обеспечивающие функциональную совместимость с IBM Rational ClearCase® и ClearQuest.

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

  • Задание (Work). Коннекторы ClearQuest обеспечивают возможность создать запись в одной базе данных и получить ее отображение в другой. Это позволяет изменять данную запись пользователями обеих систем. Возможны следующие варианты:
  • Элемент задания (Work item) и ALM-Деятельность (ALMActivity) совместно используют одни и те же атрибуты для обеспечения функциональной совместимости;

figure 9

Рисунок 9. Функциональная совместимость между деятельностью ALMActivity и элементами заданий Rational Team Concert

  • Элементы заданий в Rational Team Concert, которые имеют дочерние элементы заданий или элементы заданий типа Task (Задача) и Задачи ALMTask (рисунок 10);

figure 10

Рисунок 10. Функциональная совместимость между ALMTask и иерархическими элементами заданий (элементами заданий типа Task) в Rational Team Concert

  • Запросы ALM можно представить двумя способами. С одной стороны, Запрос типа Дефект можно сопоставить элементу задания типа Дефект. C другой стороны, возможно, вы считаете, что Запросы больше похожи на требования и не найдете здесь прямой аналогии;
  • Проект. Проекты используются и в Rational Team Concert, и в ClearQuest. Необходимо только вручную согласовать их имена;
  • Категория. Деревья категорий используются и в Rational Team Concert, и в ClearQuest. Здесь также требуется согласование вручную;
  • Роль. Определения ролей существуют как в Rational Team Concert, так и ClearQuest. Здесь также требуется согласование вручную.

Начало работы

Мы рассказали о функциональных возможностях решения ClearQuest ALM и его месте среди других продуктов Rational; теперь можно предложить несколько идей по поводу внедрения ClearQuest ALM в вашей организации.

Схема и пакеты ClearQuest

ClearQuest 7.1.0.0 предоставляет новую схему с именем ALM, которую можно использовать, чтобы начать управление рабочей группой.

ALM-записи предоставляются в виде двух пакетов, ALMProject и ALMWork. Эти пакеты можно применить к существующей схеме, не создавая помех работе текущих рабочих групп и не оказывая влияния на типы записей. Имена всех записей имеют префикс "ALM", который помогает отличить их от других записей в вашей текущей схеме. Кроме того, предоставляется ряд рекомендаций, позволяющих безопасно изменять пакеты, не лишая себя возможности получать обновления в будущем.

Пример базы данных OpenUP

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

Пример базы данных и набор импортируемых файлов построены на использовании процесса OpenUP (Open Unified Process, открытый унифицированный процесс), который представляет собой учебный процесс в проекте Eclipse Process Framework. OpenUP – это адаптация процесса RUP для динамичных коллективов. Загружаемые файлы OpenUP можно получить по следующим адресам: http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

Версию "published" можно просматривать через Web-браузер, весь ее контент сохраняется на локальном жестком диске.

В этот пример базы данных уже включены стандартные имена, типы заданий, конфигурации заданий и запросы. Кроме того, предусмотрен пример проекта. Процессы OpenUP отображаются на записи ALM Task и Activity, чтобы проиллюстрировать внедрение процесса в управляемые проекты при помощи ClearQuest.

Мы планируем познакомить вас с примером базы данных и проектом OpenUP в одной из следующих статей в журнале The Rational Edge.

Заключение

Новая схема ALM в Rational ClearQuest 7.1.0.0 представляет собой готовый набор компоновочных блоков для проектных групп, который можно настраивать в соответствии с существующими в данных коллективах культурными традициями и процессами. Она избавляет администраторов ClearQuest от необходимости редактировать схему и в то же время позволяет руководителям проектов настраивать систему в соответствии с собственными потребностями.

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

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

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

Уменьшается также потребность в создании обучающих материалов. Вы можете использовать как основу справку в режиме онлайн, учебные руководства, пример базы данных и статьи (аналогичные данной) на Web-сайте IBM developerWorks.

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

Кроме того, ClearQuest ALM может в значительной степени расширить ваши возможности по управлению проектом разработки. Управляя распределением работы между всеми пользователями в рабочей группе, вы можете выполнять запросы, генерировать отчеты и диаграммы, помогающие создать более углубленное, чем до сих пор, представление о состоянии работ по проекту. В первое время ваше руководство внутренним процессом (например, вашей адаптированной версией RUP) может получить практическое значение за счет реализации основных концепций в ролях, типах, и конфигурациях заданий.

Схема и пакеты ALM предоставляют масштабируемое решение для рабочих потоков, которое аккумулирует в себе передовые методы проектирования процессов разработки программного обеспечения. Благодаря этому обеспечивается солидное основание для управления проектами разработки и гибкость в настройке каждого проекта. Внедрите решение ClearQuest 7.1.0.0 ALM, тем самым сократив затраты на приобретение и предоставив своим сотрудникам возможность работать в соответствии с их потребностями.

Благодарности

Особая благодарность всем, кто потратил время на создание и редактирование данной статьи, отдав этому частичку своих способностей. В алфавитном порядке: Кеннет Гиффелс (Kenneth Giffels), Роберт У. Майерс (Robert W. Myers), Майкл Дж. Сейлор (Michael J. Saylor), Рик Уивер (Rick Weaver).

Примечания

  1. Более подробную информацию можно найти на сайте: http://www.ibm.com/developerworks/rational/library/08/0212_miller/index.html

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=374537
ArticleTitle=Управление жизненным циклом приложения при помощи ClearQuest 7.1.0.0, часть 3
publish-date=03062009