Что дадут проекту CRM и ClearQuest?
Как известно, знание - сила. А на сегодня нам известно, что чем больше проект, тем менее он управляем. Как видите, зависимость здесь обратно пропорциональная. Согласитесь, что сотрудник, тестирующий продукт, должен иметь инструмент, который позволит описать любую найденную в продукте ошибку, разработчик должен, используя сведения, полученные от группы тестирования, исправить модуль, где найдена ошибка, а руководитель, в свою очередь, должен знать, во-первых, кто чем в данный момент занят, а во-вторых, какое количество ошибок и какого рода сопровождают ту или иную версию проекта.
Проблема до боли знакомая, и каждая компания решает ее по-своему, изобретая порой то, что уже есть и работает… Давайте посмотрим, что предлагает Rational.
ClearQuest - это средство управления запросами на изменение (Change Request Management - CRM), специально разработанное с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest предназначен для отслеживания и управления любым типом действий, приводящим к изменениям в течение всего жизненного цикла продукта, помогая тем самым создавать качественное ПО более предсказуемым образом.
ClearQuest представляет собой многомодульное приложение, которое собственными средствами создает базу данных проекта и заносит в нее все изменения. Он поддерживает СУБД ведущих производителей, в частности Oracle, Microsoft и Sybase.
Смысл работы продукта прост и прозаичен. Основная информационная единица - дефект - это найденная ошибка в продукте или описание какой-то его особенности. Дефект заносится в систему пользователем, обнаружившим его. У каждого дефекта есть определенный набор состояний, по которым руководство может как отследить историю проекта, так и оценить текущее положение дел.
Состояний у дефектов всего пять. "Подан" (Submitted) - описание дефекта только что внесено; "Назначен" (Assigned) - описание передано определенному сотруднику. Начало работы над запросом переводит его в "Открытое" состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос.
Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии "Проверка" (Verify) и "Закрыт" (Resolved). Состояния способны указать только на статус того или иного дефекта, а вот дотошно описать его помогут лишь специализированные поля. Любой дефект содержит определенное количество описательных полей, причем если использовать ClearQuest совместно со средствами тестирования, то при обнаружении ошибки данные продукты сами заполняют все необходимые поля. Чтобы вы не посчитали автозаполнение недостатком системы, скажу, что наряду с автозаполнением в ClearQuest предусмотрено и ручное внесение описания дефектов в систему, при котором вся ответственность за поданную информацию лежит на операторе. Итак, дефект получает идентификационный номер и набор описательных данных. Вот краткий список того, что можно передать в качестве описания к дефекту.
-
State - текущий статус дефекта (закрыт, открыт, в работе...). ID - идентификационный код дефекта. Воздействовать на это значение пользователь не может, поскольку система присваивает номер автоматически. Headline - комментарий к дефекту. В случае ручного ввода дается пользователем самостоятельно. При автоматической интеграции заполняется автоматически программой, обнаружившей дефект. RA - ассоциация с проектом (репозитарием). Необходима для ассоциации дефекта с требованием к системе. Priority - приоритет исправления дефекта. Этот параметр можно изменять по ходу проекта. Severity - критичность дефекта. То есть на первом этапе дефект можно определить как некритичный и исправить в последнюю очередь либо в последующей версии. Этот параметр также можно изменять по ходу проекта. Owner - владелец дефекта. Здесь следует отметить такую особенность: ClearQuest имеет два контрольных поля - Submitter и Owner. Причем первое поле содержит имя пользователя, который активизировал ошибку, а второе - имя пользователя, который должен эту ошибку исправить. Keyword - набор ключевых слов для данного дефекта. Специальный механизм, позволяющий конкретной компании вводить в обиход свой набор ошибок и приводить их в состояние ассоциативной связи с ошибкой в ClearQuest. Symptoms - признак дефекта (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance...
и т.д.). Заранее предопределенные типы. Description - описание проблемы, комментарий. Resolution - способ разрешения проблемы (fixed/nofixed). Attachment - сюда можно присоединить любой документ (скажем, код программы). History - история внесения изменений в дефекте. TestData - определенный набор сопроводительных документов. Заполняется либо вручную, либо автоматически средствами тестирования. Environment - среда сопровождения. Здесь можно определить тип операционной системы, тип процессора, при которых проявляется дефект. Requirements - здесь можно задать связь дефекта с требованием из RequisitePro. ClearCase - связь дефекта с конкретной версией файла. Данный модуль появляется только при правильной настройке ClearQuest и ClearCase (см. ниже).
- тестировщику - механизм внесения найденных ошибок, причем достаточно разветвленный, поскольку ClearQuest имеет возможность вносить описания ошибок удаленно, например непосредственно через Интернет либо посредством e-mail-нотификации;
- разработчику - возможность видеть все ошибки, найденные тестировщиками, и исправлять их, а результат документировать при закрытии диалога;
- руководителю - возможность контролировать ход проекта и получать отчеты установленного образца.
