Что дадут проекту CRM и ClearQuest?

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

Проблема до боли знакомая, и каждая компания решает ее по-своему, изобретая порой то, что уже есть и работает… Давайте посмотрим, что предлагает Rational.

ClearQuest - это средство управления запросами на изменение (Change Request Management - CRM), специально разработанное с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest предназначен для отслеживания и управления любым типом действий, приводящим к изменениям в течение всего жизненного цикла продукта, помогая тем самым создавать качественное ПО более предсказуемым образом.

ClearQuest представляет собой многомодульное приложение, которое собственными средствами создает базу данных проекта и заносит в нее все изменения. Он поддерживает СУБД ведущих производителей, в частности Oracle, Microsoft и Sybase.

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

Состояний у дефектов всего пять. "Подан" (Submitted) - описание дефекта только что внесено; "Назначен" (Assigned) - описание передано определенному сотруднику. Начало работы над запросом переводит его в "Открытое" состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос.
Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии "Проверка" (Verify) и "Закрыт" (Resolved). Состояния способны указать только на статус того или иного дефекта, а вот дотошно описать его помогут лишь специализированные поля. Любой дефект содержит определенное количество описательных полей, причем если использовать ClearQuest совместно со средствами тестирования, то при обнаружении ошибки данные продукты сами заполняют все необходимые поля. Чтобы вы не посчитали автозаполнение недостатком системы, скажу, что наряду с автозаполнением в ClearQuest предусмотрено и ручное внесение описания дефектов в систему, при котором вся ответственность за поданную информацию лежит на операторе. Итак, дефект получает идентификационный номер и набор описательных данных. Вот краткий список того, что можно передать в качестве описания к дефекту.

Рисунок 1. Внесение нового дефекта На рис. 1 показано диалоговое окно, возникающее при вводе или изменении дефекта. Как видите, окно включает большое число закладок, подавляющее большинство которых уже описано выше. Итак, посмотрим, что даст ClearQuest каждому участнику проекта:

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