Является ли методика измерения метрик программного обеспечения популярной в современной индустрии?

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

Будучи студентом с информатикой, я очень мало знаю о показателях и их важности, но мои вопросы:

1. У большинства компаний есть какой-то способ, не должна ли быть элегантная программа для измерения значимых показателей?
2. Какие показатели, единичные или комбинированные, помогают сузить объем и смету ваших проектов?
3. Как человек, который анализирует показатели, как часто вы основываете на них решения? IE. Тесты не пройденные за неделю резко возрастают?
4. Считаете ли вы, что введение изучения метрик помогло вам лучше понять проект?

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

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

У большинства компаний есть какой-то способ, не должна ли быть элегантная программа для измерения значимых показателей?

Visual Studio включает в себя некоторые инструменты анализа кода, которые помогут вам начать работу. Большинство компаний даже не имеют возможности измерить наихудший показатель: строки кода. «Просто сделай это», по-видимому, является подавляющей движущей силой в отрасли, и проблемы ремонтопригодности уделяются очень мало внимания проблемам менеджеров «получу ли я свой бонус в этом году?» и "будет ли это сделано в то время, как я обещал?" Даже с продуктами, которые из года в год переносятся с постепенными изменениями, эти две проблемы сводили на нет интересы разработчиков в отношении удобства обслуживания и обнаружения / предотвращения ошибок.

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

Я считаю, что цикломатическая сложность и связь являются сильными индикаторами того, насколько глючным или сложным будет поддерживать код. Если цикломатическая сложность составляет около 20, я нахожу, что это будет почти невозможно проверить (так как он будет иметь до 2 ^ 20 путей через код) и должен быть разложен на более мелкие части. Вы не можете устранить сложность, но вы можете разделить ее на более управляемые куски.

Если вы ищете оценку , вы, вероятно, хотите исследовать функциональные точки .

% Покрытия кода резко снижает каждую итерацию, предупреждаете ли вы своих разработчиков о проблеме

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

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

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

Основными идеями были:

• Никакая особая метрика не является полезной сама по себе.
• Установка абсолютного целевого показателя (т. Е. Охват кода XX%) не имеет смысла.
• Метрика без истории полезна.

Итак, чтобы решить это:

• Показать несколько метрик, таких как:
  • Количество строк всего / изменено
  • количество коммитов
  • % покрытия кода
  • Количество тестов
  • цикломатическая сложность
  • файл / пакет / ... зависимость
  • ...
• Показать данные из QA / CI:
  
  • Количество ошибок / улучшений / изменений (лично я считаю эту классификацию важной)
  • # всего / добавлено / исправлено
• Показать эти показатели на графиках, которые показывают тенденции во времени

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

Подводя итог: важен именно этот тип динамического поведения, который дает вам информацию, а не необработанные данные (которые могут быть ценностью одной метрики).

Я планирую разместить несколько графиков в соответствии с этой схемой на широкоэкранном телевизоре рядом с нашими лавовыми лампами, подключенными к CI. ;)