$BEFORE_TIT2Правила работы в PVCS Tracker$AFTER_TIT2

PVCS Tracker (Program Version Control System, далее - трекер) — это программный комплекс, предназначенный для обеспечения сопровождения программного обеспечения. В английском языке программам такого назначения соответствует термин "bug trace software". Использование подобного рода утилит помогает организовать совместную работу всем, кто имеет отношение к жизненному циклу программного продукта.

Основными элементами при работе с трекером являются сообщения наших клиентов, которые заносятся в БД PVCS зарегистрированными контактными лицами со стороны заказчика — пожелания об улучшении программных продуктов, информация об обнаруженных ошибках и т.д. Эти сообщения сохраняются в базе данных трекера и подвергаются обработке. Статус сообщения изменяют сотрудники $COMPANY, ответственные за работу с ним. В процессе такой обработки — в зависимости от решений, принятых по существу сообщения - происходит изменение его статуса, который может принимать следующие значения:

Статус сообщенияОписание
AuthorizedСозданное сообщение зафиксировано в трекере и поставлено в очередь для анализа и обработки.
StudyingСообщение анализируется Группой поддержки.
ReceivedОшибка смоделирована (подтверждена) или пожелание по модификации программного обеспечения признано целесообразным; сообщение передано в разработку или Отдел маркетинга.
Fix in next version/patchЗапланирована модификация программного обеспечения, реализующая затребованные изменения (исправление ошибки или изменение функциональности).
Nothing to changeИзменения в программном обеспечения признаны нецелесообразными; описанная ситуация не является ошибкой, проблема может быть решена настройками определенных параметров или же пожелание об изменении функциональности может быть удовлетворено за счет других приемлемых альтернатив; сообщение закрыто.
PostponeСообщение больше не является актуальным; работы по нему приостановлены и могут быть возобновлены по отдельному запросу; сообщение закрыто.
Correction is doneМодификация программного обеспечения, реализующая затребованные изменения (исправление ошибки или изменение функциональности), выполнена; сообщение закрыто.

Правила создания сообщения

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


рис. 1. Ввод нового сообщения

Обработка сообщения может быть ускорена, если к сообщению будут приложены вспомогательные сведения: log-файл SQL Monitor'а, картинка (screenshot), иллюстрирующая описываемую проблему графически (например, в формате JPEG).

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


рис. 2. Добавление файла к сообщению

При создании сообщения пользователю предлагается заполнить следующие поля (см. рис. 1):

Название поляОбязательно к заполнениюОписание/рекомендации по заполнению
SubjectдаЗаголовок сообщения — краткое описание события или предмета сообщения, которые послужили причиной его создания.
Не рекомендуется в заголовке указывать наименование подсистемы, для этого существует специальное поле — Application.
Группа поддержки оставляет за собой право модифицировать данное поле с целью более точного описания его сути.
DescriptionдаТело сообщения — развернутое описание проблемы и действий, приведших к ее возникновению; для запросов на расширение функциональности программного обеспечения - причина возникновения такой потребности (события, бизнес-процессы) и примерный алгоритм реализации.
ApplicationнетНазвание подсистемы, к которой относится сообщение.
В случае если нельзя точно указать подсистему или описываемая проблема затрагивает несколько подсистем, допускается указание базовой подсистемы или подсистемы, в которой она проявилась.
Installed versionнетНомер версии подсистемы, к которой относится сообщение.
Информация о номерах текущих версий подсистем доступна в специализированном отчете.
Installed DB versionнетНомер версии схемы базы данных, установленной на момент создания сообщения.
Информация о номере текущей версии схемы базы данных доступна в специализированном отчете.
UrgencyнетПриоритет сообщения.
Поле предназначено для определения степени остроты проблемы и необходимости рассмотрения сообщения раньше или позже других сообщений Оператора.
Принимаемые значения:
А — Urgent: сверхсрочно; данное сообщение необходимо рассматривать в первую очередь.
В — ASAP: как можно скорее; данное сообщение необходимо рассматривать после сообщений с приоритетом А.
С — Ordinary: обычный; данное сообщение необходимо рассматривать после сообщений с приоритетами A и B.
$LQNone$RQ — без приоритета.
В случае если реализация сообщения имеет временные (дата, событие) рамки, требуется указать приемлемую дату реализации и мотивацию.

Добавление файла и записи к сообщению

Изменить сообщение, возможно добавив к нему файл с дополнительной информацией или заметку. При добавлении заметки в ее заголовке ($LQNote Title$RQ) необходимо указать наименование заметки либо выбрать наименование из списка (также, см. рис. 3):


рис. 3. Добавление заметки/нотации к сообщению

Заголовок заметкиОписание/рекомендации по заполнению
Demand to close messageЗаметка добавляется сотрудником Группы поддержки в момент закрытия сообщения. В тексте заметки указывается основание для закрытия, например, исправление ошибки в конкретной версии подсистемы;
Grounds of conclusionОписание оснований, послужившие изменению в ходе работы по сообщению.
Message analysis orderЗапрос/требование для выполнения анализа, например, просьба прислать log-file и т.д.
Message analysis resultОкончательный результат анализа сообщения.
Note of responsible concerning the message analysisЗаметка ответственного за данное сообщение.
Pilot message analysisПредварительный анализ по сообщению.
PVCS Tracker Administrator NoteЗаметка администратора трекера.
Quality NoteЗаметка Группы тестирования.

Нотификация

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

При желании правила нотификации могут быть изменены исходя из предпочтений того или иного пользователя. Заявки на такие изменения (а также любые вопросы, связанные с администрированием пользователей) необходимо отправлять Администратору трекера на адрес PVCS_admin@billing.ru. Заявки на регистрацию новых пользователей необходимо адресовать в Группу поддержки --> $BILLING_BACK