Trazable, no solo terminado
Cada entregable se puede seguir hacia atrás hasta el requisito que lo originó y hacia adelante hasta la prueba que lo cierra. Si no se puede trazar, no está hecho.
Soy Tsvetan Tsvetkov. Desde hace más de una década trabajo como ingeniero de sistemas, y antes como ingeniero de software, en los equipos detrás de componentes y herramientas de algunos de los coches más vendidos de Europa.
Escrito, parece una lista. Especificaciones de requisitos descompuestas en arquitectura; conceptos de seguridad funcional y técnica conforme a ISO 26262; análisis de peligros y evaluación de riesgos, clasificación ASIL y su descomposición hasta el elemento que la soporta; modelos de comportamiento en Matlab, Simulink y Stateflow, ejercitados en bancos model-, software- y hardware-in-the-loop mucho antes de que exista una pieza; trazabilidad que se sostiene desde una línea de la especificación del cliente hasta la prueba que lo demuestra; y la documentación que debe sobrevivir a una evaluación de seguridad años después de que quienes la escribieron hayan cambiado de proyecto.
También significa trabajar dentro del proceso de otro: las puertas de versión de un fabricante, el sistema de calidad de un proveedor, un programa que no moverá su inicio de producción porque una línea de trabajo llegue tarde. La ingeniería impecable que llega después de la puerta no vale nada.
Vivido, el trabajo es más silencioso que la lista. Una década termina convertida en unos pocos cientos de milisegundos de comportamiento que nadie debe notar: un aviso que llega cuando todavía sirve, una pantalla que sigue legible justo cuando importa, una función que, al fallar, falla hacia el lado seguro. Hoy muchísimos conductores europeos dependen de ese trabajo cada vez que arrancan, y ninguno sabrá nunca que está ahí.
Un programa de cuatro cursos del Massachusetts Institute of Technology sobre arquitectura de sistemas complejos, modelos en ingeniería, ingeniería de sistemas basada en modelos para documentación y análisis, y métodos cuantitativos: el aparato formal que hay detrás de cómo se estructura aquí cada encargo.
Arquitectura de computadores, microprocesadores, sistemas operativos, semiconductores y análisis de algoritmos: la capa que hay debajo de los modelos, que es donde acaba ejecutándose el software crítico para la seguridad.
Cada encargo se lleva de forma que los hallazgos incómodos aparezcan mientras todavía son baratos. Análisis antes que modelado, simulación antes que hardware, documentación escrita a medida que se trabaja y no reconstruida antes de una auditoría.
No son promesas, son formas de trabajar, y puedes contrastarlas con cualquier entrega.
Cada entregable se puede seguir hacia atrás hasta el requisito que lo originó y hacia adelante hasta la prueba que lo cierra. Si no se puede trazar, no está hecho.
Trabajo dentro de tus puertas, tus plantillas y tu cadena de herramientas, no al margen. La integración es mi problema, no el tuyo.
Cuando un análisis es incierto, la incertidumbre se escribe y se arrastra hacia adelante en lugar de suavizarse en un informe de estado.
En ZETOSON lo analizamos y lo convertimos en una solución. Agenda una reunión con nuestro equipo sin compromiso.