Эксперты раздела
Коэффициент качества программного кода
Описание показателя
Показатель отражает качество программного кода. Чем меньше тратится времени на исправление ошибок, тем выше качество.
Формула расчета
(t_общ - t_испр) / t_общ,
где:
t_общ - Общее время программирования.
t_испр - Общее время исправления ошибок кодирования.
где:
t_общ - Общее время программирования.
t_испр - Общее время исправления ошибок кодирования.
Нормы
Значение коэффициента стремится к 1 (отсутствие ошибок).
Тип показателя
Количественный
Диница измерения
Коэффициент (отношение)
Тренд
Максимизация значений
Отрасли
Информационные технологии,
Функциональное направление
Информационные технологии,
★★★★★
Голосов: 1
Голосов: 1
Супер, а если тот, кто правит наращивает ошибки в коде с еще большей интенсивностью, чем тот, кто написал код?
А если первоначальный код был написан хорошим, но небрежным программистом (такие личности пишут быстро, коды у них "короткие" и замысловатые), а потом этот код, который нужно немного отладить попадает в очумелые руки серой посредственности?
Что в этих случаях покажет этот показатель?
Или нужно вводить правила пользования этим показателем, какие-то ограничения его применимости (типа код возвращается на правку всегда его автору).
А если первоначальный код был написан хорошим, но небрежным программистом (такие личности пишут быстро, коды у них "короткие" и замысловатые), а потом этот код, который нужно немного отладить попадает в очумелые руки серой посредственности?
Что в этих случаях покажет этот показатель?
Или нужно вводить правила пользования этим показателем, какие-то ограничения его применимости (типа код возвращается на правку всегда его автору).
07.05.2010
Алекс
✎ ОтветитьОтвет на
2. Небрежный программист уже не есть хороший и показатель как раз покажет это.
3. Это лишь один из показателей, оценивающих качество работы программиста. Можно также, например, оценивать срыв сроков по вине программистов. Время в деньги легко перевести.
4. Насчет ограничений согласен, но они будут всегда различными и вообще будут зависеть от проекта.
Супер, а если тот, кто правит наращивает ошибки в коде с еще большей интенсивностью, чем тот, кто написал код?
А если первоначальный код был написан хорошим, но небрежным программистом (такие личности пишут быстро, коды у них "короткие" и замысловатые), а потом этот код, который нужно немного отладить попадает в очумелые руки серой посредственности?
Что в этих случаях покажет этот показатель?
Или нужно вводить правила пользования этим показателем, какие-то ограничения его применимости (типа код возвращается на правку всегда его автору).
1. Тот, кто правит ошибки, также может оцениваться этим показателем, в случае если проект сдан и ошибки возникли после. Исправление ошибки можно представить в виде отдельной работы. Эту работу вообще могут делать другие люди из техподдержки.А если первоначальный код был написан хорошим, но небрежным программистом (такие личности пишут быстро, коды у них "короткие" и замысловатые), а потом этот код, который нужно немного отладить попадает в очумелые руки серой посредственности?
Что в этих случаях покажет этот показатель?
Или нужно вводить правила пользования этим показателем, какие-то ограничения его применимости (типа код возвращается на правку всегда его автору).
2. Небрежный программист уже не есть хороший и показатель как раз покажет это.
3. Это лишь один из показателей, оценивающих качество работы программиста. Можно также, например, оценивать срыв сроков по вине программистов. Время в деньги легко перевести.
4. Насчет ограничений согласен, но они будут всегда различными и вообще будут зависеть от проекта.
07.05.2010
Шаппо Илья
✎ ОтветитьТакая постановка показателя не совсем удачна, т.к. при t_испр -> 0 (идеальный код, чего почти не бывает, но вдруг :) - давайте валидируем показатель для классической программы "Hello, world") значение коэффициента стремится к бесконечности, что не есть хорошо. Лучше применить такой вариант: (t_общ - t_испр)/t_общ.
Тогда коэффициент всегда будет заперт между 0 и 1, но как и оригинальный, тренд будет иметь на максимизацию - как КПД.
Тогда коэффициент всегда будет заперт между 0 и 1, но как и оригинальный, тренд будет иметь на максимизацию - как КПД.
07.06.2010
Зверев Борис Николаевич
✎ ОтветитьОтвет на
Такая постановка показателя не совсем удачна, т.к. при t_испр -> 0 (идеальный код, чего почти не бывает, но вдруг :) - давайте валидируем показатель для классической программы "Hello, world") значение коэффициента стремится к бесконечности, что не есть хорошо. Лучше применить такой вариант: (t_общ - t_испр)/t_общ.
Тогда коэффициент всегда будет заперт между 0 и 1, но как и оригинальный, тренд будет иметь на максимизацию - как КПД.
Очень правильная формула, спасибо за предложение. В этом случае, при идеальном варианте, данный коэффициент будет стремиться к 1. А поскольку ошибки всегда будут (даже после очень хорошего тестирования), то и норму можно установить на уровне 0,9.0,95 на начальном этапе эксплуатации системы и, например, 0,99 после года эксплуатации.
Тогда коэффициент всегда будет заперт между 0 и 1, но как и оригинальный, тренд будет иметь на максимизацию - как КПД.
08.06.2010
Шаппо Илья
✎ ОтветитьПример:
Программист №1 потратил за выполнение задачи, 3 часа, а на исправление ошибок 1 час, соответственно его коэффициент 0,66
Программист №2 (менее опытный) потратил на выполнение той же самой задачи 24 часа, допустил столько же ошибок и правил их 2 часа, соответственно его коэффициент будет 0,92.
Выходит при одинаковом количестве ошибок в коде, качество кода выше у того программиста, который дольше выполнял работу. Несмотря на то, что первый программист и быстрее выполняет работу и быстрее правит ошибки, у него коэффициент хуже.
Я уж не говорю о том, что в зависимости от сложности задачи вероятность ошибок возрастает в геометрической прогрессии. Например, майкрософт разрабатывает новый Windows, а я пишу “Hello World”, Винда, естественно, глючит, а мой супер-блокнот – нет, выходит качество моего кода выше, чем у сотрудников майкрософта :)
Программист №1 потратил за выполнение задачи, 3 часа, а на исправление ошибок 1 час, соответственно его коэффициент 0,66
Программист №2 (менее опытный) потратил на выполнение той же самой задачи 24 часа, допустил столько же ошибок и правил их 2 часа, соответственно его коэффициент будет 0,92.
Выходит при одинаковом количестве ошибок в коде, качество кода выше у того программиста, который дольше выполнял работу. Несмотря на то, что первый программист и быстрее выполняет работу и быстрее правит ошибки, у него коэффициент хуже.
Я уж не говорю о том, что в зависимости от сложности задачи вероятность ошибок возрастает в геометрической прогрессии. Например, майкрософт разрабатывает новый Windows, а я пишу “Hello World”, Винда, естественно, глючит, а мой супер-блокнот – нет, выходит качество моего кода выше, чем у сотрудников майкрософта :)
02.08.2010
Петров Дмитрий Юрьевич
✎ ОтветитьРазумеется, любые показатели надо применять осмысленно и к реальным задачам, а не к Hello world. Если проводить оценку программистов, работающих на одном проекте (или на похожих проектах), то показатель будет работать корректно.
02.08.2010
Шаппо Илья
✎ Ответить
Для добавления отзыва необходимо зарегистрироваться или авторизоваться
© 2009-2024. При поддержке компании KPI Lab. Права на все изображения и материалы, представленные на портале, принадлежат их владельцам.
При использовании материалов с портала активная ссылка на www.kpilib.ru обязательна. Пожалуйста, ознакомьтесь с Условиями использования сайта.
При использовании материалов с портала активная ссылка на www.kpilib.ru обязательна. Пожалуйста, ознакомьтесь с Условиями использования сайта.