Методика подготовки исходных данных для нестационарных моделей надежности и планирования испытаний программных средств Текст научной статьи по специальности «Компьютерные и информационные науки»

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

УДК 519.217.2

Методика подготовки исходных данных для нестационарных моделей надежности и планирования испытаний программных средств

Тырва А. В., Бубнов В. П., Шардаков К. С., Бараусов Д. В.

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

Ключевые слова: нестационарная система обслуживания, НСО, программные метрики сложности, программная ошибка, модель роста надежности программных средств.

Введение

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

Библиографическая ссылка на статью:

Тырва А. В., Бубнов В. П., Шардаков К. С., Бараусов Д. В. Методика подготовки исходных данных для нестационарных моделей надежности и планирования испытаний программных средств // Системы управления, связи и безопасности. 2021. № 1. С. 77-103. DOI: 10.24411/2410-9916-202110104.

Reference for citation:

Tyrva A. V., Bubnov V. P., Shardakov K. S., Barausov D. V. The Method of Preparation of Source Data for Nonstationary Reliability Models and Planning of Testing of Software. Systems of Control, Communication and Security, 2021, no. 1, pp. 77-103 (in Russian). DOI: 10.24411/2410-9916-2021-10104.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

совершенных технологий, сред разработки и средств автоматизации тестирования, но и за счет грамотного и эффективного планирования разделения ресурсов при разработке. Так как этапы тестирования и испытаний являются особенно важными при разработке высоконадежных ПС, оптимизация затрат на этих этапах может приводить к значительному повышению эффективности разработки в целом. С другой стороны, эффективное планирование тестирования ведет к повышению надежности разрабатываемого программного продукта. При разработке сложных многомодульных ПС такое планирование может быть выполнено путем обоснованного распределения ресурсов тестирования между отдельными модулями приложения с целью сокращения сроков разработки (повышения надежности системы в целом). Для решения поставленных задач могут быть использованы средства математического моделирования надежности ПС. Этой теме уделяется большое внимание в научной литературе [1-4]. Однако наибольшее распространение получили модели нестационарных систем обслуживания (НСО) [5-8]. Несмотря на достаточно большое количество публикаций посвященных разработке новых моделей нестационарных моделей роста надежности программного обеспечения и методов их расчета, вопросу подготовки исходных данных для процесса моделирования уделено незаслуженно мало внимания. На устранение этого недостатка направлено содержание данной статьи. Данное исследование является логическим продолжением работы [9].

Понятие отказа и ошибки программных средств

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

1) стабильность, связанную с «частотой отказов при ошибках в программном обеспечении»;

2) устойчивость к ошибке, связанную со способностью ПС «поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса»;

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

Надежность ПС является его внутренним свойством и проявляется во времени в процессе эксплуатации.

Основными понятиями, связанными с надежностью ПС, являются отказ, дефект, программная ошибка.

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

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

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

- алгоритмические ошибки;

- ошибки программирования;

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

Внешние факторы, вызывающие отказы ПС:

- ошибки пользователей ПС;

- искажение данных в каналах связи;

- сбои и отказы в аппаратуре;

- использование несовместимых аппаратных средств.

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

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

Дефект в ПС - это последствие использования элемента программы, который может привести к некоторому событию, например, в результате неверной интерпретации этого элемента компьютером (как ошибка в программе) или человеком (ошибка исполнителя). Дефект является следствием ошибок разработчика на любом из процессов разработки - в описании спецификаций требований, начальных или проектных спецификациях, эксплуатационной документации и т.п. Дефекты в программе, не выявленные в результате проверок, являются источником потенциальных ошибок и отказов ПС. Проявление дефекта в виде отказа зависит от того, какой путь будет выполнять специалист, чтобы найти ошибку в коде или во входных данных. Однако не каждый дефект ПС может вызвать отказ или может быть связан с дефектом в ПС или среды. Любой отказ может вызвать аномалию от проявления внешних ошибок и дефектов [13].

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

Интенсивность отказов - это частота появления отказов или дефектов в ПС при тестировании или эксплуатации.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

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

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

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

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

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

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

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

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

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

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

P(t) = P(T0 > t), (1)

где T - наработка до первого отказа.

Частота отказов a(t) есть плотность распределения времени безотказной работы ПС до первого отказа:

a(t) = - P'(s),

P(t) = J a( x)dx. (2)

t

Интенсивность отказов A(t) есть плотность распределения наработки до первого отказа при условии, что до рассматриваемого момента ПС функционировало безотказно:

т) = = - in P(t), P(t)

t

—^Л( x) dx

P(t) = e 0 . (3)

Вероятность безотказной работы P(т, t) в интервале (т, t) определяется как вероятность того, что отказа не будет в интервале т +1 при условии, что его не было в течение времени т:

T + t

— J Л(x)dx

P(t, t) = P(T >т + t\T0 > t) = e T . (4)

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

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

Программные метрики сложности

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

Было предложено множество различных метрик, которые в целом можно объединить в две группы: метрики программного текста и метрики программной архитектуры. Наиболее известными и получившими применение на практике и в научных исследованиях являются метрики, предложенные Холстедом [14-16], МакКейбом [14], Чайдембером и Кемерером [17], Бансия и Дэвисом [18, 19].

Метрики Холстеда вычисляются на основе четырех базовых измерений: количество уникальных операторов щ, количество уникальных операндов щ,

общее количество операторов N и общее количество операндов N.

Длина программы N определяется следующим образом:

N = N + (5)

Объем программы V определяется следующим образом:

V = (N + #2)1п(щ + «2). (6)

Размер программы £ определяется следующим образом:

5 = щ 1п(щ) + «1п(щ). (7)

Сложность программы О определяется следующим образом:

О = ^. (8)

Метрики Холстеда позволяют дать оценки надежности ПС, которые могут быть использованы при моделировании надежности ПС. Например, можно получить оценку количества ошибок в ПС N[20,90]:

V

N = —. (9)

3000

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

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

больше при использовании высокоуровневых языков, чем при использовании, например, ассемблера.

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

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

N = 4,86 + 0,0181, (10)

где Ь - количество тысяч строк кода.

Формула Липова представляет собой модификацию формулы Холстеда:

— о

— = а + А 1п(ь) + А1п2 (Ь), (11)

Ь

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

Были разработаны и другие оценки количества ошибок на основе метрик сложности, например:

N = 4,2 + 0,0015Ь43, (12)

N = 0,069 + 0,00156Ь + 0,00000047Ь2. (13)

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

Цикломатическая метрика сложности у(С), предложенная МакКейбом [20], вычисляется на основе графа потока управления программы по следующей формуле:

у(в) = е - п + 2 р, (14)

где е - количество дуг графа; п - количество вершин графа; р - количество несвязных компонент графа.

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

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

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

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

морфизм, связывание. Поэтому целесообразно использовать специальные объектно-ориентированные метрики:

- метрики применимы (с небольшими изменениями) для различных языков программирования (C++, C#, Java и др.);

- метрики теоретически и математически обоснованы [21, 17, 19], хорошо известны и практически применимы [22];

- исследована и подтверждена возможность применения для раннего обнаружения модулей, потенциально приводящих к отказу [2, 3, 21-23];

- сбор значений метрик сложности не требует больших трудозатрат и может быть автоматизирован [22], в том числе при сборе из проектных документов, разработанных с использованием унифицированного языка моделирования UML - фактически промышленного стандарта проектирования.

Подробный анализ существующих объектно-ориентированных метрик приведен в [22]. В [24] показано, как объектно-ориентированные метрики могут использоваться для прогнозирования повышения надежности при применении обратной семантической трассировки.

Наибольшее распространение получил набор метрик, предложенный Чайдембером и Кемерером [17]:

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

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

- длина наибольшего пути иерархии наследования;

- количество классов-наследников;

- взвешенное количество методов класса;

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

- количество атрибутов классов;

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

[3, 21].

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

7 =-^-, (15)

1 + ¿Ро+ЪРл)

где xi - значение метрики сложности; Р - коэффициент.

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

Параметры модели Д находятся методом максимального правдоподобия [17]. Например, для статистики об ошибках в n программах (или программных модулях) функция правдоподобия Ь(Д) имеет вид:

__n ___

цд)=П (x)y t1 -ж( )]1-У, (16)

i=1

где y = 1, если в i-й программе была обнаружена ошибка, иначе y = 0;

X - вектор значений метрик сложности для i-й программы; Д) - вектор параметров модели.

Значения параметров модели определяет вектор Д , при котором функция правдоподобия максимальна. Для нахождения вектора численными методами решается система уравнений [17]:

n

у -ж( Xi)] = 0,

П (17)

Z[У -ж(xi)] = 0.

J=1

В [3] приводится пример и результат такого моделирования, для чего авторами было проанализировано готовое коммерческое приложение, его программные модули классифицированы как ненадежные (если при тестировании в них обнаружены ошибки) и надежные, определены проектные метрики сложности и построена регрессионная модель:

^ = Y + ^-(-3,97+0,464N+1,470+1,06D) , (18)

где ж - вероятность обнаружения ошибки в классе; N - количество атрибутов класса; O - количество других классов, имеющих этот класс в параметрах методов; D - глубина наследования объекта в иерархии классов.

Помимо метрик набора Чидамбера-Кемерера были предложены и другие наборы метрик. Например, набор метрик качества объектно-ориентированного дизайна Бансия-Дэвиса QMOOD (Quality Metrics for Object-Oriented Design) [18, 19] содержит следующие метрики: количество классов; количество иерархий наследования; среднее количество классов-наследников;

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

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

- метрика агрегации (количество связей типа «часть-целое»);

- доля унаследованных методов в общем числе методов класса; количество виртуальных методов класса;

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

- количество методов класса.

Модели, аналогичные описанной выше, могут быть построены и для других наборов метрик сложности, в том числе на поздних этапах жизненного цикла. Например, на этапе реализации для анализа программного кода могут быть использованы следующие метрики: LOC (lines of code), метрики Холстеда и МакКейба, функциональные точки и др. (обзор метрик сложности и примеры их использования для моделирования надежности можно найти в [23]). Как отмечалось выше, после начала отладки, когда появляются данные о распределении отказов, становится возможным учитывать в прогнозе также оценки моделей надежности.

С понятием надежности ПС связаны три основных процесса [26]: измерение, оценивание и предсказание. Измерение надежности ПС основано на «анализе временных интервалов между последовательными отказами» (обнаружением программных ошибок), которые получены при тестировании или эксплуатации ПС. Оценивание надежности ПС относится к «процессу определения метрик на основе интервалов времени между отказами». Предсказание надежности ПС - «процесс вычисления количественных показателей надежности исходя из характеристик программы» (например, метрик сложности ПС).

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

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

1) системный анализ и разработка спецификаций;

2) проектирование;

3) реализация (программирование);

4) отладка и тестирование;

5) эксплуатация и сопровождение.

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

На этапе проектирования разрабатывается архитектура ПС, проектируется интерфейс системы и компонентов, структуры данных и алгоритмы обработки данных.

Этап реализации подразумевает выбор языка программирования и преобразование разработанных алгоритмов в программные коды.

На этапе отладки и тестирования выполняется проверка правильности функционирования ПС и удовлетворения его спецификациям.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

На этапе эксплуатации происходит непосредственное использование разработанного ПС заказчиком (пользователем). Сопровождение ПС необходимо для внесения корректировок и развития ПС и является продолжением этапов разработки.

В зависимости от последовательности этапов различают различные модели жизненного цикла ПС: каскадная (водопадная), итеративная (эволюционная), спиральная (подробное описание см. [27, 28])

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

Метод планирования испытаний многомодульных программных средств

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

В [29, 30] показано, что модель надежности ПС Чунга-Смагина может быть использована для решения прямой и обратной задач надежности многомодульных ПС. Модель Чунга-Смагина основана на алгоритме расчета функции распределения времени нахождения заявки в сети массового обслуживания [31, 32]. В модели Чунга-Смагина использовано представление ПС в виде совокупности программных компонент (модулей), каждый модуль представляет собой аналог элемента расчета теории надежности.

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

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

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

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

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

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

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

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

Таким образом, для планирования испытаний должны использоваться условные вероятностные характеристики надежности модулей к\, которые получаются из безусловных с учетом вероятности ^ выполнения модуля:

п\ = . (19)

В качестве показателей надежности п в зависимости от собранных исходных данных и этапа жизненного цикла разработки ПС могут использоваться различные показатели. На этапе проектирования целесообразно использовать прогноз наличия ошибок по значениям объектно-ориентированных метрик сложности с использованием средств математической статистики или искусственного интеллекта. Расчет этой оценки производится по формулам (15)-(18).

Когда программный код уже написан и начался этап его тестирования, в случае наличия данных или прогнозов о числе еще не исправленных ошибок и распределении длительностей интервалов времени их обнаружения и устранения, целесообразно применение разработанных моделей надежности ПС на основе распределений фазового типа [33]. Тогда в качестве показателя ж1 используется вероятность безотказной работы Р(?,т) в течение интервала т после испытаний в течение времени ? или вероятность Р (£) того, что в процессе испытаний было устранено ровно у вычисленные по формулам разделов 3.1-3.4 статьи [9]. Для расчета вероятности безотказной работы необходимо определить суммарное время исполнения каждого модуля при работе в составе комплекса.

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

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

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

Тогда вероятность выполнения у-го модуля ^ определяется путем решения системы линейных уравнений баланса: 1 ь р

ъ г=2 *Рг- (20)

i=1

где Ь - среднее время выполнения /-го модуля; р - вероятность перехода из /-го модуля в у-й.

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

Суммарное время выполнения каждого модуля при функционировании в составе многомодульного ПС можно найти с использованием матрицы у(я) [30, 32]:

У ( s)

P

P

P

00 01 02 P yi(s) P11 yi(s) P12 yi(s )

P

0,L+1

P1, L+1 У1( S)

PL0 УL (s) PL1 Уь (S) PL2 Уь (S)

P

P

P

PL,L+1 УL (S)

P

(21)

- Ь+1,0 Ь+1,1 -1 Ь+1,2 Ь+1,Ь+1

где р - вероятность вызова у-го модуля после исполнения /-го; у (я) - преобразование Лапласа-Стилтьеса (ПЛС) распределения времени исполнения /-го модуля.

Для определения времени выполнения многомодульного ПС необходимо рассмотреть матрицу, элементами которой являются ПЛС функции распределения времени исполнения модулей за бесконечное число переходов из одного модуля в другой V (я):

V (я) = I + у (я) + у2 (я) +... = I (I - у(я))-1, (22) где I - единичная матрица,

V (я) = 4 (я)/ О(я), (23) где А (я) - алгебраическое дополнение элемента (i,j) матрицы V(я); О(я) -определитель матрицы V (я).

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

Среднее время выполнения многомодульного ПС (при 5 = 0):

T =

dV+i(s ) ds

(24)

Суммарное среднее время выполнения /-го модуля в составе ПС:

Т = д,Г. (25)

Если время работы отдельных модулей значительно зависит от характера входных данных или режима эксплуатации ПС и при этом известен вид и параметры распределения (нормального, Вейбулла, гамма и других). То исходя из экспертных оценок или статистических данных - для универсализации предлагаемого подхода, такие распределения могут быть аппроксимированы распределениями фазового типа (Эрланга, Кокса, гиперэкспоненциальным), описанными в [34]. При этом с практической точки зрения для обеспечения приемлемой точности достаточно использовать две экспоненциальные фазы аппроксимирующего распределения. Такая функциональность реализована в разработанном комплексе программ расчета надежности и планирования испытаний программных средств [35].

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

Т = ТПг '. (26)

Как уже указывалось, в качестве ' целесообразно использовать:

прогноз наличия ошибок по значениям объектно-ориентированных метрик сложности - на этапе проектирования ПС;

вероятность безотказной работы р

T ,т

К

I

V

или вероятность

У

исправления всех N ошибок

N

\

К

К,

V

- при разработке и

У

тестировании (расчетные формулы приведены в разделе 3 [9]). Применение предлагаемого метода планирования испытаний на этапе проектирования схематично проиллюстрировано на рис. 1.

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

Рис. 1. Использование стратегии планирования тестирования ПС

На рисунке показаны два проекта по разработке ПС. В проекте 1 завершены этапы проектирования (собраны проектные метрики сложности из UML-диаграмм), кодирования и тестирования. По статистике ошибок, собранной при тестировании, строится прогнозная модель влияния метрик сложности на надежность ПС, то есть определяются коэффициенты ß в формуле (15). В проекте 2 выполнены только работы этапа проектирования и собраны проектные метрики сложности из UML-диаграмм. По построенной модели прогнозируются потенциально ненадежные модули. Использование экспертных заключений о характере распределения времени исполнения отдельных модулей и стохастического графа ПС позволяет выполнить оценку степени влияния каждого модуля на надежность ПС в целом и, следовательно, оптимизировать распределение ресурсов тестирования, построить план испытаний.

В случае использования метода на этапе тестирования, данные о распределении времени исполнения отдельных модулей и вероятности вызовов модулей задаются не экспертом, а получаются автоматизировано как результат профилирования работы ПС для различных наборов входных данных (например, с использованием средств MS Visual Studio Profiler, Rational PurifyPlusj. Метрики сложности также автоматизировано собираются непосредственно из программного кода (например, средствами QMOOD++, JStyle [36]). Если возможно использование моделей надежности на основе распределений фазового типа, план испытаний составляется на основе значений соответствующих показателей надежности, рассчитанных с применением указанных моделей.

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

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

ориентированных метрик сложности. Таким образом, разработанная методика планирования испытаний расширяет известные аналоги (например, [29-30]) на более ранние этапы жизненного цикла. Кроме того, при планировании испытаний учитывается вклад каждого модуля в надежность ПС в целом на основе прогноза времени и вероятности его исполнения, получаемого из экспертной оценки стохастического графа ПС и характера распределения времени исполнения модулей на этапе проектирования или результатов профилирования работы ПС - при тестировании.

Предлагаемый метод планирования испытаний многомодульного ПС снижает трудозатраты на тестирование и отладку, и обладает следующими особенностями:

- использует рассчитанные вероятностные показатели надежности и метрики сложности в качестве исходных данных для анализа и планирования;

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

- может применяться на всех этапах цикла разработки ПС;

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

Методика подготовки исходных данных

Нестационарные модели надежности ПС [9] удовлетворяют следующим требованиям с точки зрения прикладного использования:

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

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

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

Методика планирования испытаний ПС [9] удовлетворяет следующим требованиям с точки зрения прикладного использования:

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

- методика применима на этапе проектирования и испытаний;

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

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

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

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

Исходными данными для моделей надежности и методики планирования испытаний являются следующие значения:

- состав ПС как набор модулей, общее количество которых п;

- связи между модулями, представленные в виде ориентированного графа О;

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

- значения программных метрик для каждого модуля {Х1,..., Хп};

- временные характеристики процесса испытаний в виде статистики мощности N средних значений длительностей интервалов времени между обнаружением последовательных программных ошибок {^}, i = 1,...,N и длительности интервалов времени устранения ошибок

и}, i = 1,...,N.

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

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

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

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

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

При использовании моделей надежности на этапе тестирования в качестве исходных данных могут использоваться те сведения об ошибках, которые получены за время испытаний до момента моделирования. Результатом моделирования с использованием моделей, описанных в разделе 3 работы [9], в этом случае будет оценка общего числа программных ошибок и времени до нахождения очередной ошибки.

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

Далее предложена методика определения исходных данных для моделей надежности, описанных в разделе 3 работы [9]. Описываемая схема применения графически представлена на рис. 2.

Данные о завершенных проектах

ОО-метрики сложности (М) Результаты испытаний (8) Факторы разработки (Р)

Регрессионная модель влияния сложности на надежность

п =

1 + е

(Po+Iß X )

Модель влияния факторов разработки на надежность (аппроксимация сплайнами, нейросеть)

Прогноз числа ошибок, времени их обнаружения и исправления

M S F

Проект 1

M

Проект 2

Рис. 2. Схема применения методики задания исходных данных

Пусть при разработке уже завершенного проекта (1-й проект) была собрана статистика временных характеристик процессов поиска и устранения

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

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

Пусть в процессе разработки 1-го проекта была собрана следующая статистика о процессах обнаружения и устранения программных ошибок: общее количество ошибок N(1). Длительности интервалов времени обнаружения ошибок (1),i = 1,...,и длительности интервалов времени устранения ошибок (1), i = 1,..., N(1). Известны данные о структуре ПС 1-го проекта: оно состоит из I(1) классов, и для каждого класса собраны значения объектно-ориентированных метрик сложности набора Чайдамбера-Кемерера. Для каждого класса на основе значений объектно-ориентированных метрик сложности рассчитана вероятность наличия в нем ошибки л1 (1), i = 1,..., с использованием подхода, описанного в [3, 12] по формулам (15)—(18).

Рассчитанные вероятности яг(1),I = 1,...,I(1)используются для вычисления

ожидаемого количества ошибок П(1) как числа классов с оценкой вероятности наличия ошибки, превышающей некоторое пороговое значение И (например, ¿=0,5):

1( рг)

П(рг) = (РГ) - А), (27)

г-1

[1, к > 0

где §(к) = <! рг - номер проекта.

[0, к < 0

Если доступны только средние вероятности наличия ошибок в классе ожидаемое количество ошибок П(1) определяется как:

П( рг) = п\(рг). (28)

Описанные выше данные о первом проекте используются для моделирования надежности 2-го проекта, для которого по результатам этапа проектирования известны общее число классов I(2) и рассчитаны предполагаемые вероятности наличия ошибок в классах^(2) , i = 1,..., N(2). По формулам (27)-(28) на

основе значений п1 (2), i = 1,...,N(2)рассчитывается величина П(2). Предполагается, что 1 -й и 2-й проекты похожи, поэтому должно соблюдаться соотношение:

П(1) П(2)

= К ^ (29)

N(1) N(2)

где К - коэффициент, учитывающий подобие проектов.

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

DOI: 10.24411/2410-9916-2021-10104

Systems of Control, Communication and Security

ISSN 2410-9916

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

Предполагаемое количество ошибок в ПС 2-го проекта рассчитывается как:

N(2) = К . (30)

П(1)

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

Если N(2) > N(1), то для упрощения моделирования имеет смысл представить ПС 1 -го проекта в виде набора модулей (если это возможно), оценить надежность каждого модуля, а затем рассчитать показатели надежности всего ПС согласно модели Чунга-Смагина [29-30, 38].

В простейшем случае, если проекты 1 и 2 подобны, то есть К«1 и N(2) > N(1), для построения модели 2-го проекта могут быть использованы следующие значения: общее количество ошибок N(2), длительности интервалов времени обнаружения ошибок ti (2) = tJ (1), i = 1,..., и длительности интервалов

времени устранения ошибок /(2) = /(1),i = 1,...,N(2). В более сложных случаях длительности интервалов времени ti (2) и /(2) должны быть экспертно скорректированы относительно ti (1) и /(1) с учетом различия факторов разработки.

Заключение

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

Исследования, выполненные по данной тематике, проводились в рамках бюджетной темы № 0073-2019-0004.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

Литература

1. Dick S., Bethel C. L., Kandel A. Software-Reliability Modeling: The Case for Deterministic Behavior // IEEE Transactions on Systems, Man, and Cybernetics -Part A: Systems and Humans. 2007. Vol. 37. № 1. P. 106-119.

2. El-Emam K. Object-Oriented Metrics: A Review of Theory and Practice // Advances in software engineering. 2002. № 1. P. 23-50.

3. El-Emam K., Melo W., Machado J. C. The prediction of faulty classes using object-oriented design metrics // Journal of Systems and Software. 2001. № 1. P. 63-75.

4. Musa J. D. The Measurement and Management of Software Reliability // Proceedings of the IEEE. 1980. № 9. P. 1131-1143.

5. Бубнов В. П. Комплекс моделей надежности программных средств с распределениями фазового типа // Вестник Всероссийского научно-исследовательского и проектно-конструкторского института электровозостроения. 2011. № 1. С. 185-193.

6. Bubnov V. P., Tyrva A. V., Khomonenko A. D. Model of reliability of the software with Coxian distribution of length of intervals between the moments of detection of errors // Proceedings of 34th Annual IEEE Computer Software and Applications Conference (COMPSAC 2010). - Seoul. 2010. - P. 238-243.

7. Bubnov V. P., Tyrva A. V., Khomonenko A. D. Software Reliability Model with Coxian Distribution of Length of Intervals Between Errors Detection and Fixing Moments // Proceedings of 35th Annual IEEE Computer Software and Applications Conference (COMPSAC 2011). - Munich. 2011. - 2011. - P. 310-314.

8. Данилов А. А. Комплекс программ оценивания надежности и планирования разработки программных средств на основе динамических моделей // Интеллектуальные технологии на транспорте. 2017. № 4. С. 18-24.

9. Бубнов В. П., Сафонов В. И., Шардаков К. С. Обзор существующих моделей нестационарных систем обслуживания и методов их расчета // Системы управления, связи и безопасности. 2020. № 3. С.65-121. DOI: 10.24411/2410-9916-2020-10303.

10. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. - М.: ИПК Издательство стандартов, 2004. - 9 с.

11. ГОСТ 27.002-89 Надежность в технике (ССНТ). Основные понятия. Термины и определения. - М.: ИПК Издательство стандартов, 2002. - 32 с.

12. Благодатских В. А., Волнин В. А., Поскакалов К. Ф. Стандартизация разработки программных средств: Учеб. пособие. - М.: Финансы и статистика, 2005. - 288 c.

13. Петрухин В. А., Лаврищева Е. М. Методы и средства инженерии программного обеспечения информация // Национальный Открытый Университет «ИНТУИТ» [Электронный ресурс]. - URL: http://www.intuit.ru/department/se/swebok/ (дата обращения: 10.11.2020).

14. Kan S. H. Metrics and Models in Software Quality Engineering, Second Edition. - Addison Wesley, Reading MA, 2002. - 344 p.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

15. Lee A. T., Gunn T., Pham T., Ricaldi R. Software Analysis Handbook: Software Complexity Analysis and Software Reliability Estimation and Prediction. // Technical Memorandum 104799: National Aeronautics and Space Administration, 1994. - 91 p.

16. Холстед М. Х. Начала науки о программах. - М.: Финансы и статистика, 1981. - 128 с.

17. Chidamber S. R., Kemerer C. F. A metrics suite for object oriented design // IEEE Transactions on Software Engineering. 1994. Vol. 20. P. 476-493.

18. Bansiya J., Davis C. A. Hierarchical Model for Object-Oriented Design Quality Assessment // IEEE Transactions on Software Engineering. 2002. Vol. 28. P. 4-17.

19. Olague H. M., Etzkorn L. H., Gholston S., Quattlebaum S. Empirical Validation of Three Software Metrics Suites to Predict Fault-Proneness of Object-Oriented Classes Developed Using Highly Iterative or Agile Software Development Processes // IEEE Transactions on Software Engineering. 2007. Vol. 33. № 6. P. 402-419.

20. Fenton N. E., Neil M. A critique of software defect prediction models // IEEE Transactions on Software Engineering. 1999. Vol. 25. P. 675-689.

21. Briand L., Devanbu P., Melo W. An Investigation into Coupling Measures for C++ // Proceedings of the 1997 (19th) International Conference on Software Engineering. 1997. P. 412-421.

22. Genero M., Piattini M., Caleron C. A survey of metrics for UML class diagrams // Journal of Object Technology. 2005. Vol. 4. № 9. P. 59-92.

23. Basili V. R., Briand L. C. A validation of object-oriented design metrics as quality indicators // IEEE Transactions on Software Engineering. 1996. Vol. 22. P. 751-761.

24. Rogalchuk V. V., Tyrva A. V., Khomonenko A. D. Estimation of program reverse semantic traceability influence at program reliability with assistance of object-oriented metrics // Software Engineering Conference in Russia (CEE-SECR), 2009 5th Central and Eastern European. 2009. P. 125-130.

25. Khoshgofttaar T. M., Woodcock T. G. Software Reliability Model Selection: A Case Study // Proceedings of International Symposium on Software Reliability Engineering. 1991. P. 183-191.

26. Муса Д. Д. Измерение и обеспечение надежности программных средств // Труды института инженеров по электротехнике и радиоэлектронике. 1980. т. 68, № 9. С. 113-125.

27. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия // Программные требования [Электронный ресурс]. 2020. - URL: https://software-testing.ru/library/around-testing/engineering/267-swebok (дата обращения: 15.11.2020).

28. Орлов С. А. Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд. - СПб.: Питер, 2004. - 527 с.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

29. Кузнецов В. В., Смагин В. А. Прямая и обратная задачи надежности сложных программных комплексов // Надежность и контроль качества. 1997. № 10. С. 56-62.

30. Смагин В. А. Техническая синергетика. Вероятностные модели сложных систем - СПб.: ВИКА им. А.Ф. Можайского, 2004. - 171 с.

31. Молчанов О. Е., Бубнов В. П. Определение начальных моментов распределения времени нахождения заявки в сети массового обслуживания // Сборник типовых алгоритмов и программ. 1985. №7. С. 211-217.

32. Смагин В. А., Бубнов В. П., Филимонихин Г. В. Расчет вероятностно-временных характеристик пребывания задач в сетевой модели массового обслуживания // Известия ВУЗов. Приборостроение. 1989. № 2. С. 23-25.

33. Бубнов В. П., Тырва А. В., Еремин А. С. Комплекс моделей нестационарных систем обслуживания с распределениями фазового типа // Труды СПИИРАН. 2014. № 6. С. 61-71.

34. Бубнов В. П., Сергеев С. А. Аппроксимационный метод исследования немарковских систем: учебное пособие. СПб.: Петербургский государственный университет путей сообщения, 2014. - 37 с.

35. Тырва А. В., Хомоненко А. Д., Бубнов В. П. Комплекс программ расчета надежности и планирования испытаний программных средств // Свидетельство о государственной регистрации программ для ЭВМ № 2010615617. 2010.

36. Darcy D. P., Kemerer C. F. OO Metrics in Practice // Software. 2005. Vol. 22. № 6. P. 17-19.

37. Asad C. A., Ullah M. I., Rehman M. J. An Approach for Software Reliability Model Selection // Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC'04). 2004. P. 534-539.

38. Cheung R. C. A User-Oriented Software Reliability Model // IEEE Transactions on Software Engineering. 1980. Vol. 6. P. 118-125.

References

1. Dick S., Bethel C. L., Kandel A. Software-Reliability Modeling: The Case for Deterministic Behavior . IEEE Transactions on Systems, Man, and Cybernetics— Part A: Systems and Humans, 2007, vol. 37, no. 1, pp. 106-119.

2. El-Emam K. Object-Oriented Metrics: A Review of Theory and Practice. Advances in software engineering, 2002, no. 1, pp. 23-50.

3. El-Emam K., Melo W., Machado J. C. The prediction of faulty classes using object-oriented design metrics. Journal of Systems and Software, 2001, no. 1, pp. 63-75.

4. Musa J. D. The Measurement and Management of Software Reliability. Proceedings of the IEEE, 1980, vol. 68, no. 9, pp. 1131-1143.

5. Bubnov V. P. Kompleks modelei nadezhnosti programmnykh sredstv s raspredeleniiami fazovogo tipa [A complex of software reliability models with phasetype distributions]. Vestnik Vserossiiskogo nauchno-issledovatel'skogo i proektno-konstruktorskogo instituta elektrovozostroeniia, 2011, no. 1, pp. 185-193 (in Russian).

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

6. Bubnov V. P., Tyrva A. V., Khomonenko A. D. Model of reliability of the software with Coxian distribution of length of intervals between the moments of detection of errors. Proceedings of 34th Annual IEEE Computer Software and Applications Conference (COMPSAC2010). Seoul, 2010, pp. 238-243.

7. Bubnov V. P., Tyrva A. V., Khomonenko A. D. Software Reliability Model with Coxian Distribution of Length of Intervals Between Errors Detection and Fixing Moments. Proceedings of 35th Annual IEEE Computer Software and Applications Conference (COMPSAC 2011). Munich, 2011, pp. 310-314.

8. Danilov A. A. A set of programs for assessing reliability and planning software development based on dynamic models. Intellectual Technologies on Transport, 2017, no. 4, pp. 18-24 (in Russian).

9. Bubnov V. P., Safonov V. I., Shardakov K. S. Overview of existing models of non-stationary queuing systems and methods for their calculation. Systems of Control, Communication and Security, 2020, no. 3, pp. 65-121 (in Russian). DOI: 10.24411/2410-9916-2020-10303.

10. State Standard R ISO / IEC 9126 - 93. Information technology. Evaluation of software products. Quality characteristics and guidelines for their use. Moscow, Standartov Publ. 2004. 9 p. (in Russian).

11. State Standard 27.002 - 89. Reliability in technology. Basic concept. Terms and definitions. Moscow, Standartov Publ. 2002. 32 p. (in Russian).

12. Blagodatskih V. A., Volnin V. A., Poskakalov K. F. Standartizatsiia razrabotki programmnykh sredstv [Standardization of software development]. Moscow, Finance and statistics Publ., 2005. 288 p.

13. Petrukhin V. A., Lavrishcheva E. M. Methods and means of information software engineering. National opened university "INTUIT". Available at: http://www.intuit.ru/department/se/swebok/ (accessed 10 November 2020) (in Russian).

14. Kan S. H. Metrics and Models in Software Quality Engineering, Second Edition. - Addison Wesley, Reading MA, 2002. - 344 p.

15. Lee A. T., Gunn T., Pham T., Ricaldi R. Software Analysis Handbook: Software Complexity Analysis and Software Reliability Estimation and Prediction.

Technical Memorandum 104799: National Aeronautics and Space Administration, 1994, 91 p.

16. Halsted M. H. The beginning of science about the programs. Moscow, Finance and statistics Publ., 1981. 128 p.

17. Chidamber S. R., Kemerer C. F. A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 1994, vol. 20, no. 6, pp. 476-493.

18. Bansiya J., Davis C. A Hierarchical Model for Object-Oriented Design Quality Assessment. IEEE Transactions on Software Engineering, 2002, vol. 28, no. 1, pp. 4-17.

19. Olague H. M., Etzkorn L. H., Gholston S., Quattlebaum S. Empirical Validation of Three Software Metrics Suites to Predict Fault-Proneness of Object-Oriented Classes Developed Using Highly Iterative or Agile Software Development Processes. IEEE Transactions on Software Engineering, 2007, vol. 33, no. 6, pp. 402-419.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

20. Fenton N. E., Neil M. A critique of software defect prediction models. IEEE Transactions on Software Engineering, 1999, vol. 25, pp. 675-689.

21. Briand L., Devanbu P., Melo W. An Investigation into Coupling Measures for C++. Proceedings of the 1997 (19th) International Conference on Software Engineering. Boston, 1997, pp. 412-421.

22. Genero M., Piattini M., Caleron C. A. survey of metrics for UML class diagrams. Journal of Object Technology, 2005, vol. 4, no. 9, pp. 59-92.

23. Basili V. R., Briand L. C. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, 1996, vol. 22, pp. 751-761.

24. Rogalchuk V. V., Tyrva A. V., Khomonenko A. D. Estimation of program reverse semantic traceability influence at program reliability with assistance of object-oriented metrics. Software Engineering Conference in Russia (CEE-SECR), 5th Central and Eastern European. Moscow, 2009, pp. 125-130.

25. Khoshgoftaar T. M., Woodcock T. G. Software Reliability Model Selection: A Case Study // Proceedings of International Symposium on Software Reliability Engineering. Austin, 1991, pp. 183-191.

26. Musa D. D. Measuring and ensuring the reliability of software. Proceedings of the Institute of electrical and radio electronics engineers, 1980, vol. 68, no. 9, pp. 113 - 125.

27. Orlik S., Baluy Y. Vvedenie v programmnuiu inzheneriiu i upravlenie zhiznennym tsiklom PO Programmnaia inzheneriia. Programmnye trebovaniia [Introduction to software engineering and software lifecycle management. Program requirements]. Available at: https://software-testing.ru/library/around-testing/engineering/267-swebok (accessed 15 November 2020) (in Russian).

28. Orlov C. A. Tekhnologii razrabotki programmnogo obespecheniia [Software development technologies]. Saint Petersburg, Piter Publ., 2004. 527 p. (in Russian).

29. Kuznetsov V. V., Smagin V. A. Priamaia i obratnaia zadachi nadezhnosti slozhnykh programmnykh kompleksov [Direct and inverse problems of reliability of complex software systems]. Nadezhnost' i kontrol' kachestva, 1997, no. 10, pp. 5662. (in Russian).

30. Smagin V. A. Tekhnicheskaia sinergetika. Veroiatnostnye modeli slozhnykh system [Technical synergy. Probable models of complex systems]. Saint Petersburg, MSA named after A. F. Mozhaisky Publ., 2004, 171 p. (in Russian).

31. Molchanov O. E., Bubnov V. P. Opredelenie nachal'nykh momentov raspredeleniia vremeni nakhozhdeniia zaiavki v seti massovogo obsluzhivaniia [Determination of the initial moments of distribution of the time spent by the request in the queueing network]. Sbornik tipovykh algoritmov i programm. 1985. vol. 7, pp. 211 - 217 (in Russian).

32. Smagin V. A., Bubnov V. P., Philimonikhin G. V. Raschet veroiatnostno-vremennykh kharakteristik prebyvaniia zadach v setevoi modeli [Calculation of probabilistic-time characteristics of tasks stay in the network queuing model]. Izvestiia VUZov. Priborostroenie, 1989, vol. 2, pp. 23-25 (in Russian).

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

33. Bubnov V. P., Tyrva A. V., Eremin A. S. Kompleks modelei nestatsionarnykh sistem obsluzhivaniia s raspredeleniiami fazovogo tipa [A complex of models of non-stationary queuing systems with phase-type distributions]. SPIIRAS Proceedings, 2014, no. 6, pp. 61-71 (in Russian).

34. Bubnov V. P., Sergeev S. A. Approximation method for studying non-markov systems. Saint Petersburg, Saint Petersburg state transport university Publ., 2014. 37 p. (in Russian)

35. Tyrva A. V., Khomonenko A. D., Bubnov V. P. Kompleks programm rascheta nadezhnosti i planirovaniia ispytanii programmnykh sredstv. Svidetel'stvo ob ofitsial'noi registratsii programm dlya EVM [A set of programs for calculating reliability and test software planning. The Certificate on Official Registration of the Computer Program]. No. 2010615617, 2010.

36. Darcy D. P., Kemerer C. F. OO Metrics in Practice. Software, 2005, vol. 22, no. 6, pp. 17-19.

37. Asad C. A., Ullah M. I., Rehman M. J. An Approach for Software Reliability Model Selection. Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSACV4). Hong Kong, 2004, pp. 534-539.

38. Cheung R. C. A User-Oriented Software Reliability Model. IEEE Transactions on Software Engineering, 1980, vol. 6, pp. 118-125.

Статья поступила 26 ноября 2020 г.

Информация об авторах

Тырва Алексей Владимирович - кандидат технических наук. Разработчик Java. ООО «1С-Софт». Область научных интересов: модели надежности программных средств, программные комплексы. E-mail: altyr@mail.ru

Бубнов Владимир Петрович - доктор технических наук, профессор. Профессор кафедры «Информационные и вычислительные системы». Петербургский государственный университет путей сообщения императора Александра I. Область научных интересов: вероятностные модели, решение систем дифференциальных уравнений. E-mail: bubnov1950@yandex.ru

Шардаков Кирилл Сергеевич - соискатель ученой степени кандидата технических наук. Аспирант кафедры «Информационные и вычислительные системы». Петербургский государственный университет путей сообщения императора Александра I. Область научных интересов: нестационарные системы обслуживания. E-mail: k.shardakov@gmail.com

Бараусов Даниил Викторович - соискатель ученой степени кандидата технических наук. Специалист. Петербургский государственный университет путей сообщения императора Александра I. Область научных интересов: модели надежности программных средств, программные комплексы. E-mail: barausovv@gmail.com

Адрес: 190031, Россия, г. Санкт-Петербург, Московский пр., д. 9.

DOI: 10.24411/2410-9916-2021-10104

Системы управления,связи и безопасности №1. 2021

Systems of Control, Communication and Security ISSN 2410-9916

The Method of Preparation of Source Data for Nonstationary Reliability Models and Planning of Testing of Software

A. V. Tyrva, V. P. Bubnov, K. S. Shardakov, D. V. Barausov

Relevance. As the degree of automation of management processes in all aspects of human activity increases, the problem of evaluating the reliability of software tools at all stages of their life cycle is growing. A number of mathematical models and methods for calculating software reliability indicators have been developed. A significant place in this series is occupied by non-stationary models of reliability and test planning of software tools. Therefore, research aimed at developing methods for preparing initial data and planning tests is undoubtedly relevant. The aim of this work is to eliminate the discrepancy between a significant number ofpublications on the development of new non-stationary models of software tools and a significantly smaller number of works on the development of methods for preparing initial data and planning experiments using these models. Results. The article presents the results of systematization and analysis of the concepts of software failure and error, provides a critical analysis of software complexity metrics, and defines the methodology for preparing source data and planning software tests. Elements of the novelty of the work are the approach to preparing initial data and planning an experiment for planning tests for both single-module and multi-module software tools at all stages of their life cycle. Practical significance. The material of the article can be effectively used in the tasks of analyzing the reliability indicators of software tools at all stages of their life cycle.

Key words: non-stationary service system, software complexity metrics, programming error, software reliability growth model.

Information about Authors

Alexey Vladimirovich Tyrva - Ph.D. of Engineering Sciences. Software Engineer. 1C-Soft Ltd. Field of research: software reliability models, software packages. E-mail: altyr@mail.ru

Vladimir Petrovich Bubnov - Dr. habil. of Engineering Sciences, Full Professor. Professor at the Department of Information and Computing Systems. Emperor Alexander I St. Petersburg State Transport University. Field of research: probabilistic models, solving systems of differential equations. E-mail: bubnov1950@yandex.ru

Kirill Sergeevich Shardakov - postgraduate student. Postgraduate at the Department of Information and Computing Systems. Emperor Alexander I St. Petersburg State Transport University. Field of research: non-stationary queuing systems. E-mail: k.shardakov@gmail.com

Daniil Victorovich Barausov - postgraduate student. Specialist. Emperor Alexander I St. Petersburg State Transport University. Field of research: software reliability models, software packages. E-mail: barausovv@gmail.com

Address: Russia, 190031, Saint Petersburg, Moskovskiy avenue, 9.

DOI: 10.24411/2410-9916-2021-10104