2. Проверяются все возможные исходные информационные состояния модуля, которые характеризуются различной степенью полноты входной информации Xi, а также покрытие области возможных значений {Xi} некоторой сеткой, определяемой методами планирования эксперимента.
В результате дублер-разработчик выдает в контролирующие органы разработчика вариант выверенного алгоритма Аi, и исходные данные автономных тестов {Xi}w, на множестве возможных значении W параметров Xi, модели угроз.
Утвержденные контролирующими органами алгоритмы Аi, заносятся в базу алгоритмов системы поддержки ИБТ (СП ИБТ).
На этапе разработки исходных текстов программ модуля Ui - дублер-разработчик проводит статический анализ исходных текстов программ и динамический анализ исходных программных модулей. Статический анализ включает сверку текста программ с утвержденным алгоритмом и логический анализ эффективности и безопасности программы. Динамический анализ включает тестовые испытания программного модуля рi,скомпилированного на основе исходных текстов Ui по программе {Xi}w, утвержденной на предыдущем этапе. Результатом динамического автономного анализа, наряду с качественными оценками, являются значения векторов выходных параметров Уi дубл..[Хiw] {w}=W, сформированных в виде таблиц проверок.
Решение об утверждении исходных текстов формируются на основе анализа результатов тестирования программ основным разработчиком и дублером на основе критерия:
max ½Yi [Xi] w – Уi дубл. [Xi] w ½ dYi ,
где: Yi [Xi] w - результаты тестирования программы основным разработчиком, Уi дубл. [Xi] w - результаты тестирования программы дублером, dYi - допустимые отклонения вектора выходных данных.
В случае удачных тестовых испытаний утвержденный алгоритм заносится в базу эталонных текстов СП ИБТ.
На этапе продуцирования загрузочного модуля дублирование заключается в независимом от основного разработчика продуцирование эталонного загрузочного модуля, полученного компилированием эталонного исходного текста из базы исходных текстов.
В последующем, при модернизации алгоритма, эта процедура повторяется по независимым от разработчика правилам.
Сравнение эталона с модулем разработчика производится администратором СП ИБ1 с помощью специальных программ обработки, использующих анализ контрольных сумм, побайтовое сравнение с эталонном и другие алгоритмы, для контроля несанкционированных изменений, вносимых в программы. Основные организационные методы использования СП ИБТ и принципы ее организации изложены в п. 6.3.
На последующих этапах проектирования дублер-разработчик проводит комплексный динамический анализ продукта Рi, основного разработчика на контрольно-испытательном моделирующем стенде.
Исходные данные моделирования определяются комплексными тестами, полученными с помощью моделей угроз для подсистем и системы в целом.
По характеру исследований контрольно-испытательные стенды можно классифицировать как стенды статистических исследований и натурные диалоговые стенды.
К стендам первой категории предъявляются требования работы в ускоренном режиме времени. В связи с этим моделирование среды ВС-оператор полностью автоматизируется.
Стенды второй категории предназначены для проверки функционирования СПО совместно с графическими интерфейсами ввода-вывода, В связи с этим реализация этих стендов должна быть максимально приближена к реальной. Однако, при этом возникают трудности с реализацией режима ускоренного времени, что сокращает возможности перебора большого количества исходных значений Xi.
Элементы данной технологии в применении к анализу качества и надежности СПО СУ, а также технология создания СПО моделирующих стендов отработана в Отраслевой научно-исследовательской лаборатории системного моделирования Санк-Петербургского морского технического университета.
6.3.1. Организационные меры СП ИБТ
Для создания СПО с учетом его безопасности от закладки предлагается следующая организация проведения работ коллективом программистов-разработчиков (рис.6.3):
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.