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

ВЫБОР И ОБОСНОВАНИЕ МОДЕЛЕЙОЦЕНКИ КАЧЕСТВА И НАДЕЖНОСТИ ПРОГРАММНЫХ ПРОДУКТОВПонятие надежности программного продукта возникло по аналогии спонятиемнадежностиаппаратурыилитехническихизделий.Аналогияобусловлена тем, что и аппаратуре, и программам свойственны отказы. Хотявнешние проявления отказов программ и аппаратуры схожи, причины ихпринципиально различны.

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

Моделирование общих требований к качеству программногопродуктаКлассификации уязвимостей на основе причин их возникновения (дефектов)в общем виде представлены в Таблице 2 Приложение В.С учетом данной классификации разработчики обязаны соблюдать основныетребования, изложенные как в отечественных, так и зарубежных стандартах.Общие требования к качеству программного продукта определены в модели,указанной на Рисунке 15.Применяемость данной модели качества распространена не только наконкретный программный продукт, но и различные компьютерные системы, всостав которых входит программное обеспечение.Модель, изображенная на Рисунке 15, удовлетворяет требованиям стандартаГОСТРИСО/МЭК25010-2015,являющегосясоставнойчастьюсериимеждународных стандартов SQuaRE6, которая состоит из следующих разделов[17]: раздел «Менеджмент качества» (ИСО/IEC 2500n); раздел «Модель качества» (ИСО/МЭК 2501n); раздел «Измерение качества» (ИСО/МЭК 2502n); раздел «Требования к качеству» (ИСО/МЭК 2503n); раздел «Оценка качества» (ИСО/МЭК 2504n); раздел «Расширение SQuaRE» (ИСО/МЭК 25050 - ИСО/МЭК 25099).Стоит учитывать, что ГОСТ Р ИСО/МЭК 25010-2015 предлагаетразработчику использовать эталонную модель качества программного продукта,приведенную на Рисунке 16.SQuaRE – Программные требования и оценка качества продукции (Software product QualityRequirements and Evaluation).6Качество системы / программной продукцииСовместимостьУровеньпроизводительностиФункциональнаяпригодностьсосуществование;интероперабильностьвременные характеристики;использование ресурсов;потенциальные возможностифункциональная полнота;функциональная корректность;функциональная целесообразностьНадежностьзавершенность;готовность;отказоустойчивость;восстанавливаемостьУдобствоиспользованияопределимость пригодности;изучаемость;управляемость;защищенность от ошибки пользователя;эстетика пользовательского интерфейса;доступностьПереносимостьСопровождаемость48Защищенностьконфиденциальность;целостность;неподдельность;отслеживаемость;подлинностьадаптируемость;восстанавливаемость;взаимозаменяемостьмодульность;возможность многократного использования;анализируемость;модифицируемость;тестируемостьРисунок 15 - Общие требования к качеству программного продуктаКачествопрограммнойпродукцииопределяюткачестваПоказателикачествасостоит изопределяет49ХарактеристикикачестваФункцияизмерениясостоят изприменяютсяПодхарактеристикикачестваРисунок 16 - Эталонная модель качества программного продуктаЭлементыпоказателейкачества50Качество программного продукта может быть оценено путем измерения каквнутренних свойств (статические показатели промежуточных продуктов), так ивнешних свойств (оценка поведения кода при исполнении) или посредствомизмерения свойств качества при использовании (продукт эксплуатируется вреальных или моделируемых условиях).

Качество в жизненном цикле можнопредставить схемой, изображенной на Рисунке 17.На схеме (рис.17) видна взаимосвязь целевых объектов модели качества. Накачество программного продукта и системы влияют следующие процессыжизненного цикла программного обеспечения: процесс обработки требований к качеству; процесс проектирования; процесс тестирования.На качество ресурсов, таких как человеческие ресурсы, используемые впроцессе разработки программного продукта, влияют программные инструментыи методы.

И как следствие, оказывают влияние на качество продукции в целом.Схема сказанного выше, приведена на Рисунке 18.51ПроцессПрограммный продуктвоздействияКачествопроцессавоздействияВнутреннеекачествозависит отЭффект отиспользования ППвоздействияВнешнеекачествозависит отКачество прииспользованиизависит от51ИзмеренияпроцессаВнутренниеизмеренияВнешниеизмеренияРисунок 17 - Качество программного продукта в жизненном циклеИзмерениякачества прииспользовании52Качество процессажизненного циклапрограммногопродукта / системыКачество программнойпродукцииКачество системыКачество другихкомпонентовКачество ресурсовКачество прииспользованиисистемыКонтекстиспользования522АВЗадачаСреда«А» влияет на «В» или «В» определяется «А»Рисунок 18 - Процессы, влияющие на качество программного продуктаЗаинтересованныестороны53В рамках заявленной терминологии данной работы видно, что основнымихарактеристиками качества программного продукта являются: функциональная пригодность; надежность; уровень производительности; удобство использования; защищенность; совместимость; сопровождаемость; переносимость.Указанные характеристики не могут быть учтены при использованиипрограммного продукта, не имеющего исходных текстов в силу того, что егоневозможно проверить в полном объеме на требования, предусмотренныеГОСТами.Начиная с 2016 года на территории Российской Федерации вступил в силустандарт ГОСТ Р 56939-2016, содержащий в себе рекомендации для разработчиковпо созданию документации на стадии разработки программного продукта.

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

В лучшем случае, при создании программного продукта,разработчик ограничивается обязательными документами, предусмотреннымиЕСПД7.2.2 Модели оценки надежности программных продуктовНаравне с основными типами моделей оценки надежности сложных систем вцелом, и программных продуктов в частности, используются байесовские модели,условно-геометрические и условно-экспоненциальные модели, обновляющиесямодели, а также модели роста надежности типа порядковых статистик (мозаичныеЕдиная система программной документации (ЕСПД) – комплекс государственныхстандартов Российской Федерации755модели) [22].

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

При этом вработах [4 и 21] показано, что единого мнения о том, что такое надежностьпрограммного продукта пока нет.2.2.1. Аналитические моделиМодель Джелински - МорандыМодель основана на допущениях, что время до следующего отказараспределеноэкспоненциально,аинтенсивностьотказовпрограммыпропорциональна количеству оставшихся в программе ошибок.Вероятность безотказной работы ПП как функция времени tiравна ( ) = − ,(1)где λi- интенсивность отказов, = (N – (i − 1)),(2)здесь CD- коэффициент пропорциональности; N- первоначальное количествоошибок.В (1) отсчет времени начинается от момента последнего (i- 1) - го отказапрограммы.Используя метод максимума правдоподобия на основании (1), обозначаячерез k номер прогнозируемого отказа, получаем, что функция правдоподобияимеет вид56−1= ∏=1 ( − + 1) − (−+1)(3)Логарифмическая функция правдоподобия имеет вид−1 = ln = ∑=1[ln( ( − + 1)) − ( − + 1) ](4)Условия для поиска экстремума−1 1= ∑[ − ( − + 1) ] = 0=1 (5)−1 1= ∑[ − ( − + 1) ] = 0=1 (6)Из (6) получаем =1−+1∑−1=1 ∑−1=1(7)Подставляя (7) в (5), имеем−1∑−1=1 ( − 1)= ∑ ( − + 1)1−1=1∑=1−+1(8)При известных значениях k; t1,t2,…...,tk из (7) и (8) можно найти значенияпараметров модели CD и N, затем интенсивность отказов, время между отказамиtk+1, вероятность безотказной работы через время t k + 1 после последнего отказа.Достоинством модели является простота расчетов, а основным недостатком,что при неточном определении величины N интенсивность отказов программы может стать отрицательной [33].Модель ШуманаВ модели предполагается, что тестирование проводится в несколько этапов,каждый из которых представляет собой выполнение программы по наборутестовыхданных.Выявленныевтечениеэтапатестированияошибкирегистрируются, но не исправляются.

По завершении этапа исправляются все57обнаруженные ошибки, корректируются тестовые наборы и проводится новый этаптестирования.Пустьвсегопроводятсяkэтаповтестирования.Обозначимпро-должительность каждого этапа через t1, ..., tk, а число ошибок, обнаруженных накаждом этапе, через m1, ..., mk.Пусть T= t1+ ... + tk- общее время тестирования; n= m1+ ...

+ mк - общее числообнаруженных и исправленных при тестировании ошибок; ni= m1 + ... + mi- числоошибок, исправленных к началу (i+ 1)-го этапа тестирования (n0= 0).Модель Шумана ПП на i-м этапе тестирования описывается функциейнадежности () = − ,(9)где λi= (N— ni-1)С; N- первоначальное количество ошибок в ПП; N- ni -lколичество ошибок, оставшихся к началу i-го этапа; C- коэффициентпропорциональности, равный= − −1∑=1 ∑=1(10)Для нахождения первоначального количества ошибок N используемуравнение∑=1 = ∑( − −1 )∑ =1∑=1=1 − −1(11)При известных значениях k; t1, ..., tk; m0 + m1 +... + mk из (10) и (11) можнонайти значения параметров модели С и N.