Что является Лучшим для Отслеживания Скорости дефектообразования? Дефекты на KLOC?

You may also consider mapping defect discovery rate and defect resolution rates... how long does it take to find bugs, and once they're found, how long do they take to fix? To my knowledge, TDD is supposed to improve on fix times because it makes defects known earlier... right?

Any measure is an arbitrary comparison of defects to code size; so long as the comparison is similar, it should work. E.g., defects/kloc in C to defects/kloc in C. If you changed languages, it would affect the metric in any case, since the same program in another language might be less defect-prone.

Измерение дефектов - непростая задача. Хотелось бы учесть сложность кода, но это невероятно запутано и неприятно. При измерении качества кода я рекомендую:

1. Измерить текущее состояние (какова ваша частота дефектов сейчас)
2. Внести изменения (экспертные оценки, обучение, рекомендации по кодам и т. Д.)
3. Измерить новую частоту дефектов (Есть вещи улучшено?)
4. Goto 2

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

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

I suggest to use the ratio between the times :

1. the time spend fixing bugs
2. the time spend writing other codes

This seem valid across languages...

It also works if you only have a rough estimation of some big code base. You can still compare it to the new code you are writing, to impress you management ;-)

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

В интересах управления проектом я бы измерил следующее:

• Количество открытых дефектов в проекте. Не существует единого скаляра, который мог бы сказать вам, где находится проект и насколько он близок к готовому к выпуску состоянию, но это по-прежнему удобное число, которое нужно иметь под рукой и следить за временем.
• Уровень обнаружения дефектов. Это не скорость появления новых дефектов в системе, но это, вероятно, ближайший показатель, который вы найдете.
• Скорость устранения дефектов. Если это меньше, чем уровень обнаружения, вы отстаете - если оно больше, вы впереди.

Все эти числа будут более полезными, если вы объедините их с информацией о степени серьезности. Продукт с 20 незначительными ошибками может быть ближе к выпуску, чем продукт с двумя сбойными ошибками. Если вы устраняете мелкие, но не серьезные ошибки, вы должны заставить разработчиков переориентировать свое внимание.

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

Вы также можете пометить все заявки в вашей системе отслеживания дефектов с помощью модуль проекта (особенно для крупных проектов),

Почему вы не учитываете дефекты для каждого варианта использования? или дефекты по требованию. Прибыв в KLOC, мы столкнулись с практическими проблемами.