Применение методов исследования данных (data science) стало практически обязательным для успеха современного бизнеса. Это в полной мере относится и к программной инженерии: здесь такие методы применяют для анализа кода и особенностей процесса разработки, чтобы улучшить характеристики продукта. Данный аспект важен в связи с усложнением ПО и распространением встроенных систем, Интернета вещей и самоуправляемых автомобилей. Рост сложности, с одной стороны, означает повышение функциональности и внедрение ускоренных моделей разработки, благодаря которым появляется в том числе возможность быстрого учета требований конкретного клиента. С другой — растет технологический долг компаний, что может привести к снижению продуктивности и качества. В то же время в рамках проектов разработки ПО накапливаются все более обширные и разнообразные наборы данных: отчеты по использованию функционала, анализу кода и тестовому покрытию, журналы ошибок, сведения об обслуживании и пр. С ростом объемов таких данных извлекать из них полезную информацию становится все труднее.
Рост применения встроенного ПО и усиление его важности в жизни общества требуют гарантий точного соответствия работы таких систем их назначению и отсутствия отказов. Дефекты в программах наносят вред деловой репутации, заставляют расходовать дополнительные ресурсы на сопровождение и снижают лояльность клиентов, а дефекты системы, работающей в реальном времени, могут создавать непосредственную угрозу здоровью и жизни людей, поэтому тут предельно важны надежность и качество.
Независимо от сферы применения программных систем, все они неуклонно усложняются, и важную роль в управлении сложностью программных продуктов и процессов разработки отводят оценке характеристик ПО [1]. Современные подходы к разработке, характерные для парадигм Agile и DevOps, расширяют возможности, связанные с получением огромных объемов данных за малое время, обучением на этих данных и обменом полученными знаниями между проектами. Однако без средств автоматизации невозможно разобраться в огромных массивах доступных данных и учесть все их взаимозависимости.
Сегодня дисциплина измерения характеристик ПО берет на вооружение методы исследования данных, включая технологии работы с большими данными и алгоритмы машинного обучения [1, 2]. Для поддержки таких методов существует множество коммерческих и открытых инструментов и платформ, однако работа с ними требует специальных знаний, в том числе о применимости разных методов в каждом конкретном случае, а также о принципах анализа и оценки данных.
На примерах управления качеством и автоматической обработки отчетов об анализе кода покажем преимущества, получаемые разработчиками ПО при использовании методов исследования данных.
Основные этапы добычи данных
Междисциплинарная область исследования данных требует глубоких знаний в области информатики и прикладной математики [3], необходимых для применения методов систематического сбора и быстрой обработки больших данных различной структуры. Подробное описание науки о данных и соответствующих компетенций можно найти в спецификации Edison Data Science Framework (EDSF), согласно которой исследователь данных должен понимать потребности бизнеса, обладать аналитическими навыками, а также теоретическими и практическими знаниями в области программирования и системной инженерии, чтобы на всех этапах жизненного цикла больших данных применять и совершенствовать методы, обеспечивающие получение результатов, необходимых организации или проекту.
Один из важнейших навыков специалиста — умение строить и объективно оценивать модели. Соответствующий фактический стандарт, широко применяемый в исследовательской и коммерческой среде, — Cross-Industry Standard Process for Data Mining (CRISP-DM) — описывает шесть основных этапов добычи данных:
1) понимание бизнеса (ориентирование в бизнес-задачах организации, определение целей анализа и создание плана проекта);
2) понимание данных (сбор, оценка характеристик и сути данных, анализ качества доступных данных);
3) подготовка данных (выбор данных для анализа, их очистка и форматирование);
4) моделирование (выбор оптимального метода построения модели, создание модели и анализ ее качества);
5) оценка (контроль, интерпретация результатов и выбор дальнейших действий);
6) развертывание (планирование развертывания и сопровождения модели; документирование результатов и выводов).
Перечисленные этапы могут выполняться итеративно с возможностью возврата к предыдущим шагам и их повторения.
Управление качеством на основе данных
Рис. 1. Архитектура фреймворка Q-Rapids |
Задача европейского проекта Q-Rapids — разработка методов повышения качества ПО с использованием данных как собственно по продукту, так и по процессам его разработки и применения. В архитектуре Q-Rapids (рис. 1) предусматривается масштабируемый механизм получения информации из различных источников и обеспечивается взаимодействие с фреймворками анализа данных для построения модели качества и формирования рекомендаций лицам, принимающим решения. Например, специалисты могут получать предупреждения о выявленных или прогнозируемых проблемах качества ПО и предложения по его улучшению. Фреймворк Q-Rapids позволил лучше управлять качеством программной платформы, поддерживающей цифровые сервисы для жителей из сельской местности: интернет-магазин, информационный портал, каршеринг и др.
Рассмотрим, как происходит управление качеством согласно CRISP-DM.
Понимание бизнеса. Программную платформу Q-Rapids можно было существенно улучшить, анализируя данные, накапливаемые в ходе эксплуатации. При этом ставилась задача выделить факторы, влияющие в ходе разработки на эксплуатационное качество ПО, и научиться прогнозировать потенциальные проблемы. Цель — минимизация ресурсов, требуемых для обработки поступающих в ходе эксплуатации данных.
Понимание данных. Решить перечисленные задачи предполагалось с использованием имеющихся внешних данных (журналов доступа и ошибок, сведений о непредвиденных завершениях приложений, информации о дефектах), полученных службой поддержки, и внутренних данных (показателей качества кода, сведений о нарушениях правил контроля качества, исправлений в коде). Для приема информации в реальном времени в Q -Rapids применяли коннекторы Apache (рис. 1). Был создан центральный репозиторий с данными всех типов, в том числе по использованию (сведения об аварийных завершениях и журналы работы мобильных приложений). После этого провели анализ, позволивший определить, какие из собранных данных подходили для решения стоявших задач.
Подготовка данных. Данные, хранимые в различных системах-источниках, были интегрированы при одновременном улучшении их качества (в случае неполных, несогласованных и неверных данных) и преобразованы в форматы, оптимальные для аналитической обработки.
Моделирование. На этом этапе стояла задача найти оптимальную модель надежности ПО. Были задействованы методы на основе ансамблей — «случайный лес» и экстремальный градиентный бустинг, c помощью которых оценивали связь между вероятностью наличия ошибок в ПО, проявляющихся в период выполнения, структурными особенностями кода, характеристиками и объемом вносимых изменений. В результате были получены оценки релевантности ряда метрик в качестве предикатов внешнего качества и построена модель качества, выражающая зависимости между самыми релевантными метриками и внешним качеством программного продукта.
Оценка. В ходе оценки были подтверждены возможности формирования обзора системных сбоев и исключений в зависимости от времени и прогноза отказов по результатам анализа показателей внутреннего качества ПО.
Развертывание. Разработанные модели были встроены в Q-Rapids, с тем чтобы разработчики могли получать прогнозы изменения внешнего качества и сведения о том, какие факторы оказывают на него наибольшее влияние.
Приоритизация результатов анализа кода
Для повышения качества ПО в организациях все шире применяются инструменты анализа кода. В частности, в конвейеры Jenkins встраиваются механизмы статического анализа, выполняющие строгую проверку вносимых в код изменений. Для критичного к безопасности ПО статический анализ кода обязателен, но соответствующие инструменты весьма сложны как в применении, так и с точки зрения интерпретации предоставляемых ими результатов — использовать их без помощи квалифицированных специалистов практически невозможно. К тому же разработчикам приходится иметь дело с множеством отчетов, подавляющая часть информации в которых не нужна. Автоматизированные инструменты генерируют слишком много ложноположительных результатов, а кроме того, приходится одновременно использовать сразу несколько систем. Как следствие, после ряда попыток в компаниях нередко просто прекращают использовать подобные средства ввиду их чрезмерной сложности. В связи с этим некоторые поставщики услуг даже специализируются на различных средствах анализа кода и выполняют для клиентов необходимую обработку данных.
Понимание бизнеса. Обнаружение дефектов кода на ранних этапах разработки ПО позволяет уменьшить затраты и повысить качество кода за счет уменьшения технологического долга и предотвращения перехода ошибок на последующие этапы жизненного цикла [1]. По статистике, 40–60% дефектов приходятся на 20–30% кода. При этом показано, что внедрение статического анализа кода ведет к уменьшению количества отказов ПО после выпуска более чем на 50%, благодаря чему затраты на разработку снижаются на 20–30% [1]. Это не отменяет необходимости проведения других этапов верификации и валидации, но позволяет устранить дефекты определенного рода, которые иным образом не обнаруживаются. Однако в отчетах, генерируемых различными средствами статического анализа кода, дефекты перечисляются не по степени критичности соответствующих программных модулей, а в порядке, соответствующем закодированным приоритетам.
Главная задача, стоявшая в данном проекте, — обеспечить приоритизацию дефектов с учетом критичности программных модулей. Эта проблема требует решения в связи с тем, что руководители проектов нередко затрудняются с выбором направлений основных усилий по улучшению качества программного продукта.
Понимание данных. Как правило, для обучения соответствующего классификатора данных хватает с избытком: показатели цикломатической сложности кода; история изменения модулей, в том числе показатели динамики темпов модификации, удаления фрагментов и внесения новых; показатели повторного использования кода, импортируемого в разные модули; метрики, фиксирующие процесс разработки ПО.
Подготовка данных. Для проверки концепции было проведено обучение прогнозных моделей с использованием метрик кода и истории изменений. Начальное обучение классификаторов выполняли на основе показателей сложности кода и истории изменений систем реального времени из репозитория Promise.
Рис. 2. Признаки и метки для обучающего набора данных, результативность работы классификаторов критичности* LOC (lines of code) — число строк кода |
Моделирование. Используя прогнозы критичности модулей и сведения о плотности дефектов в модуле, реализованный метод ранжирует ошибки по степени приоритетности. Оценка критичности выполняется при помощи классификатора, сгенерированного с использованием предварительно обученного алгоритма. Признаки для обучения выбирались из показателей, полученных от инструментов автоматизированной оценки кода. Признаки и метки, использованные для обучения, перечислены в верхней части рис. 2. На основе этих наборов данных и четырех различных алгоритмов было проведено обучение двух классификаторов. Оценка результативности позволила выбрать оптимальный алгоритм для каждого типа данных.
Оценка. При оценке учитывались следующие показатели: точность обучения, точность прогнозирования и площадь под ROC-кривой. В нижней части рис. 2 показаны результаты и лучший алгоритм для каждого набора данных.
Развертывание. После выбора алгоритма и обучения классификатора критичности, на основе полученных прогнозов формируется рейтинг модулей. Поскольку используются две модели прогнозирования с двоичным результатом («критичный», «некритичный»), возможны четыре сочетания прогнозов, которым поставили в соответствие индекс критичности от 1 (максимум) до 4 (минимум). Классификатору с более высокой точностью прогнозирования и большей площадью под ROC-кривой присвоили более высокий индекс критичности. Алгоритм ранжирования вначале извлекает метрики кода из отчетов и истории изменений для каждого модуля в системе управления версиями. Каждый полученный таким образом вектор признаков подавался на вход соответствующего классификатора для получения прогнозов. Сочетанию прогнозов, полученных для каждого модуля, назначался фактор критичности согласно предварительно описанным критериям. Затем модули сортировались по фактору критичности.
Итак, методы исследования данных могут с успехом применяться в программной инженерии. В таблице перечислены основные выводы, отсортированные по стадиям из стандарта CRISP-DM. Исследование и аналитическая обработка данных обеспечивают существенные преимущества по сравнению с классическими методами измерения ПО. Но не следует забывать, что средства аналитики бесполезны, если у применяющих их специалистов отсутствует понимание бизнеса и сущности данных. Суть использования науки о данных в программной инженерии состоит не в применении алгоритмов машинного обучения к очищенным наборам данных — помимо этого, необходимо определить четкие цели в соответствии с пониманием бизнеса и данных, а также обеспечить релевантность и качество информации. Без этого не будет гарантии получения полезных аналитических сведений. В рамках проектов разработки ПО формируются огромные объемы данных, но в чистом виде они вряд ли смогут стать фундаментом для построения моделей аналитики и прогнозирования.
Применение науки о данных в программной инженерии требует навыков вне этой области, в том числе в сфере статистики и построения алгоритмов, поэтому руководителям проектов лучше сотрудничать со специалистами по исследованию данных и консультантами, специализирующимися в соответствующих областях. Они помогут с решением многих задач, таких как: определение сценариев применения и уточнение преимуществ data science, больших данных и искусственного интеллекта в контексте инженерии ПО и проектирования систем (в том числе с точки зрения повышения качества и управления рисками); получение и хранение метрик периода разработки и выполнения, анализ качества данных, подготовка данных (репозиториев ПО, журналов и др.); анализ результатов измерений, моделирование, применение методов ИИ (машинное обучение, нейронные сети); создание инструментов сбора, хранения, анализа и визуализации больших данных, построения моделей ИИ; подготовка рекомендаций в области этики и культуры данных, обмена данными, безопасности и оценки моделей.
***
Герберт Саймон, один из пионеров в области искусственного интеллекта, утверждал, что избыток информации приводит к дефициту внимания. Именно ему принадлежит идея о том, что исследование данных требует фокусировки на самом важном — сущности данных, «сюжете», который они описывают. Тому же принципу стоит следовать и в программной инженерии. Вместо того чтобы увеличивать объемы данных и путаться из-за растущего уровня сложности ПО, лучше абстрагироваться и прибегнуть к помощи анализа, задавшись целью улучшения качества.
Литература
1. C. Ebert, R. Dumke. Software Measurement. Springer, Heidelberg, Germany, 2007.
2. J. Heidrich, A. Trendowicz, C. Ebert. Exploiting data’s benefits // IEEE Softw. — 2016 (July). — vol. 33, N. 4. — P. 111–116.
3. D. Conway. The data science Venn diagram. Drew Conway Data Consulting, 2015. [Online]. URL: http://drewconway.com/zia/2013/3/26/the-data-science-venn-diagram (дата обращения: 08.03.2020).
Кристофер Эберт (christof.ebert@vector.com) — член редакционного совета IEEE Software; Йенс Хейдрих (ens.heidrich@iese.fraunhofer.de) — руководитель подразделения, Сильверио Мартинес-Фернандес (ilverio.martinez@iese.fraunhofer.de) — научный сотрудник, Адам Трендович (dam.trendowicz@iese.fraunhofer.de ) — старший консультант, Институт экспериментальной программной инженерии им. Фраунгофера.
Christof Ebert, Jens Heidrich, Silverio Martinez-Fernandez, Adam Trendowicz, Data Science: Technologies for Better Software, IEEE Software, November/December 2019, IEEE Computer Society. All rights reserved. Reprinted with permission.