WorkProductDescriptor
Рабочий продукт (Артефакт): Запрос изменения
Эти артефакты применяются для документирования и отслеживания запросов на изменения продукта. Предоставляется запись решения и, с помощью соответствующего процесса оценки, гарантируется, что влияние изменения является обдуманным.
Назначение
  • Для формулировки и отслеживания изменений и дефектов
Взаимосвязи
РолиОтветственный: Изменен:
Выход из
Описание
Основное описание

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

 Запросы на изменения также известны как CR, дефекты, ошибки, инциденты, запросы на расширения. Соответственно фиксация этих запросов и управление ними гарантирует, что изменения вносятся в систему под контролем, так что их влияние на систему предсказуемо. Ниже перечислены некоторые важнейшие типы Запросов на изменения:

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

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

Цель дефекта - сообщить сведения о неполадке, вызвав корректирующее действие, разрешение вопроса, и проследив происхождение неполадки. CR используется следующими сотрудниками:

  • Набор ролей: Аналитики  используют CR для определения существенных изменений в рекомендациях высокого уровня и для определения требований на их основе, особенно на основе CR, указанных в запросах на расширение.
  • Набор ролей: Руководители  используют CR для управления назначением работ и контроля за ним.
  • Набор ролей: Ответственные за тестирование  используют CR для описания сбоев (дефектов), пропусков и вопросов, связанных с качеством, обнаруженных во время тестирования программного обеспечения.
  • Набор ролей: Разработчики используют CR для анализа неполадок и обнаружения лежащих в основе сбоев или причин неполадок с целью разрешения CR.
  • Роль: Аналитик тестов  использует CR для планирования тестов, предназначенных для проверки разрешенных CR, и для оценки усилий на тестирование путем анализа набора дефектов для измерение тенденций в качестве программного продукта и процесса разработки программы.
Краткая схема

Пример формы запроса на изменение

  1. Идентификация

  • Проект:
  • Номер запроса на изменение:
  • Тип запроса на изменение: (Неполадка или расширение)
  • Заголовок:
  • Дата отправки:
  • Отправитель:
  • Приоритет запроса на изменение:
  1. Текущая неполадка

  • Описание текущей неполадки:
  • Критический сбой:
  • Ущерб:
  • Расширение:
  • Новое требование:
  • Условия, при которых наблюдалась неполадка:
  • Текущая среда: Аппаратное обеспечение
  • Компилятор операционной системы:
  • Источник текущей неполадки:
  • Влияние текущей неполадки на стоимость или сбережения:
  1. Предлагаемое изменение (отправитель)

  • Описание предлагаемого изменения:
  • Оценочная стоимость внесения предлагаемого изменения:
  1. Предлагаемое изменение (группа просмотра изменений)

  • Действие:
  • Утверждено:
  • Не утверждено:
  • Отложено:
  • Описание предлагаемого изменения:
  • Затронутые элементы конфигурации:
  • Категория:
  • Исправление ошибки:
  • Расширение:
  • Новая функциональная возможность:
  • Прочее:

  1. Решение

  • Оценочная стоимость внесения предлагаемого изменения:
  • Ответственный за реализацию:
  • Фактическое время на реализацию изменения:
  • Анализ:
  • Реализация:
  • Тест:
  • Документация:
  • Затронутое число строк исходного кода:
  1. Оценка

  • Методы тестирования
  • Проверка
  • Анализ
  • Демонстрация
  • Тестирование
  • Тестовые платформы
  • Прецеденты тестирования
  1. Размещение группы просмотра изменений

  • Утвержденные и принятые изменения
Свойства
Необязательный
ЗапланированныйYes
Доводка
Опции представления

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

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

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



Дополнительные сведения