Управление жизненным циклом приложения при помощи ClearQuest 7.1.0.0

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

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

Управление изменениями на протяжении всего жизненного цикла приложения

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

Как показано на рисунке 1, фундаментальный принцип ALM заключается в содействии процессам разработки программного обеспечения, которые на протяжении процессов объединяют множество ролей, и в управлении всем контентом, который создается каждой ролью в ходе работы. Члены рабочей группы в обеспечении своей деятельности по разработке опираются на пять принципов. Они должны: 1) участвовать в совместной работе коллектива; 2) обеспечить трассируемость своего задания до исходного запроса; 3) автоматизировать нетворческие, повторяющиеся задачи; 4) стараться найти стратегии для непрерывного совершенствования и 5) если коллектив является рассредоточенным, обеспечить надежное подключение к цепочке поставки программного обеспечения.

Рисунок 1. ALM координирует деятельность разработчиков для создания активов, из которых будет строиться ПО

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

Рисунок 2. Всего один запрос (одно новое требование) может затронуть всех членов коллектива разработчиков программного обеспечения

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

Управление жизненным циклом приложений в ClearQuest

Rational ClearQuest 7.1.0.0 включает готовое ALM-решение, которое предоставляет поддержку решения многих проблем, связанных со средствами GDD и ALM. Пакет ALM поддерживает рационализированный, динамичный процесс разработки приложений, который одновременно является ориентированным на роли и управляемым процессами, как показано на рисунке 3. Проекты определяют контекст выполнения заданий; их безопасность можно обеспечить через определение политик безопасности и ролей. Работа может быть распределена между членами коллектива, которые находятся в одном месте или в разных местах. Кроме того, работа является трассируемой до исходного запроса и до проекта, который реализуется по этому запросу.

Рисунок 3. ClearQuest ALM поддерживает ориентированные на роли процессы разработки.

Описание и проектные задачи

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

• 100-процентная полезность для будущих и нынешних потребителей ClearQuest.
• Предоставление решения, которое является масштабируемым от небольших коллективов до организаций корпоративного уровня.
• Поддержка территориально рассредоточенных коллективов разработчиков Поддержка, но не обязательное требование, технологий multisite и UCM.
• Поставка в составе ClearQuest v7.1 в виде набора пакетов и схемы Возможность применения ALM-пакетов в ClearQuest 7.0.1.
• Снижение затрат клиентов на владение и улучшение показателей возврата инвестиций.
• Предоставление 70% функциональности без дополнительной настройки.
• Сокращение времени на разработку не менее, чем на 50%.
• Сокращение объема административных изменений (необходимо для поддержки корпоративных пользователей).
• Перестройка проекта в связи с назначением руководителей и сотрудников не оказывает влияния на схему.
• Предоставление основных "компоновочных блоков" для начала работы.
• Предоставление заключающего в себе "передовые методы" и не требующего предварительной настройки механизма работы, который может быть использован "как есть" или дополнен и применен к имеющимся реализациям ClearQuest.
• Обеспечение контекста безопасности для проекта с распределенными по ролям "разрешенными действиями".
• Содействие координации работы коллектива на протяжении всего жизненного цикла разработки коллектива.
• Упрощение возможности поддержки соответствия законодательным инициативам и ведения следов аудита.
• Предоставление готовой базы данных, демонстрирующей поддержку примерного процесса OpenUP из инфраструктуры процессов (Process Framework) Eclipse.

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

Основные понятия

Ниже перечислены основные понятия, которые необходимы для того, чтобы разобраться, когда следует применять AML-схему в ClearQuest:

• Проекты создают контекст для управления заданиями, созданными членами коллектива. Доступ к проектам предоставляется пользователям через политики безопасности, а их действия определяются их ролью.
• Управление заданиями осуществляется в форме требований, задач и деятельностей. Определение деятельностей и задач направляется определениями процесса, которые могут отличаться в разных коллективах.
• Системные параметры могут определяться для проекта и управляемого задания. Эти параметры позволяют учесть многократное использование и согласованную классификацию в нескольких проектах; кроме того, их можно адаптировать к условиям конкретной организации. Обычно они настраиваются раз и навсегда или незначительно изменяются с ростом коллектива и изменениями в использовании системы пользователями. (Администраторам ClearQuest читать с этого места.)

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

Проекты предоставляют ориентированный на роли контекст для работы.

Проекты организуют всю работу в ALM-схеме. Проекты предоставляют контекст, управление доступом и ролевую модель безопасности для работы. Свод знаний по управлению проектами (Project Management Body of Knowledge, PMBOK) определяет "Проект" как временное усилие, предпринимаемое для создания уникального продукта, сервиса или результата. В ALM-системе он является контекстом, в котором выполняется работа, и обеспечивает трассируемость работы, выполняемой на протяжении жизненного цикла проекта программного обеспечения. На рисунке 4 показана схема архитектуры ALM-проекта вместе с объектами, из которых состоит определение проекта, системными параметрами и имеющимися пользователями и администраторами групп ClearQuest.

Рисунок 4. ClearQuest ALM: Концептуальная схема проекта. Проекты организуют всю работу в ALM-схеме. Проекты предоставляют контекст и ролевую модель безопасности для работы.

Далее в разделе рассказывается о записях (record), которые используются для определения проектов.

Обеспечение безопасности проекта

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

.

Рисунок 5. Политики безопасности предоставляют доступ, а роли определяют разрешенные действия

Действия по настройке безопасности, показанные на рисунке 5, можно прокомментировать следующим образом:

1. Создайте пользователей (Users) и группы (Groups). В существующих установках ClearQuest пользователи и группы уже настроены. Для определения политик безопасности необходимо использовать имеющихся пользователей и группы. Для вновь настраиваемых установок ClearQuest необходимо создать пользователей и группы в соответствии с инструкциями в документации ClearQuest.
2. Создайте политики безопасности (Security Policies). Использование политик безопасности относится к основным концепциям в проектировании. Политика безопасности создается для того, чтобы определить, какие пользователи имеют доступ к данному проекту. Для этого достаточно добавить в запись политики безопасности одну или более групп ClearQuest. Для некоторых организаций управление доступом к проекту может не представлять существенной проблемы. В таком случае можно просто создать одну политику безопасности и добавить в нее все группы ClearQuest. Эта политика безопасности будет предоставлять доступ всем пользователям ко всем проектам. Если разграничение доступа к проектам имеет значение, то можно создать политики безопасности, которые будут управлять доступом для отдельных групп. Например, организация, работающая со сторонним поставщиком, может создать политику безопасности для сторонних пользователей, тем самым ограничив их права доступа только теми проектами, которые заданы в политиках безопасности их организаций.
3. Выберите политику безопасности (Security Policy). При создании проекта политику безопасности можно выбрать из раскрывающегося списка. Администраторы могут заранее определить политики безопасности, а затем уполномочить руководителей проектов выбрать ту политику, которая в наибольшей степени применима к их проектам. Политика безопасности может использоваться одним или более проектами. Безопасность настраивается для каждого проекта отдельно и наследуется всеми записями, связанными с этим проектом. Поле Security Policy является обязательным для записи проекта.
4. Создайте категории ролей. Роли используются для того, чтобы определить, какие пользователи или группы могут выполнять конкретные действия по проекту. Во многих случаях в организации имеется утвержденный список названий ролей, например, Аналитик, Разработчик, Разработчик архитектуры и Тестировщик. Роли определяются посредством создания записи ALMRoleLabel.
5. Создайте роли для проекта. Категории ролей могут быть общими во всей организации, а определения каждой конкретной роли могут меняться от проекта к проекту. В каждом проекте определяется, какие роли будут использоваться в проекте и какие пользователи будут выполнять каждую роль, а также разрешенные для этих ролей действия. Определите новые роли для проекта путем создания новой записи ALMRole.

Идентификация и уникальность проекта

С течением времени количество проектов, создаваемых в организации, может значительно возрасти. Характеристики уникальности и идентификации проекта необходимы для того, чтобы идентифицировать проект и отличить его от других проектов. Кроме того, крупные проекты могут подразделяться на более мелкие проекты и иметь одну и ту же версию релиза (Release). Для классификации проектов используют категории, а для идентификации версии ПО, поставляемого по данному проекту, используют релизы. На рисунке 6 показано, какие записи используются для идентификации и классификации проектов.

Рисунок 6. Записи Category и Release определяют уникальность проекта.

Шаги, представленные на рисунке 6, можно описать следующим образом:

1. Создайте дерево категорий (Category Tree) для классификации проектов. Проекты идентифицируются по категории (Category), которая помогает классифицировать продукты, функции или компоненты, поставляемые проектом. В некоторых организациях возникает необходимость в создании более одного дерева категорий. Например, в какой-нибудь организации проекты могут идентифицировать по определенному сочетанию "продуктов" и "сервисов". Типы категорий (Category Types) используются для идентификации схемы классификации. Например, в приведенном выше примере создаются две записи CategoryType, одна для "продуктов", а другая - для "сервисов". Еще примеры: "продукт" и "компонент" или "предложение" и "применение." После того, как типы категорий определены, в этих типах создаются категории. Категории могут быть иерархическими. Сначала создайте тип (CategoryType). Затем создайте категории в этом типе.
2. Создайте идентификаторы релизов (Release labels). Релиз (Release) определяет "версию" ПО. Во многих организациях стандартизируют номенклатуру для идентификаторов релизов. ALM-решение обеспечивает поддержку этой потребности путем предоставления записи Release Label.
3. Выберите категорию (Category). При создании записи для проекта доступные категории отображаются в раскрывающемся списке. Выберите категорию, описывающую проект.
4. Выберите релиз (Release). При создании проекта доступные идентификаторы релизов отображаются в раскрывающемся списке.

Например, в данной статье описывается ALM-схема, поставляемая вместе с ClearQuest 7.1.0.0. Для управления ею мы создаем проект с именем "Out of Box ALM," выбираем категорию "ALM" и релиз "7.1.0.0" (см. рисунок 7). Эти три идентификатора определяют проект. Кроме того, может существовать только один проект с данным сочетанием характеристик. Это гарантирует, что существует только один проект ALM Release 7.1.0.0. Следующий проект может сохранить те же значения проекта и категории, но версия будет другой - "7.2.0.0."

Рисунок 7. Создание записи проекта. Три идентификатора - имя, категория и релиз - определяют уникальность проекта.

Проекты часто связаны с другими проектами. Эти связи могут быть описаны на вкладке Related Projects, показанной на рисунке 8.

Рисунок 8. Пример проекта, который имеет вложенный проект и предшествующий проект

Как уже говорилось ранее, крупный проект часто делится на более мелкие вложенные проекты. Для установления связей между этими типами проектов используют поля Super Projects и Sub Projects. Кроме того, отдельные программные решения могут претерпеть множество редакций. Этими взаимосвязями можно управлять при помощи полей Prior Project или Next Project на этой же вкладке.

Планирование проекта

Для успешного создания и сдачи проектов необходимо планировать выполнение работ. Методика итеративной разработки оказалась успешной для планирования и сдачи проектов программного обеспечения. На рисунке 9 показано использование записей планирования проектов для определения итеративных проектов.

Рисунок 9. Планирование для проектов итеративной, инкрементальной разработки ПО

Шаги, представленные на рисунке 9, можно описать следующим образом:

1. Проект можно разделить на фазы (Phases) и итерации (Iterations), для которых создаются планы, временные рамки обычно измеряются неделями. Например, в процессе IBM Rational Unified Process®, или RUP®, определены 4 фазы - это начальная фаза (Inception), фаза уточнения (Elaboration), фаза конструирования (Construction) и фаза передачи и сопровождения (Transition) Еще пример - это процесс 4 D (Define, Design, Develop, Deliver (Определение, проектирование, разработка и поставка)). Начните с определения идентификаторов фаз и итераций, используемых в вашей организации. Например, первая итерация фазы уточнения (Construction) может иметь идентификатор C1 (что означает фаза Construction Итерация 1).
2. Создайте записи Phase. При создании этих записей выберите идентификатор фазы, а затем проект, как показано на рисунке 10. Создайте одну запись Phase для каждой фазы вашего проекта.
3. Создайте записи Iteration. Фаза проекта делится на итерации. Итерации ориентируют коллектив на поставку постепенно возрастающей экономической ценности заинтересованным лицам предсказуемым образом. Просмотрите фазы и итерации для проекта на вкладке Plans. Это необязательное действие.

Пользователи RUP создают записи Phase для фаз Inception (начальная фаза), Elaboration (фаза уточнения), Construction (фаза конструирования) и Transition (фаза передачи и сопровождения). Для управления итерациями необходимо создать записи итераций с именами типа "I1" для "фазы Inception итерации 1 и "C1" для "фазы Construction итерации 1".

Креативные пользователи могут использовать и другой принцип назначения имен фазам и итерациям. Например, можно создать одну запись Phase с именем Iteration. Затем создайте запись итерации с порядковым номером итерации. Например, создайте запись итерации с именем "1", затем "2" и так далее. В этой системе у вас будут названия типа "Iteration 1" "Iteration 2" и т. д.

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

Использование проектов в качестве шаблонов

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

Copy project (Копировать проект)

Часто новые проекты аналогичны уже существующим. Например, следующая версия проекта будет иметь параметры, аналогичные предыдущей версии, равно как и вложенный проект будет иметь те же параметры, что и родительский проект. В ALM-решении предлагается возможность "скопировать" существующий проект. Команда "Copy Project" создает копию структуры проекта, в том числе, определения ролей, фаз и итераций и конфигураций работы. Такие данные, как конкретные записи о запросах, задачах или деятельностях, не копируются. Создав копию, вы можете внести в нее любые необходимые изменения.

Вы можете просто разрешить руководителям проектов скопировать любой проект; можно также внедрить передовой метод, заключающийся в создании шаблонов проектов. Создав примеры проектов со всеми предполагаемыми настройками, вы сможете порекомендовать руководителям проектов скопировать один из таких примеров. Например, ваша организация может иметь ряд проектов, которые реализуют пакет приложений типа SAP. С другой стороны, ваши проекты сервис-ориентированной архитектуры (service-oriented architecture, SOA), вероятно, имеют принципиальные отличия от этих проектов. Вы можете создать примерный проект SAP и примерный проект SOA, и при следующем выделении денег на один из таких проектов вы просто скопируете соответствующий примерный проект.

Project wizard (Мастер проектов)

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

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

Далее в части 2...

В следующем месяце мы завершим эту статью рассказом о двух оставшихся фундаментальных концепциях работы с ALM-схемой в ClearQuest - управлением работой и администрированием и обеспечением безопасности.