$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 | Модификация программного обеспечения, реализующая затребованные изменения (исправление ошибки или изменение функциональности), выполнена; сообщение закрыто. |
Правила создания сообщения
При создании сообщений необходимо стремиться выделять разные пожелания и ошибки в отдельные сообщения. Лучше создать несколько сообщений, одни для ошибок, другие для пожеланий или даже для каждой ошибки или пожелания свое сообщение. Это ускорит работу, поскольку по разным проблемам могут быть приняты разные решения, и циклы обработки сообщений будут значительно различаться. Если описываемая проблема затрагивает работу более чем одной подсистемы, то основную лучше указать явно, а другие в дополнительной заметке.
Обработка сообщения может быть ускорена, если к сообщению будут приложены вспомогательные сведения: log-файл SQL Monitor'а, картинка (screenshot), иллюстрирующая описываемую проблему графически (например, в формате JPEG).
При создании сообщения, которое уже на начальном этапе можно классифицировать, как пожелание, необходимо обязательно указывать ещё и причины мотивирующие создание такого сообщения (ссылки на требования служб клиента, например, таких как отдел маркетинга, нормативные документы и т.п.), а также информацию по желаемым срокам реализации.
При создании сообщения пользователю предлагается заполнить следующие поля (см. рис. 1):
Название поля | Обязательно к заполнению | Описание/рекомендации по заполнению |
---|---|---|
Subject | да | Заголовок сообщения краткое описание события или предмета сообщения, которые послужили причиной его создания.
Не рекомендуется в заголовке указывать наименование подсистемы, для этого существует специальное поле Application. Группа поддержки оставляет за собой право модифицировать данное поле с целью более точного описания его сути. |
Description | да | Тело сообщения развернутое описание проблемы и действий, приведших к ее возникновению; для запросов на расширение функциональности программного обеспечения - причина возникновения такой потребности (события, бизнес-процессы) и примерный алгоритм реализации. |
Application | нет | Название подсистемы, к которой относится сообщение.
В случае если нельзя точно указать подсистему или описываемая проблема затрагивает несколько подсистем, допускается указание базовой подсистемы или подсистемы, в которой она проявилась. |
Installed version | нет | Номер версии подсистемы, к которой относится сообщение.
Информация о номерах текущих версий подсистем доступна в специализированном отчете. |
Installed DB version | нет | Номер версии схемы базы данных, установленной на момент создания сообщения.
Информация о номере текущей версии схемы базы данных доступна в специализированном отчете. |
Urgency | нет | Приоритет сообщения.
Поле предназначено для определения степени остроты проблемы и необходимости рассмотрения сообщения раньше или позже других сообщений Оператора. Принимаемые значения: А Urgent: сверхсрочно; данное сообщение необходимо рассматривать в первую очередь. В ASAP: как можно скорее; данное сообщение необходимо рассматривать после сообщений с приоритетом А. С Ordinary: обычный; данное сообщение необходимо рассматривать после сообщений с приоритетами A и B. $LQNone$RQ без приоритета. В случае если реализация сообщения имеет временные (дата, событие) рамки, требуется указать приемлемую дату реализации и мотивацию. |
Добавление файла и записи к сообщению
Изменить сообщение, возможно добавив к нему файл с дополнительной информацией или заметку. При добавлении заметки в ее заголовке ($LQNote Title$RQ) необходимо указать наименование заметки либо выбрать наименование из списка (также, см. рис. 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