Верификация программного обеспечения (стр. 27 )

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

[ANCHOR: код]

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

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

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

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

[REF: код]

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

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

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

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

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

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

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

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

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

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. В первой строке указаны главы, а в ячейчах – конкретные разделы.

Формальные инспекции (лекции 9-10) Задачи и цели проведения формальных инспекций

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

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

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

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

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

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

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

Рис. 21 Место формальной инспекции в проекте по разработке программной системы

Этапы формальной инспекции и роли ее участников

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

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

Инициализация

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

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