Программные системы и вычислительные методы
Правильная ссылка на статью:
Тиханычев О.В. — О показателях качества программного обеспечения автоматизированных систем управления // Программные системы и вычислительные методы. - 2020. - № 2. DOI: 10.7256/2454-0714.2020.2.28814 URL: https //nbpubMLcom/fcary_read_article.php?id=28814
О показателях качества программного обеспечения автоматизированных систем управления
Тиханычев Олег Васильевич
кандидат технических наук заместитель начальника отдела, ГК "Техносерв 111395, Россия, г. Москва, ул. Юности, 13
И tow65@yandex.ru
Статья из рубрики "Показатели качества и повышение надежности программных систем"
DOI:
10.7256/2454-0714.2020.2.28814
Дата направления статьи в редакцию:
20-02-2020
Аннотация.
Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования - система контроля качества этого процесса. В настоящее время нормативными документами установлен перечень основных характеристик оценки качества программ, который, как показала практика, не в полной мере соответствует своему назначению, обеспечивая не контроль качества, а проверку соответствия программ требованиям заказчика, сформулированным в техническом задании. Одна из причин этого заключается в невозможности оценивать исключительно количественными показателями качество систем, включающих как технические средства, так и человека. Попытка использовать мировую практику, например, относительно удачные модели качества из стандартов ISO/IEC 25000:2014 до настоящего времени не реализована: сама модель нормативными документами (ГОСТ Р ИСО/МЭК 25010-2015) разрешена к использованию, но описанные в ней показатели качества не приняты. Проводимые в частном порядке доработки существующих методов не решают проблему системно. В статье использованы общенаучные методы анализа и синтеза. На основе анализа существующих подходов к оценке качества разработки программного обеспечения синтезированы предложения по совершенствованию этого процесса В статье сформулирована постановка научно-практической задача и предложен один из подходов к её решению, основанный на доработке существующих методов оценки качества на основе модели, описанной в ГОСТ
Р ИСО/МЭК 25010 с учётом реальных потребностей пользователей, интерпретированных через снижение вероятности ошибок первого и второго рода, возникающих при использовании программного обеспечения. Решение сформулированной задачи обеспечит общее повышение эффективности автоматизированного управления за счёт применения количественно-качественных оценок разрабатываемого программного обеспечения
Ключевые слова: автоматизация управления, поддержка принятия решений, качественный подход, количественные методы, контроль качества, программное обеспечение, автоматизированная система управления, модель оценки качества, нормативные документы, ошибки применения программ
Введение
Эффективность применения большинства современных технических систем обеспечивает использование в них программного обеспечения (ПО). Возможности устанавливаемого ПО позволяют кардинально нарастить качество систем, дополняя существующие свойства или даже порождая новые [1,2].
Но, несмотря на многочисленные успешные примеры, проблема оценки качества самого ПО до настоящего времени решена не в полной мере и остаётся актуальной. Анализируя все аспекты этого вопроса, можно сделать вывод, что проблема, вероятно, порождается как существующим пониманием самого термина «качество ПО», так и подходами, применяемыми для расчёта этого показателя [3,4]. Автор делает этот вывод не только на основе анализа нормативных документов и специализированной литературы, но и как практик, неоднократно участвовавший в приёмо-сдаточных испытаниях автоматизированных систем различного назначения.
1.Существующие подходы к оценке качества программного обеспечения
В соответствии с нормативными документами, под качеством программного обеспечения понимается его способность при заданных условиях удовлетворять установленным или
предполагаемым потребностям J51.
На практике, в ряде случаев, используются определения из стандартов, определяющих качество ПО как:
- весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94);
- степень, в которой система, компонент или процесс удовлетворяют потребностям, ожиданиям заказчика или пользователя (IEEE Std 610.12-1990).
В ГОСТ Р ИСО/МЭК 25010-2015 (аналог ISO/IEC 25010:201 задана модель качества ПО, которая включает восемь характеристик верхнего уровня:
- функциональная пригодность;
- уровень производительности;
- совместимость;
- удобство использования (usability);
- надёжность;
- защищённость;
- сопровождаемость;
- переносимость (мобильность).
В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от пользовательской модели качества (в англоязычной интерпретации - «модель качества в использовании» или quality in use model). Модель качества в использовании включает следующие характеристики верхнего уровня [7,8]:
- результативность;
- производительность;
- удовлетворение потребностей;
- свобода от риска;
- покрытие контекста
Данная модель достаточно адекватно подходит к описанию всех аспектов оценки качества программной продукции. Но в её практическом использовании есть определённые проблемы.
Во-первых, она ориентирована на зарубежный стандарт ISO/IEC 25000:2014^, не являющийся нормативным документом РФ. Исходя из этого, в нашей стране данная модель в настоящее время официально не используется.
Во-вторых, даже принятие данного стандарта не сильно улучшит ситуацию, так как в нём используются преимущественно качественные показатели, что недостаточно для оценки точных систем, использующих ПО.
В то же время, реализуемая в используемых в нашей стране ГОСТ Р ИСО/МЭК 25010 и Р 25012 модель содержит, преимущественно, количественные показатели, что также делает её использование для оценки человеко-машинных систем проблематичным.
Таким образом, как показывает анализ нормативных документов [9-13], структура показателей качества, определяемая применяемыми в настоящее время руководящими документами, не в полной мере соответствует задаваемым в этих же ГОСТ определениям качества ПО.
Исходя из анализа применяемых моделей качества, можно сделать вывод, что существующие показатели нацелены, преимущественно, на определение таких «внешних» показателей программ, как удобство использования, простота освоения и сопровождения и им подобных, а также «внутренних» показателей, но только в части надёжности и безопасности программ. Например, устойчивость к сбоям технических средств. Это, конечно, очень важные показатели свойств программного продукта. Но, как показывает анализ ошибок и сбоев, возникающих при применении средств автоматизации, это только часть показателей качества.
Таким образом, существующие модели оценки качества противоречат задаваемому в тех
же нормативных документах определению качества ПО. Эта ситуация является неприемлемой и требует скорейшего решения.
В итоге, существующие подходы к оценке качества ПО представляют его пользователю как «чёрный ящик»; безопасный, надёжный, но совершенно непрозрачный с точки зрения логики его функционирования. Для развлекательных или «бытовых» программ такой подход вполне приемлем. А вот для ПО, применяемого в областях принятия решений с высокими рисками и большой ценой ошибки - критичен. Пользователь, лично отвечающий за конечный результат действий, организуемых с применением ПО хочет понимать:
- общую логику используемых программой алгоритмов и их соответствие проверенным методикам, применяемым ранее;
- границы применимости используемого математического аппарата, предсказуемость его поведения в граничных и нестандартных ситуациях, логику оповещения в случае возникновения критичных ситуаций;
- аргументацию выбора применяемых методик, алгоритмов, показателей и критериев;
- соответствие понятийного аппарата, реализованного в ПО пониманию заказчика;
- возможность, необходимость и порядок изменения заложенных в ПО критериев;
- порядок и сроки мониторинга адекватности разработанного ПО.
То есть потенциальный пользователь, он же, как правило - технический заказчик ПО, хочет оценивать не только пользовательские качества ПО, но и качество заложенных в него алгоритмов и их устойчивость к изменению исходных данных: как для алгоритмов расчётов, так и алгоритмов, регламентирующих общение с пользователем. То, чего используемые в настоящее время модели качества, не обеспечивают.
Для исправления сложившейся ситуации, как показывает практика, необходимо дополнить существующие показатели системой поиска алгоритмических ошибок. То есть показателями, которые, кроме безопасности, устойчивости и удобства применения должны контролировать и алгоритмические свойства ПО: качество, полноту и устойчивость алгоритмов, в том числе - к неполным или искаженным исходным данным. Отсутствие таких возможностей у применяемых в настоящее время моделей качества существенно снижает достоверность контроля качества ПО в составе автоматических систем и ПО автоматизированных систем управления (АСУ).
2 Проблемы, порождаемые недостаточным качеством программного обеспечения и анализ причин их возникновения
В чём же на практике выражается несоответствие между заявленным определением качества и используемыми для его определения моделями? И на что влияет недостаточно достоверная оценка качества ПО, применяемого в АСУ и в составе сложных технических систем? Как показывает практика, использование ПО, оценка которого проводилась по существующим подходам, без анализа качества алгоритмов, может приводить к возникновению ошибок принятия решений: как при работе автоматических систем в составе которых имеется ПО, так и в системах автоматизированного управления, где П О используется оператором в процессе выработки решений.
Из практики, типичным примером ошибки ПО автоматической системы является
произошедшее в 2007 году происшествие, когда случайным огнём среагировавшей на движение людей корабельной автоматической зенитной пушки были убиты девять
военнослужащих в Южной Африке I-14!. Ещё один подобный пример - крушение российского разгонного блока «Фрегат» в декабре 2017 года. Как показало расследование, проблема заключалась в алгоритмической ошибке ПО, не выявленной на этапе тестирования и проявившейся дорогостоящей аварией через два десятка лет эксплуатации i15!.
В качестве практического примера ошибки автоматизированного управления можно отнести сбой программного обеспечения автоматизированной системы ПВО «Си Вулф» (GWS-25 See Wolf) английского фрегата «Бродсворд» (F88 Broadsword) во время боя с аргентинскими самолётами в мае 1982 года. Из-за ошибки распознавания, когда пара самолётов была воспринята как одна цель, а потом зафиксирована ещё раз как две раздельные, программа неверно выстроила приоритетность поражения воздушных целей, введя операторов в заблуждение. Операторы, безоговорочно доверяя системе, решение на поражение не приняли. В результате аргентинские самолёты не были обстреляны и
ими был потоплен эсминец «Ковентри» (D-118 Coventry) I16!.
Примеров ошибок обоих типов можно привести множество: непоражение обнаруженной иракской ракеты «Скад» (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) ошибка первого рода, когда пользователь, не зная особенностей расчётов и влияния на их точность сложившихся факторов, воспринимает их как единственно верные и принимает решение, не соответствующее сложившейся обстановке. То есть незамеченная пользователем с вероятностью Н1 ошибка работы программы Н2 ;
2) ошибка второго рода, когда пользователь необоснованно не доверяет результатам расчётов и моделирования и принимает собственное решение, несоответствующее условиям обстановки. То есть вероятность неверной интерпретации расчётов, проведенных верно с вероятностью Н д .
При этом в автоматизированных системах пользователь - это человек-оператор, а в автоматических системах под пользователем можно понимать исполнительные органы управляемой системы или взаимодействующие (управляемые) подсистемы.
Таблица - Характер ошибок, возникающих в ходе принятия управленческих решений по
результатам расчётов и моделирования
Правильное управленческое решение
Н 0 Н 1
Результат интерпретации расчётов и моделирования H 0 Н о верно использованы Н 01 неверно скорректированы (ошибка первого рода)
H 2 Н 02 неверно использованы (ошибка второго рода) Н 1 верно скорректированы
В численной теории рисков к вероятности принято добавлять цену ошибки. Впрочем, если цена ошибки неизвестна, допускается оперировать исключительно вероятностными пока з а те ля ми.
В предлагаемой постановке, основной проблемой существующих методов оценки качества программ можно считать то, что они ориентированы в основном на выявление ошибок расчётов H 2 , не позволяя отследить вероятности Нд^ и Нд2 (см. таблицу). Вероятности, которые неизбежны в человеко-машинных системах и составляют значительную долю ошибок их использования. Такой класс ошибок можно назвать ошибками организации применения или алгоритмическими ошибками. В рамках существующих подходов к оценке качества ПО, такие ошибки не выявляются.
Таким образом, из анализа сложившейся ситуации можно сделать вывод, что применяемые в настоящее время модели оценки качества ПО недостаточно полно отслеживают ошибки реализации двух крупных групп алгоритмов, непосредственно влияющих на результаты применения программ:
- алгоритмов решения задач и моделирования на всём спектре условий их реализации;
- алгоритмов взаимодействия программ с пользователями. Ситуация, как отмечалось ранее, требует решения.
3.Анализ причин возникновения алгоритмических ошибок применения средств автоматизации
Проблема появления алгоритмических ошибок ПО возникает и накапливается вследствие особенностей, объективно присутствующих на всех этапах процесса разработки специального математического и программного обеспечения (СМПО) АСУ: от информационного обследования объекта автоматизации, до проведения приёмосдаточных испытаний.
В соответствии с ГОСТ, программные средства АСУ разрабатываются на основании технического задания, требования которого детализируются по мере работы в ходе проведения эскизного и технического проектирования.
Уже на этапе формирования технического задания могут возникать неточности в описании структуры программ и требований к ним, определяемые особенностями представления о них заказчика. На последующих этапах часть этих требований уточняется, но этот процесс относительно инерционный в связи с недостаточным
использованием современных подходов к организации разработки [17,18]. Не устранённые вовремя ошибки накапливаются по мере разработки программ: на этапе описания постановок задач, их интерпретации алгоритмистами и программистами и т.д. Более того, в процессе детализации требований, существует вероятность появления новых ошибок.
В соответствии с существующими ГОСТ, программное обеспечение, до внедрения в систему, проходит целый ряд приёмо-сдаточных испытаний. В ходе этих испытаний оценивается, в том числе, и качество программных средств. Для разработки программ и методик испытаний используются актуальные на момент испытаний руководящие документы, в первую очередь ГОСТ, использующие существующие модели оценки качества ПО. Для повышения эффективности проводимых проверок используются различные средства и методы тестирования.
Но, как показывает анализ, применяемые модели и методы тестирования рассчитаны на итерационные методы поиска ошибок, а повышение их эффективности предлагается обеспечивать за счёт максимального увеличения количества испытаний в разных режимах. в том числе с использованием автоматизированных систем тестирования. Методов, обеспечивающих целенаправленный поиск ошибок с использованием соответствующих моделей качества, в настоящее время не существует.
Для устранения существующих проблем и обеспечения достоверности оценки качества, специальные математические методы, положенные в основу СМПО АСУ, должны досконально проверяться на адекватность расчётов и моделирования на максимально широком диапазоне исходных данных, в различных ситуациях применения с формированием соответствующих рекомендаций пользователям и разработчикам. Но, как показал анализ всех этапов разработки П О, существующие подходы к организации этого процесса, обеспечивают решение данной задачи не в полном объёме.
4.Возможные подходы к решению проблемы оценки качества
Чтобы исправить сложившуюся ситуацию, специалисты в области разработки ПО вынуждены расширять спектр и содержание проводимых проверок, а порой даже использовать показатели качества собственной разработки, описывающие пользовательские качества программы с учётом особенностей реализованных в ней алгоритмов. Известны случаи, когда разработчики программ, описывая качество своего ПО, приводили в качестве оценки скорость выполнения и точность расчётов, например: «повышение оперативности и обоснованности решений, принимаемых с использованием средств автоматизации». В качестве количественных показателей времени при таком подходе применяются длительность цикла расчётов и количество итераций, обсчитываемых в заданный промежуток времени, а адекватность определяется точностью получаемых результатов на заданном интервале исходных данных.
Если показатель адекватности и первый из показателей оперативности в целом не
вызывают претензий, то со вторым возникают определённые сомнения. Логичнее использовать в качестве показателя оперативности не максимальное количество циклов расчётов, а их достаточность, обеспечивающую формирование в заданное время необходимого количества альтернативных решений, составляющего полное множество по всем заданным пользователем критериям. Время расчёта этого множества не столь важно, главное, чтобы оно не превышало срока, отведённого на принятие решения в целом.
Причём, первый и второй показатели оперативности не тождественны и не взаимозаменяемы. В определение суммарного количества рассчитанных итераций может не включаться время на ввод исходных данных в каждом варианте расчётов, если программа ищет оптимум самостоятельно, по общим, заданным оператором критериям. А может включать, если программа ищет оптимум в диалоговом режиме, и оператор каждый раз меняет исходные данные самостоятельно.
Но, напомним, данные показатели не утверждены официально, их применение - личное решение и ответственность разработчиков и заказчиков ПО. Более того, точностные качества программы, вероятность совершения ошибок первого и второго рода эти показатели не описывают. И если для некоторых областей применения ПО это, может быть, не критично, то в ситуациях управления, отличающейся высокой «стоимостью» ошибок, существующая ситуация просто неприемлема.
Вероятно, в перспективе, описанная в статье проблема будет только углубляться. С развитием систем искусственного интеллекта, на каких ли принципах они бы не строились, существующие принципы контроля качества будут всё менее соответствовать требованиям пользователя . Действительно, проблематично контролировать системы, по определению нацеленные на модификацию собственных алгоритмов, проверяя количественные показатели реализации расчётных зависимостей, «отсутствие незадекларированных возможностей» и другие свойства, определяемые применяемыми в
настоящее время моделями качества [10,11].
Для парирования сложившейся ситуации предлагается реализовать ряд мер.
Во-первых , для повышения вероятности выявления ошибок СМПО АСУ в процессе разработки, ввести дополнительный этап приёмки программ - обязательный этап опытной эксплуатации (тестирования) разработанного образца.
Во-вторых , расширить диапазон основных приёмо-сдаточных испытаний. Производить не только оценку выполнения требований технического задания, но и другие качества программ, описывающих конечную цель их применения. Разумеется, в части, не противоречащей требованиям задания, а дополняющей их.
В-третьих , выделить в процессе тестирования программ обязательные составляющие, подлежащие отдельным проверкам:
- тестирование качества пользовательских интерфейсов;
- поиск погрешностей алгоритмов и математического аппарата;
- контроль реакции программы на неполноту и искажение исходных данных, выход данных за границы области возможного использования.
Соответственно, в обязательном порядке учитывать выполнение указанных мер при разработке программ и методик испытаний на основе модели качества ^0/!ЕС
25000:2014. Причём, учитывая практический опыт испытаний АСУ, предлагается первую составляющую тестирования оставить в структуре приёмо-сдаточных испытаний, а поиск алгоритмических ошибок вынести в этап апробации программ, сделав данную работу на э том эта пе о б я з а те льной.
5.Предложения по уточнению системы оценки качества программной продукции
Для реализации сформулированных требований, в организационно-техническом плане необходимо доработать систему оценки качества разрабатываемых АСУ с учётом уточнённой модели [6,7]. В частности, ввести в неё такой показатель как «качество реализуемых алгоритмов».
Данный показатель должен формироваться на основе не только количественных, но количественно-качественных моделей, описывать поведение программ в условиях неполной входной информации, при использовании информации с различной степенью достоверности и проверять адекватность результатов расчётов и моделирования, получаемых в различных секторах области допустимого использования математического а ппа ра та .
В состав комплексного показателя «качество программы», учитывающего качество реализуемых алгоритмов, как вариант, могут входить частные показатели:
- возможность получения решения в заданное время;
- сохранение заданной точности результатов в установленном диапазоне и при различном уровне полноты исходных данных;
- сохранение требуемой точности результатов при разных значениях достоверности исходных данных;
- предельное отклонение результатов расчётов и моделирования в различных сегментах области допустимых решений и другие.
Включение в систему технического регламентирования оценки качества показателей устойчивости ПО и алгоритмов, позволит избежать совершение пользователями АСУ ошибок первого рода и существенно снизить вероятности ошибок второго рода за счёт повышения уровня доверия к результатам расчётов и моделирования [20-22].
Вывод
Таким образом, текущее состояние методологии оценки качества ПО АСУ требует решения научно-практической задачи [23,24], в рамках которой необходимо уточнить модель оценки качества в части:
- использования количественно-качественных оценок программного обеспечения;
- обеспечения этой моделью полного цикла проверки разрабатываемых программных средств, от контроля эффективности заложенных в них алгоритмов до оценки уровня
взаимодействия программ с пользователем I25!;
- более активного применения автоматизированных методов тестирования [26,27].
Выполнение указанной задачи позволит решить важную для создания ПО АСУ проблему контроля качества, в том числе в части реализации сквозного автоматизированного
тестирования программ. И создать систему, контролирующую не только возможные ошибки разработки программ, но и учитывающую эффективность используемых в них алгоритмов, а также возможную реакцию на ошибки оператора. Учитывая, что программное обеспечение в настоящее время является важной составляющей частью практически любой сложной системы, сформулированная в данной статье постановка задачи оценки его качества является актуальной и своевременной.
Библиография
1. Тиханычев О.В. Виртуальная реальность и поддержка принятия решений // Прикладная информатика. - 2019. - №4(72). - С.56-64.
2. Выпасняк В.И. и др. Система поддержки принятия решений как "виртуальный штаб" // Военная мысль. - 2015. - №2. - С.23-29.
3. Выпасняк В.И. и др. Моделирование вооруженного противоборства: перспективы развития // Военная мысль. - 2009. - №7. - С.12-20.
4. Тиханычев О.В. Субъективные аспекты применения математического моделирования военных действий в практике работы органов военного управления // Военная мысль. - 2011. - №10. - С.49-53.
5. ISO/IEC 25000:2014 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)-Guide to SQuaRE. 34 p.
6. ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. Утвержден и введён в действие Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. №464-ст. М.: Стандартинформ, 2015. - 36 с.
7. ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества. Утвержден и введён в действие Приказом Федерального агентства по техническому регулированию и метрологии от 11 июня 2014 г. №557-ст. Стандартинформ, 2015. - 41 с.
8. Wagner, Stefan (2015). Operationalised product quality models and assessment: The Quamoco approach. Information and Software Technology №62. рр.101-123. D0I:10.1016/j.infsof.2015.02.009.
9. ГОСТ Р ИСО/МЭК 9126-93 Государственный стандарт Российской Федерации. Информационная технология. Оценка программной продукции характеристики качества и руководства по их применению.
10. ГОСТ 28195-99 Межгосударственный стандарт. Оценка качества программных средств. М.: Стандартинформ, 1999. - 28 с.
11. ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование. М.: Стандартинформ, 2001. - 18 с.
12. ГОСТ Р ИСО/МЭК 9001-2000. Система менеджмента качества. Требования (Quality management systems — Requirements). М.: Стандартинформ, 2000. - 44 с.
13. Дзюба Ю.В., Павловский А.А. Особенности стандартизации в области информационных технологий // Наука и технологии железных дорог. - 2017. -№ 2(2). - С.47-59.
14. The Sunday paper (tech ethics edition) // Defense Tech. January 2008 [Электронный ресурс]. URL: htpp://defensetech.org/2008/01/27/ (дата обращения: 30.01.2008).
15. «Роскосмос» назвал причину аварии блока "Фрегат" с 19 спутниками. РИА
«Новости», официальный сайт. URL: https://ria.ru/science/20171212/1510707313.html (дата обращения 12.12.2017)
16. Sandy Woodward, Patrick Robinson. One Hundred Days: The Memoirs of the Falklands Battle Group Commander. Harper Collins, London, 1997. 213 p.
17. Mакарцев Л.В. и др. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. - 2017. - №4. - С.706-710. DOI: 10.15827/0236-235X.120.706-710.
18. Тиханычев О.В. О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений // Программные системы и вычислительные методы. - 2018. - №2. - С.51-59. DOI: 10.7256/2454-0714.2018.2.23743.
19. Федеральный закон "О техническом регулировании" от 27.12.2002 N 184-ФЗ (ред. от 05.04.2016)-URL: http://legalacts.ru/doc/federalnyi-zakon-ot-27122002-n-184-fz-o (дата обращения 19.02.2019).
20. Тиханычев О.В. Теория и практика автоматизированной поддержки принятия решений. Mонография. M.: Эдитус, 2018. - 76 с.
21. Gijs Wijnholds, Zeeger Lubsen, Sylvan Rigal, Joost Visser. Building Software Teams. O'Reilly Media, Inc., 2016. 213 р.
22. Mихеев И.В., Виштак О.В., Кондратов Д.В. Система количественных характеристик оценки качества программных продуктов // Программные системы и вычислительные методы.- 2018. - № 2. - С.28-35. DOI : 10.7256/2454-0714.2018.2.25981.
23. Долженко А.И., Шполянская И.Ю. Нечеткие модель и алгоритм оценки качества веб-сервисов, интегрируемых в сервис-ориентированную архитектуру информационной системы // Программные системы и вычислительные методы. -2017. - № 2. - С.22-31. DOI: 10.7256/2454-0714.2017.2.23098.
24. Грундел Л.П., Бирюков В.В.. Применение функций нечеткого моделирования для определения ключевых показателей эффективности // Программные системы и вычислительные методы. - 2016. - № 3. - С.268-286. DOI : 10.7256/23056061.2016.3.1947.
25. Поначугин А.В. Определение надёжности программного обеспечения в структуре современной информационной системы // Кибернетика и программирование. - 2019. - № 2. - С. 65 - 72. DOI: 10.25136/2306-4196.2019.2.20341
26. World Quality Report 2017-18 - 9TH EDITION // Sogeti. URL:
https ://www.sogeti.com/explore/reports/world-quality-report-2017-2018/ (дата обращения 19/04/2019).
27. Barnett, Michael & Fähndrich, Manuel & de Halleux, Peli & Logozzo, Francesco & Tillmann, Nikolai. Exploiting the Synergy between Automated-Test-Generation and Programming-by-Contract. 2009. pp.401-402. DOI: 10.1109/ICSE-COMPANION.2009.5071032.
Результаты процедуры рецензирования статьи
В связи с политикой двойного слепого рецензирования личность рецензента не
раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.
Предмет исследования - показатели качества, процедура тестирования и апробации
программного обеспечения автоматизированных систем управления. Mетодология
исследования основана на теоретическом подходе с применением методов анализа,
обобщения, сравнения, синтеза. Актуальность исследования определяется широким применением автоматизированных систем управления в современной технике и, соответственно, необходимостью изучения и проектирования соответствующего программного обеспечения, в том числе обоснование показателей качества, процедур тестирования и апробации. Научная новизна связана со сформулированными автором выводами о том, что текущее состояние методологии оценки качества ПО АСУ требует уточнения модели оценки качества в части использования количественно-качественных показателей, обеспечения полного цикла проверки разрабатываемых программных средств, более активного применения автоматизированных методов тестирования, что позволит создать систему, контролирующую не только возможные ошибки разработки программ, но и учитывающую эффективность используемых в них алгоритмов, а также возможную реакцию на ошибки оператора. Статья написана русским литературным языком. Стиль изложения научный. Структура рукописи включает следующие разделы: Введение (эффективность применения современных технических систем, использование программного обеспечения (ПО), проблема оценки качества ПО), 1. Существующие подходы к оценке качества программного обеспечения (качество программного обеспечения - способность при заданных условиях удовлетворять установленным или предполагаемым потребностям, определения из стандартов ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94, IEEE Std 610.12-1990, ГОСТ Р ИСО/МЭК 25010-2015, ISO/IEC 25010:201 восемь характеристик верхнего уровня - функциональная пригодность, уровень производительности, совместимость, удобство использования (usability), надёжность, защищённость, сопровождаемость, переносимость (мобильность), модель качества продукта / software product quality model и пользовательская модель качества / quality in use model, модель качества в использовании - результативность, производительность, удовлетворение потребностей, свобода от риска, покрытие контекста, проблемы в практическом использовании, зарубежный стандарт ISO/IEC 25000:2014, качественные и количественные показатели, определение «внешних» и «внутренних» показателей, ПО как «чёрный ящик», ПО, применяемое в областях принятия решений с высокими рисками и большой ценой ошибки, качество заложенных алгоритмов и их устойчивость к изменению исходных данных, система поиска алгоритмических ошибок), 2 Проблемы, порождаемые недостаточным качеством программного обеспечения и анализ причин их возникновения (несоответствие между заявленным определением качества и используемыми для его определения моделями, возникновение ошибок принятия решений, примеры ошибок, количество и тяжесть последствий ошибок ПО, некорректные действия операторов (пользователей), несколько классов ошибок, возникающих при принятии решений с применением средств автоматизации управления - ошибки оператора, технические ошибки в результатах расчётов, средства статического и динамического тестирования ПО и их классификация - по объекту тестирования, по необходимому уровня знания внутреннего строения системы, по степени автоматизации процесса тестирования, по степени изолированности, по этапу проведения тестирования, по признаку позитивности сценариев, по уровню тестирования, задание цели тестирования, использование подходов к оценке ошибок принятия решений, принятых в математической статистике, -ошибки первого и второго рода, характер ошибок, возникающих в ходе принятия управленческих решений по результатам расчётов и моделирования), 3. Анализ причин возникновения алгоритмических ошибок применения средств автоматизации (появление алгоритмических ошибок ПО, программные средства АСУ, техническое задание, этап формирования технического задания, неточности в описании структуры программ и требований к ним, ряд приёмо-сдаточных испытаний, итерационные методы поиска ошибок, увеличение количества испытаний в разных режимах, целенаправленный поиск
ошибок с использованием соответствующих моделей качества, специальные математические методы), 4. Возможные подходы к решению проблемы оценки качества (спектр и содержание проводимых проверок, скорость выполнения и точность расчётов, максимальное количество циклов расчётов, их достаточность, время расчёта, развитие систем искусственного интеллекта, предлгаемые меры - обязательный этап опытной эксплуатации (тестирования) разработанного образца, расширить диапазон основных приёмо-сдаточных испытаний, тестирование качества пользовательских интерфейсов, поиск погрешностей алгоритмов и математического аппарата, контроль реакции программы на неполноту и искажение исходных данных, выход данных за границы области возможного использования), 5. Предложения по уточнению системы оценки качества программной продукции (показатель «качество реализуемых алгоритмов», поведение программ в условиях неполной входной информации, при использовании информации с различной степенью достоверности, адекватность результатов расчётов и моделирования, частные показатели - возможность получения решения в заданное время, сохранение заданной точности результатов в установленном диапазоне и при различном уровне полноты исходных данных, сохранение требуемой точности результатов при разных значениях достоверности исходных данных, предельное отклонение результатов расчётов и моделирования в различных сегментах области допустимых решений и др.), Вывод (заключение), Библиография. Текст содержит одну таблицу. Таблица должна иметь номер. Содержание соответствует названию. Представлены существующие подходы к оценке качества программного обеспечения, выявлены проблемы, порождаемые недостаточным качеством программного обеспечения и проведён анализ причин возникновения алгоритмических ошибок применения средств автоматизации, обоснованы возможные подходы к решению проблемы оценки качества, а также предложения по уточнению системы оценки качества программной продукции. В то же время в формулировке заголовка, возможно, сдедует отметить, что речь ид т. в основном, об автоматизированных чистемах правления специального (военного) назначения, что определяет некоторую специфику требований к программному обеспечению. Библиография включает 27 источников отечественных и зарубежных авторов - монографии, научные статьи, нормативные документы, Интернет-ресурсы. Библиографические описания некоторых источников нуждаются в корректировке в соответствии с ГОСТ и требованиями редакции, например: 2. Выпасняк В. И., ФИО автора 2 ???, ФИО автора 3 ???. Система поддержки принятия решений как "виртуальный штаб" // Военная мысль. - 2015. - №2. - С.23-29. 5. ISO/IEC 25000:2014 Systems and Software engineering - Systems and Software Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. - Место издания ???: Наименование издательства ???, Год издания ???. - 34 р. 8. Wagner S. Operationalised product quality models and assessment: The Quamoco approach // Information and Software Technology. - 2015. - № 62. - Р.101-123. 9. ГОСТ Р ИСО/МЭК 9126-93 Государственный стандарт Российской Федерации. Информационная технология. Оценка программной продукции характеристики качества и руководства по их применению. -Место издания ??? : Наименование издательства ???, Год издания. - ??? с. 14. The Sunday paper (tech ethics edition). URL: htpp://defensetech.org/2008/01/27 (date of access: 30.01.2008). 21. Gijs W., Zeeger L., Sylvan R., Joost V. Building Software Teams. -Место издания ??? : O'Reilly Media, Inc., 2016. - 213 р. 27. Barnett M., Fähndrich M., de Halleux P., Logozzo F., Tillmann N. Exploiting the Synergy between Automated-TestGeneration and Programming-by-Contract. - Место издания ??? : Наименование издательства, 2009. - P.401-402. Возможно излишнее самоцитирование (Тиханычев О. В.). Апелляция к оппонентам (Выпасняк В. И., Wagner, Stefan, Дзюба Ю. В., Павловский А. А., Макарцев Л. В., Wijnholds G., Lubsen Z., Rigal S., Visser J., Михеев И. В., Виштак
О. В., Кондратов Д. В., Долженко А. И., Шполянская И. Ю., Грундел Л. П., Бирюков В В., Поначугин А. В., Barnett M., Fähndrich M., de Halleux P., Logozzo F., Tillmann N. и др.) имеет место. В целом рукопись соответствует основным требованиям, предъявляемым к научным статьям. Материал представляет интерес для читательской аудитории и после доработки может быть опубликован в журнале «Программные системы и вычислительные методы» (рубрика «Показатели качества и повышение надежности программных систем»).