Прогнозирование дефектов в программном обеспечении (часть 3)

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

Итак, возвращаемся к утилите MSR.Tools.Predictor. Открываем файл настроек для нашего проекта. Я снова использую общедоступные данные для проекта gnome-terminal. Выберем несколько старых версий и например модель Simple total LOC model, выполним расчёт для них через команду меню «Command/Predict». Никаких опций на этот раз менять не нужно, всё уже выставлено. Пункт меню «View/Show files» не отмечен, т.к. нас интересует не то какие файлы содержат дефекты в соответствии с прогнозом, а то насколько прогноз оказался точен. Пункты меню «View/Evaluate» и «View/Evaluate using ROC» отмечены. Увидим примерно следующую картину.

Можно видеть, что для версии 2.0 с использованием Simple total LOC model мы получили прогноз, точность которого оценена набором различных метрик.

Фактически модель прогнозирования дефектов является бинарным классификатором, т.к. ставит в соответствие каждому файлу оценку: содержит дефекты/не содержит дефекты. Как следствие, классификатор может совершать ошибки первого и второго рода. На основе данных о количестве таких ошибок можно посчитать метрики Precision и Recall. Не знаю подходящего перевода на русский. Кто знает подскажите! Эти две метрики характеризующие точность прогноза наиболее просты для интерпретации. Для вышеприведённого прогноза Precision равен 0,94 а Recall равен 0,40. Это означает, что выборка файлов, которые в соответствии с прогнозом считались содержащими необнаруженные дефекты, на самом деле состояла из таковых на 94%. Из всех файлов оказавшихся дефектными в выборку попало 40%. Результат в данном случае — так себе. Чтобы результат считался хорошим нужно чтобы обе эти метрики были не ниже 0,7. Хотя могут быть и исключения в зависимости от того для каких целей предполагается использовать прогноз. Метрика NegPos является отношением числа недефектных файлов к числу дефектных для данной версии. Accuracy — более общая метрика точности прогноза. Вся первая строка относится к простой проверке точности прогноза.

А где есть простая проверка там есть и сложная. В данном случае сложной является оценка точности прогноза посредством построения ROC-кривой и вычисления площади под ней AUC. Если считать, что наш классификатор каждому файлу ставит в соответствие некоторую оценку, которая тем больше чем больше вероятность наличия в файле необнаруженных дефектов, то AUC есть вероятность того, что случайным образом взятый дефектный файл получит оценку выше чем случайным образом взятый недефектный файл. Для идеального классификатора, который не допускает ошибок AUC = 1. Для случайной равновероятной выборки — AUC = 0,5. MaxPoint и BalancePoint — пара «оптимальных» порогов отсечения. Для «понимающих» есть возможность посмотреть непосредственно на ROC-кривую с кривыми «чувствительности» и «специфичности» через меню «Command/Show ROC for».

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