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

Содержание:

ВВЕДЕНИЕ            3

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

2. Модели оценки надежности программ        6

      2.1. Модель Джелински-Моранды        6

     2.2. Модель Шумана         7

      2.3. Модель Миллса          7

3. Методы обеспечения надежности программных средств     8

4. Подход к обеспечению надежности №1  - предупреждение ошибок                                 10

      4.1. Методы борьбы со сложностью                                                                         10

     4.2. Обеспечение точности перевода                                                                            10

     4.3. Преодоление барьера между пользователем и разработчиком                            11

     4.4. Контроль принимаемых решений                                                                           11

5. Подход к обеспечению надежности №2  - обнаружение и исправление ошибок          12

6. Подход к обеспечению надежности №3  - обеспечение устойчивости программы к ошибкам                     16

ЗАКЛЮЧЕНИЕ                                                                                                                           18

СПИСОК ИСПОЛЬЗОВАНОЙ  ЛИТЕРАТУРЫ                19  

     Введение

     Программное обеспечение - согласно ГОСТ 19781-90 - совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации.

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

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

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

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

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

1. Свойства надежности программного обеспечения 

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

• Зрелость, завершенность (обратна к частоте отказов) (maturity)
• Устойчивость к отказам (fault tolerance)
• Способность к восстановлению работоспособности при отказах (recoverability)
• Соответствие стандартам надежности (reliability compliance, добавлен в 2001)

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

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

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

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

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

Выделяют два  типа устойчивости:

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

2. Модели оценки надежности программ 

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

• случайное время между двумя последовательными отказами, которое имеет функцию плотности распределения f(t/li) появления ошибок;
• число оставшихся ошибок в программе.

2.1. Модель Джелински-Моранды

     Самой известной моделью надежности является модель Джелински-Моранды, опирающая на модели надежности аппаратуры.

     Пусть R(t) - функция надежности, т.е. вероятность  того, что ни одна ошибка не появится в интервале от 0 до t. F(t)=1-R(t) - функция отказов. Соответственно плотность вероятности f(t)=-dR(t)/dt.

     Вводится  функция риска z(t) - условная вероятность того, что ошибка появится на интервале от t до t+Dt, при условии, что до момента t ошибок не было. По аналогии z(t)=f(t)/R(t) и R(t) = exp ( -∫ z(x)dx), а среднее время между отказами интеграл от 0 до ¥ от функции R(t).

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

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

     Второе  предположение z(t) - прямо пропорциональна  числу оставшихся ошибок, z(t)=K(N-i), где N - неизвестное первоначальное число ошибок, i - число обнаруженных ошибок,  K - некоторая неизвестная константа. Каждый раз, когда ошибка обнаруживается (модель предполагает, что задержка между обнаружением ошибки и ее исправлением отсутствует) z(t) уменьшается на некоторую величину К.

     Дальнейшая  проработка этой модели - Модель Шумана  
 

     2.2. Модель Шумана

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

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

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

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

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

2.3. Модель Миллса

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

     Предположим, что в программу внесено s ошибок, после чего начато тестирование. При тестировании обнаружено  n - число собственных ошибок,  v -  число найденных внесенных. Тогда N=sn/v.

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

3. Методы обеспечения надежности программных средств 

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

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

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

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

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

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

• предупреждение ошибок;
• обнаружение ошибок;
• исправление ошибок;
• обеспечение устойчивости к ошибкам.

4. Подход к обеспечению надежности №1  - Предупреждение ошибок 

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

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

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

4.1. Методы борьбы со сложностью.

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

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

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

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

4.2. Обеспечение точности перевода.

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

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

4.3.Преодоление барьера между пользователем и разработчиком.

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

4.4. Контроль принимаемых решений.

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

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

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

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

5. Подход к обеспечению надежности №2  - Обнаружение и исправление ошибок в программе 

     ПО  как объект тестирования имеет ряд  особенностей:

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

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

     Для определения задач тестирования целесообразно выделить три стадии:

1. Тестирование для обнаружения ошибок в программе.

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

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

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

3. Тестирование для контроля выполненных корректировок программ и данных (контрольное тестирование).

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

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

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