Embedded Software Defecto Tasa

Question

¿Qué tipo de defecto se puede esperar en un C ++ código base que está escrito para un procesador embebido (DSP), dado que no se han presentado pruebas de unidad, no hay las revisiones de código, ningún análisis de código estático, y que compilar el proyecto genera alrededor de 1.500 advertencias. 5 es defectos / 100 líneas de código una estimación razonable?

Answer 1

A pesar de mi escepticismo de la validez de cualquier cálculo en este caso, he encontrado algunas estadísticas que pueden ser relevantes.

este artículo , el autor cita cifras de un " una gran cantidad de estudios empíricos", publicado en Software evaluaciones, puntos de referencia, y Mejor prácticas (Jones, 2000) . En SIE CMM Nivel 1 , que suena como el nivel de este código, se puede esperar una tasa de defectos del 0,75 por punto de función . Lo dejo a usted para determinar cómo puntos de función y el COL referidas, en su código - es probable que tengas un métricas de la herramienta para llevar a cabo este análisis.

Steve McConnell en el código completo cita una estudiar de 11 proyectos desarrollados por el mismo equipo, 5 sin revisiones de código, 6 con las revisiones de código. La tasa de defectos para el código no revisado-fue de 4,5 por 100 LOC, y para la crítica que era 0,82. Así que, sobre esa base, su estimación parece justo en ausencia de cualquier otra información. Sin embargo tengo que asumir un nivel de profesionalismo entre este equipo (sólo por el hecho de que sentían la necesidad de realizar el estudio), y que tendría al menos asistió a las advertencias; su tasa de defectos podría ser mucho más alto .

El punto acerca de las advertencias es que algunos son benignos, y algunos son errores (es decir, dará lugar a un comportamiento no deseado del software), si los ignora en el supuesto de que todos ellos son benignos, se introducen errores. Por otra parte algunos lo harán convertirse errores en mantenimiento cuando otras condiciones cambian, pero si ya ha decidido aceptar una advertencia, no tiene defensa contra la introducción de dichos errores.

Answer 2

Su pregunta es "es 5 defectos / 100 líneas de código una estimación razonable?" Esa pregunta es muy difícil de responder, y es dependiente de la base de código y código de alta complejidad.

También mencionó en un comentario "para mostrar la dirección que probablemente hay un montón de errores en el código base." - Eso es genial, felicitaciones, justo en

Con el fin de ojos figurativas de gestión abierta, me gustaría sugerir al menos un enfoque de 3 puntas:

• Tome las advertencias del compilador específicos, y mostrar cómo algunos de ellos pueden causar un comportamiento indefinido / desastrosa. No todas las advertencias serán tan pesada. Por ejemplo, si tienes a alguien usando un puntero no inicializado, eso es oro puro. Si tienes a alguien relleno de un valor sin signo de 16 bits en un valor sin signo de 8 bits, y se puede demostrar que el valor de 16 bits siempre será <= 255, que uno no va a ayudar a hacer su caso con tanta fuerza.
• ejecutar una herramienta de análisis estático. PC-Lint (o Flexelint) es barato y proporciona una buena "explosión para el dólar". Es casi seguro que coger cosas que el compilador no lo hará, y también puede correr a través de las unidades de traducción (pelusa todo juntos, incluso con 2 o más pases) y encontrar los errores más sutiles. Una vez más, utilizar algunos de estos como indicaciones.
• ejecutar una herramienta que le dará a otras métricas de la complejidad del código, otra fuente de errores. Te recomiendo Estándar de Recursos métricas de M Squared (RSM) que será darle más información y métricas (incluyendo la complejidad del código) que se podría desear. Cuando cuentas de gestión que una puntuación complejidad mayores de 50 años es "básicamente no comprobable" y usted tiene una puntuación de 200 en una rutina, que debe abrir algunos ojos.

La otra cosa: requiero compila limpias en mis grupos, y la salida de pelusa limpio. Por lo general, esto puede lograrse únicamente mediante la escritura de código buena, pero a veces las advertencias del compilador / pelusa necesita ser ajustado para calmar la herramienta para cosas que no son problemas (utilización juiciosa).

Pero el punto importante que quiero hacer es la siguiente: tener mucho cuidado cuando se va en la fijación y del compilador y pelusa advertencias . Es un objetivo admirable, pero también se puede inadvertidamente romper el código de trabajo, y / o descubrir un comportamiento indefinido que accidentalmente trabajó en el código "roto". Sí, esto realmente sucede. Así que ir con cuidado.

Por último, si usted tiene un sólido conjunto de pruebas que ya están en su lugar, que le ayudará a determinar si accidentalmente se rompe algo, mientras que la refactorización.

Buena suerte!

Answer 3

Tome un vistazo a la calidad del código. Rápidamente se le daría una indicación de la cantidad de problemas que se esconden en la fuente. Si la fuente es feo y tomar mucho tiempo para entender que habrá un montón de errores en el código.

código bien estructurado con estilo coherente y que es fácil de entender van a contener menos problemas. muestra el código de la cantidad de esfuerzo y pensamiento entraron en ella.

Mi conjetura es si la fuente contiene muchas advertencias de que no va a ser un montón de errores se esconden en el código.

Answer 4

Eso también depende de quien escribió el código (nivel de experiencia), y lo grande que es la base de código.

Yo trataría a todas las advertencias como errores.

¿Cuántos errores se puede conseguir cuando se ejecuta una herramienta de análisis estático del código?

editar

Ejecutar CCCC, y comprobar la complejidad cíclica del McCabe. Se debe decir la complejidad del código de la misma.

http://sourceforge.net/projects/cccc/

Run otras herramientas de análisis estático.

Answer 5

Si desea obtener una estimación del número de defectos, la forma habitual de estimatation estadística es submuestra de los datos. Me volvería a escoger tres subrutinas de tamaño medio al azar, y comprobar con cuidado para eliminar insectos (advertencias del compilador, ejecutar la herramienta de análisis estático, etc.). Si encuentras tres errores en 100 el total de líneas de código seleccionado al azar, parece razonable que una densidad similar de insectos se encuentran en el resto del código.

El problema mencionado aquí de introducir nuevos errores es un tema importante, pero no es necesario volver a comprobar el código modificado en la rama de producción para ejecutar esta prueba. Yo sugeriría un conjunto exhaustivo de las pruebas unitarias antes de modificar cualesquiera subrutinas, y la limpieza de todo el código seguido de las pruebas del sistema muy minucioso antes de lanzar nuevo código de producción.

Answer 6

Si desea demostrar los beneficios de las pruebas unitarias, las revisiones de código, herramientas de análisis estático, Sugiero hacer un estudio piloto.

Hacer algunas pruebas unitarias, las revisiones de código, y ejecutar herramientas de análisis estático en una parte del código. Mostrar gestión cuántos errores que encuentre el uso de esos métodos. Con suerte, los resultados hablan por sí mismos.

Answer 7

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, el criterio por el cual una anomalía se cuenta puede afectar los resultados drásticamente, dando lugar a la gran variación en las figuras mostradas en la Tabla 1. En esta tabla, el número de anomalías por cada mil líneas de código para C oscila entre 500 (!) a aproximadamente 10 (autogenerado).