Por qué debería utilizar prácticas de desarrollo basadas en estándares (incluso si no es necesario)

Toda una industria se ha desarrollado en torno a prácticas de verificación y validación que están respaldadas por estándares de seguridad funcional, protección y codificación como IEC 61508, ISO 26262, IEC 62304, MISRA C y CWE. Por supuesto, no todo el mundo está obligado a seguir los procesos formales y las metodologías que promueven estos estándares, especialmente si su software no necesita cumplir con los rigores de estos estándares. Pero los estándares defienden las mejores prácticas porque la experiencia dice que representan la forma más eficaz de lograr un software sólido, confiable y de alta calidad.

Las técnicas de desarrollo de mejores prácticas que siguen estos estándares ayudan a garantizar que los errores no se introduzcan en el código en primer lugar, lo que reduce la necesidad de actividades de depuración extensas que pueden ralentizar el tiempo de comercialización y agregar costos. Por supuesto, no todos los desarrolladores pueden darse el lujo de disponer de tiempo y presupuesto para las aplicaciones de las industrias aeroespacial, automotriz o de dispositivos médicos. Sin embargo, las técnicas que implementan representan una caja de herramientas con enormes beneficios potenciales para cualquier equipo de desarrollo, ya sea que la criticidad imponga su uso o no.

Tipos de errores y herramientas para solucionarlos

Se pueden encontrar dos tipos clave de errores en el software y solucionarlos utilizando herramientas para evitar que se introduzcan errores:

• Errores de codificación. Un ejemplo es el código que intenta acceder fuera de los límites de una matriz. Este tipo de problemas se pueden detectar realizando un análisis estático.
• Errores de aplicación. Estos solo se pueden detectar si se sabe exactamente lo que se supone que debe hacer la aplicación, lo que significa realizar pruebas en función de los requisitos.

Errores de codificación y revisión del código

El análisis estático es una técnica eficaz para detectar errores de codificación, especialmente cuando se implementa desde el inicio de un proyecto. Una vez que se ha analizado el código, existen diferentes tipos de resultados que se pueden visualizar. La revisión de código es donde el código se compara con un estándar de codificación como MISRA C:2012, que es en lo que nos centraremos en este artículo.

Idealmente, se utilizaría un lenguaje seguro como Ada para todos los proyectos integrados. Ada incluye numerosas características para hacer cumplir un proceso de pensamiento que naturalmente reduce los errores (como la mecanografía estricta, por ejemplo). Desafortunadamente, es difícil encontrar programadores con conocimientos y experiencia en Ada, por lo que la mayoría de las empresas utilizan C y / o C ++. Sin embargo, estos lenguajes presentan dificultades incluso para desarrolladores experimentados. Afortunadamente, al realizar la revisión del código, la mayoría de estos posibles errores se pueden evitar.

La mejor forma de evitar defectos en el código es evitar ponerlos allí. Esto suena obvio, pero esto es exactamente lo que hace un estándar de codificación. En el mundo de C y C ++, alrededor del 80% de los defectos del software son causados ​​por el uso incorrecto de alrededor del 20% del lenguaje. Si se restringe el uso del lenguaje para evitar las partes del lenguaje que se sabe que son problemáticas, se evitan los defectos y la calidad del software aumenta considerablemente.

Las causas fundamentales de fallas relacionadas con el lenguaje con los lenguajes de programación C / C ++ son el comportamiento indefinido, el comportamiento definido por la implementación y el comportamiento no especificado. Estos comportamientos provocan errores de software y problemas de seguridad.

Como ejemplo de comportamiento definido por la implementación, considere la propagación del bit de orden superior cuando un entero con signo se desplaza a la derecha. ¿El resultado es 0x40000000 o 0xC0000000?

Figura 1:El comportamiento de algunas construcciones de C y C ++ depende del compilador utilizado. (Fuente:LDRA)

La respuesta depende del compilador que esté utilizando (Figura 1). Podría ser cualquiera. El orden en el que se evalúan los argumentos de una función no está especificado en el lenguaje C. En el código que se muestra en la Figura 2, donde rollDice () la función simplemente lee el siguiente valor de un búfer circular que contiene los valores "1, 2, 3 y 4"; el valor devuelto esperado sería 1234. Sin embargo, no hay garantía de eso y al menos un compilador generará código que devuelva el valor 3412.

Figura 2:Los lenguajes no especifican el comportamiento de algunas construcciones de C y C ++. (Fuente:LDRA)

Los lenguajes C / C ++ presentan muchas trampas como esta, pero con el uso de un estándar de codificación, estos comportamientos indefinidos, no especificados y definidos por la implementación pueden evitarse. De manera similar, el uso de construcciones como goto o malloc puede dar lugar a defectos, por lo que se puede utilizar un estándar de codificación para evitar que se utilicen estas construcciones. Se producen muchos problemas al mezclar valores con y sin signo, lo que no genera ningún problema la mayor parte del tiempo, pero a veces puede haber un caso de esquina en el que el valor con signo se desborda y se vuelve negativo.

Los estándares de codificación también pueden verificar que el código esté escrito en un estilo particular; por ejemplo, verificar que el carácter de tabulación no se utilice, que la sangría sea de un tamaño específico o que los paréntesis estén colocados en una posición específica. Esto es importante ya que se requerirá una revisión manual del código y cuando el código se ve en un editor diferente donde el carácter de tabulación tiene un tamaño diferente, entonces el diseño extraño distrae al revisor de concentrarse en revisar el código.

Algunos desarrolladores son culpables de escribir código "inteligente" que puede ser muy eficiente y compacto, pero también puede ser críptico y complejo, lo que dificulta que otros lo entiendan. Es mucho mejor mantenerlo simple y dejar que el compilador se encargue de hacer un binario eficiente. Una vez más, el uso de un estándar de codificación puede ayudar a evitar que los desarrolladores creen código indocumentado y demasiado complejo.

Los estándares de programación más conocidos son quizás los estándares MISRA, que se publicaron por primera vez en 1998 para la industria automotriz. La popularidad de estos estándares se refleja en la cantidad de compiladores integrados que ofrecen cierto nivel de verificación MISRA. La última versión de MISRA es MISRA C:2012, que tiene casi el doble de páginas que su predecesor. La mayor parte de esta documentación adicional consta de explicaciones útiles sobre por qué existe cada regla, junto con detalles de las diversas excepciones a esa regla. MISRA tiene varias pautas y, cuando corresponde, contienen referencias a estándares o al comportamiento indefinido, no especificado y definido por la implementación. Un ejemplo de esto se puede ver en la Figura 3.

Figura 3:Referencias de MISRA C a comportamiento indefinido, no especificado y definido por la implementación. (Fuente:LDRA)

La mayoría de las pautas de MISRA son "Decidables", lo que significa que una herramienta debe poder identificar si hay una violación o no. Sin embargo, algunas pautas son "indecidibles", lo que significa que no siempre es posible que una herramienta deduzca si existe una infracción o no. Un ejemplo de esto es cuando una variable no inicializada se pasa como parámetro de salida a una función del sistema que debería inicializarla. Sin embargo, a menos que el análisis estático tenga acceso al código fuente de la función del sistema, no podrá saber si esa función utiliza la variable antes de inicializarla. Si se utiliza un verificador MISRA simple, es posible que no informe esta infracción, lo que posiblemente dé lugar a un falso negativo. Alternativamente, si un verificador de MISRA no está seguro, podría informar de la infracción, lo que posiblemente dé lugar a un falso positivo. ¿Qué es lo mejor? ¿Sin saber que podría haber un problema? ¿O saber exactamente dónde dedicar el tiempo para asegurarse de que definitivamente no hay un problema? Seguramente es preferible tener falsos positivos en lugar de falsos negativos.

En abril de 2016, el Comité MISRA emitió una enmienda a MISRA C:2012 que agregó 14 pautas adicionales para ayudar a garantizar que MISRA fuera aplicable no solo para software crítico para la seguridad sino también para software crítico para la seguridad. Una de estas pautas fue la Directiva 4.14, que, como se puede ver en la Figura 4, ayuda a prevenir errores debidos a comportamientos indefinidos.

Figura 4:MISRA y consideraciones de seguridad. (Fuente:LDRA)

Pruebas de requisitos y errores de la aplicación

Los errores de aplicación solo se pueden encontrar probando que el producto haga lo que se supone que debe hacer, y eso significa tener requisitos. Evitar errores de aplicación requiere tanto diseñar el producto correcto como diseñar el producto correctamente.

Diseñar el producto correcto significa establecer requisitos por adelantado y garantizar la trazabilidad bidireccional entre los requisitos y el código fuente, de modo que se hayan implementado todos los requisitos y todas las funciones del software se remontan a un requisito. Cualquier funcionalidad que falte o sea innecesaria (que no cumpla con un requisito) también es un error de la aplicación. Diseñar el producto correctamente es el proceso de confirmar que el código del sistema desarrollado cumple con los requisitos del proyecto, lo que se puede lograr mediante la realización de pruebas basadas en requisitos.

La figura 5 muestra un ejemplo de trazabilidad bidireccional. En este ejemplo simple, se ha seleccionado una sola función y se destaca la trazabilidad ascendente desde la función a un requisito de bajo nivel, luego a un requisito de alto nivel y finalmente a un requisito a nivel del sistema.

Figura 5:Trazabilidad bidireccional, con función seleccionada. (Fuente:LDRA)

En la Figura 6, se ha seleccionado un requisito de alto nivel, y el resaltado muestra tanto la trazabilidad ascendente a un requisito a nivel del sistema como la trazabilidad descendente a los requisitos de bajo nivel y las funciones del código fuente.

haz clic para ampliar la imagen

Figura 6:Trazabilidad bidireccional, con requisito seleccionado. (Fuente:LDRA)

Esta capacidad de visualizar la trazabilidad puede conducir a la detección de problemas de trazabilidad (errores de aplicación) al principio del ciclo de vida.

Probar la funcionalidad del código exige ser consciente de lo que se supone que debe hacer, y eso significa tener requisitos de bajo nivel para indicar lo que hace cada función. La Figura 7 muestra un ejemplo de un requisito de bajo nivel que, en este caso, describe completamente una sola función.

Figura 7:Ejemplo de requisito de bajo nivel. (Fuente:LDRA)

Los casos de prueba se derivan de requisitos de bajo nivel como se ilustra en la Tabla 1.

Tabla 1:Casos de prueba derivados de requisitos de bajo nivel. (Fuente:LDRA)

Con una herramienta de prueba unitaria, estos casos de prueba se pueden ejecutar en el host o en el destino para garantizar que el código se comporte de acuerdo con los requisitos. La Figura 8 muestra que todos los casos de prueba se retrocedieron y aprobaron.

Figura 8:Realización de pruebas unitarias. (Fuente:LDRA)

Cuando se hayan ejecutado los casos de prueba, entonces se debe medir la cobertura estructural para garantizar que se haya ejercido todo el código. Si la cobertura no es del 100 por ciento, es posible que se requieran más casos de prueba o que exista un código superfluo que deba eliminarse.

Conclusión

Con el aumento de la complejidad del software, también aumentan los posibles errores de software. Las técnicas de desarrollo de mejores prácticas ayudan a evitar que se produzcan estos errores. El desarrollo de mejores prácticas consiste en utilizar un estándar de codificación de vanguardia como MISRA C:2012, medir métricas en el código, rastrear requisitos e implementar pruebas basadas en requisitos. La medida en que se aplican estas técnicas cuando no hay obligación de cumplir con los estándares queda claramente a discreción del equipo de desarrollo. Sin embargo, los estándares defienden estas prácticas porque la experiencia dice que representan la forma más efectiva de lograr software de calidad, confiable y robusto. Y si un producto es crítico para la seguridad o no, ese es seguramente un resultado que solo puede ser beneficioso para su equipo de desarrollo.