Помощь студентам в учебе
Применение методов машинного обучения в системах отслеживания ошибок программного обеспечения
|
1. Введение 5
2. Постановка задачи 7
3. Исходные данные 8
4. Обзор существующих работ 9
4.1. Методы оценки точности
5. Используемая методология 12
5.1. Логистическая регрессия
5.2. Наивный байесовский классификатор . . . . . . . . . . . 12
5.3. Машина опорных векторов . . . . . . . . . . . . . . . . . . 13
5.4. Метод ближайших соседей
5.5. Решающие деревья
5.6. Случайный лес
5.7. Методы градиентного бустинга
5.8. Expectation-Maximization
6. Эксперименты 17
6.1. Подготовка данных
6.2. Применение методов машинного обучения . . . . . . . . . 21
6.3. Двухэтапная классификация с использованием подсистем
проекта
6.3.1. Нахождение зависимостей между разработчиками 25
6.3.2. Классификация по подсистемам . . . . . . . . . . 26
6.4. Использование частичного обучения для классификации
по разработчикам . . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Использование векторов вероятностей для улучшения предсказания
6.5.1. Уточнение результата предсказания
6.5.2. Классификатор с неопределенностью
37. Заключение 33
Литература
2. Постановка задачи 7
3. Исходные данные 8
4. Обзор существующих работ 9
4.1. Методы оценки точности
5. Используемая методология 12
5.1. Логистическая регрессия
5.2. Наивный байесовский классификатор . . . . . . . . . . . 12
5.3. Машина опорных векторов . . . . . . . . . . . . . . . . . . 13
5.4. Метод ближайших соседей
5.5. Решающие деревья
5.6. Случайный лес
5.7. Методы градиентного бустинга
5.8. Expectation-Maximization
6. Эксперименты 17
6.1. Подготовка данных
6.2. Применение методов машинного обучения . . . . . . . . . 21
6.3. Двухэтапная классификация с использованием подсистем
проекта
6.3.1. Нахождение зависимостей между разработчиками 25
6.3.2. Классификация по подсистемам . . . . . . . . . . 26
6.4. Использование частичного обучения для классификации
по разработчикам . . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Использование векторов вероятностей для улучшения предсказания
6.5.1. Уточнение результата предсказания
6.5.2. Классификатор с неопределенностью
37. Заключение 33
Литература
При создании современного программного обеспечения зачастую возникает потребность в использовании специальных средств, позволяющих программистам контролировать ход разработки, получать отзывы
от пользователей и поддерживать связь с другими членами команды, особенно в больших распределенных проектах.
Одним из таких средств является система отслеживания ошибок.
Эта система позволяет команде разработчиков учитывать и контролировать ошибки, найденные в ходе эксплуатации программного обеспечения. Каждый, кто имеет доступ к системе, может создать специальный запрос, затем внутри команды этот запрос будет обработан, будет выделен человек или команда, ответственные за решение поставленной задачи или исправление допущенных исключительных ситуаций. Запрос получит уникальный номер, состояние, символизирующее статус работы, и может служить местом обсуждения проблемы внутри команды или между командой разработчиков и пользователем.
В связи с выше сказанным, в системах отслеживания ошибок можно выделить ряд прикладных задач, позволяющих упростить процесс работы создателей программного обеспечения. Один из примеров - задача
объединения сообщений в кластеры для нахождения дубликатов.
Отдельного упоминания заслуживает задача определения ответственного за устранение неисправности, описанной в сообщении. В больших проектах возможны ситуации, когда ежедневно к отслеживанию добавляются тысячи новых ошибок и предложений к улучшению, требующих назначения ответственного. В особенности это касается отчетов об исключительных ситуациях - во многих крупных проектах имеется возможность автоматической отправки такого типа сообщений, из-за чего система отслеживания ошибок будет подвергаться огромной нагрузке. Также стоит отметить, что данные отчеты генерируются автоматически и очень часто не содержат дополнительной информации от пользователя. Ручное определение разработчика в таком случае может занимать еще больший объем времени, даже в случае, если человек, обрабатывающий запросы, обладает достаточными знаниями о всех деталях разрабатываемого программного обеспечения.
Таким образом, можно сделать заключение, что необходима автоматизация данного процесса, позволяющая переложить большую часть работы с разработчика на машину. Методы машинного обучения, позволяющие решать многие задачи классификации и кластеризации, могут быть эффективными и для проблемы классификации отчетов об исключительных ситуациях.
от пользователей и поддерживать связь с другими членами команды, особенно в больших распределенных проектах.
Одним из таких средств является система отслеживания ошибок.
Эта система позволяет команде разработчиков учитывать и контролировать ошибки, найденные в ходе эксплуатации программного обеспечения. Каждый, кто имеет доступ к системе, может создать специальный запрос, затем внутри команды этот запрос будет обработан, будет выделен человек или команда, ответственные за решение поставленной задачи или исправление допущенных исключительных ситуаций. Запрос получит уникальный номер, состояние, символизирующее статус работы, и может служить местом обсуждения проблемы внутри команды или между командой разработчиков и пользователем.
В связи с выше сказанным, в системах отслеживания ошибок можно выделить ряд прикладных задач, позволяющих упростить процесс работы создателей программного обеспечения. Один из примеров - задача
объединения сообщений в кластеры для нахождения дубликатов.
Отдельного упоминания заслуживает задача определения ответственного за устранение неисправности, описанной в сообщении. В больших проектах возможны ситуации, когда ежедневно к отслеживанию добавляются тысячи новых ошибок и предложений к улучшению, требующих назначения ответственного. В особенности это касается отчетов об исключительных ситуациях - во многих крупных проектах имеется возможность автоматической отправки такого типа сообщений, из-за чего система отслеживания ошибок будет подвергаться огромной нагрузке. Также стоит отметить, что данные отчеты генерируются автоматически и очень часто не содержат дополнительной информации от пользователя. Ручное определение разработчика в таком случае может занимать еще больший объем времени, даже в случае, если человек, обрабатывающий запросы, обладает достаточными знаниями о всех деталях разрабатываемого программного обеспечения.
Таким образом, можно сделать заключение, что необходима автоматизация данного процесса, позволяющая переложить большую часть работы с разработчика на машину. Методы машинного обучения, позволяющие решать многие задачи классификации и кластеризации, могут быть эффективными и для проблемы классификации отчетов об исключительных ситуациях.
В данной работе была рассмотрена задача автоматического назначения ответственного за отчет об исключительных ситуациях проекта ReSharper. Были рассмотрены различные способы преобразования данных, была рассмотрена возможность применения различных классификаторов, в том числе и составных. Были проведены сравнение и анализ результатов.
Исходя из полученных данных, был выбран классификатор на основе метода логистической регрессии, реализованного в библиотеке scikitlearn, обладающий лучшими показателями усредненной по всем классам F1-меры, выбранной в качестве оценки точности - при помощи него удалось достичь значения в 0.63. При этом данный классификатор также показал лучшие результаты при измерении процента правильно
предсказанных отчетов - он верно определял разработчика в 74% случаев, что является хорошим результатом в рассматриваемой области (см. Рис. 1), а также новым результатом для более конкретной задачи классификации отчетов об исключительных ситуациях, показывающим, как уточнение области может влиять на способ подготовки данных и применяемые алгоритмы классификации.
На основе данного метода был реализован анализатор, позволяющий определять разработчика, который вероятнее всего ответственен за данный отчет об ошибке. Данный компонент встраивается в сервер,
занимающийся обменом сообщений с системой отслеживания ошибок.
Для уменьшения вероятности выдачи неверного предсказания было добавлено игнорирование результатов предсказания, обладающих недостаточно высокими вероятностными показателями. Это позволило снизить вероятность ошибки до 16% от общего размера тестовой выборки при общем размере количества проигнорированных элементов в 17%.
Также, была добавлена возможность предсказания нескольких наиболее вероятных, по мнению классификатора, разработчиков с их числовыми оценками вероятностей. Так, процент попаданий настоящего
разработчика в список из трех наиболее подходящих для тестовой выборки равен 85%, поэтому данная статистика может использоваться как дополнительная информация для команды разработчиков.
Исходя из полученных данных, был выбран классификатор на основе метода логистической регрессии, реализованного в библиотеке scikitlearn, обладающий лучшими показателями усредненной по всем классам F1-меры, выбранной в качестве оценки точности - при помощи него удалось достичь значения в 0.63. При этом данный классификатор также показал лучшие результаты при измерении процента правильно
предсказанных отчетов - он верно определял разработчика в 74% случаев, что является хорошим результатом в рассматриваемой области (см. Рис. 1), а также новым результатом для более конкретной задачи классификации отчетов об исключительных ситуациях, показывающим, как уточнение области может влиять на способ подготовки данных и применяемые алгоритмы классификации.
На основе данного метода был реализован анализатор, позволяющий определять разработчика, который вероятнее всего ответственен за данный отчет об ошибке. Данный компонент встраивается в сервер,
занимающийся обменом сообщений с системой отслеживания ошибок.
Для уменьшения вероятности выдачи неверного предсказания было добавлено игнорирование результатов предсказания, обладающих недостаточно высокими вероятностными показателями. Это позволило снизить вероятность ошибки до 16% от общего размера тестовой выборки при общем размере количества проигнорированных элементов в 17%.
Также, была добавлена возможность предсказания нескольких наиболее вероятных, по мнению классификатора, разработчиков с их числовыми оценками вероятностей. Так, процент попаданий настоящего
разработчика в список из трех наиболее подходящих для тестовой выборки равен 85%, поэтому данная статистика может использоваться как дополнительная информация для команды разработчиков.
Подобные работы
- Математическое и программное обеспечение для индексации графических файлов с помощью метода сегментации KMCC и нечеткого классификатора текстур
Магистерская диссертация, информатика. Язык работы: Русский. Цена: 5900 р. Год сдачи: 2016 - РАЗРАБОТКА АЛГОРИТМА И РЕАЛИЗАЦИЯ ПРОГРАММНОГО МОДУЛЯ
ОБРАБОТКИ ВИДЕОДАННЫХ ДЛЯ РАСПОЗНАВАНИЯ ДОРОЖНОЙ
РАЗМЕТКИ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ
Магистерская диссертация, информатика. Язык работы: Русский. Цена: 5750 р. Год сдачи: 2018 - Управление инновационными проектами в территориально-отраслевых
кластерах
Дипломные работы, ВКР, менеджмент. Язык работы: Русский. Цена: 4850 р. Год сдачи: 2017 - Методическое обеспечение стенда: «Исследование многоуровневой безопасности встраиваемых систем»
Дипломные работы, ВКР, информационная безопасность. Язык работы: Русский. Цена: 4295 р. Год сдачи: 2018