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

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

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

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

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

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

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

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

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

     1. Полное прекращение выполнения функций программы;

     2. Кратковременное нарушение хода обработки информации в ИС.

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

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

 

7 Основные показатели  надежности ПО

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

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

     1. Вероятность безотказной работы программы p(t) , представляющая собой вероятность того, что ошибки программы не проявятся в интервале времени (0, t);

     2. Вероятность отказа программы q(t) или вероятность события отказа ПО до момента времени t ;

     3. Интенсивность отказов программы l(t) ;

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

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

 

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

 

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

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

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

     р = k/n. (2) 

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

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

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

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

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

 

9 Некоторые следствия

 

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

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

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

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

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

 

     

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

 

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

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

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

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

     1. Модульность и строгую иерархию в структурном построении программ;

     2. Унификацию правил проектирования, структурного построения и взаимодействия компонент ПС;