52
предусмотрены внутренние переменные, которые не соответствуют регистрам
эмулированной системы, то в качестве представителя класса берется одна из
переменных. В противном случае берется вторая переменная класса. Пример
тестирования программного обеспечения в среде QEMU приведен на рисунке 9.
Рисунок 9 – Пример тестирования программного обеспечения в среде
QEMU
Выполним описание процесса оптимизации. Если определено состояние
всех переменных в момент начала осуществления операции, то эта операция
входит в состав операций пересылки переменных А=В, принадлежащих одному
из классов эквивалентности.
В этом случае одна из инструкций будет заменяться на другую. В случае
если операция пересылки осуществляется из разных классов то переменная А
будет при переходе в другой класс эквивалентной. При этом если переменная А
является представителем в своем классе эквивалентности, то в этом классе
необходимо выбрать нового представителя по описанным правилам и
выполнением обновления.
53
Также устанавливается пометка, что переменная А входит в состав копий
представителей класса эквивалентности в состав которого входит переменная
В. При этом переменная B может быть заменена на представителя своего
класса. Если операция входит в состав операций пересылки, то переменные A и
B являются константами. Если переменная А является представителем класса
эквивалентности, то в этом классе необходимо выбрать нового представителя.
Если все аргументы арифметической операции являются константами, то
значение переменной А вычисляется, а операция является операцией пересылки
данных.
Пример выполнения оптимизации в среде QEMU с применением тестов
набора SPEC CPU2000 приведен в таблице 4.
Таблица 4 – Пример выполнения оптимизации в среде QEMU с
применением тестов набора SPEC CPU2000
Название теста
Тестирование без
оптимизации, с
Тестирование с
оптимизацией, с
%
164.gzip
754,45
751,19
0,43
175.vpr
728,84
719,84
1,23
176.gcc
459,47
459,95
-0,1
181.mcf
119,4
118,99
0,35
186.crafty
705,12
712,58
-1,06
197.parser
1709,33
1687,56
1,27
252.eon
1496,51
1490,66
0,39
253.perbmk
1173,34
1164,48
0,76
256.bzip2
665,53
659,77
0,87
300.twolf
1479,2
1467,94
0,76
Как видно из таблицы 4, наблюдается оптимизация на всех тестах, кроме
176.gcc и 186.crafty. Оптимизация программного кода при тесте 176.gcc
находится в пределах точности измерений. Для теста 186.crafty наблюдается
ухудшение процесса оптимизации.
На следующем этапе выполним выявление недостатков в методах по
оценке качества программного обеспечения.
54
2.3. Выявление недостатков в методах по оценке качества программного
обеспечения
В настоящее время в ОАО «Аурат» для оценки качества программного
обеспечения применяется автоматизированная система оценки качества
программных средств, которая позволяет хранить, обрабатывать полученные
результаты оценки качества программного обеспечения на различных стадиях
жизненного цикла.
Для выявления недостатков в методах по оценке качества программного
обеспечения ОАО «Аурат» будем использовать нотацию UML, которая
позволит определить выполняемые процессы в автоматизированной системе
оценки качества программных средств.
Язык моделирования UML является унифицированным языком и
стандартным инструментом для анализа функций работы программного
обеспечения. С его помощью можно специфицировать, визуализировать,
документировать артефакты программных продуктов
59
.
Диаграмма вариантов использования позволяет описать функциональное
назначение системы, то есть выделить функции, которые ею выполняются в
процессе работы.
Диаграмма вариантов использования позволит оценить работу
специалистов ИТ-отдела ОАО «Аурат» с автоматизированной системой оценки
качества программных средств, порядок действий при работе с системой для
оценки качества программного обеспечения.
Представим процесс работы с автоматизированной системой оценки
качества программного обеспечения в ОАО «Аурат» с помощью диаграммы
вариантов использования, приведенной на рисунке 10.
59
Степанова М. А. Разработка методов и средств комплексной оценки качества систем
защиты программного обеспечения // Вестник ОрелГИЭТ, 2016. - №2. – С.88-92
55
Рисунок 10 – Диаграмма вариантов использования
Как видно из рисунка 10, к основным вариантам использования при
работе с автоматизированной системой оценки качества программного
обеспечения в ОАО «Аурат» относятся:
- работа со справочниками через формы V1, V2 посредством
формирования запросов к базе данных OKPS через технологию OLE;
- создание проекта по оценке качества программного обеспечения через
форму YYY с использованием такого же интерфейса, что и при работе со
справочниками;
- оценка качества программного обеспечения через форму ZZZ с
использованием такого же интерфейса, что и при работе со справочниками;
- работа с документами по проектам оценки качества программной
системы через форму ССС с использованием текстового редактора и файла;
56
- работа с отчетами по проектам оценки качества программного
обеспечения через форму ААА также с применением текстового редактора и
файла.
В качестве пользователей автоматизированной системой оценки качества
программного обеспечения в ОАО «Аурат» выступают исполнитель или
сотрудник ИТ-отдела и эксперт (программист). Работу со справочниками
автоматизированной системой оценки качества программного обеспечения в
ОАО «Аурат» выполняет администратор баз данных.
Диаграмма вариантов использования для работы администратора баз
данных приведена в приложении Б. Как видно из приложения Б, в состав
автоматизированной системе оценки качества программного обеспечения ОАО
«Аурат» входят такие справочники как:
- справочник «Заявитель», который используется для регистрации заявок
на проведение оценки качества программного обеспечения;
- справочник «Исполнитель», в котором ведется учет специалистов
выполнивших оценку качества программного обеспечения (специалисты ИТ-
отдела ОАО «Аурат»);
- справочник «Критерии качества ПС» применяется для создания
критериев для оценки качества программного обеспечения (например,
надежность, отказоустойчивость);
- справочник «Оценочные элементы» для формирования шкалы оценки
для оценки работы программного обеспечения экспертами;
- справочник «Типы ПС» для ведения учета типов программного
обеспечения в зависимости, от которых подбираются метрики.
Диаграмма вариантов использования формы для создания проекта по
оценке качества программного обеспечения приведена в приложении В.
Модуль создания проекта для оценки качества программного
обеспечения используется исполнителем (программистом) ОАО «Аурат» и
позволяет выполнить следующие функции:
- выбрать исполнителя и эксперта проекта и тип программного средства;
57
- выбрать процесс жизненного цикла программного средства и фазы
жизненного цикла программного средства;
- выбрать критерии и метрики качества для каждого фактора, в том числе
базовые показатели и весовые коэффициенты;
- выбрать оценочные элементы и методы оценки для каждой метрики;
- создать и сохранить список планируемых показателей и характеристик
качества проекта;
- выполнить печать списка планируемых показателей и характеристик
качества проекта.
Диаграмма вариантов использования модуля для оценки качества
программного обеспечения приведена на рисунке 11.
Рисунок 11 –Диаграмма вариантов использования модуля для оценки
качества программного обеспечения ОАО «Аурат»
58
В качестве пользователя модуля для оценки качества выступает эксперт,
который осуществляет ввод значений оценочных элементов по каждой метрике,
а затем с помощью модуля определяет относительные значения факторов
качества, сравнивает полученные оценочные значения с базовыми значениями,
проводит оценку результатов и сохраняет результаты оценки качества.
Функция ввода оценочных элементов для каждой метрике включает в
свой состав подфункцию сохранения и расширения, а функция вычисления
относительных значений факторов выполняется в соответствии с ГОСТ 28195-
99 и включает в свой состав определение усредненных значений оценочных
элементов по каждой метрике, а также расчет итоговых оценок метрик.
Диаграмма вариантов использования модуля для создания документов по
проектам оценки качества приведена на рисунке 12.
Рисунок 12 – Диаграмма вариантов использования модуля для создания
документов по проектам оценки качества
59
В качестве пользователя в системе выступает или исполнитель
(программист ОАО «Аурат»), который использует модуль для создания
документов по проектам оценки качества. В состав модуля входят функции для
создания заявки на проведение оценки качества, решения об отказе проведения
оценки качества или проведении оценки качества. Также в модуле можно
разработать договор для проведения оценки качества и создания акта о
результатах оценки качества. Все функции расширяются подфункциями
редактирования, добавления, печати.
Диаграмма вариантов использования модуля «Работа с отчетами по
проектам оценки качества» приведена на рисунке 13.
Рисунок 13 – Диаграмма вариантов использования модуля «Работа с
отчетами по проектам оценки качества»
60
Как видно из рисунка 13, к функциям модуля для создания отчетов
относятся поиск отчетов по проектам, создание отчета о текущих проектах,
создание отчета со списком проектов по исполнителям, создание отчета со
списком проектов по заказчикам, печать отчета и его сохранение.
Недостатком автоматизированной системы является то, что она не
позволяет проводить тестирование программного обеспечения на основе
символьного выполнения и не позволяет исключить критические ошибки и
уязвимости при автоматизации процессов качества программного обеспечения.
Выводы по главе 2
На основании выполненного анализа методов работы и оценки качества
программного обеспечения ОАО «Аурат» можно сделать следующие выводы:
1. Оценка работы обфускаторов по различным метрикам показала, что
наибольшую защиту программному обеспечению позволяет обеспечить
обфускатор eazfuskator, показавший наибольшие результаты по метрикам
Джилба, Чепина и Хансена. Поэтому рекомендуем специалистам ОАО «Аурат»
использовать его в большей степени для защиты программного обеспечения.
2. Анализ оптимизации в среде QEMU с применением тестов набора
SPEC CPU2000 показал, что наблюдается оптимизация на всех тестах, кроме
176.gcc и 186.crafty. Оптимизация программного кода при тесте 176.gcc
находится в пределах точности измерений. Для теста 186.crafty наблюдается
ухудшение процесса оптимизации.
3. Недостатком автоматизированной системы является то, что она не
позволяет проводить тестирование программного обеспечения на основе
символьного выполнения и не позволяет исключить критические ошибки и
уязвимости при автоматизации процессов качества программного обеспечения.
61
ГЛАВА 3. РАЗРАБОТКА РЕКОМЕНДАЦИЙ ПО
СОВЕРШЕНСТВОВАНИЮ МЕТОДОВ ОЦЕНКИ КАЧЕСТВА
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОАО «АУРАТ»
3.1. Предложения по совершенствованию статических методов
оптимизации динамической двоичной трансляции и проведению
тестирования программ на основе динамического символьного
выполнения
Для совершенствования статистических методов оптимизации
предлагаем использовать программу Valgrind, которая является
инструментальным программным обеспечением, позволяющим отлаживать и
обнаруживать ошибки в программном коде, а также повышать качество
программного обеспечения. Она вначале транслирует среду тестирования в
промежуточное представление IR (Intermediate Representation), которое
машинно-независимо и размещено в SSA-форме, затем добавляет в
программный код инструкции и на завершающем этапе производит трансляцию
этого представления обратно в машинный код.
Как и в случае с программой QEMU, в качестве единицы двоичной
трансляции выступает расширенный базовый блок. До начала процесса
аннотирования программного кода и после его завершения отладочными
инструкциями программы Valgrind производится машинно-независимая
оптимизация на уровне промежуточных представлений
60
.
Из промежуточных представлений на фазе выбора инструкций
получается низкоуровневое промежуточное представление, близкое к языку
Ассемблер целевой машины, но в его основе находятся виртуальные регистры.
Реальные регистры применяются в тех случаях, когда не существует
альтернатив.
60
Ярошик А. А. Программное обеспечение для анализа качества работы алгоритмов
компьютерного зрения // Международный студенческий научный вестник, 2018. - №3. –
С.523-527