Qué tasa de defectos puedo esperar en una base de código C++ escrita para un procesador integrado (DSP), dado que no ha habido pruebas unitarias, revisiones de códigos ni análisis de códigos estáticos, y que compila el proyecto genera alrededor de 1500 advertencias. ¿Son 5 defectos/100 líneas de código una estimación razonable?Software embebido Tasa de defectos
A pesar de mi escepticismo sobre la validez de cualquier estimación en este caso, he encontrado algunas estadísticas que pueden ser relevantes.
En this article, el autor cita las cifras de un "gran cuerpo de estudios empíricos", publicado en Software Assessments, Benchmarks, and Best Practices (Jones, 2000). En SIE CMM Level 1, que suena como el nivel de este código, uno puede esperar una tasa de defectos de 0.75 por function point. Dejaré que usted determine cómo se pueden relacionar los puntos de función y LOC en su código; probablemente necesite un metrics tool para realizar ese análisis.
Steve McConnell en Code Complete cites a study de 11 proyectos desarrollados por el mismo equipo, 5 sin revisiones de código, 6 con revisiones de código. La tasa de defectos para el código no revisado fue 4.5 por 100 LOC, y para la revisada fue 0.82. Entonces sobre esa base, su estimación parece justa en ausencia de otra información. Sin embargo, tengo que asumir un nivel de profesionalismo en este equipo (solo por el hecho de que sintieron la necesidad de realizar el estudio), y que al menos habrían atendido las advertencias; su tasa de defectos podría ser mucho más alta.
El punto de las advertencias es que algunas son benignas, y algunas son errores (es decir, provocarán un comportamiento no deseado del software); si las ignora en el supuesto de que son todas benignas, introducirá errores. Además, algunos se convierten en errores en mantenimiento cuando cambian otras condiciones, pero si ya ha decidido aceptar una advertencia, no tiene ninguna defensa contra la introducción de dichos errores.
Muchas gracias por la respuesta bien documentada. Debo admitir que nunca antes había oído hablar de los puntos de función. – geschema
Eso también depende de quién escribió el código (nivel de experiencia) y cuán grande es la base de códigos.
Consideraría todas las advertencias como errores.
¿Cuántos errores obtienes al ejecutar una herramienta de análisis estático en el código?
EDITAR
Run CCCC, y comprobar la complejidad cíclica del McCabe. Debería decir qué tan complejo es el código.
http://sourceforge.net/projects/cccc/
Run otras herramientas de análisis estático.
Ni siquiera he intentado ejecutar una herramienta de análisis estático en la base de código. Creo que primero deberíamos intentar que las advertencias cuenten a cero. ¿Esto parece razonable? – geschema
@geschema Sí, por supuesto. En mi opinión, el código debería compilarse sin advertencias, ya que la mayoría de las advertencias son válidas. –
Además, agregue tantas pruebas unitarias como sea posible. –
Eche un vistazo a la calidad del código. Le daría rápidamente una indicación de la cantidad de problemas que se esconden en la fuente. Si la fuente es fea y toma mucho tiempo entender que habrá muchos errores en el código.
El código bien estructurado con un estilo consistente y fácil de entender va a contener menos problemas. El código muestra cuánto esfuerzo y pensamiento entraron en él.
Supongo que si la fuente contiene tantas advertencias, habrá una gran cantidad de errores ocultos en el código.
La calidad del código es relativa y muy difícil de medir. Solo mirar el código no dará mucha información. –
Es cierto, pero le da una idea de lo que está sucediendo en el software. – Gerhard
Su pregunta es "¿Son 5 defectos/100 líneas de código una estimación razonable?" Esa pregunta es extremadamente difícil de responder, y depende en gran medida de la complejidad del código de la base de código &.
También mencionó en un comentario "para mostrar a la administración que probablemente hay muchos errores en la base de código" - eso es genial, felicitaciones, justo en.
Con el fin de abrir los ojos figurativos de la administración, me gustaría sugerir al menos un enfoque de 3 puntas:
Otro punto: Necesito compilaciones limpias en mis grupos, y también limpio la salida de pelusa. Por lo general, esto puede lograrse únicamente al escribir un buen código, pero ocasionalmente las advertencias sobre el compilador/pelusa deben modificarse para silenciar la herramienta en busca de cosas que no son problemas (use prudentemente).
Pero el punto importante que quiero hacer es la siguiente: tener mucho cuidado cuando se va en & fijación compilador & advertencias pelusa. Es un objetivo admirable, pero también puede romper inadvertidamente el código de trabajo y/o descubrir un comportamiento indefinido que accidentalmente funcionó en el código "roto". Sí, esto realmente sucede. Así que pise con cuidado.
Por último, si ya cuentas con un conjunto sólido de pruebas, eso te ayudará a determinar si accidentalmente se rompe algo mientras se refactoriza.
¡Buena suerte!
+1 para un consejo cuidadoso. Consulte también este libro para obtener ayuda sobre la transición del código no probado al código compatible con la refactorización: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 – Matthieu
@matthieu: eso es un gran libro. También lo recomiendo. – geschema
Gracias por los excelentes consejos y por señalar el riesgo de introducir nuevos errores al reparar advertencias aparentemente inofensivas, especialmente cuando no hay pruebas. – geschema
Si desea obtener una estimación del número de defectos, la forma habitual de estimación estadística es submuestrear los datos. Elegiría tres subrutinas de tamaño mediano al azar, y las revisaría cuidadosamente para detectar errores (eliminar las advertencias del compilador, ejecutar la herramienta de análisis estático, etc.). Si encuentra tres errores en 100 líneas de código total seleccionadas al azar, parece razonable que haya una densidad similar de errores en el resto del código.
El problema mencionado aquí de la introducción de nuevos errores es un problema importante, pero no es necesario volver a verificar el código modificado en la rama de producción para ejecutar esta prueba. Sugeriría un conjunto exhaustivo de pruebas unitarias antes de modificar cualquier subrutina, y limpiar todo el código seguido de pruebas exhaustivas del sistema antes de lanzar un nuevo código a la producción.
Si tiene mala suerte, su muestra podría ser muy buena ... –
@VJo: * ¡La submuestra * no significa * una muestra *! Eso es estadísticas para ti. – Clifford
@Clifford Statistics está bien, pero la ley de Murfy está por encima de las estadísticas;) –
Si desea demostrar los beneficios de las pruebas unitarias, revisiones de códigos, herramientas de análisis estático, le sugiero que realice un estudio piloto.
Realice algunas pruebas unitarias, revise códigos y ejecute herramientas de análisis estático en una parte del código. Muestre a la administración cuántos errores encuentra usando esos métodos. Con suerte, los resultados hablan por sí mismos.
El siguiente artículo tiene algunos números sobre la base de los proyectos de la vida real a la que el análisis estático se ha aplicado a: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html
Por supuesto, los criterios por los cuales una anomalía se cuenta puede afectar a los resultados de manera espectacular, lo que lleva a la gran variación en las cifras que se muestran en la Tabla 1. En esta tabla, el número de anomalías por mil líneas de código para C oscila entre 500 (!) y aproximadamente 10 (autogenerado).
¿Por qué quieres saber? – Jan
Es muy difícil decir cuán relevante es la cantidad de advertencias. La mayoría de las advertencias que se originan en un encabezado se informarán en todas las unidades de traducción que incluyan ese encabezado. – MSalters
@Jan: para mostrarle a la administración que probablemente hay muchos errores en la base de código, y que deberíamos comenzar a hacer algo al respecto ahora mismo. – geschema