5 Ingenieria de Sistemas Aplicada

        

Otros títulos publicados:                 

1. Ingeniería de Sistemas. Benjamin S. Blanchard. 2. La Teoría General de Sistemas. Ángel A. Sarabia. 3. Dinámica de Sistemas. Javier Aracil. 4. Dinámica de Sistemas Aplicada. Ronald R. Drew. 5. Ingeniería de Sistemas Aplicada. Isdefe. 6. CALS (Adquisición y apoyo continuado durante el ciclo de vida). Rowland G. Freeman III .



            

     

     

    



                           

       

            

        

          

                   



   

      

 

     

    



    

 

Isdefe ha acumulado, en estos primeros diez años, más de 1.6 millones de horas de ingeniería colaborando en diferentes programas, en las áreas de mando y control, apoyo logístico, telecomunicaciones, tecnologías de la información, navegación aérea, investigación operativa, simulación, seguridad, protección del medio ambiente, y formación de personal, siempre bajo la perspectiva del enfoque sistémico. Aproximadamente un 70 % de esas horas han correspondido a programas del sector defensa y el 30 % restante al sector civil. El objetivo de esta monografía es resumir l a experiencia adquirida por Isdefe en el campo de la ingeniería de sistemas. Para ello se han seleccionado once de los principales programas en los que se ha participado, de tal forma que con ellos se cubran diferentes aspectos o disciplinas de la ingeniería de sistemas y se abarquen, además, las diferentes fases del ciclo de vida de los sistemas.

ILUSTRACIÓN DE PORTADA Torno plano de 1850

1

                                                        

 

                                       

3

Madrid, 15 de septiembre de 1995 Han transcurrido ya diez años desde la creación de Isdefe en 1985 y puede decirse hoy con satisfacción que la empresa ha madurado rápidamente y se ha consolidado como una compañía de ingeniería de sistemas capaz de apoyar eficazmente a las Fuerzas Armadas, al Ministerio de Defensa y en general a la Administración Pública. Los trabajos desarrollados en estos años han permitido consolidar conocimientos y adquirir una experiencia significativa. La serie de monografías que estamos editando está orientada a divulgar los fundamentos de la ingeniería de sistemas. Sus autores son profesionales cualificados que explican, de forma clara y sencilla, los aspectos básicos de la ingeniería de sistemas y sus disciplinas asociadas. La intención de la monografía que ahora se presenta es reflejar, de forma coherente con la serie en la que se integra, actuaciones de ingeniería de sistemas realizadas por Isdefe para Isdefe para la Administración española, donde se refleja parte de la experiencia vivida durante estos primeros diez años de andadura, en este apasionante campo. Quiero agradecer al personal de la empresa que está colaborando con la serie y especialmente a los autores de las monografías y a los miembros del Comité de Redacción, la ilusión volcada en este proyecto.

José Vicente Cebrián Consejero Delegado de Isdefe

4

INGENIERÍA DE SISTEMAS APLICADA

5

ÍNDICE GENERAL 1.

INTRODUCCIÓN (Alberto Sols Rodríguez-Candela ) 1.1. 1.2. 1.3. 1.4. 1.5.

2.

3.

Evolución de la complejidad de los sistemas El enfoque sistémico La creación de Isdefe Experiencia de Isdefe en ingeniería de sistemas Desarrollo de la monografía

5.

10 10 12 13 14

AEGIS: DISEÑO CONCEPTUAL DEL FUTURO SISTEMA DE GESTIÓN DEL TRÁNSITO AÉREO (Trudi Kiebala Xiol )

19

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7.

20 21 21 26 28 28 29

Descripción global del proyecto AEGIS Relación del proyecto con la ingeniería de sistemas Fase 1: evaluación Fase 2: mejora Fase 3: consolidación Valor añadido del proyecto Consideraciones finales

EVALUACIÓN DE DESARROLLOS BASADOS EN UNA NUEVA TECNOLOGÍA: DEMOSTRADOR PlanBA (Rafael García Vázquez ) 3.1. El programa PlanBA 3.2. Evaluación de desarrollos en PlanBA 3.2.1. Identificación de tecnologías relevantes en banda ancha 3.2.2. Identificación de aplicaciones y usuarios de banda ancha 3.2.3. Definición del plan de trabajo para la consecución del demostrador 3.3. Evolución del proyecto integrado PlanBA

4.

9

31 32 33 35 36 37 38

ESPECIFICACIÓN DE REQUISITOS EN EL PROGRAMA MIDS (Luis Rodríguez Palencia )

43

4.1. El sistema MIDS 4.2. El programa MIDS 4.3. Actividades previas a la fase de desarrollo 4.3.1. Preparación de la petición de oferta 4.3.2. Reducción de prestaciones técnicas 4.3.3. Negociación del precio 4.3.4. Establecimiento de la línea base 4.3.5. Seguimiento industrial 4.3.6. Seguimiento de costes 4.3.7. Gestión del espectro radioeléctrico 4.4. Consideraciones finales

44 45 46 46 53 53 54 54 55 55 56

ANÁLISIS DE RIESGOS DURANTE LA EVALUACIÓN DE OFERTAS EN EL PROGRAMA SANTIAGO (Juan José Martínez Dopico )

59

5.1. El programa Santiago 5.2. Análisis de riesgos

60 61

6


6.

7.

8.

9.

5.3. La metodología utilizada 5.3.1. Objetivos 5.3.2. Identificación 5.3.3. Evaluación del impacto 5.3.4. Cuantificación de la probabilidad 5.3.5. Integración 5.3.6. Automatización del proceso 5.4. Consideraciones finales

62 62 63 65 66 67 69 71

PROCEDIMIENTO DE EVALUACIÓN DE OFERTAS EN EL PROGRAMA SIMCA (Jorge Parra Gila )

75

6.1. Descripción general del programa Simca 6.2. Evaluación de ofertas. Metodología 6.2.1. Introducción 6.2.2. Procedimiento de evaluación 6.3. Consideraciones finales

76 78 78 79 88

ANÁLISIS DE VALOR EN LA F-100 (Fernando J. Morales Moreno y José Luis Sánchez Menéndez )

91

7.1. El programa F-100 7.2. Análisis de valor en el programa F-100 7.3. Análisis de costes. Estudios paramétricos 7.3.1. Generalidades 7.3.2. Análisis de costes 7.3.3. Herramienta paramétrica de estimación de costes 7.3.4. Aplicación de los análisis paramétricos de ingeniería de costes en la fragata F-100 7.4. Consideraciones finales

100 102

GESTIÓN DE LA CONFIGURACIÓN EN EL SCTM (Juan Méndez Fariñas )

105

8.1. Programa SCTM 8.2. Gestión de la configuración aplicada al SCTM 8.3. Concepto de gestión de la configuración 8.3.1. Elementos de gestión de la configuración 8.4. Descripción de actividades 8.5. Consideraciones finales

106 107 108 110 113 114

PROCESO DE SELECCIÓN DE EQUIPOS Y SUMINISTRADORES EN EL PROGRAMA EF2000 (José Manuel Buergo Villanueva )

121

9.1. 9.2. 9.3. 9.4. 9.5.

Descripción del programa Participación de la industria española Equipos de avión y accesorios de motor Proceso de gestión del desarrollo Proceso de selección 9.5.1. Principios del proceso de selección 9.5.2. Evaluación y aprobación de especificaciones 9.5.3. Selección de suministradores de equipos 9.5.4. Criterios de evaluación y selección 9.6. Consideraciones finales

92 92 93 93 96 97

122 122 123 125 126 126 127 128 132 138

7

10. VERIFICACIÓN Y VALIDACIÓN EN EL PROGRAMA EUROMAYA (Juan Revuelta Lapique ) 10.1. Descripción del programa Euromaya 10.2. Verificación y validación 10.3. Descripción de actividades 10.3.1. Auditorías e inspecciones 10.3.2. Revisiones 10.3.3. Pruebas 10.4. Consideraciones finales 11. TRANSICIÓN OPERATIVA EN EL PROGRAMA SACTA (Miguel Baragaño Fueyo ) 11.1. Descripción del programa SACTA 11.2. Transición operativa 11.2.1. Características generales 11.2.2. Planificación de la transición 11.2.3. Preparación de la transición 11.2.4. Ejecución de la transición 11.3. Ejemplo de transición (Madrid) 11.4. Consideraciones finales

141 142 145 147 148 149 150 153 157 158 161 161 162 164 165 165 166

12. SISTEMAS DE GESTIÓN INTEGRADA DEL PROGRAMA TLE (Álvaro Manresa Sánchez )

169

12.1. Introducción 12.2. Descripción del programa TLE 12.2.1. Objetivo 12.2.2. Situación actual del programa 12.3. La gestión del programa TLE 12.3.1. Ingeniería y gestión 12.3.2. Colaboración de Isdefe en el programa TLE 12.3.3. El sistema de gestión integrada del programa TLE 12.3.4. Elementos del diseño del sistema de gestión 12.3.5. Proceso de datos y generación de informes

170 170 170 171 172 172 173 174 174 180

13. EPÍLOGO (Alberto Sols Rodríguez-Candela )

187

13.1. Introducción 13.2. La rueda es redonda y rueda bien 13.3. Resumen de lecciones aprendidas 13.4. Kaizen

188 188 189 193

REFERENCIAS

195

BIBLIOGRAFÍA

199

GLOSARIO

203

8


9

1 Introducción

10


1.1. Evolución de la complejidad de los sistemas En su apasionante novela «2001: Una odisea del espacio» [1], Arthur C. Clarke narra la evolución de la especie humana desde el despertar de la inteligencia en los pre-homínidos, en la Noche Primigenia, a los viajes de la era espacial de un futuro próximo. Carl Sagan, en su ensayo científico «Los dragones del Edén» [2], muestra que la lentitud de desarrollo de la especie humana viene compensada por una extraordinaria capacidad de aprender y crear cosas. Ambos autores ponen de manifiesto el potencial del hombre para diseñar y desarrollar cosas cada vez más complejas. Entre las hachas de piedra del Paleolítico y los transbordadores y estaciones espaciales de nuestros días no sólo median dos millones de años, sino un incremento colosal en la complejidad de los sistemas diseñados por el hombre. Esa complejidad crece exponencialmente, de forma que la mayoría de los diseños de hace unas pocas décadas están hoy tecnológica y funcionalmente obsoletos. Con ello ha ido aumentando nuestra necesidad de un modelo o paradigma capaz de posibilitar el diseño y desarrollo de sistemas.

1.2. El enfoque sistémico Tanto el concepto de sistema como el modelo empleado para su estudio ha evolucionado notablemente con el tiempo [3]. Desde mediados

11 Introducción

del presente siglo el paradigma empleado en la conceptualización de sistemas es el denominado enfoque sistémico, que aporta frente a su predecesor (el enfoque reduccionista de la Revolución Industrial) la consideración explícita de que un sistema lo componen no sólo sus partes integrantes, sino también las interrelaciones interre laciones entre ellas. Esa «no independencia» de las partes es una de las características fundamentales del enfoque sistémico, distinguido además por su consideración del ciclo de vida de los sistemas. La Figura 1.1 muestra la relación entre la cantidad y calidad de la información disponible sobre un sistema a lo largo de su ciclo de vida, así como la trascendencia e importancia de las decisiones de cisiones tomadas en cada fase. La relación entre los costes incurridos incurrido s y los compromisos contraídos (coste, tecnología, arquitectura del sistema, etc.) se muestra en la Figura 1.2. El hecho de que en las fases iniciales la información sobre el sistema sea relativamente escasa y poco precisa y que las decisiones adoptadas sean las más importantes, por todos

12


los compromisos que al tomarlas se contraen, hace especialmente importante la consideración, desde esas etapas etapa s iniciales, del conjunto del sistema como algo dinámico a lo largo de un ciclo de vida; es decir, es esencial un enfoque sistémico. 1.3.. La creac 1.3 creació ión n de Isde Isdefe fe En el final de la década de los 70 se vivió un fuerte aumento de la relación de nuestr nue stras as Fuerzas Armadas con las de otros países. Ello puso de manifiesto ciertas carencias y limitaciones, que era preciso solventar de cara a posibilitar su auténtica integración en foros internacionales. Se emprendió así un ambicioso proyecto de modernización de las Fuerzas Armadas. Dentro de esa nueva maquinaria que se iba concibiendo en esos años como el futuro Ministerio de Defensa, con capacidades

13 Introducción

equivalentes a las de los países aliados, se detectaron numerosos engranajes nuevos que se hacían necesarios. ne cesarios. Uno de ellos, destinado a contribuir como un elemento más a la modernización y capacitación tecnológica de las Fuerzas Armadas, era una ingeniería propia de defensa, del estilo de las existentes en otros países tales como Estados Unidos y Alemania. Como consecuencia de todo ello, Isdefe fue creada en Septiembre de 1985, por acuerdo del Consejo de Ministros, para apoyar en trabajos de ingeniería de sistemas y en consultoría a organismos de la Administración, especialmente al Ministerio de Defensa y a las Fuerzas Armadas. Entre las misiones de Isdefe destacan el ayudar a la definición técnica de las necesidades que determinen operativamente los Estados Mayores; el apoyar en la elaboración de las especificaciones técnicas de los sistemas, el análisis de las ofertas y el seguimiento de los programas; el colaborar en la ordenada planificación de las adquisiciones de Defensa; el disponer de un personal de alta cualificación en tecnologías específicas; y el hacer extensivas esas capacidades al resto de la Administración en sistemas relacionados con la seguridad nacional. La propia concepción de Isdefe como un engranaje más de esa gran maquinaria de relojería que debía ser el Ministerio de Defensa pone de manifiesto la excelente visión sistémica de los «relojeros» que diseñaron la maquinaria, que ciertamente demostraron ser mucho menos «ciegos» que nuestro relojero genérico del cuadernillo de presentación de esta serie de monografías. 1.4. Experie Experiencia ncia de de Isdefe Isdefe en ingen ingeniería iería de sistemas sistemas Isdefe ha acumulado, en estos primeros diez años, más de 1.6 millones de horas de ingeniería colaborando en diferentes programas, en las áreas de mando y control, apoyo logístico, telecomunicaciones, tecnologías de la información, navegación aérea, investigación operativa, simulación, seguridad, protección del medio ambiente, y formación de personal, siempre bajo la perspectiva del enfoque

14


sistémico. Aproximadamente Aproximadamente un 70% de esas horas han correspondido a programas del sector defensa y el 30% restante al sector civil. Si la cuarta monografía de esta serie, Dinámica de Sistemas Aplicada [4], Aplicada [4], ilustra a través de varios ejemplos la aplicabilidad de Sistemas (expuesta de forma conceptual en la tercera la Dinámica de Sistemas (expuesta monografía) [5] tanto en el sector defensa como en el civil, esta monografía refleja aplicaciones concretas en la Administración española y en la europea de algunos de los aspectos del proceso descrito en la primera monografía de la serie, Ingeniería de Sistemas [6]. Sistemas [6]. El objetivo de esta monografía es resumir la experiencia adquirida por Isdefe en el campo de la ingeniería de sistemas. Para ello se han seleccionado once de los principales programas en los que se ha participado, de tal forma que con ellos se cubran diferentes aspectos o disciplinas de la ingeniería de sistemas y se abarquen, además, las diferentes diferente s fases del ciclo de vida de los sistemas. La Figura 1.3 muestra los programas seleccionados para ilustrar la experiencia adquirida, indicándose además el aspecto a resaltar de cada uno en la fase correspondiente del ciclo de vida. 1.5. Desa Desarro rrollo llo de la mono monogra grafía fía Cada uno de los siguientes once capítulos ilustra un aspecto relacionado con la ingeniería de sistemas, sistemas , a través de su desarrollo concreto en uno de los programas seleccionados. En primer lugar se describe el objeto y naturaleza del programa, indicando la fase del ciclo de vida en la que actualmente se encuentra. Seguidamente Seguidame nte se indica la faceta a resaltar y su integración en el proceso de ingeniería de sistemas, sistemas , especificando la fase en la que se materializó la colaboración de Isdefe en el programa. Finalmente se describen las actividades realizadas en relación con la faceta seleccionada. No se pretende describir en detalle los programas seleccionados,

15 Introducción

16


sino reflejar las actividades realizadas en ellos por Isdefe en relación con aspectos concretos de la ingeniería de sistemas, salvaguardando siempre aquellos de naturaleza clasificada o sensible. Algunos programas abarcan, en su desarrollo real, varias fases del ciclo de vida. Aquí sólo se muestra alguna de ellas (para cada uno), a fin de dar cabida a diferentes ámbitos y programas. En el Epílogo se resumen las lecciones aprendidas, fruto de las colaboraciones de Isdefe en los programas en los que ha participado. El proceso de ingeniería de sistemas descansa en modelos matemáticos y, como dijo Einstein, «en la medida en la que los modelos matemáticos reflejan la realidad no son ciertos, y en la medida en la que son ciertos no reflejan la realidad». Los paradigmas o modelos empleados se mantienen en tanto en cuanto la experiencia práctica acumulada en su utilización los confirma y refuerza; la detección de deficiencias o limitaciones implica una modificación de los modelos y, eventualmente, su evolución a otros. Un modelo conceptual o teórico carece de valor si no está respaldado por la evidencia de la práctica. Como dice el refrán inglés, la prueba del pudding está en comérselo.

17 Introducción

18


19

2 AEGIS: Diseño conceptual del futuro sistema de gestión del tránsito aéreo

20


2.1. Descripción global del proyecto AEGIS En los últimos años distintas organizaciones europeas e internacionales han desarrollado escenarios y programas para la implantación de un sistema mejorado de gestión del tránsito aéreo (Air Traffic Management , «ATM»). El futuro sistema deberá ser capaz de satisfacer el aumento previsto en la demanda antes del año 2010 (entre el 70 y el 133 por ciento del actual). Estos escenarios no son homogéneos: contemplan distintas funciones y difieren en el marco temporal que abarcan. Con el fin de aunar criterios y definir así uno o varios escenarios con la capacidad de satisfacer las necesidades de ATM en Europa en el siglo XXI, la Dirección General de Transporte de la Comisión de las Comunidades Europeas decidió patrocinar el proyecto AEGIS (Grupo Europeo ATM para la Mejora de Escenarios). El objetivo global de este proyecto fue la mejora y unificación de los escenarios existentes en el campo de ATM, mediante la ampliación del ámbito de investigación y las aportaciones de la variada experiencia técnica de un consorcio multidisciplinario. Los miembros del consorcio AEGIS eran Aérospatiale, BNR Europe Ltd., Isdefe, National Technical University of Athens, Queen Mary and Westfield College (University of London), Sextant Avionique, Sofréavia y Syseca. El proyecto se dividió en tres fases: evaluación, mejora y consolidación, subdivididas, a su vez, en un total de nueve paquetes


de trabajo técnicos y uno de gestión. En la fase de evaluación, el consorcio analizó y comparó los escenarios y conceptos existentes, elaboró una definición del término «escenario», estableció una metodología para desarrollar escenarios y aplicó esta metodología para obtener un escenario base. En la fase de mejora, se identificaron e integraron en el escenario base una serie de mejoras organizativas, técnicas y de entorno. Finalmente, en la fase de consolidación, el consorcio desarrolló una metodología para analizar los costes y beneficios de escenarios para ATM y validó el escenario mejorado aplicando esta metodología. La Figura 2.1 presenta estas tres fases de forma esquemática. Isdefe participó en el proyecto AEGIS como coordinador. Asimismo, fue responsable directo del estudio coste/beneficio que se llevó a cabo y de la consolidación final del escenario. 2.2. Relación del proyecto con la ingeniería de sistemas La totalidad del trabajo que se ha llevado a cabo en el proyecto AEGIS se puede enmarcar en la primera fase del ciclo de vida de un sistema. En concreto, el proyecto AEGIS es un ejemplo de la fase de diseño conceptual de la ingeniería de sistemas aplicada al campo de la gestión del tránsito aéreo. Basándose en las necesidades del cliente, se identificaron y analizaron los requisitos del futuro sistema ATM, se propuso una solución coherente para satisfacer estos requisitos y se definieron los pasos de transición necesarios para lograr la solución propuesta. 2.3. Fase 1: evaluación Como primer paso de la fase de evaluación, el consorcio identificó y analizó los escenarios y conceptos existentes en el campo de ATM. Los escenarios y conceptos estudiados se clasificaron por su

22



nivel de descripción, si eran generales o específicos, si proponían un sistema totalmente automatizado o un sistema que conservaría la intervención humana en el ciclo de toma de decisiones, y si trataban cuestiones organizativas o institucionales. Finalmente, se clasificaron por su ámbito funcional: si trataban principalmente la gestión de afluencia, la gestión del espacio aéreo, el control de tráfico aéreo, comunicaciones/navegación/vigilancia, la integración aire/tierra, el papel del hombre en el sistema y la interfaz hombre-máquina, la gestión del tránsito aéreo o los costes. Asimismo, se identificaron conceptos en cinco dominios: gestión de vuelo a bordo (Air Flight Management , «AFM»), ATM, comunicaciones, arquitectura del sistema y entorno. Antes de proceder a desarrollar una metodología para la elaboración de escenarios, se definió el término «escenario» como "la descripción preceptiva del estado futuro de un sistema o subsistema, teniendo en cuenta las diversas restricciones y problemas que se pretenden resolver con la implantación de conceptos existentes o nuevos ". Desde la perspectiva de AEGIS, un escenario debería ser un planteamiento «vivo» de un sistema, que se realimente de todos los conocimientos y experiencias que se obtengan en el proceso de investigación y desarrollo que forma parte de su ciclo de vida. Este ciclo de vida se muestra en la Figura 2.2. Basándose en el ciclo de vida del sistema, el consorcio definió una metodología para elaborar escenarios, que se plasmó en el siguiente esquema o «índice»: 1) Identificación de las necesidades del cliente: consideración de las tendencias de la política y desarrollo de un esquema inicial de soluciones; 2) Elaboración de esquemas de soluciones: delimitación del área temática sobre el que versará el escenario y desarrollo de grupos de objetivos/principios/soluciones para iniciar la identificación de soluciones alternativas;

24


3) Desarrollo de soluciones: exposición en detalle de las soluciones que propone el escenario; 4) Transición: definición de uno o varios caminos alternativos para llegar al estado futuro que se propone, partiendo del estado actual; 5) Mejoras previstas: identificación de los efectos y beneficios que se espera obtener con la implantación del escenario; y 6) Conclusiones: resumen de los resultados del escenario y planteamiento de propuestas para futuros trabajos. Aplicando esta metodología, el consorcio definió las necesidades del cliente, basándose en los requisitos de alto nivel contenidos en el anexo técnico del contrato con la Comisión Europea y en las opiniones de las líneas aéreas (usuarios del sistema ATM) expresadas en el «libro


blanco» editado por la Asociación de Líneas Aéreas Europeas. Depuradas por el consorcio, las necesidades identificadas se agruparon en los tres objetivos principales del escenario que se iba a desarrollar: 1) Mejora de los escenarios ATM existentes. Específicamente, se requería un escenario de transición hasta el año 2015, que contemplara mantener la intervención humana en el ciclo de toma de decisiones. 2) Estudio de las interacciones entre las líneas aéreas y los sistemas ATM (por ejemplo, cooperación entre los sistemas embarcados y de tierra). 3) Identificación de propuestas para aumentar la capacidad, seguridad y calidad de los servicios del sistema de gestión del tránsito aéreo. Partiendo de estos objetivos generales, se definieron las seis áreas generales en que se iba a centrar el futuro escenario: (1) la organización de ATM; (2) las alternativas para la gestión del espacio aéreo; (3) la estrategia de automatización; (4) los aspectos funcionales; (5) el reparto de tareas entre los sistemas embarcados y de tierra, entre sectores y entre el hombre y la máquina; y (6) los aspectos de transición. Estas áreas se desglosaron en las siguientes subáreas: filosofía del sistema, gestión del espacio aéreo, gestión de afluencia, compartición de tareas entre aire y tierra, estrategia de automatización, reparto de tareas entre el hombre y la máquina, organización de la unidad de control, relaciones entre ATM y las líneas aéreas, relaciones entre ATM y los aeropuertos, relaciones entre ATM y el sistema militar, y comunicaciones/navegación/ vigilancia (Communications/Navigation/Surveillance , «CNS»). Para cada una de estas subáreas, se identificaron varios conceptos, clasificados globalmente como de carácter conceptual, organizativo o técnico. Estos conceptos se utilizaron para definir, en cada subárea, los objetivos del futuro escenario, los principios que lo guiarían y las soluciones propuestas para lograr los objetivos cumpliendo con los principios establecidos.

26


A continuación, los conceptos se dispusieron en una matriz para identificar su compatibilidad, incompatibilidad o independencia entre sí. El resultado de este ejercicio fue la identificación de aquellos conceptos que podrían definir el futuro escenario AEGIS: 1) Filosofía ATM: no determinista (la situación actual), o determinista. 2) Estructura de ATM: integrada o en niveles. 3) Estrategia de automatización: completamente automatizado, principalmente dependiente de la tecnología o centrado en la intervención humana. 4) Gestión del espacio aéreo: «cielos abiertos», concepto de rutas fijas aeronáuticas o cielos semi-abiertos. 5) Organización del control de tráfico aéreo: AFM ejercido en tierra, control de tráfico aéreo ejercido a bordo o redundancia entre las partes de aire y tierra de ATM. Se seleccionaron seis posibles combinaciones de estos conceptos como esquemas de soluciones, que fueron valorados utilizando una serie de criterios cualitativos. Esta valoración dio como resultado un conjunto consolidado de escenarios (ver Figura 2.3). Uno de estos escenarios se eligió para ser desarrollado en la siguiente fase, el Escenario Genérico e Integrado para ATM y Redes (GIANTS). Otro escenario, el Sistema de Tráfico Aéreo Automatizado e Integrado (AIATS), se consideró fuera del ámbito del AEGIS, pero se propuso para un estudio futuro. 2.4. Fase 2: mejora Los principales aspectos del escenario GIANTS que se desarrollaron y mejoraron en la segunda fase del proyecto fueron el papel fundamental


de la intervención humana en el sistema, su carácter no determinista y su estructura en seis niveles temporales decrecientes. Estos niveles, que servirían de filtros sucesivos para ajustar la capacidad del sistema a la demanda en cualquier momento dado, fueron los siguientes: gestión global del sistema, planificación estratégica, planificación preoperativa, operación en tiempo real, redes de seguridad y análisis posterior de datos. En el desarrollo del escenario, se hicieron propuestas en cuatro áreas. En la primera, cooperación entre aire y tierra, el escenario propuso tres conceptos: la redundancia entre los sistemas embarcados y los de tierra, la aeronave «autónoma» y la cooperación entre los sistemas embarcados y los de tierra. Asimismo, se propuso la convergencia de los modelos de tierra y de aire como requisito previo para una cooperación eficaz entre aire y tierra. En las áreas segunda y tercera, AFM ejercido en tierra y control de tránsito aéreo ejercido a bordo, respectivamente, el escenario definió

28


nuevas tareas para los operadores, basadas en una nueva forma de compartir responsabilidades y en nuevas herramientas, que se diseñarían basándose en un análisis detallado de las tareas que deben desempeñar. En particular, se crearon tres nuevos actores para el ATM en tierra: el gestor de área, el planificador de área y las unidades de control. Finalmente, se propusieron tres fases de transición: hasta el año 2000, del año 2000 al 2005, y del año 2005 al 2010. Se definieron los requisitos para la transición del sistema para cada una de estas fases. 2.5. Fase 3: consolidación En la tercera fase del proyecto se consolidaron los resultados obtenidos en las primeras dos fases. Una vez definidos los requisitos técnicos y de transición del escenario GIANTS, el consorcio diseñó una metodología especializada para analizar los costes y beneficios de cualquier inversión en el sistema ATM. La metodología, una vez particularizada para el análisis del escenario GIANTS, consistió en dos pasos: (1) la obtención de los parámetros de eficacia del sistema, partiendo de los parámetros técnicos, y (2) partiendo de los parámetros de eficacia del sistema, la obtención de los costes diferenciales de operación de las líneas aéreas que, por hipótesis, se consideraron los beneficios del escenario. El estudio concluyó con un análisis de sensibilidad. Este análisis dio por resultado que los beneficios diferenciales esperados tras la implantación del escenario GIANTS eran de un orden de magnitud mayor que los costes diferenciales. 2.6. Valor añadido del proyecto El escenario GIANTS que se ha propuesto en el proyecto AEGIS deberá ser capaz de resolver la mayoría de los problemas actuales de


la gestión del tránsito aéreo. Sin embargo, se requerirá una validación posterior de sus soluciones conceptuales, organizativas y técnicas en futuros estudios de investigación y desarrollo, sobre todo de la nueva estructura organizativa que se propone. Como valor añadido, el proyecto AEGIS ha desarrollado dos metodologías que se pueden aplicar en otros proyectos: una metodología para elaborar escenarios y una metodología especializada para el análisis de los costes y beneficios de cualquier sistema de gestión del tránsito aéreo. 2.7. Consideraciones finales El proyecto AEGIS es un ejemplo de la primera fase del ciclo de vida de un sistema: la identificación o definición de la necesidad. Habiendo determinado que la capacidad actual del sistema de gestión de tráfico aéreo no será capaz de hacer frente a la demanda en el siglo XXI, se plantea la mejora del sistema para aumentar su capacidad. Como primer paso en la definición del futuro sistema, se estudiaron diversos escenarios ATM (descripciones del estado futuro del sistema de gestión de tránsito aéreo) para adecuarlos a las necesidades reales del cliente, identificando propuestas para aumentar la capacidad, seguridad y calidad de los servicios prestados por el sistema ATM. Estas propuestas, que deberán ser validadas por otros proyectos, podrán servir de base para la definición de los requisitos operativos del futuro sistema, en un siguiente paso hacia el diseño del sistema ATM del siglo XXI. El planteamiento metódico y estructurado para determinar y desarrollar las necesidades del cliente que se ha seguido en el proyecto AEGIS puede ayudar en la definición más precisa de los requisitos conceptuales de cualquier sistema.

30


31

3

Evaluación de desarrollos basados en una nueva tecnología: demostrador PlanBA

32


3.1. El programa PlanBA PlanBA (Plan de acción nacional para la Investigación y Desarrollo [I+D] en comunicaciones integradas de Banda Ancha) es un programa promovido y financiado parcialmente por la Administración española. Su principal objetivo es disponer, a finales de 1995, de un demostrador experimental de banda ancha que tome como núcleo la red RECIBA desarrollada por Telefónica. PlanBA (1992-1995) es una acción coordinada con la industria nacional sobre actividades de I+D en banda ancha, en la que están involucrados operadores, fabricantes de productos de telecomunicación y centros públicos de investigación. En su organización, gestión y financiación intervienen los organismos de la Administración con responsabilidad en la promoción de la tecnología de telecomunicaciones. El núcleo de la actividad PlanBA consiste en la integración y puesta en operación de un demostrador de red experimental de comunicaciones en banda ancha integrado por los prototipos de los elementos desarrollados por los proyectos PlanBA: aplicaciones, terminales, adaptadores,... El demostrador utilizará el Modo de Transferencia Asíncrono (MTA), una tecnología de transmisión y conmutación de paquetes de longitud fija (células) que proporciona un soporte muy flexible para el transporte de la información. Cada elemento individual del demostrador, o grupo de ellos, es desarrollado por un proyecto. Cada proyecto es realizado por un

33 Evaluación de desarrollos basados en una nueva tecnología: demostrador PlanBA

consorcio en el que participan empresas y organismos públicos de investigación (OPIs) que trabajan de forma conjunta durante todo el ciclo de vida del proyecto. La coordinación se realiza a través de la participación de los organismos gestores y financiadores en el Comité de Gestión PlanBA. Este Comité está soportado en sus actividades por la Oficina de Gestión (Oficina PlanBA). Se ha constituido un grupo de personas con experiencia multidisciplinar relacionada con la gestión, la investigación y el desarrollo de proyectos de ingeniería en comunicaciones de banda ancha. La Figura 3.1 representa esquemáticamente las interacciones entre los diferentes agentes involucrados. Actualmente, PlanBA está en la fase final de su desarrollo, aunque este Capítulo se centra en los aspectos de desarrollos que avalen la viabilidad de la nueva tecnología MTA, desarrollos que se encuadran clásicamente dentro del diseño conceptual en la ingeniería de sistemas. La evaluación de desarrollos sobre una tecnología concreta determina el interés de dedicar recursos a esa tecnología y, lo que es más importante, permite cuantificar la cantidad de recursos necesarios. Mediante este tipo de análisis se pueden establecer calendarios y costes aproximados para la realización de prototipos basados en la tecnología en cuestión. 3.2. Evaluación de desarrollos en PlanBA La Administración española, en base a la tecnología emergente del Modo de Transferencia Asíncrono, que prometía ser la base de las futuras redes de comunicaciones de banda ancha, tomó en 1988 la iniciativa de consultar a la industria nacional de telecomunicaciones sobre la conveniencia de polarizar hacia el MTA las actividades de I+D en telecomunicaciones. El objetivo era permitir que se posicionara adecuadamente la industria española ante los nuevos objetivos que se apuntaban.

34



Se acordó que la Dirección General de Telecomunicaciones realizara un estudio de detalle sobre las posibles actuaciones que cabría abordar, con el objetivo de incorporarlo a la nueva versión del Plan Nacional de Telecomunicaciones (1991-2002). La realización del estudio convocó a la Administración, la industria de telecomunicaciones, los operadores de red y los centros de estudio e investigación. Con objeto de identificar las necesidades, analizar los requisitos, seleccionar el enfoque y proceder a la definición funcional del programa de actuación, se crearon cuatro grupos de trabajo: (1) Servicios, (2) Situación española, (3) Tecnología y (4) Plan de Trabajo. El modelo conceptual que se derivó de los estudios fue facilitar la coordinación e integración de experiencias previas mediante la participación conjunta de diferentes agentes en una serie de acciones de I+D en comunicaciones integradas de banda ancha. Acciones encaminadas a complementar otras similares en el entorno europeo (ESPRIT, RACE, etc) que potenciarían la I+D en la industria y los centros de investigación. Éstas debían permitir la integración de los resultados en un demostrador que permitiera comprobar el interfuncionamiento de resultados a la vez que sirviera de demostración para impulsar servicios y aplicaciones, así como de banco de pruebas para distintas tecnologías, elementos y equipos. El trabajo se llevó a cabo en tres etapas: 1) Identificación de tecnologías relevantes en banda ancha; 2) Identificación de aplicaciones y usuarios; y 3) Definición del plan de trabajo para la consecución del demostrador. 3.2.1

Identificación de tecnologías relevantes en banda ancha

Se realizó un estudio tomando como material de partida una definición de actividades de I+D en comunicaciones de banda ancha.

36


En esta definición participaron empresas y profesionales relevantes del sector de las telecomunicaciones: operadores, fabricantes, institutos oficiales y universidades. El estudio incluía una descripción para cada área según el siguiente esquema: (1) justificación de la necesidad de la tecnología, (2) subáreas de la tecnología, (3) objetivos y (4) estrategia. En total, se identificaron ocho áreas tecnológicas: (1) Microelectrónica, (2) Optoelectrónica, (3) Software, (4) Algoritmos y Proceso de Señal, (5) Tecnología de Conmutación, (6) Arquitectura de Sistemas, (7) Tecnologías de Diseño Físico y (8) Tecnologías de Usuario. Estas áreas incluían a su vez otras veintiocho subáreas. Así, en microelectrónica se contemplaban tecnologías básicas y metodologías, en tecnología de conmutación se consideraban las subáreas de conmutación MTA y técnicas de adaptación e interfuncionamiento, etc. 3.2.2.

Identificación de aplicaciones y usuarios de banda ancha

En esta etapa, se realizó un estudio con los mismos participantes de la etapa anterior para establecer las pautas de cómo debían considerarse los escenarios de usuarios y aplicaciones, con objeto de llevar a cabo una eficiente implantación de las comunicaciones de banda ancha. Para identificar las potenciales aplicaciones y usuarios de las tecnologías de banda ancha se llevaron a cabo tres análisis independientes: 1) Tendencias y perspectivas europeas: en primer lugar se analizó la disponibilidad previsible de infraestructuras de comunicaciones avanzadas en Europa. También se estudiaron las expectativas de mercado y las estimaciones de la demanda de este


tipo de comunicaciones. Finalmente, se hizo una revisión de pilotos europeos de comunicaciones integradas de banda ancha. Principalmente RACE y ESPRIT. 2) Identificación de las facilidades específicas añadidas por la tecnología de banda ancha. Se realizó un análisis matricial de acuerdo a las variables siguientes: (1) estratificación de usuarios, (2) funciones de los usuarios y (3) aplicaciones genéricas. 3) Análisis de agentes: se identificaron a los particulares, a las empresas y al sector público como los principales agentes. A partir de los análisis anteriores se determinaron las aplicaciones más oportunas, con el objetivo de orientar la toma de decisiones en el área de aplicaciones de PlanBA y de contribuir al dimensionamiento de los recursos. Para cada agente identificado se definieron las aplicaciones siguientes: 1.- Agentes Empresarios: (1) instituciones de crédito y seguro y (2) turismo. 2.- Sector Público: (1) Sanidad y Seguridad Social y (2) educación. 3.- Agentes Particulares: (1) teleeducación, (2) teletrabajo, (3) telecompra y (4) ocio y entretenimiento. 3.2.3.

Definición del plan de trabajo para la consecución del demostrador

A partir del análisis de las áreas tecnológicas más relevantes para las comunicaciones integradas en banda ancha, los módulos incorporados en otros pilotos europeos de los análisis de demanda de este tipo de tecnologías y las aplicaciones de mayor interés, según

38


los expertos participantes en las reuniones de definición, se identificaron una serie de elementos a desarrollar en el demostrador (ver Figura 3.2). Se procedió a la identificación y cuantificación de medios (recursos humanos, inversiones en equipamiento, etc.) de forma que integrados y secuenciados debidamente en el tiempo permitieran la realización del demostrador para satisfacer las necesidades y los objetivos estratégicos planteados en la definición de las acciones. A partir de las experiencias aportadas por los expertos se elaboró una tabla de estimaciones para los recursos humanos (hombres * año) y las inversiones requeridas (Mpts.) por cada uno de los elementos del demostrador (ver Tabla 3.1). Se estimó que era conveniente la existencia de un Proyecto de Integración para asegurar la funcionalidad coherente de la red y garantizar la compatibilidad entre las actividades desarrolladas (ver Figura 3.3). Para el desarrollo de cada elemento se sugirió la formación de consorcios entre empresas y centros públicos de investigación con objeto de que se desarrollara en lo posible un único proyecto por cada uno de los elementos a desarrollar. Finalmente, se previó una dotación económica (Fondo de Integración) para la inversión en posibles réplicas de prototipos no previstas inicialmente o para aumentar la funcionalidad de ciertos elementos. 3.3. Evolución del proyecto integrado PlanBA Desde su inicio en 1992 hasta 1995 se incorporaron 16 proyectos que cubrían los objetivos generales establecidos al inicio. En los proyectos aprobados intervienen: 22 empresas pertenecientes al sector


40



de las tecnologías de la información y las comunicaciones, 10 grupos investigadores de universidades y centros públicos de investigación y 8 usuarios de aplicaciones (hospitales, cadenas hoteleras y organismos relacionados con la educación). El proceso de evolución posterior del programa se detalla en la Figura 3.4. Los desarrollos PlanBA finalizan en diciembre de 1995. En el primer trimestre de 1996 se esperan realizar demostraciones públicas de los logros obtenidos por la industria y la universidad española en el marco de este programa.

42


43

4 Especificación de requisitos en el programa MIDS

44


4.1. El sistema MIDS MIDS ("Multifunctional Information Distribution System", Sistema Multifuncional de Distribución de Información), es un sistema de comunicaciones, navegación e identificación (de aquí la multifuncionalidad) que permite intercambiar voz y datos entre usuarios distribuidos en una amplia zona geográfica. Los usuarios del MIDS son los aviones y helicópteros militares, buques de guerra y unidades terrestres. Las ventajas que aporta la utilización del MIDS en relación con los sistemas actualmente existentes son básicamente tres: 1. La seguridad de las comunicaciones, ya que es muy difícil interceptar los mensajes transmitidos por el sistema MIDS. 2. La resistencia a las interferencias externas de radio, en ambientes electromagnéticamente muy densos, como son los que suelen encontrarse en las operaciones militares. 3. La interoperatividad entre usuarios muy diversos, de ejércitos e incluso países distintos, al aportar un alto grado de estandarización en la obtención de las funciones suministradas por el sistema. Técnicamente el MIDS es un sistema muy complejo [11, 12], que funciona con un alto grado de automatización e incorpora


tecnologías muy avanzadas. Los equipos para el intercambio de información a través del MIDS se llaman terminales y el programa multinacional MIDS que aquí se comenta tiene por objeto el diseño, desarrollo y producción masiva de un modelo único de terminal MIDS válido para todo tipo de usuarios, terrestres, navales y aéreos. 4.2. El programa MIDS En la actualidad, el programa se encuentra en su fase de diseño y desarrollo. Las actividades de ingeniería de sistemas que se comentan en este Capítulo se realizaron durante la fase de especificación de requisitos, previa a la de desarrollo. En la Figura 4.1 puede verse un esquema de las partes que intervienen en el programa para desarrollar un terminal que cumpla las especificaciones del sistema MIDS. Existe un acuerdo entre los gobiernos de cinco naciones para la realización del citado programa. En cada una de estas naciones existe una Oficina Nacional de Programa, que coordina todas las actividades nacionales e internacionales del programa y se ocupa del funcionamiento día a día del mismo. Por otra parte, se ha constituido un Comité Director del programa, que toma las decisiones de gestión del programa, y tiene delegadas ciertas atribuciones en una Oficina Internacional de Programa (IPO). Tanto en la IPO como en el Comité Director están representadas todas las naciones participantes. En la parte industrial, existe un acuerdo de cinco empresas procedentes de las cinco naciones participantes. Dichas empresas han constituido un consorcio denominado MIDSCO del cual son a su vez socios y subcontratistas. El programa MIDS se realiza a través de un contrato único firmado por la IPO y MIDSCO, que actúan por delegación de las distintas partes.

46


4.3. Actividades previas a la fase de desarrollo A continuación se comentan brevemente las actividades principales del programa durante la fase de especificación de requisitos. La lista no es completa, ya que no figuran en ella, por ejemplo, los aspectos logísticos. Sólo se pretende exponer unos cuantos ejemplos típicos que sirvan para ilustrar el proceso de la ingeniería de sistemas. Isdefe ha participado en todas las actividades descritas a lo largo de esta Sección. 4.3.1.

Preparación de la petición de oferta

La petición de oferta incluye: cláusulas contractuales; especificaciones técnicas; definición de trabajos / desglose de tareas; y lista de productos entregables. La petición de oferta constituye un extenso paquete de documentos que contiene toda la información detallada necesaria para


contratar los trabajos industriales del programa. La participación de los grupos de ingeniería en estas actividades ha sido muy intensa en las siguientes áreas: 1)

Cláusulas contractuales

Se han discutido con otras naciones qué elementos de configuración hardware, software y servicios eran exactamente objeto de contrato, y en qué condiciones. Los principales elementos contratados son: a) b) c) d) e)

Diseño del terminal MIDS. Diseño de un simulador de interfaz del MIDS. Prototipos de terminales. Simuladores. Apoyo logístico para todo lo anterior (repuestos, formación, mantenimiento, etc).

Para disponer de una versión definitiva de cláusulas contractuales, se ha realizado una labor de análisis de las cláusulas de las FAR (Federal Acquisition Regulations, Regulaciones Federales de Adquisición), que debían incluirse en el contrato, dado que el contrato se firma entre un representante de la Oficina Internacional de Programa (IPO) y un representante del consorcio industrial MIDSCO. La legislación aplicable es en consecuencia la estadounidense, por lo cual el contrato ha de ajustarse a las FARs, equivalentes a la Ley de Contratos del Estado y Disposiciones Complementarias. 2)

Especificaciones técnicas

La redacción de las especificaciones técnicas que debe cumplir el terminal MIDS ha sido sin duda la actividad que más recursos de ingeniería ha consumido en toda la preparación previa a la fase de desarrollo. Para ello, se han formado varios grupos multinacionales, con representantes técnicos de todas las naciones participantes, y se han ido discutiendo todos los temas técnicos que intervienen en el terminal.

48


3)

Selección de la documentación aplicable

Una parte importante de la actividad de los grupos técnicos responsables de la redacción de especificaciones técnicas es el análisis y selección de la normativa aplicable para cada elemento hardware y software del futuro terminal MIDS. Esto supone el estudio de un alto número de estándares de diversa procedencia: Normas y especificaciones militares de Estados Unidos (MIL-STD), STANAGs promulgados por la OTAN, normas IEEE, ISO, ANSI, etc. Para cada documento que se incluye como referencia en las especificaciones, se ha de definir su «aplicabilidad». Esto quiere decir que no basta con citar una norma aplicable, sino que, desde el momento en que se incluye en el documento de especificaciones, se ha de determinar qué secciones de la misma se aplican y en qué medida. Otro problema que se discutió en los grupos de trabajo, fue la armonización de las distintas normativas existentes en relación con un mismo tema. Cuando existen varias posibles normas aplicables para definir un determinado requisito, y se estima que la toma de decisiones no es inmediata, se forma un subgrupo de trabajo constituido por expertos en el tema de que se trate, al que se asigna la responsabilidad de analizar las distintas normas existentes y proponer una decisión final debidamente razonada y documentada. Un tema típico que ha exigido varias actuaciones de este tipo es el de la compatibilidad electromagnética (Electromagnetic Compatibility, EMC). 4)

Metodología de trabajo

Para preparar el documento de especificaciones técnicas, se ha seguido un procedimiento iterativo de reuniones de trabajo multinacionales, períodos de estudio en las distintas naciones para asimilar las propuestas presentadas en las reuniones, y nuevas reuniones para incorporar nuevos cambios y discutir su impacto en los sucesivos borradores de trabajo.


De esta forma se ha ido consolidando un documento cuya versión definitiva es el documento de especificaciones técnicas del terminal MIDS, cuyo nombre es System Segment Specification (SSS) y que establece cuál ha de ser el funcionamiento global del terminal y los requisitos a los que deberá ajustarse su cualificación completa. La organización general del documento de especificaciones se ajustó a lo establecido en la norma DI-CMAN-80008A: Data Item Description/System Segment Specification, que contiene directrices para la definición de especificaciones técnicas. El documento SSS contiene en primer lugar el alcance e identificación de la especificación. A continuación se listan los documentos aplicables, tanto generados por el gobierno como de otras procedencias. Seguidamente se especifican los requisitos de prestaciones del terminal MIDS, sus características físicas y los estándares mínimos que ha de satisfacer su diseño y construcción. Esta sección de requisitos es la más voluminosa de la SSS y la que más recursos exige en su preparación. A continuación se incluye una sección sobre requisitos en materia de garantía de calidad, otra sección sobre preparación para entrega de terminales a los usuarios, y una última sección con información complementaria para aclarar determinados aspectos de las secciones anteriores. Dado que el terminal MIDS ha de servir para una amplia variedad de plataformas, se reveló prácticamente imposible reunir en un único documento común todos los requisitos exigibles a las distintas plataformas usuarias. Por ello, se recurrió, a añadir al final del documento SSS una serie de anexos, uno por cada plataforma usuaria del MIDS, en los que se contemplaban los requisitos exclusivos de cada plataforma. Durante todo el trabajo de preparación de la SSS, se puso el mayor interés en que dichos anexos contuvieran el mínimo de requisitos exclusivos, de forma que la mayoría de los requisitos de las plataformas estuviera ya contemplada en el cuerpo principal común de la SSS. Se adoptó esta filosofía para obtener un diseño común, ya que esta «comunalidad» es precisamente un objetivo básico del programa.

50


Las principales categorías de elementos objeto de especificación durante esta actividad fueron las siguientes: proceso de señal MIDS; estructura de mensajes/proceso de mensajes; esquemas de modulación y demodulación; interfaces externas del terminal; características físicas; fiabilidad, mantenibilidad y prueba incorporada (Built-In Test, BIT); condiciones ambientales; alimentación; logística/adiestramiento/ personal; y verificación. De esta forma se ha ido consolidando un borrador, cuya versión definitiva es la Especificación de Segmentos del Sistema. Una vez finalizado el documento, es posible realizar cambios formales en el mismo, siempre que se respeten los procedimientos establecidos de control de configuración y se acepten por todas las naciones las consecuencias técnicas, económicas y operativas de los cambios introducidos. Esta actividad de refinamiento del documento continúa aún en la actualidad, si bien con una reducida aportación de recursos. 5)

Verificación de requisitos/matriz de verificación

En la sección de la Especificación de Segmentos del Sistema dedicada a la garantía de calidad, se incluyeron los requisitos necesarios para la verificación del diseño y comportamiento del hardware y el software del terminal MIDS. Las distintas verificaciones contempladas en la SSS se clasificaron en cuatro grupos: Verificaciones de ingeniería, para detectar y corregir a tiempo las deficiencias del diseño. Estas pruebas se realizan en paralelo con el trabajo de desarrollo y en general no van asociadas a un requisito formal de planes y procedimientos de verificación debidamente aprobados. Verificaciones de alistamiento para la integración, para garantizar que el desarrollo del terminal MIDS ha progresado lo suficiente como para poder abordar los trabajos de integración en la


plataforma anfitriona y comenzar las pruebas de campo. Estas pruebas son las primeras que se realizan a nivel de terminal MIDS completo. Verificaciones de cualificación, para demostrar que un diseño maduro satisface todos los requisitos especificados. Estas pruebas deben realizarse utilizando planes y procedimientos preparados por MIDSCO y aprobadas por las naciones. Dichos planes contemplan las siguientes categorías de pruebas: funcionalidad; software; ambientales; compatibilidad e interferencia electromagnéticas; fiabilidad y mantenibilidad; calidad de la voz/tasa de errores; alimentación/pruebas térmicas; diseño estructural; e interoperatividad. Verificaciones de aceptación, para comprobar que todo elemento entregado por MIDSCO está en buen estado. Estas pruebas se aplican tanto a los distintos módulos que configuran el terminal MIDS, como al propio terminal completo. También en este tipo de pruebas se exigió la adopción de planes y procedimientos aprobados por las naciones. En cuanto a los métodos de verificación, se identificaron los cinco siguientes, por orden creciente de complejidad y profundidad: inspección, análisis, certificación, demostración y prueba. En base a todos los elementos anteriores, se construyó una matriz de verificación, en la que se identificaban todos los requisitos especificados para el terminal MIDS, y el método de verificación a utilizar en las pruebas formales (cualificación y aceptación). 6)

Definición de trabajos / desglose de tareas

Además de definir las características técnicas que ha de tener el producto del programa (el terminal MIDS), se discutieron detalladamente las actividades que se espera realice el contratista principal o cualquiera de sus subcontratistas de primer nivel (las empresas nacionales que participan en el programa).

52


Esta definición de tareas se especifica en el Statement Of Work (SOW) que es la Definición deTrabajos, donde se explican todas las tareas a realizar, se indican las normas que ha de cumplir el contratista en la realización de dichas tareas y se asocia cada tarea especificada con el contenido de las cláusulas contractuales y, en algunos casos, con productos entregables, al objeto de poder realizar posteriormente el seguimiento de dichas tareas. También en el caso del SOW se ha especificado la aplicabilidad y el alcance de los estándares incluidos. Estrechamente asociada con el SOW está el desglose de tareas del programa completo, o Work Breakdown Structure (WBS) que permite asociar las tareas realizadas con los costes del programa. El desglose de tareas es una descomposición en árbol de todo el programa, que puede analizarse a distintos niveles de agregación, desde el programa completo, hasta las actividades más elementales. 7)

Lista de productos entregables

Todos los productos entregables están descritos en una lista de documentos denominados CDRLs (pronunciado «sidrals»). El significado de este acrónimo en inglés es Contractor Data Requirement List, es decir, lista de requisitos que han de cumplir los datos entregados por el contratista. Se trata de especificaciones particulares que ha de cumplir cada documento o producto entregable, con indicación asimismo de lugar de entrega, plazo de entrega, lista de distribución, etc. La información asociada con cada entregable del CDRL va complementada con el correspondiente documento DID, Data Item Description. El DID es generalmente un documento ya existente en la literatura técnica. Por ejemplo, existen DIDs para informes de reunión, para documentos de interfaz, para planos mecánicos, etc. En los casos en que no se dispone de un DID para una necesidad específica, se redacta uno nuevo para cubrir dicha necesidad, y se incorpora en el


paquete de documentación contractual, asociado con uno o más documentos del CDRL. 4.3.2.

Reducción de prestaciones técnicas

Cuando las naciones participantes dispusieron de una oferta formal de MIDSCO, conforme con el paquete contractual que se había emitido, los precios ofertados se consideraron demasiado elevados. Al margen de una negociación del precio, discutiendo uno tras otro todos los elementos que figuran en el contrato, las naciones acordaron reducir ligeramente algunas de las prestaciones técnicas, siempre que el impacto resultante sobre la operatividad del terminal MIDS fuese tolerable. Para realizar esta labor de reducción de prestaciones técnicas, fue preciso revisar completamente las especificaciones técnicas, analizando en qué medida se podían realizar cambios en los requisitos contemplados en dicho documento. Este trabajo se realizó en dos fases, y se ha prolongado aproximadamente durante un año. El método de trabajo a seguir ha sido análogo al de redacción de especificaciones técnicas. Las naciones presentaban sus propuestas de reducción, se formaba una propuesta consolidada y periódicamente se reunían grupos de trabajo especializados, con asistencia de personal técnico y de costes, y se analizaban las propuestas. Posteriormente las propuestas se presentaban a la Oficina Internacional del Programa quien, tras una nueva labor de filtrado las elevaba al Comité Director para su aprobación formal o devolución. 4.3.3.

Negociación del precio

La totalidad del contrato del MIDS supone aproximadamente 1.300 paquetes de trabajo bien definidos que han sido adecuadamente

54


descritos y valorados por MIDSCO en su oferta, y que el órgano de contratación (la Oficina Internacional del Programa), ha tenido que analizar, discutir y aceptar o rechazar. La negociación de todos estos paquetes se ha distribuido entre varios equipos especializados, formados por personal de la IPO y personal de MIDSCO y de las cinco empresas subcontratistas: GEC, THOMSON-CSF, ITALTEL, SIEMENS y ENOSA. 4.3.4.

Establecimiento de la línea base

Una vez aceptada la reducción de prestaciones, negociado los precios de todos los paquetes de trabajo y en consecuencia del contrato global, aceptadas las cifras de beneficio y bonificaciones o penalizaciones, etc, se ha procedido al establecimiento de la línea base. Esto significa que, dada la complejidad de las tareas a realizar, los múltiples cambios introducidos, y las discusiones relacionadas con el reparto de tareas y costes entre empresas nacionales, es preciso realizar una revisión completa de la configuración resultante del contrato. Este proceso de revisión de línea base está finalizando en la actualidad. 4.3.5.

Seguimiento industrial

Una vez comenzado el programa, es preciso llevar un seguimiento cercano de todas y cada una de las actividades industriales que se realizan en el mismo. Dada la gran cantidad de tareas a realizar, de documentos entregables y, en su momento, de pruebas e informes de pruebas, el seguimiento industrial es básico para aprovechar al máximo la participación de las naciones en el programa.


Dentro de las actividades del seguimiento industrial, los principales hitos en este programa son los siguientes: a) b) c) d) 4.3.6.

Revisión preliminar del diseño. Revisión crítica del diseño. Ensayo preliminar de cualificación. Auditoría de cualificación formal. Seguimiento de costes

El contrato del MIDS es del tipo de costes incurridos, en el que se resarce al contratista de todos sus costes, y se le paga además un beneficio que ha sido objeto de negociación. Por eso es del máximo interés para el cliente (las naciones participantes) realizar un seguimiento de costes, al objeto de ir analizando el progreso del programa. En este contexto resulta básico el concepto de «valor ganado», que va más allá de una mera cuenta del gasto producido. El valor ganado es una medida del trabajo realmente realizado por el contratista en un período determinado, e indica a un cierto nivel, lo que realmente se obtiene como contraprestación del dinero que se ha gastado en dicho período. En el programa MIDS el valor ganado se mide con periodicidad mensual. Para ello los contratistas han de presentar unos informes de seguimiento de costes que permiten calcular, al nivel de agregación del desglose de tareas que se desee, el valor ganado teórico (el establecido en la línea base del contrato), el valor ganado real, y las desviaciones producidas, tanto en costes como en plazos de ejecución. Una vez conocidas las desviaciones producidas, se estudia la posibilidad de adoptar o no acciones correctoras. 4.3.7.

Gestión del espectro radioeléctrico

Dado que el MIDS es un sistema de transmisión por radio, en la banda de UHF, su utilización real requiere una autorización

56


administrativa para la utilización del espectro radioeléctrico. La banda de frecuencias en que funciona el sistema MIDS es utilizada también por otros sistemas aeronáuticos, lo cual obliga a coordinar las transmisiones del MIDS de forma que no interfiera en dichos sistemas. En los casos en que se produzcan conflictos por interferencia, se han de realizar estudios técnicos para determinar en qué condiciones se podrían realizar las transmisiones, por ejemplo, fijando unas distancias mínimas entre emisores, zonas de exclusión, reduciendo la densidad de pulsos, etc. En todos los casos, el MIDS actúa como usuario secundario de la banda, lo cual significa, según el Reglamento de Radiocomunicaciones que, en caso de interferencias, los demás sistemas tendrán prioridad sobre el MIDS. Todos estos trabajos, de alto contenido técnico, se desarrollan dentro de otro grupo, separado de la actividad industrial de desarrollo del terminal MIDS. El grupo de Gestión de Espectros realiza simulaciones de todos los equipos que operan en la misma banda, así como pruebas de laboratorio y de campo con equipos reales, determinando las condiciones técnicas y operativas mínimas que deben cumplir los equipos para operar en la misma banda de frecuencias. La Especificación de Segmentos del Sistema incluye varios apartados para definir protecciones específicas contra interferencias a otros servicios, de forma que cesen las transmisiones MIDS en caso de que se produzcan dichas interferencias por encima de un determinado nivel. 4.4. Consideraciones finales El proceso de definición de las especificaciones técnicas del terminal MIDS fue largo y laborioso, a veces muy tedioso, debido a la variedad y diferencias existentes entre plataformas, y a la complejidad inherente al propio sistema MIDS. Sin embargo, gracias al elevado nivel de detalle conseguido en la especificación


final, se dispone de una alta granularidad en la posterior verificación de requisitos, y por añadidura, la fase de pruebas ha quedado preconfigurada desde una fase muy temprana del programa. En cuanto a la actuación de Isdefe como parte de la representación española, aunque el liderazgo de los grupos técnicos de especificación estuvo ostentado por otro país (EEUU), la participación directa en las discusiones ha permitido acumular una amplia base metodológica y técnica de conocimientos a los que no se puede acceder por otras vías. En otras palabras, gran parte de lo aprendido como consecuencia de la participación en la definición de especificaciones del MIDS es consecuencia del trabajo diario de unos equipos punteros dentro de su sector.

58


59

5

Análisis de riesgos durante la evaluación de ofertas en el programa SANTIAGO

60


5.1. El programa SANTIAGO El objeto principal del programa SANTIAGO es la captación de emisiones electromagnéticas y de imágenes en las zonas definidas como de interés estratégico para la seguridad nacional. El sistema obtenido deberá complementar los medios específicos ya existentes a nivel estratégico, con el fin de: apoyar a los centros de fusión y análisis de datos de guerra electrónica; servir de sensor y alerta al sistema de mando y control militar; y cooperar con otros sistemas de mando y control. Para cumplir este objetivo, es necesario el establecimiento de una red de sensores móviles, semimóviles y fijos que, disponiendo de capacidades de inteligencia de comunicaciones, inteligencia electrónica e inteligencia óptica, proporcionen una cobertura óptima del espacio estratégico de interés nacional. El sistema SANTIAGO, por su volumen y complejidad, está divido en diversos subsistemas. Estos se han abordado secuencialmente en el tiempo, siendo el último de ellos el de integración global. Algunos de estos subsistemas se encuentran en su fase más temprana, la especificación de requisitos (estudios de viabilidad), otros en la fase de diseño y desarrollo y otros en la fase final de construcción (pruebas tipo 3, [6]).

61 Análisis de riesgos durante la evaluación de ofertas en el programa SANTIAGO

5.2. Análisis de riesgos En este Capítulo se describe la metodología empleada durante los dos últimos años en el programa SANTIAGO, para efectuar el análisis de riesgos durante el proceso de evaluación de las ofertas presentadas para los diferentes subsistemas. Este análisis abarca los procesos de identificación y valoración de los riesgos, sin entrar en el tratamiento de la gestión y reducción de los mismos. Dentro de este esquema el análisis de riesgos ha servido como un elemento más de apoyo a la toma de decisión. Esto supone que dentro de este Capítulo nos ceñiremos, dentro del proceso general de ingeniería de sistemas, a la fase de evaluación de ofertas situada en la línea divisoria entre el diseño conceptual y el diseño preliminar del subsistema. Debe quedar claro, sin embargo, que el análisis de riesgos es un proceso iterativo que se extiende más allá de esta fase del ciclo de vida, abarcando desde el estudio de viabilidad hasta la puesta en funcionamiento del sistema. Dentro del programa SANTIAGO se sigue la metodología para adquisición de sistemas de armas Phased Armaments Programming System (PAPS) de la OTAN. Esta metodología impone la realización previa de estudios de viabilidad y definición de los sistemas. En los estudios de viabilidad se realiza un análisis de los riesgos tecnológicos asociados a los mismos que, lógicamente, es utilizado como punto de referencia fundamental en el momento de definir la solución final propuesta. La propia redacción del Pliego de Bases es otro de los elementos críticos en el proceso de análisis y gestión del riesgo. Desde un punto de vista conceptual todo el Pliego de Bases tiene por objeto especificar suficientemente, tanto el sistema como los trabajos que deben realizarse para su consecución, de manera que se minimice el riesgo de que el sistema final no satisfaga la necesidad operativa que originó su desarrollo.

62


5.3. La metodología utilizada 5.3.1.

Objetivos

Cuando se comenzó a diseñar la metodología que debía emplearse para efectuar el análisis de riesgos dentro del proceso general de evaluación de ofertas, se establecieron tres objetivos prioritarios, en orden de importancia: 1) Centrarse en el estudio de las posibles desviaciones entre lo ofertado y el producto final que pudiera conseguirse, y no en las desviaciones existentes entre lo ofertado y lo especificado en el Pliego de Bases. Estas últimas desviaciones son el objeto de la valoración de las ofertas, no de su análisis de riesgo. El proceso de valoración de ofertas se trata específicamente en el capítulo dedicado al programa SIMCA de esta monografía. 2) Permitir la comparación directa de los resultados conseguidos para las distintas alternativas (ofertas). La necesidad de la comparación directa se deriva de la utilización del análisis de riesgos como soporte a una toma de decisión. 3) Facilitar la incorporación a la metodología de lo aprendido en cada aplicación de la misma, puesto que se pensaba en su utilización reiterada. La metodología diseñada finalmente, que aparece resumida en la Figura 5.1, se descompone en cuatro grandes fases: (A) identificación de riesgos; (B) evaluación del impacto que la aparición de cada uno de los riesgos identificados tendría en el desarrollo del programa; (C) cuantificación de la «probabilidad» de aparición de cada uno de los riesgos; y (D) integración de los resultados. Esta metodología se utilizó por primera vez durante la evaluación de ofertas de uno de los subsistemas del segmento terrestre.


5.3.2.

Identificación

La identificación de riesgos es el primer paso de la metodología; consistió en enumerar las posibles desviaciones que podían producirse en el subsistema respecto a lo ofertado. Para afrontar el requisito relativo a la necesidad de la comparación directa del riesgo de las diferentes ofertas, se identificaron los riesgos asociados al pliego, es decir, se generó un diccionario de riesgos asociados a él. Esta labor se realizó durante el proceso de preparación de la evaluación, previa a la recepción de las ofertas. La generación de este diccionario de riesgos se efectuó mediante una descomposición descendente. El pliego se descompuso en grandes áreas de riesgo. Aunque no es imprescindible, desde que esta metodología se está aplicando dentro del programa SANTIAGO, las áreas de riesgo han coincidido con las consideradas para la evaluación: técnica, gestión, industrial

64


y económica. Estas áreas tratan con los riesgos asociados al desarrollo del sistema en los aspectos de prestaciones técnicas, calendarios, retorno industrial y costes. Cada una de estas áreas se descompuso, a su vez, en bloques de riesgo, agrupaciones lógicas y estructuradas de información bajo la óptica de cada una de las áreas. Así, por ejemplo, el área técnica se descompuso en los siguientes bloques: a) Funciones: agrupamiento de riesgos asociados a las funciones que debe verificar el sistema. b) Operatividad: agrupamiento de riesgos asociados a los modos de operación y recursos operativos que debe proporcionar el sistema. c) Desarrollo software: agrupamiento de riesgos asociados a la metodología y normativa de desarrollo. d) Instalación: agrupamiento de riesgos asociados a la transición o instalación del nuevo sistema. e) Apoyo Logístico: agrupamiento de riesgos asociados a la fiabilidad, mantenibilidad, abastecimiento y formación. El ultimo paso en el proceso de identificación fue la descomposición de cada uno de estos bloques en elementos de riesgo. Un elemento de riesgo se definió como una posible desviación respecto de lo ofertado. Sin embargo, como resultado de la aplicación práctica de esta metodología, se detectó la necesidad de incluir también como elemento de riesgo la falta de una definición detallada de lo ofertado, ya que efectivamente la falta de definición de la oferta introducía un evidente grado de incertidumbre sobre el resultado final a obtener. Con objeto de facilitar la cuantificación de los elementos de riesgo, para cada una de las ofertas, éstos iban acompañados por una descripción de lo que debía cuantificarse.


Aunque la identificación de riesgos se llevó a cabo fundamentalmente durante el proceso de preparación de la evaluación, tras la recepción de las distintas ofertas se detectaron nuevos elementos de riesgo, que fueron incorporados al diccionario inicial. 5.3.3.

Evaluación del impacto

El segundo paso consistió en la evaluación del impacto que la aparición de cada uno de los elementos de riesgo, identificados en el proceso anterior, podría tener para el desarrollo del subsistema. El objetivo fundamental de esta evaluación del impacto fue estimar el efecto que cada una de las posibles desviaciones detectadas causaría en el subsistema final a obtener. Esta tarea se realizó antes de la recepción de las ofertas y simultáneamente a la identificación de los riesgos. Con objeto de facilitar el proceso, la evaluación se efectuó siguiendo la misma descomposición descendente que se generaba en la identificación de los riesgos. Para ello se estableció una importancia o peso relativo a cada una de las áreas de riesgo identificadas. Posteriormente se asignó un peso, dentro de cada una de las áreas, a los bloques de riesgo que la constituían. Por último se asignaron pesos a los elementos de riesgo identificados dentro de cada uno de los bloques. Estos pesos fueron normalizados de modo que la suma de los pesos correspondientes a todas la áreas de riesgo fuera igual a la unidad. Esta normalización se aplicó igualmente para todos lo bloques de cada una de la áreas y para todos los elementos de cada uno de los bloques. De este modo el impacto final, sobre el programa, de cada uno de los elementos de riesgo identificados, se pudo obtener efectuando el producto de los pesos del propio elemento, del bloque de riesgo al que pertenecía y del área que contenía dicho bloque.

66


Desde el momento de la propia concepción de la metodología descrita se detectó que la evaluación del impacto no podía ser únicamente el resultado de un proceso técnico. La evaluación del impacto debía estar condicionada por las prioridades de programa evaluado y por la propia sensibilidad del decisor, responsable final de la adjudicación, es decir, por su función de utilidad. Para ello, la asignación de pesos anteriormente descrita se realizó, al menos en los niveles superiores de la estructura jerárquica, siguiendo los criterios del Jefe de Programa. 5.3.4.

Cuantificación de la probabilidad

Una vez recibidas las ofertas se procedió a la cuantificación de la «probabilidad» de los elementos de riesgo para cada una de las ofertas. Debe destacarse que, con la metodología descrita, no se pretendió en absoluto establecer una verdadera probabilidad, es decir, un conjunto de valores que cumplan los axiomas de probabilidad, sino únicamente cuantificar un índice, para cada una de las ofertas, del grado de ocurrencia de los elementos de riesgo identificados. Esta cuantificación para las distintas ofertas se tradujo, de forma práctica, en la asignación de un valor, entre muy alto (9) y muy bajo (1), del grado de ocurrencia de cada uno de los elementos de riesgo. Este tipo de asignación, aunque se efectúo de la forma más objetiva posible, carece de las ventajas asociadas al formalismo matemático. La cuantificación del grado de ocurrencia por métodos matemáticamente formales no fue realizada por dos causas fundamentales: 1) Estimar estas probabilidades de modo estadístico resultó imposible debido a la ausencia de un espacio muestral nacional sobre el que extraer datos. 2) La estimación de una probabilidad, en el sentido axiomático del término, mediante técnicas como la de ChurchmanAckoff, Delphi o similares, hubiera requerido un esfuerzo


muy significativo en términos de horas-hombre. Como resultado de este esfuerzo se obtendrían únicamente las ventajas asociadas al puro formalismo matemático, pero se complicaría notablemente la metodología sin aportar un incremento de la objetividad. El mecanismo de asignación adoptado supuso, desde el punto de vista práctico, algunas ventajas importantes: sencillez, facilidad de modificación, comprensión por parte del decisor y adecuación a la percepción subjetiva del evaluador. Para un mejor aprovechamiento la cuantificación numérica se acompañó de unos comentarios justificativos de la misma, los cuales incluían la identificación de los puntos o párrafos de la oferta en los que se había detectado la posible aparición del elemento de riesgo. Merece destacarse que, mientras la identificación y la evaluación del impacto de los riesgos se realizaron en el proceso de preparación de la evaluación, la cuantificación de los mismos se efectuó específicamente para cada una de las ofertas durante el proceso de evaluación propiamente dicho. La Figura 5.2 muestra la relación entre el análisis de riesgos y el procedimiento general de evaluación de ofertas. Además, y a diferencia de los procesos anteriores que se ajustan a una descomposición descendente, la cuantificación de riesgos se realizó únicamente para el nivel inferior de dicha descomposición. 5.3.5.

Integración

Finalmente se procedió a la integración de los resultados obtenidos mediante el análisis de riesgo de las distintas ofertas. Dicha integración se llevó a cabo recorriendo, desde los niveles inferiores hacia los superiores, la jerarquía generada para la identificación de riesgos. Esta operación permitió asignar un valor numérico al nivel de riesgo asociado a cada una de las ofertas, así como a las áreas y bloques de riesgo en que se descomponen.

68



El nivel de riesgo asociado a un bloque, para una determinada oferta, se construyó sumando, para todos elementos de riesgo en que se descomponía, el producto de su probabilidad, o grado de ocurrencia, por su impacto, o peso ponderado, dentro del bloque. De forma análoga se obtuvo el nivel de riesgo para cada una de las áreas y para el global de las diferentes ofertas, consiguiéndose un valor del nivel de riesgo, para las diferentes ofertas, que podía variar teóricamente entre: Cero (grado de ocurrencia nula de cualquier factor de riesgo que pudiera tener algún impacto sobre el desarrollo del programa) y Diez («probabilidad» casi segura, o grado de ocurrencia evidente, de factores de riesgo que impedirían el desarrollo esperado del programa). En la práctica los resultados variaron entre 3,9 y 5,6. Merece destacarse que, en las primeras aplicaciones de la metodología, se ha observado una cierta «aversión» de los evaluadores a asignar probabilidades muy altas o muy bajas a la aparición de los elementos de riesgo. Los resultados de esta integración, además de en un formato tabular numérico y comentado, se ofrecieron al decisor en forma de gráficos comparados para las distintas ofertas. Estos gráficos presentaban tanto el perfil como la contribución al riesgo de cada una de las ofertas. Los gráficos de perfil de riesgo permitían visualizar, por ejemplo, los niveles de riesgo de las diferentes áreas obtenidos para cada una de las ofertas evaluadas. Los gráficos de contribución al riesgo presentan la misma información, pero ponderada por el impacto o peso relativo de cada una de las áreas. La inclusión de este tipo de gráficos resultó una ayuda valiosa para detectar en qué áreas o bloques la presencia de altos niveles de riesgo era especialmente indeseable. 5.3.6.

Automatización del proceso

Toda la metodología descrita en este capítulo se implementó en una herramienta informática, EVALOFER, que integra los cuatro pasos

70


descritos para el análisis de riesgo dentro del proceso global de la evaluación de ofertas. Esta herramienta, aunque conceptualmente sencilla, ha tenido que ser desarrollada específicamente para tal fin. La utilización de EVALOFER, junto con la aplicación de una metodología normalizada, que especifica procesos y asigna responsabilidades dentro del programa SANTIAGO, ha permitido tanto la automatización relativa del proceso como la obtención de resultados objetivos y fácilmente manejables. La Figura 5.3 muestra una pantalla de la mencionada herramienta informática correspondiente a la integración de resultados. El análisis de riesgos debe contemplarse como una de las áreas fundamentales dentro de la ingeniería de sistemas con un influencia directa en el apoyo a la toma de decisiones. Este tipo de análisis es una labor recurrente que debe efectuarse tanto durante la fase de selección de alternativas como durante el seguimiento de los programas. Todo ello con el doble propósito de tratar de cuantificar,


a priori , los riesgos asociados a las distintas alternativas y apoyar la gestión de riesgos encaminada a su minimización. 5.4. Consideraciones finales La frecuencia con que, durante el desarrollo de un programa, se presentan desajustes entre los costes, plazos y prestaciones técnicas previstas y las finalmente alcanzadas deben hacernos reflexionar sobre la importancia que debe concederse al análisis de riesgos desde las fases más tempranas del desarrollo de un programa. La dificultad principal con que tropieza el análisis de riesgos durante las fases iniciales del desarrollo de un sistema es la escasez de información y definición. Esta escasez impide en muchas ocasiones la cuantificación formal del riesgo, conduciendo a un entorno de decisión de casi incertidumbre. La forma más eficaz de superar estas dificultades es utilizar la experiencia acumulada en proyectos anteriores, articulando un procedimiento que facilite esta reutilización. Estamos seguros que la metodología aquí descrita es perfeccionable, de hecho se mejora con cada aplicación de la misma. Pese a ello no pueden dejar de destacarse algunos logros que, tal vez por la simple sistematización, y pese a los diseñadores y operadores de la metodología, se han hecho patentes con el transcurrir del tiempo: 1) El empleo de esta metodología resalta aquellos aspectos de cada una de las ofertas que pueden constituir elementos de riesgo. La enfatización de estos aspectos permite, al menos, la petición de una clarificación sobre los mismos. En muchos casos es posible la realización de una negociación específica, sobre los puntos críticos, previa a la adjudicación.

72


2) El diccionario de riesgos generado por la aplicación sucesiva de la metodología descrita, y posterior seguimiento de los subprogramas, se ha mostrado como un punto de partida eficaz en el momento de encarar la realización del análisis de riesgos correspondiente a un nuevo proceso de evaluación de ofertas. 3) La sencillez formal de la metodología utilizada, pese a los inconvenientes anteriormente expuestos, se traduce en un alto nivel de confianza en la misma por parte del decisor, el cual, además de comprender su enfoque global, es capaz de controlar la importancia relativa de sus distintos componentes.


74


75

6

Procedimiento de evaluación de ofertas en el programa SIMCA

76


6.1. Descrip Descripción ción genera generall del del progra programa ma SIMCA SIMCA El programa Sistema de Mando y Control Aéreo (SIMCA) del Ejército del Aire tiene como objetivo disponer de un sistema que permita per mita conocer la situación en todo el espacio aéreo de responsabilidad y que facilite la toma de decisiones en la conducción condu cción de las operaciones aéreas tanto defensivas como ofensivas ofen sivas y las de apoyo en situaciones de paz o de crisis. El SIMCA debe ser un sistema fiable, seguro, debe operar ininterrumpidamente, y ha de poder intercambiar información con otros sistemas. Consta de tres subsistemas: Mando y Control, Vigilancia y Comunicaciones. El SIMCA sustituirá al actual sistema Semiautomático de Defensa Aérea (SADA), operativo desde el año 1977 y formará parte del futuro Sistema de Mando y Control Aéreo de la OTAN (ACCS) que a su vez sustituirá al sistema actual de control y detección de la Alianza NADGE (NATO Air Defence Ground Environment) [13,14]. Para realizar dicha transformación se están realizando proyectos, en cada uno de los tres subsistemas mencionados, que se encuentran en diversas fases de ejecución. Unos se encuentran en fase de definición y especificación de requisitos, otros en fase de evaluación de ofertas y otros en estado más avanzado como son la realización de revisiones críticas, fabricación y producción de prototipos y primeras series con la realización de las correspondientes pruebas de validación.

77 Procedimiento Procedimiento de evaluación de ofertas en el programa SIMCA

Las áreas de actividad en las cuales se está desarrollando la participación de Isdefe dentro del programa SIMCA se pueden englobar principalmente en tres bloques que se corresponden con los subsistemas en que se divide el programa: Mando y Control, Vigilancia y Comunicaciones. En ellas se participa dando apoyo a la Oficina de Programa, en los siguientes aspectos: a) Análi nálisi siss de de nec neces esid idad ades es;; b) Estud studio ioss de de alt alter erna natitiva vas; s; c) Especi Especific ficaci ación ón de requisi requisitos tos (operat (operativo ivos, s, funcio funcional nales es y técnicos); d) Evalu aluación de de of ofert ertas; e) Segu Seguim imie ient ntoo y con contr trol ol de de proy proyec ecto tos; s; f) Prueb ruebas as de acep acepta taci ción ón del del sis siste tema ma;; g) Audi Audito torí rías as y dict dictám ámen enes es téc técni nico cos; s; y h) Garant antía de calidad. En el seguimiento de los proyectos del programa SIMCA el capítulo relativo a la evaluación de las ofertas presentadas por los posibles contratistas, en respuesta a un Pliego de Prescripciones Técnicas (PPT) donde se definen los requisitos técnicos técn icos y operativos que deben cumplir los sistemas o equipos requeridos, requ eridos, es un aspecto que condiciona la obtención de un producto que satisfaciendo las necesidades del cliente minimice los costes. Existe otro concepto que debido a los puntos de similitud que posee con la evaluación de ofertas se puede confundir con este y que es el del análisis de riesgos. Este último se emplea como complemento del anterior en aquellos proyectos en los cuales, a la hora de tener que tomar una decisión sobre una u otra solución propuesta, estas se basen en nuevos diseños o desarrollos (I+D) que impliquen o conlleven cierto riesgo en su ejecución. Aspectos específicos relativos al análisis de riesgos se tratan en el Capítulo dedicado al programa SANTIAGO de esta monografía.

78


El proceso de evaluación de ofertas es una parte par te decisiva y que se lleva a cabo al inicio del proyecto, determinando en gran medida la buena marcha de las fases posteriores del mismo. La elección de un equipo o sistema con unas prestaciones o características degradadas, degr adadas, comparándolas con las requeridas, puede suponer un encarecimiento considerable del ciclo de vida logístico del producto además de la insatisfacción del usuario. El procedimiento de evaluación debe basarse en métodos lo más objetivos posibles, de manera que dicho procedimiento sea transparente. 6.2. Eval Evaluaci uación ón de ofertas. ofertas. Metodo Metodolog logía ía 6 .2 .1 .

Introducción

En el proceso de evaluación de ofertas, y principalmente en proyectos donde los sistemas o productos a obtener sean de cierta envergadura tanto técnica como económica, como ocurre en el programa SIMCA, es preciso tener en cuenta no solo el sistema a adquirir como tal (radar, equipamiento de Centro de Mando y Control, equipo de comunicaciones, red de microondas, etc) sino también otros aspectos que van ligados al ciclo de vida del producto tales como su mantenibilidad, mantenibilid ad, fiabilidad, disponibilidad, disponibilidad , coste,... etc. [6]. Es pues, este, un proceso complejo y delicado que implica el concurso de especialistas por temas o áreas y en el que partiendo de una especificación de requisitos se trata de sopesar los aspectos o soluciones contenidos en las diversas ofertas suministradas por las empresas que concurren. El mayor o menor acierto en la adquisición del de l sistema o equipo que satisfaga las necesidades del usuario dependerá en gran medida, además del nivel de detalle y calidad con el que haya sido confeccionada la especificación de requisitos técnicos, del método de evaluación utilizado para seleccionar la oferta más adecuada.

79 Procedimiento de evaluación de ofertas en el programa SIMCA

Existen diversos métodos o procedimientos para la realización de evaluaciones, pero independientemente de cual sea el elegido todos ellos deben cumplir o perseguir una serie de objetivos básicos: a) b) c) d)

Objetividad y transparencia en el proceso; Precisión; Agilizar y facilitar la evaluación; Obtención de un producto acorde con los requisitos y que satisfaga o posea la mejor relación calidad-precio; y e) Permitir la justificación de la elección realizada. Entre las ventajas que comporta la realización de una evaluación llevada a cabo en base a una metodología objetiva se pueden destacar las siguientes: a) b) c) d) e) f)

Reducir, o al menos ponderar, la incertidumbre; Facilitar la posterior utilización de resultados; Normalizar el proceso de presentación y selección; Aumentar la transparencia del proceso de selección; Aumentar la credibilidad del organismo evaluador; y Mejorar la comunicación tanto interna del organismo que evalúa como externa con las empresas.

6.2.2.

Procedimiento de evaluación

6.2.2.1.

Principios básicos

El procedimiento de evaluación utilizado en los proyectos involucrados en el programa SIMCA al igual que cualquier procedimiento de evaluación que se considere, se basa en los tres principios o premisas siguientes: 1. Estricto seguimiento de unos procedimientos de evaluación bien definidos y uniformes para todos los casos.

80


Los procedimientos definen claramente la forma en que debe realizarse la evaluación incluyendo: formatos, métodos de evaluación a utilizar, forma de asignación de grupos evaluadores, generación de informes, archivo y tratamiento de la documentación generada en el proceso de evaluación, etc. En particular el procedimiento de evaluación está formado por dos grupos de valoraciones: a) Valoración global. Constituye el primer paso en el estudio de la oferta donde se realiza un análisis general de los siguientes temas, que deben estar convenientemente explicados en la misma: (1) cumplimiento de los criterios excluyentes, si los hubiera; (2) requisitos técnicos y operativos; (3) apoyo logístico y calidad del suministrador; y (4) criterios específicos para el proyecto, como pueden ser la planificación y el plan de pruebas. b) Valoración detallada. Se realiza utilizando el método de Atributos Ponderados Jerarquizados, usando una combinación de dos sistemas conocidos como son los de Listas de Control e Índices de Rentabilidad (para los proyectos en que se requieran). Listas de Control son sistemas básicamente cualitativos en los que se valoran, de forma subjetiva, diversos criterios de una oferta. Los criterios pueden ponderarse, tanto de forma individual como agrupados. La ponderación de cada criterio suele realizarse asignando un valor numérico dentro de una escala establecida (por ejemplo de 0 a 5). La suma de todos los criterios con las ponderaciones previstas en cada caso, representa el índice de mérito de la


oferta, bien directamente o como porcentaje del valor máximo alcanzable. Las listas de control tienen las siguientes ventajas: (1) versatilidad para adaptarse a cualquier tipo de oferta; (2) sencillez en su cumplimentación; (3) determinación de puntos fuertes y débiles; y (4) jerarquización de las ofertas en función de su índice de mérito. Estas listas presentan, sin embargo, los inconvenientes siguientes: (1) subjetividad en la valoración de los criterios, solo corregible con la intervención de diferentes especialistas; y (2) necesidad de amplia experiencia en su utilización, si se usa el índice de mérito como base exclusiva de aceptación y ponderación elegida. El condicionante mayor de las listas de control lo constituye la elección de los criterios de evaluación, así como la escala de valoración y la ponderación elegida. Los Índices de Rentabilidad son métodos cuantitativos en los que se valoran aspectos financieros de la empresa. Estos índices tienen la gran ventaja de utilizar términos financieros de fácil comprensión y facilitar la comparación de unas ofertas con otras al reducirse a términos económicos. Sin embargo, presentan el inconveniente de que anteproyectos de muy distinta credibilidad y atractivo pueden tener índices iguales. 2. Definición de unos criterios de evaluación que son, en general, distintos para cada tipo de sistema a evaluar, pero que son iguales o muy similares para evaluar sistemas del mismo tipo o características.

82


Los criterios definen los subsistemas, áreas y atributos que son objeto de calificación durante el proceso de evaluación. Se asigna un peso a cada uno de dichos parámetros. La definición de criterios se efectúa por un grupo de expertos en el tipo de sistema considerado. 3. Creación de un grupo de trabajo, formado por especialistas en los temas a evaluar para realizar las calificaciones concretas para cada proyecto de cada sistema. Estas calificaciones se ajustan siempre a los procedimientos y criterios definidos en los puntos anteriores. Las calificaciones, asignadas por el equipo evaluador, constituyen la puntuación numérica subjetiva a cada área o atributo objeto de calificación, reflejando el grado en que las ofertas presentadas satisfacen los criterios establecidos. 6.2.2.2.

Definición de los criterios en la evaluación de ofertas

La definición de los criterios se realiza por un grupo de expertos en los temas que se tratan, con objeto de que sean enfatizados aquellos aspectos relevantes sobre aquellos que no lo sean tanto. Dicho grupo realiza las acciones siguientes: a) Define un conjunto de ÁREAS a evaluar en cada una de las ofertas (grupo de criterios); b) Selecciona un conjunto de ATRIBUTOS dentro de cada una de las áreas; c) Asigna pesos o PONDERA los atributos y las áreas (baremo); y d) Asigna una puntuación numérica o CALIFICACIÓN a cada uno de los atributos. Para calificar los atributos, se define una escala numérica que es utilizada por el equipo evaluador para indicar el grado en que los anteproyectos satisfacen los criterios establecidos.


A cada atributo se le asigna una puntuación y para dar más relevancia a unos que a otros, se les asigna a cada uno un peso que sirve como factor de ponderación. Combinando entre sí las calificaciones de los atributos de cada área, se obtiene la calificación de área. De la misma manera que para los atributos, cada una de las áreas tiene un peso, y combinando entre sí las evaluaciones de cada área, se obtiene la calificación final de cada oferta, que constituye el índice de mérito de la misma. Los criterios se visualizan, una vez definidos, mediante unas tablas jerarquizadas. Con objeto de comprender más claramente la estructura y el proceso de valoración de criterios se muestra el ejemplo concreto de la valoración de un sistema radar, el cual se desglosa en apartados como se refleja en la Figura 6.1. En la primera tabla, o la de orden superior (ver Figura 6.2), se refleja el organigrama del sistema a evaluar con el desglose de los criterios - áreas principales en otras secundarias (subtablas). En ella se puede observar que se han considerado cuatro criterios principales: 1) 2) 3) 4)

Valoración de aspectos globales; Criterios técnicos y operativos; Apoyo logístico y calidad del suministrador; y Criterios específicos para el proyecto.

Cada uno de los cuales se subdivide a su vez en nuevos criterios que constituyen las tablas de orden jerárquico inferior. El método de valoración de los atributos se realiza estableciendo una escala de puntuación para cada atributo entre 0 y 5 con valores naturales, entendiéndose que los valores 0, 1, 2 indicarían un no cumplimiento o mal cumplimiento de lo especificado y los valores 3, 4 y 5 un cumplimiento de los mismos.

84



Se establecen, dependiendo de que se requiera en el proyecto en cuestión, criterios excluyentes de manera que una puntuación por debajo de 3 de algún atributo, elegido previamente, supone el rechazo automático de la oferta en cuestión. Cuando algún punto de una tabla de orden superior se descompone en una tabla de orden inmediatamente inferior, la aportación de la tabla de nivel inferior a la superior se convierte a una puntuación entre 0 y 5, mediante el siguiente algoritmo: ∑ Puntuaciones elementales (T. Inferior)

Puntuación parcial (Tabla superior)=

x 5

∑ M a x i m o s e l e m e n t a l e s ( T . I n fe r io r )

La contribución de las tablas principales a la tabla de valoración total son los valores de la suma de puntuaciones (Pi) y la suma de máximos (Mi) como puede verse en las Figuras 6.2 y 6.3.

86


6.2.2.3.

Fases en el procedimiento de evaluación

En la Figura 6.4 se pueden observar en forma de organigrama las fases principales de que consta el procedimiento o proceso de evaluación de ofertas. Aunque no sea parte propiamente dicha del propio proceso de evaluación se parte del PPT, como documento de referencia en la documentación, para la petición de ofertas a las empresas, así como del procedimiento de evaluación. Se crea un grupo formado por expertos en las tecnologías involucradas o contempladas en el sistema a evaluar que se encarga de realizar, partiendo del PPT, tanto el desglose de los atributos y áreas como el pesado o la ponderación de los mismos siguiendo el procedimiento de evaluación elegido. Se crea también un grupo evaluador por la autoridad que corresponda, formado por especialistas por temas, cuya misión será la de evaluar-calificar los apartados o aspectos de las ofertas presentadas comparándolos


88


con el documento de referencia que es el PPT. Una vez recibidas las ofertas, que deberán contener de forma desglosada todos aquellos puntos o aspectos que se demanden en el PPT, se realiza la lectura detallada de las mismas por el grupo evaluador. Este realiza las peticiones de aclaración que estima oportunas, las cuales son respondidas por escrito. Una vez que el grupo evaluador realiza la calificación de las ofertas recibidas y, obtenido el índice de mérito, realiza el informe final terminándose así el proceso. 6.3. Consideraciones finales El proceso de evaluación de ofertas es una parte decisiva y que se lleva a cabo al inicio del proyecto condicionando en gran medida la buena marcha de las fases posteriores del mismo. La elección de un equipo o sistema con unas prestaciones o características degradadas, comparándolas con las requeridas, puede suponer un encarecimiento considerable del ciclo de vida logístico del producto además de la insatisfacción del usuario. El procedimiento de evaluación debe basarse en métodos lo más objetivos posibles de manera que dicho procedimiento sea transparente.


90


91

7

Análisis de valor en la F-100

92


7.1. El programa F-100 El programa de fragatas F-100 se enmarca dentro de los planes propuestos por la Armada para el desarrollo y construcción de nuevas unidades y sigue para su realización la metodología de programación de armamento por fases (Phased Armaments Programming System, PAPS) de acuerdo con las directrices del Ministerio de Defensa, que es similar al ciclo de vida de los sistemas [6]. El programa F-100 se encuentra en la actualidad en la parte final de la fase de definición del proyecto (diseño) del buque. Esta fase es previa a la de producción. 7.2. Análisis de valor en el programa F-100 Isdefe participó en el Estudio de la Fase de Viabilidad del diseño del buque (segunda fase del ciclo de vida del sistema) como contratista principal, con responsabilidad directa en las áreas de Sistema de Combate, Planificación, Análisis Industrial, Logística y Costes. El estudio tuvo dos fases. La primera consistió en explorar y estudiar un número limitado de variantes de un diseño base (Proyecto Preliminar) que cumpliesen con lo establecido por los requisitos de la Armada y que posibilitase un proceso de comparación riguroso, para la selección de uno de ellos o de uno compuesto por partes de

93 Análisis de valor en la F-100

los mismos, que minimizase los riesgos del programa. La segunda fue profundizar en el buque seleccionado ampliando el proyecto hasta alcanzar un nivel de desarrollo, que permitiese abordar la siguiente fase (definición de proyecto) con un estado del estudio suficientemente avanzado y los principales aspectos del proyecto definidos. Uno de los aspectos más novedosos de este estudio fue la realización, dentro de la primera fase, de los análisis de costes de diez alternativas del sistema de combate, y de las plataformas capaces de sustentarlas, para predecir las desviaciones frente al objetivo de costes de las alternativas en estudio, y posibilitar la contención de costes del programa en función de las desviaciones encontradas. Los requisitos de la Armada impusieron inicialmente que las fragatas tuviesen como misión principal la lucha antisubmarina, aunque durante el desarrollo del Estudio de Viabilidad se contempló también la alternativa de lucha antiaérea como misión principal, lo que obligó a estudiar un número elevado de alternativas debido a unas configuraciones de buque tan diferentes. 7.3. Análisis de costes. Estudios paramétricos 7.3.1.

Generalidades

Las estimaciones de costes de un buque, o de cualquier sistema, deben realizarse desde las fases más tempranas del proyecto utilizando diferentes técnicas de estimación puesto que las decisiones de diseño o logísticas, tomadas al inicio de un proyecto, comprometen un alto porcentaje de las inversiones a realizar en el ciclo de vida del sistema, como se indica en la Figura 7.1. La estimación del coste de un sistema evoluciona y se refina según se desarrolla el programa. La precisión en la estimación depende de forma muy importante en la fiabilidad de los datos de los elementos de coste.

94


Las técnicas más comúnmente utilizadas son: (1) estimación paramétrica, (2) estimación por analogía y (3) estimación Integradora. La estimación paramétrica se emplea en estudios en los que el nivel de definición del buque no es muy alto y no se tienen datos comerciales para realizar valoraciones según precios de mercado, si no fundamentalmente datos técnicos, o el tiempo disponible para la realización de la estimación es escaso, con este método se llega a una estimación de coste de las unidades en estudio con un grado de fiabilidad que dependerá de las herramientas empleadas y del nivel de definición del proyecto, permitiendo analizar diferentes alternativas de configuración del buque y controlar las posibles desviaciones del coste objetivo. La estimación por analogía se realiza en las fases muy iniciales de los proyectos y consiste en estimar el coste del buque por analogía con otros ya construidos; se usa para validar estudios realizados con otras herramientas.


La estimación integradora (bottom-up) exige un conocimiento muy detallado del buque a nivel de equipos y se utiliza en fases más avanzadas del desarrollo del proyecto. Para su realización necesita la utilización de muchos recursos tanto humanos como de tiempo, así como de datos fiables de coste de equipos históricos o actuales. En la Figura 7.2 se presentan las diferentes técnicas de estimación de coste en función de las fases de evolución del programa. Existen diferentes tipos de herramientas paramétricas: específicas y generales. Dentro de las primeras están las que realizan las empresas para la predicción de sus propios productos o las que se conciben para un tipo de sistema (buques, aeronaves, etc.) con una gama de aplicación más amplia. Las segundas permiten predecir el coste de cualquier sistema en función de parámetros genéricos (peso, volumen, etc.) que lo caracterizan.

96


7.3.2.

Análisis de costes

Durante el Estudio de Viabilidad de la fragata F-100 se realizaron dos tipos de estimaciones de las tres mencionadas: estimaciones paramétricas y estimaciones integradoras. En la primera fase se estudió paramétricamente el coste del buque para diez variantes; en la segunda fase del estudio se profundizó mediante un modelo integrador en el tipo de buque elegido tras los estudios de la primera fase. En la realización del análisis y estimación del coste del buque, éste se dividió en dos partes. La primera parte correspondió a la plataforma del buque y la segunda al sistema de combate. El motivo de tal división fue que los equipos del sistema de combate son difíciles de estimar por métodos paramétricos, debido al alto coste de los mismos, a lo sensible que es el coste de los equipos de estos sistemas en las distintas situaciones internacionales, a la escasa competencia que existe en equipos específicos de alta tecnología, así como al gran número de configuraciones posibles de sistemas de combate que se contemplaban, mientras que la plataforma es más fácilmente parametrizable debido a sus características. Las variantes del sistema de combate se sustentaron sobre tres plataformas de buque denominadas 1, 2 y 3. Las configuraciones del sistema de combate se denominaron 1A, 1B, 2A, 2B, 3, 4, 4A, 5, 5A y 6, y se establecieron para designar los diferentes niveles de cumplimiento de los requisitos de la Armada. Las configuraciones del sistema de combate más capaces se asociaron a plataformas de mayores prestaciones, disminuyéndolas según se rebajaba la capacidad y prestaciones del sistema de combate. En la Figura 7.3 se presentan las diferentes configuraciones de los buques en función de las prestaciones de la plataforma y del sistema de combate. El hecho de que existan varias configuraciones de buque en un mismo apartado de la tabla se debe a cambios en


equipos que, aproximadamente, pueden dar el mismo nivel de prestaciones al buque. Para la realización de los análisis de las diez alternativas se utilizaron herramientas paramétricas de estimación de coste específicas de buques, contrastadas anteriormente en otros programas navales (estudio de la NFR90 - Nato Frigate Replacement for ´90s). 7.3.3.

Herramienta paramétrica de estimación de costes

La herramienta paramétrica utilizada en el estudio funciona de la forma que se representa esquemáticamente en la Figura 7.4. Los datos introducidos dan los condicionantes y limitaciones que debe cumplir la plataforma y entre ellos figuran: Tipo de Buque;

98



Velocidad-autonomía; Dimensiones del buque (Rango: Máximas, mínimas); Coeficientes hidrodinámicos; Tipo de propulsión; Tipo de material del casco; Tripulación; Requisitos eléctricos; Márgenes. Se introducen también los datos de los equipos que forman el sistema de combate del buque (sistemas de comunicaciones, control y armamento), de los que se dan: peso, volumen requerido, coste y horas de instalación estimadas, así como los parámetros indicadores de la incidencia del sistema de combate en la plataforma. Por último, se introducen los parámetros específicos de costes, como son: año para el cálculo del presupuesto, número de buques para prever efecto serie o no, productividad del astillero constructor, tasas de inflación en porcentaje, valores de coste horarios y gastos generales. Con los datos aportados el modelo paramétrico realiza los cálculos internos y devuelve como salida los resultados de las características técnicas (pesos, potencia, dimensiones principales, etc.), que se comparan con los datos calculados en el proyecto. Si no existiese una gran diferencia entre los resultados y los valores del proyecto, se considerarán como buenos los valores de costes obtenidos. Si por el contrario existieran diferencias notables, nota bles, se deben modificar los datos introducidos hasta que se obtengan resultados análogos entre los predichos por el programa paramétrico y los datos técnicos del proyecto. Una vez logrado un acuerdo entre éstos, los resultados de costes que se obtienen también se consideran adecuados. Esta técnica permite predecir el coste de las alternativas y posibilita una vez encajado un buque, en cuanto a sus características técnicas, realizar modificaciones con una gran rapidez para conseguir con seguir costes de alternativas. Se debe hacer notar que una modificación de algún elemento del sistema de combate lleva aparejada modificaciones en la plataforma, lo que sería muy costoso de analizar caso por caso,

100


mientras que el análisis paramétrico tiene en cuenta estas modificaciones y las realiza de una forma prácticamente inmediata. 7.3. 7. 3.4. 4.

Aplica Apli caci ción ón de lo loss aná análilisi siss par param amét étri rico coss de de ing ingen enie ierí ríaa de de costes en la fragata F-100

Partiendo de las características técnicas de la fragata F-100 y de los datos de la lista de equipos más importantes, aproximadamente unos cuarenta, que configuraban el sistema de combate del buque de máximo cumplimiento de requisitos (alternativa 1A), se realizó el encaje del primer buque y a continuación se obtuvieron los costes de las otras nueve siguientes variantes, lo que supuso finalmente el análisis del coste de diez alternativas. En la Figura 7.5 se ha representado la relación entre el desplazamiento del buque y el coste de las alternativas de la fragata F-100.


En la Figura 7.6 se indican los resultados porcentuales de las alternativas consideradas. El coste de valor 100 se da al Objetivo de Coste fijado por la Armada y para el resto de las alternativas se da la desviación en porcentaje de ese valor y el desglose porcentual de sus componentes, plataforma y sistema de combate. Estos resultados se presentan en la Figura 7.7 donde se muestra la desviación de cada alternativa estudiada sobre el objetivo de coste (100) y la distribución del coste total entre las dos partes principales en que se han dividido el buque: plataforma y sistema de combate. El análisis de estas diez alternativas de buques, permitió a la Armada contemplar soluciones de diseño muy diferentes, según el nivel de cumplimiento de los requisitos técnicos y de coste, logrando con ello que la toma de decisión final sobre el buque fuese lo más adecuada a sus necesidades.

102


7.4. Con Conside sideraci racione oness fin finales ales El valor de cualquier sistema de armas es un condicionante con dicionante muy fuerte durante el proceso de adquisición. Por tanto la estimación del coste se debe realizar desde las fases más tempranas del proyecto. La utilización de las herramientas de estimación paramétricas ayudan en este proceso. Las estimaciones paramétricas de coste permiten analizar diferentes alternativas de los sistemas de armas con una inversión de recursos limitada y con una precisión aceptable en los resultados. La estimación paramétrica de costes es necesaria en las fases iniciales de cualquier sistema, permitiendo analizar alternativas de diseño que posibiliten una toma de decisión lo más correcta posible, po sible, y puede llevar a ahorros considerables en el coste del ciclo de vida del sistema con pequeñas variaciones en el cumplimiento de los requisitos.


104


105

8

Gestión de la configuración en el SCTM

106


8.1. Programa SCTM El programa SCTM está incluido dentro del contexto de planeamiento e implantación del Sistema Defensa C3 (Mando, Control y Coordinación) y su finalidad es la obtención del Sistema Conjunto de Telecomunicaciones Militares (SCTM). El SCTM es un sistema de cobertura nacional con soporte de red en estaciones terrenas fijas, y cuyo objeto es satisfacer necesidades operativas de servicios de telecomunicación (voz, mensajes, datos e imágenes) que requieren los usuarios y sistemas del Mando y Control Militar. El SCTM dispone de puntos de interconexión con otros sistemas o redes de telecomunicaciones que permiten ampliar la cobertura de interfuncionamiento con otros usuarios varios (Tácticos, Satélite, OTAN, Públicos y Privados). El carácter conjunto del SCTM se fundamenta en que posibilita la preparación y conducción de las operaciones militares y permite su empleo conjunto por los usuarios de Defensa. Debido a que por su naturaleza el SCTM es un sistema dinámico y abierto, cuyo diseño e implantación viene siendo progresivo y gradual en función de la propia evolución de las necesidades operativas que ha de satisfacer, su situación actual responde a dos vertientes, una de medios ya en servicio, cuyo funcionamiento está soportado por las estructuras logísticas asignadas de operación y sostenimiento de las Fuerzas Armadas, y otra de obtención de nuevos medios, que potencien y amplíen los existentes mediante la ejecución de los correspondientes proyectos de implantación.

107 Gestión de la configuración en el SCTM

Esta simultaneidad de medios en servicio y en proceso de obtención hace que en el desarrollo del SCTM coexistan las diferentes fases del ciclo de vida de un sistema: (análisis de la necesidad, especificación de requisitos, diseño, desarrollo, producción/ implantación, empleo y apoyo al sistema). El planeamiento del SCTM llevado a cabo en los últimos años se ajustó a la metodología m etodología PAPS PAPS (Periodic Armaments Planning System) de la OTAN, OTAN, y como resultado de la última fase realizada (Fase de Definición) se elaboraron las especificaciones de diseño y desarrollo (año 1990). En concordancia con las actualizaciones de requisitos operativos y priorización de necesidades existentes, actualmente el programa SCTM tiene en proceso de implantación diversos proyectos que, en su conjunto, completarán y potenciarán las estructuras de red y logísticas existentes del SCTM, proporcionando a su vez servicios de telecomunicación a usuarios prioritarios de mando y control. 8.2. Gestió Gestión n de la configur configuración ación aplica aplicada da al SCTM En su perspectiva actual, la concepción de la arquitectura del SCTM responde a una estructura integrada de subsistemas componentes: Transmisión, Conmutación de Circuitos, Conmutación de Paquetes y Tratamiento de Mensajes, Seguridad de Comunicaciones y Gestión y Supervisión. Dentro de la funcionalidad general soportada por esta arquitectura, el Subsistema de Gestión y Supervisión tiene como objetivo principal posibilitar la operación, administración y mantenimiento de los elementos componentes del SCTM, asegurando en todo momento su disponibilidad d isponibilidad y funcionamiento, así como un empleo eficaz y adecuado del mismo. Un aspecto esencial de la funcionalidad requerida al Subsistema de Gestión y Supervisión es la función de Gestión de Configuración, cuyo concepto es objeto de enfoque y aspecto a resaltar en este Capítulo de la monografía.

108


Como es sabido, la implantación de los conceptos y principios de ingeniería de sistemas requiere de una gestión de configuración que asegure disponer a lo largo del d el ciclo de vida de un sistema de una configuración actualizada del mismo, permitiendo controlar los cambios producidos en ella tanto en las fases de diseño e implantación como en la vida operativa del sistema. Asimismo, la disponibilidad de esta configuración actualizada implica y debe ser referencia común del conjunto de organizaciones que tienen responsabilidades en la obtención de un sistema (Oficina de Programa y contratistas) y en el funcionamiento del mismo (organizaciones de operación y apoyo asignadas). La obtención de un sistema de información que, dentro del contexto general de la gestión y supervisión del SCTM, soportase la función de gestión de configuración, ha sido un objetivo prioritario y consustancial con el proceso de planificación y adquisición del SCTM. Este sistema está actualmente en fase de implantación (Diseño Detallado, Desarrollo e Instalación), después de la realización anterior de diversos estudios y elaboración de especificaciones que junto a aplicaciones de prototipados completaron las fases de Diseño Conceptual y Preliminar del sistema. Con la implantación de este sistema se pretende satisfacer la operatividad requerida por los órganos responsables del funcionamiento del SCTM (órganos de dirección y ejecución que constituyen la estructura de operación y sostenimiento) y de su obtención (Oficina de Programa), apoyando la explotación de los medios en servicio y facilitando el proceso de implantación de nuevos medios. 8.3. Concep Concepto to de de gestión gestión de la config configuració uración n En su concepción genérica, la gestión de d e la configuración de un sistema comprende las siguientes áreas funcionales: identificación de la configuración, control de la configuración, registro de estado de configuración y auditorías de configuración.


En el caso específico de un sistema de telecomunicaciones, la gestión de configuración engloba el conjunto de capacidades que permiten identificar identifica r los componentes del sistema, definir las conexiones entre ellos, recoger los datos de funcionamiento (control de estados) estado s) y posibilitar la reconfiguración en caso necesario de los recursos de red disponibles. En su aplicación al SCTM, el concepto concebido de gestión de configuración se enmarca dentro del contexto de funciones de gestión que, junto a las de supervisión supervisió n y control de tiempo real de los elementos del sistema, permitirán apoyar el desarrollo de actividades actividade s y tareas asociadas a su planificación, implantación y operación y apoyo. La organización de estas funciones de gestión que incluyen las aplicables al control de configuración de la red (física y lógica) y apoyo logístico (mantenimiento y abastecimiento), responde al esquema que se representa en la Figura 8.1. Estas funciones estarán soportadas por un conjunto de aplicaciones informáticas que se apoyan en una base de datos constituida por dos partes diferenciadas: 1) Base Base de de dato datoss gráfi gráfica, ca, compues compuesta ta por el conjunt conjuntoo de de plan planos os estáticos y dinámicos que representan la configuración de la red. 2) Base Base de datos datos alfanu alfanuméri mérica, ca, que incluye incluye la identif identifica icació ciónn y descripción de los elementos componentes de la red. Para asegurar la seguridad e integridad de los datos bajo control de las aplicaciones, existirá una aplicación específica de Gestión de Usuarios dotada de mecanismos de control de accesos e interfaces con el resto de aplicaciones. Ello permitirá fijar a cada usuario autorizado las aplicaciones que puede ejecutar y, dentro de ellas, las operaciones que puede realizar.

110


8.33.1. 8.

Elemen enttos de gestión de la confifigu gurrac aciión

La función de Gestión de la Configuración estará soportada sopor tada por el conjunto de procedimientos y herramientas (programas software), que apoyándose en la arquitectura hardware del d el Subsistema de Gestión y Supervisión del SCTM, permitirá: a) La iden identitifificac cació iónn de de los los eleme elemento ntoss de de la la rred. ed. b) El control control de cambios cambios,, así así como como su distrib distribuci ución ón autom automáti ática ca a los órganos responsables de la obtención y funcionamiento de la red. c) El contr control ol de estado estado de los los ele elemen mento toss de de la la red. red. Según se representa en la Figura 8.1, la función de gestión de la configuración se ha subdividido en las siguientes áreas funcionales: fu ncionales:


1) Configuración física, que comprende las funciones de identificación y control de los elementos de planta que constituyen la red. 2) Configuración lógica, que incluye las funciones que permiten la planificación y explotación de la red presentando a los correspondientes operadores autorizados la conectividad y estado de los enlaces y servicios soportados por la misma. 8.3.1.1.

Configuración física

Se basa en la modelización de la red por medio de un conjunto de objetos que representan a cada uno de sus elementos componentes, apareciendo estos objetos ante el operador mediante un símbolo. La asociación de símbolos en una página constituye los mapas de red, cuya visualización permite al operador transitar por las diversas rutas y estaciones que configuran la red. La función de identificación de los elementos de red estará soportada por dos aplicaciones informáticas enlazadas entre sí: Gestión de Planos y Control de Inventario. Esta identificación se realizará a dos niveles: 1) Mediante la posición que ocupa el equipamiento en la planta y alzado de la estación, así como por su composición hasta el nivel de elemento mínimo reemplazable. 2) Mediante un número de inventario asignado a cada elemento componente del equipamiento de la estación. La modificación de los elementos de un determinado equipo, implicará la modificación automática de los planos de la base de datos que corresponden a dicho equipo.

112


A su vez, la función de control de la documentación y manuales descriptivos de la red, estará soportada por la correspondiente aplicación informática. La función de control de cambios permitirá realizar el seguimiento e historial de los cambios realizados sobre los elementos de la red, y su correspondiente aplicación de soporte implicará a los elementos de configuración física de la red, así como a la información descriptiva de ésta. 8.3.1.2.

Configuración lógica

La función de configuración lógica estará soportada por una aplicación basada en los conceptos de simulación discreta aplicables a una red de transmisión, y con ella se pretende disponer de las siguientes capacidades: a) Identificación y control de los enlaces y servicios disponibles en la red. b) Verificación de los niveles de supervivencia de la red, mediante la simulación de caída de nodos y/o enlaces. c) Visualización de los mapas de conectividad de la red. d) Estadísticas sobre recursos de red disponibles. e) Gestión de altas y bajas de servicios. En relación con la operación de red, esta aplicación permitirá determinar la ruta principal y las rutas alternativas posibles en base a la necesidad de establecimiento de un servicio determinado sobre los recursos de red disponibles.


8.4. Descripción de actividades Como se ha indicado en la sección 8.2, la obtención del sistema de gestión de configuración aplicable al SCTM está en fase de implantación mediante proyecto en ejecución, después de haber sido cubiertas las fases de Diseño Conceptual y Preliminar dentro del proceso general de planificación del SCTM. La Fase de Diseño Conceptual fue completada mediante estudios y trabajos de ingeniería llevados a cabo en las distintas etapas de la metodología PAPS (Previabilidad, Viabilidad, Definición, Diseño y Desarrollo), y que en lo relativo a la gestión de configuración, permitieron obtener las correspondientes «Especificaciones de Sistema» (Tipo «A») y un Plan Preliminar de Gestión de la Configuración. Durante la Fase de Diseño Preliminar, en síntesis se realizaron las siguientes actividades y trabajos: ·

Análisis funcional y asignación de requisitos de la arquitectura del sistema de gestión de configuración especificado.

·

Implantación de un prototipo de sistema informático que permitió, por una parte, establecer un embrión de arquitectura para analizar su funcionalidad y apoyar la definición de especificaciones técnicas de la misma y, por otra parte, disponer en base de datos de un primer nivel de planos informatizados que representan la configuración de gran parte de la estructura de red en servicio del SCTM.

·

Elaboración de los Pliegos de Prescripciones Técnicas del expediente de suministro actualmente en ejecución y que incluyen los requisitos técnicos y la metodología que aplican al diseño detallado e implantación del sistema de gestión de la configuración objeto de obtención.

114


El prototipo de sistema implantado se concibió en base a una arquitectura hardware de estaciones de trabajo, una estructura básica de aplicaciones informáticas (gestión de planos y de inventarios) y una carga inicial en base de datos de una partida significativa de planos informatizados de elementos de red que se irán completando mediante sucesivas implantaciones del SCTM. A título de ejemplo, en las Figuras 8.2, 8.3 y 8.4 se han representado unas muestras de tipos de planos de los incluidos en base de datos que identifican a diversas configuraciones de la red y cuya visualización en pantalla de las estaciones de trabajo permiten al operador acceder de forma ágil a las configuraciones de equipamiento instalados en las estaciones del SCTM. 8.5. Consideraciones finales El establecimiento de requisitos de ingeniería de sistemas que permitan armonizar y supervisar los procesos de obtención desde las etapas iniciales de diseño, es garantía de alcanzar en plazos y costes los objetivos operativos planteados para la adquisición de un sistema. En particular, ello es tanto más necesario en aquellos casos de proyectos cuyo alcance de implantaciones impliquen nuevos desarrollos. La gestión de la configuración es una función esencial cuya ejecución abarca todo el ciclo de vida de un sistema y que facilita en gran medida su obtención y posterior funcionamiento. La implantación de los conceptos y principios de ingeniería de sistemas requiere disponer de una buena gestión de la configuración. En su concepción genérica la gestión de la configuración es común para todo tipo de sistemas y comprende las siguientes áreas funcionales: Identificación, Control, Registro de Estados y Auditorías de Configuración. De la experiencia obtenida de los trabajos llevados a cabo para la definición e implantación del sistema de gestión de configuración aplicable


116


al SCTM, cabe resaltar la utilidad que ha tenido desarrollar un prototipo de sistema, lo que ha permitido probar y evaluar los conceptos de diseño y completar las especificaciones técnicas del sistema objeto de obtención en concordancia con la funcionalidad operativa requerida. Aspectos que se consideran fundamentales para desarrollar la función de gestión de la configuración, además de disponer de las correspondientes capacidades técnicas y elementos de soporte, son los concernientes al establecimiento de una estructura de organización y unos procedimientos que aseguren en todo momento la consistencia e integridad de la información asociada a los elementos del sistema objeto de gestión de la configuración. Estos aspectos de organización y procedimientos de gestión de configuración son tanto más críticos en sistemas abiertos y dinámicos, como es el SCTM, cuya obtención y funcionamiento de medios en servicio implica a diversos órganos asignados de las Fuerzas Armadas,


118


y que en estrecha coordinación e interoperatividad con las organizaciones de los contratistas de expedientes de implantación y apoyo logístico, tienen la misión de asegurar en todo momento los objetivos operativos del SCTM.


120


121

9

Proceso de selección de equipos y suministradores en el programa EF2000

122


9.1. Descripción del programa El programa de Avión de Combate Europeo, Eurofighter 2000 (EF2000), es un proyecto multinacional en el que participan Alemania, Gran Bretaña, Italia y España. En la actualidad se encuentra en la fase de desarrollo, a la que los cuatro países contribuyen respectivamente con el 33%, 33%, 21% y 13%. Para la gestión del programa se creó la Agencia NEFMA, que coordina y representa los intereses de los cuatro gobiernos, así como los consorcios industriales Eurofighter y Eurojet, en cuya composición participan empresas de las cuatro naciones. El consorcio Eurojet (EJ) es responsable del desarrollo del motor, mientras que el consorcio Eurofighter (EF) se responsabiliza del desarrollo del EF2000 como sistema completo, incluyendo la integración de la aviónica, del motor, etc. La estructura organizativa del programa EF2000 se muestra en la Figura 9.1. 9.2. Participación de la industria española El EF2000, sin duda el mayor proyecto de colaboración que ha existido en Europa, ha proporcionado a nuestra industria aeronáutica y electrónica la oportunidad de participar por primera vez como socios en el diseño y desarrollo de un proyecto de la más alta tecnología junto con las empresas de los países europeos más avanzados en el campo aeronáutico (exceptuando a Francia).

123 Proceso de selección de equipos y suministradores en el programa EF2000

En este proyecto, en el que todo es de nuevo desarrollo y por tanto supone un paso adelante en todas las áreas, nuestra industria está participando en la ingeniería de diseño del avión, en la estructura, en la integración de sistemas y equipos, en la integración del motor, así como en la utilización de nuevos materiales en procesos avanzados de fabricación, y en la fabricación y ensamblaje de los prototipos de avión y motor. Igualmente participa en el diseño, desarrollo y fabricación de prototipos de los equipos asociados al sistema de aviónica (navegación, guerra electrónica, comunicaciones, identificación y ataque, presentación de datos y simbología, etc.) y a los sistemas generales (control de vuelo, combustible, eléctrico, hidráulico, refrigeración y control ambiental, etc.). 9.3. Equipos de avión y accesorios de motor Uno de los aspectos más importantes y complejos del programa EF2000 es el relacionado con el desarrollo de los equipos de avión y

124


accesorios (equipos) de motor, del cual forman parte esencial los procesos de elaboración y aprobación de especificaciones y la posterior selección de empresas suministradoras. La responsabilidad de estos procesos está compartida por EF (equipos) / EJ (accesorios) junto con NEFMA y las cuatro naciones participantes y son un buen ejemplo de la aplicación de los conceptos sistémicos al tratamiento práctico de un sistema complejo. Gran parte de esta complejidad es debida al elevado número de equipos (285) y accesorios (24) a desarrollar, a la gran cantidad de ofertas presentadas, bien en colaboración o de forma individual, y al alto nivel de exigencia tanto de las especificaciones de desarrollo como del resto de la documentación asociada al paquete de petición de Ofertas. Como resultado del proceso de selección, el número de empresas de los cuatro países del programa EF2000 que participan es de 120, asociadas la mayoría de las veces en consorcios. Los equipos y accesorios se han clasificado en tres grupos o categorías, A, B y C, según su importancia en el sistema EF2000 y su complejidad y exigencia tecnológica, a la que normalmente va asociado un elevado importe económico. En lo sucesivo se hará referencia a equipos, entendiéndose que se aplica tanto a los equipos de avión como a los accesorios de motor. Una de las reglas fundamentales de este programa multinacional establece que la aportación económica (costshare ) de cada país participante ha de ser igual a su participación industrial (workshare ). De esta forma cada país se asegura el justo retorno a la inversión que realiza, y se favorece la colaboración entre empresas en el ámbito del programa y la formación de consorcios industriales. En consecuencia, el aseguramiento de la participación industrial compatible con el resultado más competitivo posible desde el punto de vista coste-eficacia, ha sido uno de los factores a tener en cuenta en la selección y adjudicación de ofertas, como veremos más adelante.


9.4. Proceso de gestión del desarrollo Dentro del marco de asistencia técnica a la gestión del programa EF2000, Isdefe colabora con la Oficina del Programa del Ministerio de Defensa en los procesos de aprobación de especificaciones, de evaluación y adjudicación de ofertas y selección de suministradores, así como en el seguimiento y control del desarrollo, calificación y entregas de prototipos de equipos con objeto de: a) Asegurar que los sistemas, subsistemas y equipos del avión cumplen los requisitos del sistema EF2000; b) Asegurar que los desarrollos de los equipos se ajustan a lo especificado en los aspectos técnicos, de coste y plazos; c) Asegurar que el reparto de trabajo para las empresas españolas miembros de consorcios está en línea con nuestro nivel de participación tanto en cantidad (volumen de trabajo) como en calidad (tecnología); y d) Contribuir a solucionar los problemas que se presentan a los suministradores a lo largo del desarrollo. Este Capítulo se centra en la parte inicial de este proceso, hasta la contratación del equipo con la empresa/consorcio seleccionada. Al término de la fase de definición, el sistema ha quedado definido (Especificación General del Sistema), habiéndose realizado el análisis funcional, con la consiguiente asignación de requisitos, y su transformación en criterios de diseño [6]. El proceso que se describe a continuación se enmarca en la etapa inicial de la fase de desarrollo, en la que se consolidan tanto el análisis funcional de los requisitos como las interfaces entre sistemas,

126


subsistemas y equipos, y se establecen de manera detallada las especificaciones técnicas de todos los equipos del avión, que serán parte fundamental del paquete de petición de ofertas a partir del cual se seleccionará a los suministradores. 9.5. Proceso de selección El marco en el que se encuadra el proceso de validación de especificaciones, evaluación de ofertas y selección de suministradores está determinado por dos aspectos fundamentales: 1) Principios. 2) Criterios de evaluación y selección. 9.5.1.

Principios del proceso de selección

Dadas las características específicas de este programa multinacional, en el que se busca fomentar la colaboración entre la industria europea y a la vez respetar los principios de retorno industrial a cada país y libre competencia, se consensuaron unas reglas de juego que, en esencia, se pueden traducir en los siguientes puntos: a) La selección se realiza mediante concurso de ofertas en competencia genuina, definida así cuando se hayan recibido dos o más ofertas independientes de entre tres o más empresas independientes invitadas a concursar. b) Las ofertas tienen que incorporar una distribución equilibrada de las áreas de tecnología nuevas o avanzadas que intervienen en el desarrollo de cada equipo (categorías A y B), de acuerdo con los porcentajes de participación industrial nacionales.


c) Con el fin de cumplir los requisitos de participación industrial del programa, se favorece que las empresas invitadas a concursar (suministradores potenciales) presenten ofertas en colaboración o consorcio siempre que sea posible. En la evaluación de ofertas se da un mayor peso a las ofertas en colaboración frente a las ofertas individuales, aunque éstas también se consideran en las evaluaciones. Una oferta se considera en colaboración cuando dos o más empresas de dos o más países participantes en el programa presentan una oferta conjunta regulada por un acuerdo formal en el que se detallan las condiciones de colaboración, de reparto de trabajo (workshare ) y la transferencia de tecnología. d) En las ofertas en colaboración para la fase de desarrollo, no se admiten duplicidades de trabajo o redundancias entre los socios del consorcio. 9.5.2.

Evaluación y aprobación de especificaciones

Cada una de las naciones, así como las secciones de la Agencia NEFMA involucradas, llevan a cabo la evaluación de los distintos apartados de la especificación. NEFMA realiza las tareas de coordinación de los comentarios y posturas respectivas de cada nación, pudiendo convocarse reuniones de especialistas en caso necesario. Si como resultado de estas reuniones se sigue sin poder aceptar la especificación, dependiendo del grado de discrepancia, se plantean dos alternativas: a) convocar una reunión del Panel de Selección de Equipos (Equipment Selection Panel, EQSP) para consolidar posturas y llegar a un punto de acuerdo con EF.

128


b) remitir la especificación a EF para su revisión, según las directrices establecidas por el EQSP, si las discrepancias son insuperables. Este proceso está reflejado esquemáticamente en la Figura 9.2. 9.5.3.

Selección de suministradores de equipos

Cada nación, así como los departamentos de NEFMA implicados, evalúan todas las ofertas recibidas en sus aspectos técnico, económico y contractual, y los califican de acuerdo con unos criterios y baremos establecidos para cada caso concreto, basados en los criterios de selección y factores de ponderación de la Sección 9.5.4. Estas valoraciones se comparan con la selección realizada por EF. NEFMA ejerce la función de coordinar las diferentes posturas nacionales, pudiendo celebrarse reuniones de coordinación previas al EQSP, en las que se decidirá si es necesario debatir aspectos de la evaluación de ofertas a nivel de especialistas de las cuatro naciones junto con NEFMA y EF. Posteriormente se convoca el EQSP, que en una sesión cerrada (NEFMA/naciones) unifica y consolida las posturas de sus miembros y comprueba si se satisfacen los requisitos de la participación industrial y en sesión abierta con EF le comunica a éste su decisión, que puede contemplar las siguientes posibilidades: a. Ratificación de la selección recomendada por EF y adjudicación definitiva del concurso a la oferta ganadora. EF puede proceder de inmediato a contratar con la empresa o consorcio adjudicatario. b. Aceptación de la oferta seleccionada desde el punto de vista técnico, económico y contractual que, sin embargo, incumple


130


el requisito de la participación industrial establecido. El EQSP concede una adjudicación condicionada a que se solucione el incumplimiento, dando instrucciones a EF para que negocie con el consorcio en este sentido e informe del resultado. Si finalmente el requisito se cumple, la adjudicación se convierte en definitiva. Por el contrario, si el líder del consorcio se opone a una redistribución de la participación industrial, dado el peso que este factor tiene en la valoración de las ofertas, esta quedaría descartada. c. El EQSP acepta la oferta recomendada por EF, pero ésta no cumple la totalidad de los requisitos técnicos de la especificación o de los requisitos contractuales de la documentación asociada, y el cumplimiento de algunos de esos requisitos, sin ser decisivos o fundamentales, son muy deseables para las naciones. En estos casos se puede dar la adjudicación definitiva condicionada a que EF haga todo lo posible para que el consorcio cumpla las instrucciones dadas por las naciones en las negociaciones previas a la firma del contrato. Aunque EF no consiguiera plenamente su objetivo, el contrato se adjudicaría a dicho consorcio. d. Si la oferta seleccionada y recomendada por EF tiene carencias o incumplimientos básicos en las áreas técnica (fundamentalmente) o contractual, o bien se considera que el precio ofertado es excesivamente alto, el EQSP rechazaría la oferta después de consultar con EF y le daría instrucciones para realizar un nuevo concurso de ofertas ampliando la lista de empresas suministradoras potenciales a otros países no participantes en el programa EF2000. Este caso raramente se presenta, puesto que normalmente EF lo detectará en su proceso interno de evaluación, selección y recomendación, e inmediatamente lo notificaría al cliente. La Figura 9.3 describe gráficamente el proceso de evaluación de ofertas y adjudicación del concurso al suministrador seleccionado.


132


9.5.4.

Criterios de evaluación y selección

9.5.4.1.

Evaluación

La evaluación de las ofertas se hace siguiendo el esquema detallado de criterios de selección, y la guía de puntuación y factores de ponderación asociados a cada elemento del esquema. El esquema detallado de criterios es un desglose del esquema general reflejado en el Apartado 9.5.4.2. Este recoge los aspectos a considerar de la especificación y documentación asociada al paquete de petición de ofertas a nivel de bloques (1º nivel) y áreas (2º nivel), mientras que el esquema detallado continua el desglose hasta subárea (3º nivel) y elementos (4º nivel). Para la evaluación de los aspectos técnicos de la oferta se ha utilizado la metodología siguiente: a. Se establece el concepto de puntuación básica, que expresa el grado de cumplimiento de cada elemento de la oferta respecto a la especificación. Los especialistas califican cada elemento de la oferta presentada con una puntuación que puede variar desde 0 (incumplimiento total) hasta 10. b. Cada bloque, área, subárea y elemento tienen asignado un factor de ponderación, que refleja la importancia relativa de las diferentes características técnicas, funcionales, etc. del equipo considerado. Para cada elemento evaluado, la puntuación básica se multiplica por el factor de peso asignado a cada elemento, obteniéndose así la puntuación elaborada por elemento. Sumando en secuencia las puntuaciones elaboradas por elemento se obtiene la puntuación por subárea. Afectando a este valor del factor de ponderación de cada subárea, se obtiene la puntuación elaborada por subárea. Procediendo de forma análoga se


van agregando las puntuaciones hasta obtener la puntuación por área y seguidamente la puntuación elaborada por cada bloque. Desde el punto de vista de la evaluación técnica, los bloques (1º nivel) son los siguientes: 1. 2. 3. 4.

Prestaciones. Fiabilidad y Seguridad, Mantenibilidad y Capacidad de Prueba. Características Técnicas y Aspectos de Programa. Aspectos Logísticos.

De esta forma las puntuaciones así elaboradas por cada bloque dan una idea muy completa de cuál es el equipo que propone el suministrador y, al mismo tiempo, permiten la comparación con las ofertas de los demás concursantes. c. Dado que el esquema se ha elaborado para evaluar cualquier equipo (de aviónica, mecánico, hidráulico, etc.) el esquema detallado se ha de adaptar al equipo concreto que se esté valorando. Adicionalmente, el suministrador ha de tener debidamente en cuenta en su oferta aquellos elementos que sean característicos o fundamentales en el equipo considerado, de forma que si la puntuación de alguno de esos elementos fuera muy baja o próxima a cero, la oferta quedaría automáticamente rechazada. d. Otro concepto importante a tener en cuenta en la evaluación es la valoración del riesgo, enfocada fundamentalmente al Bloque 1 (Prestaciones) y ciertos aspectos del Bloque 3 (Diseño, Integración, Instalación y características técnicas). Esta se define como el grado de dificultad que cada suministrador encuentra para llevar a buen término la propuesta de equipo que ha ofertado.

134


Este factor varía de 0 a 10. Para un equipo que cumple íntegramente los requisitos de la especificación y está disponible en el momento de presentar la oferta (off-the-shelf ), la puntuación del riesgo sería 10 (muy bajo). Por el contrario, si un suministrador oferta a un equipo en el que no tiene experiencia previa, la puntuación estará próxima a cero, debido al alto riesgo que supondría que ese suministrador desarrollara un equipo que a un coste razonablemente bajo satisfaciera todos los requisitos de la especificación dentro de los plazos de tiempo establecidos. Por tanto, cuanto más próximo a un diseño existente está el diseño presentado, menor es el riesgo y mayor será la puntuación. La valoración del riesgo es un valor absoluto y un concepto independiente del resto de la evaluación y, como tal, debe mantenerse al margen de la puntuación básica, factores de peso y del esquema de selección. e. La evaluación de los aspectos comerciales (económicos y contractuales) de la oferta sigue los procedimientos anteriormente descritos para el área técnica. Agregando las puntuaciones básicas, junto con los factores de peso correspondientes, se obtienen las puntuaciones elaboradas por bloque, que para la evaluación comercial son los siguientes: (1) precios; (2) colaboración; (3) participación industrial; y (4) condiciones contractuales, dando una valoración exhaustiva del área comercial de la oferta y permitiendo la comparación directa y sistemática con el resto de las ofertas. f.

Es importante resaltar que en la petición de ofertas para la fase de desarrollo, en el Bloque 1 (Precios), además del precio de desarrollo del equipo los suministradores potenciales deben de cotizar los precios correspondientes a las siguientes fases del programa, inversiones para la producción, producción en serie y apoyo en servicio,


considerándose por tanto todos los costes del ciclo de vida en la valoración económica. g. Una puntuación notablemente baja en ciertos aspectos que se puedan considerar fundamentales o de obligado cumplimiento sería motivo para descalificar la oferta, independientemente de cualquier otra consideración. 9.5.4.2.

Criterios de selección

El esquema general que recoge los criterios de selección a nivel de bloque y área (1º y 2º nivel) se divide en dos grandes grupos, que engloban los aspectos técnicos y los aspectos comerciales (económicocontractuales) y se muestra en las Figuras 9.4 y 9.5. 9.5.4.3.

Síntesis

La selección de suministradores se basa en favorecer la competencia industrial entre empresas y consorcios fundamentalmente de los cuatro países participantes, aunque no se excluyen a empresas de otros países. En esta línea, el criterio fundamental que se sigue para la adjudicación definitiva de un contrato en el programa es el siguiente: 1. Identificación de las ofertas que hayan tenido mayor valoración desde el punto de vista técnico, es decir, de cumplimiento de la especificación del equipo, así como de valoración del riesgo. 2. Grado de cumplimiento de estas ofertas de los términos y condiciones contractuales del programa EF2000, los cuales forman parte, junto con la especificación, del paquete de documentación asociado a la petición de ofertas.

136



138


3. Selección y adjudicación del contrato a aquella oferta que habiendo cumplido los dos puntos anteriores, obtenga la mejor valoración económica. 9.6. Consideraciones finales La realización del trabajo descrito en este Capítulo dentro del marco del programa EF2000, con 285 equipos de avión y 24 accesorios (equipos) de motor, todos ellos de nuevo desarrollo y marcando el estado del arte de la tecnología europea ha significado una experiencia muy valiosa y establece una metodología en un área fundamental como es la selección de suministradores. Esta metodología no es solamente de aplicación en el ámbito de equipos embarcados, sino a nivel de sistema completo, con un amplísimo campo de actuación en cualquier programa de adquisición de un sistema, ya sea de nuevo desarrollo, de modernización o de adquisición directa (nacionalización, compensaciones, etc.).


140


141

10

Verificación y validación en el programa EUROMAYA

142


10.1.Descripción del programa Euromaya El programa EUROMAYA, se enmarca dentro de los Programas de cooperación y ayuda al desarrollo que la Comisión Europea lleva a cabo en América Latina, recibiendo la denominación formal de Proyecto ALA 88/19. El programa se desarrolla para la Corporación Centro Americana de Servicios de Navegación Aérea (COCESNA) formada por Belice, Costa Rica, Guatemala, Honduras, Nicaragua y El Salvador, siendo el organismo contratante y regulador de la subvención la Dirección General I de la Comisión Europea. Los fondos económicos iniciales del programa provienen de la Comisión Europea (64%), del Estado Italiano (32%) y de la propia COCESNA (4%). La Figura 10.1 muestra el esquema de gestión. El programa Euromaya tiene por objetivo incorporar en Centro América las modernas tecnologías de Control de Tráfico Aéreo, aumentando la capacidad y seguridad del Sistema de Navegación Aérea, y capacitando al personal de COCESNA en estas nuevas tecnologías.

143 Verificación y validación en el programa EUROMAYA

Los principales componentes del proyecto, son: a) Instalación de 4 radares secundarios monopulso y del sistema de comunicaciones para su conexión con el Centro de Control. b) Construcción de un nuevo Centro de Control en Tegucigalpa. c) Sistema de Control de Trafico Aéreo. d) Obras civiles para infraestructura de apoyo. En la Figura 10.2 se presenta la ubicación geográfica de los componentes del sistema. Isdefe participa como Asistencia Técnica a la Oficina de Programa I.S.E. (Ingeniería de Sistemas Euromaya), en todas las fases del ciclo de vida, desde el análisis de necesidades y especificación de

144



requisitos, hasta el proceso de instalación y pruebas, actualmente en curso. También está previsto realizar el apoyo a la explotación del Sistema tras la puesta en servicio. Para la realización de los trabajos, Isdefe tiene una oficina de campo en Tegucigalpa en la que están desplazados de forma permanente 5 expertos en otras tantas áreas, actuando uno de ellos como Director Europeo del programa. Cabe destacar como actividades de especial relevancia, las asociadas a: planificación, especificación, y verificación/validación. Estas últimas actividades son de especial relevancia en la fase de producción/ implantación actualmente en curso, dadas las características especificas de medios e infraestructura en la zona centroamericana. 10.2. Verificación y validación Las actividades de verificación y validación, aunque realizadas a lo largo de todo el ciclo de vida del sistema (ver Figura 10.3) de acuerdo a una aproximación basada en la normativa DOD-STD-2167-A, se han centrado fundamentalmente en: a) Revisión de requisitos del sistema; y b) Pruebas de aceptación en fabrica y en emplazamiento. En la fase actual en que se encuentra el sistema EUROMAYA (producción / implantación), las actividades de verificación y validación se concretan en el proceso de ejecución y gestión de pruebas (de cada uno de los sistemas/subsistemas por separado, y de todos los sistemas integrados). Un condicionante permanente durante todo el proceso de ingeniería ha sido la ubicación geográfica del sistema, y

146


fundamentalmente la lejanía respecto de los centros de producción, en Europa del contratista suministrador del sistema. Se ha tratado en todo momento de minimizar los riesgos inherentes a estas dificultades. El objetivo fundamental de las actividades de verificación y validación que se realizan tiene una doble vertiente: a) Asegurar que el contratista ha identificado y comprendido correctamente todos y cada uno de los requisitos técnicooperativos del sistema, y ha establecido un plan de ejecución viable y realista; y b) Garantizar que los diversos componentes del sistema tienen las funcionalidad y prestaciones requeridas anticipando la detección de no conformidades, mediante la realización del mayor número posible de pruebas en fábrica.


Esta doble vertiente de los objetivos de la verificación y validación de garantizar la obtención de un sistema que cumpla los requisitos establecidos y cuyo desarrollo se realiza en el coste y los plazos previstos, se encuentra en plena sintonía con el marco establecido por los objetivos de ingeniería de sistemas, orientada a la adquisición eficaz y eficiente de sistemas que satisfagan necesidades identificadas. 10.3.Descripción de actividades Las actividades de verificación y validación que se están realizando, son de 4 tipos (ver Figura 10.4): a) Revisiones: evaluación de los productos de una actividad de desarrollo para determinar la consistencia y corrección con respecto a los productos estándar suministrados.

148


b) Auditorías: verificación del grado de implantación de los sistemas, técnicas y procedimientos establecidos para el desarrollo del EUROMAYA. c) Inspecciones: comprobación de los aspectos puntuales de la ejecución del proyecto por parte de los contratistas. d) Pruebas: comprobación y validación de que un componente, subsistema y el sistema EUROMAYA, cumple todos y cada uno de los requisitos técnico-operativos especificados. 10.3.1.

Auditorías e inspecciones

Como parte del proceso de seguimiento y control de las actividades realizadas por el contratista, se han llevado a cabo auditorías e inspecciones en los centros de ingeniería y producción del contratista. Estas auditorías se han centrado en: a) Verificar la cantidad y la adecuación de los recursos (humanos y materiales) asignados al proyecto; b) Verificar el grado de implantación del sistema de calidad del contratista en el proyecto EUROMAYA de conformidad con el plan de calidad establecido; c) Verificar la adecuación técnica de los desarrollos, producción e instalación de los diversos componentes; y d) Verificar el grado de cumplimiento de la planificación establecida, con el fin de anticipar y detectar retrasos. Para llevar a cabo estas actividades se han definido e implantado un procedimiento de ejecución de auditorías y un procedimiento de análisis y gestión de riesgos.


Con estas actividades se han detectado determinados riesgos de relevancia para la ejecución del proyecto lo cual ha permitido tomar las medidas correctoras con la suficiente anticipación. 10.3.2.

Revisiones

Aunque formalmente existen muchos tipos de revisiones, en el programa EUROMAYA la más relevante ha sido la Revisión de Requisitos del Sistema . Esta actividad se encuadra en lo que en el programa recibe el nombre genérico de «replanteo», que engloba también la revisión de los planes de ejecución y gestión asociados al proyecto (Plan de Gestión, Plan de Calidad, Plan de Documentación, etc...). Tiene por objeto revisar el documento de Especificaciones de Requisitos del Sistema elaborado por el contratista para verificar la adecuación a los requisitos técnico-operativos del sistema, comprobando que son completos (cobertura) y viables (viabilidad y necesidad de desarrollos). Se tomaron como documentos de referencia el Pliego de Términos de Referencia (PTR), la oferta y los documentos adicionales suministrados por el contratista y que estaban referenciados en el acta de adjudicación. La realización del replanteo ha sido de fundamental importancia prolongándose en el tiempo durante varios meses. Ha permitido identificar: a) Riesgos de cumplimiento en plazos por parte del contratista, de determinados requisitos técnico-operativos; y b) Desarrollos necesarios para cumplir con todos y cada uno de los requisitos técnico-operativos comprometidos por el contratista. Esto ha permitido realizar un ajuste final de los aspectos técnicos y configuración del sistema respetando en todo momento los requisitos básicos

150


e inexcusables de operatividad, seguridad y fiabilidad de un sistema de Control de Tráfico Aéreo. Además la identificación de los desarrollos requeridos permite focalizar determinados tipos de pruebas en las áreas afectadas por dichos desarrollos, como más adelante se expone. 10.3.3.

Pruebas

Los elementos técnicos que constituyen el suministro del programa EUROMAYA se estructuran en los siguientes sistemas: SADR (Sistema de adquisición de datos radar), SCDR (Sistema de comunicación de datos radar), AFTN (Sistema de conmutación de mensajes de la red AFTN), CENAMER (Sistema de control de tráfico aéreo y simulación). 10.3.3.1. Alcance de las pruebas Cada uno de los sistemas se ha estructurado a su vez en subsistemas y estos en componentes. Según el alcance de la prueba se han distinguido los siguientes niveles convencionales de pruebas: pruebas unitarias, pruebas de subsistema, pruebas de sistema, pruebas de aceptación (todos los sistemas integrados). La ISE se ha centrado en el seguimiento, monitorización y control de la ejecución de las pruebas a partir de nivel subsistema, siendo informado por el contratista del avance y resultado del resto de las pruebas. Concretamente las pruebas a nivel unitario son realizadas por el propio contratista siendo su estructura de calidad interna la que emite los correspondientes certificados acreditativos. 10.3.3.2. Tipos de pruebas Convencionalmente, atendiendo al objetivo de la prueba se pueden distinguir dos tipos de pruebas:


a) Pruebas de cualificación: orientadas a la comprobación del diseño, capacidades y prestaciones del elemento sometido a prueba; y b) Pruebas funcionales: orientadas a comprobar que el elemento sometido a prueba se comporta en sus aspectos funcionales de acuerdo con las especificaciones. Las pruebas de cualificación se han centrado fundamentalmente en los subsistemas y sistemas que tenían algún grado de desarrollo adicional. Especial atención se ha prestado al Sistema CENAMER en el que los subsistemas de Supervisión, Tratamiento Radar y Tratamiento Plan de Vuelo habían requerido desarrollos respecto del producto estándar del contratista. Las pruebas funcionales se implantaron para todos los sistemas y sus correspondientes subsistemas. 10.3.3.3. Fases de las pruebas La realización de pruebas se organizó de forma convencional en dos fases: pruebas en fabrica y pruebas en emplazamiento. a) Pruebas en fábrica. Las pruebas en fábrica se llevan a cabo a nivel de subsistemas de cada uno de los sistemas, realizándose en algunos casos pruebas de diversos subsistemas integrados. Las pruebas se realizan por el contratista de acuerdo al Plan de Pruebas y al Protocolo de Pruebas que han sido previamente revisados por la ISE. Son especialmente importantes las pruebas de cualificación de diseño ya que las acciones correctoras que podrían

152


resultar son más fáciles de llevar a cabo en fabrica que en el emplazamiento. Actualmente ya se han realizado las pruebas en fábrica de SADR, SCDR y AFTN que se encuentran en fase de instalación en los emplazamientos. A continuación se realizan las pruebas del resto de los sistemas de EUROMAYA. b) Pruebas en emplazamiento. Las pruebas en emplazamiento se realizan a nivel subsistema, sistema, y aceptación global. Estas ultimas corresponden con las asociadas a todos los sistemas integrados. Actualmente se están llevando a cabo las pruebas de SADR y SCDR. Las pruebas en emplazamiento incorporan dos tipos adicionales de pruebas: pruebas de carga y pruebas de estabilidad. Estas pruebas se realizan en las etapas finales de aceptación y permiten verificar la capacidad y estabilidad en funcionamiento continuado de todos los sistemas integrados. 10.3.3.4. Gestión de pruebas Las pruebas se realizan de acuerdo al Plan de Pruebas y a los Protocolos de pruebas específicos. Para monitorización control y seguimiento de las pruebas, se han establecido unos documentos de gestión de pruebas: a) Informe de pruebas que recoge el resultado de un conjunto de pruebas realizadas. Consta de: resultados de prueba; informes de incidencias, recogen las no conformidades o anomalías detectadas


durante la ejecución de las pruebas; e informe de aceptación, indica la aceptación o rechazo de las pruebas, así como las recomendaciones y acciones correctoras a realizar. b) Registro de pruebas que resume el estado de avance y de aceptación de las pruebas. Todas las actividades de verificación y validación descritas en esta sección 10.3, tienen una importancia notable en el proceso de Ingeniería de Sistemas. Si la Revisión del Sistema de Requisitos puso de manifiesto riesgos técnicos, de plazos y económicos, permitiendo anticipar las medidas correctoras adecuadas, las pruebas permiten comprobar que realmente el sistema EUROMAYA se ajusta a lo especificado en todos sus aspectos técnicos y operativos. 10.4. Consideraciones finales La detección temprana de errores y no conformidades en el diseño y desarrollo de un sistema, permite prever problemas posteriores y anticipar las medidas correctoras adecuadas. Las actividades de verificación y validación han permitido en el proyecto EUROMAYA identificar numerosos problemas que caso de haberse llegado a concretar hubieran tenido importantes implicaciones técnico-operativas, económicas y de plazos de ejecución. Las auditorías e inspecciones permiten detectar problemas que pueden permanecer ocultos para el propio contratista, y cuya resolución redunda en una mayor eficacia y eficiencia de los recursos disponibles. La realización de una exhaustiva revisión de especificaciones de requisitos ha permitido identificar no conformidades de las propuestas realizadas por el contratista con los requisitos técnico-operativos del sistema, y tomar las acciones correctoras oportunas que garantizan la consecución del sistema en coste y con unos plazos razonables.

154


Las pruebas del sistema, aunque se realizan en las fases finales del ciclo de vida deben de ser concebidas, estructuradas y planificadas desde las primeras fases. Una buena organización y estructuración permite sistematizar la ejecución y gestión de las pruebas aumentando la eficacia de las mismas y reduciendo costes y esfuerzos.


156


157

11

Transición operativa en el programa SACTA

158


11.1. Descripción del programa SACTA El programa SACTA lanzado por la Dirección General de Aviación Civil Española a principios de la década de los ochenta, tiene por objeto la homogeneización y automatización del sistema de control de tráfico aéreo español, tanto de ruta como de aproximación. En esa época existían diversos sistemas en operación con tecnologías anticuadas y heterogéneas. El programa, que supuso un reto para la administración española y para la industria nacional, se estructuró en una serie de fases para llevar a cabo la sustitución progresiva de los sistemas tanto en los cuatro Centros de Control de Área («Area Control Center», ACC) de Madrid, Sevilla, Canarias y Barcelona, como en el centro de Control de Área Terminal («Terminal Area», TMA) de Palma de Mallorca (ver Figura 11.1). Otras dependencias de TMA, Aproximación (APP) y Control de Torre (TWR), serían equipadas, bien con posiciones subsidiarias de alguno de los centros principales, bien con sistemas simplificados derivados de los anteriores. Los sistemas se interconectarían entre sí, y responderían a una concepción, diseño y tecnología unificados. El movimiento de aeronaves en el espacio aéreo español se caracteriza por su gran estacionalidad. Existen días y horas en los que se producen grandes concentraciones de vuelos. El programa SACTA ha sido diseñado para ayudar al control del tráfico aéreo teniendo en

159 Transición operativa en el programa SACTA

160


cuenta esas peculiaridades y para ser capaz de trabajar en las condiciones de máxima capacidad de control exigidas, siempre respetando los requisitos de seguridad. El control de tráfico aéreo soportado por el SACTA utiliza vigilancia radar, gestiona los movimientos de aeronaves con el tratamiento de la información de los Planes de Vuelo y permite las comunicaciones orales entre piloto y controlador (radio) y entre controladores (telefonía). Las funciones de control de ruta (sobrevuelos) y de aproximación (despegues y aterrizajes) son realizadas desde los Centros de Control de Madrid, Barcelona, Canarias, Sevilla y Palma, en donde están operativos y en servicio los sistemas SACTA. Isdefe ha participado en la ejecución del Programa desde su inicio, prestando asistencia técnica a la Oficina del Programa (O.P. SACTA), desde las fases iniciales de planificación y especificación de requisitos (año 1984, cuando todavía Isdefe era ISEL) hasta la transición operativa y apoyo a la explotación. Actualmente se ha cumplido el objetivo de implantación de la Versión II del Sistema SACTA que se encuentra en servicio en todos los centros y dependencias indicados anteriormente (el primer centro entró en servicio en Palma de Mallorca en 1989 con la Versión I). Especialmente interesante y delicadas han sido las transiciones operativas que se han llevado a cabo en la instalación y actualizaciones posteriores de los sistemas en los distintos centros. Estas transiciones entre las fases de implantación y de vida operativa del ciclo de vida del sistema, han supuesto, por la variedad de entornos en que se han realizado y la complejidad que conllevan, un área de especial dedicación para el personal operativo y técnico de la Administración y de Isdefe. Cabe destacar como principal condicionante la necesidad de continuidad del servicio, un servicio especialmente critico por razones de seguridad, como es el de control de tráfico aéreo.


11.2. Transición operativa 11.2.1.

Características generales

Los sistemas de control de tráfico aéreo tienen como característica principal la necesidad de garantizar una altísima disponibilidad en la continuidad del servicio (24 horas al día y 365 días al año). Como ya se ha indicado con anterioridad la continuidad del servicio es elemento imprescindible en el proceso de transición. Las transiciones que se han llevado a cabo pueden clasificarse en tres tipos, de acuerdo al siguiente criterio de complejidad creciente: a) Actualización (en uno o varios centros) de la versión/revisión del sistema SACTA en servicio. Este tipo de transiciones se produce cada vez que hay una actualización significativa de la versión del SACTA. b) Sustitución de un sistema antiguo por el sistema SACTA manteniendo la localización física del sistema, como por ejemplo en los centros de Sevilla (1994), Barcelona (1995) y Canarias (1994). c) Sustitución del sistema y de la ubicación física del mismo (traslado a otras instalaciones distantes algunos kilómetros). Cabe resaltar las transiciones de los centros de Palma de Mallorca (1989) y de Madrid (1990). En los dos últimos tipos de transición es necesario mantener durante un cierto tiempo los dos sistemas (antiguo y nuevo) funcionando en paralelo por razones obvias de seguridad y de verificación final del sistema en implantación. En todos los casos es necesario establecer un Plan de Contingencia que garantice una vuelta atrás (retorno al sistema antiguo) en caso de anomalías o problemas relevantes en el nuevo.

162


La transición operativa se estructura en tres fases: Planificación, Preparación y Ejecución. 11.2.2.

Planificación de la transición

Elemento básico e imprescindible es la realización de un Plan de Transición. En su elaboración intervienen expertos de las áreas de ingeniería, operación (personal de control) y apoyo logístico (personal de mantenimiento), tanto de la propia O.P. SACTA como de los centros y dependencias involucrados en el proceso. El Plan de Transición describe de una forma exhaustiva y detallada todas y cada una de las fases y actividades a llevar a cabo durante la preparación y la ejecución de la transición, desde los puntos de vista técnico, de logística y de operación. El Plan incluye un calendario detallado (incluso por horas del día) de todas las actividades de preparación y ejecución, así como de las comprobaciones y pruebas a llevar a cabo y de las medidas a tomar si fuera necesario desencadenar un proceso de «vuelta atrás». Durante la planificación fue necesario prestar especial atención entre otros a los siguientes aspectos: a) Identificar las necesidades de componentes y elementos (técnicos y de infraestructura), adicionales a los propiamente operativos, y que serían necesarios durante la transición. Esto fue especialmente critico cuando se realizaron traslados de edificios, ya que aparecían necesidades de duplicación o redundancia para poder mantener los dos sistemas (antiguo y nuevo) simultáneamente en operación. Por ejemplo fue necesario identificar y especificar la duplicación necesaria y los mecanismos de conmutación relativos a: i) líneas de comunicaciones de voz (VHF y telefonía); ii) líneas de comunicación radar;


iii) líneas de comunicación de datos entre subsistemas y también con centros colaterales (comunicación intercentros); y iv) equipos adicionales de seguridad (últimos recursos de comunicaciones de voz, etc...). b) Especificar las condiciones para iniciar la transición relativas al estado de la infraestructura y de los sistemas (hardware y software), que se iban a poner en operación, en los aspectos asociados a su documentación y a las pruebas. Por ejemplo era requisito imprescindible que las pruebas técnicas (cualificación de diseño y funcionales) hubieran sido superadas satisfactoriamente en el emplazamiento. Si existían anomalías, estas no debían afectar ni a la seguridad, ni a la operatividad ni a la disponibilidad del sistema. Especialmente relevantes eran los resultados de las pruebas de los subsistemas de comunicaciones voz y de tratamiento de datos radar. c) Determinar los requisitos previos de formación y entrenamiento del personal operativo y de mantenimiento en los nuevos sistemas. Un aspecto fundamental a tener en cuenta era la necesidad de formación en los procedimientos operativos específicos de la transición (especialmente los que estarían vigentes durante el funcionamiento en paralelo de los dos sistemas). Hay que tener en cuenta que aunque los dos sistemas estén en paralelo el control efectivo se realiza únicamente desde uno de ellos y es necesario establecer procedimientos de coordinación muy precisos. d) Determinación y especificación de los recursos humanos y materiales necesarios para llevar a cabo las actividades de preparación y ejecución de la transición. En algunos casos y dado lo ajustado de las plantillas es necesario prever

164


períodos de trabajo extras para determinados colectivos, con el impacto económico asociado. e) Identificación y especificación previa de las medidas restrictivas del entorno operativo. Se prevén las reducciones en capacidad de tráfico, de comunicaciones y de coordinación con colaterales, que se establecerán temporalmente durante los períodos iniciales de funcionamiento del sistema como medida de precaución. Por ejemplo se definió la reducción de numero de vuelos que se podrían controlar simultáneamente (por sector de control y para todo el centro de control), o la reducción en frecuencias operativas de comunicación tierra/aire y de líneas de telefonía. 11.2.3.

Preparación de la transición

De acuerdo al Plan de Transición establecido, se realizan todas las actividades preparatorias. Entre otras cabe resaltar como significativas: a) Implantación previa de la infraestructura, y de la duplicación o redundancia de equipos y sistemas (se realizan pruebas especificas de comprobación de dichos elementos); b) Establecimiento de los procedimientos operativos de aplicación durante la transición, así como formación y entrenamiento al personal operativo en dichos procedimientos; c) Formación y entrenamiento del personal operativo y de mantenimiento; d) Comprobación del estado de los equipos operativos (documentación y pruebas);


e) Establecimiento de un plan de «vuelta atrás», en el caso de que fuera necesario retornar al sistema (o a la versión) anterior; y f)

11.2.4.

Preparación de las medidas restrictivas del entorno operativo, y notificación a los organismos nacionales e internacionales involucrados. Ejecución de la transición

La participación de Isdefe en las diferentes ejecuciones de los Planes de Transición de todos los centros de control del Plan SACTA, ha sido indispensable para el cumplimiento del objetivo final de cambio de sistemas o versiones manteniendo una alta seguridad, fiabilidad y eficacia de los nuevos sistemas. 11.3. Ejemplo de transición (Madrid) Como ilustración de las actividades de Isdefe, se describe a continuación la ejecución de la transición operativa de ACC/TMA Madrid, por considerarse la transición al nuevo centro de control de Torrejón de Ardoz la más compleja de las realizadas. Las colaboraciones de Isdefe relacionadas con la transición podrían clasificarse en tres fases: a) Planificación y preparación. En esta fase se ha participado en tareas destinadas a garantizarlos mínimos riesgos en la ejecución de la transición:(1) definición del Plan de Transición; (2) pruebas de carga (protocolos, seguimiento de pruebas, etc.); (3) pruebas de estabilidad; (4) ensayos de la implantación de

166


la ejecución del Plan de Transición; y (5) formación del personal de control y mantenimiento. El Plan de Transición de Madrid ha presentado dificultades (primera implantación completa del SACTA), funcionales (no habían sido utilizadas en la práctica las prestaciones de los sistemas SACTA) y operativas (el personal de control y de mantenimiento había recibido cursos pero siempre es necesario una adaptación y familiarización a los nuevos sistemas). Como la transición de Madrid se realizaba entre dos edificios distanciados (Paracuellos y Torrejón), las «vuelta atrás» exigían duplicidad de sistemas y personal operando coordinada y simultáneamente. b) Ejecución de la Transición. Las actividades realizadas han sido: (1) implantación del Plan de Transición; (2) apoyo al personal de control y mantenimiento en la transición; (3) estrategias de reacción ante eventos de funcionamiento incorrecto de los sistemas SACTA; (4) seguimiento y análisis del comportamiento de los sistemas SACTA; y (5) propuesta e implantación de mejora y arreglo de averías en los sistemas SACTA. c) Post-transición. En esta fase se realizan las siguientes actividades: (1) análisis y seguimiento de fallos; (2) estadísticas de comportamiento; (3) implantación de mejoras y arreglo de fallos; y (4) estrategias de mantenimiento. 11.4. Consideraciones finales La transición operativa ha permitido la implantación de las capacidades y prestaciones del SACTA de forma gradual e incrementándose el tráfico aéreo a controlar de forma coordinada.


El programa SACTA ha proporcionado al controlador una mayor fiabilidad y precisión en cuanto a detección y localización de aeronaves, ayuda a la toma de decisiones mediante el suministro de datos auxiliares en tiempo real, detección de posibles conflictos entre aeronaves, máxima flexibilidad en cuanto a configuraciones de los sistemas y reducción de errores humanos con un aumento notable de la seguridad. A nivel administrativo el SACTA está proporcionando una mejora de la calidad del servicio y un aumento de la capacidad de absorción de tráfico aéreo con mayor seguridad y eficacia.

168


169

12

Sistema de gestión integrada del programa TLE

170


12.1.Introducción El profesor Benjamin Blanchard, en la primera de las monografías de esta serie, manifiesta que “la implantación con éxito de la ingeniería de sistemas requiere que los principios y elementos en los que ésta se apoya, sean seguidos a lo largo del proceso de obtención de los sistemas y abarca tanto la ejecución y desarrollo de las técnicas apropiadas, como los conocimientos de gestión y dirección necesarios para hacerlos realidad. Para ello debe seguirse un plan bien pensado, estructurado y ordenado ”. Bajo estos dos principios se integran conceptualmente la planificación y gestión de un programa entre las disciplinas de ingeniería de sistemas. El objeto de este Capítulo es describir la manera en que se están aplicando las técnicas de planificación y gestión en el ámbito del programa TLE (Equipos Limitados por el Tratado). 12.2. Descripción del programa TLE 12.2.1.

Objetivo

El Tratado FACE (Fuerzas Armadas Convencionales en Europa) entre la OTAN y los países del bloque del Este tiene por objeto la limitación del armamento convencional en Europa. Aprovechando este tratado la OTAN decidió reforzar su flanco Sur transfiriendo coordinadamente

171 Sistema de gestión integrada del programa TLE

determinados equipos TLE (Equipos Limitados por el Tratado) a Grecia, Turquía, Portugal y España. Como consecuencia de la ratificación del Tratado FACE, España decidió aceptar la transferencia de carros de combate, piezas de artillería y transportes oruga, comprometiéndose a mantenerlos operativos y a disposición del esfuerzo común, y a destruir los equipos sobrantes que rebasen el límite fijado por el Tratado. A estos efectos se creó en 1992 en el ámbito del Cuartel General del Ejército, el programa TLE al que se marca como objetivos el organizar y planificar las acciones para poner en estado operativo cada carro, proceder a su revisión y potenciación, constituir unidades operativas con dichos carros, adquirir el equipamiento y los medios y vehículos auxiliares precisos, crear una estructura para el mantenimiento en estado operativo, instruir tripulaciones y especialistas, crear un centro de instrucción, gestionar el proceso de reducción de equipos sobrantes, adquirir la totalidad de bienes y servicios necesarios y realizar las contrataciones que se precisan, para lo que se dotó del necesario presupuesto. 12.2.2.

Situación actual del programa

Estas actuaciones se han materializado en más de cien expedientes de contratación o de cesión de crédito, que se están gestionando por la Oficina de Programa TLE y que abarcan el ámbito temporal comprendido entre 1992 y 1997, estándose actualmente en plena fase de producción/implantación, habiendo comenzado la vida operativa para alguno de los equipos transferidos. En toda esta problemática de adquisición y gestión de medios y recursos que supone el programa TLE y que se coordina desde la Oficina de Programa, están involucrados en el cumplimiento de sus funciones distintos centros y organismos del Ejército, como son la Dirección de Abastecimiento y Mantenimiento con muchas de sus secciones y negociados, los órganos logísticos centrales, Parque Central de Material de Automoción, Centros de Mantenimiento de Sistemas Acorazados,

172


Unidades Móviles de Mantenimiento y las propias unidades receptoras, etc., estando involucrados a nivel internacional el Consorcio del Sistema de Armas (Weapon System Partnership, WSP), formado por España, Portugal, Grecia y Turquía, y la Agencia OTAN de Abastecimiento y Mantenimiento (NAMSA), así como los múltiples contratistas y subcontratistas nacionales e internacionales comprometidos. 12.3. La gestión del programa TLE 12.3.1.

Ingeniería y gestión

La gestión y control de un programa es un elemento indispensable en el proceso de la ingeniería de sistemas, aunque con frecuencia no se considere así. Se requiere de un sistema de información que identifique, recopile y trate los datos precisos para disponer a tiempo útil, de una visión clara, completa y con perspectiva de la situación del programa y de su posible evolución. Disponer de estos sistemas de información para la gestión posibilita la pronta detección de cualquier desviación o tendencia anómala aparecida, con la consecuente identificación de áreas potenciales de riesgo y el inicio inmediato de las acciones correctivas necesarias. En este Capítulo se describen los pasos dados en el programa TLE del Ejército para disponer, por aplicación de los conceptos de ingeniería relativos a planificación y organización y bajo la premisa de que “la base del control está en la acción de medir », de un sistema de información de soporte a la gestión. La gestión de los proyectos individuales que constituyen el programa TLE, requiere el control de los riesgos y la corrección de las desviaciones respecto al cumplimiento de los plazos, costes y prestaciones contractuales.


Disponer del grado de visibilidad adecuado ha hecho imprescindible apoyarse en un sistema de información que garantice por un lado la recopilación de los datos precisos de forma continuada, y por otro, el tratamiento de dichos datos, de manera que se extraiga la información esencial para que ésta le sea presentada al órgano de gestión de manera clara y concisa. 12.3.2.

Colaboración de Isdefe en el programa TLE

La actuación de Isdefe se ha centrado en prestar apoyo a la Oficina de Programa TLE en las siguientes áreas: a) Seguimiento y control de la situación de los trabajo de los contratistas en cuanto a adecuación a las necesidades del Ejército tanto desde el punto de vista operativo/técnico como de plazos y costes; b) Gestión de configuración de los carros transferidos, proporcionando la capacidad de mantener el control sobre la configuración de estos, desde su inspección inicial previa a la transferencia, a lo largo de su vida operativa; y c) Gestión de repuestos TLE, coordinando la adquisición de repuestos a NAMSA, su recepción, distribución, almacenamiento, y la gestión del proceso de abastecimiento (peticiones, solicitudes, inventarios, recepción, expedición, informes, etc.). Entre otros aspectos, el apoyo de Isdefe se ha materializado en el diseño, desarrollo e implantación de un sistema de información que posibilita a la Oficina de Programa recoger, procesar, distribuir y archivar la gran cantidad de datos e información a coordinar y gestionar, proveniente o con destino en las industrias nacionales y extranjeras, entidades y organismos del Ministerio de Defensa y del Ejército que

174


están involucrados con el programa TLE. Este sistema de información es el Sistema de Gestión Integrada del programa TLE. 12.3.3.

El Sistema de Gestión Integrada del programa TLE

Tiene por objetivo proporcionar de forma continua a la Jefatura de Programa la información de la situación de los contratos del núcleo del programa de manera que permita la toma de decisiones en tiempo útil. El núcleo del programa, que supone el 50% del presupuesto total del mismo, lo constituyen cuatro contratos: Reducción de TLEs, Carros de Recuperación, Revisión y Potenciación de Carros. Aunque cada contrato o proyecto individual de los que constituyen el núcleo del programa TLE tiene ciertas peculiaridades propias, el Sistema de Gestión Integrada trata a todos en base a una arquitectura funcional similar, en la que están implicados los mismos elementos. 12.3.4.

Elementos del diseño del sistema de gestión

Además de otras limitaciones y requisitos menores, el requisito esencial bajo el que se desarrolla el Sistema de Gestión Integrada del programa TLE, es, como ya se ha dicho, “proporcionar en tiempo útil, la información de la situación de los contratos” . El puente entre estos requisitos y la implementación que los satisface ha sido el trabajo de diseño realizado, que, para el Sistema de Gestión, ha seguido dos etapas: diseño conceptual y diseño detallado. El objetivo del diseño conceptual («qué hay que hacer») ha sido el especificar una arquitectura del sistema que satisfaga los requisitos y limitaciones. El diseño detallado posterior ha proporcionado los detalles en cuanto al tratamiento y representación de los datos («cómo hay que hacerlo»).


Los procesos integrados bajo la arquitectura del Sistema de Gestión son los siguientes: captura de datos, transmisión de datos, análisis de los datos de gestión y presentación de información. En la Figura 12.1 se ilustra el esquema conceptual del sistema, donde aparecen reflejados los distintos elementos del mismo, y el flujo general de la información. Como notación de diseño se han utilizado los diagramas de flujo de datos, entre otras razones por la facilidad de estos para representar cualquier nivel de abstracción. La Figura 12.2 presenta el diagrama de contexto que ilustra la arquitectura del Sistema de Gestión al nivel más alto, donde se indican las entidades externas que se relacionan con el sistema (fuentes de información y destinatario de los informes), y los conjuntos de datos que fluyen en cada caso. Los elementos sobre los que se ha construido el diseño, recogidos en el diagrama de contexto, han sido: 1) Datos: Constituidos por la información que es necesario conocer para ejercer el adecuado seguimiento y control de las actividades de cada contrato, a partir de las que deben poder generarse, mediante su procesado y análisis, los informes de gestión precisos. Los requisitos del Sistema de Gestión del TLE han hecho posible considerar tres tipos de datos: referencia, control y logística. a) Datos de referencia: Son los datos establecidos al inicio de los trabajos y que permanecen fijos durante todo el proyecto, salvo que se autoricen cambios. Son los datos de referencia contra los que se comparan los datos de control que se van produciendo durante el transcurso del proyecto. Los posibles cambios que pueden producirse en estos datos, deben estar debidamente aprobados, pasando así a constituirse en nueva referencia.

176



b) Datos de control: Son los datos que permiten evaluar el grado de avance de los trabajos, y determinar la marcha del contrato desde el punto de vista de la gestión. Los datos de control se han agrupado en: datos económicos y datos de situación de obra de cada contrato. c) Datos de logística: Son los datos integrados por la Base de Datos de Inspección, el Sistema de Gestión de Repuestos y la Base de Datos de Configuración. La Base de Datos de Inspección, que junto con la información proporcionada por el Sistema de Gestión de Repuestos, permite conocer la marcha de las actividades relacionadas con el aprovisionamiento de los repuestos, así como con la puesta de los carros al nivel Mínimo Operativo Español (MOE). 2) Fuentes de información: Constituidas por las Unidades, Centros u Organismos donde se generan los datos, las cuales

178


transmiten estos al centro donde son procesados y analizados. En el Sistema de Gestión del TLE se han identificado las siguientes: a) Órgano Director, como entidad que marca las directrices generales del programa, proporcionando los datos de referencia para el sistema y aprobando los cambios de gran alcance que puedan producirse. b) Órgano de Contratación, que genera los datos de referencia que se encuentran en las prescripciones técnicas de cada expediente. c) Comisión de Seguimiento que proporciona los datos de referencia, y aquellos cambios sobre los mismos que, por su alcance, no es necesario que sean aprobados por el Órgano de Contratación. Además proporciona datos de control relativos a la gestión del programa y relacionados con la planificación, como calendarios de entregas y recepciones de material, etc. d) Sección Técnica a través de la que se obtienen los datos técnicos necesarios relativos a los procesos y trabajos que comporta cada expediente. e) Sección Económico-Financiera que es quien proporciona los datos económicos del programa a nivel de cada expediente. f)

Inspecciones Técnico-Receptoras, que proporcionan los datos de avance de obra, a través de los Responsables de Aseguramiento de la Calidad (RAC) de cada contrato.

3) Flujos de datos/canales de transmisión: Es el conjunto de procedimientos, métodos y medios, que permiten que los datos se transmitan, desde las fuentes de información hasta el centro de proceso y análisis de los datos. En la Figura 12.3 se ilustra el esquema general de


relaciones entre las secciones u organismos que intervienen directamente en el seguimiento y control de los expedientes del núcleo del programa. Se recoge en la Figura 12.4 el flujo de datos entre estas entidades asociadas al Sistema de Gestión Integrada. a) El flujo de datos que proporcionan las Inspecciones Técnico Receptoras consiste esencialmente en: i)

Datos para determinar el grado de avance de los trabajos (Puntos de Inspección Obligatoria (PIOs), fechas de cumplimiento de PIOs, en caso de incumplimiento, nueva fecha prevista, impacto en otros PIOs, etc.).

ii) Datos de equipos a suministrar/reparar por subcontratistas (datos de identificación, fecha de envío, fecha de recepción, etc.).

180


iii) Datos de ítems/equipos a entregar por Ejército de Tierra (datos de filiación, fecha de recepción, etc.). iv) Datos para el control y seguimiento de la planificación de los trabajos (fecha de recepción/inicio de operaciones, fecha de inicio y final de cada fase del proceso, etc.). b) La OP TLEs, proporciona los datos relativos a cambios aprobados en los datos de referencia. 12.3.5.

Proceso de datos y generación de informes

Para alcanzar el objetivo de obtener una información procesada, útil para la toma de decisiones relacionadas con la gestión de cada contrato, los datos son sometidos al conjunto de procesos (fusiones, filtrados, combinaciones y algoritmos) que se describen a continuación.


El diagrama de la Figura 12.5 constituye una descomposición funcional de primer nivel del Sistema de Gestión Integrada que se obtiene abriendo el diagrama de contexto presentado en la Figura 12.2. Se ha seguido el siguiente convenio de representación: a) Los procesos a que se someten los datos se representan por círculos; b) Las flechas representan flujos de datos; y c) Las barras paralelas horizontales representan bases de datos para almacenamiento de los mismos. El diseño del Sistema de Gestión realizado, ha permitido identificar a este nivel los siguientes cinco procesos de datos: 1) Seguimiento de la planificación del núcleo del programa . Para cada uno de los contratos del núcleo del programa, este proceso mantiene actualizada la planificación de los mismos, incorporando los cambios aprobados que se hayan producido en los datos de referencia. Asimismo, se controla la marcha de los trabajos y avance de obra, que se integra a nivel de la planificación, al objeto de establecer la situación respecto al cumplimiento de la misma. 2) Disponibilidad de carros . Aunque los cuatro contratos del núcleo del programa son técnicamente independientes, la disponibilidad de carros operativos en el Ejército de Tierra en un momento dado es el aspecto esencial a través del que se relacionan y que incide en todos los contratos. La información de disponibilidad de carros se genera a partir de los datos de entregas y recepciones previstas. 3) Grado de avance de los trabajos . Para los contratos del núcleo del programa con Puntos de Inspección Obligatoria (PIOs),

182


Entregas/Recepciones


se determina el grado de avance de los trabajos por cada carro, y a nivel del conjunto de los mismos en base a: a) Elementos que han pasado cada PIO, y PIOs que ha pasado cada carro. b) Para cada carro, diagrama de Gantt donde se ilustra la planificación prevista y se compara con el avance realizado hasta la fecha. c) Número de carros, subconjuntos y elementos importantes que se encuentran reparados y disponibles para montaje. d) Planificación de entregas y recepciones de material por parte de Ejército de Tierra y del contratista y subcontratistas. 4) Seguimiento de costes . Para el control y seguimiento de los costes incurridos en las reparaciones, se contabilizan los costes de reparaciones, diferenciando las contempladas en el proceso estándar, de las que están fuera del proceso estándar. 5) Situación económica del programa . Este proceso genera los informes de la situación económica del programa que a continuación se indican, a partir de los datos actualizados de la base de datos para el Seguimiento de la Gestión de Presupuestos: a) Diagrama general del gasto asignado, iniciado, adjudicado y librado del programa. b) Resumen de la situación de la contratación prevista en el año en curso, tanto para mantenimiento como para inversión.

184


c) Gasto adjudicado a empresas, nacionales o extranjeras, por anualidades, pendientes de adjudicar en los distintos elementos de programa, comprometidos para próximas anualidades, etc. La información elaborada que se obtiene del proceso de los datos, se presenta a la Jefatura de Programa mediante esquemas y formatos preestablecidos al objeto de proporcionar una amplia visibilidad sobre la situación de los expedientes. Estos informes contienen también las conclusiones que se derivan del análisis de la situación, y la propuesta de acciones correctoras en caso de existir desviaciones respecto a los requisitos de calidad, coste o plazo. Los informes sistemáticos que, con una periodicidad bimensual, genera el Sistema de Gestión son básicamente los siguientes: a) Informe gerencial, en el que se resume la situación general del programa a la fecha, y se enumeran los aspectos críticos y las acciones correctoras propuestas. b) Situación económica del programa, donde se recogen los diagramas en los que se representa la situación económica. c) Disponibilidad de carros, que recoge la previsión actualizada de disponibilidad de carros, de acuerdo con las planificaciones de los expedientes. d) Planificación de los expedientes del núcleo del programa, en donde se presentan las planificaciones actualizadas de los expedientes del núcleo. En estos diagramas se incorpora el avance de los trabajos sobre la planificación de referencia, y los hechos destacables que hayan tenido lugar. También recoge el calendario actualizado de entregas y recepciones.


e) Grado de avance de los trabajos, que ilustra el grado de avance de los trabajos, mediante la inclusión de diagramas de Puntos de Inspección Obligatoria superados, avance de los subcontratistas, planificaciones particulares, etc. f)

Seguimiento de los costes que incluye el cuadro de costes descrito en el apartado anterior.

186


187

13

Epílogo

188


13.1.Introducción La experiencia es la madre de la ciencia , dice uno de nuestros más populares refranes. Y encierra una gran verdad. La teoría es importante, pero la práctica es insustituible. Sólo se puede hablar con propiedad de aquello que se conoce por haberse experimentado. El objetivo de este último Capítulo es resumir la experiencia acumulada por Isdefe no sólo en los once programas que han servido para ilustrar otros tantos aspectos del proceso de ingeniería de sistemas en los Capítulos precedentes, sino en el conjunto de todos los programas en los que ha participado desde su creación. 13.2. La rueda es redonda y rueda bien Antes de comentar en detalle las lecciones aprendidas por Isdefe en su aplicación de los conceptos de ingeniería de sistemas, es necesario destacar como primera lección la importancia de no reinventar la rueda. Con una frecuencia lamentable se tiende a consumir recursos valiosos y escasos, como el tiempo, en el diseño de procedimientos o métodos para la resolución de problemas bien conocidos y estudiados con el agravante adicional del riesgo de no «encontrar» la solución adecuada u óptima, cuando una cierta labor de investigación o documentación permitiría conocer el método o procedimiento más recomendado (si es que no fuera ya directamente conocido) en base a la experiencia demostrada en su aplicación.

189 Epílogo

Por ejemplo, supongamos que en el diseño de un sistema es necesario realizar un análisis de modos de fallos para identificar áreas críticas del diseño y poder tomar las acciones oportunas (por ejemplo rediseño, o establecimiento de tareas de mantenimiento preventivo que eviten la aparición de ciertos modos de fallos o que al menos palien sus efectos, si llegan a producirse). No sería lógico ni práctico tratar de desarrollar un modelo propio para realizar tal tipo de análisis, cuando existen procedimientos bien documentados y ampliamente contrastados (tales como el Análisis de Modos de Fallos, sus Efectos y su Criticidad, o el Análisis de Árboles de Fallos) que se ajustan a lo necesitado. En todo caso, siempre puede modificarse algún procedimiento o método existente para que refleje aspectos particulares importantes del caso en estudio. Es pues tan necesaria la información como la formación. Sin una buena preparación es difícil afrontar con éxito problemas complejos, y una falta de información puede suponer un aprovechamiento ineficaz e ineficiente de los recursos empleados por haberse tratado de reinventar, una vez más, la rueda. 13.3. Resumen de lecciones aprendidas Partiendo de la característica teleológica de los sistemas diseñados por el hombre, un planteamiento metódico y estructurado de análisis de las necesidades identificadas es esencial para la precisa determinación de los requisitos del sistema que las satisfaga. El coste del ciclo de vida y la efectividad de un sistema determinan, conjuntamente, la utilidad que éste representa para su usuario. De ahí se deriva la necesidad de incluir consideraciones de ambos desde las fases iniciales del ciclo de vida de los sistemas. La evolución de un sistema a lo largo de las diferentes etapas y la cantidad y diversidad de actividades a desarrollar en cada una de ellas confiere una singular importancia a la planificación. Sin una

190


rigurosa identificación, definición y ordenación de las actividades a realizar es imposible alcanzar los objetivos de la ingeniería de sistemas. Nunca se enfatizará lo suficiente la importancia de una especificación de requisitos correcta (que realmente defina la necesidad identificada) y completa (que cubra todos los aspectos relevantes); no deben ser ni más ni menos que los necesarios para definir el sistema requerido siendo tan perjudicial el especificar por exceso como el hacerlo por defecto. Los requisitos son la definición cualitativa y cuantitativa de lo que el usuario necesita, y una buena especificación es esencial para asegurar que el producto finalmente obtenido responda fielmente a sus expectativas. Deben desterrarse los falsos pragmatismos en base a los que se comienzan diseños y desarrollos sobre especificaciones excesivamente incompletas o inestables, en la creencia de que «se va adelantando trabajo», pues las adiciones y modificaciones posteriores aumentan dramáticamente los plazos y costes de obtención de los sistemas. Además, es vital que los requisitos puedan realmente ser «diseñados» en el sistema y que su cumplimiento pueda ser posteriormente comprobado (verificado) por métodos objetivos. Junto con la indicación de los métodos a seguir, en la demostración de los requisitos especificados, deben concebirse, planificarse y estructurarse desde las fases iniciales del ciclo de vida las pruebas que serán realizadas en las etapas finales del diseño y de la producción. Muchas de las actividades del proceso de ingeniería de sistemas requieren la selección entre posibles alternativas. Puede tratarse de elegir entre diferentes ofertas recibidas aquella que más se ajuste a lo solicitado, o de seleccionar entre configuraciones alternativas de diseño la que cumpla en mayor medida con los requisitos establecidos, etc. El hecho de que las alternativas a evaluar posean múltiples características, no todas definibles con una misma medida, hace imprescindible el desarrollo de modelos multiatributo de evaluación que permitan sintetizar, de forma

191 Epílogo

objetiva, las múltiples características de cada alternativa para poder compararlas entre sí. De forma similar, muchas de las decisiones que deben tomarse a lo largo del proceso de ingeniería de sistemas conllevan un cierto riesgo y, en algunos casos, llegan a desconocerse los futuros escenarios posibles o sus probabilidades de ocurrencia. La frecuencia con que en el diseño y desarrollo de sistemas se presentan desviaciones sensibles entre los plazos, prestaciones técnicas y costes previstos, y los finalmente alcanzados, marca la importancia de realizar los oportunos análisis de riesgos desde las etapas más tempranas del ciclo de vida de los sistemas. La dificultad principal con la que tropieza el análisis de riesgos durante las fases iniciales del ciclo de vida es la escasez de información, lo que impide en muchas ocasiones la cuantificación formal del riesgo, conduciendo a un entorno de decisión bajo incertidumbre. La forma más eficaz de superar estas dificultades es utilizar la experiencia acumulada en proyectos anteriores, articulando un procedimiento que facilite su reutilización. Las estimaciones de costes, ya sean paramétricas, integradoras o por analogía, son especialmente necesarias en las fases iniciales del ciclo de vida, donde se comprometen los costes del resto de las fases. Las estimaciones tempranas permiten analizar alternativas viables de diseño que faciliten el proceso de toma de decisiones, de forma que se obtengan las prestaciones deseadas del sistema a un coste global admisible para el usuario. La complejidad de los sistemas y de los procesos de diseño y de desarrollo, así como los aspectos relacionados con su utilización y mantenimiento, implican la necesidad de un riguroso control de su configuración. La gestión de la configuración es una función esencial cuya ejecución abarca todo el ciclo de vida de los sistemas, y que facilita en gran medida su obtención y posterior utilización. La implantación de los conceptos y principios de ingeniería de sistemas

192


requiere disponer de una eficaz gestión de la configuración. En su concepción genérica la gestión de la configuración es común para todo tipo de sistemas y comprende las siguiente áreas funcionales : identificación, control, registro de estados y auditorías de configuración. Para desarrollar la función de gestión de la configuración, además de disponer de las correspondientes capacidades técnicas y elementos de apoyo, son necesarios los aspectos concernientes al establecimiento de una estructura de organización y de unos procedimientos que aseguren en todo momento la consistencia e integridad de la información asociada a los elementos del sistema objeto de gestión de la configuración. En ocasiones los sistemas que se desarrollan vienen a sustituir a otros que se encuentran al final de su vida operativa, lo que plantea la necesidad de planificar y ejecutar la transición entre ambos. La transición debe llevarse a cabo por personal cualificado con elevada experiencia en los sistemas a implantar, desde puntos de vista técnicos, funcionales y de usuario. La previsión de la mayor parte posible de eventos que puedan presentarse, sólo puede ser realizada por personas que hayan participado en todas las fases previas del programa. La reacción ante eventos imprevistos que pueden aparecer en una transición debe ser inmediata, efectiva y con la mayor fiabilidad y seguridad posible. La comprobación de la bondad de un plan de transición sólo se realiza de forma completa en el momento de su implantación. En resumen, la ingeniería de sistemas es el enfoque integrado multidisciplinar que permite transformar necesidades identificadas en sistemas que las satisfagan eficientemente, con un aprovechamiento eficaz de los recursos empleados. Debe tenerse siempre presente que los sistemas tienen elementos hardware, elementos software, y que son utilizados y mantenidos por el hombre. La no consideración de todos esos elementos y de las relaciones e interacciones que existan entre ellos supondrá inevitablemente una merma sensible en la eficiencia y la eficacia de los sistemas obtenidos.

193 Epílogo

13.4.Kaizen Kaizen significa, en japonés, mejora continua [15]. Esa es la actitud del verdadero ingeniero de sistemas, una constante inquietud por mejorar su formación tanto de generalista como de especialista en diferentes disciplinas. Los mejores ingredientes no hacen un buen plato en manos de un cocinero inexperto. No basta con pretender seguir «los pasos» del bien definido proceso de ingeniería de sistemas para obtener sistemas que satisfagan, de forma eficaz y eficiente, necesidades identificadas; es imprescindible tener una visión de conjunto y conocer el porqué de lo que hay que hacer y de cómo hay que hacerlo, que más que un estado que alguna vez pueda decirse que se ha alcanzado es la dirección en la que siempre se debe caminar.

194


195

Referencias

196


[1] Clarke, A. C., 2001: A Space Odyssey, Hutchinson, Londres, 1968. [2]

Sagan, C., Dragons of Eden, Ballantine Books, Nueva York, 1977.

[3] Sarabia, A., La Teoría General de Sistemas, Publicaciones de Ingeniería de Sistemas, Isdefe, Madrid, 1995. [4] Drew, D.R., Dinámica de sistemas Aplicada, Publicaciones de Ingeniería de Sistemas, Isdefe, Madrid, 1995. [5] Aracil, J., Dinámica de Sistemas, Publicaciones de Ingeniería de Sistemas, Isdefe, Madrid, 1995. [6] Blanchard, B. S., Ingeniería de Sistemas, Publicaciones de Ingeniería de Sistemas, Isdefe, Madrid, 1995. [7] D. G. Telecomunicaciones, Escenarios de usuarios y aplicaciones en PlanBA, Madrid, 1991. [8] D. G. Telecomunicaciones, Tecnologías relevantes en PlanBA, Madrid, 1991. [9] D. G. Telecomunicaciones, Plan de Trabajo PlanBA, Madrid, 1991. [10] D. G. Telecomunicaciones, Guía para presentar propuestas a PlanBA, Madrid, 1991. [11] Stanag 4175, Technical Characteristics of MIDS. [12] Stanag 5516, Tactical Data Exchange, Link 16. [13] Quiñones, M. R., Sistema SADA Semiautomático de Defensa Aérea, Revista de Aeronáutica y Astronáutica, noviembre, 1984.

197 Referencias

[14] Sistema de Mando y Control Aéreo, (ejemplar monográfico), Revista de Aeronáutica y Astronáutica, septiembre 1990. [15] Imai, M., Kaizen, McGraw-Hill Publishing Co., Nueva York, 1986.

198


199

Bibliografía

200


Akao, Y. (ed.): Akigama, K.: Blanchard, B.S.: Blanchard, B.S. & W.J. Fabrycky: Canada, J.R. & W. G. Sullivan: Cuthbertr, L.G. & J.C. Sapanel: Fishburn, P.C.: Gregory, G.: Hammer, C. & J. Champy: Handel , R. & M.N. Huber:

Quality Function Deployment , Productivity Press, Portland, OR, 1990. Function Analysis , Productivity Press, Cambridge, MA, 1991. Engineering Organization and Management, Prentice-Hall Inc., Englewood Cliffs, NJ, 1986. Life Cycle Cost And Economics Analysis, Prentice-Hall, Englewood Cliffs, N.J., 1991. Economic and Multiattribute Evaluation of Advanced Manufacturing Systems, Prentice-Hall, Inc., 1989. ATM. The Broadband Telecommunications Solution, IEE Telecommunication Series 29, Londres, 1993. Uthility Theory for Decision Making, John Wiley & Sons, Inc., Nueva York, 1970. Decision Analysis, Plenum Publishing Co., 1988. Reingeniería de la Empresa , Parramón Ediciones, Barcelona, 1994. Integrated Broadband Networks, Addisson-Wesley, Gran Bretaña, 1991.

Marazzi, C.A.:

A Value Analisys Method for The Evaluation of Telecommunication System Bid proposals, IEEE 2/5/95.

Ostwald, P.F.:

Cost Estimating, Wiley Interscience, New York, 1991.

Sanders, M.S. & E.J. McCormick:

Human Factors in Engineering and Design , 7th Ed., McGraw-Hill, 1993.

201 Bibliografía

Senge, P.M.:

La Quinta Disciplina , Granica, Barcelona, 1992.

Soldevilla, E.:

Decisiones Empresariales con Riesgo e Incertidumbre, Hispano Europea S.A., Barcelona, 1984.

Stewart, R.D.:

Cost Estimating, Prentice-Hall, Englewood Cliffs, N.J., 1984.

Stewart, R.D. & R.M. Wyskida:

Cost Estimator Reference Manual, Wiley Interscience, Nueva York, 1987.

-

MIL-STD-973, Configuration Management.

-

MIL-STD-480, Configuration Control-Engineering Changes, and Waivers.

-

MIL-STD-483, Configuration Management Practices for Equipment, Munitions and Computer Programs.

-

STANAG 4189, NATO Material Configuration .

-

Management Policy and Procedures. The AEGIS Scenario: GIANTS, AG-IS-129-T10F-P-04.0, noviembre, 1994.

-

Risk Assessment Techniques, Defense Systems Management College, Fort Belvoir, Virginia, 1983.

202


203

Glosario

204


1. ANÁLISIS DE RIESGO. Análisis matemático de la probabilidad de desviaciones respecto a los objetivos de coste, calendario y prestaciones de un programa. Es un proceso iterativo que trata de identificar y cuantificar lo que podría ir mal. 2. AUDITORÍAS DE CONFIGURACIÓN. Verificación de la conformidad de los elementos de configuración respecto a especificaciones y otros requisitos establecidos (control de calidad, planes de gestión de configuración, etc.). Las auditorías pueden ser funcionales o físicas. 3. COMITÉ DE CONTROL DE CONFIGURACIÓN. Comité compuesto por representantes de las funciones técnicas y administrativas de un sistema que aprueban o rechazan los cambios de ingeniería propuestos en una línea base previamente aprobada. 4. COMUNICACIONES DE BANDA ANCHA. Transmisión y conmutación de datos, voz e imagen fija o en movimiento a velocidades superiores a 2 Mbit/s (típicamente 34, 155 ó 622 Mbits/s). Las comunicaciones de banda ancha están asociadas a tecnologías avanzadas como la transmisión por fibra óptica, el Modo de Transferencia Asíncrono (MTA) o la microelectrónica de alta velocidad. 5. CONTROL DE CONFIGURACIÓN. La propuesta sistemática, justificación, evaluación, coordinación, aprobación o rechazo de los cambios y la implantación de todos los cambios

205 Glosario

aprobados en la configuración de un elemento de configuración después del establecimiento formal de su línea base de referencia. El control de la configuración proporciona una metodología a seguir para el tratamiento de alteraciones en los componentes y líneas de referencia. Mediante un soporte técnico y administrativo se hace posible mantener la visibilidad del sistema. 6. DEMOSTRADOR DE COMUNICACIONES. Es un banco de pruebas o un prototipo experimental para mostrar las capacidades de una tecnología de comunicaciones en concreto. 7. ELEMENTO DE CONFIGURACIÓN. Conjunto de hardware, firmware, software, o cualquiera de sus elementos discretos, que satisface una función final y forma parte de la gestión de configuración. Cualquier elemento requerido para el apoyo logístico y que se puede adquirir de forma independiente, es un elemento de configuración y puede variar en complejidad, tamaño y tipo. 8. ELEMENTO DE RIESGO. Una posible desviación entre lo ofertado y el subsistema final que pueda conseguirse. 9. ENTORNO DE INCERTIDUMBRE. Entorno de decisión en el cual no se conocen las distribuciones probabilísticas del espacio de alternativas. 10. ENTORNO DE RIESGO. Entorno de decisión en el cual se conocen las distribuciones probabilísticas del espacio de alternativas. 11. ESCENARIO. Descripción preceptiva del estado futuro de un sistema o subsistema, teniendo en cuenta las diversas restricciones y problemas que se pretenden resolver con la implantación de conceptos existentes o nuevos. 12. ESTIMACIÓN DE COSTE INTEGRADORA. Técnica que se caracteriza por el análisis en profundidad de todos los elementos,

206


procesos, componentes y conjuntos que componen un sistema y la aplicación de los costes horarios, de materiales y gastos generales a cada uno de estos elementos. 13. ESTIMACIÓN DE COSTE POR ANALOGÍA. Técnica que utiliza la similitud entre dos o más sistemas para la medición de los costes asociados con el desarrollo, fabricación y/o modificación de un elemento específico. 14. ESTIMACIÓN PARAMÉTRICA DE COSTE. Técnica que utiliza una o más relaciones de estimación de coste para medición de los costes asociados con el desarrollo, fabricación, y/o modificación de un elemento específico y se basa en sus características técnicas, físicas u otras. 15. FUNCIÓN DE UTILIDAD. Función del espacio de alternativas a los números reales que expresa las preferencias del decisor, esto es: x es preferido a y si y sólo si u(x ) > u(y ). 16. GESTIÓN DE CONFIGURACIÓN DE UN SISTEMA. La parte del proceso de ingeniería de sistemas que identifica las características físicas y funcionales de los elementos de un sistema durante su ciclo de vida, controla los cambios a dichas características, y registra e informa del proceso de cambios y el estado de ejecución. 17. IDENTIFICACIÓN DE CONFIGURACIÓN. El proceso de documentar los requisitos de prestaciones, cualificación, fabricación y aceptación de los elementos de la configuración de un sistema. Generalmente se desarrolla y mantiene a través de los distintos niveles incrementados, cada uno de ellos utilizado para establecer una línea base específica. Estos tres niveles son: (1) identificación de la configuración funcional; (2) identificación de la configuración distribuida; y (3) identificación de la configuración de producto. 18. ÍNDICES DE RENTABILIDAD. Métodos cuantitativos en los que se valoran aspectos financieros de la empresa.

207 Glosario

19. LISTAS DE CONTROL. Sistemas básicamente cualitativos en los que se valoran, de forma subjetiva, diversos criterios de una oferta. 20. MODO DE TRANSFERENCIA ASÍNCRONO (MTA). Tecnología de transmisión y conmutación de paquetes de longitud fija (53 octetos) muy flexible para el transporte de información (datos , voz e imagen fija o en movimiento). Está ligado a las tecnologías de comunicaciones de banda ancha. 21. PlanBA. Plan de acción nacional para la I+D en comunicaciones integradas de banda ancha, desde 1992 a 1995. 22. PROBABILIDAD SUBJETIVA. Expresión de la susceptibilidad de predicción basada en valoraciones personales que cumple los axiomas de probabilidad. 23. PROCEDIMIENTO. Metodología que define claramente la forma en que debe realizarse una evaluación incluyendo formatos, métodos a utilizar, forma de asignación de grupos evaluadores, generación de informes, archivo y tratamiento de la documentación generada etc. 24. RELACIÓN DEL ESTADO DE LA CONFIGURACIÓN. Suministra la historia de como un sistema ha sido cambiado, registrando las actividades de las otras funciones de la gestión de la configuración. En un momento determinado, disponer de los registros de los cambios realizados en el sistema permite diagnosticar fallos en el mismo. 25. TRANSICIÓN OPERATIVA. Acción encaminada a permitir la entrada en operación de nuevos sistemas o versiones de un programa sin afectar a la eficacia, fiabilidad y seguridad del servicio a prestar. 26. VALIDACIÓN. Proceso de evaluación de un elemento de configuración para determinar el grado de cumplimentación de los requisitos específicos.

208


27. VERIFICACIÓN. Proceso de evaluación de los productos de una determinada actividad de desarrollo para determinar la consistencia y corrección con respecto a los productos suministrados como entrada a esta actividad, y conforme a las normas y procedimientos que regulan la ejecución de la actividad.

209 Glosario

210


5 Ingenieria de Sistemas Aplicada

Recommend Documents