Оптимизация разработки приложений. Часть 3: Внесение изменений в требования

Оглавление

• Раздел 1. Перед началом работы
  • Необходимые условия
• Раздел 2. Упорядочивание запросов на изменение
  • Источник запросов на изменение
  • Сбор запросов
• Раздел 3. Rational ClearQuest
  • Схемы базы данных Rational ClearQuest
  • Создание нового проекта Rational
  • Добавление базы данных Rational ClearQuest
  • Создание хранилища данных тестирования для проекта
  • Регистрация запросов на усовершенствование
  • Регистрация дефектов
• Раздел 4. Использование данных Rational ClearQuest в рамках Rational Application Developer
  • Создание записей Rational ClearQuest
  • Составление запросов
  • Создание простого запроса
  • Фильтрация запросов
  • Классификация запросов
  • Принятие или отклонение запросов
  • Присвоение запросов
  • Разрешение запросов
• Раздел 5. Интеграция запросов на усовершенствование в спецификации требований
  • Сопоставление проекта Rational RequisitePro с проектом Rational
  • Процедура интеграции Rational ClearQuest и Rational RequisitePro
• Раздел 6. Создание новой спецификации требований
  • Создание нового требования
  • Интеграция изменений в подробные требования
• Раздел 7. Заключение

Раздел 1. Перед началом работы

Об этом руководстве

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

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

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

IBM Rational ClearQuest представляет собой идеальный инструмент для сбора всех запросов на изменение (дефекты и запросы на усовершенствование), их принятия или отклонения, а также для организации, присвоения и утверждения изменений по мере их принятия, разрешения и внедрения. Некоторые запросы на изменение влияют на исходную спецификацию требований, на основе которой все еще продолжает реализоваться проект. Чтобы контролировать воздействие изменения на требования, Rational ClearQuest интегрируется с IBM Rational RequisitePro для выявления связи между запросами на усовершенствование и спецификациями требований.

В данном руководстве рассматриваются следующие вопросы:

• Сбор запросов на изменение;
• Интеграция Rational ClearQuest и Rational RequisitePro;
• Управление данными Rational ClearQuest с помощью IBM Rational Application Developer;
• Создание новой версии спецификации требований;
• Модификация приложения.

Необходимые условия

Основное внимание в данном руководстве уделяется двум продуктам из пакета Rational Suite: Rational RequisitePro и Rational ClearQuest. В руководстве также рассматривается интеграция платформы IBM Software Development Platform (она объединяет компоненты IBM Rational Software Modeler и Rational Application Developer) в процесс разработки. Ссылки на загрузку ознакомительных версий данных продуктов представлены ниже. Для получения ознакомительной версии Rational ClearQuest необходимо обратиться в ближайшее представительство компании IBM.

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

• RequisitePro (версия 2003.06.13 или более поздняя);
• Rational ClearQuest (версия 2003.06.13 или более поздняя);
• Клиент Rational ClearQuest Eclipse Client:
  • При наличии Rational ClearQuest версии 2003.06.13.x используется клиент версии 6.0.0x;
  • При наличии Rational ClearQuest версии 2003.06.14.x необходимо использовать клиент Rational ClearQuest Eclipse версии 6.14.x. Эту версию клиента можно загрузить, выбрав Help > Software Updates > Find and Install в рамках платформы IBM Software Development Platform. Следуйте инструкциям по установке клиента;
• Rational Application Developer (версия 6.0);
• Rational Software Modeler (версия 6.0).

Также необходимо установить демонстрационное приложение Auction из базы примеров IBM Software Development Platform Showcase. В число этих примеров входит предварительно разработанная версия приложения Auction, которая создается в рамках данного учебного руководства. Используя эту версию, вы можете продолжить изучение руководства, при этом остальная часть программного кода будет заранее сконфигурирована. Чтобы установить пример, следует выполнить следующие действия:

• Выберите Help > Samples Gallery;
• В окне Samples Gallery разверните папку Showcase samples;
• Разверните папку Auction Application;
• Разверните папку Construction;
• Нажмите Web Application;
• Нажмите Import the sample, чтобы импортировать код и исходные файлы в текущее рабочее пространство.

Компоненты Enterprise JavaBean (EJB) для приложения размещены в папке EJB Projects как проект AuctionV60EJB.

Раздел 2. Упорядочивание запросов на изменение

Изменение приложения

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

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

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

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

Источник запросов на изменение

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

Запросы на изменение поступают от нескольких разных источников:

• Внешние заинтересованные лица. Наиболее очевидный источник. Заинтересованные лица могут часто требовать изменения приложения. Как правило, речь идет об усовершенствовании исходных требований. Усовершенствования можно подразделить на две основные категории: запросы на усовершенствование существующей функции и требования по расширению предоставляемой функциональности. Например, в качестве усовершенствования исходной системы ведения аукционов может запрашиваться поддержка вывода нескольких изображений определенной позиции на аукционе. Также, руководствуясь своим пониманием предполагаемого функционирования приложения, заинтересованные лица могут представить отчет о дефекте (если этот дефект точно не является ошибкой, а определенным образом относится к работе самого приложения или его внедрению);
• Сравнение с конкурентами. Возможно, в рамках конкурентной борьбы вам потребуется добавить в программное обеспечение те или иные функции;
• Специалисты отдела обеспечения качества. Средства тестирования предоставляют автоматические отчеты по дефектам системы, и в рамках процесса тестирования могут автоматически генерировать список выявленных в приложении проблем. Дефектом может оказаться любая неисправность: от программной ошибки до серьезного отклонения в фундаментальной логике;
• Группа разработчиков. Разработчики нередко сами выявляют в системе потенциальные ошибки и возможные пути усовершенствования, так как они больше, чем кто-либо другой в проектной группе, занимаются процессом внедрения. Использование инструментов тестирования (например, IBM Rational PurifyPlus и IBM TestManager) рассматривается в части 5 данного руководства.

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

Сбор запросов

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

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

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

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

В целях управления запросами на изменение демонстрационного приложения, в рамках данного руководства Rational ClearQuest используется для сбора запросов, а компонент Rational RequisitePro - для интеграции входящих запросов на изменение с требованиями, определяющими процесс разработки проекта.

Раздел 3. Rational ClearQuest

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

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

Схемы базы данных Rational ClearQuest

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

Rational ClearQuest поддерживает несколько готовых схем базы данных. Вдобавок, с помощью компонента Rational ClearQuest Designer (входит в состав Rational ClearQuest) вы можете создавать собственные схемы и форматы. Ниже приводится подробный список стандартных схем, предоставляемых Rational ClearQuest. В некоторых случаях возможно присутствие и других схем, что зависит от того набора инструментальных средств, который вы использовали для установки продукта (например, в пакет программ Rational Team Unifying Suite входят схемы, относящиеся к примеру ClassicsCD.com).

• Blank. Содержит только системные поля. Blank используется в том случае, если схема создается с нуля;
• Common. Содержит метаданные, общие для остальных схем.
• Defect Tracking. Содержит поля, необходимые для того, чтобы перейти к использованию Rational ClearQuest для отслеживания дефектов в среде разработки программного обеспечения;
• Rational Suite AnalystStudio. Предоставляет код для интеграции Rational ClearQuest и Rational RequisitePro;
• Rational Suite DevelopmentStudio. Содержит поля и правила для работы с IBM Rational Purify, Rational Visual Quantify и IBM Rational PureCoverage. Предоставляет код для интеграции Rational ClearQuest и Rational RequisitePro;
• Rational Suite TestStudio. Содержит поля и правила для работы с Rational TeamTest, Rational RequisitePro, Rational Purify, Rational Visual Quantify и Rational PureCoverage. Предоставляет код для интеграции Rational ClearQuest и Rational RequisitePro;
• Rational Suite Enterprise. Содержит поля и элементы, функционирующие со всеми продуктами Rational. Предоставляет код для интеграции Rational ClearQuest и Rational RequisitePro;
• UnifiedChangeManagement. Поддерживает процесс Unified Change Management (UCM) путем интеграции с Rational ClearCase. Следует использовать в связке с Rational ClearCase.

Схему для своего проекта вы сможете выбрать в следующем разделе.

Если вы планируете сопоставить запросы на изменение Rational ClearQuest с требованиями Rational RequisitePro (что предполагается данным руководством), нужно с помощью Rational Administrator создать проект Rational. Необходимые для этого сведения представлены в следующем разделе.

Создание нового проекта Rational

В рамках Rational Administrator проект Rational сопоставляется с базой данных Rational ClearQuest, проектом Rational RequisitePro, моделью IBM Rational Rose и проектом TestManager. Все это происходит под контролем системы управления изменениями Rational ClearCase.

Чтобы создать новый проект Rational в Rational Administrator, выполните следующие действия:

1. Откройте Rational Administrator. На экране появится окно, представленное на рис. 1;

   

   Рис. 1. Rational Administrator

2. Нажмите правую кнопку мыши на Projects, а затем выберите New Project;
3. Создайте имя проекта и определите месторасположение, как показано на рис. 2. Для размещения проекта должен использоваться пустой каталог. В рабочей среде проектной группы этот каталог должен размещаться на совместно используемом узле сети и быть доступным другим пользователям посредством ресурса UNC (например, \\machine\directory\project);

   

   Рис. 2. Создание имени проекта

4. Нажмите Next;
5. Задайте пароль для данного проекта. Помните: данный пароль используется только для контроля над проектом, а не его отдельными элементами. Rational ClearQuest, Rational RequisitePro и другие инструментальные средства используют свои собственные механизмы доступа пользователей. Нажмите Next;
6. Нажмите Finish, чтобы завершить создание проекта. На экране появится окно, представленное на рис. 3.

   

   Рис. 3. Завершение создания проекта

Добавление базы данных Rational ClearQuest

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

1. В разделе Change Requests окна Configure Project (представлено на рис. 3 в предыдущем разделе) нажмите Create;
2. Выберите соединение с базой данных. При установке Rational ClearQuest в системе создается несколько соединений с базой данных. Они позволяют соединиться с хранилищем данных Rational ClearQuest, однако сама информация размещается в базе данных, для доступа к которой и используются упомянутые соединения;
3. Введите имя базы данных - webau. При необходимости вы можете добавить комментарий, описывающий содержимое базы данных (как показано на рис. 4);

   

   Рис. 4. Создание имени базы данных

4. Выберите имя базы данных, в которой будет храниться информация Rational ClearQuest для данного проекта (как показано на рис. 5).Выбор зависит от используемой системы управления базами данных (например, Microsoft Access, SQL Anywhere, Microsoft SQL Server);

   

   Рис. 5. Выбор базы данных

5. Укажите значения тайм-аута и интервала опроса. Предлагаемые по умолчанию значения (см. рис. 6), как правило, подходят для большинства проектов;

   

   Рис. 6. Определение тайм-аута

6. Выберите схему базы данных Rational TestStudio, представленную на рис. 7. Эта схема предоставляет самый большой выбор типов записей и информацию для работы со всеми инструментальными средствами Rational, включая Rational TestStudio, Rational PurifyPlus и Rational RequisitePro;

   

   Рис. 7. Выбор схемы базы данных

7. Нажмите Finish, чтобы создать базу данных.

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

Создание хранилища данных тестирования для проекта

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

Чтобы создать новое хранилище данных тестирования, выполните следующие действия:

1. Находясь в окне Configure Project, нажмите Create в разделе Test Assets;
2. Выберите тип базы данных, которая будет использоваться для хранения результатов тестирования и отслеживания информации (как показано на рис. 8). Если в тестировании задействовано несколько специалистов, следует использовать Sybase SQL Anywhere, что позволит любому тестировщику обновлять информацию. Если предполагается только один тестировщик, используйте Microsoft Access;

   

   Рис. 8. Создание хранилища данных тестирования

3. Выберите место размещения базы данных для хранилища данных (если используется Microsoft Access) или укажите параметры соединения для одной из остальных баз данных, как показано на рис. 9;

   

   Рис. 9. Выбор места размещения для базы данных хранилища информации

4. Выберите существующее хранилище данных для инициализации данного хранилища данных тестирования, как показано на рис. 10. Это может потребоваться в том случае, если вы создали хранилище данных тестирования еще до использования системы интеграции. Также можно инициализировать список пользователей и групп, взятых из существующего проекта Rational;

   

   Рис. 10. Выбор существующего хранилища данных для инициализации определенного хранилища данных тестирования

5. Нажмите Finish, чтобы создать базу данных.

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

Теперь можно перейти к сбору запросов на изменение и отслеживанию степени их выполнения в процессе разработки.

Регистрация запросов на усовершенствование

Несмотря на то, что некоторые запросы на изменение создаются и вводятся в систему не в рамках Rational ClearQuest (например, в TestManager, Rational PurifyPlus или IBM Software Development Platform), остальные запросы записываются непосредственно в рамках системы Rational ClearQuest. Эта обязанность возлагается на руководителя проекта или аналитика, отвечающего за управление изменениями. В целом, сбор данных с помощью Rational ClearQuest способствует решению большей части проблем, присущих процессу регистрации запросов на усовершенствование. Этому способствует гибкость системы схем, которую можно использовать для точного определения информации, требующейся аналитику при вводе данных.

Информация вводится в Rational ClearQuest как с помощью стандартного интерфейса Microsoft Windows, так и посредством интерфейса Rational ClearQuest Web, что обеспечивает прямой доступ к системе не только внутренним пользователям, но и внешним заинтересованным лицам (например, клиентам).

Чтобы создать новый запрос на усовершенствование посредством интерфейса Windows, выберите Actions > New. На экране появится окно, представленное на рис. 11. Следует помнить, что это окно создается в рамках ограниченной пользовательской учетной записи, предназначенной для ввода данных в систему на базовом уровне. (Инструменты для аналитиков более подробно рассматриваются в последующей части этого раздела) Поля, выделенные красным цветом, заполняются в обязательном порядке. Вкладки, имеющие незаполненные, но обязательные к вводу элементы, выделяются с помощью красного квадрата. Разработчики могут сами определить, какие поля должны заполняться обязательно, а какие поля заполняются опционально.

Рис. 11. Пустой запрос на усовершенствование

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

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

Рис. 12. Информация о клиенте в запросе на усовершенствование

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

Рис. 13. Вкладка Attachments

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

Регистрация дефектов

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

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

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

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

Чтобы создать новый дефект, выберите Actions > New. Окно Submit Defect представлено на рис. 14.

Рис. 14. Ввод (регистрация) дефекта

Как видите, вы можете ввести более подробные сведения для дефекта, чем для запроса на усовершенствование, но значительная часть этой информации (по крайней мере, в рамках данной схемы) не является обязательной для ввода. Как и в случае запроса на усовершенствование, существуют только два важных аспекта: в этом случае, описание заголовка и уровень серьезности (severity). Остальные сведения - ключевые слова, симптомы, связанные проекты и лицо, владеющее дефектом, - вводить необязательно. Просмотрев остальные вкладки, вы увидите, как Rational ClearQuest выполняет интеграцию с остальными продуктами тестирования Rational.

Когда при использовании Rational TestManager сценарий тестирования выдает ошибку, на вкладке Test Data, представленной на рис. 15, автоматически выводится место проведения теста, версия сборки приложения, а также место размещения журналов тестирования, сценарий тестирования и исходные данные, ставшие причиной возникновения дефекта. Ключевая особенность Rational ClearQuest заключается именно в интеграции с TestManager. Для ввода информации о тестировании в журнал дефектов не требуется какого-либо вмешательства.

Рис. 15. Вкладка Test Data

Вкладка Environment (представлена на рис. 16) используется для записи операционной системы и оборудования, связанных с возникшей неисправностью.

Рис. 16. Вкладка Environment

На вкладке Iterations & Notes (представлена на рис. 17) записывается итерация приложения, вызвавшая рассматриваемый дефект.

Рис. 17. Установка данных об итерациях

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

Раздел 4. Использование данных Rational ClearQuest в рамках Rational Application Developer

Открытие репозитария Rational ClearQuest

В состав клиента Rational ClearQuest Client for Eclipse входит набор дополнительных ракурсов и новая перспектива, которые можно использовать при доступе и обработке данных Rational ClearQuest. Пример упомянутой перспективы представлен на рис. 18.

Рис. 18. Перспектива Rational ClearQuest

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

Основные доступные ракурсы представлены на рис. 18. Основная связь с Rational ClearQuest поддерживается посредством ClearQuest Navigator, который отображается в левой области окна. Этот ракурс предоставляет ту же самую навигационную структуру, доступную в рамках Rational ClearQuest. Он используется для создания запросов и ракурсов в отношении данных Rational ClearQuest.

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

Чтобы подсоединиться к репозитарию Rational ClearQuest, откройте ракурс ClearQuest Navigator и выполните следующие действия:

1. Нажмите пиктограмму соединения с базой данных на панели инструментов в ракурсе ClearQuest Navigator;
2. Выберите используемый репозитарий, как показано на рис. 19;

   

   Рис. 19. Выбор репозитария

3. Нажмите Next, а затем введите идентификатор пользователя для данного репозитария, как показано на рис. 20. Если вы используете пример базы данных, входящий в состав Rational ClearQuest, в качестве идентификатора пользователя введите admin;

   

   Рис. 20. Установка регистрационных данных

4. Введите регистрационные данные для выбранного репозитария и для базы данных в рамках репозитария Rational ClearQuest, к которой вы можете подсоединиться. На рис. 21 выбрана база данных webau.

   

   Рис. 21. Выбор базы данных Rational ClearQuest

После завершения этой процедуры в ракурсе ClearQuest Navigator должен отображаться открытый репозитарий.

В следующем разделе описывается процесс обновления информации в базе данных Rational ClearQuest, выполняемый в рамках Rational Application Developer.

Создание записей Rational ClearQuest

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

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

Для того чтобы создать новые запросы на усовершенствование и дефекты, нажмите пиктограмму New Record на панели инструментов в ракурсе ClearQuest Query Results. Удерживая эту пиктограммой нажатой, вы можете выбрать создание нового дефекта или запроса на усовершенствование.

В обоих случаях, чтобы сохранить запись в базе данных, необходимо ввести минимальный объем информации в определенные поля (так же, как и при использовании самого компонента Rational ClearQuest). Новый запрос на регистрацию дефекта представлен на рис. 22. Выделенные красным цветом поля заполняются обязательно.

Рис. 22. Ввод нового дефекта в Rational Application Developer

На рис. 23 представлен новый запрос на усовершенствование в Rational Application Developer. Как и ранее, необходимо заполнить поля, выделенные красным цветом.

Рис. 23. Новый запрос на усовершенствование в Rational Application Developer

Составление запросов

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

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

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

Безусловно, в Rational ClearQuest обрабатывается больший объем данных, что, как правило (в зависимости от используемой схемы), происходит в рамках более сложной структуры. Такая сложность имеет свои преимущества и недостатки. К плюсам стоит отнести настоящую гибкость в области отчетности и структуризации информации. Основной недостаток заключается в том, что широкий выбор зачастую затрудняет быстрое создание простого отчета. Чтобы исправить ситуацию, Rational ClearQuest позволяет создавать и сохранять запросы в рабочем пространстве. Определив необходимые для вывода на экран поля и параметры фильтра, вы можете в любое время выполнить свой запрос для получения отчета по текущим данным. Кроме этого, система предоставляет пользователю и предварительно определенные запросы.

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

Создание простого запроса

Запрос можно создать как в ClearQuest, так и с помощью Rational Application Developer, так как основная структура и процесс в обоих случаях полностью идентичны. Чтобы создать публичный или персональный запрос в базу данных Rational ClearQuest в рамках Rational Application Developer, откройте ракурс ClearQuest Navigator и выполните следующие действия:

1. Нажмите правую кнопку мыши на папке в рамках древовидной структуры ClearQuest Navigator, а затем выберите New Query. Также, вы можете нажать New Record в ракурсе ClearQuest Query Results, а затем выбрать New Query. Персональные запросы относятся только к текущему пользователю. Публичные запросы (если у вас есть разрешение на их создание) доступны всем пользователям;
2. Выберите тип записи, которую будет обрабатывать запрос, как показано на рис. 24. Вы можете также снабдить новый запрос именем, которое будет использоваться для идентификации запроса в рамках ракурса Navigator. В данном примере выберите в качестве объекта запроса дефекты в базе данных и введите имя запроса All Defects. (Обратите внимание на то, что вы также можете выбрать вариант создания запроса на основе существующего определения, что может понадобиться, если вы планируете продублировать запрос и изменить фильтр. На данном этапе эту опцию следует пропустить.);

   

   Рис. 24. Создание нового запроса

3. Как показано на рис. 25, на следующем этапе вы можете выбрать поля, которые будут использоваться для фильтрации результатов запроса. Однако для данного запроса фильтрация результатов проводиться не будет, поэтому вы можете пропустить этот экран и нажать Next. Вопрос фильтрации рассматривается в последующих разделах руководства.

   

   Рис. 25. Выбор полей для фильтрации

4. \На экране появится страница конфигурации экрана. Здесь вы можете определить поля из указанного на первом этапе типа записей, которые будут включены в результаты запроса. (Следует помнить, что список представленных здесь полей полностью зависит от типа записей, который вы выбрали на первом экране мастера.) Перетащите поля Headline, id, record_type и State с панели в левой области экрана в таблицу Display Format в правой области экрана. Для перемещения можно также использовать двойное нажатие полей;
5. Нажмите мышью в столбце Sort рядом с полем State, чтобы выбрать сортировку полей по возрастанию. Так как для сортировки вы будете использовать только это поле, не стоит волноваться о порядке сортировки. Тем не менее, вы можете использовать этот столбец в определении запроса для определения приоритетов столбцов в отображении результатов. После перемещения элементов экран будет выглядеть так, как показано на рис. 26;

   

   Рис. 26. Определение формата отображения запроса

6. Нажмите Finish, чтобы сохранить запрос.

Чтобы на самом деле выполнить запрос, дважды нажмите имя запроса в рамках ракурса Navigator. Результаты для рассматриваемого примера базы данных представлены на рис. 27.

Рис. 27. Результаты запроса

Статичный экран результатов ClearQuest Query Results автоматически не обновляется при изменении информации в базе данных (что, например, могло бы происходить, если другие разработчики изменяли бы данные). Чтобы обновить отображаемые сведения, нажмите Refresh на панели инструментов или просто снова дважды нажмите запрос в ракурсе Navigator.

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

Фильтрация запросов

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

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

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

Чтобы скопировать запрос:

1. В ракурсе Navigator нажмите правую кнопку мыши на запросе, который будет копироваться, а затем выберите Copy;
2. В Navigator нажмите правую кнопку мыши на папке, в которой вы планируете создать новый запрос, а затем выберите команду Paste;
3. Нажмите правую кнопку мыши на новом запросе, а затем выберите Rename. В качестве имени нового запроса введите Submitted defects.

Теперь в новый запрос нужно добавить фильтр:

1. Нажмите ячейку со знаком "плюс" рядом с запросом, чтобы развернуть определение запроса;
2. Дважды нажмите Filters, чтобы отредактировать фильтры. На экране появится окно, представленное на рис. 28. Здесь мы уже добавили поле State в список фильтров. Добавьте в этот список любые другие необходимые поля. Нажмите Next;

   

   Рис. 28. Редактирование фильтров

3. При появлении запроса введите настройки фильтра для каждого поля. Выберите поле State. В окне отображаются настройки фильтра для данного поля. Выберите параметр Equal, а затем введите в поле значение Submitted. (Обратите внимание на то, что при нажатии Values на экран выводится список потенциальных значений для рассматриваемого поля.) Экран с установленными настройками фильтра представлен на рис. 29;

   

   Рис. 29. Установка параметров фильтра

4. Нажмите Finish, чтобы сохранить определение фильтра.

Вот и все! Выполнив данный запрос, вы получите сокращенный список дефектов в базе данных Rational ClearQuest, отображающий только введенные дефекты.

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

Классификация запросов

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

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

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

Ниже представлена вкладка Analysis для дефекта (на рис. 30) и для запроса на усовершенствование (на рис. 31). Оба примера взяты из Rational ClearQuest.

Рис. 30. Вкладка Analysis для дефекта

Рис. 31. Вкладка Analysis для запроса на усовершенствование

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

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

Рис. 32. Установка приоритетов

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

Присвоение запросов

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

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

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

Для присвоения используйте программный запрос, позволяющий найти соответствующий запрос. Например, предыдущий программный запрос, перечисливший все запросы в системе, все еще находится в статусе Submitted.

1. Выберите запрос в списке результатов;
2. Нажмите Actions справа от формы записи;
3. Выберите Assign;
4. В ниспадающем списке пользователей выберите владельца данного запроса;
5. Нажмите Apply.

Результаты присвоения запроса на усовершенствование представлены на рис. 33.

Рис. 33. Новый список запросов на усовершенствование

Разрешение запросов

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

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

В большинстве случаев, для определения присвоенной им работы разработчики используют запрос "My ToDo List" (с помощью методов, представленных в предыдущих разделах руководства). Этот запрос отображает все запросы в статусе Assigned, в которых владельцем запроса выступает текущий пользователь (CURRENT_USER). Значение параметра CURRENT_USER, который сам по себе является ключевым словом, используемым в запросах Rational ClearQuest, совпадает с именем текущего зарегистрированного пользователя. Чтобы открыть запрос, найдите требуемый запрос в рамках Rational ClearQuest или внутри окна ClearQuest Query Results. Затем нажмите Actions > Open. Вы можете ввести информацию о выполняемом действии или нажать Apply, чтобы пометить запрос как открытый элемент.

После того как проблема будет решена или запрос на усовершенствование будет внедрен, выберите Action > Close и заполните форму, представленную на рис. 34.

Рис. 34. Форма запроса разрешения

Если запрос подразумевал исправление дефекта, укажите сведения о разрешении. Соответствующий пример представлен на рис. 35.

Рис. 35. Сведения о разрешении дефектов

Итак, мы проследили за жизненным циклом запроса (от обследования до составления отчета), а затем закрыли запрос в рамках системы. А что если запрос связан с исходным требованием, входящим в спецификацию требований?

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

Раздел 5. Интеграция запросов на усовершенствование в спецификации требований

Взаимосвязь запросов и требований

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

Интеграция Rational ClearQuest и Rational RequisitePro позволяет связать запросы на усовершенствование с соответствующими требованиями. В большинстве случаев, два основных типа запросов интегрируются различными способами:

1. Запросы на усовершенствование. Как правило, эти запросы связаны с существующей функцией или требованием к системе, или являются усовершенствованием существующей функциональности. Например, функция автоматического ввода заявок является усовершенствованием исходной функции "Покупатели могут подавать ценовые заявки". Запросы на усовершенствование могут также относиться к отсутствующей функциональности. В этом случае в спецификации требований создается новое требование, отображающее данную функциональность;
2. Дефекты. Дефекты присоединяются к определению прецедента для объекта или класса, который, как считают, и вызвал рассматриваемую проблему. Отслеживая дефект подобным образом, можно выявить требование, к которому относится данный дефект. Такой способ эффективен при анализе закономерностей в неудачно определенных требованиях. Присоединение множества дефектов к прецеденту свидетельствует о том, что данный прецедент еще не был достаточно разработан до начала внедрения. Это следует учесть при реализации вашего следующего проекта.

Для интеграции Rational ClearQuest и Rational RequisitePro можно создать связь между типом требования в рамках Rational RequisitePro и типом запроса на изменение в Rational ClearQuest.

Сопоставление проекта Rational RequisitePro с проектом Rational

В этом разделе Rational Administrator будет использован снова для сопоставления проекта Rational RequisitePro, созданного в части 1 данного руководства, с базой данных Rational ClearQuest, созданной в рамках текущего учебного материала. В схему, используемую для создания базы данных, уже входит программный код, необходимый для интеграции с проектом Rational RequisitePro.

Чтобы сопоставить проект Rational RequisitePro, выполните следующие действия:

1. Закройте Rational ClearQuest, если он был до этого открыт (не обязательная, но рекомендуемая операция);
2. Откройте Rational Administrator;
3. Нажмите правую кнопку мыши на созданном проекте WebAuction, а затем выберите команду Configure. При появлении запроса введите пароль (если таковой был создан для проекта Rational). На экране появится окно, представленное на рис. 36;

   

   Рис. 36. Установка интеграции с Rational RequisitePro

4. Нажмите Select в разделе Requirements Assets, чтобы выбрать проект Rational RequisitePro, который необходимо сопоставить (связать) с базой данных Rational ClearQuest. С помощью браузера выберите файл проекта Rational RequisitePro.

Процедура интеграции Rational ClearQuest и Rational RequisitePro

После того как проект Rational RequisitePro будет сопоставлен с проектом Rational, в системе автоматически запустится мастер интеграции Rational ClearQuest-Rational RequisitePro Integration. Этот мастер проводит пользователя через серию основных операций по сопоставлению проекта Rational RequisitePro с базой данных Rational ClearQuest, включая модификацию проекта Rational RequisitePro в целях внедрения новых типов требований, используемых для отслеживания интеграции двух упомянутых систем.

При работе с мастером выполните следующие действия:

1. На первом экране, представленном на рис. 37, приводятся основные сведения об интеграции. Введите соответствующее имя и пароль для базы данных Rational ClearQuest. На этом этапе ничего изменять не требуется, поэтому просто нажмите Next;

   

   Рис. 37. Запуск мастера интеграции

2. Окно Choose Setup Type определяет, как происходит информационное взаимодействие между двумя инструментами. Параметр Typical связывает типы записей Rational ClearQuest Defects и Enhancement Requests с типами требований Feature или Use Case. Если вы используете другие типы записей или требований, или хотите установить другую взаимосвязь, выберите параметр Custom. В этом случае вы сможете выбрать, какие типы записей Rational ClearQuest будут сопоставлены с теми или иными типами требований Rational RequisitePro. Вы также можете выбрать Integration Status, чтобы получить отчет о статусе (и любых аспектах) интеграции. В любом случае, для данного примера следует выбрать параметр Typical, как показано на рис. 38;

   

   Рис. 38. Выбор типа установки

3. В окне, представленном на рис. 39, отображается краткое резюме того, что будет выполнено мастером интеграции. Так как выбран параметр Typical, мастер устанавливает связь типов требований Rational RequisitePro Feature и Use Case с запросами Rational ClearQuest Defects и Enhancement.

   

   Рис. 39. Резюме действий для установки интеграции

По окончании работы мастера на экране вновь отображается главное окно Project Configuration.

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

Раздел 6. Создание новой спецификации требований

Создание сопоставления между запросом и требованием

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

Чтобы создать сопоставление, выполните следующие действия:

1. В Rational ClearQuest найдите то усовершенствование или дефект, который необходимо сопоставить с требованием. В данном примере сопоставляется усовершенствование в области автоматической подачи заявок с запросом на введение новой функции. Для поиска используйте один из ранее созданных запросов;
2. Нажмите Actions > Modify;
3. На вкладке Main выберите имя проекта Rational, с которым вы планируете связать данный запрос. В данном примере, проект Rational носит имя Auction;
4. Нажмите вкладку Requirements, как показано на рис. 40;

   

   Рис. 40. Определение связи с проектом требований

5. Нажмите Add to List. На экране отобразится список всех требований в проекте Rational RequisitePro, сопоставленных с рассматриваемой базой данных Rational ClearQuest (см. рис. 41);
6. Выберите FEAT: Feature в качестве типа требования, а затем выберите Buyers can bid on an item в качестве функционального требования;

   

   Рис. 41. Сопоставление требования с запросом на изменение

7. Закройте это окно, затем нажмите Apply;
8. В Rational RequisitePro выберите ракурс Rational RequisitePro, в котором содержится список функций в атрибуте Defect или Enhancement Request. На рис. 42 показано, что в систему был введен номер запроса на изменение Rational ClearQuest;

   

   Рис. 42. Список функций в Rational RequisitePro

9. Нажмите ячейку, в которой перечисляется Rational ClearQuest CR. Затем нажмите кнопку .... В окне появится подробная информация о запросе на изменение, сохраненном в Rational ClearQuest. Интеграция обеспечивает динамический доступ к данным Rational ClearQuest из Rational RequisitePro. Преимущество заключается в том, что, находясь в Rational RequisitePro, вы можете просмотреть сведения о запросах на усовершенствование, которые привели к изменению требования.

Создание нового требования

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

В большинстве случаев, Rational ClearQuest и Rational RequisitePro соединяются с помощью типа Feature Requirement, что позволяет создавать требования FEAT непосредственно в рамках Rational ClearQuest. Как правило, запросы на усовершенствование основаны на функциях высокого уровня, хотя также могут относиться и к более подробным усовершенствованиям. Хорошим примером в этом случае служит рассматриваемое в данном руководстве усовершенствование в области автоматической подачи заявок.

Чтобы создать в рамках Rational ClearQuest новое требование, связанное с определенным запросом, выполните следующие действия:

1. Найдите то усовершенствование или дефект, который необходимо сопоставить с требованием. Так как запрос на усовершенствование будет сопоставляться с новой функцией, для поиска используйте один из ранее созданных запросов;
2. Нажмите Actions > Modify;
3. На вкладке Main выберите имя созданного ранее проекта Rational (того проекта, который соединяет проект Rational RequisitePro с базой данных Rational ClearQuest). В данном примере проект Rational носит имя Auction;
4. Нажмите вкладку Requirements, а затем нажмите Add to List, чтобы открыть список доступных требований;
5. Нажмите Create, чтобы создать новое требование. На экране откроется окно свойств Rational RequisitePro, представленное на рис. 43;

   

   Рис. 43. Определение свойств изменения функции

6. Укажите свойства нового требования. Будьте внимательны при написании текста. Простое копирование текста запроса на усовершенствование в текст требования является типичной ошибкой. Требования должны быть четкими, доступными для тестирования и соответствующими используемой разработчиками терминологии. При наличии незавершенного и неточного текста запроса на усовершенствование вы рискуете добавить в набор требований двусмысленность;
7. При необходимости выберите родительское требование и нажмите OK;
8. Нажмите Apply, чтобы сохранить изменения и закрыть данное окно.

На рис. 44 вы можете видеть метку Rational ClearQuest для запроса на усовершенствование, добавленную только что созданному требованию в качестве атрибута.

Рис. 44. Запрос на усовершенствование в Rational RequisitePro

Чтобы отобразить новое требование в документе требований Rational RequisitePro (скорее всего, именно так была создана ваша спецификация требований), выполните следующие действия:

1. Нажмите правую кнопку мыши на новом требовании, а затем выберите команду Cut;
2. Откройте документ Microsoft Word, в котором содержатся требования, и установите курсор в том месте, где вы планируете разместить новую функцию;
3. Выберите RequisitePro > Requirement > Paste (будьте внимательны: следует использовать не функцию вставки редактора Word, а соответствующую функцию Rational RequisitePro). Функция вырезания (Cut) фактически не вырезает требование из базы данных, а позволяет отобразить требование в документе Word.

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

Интеграция изменений в подробные требования

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

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

Раздел 7. Заключение

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

Интеграция между Rational Application Developer и Rational ClearQuest позволяет разработчикам использовать данные Rational ClearQuest для оптимизации разработки и концентрации своих усилий. Поскольку требуемая информация доступна в самом приложении, используемом для разработки, они получают все необходимые сведения, не переключаясь между приложениями и не просматривая Web-ресурсы. Чем проще использовать информацию, тем вероятнее факт ее использования. Вдобавок, разработчики могут использовать и обновлять базу данных Rational ClearQuest, а также записывать состояние работы в системе.

В части 4 данного руководства IBM Rational Application Developer будет использоваться для разработки сессионных компонентов и создания страниц для доступа к этим компонентам с помощью технологии JavaServer Faces. В части 5 вы узнаете о роли инструментов тестирования в разработке приложения.