Proyecto de Avanzada Tecnología

UN PROYECTO DE AVANZADA TECNOLOGIA COMO EL PES (PLATAFORMA ESTRATEGICA DE SUPERFICIE-BUQUE) IMPLICA REQUERIMIENTOS COMPLEJOS EN TODOS LOS
FRENTES TALES COMO EN GERENCIA DE PROYECTOS Y DESARROLLO DE SOFTWARE: En el Proyecto PES, en su inicio en 1998 tome parte y en el cual hasta el 2012 participé,
así como contribución con el Grupo de Análisis y Pensamiento Estratégico Naval GRAPEN en 2018.

Un buque como el PES es un “sistema de combate” esto a su vez lleva a conceptos como “sistema de sistemas” y ello se fundamenta en desarrollo de software, normalmente asignado a subcontratistas y grandes empresas especializadas; lo cual no releva a la Gerencia de Proyecto y demás involucrados de sus responsabilidades en cuanto a prácticas gerenciales, acciones y toma de decisiones respecto al proyecto como un todo.

Sin embargo, en construcción de buques de combate y sus sistemas, las experiencias en todas las latitudes y en la Marina Colombiana ha sido un tema critico que afecta la construcción en tiempos y costos de manera que requiere entenderse y ser parte integral del proyecto, con todos sus efectos y esto incluye compatibilidad e integración.
Si hace unos años el tema era critico hoy es aún más, debido al exponencial avance científico tecnológico actual y previsto hacia el futuro.

Dentro de este marco y el desarrollo del buque PES y cualquier buque de combate actual y futuro, éste implica características requeridas con armas de cortísima y altamente efectiva
capacidad de reacción, lo cual es posible mediante CUEING, múltiples agentes interactuando, automatismo y NetWork Centric. Esto trae como consecuencia, que el fundamento de software es incuestionablemente vital.

Con base en: The roots of agile project management TechRepublic, Rick Freedman, June 16, 2009 Se empieza por aceptar que hay problemas reconocidos con los métodos estándar de Gerencia de Proyectos. Los famosos estudios Standish Group CHAOS demuestran que muchos proyectos de TI (Tecnologías de Información) fallan en las predicciones de costo y cronograma, y con frecuencia no pueden aportar los beneficios esperados. Estos problemas han sido confirmados por varias organizaciones, incluyendo el Departamento de Defensa (DoD).

EL DEPARTAMENTO DE DEFENSA DE EEUU SEÑALÓ QUE DE LOS $ 35,7 BILLONES GASTADOS POR LA ORGANIZACIÓN EN 1995 PARA SOFTWARE, SÓLO EL 2 POR CIENTO
DEL SOFTWARE SE PUEDE UTILIZAR EN EL MOMENTO DE ENTREGA DEL DESARROLLO. EL DEPARTAMENTO DE DEFENSA REVELÓ QUE EL 75 POR CIENTO DEL SOFTWARE DESARROLLADO NO SE UTILIZA O SE CANCELA ANTES DE LA ENTREGA Con base en: The roots of agile project management TechRepublic, Rick Freedman, June 16, 2009.

En 1998, los académicos de la “Harvard Business School” Robert D. Austin y Richard L. Nolan estudiaron grandes proyectos de software. Su estudio, que cuestionaba muchas de las ideas fundamentales de desarrollo de TI (Tecnologías de Información) y Gerencia de proyectos, produjo hallazgos claves: " La primera suposición errónea es que es posible planificar un proyecto grande. La segunda suposición errónea es que es posible proteger el proyecto contra los cambios durante el desarrollo mismo La tercera suposición errónea es que, incluso, tiene sentido comprometerse en grandes proyectos tempranamente“.

Watts Humphrey, un respetado investigador de IBM, luego de este estudio produjo su documento “Requirements Uncertainty Principle”, en el que afirma que: "Para un nuevo sistema de software, los requisitos no se conocen por completo hasta después que los usuarios lo han utilizado." Hadar Ziv, de la Universidad de California, poco después produjo su “Uncertainty Principle in Software Engineering”, que establece: "La incertidumbre es inherente e inevitable en los procesos de desarrollo de software y
productos.“

Aceptando estos conceptos e ideas, la consecuencia lógica es que los métodos de "cascada" son claramente erróneos, requiriendo otros enfoques SHIP SELF DEFENSE) DE RAYTHEON El desarrollo del SSD (Ship Self Defense) de Raytheon para la USN viene desde 1997 Los reportes anuales al Congreso de EEUU recopilados de 2008, 2009 y 2011 contundentemente indican: El sistema SSD presenta varias fallas y falta de confiabilidad que no permiten en este momento considerarlo operacionalmente efectivo y que cumpla con su objetivo de defensa y SUPERVIVENCIA de buques de superficie vitales en la USN como los CVN (portaviones) La importancia del papel de la USN en el proceso de pruebas y evaluaciones de efectividad operacional es vital, así como es igualmente crítico EL SUMINISTRO POR LA USN DE MEDIOS Y BLANCOS PARA REALIZACIÓN DE LAS PRUEBAS.

Las cuantiosas inversiones en presupuestos indican una determinación, esfuerzo y claridad tanto de la USN como del DoD de EEUU, haciéndose palpable un proceso de desarrollo evolutivo.
Muchas lecciones se derivan de lo mostrado y requieren ser consideradas en construcciones de buques de combate, siendo una de ellas: LOS GRANDES TIEMPOS, ESCOLLOS, COMPROMETIMIENTO Y ESFUERZOS QUE REQUIEREN ESTOS DESARROLLOS EN BUQUES DE COMBATE. ALGO DE HISTORIA ES NECESARIA =)Fragatas Oliver Hazard Perry (FFG 7) de la Marina de EEUU de 4000 toneladas en un programa en los 1970s de casi 70 buques, fueron denominadas “square pegs”, una
limitación fue su sistema de Control de tiro holandés y altos costos. =)Littoral Combat Ship LCS de la marina de EEUU de 3500 toneladas programa de 50 buques: se creyó erróneamente que un diseño comercial podría adaptarse a buques de combate.

=)Sistema de defensa SSD (Ship Self Defense) de Raytheon para Buques de la Marina de EEUU-estado: 1997 a 2011 Reportes anuales al Congreso de EEUU de 2008, 2009 y
2011 indican: El sistema SSD presenta varias fallas y falta de confiabilidad que no permiten considerarlo operacionalmente efectivo y que cumpla con su objetivo de defensa y SUPERVIVENCIA de buques de superficie vitales en la USN como los CVN (portaviones). El papel de la USN en el proceso de pruebas y evaluaciones de efectividad operacional es vital, e igualmente crítico EL SUMINISTRO POR LA USN DE MEDIOS Y BLANCOS PARA REALIZACIÓN DE LAS PRUEBAS.

CASO DEL SISTEMA DE CONTROL TIRO MK 92 DE LAS FF OLIVER HAZARD PERRI En AA W, preocupación considerable se ha levantado sobre la calidad del FCS Mk-92. Un programa de tres fases para modernización se ha discutido para corregir las degradaciones de la confiabilidad del funcionamiento del sistema y hacer la unidad un recurso más creíble de AAW. La primera fase, actualmente en curso, ha sido el desarrollo y el instalación de una serie de alteraciones de la artillería a los problemas de la confiabilidad observados en operaciones e inspecciones de la flota 6 la segunda fase, actualmente en investigación y desarrollo, exigirá una mejora importante del programa con la formulación de un receptor-transmisor coherente para mejorar el desempeño
sistema del radar.

The spectrum of process complexity These high risk, heavily interconnected systems finally are getting their due. Building games is not like engineering bridges

EL ESPECTRO DE LA COMPLEJIDAD DEL PROCESO
Estos sistemas de alto riesgo y fuertemente interconectados finalmente están recibiendo su merecido. Construir juegos no es como diseñar puentes
 Technology vs requirement
 SIMPLE, COMPLICATED, COMPLEX, ANARCHY
 Simple Processes: When both requirements and execution are quite certain, then the projects can be managed with relatively simple processes. Often a simple checklist does the trick. The repetitive steps that a single worker performs on an assembly line is a good example of a simple task.
 Complicated: When the requirements and execution get out of hand slightly, you end up with a project that can still be completed with your typical check list. However, you need to increase the number of rule and steps necessary to accomplish the task. Bridge building is a good example of a complicated task.
 Complex: Many projects fall into the dangerous middle ground where requirements and execution is somewhat defined, but rife with multiple layers of uncertainty. In these situations, high feedback, agile processes let team steer their way towards ago despite high risk and uncertainty. Software development is a good example of a complex task.
 Chaotic Processes: When both requirements and execution uncertainty is very high, projects tend to devolve into unmanageable chaos. Success arises as often from luck as it does from any real process
Uno de los mitos de mayor trascendencia y efectos es la creencia que cualquier software sirve para simular en desarrollo de buques de combate, sin tener en cuenta para buques de combate , se requiere: simulación en tiempo real, estocástica (probabilística), bases de datos que cubran las amenazas, un espacio para interacción de usuarios, actualizaciones.
La simulación es lo más parecido a la guerra y combate real. Juegos de guerra en la historia humana han sido clave. Demanda enfoque sistémico, largos tiempos, el de la arc requirió a Edgar Romero en orden de 11 años de desarrollo.

SU NO ENTENDIMIENTO LLEVO A HDW EN EL CASO CORBETAS MISILERAS ARC A INMENSOS PROBLEMAS, COMO YA SE HA COMENTADO.
La construcción de buques de combate es una enredada maraña de efectos psicológicos, auspiciada por la complejidad que implica un desarrollo para funcionar en un medio hostil a la vida humana.

EN "LA CONSTRUCCIÓN NAVAL MILITAR, IDEAS PARA SER LIDER", DR. INGENIERO NAVAL. JUAN M. BLANCO-TRABA Y TRABA PRESIDENTE DE ASESMAR (ESPAÑA), XXVII SEMANA DE ESTUDIOS DEL MAR, SE DICE:
LA CONSTRUCCIÓN NAVAL MILITAR SOLO EXISTE DE FORMA SIGNIFICATIVA EN PAÍSES FUERTEMENTE INDUSTRIALIZADOS. SE ESTRUCTURA EN TODOS ELLOS ALREDEDOR DE LÍDERES NACIONALES QUE DOMINAN SUS MERCADOS DOMÉSTICOS (BAE SYSTEMS / VT GROUP EN REINO UNIDO- UK, DCNS EN FRANCIA, THYSSENKRUPP MARINE SYSTEM EN ALEMANIA, NAVANTIA EN ESPAÑA, FINCANTIERI EN ITALIA, DAMEN EN HOLANDA O GENERAL DYNAMICS/NORTHROP GRUMMAN EN EE.UU). OTROS CASOS PODRÍAN
INCLUIRSE.

Se trata de una industria muy intensiva tanto en capital como en exigencia tecnológica y que presenta altas barreras de entrada. Tiene un alto grado de dependencia de un único cliente, que es el ministerio de defensa y en consecuencia de sus asignaciones presupuestales.

UNA CARACTERÍSTICA CLARAMENTE DIFERENCIAL CON LA CONSTRUCCIÓN NAVAL MERCANTE, ES EL LARGO PERIODO DE GESTIÓN QUE PRECISAN LOS PROGRAMAS
NAVALES MILITARES. LA CAUSA PRINCIPAL DEL LARGO PERIODO DE GESTIÓN SE DERIVA DE LA METODOLOGÍA DE DESARROLLO.

se emplea una metodología reciente para programas navales complejos. para los astilleros, esta sofisticación de los buques combatientes trae consigo la aplicación de un esfuerzo considerable en i+d+i, a la vez que provoca en el desarrollo de este tipo de  proyectos de buques de guerra una fuerte dependencia externa https://www.computer.org/csdl/magazine/co/2022/06/09789303/1DZ8cftUOkM El grupo Standish ha estado compilando informes CHAOS sobre el estado de finalización /
éxito / fracaso de proyecto desde 1994. En 1994, se informó que Estados Unidos había gastado US $ 81 mil millones en proyectos cancelados (US $ 250 mil millones en proyectos en total). En otras palabras, en 1994, el 53% de los proyectos costaron el 189% del presupuesto original, el 16% llegó a tiempo y dentro del presupuesto, y el 31% no se completó (Tabla 1).

Veamos ahora 2020. ¿26 años de datos muestran mejoras en la experiencia en gestión de proyectos (por ejemplo, más gerentes de proyectos "certificados", mejor capacitación y herramientas, y el uso efectivo de métricas)? No es que podamos decirlo; Los datos de 2020 muestran que, aunque casi duplicamos el éxito hasta el 31%, la mitad de los proyectos siguen siendo cuestionados Una posible razón puede ser porque las complejidades del proyecto y del sistema han aumentado, mientras que el tiempo de entrega se ha reducido Revisiting Software Metrology Joanna F. Defranco , The Pennsylvania State University. Jeffrey Voas , IEEE Fellow JUNE 2022 SUCCESSFUL exitoso CHALLENGED fallas en tiempos, costos y funcionalidad.

TABLE 1. Project data over the years

Existencia de Complejidad y Cono de Incertidumbre es inherente en desarrollo de software y demanda manejo por fabricantes y expertos: lo sucedido en el caso de corbetas ARC en HDW, fue reemplazo por HDW de especialistas para un manejo de reducción de costos. Hasta que por exigencia de la Comisión de la ARC fueron involucrados los fabricantes, se hizo correcciones- manejo de pruebas operacionales y los problemas fueron resueltos a costo del Astillero HDW.
COMO SE OBSERVA: LA SITUACIÓN DE DIFICULTAD EN DESARROLLO DE SOFTWARE, PERSISTE ACTUALMENTE AFECTANDO PRINCIPALMENTE SISTEMAS DE ARMAS Y
ELECTRÓNICA, Y AL IGUAL QUE SIEMPRE SU MANEJO ES NECESARIO, NO HACER NADA NO ES SOLUCIÓN, GERENCIA EXPERIMENTADA SE REQUIERE.
Los casos reales fallidos aquí presentados (Litoral Combat Ship LCS, Sistema de defensa SSD (Ship Self Defense) de Raytheon) son demostración de los niveles que se pueden alcanzar en caso de no actuar.
Esto implica Ingeniería Sistémica, centrado en redes, juegos de guerra y modelos y simulaciones, Planeamiento de Fuerzas, especificaciones de pruebas incluidas de Evaluación Operacional, especificaciones militares. Demanda similar alcance de conocimiento al concepto empleado por ARC durante construcción corbetas misileras ARC. Lo cual no se improvisa.
"EN ESPAÑA Y A PESAR DEL GRAN ESFUERZO DE NACIONALIZACIÓN REALIZADO POR EL ASTILLERO Y LA INDUSTRIA ELECTRÓNICA NACIONAL DE DEFENSA, EN PROGRAMAS COMO EL DE LA FRAGATA F-100, SE MANTUVO UNA FUERTE DEPENDENCIA DE EQUIPOS DE IMPORTACIÓN, CON GRAN INFLUENCIA EN LA PLANIFICACIÓN GENERAL DEL PROGRAMA".

67% del Total de Horas-Hombre de 7.1R hasta Octubre de 2006 se emplearon en pruebas y correcciones a problemas descubiertos durante las pruebas OPEN SYSTEMS ENABLING SURFACE NAVY FLEET OPEN, HERREN ARCHITECTURE THRU SYSTEMS ENGINEERING. HERREN SYSTEMS THINKING. SMARTER SOLUTIONS. AND ANALYSIS PROCESS IMPROVEMENTS
L3HARRIS OPEN SYSTEMS: THE KEY TO MAINTAINING MARITIME DOMINANCE. From processing to platforms, L3HARRIS provides the open systems technology the U.S. Navy
relies on to stay ahead of rapidly evolving threats.

EN LA US NAVY: ASSESSING AEGIS PROGRAM TRANSITION TO AN OPEN-ARCHITECTURE MODEL

ARQUITECTURA ABIERTA DEFINICION
Informalmente, un sistema de arquitectura abierta es aquel para el cual el cambio y el crecimiento de la funcionalidad y la capacidad se pueden lograr con un costo y un impacto mínimos mediante componentes de sistema existentes mediante el uso de estándares de hardware y software de sistema ampliamente aceptados, componentes de aplicación
estándar e interfaces bien definidas.
Más formalmente, desde la Oficina del Secretario de Defensa, un sistema abierto "implementa suficientes especificaciones no propietarias para interfaces, servicios y formatos de soporte para permitir que los componentes diseñados adecuadamente se utilicen en una amplia gama de sistemas con cambios mínimos, para interoperar con otros componentes en sistemas locales y remotos, e interactuar con los usuarios en un estilo que facilite la portabilidad".

WIKIPEDIA ARQUITECTURA ABIERTA es un tipo de arquitectura de ordenadores o arquitectura de software que permite añadir, modernizar y cambiar sus componentes. Por
ejemplo, el IBM PC tiene una arquitectura abierta, mientras que el ordenador personal Amiga 500 tiene una arquitectura cerrada, donde el fabricante del hardware escoge los componentes, y normalmente no son actualizables.
La arquitectura abierta permite a los potenciales usuarios ver el interior de todo o parte de la arquitectura sin ninguna restricción propietaria. Los procesos de negocio abiertos relacionados con una arquitectura abierta pueden necesitar de algunos acuerdos de licencia entre las entidades que comparten la información de la arquitectura.

MOSA: UN CAMBIO DE PARADIGMA PARA LOS SISTEMAS MILITARES
La mayoría de los sistemas militares de la nación, pasados y presentes, son como rompecabezas. Cada uno está compuesto por cientos de piezas únicas que se unen de maneras específicas e invariables. Las piezas no están diseñadas para ser reconfiguradas o utilizadas indistintamente, lo que hace que estos sistemas tipo rompecabezas sean muy difíciles y costosos de modificar.
MOSA cambia este paradigma de diseño. Básicamente, reemplaza las piezas del rompecabezas con Legos en la ecuación de ingeniería sistémica para la tecnología de defensa, favoreciendo los componentes estandarizados (que pueden ensamblarse de muchas maneras, desmontarse nuevamente y reutilizarse para hacer nuevos diseños) sobre los bloques de construcción tecnológicos a medida.
Este enfoque para diseñar sistemas asequibles y adaptables exige que las interfaces de sistemas clave se ajusten a estándares ampliamente aceptados, respaldados y basados en el consenso, independientemente de un proveedor en particular. Como resultado, la tecnología se puede agregar, eliminar o reemplazar gradualmente a lo largo del ciclo de vida del sistema, lo que permite al sistema seguir el ritmo del entorno de seguridad global en rápida evolución.

EN "LA CONSTRUCCIÓN NAVAL MILITAR, IDEAS PARA SER LIDER", DR. INGENIERO NAVAL JUAN M. BLANCO TRABA Y TRABA PRESIDENTE DE ASESMAR (ESPAÑA), XXVII SEMANA DE ESTUDIOS DEL MAR, SE DICE:
LA CONSTRUCCIÓN NAVAL MILITAR SOLO EXISTE DE FORMA SIGNIFICATIVA EN PAÍSES FUERTEMENTE INDUSTRIALIZADOS. SE ESTRUCTURA EN TODOS ELLOS ALREDEDOR DE LÍDERES NACIONALES QUE DOMINAN SUS MERCADOS DOMÉSTICOS (BAE SYSTEMS / VT GROUP EN REINO UNIDO- UK, DCNS EN FRANCIA, THYSSENKRUPP MARINE SYSTEM EN ALEMANIA, NAVANTIA EN ESPAÑA, FINCANTIERI EN ITALIA, DAMEN EN HOLANDA O GENERAL DYNAMICS/NORTHROP GRUMMAN EN EE.UU).

CON ESTA BASE EXISTEN ECOSISTEMAS O CLÚSTERS (concentración de empresas e instituciones interconectadas en la actividad que desarrollan), INDEPENDIENTES CON BASE
EN CADA UNO DE LOS DIFERENTES DESARROLLOS INDUSTRIALES CITADOS. Cada uno enfrenta los resultados por desarrollo de software y cono de incertidumbre,
como se mostró, por ejemplo: mediante 67% del Total de Horas-Hombre de 7.1R hasta Octubre de 2006 se emplearon en pruebas y correcciones a problemas descubiertos durante las pruebas.
Esto presenta un entorno favorable para el desarrollo, dentro de cada grupo, pero las amenazas y Planeamiento de Fuerzas son propias de cada Marina de Guerra Nacional.

ALGUNAS CARACTERISTICAS DE COMPLEJIDAD SON: COMPLICADO vs COMPLEJO: causa efecto vs efectos no lineales, azar vs probabilidad, control vs atractor, supervisión vs auto organización, cambio vs Darwinismo Organizacional. En complejidad el todo es más que suma de partes, la predicción es IMPOSIBLE.

En nuevos programas de desarrollo de buques de combate, para cualquier Marina de Guerra Nacional, inmenso trabajo tiene por delante, desarrollar temas como los siguientes: definición de pruebas (Fabrica, Puerto, Mar y Evaluación Operacional), según amenazas establecer defensa y parte ofensiva; empleo de Juegos de Guerra y Modelos y
Simulaciones para el caso específico de la Marina de Colombia.
Experiencias indican como mejor camino: conformación y establecimiento de grupos de Investigación de Operaciones y Análisis de Sistemas y Operaciones, con base en Planeamiento de Fuerzas y gerencia con enfoque sistémico, manejo de complejidad y Efectividad vs costos y riesgos.

LA CLAVE DE LA PREPARACION PARA DESARROLLO DE BUQUES DE COMBATE ES: DISEÑAR, INTEGRAR Y GERENCIAR SISTEMAS COMPLEJO

VER HISTORIA CORBETAS MISILERAS ARC
https://www.eromerovdominio.com/conscorbe28/conscorbe28.html