Аналитика эффективного предотвращения дефектов программ



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

Ключевые слова: дефект, программное обеспечение, классификация дефектов, обнаружение и предотвращение дефектов.

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

«Лучше изначально позаботиться о безопасности, чем потом устранять инциденты». Это высказывание имеет огромное значение в разработке ПО и обеспечении качества продукта. Главные проблемы безопасности при разработке ПО действительно могут быть устранены конкретными проверками и валидацией. Таким образом, крайне важно выявлять проблемы (дефекты) на всех этапах, чтобы гарантировать повышение качества программных средств. Понятие «качество» включает в себя все характеристики и особенности продукта, которые относятся к удовлетворению заданного требования. Многие компании, производящие ПО, имеют отделы обеспечения качества ПО, где основное внимание уделяется предотвращению дефектов [1].

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

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

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

1. Основные классификации дефектов программ

Ортогональная классификация дефектов (ODC)

Фирма IВМ разработала подход к классификации ошибок, называемый ортогональной классификацией дефектов (Orthogonal Defect Classification). Подход предусматривает разбиение ошибок по категориям с соответствующей ответственностью разработчиков за них [3].

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

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

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

Рис. 1. Ортогональная классификация дефектов IBM

Анализ первопричины (RCA)

«Анализ первопричины» (Root cause analysis, RCA) или «Анализ первопричины отказа» (Root Cause Failure Analysis, RCFA) — структурированный пошаговый метод для нахождения реальной причины проблемы и реагирования на нее, а не только на ее симптомы. Это процесс, который помогает заинтересованным сторонам понять причины проблемы в достаточной степени, чтобы достигнуть ее полного разрешения [2].

Рис. 2. Диаграмма работы метода RCA

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

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

Основными входными данными метода RCA являются все объективные данные об отказах или потерях. Данные об аналогичных отказах также могут быть рассмотрены в процессе анализа. Другими входными данными могут быть данные, полученные при проверке конкретных гипотез [2].

Модель предотвращения дефектов программ ( DP Model )

Модель предотвращения дефектов программ (Defect Prevention model, DP model) — это стратегия, применяемая к жизненному циклу разработки ПО, которая выявляет коренные причины дефектов и предотвращает их повторение. Процесс предотвращения дефектов программ включает в себя анализ дефектов, возникших в прошлом, и определение контрольных точек и действий для предотвращения возникновения подобных дефектов в будущем. В целом, деятельность по предотвращению дефектов программ опирается на распространение знаний об обнаруженных и распознанных дефектах в других программных проектах [3].

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

Рис. 3. Скорость обнаружения дефектов ПО

Модель усовершенствованного процесса разработки ПО, включающего стратегию DP, представлена на рисунке 4 [4].

Рис. 4. Стратегия предотвращения дефектов в процессе разработки ПО

Классификация дефектов программ IEEE

Классификация дефектов программ IEEE (Standard classification for Anomalies, стандарт аномалий) была предложена для выработки единого стандарта классификации программных ошибок. Этот стандарт охватывает весь жизненный цикл ПО, эффективно выявляет и отслеживает дефекты и улучшает цикл разработки ПО [5].

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

– вычислительные проблемы;

– проблемы интерфейса/времени;

– логические проблемы;

– проблемы с данными;

– проблемы с обработкой данных;

– проблемы с качеством документа;

– проблемы с документацией;

– проблемы с усилением защиты.

Каждый класс также может быть разделен на более подробные подклассы. Эта модель хорошо масштабируется, ее можно адаптировать под конкретный тип программного проекта. Из этих особенностей вытекает главный недостаток модели — сильная зависимость от уровня квалификации команды разработчиков и менеджера проекта, так как индивидуальные субъективные факторы будут серьезно влиять на классификацию [6].

2. Методики обнаружения и распознавания дефектов программной среды

Сложность ПО также приводит к большему количеству дефектов, и поэтому ручное обнаружение может стать очень трудоемким процессом. Это дало исследователям стимул для разработки методов автоматического обнаружения дефектов ПО [7].

Далее будут проанализированы различные методики и алгоритмы, которые помогут обнаружить дефекты ПО.

Метод обнаружения дефектов на основе сходства кода

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

– Клоны типа 1 (T1) представляют собой идентичные фрагменты кода, которые могут содержать различия в пробелах, макетах или комментариях.

– Клоны типа 2 (T2) представляют собой фрагменты кода, допускающие изменения идентификаторов, литералов, типов, пробелов, макетов и комментариев.

– Клоны типа 3 (T3) допускают дополнительные модификации, такие как измененные, добавленные или удаленные инструкции.

– Клоны типа 4 (T4) дополнительно включают семантически эквивалентные, но синтаксически отличающиеся фрагменты кода [8].

В существующих методах обнаружения подобия кода обычно используется модель четырехслойной сетевой структуры. RNN (Recurrent neural network) и CNN (Convolutional neural network) имеют свои преимущества в обработке взаимосвязей данных и извлечении признаков, преимущества которых можно учитывать при разработке новой сетевой структуры.

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

Технология обнаружения уязвимостей на основе сигнатур кода в основном включает в себя два этапа. На этапе обучения поток управления и технология потока данных используются для извлечения ключевых кодов в программе, которые преобразуются в векторные с помощью текущего основного инструмента (такого как word2vec), который вводит их в соответствующие нейронные сети для контролируемого обучения. На этапе обнаружения выполняется та же обработка данных для новой программы, которая используется для обнаружения существующих уязвимостей с помощью изученной модели. В зависимости от того, нужно ли запускать программу, методы обнаружения уязвимостей на основе сигнатур кода подразделяются на методы статического обнаружения и методы динамического обнаружения, сетевые структуры которых, используемые в настоящее время для обучения модели, включают CNN, RNN и LSTM (Long short-term memory) [9].

Статические методы обнаружения

Статический анализ относится к процессу анализа программы путем построения абстрактных синтаксических деревьев и графов зависимостей программы без запуска ПО, анализируемый объект которого обычно относится к исходному коду или исполняемому коду. По сравнению с исполняемым кодом анализ исходного кода позволяет получить больше семантической информации, всесторонне рассматривает информацию о пути выполнения, тем самым обнаруживая больше уязвимостей и повышая процент попаданий [8, 9].

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

Динамические методы обнаружения

Динамический анализ — это процесс проверки или обнаружения уязвимости ПО путем запуска определенной программы и получения информации, такой как выходные данные или внутреннее состояние программы, объектом анализа которой является исполняемый код. По сравнению со статическими методами динамические методы анализируют уязвимости для получения конкретной оперативной информации, поэтому анализируемые уязвимости, как правило, более точны и имеют меньшую частоту ложных срабатываний [9, 10].

Программное средство обнаружения дефектов Aegis

В качестве примера отечественных решений обнаружения программных дефектов представлен Aegis MT. Система Aegis позволяет обнаруживать программные дефекты в последовательных программах. Структурная схема системы Aegis MT приведена на рисунке 5.

Рис. 5. Структурная схема системы обнаружения дефектов Aegis MT

Метод ядра для прогнозирования дефектов

Прогнозирование дефектов ПО является неотъемлемой частью анализа качества ПО и широко изучается в области инженерии надежности ПО.

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

Также в качестве методов уменьшения размерности для проблемы несбалансированности класса с помощью частичных наименьших квадратов (Partial least squares, PLS), линейного дискриминантного анализа (Linear discriminant analysis, LDA) и анализа основных компонентов (Principle component analysis, PCA) [11].

Линейный частичный метод наименьших квадратов PLS является эффективным линейным преобразованием, которое выполняет регрессию на подмножестве извлеченных скрытых переменных. Ядро PLS сначала выполняет нелинейное отображение, Φ: {𝑥𝑖} 𝑛𝑖 = 1∈ R 𝑁 → Φ( 𝑥 ) ∈ F , чтобы проецировать входной вектор в многомерное пространство признаков, в котором используется линейная PLS [12].

Анализ основных компонентов PCA представляет собой эффективное линейное преобразование, которое отображает данные высокой размерности в пространство более низкой размерности. Анализ основных компонентов ядра KPCA сначала выполняет нелинейное отображение Φ (𝑥) для преобразования входного вектора в пространство признаков более высокой размерности. И затем в этом пространстве признаков используется линейный PCA [12].

Недостаток регрессионной модели KPCA заключается в том, что она не учитывает корреляцию между основными компонентами и атрибуцией класса. На уменьшение размерности неизбежно влияет асимметричное распределение. Поэтому для решения проблемы дисбаланса классов может также использоваться асимметричный классификатор анализа главных компонентов ядра (AKPCAC), который извлекает потери, вызванные этим эффектом [12].

Методика распознавания дефектов IGNITE от IBM

Инструментальное приложение IGNITE от IBM использует комплексные когнитивные подходы для сокращения времени обработки дефектов. Оно определяет и классифицирует дефекты программ на основе имеющейся базы знаний. Программа IGNITE использует метод машинного обучения, предварительную обработку текста и моделирование для преобразования и улучшения типичных взаимодействий, переводя их с процесса обнаружения дефектов на предотвращение дефектов. Главное преимущество данного решения заключается в предоставлении тестировщику классификации обнаруженного дефекта в реальном времени на основе существующих сигнатур дефектов. Это улучшает идентификацию первопричины дефекта, что приводит к более быстрому и эффективному его устранению [13].

Заключение

В процессе разработки программных систем общей целью разработчиков ПО является повышение качества и безопасности ПО. Традиционные методы обнаружения требуют, чтобы эксперты в предметной области тратили много времени и энергии на разработку функций, и жизненно важно сочетать технологию глубокого обучения с технологией анализа программ, чтобы помочь исследованиям безопасности ПО и способствовать дальнейшему развитию технологии автоматического обнаружения. В данной статье рассмотрены основные классификации дефектов программ (ODC, RCA, DP, IEEE). Кроме того, рассмотрены и проанализированы основные методики обнаружения и распознавания дефектов программ, основанные на различных подходах к классификации программных ошибок. Так, например, метод распознавания дефектов IGNITE от IBM определяя дефекты программ, использует классификацию из имеющейся базы знаний и сокращает время обработки дефектов. Методы обнаружения дефектов на основе сходства кода, а также статические и динамические методы показывают свою эффективность при работе с сетевыми структурами, включающими RNN, CNN, LSTM. Отечественное решение обнаружения программных дефектов Aegis MT позволяет обнаруживать программные дефекты в последовательных программах. Для прогнозирования дефектов используется метод ядра.

Литература:

1. Sakthi Kumaresh. Defect Analysis and Prevention for Software Process Quality Improvement / Sakthi Kumaresh / International Journal of Computer Applications. — 2010. — № 7 (8). — с. 42–47.
2. Priyanka Chandani, Chetna Gupta. A Survey on Effective Defect Prevention-3T Approach / Priyanka Chandani, Chetna Gupta / I. J. Information Engineering and Electronic Business. — 2014. — № 1. — с. 32–41.
3. S. Kumaresh. Defect Prevention through Orthogonal Defect Classification / S. Kumaresh / International Journal of Computers & Technology. — 2013. — № 3 (11). — с. 2393–2400.
4. Defection Prevention for Software Development [Электронный ресурс] // Process News / Rufina Scott. — URL: http://processnews.blogspot.com/2020/01/software-defect-prevention-nutshell.html.
5. IEEE Standard Classification for Software Anomalies Software & Systems Engineering Standards Committee.
6. Elena N. Akimova, Alexander Yu. Bersenev. A Survey on Software Defect Prediction Using Deep Learning / Elena N. Akimova, Alexander Yu. Bersenev / Mathematics. — 2021. — № 9 (11). — с. 1180.
7. N. Kalaivani, Dr. R. Beena. Overview of Software Defect Prediction using Machine Learning Algorithms / N. Kalaivani, Dr. R. Beena / International Journal of Pure and Applied Mathematics. — 2018. — № 20 (118). — с. 12.
8. Zhidong Shen, Si Chen. A Survey of Automatic Software Vulnerability Detection, Program Repair, and Defect Prediction Techniques / Zhidong Shen, Si Chen / Hindawi. Security and Communication Networks. — 2020. — с. 16.
9. T. Mikolov, M. Karafiát, L. Burget. Recurrent neural network based language model / T. Mikolov, M. Karafiát, L. Burget, et al / Proceedings of the 11th Annual Conference of the International Speech Communication Association, Makuhari. — 2010. — с. 1045–1048.
10. Y. Wang, Z. Wu, Q. Wei. NeuFuzz. Efficient fuzzing with deep neural network / Y. Wang, Z. Wu, Q. Wei, et al / IEEE Access. — 2019. — № 7. — с. 36340–36352.
11. Pooja Paramshetti, D. A. Phalke. Survey on Software Defect Prediction UsingMachine Learning Techniques / Pooja Paramshetti, D. A. Phalke / International Journal of Science and Research (IJSR). — 2014. — № 12(3). — с. 1394–1397.
12. Jinsheng Ren, Ke Qin. On Software Defect Prediction Using Machine Learning / Jinsheng Ren, Ke Qin / Hindawi Publishing Corporation Journal of Applied Mathematics. — 2014. — с. 8.
13. Abhishek Mitra, Ilan S Jayaraman. IBM IGNITE Defect Classify accelerates test using machine intelligence / Abhishek Mitra, Ilan S Jayaraman / IBM Global Business Services. Solution Brief. — 2018. — с. 4.