Software & Systems

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

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

К сожалению, как показывает практика, эффективность данных методик и средств тестирования не всегда обеспечивает безопасность эксплуатации сложных систем [1–3]. Примерами могут служить достаточно большое количество технических происшествий, связанных с некорректным функционированием ПО, например, авария российского разгонного блока «Фрегат» в декабре 2017 года. Как показало расследование, причина случившегося в ошибке ПО, не выявленной на этапе тестирования и проявившейся через два десятилетия эксплуатации [4]. Аналогичным примером является и сбой ПО автоматизированной системы противовоздушной обороны «Си Вулф» английского фрегата «Бродсворд» во время боя с аргентинскими самолетами в мае 1982 года, когда пара самолетов была воспринята как одна цель, а потом зафиксирована еще раз как две раздельные цели [5]. Подобных примеров аварий, обусловленных ошибками ПО, можно привести множество: непоражение обнаруженной иракской ракеты «Скад» 25 февраля 1991 года комплексом Patriot из-за не выявленного ранее накопления ошибки округления внутреннего таймера, сбой электроники истребителей F-22 Raptor в момент пересечения линии перемены дат, отказ компьютерной системы амери- канского ракетного крейсера «Йорктаун» в 1997 году из-за ошибки деления на ноль, приведшая к катастрофе некорректная работа автоматики системы MCAS самолетов «Боинг» в 2018 году в Индонезии, в 2019 году в Эфиопии и другие. У этих ситуаций различные природа и последствия, но их объединяет причина возникновения – нештатная работа ПО.

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

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

Обзор средств и методологий контроля качества

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

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

-     обеспечение качества процесса и продукта (категория процессов CMMI Support);

-     проверка (категория Engineering);

-     аттестация (категория Engineering).

Обе эти методологии не противоречат друг другу, реализующие их стандарты рассматриваются специалистами как взаимодополняющие. Методологии детализируются в нормативных документах (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94, IEEE Std 610.12-1990 и других).

В рамках реализации указанных методологий в соответствии с нормативно-технической документацией [6, 7] ПО до внедрения в систему проходит целый ряд приемо-сдаточных испытаний, оценивающих качество разрабатываемых программ. Объем и содержание проверок определяются нормативно-технической документацией, например, ГОСТами 19.301-79, 34.603-92 или Р 15.301-2016.

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

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

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

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

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

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

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

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

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

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

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

Анализ возможных источников возникновения проблем

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

Анализ показывает, что существующие принципы оценки качества основаны на следующих допущениях:

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

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

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

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

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

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

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

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

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

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

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

Предложения по решению проблемы

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

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

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

В-третьих, для реализации гибких принципов оценки качества потребуется расширение спектра и соотношения используемых методов тестирования: от проверки формальных признаков отдельных программ, описанных в ТЗ (UNIT-тестирова­ние), к преимущественному тестированию системы по существу (функциональное тестирование), в том числе в процессе закрытия внутренних этапов разработки в ходе реализации гибких методологий. При таком подходе потребуется активное привлечение к проведению проверок на всех этапах разработки аналитиков, а в ряде случаев и экспертов предметной области (конечных пользователей). Его применение обеспечит не только расширение перечня проверяемых как количественных, так и качественных параметров, но и вынесение части объема проверок на этап разработки. Последнее позволит увеличить сам объем проверок без увеличения срока приемо-сдаточных испытаний, а также обеспечить динамичное совершенствование компонентов программы в ходе ее разработки. Это относится и к таким важным, но ограниченно тестируемым в настоящее время компонентам, как пользовательский интерфейс программы [13].

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

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

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

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

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

Доработки по уточнению существующих принципов оценки качества программ

Improvements to clarify the existing principles for assessing program quality

Заключение

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

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

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

Литература

1.    Тиханычев О.В. О показателях качества программного обеспечения автоматизированных систем управления // Программные системы и вычислительные методы. 2020. № 2. С. 22–36. DOI: 10.7256/2454-0714.2020.2.28814.

2.    Wagner S., Goeb A., Heinemann L. et al. Operationalised product quality models and assessment: The Quamoco approach. Information and Software Technology, 2015, no. 62, рр. 101–123. DOI: 10.1016/j.infsof.2015.02.009.

3.    Krill P. Software testers balk at ISO 29119 standards proposal. InfoWorld Tech Watch, 2014. URL: https://www.infoworld.com/article/2608932/software-testers-balk-at-iso-29119-standards-proposal.html (дата обращения: 27.10.2021).

4.    Tikhanychev O.V. On improving indicators for assessing the decision support systems' software quality. IOP Conf. Ser.: Mater. Sci. Eng., 2020, vol. 919, art. 052009. DOI: 10.1088/1757-899x/919/5/052009.

5.    Danglot B., Vera-Perez O., Yu Z., Zaidman A., Monperrus M., Baudry B. A snowballing literature study on test amplification. J. of Systems and Software, 2019, vol. 157, art. 110398. DOI: 10.1016/j.jss. 2019.110398.

6.    Lewis W.E., Dobbs D., Veerapillai G. Software Testing and Continuous Quality Improvement. Boca Raton, CRC Press Publ., 2017, 688 p. DOI: 10.1201/9781439834367.

7.    Тиханычев О.В., Макарцев Л.В., Гахов В.Р. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. 2017. Т. 36. № 4. С. 706–710. DOI: 10.15827/ 0236-235X.120.706-710.

8.    Струбалин П.В., Фатьянова А.А. Управление качеством программного обеспечения // Вестн. СГСЭУ. 2019. № 2. C. 108–111.

9.    Ransome J., Misra A. Core Software Security: Security at the Source. Boca Raton, CRC Press Publ., 2014, 351 p.

10. Никулина И.Е., Николаенко В.С. Становление и развитие концепций управления проектами и риск-менеджмента // Государственное управление. 2018. № 68. URL: https://portal.tpu.ru/SHARED/n/ NIKOLAENKOVS/Scientific_work/Tab/nikulina_nikolaenko%202.pdf (дата обращения: 27.10.2021).

11. Бугорский В.Н., Голоскоков К.П. Управление качеством в процессе испытаний средств электронной техники // Прикладная информатика. 2011. № 1. C. 50–60.

12. Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ. М.: Диалектика, 2019. 272 с.

13. Wiegers K. Creating a Software Engineering Culture. NY, Dorset House Publ., 2013, 359 p.

References

1. Tikhanychev O.V. On the quality indicators of automated control systems software. Software Systems and Computational Methods, 2020, no. 2, pp. 22–36. DOI: 10.7256/2454-0714.2020.2.28814 (in Russ.).
2. Wagner S., Goeb A., Heinemann L. et al. Operationalised product quality models and assessment: The Quamoco approach. Information and Software Technology, 2015, no. 62, рр. 101–123. DOI: 10.1016/j.infsof.2015.
   02.009.
3. Krill P. Software testers balk at ISO 29119 standards proposal. InfoWorld Tech Watch, 2014. Available at: https://www.infoworld.com/article/2608932/software-testers-balk-at-iso-29119-standards-proposal.html (accessed October 27, 2021).
4. Tikhanychev O.V. On improving indicators for assessing the decision support systems' software quality. IOP Conf. Ser.: Mater. Sci. Eng., 2020, vol. 919, art. 052009. DOI: 10.1088/1757-899x/919/5/052009.
5. Danglot B., Vera-Perez O., Yu Z., Zaidman A., Monperrus M., Baudry B. A snowballing literature study on test amplification. J. of Systems and Software, 2019, vol. 157, art. 110398. DOI: 10.1016/j.jss.2019.110398.
6. Lewis W.E., Dobbs D., Veerapillai G. Software Testing and Continuous Quality Improvement. Boca Raton, CRC Press Publ., 2017, 688 p. DOI: 10.1201/9781439834367.
7. Tikhanychev O.V., Makartsev L.V., Gakhov V.R. Rational organization of an application software development process for decision support successful automation. Software and Systems, 2017, vol. 36, no. 4, pp. 706–710. DOI: 10.15827/0236-235X.120.706-710 (in Russ.).
8. Strubalin P.V., Fatyanova A.A. Quality management for software. Bull. of SGSEU, 2019, no. 2, pp. 108–111 (in Russ.).
9. Ransome J., Misra A. Core Software Security: Security at the Source. Boca Raton, CRC Press Publ., 2014, 351 p.
10. Nikulina I.E., Nikolaenko V.S. Formation and development of project management and risk management concepts. Public Administration, 2018, no. 68. Available at: https://portal.tpu.ru/SHARED/n/NIKOLAENKOVS/
    Scientific_work/Tab/nikulina_nikolaenko%202.pdf (accessed October 27, 2021) (in Russ.).
11. Bugorsky V.N., Goloskokov K.P. Quality management when testing electronic equipment. J. of Applied Informatics, 2011, no. 1, pp. 50–60 (in Russ.).
12. Myers G., Badgett T., Sandler C. The Art of Software Testing. Word Association Publ., 2012, 240 p. DOI: 10.1002/9781119202486. (Russ. ed.: Moscow, 2019, 272 p.).
13. Wiegers K. Creating a Software Engineering Culture. NY, Dorset House Publ., 2013, 359 p.