Функциональная надежность программного обеспечения

Размещено на http://www.allbest.ru/

Министерство науки и высшего образования Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Российский государственный гидрометеорологический университет»

Филиал в г.туапсе

Кафедра «экономики и управления на предприятии природопользования»

Курсовая работа

По предмету Основы теории надёжности информационных систем

На тему «Функциональная надёжность программного обеспечения»

Исполнитель студент 3 курса группы 121-И

Абян Алэн Артынович

Руководитель Полупанов Владимир Николаевич

Туапсе 2024



Оглавление

Введение

1. Теоретические аспекты функциональной надежности программного обеспечения

1.1 Основные понятия и сущность функциональной надежности

1.2 Методы оценки надежности программного обеспечения посредством применения функционального подхода

1.3 Основные группы метрик, относящиеся к функциональной надёжности программного обеспечения

2. Определение качества и функциональной надежности программного обеспечения

2.1 Применение метрик сложности для функциональной надежности программного обеспечения

2.2 Показатели функциональной надежности программного обеспечения

Заключение

Список использованной литературы



Введение

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

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

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

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

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

Объектом исследования является функциональная надежность программного обеспечения.

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

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

Для достижения поставленной в курсовой работе цели были определены следующие задачи:

изучить теоретические аспекты функциональной надежности информационных систем;

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

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

рассмотреть последовательность использования статического анализа при оценке надёжности программного обеспечения;

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



1. Теоретические аспекты функциональной надежности программного обеспечения

1.1 Основные понятия и сущность функциональной надежности

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

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

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

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

Рисунок 1.1 - Распределение технических средств информационной системы по функциональным подсистемам Рисунок составлен при написании курсовой работы

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

На рисунке 1.1 в каждой функциональной подсистеме квадратами обозначены объекты, участвующие в выполнении функции этой подсистемы. Например, в выполнении функции ФП 1 участвуют объекты 1, 3, 5, 6, 7, 12 информационной системы. Стрелки -- это связи между объектами. Так, в ФП 1 входной информацией для объекта 3 являются выходные результаты работы объектов 1, 6, 12. Рассмотренный подход есть не что иное, как попытка с позиций структурной надежности объединить надежность технических средств и надежность выполнения информационных процессов в АСУ. Эти позиции хорошо известны -- результат объединения получается неудачным. И тому есть две причины [3,с.39]:

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

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

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

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

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

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

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

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

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

Рисунок 1.2 - Фрагмент графа алгоритма задачи. Зависимость вероятности безошибочного выполнения подзадачи от функциональной надежности выполнения составных процедур Рисунок составлен при выполнении курсовой работы

Рассмотрим причинно-следственные связи, приводящие к нарушению информационного процесса при выполнении задачи в целом.

Дело в том, что информационный процесс состоит из совокупности иерархически упорядоченных информационных процессов и реализуется от низшего уровня иерархии (этот уровень иерархии процесса обозначим как imax) до процесса высшего уровня иерархии (этот уровень иерархии принято обозначать как i0 => 0). Ошибки, возникшие на любом уровне иерархии, распространяются до высшего уровня и могут привести к функциональному отказу информационной системы. Причинно-следственная цепочка ошибок применительно к информационному процессу показана на рисунке 1.3.

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

Рисунок 1.3 - Концептуальное представление взаимосвязи функциональной ошибки и функционального отказа системы относительно данного информационного процесса Рисунок составлен при выполнении курсовой работы

Результаты выполнения процесса нулевого уровня иерархии являются выходными результатами выполнения данного информационного процесса в целом. Они могут привести к функциональному отказу относительно данной задачи. Функциональный отказ -- это событие невыполнения функциональной задачи вследствие нарушения информационного процесса [5].

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

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

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

В различных публикациях предлагаемые определения надежности ПО существенно различаются. Ряд авторов механически переносят понятия, присущие структурной надежности объектов, на надежность самого программного обеспечения. Они рассматривают ПО как неотъемлемую часть цифровой техники, на которой оно реализуется. С учетом приведенных рассуждений можно дать следующее определение функциональной надежности ПО: «Функциональная надежность - это совокупность свойств, которые определяют способность программного обеспечения с приемлемым уровнем безошибочности правильно преобразовывать исходные данные в результаты при данных условиях, сохраняя выходные результаты в допустимых пределах» [10,с.57].

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

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

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

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

Сохранение выходных результатов в допустимых пределах достигается:

а) при наличии в составе ПО качественных средств оперативного обнаружения ошибок;

б) при наличии в составе ПО средств обеспечения устойчивости к ошибкам.

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

1.2 Методы оценки надежности программного обеспечения посредством применения функционального подхода

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

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

Названные характеристики могут быть в той или иной степени трансформированы применительно к теории надежности компьютерных программ, в которой понятие надежности выражается в наборе атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени (ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению) [8].

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

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

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

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

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

Аналогично могут быть выделены вероятные отказы по всем функциональным блокам и тогда оценка надежности программного обеспечения может быть произведена согласно следующей формуле [6,с.28]:



(1.1)

где, n- количество выделенных функциональных блоков в программе,

Ni- показатель надежности функционирования i-ого блока;

N- интегральный показатель надежности программного обеспечения.

При этом оценка Ni должна производиться исходя из вероятностей возникновения каждого выделенного вида отказа в блоке [6,с.31]:

(1.2)

где, mi - количество возможных отказов в i-ом блоке;

pij - вероятность возникновения j-ого вида отказа в i-ом блоке.

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

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

1.3 Основные группы метрик, относящиеся к функциональной надёжности программного обеспечения

Все модели надежности можно классифицировать по тому, какой из перечисленных процессов они поддерживают. Существует четыре основные составляющие функциональной надежности программных систем [9,с.62]:

безотказность - свойство программы выполнять свои функции во время эксплуатации;

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

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

защищенность - свойство программы противостоять случайным или умышленным вторжениям в нее.

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

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

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

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

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

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

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

Наиболее простой метрикой стилистики и понятности является оценка уровня комментированности программы F [1,с.83]:

F = Nком/Nстр (1.3)

где, Nком - количество комментариев в программе;

Nстр - количество строк или операторов исходного текста.

Таким образом, метрика F отражает насыщенность программы комментариями. Исходя из практического опыта, принято считать, что F0.1, т.е. на каждые десять строк программы должен приходиться минимум один комментарий.

Более удачен вариант, когда вся программа разбивается на n равных сегментов и для каждого из них определяется Fi [8]:

Fi=sign(Nком/Nстр-0.1) (1.4)

при этом (1.5)

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

Метрики Холстеда

Для измерения теоретической длины программы N М.Холстед вводит аппроксимирующую формулу [1,с.102] :

(1.6)

где, h1 - словарь операторов;

h2 - словарь операторов программы.

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

Выделим, что приведенное выражение представляет собой идеализированную аппроксимацию N=N1+N2, т.е. справедливо для потенциально корректных программ, свободных от избыточности или несовершенства (стилистических ошибок). Несовершенствами можно считать следующие ситуации [1,с.188]:

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

присутствуют тождественные выражения, решающие совершенно одинаковые задачи;

одной и той же переменной назначаются различные имена и т.п.

Подобные ситуации приводят к изменению N без изменения h.

М.Холстед утверждает, что для стилистически корректных программ отклонение в оценке теоретической длины от реальной не превышает 10%. При автоматизации измерения h1, h2, N1 и N2 определить N нетрудно. Тем не менее, оценка N представляет интерес и с другой точки зрения так как N используется как эталонное значение длины программы со словарем h. Длина корректно составленной программы N, т.е. программы, свободной от избыточности и имеющей словарь h, не должна отклоняться от теоретической длины программы N более чем на 10%.

Таким образом, измеряя h1, h2, N1 и N2 и сопоставляя значения N для некоторой программы, при более чем 10%-ном отклонении можно говорить о наличии в программе стилистических ошибок, т.е. несовершенств.

Другой характеристикой, принадлежащей к метрикам корректности программ по Холстеду является уровень качества программирования L (уровень самой программы):

(1.7)

где, V и V* определяются по формуле вида:

(1.8)

Исходным для введения этой характеристики является предположение о том, что при снижении стилистического качества программирования уменьшается содержательная нагрузка и каждый компонент программы и, как следствие, расширяется объем реализации исходного алгоритма. Учитывая это, можно оценить качество программирования на основании степени расширения текста относительно потенциального объема V*. Очевидно, для идеальной программы L=1, а для реальной - всегда L<1.

Нередко целесообразно определить уровень программы, не прибегая к оценке ее теоретического объема, поскольку список параметров программы часто зависит от реализации и может быть искусственно расширен. Это приводит к увеличению метрической характеристики качества программирования. М.Холстед предлагает аппроксимировать эту оценку выражением, включающим только фактические параметры, т.е. параметры реальной программы [1,с.202]:

(1.9)

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

Система метрик Холстеда основана на двух основных понятиях: объеме программы и сложности программы. Объем программы - это мера количества кода, написанного для реализации программы. Он измеряется в единицах объема программы (PVO), которые определяются следующим образом [10,с.117]:

PVO = N1 + N2 (1.10)

где, N1 - количество уникальных операторов в программе;

N2 - количество уникальных операндов в программе.

Уникальные операторы и операнды - это различные элементы кода, такие как ключевые слова, операторы, переменные и константы. Сложность программы - это мера сложности кода, которая определяется количеством управляющих конструкций и взаимодействием между ними. Она измеряется в единицах сложности программы (PVS), которые определяются следующим образом [5]:

PVS = V + E (1.11)

где, V - объем программы;

E - количество управляющих конструкций в программе

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

Выводы по первой главе:

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

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



2. Определение качества и функциональной надежности программного обеспечения

2.1 Применение метрик сложности для функциональной надежности программного обеспечения

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

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

Качество программного обеспечения - это относительное понятие, которое имеет смысл только при учете реальных условий его применения, поэтому требования, предъявляемые к качеству, ставятся в соответствии с условиями и конкретной областью их применения [4, с.94].

Модель качества ПО имеет следующие четыре уровня представления:

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 2.1 - Характеристики и атрибуты качества программного обеспечения Рисунок составлен при написании курсовой работы

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

К атрибутам функциональных возможностей относятся [7,с.15]:

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

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

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

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

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

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

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



xmin = amin / amax (2.1)

xфi = ai /amax (2.2)

где, ai - значение метрики, рассчитанное для конкретного ПС;

amin - минимально возможное значение этой метрики для данного

типа ПС;

amax - максимально возможное значение этой метрики для данного

типа ПС.

Рассчитываем дискриминант di для каждой метрики по формуле[8]:

(2.3)

Рассчитываем R - вероятность снижения надёжности ПС, используя формулу вида, которая отражает, насколько та или иная метрика имеет больший вес для надежности ПС [10,с.89]:

(2.4)

где, лi - весовые коэффициенты для конкретных метрик.

Применение данной формулы показывает должна ли метрика удовлетворять условию вида [5]:

(2.5)

где, N - количество метрик, используемое при расчете риска снижения

надежности (для упрощения задачи можно считать равнозначным

вклад каждой метрики в результат расчета риска снижения

надежности, в нашем случае лi = л = 0,0625)

Задание к первому варианту курсовой работы предусматривало исходные

значения метрик сложности ПО (лi = л = 0,0625), которые представлены в табличной форме (таблица 2.1).

Таблица 2.1 - Исходные значения метрик сложности ПО (лi = л = 0,0625) Таблица - задание к курсовой работе (составлена преподавателем)

№ п/п	Метрики ПО	amin *)	amax *)	ai **)
1	V	108	1364	1202
2	V*	540	83362,41	71119
3	CL	7	368	255
4	Cl	25	1278	659
5	CLI	41	4213	75
6	Q	67	3589	3454
7	N^	6	186	131,4
8	L	0,0054	2	0,246
9	L^	0	3	0,25
10	E	29	967	736
11	WMC	13	299	202,4
12	DIT	1	8	6,429
13	NOC	1	32	25,548
14	CBO	1	27	4,308
15	RFC	1	163	126,543
16	LCOM	-39	387	20,094
*) amin и amax - минимально возможное и максимально возможное значение метрики для данного типа ПО; **)ai - метрика данного типа ПО

Согласно ранее представленной методики определения надежности ПО были произведены расчеты по формулам 2.1 - 2.5 и полученные результаты отражены в таблице 2.2. При заданных данных лi = л = 0,0625 и di по данным таблицы 2.2 рассчитываем соотношение R:R = 0,007686 ? 0,0077. Расчеты показывают, что вероятность снижения надёжности программного обеспечения составят около 0,008 или 0,8%. Данная погрешность считается минимальной, а уровень надежности приемлемым.

Таблица 2.2 - Результаты расчета вероятности снижения надежности ПС Таблица составлена в ходе написания курсовой работы

№ п/п	Метрики	amin	amax	ai	xmin	xфi	di*)
1	V	108	1364	1198	0,079179	0,878299	0,011915
2	V*	540	83362,41	71116	0,006478	0,853094	0,001123
3	CL	7	368	252	0,019022	0,684783	0,008926
4	Cl	25	1278	657	0,019562	0,514085	0,018859
5	CLI	41	4213	75	0,009732	0,017802	0,542212
6	Q	67	3589	3450	0,018668	0,961271	0,000766
7	N^	6	186	128,4	0,032258	0,690323	0,014953
8	L	0,0054	2	-0,196	0,002700	-0,098000	-0,030333
9	L^	0	3	0,533	0,000000	0,177667	0,000000
10	E	29	967	732	0,029990	0,756980	0,009925
11	WMC	13	299	202,5	0,043478	0,677258	0,021661
12	DIT	1	8	6,571	0,125000	0,821375	0,031067
13	NOC	1	32	25,703	0,031250	0,803219	0,007903
14	CBO	1	27	4,338	0,037037	0,160667	0,200926
15	RFC	1	163	126,698	0,006135	0,777288	0,001769
16	LCOM	-39	387	20,103	-0,10077	0,051946	-1,670853

2.2 Показатели функциональной надежности программного обеспечения

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

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

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

Итак, первая группа показателей [7,с.88]:

вероятность безошибочного выполнения программы - P. Этот показатель предназначен для оценки отсутствия ошибок в данной программе после ее написания и отладки.

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

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

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

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

(2.6)

После ряда преобразований находим приближенное выражение вероятности отсутствия ошибки в результатах выполнений программы в течение времени ее эксплуатации по формуле вида [8]:

P(t) exp (1 a P P) t] (2.7)

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

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

Основными критериями классификации моделей выступали два достаточно простых метода исследования:

1. Исследование временных отрезков между ошибками.

2. Исследование количества ошибок за определенный период времени (измерение времени «в режиме настенных часов» или измерение времени относительно исполнения процессов устройствами компьютера).

Считалось, что модели классифицированные данным способом взаимно не пересекаются и могут включать в себя частные случаи в каждом исследовании [7,с.121].

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

временной отрезок;

общее количество ошибок, которые возможно отследить за бесконечный или конечный отрезок времени;

распределение количества ошибок произошедших за время t (По Типу Пуассона или биноминальному типу);

класс ошибки или функциональная форма активности ошибок за определенное время (применяется только для испытаний с конечными временными отрезками);

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

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

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

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

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

Выводы по второй главе курсовой работы.

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



Заключение

При изучении темы курсовой работы «Функциональная надёжность программного обеспечения» было изучено много научных статей, монографий и литературных источников как российских, так и зарубежных авторов, что в итоге позволило сделать ряд выводов по изучаемому вопросу исследования:

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

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

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

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

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

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

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

В целом, поставленная цель курсовой работы - достигнута.

Задачи, намеченные для достижения цели - решены.



Список использованной литературы

1. Гнеденко, Б.В., Беляев, Ю.К., Соловьев, А.Д. Математические методы в теории надежности. - М.: Наука, 2020. - 524 с.

2. Куликов, В.А. Методика расчета надежности выполнения алгоритмов. Надежность и контроль качества. - М.: Омега, 2021. - 207 с.

3. Майерс, Г. Надежность программного обеспечения / Пер. с англ. - М.: Мир, 2022. - 360 с

4. Мартин, Дж. Вычислительные сети и распределенная обработка данных: программное обеспечение, методы и архитектура / Дж. Мартин. - М.: Финансы и статистика, 2022. - 525 c.

5. Основы функциональной надежности программного обеспечения [Электронный ресурс]

6. Половко, А.М., Гиндин, С.И., Новоселов, А.И. Надежность программного обеспечения. - М.: ИНФРА, 2019. - 137 с.

7. Смагин, В.А. Моделирование и обеспечение надёжности программных средств АСУ.- СПб.: ВИКУ им. А.Ф. Можайского, 2020. - 149 с.

8. Стасюк, С. Г. Оценка надежности программного обеспечения.

9. Тейер, Т., Липов, М.П., Нельсон, Э. Надежность программного обеспечения. - М.: Информационные технологии, 2022. - 611 с.

10. Шубинский, И.Б. Функциональная надежность информационных систем: методы анализа. - М.: Экономический анализ, 2022. - 216 с.

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