Лист
     3 Надежность программного изделия


      Одной из важнейших характеристик качества ПИ является надежность.

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

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

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

       Рассмотрим основные количественные показатели надежности программного изделия.

      1) Вероятность безотказной работы P(tз) – это вероятность того, что в пределах заданной наработки отказ системы не возникает.

     2) Вероятность отказа – вероятность того, что в пределах заданной наработки отказ системы возникает.

      Это показатель, обратный предыдущему.


                     Q(t з) =1 – P(t з)                                            (3.1)


     где t з – заданная наработка, ч.;

           Q(t з) – вероятность отказа.

Лист
    3. Интенсивность отказов системы – это условная плотность вероятности возникновения отказа ПИ в определенный момент времени при условии, что до этого времени отказ не возник.

   

где f(t) – плотность вероятности отказа в момент времени t.


    

Существует следующая связь между интенсивностью отказов системы и вероятностью безотказной работы /10/

 

 

В частном случае, при

 

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


     4. Средняя наработка на отказ Тi  - математическое ожидание времени работы ПИ до очередного отказа :

Лист
 

      Иначе среднюю наработку на отказ Тi можно представить :

    где t -  время работы ПИ между отказами, с.

          n – количество отказов.

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

     Естественно, мы можем и должны стремиться повышать уровень надежности АСОД, но достижение 100 %-ной надежности лежит за пределами возможного.

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

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

     Под категорией ошибок понимается видовое описание ошибок конкретных типов. В полной классификации выделено более 160 категорий, объединенных в 20 классов. В таблице 3.1. приведены некоторые классы программных ошибок с применением категорий.

Таблица 3.1- Классы программных ошибок

Идентификаторы

Наименование

Класса

категория

1

2

3

АА000

Ошибки вычисления

АА010

Неверно определено общее  число элементов

АА020

Неверно вычислен физический или логический номер эле-та

ВВ000

Логические ошибки

ВВ010

Ошибка в определении границ

ВВ020

Логически неверное ветвление

СС000

Ошибки ввода-вывода

СС010

Информация не выводиться

DD030

Данные потеряны или не хранятся

DD070

Ошибка при манипулировании с битами данных




Продолжение таблицы 3.1

            1                         2                                       3


DD071

Ошибочное использование


Лист


операции изменения состояния бита

EE000

Ошибки в ОС

FF000

Ошибки компоновки

GG000

Ошибки в межпрограммных интерфейсах

ИИ000

Неясности

     Проблема создания надежных программных изделий имеет 2 стороны:

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

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

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

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


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

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

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

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

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

     К таким технологиям можно отнести HIPO –технологию и следующие технологии:

­         PSL\PSA (Problem Statement Lanquaqe \ Problem

Statement Analyzer ), включающая язык и анализатор постановки задач;

­         SREM (Software Requrement Engineering


Лист
Metodologi),методология разработки требований к ПО, ориентированный на разработку систем реального времени;

­         PDM ( Process Design Metodology ), методология

проектирования процессов, предназначенная для проектирования и тестирования ПС;

­         SADT (Structured Analysis and Design Technique),

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

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

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

Лист
      Аналитические модели представлены двумя группами: динамические модели и статические. В динамических АСОД поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем, а учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных (по области данных).

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