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

Рис. 1.9. Связь модулей при наследовании

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

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

Для достижения заданного уровня надежности программного обеспечения основные принципы разработки могут быть объединены в четыре группы [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 ошибок, то есть треть времени затрачивается на обнаружение последней ошибки. вероятность безотказный программное надежность

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

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

2. Методические указания к выполнению расчета надежности в дипломных проектах

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

2.1 Подготовка к расчету надежности программного обеспечения

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

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

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

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

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

,

где l - интенсивность появления ошибки. Время наработки на отказ - среднее время между отказами:

.

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

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

3. Разрабатывается программа мероприятий, направленных на повышение надежности разрабатываемого программного обеспечения. Нельзя добиться повышения надежности программного обеспечения разрозненными мероприятиями. Их надо проводить целенаправленно, начиная с начальных этапов (см. п. 1.4). Совокупность этих мероприятий объединяется в программу обеспечения надежности разрабатываемого программного обеспечения. Ее составляют либо одновременно с техническим заданием на разработку программного обеспечения, либо на ранних этапах проектирования. В ходе разработки программного обеспечения эта программа мероприятий по обеспечению надежности программного обеспечения уточняется и дополняется.

2.2 Методика расчета показателей надежности ПО

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

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

Табл. 1

3. Задается время испытаний ПО на надежность - время, необходимое для тестирования (см. формулу 1.44).

4. Подготавливаются тесты для выявления ошибок (см. п. 1.4).

5. Проводится тестирование ПО.

6. Результаты тестирования заносятся в табл. 1, табл. 2 или табл. 3.

Табл. 2

Табл. 3

7. Исходя из результатов тестирования выбирают модель для расчета надежности программного обеспечения (табл. 4.1).

Табл. 4.1. Выбор модели надежности по результатам тестирования

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

Табл. 4.2. Выбор модели надежности для определения первоначального числа ошибок

9. Если начальное число ошибок N не поддается вычислению, то выбирают модель для его расчета (табл. 4.2). Если выбрана модель Миллса, то проводят дополнительное тестирование для выявления искусственно внесенных ошибок. Эту же модель выбирают в случае, когда основное тестирование за время T не выявило ни одной ошибки.

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

Если в техническом задании определена требуемая величина средней наработки на отказ t_d, а рассчитанное по результатам тестирования время t меньше требуемого t_d, то по модели Муса рассчитывается дополнительное время тестирования DT. Предполагают, что за дополнительное время новых отказов ПО не возникнет. Тогда общее время тестирования (T + DT) должно удовлетворять соотношению:

, (2.1)

где t₀ - средняя наработка на отказ до начала тестирования;

C - коэффициент, учитывающий уплотнение тестового времени по сравнению с временем реальной эксплуатации (если один час тестирования соответствует 12 ч работы в реальных условиях, то C = 12);

T - суммарное время тестирования;

n - число отказов, произошедших за время тестирования.

Из формулы (2.1) легко получить:

. (2.2)

Приведем схему алгоритма достижения надежности программного обеспечения, заданной в техническом задании (рис. 2.1).

Рис. 2.1. Схема алгоритма достижения надежности ПО, указанной в техническом задании

Список использованных источников

1. Майерс Г. Надежность программного обеспечения: Пер. с англ. - М.: Мир, 1980. - 356 с.

2. Липаев В.В. Надежность программных средств. - М.: СИНТЕГ, 1998. - 232 с.

3. Шураков В.В. Надежность программного обеспечения систем обработки данных: Учебник для вузов. - М.: Статистика, 1981. - 216 с.

4. Карповский Е.Я., Чижов С.А. Надежность программной продукции. - К.: Тэхника, 1990. - 160 с.

5. Смагин В.А. Метод оценивания и обеспечения надежности сложных программных комплексов. http://www.geocities.com/sirine_cva/Cmagin/ /Metod_15032.php.

6. Фатуев В.П. Надежность автоматизированных информационных систем: Учебное пособие // Высоцкий В.И., Бушинский В.И. - Т.: ТГУ, 1998. - 104 с.

7. Иыуду К.А. Надежность, контроль и диагностика вычислительных машин и систем. - М.: Высшая школа, 1989. - 216 с.

8. Кабак И.С., Позднеев Б.М. О надежности объектно-ориентированного программного обеспечения. - М.: МГТУ "СТАНКИН", http://www.stankin.ru/rus_ver/sc_prj/magazine/art/10/index.php.

Размещено на Allbest.ru