Reduce a la mitad el tiempo y el coste de integración de tus sistemas

¿Por qué gastar la mitad del cronograma y los recursos de su programa en la integración del sistema?

La integración del sistema consume una parte importante de los cronogramas y recursos del programa a medida que reúne el software, la electrónica y la mecánica. En mi blog Extendiendo MBSE a su cadena de suministro, describí cómo realmente planifica los problemas de integración y cómo gasta entre el 30 % y el 70 % de los cronogramas/recursos de su programa reuniendo todo en el lado derecho de la V.

Por qué tenemos problemas de integración

Mirando el proceso en V, la razón es clara:

Observar el proceso Aero ARP4754 estándar muestra cómo los diversos silos de desarrollo encajan en el proceso V. Los requisitos se desarrollan en un silo, las pruebas utilizadas para verificar esos requisitos están en otro silo, la arquitectura está en otro lugar, y así sucesivamente. Esto significa que no hay una fuente única de verdad, no hay trazabilidad entre dominios, no se transmiten lecciones aprendidas, etc., ya que cada silo hace lo suyo con sus propios conjuntos de herramientas.

Podría culpar al proceso V, pero este V se encuentra en la parte superior de una organización, que de acuerdo con la Ley de Conway dice, las organizaciones desarrollan productos que coinciden con sus estructuras organizativas, es decir, desarrollamos en silos y esperamos hasta llegar al lado correcto de la V para hacer la integración del sistema, descubrir los problemas de integración y LUEGO comenzar a integrar.

El Proyecto de Integración Virtual de Arquitectura de Sistemas (SAVI, por sus siglas en inglés) del Instituto de Sistemas de Vehículos Aeroespaciales (AVSI, por sus siglas en inglés) dice que esto tiene que cambiar, ya que ya no es asequible construir aviones como solíamos hacerlo (consulte la Ley n.º 16 de Augustine), cruzando el límite de asequibilidad para aviones comerciales y aviones militares en 2013.

El proyecto ha recopilado varias medidas de complejidad de organizaciones miembros como esta para Source Lines-of-Code (SLOC):

Sugieren un cambio del proceso actual de «diseño de especificaciones e integración» a un proceso de «integrar, luego construir» o, como dicen, «comenzar integrado, permanecer integrado». Entonces, ¿por qué aguantamos esto? Como me dijo una persona aerodinámica, «porque así es como siempre lo hemos hecho».

Cómo empezar integrado, permanecer integrado

Dejando de lado los problemas de organización necesarios para hacer ese cambio por el momento, «comenzar integrado» requerirá la captura y gestión de la cruz.

• + La arquitectura del producto impulsa las relaciones entre productos que permiten la comprensión del impacto entre productos.
• + Los requisitos que describen qué tan bien se hace algo deben mostrarse en todos los silos para influir en las decisiones de diseño a medida que se realizan.
• + Los parámetros participan en la configuración, por lo que se utiliza la versión correcta en simulaciones, pruebas, etc.
• .

«Permanecer integrado» requiere administrar/controlar los artefactos a través de servicios PLM estándar como cambio, configuración, flujo de trabajo, variación y más:

• + Un cambio regulatorio o de requisitos sigue las estructuras y asignaciones de productos para notificar a todos los afectados por un cambio. La gestión de cambios garantiza que todos los afectados estén incluidos y que las acciones se completen con evidencia manteniendo un historial documentado del producto.
• + Las pruebas saben qué versiones de casos de prueba se deben realizar, cuándo, qué recursos se requieren, qué versiones de parámetros, estado de calibración del equipo de prueba, etc. junto con cómo se comparan los resultados de las pruebas con los resultados de gemelos digitales previstos, etc.
• .

Comenzando Integrado, Permaneciendo Integrado tiene la promesa de traernos de vuelta a lo asequible.

¿Esto funciona?

Según Air Force Magazine, Boeing aplicó estas técnicas en el entrenador T-X doblando la curva de costos un 50% menos de lo que esperaba la USAF:

• + Aumento del 75 % en la calidad de la primera pasada
• + 50% menos de horas de desarrollo de software
• + Reducción del 80% en horas de montaje
• .

…y esta gran cita del ingeniero jefe del proyecto:

Probablemente las estadísticas más significativas que teníamos, pasamos los primeros 14 vuelos sin un graznido del piloto [problema de integración]. Ese es un testimonio de cómo atravesamos este viaje, [teníamos] un diseño robusto.
– Paul Niewald  Boeing T-X Chief Engineer