Надежность программного обеспечения как инженерного продукта

Обновлено: 07.07.2024

1. Основные понятия и определения надежности программного обеспечения.

2. Показатели надежности программного обеспечения.

3. Причины отказов программного обеспечения, признаки появления ошибок.

4. Способы обеспечения и повышения надежности программ.

Рекомендуемые файлы

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

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

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

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

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

Безотказность программы или программного обеспечения есть его (ее) свойство сохранять работоспособность при использовании в процессе обработки информации на компьютере.

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

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

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

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

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

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

Корректность программы – ее соответствие спецификации.

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

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

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

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

Основными причинами непосредственно вызывающими нарушение нормального функционирования программы, являются [1, 2, 3, 10, 11]:

1. ошибки, скрытые в самой программе;

2. искажения входной информации, подлежащей обработке;

3. неверные действия пользователя;

4. неисправность аппаратуры установки, на которой реализуется вычислительный процесс.

1. Скрытые ошибки программы являются главным фактором нарушения нормальных условий его функционирования;

Можно выделить следующие основные ошибки в программе:

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

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

· Ошибки ввода-вывода – связаны с такими действиями, как управление вводом-выводом, формирование выходных записей и определение размеров записей.

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

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

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

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

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

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

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

· сбои и отказы в аппаратуре ввода данных с первичных носителей информации;

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

Признаки появления ошибок

Наиболее типичными симптомами появления ошибок в программе являются:

· преждевременное окончание выполнения программы;

· недопустимое увеличение времени некоторой последовательности команд одной из программ;

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

· нарушение последовательности вызова отдельных программ, в результате чего происходит пропуск необходимых программ;

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

Способы обеспечения и повышения надежности программ

Они определены на следующие основные категории:

1. усовершенствование технологии программирования;

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

3. резервирование программ – дуальное или N -версионное программирование, другие методы введения структурной избыточности;

4. контроль и тестирование программ с последующей коррекцией.

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

Результаты вычислений искажаются погрешностями:

· исходных данных, трансформированными в ходе вычислений:

· обусловленными отказами, сбоями и ошибками в программе.

Контрольные вопросы и задания

1. Что понимается под надежностью программного обеспечения (ПО)?

2. Что такое корректность ПО?

3. От чего зависит восстанавливаемость ПО компьютера и КС?

4. Определите основные причины отказов ПО.

5. Какие существуют пути повышения надежности ПО компьютеров и КС?

6. Почему при мультипрограммной обработке информации используют принцип виртуальных машин?

7. Какой из способов обеспечения надежности программ считается более эффективным?

К числу основных факторов, влияющих на надежность ПО отнесены:

 взаимодействие ПО с внешней средой (программно-аппаратная

средства, трансляторы, ОС). Этот фактор вносит наименьший вклад в

надежность ПО при современном уровне надежности аппаратуры, ОС и

 взаимодействие с человеком (разработчиком и пользователем) (см.

 организация ПО ( проектирование, постановка задачи и способы их

достижения и реализации) и качество его разработки. Этот фактор вносит

В борьбе со сложностью ПО используются две концепции :

Иерархическая структура . Иерархия позволяет разбить систему по

уровням понимания (абстракции, управления). Концепция уровней позволяет

анализировать систему, скрывая несущественные для данного уровня детали

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

Независимость. В соответствии с этой концепцией, для минимизации

сложности, необходимо максимально усилит ь независимость элементов

системы. Это оз начает такую декомпозици ю системы, чтобы её

высокочастотная динамика была заключена в отдельных компонентах, а

межкомпонентные взаимодействия (связи) описывали только

Методы обнаружения ошибок , которые базируются на введении в ПО

Временная избыточность . Использование части производительности

ЭВМ для контроля исполнения и восстановления работоспособности ПО

Информационная избыточность. Дублирование части данных

информационной системы для обеспечения надёжности и контроля

Программная избыточность включает в себя: взаимное недоверие -

компоненты системы проектируются, исходя из предположения, что другие

компоненты и исходные данные содержат ошибки, и должны пытаться их

обнаружить; немедленное обнаружение и регистрацию ошибок; выполнение

одинаковых функций разными модулями системы и сопоставление

результатов обработки; контроль и восстановление данных с использованием

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

применение методов минимизации ущерба, вызванного появлением ошибок,

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

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

 предотвращение ошибок за счет структурного программирования;

 сокрытие информации или дозированный доступ к данным со стороны

программных средств и объектов в объектно-ориентированном

 обработка исключительных ситуаций (перехват ошибок, например,

В соответствии с ГОСТ 19.004-80 различают следующие виды работ,

направленные на устранение ошибок в ПО : проверка, отладка и испытание

Чем интенсивнее использ ование программного изделия (ПИ), тем быстрее

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

обнаруженных ошибок от числа использующих ПИ пользователей:

Рис. 1 Интенсивность обнаружения ошибок от интенсивности использования

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

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

Ошибочная логика или последовательность операций 12

Как видно из таблицы 1 основное количество ошибок делается из-за

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

Неправильное описание или требование к аппаратуре 2

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

при проведении валидации и верификации ПО (верификация отвечает на

вопрос, правильно ли и качественно ли создана программа, а валидация (или

аттестация) - на вопрос правильно ли работает программа).

На основании м етодов обнаружения ошибок были разработаны

Средства, использующие врем енную избыточность : авторизация

доступа пользователей к систем е, анализ доступных пользователю ресурсов,

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

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

информационную избыточность : ссылочная целостность баз данных

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

информационных записей системы, открытая система кодирования,

позволяющая пользователю в любой момент изменять коды любых объектов

классификации, обеспечивает стыковку системы классификации АИС

делопроизводство с ПО других разработчиков, м еханизмы проверки

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

несанкционированных модификаций (ошибок, сбоев) информации.

 усовершенствование технологии программирования (например,

формальное описание этапов программирования при помощи языка UML);

 выбор алгоритмов, не чувствительных к различного рода нарушениям

вычислительного процесса (использование алгоритмической избыточности);

 резервирование программ - N -версионное программирование;

 верификация и валидация программ с последующей коррекцией.

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

 прежде всего - разработка методов оценки и прогнозирования

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

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

 совершенствование методов повышения надежности ПО в п роцессе

Важным этапом жизненного цикла ПО, определяющим качество и

надёжность системы, является тестирование . Тестирование - процесс

выполнения программ с намерением найти ошибки и включает в себя

Надежность ПО повышается также с помощью применения различных

методов тестирования . Полное тестирование ПО невозможно. Обычно

 математическое доказательство правильности алгоритма решения

задачи ( в некоторых работах именно в этом смысле употребляется слово

 символическое тестирование (или с помощью специально подобранных

тестовых наборов), еще называется статическим тестированием. Удобно при

локализации ошибки, проявление которой выявлено при конкретном узком

 динамическое тестирование (с помощью динамически генерируемых

входных данных), что удобно при быстром тестировании во всем широком

 проверка по использованию ресурсов и стрессовое тестирование.

 По количеству характеризуемых свойств различают единичные и

комплексные показатели. Единичные показатели качества характеризуют

одно из свойств ПС, комплексный – несколько. Комплексные показатели

могут быть групповыми, обобщенными или интегральными.

 В зависимости от места применения в процедуре оценки уровня

качества ПС различают базовые и относительные показатели. Базовым

значением показателя качества продукции называют значение показателя,

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

Относительное значение показателя качества продукции представляет

собой отношение ф актического значения показателя качества оцениваемой

 По стадии определения значений показателей качества

различают прогнозируемые, проектные, производственные и

эксплуатационные показатели . Прогнозируемыми показателями оперируют

на стадиях выполнения научно-исследовательских работ и составления ТЗ на

разработку ПС, т. е. на тех стадиях, когда нет еще ни детального проекта ПС,

ни, тем более, самого ПС. Значения прогнозируемых показателей в основном

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

Значения проектных показателей определяют на основе анализа проектов

ПС ( эскизного, технического, рабочего), а также путем испытания опытного

• устойчивость (robustness) или отказоустойчивость (fault-tolerance) — способность продолжать правильно работать после отказов.

Улучшение первого качества достигается хорошей технологией, предупреждающей ошибки (fault-avoidance). Здесь уместно сказать о надёжности языка программирования. Под надёжностью ЯП будем понимать его свойство, которое характеризуется_вероятностью безошибочного написания и трансляции программ заданного размера. Это определение нуждается в пояснениях. Во-первых, ошибки в написании программы зависят не только (и не столько!) от свойств языка, сколько от квалификации программиста. Поэтому надежность языка — понятие относи тельное; можно представить себе, что один и тот же программист, в равной мере владеющий двумя языками, при использовании одного из них совершает в программе меньше ошибок, чем при использовании другого. Следовательно, вполне естественно говорить, что первый из этих языков более надежен. Во-вторых, в определение вошел также процесс трансляции. Это объясняется двумя причинами. Во-первых, надежность транслятора связана со свойствами языка, во-вторых, способность транслятора обнаруживать ошибки тоже в значительной мере зависит от конструкции языка. Например, указание типа данных, принятое в большинстве распространенных языков, повышает надежность языка, поскольку компилятор осуществляет проверку соответствия типов переменных, участвующих в операции. Однако наличие правила объявления по умолчанию, призванного облегчить труд программиста, может существенно усложнить дело. Однако 100%-ное отсутствие ошибок недостижимо. Устойчивость должна быть относительно любых видов отказов, для ее поддержания создаются специальные программно-аппаратные средства.

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

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

Классификация причин отказов:

1. Физические дефекты:

• внутренние (старение, износ);

• внешние воздействия (радиация, высокая температура).

• ошибки эксплуатации или взаимодействия;

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

Восстановление (Recovery) — возврат в исправное состояние путем:

• ручного ремонта, замены, исправления;

• автоматически — задействованием резервов;

• самопроизвольно, обычно быстро.

Типичный пример восстановления — с помощью резервной (backup) копии данных. Если выполнить восстановление в латентном периоде отказа, то он никогда не проявится вовне — в этом состоит идеальная отказоустойчивость.

1. Количественные характеристики надежности программ

Надежность нужно оценивать, измерять, предсказывать — обеспечивать заданные требования к надежности в проекте и проверять их выполнение в продукте [3].

где λ — интенсивность отказов (обычно в 1/час).

В табл. 5.4 приведены средние значения MTBF для устойчивых отказов:

Большие интегральные схемы

Таким образом, программы вносят наибольший вклад в (не)надежность современных вычислительных систем. Между тем существуют столь ответственные (mission-critical) приложения, где требуется очень малая вероятность отказов. Например, для бортовой системы управления космическим зондом требуется λ=10 -9 , чтобы вероятность устойчивого отказа в первые 10 лет работы была не более 10 -4 (или вероятность безотказной работы 0,9999), что означает MTBF = 100 тысяч лет!

Вообще говоря, λ не постоянна во времени. Для аппаратуры характерна зависимость вида рис. 5.3.

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

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

где Т — общее время работы; T np — время простоя из-за восстановлений.

В ответственных системах требуется, чтобы значение к почти не отличалось от 1: для цифровых АТС — 2 часа простоя суммарно за 15 лет; для системы управления воздушным движением — 3 с за год!

1. Методы оценки и измерения характеристик надежности

Как проверить соответствие ПП таким требованиям?

Пусть внесено s ошибок, обнаружено n собственных и v внесенных ошибок. Предполагая, что вероятность обнаружения внесенных и собственных ошибок одинакова, получим первоначальное количество оставшихся ошибок N=sn/v. Проверка гипотезы: осталось k и s/(s + к + 1) при n

В методе Руднера (1977 г.) тестирование осуществляется двумя независимыми группами тестеров параллельно, они обнаруживают m 1 и m 2 ошибок соответственно, из которых m 1,2 ошибок — общие. Используя гипергеометрическое распределение, методом максимального правдоподобия может быть найдена оценка числа первоначально содержавшихся в программе ошибок N = m 1 m 2 /m 1,2 .

1. Модель последовательности испытаний Бернулли

Рассмотрим для простоты класс программ, имеющих единственный вход и выход, т.е. не содержащих бесконечных циклов. Фазу выполнения программы от начала до завершения будем называть запуском. Все возможные результаты запуска разобьем на два класса: правильные и неправильные (ошибочные). Будем считать, что любой результат всегда можно отнести к одному из этих классов. (Ясно, что по этому вопросу возможны разногласия между изготовителями программы и пользователями, однако будем предполагать, что имеется какой-то общий критерий, например, "клиент всегда прав".) Рассмотрим классическую вероятностную модель последовательности испытаний Бернулли. Пространство элементарных событий в этой модели содержит 2 n точек, где n - число испытаний (в данном случае под испытанием подразумевается запуск программы). Каждый запуск программы имеет два исхода: правильный и неправильный. Обозначим вероятность неправильного исхода р, а вероятность правильного - (1-р). Вероятность того, что из n запусков k приведут к неправильному результату, выражается хорошо известной формулой биномиального распределения ([4]).

B(p,n,k) = C(n,k) * p k * (1-р) (n-k) , (1)

где C(n,k) - число сочетаний. Вероятность р априори неизвестна, но по результатам запусков известны пик. Величина В как функция р имеет максимум при

В качестве меры надежности программы можно принять величину

R = 1 - k/n = (n-k)/n, (3)

значения которой (от 0 до 1) согласуются с общепринятым смыслом термина надежность: например, если все запуски окончились с ошибочным результатом (k= n), то надежность -нулевая.

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

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

Формула (3) позволяет оценить надежность программы по результатам ее запусков. Следует особо остановиться на двух предельных случаях: k - n (нулевая надежность) и k = 0 (абсолютная надежность). В обоих случаях результаты не следует интерпретировать буквально: нет никаких гарантий того, что очередной запуск приведет к тому же реультату, что и предыдущие. Однако с точки зрения пользователя эти случаи совершенно разные. Если нулевая надежность свидетельствует о том, что программа явно непригодна для эксплуатации, то показатель абсолютной надежности не должен вводить в заблуждение: такой вывод нельзя делать по результатам даже очень большого числа запусков. Следует подчеркнуть, что для оценки надежности в этом случае необходимо рассмотреть другие вероятностные модели.

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

По теме: методические разработки, презентации и конспекты

Программа профессионального модуля "Разработка программных модулей программного обеспечения"

Образовательная программа профессионального модуля разработана на основе Федерального государственного образовательного стандарта по специальностям среднего профессионального образования (СПО) 230115 .

много полезного и интересного.

Рабочие программы практик УП. 02 ПМ.02 Установка и обслуживание программного обеспечения персональных компьютеров, серверов, периферийных устройств и оборудования по профессии 230103.04 Наладчик аппаратного и программного обеспечения

Рабочие программы практик УП. 02 ПМ.02 Установка и обслуживание программного обеспечения персональных компьютеров, серверов, периферийных устройств и оборудования по профессии 230103.04 Наладчик аппар.

Рабочая программа для профессии 230103.04 Наладчик аппаратного и программного обеспечения: ПМ 02 Установка и обслуживание программного обеспечения персональных компьютеров, серверов, периферийных устройств и оборудования

Рабочая программа для профессии 230103.04 Наладчик аппаратного и программного обеспечения: ПМ 02 Установка и обслуживание программного обеспечения персональных компьютеров, серверов, периферийных устр.

Рабочая программа для профессии 230103.04 Наладчик аппаратного и программного обеспечения: ПМ 04 Модернизация программного обеспечения персональных компьютеров, серверов, периферийных устройств и оборудования

Рабочая программа для профессии 230103.04 Наладчик аппаратного и программного обеспечения: ПМ 04 Модернизация программного обеспечения персональных компьютеров, серверов, периферийных устр.

Содержание

Основные положения

Формализации показателей качества программных средств посвящена группа нормативных документов. В международном стандарте ISO 9126:1991, при отборе минимума стандартизируемых показателей выдвигались и учитывались следующие принципы:

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

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

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

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

            Близким к описанному стандарту по идеологии, структуре и содержанию является стандарт ГОСТ 28195-89. На верхнем, первом уровне выделено 6 показателей - факторов качества:

            1. надежность,
            2. корректность,
            3. удобство применения,
            4. эффективность,
            5. универсальность
            6. сопровождаемость.

            Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240.

            
            

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

            В стандарте ГОСТ 28806-90 формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в стандарте 28195-89.

            Функциональная пригодность

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

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

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

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

            Корректность программы

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

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

            Надежность программы

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

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

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

            Классификация сбоев и отказов

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

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

            Устойчивость и восстанавливаемость работоспособного состояния ПС

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

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

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

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

            Наработка на отказ

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

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

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

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

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

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

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

            НАДЕЖНОСТЬ ИСПЫТАНИЯ — это тип тестирования программного обеспечения, который проверяет, может ли программное обеспечение выполнять безотказную работу в течение определенного периода времени в конкретной среде.

            В этом уроке вы узнаете

            Пример тестирования надежности

            Вероятность того, что ПК в магазине работает и работает в течение восьми часов без сбоев, составляет 99%; это называется надежностью.

            
            

            Тестирование надежности можно разделить на три сегмента,

            • моделирование
            • измерение
            • улучшение

            Следующая формула предназначена для расчета вероятности отказа.

            Факторы, влияющие на надежность программного обеспечения

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

            Зачем проводить тестирование надежности

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

            Целью проведения проверки надежности являются:

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

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

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

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

            Тестирование функций: —

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

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

            Нагрузочное тестирование: —

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

            Регрессионный тест:-

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

            Как сделать тестирование надежности

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

            Чтобы начать тестирование на надежность, тестер должен придерживаться следующих вещей,

            • Установить цели надежности
            • Разработать операционный профиль
            • Планируйте и выполняйте тесты
            • Используйте результаты тестов для принятия решений

            Как мы уже говорили ранее, есть три категории, в которых мы можем проводить тестирование надежности: моделирование, измерение и улучшение .

            Ключевые параметры, вовлеченные в тестирование надежности:

            • Вероятность безотказной работы
            • Продолжительность безотказной работы
            • Среда, в которой он выполняется

            Шаг 1) Моделирование

            Метод моделирования программного обеспечения можно разделить на две подкатегории:

            1. Моделирование прогноза

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

            Основные отличия двух моделей:

            Шаг 2) Измерение

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

            1. Метрики продукта: —

            Метрики продукта представляют собой комбинацию 4 типов метрик:

            • Размер программного обеспечения : — Линия кода (LOC) — это интуитивно понятный начальный подход к измерению размера программного обеспечения. В этом метрике учитывается только исходный код, а комментарии и другие неисполняемые операторы не учитываются.
            • Метрика точки функции : — Метрика функции Pont — это метод измерения функциональности разработки программного обеспечения. Он будет учитывать количество входов, выходов, основных файлов и т. Д. Он измеряет функциональность, предоставляемую пользователю, и не зависит от языка программирования.
            • Сложность : — Это напрямую связано с надежностью программного обеспечения, поэтому важно представлять сложность. Метрика, ориентированная на сложность, представляет собой метод определения сложности структуры управления программой путем упрощения кода в графическом представлении.
            • Метрики покрытия тестирования : — Это способ оценки неисправности и надежности путем выполнения полного тестирования программных продуктов. Надежность программного обеспечения означает, что это функция определения того, что система была полностью проверена и протестирована.

            2. Метрики управления проектом

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

            3. Метрики процесса

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

            4. Показатели неисправностей и отказов

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

            Надежность программного обеспечения измеряется в терминах среднего времени наработки на отказ (MTBF) . MTBF состоит из

            • Среднее до отказа (MTTF): это разница во времени между двумя последовательными сбоями
            • Среднее время ремонта (MTTR): это время, необходимое для устранения неисправности.

            Надежность для хорошего программного обеспечения — это число от 0 до 1.

            Надежность возрастает при удалении ошибок или ошибок из программы.

            Шаг 3) Улучшение

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

            Примеры методов проверки надежности

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

            В основном, для тестирования надежности используются три подхода

            • Тест-ретест Надежность
            • Надежность параллельных форм
            • Согласованность решений

            Ниже мы попытались объяснить все это на примере.

            Тест-ретест Надежность

            
            

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

            Надежность параллельных форм

            
            

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

            Согласованность решений

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

            Важность тестирования надежности

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

            Чтобы проверить надежность программного обеспечения с помощью тестирования: —

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

            Инструменты тестирования надежности

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

            1. WEIBULL ++: — Анализ данных о сроке службы

            2. RGA: — Анализ роста надежности

            3. RCM: -обслуживание, ориентированное на надежность

            Summary:

            Reliability Testing is the important part of a reliability engineering program. More correctly, it is the soul of reliability engineering program.

            Furthermore, reliability tests are mainly designed to uncover particular failure modes and other problems during software testing.

            In Software Engineering, Reliability Testing can be categorized into three segments,

            Читайте также:

              
            • Кого называют дальнобойщиками на какой правовой основе действуют дальнобойщики дайте пояснения
              
            • Как в 1с провести возврат заработной платы из банка
              
            • Как получить внж румынии гражданину россии
              
            • Положено ли два дня после прививки от коронавируса
              
            • Является ли вердикт процессуальным решением