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

Тиханычев Олег Васильевич 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 Другие публикации этого автора

Введение

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

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

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

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

Все эти факторы, пока ПО использовалось преимущественно в узкоспециализированных системах, были не критичными – ошибки, как правило, обнаруживались и устранялись как на этапе тестирования, так и в процессе эксплуатации, не приводя к существенным проблемам ^[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 – Пример формирования и контроля требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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