Статья 'Об уточнении парадигмы контроля качества программных продуктов' - журнал 'Программные системы и вычислительные методы' - NotaBene.ru
по
Меню журнала
> Архив номеров > Рубрики > О журнале > Авторы > Требования к статьям > Политика издания > Редакция > Порядок рецензирования статей > Редакционный совет > Ретракция статей > Этические принципы > О журнале > Политика открытого доступа > Оплата за публикации в открытом доступе > Online First Pre-Publication > Политика авторских прав и лицензий > Политика цифрового хранения публикации > Политика идентификации статей > Политика проверки на плагиат
Журналы индексируются
Реквизиты журнала
ГЛАВНАЯ > Вернуться к содержанию
Программные системы и вычислительные методы
Правильная ссылка на статью:

Об уточнении парадигмы контроля качества программных продуктов

Тиханычев Олег Васильевич

ORCID: 0000-0003-4759-2931

кандидат технических наук

заместитель начальника отдела управления перспективных разработок, ГК "Техносерв"

111395, Россия, г. Москва, ул. Юности, 13

Tikhanychev Oleg Vasilyevich

PhD in Technical Science

Deputy Head of Department in the Office of Advanced Development, Technoserv Group 

111395, Russia, Moscow, Yunosti str., 13

tow65@yandex.ru
Другие публикации этого автора
 

 

DOI:

10.7256/2454-0714.2022.2.37985

EDN:

ZXYEKP

Дата направления статьи в редакцию:

03-05-2022


Дата публикации:

05-07-2022


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


Ключевые слова:

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

Abstract: Despite the extensive volume of experience in the field of control automation, there are quite a lot of problems in the process of developing automated systems, including those related to the development of application software for them. With this in mind, the process of software development of automated control systems is chosen as the subject of research. The object of the study is a model of quality control of this process. Currently, legal regulation of software quality control is based on a paradigm that determines that the quality of programs will be checked exclusively for compliance with the requirements of the terms of contract. But, as practice has shown, such a paradigm does not fully meet modern conditions, providing not full-fledged quality control -- the verification of compliance of programs with customer expectations formulated at the stage of system design is needed. To find ways to solve the problem, the article uses general scientific methods of analysis. Based on the analysis of currently used methods and models of software testing, proposals for clarifying the paradigm of its evaluation and control are synthesized. The article formulates a scientific and practical problem and suggests a possible approach to its solution based on the refinement of the quality assessment paradigm currently used, on the transition from a "rigid", preset model to an expanded quality assessment model that takes into account not only the requirements of the terms of the contract, but also the conditions for their implementation. The novelty of the proposed approach lies in the fact that the solution of the formulated task will provide an overall improvement in the quality of control by improving the safety and effectiveness of programs based on the transition to the use of an extended dynamic testing model of the software being developed, implemented within the framework of a refined quality assessment paradigm


Keywords:

automated control system, decision support, software, software quality, program quality assessment, the quality assessment paradigm, quality assessment model, quality management methodology, the principle of quality assessment, testing programs

Введение

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

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

· погрешности интерпретации требований ТЗ и других документов аналитиками и алгоритмистами;

· системные, технические и логические ошибки, возникающие при разработке программного кода, структуры баз данных и запросов к ним.

Все эти факторы, пока ПО использовалось преимущественно в узкоспециализированных системах, были не критичными – ошибки, как правило, обнаруживались и устранялись как на этапе тестирования, так и в процессе эксплуатации, не приводя к существенным проблемам [1,2,3].

Но, в последние годы актуальность проблемы контроля качества существенно возросла: ошибки проявляются всё чаще, а их последствия становятся всё заметнее. Это определяется тем, что разнообразное ПО всё активнее внедряется во все сферы деятельности: от управления простыми бытовыми устройствами в рамках интернета вещей IoT (Internet of Things), до распределённых систем поддержки принятия решений типа ERP (Enterprise Resource Planning) и программных средств управления автономными робототехническими системами.

Наглядными примерами, подтверждающими данный тезис, могут служить происшествия, связанные с некорректным функционированием программного обеспечения в составе сложных технических систем. Такие, как авария российского разгонного блока «Фрегат» в декабре 2017 года, произошедшей из-за ошибки ПО, не выявленной на этапе тестирования и проявившейся через два десятка лет эксплуатации [4]. Или сбой программного обеспечения автоматизированной системы противовоздушной обороны английского фрегата «Бродсворд» (F88 Broadsword) во время боя с аргентинскими самолётами в мае 1982 года, когда пара самолётов была воспринята как одна цель, а потом зафиксирована ещё раз как две раздельные [5]. Аналогичных примеров, порождаемых ошибками функционирования ПО, можно привести множество: непоражение обнаруженной иракской ракеты «Скад» (Scud) 25 февраля 1991 года комплексом «Пэтриот» (Patriot) из-за не выявленного ранее накопления ошибки округления внутреннего таймера, сбой электроники истребителей F-22 Raptor в момент пересечения линии перемены дат, отказ информационной управляющей системы американского ракетного крейсера «Йорктаун» (USS Yorktown CG-48) в 1997 году из-за ошибки деления на ноль, ставшую причиной нескольких авиационных катастроф некорректную работу автоматики системы MCAS (Maneuvering Characteristics Augmentation System) самолётов «Боинг» (Boeing-737 MAX) и другие. И это только наиболее резонансные случаи. А в целом, по данным Департамента по торговле и промышленности Великобритании (DTI), при внедрении информационных технологий на предприятиях, потери прибыли из-за ненадлежащего качества программного обеспечения могут составлять до 20% от общего объема потерь.

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

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

· недостатки методов или средств тестирования;

· некорректная организация тестирования, использования методов или средств тестирования.

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

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

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

В настоящее время, при организации управления разработкой программ (software quality management), принято ориентироваться на две основных методологии управления качеством: TickIT (TickIT plus) и CMMI (Capability Maturity Model Integration).

Первая из них функционирует в рамках общей системы менеджмента качества проектов по разработке программного обеспечения ISO 9001-00. Вторая методология, CMMI, предоставляет рекомендации по совершенствованию процессов разработки. Обе эти методологии не противоречат друг другу, реализующие их стандарты рассматриваются специалистами как взаимодополняющие.

В рамках реализации указанных методологий, в соответствии с нормативно-технической документацией [6,7], программное обеспечение, до внедрения в систему, проходит целый ряд приёмо-сдаточных испытаний. Объём и содержание проверок определяется нормативно-технической документацией (НТД), в нашей стране: ГОСТ Р 15.301-2016 «Система разработки и постановки продукции на производство. Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство», ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем», ГОСТ 19.301-79 «Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению» и отменённым в 2019 году, но ничем пока не заменённым РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ведущих зарубежных странах используются стандарты формирования моделей качества ПО серии ISO 900x (ISO 9001 «Quality management systems. Requirements», ISO 9002 и ISO 9003), прямыми аналогами которых является часть отечественных ГОСТ, таких как ГОСТ Р ИСО 9001-2015.

Для обеспечения проведения проверок в рамках данных стандартов, используются различные средства и методы тестирования [8,9], работоспособность которых неоднократно подтверждалась практикой. И, теоретически, существующий спектр средств и методов тестирования должен полностью обеспечить проверку качества функционирования программ в любых условиях [10,11]. Но, как показывают приведённые в начале статьи примеры, этого не происходит.

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

2.Возможные источники возникновения ошибок тестирования

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

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

· заказчик, уже на начальном этапе разработки ПО точно знает, какой функционал он ожидает получить от конечного продукта;

· заказчик перед началом разработки корректно задал границы применимости системы, допущения и ограничения;

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

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

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

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

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

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

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

Таблица 1 – Пример формирования и контроля требований

Тип требований

Требования, указанные заказчиком в техническом задании

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

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

Системные требования, возникающие в рамках проявления синергического эффекта

Необходимость проверки в соответствии с существующей парадигмой

Подлежат обязательной проверке в соответствии с ГОСТ 19.301-79, ГОСТ 34.603-92 и ГОСТ Р 15.301-2016

Подлежат проверке, если задокументированы в соответствии с ГОСТ серии 34, РД 50-34.698-90

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

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

Содержание требований

Оперативность доставки грузов

Оптимизация скоростного режима

Учёт характеристик дорожной сети

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

Оптимизация маршрутов движения

Учёт структуры дорожной сети

Низкая стоимость перевозок

Сокращение маршрутов доставки

Повышение грузоподъёмности и вместимости транспортных средств

Оптимизация модельного ряда

Снижение расхода топлива

Экономичность функционирования предприятия

Повышение коэффициента загрузки транспортных средств

Соответствие типа транспортных средств перевозимым грузам

Уменьшение времени простоя

Оптимизация процесса обслуживания транспортных средств

В таблице 1 описан пример последствий недостаточной детализации требований к разрабатываемой программе и результатов отсутствия учёта синергетического эффекта. Кроме данных ситуаций, на практике периодически возникает ещё и субъективная проблема, описанная ранее – когда заказчик не упоминает в ТЗ и постановках ряд требований, считая их очевидными. В рамках разработки задачи для оптимизации автомобильных перевозок это были, как показала практика, требования проверки полноты заправки топливом транспортных средств перед выездом и наличия подготовленных водителей. В результате, данные требования не попали в программу и методики проверок, и необходимость их выполнения была выявлена только на этапе опытной эксплуатации, что потребовало затрат на доработку уже проверенной программы, увеличило время внедрения. То есть, методы контроля качества, основанные на существующей парадигме, не обеспечивают полноценной проверки разрабатываемых программных средств.

3.Предлагаемый подход к решению проблемы

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

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

Во-вторых, в рамках реализации уточнённой парадигмы, предлагается изменить область проверки качества, расширив её от формальной проверки требований ТЗ к дополнительному анализу возможности их реализации. То есть, предлагается проверять как сами требования, так и необходимые условия для их выполнения, не описанные в ТЗ в явном виде. А именно, проверять как последствия синергетического эффекта, так и «производные» показатели, являющиеся продуктом преобразования высокоуровневых требований в свойства большей детализации. Первое может определяться на основе дополнительных исследований системных связей разрабатываемого ПО. Второе требование логично реализовать по принципам, описанным в известной спецификации требований к программным средствам FURPS+ (Functionality, Usability, Reliability, Performance, Supportability плюс дополнительны факторы) [13].

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

И если ведущие зарубежные разработчики ПО хотя бы частично пытаются реализовать расширенную модель контроля качества, управляя требованиями в рамках agile-технологий или дополняя их с использованием подходов, аналогичных FURPS+, то отечественная НТД опирается исключительно на «жёсткую» модель качества, ориентируясь исключительно на проверку требований технического задания. Для исправления ситуации необходима разработка мер, основанных как на использовании зарубежного опыта, так и на собственных разработках на основе теории систем.

Комплексное выполнение предлагаемых мер позволит сформировать и применить «расширенную» парадигму контроля качества ПО (рисунок 1), включающую в себя:

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

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

· выявление и проверку безопасности проявлений синергетического эффекта, возникающих при разработке системных требований ТЗ.

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

Рисунок 1. Графическая интерпретация уточнения парадигмы контроля качества программ

Внедрение уточнённой парадигмы потребует предварительного выполнения ряда мероприятий:

· проведение НИОКР по разработке методик декомпозиции требований заказчика на частные, необходимые для выполнения основных задач;

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

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

Выполнение данных мероприятий, разумеется, потребует определённых материальных и временных затрат.

С другой стороны, анализ содержания таблицы 1 и опыта разработки программно-технических комплексов, показывает, что, в существующей парадигме из проверки могут выпадать до 20-25% частных требований по функционалу. Кумулятивное влияние этого фактора приводит к снижению качества тестирования, к увеличению объёма потребных доработок в процессе апробации программ и опытной эксплуатации, затягиванию процесса разработки. И, как подтверждает проведённый анализ, указанные проблемы порождает именно принятая парадигма оценки качества, по которой формируется модель его оценки и уточняются её показатели.

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

Заключение

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

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

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

Библиография
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

Результаты процедуры рецензирования статьи

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

Рецензируемая работа посвящена актуальному направлению контроля качества программных продуктов в сложных технических системах. Авторы акцентируют внимание на катастрофических последствиях программных ошибок, не выявленных на этапе тестирования, в системах оборонного комплекса и вооружении, и вызванных, например, ошибками округлений. Отмечается, что снижение качества ПО вызвано не недостатками самих методов тестирования, а его некорректной организацией.
Актуальность работы заключается в формировании подходов к проверке качества ПО, снижении ошибок принятия решений и предотвращения негативных последствий ошибок его функционирования. Авторы анализируют требования стандартов качества и нормативной документации, рассматривают средства и методы тестирования, отмечают формальную сторону соответствия разработанного ПО требования задания. Достоинством работы является анализ источников возникновения ошибок тестирования. Авторы акцентируют внимание на ошибках, связанных с очевидностью ряда требований для заказчика и отсутствии их в задании разработчику, что приводит к ошибкам при разработке алгоритма ПО. Научную новизну определить затруднительно.
Стиль изложения. В статье используется профессиональная терминология, однако в тексте отсутствуют формулы и количественные критерии оценки результатов. Отсутствуют иллюстрации.
Структура статьи в целом отвечает требованиям к научной публикации.
Библиография содержит 13 отечественных и зарубежных источников, в т.ч. в рецензируемых изданиях.
Замечания.
В статье не упоминается типовая продолжительность этапов создания программных продуктов, и длительность этапа тестирования в общей продолжительности разработки ПО.
Не упоминаются критерии выбора элементов технического задания, подробность его составления.
В табл. 1 приведен пример из конкретной отрасли, однако в тексте статьи отсутствует обоснование выбора именно её. Приведенные количественные критерии характерны для любого ПО или определенного?
Значительная часть статьи посвящена вопросам организации тестирования, однако не приводится какой-либо алгоритм снижения вероятности ошибок. Какова типовая продолжительность этапа поиска ошибок ПО?
Статья носит аналитический характер, экспериментальная часть отсутствует. Однако для указанного примера приводятся количественные оценки. Не вполне ясно как они получены.
Желательно дополнить статью анализом существующих количественных оценок или типовыми или предлагаемым авторами алгоритмами поиска ошибок. Возможно ли снижение вероятности ошибок посредством качественных исследований в целевой аудитории.
В заключение необходимо сформулировать четко предлагаемыми авторами решения, рекомендации или требования к исходным данным.
Библиографию оформить в соответствии с требованиями журнала.
Статья интересна специалистам в области разработки программного обеспечения, тестирования продуктов, решения прикладных задач методами программирования.
Статья нуждается в доработке, после которой может быть опубликована в журнале «Программные системы и вычислительные методы».
Ссылка на эту статью

Просто выделите и скопируйте ссылку на эту статью в буфер обмена. Вы можете также попробовать найти похожие статьи


Другие сайты издательства:
Официальный сайт издательства NotaBene / Aurora Group s.r.o.