Матрица трассируемости (traceability matrix)

08.04.2010 18:09

Матрица трассируемости (или матрица трассировки) - эффективный и простой инструмент, часто используемый при разработке программного обеспечения. Зачастую это инструмент аналитика, но может использоваться всеми проектными ролями. Основное назначение матрицы трассировки:

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

Вот пример матрицы трассировки, демонстрирующей покрытие требований тестовой и пользовательской документацией, реализацией:

Матрица трассируемости применяется при любых уровнях зрелости процессов разработки и управления требованиями и способах упаковки требований:

  • Если при разработке продукта выделяются стадия бизнес-анализа, стадии системного анализа и проектирования.
  • Если в проекте используется только стадия системного анализа, либо проектирования.
  • Если при выявлении и разработке требований участвует вся команда и документирует их в форме пользовательских историй.

Где применять?

Матрица трассируемости применима практически на всех этапах процесса разработки и позволяет:

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

Управление потребностями - фиксируем хотелки и пожелания из различных источников в баклоге продукта (системы или сервиса), при этом мы

  • хотим понять, как именно были учтены исходные пожелания, когда они будут реализованы;
  • хотим проверить, учли ли мы все важные пожелания в очередной версии бизнес-требований или версии продукта.

Бизнес-анализ - формируем понимание о проблемной области и сводим различные источники слабо проработанных требований (пожеланий) в формализованных бизнес-требованиях, при этом мы

  • хотим понять, откуда появилось бизнес-требование, какая у него важность;
  • хотим понять, как будут реализованы бизнес-требования путем изучения системных требований;
  • хотим проверить, все ли необходимые бизнес-требования отражены в системных требованиях.

Управление продуктом - фиксируем фичи продукта (функции продукта) для последующего контроля за сроками их реализации и одновременно:

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

Системный анализ и проектирование - разрабатываем системные (функциональные и нефункциональные) требования на основе бизнес-требований или доработок к системе, в процессе работы мы:

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

Управление изменениями - оцениваем трудоемкость и стоимость изменений, планируем реализацию изменений и обновление необходимой проектной документации:

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

Контроль качества - разрабатываем тестовую документацию и планы тестирования на основе системных требований, при этом

  • хотим оценить качество тестового сценария, разработанного на основе требования;
  • хотим оценить полноту покрытия требований тестовой документацией.

Разработка пользовательской и эксплуатационной документации основана на системных требованиях и для контроля мы хотим оценить полноту покрытия требований тестовой документацией.

Использование инструмента

Использование столь эффективного и полезного инструмента, как матрицы трассировки, доступно только в интегрированных решениях (Application Lifecycle Management). Возможности по связыванию различных артефактов и их трассировке вы найдете во многих продуктах, но в Devprom.ALM есть ряд существенных преимуществ:

  • Автоматическое создание связей между артефактами при выполнении задач участниками проекта, вам не нужна специальная должность, ответственная за формирование матриц трассировки.
  • Помощь со стороны системы в отслеживании и уведомлении о неактуальных связях, например, когда требование изменилось, а тестовая и справочная документация требует обновления.
  • Быстрый доступ к матрицам трассировки, без необходимости создания отчетов и настройки фильтров.

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

Еще интересные статьи на эту тему: