Тема 9. Таблицы трассировки

Мадорская Ю.М.

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

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

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

Самое важное — это то, что никакое требование не существует отдельно от других проектных данных. Оно обязательно должно быть связано напрямую или косвенно, например, с элементом структуры системы (в английской терминологии это называется allocation и является одной из задач проектирования).
Требования также могут быть связаны с конкретными заказчиками. С требованиями могут быть связаны риски.
И, конечно, требования часто взаимозависимы, а значит эти связи также должны быть отражены в проекте.
И так далее, в соответствии с выбранной моделью трассировки.

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

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

В Cradle можно настроить очень много удобных представлений для анализа проектных связей. Технически они делятся на три класса:

  • Таблицы трассировки
  • Матрицы трассировки
  • Иерархические диаграммы трассировки

— это три разных способа показать связи между проектными данными.

Сегодня мы посмотрим подробнее на таблицы трассировки.
Они основаны на Представлениях, которые мы уже немного разбирали (в рамках отображения загруженных требований (8)).
Далее иллюстрации.

На этой иллюстрации представлена типичная структура таблицы трассировки. Слева отображается один тип элементов, справа — элементы другого типа, связанные с теми, что справа. В данном случае эта таблица отражает риски, связанные с требованиями, а заоднопоказывает вероятность этих рисков.

Что можно быстро увидеть по этой таблице? Например, Тр1 — какое-то подозрительно рискованное, с ним связано аж два риска, один из них с высокой вероятностью. Возможно стоит это требование исключить или наоборот, уделить ему больше внимания.

traceability_table

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

report

А вот еще одно представление (не из демо-проекта), с таблицей трассировки. В этот раз от бизнес-целей к бизнес-правилам. Это уже более сложное иерархическое представление, для его генерации используется рекурсия (представление вызывает само себя).
Здесь мы видим, какие накладываются ограничения на наши бизнес-цели. Это демо-проект, поэтому конкретные цели/требования не указаны, но если бы он был наполнен реальными данными, вся картина проблем, задач и ограничений была бы как на ладони.

traceability_table2

Еще несколько примеров. Трассировка от Требований к «Фичам»
верификация

Трассировка от тестов к требованиями. Сразу можем видеть, по каким требованиям не прошли тесты. Обратите внимание, что некоторые тесты покрывают несколько требований.

тесты

И трассировка через три типа элементов — от результатов тестов, к тесткейсам и требованиям

тесты-3 типа

Еще один пример совершенно иной таблицы трассировки через три типа элементов (Доска Scrum) Релизы-User Stories-Задачи, связанные с каждой пользовательской историей

scrum_board