Проектирование информационных систем

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

А если ошибки содержатся и в программе и в публикациях? Или если в руководстве описана только ожидаемая и планируемая работа с системой. Например, написано: "Чтобы получить то-то, нажмите один раз то-то". Предположим, что пользователь случайно два раза нажимает то-то и система выходит из строя, потому что её разработчики не предусмотрели такой ситуации. Система, очевидно, содержит ошибку, но ведёт себя в соответствии с публикациями.

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

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

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

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

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

· failure -- нарушение требований, проявляющееся при каком-то реальном сценарии работы ПО, это скорее проявление ошибки

· fault -- ошибка в коде программы, вызывающая нарушения требований при работе (failures), то место, которое надо исправить. Хотя это понятие используется довольно часто, оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можно исправить программу в нескольких местах. Что именно надо исправлять, зависит от дополнительных условий, выполнение которых мы хотим при этом обеспечить.

· error -- используется в двух смыслах.

Первый -- это ошибка в ментальной модели программиста, которая заставляет его делать ошибки в коде (faults).

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

Первое место в неформальном состязании за место «самой дорого обошедшейся ошибки в ПО» долгое время удерживала ошибка, приведшая к неудаче первого запуска ракеты Ариан-5 4 июня 1996 года, стоившая около $500 миллионов. После произошедшего 14 августа 2003 года обширного отключения электричества на северо-востоке Северной Америки, стоившего экономике США и Канады от 4 до 10 миллиардов долларов, это место закрепилось за вызвавшей его ошибкой в системе управления электростанцией.

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

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

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

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

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

· искажения в каналах телекоммуникации информации, поступающей от внешних источников и передаваемой потребителям, а также недопустимые значения и изменения характеристик потоков информации от объектов внешней среды;

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

· вирусы, сбои и отказы, распространяемые по каналам телекоммуникации, влияющие на информационную и функциональную безопасность;

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

Внутренними источниками угроз безопасности функционирования ПС являются:

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

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

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

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

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

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

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

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

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

§ Зрелость, завершенность (обратна к частоте отказов) (maturity)

§ Устойчивость к отказам (fault tolerance)

§ Способность к восстановлению работоспособности при отказах (recoverability)

§ Соответствие стандартам надежности (reliability compliance, добавлен в 2001)

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

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

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

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

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

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

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

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

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

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

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

3. Выбор и обоснование характеристик надежности ПО

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

В простейшем варианте набор этапов жизненного цикла таков:

· системный анализ (анализ требований);

· проектирование (предварительное и детальное);

· кодирование и отладка ("программирование");

· тестирование;

· эксплуатация (хранение и внедрение) и сопровождение.

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

1) масштабность и сложность заданий на ПО, многофункциональность, универсальность, большой объем обрабатываемой информации,.

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

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

На этапе проектирование закладывается корректность программ и основными влияющими факторами являются:

1) технология разработки

2) структурная упорядоченность программ и данных, стандартизация структуры единиц ПО;

3) уровень автоматизации проектирования и испытаний

4) выбор способов и критериев отладки

5) создание инструментальной среды

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

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

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

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

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

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

Б) число оставшихся ошибок в программе

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

Пусть 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) и

,

а среднее время между отказами интеграл от 0 до ? от функции R(t).

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

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

Второе предположение z(t) - прямо пропорциональна числу оставшихся ошибок,

z(t)=K(N-i),

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

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

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

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

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

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

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

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

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

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

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

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

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

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

предупреждение ошибок;

обнаружение ошибок;

исправление ошибок;

обеспечение устойчивости к ошибкам.

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

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

борьба со сложностью,

обеспечение точности перевода,

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

обеспечение контроля принимаемых решений.

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

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

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

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

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

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

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

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

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

Поймите задачу;

Составьте план (включая цели и методы решения);

Выполните план (проверяя правильность каждого шага);

Проанализируйте полученное решение.

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

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

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

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

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

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

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

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

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

отсутствие полностью определенного эталона (программы), которому должны соответствовать все результаты тестирования проверяемой программы;

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

невысокая степень формализации критериев качества процесса тестирования и достигаемого при этом качества объектов тестирования;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

,

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

gн - доверительная вероятность (>=0,9, как правило);

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

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

Тогда вероятность того, что при одном тесте ошибка не будет обнаружена, оценивается как 1-r/N. Вероятность того, что при n независимых тестах ошибка не будет обнаружена, равна (1-r/N)n. Если ошибочных символов в программе больше, чем один, то вероятность их обнаружения одним тестом будет еще больше, так что оценка является оценкой сверху.

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

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

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

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

В данном методе наряду с вычисляемой функцией по иной программе определяется другая функция в соотношениях, называемых контрольными соотношениями. Эти соотношения позволяют не только обнаружить отказ одной из программ, но также и восстановить искаженный результат отказавшей программы на основании результата, полученного по безошибочно работающей программе (программам). Простейшим примером применения метода контрольных соотношений является вычисление функции sinx и cosx по отдельным программам. Контрольное соотношение в данном случае будет соотношение sin2x+cos2x=1.

Более сложный вариант исправления ошибок с использованием матрицы Хэмминга.

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

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

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

 13. Отказоустойчивые вычислительные системы

1. Термин - отказоустойчивость и связанные с ним понятия

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

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

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

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

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

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

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

Системы, эластичные к отказам (Fault Resiliency). Ключевым моментом в определении эластичности к отказам является более короткое время восстановления, которое позволяет системе быстро откатиться назад после обнаружения неисправности.

Системы, устойчивые к отказам (Fault Tolerance). Такие отказоустойчивые системы имеют в своем составе избыточную аппаратуру для всех функциональных блоков, включая процессоры, источники питания, подсистемы ввода/вывода и подсистемы дисковой памяти. Если соответствующий функциональный блок неправильно функционирует, всегда имеется горячий резерв. Часто избыточные аппаратные средства можно использовать для распараллеливания обычных работ. Время восстановления после обнаружения неисправности для переключения отказавших компонентов на избыточные для таких систем обычно меньше одной секунды.

Системы непрерывной готовности (Continuous Availability). Системы с непрерывной готовностью, устраняют любое время простоя как плановое, так и неплановое. Разработка такой системы охватывает как аппаратные средства, так и программное обеспечение и позволяет проводить модернизацию (upgrade) и обслуживание в режиме on-line. Дополнительным требованием к таким системам является отсутствие деградации в случае отказа. Время восстановления после отказа не превышает одной секунды.

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

2. Классификация вычислительных систем

По стоимости возможного простоя (вследствие сбоя в работе) корпоративные системы можно разделить на следующие категории:

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

business critical -- при сбое возникают значительные финансовые потери, однако он не влияет на работоспособность компании в целом;

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

Классификация вычислительных систем по готовности

Коэффициент готовности, %

Максимальное время простоя в год

Тип системы

99

3,5 сут

Обычная (Conventional)

99,9

8,5 ч

Высокой готовности (High Availability)

99,99

1 ч

Эластичная к отказам (Fault Resilent)

99,999

5 мин

Устойчивая к отказам (fault tolerant)

Основные причины отказов в современных ИС и пути их устранения

По экспертным оценкам причины отказов в ИС выглядят следующим образом:

отказы дисков - 27%,

отказы сервера или его ядра - 24%,

отказы в программах - 22%,

отказы в коммуникационном оборудовании - 11%,

отказы в каналах передачи данных - 10%,

отказы из-за ошибок персонала - 6%.

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

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

На первом месте отказы подсистемы памяти. Имеются три основных типа подсистем внешней памяти с высокой готовностью. Для своей реализации они используют технологию Избыточных Массивов Независимых Дисков (RAID - Redundant Arrays of Inexpensive Disks). Наиболее часто используются следующие решения (более подробно об уровнях RAID см. разд. 9.3.2): RAID уровня 1 или зеркальные диски, RAID уровня 3 с четностью и RAID уровня 5 с распределенной четностью. Эти три типа внешней памяти в общем случае имеют практически почти мгновенное время восстановления в случае отказа. Кроме того, подобные устройства иногда позволяют пользователям смешивать и подбирать типы RAID в пределах одного дискового массива. В общем случае дисковые массивы представляются прикладной задаче как один диск.

Технология RAID уровня 1 (или зеркалирования дисков) основана на применении двух дисков так, что в случае отказа одного из них, для работы может быть использована копия, находящаяся на дополнительном диске. Программные средства поддержки зеркальных дисков обеспечивают запись всех данных на оба диска. Недостатком организации зеркальных дисков является удвоение стоимости аппаратных средств и незначительное увеличение времени записи, поскольку данные должны быть записаны на оба диска. Положительные стороны этого подхода включают возможность обеспечения резервного копирования в режиме on-line, а также замену дисков в режиме on-line, что существенно снижает плановое время простоя. Как правило, структура устройств с зеркальными дисками устраняет также единственность точки отказа, поскольку для подключения обоих дисков обычно предусматриваются два отдельных кабеля, а также два отдельных контроллера ввода/вывода.

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

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

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

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

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

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