A medição de métricas de projetos de software é popular no setor atual?

Encontrei um desenvolvedor que queria alguns conselhos externos sobre o projeto de suas equipes. Descobri que eles estão desenvolvendo um enorme conjunto de software para os executivos, gerente de projetos e desenvolvedores que podem calcular métricas automaticamente e representá-las graficamente por iteração.

Como estudante de ciência da computação, sei muito pouco sobre métricas e sua importância, mas minhas perguntas são:

1. A maioria das empresas tem alguma maneira, não precisa ser um programa elegante, para medir métricas significativas?
2. Quais métricas, únicas ou combinadas, ajudam a restringir o escopo e as estimativas do seu projeto?
3. Como uma pessoa que analisa métricas, com que frequência você baseia suas decisões? IE. Os testes falharam por semana estão aumentando drasticamente?
4. Você acha que a introdução do estudo de métricas ajudou a entender melhor o projeto?

Não sei por que, mas o projeto dos desenvolvedores me intrigou e preciso saber mais. Se y

Alguns livros sobre métricas que sua biblioteca da faculdade provavelmente inclui incluem Métricas de Software e Métricas e Modelos em Engenharia de Qualidade de Software . Esses 2 devem dar-lhe um ponto de partida. No mundo industrial, poucas empresas possuem algum tipo de programa de medição métrica.

A maioria das empresas tem alguma maneira, não precisa ser um programa elegante, para medir métricas significativas?

O Visual Studio inclui algumas ferramentas de análise de código que podem ajudar você a começar. A maioria das empresas nem sequer tem algo para medir a pior métrica possível: linhas de código. "Basta fazer" parece ser a força motriz esmagadora do setor, e as preocupações com a manutenção recebem muito pouca atenção às preocupações dos gerentes de "receberei meu bônus este ano?" e "isso será feito no tempo que prometi?" Mesmo com produtos que transitam ano a ano com mudanças incrementais, essas duas preocupações diminuíram as preocupações dos desenvolvedores em relação à manutenção e detecção / prevenção de erros.

Quais métricas, únicas ou combinadas, ajudam a restringir o escopo e as estimativas do seu projeto?

Acho que a complexidade e o acoplamento ciclomáticos são fortes indicadores de quão problemático ou difícil de manter o código. Se a complexidade ciclomática for em torno de 20, acho que será quase impossível testar (pois ele terá até 2 ^ 20 caminhos pelo código) e deve ser decomposto em pedaços menores. Você não pode eliminar a complexidade, mas pode dividi-la em pedaços mais gerenciáveis.

Se você está procurando uma estimativa , provavelmente deseja investigar pontos de função .

A porcentagem de cobertura do código está diminuindo drasticamente a cada iteração. Você alerta seus desenvolvedores sobre o problema

Acho que a maioria dos gerentes se preocupa com o número de check-ins e o número de bugs sendo corrigidos. Meu gerente atual se opõe aos testes de unidade (ele acha que é uma perda de tempo) e meu gerente anterior achou que o tempo gasto em testes de unidade era o tempo que deveria ser gasto escrevendo-o em primeiro lugar.

O argumento canônico usado pelos desenvolvedores é que, se você medir algo, é apenas isso que você obterá. Esse argumento deriva da ideia de que a única métrica são as linhas de código.

Eu estava em uma conversa sobre métricas de software em que o palestrante fez alguns, IMHO, pontos perspicazes. Tendo pouca experiência com essas coisas, eu ainda estava intrigado e inspirado, mas não sei dizer se está certo ou errado.

As principais idéias foram:

• Nenhuma métrica singular é útil por si só.
• Definir uma meta absoluta (ou seja, XX% de cobertura do código) não é significativo.
• Uma métrica sem histórico é útil.

Então, para resolver isso:

• Mostre várias métricas, como:
  • Nº de linhas totais / alteradas
  • Nº de confirmações
  • % Cobertura de código
  • Nº de testes
  • complexidade ciclomática
  • dependência de arquivo / pacote / ...
  • ...
• Mostrar dados de QA / CI:
  
  • # de erros / aprimoramento / alterações (eu pessoalmente acho que essa categorização é importante)
  • # total / adicionado / fixo
• Mostre essas métricas em gráficos que mostram tendências ao longo do tempo

Dessa forma, quando os tickets são corrigidos rapidamente, é possível ver se a qualidade do código diminui. Além disso, quando pouco parece acontecer com o banco de dados de erros, a qualidade do código pode aumentar, à medida que refatorações estão sendo feitas.

Resumindo: esse tipo de comportamento dinâmico é importante e fornece informações, e não dados brutos (o que seria o valor de uma única métrica).

Estou planejando colocar alguns gráficos de acordo com esse esquema em uma TV widescreen ao lado de nossas lâmpadas de lava conectadas à CI. ;)