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

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

Показатели надежности и свойства программных средств

Рассмотрим показатели надежности и свойства программных средств, которые можно разделить на единичные и комплексные.

• •    Завершенность – свойство не попадать в состояние отказов вследствие ошибок в программах и данных; при этом учитываются только отказы ошибок ПО.

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

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

• •    Годность – свойство быть в состоянии выполнять требуемую функцию в данный момент времени при заданных условиях использования [1; 2].

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

• •    Согласованность – свойство соответствовать стандартам и нормативам из законов и подобных предписаний, связанных с надежностью.

Характеристики надежности программного обеспечения

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

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

Таким образом,

Q ( t ) = 1 - p ( t ).                                     (1)

Интенсивность отказов ( t ) – условная плотность вероятности времени до возникновения отказа программы при условии, что до момента t отказа не было:

A (t) = QI / p ( t ).                              (2)

dt

Средняя наработка на отказ Т0 – математическое ожидание временного интервала между последовательными отказами.

Результаты испытаний можно признать положительными, если:

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

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

• •    полученные значения параметров и характеристик при выполнении всех тестовых заданий удовлетворяют установленным критериям или находятся в допустимых пределах отклонений от них;

• •    в ПО реализованы необходимые методы защиты и идентификации в соответствии с требованиями;

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

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

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

Исходные данные при аттестации ПО согласно показателю надежности:

• •    техническое задание (далее – ТЗ), ГОСТы, система команд специализированной ЭВМ;

• •    спецификации уровней прерываний, описание штатной ЭВМ;

• •    стандартные подпрограммы;

• •    программа генерации погрешности входных данных;

• •    журнал регистрации программных ошибок.

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

• 1)    регистрация программных ошибок на этапе автономных и заводских испытаний;

• 2)    запись исходных данных в журнал регистрации;

• 3)    анализ и обработка полученных данных;

• 4)    оценка показателей надежности;

• 5)    утверждение заказчиком документации на ПО, включая показатели надежности;

• 6)    выпуск проекта документации главного конструктора на изделие;

• 7)    совместные испытания;

• 8)    выпуск документации главного конструктора на изделие;

• 9)    государственные испытания;

• 10)    утверждение документации на изделие, включая показатели надежности ПО.

На всех этапах испытаний, кроме государственных, устраняются несоответствия с техническим заданием и корректируются ошибки.

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

Обнаруженные ошибки регистрируются в журнале.

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

Мониторинг программных ошибок

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

Вестник Российского нового университета

Серия «Сложные системы: модели, анализ и управление», выпуск 1 за 2025 год

Рисунок. Контрольная карта процесса эксплуатации изделия, где ■ – экспериментальные точки

Источник: рисунок выполнен авторами.

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

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

При составлении контрольной карты введем следующие ограничивающие линии:

• •    верхняя контрольная граница п ₀ ж (T p ) + ^ n ;

• •    нижняя контрольная граница п _{о ж} (T p ) - ^ n ;

• •    верхняя критическая граница.

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

Обратимся к расшифровке этих граничных линий. Прогнозируемое число ошибок имеет разброс

(T„

П _ж ( T p ) = Na1 n 1 + — p- 1 ± 3 n o (1 + a T p )

b + т I            „    -

^rv

L

П = 2 A n .

Верхняя критическая граница устанавливается из нижеследующих соображений. Начнем с оценки временных затрат T _{ycm п} р на устранение программной ошибки.

Указанное T _{yc:m пр} делится на следующие временные интервалы: диагностика, выпуск извещения на доработку, внедрение доработки в эксплуатирующих организациях.

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

Качество или контролируемость процесса выявления программных ошибок в соответствии со стандартами по менеджменту качества в данном случае представлены отношением с _р = А 1 / А 2 ,                                     (4)

то есть отношением количества критических допустимых ошибок А ₁ к фактически наработанному количеству А ₂ за годы эксплуатации.

При С _р <  1 качество процесса неприемлемо, а при С _р = 1 процесс находится на грани требуемых возможностей, необходимо С р >  1. Хорошим показателем С р считается величина 1,33.

На представленном Рисунке можно увидеть, что в районе 15–19 кварталов эксплуатации количество реальных накопленных ошибок вышло за верхнюю контрольную границу, но не достигло верхней критической границы. Плохо это или допустимо?

Заключение

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

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

Вестник Российского нового университета

Серия «Сложные системы: модели, анализ и управление», выпуск 1 за 2025 год

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