Матрица трассируемости (или матрица трассировки) - эффективный и простой инструмент, часто используемый при разработке программного обеспечения. Зачастую это инструмент аналитика, но может использоваться всеми проектными ролями. Основное назначение матрицы трассировки:
- визуализирует причинно-следственные связи или их отсутствие между требованиями различных типов (бизнес и системные)
- визуализирует связи или их отсутствие между артефактами смежных фаз разработки продукта: требованиями и реализацией, требованиями и тестированием, требованиями и пользовательской документацией.
Вот пример матрицы трассировки, демонстрирующей покрытие требований тестовой и пользовательской документацией, реализацией:
Матрица трассируемости применяется при любых уровнях зрелости процессов разработки и управления требованиями и способах упаковки требований:
- Если при разработке продукта выделяются стадия бизнес-анализа, стадии системного анализа и проектирования.
- Если в проекте используется только стадия системного анализа, либо проектирования.
- Если при выявлении и разработке требований участвует вся команда и документирует их в форме пользовательских историй.
Где применять?
Матрица трассируемости применима практически на всех этапах процесса разработки и позволяет:
- Контролировать целостность разрабатываемого продукта, выявлять расхождения между тем, что требуется и тем, что реализуется.
- Существенно сократить время на анализ изменений, последующих за появлением новой доработки.
- Поддерживать артефакты в актуальном состоянии.
Управление потребностями - фиксируем хотелки и пожелания из различных источников в баклоге продукта (системы или сервиса), при этом мы
- хотим понять, как именно были учтены исходные пожелания, когда они будут реализованы;
- хотим проверить, учли ли мы все важные пожелания в очередной версии бизнес-требований или версии продукта.
Бизнес-анализ - формируем понимание о проблемной области и сводим различные источники слабо проработанных требований (пожеланий) в формализованных бизнес-требованиях, при этом мы
- хотим понять, откуда появилось бизнес-требование, какая у него важность;
- хотим понять, как будут реализованы бизнес-требования путем изучения системных требований;
- хотим проверить, все ли необходимые бизнес-требования отражены в системных требованиях.
Управление продуктом - фиксируем фичи продукта (функции продукта) для последующего контроля за сроками их реализации и одновременно:
- хотим понять, как именно реализуются фичи продукта, через какие системные требования, когда они будут реализованы;
- хотим проверить, учли ли мы все важные фичи в очередной версии продукта.
Системный анализ и проектирование - разрабатываем системные (функциональные и нефункциональные) требования на основе бизнес-требований или доработок к системе, в процессе работы мы:
- хотим понять, откуда появилось системное требование, какая у него важность и кто источник;
- хотим проверить, все ли необходимые системные требования запланированы в работу;
- хотим понять, в какой версии и когда будут реализованы системные требования;
- хотим оценить фактическую трудоемкость реализации системных требований;
- хотим понять, как проверяются требования тестировщиками;
- хотим понять, каким образом документируются требования.
Управление изменениями - оцениваем трудоемкость и стоимость изменений, планируем реализацию изменений и обновление необходимой проектной документации:
- хотим оценить, сколько системных требований придется переработать при изменении бизнес-требования;
- хотим понять, какие именно доработки нужно выполнить, чтобы реализовать новое пожелание или изменение в бизнес-требовании;
- хотим оценить, каков будет объем изменений (или трудоемкость) в коде, тестовой и пользовательской документации, при изменении системного требования;
- хотим понять, какие именно изменения необходимо внести в тестовую и пользовательскую документацию, при изменении системного требования;
- хотим понять, какие участки системы необходимо переработать при обнаружении дефекта в требовании.
Контроль качества - разрабатываем тестовую документацию и планы тестирования на основе системных требований, при этом
- хотим оценить качество тестового сценария, разработанного на основе требования;
- хотим оценить полноту покрытия требований тестовой документацией.
Разработка пользовательской и эксплуатационной документации основана на системных требованиях и для контроля мы хотим оценить полноту покрытия требований тестовой документацией.
Использование инструмента
Использование столь эффективного и полезного инструмента, как матрицы трассировки, доступно только в интегрированных решениях (Application Lifecycle Management). Возможности по связыванию различных артефактов и их трассировке вы найдете во многих продуктах, но в Devprom.ALM есть ряд существенных преимуществ:
- Автоматическое создание связей между артефактами при выполнении задач участниками проекта, вам не нужна специальная должность, ответственная за формирование матриц трассировки.
- Помощь со стороны системы в отслеживании и уведомлении о неактуальных связях, например, когда требование изменилось, а тестовая и справочная документация требует обновления.
- Быстрый доступ к матрицам трассировки, без необходимости создания отчетов и настройки фильтров.
Попробуйте поработать с матрицами трассировки в демонстрационном проекте, чтобы лучше понять возможности и преимущества этого инструмента.
|
