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

Как это там… «Устроены так люди… Желают знать что будет…» Вот и в отношении дефектов в ПО тоже самое. Определённо, любой менеджер хотел бы знать где дефекты, до того как они себя проявят, но лень и отсутствие доступных решений оставляют его наедине с традиционными подходами управления.

Уже очень долго умные дяди и тёти в больших западных университетах развивают тему прогнозирования дефектов в ПО. И это не так бесполезно как может показаться на первый взгляд. Основная задача — с удовлетворительной точностью сказать где будут дефекты после выпуска новой версии. Как можно использовать такое знание? Например для распределения ресурсов тестирования. Если до выпуска новой версии нам известно где дефекты, то логично потратить оставшееся время на тестирование тех компонентов, в которых эти дефекты есть. Ещё одна возможность — корректировка сроков выхода новой версии. Если нам известно число необнаруженных дефектов, то можно поставить цель продолжать тестирование до тех пор пока это число не снизиться до приемлемых показателей. На деле всё несколько сложнее. Даже зная список компонентов, в которых остались дефекты не всегда можно безболезненно ограничить тестирование кругом этих компонентов. А если Вы предложите отложить дату релиза основываясь на каких-то там метриках, то скорее всего будете непоняты.

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

Но вот что печально, так это то, что за все эти годы все эти «достижения» так и не дошли до тех, для кого они по идее предназначались, до разработчиков. Отчасти потому что это не особо нужно самим разработчикам. Отчасти потому что в деле прогнозирования дефектов всё не так благополучно как представляют некоторые товарищи. Основные проблемы: инструментальная и измерительная. Суть инструментальной проблемы в отсутствии программных средств прогнозирования, которые могли бы быть применены простыми инженерами в различных окружениях. Большинство исследователей не утруждает себя созданием инструментальных средств. Они выдают публикации и на этом успокаиваются. А если и появляется какое-то инструментальное средство, то в лучшем случае это набор скриптов для Perl или плагин для Eclipse работающий только с программами на языке Java, а в худшем — это целый стек программ включающий утилиты машинного обучения и что-нибудь проприетарное вроде MATLAB. В таких условиях не то что использование для своих нужд, даже повторение чужого эксперимента становится задачей на отдельную диссертацию… Вторая проблема — измерительная. В общем, является следствием первой. Нет инструментальных средств — нечем мерить метрики. Точнее средств измерения метрик хватает, но они не предназначены для прогнозирования дефектов. Для исследовательских задач вообще не обязательно чего-то там мерить. Можно просто взять готовые данные опубликованные NASA или из репозитория PROMISE. Вот только это не решает проблему прогнозирования для реальных проектов.

В MSR Tools реализованы относительно простые модели прогнозирования дефектов, которые работают на основе информации полученной из системы контроля версий. Эти модели могут быть применены к любым программам вне зависимости от языка программирования, на котором они написаны, т.к. не используют ни метрик зависимых от парадигмы языка (объектно-ориентированные метрики и т.п.), ни метрик требующих парсинга конструкций языка (цикломатическая сложность и т.п.). В следующий раз перейдём непосредственно к практике.

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

  1. Александр говорит:

    Если разработчик этих MSR Tools решит портировать свое детище под linux , то имя пакета msr-tools там уже занято для совершенно другого софта =)

    • Semyon Kirnosenko говорит:

      Да я в курсе уже! Забавно что с sourceforge большинство скачиваний идёт с mac’ов. Народ видимо даже описание не читает :)

  2. Эдуард говорит:

    А где можно почитать про модели прогнозирования дефектов?

    • Semyon Kirnosenko говорит:

      Могу порекомендовать гуглить на тему «software defect prediction». К Вашим услугам десятки англоязычных публикаций. На русском языке практически ничего нет. Разве что пара фундаментальных трудов:
      Майерс Г. Надёжность программного обеспечения, 1980
      Тейер Т. Надёжность программного обеспечения, 1981
      но они малость устарели.

  3. LeshaL говорит:

    Основная задача – с удовлетворительной точностью сказать где будут дефекты после выпуска новой версии.
    Да ладно! Кому это надо после того как что-то выпустили?

    • Semyon Kirnosenko говорит:

      Вы не поняли. …сказать где будут дефекты после релиза, но сказать это до самого релиза!

      • Эдуард говорит:

        Ха, тогда это будет уже не тот релиз. Это называется «эффект бабочки», помните у Рея Бредбери. Так и здесь, предскажешь ошибки в будущем релизе — изменишь сам релиз. :)

        • Semyon Kirnosenko говорит:

          >> предскажешь ошибки в будущем релизе – изменишь сам релиз

          Дык, к этому и стремимся!