Оценку структурной (топологической) и информационной сложности ПО в настоящее время проводят различными способами, которые можно разделить на метрики сложности потока управления и метрики сложности потока данных [16]. Метрики сложности потока управления связывают сложность ПО со сложностью структуры передач управления при работе оцениваемого ПО. Оценку сложности потока управления проводят с помощью следующих методов:

а) Метрика Холстеда.

Метрика Холстеда [17] используется для численной оценки сложности программы. Исходными данными для нее являются:

• количество уникальных операндов в программе;

• количество операторов в программе;

• общее количество операторов данного языка программирования. Метрика Холстеда заключается в следующем.

Введем обозначения:

- число уникальных операторов в программе,

- число уникальных операндов, в программе,

- словарь программы,

- общее число операторов в программе,

- общее число операндов в программе,

- длина программы.

Тогда объем программы вычисляется по формуле:

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

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

• дополняющие друг друга операции;

• синонимические операнды;

• неоднозначные операнды;

• наличие общих подвыражений;

• ненужное присваивание;

• нефакторизированные выражения.

Потенциальный объем ПО вычисляется по формуле:

где - число входных и выходных данных программы.

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

По уровню программы можно судить об избыточности программы. При этом более качественные (неизбыточные) программы имеют большее значение уровня.

Зависимости, используемые в метрике Холстеда, вытекают из положений теории информации. Используя метрику Холстеда, можно оценить теоретическую длину конкретной программы, ее объём, избыточность реализации алгоритма и численно оценить уровень языка программирования, на котором написана программа. Важно отметить, что эта оценка будет достаточно правдоподобной. Правдоподобность такой оценки подтверждается проведенным корреляционным и регрессионным анализом на примере типичных программных модулей. [18]

б) Метрика Маккейба.

Метрика Маккейба [19] использует графовое представление структуры программы - структурное дерево программы (СДП) и структуры передач управления при ее работе между операторами, или, на более высоком уровне, между модулями - управляющий граф программы (УГП). Такое представление позволяет оценить сложность программы различными методами. Например, методами алгебры графов оценивают связность построенного УГП и, таким образом, оценивают степень отличия данного УГП от графа типа «дерево», что характеризует структурную сложность программы :

где: - количество ребер в графе вызовов модулей (УГП);

- количество вершин в УГП.

Для структурированной программы характерна простая структура УГП (дерево).

Сложность программы по Маккейбу (цикломатическое число СДП программы, или модуля) оценивается по следующей формуле:

где: - число дуг в графе логической структуры модуля (СДП);

- число вершин в графе.

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

Метрика Маккейба исследована в современных работах. Например, в [20] сложность программы оценивается по количеству тестов, необходимых для покрытия всего УГП программы. В построенном УГП программы выделяются вычислительные траектории (ВТ), т.е. полная последовательность всех операторов со значениями их операндов и вычислительные пути, т.е. совокупность всех ВТ, имеющих идентичную последовательность одних и тех же операторов. Вводится понятие неизбыточного теста программы - такого теста И, что существует покрытая им вычислительная траектория в УГП, не покрытая ни одним из предыдущих тестов. Тогда, сложность программы измеряется как трудоемкость тестирования, или минимальное число неизбыточных тестов, покрывающие все вычислительные траектории УГП. Существуют также автоматизированные системы, позволяющие строить УГП и оценивать количество тестов, необходимых для полного покрытия данного УГП, и, таким образом, автоматически оценивать сложность ПО. Недостатком таких автоматизированных систем является следующее. По мере увеличения сложности оцениваемого ПО количество вычислительных ресурсов, необходимых для работы автоматизированной системы, резко возрастает из-за резкого увеличения количества вычислительных траекторий в УГП.

Существуют усовершенствованные метрики, основанные на метрике Маккейба, например, метрика Майерса[21].

в) Метрика Джилба.

Метрика Джилба [16] оценивает сложность программы. Она основана на подсчете количества условных конструкций типа и, несмотря на простоту, дает хорошие результаты. В работе [16] эта метрика дополнена учетом максимального уровня вложенности базовых структурных конструкций (следование, условие, цикл).

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

Проанализируем эти методы.

Метрика «модуль - глобальная переменная» оценивает сложность программы, связывает сложность программ с обращениями к глобальным переменным.

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

г) Метрика Чепина [19] оценивает сложность программы. В данной метрике все переменные разбиваются на четыре класса по характеру использования - переменные, используемые для расчета, модифицируемые или создаваемые внутри программы, управляющие и паразитные. Далее по формуле вычисляется значение метрики. Существуют несколько вариантов этой метрики. Рассмотрим более простой, а с точки зрения практического использования - достаточно эффективный вариант этой метрики.

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

1. Множество «» - вводимые переменные для расчетов и для обеспечения вывода. Примером может служить используемая в программах лексического анализатора переменная, содержащая строку исходного текста программы, то есть сама переменная не модифицируется, а только содержит исходную информацию.

2. Множество «» - модифицируемые или создаваемые внутри программы переменные.

3. Множество «» - переменные, участвующие в управлении работой программного модуля (управляющие переменные).

4. Множество «» - не используемые в программе («паразитные») переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.

Далее вводится значение метрики Чепина:

где: - весовые коэффициенты.

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

Структурность

Структурность ПО - это организация всех взаимосвязанных частей ПО в единое целое с использованием логических структур «следование», «условие», «цикл». Основы структурной технологии проектирования ПО изложены в работе [22]. Необходимость оценки данного показателя связана с тем, что от структурности ПО напрямую зависит удобство сопровождения и модификации ПО. Кроме того, при строгом соблюдении технологии структурного проектирования ПО, количество ошибок в нем значительно снижается. Существует несколько метрик для оценки структурности ПО, например, метрика структурности программы, основанная на оценке линеарности УГП - «подсчете точек пересечения» дуг графа программы . Полученная оценка линеарности УГП может использоваться для оценки меры неструктурированности программы. Данное предположение основано на том, что структурные конструкции при представлении их управляющим графом планарны и, таким образом, точка пересечения дуг в УГП появляется только при наличии неструктурной конструкции. Следовательно, по их количеству можно оценить неструктурированность программы.

Наглядность

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

где: - количество комментированных строк исходного текста программы;

- общее количество строк исходного текста программы.

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

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

Наглядность ПО можно также косвенно оценить по его структурности. При этом более структурированное ПО имеет более высокую наглядность.

Повторяемость

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

1.4.2 Показатели надежности

Надежность ПО - это способность ПО в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями [15]. В понятии надежности ПО обычно выделяют два понятия[23]:

• работоспособность ПО, т.е. способность ПО выполнять свои функции в соответствии с программными документами;

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

Сравнительно недавно начали появляться методы оценки надежности, разработанные специально для оценки надежности ПО. Они используют понятие математической модели надежности программы (МНП). МНП - это математическое выражение, связывающее один или несколько показателей надежности ПО с непосредственно измеренным параметром, характеризующим ПО в некоторой среде. Иными словами, это предельно абстрагированная математическая модель программы, в которой отсутствуют детали, не влияющие на надежность. Это заметно упрощает процедуру оценки надежности программы [24].

Среди МНП можно выделить следующие:

• априорные МНП (АМН);

• эмпирические МНП (ЭМН);

• полные (ПМН).

В основе АМН лежат такие характеристики ПО, как объем, сложность и характеристики процесса создания. С помощью АМН можно оценить показатели надежности ПО до начала его испытаний. Существующие на сегодняшний день АМН пока не позволяют применить их на практике, в основном, это оценка сложности разрабатываемого ПО, например, по метрике Холстеда, и попытка связать ее с надежностью будущего ПО. Точная взаимосвязь сложности ПО с его надежностью пока неясна. Так как главным, если не единственным источником ошибок является программист, то здесь необходимо привлекать дисциплины, изучающие самого человека.

В ЭМН используется информация, полученная в процессе функционирования ПО (отладки и т.д.). Эмпирические МНП делятся на:

• непрерывные ЭМН. Если ЭМН имеет в качестве одного из аргументов время, то такая модель называется непрерывной ЭМН (НЭМН).

• дискретной ЭМН (ДЭМН), если время отсутствует, а используется порядковый номер испытания.

Для получения необходимой для ЭМН информации пользуются результатами отладки ПО в процессе разработки, результатами бета-тестирования (тестирования предварительной или окончательной версии ПО в условиях, близких к реальным, группой специально подготовленных пользователей - бета-тестеров).

Непрерывные эмпирические математические модели надежности ПО характерны тем, что в список их аргументов, входит время работы ПО, но это не совсем корректно отражает работу ПО на современных компьютерах, так как они работают фиксированными дискретными порциями времени - тактами.

В настоящее время наиболее известной НЭМН является модель Шумана. Согласно этой модели интенсивность отказов определяется тем, насколько часто в процессе выполнения программы приходится сталкиваться с дефектами. То есть, интенсивность отказов зависит от количества обнаруженных дефектов. Если допустить, что интенсивность отказов пропорциональна количеству обнаруженных ошибок, то можно получить экспоненциальную модель. В этой модели предполагается, что зависимость интенсивность проявления ошибок остается постоянной до тех пор, пока не исправлен дефект в программе, вызывающий эти ошибки (первичная ошибка). Если каждая обнаруженная ошибка исправляется, то значения промежутков времени между их проявлениями изменяются по экспоненциальному закону. Исследования, проведенные на ряде комплексов крупных программ, показали, что распределение числа накопленных ошибок от времени их обнаружения хорошо аппроксимируется экспонентой. Значение коэффициента корреляции примерно равно 0,85. Пропорциональность частот обнаружения ошибок и их исправления можно объяснить тем, что исправления сами могут вносить дополнительные ошибки, и тем, что внесенное исправление может исправлять сразу несколько связанных ошибок. Эта гипотеза хорошо подтверждается статистическими исследованиями, проведенными при разработке крупных комплексов ПО. При этих допущениях получим:

где: - коэффициенты пропорциональности, учитывающие масштаб времени, используемого при описании процесса обнаружения ошибок,

- интенсивность проявления ошибок при нормальном функционировании ПО,

- число оставшихся ошибок,

- число обнаруженных ошибок,

- общее число ошибок в программе, .

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

Пусть = 1, то есть время отладки соответствует реальному времени, тогда получим:

Отсюда число обнаруженных ошибок вычисляется по формуле:

а число оставшихся в ПО первичных ошибок при времени отладки равно:

Эти выводы согласуются со статистикой, собранной при разработке больших комплексов ПО. Их можно использовать для расчета требуемого времени отладки для достижения нужной степени тестированности ПО. Если известны все моменты обнаружения ошибок, и в эти моменты обнаруживается и устраняется одна первичная ошибка, то по собранной статистике можно корректировать коэффициенты , добиваясь большего соответствия экспоненциальной МНП характеристикам реального ПО.[29]

Существует еще ряд других НЭМН, например, модели Вейса, Формана, Хетагурова, Минаева.

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

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

где: - число успешных испытаний,

k - априори известное число типов дефектов,

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

В современном производстве МНП пока не получили широкого распространения. Оценка надежности ПО ведется в основном с помощью тестирования, что ведет к некоторой неопределенности понятия «надежность» конкретного ПО. В связи с этим появилась юридическая практика распространения и продажи ПО по принципу «как есть» («as is»). Согласно этому принципу фирма-изготовитель ПО не несет ответственности ни за возможные ошибки, содержащиеся в данном ПО, ни за возможные их побочные эффекты (сбои и зависания компьютеров, или даже необратимую потерю содержимого носителей информации).

В соответствии с вышеизложенным можно сделать вывод о том, что разработка реально применимых МНП является актуальной задачей.

1.4.3 Показатели удобства применения программного обеспечения

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

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

• Доступность эксплуатационных программных документов - понятность, наглядность и простота описания в эксплуатационных программных документах (ПД). Для понятия качества ПД характерны некоторые особенности качества ПО:

- Понятность. ( понятен читающему его человеку)

- Завершенность. (содержатся все элементы, перечисленные в его оглавлении, и с достаточной точностью и полнотой отражает аспекты принятых технических решений)

- Осмысленность. (не содержит избыточной информации)

- Согласованность. (содержит единую нотацию, терминологию, символику, смысловую связь внутри себя, с другими документами и с ПО)

- Самоопределенность. (его взаимосвязанные части, разделы и подразделы, организованы в единое целое определенным образом).

- Полнота. (соответствует требованиями к структуре и содержанию документа.)

- Идентифицируемость. (содержит всю информацию о полном наименовании документа, дате завершения его разработки и о его разработчике)

• Удобство эксплуатации и обслуживания - это соответствие процесса обработки данных и форм представления результатов характеру решаемых задач. Трудно поддается формализации оценке, поэтому оценивается при помощи методов экспертной оценки и бета-тестирования.

1.4.4 Показатели эффективности программного обеспечения

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

• Уровень автоматизации - степень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов.

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

• Ресурсоемкость ПО - минимально возможные вычислительные ресурсы и число обслуживающего персонала для эксплуатации данного ПО. Оценивается путем практических испытаний ПО в условиях, близких к реальной эксплуатации, или в течение пробного периода эксплуатации.

1.4.5 Показатели универсальности программного обеспечения

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

• Гибкость. Характеризует возможности использования ПО в различных областях применения.

• Мобильность. Характеризует возможность применения ПО на ЭВМ аналогичного класса. Примером такого ПО является ПО, написанное для операционных систем (ОС) UNIX-клона, например, Linux, FreeBSD, Solaris. Подавляющее большинство ПО для этих ОС распространяется в виде исходных текстов на языках С, Perl, Python, LISP и компилируется только при инсталляции на конкретную ЭВМ.

• Модифицируемость ПО характеризует простоту внесений необходимых изменений и доработок в программу в процессе ее эксплуатации.

1.4.6 Показатели корректности программного обеспечения

Показатели корректности ПО характеризуют степень соответствия ПО требованиям, установленным в техническом задании (ТЗ), требованиям к обработке данных и общесистемным требованиям. Включает следующее:

• Логическая корректность

• Полнота реализации

• Согласованность

• Проверенность

Рассмотрим подробнее все эти показатели.

Логическая корректность ПО - функциональное и программное соответствие процесса обработки данных общесистемным требованиям. Характеризует неидеальность реализации алгоритма из-за ограниченности возможностей аппаратных средств, для которых написано ПО. Самой точной и надежной оценкой корректности является полная верификация - перебор всех возможных наборов данных и сравнение результатов работы программы на каждом наборе данных с эталоном.[16] Однако, при большом наборе данных такой подход требует огромных временных и денежных затрат. Поэтому для особо ответственного ПО применяют частичную верификацию. Ведется создание автоматических верификаторов. Здесь возникает еще одна проблема - создание эталонных результатов, с которыми будут сравниваться результаты работы верифицируемого ПО и проверка его корректности. Для оценки корректности также применяются выработанные практикой эвристические методы. Кратко их проанализируем.

Метод Миллса. В программу специально вводится некоторое количество ошибок для последующей отладки специалистами. После отладки количество найденных введенных ошибок сопоставляется с количеством найденных собственных ошибок программы, и делается вывод о количестве еще оставшихся ошибок.

Метод «штурма». Для отладки одного из модулей ПО привлекается весь коллектив разработчиков, все найденные ошибки учитываются. Таким образом, после такой отладки данный модуль станет практически безошибочным. Интенсивность ошибок по длине тестируемого модуля вычисляется по формуле:

где: В - число обнаруженных ошибок;

N - длина тестируемого модуля.

Тогда, коэффициент тестированности модуля равен:

где: - число ошибок, обнаруженных в модуле до начала совместной отладки.

Оценка общего количества ошибок во всем ПО равна:

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

Также, существует оценка полноты реализации заданного алгоритма обработки данных в процессе разработки ПО, :

где: - количество реализованных модулей,

- количество еще не реализованных модулей («модулей-заглушек»).

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

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

где: - число модулей, отработавших в процессе тестирования,

- общее число модулей.

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

Разработка метода экспертных оценок показателей качества

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

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

В данной методике подход к оценке показателей качества основан на понятии нечеткого множества Л.Заде [26]. Формализация нечетких понятий по Заде предполагает отказ от основного положения теории множеств об однозначной принадлежности элемента некоторому множеству. Нечеткое множество определяется как совокупность упорядоченных пар, составленных из элементов , и соответствующих степеней принадлежности и обозначается следующим образом:



где: - функция принадлежности, выражающая степень принадлежности элемента х к множеству ;

- область определения функции принадлежности

Функция принадлежности является специальной характеристической функцией нечеткого множества А и принимает значения из интервала [0; 1]. Область определения функций принадлежности, рассматриваемых в данной методике, определяется метрикой показателя качества и для общности представляется интервалом [0; 1], на котором введена сетка точек действительной числовой оси, расположенных с шагом 0,005 (сетка может быть иной).

В процессе получения оценок используются нечеткие числа (L-R)-типа, определенные на интервале [0; 1].

Нечеткое число может быть задано с помощью функции принадлежности (L-R)-типа следующим образом:

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

- среднее значение (четкое число),

- левый и правый коэффициенты нечеткости соответственно.

Нечеткое число записывается в виде тройки: Нечеткое число является характеристикой ПО по определенному показателю качества (нечеткое значение показателя качества).

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

• очень хорошо (очень высокие требования);

• хорошо (высокие);

• почти хорошо (почти высокие);

• между хорошим и средним (высоким и средним);

• чуть более среднего;

• среднее;

• чуть менее среднего;

• между средним и плохим (средним и низким);

• почти плохо (почти низкие);

• плохо (низкие);

• очень плохо (очень низкие требования).

Каждому лингвистическому значению соответствует стандартное нечеткое число , например, в одной из реализаций данной методики, лингвистическим значениям соответствуют следующие нечеткие числа:

(1,0.045,0.045) -- очень хорошо;

(1,0.1025,0.1025) -- хорошо;

(0.875, 0.08,0.08) -- почти хорошо;

(0.75, 0.07, 0.07) --между хорошим и средним;

(0.625,0.06,0.06) -- чуть более среднего;

(0.5,0.045,0.045) -- среднее;

(0.375, 0.06,0.06) -- чуть менее среднего;

(0.25, 0.07,0.07) --между средним и плохим;

(0.125, 0.08,0.08) -- почти плохо;

(0,0.1025,0.1025) --плохо;

(0,0.045,0.045) -- очень плохо,

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

Значения функций принадлежности находятся по формуле:

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

Обобщенная функция принадлежности по всем экспертам получается с использованием меры согласованности мнений экспертов:



где - функция принадлежности, отражающая мнение i-го эксперта.

Обобщенная функция принадлежности вычисляется следующим образом:

где - коэффициент компетентности i-го эксперта.

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

1.5 Постановка задачи оценки защищенности ПО

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

• знание назначения испытываемого СПО, условий его функционирования и требований к нему со стороны пользователей;

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

• ясное представление цели и последовательности испытания;

• целенаправленность и неизбыточность испытания, исключающие или минимизирующие повторение однородных процедур при одних и тех же условиях функционирования испытываемого СПО;

• систематический контроль за ходом, регулярное ведение протокола и журнала испытания;

• четкое, последовательное определение и исполнение плана испытания;

• четкое сопоставление имеющихся ресурсов с предполагаемым объемом испытания;

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

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

ГЛАВА 2. МЕТОДЫ ЗАЩИТЫ ПРОГРАММНОГО

ОБЕСПЕЧЕНИЯ, ИХ ОЦЕНКА И АНАЛИЗ ЗАЩИЩЕННОСТИ

2.1 Методы технологической защиты ПО и их оценка

эффективности

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

2.1.1Аппаратные средства защиты программного обеспечения

Аппаратные ключи защиты

Основой данной технологии является специализированная микросхема, либо защищённый от считывания микроконтроллер, имеющие уникальные для каждого ключа алгоритмы работы. Ключ представляет собой плату, защищённую корпусом, в архитектуру которой обязательно входят микросхемы памяти и, иногда, микропроцессор. Ключ может подключаться в слот расширения материнской платы ISA, или же к LPT, COM, PCMCIA, USB-порту компьютера. В его программное обеспечение входит модуль, который встраивается в защищаемое ПО (таким образом данное программное обеспечение "привязывается" к ключу, а не к конкретному компьютеру), и драйвера под различные операционные системы. Ключи в большинстве своём основаны на одной из трёх моделей существующих аппаратных реализаций: на основе FLASH-памяти, PIC или ASIC-чипов. Помимо этого, в некоторые ключи встраиваются дополнительные возможности в виде энергонезависимой памяти, таймеров, выбора алгоритма кодирования данных.

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

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

На российском рынке наиболее известны следующие линейки продуктов (в алфавитном порядке): CodeMeter от WIBU-SYSTEMS, Guardant от компании «Актив», HASP от Aladdin, LOCK от Astroma Ltd., Rockey от Feitian, SenseLock от Seculab и др.

Аппаратные ключи защиты можно классифицировать по нескольким признакам:

• типы подключения (ключи на порт принтера (LPT), последовательный порт (СОМ), USB-порт и ключи, подключаемые к специальной плате, вставляемой в компьютер);

• удобство и функциональность программного обеспечения;

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

• список поддерживаемых аппаратных платформ и операционных систем;

• применимость ключа для сетевого лицензирования программного обеспечения;

• по архитектуре можно подразделить на ключи с памятью (без микропроцессора) и ключи с микропроцессором (и памятью).

Виды ключей:

Ключи с памятью

Это, наверное, самый простой тип ключей. Ключи с памятью имеют определенное число ячеек, из которых разрешено считывание. В некоторые из этих ячеек также может производиться запись. Обычно в ячейках, недоступных для записи, хранится уникальный идентификатор ключа.

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

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

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

Ключи с неизвестным алгоритмом

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

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

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

В рекомендациях по защите программ с помощью аппаратных ключей даются советы, как сделать фиктивные запросы со случайными данными так, чтобы затруднить построение эмулятора. Однако если программа при запуске делает 100 запросов, результат которых может быть проверен, и 100 случайных запросов, результат которых не проверяется, то, запустив программу 10 раз, очень легко выделить действительные запросы, повторившиеся 10 раз, и отсечь все фиктивные, встретившиеся по 1-2 раза.

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

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

Атрибуты алгоритмов

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

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

Однако все достоинства алгоритмов, активируемых по паролю, опираются на секретность пароля, а не на свойствах аппаратного ключа. Следовательно, аналогичная защита может быть реализована чисто программными средствами. Другой тип атрибутов алгоритмов, поддерживаемых ключами Sentinel SuperPro, - это счетчики. С активным алгоритмом может быть связан счетчик, изначально имеющий ненулевое значение. Программа при каждом запуске (или выполнении определенной операции, например при экспорте данных) вызывает специальную функцию API-ключа, уменьшающую значение счетчика на единицу. Как только счетчик принимает нулевое значение, алгоритм деактивируется и перестает работать.

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

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

Ключи с таймером

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

Ключи HASP Time предоставляют возможность узнавать текущее время, установленное на встроенных в ключ часах. И защищенная программа может использовать ключ для того, чтобы отследить окончание тестового периода. Но очевидно, что эмулятор позволяет возвращать любые показания таймера, т. е. аппаратная часть никак не повышает стойкость защиты. Хорошей комбинацией является алгоритм, связанный с таймером. Если алгоритм может быть деактивирован в определенный день и час, очень легко будет реализовывать демонстрационные версии программ, ограниченные по времени.

Но, к сожалению, ни один из двух самых популярных в России разработчиков аппаратных ключей не предоставляет такой возможности. Ключи HASP, производимые компанией Aladdin, не поддерживают активацию и деактивацию алгоритмов. А ключи Sentinel SuperPro, разработанные в Rainbow Technologies, не содержат таймера.

Ключи с известным алгоритмом

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

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

Так что аппаратное выполнение симметричного алгоритма шифрования с известным ключом не дает ничего нового с точки зрения защиты. Но есть еще и асимметричные алгоритмы.

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

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

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

Ключи с программируемым алгоритмом

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

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

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

Обход защиты

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

• Перехватывать все обращения к ключу;

• Протоколировать и анализировать эти обращения;

• Посылать запросы к ключу и получать на них ответы;

• Протоколировать и анализировать эти ответы;

• Посылать ответы от имени ключа и др.

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

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

Стоит отметить, что современные электронные ключи (к примеру, ключи Guardant поколения Sign и современные ключи HASP HL) обеспечивают стойкое шифрование протокола обмена электронный ключ - библиотека API работы с ключом. В результате наиболее уязвимыми местами остаются точки вызовов функций этого API в приложении и логика обработки их результата.

Эмуляция ключа

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

Построить полный эмулятор современного электронного ключа - это достаточно трудоёмкий процесс, требующий большого количества времени и существенных инвестиций. Ранее злоумышленникам это удавалось: например, компания Aladdin признаёт, что в 1999 году злоумышленникам удалось разработать довольно корректно работающий эмулятор ключа HASP3 и HASP4. Это стало возможным благодаря тому, что ключ использовал проприетарный алгоритм кодирования, который был взломан. Сейчас большинство ключей используют публичные крипотоалгоритмы, поэтому злоумышленники предпочитают атаковать какой-то конкретный защищённый продукт, а не защитный механизм в общем виде. Для современных систем защиты HASP и Guardant эмуляторов в свободном доступе нет, так как используется публичная криптография.

Информации о полной эмуляции современных ключей Guardant не встречалось. Существующие табличные эмуляторы реализованы только для конкретных приложений. Возможность их создания была обусловлена неиспользованием (или неграмотным использованием) основного функционала электронных ключей разработчиками защит.