Algunos libros sobre métricas que probablemente tenga la biblioteca de su universidad incluyen métricas de software y métricas y modelos en ingeniería de calidad de software . Esos 2 deberían darle un punto de partida. En el mundo industrial, muy pocas empresas tienen algún tipo de programa de medición métrica.
¿La mayoría de las empresas tienen alguna forma, no tiene que ser un programa elegante, para medir métricas significativas?
Visual Studio incluye algunas herramientas de análisis de código que pueden ayudarlo a comenzar. La mayoría de las empresas ni siquiera tienen algo para medir la peor métrica posible: líneas de código. "Simplemente hazlo" parece ser la fuerza motriz abrumadora en la industria, y las preocupaciones de mantenimiento reciben muy poca atención a las preocupaciones de los gerentes de "¿recibiré mi bono este año?" y "¿se hará esto en el tiempo que prometí?" Incluso con productos que se trasladan de año en año con cambios incrementales, esas dos preocupaciones eclipsaron las preocupaciones de los desarrolladores sobre la capacidad de mantenimiento y la detección / prevención de errores.
¿Qué métricas, simples o combinadas, lo ayudan a reducir el alcance y las estimaciones de sus proyectos?
Me parece que la complejidad ciclomática y el acoplamiento son indicadores sólidos de cuán defectuoso o difícil será mantener el código. Si la complejidad ciclomática es de alrededor de 20, encuentro que será casi imposible de probar (ya que tendrá hasta 2 ^ 20 rutas a través del código) y debe descomponerse en pedazos más pequeños. No puede eliminar la complejidad, pero puede dividirla en trozos más manejables.
Si está buscando una estimación , probablemente quiera investigar los puntos de función .
El% de cobertura de código está reduciendo drásticamente cada iteración, ¿alerta a sus desarrolladores del problema?
Me parece que a la mayoría de los gerentes les importa la cantidad de registros y la cantidad de errores que se solucionan. Mi gerente actual se opone a las pruebas unitarias (él piensa que es una pérdida de tiempo) y mi gerente anterior sintió que el tiempo dedicado a las pruebas unitarias era el tiempo que debería haberse dedicado a escribirlo en primer lugar.
El argumento canónico utilizado por los desarrolladores es que si mides algo, eso es solo lo que obtendrás. Este argumento proviene de la idea de que la única métrica son las líneas de código.