Эксперименты, коррелирующие метрики кода с плотностью ошибок

Мне интересно, проводил ли кто-нибудь эксперименты, связывающие метрики кода (SLOC, Cyclomatic Complexity и т. Д.) С плотностью ошибок в объектно-ориентированных приложениях.

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

Моя цель состоит в том, чтобы

1. Измерьте все интересные метрики за 2-3 месяца (у нас уже немало от сонара).
2. Найдите один показатель, который коррелирует с количеством новых ошибок.
3. Проведите анализ основных причин, чтобы проверить, почему это происходит (например, не хватает ли у нас определенных навыков проектирования?).
4. Улучшите навык и измерьте изменение за пару итераций.
5. Промыть и повторить с 2.

Если у вас нет опыта в этом вопросе, но вы помните, что читали статью / блог на эту тему, я был бы признателен, если бы вы могли поделиться этим.

До сих пор я нашел следующие ссылки с некоторой информацией по этому вопросу

• Находятся ли ошибки в сложном коде? - просто слайды из презентации.
• Изменения и ошибки: разработка и прогнозирование деятельности по разработке - просто слайды из презентации. В итоге, чем больше зависимостей, тем выше вероятность ошибок (я думаю, что это довольно общее правило).
• Отказ - это четырехбуквенное слово - парад о корреляции между ошибками и метриками.

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

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

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

Существует также группа показателей, известных как CK Metrics. Первое определение этого набора метрик, по-видимому, содержится в статье под названием «Набор метрик для объектно-ориентированного проектирования» Чидамбера и Кемерера. Они определяют взвешенные методы для каждого класса, глубину дерева наследования, количество дочерних элементов, связь между классами объектов, реакцию на класс и отсутствие единства в методах. Их статья предоставляет вычислительные методы, а также описание того, как анализировать каждый из них.

С точки зрения академической литературы, которая анализирует эти метрики, вас может заинтересовать эмпирический анализ метрик CK для объектно-ориентированной сложности проектирования: последствия для дефектов программного обеспечения, автором которых являются Раманат Субраманьям и М.С. Кришна. Они проанализировали три из шести метрик CK (взвешенные методы на класс, связь между классифицируемым объектом и глубиной дерева наследования). Просматривая статью, выясняется, что они обнаружили, что это потенциально допустимые показатели, но их следует осторожно интерпретировать как «улучшение», которое может привести к другим изменениям, которые также приводят к большей вероятности появления дефектов.

Эмпирический анализ объектно-ориентированных проектных метрик для прогнозирования сбоев высокой и низкой серьезности, автором которых являются Юминг Чжоу и Харетон Леунг, также исследует метрики CK. Их подход состоял в том, чтобы определить, могут ли они прогнозировать дефекты на основе этих метрик. Они обнаружили, что многие метрики CK, за исключением дерева глубины наследования и числа детей), имели некоторый уровень статистической значимости в прогнозировании областей, в которых могут быть обнаружены дефекты.

Если у вас есть членство в IEEE, я бы порекомендовал поискать в « Транзакциях IEEE по программной инженерии» больше научных публикаций, а в « IEEE Software» - несколько более реальных и прикладных отчетов. ACM может также иметь соответствующие публикации в своей цифровой библиотеке .

Я обсуждал возможные корреляции в одном из моих постов в блоге :

Корреляция между цикломатической сложностью и плотностью ошибок: действительно ли это проблема?

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

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

Второй вопрос: сильно ли коррелирует CC с коэффициентом обратной связи по неисправностям (FFR, среднее число дефектов, возникающих в результате применения одного изменения или исправления одного дефекта)?

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

Это хороший эксперимент, чтобы сделать. Будьте в курсе результатов!

В книге Code Complete, стр.457, Стив Макконнелл говорит, что «сложность потока управления важна, потому что он коррелирует с низкой надежностью и частыми ошибками». Затем он упоминает несколько ссылок, поддерживающих эту корреляцию, включая самого МакКейба (которому приписывают разработку метрики цикломатической сложности). Большинство из них предшествуют широкому использованию объектно-ориентированных языков, но поскольку этот показатель применяется к методам в этих языках, ссылки могут быть тем, что вы ищете.

Эти ссылки:

• МакКейб, Том. 1976. «Мера сложности». IEEE Транзакции по программной инженерии, SE-2, нет. 4 (декабрь): 308-20
• Shen, Vincent Y., et al. 1985. «Определение подверженного ошибкам программного обеспечения - эмпирическое исследование». Операции IEEE по программной инженерии SE-11, № 4 (апрель): 317-24.
• Уорд, Уильям Т., 1989. «Предотвращение дефектов программного обеспечения с использованием показателя сложности McCabe». Hewlett-Packard Journal, апрель, 64-68.

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