INGENIERÍA DE SISTEMAS, ORIGEN E IMPLICACIÓN MILITAR. SISTEMA DE SISTEMAS, EVOLUCIÓN HACIA UN ENFOQUE MULTISISTÉMICO. INGENIERÍA DE SOFTWARE Y GESTIÓN DE LA CONFIGURACIÓN COMO ELEMENTOS VERTEBRADORES DE LA INGENIERÍA DE SISTEMAS.

Un sistema es un conjunto dinámico de elementos en interrelación según von Bertalanffy. Las nuevas redes de comunicación en la toma de decisiones, los nuevos fenómenos organizativos; la apertura de la industria a nuevas perspectivas a partir de la exploración científica, hace que en este caso el dinamismo en la definición de sistema marque de manera inexorable la importancia vital de la Ingeniería de Sistemas en la resolución de problemas a partir del planteamiento de necesidades.

En los comienzos del siglo XX parte de la comunidad científica empezó a darse cuenta que no todo podía emprenderse con el enfoque reduccionista. Algunas cosas tenían que verse como un todo para que no perdiera su razón de ser. Este nuevo enfoque se conoció como enfoque sistémico, del cual es inherente al mismo la visión de conjunto, las alternativas de solución y las interrelaciones, conceptos todos ligados a la Ingeniería de Sistemas.

El Departamento de Defensa de los Estados Unidos de América (DoD) en referencia a la Ingeniería de Sistemas indica lo siguiente:

“La Ingeniería de Sistemas comprende dos importantes disciplinas: el dominio de conocimiento técnico en el que opera el ingeniero de sistemas y la gestión de ingeniería de sistemas”.

La primera vez que se acuñó el término Ingeniería de Sistema fue en la década de los cuarenta en los laboratorios Bell, donde los complejos proyectos llevados a cabo por el DoD, la NASA y la industria estadounidense durante la Segunda Guerra Mundial marcaron la necesidad de aplicar un enfoque sistémico.

El análisis de sistemas inducido a la Ingeniería de Sistemas está vinculado a la investigación operativa que no es más que el «conjunto de métodos y técnicas de análisis destinados a la toma de decisiones». Esto incluye métodos de control numérico, fenómenos aleatorios, fiabilidad, control de calidad, teoría de grafos,…

Dos ejemplos claros del análisis de sistemas aplicados a problemas militares durante la Segunda Guerra Mundial son:

La disposición de los radares de vigilancia durante la Batalla de Inglaterra a partir de métodos matemáticos.

Dimensionamiento óptimo de los convoyes marítimos aliados para reducir las pérdidas por ataques de submarinos enemigos.

El propósito de la Ingeniería de Sistemas es obtener un sistema que satisfaga de forma eficaz y eficiente las necesidades del cliente reduciendo los riesgos y el coste del ciclo de vida, teniendo como actividades principales el: análisis de requisitos, el análisis funcional y el diseño.

Hoy en día la Ingeniería de Sistemas abarca un sinfín de disciplinas como pueden ser la gestión y control de proyectos, especificaciones de requisitos, análisis de decisiones, modelado, simulación de sistemas, ingeniería de software, redacción de especificaciones, gestión del riesgo, relaciones interpersonales o estimaciones de costes entre otras.

Es importante no confundir la Gestión de Proyectos con la Ingeniería de Sistemas, aunque ésta pueda incluir a la primera en ocasiones, la Gestión de Proyectos debe centrarse en la adquisición de recursos, personal, herramientas, financiación, … y por supuesto en la gestión de los mismos. Mientras tanto, la Ingeniería de Sistemas es responsable de la utilización eficaz de los recursos (que proporciona la Gestión de Proyectos) y de que el sistema satisfaga las necesidades últimas del cliente.

El perfil tipo de un ingeniero de sistemas responde hoy en día a la:

• Definición de requisitos.
• Diseño de arquitecturas.
• Verificación y validación del sistema.

En definitiva, el ingeniero de sistemas debe transformar las necesidades del cliente en una solución viable. Para ello es importante escuchar a usuarios y clientes, tomar buena nota de lo que dicen y poder transformar esas necesidades, casi siempre intangibles, en requisitos técnicos, en elementos concretos.

En pleno siglo XXI no se entiende la Ingeniería de Sistemas sino es a partir de un equipo multidisciplinar incluso trabajando con actores externos en pro de buscar todo el conocimiento necesario.

Analizar, examinar e investigar funciones y características de los sistemas con el fin de mejorar el sistema final y que sea aceptable económicamente hablando pudiendo ser mantenido a lo largo del ciclo de vida.

En el plano del Diseño, un ingeniero de sistemas no debe dejar de escudriñar para buscar nuevas relaciones entre recursos y datos y desde luego comunicar las posibles interferencias o los nuevos hallazgos.

Evidentemente todo esto no es posible sin una visualización inicial con carácter general de lo que debe ser el sistema final que responde a un producto real y para un cliente concreto.

Los sistemas de armas son cada vez más y más complejos. El carro de combate Abrahams M1A1 necesitó más de 40000 páginas de manuales técnicos y más de 800 planos de ingeniería. El buque USS Vincennes de la clase Ticonderoga requirió 23,5 toneladas de papel en documentación. El caza F-16, también estadounidense, más de 3500 manuales técnicos diferentes.

El incremento de la complejidad de los sistemas, concretamente en el ámbito militar después de la Guerra Fría ha dado lugar a lo que se conoce como Sistema de Sistemas (SoS), esto es, un sistema tan complejo que sus componentes son otros sistemas. Son sistemas integrados a gran escala, independientes unos de otros pero que se encuentran conectados entre sí, beneficiándose unos de otros en pro de una mejor solución para un objetivo final común. Hemos saltado la barrera del enfoque sistémico para hablar ahora de un enfoque multisistémico.

Los  SoS responden al concepto NCW (Network Centric Warfare) en el que una red de información une diferentes componentes, por ejemplo, sensores, sistemas de armas, nodos de comunicación de mando y control, … con la ventaja de que pueden estar dispersos entre sí. En definitiva une dispositivos independientes con el objetivo de agilizar la toma de decisiones.

¿Puede la Ingeniería de Sistemas afrontar el desafío de la complejidad que representan el Sistema de Sistemas?¿Puede afrontar los retos de los nuevos programas militares conocidos como Iniciativa de Defensa Estratégica (SDI) popularmente conocidos como Guerra de las Galaxias?

La respuesta es sí, pero para ello debe definir un nuevo Concepto de Operaciones del Sistema Completo, esto es, definir cómo tiene que trabajar todo el sistema, una “gestión 360º”, gestionando las funcionalidades de la misión, las funcionalidades de los recursos y de la viabilidad.

Esta nueva respuesta de la Ingeniería de Sistemas a los nuevos retos de la Defensa y que ligan con la idea de satisfacer una solución viable a los SoS viene dada por el nuevo modelo de contratación de las diferentes agencias de defensa de los diferentes países orientados cada vez más a la búsqueda de capacidades más que de sistemas que contrarresten la amenaza.

Al hablar de capacidades militares hablamos de equipamiento, doctrina, logística, entrenamiento, infraestructura, organización… y la interoperabilidad de todo ello, de la integración y del beneficio mutuo de la interrelación de unos con otros y esto nos lleva de nuevo a un Sistema de Sistemas.

De un buen funcionamiento de un SoS dependerá el éxito de la misión. Los sistemas C2, de los que se habló en un artículo anterior, ponen en relación comunicaciones, electrónica, informática, mecánica… y la complejidad inherente de estos sistemas hace que algo en algún momento y según las circunstancias pueda fallar o no, provocando más incertidumbre y más riesgo de lo que la misma misión entraña. Por ello, un sistema de sistemas tiene que dar más de sí que la mera suma de sus componentes. ¿Quién liga todo esto? La Ingeniería de Software.

La Ingeniería de Software es el hilo conductor de los SoS y su misión es la preparación para hacer frente a la incertidumbre en un entorno donde no hay capacidad de reacción ante los fallos.

La primera vez que se utilizó el término Ingeniería de Software fue en 1967 ante un grupo de estudio de la OTAN y fue dicho por el Dr. Richard Thayer. El grupo se formó a raíz de la denominada “crisis del software” donde se intentaba poner remedio a los problemas causados en el desarrollo del software, algo nuevo en aquella época.

El Dr. Thayer afirmó, no sin cierto estupor ante los asistentes, que el problema del software radicaba en la falta de un proceso de fabricación claro y que lo que se necesitaba era una Ingeniería del Software. El 7 de octubre de 1968 tenía lugar la primera conferencia sobre Ingeniería de Software en Garmisch, Alemania.

Se puede definir la Ingeniería del Software como:

“El establecimiento y aplicación de los principios de ingeniería para obtener, de forma económica, software fiable que funcione en máquinas reales”.

La dificultad de producir software fiable en la actualidad sigue siendo una tarea hercúlea por la dificultad de comprender, expresar y comunicar todos los estados existentes implicados en nuestro sistema, algo que hace la tarea prácticamente inviable y que es causa de constantes retrasos.

La variabilidad a la que está sometido el software, es decir, la constante presión a la que se ve sometida el personal de esta área para cambiar el software en un sentido o en otro en función de nuevas expectativas, nuevos procesos, o por la creencia de que es más fácil modificar el software que otros procesos mecánicos, de diseño, funcionales, etc… y por lo tanto aceptar los errores en estos campos casi como una constante con tal de que una modificación del software resuelva el problema final no sin un cierto alejamiento de la premisas originales se debe a que el software es algo intangible y es concebido como algo infinitamente maleable y por tanto sencillo de modificar.

La ingeniería del Software responde como la Ingeniería de Sistemas a unos requisitos. Estos requisitos según el Dr. Thayer en el Software Requirements Engineering Concepts tienen que ser: completos, consistentes, claros, modificables, verificables y trazables.

Estas características de los requisitos software están en consonancia con las directrices de normas como la IEEE830 en donde se recomienda: requisitos completos y no ambiguos, sin embargo encontramos aquí el primero de innumerables escollos.

La Ingeniería de Software, como los Sistemas de Información en el ámbito de la Ingeniería de Sistemas en el entorno de proyectos militares son los más perjudicados por la incertidumbre.

Se ha hablado del software en términos de incertidumbre, de algo intangible y sin embargo le exigimos claridad, trazabilidad y consistencia, algo que por supuesto casi nunca se cumple por lo que pocas veces se siguen las normativas, pues de cumplirlas el proyecto sería inviable por el tiempo y recursos consumidos.

La exigencia de exactitud en la Ingeniería del Software provoca retrasos y no permite dejar atrás el enfoque cartesiano impidiendo que la incertidumbre sea parte de la solución como hacen otras disciplinas por ejemplo la Física o la Economía aún sabiendo que es precisamente la incertidumbre lo que convierte a la Ingeniería del Software en algo muy diferente a las disciplinas tradicionales o clásicas de la Ingeniería.

En ausencia de incertidumbre los problemas son sencillos, se pueden descomponer según un árbol de configuración detallado y único, mientras que aceptando la incertidumbre como parte de la naturaleza de los problemas, éstos se pueden complicar hasta el infinito.

Por eso, llegados a este punto es necesario admitir la incertidumbre en las soluciones a los problemas planteados y por lo tanto admitir cierto riesgo en la toma de decisiones y admitir ciertas consecuencias desfavorables como posibles.

La clave de la incertidumbre radica en cómo de exacta podemos responder a la siguiente pregunta.

¿Hasta dónde se puede conocer el problema sin experiencia previa del cliente y el diseñador?

Un SoS real se basa en problemas desconocidos e inestables donde la incertidumbre como parte de la solución es inevitable.

La Ingeniería de Sistemas se dedica a los sistemas. Pero los sistemas evolucionan, son dinámicos como apuntábamos al principio. Evolucionan desde una fase inicial de requisitos hasta la puesta en producción y desde ésta hasta la baja del sistema ¿Cómo controlar la evolución continua del sistema?

La Gestión de la Configuración proporciona una visión de conjunto de la evolución del sistema y por lo tanto la herramienta más eficaz para controlar su dinamismo.

La configuración de un sistema es el conjunto de sus características tenidas en cuenta en un árbol de configuración formado por elementos que son susceptibles de ser analizados y estar perfectamente documentados pudiendo establecer su trazabilidad.

Ante la evolución continua del sistema, surge en ocasiones la necesidad de parar y analizar el producto en un momento dado. Esta imagen fija se denomina línea de referencia y va acompañada de toda la información y documentación necesaria. La línea de referencia puede ser funcional, de desarrollo o de producto, según se fijen especificaciones, se desarrollen dichas especificaciones o bien se analice toda la documentación final del producto.

La Gestión de la Configuración es por tanto el proceso por el cual se establecen procedimientos que aseguren la consistencia de las características físicas y funcionales de los elementos que componen un sistema, así como de la documentación que los describe a lo largo de todo el ciclo de vida.

La gestión de la Configuración durante el periodo de desarrollo del producto involucra cuatro actividades principales a saber:

Identificación de la configuración.

El objetivo en este punto es seleccionar y determinar la estructura de los elementos a configurar. Determinar la documentación necesaria. Documentar las características físicas y funcionales de los elementos y sus cambios. Establecer las nomenclaturas para las identificaciones individuales.

Control de la configuración.

Es la más conocida y trata sobre la propuesta, justificación, evaluación, coordinación, aprobación o desaprobación sistemática de las propuestas de cambio a un elemento de configuración después del establecimiento de una línea de referencia.

Registro de la configuración.

Se inicia tan pronto se genera la primera documentación relacionada con la gestión de la configuración. Se incluyen registros de las incidencias, fallos y propuestas de cambios, concesiones, etc.

Auditorías de la configuración.

La gran carga de documentación que genera la gestión de la configuración hace que si la documentación necesaria no se actualiza se corromperá el sistema por quedar la documentación desfasada. Las auditorías son comprobaciones más o menos formales que examinan prácticas y procesos.

La gestión de la configuración es una tarea ardua que exige dedicación, precisión y organización, sobre todo en aquellos proyectos militares y muy especialmente los relacionados con los sistemas de información. Algunos de los estándares militares y comerciales utilizados para tal fin se muestran a continuación.

Los estándares actuales, aunque son los mejores, no son suficientes, mantienen limitaciones y ambigüedades. Por otra parte las empresas y universidades no emplean el tiempo suficiente o ninguno para formar a ingenieros en esta materia y por último, la tecnología ha sido siempre el motor que ha ido impulsando los cambios en esta disciplina y como estos cambios son continuos, la industria en cuanto a la ingeniería de sistemas no ha gozado de estabilidad para afianzarse en las nuevas técnicas.

Sin embargo, todo lo que involucra la Ingeniería de Sistemas aquí resumido en tres bloques (Ingeniería de Sistemas, Ingeniería de Software y Gestión de la Configuración) es una realidad evidente y la mejora de los Proyectos de Defensa pasan inexorablemente por la mejora exhaustiva de esta rama de la ingeniería que proporcionará ventajas evidentes para una fabricación flexible integrada, pero eso es otra historia.