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

Для достижения заданного уровня надежности программного обеспечения основные принципы разработки могут быть объединены в четыре группы [3]: избежание, обнаружение, исправление и допуск ошибок.

Избежание ошибок достигается:

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

Но полностью избежать ошибок не удается, поэтому применяют для их обнаружения следующие приемы и принципы:

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

Исправление ошибок — самое действенное средство повышения надежности программного обеспечения.

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

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

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

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

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

При проверке внешних спецификаций необходимо выявить как можно больше ошибок посредством верификации и тестирования.

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

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

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

Временная избыточность — использование части производительности ЭВМ для контроля исполнения и восстановления работоспособности программного обеспечения после сбоя.

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

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

Для повышения надежности программного обеспечения также применяется резервирование [6]. Для этого готовится несколько версий программного обеспечения. Желательно, чтобы они основывались на различных алгоритмах или создавались бы разными программистами. В случае двух различных версий программного обеспечения говорят, что применено дуальное программирование. Если при выполнении этих версий обнаруживается расхождение в результатах, то правильный результат выбирается по каким-либо дополнительным критериям (например, проверяется принадлежность результата определенной области). Если подготавливается и выполняется N версий программного обеспечения, то говорят о N-версионном программировании. В этом случае в качестве правильного выбирается результат, полученный на выходе большинства версий программного обеспечения. Недостатки дуального и N-версионного программирования: либо в несколько раз возрастает время выполнения (в случае последовательного выполнения версий), либо во столько же раз возрастает количество требуемой вычислительной техники (в случае одновременного исполнения). Кроме того, в несколько раз возрастает труд программистов.

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

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

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

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

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

Важным этапом жизненного цикла программного обеспечения, определяющим качество и надежность системы, является тестирование. Тестирование — это процесс выполнения программ с намерением обнаружить максимальное число ошибок [2]. Разработаны этапы тестирования:

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

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

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

(1.44).

позволяет установить среднее количество проверок, необходимых для обнаружения n ошибок, если при исправлении не вносится k новых ошибок (k = 0). Здесь b — неизвестное значение, которое может быть определено экспериментально; N — общее количество ошибок в модуле (приблизительно известно, определяется, например, по модели Холстеда).

Исходя из (1.44), получаем формулу, показывающую, какой процент P тестовых прогонов, необходимых для обнаружения всех N ошибок, был сделан, когда в процессе этих прогонов было обнаружено n ошибок:

. (1.45).

Пример. Если N = 10, по (1.45) получим, что половина всех ошибок может быть обнаружена в первых 22% тестовых прогонов, необходимых для обнаружения всех ошибок. Процент прогонов возрастает до 37%, если требуется найти 7 из 10 ошибок, и до 66%, если требуется найти 9 из 10 ошибок, то есть треть времени затрачивается на обнаружение последней ошибки. вероятность безотказный программное надежность Этот закон, устанавливающий, что эффект от тестирования уменьшается со временем, позволяет сделать вывод о необходимости прекращения тестирования в тот момент, когда оно становится экономически невыгодным, так как можно утверждать, что в отлаженном модуле все равно остается хотя бы одна ошибка.

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