Материалы сайта
Это интересно
Автоматизация учета исполнения бюджета Краснодарского края
3 Надежность программного изделия Одной из важнейших характеристик качества ПИ является надежность. Надежность – это свойство ПИ сохранять работоспособность в течение определенного периода времени, в определенных условиях эксплуатации учетом последствий для пользователя каждого отказа. Причиной отказа (перехода из работоспособного в неработоспособное состояние) ПИ является невозможность его полной проверки в процессе тестирования и испытаний. При эксплуатации ПИ в реальных условиях может возникнуть такая комбинация входных данных, которая вызывает отказ. Таким образом, работоспособность ПИ зависит от входной информации, и чем меньше эта зависимость, тем выше уровень надежности программы. Для оценки надежности используются 3 группы показателей: качественные, порядковые и количественные. Рассмотрим основные количественные показатели надежности программного изделия. 1) Вероятность безотказной работы P(tз) – это вероятность того, что в пределах заданной наработки отказ системы не возникает. 2) Вероятность отказа – вероятность того, что в пределах заданной наработки отказ системы возникает. Это показатель, обратный предыдущему. Q(t з) =1 – P(t з) (3.1) где t з – заданная наработка, ч.; Q(t з) – вероятность отказа. 3. Интенсивность отказов системы – это условная плотность вероятности возникновения отказа ПИ в определенный момент времени при условии, что до этого времени отказ не возник. где f(t) – плотность вероятности отказа в момент времени t. Существует следующая связь между интенсивностью отказов системы и вероятностью безотказной работы /10/ В частном случае, при Если в процессе тестирования фиксируется число отказов за определённый временной интервал, то интенсивность отказов системы есть число отказов в единицу времени. 4. Средняя наработка на отказ Тi - математическое ожидание времени работы ПИ до очередного отказа : Иначе среднюю наработку на отказ Тi можно представить : где t - время работы ПИ между отказами, с. n – количество отказов. Причиной отказов АСОД являются ошибки, которые могут быть вызван: внутренним устройством АСОД, реакцией АСОД на изменение внешней среды функционирования. Это значит , что даже при самом тщательном тестировании , если предположить, что удалось избавиться от всех внутренних ошибок, никогда нельзя с полной уверенностью утверждать, что в процессе эксплуатации базы данных отказ не возникнет. Естественно, мы можем и должны стремиться повышать уровень надежности АСОД, но достижение 100 %-ной надежности лежит за пределами возможного. Причиной ошибок в АСОД является нарушение правильности перевода информации (из одного представления в другое). Создание АСОД рассматривается как совокупность процессов перевода информации из одной формы представления в другую с фиксацией множества промежуточных решений, с участием специалистов различного профиля и квалификации. Кроме того, необходимо учитывать взаимного перекрывания процессов и наличие циклов обратной связи.( Например, ошибки, сделанные в процессе проектирования, могут быть обнаружены при программировании. Тогда возникает необходимость возврата к предшествующему этапу и устранению ошибки.) Классификация программных ошибок по категориям основана на эмпирических данных, полученных при разработке различных программных изделий. Под категорией ошибок понимается видовое описание ошибок конкретных типов. В полной классификации выделено более 160 категорий, объединенных в 20 классов. В таблице 3.1. приведены некоторые классы программных ошибок с применением категорий. Таблица 3.1- Классы программных ошибок |Идентификаторы |Наименование | |Класса |категория | | |1 |2 |3 | |АА000 | |Ошибки вычисления | | |АА010 |Неверно определено общее число | | | |элементов | | |АА020 |Неверно вычислен физический или | | | |логический номер эле-та | |ВВ000 | |Логические ошибки | | |ВВ010 |Ошибка в определении границ | | |ВВ020 |Логически неверное ветвление | |СС000 | |Ошибки ввода-вывода | | |СС010 |Информация не выводиться | | |DD030 |Данные потеряны или не хранятся | | |DD070 |Ошибка при манипулировании с | | | |битами данных | | |DD071 |Ошибочное использование | | | | | | | | | | | | | |Продолжение | | | |таблицы 3.1 | | | |1 | | | |2 | | | |3 | | | | | |операции изменения состояния бита | |EE000 | |Ошибки в ОС | |FF000 | |Ошибки компоновки | |GG000 | |Ошибки в межпрограммных | | | |интерфейсах | |ИИ000 | |Неясности | | | |Проблема создания надежных программных изделий имеет 2 стороны: | |разработка средств и методов, применения которых в процессе создания | |программы позволит обеспечить ему высокие показатели надежности; | |развитие самой теории надежности: создание стройной системы | |показателей надежности; планирование уровня надежности на начальных | |этапах разработки программного изделия; возможность оценить | |показатели надежности по результатам испытаний программ; контроль | |уровня надежности в процессе эксплуатации программного изделия. | В настоящее время остро стала проблема индустриализации процесса создания и сопровождения программного изделия. Действенным шагом в решений этой проблемы является признание ПИ продукцией производственно-технического назначения. Анализ потока данных базируется на исследовании процесса передачи и преобразования входных элементов. Первоначальный поток данных разбивается на вход, преобразование и выход, интерпретируемые в программы управления вводом, выводом, непосредственно обработки информации. В методах расширения ядра и восходящего проектирования (проектирование снизу-вверх) больше внимания уделяется не определению функции всей программы в целом, а тем частным функциям, которые потребуются проектируемой базе данных. При этом в методе расширения ядра осуществляется локализация основных частей программы, базирующихся на типичных для данного класса задач процессах обработки информации (контроль входных данных, сортировка, редактирование файлов, записей и т.д.) с дальнейшей их детализацией, а также с первоначальными определениями и последующими изменениями управляющих связей. Перестройка связей между модулями определяется необходимостью функционирования объединения процедур обработки. В методе восходящего проектирования определяются функции самого низкого уровня, обеспечивающие такие элементарные операции, как управление внешней памятью, выбор библиотечных процедур и т.д. Далее разработанные модули, реализующие эти функции, используются для определения функции и создания модулей более высокого уровня, таких, как обновление файлов, корректировка информации и других, которые в свою очередь, включаются в части программы на более высоком уровне. Процесс продолжается до тех пор, пока разработка программы не будет завершена. Обе последние стратегии проектирования ориентированы на разработку небольших по объёму вспомогательных систем ПИ с имеющимися аналогами реализации, а также могут использоваться при модификации программ. К таким технологиям можно отнести HIPO –технологию и следующие технологии: PSL\PSA (Problem Statement Lanquaqe \ Problem Statement Analyzer ), включающая язык и анализатор постановки задач; SREM (Software Requrement Engineering Metodologi),методология разработки требований к ПО, ориентированный на разработку систем реального времени; PDM ( Process Design Metodology ), методология проектирования процессов, предназначенная для проектирования и тестирования ПС; SADT (Structured Analysis and Design Technique), методология структурного анализа и проектирования, состоящая из графического языка ссылок и языка синхронизации, используемая при разработке систем самых широких классов и т.д. Все модели надежности можно классифицировать по тому, какой из перечисленных процессов они поддерживают (предсказывающие, прогнозные, измеряющие и т.д.). Нужно отметить, что модели надёжности, которые в качестве исходной информации используют данные об интервалах между отказами, можно отнести и к измеряющим, и к оценивающим в равной степени. Некоторые модели, основанные на информации, полученной в ходе тестирования АСОД, дают возможность делать прогнозы поведения АСОД в процессе эксплуатации. Рассмотрим классификацию моделей надежности АСОД , приведенную на рисунке 3.1. АСОД подразделяется на аналитические и эмпирические. Аналитические модели дают возможность рассчитывать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе структурных особенностей программ. Они рассматривают зависимость показателей надёжности от числа межмодульных связей, количества циклов в модулях и т.д. Часто эмпирические модели не дают конечных результатов показателей надёжности, однако они включены в классификационную схему, так как развитие этих моделей позволяет выявлять взаимосвязь между сложностью АСОД и его надежностью. Эти модели можно использовать на этапе проектирования АСОД, когда осуществляется разбивка на модули и известна его структура. Аналитические модели представлены двумя группами: динамические модели и статические. В динамических АСОД поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем, а учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных (по области данных). Для использования динамических моделей необходимо иметь данные о появлении отказов во времени. Если фиксируются интервалы каждого отказа, то получается непрерывная картина появления отказов во времени (группа динамических моделей с непрерывным временем). С другой стороны, может фиксироваться только число отказов за произвольный интервал времени. В этом случае поведение АСОД может быть представлено только в дискретных точках (группа динамических моделей с дискретным временем). ----------------------- [pic] [pic] [pic] [pic] [pic] [pic] [pic] Лист Лист Лист Лист Лист Лист Лист Лист
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23