Смекни!
smekni.com

Разработка программно–алгоритмических средств для определения надёжности программного обеспечения на основании моделирования работы системы типа "клиент–сервер" (стр. 2 из 13)

Рисунок 1 – Соотношение надежности программы и аппаратуры

Можно выделить три типа системных (программно–аппаратных) компонентов, склонных к отказам:

аппаратные средства системы, отказывающие либо из–за ошибок конструирования, либо из–за ошибок изготовления, либо из–за износа (старения), либо из–за эксплуатации в тяжелых недопустимых по ТУ условиях;

ПО системы, которое может отказать из–за ошибок в спецификациях, в архитектуре, в программном коде;

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

В данной дипломной работе будут рассмотрены вопросы надежности ПО.

В [11] говорится о высокой стоимости ПО как следствие его низкой надежности. Типичное распределение стоимости ПО приведено на рис. 2.

Рисунок 2 – Типичное распределение стоимости ПО

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

1.2 Текущее состояние вопроса

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

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

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

К основным проблемам исследований надежности ПО относятся:

прежде всего – разработка методов оценки и прогнозирования надежности ПО;

определение основных факторов, влияющих на надежность ПО;

разработка методов, обеспечивающих достижение заданного уровня надежности ПО;

совершенствование методов повышения надежности ПО в процессе проектирования и эксплуатации.

Основная причина ошибок в ПО – это его сложность. Для борьбы со сложностью выделяются две концепции:

независимость;

иерархическая структура.

В работе [11] приводится правило "n ± 1": Проверка правильности фазы n проекта должна осуществляться проектировщиками (исполнителями) фаз (n+1) и (n–1). Кроме того, в [11] приводится обоснование необходимости как можно более раннего обнаружения ошибок проектирования ПО. Оно заключается в том, что стоимость исправления ошибки со временем возрастает (рис. 3б), а вероятность правильно исправить ошибку – падает (рис. 3б).

Рисунок 3 – Обоснование необходимости раннего обнаружения ошибки

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

Рисунок 4 – Вероятность обнаружения ошибки и задача оптимизации

На рис.4а изображена зависимость вероятности обнаружить ошибку от времени, а на рис.4б: линия 1 – зависимость вероятности обнаружить ошибку от времени; линия 2 – вероятность исправить ошибку; также представлены области оптимального соотношения и оптимального времени для обнаружения и исправления ошибок в ЖЦ ПО.

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

Процентные частоты появления ошибок в ПО [13-15] по типам ошибок представлены в табл. 2.

Таблица 2 – Процентные частоты появления ошибок в ПО

Тип ошибки Частота появления, %
Не полная или ошибочная спецификация 28
Отклонение от спецификации 12
Пренебрежение правилами программирования 10
Ошибочная выборка данных 10
Ошибочная логика или последовательность операций 12
Ошибочные арифметические операции 9
Нехватка времени для решения 4
Ошибка обработки прерываний 4
Ошибка в исходных данных 3
Неточная запись 8

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

Таблица 3 – Категории ошибок в ПО

Причина ошибки Частота появления, %
Ошибки в числовых значениях 12
Недостаточные требования к точности 4
Ошибочные символы или знаки 2
Ошибки оформления 15
Неправильное описание или требование к аппаратуре 2
Исходные данные для разработки неполные, неточные или ошибочные 52
Двусмысленность требований 13

Из этих таблиц следует, на что нужно обращать особое внимание при проведении валидации и верификации ПО.

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

Программные отказы и аппаратные отказы имеют общие признаки:

объект не выполняет заданной функции;

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

методы обработки статистических данных одинаковы.

И отличия:

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

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

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

аппаратные отказы подразделяют на внезапные и постепенные.

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

Если аппаратная часть жестко задана и интенсивность отказов ее не меняется (только увеличивается в результате старения), то ПО имеет в процессе эксплуатации ряд модификаций с уменьшающейся (в идеале) интенсивностью отказов. Следует иметь в виду, что ПО в ПТС определяет наибольшее количество ошибок. В настоящее время около половины отказов сложных вычислительных систем обусловлено ошибками ПО, а с ростом надежности технических средств составит 90% отказов от общего числа [16].

Можно выделить 4 группы принципов обеспечения надежности:

предупреждение ошибок;

обнаружение ошибок;

исправление ошибок;

обеспечение устойчивости к ошибкам.

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

Возможные действия, направленные на минимизацию ошибок и сбоев: