Por qué importan prácticas de desarrollo basadas en estándares —incluso cuando no son obligatorias

Una industria dedicada a verificación y validación —impulsada por estándares como IEC 61508, ISO 26262, IEC 62304, MISRA C y CWE— ha emergido para asegurar que el software sea fiable, seguro y de alta calidad. Incluso si tu producto no cae bajo requisitos regulatorios estrictos de estos estándares, adoptar sus procesos de mejores prácticas probados puede reducir drásticamente bugs, acortar time-to-market y recortar costes de mantenimiento.

Tipos de Errores y Herramientas para Abordarlos

Los defectos de software caen en dos categorías amplias, cada una requiriendo técnicas de mitigación distintas:

• Errores de codificación —ej. accesos a array fuera de límites— pueden detectarse temprano con análisis estático.
• Errores de aplicación surgen cuando el código no cumple sus especificaciones; estos solo se descubren mediante testing dirigido por requisitos.

Errores de Codificación y Code Review

El análisis estático es una poderosa primera línea de defensa, especialmente cuando se integra al inicio de un proyecto. Identifica violaciones de reglas de codificación que de otro modo se convertirían en bugs difíciles de depurar después. Complementario al análisis estático, una rigurosa code review verifica que el código cumple con un estándar de codificación elegido, como MISRA C:2012.

En teoría, un lenguaje diseñado para seguridad —Ada, por ejemplo— eliminaría muchos escollos mediante tipado fuerte y constructos explícitos. En la práctica, la mayoría de equipos embebidos dependen de C o C++, que ofrecen flexibilidad pero también exponen a desarrolladores a trampas sutiles como comportamientos indefinidos, no especificados y definidos por implementación. Restringiendo características de lenguaje usadas y prohibiendo constructos riesgosos (ej. goto, malloc, mezclar aritmética signed y unsigned), un estándar de codificación puede elevar la barra para prevención de defectos.

Aquí hay algunos escollos comunes ilustrados en el mundo C/C++:

1. Shift de entero signed definido por implementación: ¿un right shift rellena el bit de orden alto con ceros o unos?
2. Orden no especificado de evaluación de argumentos de función, que puede alterar resultado de una rutina simple como rollDice().
3. Mezclar valores signed y unsigned, que puede llevar a overflows sutiles.

Las Figuras 1 y 2 abajo demuestran cómo el mismo código puede comportarse diferente entre compiladores, subrayando la importancia de un enfoque de codificación disciplinado.

Figura 1: El comportamiento de algunos constructos C y C++ depende del compilador usado. (Fuente: LDRA)

Figura 2: El comportamiento de algunos constructos C y C++ no está especificado por los lenguajes. (Fuente: LDRA)

Adoptar un estándar de codificación bien establecido como MISRA C:2012 ayuda a evitar estos escollos. Las reglas del estándar cubren más de 300 prácticas de codificación específicas, cada una respaldada por explicaciones que referencian comportamientos indefinidos y no especificados del lenguaje. La mayoría de guías son "decidibles", significando que una herramienta de análisis estático puede detectar violaciones automáticamente; unas pocas son "indecidibles", donde la herramienta debe señalar problemas potenciales y los desarrolladores deciden si son problemas reales.

En abril 2016, MISRA expandió su alcance para abordar software crítico de seguridad añadiendo 14 nuevas guías. Directiva 4.14, por ejemplo, apunta explícitamente a comportamiento indefinido, proveyendo capa extra de protección para proyectos orientados a seguridad. La Figura 4 muestra cómo las consideraciones de seguridad de MISRA se alinean con el marco de seguridad más amplio.

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

Errores de Aplicación y Testing de Requisitos

Mientras los estándares de codificación protegen contra bugs de bajo nivel, los bugs de aplicación surgen cuando el software falla en cumplir su comportamiento intencionado. Detectar estos requiere una base sólida de requisitos y enlace trazable entre requisitos, diseño y código.

Trazabilidad bidireccional asegura que cada requisito se implementa y cada implementación puede rastrearse a un requisito. Las Figuras 5 y 6 ilustran este mapeo de dos vías, revelando funcionalidad faltante o redundante temprano en el ciclo de vida.

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

clic para imagen ampliada

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

Una vez la trazabilidad está en su lugar, los casos de test pueden derivarse de requisitos de bajo nivel. La Figura 7 muestra un requisito típico de bajo nivel que especifica completamente el comportamiento de una sola función, y la Tabla 1 demuestra cómo los casos de test se mapean a esos requisitos.

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

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

Ejecutando estos tests con un framework de unit-testing tanto en host como en target confirma que la implementación coincide con el requisito. La Figura 8 muestra una suite de regresión donde todos los casos de test pasan. Tras la ejecución de tests, métricas de cobertura estructural verifican que toda la base de código ha sido ejercitada; cualquier gap provoca tests adicionales o refactorización de código.

Figura 8: Ejecutando unit tests. (Fuente: LDRA)

Conclusión

La complejidad del software aumenta, y con ello el riesgo de defectos. Desarrollo de mejores prácticas —basado en estándar de codificación moderno como MISRA C:2012, métricas rigurosas, requisitos trazables y testing basado en requisitos— proporciona un camino probado a código de alta calidad, fiable y robusto. Ya sea que tu proyecto esté vinculado a regulaciones formales de seguridad o no, la disciplina y transparencia que estas prácticas aportan son un beneficio neto para cualquier equipo de desarrollo.