4.8. Трассировочные таблицы

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

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

Так, например, часто применяемая практика заключается в том, что каждое требование в документах помечается уникальным идентификатором – якорем (anchor). Якоря в требованиях могут иметь, например, следующий формат:

[ANCHOR: код]

Где код записывается в виде AAA_RR_NNNNNN, где AAA – тип документа (SYS, ORD и т.п.), RR – номер раздела верхнего уровня, в котором содержится якорь и NNNNNN – номер ссылки с ведущими нулями.

Требование в таком виде будет выглядеть следующим образом:

Для каждого вычислимого атрибута должна быть определена роль, от которой производится вычисления. [ANCHOR: SYS_02_000084]

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

[REF: код]

Где код имеет тот же формат, что и для якоря, ссылка на требования будет иметь следующий вид:

Для доступа к названию роли в формуле расчета значения вычислимого атрибута должна использоваться мнемоника [RoleName]. [ANCHOR: SRD_02_000058] [REF: SYS_02_000084].

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

• обычная гиперссылка;

• ссылка требований нижнего уровня на требования верхнего уровня;

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

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

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

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

4.8.2. Возможные формы трассировочных таблиц

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

	SYS_01_0001	SYS_01_0002	SYS_01_0003	SYS_01_0003
SRD_01_0001	cross-ref			variant
SRD_01_0002	based on		variant
SRD_01_0003	based on			variant
SRD_01_0004		cross-ref	variant

В первом столбце перечислены якоря требований к программному обеспечению, в первой строке – якоря системных требований. На пересечении указаны типы ссылок – cross-ref – обычная информационная перекрестная ссылка, based on – требование к ПО основано на данном системном требовании, variant – может использоваться либо одно, либо другое требование к ПО в зависимости от варианта системы.

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

РД СВТ	Protection Profile	Protection Profile глава 6	Protection Profile главы 1-4	Комментарии
2.2.2 КСЗ должен требовать от пользователей идентифицировать себя при запросах на доступ.	5.2.2.4 FIA_UID.1.2	286, 288	82 O.USER_AUTHENTICATION, O.USER_IDENTIFICATION, 57 Identification&Authentication, 80 P.I_AND_A, 58 Non-bypassability
2.2.2 КСЗ должен подвергать проверке подлинность идентификации - осуществлять аутентификацию.	5.2.2.3 FAI_UAU.1.2	277, 280		В названии трассировочного тега опечатка. Правильно - FIA_UAU.1.2
2.2.2 КСЗ должен препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась.	5.1.3.1	286, 287		5.1.3.1 - необходимые данные для аутентификации - атрибуты учетной записи пользователя

Здесь РД СВТ – документ Гостехкомиссии РФ, включающий в себя требования по защищенности средств вычислительной техники [5], Protection Profile – один из аналогичных документов, используемых в США. Таблица представляет собой трассировку требований РД СВТ на требования различных глав Protection Profile. В первой строке указаны главы, а в ячейчах – конкретные разделы.