Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Василенко Н. В., Макаров В. А.
A new model of the evaluation of software reliability, based on the estimation of processing and the results of the program product testing is proposed. The reliability estimation model, based on Poisson’s heterogeneous models, is adapted. New concepts reliability matrix and reliability class are introduced. Предложена новая модель оценки надежности программного обеспечения, основанная на оценках процесса разработки и результатов тестирования программного продукта. Адаптирована модель оценки надежности, основанная на неоднородных процессах Пуассона. Введены новые понятия матрицы надежности и класса надежности
i Надоели баннеры? Вы всегда можете отключить рекламу.
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Василенко Н. В., Макаров В. А.
Модели надежности программного обеспечения ответственного назначения
Учет вторичных дефектов в моделях надежности программных средств
Как найти надежных поставщиков? Методика выбора
Исследование моделей надежности программного обеспечения в среде имитационного моделирования Any Logic
Модели оценки надежности программного обеспечения
Учет фактора вторичных дефектовпри оценке надежности программных средств
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры?
Вы всегда можете отключить рекламу.
Текст научной работы на тему «Оценка надежности программного обеспечения»
УСТАНОВКИ И МЕТОДИКИ ИССЛЕДОВАНИЯ
ОЦЕНКА НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
A new model of the evaluation of software reliability, based on the estimation of processing and the results of the program product testing is proposed. The reliability estimation model, based on Poisson’s heterogeneous models, is adapted. New concepts — reliability matrix and reliability class are introduced.
В международном стандарте ISO 9126:1991 [1] надежность выделена как одна из шести основных характеристик качества программного обеспечения (ПО) наряду с функциональной пригодностью, применимостью, эффективностью, сопровождаемостью и переносимостью. Но как узнать, насколько надежен программный продукт, выпущенный фирмой, специализирующейся на разработке ПО? Как измерить его надежность?
Согласно стандартному словарю терминов программного инжиниринга [2] надежность программного обеспечения есть способность системы или компонента выполнять требуемые функции в заданных условиях на протяжении указанного периода времени.
Для обеспечения надежности программ предложено множество подходов, включая организационные методы разработки, различные технологии и технологические программные средства, что требует, очевидно, привлечения значительных ресурсов. Однако отсутствие общепризнанных критериев надежности не позволяет ответить на вопрос, насколько надежнее становится программное обеспечение при соблюдении предлагаемых процедур и технологий и в какой степени оправданы затраты. Таким образом, приоритет задачи оценки надежности должен быть выше приоритета задачи ее обеспечения, чего на самом деле не наблюдается.
ДМ и ОК — 2.3.2 Основные положения и зависимости надежности. Показатели надежности.
К настоящему времени разработаны различные модели надежности программного обеспечения, представляющие собой математические модели, построенные для оценки зависимости надежности программного обеспечения от некоторых определенных параметров (модели Шумана, Ла Падула, Джелинского — Моранды, Шика — Волвертона, Мусса, Миллса, Липова, Коркорэна, Нельсона, модель преходных вероятностей, простая интуитивная модель и др. [3]). Однако ни одна из предложенных моделей не используется на практике по той причине, что их применение неудобно или нецелесообразно. Отметим основные недостатки существующих моделей.
1. Модели оперируют с функциями, зависящими от времени проявления ошибок. А количество ошибок, выявляемых при тестировании и эксплуатации, зависит от времени только косвенно, так как время лишь в некоторых случаях влияет на разнообразие условий (количество различных, проявляющих ошибки условий) для тестируемого модуля.
2. При построении моделей не рассматриваются вопросы, связанные с характеристиками тестов, например полнотой теста, распределением появления входных наборов.
3. Значение полученных оценок во многих моделях зависит не только от свойств ПО, но и от принятого плана и методики испытания, что искажает полученные оценки. Например, в модели Нельсона не определено понятие эксперимента, а различные его трактовки приведут к совершенно разным результатам.
4. Некоторые модели, например модель Джелинского — Моранды, дают достаточно грубую, непригодную для использования оценку надежности.
5. В ряде моделей сказывается большое влияние субъективного фактора. Например, модель Миллса требует предварительно задать предполагаемый уровень ошибок в программе, что основывается исключительно на интуиции и опыте человека, проводящего оценку.
6. В некоторых моделях (например, в модели Коркорэна) требуется априорная информации или данные предшествующего периода функционирования однотипных программных средств.
Все упомянутые модели основаны на результатах тестирования (испытания) ПО. Но все активнее обсуждается вопрос обеспечения надежности в процессе разработки. Следует признать, что разумно оценивать надежность, не только как результат испытаний ПО, но и как организацию процесса создания надежного программного продукта. Предлагается определять надежность ПО на основе двух оценок: оценки процесса его разработки и оценки результатов тестирования.
Процесс разработки ПО можно оценить с помощью факторов, влияющих на этот процесс. Эти факторы рассматриваются многими авторами. Например, А.В.Коганов и С.Г.Романюк [4] вводят понятие кортежа программы и, говоря о надежности ПО, имеют в виду надежность составляющих этого кортежа. В кортеж входят: сама программа, окружающая среда, режим эксплуатации и документация.
В.В.Липаев [5] среди прочих приводит такие факторы, как допустимые финансово-экономические затраты, кадры специалистов, доступные разработчикам ПО вычислительные ресурсы. В.В.Шураков [6] делит все факторы на три группы: общие (процедура управления разработкой, квалификация персонала и др.), связанные с разработкой ПО (конструктивные, технологические, организационные) и эксплуатационные.
Нами выделены следующие, на наш взгляд, наиболее существенные факторы, влияющие на надежность ПО в процессе разработки:
— совершенство процесса управления разработкой (УПР),
— квалификация участников разработки программного продукта (КВАЛ),
— сложность архитектуры системы (АРХ),
— язык программирования (ЯЗ),
— трудоемкость разработки (ТРУД),
— опыт в разработке подобных систем (ОПЫТ),
— взаимодействие в команде (КОМ),
— полнота и качество документации (ДОК).
Совершенство процесса управления разработкой предлагается оценивать в соответствии с моделью зрелости процесса разработки ПО — CMM (Capability Maturity Model), предложенной в 1991 г. институтом системного программирования при университете Карнеги — Меллон [7]. В модели CMM определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически) понижаться.
Для оценки квалификации участников разработки программного продукта введем показатель Q, который рассчитывается по формуле.
где Q — оценка квалификации команды; N — количество человек в команде разработки; N — число сертифицированных специалистов в команде; V — статусная оценка /-го участника команды (от 1 до 5); 2^ — загрузка /-го участника команды в проекте; 0,4 и 0,6 — весовые коэффициенты, установленные эмпирически; 5 — коэффициент приведения к единой шкале.
Сложность архитектуры системы предлагается оценивать в соответствии с существующей их классификацией. Различают следующие основные классы архитектур программных средств: цельная программа, комплекс автономно выполняемых программ, слоистая программная система, коллектив параллельно выполняемых программ [8].
Q = 0,4 • 5 —^ + 0,6—Е1——
Язык программирования формально можно оценить как количество операторов данного языка на один функциональный указатель. Количество функциональных указателей FP (Function Points) — метрика ПО, введенная А. Альбрехтом в 1979 г. К функциональным указателям относят внешний ввод, внешний вывод, внутренний логический файл, внешний интерфейсный файл, внешние запросы [9].
Трудоемкость разработки оценивается по факту после ее окончания.
Опыт в разработке подобных систем, взаимодействие в команде, полнота и качество документации оцениваются экспертно.
Для оценки надежности ПО с точки зрения процесса разработки необходимо оценить каждый из восьми предложенных факторов по пятибалльной шкале. У авторов статьи разработана методика оценки этих факторов в соответствии с приведенными выше критериями, но рамки журнальной статьи не позволяют привести ее здесь.
Оценка факторов проводится экспертно. Вклад каждого из факторов в надежность разрабатываемого ПО очевидно различен. Необходимо выделить постоянную систему весов для этих факторов, чтобы сравнивать надежность различных программных продуктов.
Обобщенную оценку надежности как результата организации процесса разработки R1 определим как взвешенную сумму оценок факторов, влияющих на надежность:
где V, — оценка /-го фактора по пятибалльной шкале; у,- — вес /-го фактора по пятибалльной шкале.
Теперь рассмотрим оценку надежности ПО, которая может быть получена как результат испытания (тестирования) готового программного продукта.
Перечислим требования, которым должна удовлетворять корректная модель.
1. Вся совокупность тестов и возможных комбинаций входных данных (все тесты, принадлежащие программе функциональных испытаний) есть одно испытание на надежность.
2. Целесообразно, чтобы модель учитывала процесс доработки ПО по результатам испытаний
3. Оценка надежности ПО должна производится тогда, когда после испытания данной версии ПО не было обнаружено ни одной ошибки.
4. В модели не должны учитываться временные интервалы между обнаруженными ошибками, так как они отражают в основном очередность отдельных проявляющих ошибки условий или очередность смены наборов входных данных.
5. Модель не должна требовать априорных данных или данных предшествующего периода функционирования однотипных программных средств
Для описания процесса проявления и исправления ошибок в ПО можно воспользоваться моделью Пуассона, удовлетворяющей всем пяти условиям.
Пусть Щґ) — число проявившихся ошибок за время ґ тестирования версии г ПО есть неоднородный процесс Пуассона с интенсивностью Х(ґ), ґ > 0.
Обозначим N(ґг, ґг-1) = N(ґг) — N(ґг-1). Тогда для любых моментов 0 < ґ1 < ґ2 <. справедливо
где к = 0,1,2,. — число ошибок; г = 0,1,2,. — ряд последовательно испытываемых версий ПО; т(ґг) — среднее число проявлений ошибок за время ґ в версии г. Отсюда определяется вероятность того, что на интервале (ґ,4) ошибки не проявятся:
Р^(ґ, ґ,) = 0> = ехр| — ^ 1(и)ёи I.
Для оценки вероятности Р необходимо по заданной статистике доработки ПО построить функцию, аппроксимирующую т(ґ) или Х(ґ), и на основании этого получить верхнюю оценку т(ґ) или Х(ґ) с заданным уровнем доверия. После подстановки этой оценки в
(*) можно вычислить показатель надежности ПО.
Для выбора аппроксимирующей зависимости предлагается использовать критерий минимума среднеквадратичного отклонения, аппроксимирующей кривой — экспоненту. В качестве параметра ґ берутся дискретные значения номеров соответствующих версий ПО (из натурального ряда чисел 1,2,3. ).
Таким образом, мы получили две оценки надежности ПО: Я1 как результат оценки процесса разработки и Я2 как результат тестирования готового программного продукта.
На основании этих оценок предлагается новая модель оценки надежности ПО. В рамках этой модели введем два новых понятия: класс надежности и матрица надежности. Под классом надежности будем понимать совокупную оценку надежности программного продукта, которая базируется на оценке процесса разработки и результатов испытания ПО и позволяет сравнивать программные продукты между собой по надежности их функционирования. Таблица иллюстрирует понятие матрицы надежности.
*2 *1 0-50 % 51-75% 76-90% 91-98% 99-100%
0-10 Класс М Класс К Класс Н Класс Б —
11-20 Класс Ь Класс ] Класс в Класс Б Класс В
21-25 — Класс I Класс Е Класс С Класс А
Будем откладывать по горизонтали интервалы оценки надежности Я2, а по вертикали — интервалы оценки надежности Я1. На пересечении этих интервалов получим класс надежности для данного продукта. Два пересечения не определяют класса надежности: когда одна из оценок низшая, а вторая — наивысшая.
В таких случаях будем считать, что либо процесс тестирования организован некорректно, либо дана не отражающая реальности оценка процесса разработки. Остальные классы могут быть ранжированы по степени увеличения надежности в соответствии с их положением в матрице надежности. Класс А мы представляем как класс высоконадежного ПО, показавшего максимальную вероятность дальнейшей безотказной работы и процесс разработки которого оценен максимально. Остальные классы представляют ПО меньшей надежности, однако в некоторых случаях этой надежности будет достаточно для нормального функционирования конкретного ПО.
1. Предложен новый способ практической оценки надежности ПО, основанный на оценках процесса разработки ПО и результатов тестирования программного продукта. Введены понятия матрицы надежности и класса надежности для количественного расчета надежности ПО.
2. Определены факторы, влияющие на надежность, по которым возможно производить оценку процесса разработки ПО, сформулированы принципы оценки этих факторов по пятибалльной шкале.
3. Формализованы требования к модели оценки надежности по результатам его тестирования. Адаптирована модель оценки надежности, основанная на неоднородных Пуас-соновских процессах, которая максимально ориентирована на оценку надежность программного средства по результатам его тестирования в производстве.
1. ISO 9126:1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению. 186 с.
2. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Tecrminology (ANSI). 1283 с.
3. Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств: Учеб. пособие под ред. О.С.Разумова. М.: Финансы и статистика, 2003. 284 с.
1. Коганов А.В., Романюк С.Г. Экономический подход к понятию надежности программы — http://inf.tu-
5. Липаев В.В. Надежность программных средств. Сер.: Информатизация России на пороге XXI века. М.: СИНТЕГ,1998. 232 с.
6. Шураков В.В. Надежность программного обеспечения систем обработки данных: Учебник. 2-е изд., пе-рераб. и доп. М.: Финансы и статистика, 1987. 272 с.
7. Терехов А. А. // BYTE/Россия. 1999. №12. С.12-18.
8. Майерс Г. Надежность программного обеспечения. М.: Мир, 1980. 360 с.
9. Технологии разработки программного обеспечения: Учеб. пособие. 2-е изд. / С.Орлов. СПб.: Питер, 2003. 480 с.
Источник: cyberleninka.ru
Оценка надежности программ цифровых ЭВМ
В современных АСУ, использующих цифровые ЭВМ, очень велико значение не только безотказной работы машин, но и программ, не имеющих скрытых ошибок. В настоящее время существует тенденция к снижению качества программ, увеличению в них количества ошибок.
Современные методы разработки и проверки программ не обеспечивают создания оптимальных программ даже при известных путях их улучшения. В практике программирования разработчику обычно трудно оценить несколько возможных решений, так как проверка программы часто возможна лишь после объединения ее частей, когда изменения в программе связаны со значительными затратами времени и средств.
Кроме того, часто используются ранее составленные блоки программ, что также затрудняет оптимизацию программы. Не все блоки программируются одинаково тщательно и подробно, часто теряется однородность написания различных блоков. Это, как правило, обнаруживается слишком поздно. Существует ряд других факторов, способствующих появлению в программах ошибок.
Понятие ошибка программы можно определить как несоответствие между данной и некоторой «идеальной» программами. Однако, если бы «идеальная» программа существовала, не было бы проблемы. Поэтому, чтобы использовать математический аппарат теории надежности, рассматривают отказы программы — события, состоящие в переходе к неверной работе или остановке программы. После появления отказа программисты исследуют программу в целях поиска (локализации) ошибки и усовершенствования программы.
Сведения об ошибках и их исправлении выдаются на специальных извещениях. Ошибка считается исправленной, если при проведении повторного теста ошибка не обнаружена и выпущено извещение об устранении ошибки. Время от выпуска извещения об ошибке до выпуска дополнительного извещения называется циклом отладки.
По сложности программы можно разделить на несколько типов.
Длина стандартных программ для вычисления элементарных функций не превышает сотни команд. Эти программы проверяются очень тщательно, но иногда в них обнаруживаются ошибки, обычно при специфических значениях аргумента. Проверка стандартных программ не представляет затруднений.
Более сложными программами являются трансляторы, которые применяются для преобразования алгоритмов, записанных на языке программирования в последовательность машинных команд. Трансляторы содержат 10000. 50000 команд. Полную проверку транслятора обычно не удается осуществить, поэтому в процессе эксплуатации продолжается выявление ошибок.
Наиболее сложными являются программы управления в реальном масштабе времени, реализуемые на вычислительных машинах с мультипроцессором (содержат сотни тысяч команд). Полная проверка таких программ в процессе отладки невозможна. Функционирование программы может быть полностью оценено лишь в процессе применения. Ошибки программ обычно проявляются только при действии определенных входных сигналов, которые в данном случае играют роль условий работы программ.
При рассмотрении множества значений входных сигналов ошибки программ могут считаться случайными.
Время эксплуатации программы представляет собой последовательность чередующихся периодов наработки от момента восстановления до отказа программы и времени восстановления Гв (|> от момента отказа до момента восстановления, т.е. внесения в программу исправлений.
Аналогичная модель рассматривалась при оценке надежности восстанавливаемых изделий (см. гл. 3), причем все случайные величины Т® считались одинаково распределенными (аналогично и 7’l( ( ‘ , ). При этом были использованы математические модели теории восстановления. Непосредственное применение этих моделей для оценки надежности программ нецелесообразно из-за ряда особенностей случайного процесса их эксплуатации.
Во-первых, периоды наработки между отказами 7^° имеют тенденцию к увеличению с течением времени эксплуатации. Это связано с тем, что по мере выявления и устранения ошибок их общее количество в программе уменьшается, поэтому отказы программ становятся все более редкими. Процесс совершенствования управляющих программ можно рассматривать как процесс выявления и устранения скрытых дефектов. Существует также тенденция к уменьшению времени восстановления, так как у программистов все время накапливается соответствующий опыт. Вместе с тем можно предположить взаимную независимость случайных векторов Т и Тв.
Во-вторых, большие управляющие программы обычно являются уникальными. Если для технических изделий оценки показателей надежности обычно вычисляются по статистическим данным об отказах и восстановлениях многих однотипных изделий, то при оценке надежности программ возможно лишь индивидуальное прогнозирование.
Большие программы в начальный период эксплуатации обычно работают в одном экземпляре и лишь после выявления и устранения подавляющего большинства ошибок, т.е. при достижении определенного уровня надежности, могут в редких случаях тиражироваться. Поэтому метод оценки надежности программ должен предусматривать период накопления экспериментальных данных с последующим экстраполированием значений показателей надежности программ. Этот период должен быть сравнительно небольшим. Поэтому на практике можно получить не более двух первых моментов случайных величин.
Таким образом, для оценки надежности программ необходима новая, не применявшаяся ранее в теории надежности математическая модель потока случайных событий (отказов и восстановлений).
Наработку между очередными отказами — случайную величину Т и) — можно представить в виде суммы двух случайных величин:
Последовательно применяя формулу (7.1) ко всем периодам наработки между отказами, получаем
Случайная величина Тп наработки до возникновения и-го отказа программы
Введем следующие допущения:
- 1) все случайные величины bF~ v) независимы и имеют одинаковые математические ожидания /ид, и средние квадратические отклонения аД(;
- 2) случайная величина 7 пренебрежимо мала по сравнению
с суммой ?д Т^К
Основанием для второго допущения могут служить следующие соображения. В самый начальный период эксплуатации программы ошибки возникают очень часто, т.е. время Г мало. Сумма (7.3) быстро растет с увеличением л, и доля 7 быстро падает. Будем считать 7 а ДГ .
В соответствий со вторым допущением из формулы (7.2) имеем
При одинаковых Д7′ (0, наработка между (и — 1)-м и я-м отказами случайная величина 7’ имеет математическое ожидание
и среднее квадратическое отклонение
Для случайной величины Тп математическое ожидание
и среднее квадратическое отклонение
Чтобы вычислить значения mj» m,n и о,л, необходимо по данным об отказах программы в течение периода наблюдения /, найти статистические опенки числовых характеристик случайной разности АГ (1) = T :
где «н — число отказов программы за наработку (0, t„).
Учитывая, что при t> t„ число отказов пн » 1, из формул (7.8) и (7.9) имеем
Поскольку случайные величины 7’ (л) и Т„ согласно выражениям (7.4) и (7.5) равны суммам многих случайных величин, 7′ (л) и Тп можно считать распределенными нормально с математическими ожиданиями и дисперсиями, определенными по формулам (7.6)—(7.9), (7.12) и (7.13). Поскольку наработка положительна, на практике используется усеченное на интервале (0, да) нормальное распределение. Обычно нормирующий множитель с а 1.
При л > лн плотность распределения наработки между очередными (я — 1)-м и я-м отказами
где т отсчитывается с момента последнего (я — 1)-го отказа.
Соответствующая функция распределения наработки между отказами
где Ф(и) — табулированная функция, Ф(м) = -7= exp—dt>.
При вычислении вероятности безотказной работы программы удобно использовать условную функцию надежности (вероятность того, что случайная наработка до отказа будет больше заданной наработки, отсчитываемой с момента последнего (и — 1)-го отказа):
В соответствии с формулой (7.14) вероятность безотказной работы в течение заданной наработки (т,, т2) после (я — 1)-го отказа
При сделанных ранее допущениях отказы программы образуют редеющий случайный поток. Ведущая функция потока, т.е. среднее число отказов, происшедших за интервал наработки (0, /), при t> tH
где /»„(/) — функция распределения наработки до появления я-го отказа.
где плотность распределения наработки до появления я-го отказа
Из формулы (7.17) при t > tH имеем выражение для параметра потока отказов программы
График функции со(/) представляет собой слегка волнистую кривую с убывающими максимумами при значениях /=^-юдм где п = ин, nH +1, .
Ввиду сложности выражений (7.16) и (7.18) целесообразно аппроксимировать их более простыми приближенными формулами. Практически имеет смысл применить метод наименьших квадратов. В соответствии с этим методом аппроксимирующая функция (для и(/) целесообразно взять /lexp(-v/)) наилучшим образом согласуется на интервале (/„, tt) с функцией, определяемой выражением (7.18), при выполнении условия
Приравняв нулю частные производные интеграла /, по А и v, получим систему уравнений для определения этих числовых характеристик. Аналогично можно поступить при аппроксимации П(/) функцией 1 — Вехр(-у/).
Источник: studme.org
3.5. Особенности оценки надежности программного обеспечения
Качество программного обеспечения, также как и качество технических объектов и систем является собирательным понятием. Оно выступает, как определенная совокупность свойств. В число таких свойств в первую очередь входит надежность.
Надежностью программного обеспечения, называется свойство программы выполнять требуемые функции в заданных условиях применения. Под условиями применения программы понимаются: перечень и диапазон исходных данных, частота и последовательность их поступления на вход программы, подготовленность оператора, безотказная работа датчиков автоматизированных испытательных комплексов.
Надежность программы — это сложное свойство. Оно включает в себя два простых (частных) свойства: безотказность и восстанавливаемость.
Свойство безотказность программного обеспечения является аналогом безотказности технических средств. Например: вероятность безотказной работы программы, интенсивность программных отказов, среднее время безотказной работы программы и др. Находят применения также такие показатели, как вероятность отсутствия ошибки при однократном обращении к программе и вероятность отсутствия ошибок в программе.
Восстанавливаемостью называется свойство программы, заключающееся в ее приспособленности к исправлению (обнаружению и устранению) ошибок. Показателями восстанавливаемости программ являются: вероятность исправления ошибки в течение заданно времени, интенсивность исправления ошибки, среднее время исправления ошибки и т.д.
Показатели надежности программного обеспечения условно разделяют на две группы. К первой группе относятся показатели сходные с показателями безотказности восстанавливаемых объектов (п. 3.2 – 3.4):
— вероятность безотказной работы программы , где — функция распределения времени безотказной работы программы;
— интенсивность программных отказов , где — плотность распределения времени безотказной работы программы;
— среднее время безотказной работы ;
— вероятность исправления ошибки в течение заданного времени , где — функция распределения времени исправления ошибки;
— интенсивность исправления ошибки , где — плотность распределения времени исправления ошибки;
— среднее время исправления ошибки .
Показатели первой группы имеют привычный вид. Известны соотношения, устанавливающие связь между этими показателями. Например, вероятность безотказной работы программы рассчитывается по формуле
. (3.71)
Однако законы распределения таких случайных величин как время безотказной работы программы время исправления ошибки достаточно трудно формализуется.
Заметим, что в отличие от технических объектов и систем программное обеспечение не имеет этапа старения (износа), характеризуемого ростом числа ошибок. Поэтому интенсивность программных отказов является невозрастающей функцией времени использования программного обеспечения (рис.3.13).
Рис. 3.13. График зависимости интенсивности исправления ошибок от времени использования программного обеспечения
В показателях надежности программного обеспечения, относящихся ко второй группе, в качестве случайной величины выбрано не время безотказной работы, а число маршрутов (логических путей) реализации программы, в которых отсутствуют ошибки. Очевидно, что каждому маршруту программы соответствует определенный набор исходных данных. Поэтому оценка надежности программного обеспечения производиться путем подсчета безошибочных маршрутов или наборов входных данных, соответствующих правильной работе программы.
Во вторую группу показателей надежности программного обеспечения входят:
— вероятность отсутствия ошибки при однократном обращения к программе ;
— вероятность обнаружения ошибок при — кратном обращении к программе ;
— вероятность отсутствия ошибок в программе и т.п.
Предположим, что маршрут реализации программы равновероятен. Тогда показатель надежности программного обеспечения , где — число маршрутов, в которых содержится хотя бы одна ошибка; — общее число возможных маршрутов реализации программы.
При сделанном допущении о равновероятности выбора маршрута программы другие показатели надежности из второй группы находятся с помощью очевидных выражений
, . (3.72)
Нетрудно показать, что формула для расчета выводилась при условии наличия на каждом маршруте программы не более одной ошибки.
В процессе реального функционирования программы поступление на ее вход исходных данных происходит не с одинаковой вероятностью, а диктуется определенными условиями эксплуатации системы РКТ. Характеристикой этих условий является ряд распределения , где — вероятность реализации — го маршрута программы.
Для определения показателя программы вводится индикатор , который принимает значение 1 при отсутствии ошибок при единичном обращении к программе и 0 – при наличии одной или нескольких ошибок на — м маршруте. Тогда математическое ожидание дискретной случайной величины будет равно искомому показателю надежности:
, (3.73)
где — -я реализация случайной величины .
Нахождение ряда распределения представляет собой достаточно сложную проблему. Решение этой проблемы основывается на анализе возможностей появления тех или иных исходных данных в реальных условиях функционирования ОТС.
Источник: studfile.net