СЕРТИФИКАЦИЯ И НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Стр 1 из 5Следующая ⇒

СЕРТИФИКАЦИЯ И НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Преподаватель: Чуканов Всеволод Озирисович

Список литературы

Майерс Г. «Надежность ПО», М.: Мир, 1981.
Тейер Т., Липов М., Нельсон Э. «Надежность ПО», М.: Мир, 1981.
Линаев В.В. «Надежность ПО АСУ», М.: Энергоиздат, 1981.
Шураков В.В «Надежность ПО систем обработки данных. Учнбник», М.: Финансы и статистика, 1987.
Мамиконов А.Г., Кульба В.В., Шелков А.Б. «Достоверность, защита и резервирование информации в АСУ», Энергоатомиздат, 1986.
Шураков В.В. «Обеспечение сохранности информации в системах обработки данных (по данным зарубежной печати). Учебное пособие», М.: Финансы и статистика, 1985.
Линаев В.В. «Тестирование программ», М.: Радиосвязь, 1986.

Проблемы надежности ПО

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

Направления исследований в вопросе надежности ПО

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

Основные типы комплексов программ

Программы для решения инженерных и научно-исследовательских задач.

Характеристики:

a. относительно небольшой жизненный цикл;

b. неполное использование ресурсов вычислительной системы;

c. небольшая длительность разработки;

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

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

f. практически всегда имеется возможность достаточно строго проконтролировать выходные данные и при необходимости поставить контрольные эксперименты.

К этому типу программ практически не применимы основные понятия теории надежности.

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

Характеристики:

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

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

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

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

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

Характеристики:

a. обычно практически полностью используют ресурсы вычислительной системы;

b. снабжаются подробной документацией;

c. эксплуатируются долгое время.

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

Факторы, позволяющие анализировать показатели надежности программ 2-го и 3-го типов

Стабильность длительной эксплуатации.

2. Наличие технической документации.

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

Взаимосвязь надежностных характеристик ПО и аппаратуры

Проблемы эталонов

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

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

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

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

Сбой – кратковременный отказ.

λ – интенсивность проявления отказов или ошибок.

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

Затраты на обеспечение надежности должны быть сопоставимы с ущербом в следствии отказа системы.

Ошибки

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

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

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

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

Задача

Проведено прогонов ПО.

Все прогоны начались в момент времени t = 0 (т.е. на нескольких компьютерах параллельно).

Δ t = 500 часов.

Определить вероятность безотказной работы и частоту отказов .

, час.
0 – 500	0, 855	0, 00029
500 – 1000	0, 769	0, 000172
1000 – 1500	0, 692	0, 000154
1500 – 2000	0, 623	0, 000138
2000 – 2500	0, 561	0, 000124
2500 – 3000	0, 505	0, 000112
3000 – 3500	0, 454	0, 00102
3500 – 4000	0, 409	0, 00009
4000 – 4500	0, 368	0, 000082
4500 – 5000	0, 331	0, 000074
5000 – 5500	0, 298	0, 000066
5500 – 6000	0, 263	0, 00007
6000 – 6500	0, 203	0, 00015
6500 – 7000	0, 128	0, 00015
7000 – 7500	0, 066	0, 000124
7500 – 8000	0, 024	0, 000084
8000 – 8500	0, 008	0, 000032

Последовательная

Зависимость программ – отказ одной приводит к отказу всех последующих.

– вероятность безотказной работы всей системы.

– вероятность отказа всей системы.

– вероятность отказа одного элемента.

Это модель для неизбыточных систем.

Параллельная

При отказе одной подсистемы ее функции берет на себя одна из оставшихся. Пример: RAID-массив.

N – кратность резервирования (уровень избыточности).

– вероятность отказа всей системы.

– вероятность безотказной работы всей системы.

– вероятность безотказной работы одного элемента.

Мажоритарная

Система работает с одним и даже двумя отказавшими элементами.

– вероятность безотказной работы всей системы.

– вероятность безотказной работы одного элемента.

– вероятность отказа всей системы.

Экспоненциальная модель

– вероятность отказа одного элемента.

– вероятность безотказной работы одного элемента.

– интенсивность отказов i-ой подсистемы.

t – время.

Основные определения и понятия теории надежности

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

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

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

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

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

Надежность ПО базируется на понятиях корректности и устойчивости.

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

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

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

Критерии надежности

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

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

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

Критерии:

Детерминированные – оценка количества ошибок в программе на том или ином этапе работы.

· Вероятностные – вероятностная оценка свойств ПО.

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

Примеры критериев:

Корректность ПО.
Число серьезных текущих ошибок в программе и время, необходимое для их устранения.
Обслуживаемость системы – степень влияния ошибок ПО на обслуживаемость системы.
Безопасность системы.
Частота отказов.
Вероятность безотказной работы за время t при условии времени отладки .
Средняя наработка на программный отказ при условии исправления или не исправления обнаруженных отказов.

Верификация программ – процесс формального доказательства правильности программы, т.е. корректности.

Верификация:

Статическая – программа рассматривается как материальный объект.
Динамическая (частный случай – тестирование).

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

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

2. После выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО.

3. Имеют место разбросы, вызываемые различием в условиях применения и использования ПО.

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

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

Характеристики ПО

Количественные характеристики (оцениваются числом):

объем программы;
количество спряжений;
количество ветвлений;
точки входа/выхода;
количество процедур;
уровень вложения;
количество комментариев;
количество страниц документации;
требуемое машинное время.

Качественные характеристики (оцениваются числом):

· трудности проектирования;

· трудности в эксплуатации из-за ошибок;

· тип программ;

· данные о персонале (количество, коэффициент загруженности).

Качественные характеристики, как объективное суждение.

Испытания

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

Извещения об ошибке

Исходная информация об ошибках может быть представлена в извещении об ошибке. В них указывается:

Объект затруднения (подсистема, БД, ОС и т.д.).
Дата и время ошибки.
Пример или задача, на которой зафиксирована ошибка.
Конфигурация активной структуры ПО.
Содержание ошибки.
В соответствие ставится извещение о закрытии ошибки, в котором содержится:

· информация о закрытии ошибки;

· генерация новой конфигурации;

· правильность распознавания объекта затруднения;

· существо ошибки.

Классификация ошибок ПО

Где произошла ошибка?

1.1. Персонал

Информация по категориям персонала включает структуру (1.1.1.) и процедуры (1.1.2.). Это операционные процедуры, правила кодирования и проверки, а также стандарты документирования.

1.1.1. Структура

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

b. Административный – определяет администра-тивную информацию.

1.1.2. Процедура

a. Операционные процедуры включают информацию о рабочей среде, т.е. пакетный или интерактивный режим работы, свободный или ограниченный доступ.

b. Правила кодирования и проверки. Они содержат информацию о степени использования, например, структурного программирования.

c. Стандарты документации включают форматы и процедуры документирования данного модуля.

1.2. Оборудование

1.2.1. Компьютер

Перечень оборудования и интерфейсов

1.2.2. Связь

Содержит информацию о внешнем оборудовании в комплекте ПК, включая линии связи с терминалами.

1.2.3. Сопровождающее обеспечение

Информация обо всем оборудовании, подходящем для подготовки модуля и работы.

1.3. ПО

1.3.1. Внутреннее ПО

Языковой процессор, загрузчик, редактор связей, утилиты.

1.3.2. Применение

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

На что похожа ошибка?

2.1. ПО

2.1.1. Внутреннее ПО

ОС, редактор связей, загрузчик, утилиты.

2.1.2. Применение

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

2.2. Функции

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

2.2.1. Процедура

В процедурах ввода/вывода подразумевается наличие неправильных значений данных.

2.2.2. Использование ресурса

При использовании ресурсов наиболее критичными ошибками являются:

· неправильное использование терминальных устройств;

· ошибки синхронизации;

· ошибки в описании форматов вводимой и выводимой информации.

2.3. Ресурсы

2.3.1. Имя

2.3.2. Использование ресурса

2.4. Область

2.4.1. Структура программы

2.4.2. Приложение

Как была сделана ошибка?

3.1. Данные

3.1.1. Входные

3.1.2. Внутренние

3.2. Процедуры

3.2.1. Вычисление

3.2.2. Контроль

3.2.3. Интерфейс

Когда была сделана ошибка?

4.1. Начальная разработка

4.2. Внедрение

4.3. Функционирование

Почему произошла ошибка?

5.1. Механические

5.1.1. Подстановка

5.1.2. Путаница

5.1.3. Пропуск

5.2. Умственные

5.2.1. Концептуализация

5.2.2. Реализация

5.3. Коммуникационные

5.3.1. Персонал

5.3.2. Документация

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

Модели надежности ПО

Модель Джелинского-Моранда

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

M – неизвестное первоначальное число ошибок

i – число обнаруженных ошибок, зависящих от времени t

k – константа

Частота обнаружения i-ой ошибки задается соотношением

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

Минусы модели

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

Модификация формулы для С, если не все ошибки обнаружены:

j – найденные внесенные ошибки, j < S

Еще один график, который полезно строить во время тестирования – это текущее значение верхней границы k для некого доверительного уровня.

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

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

Имитационные модели

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

Часто программу представляют как последовательность узлов, дуг и петель ориентированного графа.

Узлы – точки в которых части программы объединяются или разъединяются.

Дуги – последовательности линейных участков. В них размещаются команды.

Методы тестирования

Восходящее тестирование

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

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

Нисходящее тестирование (нисходящая разработка)

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

Возникают 2 проблемы

1. Что делать, когда тестируемый модуль вызывает модуль более низкого уровня, которого в данный момент еще не существует?

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

2. Как подаются тестовые данные?

Плюсы метода

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

Минусы метода

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

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

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

Метод большого скачка

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

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

Метод «сэндвича»

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

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

Модифицированные метод «сэндвича»

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

СЕРТИФИКАЦИЯ И НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

12 3 4 5 Следующая ⇒