Администрирование и безопасность
Давайте сначала рассмотрим последнюю из ключевых областей функциональных возможностей ClearQuest ALM, а именно функции администрирования и обеспечения безопасности.
ALM-решение поставляется с набором системных параметров (рисунок 1), которые позволяют изменить решение таким образом, чтобы его можно было встроить в систему организации, не изменяя базовую схему. Эти параметры позволяют использовать существующий глоссарий для определения объектов в системе, причем вследствие системного характера параметров этот глоссарий смогут использовать все пользователи системы.
Рисунок 1. Системные параметры
Политики безопасности определяются путем добавления одной или более групп ClearQuest в запись ALM Security Policy (Политика безопасности). После того как политики безопасности настроены, проект-менеджеры смогут спокойно создавать новые проекты и выбирать политики безопасности, необходимые для этих проектов. При этом в привлечении администраторов нет никакой необходимости. Если понадобится новая политика, то для ее создания достаточно просто определить новую политику безопасности, как показано на рисунке 2.
Рисунок 2. Создание политики безопасности
Если всем членам коллектива разработчиков разрешено просматривать все записи в базе данных, то можно создать одну политику безопасности для группы Everyone (Все). В результате вся система остается открытой для всех сотрудников этой рабочей группы. Это самый простой способ приступить к работе. Однако по мере возникновения более серьезных требований к безопасности можно создать новые политики безопасности для ограничения доступа. Например, можно создать группу, представляющую стороннего поставщика, которому разрешено видеть только те проекты, над которыми он работает. В эту группу добавляются все пользователи этого поставщика. Мы создаем политику безопасности и добавляем к ней группу пользователей стороннего поставщика. Затем данная политика безопасности назначается для всех проектов, с которыми работает этот поставщик. Члены этой группы не имеют информации об остальных записях в системе кроме тех, которые разрешаются их политикой безопасности.
Запись Admin используется для того чтобы определить, кому из пользователей разрешается изменять системные параметры. Это дает возможность разрешить надежным руководителям проектов изменять системные параметры (например, стандартные имена и деревья категорий). Это также не вносит изменений в базовую схему, зато обеспечивает руководителям проекта больше свободы и гибкости в адаптации решения к имеющейся рабочей среде.
Мы уже говорили о категориях в части 1 данной серии; сейчас важно отметить, что записи CategoryTypeLabel доступны на системном уровне. Для категорий можно задать политику безопасности и тем самым сделать их доступными или скрыть от определенных пользователей. Благодаря этому мы получаем возможность многократного использования и согласованной классификации категорий в нескольких проектах.
Категории и Типы категорий позволяют моделировать системы классификации для проектов. Категории могут быть иерархическими (рисунок 3), что позволяет разбить крупные системы на более мелкие и более управляемые модули.
Рисунок 3. Два дерева категорий - одно для проекта, другое для сервисов
Чтобы упростить создание записей Request и Task, в записи Catеgory в секции "Current Project" (Текущий проект) можно указать имя проекта. При создании новой записи Request или Task и выборе категории поле проект будет заполнено автоматически. На рисунке 4 показана запись Category. Секция Current Project выделена.
Рисунок 4. Запись Category. Секция Current Project выделена
Запись Type используется для идентификации характера задания. Типы применяются к записям Request, Task и Activity и настраиваются для всей системы. Проектные группы могут конфигурировать используемые типы путем создания записи Work Configuration (рисунок 5).
Рисунок 5. Запись Type
Запись Type не отличается сложностью. Выберите ALMRecordType, затем выберите или создайте TypeLabel. Добавлять описание в поле Description не обязательно. Некоторые (но далеко не все) примеры типов: Enhancement (Усовершенствование), Defect (Дефект), New Feature (Новая функция) и т. д.
Стандартные имена (запись Label)
Существует много примеров, когда для организации проектов и руководства ими необходима стандартизация на уровне всей организации, однако у нас редко бывают инструменты, позволяющие добиться такой согласованности. С появлением записи Label (Стандартное имя) мы получили возможность определить набор имен, которые будут отображаться в пользовательском интерфейсе, чаще всего в виде раскрывающегося списка в диалоговом окне записи. Здесь мы рассмотрим каждый из новых типов таких стандартных имен и предложим некоторые рекомендации по их использованию.
Большинство записей Labels состоит из полей Name (Имя) и Description (Описание), как показано на рисунке 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). Затем выберите типы записей, которые должны использоваться в данной интеграции.
Рисунок 7. Применение пакета RequisitePro к существующей схеме ClearQuest
Выбор типов записей зависит от того, как вы планируете управлять требованиями. Очень часто к нескольким проектам можно применить одно требование, в этих случаях рекомендуется активировать запись ALMRequest. Альтернативный вариант заключается в активации записей ALMTask или ALMActivity. В соответствующую запись добавляется вкладка requirements, позволяющая ассоциировать с записью требования RequisitePro. Записи ALMRequests будут содержать контекст, "обнаруженный в проекте", и ссылку на требование (требования). Записи ALMTasks будут удовлетворять запросы в контексте одного или более проектов.
Деятельность ALMActivity - это то же самое, что Деятельность UCM (Unified Change Management, унифицированная система управления изменениями). Отличие от ALM-решения заключается в том, что определение "деятельности" было расширено за счет включения единицы работы для любого члена рабочей группы. Это означает, что все типы ALM-деятельностей ALMActivity (рисунок 8) задействованы в UCM.
Рисунок 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) совместно используют одни и те же атрибуты для обеспечения функциональной совместимости;
Рисунок 9. Функциональная совместимость между деятельностью ALMActivity и элементами заданий Rational Team Concert
- Элементы заданий в Rational Team Concert, которые имеют дочерние элементы заданий или элементы заданий типа Task (Задача) и Задачи ALMTask (рисунок 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 7.1.0.0 предоставляет новую схему с именем ALM, которую можно использовать, чтобы начать управление рабочей группой.
ALM-записи предоставляются в виде двух пакетов, ALMProject и ALMWork. Эти пакеты можно применить к существующей схеме, не создавая помех работе текущих рабочих групп и не оказывая влияния на типы записей. Имена всех записей имеют префикс "ALM", который помогает отличить их от других записей в вашей текущей схеме. Кроме того, предоставляется ряд рекомендаций, позволяющих безопасно изменять пакеты, не лишая себя возможности получать обновления в будущем.
Пример базы данных предназначен для того чтобы помочь вам начать работать с новой схемой. Настоятельно рекомендуем начать с этой учебной базы данных, чтобы на практике познакомиться с новыми записями и их взаимосвязями.
Пример базы данных и набор импортируемых файлов построены на использовании процесса OpenUP (Open Unified Process, открытый унифицированный процесс), который представляет собой учебный процесс в проекте Eclipse Process Framework. OpenUP - это адаптация процесса RUP для динамичных коллективов.
Версию "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, тем самым сократив затраты на приобретение и предоставив своим сотрудникам возможность работать в соответствии с их потребностями.