Статический анализ исходных текстов программ должен включать следующие технологические операции:

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;

· контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

1. Контроль полноты и отсутствия избыточности

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

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

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

2. Контроль соответствия исходных текстов программного обеспечения

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

Берутся предоставленные исходные тексты (*) и производится их контрольная сборка – т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2)

В случае отсутствия исходных текстов используются два подхода:

1. С восстановлением исходных текстов:

· дизассемблирование;

· статический анализ;

· динамический анализ;

· с использованием отладчиков;

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

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

2. Без восстановления исходных текстов – использование эмуляторов

Для контрольной сборки, помимо собственно исходных файлов, желательно иметь и среду сборки (т.е. все компиляторы и компоновщики, которые использовал разработчик – иначе, при полностью самостоятельной сборке в лаборатории, расхождения по контрольным суммам почти гарантированно (т.е. собранные модули будут отличаться от модулей зафиксированного ПО). Наилучший вариант – когда контрольная сборка производится либо на стенде разработчика (один или несколько компьютеров необходимых для cборки ПО, предоставляемые разработчиком и полностью готовые к сборке ПО), либо непосредственно у разработчика.

Последовательность действий при выполнении трансляции исходных текстов, версия транслятора, а также исходные данные (директивы) для транслятора должны соответствовать приведённым в сопроводительной документации.

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

3.2.4. Отчётность

По окончании испытаний оформляется отчёт (протокол), содержащий результаты:

· контроля исходного состояния программного обеспечения;

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

· контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду.

3.3. Требования к третьему уровню контроля

3.3.1. Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав программного обеспечения, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2. Контроль исходного состояния программного обеспечения

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

3.3.3. Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);

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

· контроль связей функциональных объектов (модулей, процедур, функций) по информации;

· контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

· формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

Лекция № 13