Плотность ошибок и её трактовка

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

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

Для конечного же пользователя качество ПО — это степень безотказного удовлетворения его потребностей. Ему важны только две вещи. Чтобы программа делала то, что нужно и делала это правильно. Ему плевать сколько в программе строк кода, какова его сложность, связность и прочее. И для конечного пользователя плотность ошибок — единственная и по сути безальтернативная метрика качества.

Всё это объясняет тот факт, что на сегодняшний день плотность ошибок — наиболее распространённая метрика для измерения качества ПО и кода. Это, разумеется, не означает, что метрика эта всем хороша. Просто ничего лучше пока не придумали.

Проблемы трактовки плотности ошибок обычно сводятся к вопросам о получении качественных и сравнительных оценок. Если получена конкретная метрика плотности ошибок появляется естественный вопрос хороша она или плоха. Сегодня типичными можно считать показатели в 1-5 дефектов на 1000 строк кода. Соответственно если в Вашем проекте примерно столько и есть — то продолжайте в том же духе, если меньше — можете собой гордиться, если больше — возможно настало время разобраться в чём проблема. А проблема может заключаться в унаследованном коде, который слишком плох; в подсистеме, которая слишком сложна; в человеке, который слишком некомпетентен и т.д.

Давать сравнительные оценки следует учитывая контекст. Нельзя просто взять и сказать, что если плотность ошибок для кода программиста А меньше в два раза чем для кода программиста Б, это означает, что программист А ровно в два раз «лучше» программиста Б. На результирующую плотность ошибок оказывает влияние множество факторов. Самые существенные из них: квалификация программиста и сложность кода, над которым он работает. Соответственно если Ваш процесс поставлен так, что при распределении задач не учитывается квалификация программистов, тогда можно использовать плотность ошибок для сравнительной оценки качества их работы. Сравнение плотности ошибок внутри проекта для файлов и подсистем практически всегда даёт весьма точное представление об их проблемности и сложности. А вот сравнение плотностей ошибок двух различных проектов требует учёта множества факторов: работала ли над ними одна и та же команда, как организован процесс, сходно ли предназначение и сценарий применения этих систем и т.п.