On the quality indicators of automated control systems software

Введение

Эффективность применения большинства современных технических систем обеспечивает использование в них программного обеспечения (ПО). Возможности устанавливаемого ПО позволяют кардинально нарастить качество систем, дополняя существующие свойства или даже порождая новые ^[1,2].

Но, несмотря на многочисленные успешные примеры, проблема оценки качества самого ПО до настоящего времени решена не в полной мере и остаётся актуальной. Анализируя все аспекты этого вопроса, можно сделать вывод, что проблема, вероятно, порождается как существующим пониманием самого термина «качество ПО», так и подходами, применяемыми для расчёта этого показателя ^[3,4]. Автор делает этот вывод не только на основе анализа нормативных документов и специализированной литературы, но и как практик, неоднократно участвовавший в приёмо-сдаточных испытаниях автоматизированных систем различного назначения.

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

В соответствии с нормативными документами, под качеством программного обеспечения понимается его способность при заданных условиях удовлетворять установленным или предполагаемым потребностям ^[5].

На практике, в ряде случаев, используются определения из стандартов, определяющих качество ПО как:

- весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94);

- степень, в которой система, компонент или процесс удовлетворяют потребностям, ожиданиям заказчика или пользователя (IEEE Std 610.12-1990).

В ГОСТ Р ИСО/МЭК 25010-2015 (аналог ISO/IEC 25010:2011) ^[6] задана модель качества ПО, которая включает восемь характеристик верхнего уровня:

- функциональная пригодность;

- уровень производительности;

- совместимость;

- удобство использования (usability);

- надёжность;

- защищённость;

- сопровождаемость;

- переносимость (мобильность).

В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от пользовательской модели качества (в англоязычной интерпретации – «модель качества в использовании» или quality in use model). Модель качества в использовании включает следующие характеристики верхнего уровня ^[7,8]:

- результативность;

- производительность;

- удовлетворение потребностей;

- свобода от риска;

- покрытие контекста

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

Во-первых, она ориентирована на зарубежный стандарт ISO/IEC 25000:2014 ^[8], не являющийся нормативным документом РФ. Исходя из этого, в нашей стране данная модель в настоящее время официально не используется.

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

В то же время, реализуемая в используемых в нашей стране ГОСТ Р ИСО/МЭК 25010 и Р 25012 модель содержит, преимущественно, количественные показатели, что также делает её использование для оценки человеко-машинных систем проблематичным.

Таким образом, как показывает анализ нормативных документов ^[9-13], структура показателей качества, определяемая применяемыми в настоящее время руководящими документами, не в полной мере соответствует задаваемым в этих же ГОСТ определениям качества ПО.

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

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

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

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

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

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

- соответствие понятийного аппарата, реализованного в ПО пониманию заказчика;

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

- порядок и сроки мониторинга адекватности разработанного ПО.

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

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

2 Проблемы, порождаемые недостаточным качеством программного обеспечения и анализ причин их возникновения

В чём же на практике выражается несоответствие между заявленным определением качества и используемыми для его определения моделями? И на что влияет недостаточно достоверная оценка качества ПО, применяемого в АСУ и в составе сложных технических систем? Как показывает практика, использование ПО, оценка которого проводилась по существующим подходам, без анализа качества алгоритмов, может приводить к возникновению ошибок принятия решений: как при работе автоматических систем в составе которых имеется ПО, так и в системах автоматизированного управления, где ПО используется оператором в процессе выработки решений.

Из практики, типичным примером ошибки ПО автоматической системы является произошедшее в 2007 году происшествие, когда случайным огнём среагировавшей на движение людей корабельной автоматической зенитной пушки были убиты девять военнослужащих в Южной Африке ^[14]. Ещё один подобный пример – крушение российского разгонного блока «Фрегат» в декабре 2017 года. Как показало расследование, проблема заключалась в алгоритмической ошибке ПО, не выявленной на этапе тестирования и проявившейся дорогостоящей аварией через два десятка лет эксплуатации ^[15].

В качестве практического примера ошибки автоматизированного управления можно отнести сбой программного обеспечения автоматизированной системы ПВО «Си Вулф» (GWS-25 See Wolf) английского фрегата «Бродсворд» (F88 Broadsword) во время боя с аргентинскими самолётами в мае 1982 года. Из-за ошибки распознавания, когда пара самолётов была воспринята как одна цель, а потом зафиксирована ещё раз как две раздельные, программа неверно выстроила приоритетность поражения воздушных целей, введя операторов в заблуждение. Операторы, безоговорочно доверяя системе, решение на поражение не приняли. В результате аргентинские самолёты не были обстреляны и ими был потоплен эсминец «Ковентри» (D-118 Coventry) ^[16].

Примеров ошибок обоих типов можно привести множество: непоражение обнаруженной иракской ракеты «Скад» (Scud) 25 февраля 1991 года комплексом Patriot из-за не выявленного ранее накопления ошибки округления внутреннего таймера, сбой электроники истребителей F-22 Raptor в момент пересечения линии перемены дат, отказ компьютерной системы американского ракетного крейсера «Йорктаун» (CG-48) в 1997 году из-за ошибки деления на ноль, приведшую к катастрофе некорректную работу автоматики системы MCAS (Maneuvering Characteristics Augmentation System) самолётов «Боинг» (Boeing-737 MAX) в 2018 году в Индонезии и в 2019 году в Эфиопии и другие.

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

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

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

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

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

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

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

В настоящее время разработано и применяется достаточно много средств статического и динамического тестирования ПО, разделяемых:

1)по объекту тестирования (функциональное, тестирование производительности, конфигурационное тестирование, тестирование интерфейса пользователя, тестирование безопасности, тестирование локализации, тестирование совместимости);

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

3)по степени автоматизации процесса тестирования (ручное, автоматизированное и полуавтоматизированное);

4)по степени изолированности (тестирование компонентов, интеграционное тестирование, системное тестирование);

5)по этапу проведения тестирования (альфа-тестирование, бета-тестирование, приемо-сдаточные испытания);

6)по признаку позитивности сценариев (позитивное и негативное тестирование);

7)по уровню тестирования (тестирование по документации, иногда называемое формальным, и интуитивное тестирование).

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

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

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

1) ошибка первого рода, когда пользователь, не зная особенностей расчётов и влияния на их точность сложившихся факторов, воспринимает их как единственно верные и принимает решение, не соответствующее сложившейся обстановке. То есть незамеченная пользователем с вероятностью Н₁ ошибка работы программы Н₂;

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

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

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

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

В предлагаемой постановке, основной проблемой существующих методов оценки качества программ можно считать то, что они ориентированы в основном на выявление ошибок расчётов H₂, не позволяя отследить вероятности Н₀₁ и Н₀₂ (см. таблицу). Вероятности, которые неизбежны в человеко-машинных системах и составляют значительную долю ошибок их использования. Такой класс ошибок можно назвать ошибками организации применения или алгоритмическими ошибками. В рамках существующих подходов к оценке качества ПО, такие ошибки не выявляются.

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

- алгоритмов решения задач и моделирования на всём спектре условий их реализации;

- алгоритмов взаимодействия программ с пользователями.

Ситуация, как отмечалось ранее, требует решения.

3.Анализ причин возникновения алгоритмических ошибок применения средств автоматизации

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

В соответствии с ГОСТ, программные средства АСУ разрабатываются на основании технического задания, требования которого детализируются по мере работы в ходе проведения эскизного и технического проектирования.

Уже на этапе формирования технического задания могут возникать неточности в описании структуры программ и требований к ним, определяемые особенностями представления о них заказчика. На последующих этапах часть этих требований уточняется, но этот процесс относительно инерционный в связи с недостаточным использованием современных подходов к организации разработки ^[17,18]. Не устранённые вовремя ошибки накапливаются по мере разработки программ: на этапе описания постановок задач, их интерпретации алгоритмистами и программистами и т.д. Более того, в процессе детализации требований, существует вероятность появления новых ошибок.

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

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

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

4.Возможные подходы к решению проблемы оценки качества

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

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

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

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

Вероятно, в перспективе, описанная в статье проблема будет только углубляться. С развитием систем искусственного интеллекта, на каких ли принципах они бы не строились, существующие принципы контроля качества будут всё менее соответствовать требованиям пользователя. Действительно, проблематично контролировать системы, по определению нацеленные на модификацию собственных алгоритмов, проверяя количественные показатели реализации расчётных зависимостей, «отсутствие незадекларированных возможностей» и другие свойства, определяемые применяемыми в настоящее время моделями качества ^[10,11].

Для парирования сложившейся ситуации предлагается реализовать ряд мер.

Во-первых, для повышения вероятности выявления ошибок СМПО АСУ в процессе разработки, ввести дополнительный этап приёмки программ – обязательный этап опытной эксплуатации (тестирования) разработанного образца.

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

В-третьих, выделить в процессе тестирования программ обязательные составляющие, подлежащие отдельным проверкам:

- тестирование качества пользовательских интерфейсов;

- поиск погрешностей алгоритмов и математического аппарата;

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

Соответственно, в обязательном порядке учитывать выполнение указанных мер при разработке программ и методик испытаний на основе модели качества ISO/IEC 25000:2014. Причём, учитывая практический опыт испытаний АСУ, предлагается первую составляющую тестирования оставить в структуре приёмо-сдаточных испытаний, а поиск алгоритмических ошибок вынести в этап апробации программ, сделав данную работу на этом этапе обязательной.

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

Для реализации сформулированных требований, в организационно-техническом плане необходимо доработать систему оценки качества разрабатываемых АСУ с учётом уточнённой модели ^[6,7]. В частности, ввести в неё такой показатель как «качество реализуемых алгоритмов».

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

В состав комплексного показателя «качество программы», учитывающего качество реализуемых алгоритмов, как вариант, могут входить частные показатели:

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

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

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

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

Включение в систему технического регламентирования ^[19] оценки качества показателей устойчивости ПО и алгоритмов, позволит избежать совершение пользователями АСУ ошибок первого рода и существенно снизить вероятности ошибок второго рода за счёт повышения уровня доверия к результатам расчётов и моделирования ^[20-22].

Вывод

Таким образом, текущее состояние методологии оценки качества ПО АСУ требует решения научно-практической задачи ^[23,24], в рамках которой необходимо уточнить модель оценки качества в части:

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

- обеспечения этой моделью полного цикла проверки разрабатываемых программных средств, от контроля эффективности заложенных в них алгоритмов до оценки уровня взаимодействия программ с пользователем ^[25];

- более активного применения автоматизированных методов тестирования ^[26,27].

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