Программные системы и вычислительные методы
Правильная ссылка на статью:
Тиханычев О.В. — Об уточнении парадигмы контроля качества программных продуктов // Программные системы и вычислительные методы. - 2022. - № 2. DOI: 10.7256/2454-0714.2022.2.37985 EDN: ZXYEKP URL: https;//nbpublish.com'library_read_article.php?id=37985
Об уточнении парадигмы контроля качества программных продуктов
Тиханычев Олег Васильевич
ORCID: 0000-0003-4759-2931 кандидат технических наук
заместитель начальника отдела управления перспективных разработок, ГК "Техносерв
111395, Россия, г. Москва, ул. Юности, 13
И tow65@yandex.ru
Статья из рубрики "Показатели качества и повышение надежности программных систем"
DOI:
10.7256/2454-0714.2022.2.37985
EDN:
ZXYEKP
Дата направления статьи в редакцию:
03-05-2022
Аннотация: Актуальность статьи определяется тем, что, несмотря на большой практический опыт, накопленный в области автоматизации управления, в процессе разработки автоматизированных систем остаётся достаточно много проблем, в том числе, связанных с разработкой прикладного программного обеспечения для них. С учетом этого, в качестве предмета исследования выбран процесс разработки программного обеспечения автоматизированных систем управления. Объектом исследования выбрана модель контроля качества этого процесса, реализуемая в парадигме контроля. В настоящее время нормативные документы, регулирующие оценку качества программного обеспечения, сформированы на основе парадигмы, определяющей, что качество программ проверятся исключительно на соответствие требованиям технического задания. Но, как показала практика, такая парадигма не в полной мере соответствует современным условиям, обеспечивая не полноценный контроль качества, а проверку соответствия программ ожиданиям заказчика, сформулированным ещё на этапе проектирования системы. Для поиска путей решения проблемы, в статье использованы общенаучные методы анализа и синтеза. На основе анализа применяемых в настоящее время методов и моделей тестирования программного обеспечения синтезированы предложения по уточнению парадигмы его
оценки. В статье сформулирована постановка научно-практической задачи и предложен возможный подход к её решению, основанный на уточнении используемой в настоящее время парадигмы оценки качества, на переходе от «жесткой», заранее задаваемой модели, к расширенной модели оценки качества, учитывающей не только требования технического задания, но и условия их выполнения, а также наличие синергетического эффекта. Новизна предлагаемого подхода заключается в том, что решение сформулированной задачи обеспечит общее повышение качества автоматизации управления за счёт повышения безопасности и эффективности программ на основе перехода к применению расширенной динамической модели тестирования разрабатываемого программного обеспечения, реализуемой в рамках уточнённой парадигмы оценки качества
Ключевые слова: модель оценки качества, парадигма оценки качества, оценка качества программ, качество программного обеспечения, программное обеспечение, поддержка принятия решений, автоматизированная система управления, методология управления качеством, принцип оценки качества, тестирование программ
Введение
К важнейшим вопросам, возникающим при разработке прикладных программ можно отнести контроль качества, обеспечивающий эффективность принимаемых решений и безопасность функционирования систем, которые управляются с применением программного обеспечения. Необходимость контроля качества разрабатываемых программ определяется объективным фактором появления ошибок программного обеспечения (ПО), который обусловлен следующими причинами:
■ недостаточная полнота описания требований заказчика, описанных в техническом задании (ТЗ) на работу и детализирующих его документах;
■ погрешности интерпретации требований ТЗ и других документов аналитиками и а лгоритмис та ми;
■ системные, технические и логические ошибки, возникающие при разработке программного кода, структуры баз данных и запросов к ним.
Все эти факторы, пока ПО использовалось преимущественно в узкоспециализированных системах, были не критичными - ошибки, как правило, обнаруживались и устранялись как на этапе тестирования, так и в процессе эксплуатации, не приводя к существенным проблемам [1,2,3].
Но, в последние годы актуальность проблемы контроля качества существенно возросла: ошибки проявляются всё чаще, а их последствия становятся всё заметнее. Это определяется тем, что разнообразное ПО всё активнее внедряется во все сферы деятельности: от управления простыми бытовыми устройствами в рамках интернета вещей IoT (Internet of Things), до распределённых систем поддержки принятия решений типа ERP (Enterprise Resource Planning) и программных средств управления автономными робототехническими системами.
Наглядными примерами, подтверждающими данный тезис, могут служить происшествия, связанные с некорректным функционированием программного обеспечения в составе сложных технических систем. Такие, как авария российского разгонного блока «Фрегат» в декабре 2017 года, произошедшей из-за ошибки ПО, не выявленной на этапе
тестирования и проявившейся через два десятка лет эксплуатации J4!. Или сбой программного обеспечения автоматизированной системы противовоздушной обороны английского фрегата «Бродсворд» (F88 Broadsword) во время боя с аргентинскими самолётами в мае 1982 года, когда пара самолётов была воспринята как одна цель, а
потом зафиксирована ещё раз как две раздельные ^^ Аналогичных примеров, порождаемых ошибками функционирования ПО, можно привести множество: непоражение обнаруженной иракской ракеты «Скад» (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]. Но, как показывают приведённые в начале статьи примеры, этого не происходит.
Анализ применяемых методов, средств и технологий тестирования показывает, что целью всех видов контроля является формальная проверка соответствия разрабатываемого ПО требованиям задающей документации, разрабатываемой ещё на этапе формирования исходных данных по облику и функционалу системы, в первую очередь - технического
задания и постановок на разработку задач ü^l. При этом, в процессе организации и проведения тестирования, качество и полнота указанных документов, как правило, не подвергаются сомнению, не ставится задача управления показателями и критериями оценки качества ни при изменении требований и ожиданий заказчика, ни при уточнении условий функционирования разрабатываемой системы. Как показала практика, использование данного подхода может приводить к появлению невыявленных ошибок разработки ПО, в ряде случаев - критичных.
2.Возможные источники возникновения ошибок тестирования
По результатам анализа применяемой нормативно-технической документации и реализуемых в её рамках методов тестирования, сделано предположение о том, что одним из основных источников возникновения проблемы оценки качества
разрабатываемых программ, является существующая парадигма его оценки - принятие документов, задающих разработку ПО как аксиомы и проведение проверки исключительно относительно требований этих документов.
Реализуемая в рамках подобной модели парадигма оценки качества построена на следующих базовых допущениях:
■ заказчик, уже на начальном этапе разработки ПО точно знает, какой функционал он ожидает получить от конечного продукта;
■ заказчик перед началом разработки корректно задал границы применимости системы, допущения и ограничения;
■ алгоритмисты и программисты организации-разработчика абсолютно верно и без искажений трактуют требования заказчика, изложенные в техническом задании и пос та нов ка х на ра з ра бо тку з а да ч .
Вполне логично, что в такой постановке, качество разрабатываемой программы считается однозначно удовлетворительным, если она отвечает требованиям технического задания. То есть, в существующей парадигме, соответствие требованиям технического задания считается необходимым и достаточным условием подтверждения качества разработанной программной продукции.
Но, как показывает практика, существуют, ошибок разработки и тестирования, применяемой в настоящее время парадигмы
как минимум, три потенциальных источника подвергающих сомнению эффективность оценки качества ПО.
Первое , это периодически встречающаяся ситуация недостаточно полного описания заказчиком содержания автоматизируемых процессов при написании ТЗ и в ходе разработки документов «Постановка на разработку программ». Это объяснимо: объём разрабатываемых документов и время на их написание ограничены, поэтому исполнители могут опускать описание процессов и функций, как неумышленно, так и намеренно - в части тех, которые они считают очевидными и не требующими отдельного упоминания. В результате, данные функции выпадают из процесса контроля выполнения требований технического задания. Разумеется, можно организационно решать подобные проблемы, введя рекомендации по требуемой детализации описания исходных данных. Но, напомним, объём ТЗ, хоть и не ограничивается нормативными документами, но не бесконечен: его увеличение способствует повышению качества разработки только до определённого предела, далее наступает перенасыщение информацией.
Вторая причина аналогична первой, она возникает, когда тестировщик, составляя программу проверки, пропускает, считая их типовыми, неверно интерпретирует или недостаточно полно описывает какие-либо требования заказчика. Итог, как правило, получается тот же, что и в предыдущем случае.
И третье , автоматизация системы управления, как любое системное действие, в соответствии с принципом эмержентности, может придавать разрабатываемой программно-технической системе новые свойства, которых не было ранее и которые, соответственно, не описаны ни в техническом задании, ни в постановках на разработку программ. При применяемом в настоящее время подходе к организации тестирования, эти свойства проверены просто не будут.
В качестве пояснения причин возникновения и проявления возможных вариантов подобных проблем, можно рассмотреть пример разработки программы управления
грузоперевозками для автотранспортного предприятия. А точнее, процесс формирования требований к ней и контроля их выполнения на основных этапах разработки системы автоматизированного управления предприятием (таблица 1).
Таблица 1 - Пример формирования и контроля требований
Тип Требования, Дополнительные Требования, Системные
требований указанные требования, необходимые требования,
заказчиком в формируемые при для возникающие
техническом детализации в ходе выполнения рамках
задании разработки основного и проявления
по с та но в о к на дополнитель- синергическо
разработку задач ного эффекта
функционала
Необходимость Подлежат Подлежат В При
проверки в обязательной проверке, если существующей использовани
соотв етств ии с проверке в задокументированы парадигме существующе
существующей с о о тв е тс тв ии с в с о о тв е тс тв ии с проверки не модели
парадигмой ГОСТ 19.301-79, ГОСТ серии 34, РД обязательны, качества, мог
ГОСТ 34.603-92 и 50-34.698-90 мог ут не про в е ря ть
ГОСТ Р 15.301- про в е ря тьс я в
2016 рамках
методологии
FURPS+
Содержание Оперативность Оптимизация Учёт Комплексная
требований доставки грузов скоростного характеристик оптимизация
режима дорожной распределени
сети маршрутов
Оптимизация Учёт пунктам
маршрутов структуры загрузки
движения дорожной выгрузки
Низкая стоимость Сокращение сети учётом
перевозок маршрутов особенностей
доставки дорожной се
Повышение Оптимизация и
грузоподъёмности модельного характеристи
и вместимости ряда транспортных
транспортных средств
средств
Снижение расхода
топлива
Экономичность Повышение Соответствие
функционирования коэффициента типа
предприятия загрузки транспортных
транспортных средств
средств перевозимым
грузам
Уменьшение Оптимизация
времени простоя процесса
обслуживания
транспортных средств
В таблице 1 описан пример последствий недостаточной детализации требований к разрабатываемой программе и результатов отсутствия учёта синергетического эффекта. Кроме данных ситуаций, на практике периодически возникает ещё и субъективная проблема, описанная ранее - когда заказчик не упоминает в ТЗ и постановках ряд требований, считая их очевидными. В рамках разработки задачи для оптимизации автомобильных перевозок это были, как показала практика, требования проверки полноты заправки топливом транспортных средств перед выездом и наличия подготовленных водителей. В результате, данные требования не попали в программу и методики проверок, и необходимость их выполнения была выявлена только на этапе опытной эксплуатации, что потребовало затрат на доработку уже проверенной программы, увеличило время внедрения. То есть, методы контроля качества, основанные на существующей парадигме, не обеспечивают полноценной проверки разрабатываемых программных средств.
3.Предлагаемый подход к решению проблемы
Наиболее очевидным подходом к решению сформулированной проблемы представляется уточнение применяемой парадигмы оценки качества программной продукции. С учётом структуры используемых в рамках данной парадигмы моделей качества и принципов их реализации, выполнение данной задачи может быть обеспечено преимущественно организационными мерами. Перечень данных мер и методология их реализации определяется содержанием предлагаемой парадигмы контроля качества и её отличиями от применяемой в настоящее время.
Во-первых , необходимо формально уточнить саму парадигму, заменив в нормативно-технической документации заявленный подход организации контроля качества с существующего «жёсткого», направленного исключительно на проверку требований ТЗ, на «гибкий», позволяющий дополнять и расширять систему проверяемых показателей и критериев их выполнимости в ходе разработки программ по упрощённой процедуре, без прохождения полного цикла повторного согласования требований, как это описано в существующей НТД.
Во-вторых , в рамках реализации уточнённой парадигмы, предлагается изменить область проверки качества, расширив её от формальной проверки требований ТЗ к дополнительному анализу возможности их реализации. То есть, предлагается проверять как сами требования, так и необходимые условия для их выполнения, не описанные в ТЗ в явном виде. А именно, проверять как последствия синергетического эффекта, так и «производные» показатели, являющиеся продуктом преобразования высокоуровневых требований в свойства большей детализации. Первое может определяться на основе дополнительных исследований системных связей разрабатываемого ПО. Второе требование логично реализовать по принципам, описанным в известной спецификации требований к программным средствам FURPS+ (Functionality, Usability, Reliability,
Performance, Supportability плюс дополнительны факторы) i13^.
В-третьих , с учётом предыдущего пункта, для реализации «гибкой» парадигмы оценки качества, вероятно, потребуется расширение спектра и уточнение соотношения используемых методов тестирования: от проверки формальных признаков отдельных модулей и программ, описанных в техническом задании (формальному тестированию отдельных функций) к системному тестированию. Для реализации такого подхода
потребуется привлечение к проведению проверок аналитиков, а, в ряде случаев, и экспертов предметной области (конечных пользователей). Причём привлечения последних не на этапе опытной эксплуатации, как это регламентируется в настоящее время, а на всех этапах предварительных и приемо-сдаточных испытаний. Возможное увеличение объёма проверок, возникающее при таком подходе, не является критичным, так как оно позволит уменьшить объём последующих доработок, в том числе - за счёт предотвращения накопления ошибок по ходу разработки.
И если ведущие зарубежные разработчики ПО хотя бы частично пытаются реализовать расширенную модель контроля качества, управляя требованиями в рамках адПе-технологий или дополняя их с использованием подходов, аналогичных FURPS+, то отечественная НТД опирается исключительно на «жёсткую» модель качества, ориентируясь исключительно на проверку требований технического задания. Для исправления ситуации необходима разработка мер, основанных как на использовании зарубежного опыта, так и на собственных разработках на основе теории систем.
Комплексное выполнение предлагаемых мер позволит сформировать и применить «расширенную» парадигму контроля качества ПО (рисунок 1), включающую в себя:
■ контроль выполнения требований технического задания, как это реализуется в настоящее время;
■ выявление наличия и анализ контроля выполнимости дополнительных условий, необходимых для выполнения требований технического задания;
■ выявление и проверку безопасности проявлений синергетического эффекта, возникающих при разработке системных требований ТЗ.
Внедрение уточнённой парадигмы организации контроля качества потенциально обеспечивает решение важной научно-практической задачи, и обещает принципиально изменить эффективность тестирования за счёт существенного прироста полноты проверок и повышения достоверности результатов. В том числе потому, что в рамках новой парадигмы предлагается не просто корректировать цель тестирования: уточнённая парадигма подразумевает расширение спектра проверок, которые будут проводиться на полном диапазоне функционала разрабатываемого ПО, не ограничиваясь областью, в которой реализуются требования ТЗ.
Рисунок 1. Графическая интерпретация уточнения парадигмы контроля качества
программ
Внедрение уточнённой парадигмы потребует предварительного выполнения ряда мероприятий:
■ проведение НИОКР по разработке методик декомпозиции требований заказчика на частные, необходимые для выполнения основных задач;
■ разработка методологии выявления системных требований и анализа их влияния на функциональность и безопасность разрабатываемого ПО и управляемых им систем;
■ корректировку нормативной и руководящей конструкторской документации в части структуры жизненного цикла ПО, порядка организации и проведения испытаний.
Выполнение данных мероприятий, разумеется, потребует определённых материальных и временных затрат.
С другой стороны, анализ содержания таблицы 1 и опыта разработки программно-технических комплексов, показывает, что, в существующей парадигме из проверки могут выпадать до 20-25% частных требований по функционалу. Кумулятивное влияние этого фактора приводит к снижению качества тестирования, к увеличению объёма потребных доработок в процессе апробации программ и опытной эксплуатации, затягиванию процесса разработки. И, как подтверждает проведённый анализ, указанные проблемы порождает именно принятая парадигма оценки качества, по которой формируется модель его оценки и уточняются её показатели.
Внедрение же новой парадигмы, с учётом ожидаемой доли невыявленных ошибок ПО (две последние колонки таблицы 1) и их влияния, по данным DTI, на потери прибыли из-за проблем с качеством программного обеспечения, потенциально может сэкономить до 5% затрат автоматизируемого предприятия. И это только материальные потери. В ситуациях, когда ошибки ПО приводят к человеческим жертвам, как в случаях крушения самолётов «Боинг», стоимость пропущенных ошибок переоценить сложно. Наиболее важным представляется то, что указанная экономия и предотвращение потенциальных аварий и катастроф, будут осуществлены без дополнительных материальных затрат, за счёт организационных мер по внедрению уточнённой парадигмы контроля качества.
Заключение
Проведённый в статье анализ причин возникновения ошибок функционирования программного обеспечения показал, что существенная их доля возникает из-за проблем организации тестирования, не позволяющих выявлять ошибки, совершаемые на этапе разработки, до появления критичных неисправностей в ходе эксплуатации. И значительная часть этих проблем, как показала практика, порождается использованием существующей парадигмы оценки качества программной продукции, выдвигающей как необходимое и достаточное условие обеспечения качества, выполнение требований технического задания.
Предложенное в статье изменение данной парадигмы, при котором выполнение требований ТЗ останется только необходимым условием, а достаточные условия будут дополняться потребным для реализации этих требований дополнительным функционалом и безопасностью системных проявлений, может обеспечить существенное повышение вероятности выявления ошибок на всех этапах разработки программ и технических систем, управляемых с использованием программного обеспечения. Отказ от использования существующей парадигмы, позволит выстроить динамичный процесс контроля качества, подобный реализуемому в настоящее время для управления
требованиями заказчика в agile-методологии и используемому при формировании FURPS+ моделей управления требованиями.
Необходимо отметить, что предложенное изменение парадигмы контроля качества, это не прямое заимствование «гибких» подходов к управлению требованиями заказчика в буквальном понимании. Нет, это более широкий подход к оценке, когда в ходе тестирования проверяются не только выраженные в явном виде требования, но и условия, необходимые для их выполнения, а также факторы синергетического характера, что является новым решением известной задачи формирования модели оценки качества программной продукции.
Библиография
1. Тиханычев О.В. О показателях качества программного обеспечения автоматизированных систем управления // Программные системы и вычислительные методы. 2020. № 2. С. 22-36; DOI: 10.7256/2454-0714.2020.2.28814.
2. Wagner S. Operationalised product quality models and assessment: The Quamoco approach. Information and Software Technology. 2015. no.62. рр.101-123; D0I:10.1016/j.infsof.2015.02.009.
3. The Sunday paper (tech ethics edition) // Defense Tech. January 2008 [Электронный ресурс]. URL: htpp://defensetech.org/2008/01/27/ (дата обращения: 30.01.2008).
4. Tikhanychev O. V. 2020 On improving indicators for assessing the decision support systems' software quality IOP Conf. Ser.: Mater. Sci. Eng. 919 052009; DOI: 10.1088/1757-899x/919/5/052009.
5. Woodward S., Robinson P. One Hundred Days: The Memoirs of the Falklands Battle Group Commander. Harper Collins, London, 1997. 213 p.
6. Hyrum K. Wright. ESEC/FSE Doctoral Symposium '09: Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium. August 2009 Pages 2728https ://doi.org/10.1145/1595782.1595793.
7. Макарцев Л.В. и др. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. 2017. №4. С.706-710; DOI: 10.15827/0236-235X.120.706-710.
8. Струбалин П.В., Фатьянова А.А. Управление качеством программного обеспечения // Вестник СГСЭУ. 2019. №2(76). C.108-111.
9. Брагина Т.И., Табунщик Г.В. Сравнительный анализ итеративных моделей разработки программного обеспечения // Радиоэлектроника, информатика, управление. 2010. №2(23). C.130-138.
10. Никулина И.Е., Николаенко В.С. Становление и развитие концепций управления проектами и риск-менеджмента // Государственное управление. Электронный вестник. Июнь 2018.
11. Бугорский В.Н., Голоскоков К.П. Управление качеством в процессе испытаний средств электронной техники // Прикладная информатика. 2011. №1(31). C.50-60.
12. Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ, 3-е издание, изд.3, М.: Диалектика, 2012. - 272 с.
13. Wiegers K. Creating a Software Engineering Culture. Addison-Wesley. 2013. pp.211212
Результаты процедуры рецензирования статьи
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.
Рецензируемая работа посвящена актуальному направлению контроля качества программных продуктов в сложных технических системах. Авторы акцентируют внимание на катастрофических последствиях программных ошибок, не выявленных на этапе тестирования, в системах оборонного комплекса и вооружении, и вызванных, например, ошибками округлений. Отмечается, что снижение качества ПО вызвано не недостатками самих методов тестирования, а его некорректной организацией.
Актуальность работы заключается в формировании подходов к проверке качества ПО, снижении ошибок принятия решений и предотвращения негативных последствий ошибок его функционирования. Авторы анализируют требования стандартов качества и нормативной документации, рассматривают средства и методы тестирования, отмечают формальную сторону соответствия разработанного ПО требования задания. Достоинством работы является анализ источников возникновения ошибок тестирования. Авторы акцентируют внимание на ошибках, связанных с очевидностью ряда требований для заказчика и отсутствии их в задании разработчику, что приводит к ошибкам при разработке алгоритма ПО. Научную новизну определить затруднительно. Стиль изложения. В статье используется профессиональная терминология, однако в тексте отсутствуют формулы и количественные критерии оценки результатов. Отсутствуют иллюстрации.
Структура статьи в целом отвечает требованиям к научной публикации.
Библиография содержит 13 отечественных и зарубежных источников, в т.ч. в
рецензируемых изданиях.
Замечания.
В статье не упоминается типовая продолжительность этапов создания программных продуктов, и длительность этапа тестирования в общей продолжительности разработки ПО.
Не упоминаются критерии выбора элементов технического задания, подробность его составления.
В табл. 1 приведен пример из конкретной отрасли, однако в тексте статьи отсутствует обоснование выбора именно её. Приведенные количественные критерии характерны для любого ПО или определенного?
Значительная часть статьи посвящена вопросам организации тестирования, однако не приводится какой-либо алгоритм снижения вероятности ошибок. Какова типовая продолжительность этапа поиска ошибок ПО?
Статья носит аналитический характер, экспериментальная часть отсутствует. Однако для указанного примера приводятся количественные оценки. Не вполне ясно как они по луч е ны.
Желательно дополнить статью анализом существующих количественных оценок или типовыми или предлагаемым авторами алгоритмами поиска ошибок. Возможно ли снижение вероятности ошибок посредством качественных исследований в целевой аудитории.
В заключение необходимо сформулировать четко предлагаемыми авторами решения, рекомендации или требования к исходным данным. Библиографию оформить в соответствии с требованиями журнала.
Статья интересна специалистам в области разработки программного обеспечения, тестирования продуктов, решения прикладных задач методами программирования. Статья нуждается в доработке, после которой может быть опубликована в журнале «Программные системы и вычислительные методы».