Встроенная скорость дефекта программного обеспечения

Question

Какую скорость дефекта я могу ожидать в C ++ CodeBase, которая написана для встроенного процессора (DSP), учитывая, что не было никаких модульных тестов, никаких обзоров кода, без анализа статического кода, и которые составляют проект, генерируют около 1500 предупреждений. 5 дефектов / 100 строк кода разумной оценки?

Answer 1

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

В эта статья, автор цитирует цифры из «большого тела эмпирических исследований», опубликованных в Оценка программного обеспечения, ориентиры и лучшие практики (Джонс, 2000). Отказ В Sie CMM Уровень 1, который звучит как уровень этого кода, можно ожидать, что скорость дефекта 0,75 за функциональная точка. Отказ Я оставлю это тебе, чтобы определить, как Функциональные точки и loc может относиться в вашем коде - вам, вероятно, понадобится Инструмент метрики выполнить этот анализ.

Стив Макконнелл в Code Complete цитирует исследование Из 11 проектов, разработанных той же командой, 5 без кода отзывы, 6 с кодом отзывы. Уровень дефекта для неперезмашенного кода составлял 4,5 на 100 акций, а для рассмотрения было 0,82. Так что на этой основе ваша оценка кажется справедливой в отсутствие какой-либо другой информации. Однако я должен взять на себя уровень профессионализма среди этой команды (только от того, что они почувствовали необходимость выполнять исследование), и что они по крайней мере присутствуют на предупреждениях; Ваш уровень дефекта может быть намного выше.

Точка о предупреждениях заключается в том, что некоторые являются доброкачественными, а некоторые ошибки (т. Е. приведут к нежелательному поведению программного обеспечения), если вы игнорируете их на предположение, что все они доброкачественные, вы введете ошибки. Более того, некоторые воли стали Ошибки по техническому обслуживанию, когда другие условия меняются, но если вы уже решили принять предупреждение, у вас нет защиты от внедрения таких ошибок.

Answer 2

Ваш вопрос: «5 дефектов / 100 строк кода разумная оценка?» Этот вопрос чрезвычайно трудно ответить, и он сильно зависит от сложности кодовой базы и кода.

Вы также упомянули в комментарии «Чтобы показать руководство, которое, вероятно, есть много ошибок в кодовой базе» - это здорово, kudos, прямо на.

Для того, чтобы открыть переносные глаза управления, я бы предложил по крайней мере 3-х горный подход:

• Примите конкретные предупреждения о компиляторе, и покажите, как некоторые из них могут вызвать неопределенное / катастрофическое поведение. Не все предупреждения будут как весомые. Например, если у вас есть кто-то, использующий неинициализированный указатель, это чистое золото. Если у вас есть кто-то начисляя 16-битное значение unsigned, в 8-битное значение без знака, и его можно показать, что 16-битное значение всегда будет <= 255, что никто не поможет сделать ваше дело так же сильно.
• Запустите статический инструмент анализа. ПК-ЛИНТ (или FlexeLint) дешево и обеспечивает хороший «взрыв для доллара». Он почти наверняка поймает, что компилятор не будет, и он также может проходить через переводные единицы (пересекает все вместе с 2 или более пропусками) и найти более тонкие ошибки. Опять же, используйте некоторые из них как показания.
• Запустите инструмент, который даст другие метрики на сложность кода, другой источник ошибок. Я бы порекомендовал M Ресурс в квадрате стандартные метрики (RSM) который даст вам дополнительную информацию и метрики (включая сложность кода), чем вы можете надеяться. Когда вы скажете руководство, что Оценка сложности более 50 является «в основном беспорядок» И у вас есть счет 200 в одной рутине, что должно открыть глаза.

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

Но важный момент, который я хочу сделать, это: Будьте очень осторожны при переходе и крепежных предупреждений компилятора и линта. Отказ Это замечательная цель, но вы также можете случайно сломать рабочий код, а / или раскрыть неопределенное поведение, которое случайно работало в «сломанном» коде. Да, это действительно происходит. Так что течь осторожно.

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

Удачи!

Answer 3

Посмотрите на качество кода. Это быстро даст вам указание о количестве проблем, скрывающихся в источнике. Если источник некрасиво и займет много времени, чтобы понять, что в коде будет много ошибок.

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

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

Answer 4

Это также зависит от того, кто написал код (уровень опыта) и насколько большой код кодовой базы.

Я бы относился все предупреждения как ошибки.

Сколько ошибок вы получаете, когда вы запускаете инструмент статического анализа в коде?

РЕДАКТИРОВАТЬ

Запустите CCCC и проверьте циклическую сложность MCCABE. Это должно сказать, насколько сложна код.

http://sourceforge.net/projects/cccc/

Запустите другие инструменты статического анализа.

Answer 5

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

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

Answer 6

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

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

Answer 7

Следующая статья имеет некоторые числа, основанные на реальных проектах, к которым статический анализ был применен к: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html.

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