5 ingenieria de sistemas aplicada

P u b l i c a c i o n e s d e I n g e n i e r a d e S i s t e m a s

ING

EN

IER

A D

E S

ISTE

MA

S A

PLI

CA

DA. Is

defe

Ingeniera de Sistemas

c/ Edison, 428006 MadridTelfono (34-1) 411 50 11Fax (34-1) 411 47 03E-mail: [email protected] P.V.P.: 1.000 Ptas.

(IVA incluido)

INGENIERA DE SISTEMASAPLICADA

Isdefe

Otros ttulos publicados:

1. Ingeniera de Sistemas. Benjamin S. Blanchard.2. La Teora General de Sistemas. ngel A. Sarabia.3. Dinmica de Sistemas. Javier Aracil.4. Dinmica de Sistemas Aplicada. Ronald R. Drew.5. Ingeniera de Sistemas Aplicada. Isdefe.6. CALS (Adquisicin y apoyo continuado durante el ciclo de

vida). Rowland G. Freeman III.

5COMIT DE REDACCINPresidente Sr. D. Martn Alear Ginard Teniente General (R) del Ejrcito de Tierra

Vocales Sr. D. Eduardo Avanzini Blanco General de Brigada Ingeniero del Ejrcito del Aire

Sr. D. Carlos Casajs Daz Vicealmirante Ingeniero de la Armada

Sr. D. Luis Garca Pascual Vice-Rector de Investigacin y Postgrado de la UPCO

Sr. D. Ricardo Torrn Durn General de Brigada Ingeniero del Ejrcito de Tierra

Sr D. Alberto Sols Rodrguez-Candela Ingeniero de Sistemas. Isdefe

Sra. Da. M Fernanda Ruiz de Azcrate Varela Imagen Corporativa. Isdefe

ILUSTRACIN DE PORTADATorno plano de 1850

Isdefe ha acumulado, en estos primerosdiez aos, ms de 1.6 millones de horas deingeniera colaborando en diferentes pro-gramas, en las reas de mando y control,apoyo logstico, telecomunicaciones, tec-nologas de la informacin, navegacinarea, investigacin operativa, simulacin,seguridad, proteccin del medio ambiente,y formacin de personal, siempre bajo laperspectiva del enfoque sistmico. Aproxi-madamente un 70 % de esas horas hancorrespondido a programas del sector de-fensa y el 30 % restante al sector civil.

El objetivo de esta monografa es resumir laexperiencia adquirida por Isdefe en el campode la ingeniera de sistemas. Para ello sehan seleccionado once de los principalesprogramas en los que se ha participado, detal forma que con ellos se cubran diferentesaspectos o disciplinas de la ingeniera desistemas y se abarquen, adems, lasdiferentes fases del ciclo de vida de lossistemas.

1No est permitida la reproduccin total oparcial de este libro, ni su tratamientoinformtico, ni la transmisin de ningunaforma o por cualquier medio, ya seaelectrnico, por fotocopia, por registro o porotros mtodos, sin el previo consentimientopor escrito de los titulares del Copyright.

Primera Edicin: Septiembre - 19951.250 ejemplares

' Isdefec/ Edison, 428006 Madrid.

Diseo:HB&h Direccin de arte y produccin

Infografa de portada:Salvador Vivas

Fotomecnica:Microprint, S.A.

Impresin:Grficas Forma, S.A. (Madrid)

ISBN: 84-89338-05-1Depsito legal: M- -1995Printed in Spain - Impreso en Espaa.

3Madrid, 15 de septiembre de 1995

Han transcurrido ya diez aos desde la creacin de Isdefe en1985 y puede decirse hoy con satisfaccin que la empresa ha madu-rado rpidamente y se ha consolidado como una compaa de inge-niera de sistemas capaz de apoyar eficazmente a las Fuerzas Arma-das, al Ministerio de Defensa y en general a la Administracin Pbli-ca. Los trabajos desarrollados en estos aos han permitido consolidarconocimientos y adquirir una experiencia significativa.

La serie de monografas que estamos editando est orientada adivulgar los fundamentos de la ingeniera de sistemas. Sus autoresson profesionales cualificados que explican, de forma clara y sencilla,los aspectos bsicos de la ingeniera de sistemas y sus disciplinasasociadas.

La intencin de la monografa que ahora se presenta es reflejar,de forma coherente con la serie en la que se integra, actuaciones deingeniera de sistemas realizadas por Isdefe para la Administracinespaola, donde se refleja parte de la experiencia vivida durante es-tos primeros diez aos de andadura, en este apasionante campo.

Quiero agradecer al personal de la empresa que est colabo-rando con la serie y especialmente a los autores de las monografasy a los miembros del Comit de Redaccin, la ilusin volcada eneste proyecto.

Jos Vicente CebrinConsejero Delegado de Isdefe

INGENIERA DE SISTEMAS APLICADA4

5NDICE GENERAL1. INTRODUCCIN (Alberto Sols Rodrguez-Candela) 9

1.1. Evolucin de la complejidad de los sistemas 101.2. El enfoque sistmico 101.3. La creacin de Isdefe 121.4. Experiencia de Isdefe en ingeniera de sistemas 131.5. Desarrollo de la monografa 14

2. AEGIS: DISEO CONCEPTUAL DEL FUTURO SISTEMADE GESTIN DEL TRNSITO AREO (Trudi Kiebala Xiol) 192.1. Descripcin global del proyecto AEGIS 202.2. Relacin del proyecto con la ingeniera de sistemas 212.3. Fase 1: evaluacin 212.4. Fase 2: mejora 262.5. Fase 3: consolidacin 282.6. Valor aadido del proyecto 282.7. Consideraciones finales 29

3. EVALUACIN DE DESARROLLOS BASADOS EN UNA NUEVATECNOLOGA: DEMOSTRADOR PlanBA (Rafael Garca Vzquez) 313.1. El programa PlanBA 323.2. Evaluacin de desarrollos en PlanBA 33

3.2.1. Identificacin de tecnologas relevantes en banda ancha 353.2.2. Identificacin de aplicaciones y usuarios de banda ancha 363.2.3. Definicin del plan de trabajo para la consecucin del

demostrador 373.3. Evolucin del proyecto integrado PlanBA 38

4. ESPECIFICACIN DE REQUISITOS EN ELPROGRAMA MIDS (Luis Rodrguez Palencia) 434.1. El sistema MIDS 444.2. El programa MIDS 454.3. Actividades previas a la fase de desarrollo 46

4.3.1. Preparacin de la peticin de oferta 464.3.2. Reduccin de prestaciones tcnicas 534.3.3. Negociacin del precio 534.3.4. Establecimiento de la lnea base 544.3.5. Seguimiento industrial 544.3.6. Seguimiento de costes 554.3.7. Gestin del espectro radioelctrico 55

4.4. Consideraciones finales 56

5. ANLISIS DE RIESGOS DURANTE LA EVALUACIN DE OFERTASEN EL PROGRAMA SANTIAGO (Juan Jos Martnez Dopico) 595.1. El programa Santiago 605.2. Anlisis de riesgos 61


5.3. La metodologa utilizada 625.3.1. Objetivos 625.3.2. Identificacin 635.3.3. Evaluacin del impacto 655.3.4. Cuantificacin de la probabilidad 665.3.5. Integracin 675.3.6. Automatizacin del proceso 69


6. PROCEDIMIENTO DE EVALUACIN DE OFERTASEN EL PROGRAMA SIMCA (Jorge Parra Gila) 756.1. Descripcin general del programa Simca 766.2. Evaluacin de ofertas. Metodologa 78

6.2.1. Introduccin 786.2.2. Procedimiento de evaluacin 79


7. ANLISIS DE VALOR EN LA F-100(Fernando J. Morales Moreno y Jos Luis Snchez Menndez) 917.1. El programa F-100 927.2. Anlisis de valor en el programa F-100 927.3. Anlisis de costes. Estudios paramtricos 93

7.3.1. Generalidades 937.3.2. Anlisis de costes 967.3.3. Herramienta paramtrica de estimacin de costes 977.3.4. Aplicacin de los anlisis paramtricos

de ingeniera de costes en la fragata F-100 1007.4. Consideraciones finales 102

8. GESTIN DE LA CONFIGURACIN EN EL SCTM(Juan Mndez Farias) 1058.1. Programa SCTM 1068.2. Gestin de la configuracin aplicada al SCTM 1078.3. Concepto de gestin de la configuracin 108

8.3.1. Elementos de gestin de la configuracin 1108.4. Descripcin de actividades 1138.5. Consideraciones finales 114

9. PROCESO DE SELECCIN DE EQUIPOS Y SUMINISTRADORESEN EL PROGRAMA EF2000 (Jos Manuel Buergo Villanueva) 1219.1. Descripcin del programa 1229.2. Participacin de la industria espaola 1229.3. Equipos de avin y accesorios de motor 1239.4. Proceso de gestin del desarrollo 1259.5. Proceso de seleccin 126

9.5.1. Principios del proceso de seleccin 1269.5.2. Evaluacin y aprobacin de especificaciones 1279.5.3. Seleccin de suministradores de equipos 1289.5.4. Criterios de evaluacin y seleccin 132


710. VERIFICACIN Y VALIDACIN EN EL PROGRAMA EUROMAYA(Juan Revuelta Lapique) 14110.1. Descripcin del programa Euromaya 14210.2. Verificacin y validacin 14510.3. Descripcin de actividades 147

10.3.1. Auditoras e inspecciones 14810.3.2. Revisiones 14910.3.3. Pruebas 150


11. TRANSICIN OPERATIVA EN EL PROGRAMA SACTA(Miguel Baragao Fueyo) 15711.1. Descripcin del programa SACTA 15811.2. Transicin operativa 161

11.2.1. Caractersticas generales 16111.2.2. Planificacin de la transicin 16211.2.3. Preparacin de la transicin 16411.2.4. Ejecucin de la transicin 165

11.3. Ejemplo de transicin (Madrid) 16511.4. Consideraciones finales 166

12. SISTEMAS DE GESTIN INTEGRADA DEL PROGRAMA TLE(lvaro Manresa Snchez) 16912.1. Introduccin 17012.2. Descripcin del programa TLE 170

12.2.1. Objetivo 17012.2.2. Situacin actual del programa 171

12.3. La gestin del programa TLE 17212.3.1. Ingeniera y gestin 17212.3.2. Colaboracin de Isdefe en el programa TLE 17312.3.3. El sistema de gestin integrada del programa TLE 17412.3.4. Elementos del diseo del sistema de gestin 17412.3.5. Proceso de datos y generacin de informes 180

13. EPLOGO (Alberto Sols Rodrguez-Candela) 18713.1. Introduccin 18813.2. La rueda es redonda y rueda bien 18813.3. Resumen de lecciones aprendidas 18913.4. Kaizen 193

REFERENCIAS 195

BIBLIOGRAFA 199GLOSARIO 203

91Introduccin

INGENIERA DE SISTEMAS APLICADA1 0

1.1. Evolucin de la complejidad de los sistemas

En su apasionante novela 2001: Una odisea del espacio [1],Arthur C. Clarke narra la evolucin de la especie humana desde eldespertar de la inteligencia en los pre-homnidos, en la NochePrimigenia, a los viajes de la era espacial de un futuro prximo. CarlSagan, en su ensayo cientfico Los dragones del Edn [2], muestraque la lentitud de desarrollo de la especie humana viene compensadapor una extraordinaria capacidad de aprender y crear cosas. Ambosautores ponen de manifiesto el potencial del hombre para disear ydesarrollar cosas cada vez ms complejas. Entre las hachas de piedradel Paleoltico y los transbordadores y estaciones espaciales denuestros das no slo median dos millones de aos, sino un incrementocolosal en la complejidad de los sistemas diseados por el hombre.Esa complejidad crece exponencialmente, de forma que la mayora delos diseos de hace unas pocas dcadas estn hoy tecnolgica yfuncionalmente obsoletos. Con ello ha ido aumentando nuestranecesidad de un modelo o paradigma capaz de posibilitar el diseo ydesarrollo de sistemas.

1.2. El enfoque sistmico

Tanto el concepto de sistema como el modelo empleado para suestudio ha evolucionado notablemente con el tiempo [3]. Desde mediados

1 1Introduccin

del presente siglo el paradigma empleado en la conceptualizacin desistemas es el denominado enfoque sistmico, que aporta frente a supredecesor (el enfoque reduccionista de la Revolucin Industrial) laconsideracin explcita de que un sistema lo componen no slo suspartes integrantes, sino tambin las interrelaciones entre ellas. Esa noindependencia de las partes es una de las caractersticasfundamentales del enfoque sistmico, distinguido adems por suconsideracin del ciclo de vida de los sistemas.

La Figura 1.1 muestra la relacin entre la cantidad y calidad dela informacin disponible sobre un sistema a lo largo de su ciclo devida, as como la trascendencia e importancia de las decisiones toma-das en cada fase. La relacin entre los costes incurridos y los compro-misos contrados (coste, tecnologa, arquitectura del sistema, etc.) semuestra en la Figura 1.2. El hecho de que en las fases iniciales lainformacin sobre el sistema sea relativamente escasa y poco precisay que las decisiones adoptadas sean las ms importantes, por todos


los compromisos que al tomarlas se contraen, hace especialmenteimportante la consideracin, desde esas etapas iniciales, del conjuntodel sistema como algo dinmico a lo largo de un ciclo de vida; es decir,es esencial un enfoque sistmico.

1.3. La creacin de Isdefe

En el final de la dcada de los 70 se vivi un fuerte aumento de larelacin de nuestras Fuerzas Armadas con las de otros pases. Ello pusode manifiesto ciertas carencias y limitaciones, que era preciso solventarde cara a posibilitar su autntica integracin en foros internacionales. Seemprendi as un ambicioso proyecto de modernizacin de las FuerzasArmadas.

Dentro de esa nueva maquinaria que se iba concibiendo en esosaos como el futuro Ministerio de Defensa, con capacidades

1 3Introduccin

equivalentes a las de los pases aliados, se detectaron numerososengranajes nuevos que se hacan necesarios. Uno de ellos, destinadoa contribuir como un elemento ms a la modernizacin y capacitacintecnolgica de las Fuerzas Armadas, era una ingeniera propia dedefensa, del estilo de las existentes en otros pases tales como EstadosUnidos y Alemania. Como consecuencia de todo ello, Isdefe fue creadaen Septiembre de 1985, por acuerdo del Consejo de Ministros, paraapoyar en trabajos de ingeniera de sistemas y en consultora aorganismos de la Administracin, especialmente al Ministerio deDefensa y a las Fuerzas Armadas. Entre las misiones de Isdefedestacan el ayudar a la definicin tcnica de las necesidades quedeterminen operativamente los Estados Mayores; el apoyar en laelaboracin de las especificaciones tcnicas de los sistemas, el anlisisde las ofertas y el seguimiento de los programas; el colaborar en laordenada planificacin de las adquisiciones de Defensa; el disponerde un personal de alta cualificacin en tecnologas especficas; y elhacer extensivas esas capacidades al resto de la Administracin ensistemas relacionados con la seguridad nacional.

La propia concepcin de Isdefe como un engranaje ms de esagran maquinaria de relojera que deba ser el Ministerio de Defensapone de manifiesto la excelente visin sistmica de los relojerosque disearon la maquinaria, que ciertamente demostraron ser muchomenos ciegos que nuestro relojero genrico del cuadernillo depresentacin de esta serie de monografas.

1.4. Experiencia de Isdefe en ingeniera de sistemas

Isdefe ha acumulado, en estos primeros diez aos, ms de 1.6millones de horas de ingeniera colaborando en diferentes programas,en las reas de mando y control, apoyo logstico, telecomunicaciones,tecnologas de la informacin, navegacin area, investigacinoperativa, simulacin, seguridad, proteccin del medio ambiente, yformacin de personal, siempre bajo la perspectiva del enfoque


sistmico. Aproximadamente un 70% de esas horas han correspondidoa programas del sector defensa y el 30% restante al sector civil.

Si la cuarta monografa de esta serie, Dinmica de SistemasAplicada [4], ilustra a travs de varios ejemplos la aplicabilidad dela Dinmica de Sistemas (expuesta de forma conceptual en la terceramonografa) [5] tanto en el sector defensa como en el civil, estamonografa refleja aplicaciones concretas en la Administracinespaola y en la europea de algunos de los aspectos del procesodescrito en la primera monografa de la serie, Ingeniera deSistemas [6].

El objetivo de esta monografa es resumir la experienciaadquirida por Isdefe en el campo de la ingeniera de sistemas. Paraello se han seleccionado once de los principales programas en losque se ha participado, de tal forma que con ellos se cubran diferentesaspectos o disciplinas de la ingeniera de sistemas y se abarquen,adems, las diferentes fases del ciclo de vida de los sistemas. La Figura1.3 muestra los programas seleccionados para ilustrar la experienciaadquirida, indicndose adems el aspecto a resaltar de cada uno enla fase correspondiente del ciclo de vida.

1.5. Desarrollo de la monografa

Cada uno de los siguientes once captulos ilustra un aspectorelacionado con la ingeniera de sistemas, a travs de su desarrolloconcreto en uno de los programas seleccionados. En primer lugarse describe el objeto y naturaleza del programa, indicando la fasedel ciclo de vida en la que actualmente se encuentra. Seguidamentese indica la faceta a resaltar y su integracin en el proceso deingeniera de sistemas, especificando la fase en la que se materializla colaboracin de Isdefe en el programa. Finalmente se describenlas actividades realizadas en relacin con la faceta seleccionada.No se pretende describir en detalle los programas seleccionados,

1 5Introduccin


sino reflejar las actividades realizadas en ellos por Isdefe en relacincon aspectos concretos de la ingeniera de sistemas,salvaguardando siempre aquellos de naturaleza clasificada osensible. Algunos programas abarcan, en su desarrollo real, variasfases del ciclo de vida. Aqu slo se muestra alguna de ellas (paracada uno), a fin de dar cabida a diferentes mbitos y programas.

En el Eplogo se resumen las lecciones aprendidas, fruto de lascolaboraciones de Isdefe en los programas en los que ha participado.El proceso de ingeniera de sistemas descansa en modelosmatemticos y, como dijo Einstein, en la medida en la que los modelosmatemticos reflejan la realidad no son ciertos, y en la medida en laque son ciertos no reflejan la realidad. Los paradigmas o modelosempleados se mantienen en tanto en cuanto la experiencia prcticaacumulada en su utilizacin los confirma y refuerza; la deteccin dedeficiencias o limitaciones implica una modificacin de los modelos y,eventualmente, su evolucin a otros. Un modelo conceptual o tericocarece de valor si no est respaldado por la evidencia de la prctica.Como dice el refrn ingls, la prueba del pudding est en comrselo.

1 7Introduccin

1 9

2AEGIS:

Diseo conceptualdel futuro sistema

de gestin deltrnsito areo


2.1. Descripcin global del proyecto AEGIS

En los ltimos aos distintas organizaciones europeas einternacionales han desarrollado escenarios y programas para laimplantacin de un sistema mejorado de gestin del trnsito areo (AirTraffic Management, ATM). El futuro sistema deber ser capaz desatisfacer el aumento previsto en la demanda antes del ao 2010 (entreel 70 y el 133 por ciento del actual). Estos escenarios no sonhomogneos: contemplan distintas funciones y difieren en el marcotemporal que abarcan. Con el fin de aunar criterios y definir as uno ovarios escenarios con la capacidad de satisfacer las necesidades deATM en Europa en el siglo XXI, la Direccin General de Transporte dela Comisin de las Comunidades Europeas decidi patrocinar elproyecto AEGIS (Grupo Europeo ATM para la Mejora de Escenarios).El objetivo global de este proyecto fue la mejora y unificacin de losescenarios existentes en el campo de ATM, mediante la ampliacindel mbito de investigacin y las aportaciones de la variada experienciatcnica de un consorcio multidisciplinario.

Los miembros del consorcio AEGIS eran Arospatiale, BNREurope Ltd., Isdefe, National Technical University of Athens, QueenMary and Westfield College (University of London), Sextant Avionique,Sofravia y Syseca.

El proyecto se dividi en tres fases: evaluacin, mejora yconsolidacin, subdivididas, a su vez, en un total de nueve paquetes

2 1AEGIS: Diseo conceptual del futuro sistema de gestin del trnsito areo

de trabajo tcnicos y uno de gestin. En la fase de evaluacin, elconsorcio analiz y compar los escenarios y conceptos existentes,elabor una definicin del trmino escenario, estableci unametodologa para desarrollar escenarios y aplic esta metodologa paraobtener un escenario base. En la fase de mejora, se identificaron eintegraron en el escenario base una serie de mejoras organizativas,tcnicas y de entorno. Finalmente, en la fase de consolidacin, elconsorcio desarroll una metodologa para analizar los costes ybeneficios de escenarios para ATM y valid el escenario mejoradoaplicando esta metodologa. La Figura 2.1 presenta estas tres fasesde forma esquemtica.

Isdefe particip en el proyecto AEGIS como coordinador.Asimismo, fue responsable directo del estudio coste/beneficio que sellev a cabo y de la consolidacin final del escenario.

2.2. Relacin del proyecto con la ingeniera de sistemas

La totalidad del trabajo que se ha llevado a cabo en el proyectoAEGIS se puede enmarcar en la primera fase del ciclo de vida de unsistema. En concreto, el proyecto AEGIS es un ejemplo de la fase dediseo conceptual de la ingeniera de sistemas aplicada al campo dela gestin del trnsito areo. Basndose en las necesidades del cliente,se identificaron y analizaron los requisitos del futuro sistema ATM, sepropuso una solucin coherente para satisfacer estos requisitos y sedefinieron los pasos de transicin necesarios para lograr la solucinpropuesta.

2.3. Fase 1: evaluacin

Como primer paso de la fase de evaluacin, el consorcioidentific y analiz los escenarios y conceptos existentes en el campode ATM. Los escenarios y conceptos estudiados se clasificaron por su

2 3

nivel de descripcin, si eran generales o especficos, si proponan unsistema totalmente automatizado o un sistema que conservara laintervencin humana en el ciclo de toma de decisiones, y si tratabancuestiones organizativas o institucionales. Finalmente, se clasificaronpor su mbito funcional: si trataban principalmente la gestin deafluencia, la gestin del espacio areo, el control de trfico areo,comunicaciones/navegacin/vigilancia, la integracin aire/tierra, elpapel del hombre en el sistema y la interfaz hombre-mquina, la gestindel trnsito areo o los costes. Asimismo, se identificaron conceptosen cinco dominios: gestin de vuelo a bordo (Air Flight Management,AFM), ATM, comunicaciones, arquitectura del sistema y entorno.

Antes de proceder a desarrollar una metodologa para laelaboracin de escenarios, se defini el trmino escenario como "ladescripcin preceptiva del estado futuro de un sistema o subsistema,teniendo en cuenta las diversas restricciones y problemas que sepretenden resolver con la implantacin de conceptos existentes onuevos". Desde la perspectiva de AEGIS, un escenario debera ser unplanteamiento vivo de un sistema, que se realimente de todos losconocimientos y experiencias que se obtengan en el proceso deinvestigacin y desarrollo que forma parte de su ciclo de vida. Esteciclo de vida se muestra en la Figura 2.2.

Basndose en el ciclo de vida del sistema, el consorcio definiuna metodologa para elaborar escenarios, que se plasm en elsiguiente esquema o ndice:

1) Identificacin de las necesidades del cliente: consideracinde las tendencias de la poltica y desarrollo de un esquemainicial de soluciones;

2) Elaboracin de esquemas de soluciones: delimitacin delrea temtica sobre el que versar el escenario y desarrollode grupos de objetivos/principios/soluciones para iniciar laidentificacin de soluciones alternativas;

AEGIS: Diseo conceptual del futuro sistema de gestin del trnsito areo


3) Desarrollo de soluciones: exposicin en detalle de lassoluciones que propone el escenario;

4) Transicin: definicin de uno o varios caminos alternativospara llegar al estado futuro que se propone, partiendodel estado actual;

5) Mejoras previstas: identificacin de los efectos y beneficiosque se espera obtener con la implantacin del escenario; y

6) Conclusiones: resumen de los resultados del escenario yplanteamiento de propuestas para futuros trabajos.

Aplicando esta metodologa, el consorcio defini las necesidadesdel cliente, basndose en los requisitos de alto nivel contenidos en elanexo tcnico del contrato con la Comisin Europea y en las opinionesde las lneas areas (usuarios del sistema ATM) expresadas en el libro


blanco editado por la Asociacin de Lneas Areas Europeas.Depuradas por el consorcio, las necesidades identificadas se agruparonen los tres objetivos principales del escenario que se iba a desarrollar:

1) Mejora de los escenarios ATM existentes. Especficamente,se requera un escenario de transicin hasta el ao 2015,que contemplara mantener la intervencin humana en elciclo de toma de decisiones.

2) Estudio de las interacciones entre las lneas areas y lossistemas ATM (por ejemplo, cooperacin entre lossistemas embarcados y de tierra).

3) Identificacin de propuestas para aumentar la capacidad,seguridad y calidad de los servicios del sistema de gestindel trnsito areo.

Partiendo de estos objetivos generales, se definieron las seis reasgenerales en que se iba a centrar el futuro escenario: (1) la organizacinde ATM; (2) las alternativas para la gestin del espacio areo; (3) laestrategia de automatizacin; (4) los aspectos funcionales; (5) el repartode tareas entre los sistemas embarcados y de tierra, entre sectores yentre el hombre y la mquina; y (6) los aspectos de transicin. Estasreas se desglosaron en las siguientes subreas: filosofa del sistema,gestin del espacio areo, gestin de afluencia, comparticin de tareasentre aire y tierra, estrategia de automatizacin, reparto de tareas entre elhombre y la mquina, organizacin de la unidad de control, relacionesentre ATM y las lneas areas, relaciones entre ATM y los aeropuertos,relaciones entre ATM y el sistema militar, y comunicaciones/navegacin/vigilancia (Communications/Navigation/Surveillance, CNS). Para cadauna de estas subreas, se identificaron varios conceptos, clasificadosglobalmente como de carcter conceptual, organizativo o tcnico. Estosconceptos se utilizaron para definir, en cada subrea, los objetivos delfuturo escenario, los principios que lo guiaran y las soluciones propuestaspara lograr los objetivos cumpliendo con los principios establecidos.


A continuacin, los conceptos se dispusieron en una matriz paraidentificar su compatibilidad, incompatibilidad o independencia entres. El resultado de este ejercicio fue la identificacin de aquellosconceptos que podran definir el futuro escenario AEGIS:

1) Filosofa ATM: no determinista (la situacin actual), odeterminista.

2) Estructura de ATM: integrada o en niveles.

3) Estrategia de automatizacin: completamente automatizado,principalmente dependiente de la tecnologa o centrado enla intervencin humana.

4) Gestin del espacio areo: cielos abiertos, concepto derutas fijas aeronuticas o cielos semi-abiertos.

5) Organizacin del control de trfico areo: AFM ejercido entierra, control de trfico areo ejercido a bordo o redundanciaentre las partes de aire y tierra de ATM.

Se seleccionaron seis posibles combinaciones de estos conceptoscomo esquemas de soluciones, que fueron valorados utilizando una seriede criterios cualitativos. Esta valoracin dio como resultado un conjuntoconsolidado de escenarios (ver Figura 2.3). Uno de estos escenarios seeligi para ser desarrollado en la siguiente fase, el Escenario Genrico eIntegrado para ATM y Redes (GIANTS). Otro escenario, el Sistema deTrfico Areo Automatizado e Integrado (AIATS), se consider fuera delmbito del AEGIS, pero se propuso para un estudio futuro.

2.4. Fase 2: mejora

Los principales aspectos del escenario GIANTS que se desarrollarony mejoraron en la segunda fase del proyecto fueron el papel fundamental


de la intervencin humana en el sistema, su carcter no determinista y suestructura en seis niveles temporales decrecientes. Estos niveles, queserviran de filtros sucesivos para ajustar la capacidad del sistema a lademanda en cualquier momento dado, fueron los siguientes: gestin globaldel sistema, planificacin estratgica, planificacin preoperativa, operacinen tiempo real, redes de seguridad y anlisis posterior de datos.

En el desarrollo del escenario, se hicieron propuestas en cuatroreas. En la primera, cooperacin entre aire y tierra, el escenario propusotres conceptos: la redundancia entre los sistemas embarcados y los detierra, la aeronave autnoma y la cooperacin entre los sistemasembarcados y los de tierra. Asimismo, se propuso la convergencia de losmodelos de tierra y de aire como requisito previo para una cooperacineficaz entre aire y tierra.

En las reas segunda y tercera, AFM ejercido en tierra y controlde trnsito areo ejercido a bordo, respectivamente, el escenario defini


nuevas tareas para los operadores, basadas en una nueva forma decompartir responsabilidades y en nuevas herramientas, que se disearanbasndose en un anlisis detallado de las tareas que deben desempear.En particular, se crearon tres nuevos actores para el ATM en tierra: elgestor de rea, el planificador de rea y las unidades de control.

Finalmente, se propusieron tres fases de transicin: hasta el ao2000, del ao 2000 al 2005, y del ao 2005 al 2010. Se definieron losrequisitos para la transicin del sistema para cada una de estas fases.

2.5. Fase 3: consolidacin

En la tercera fase del proyecto se consolidaron los resultadosobtenidos en las primeras dos fases. Una vez definidos los requisitostcnicos y de transicin del escenario GIANTS, el consorcio dise unametodologa especializada para analizar los costes y beneficios decualquier inversin en el sistema ATM. La metodologa, una vezparticularizada para el anlisis del escenario GIANTS, consisti en dospasos: (1) la obtencin de los parmetros de eficacia del sistema,partiendo de los parmetros tcnicos, y (2) partiendo de los parmetrosde eficacia del sistema, la obtencin de los costes diferenciales deoperacin de las lneas areas que, por hiptesis, se consideraron losbeneficios del escenario.

El estudio concluy con un anlisis de sensibilidad. Este anlisisdio por resultado que los beneficios diferenciales esperados tras laimplantacin del escenario GIANTS eran de un orden de magnitud mayorque los costes diferenciales.

2.6. Valor aadido del proyecto

El escenario GIANTS que se ha propuesto en el proyecto AEGISdeber ser capaz de resolver la mayora de los problemas actuales de

2 9

la gestin del trnsito areo. Sin embargo, se requerir una validacinposterior de sus soluciones conceptuales, organizativas y tcnicas enfuturos estudios de investigacin y desarrollo, sobre todo de la nuevaestructura organizativa que se propone.

Como valor aadido, el proyecto AEGIS ha desarrollado dosmetodologas que se pueden aplicar en otros proyectos: unametodologa para elaborar escenarios y una metodologa especializa-da para el anlisis de los costes y beneficios de cualquier sistema degestin del trnsito areo.

2.7. Consideraciones finales

El proyecto AEGIS es un ejemplo de la primera fase del ciclo devida de un sistema: la identificacin o definicin de la necesidad.Habiendo determinado que la capacidad actual del sistema de gestinde trfico areo no ser capaz de hacer frente a la demanda en elsiglo XXI, se plantea la mejora del sistema para aumentar su capacidad.

Como primer paso en la definicin del futuro sistema, seestudiaron diversos escenarios ATM (descripciones del estado futurodel sistema de gestin de trnsito areo) para adecuarlos a lasnecesidades reales del cliente, identificando propuestas para aumentarla capacidad, seguridad y calidad de los servicios prestados por elsistema ATM. Estas propuestas, que debern ser validadas por otrosproyectos, podrn servir de base para la definicin de los requisitosoperativos del futuro sistema, en un siguiente paso hacia el diseo delsistema ATM del siglo XXI.

El planteamiento metdico y estructurado para determinar ydesarrollar las necesidades del cliente que se ha seguido en el proyectoAEGIS puede ayudar en la definicin ms precisa de los requisitosconceptuales de cualquier sistema.

AEGIS: Diseo conceptual del futuro sistema de gestin del trnsito areo

3 1

3Evaluacin de

desarrollosbasados en una

nueva tecnologa:demostrador

PlanBA


3.1. El programa PlanBA

PlanBA (Plan de accin nacional para la Investigacin yDesarrollo [I+D] en comunicaciones integradas de Banda Ancha) esun programa promovido y financiado parcialmente por la Administracinespaola. Su principal objetivo es disponer, a finales de 1995, de undemostrador experimental de banda ancha que tome como ncleo lared RECIBA desarrollada por Telefnica. PlanBA (1992-1995) es unaaccin coordinada con la industria nacional sobre actividades de I+Den banda ancha, en la que estn involucrados operadores, fabricantesde productos de telecomunicacin y centros pblicos de investigacin.En su organizacin, gestin y financiacin intervienen los organismosde la Administracin con responsabilidad en la promocin de latecnologa de telecomunicaciones.

El ncleo de la actividad PlanBA consiste en la integracin ypuesta en operacin de un demostrador de red experimental decomunicaciones en banda ancha integrado por los prototipos de loselementos desarrollados por los proyectos PlanBA: aplicaciones,terminales, adaptadores,... El demostrador utilizar el Modo deTransferencia Asncrono (MTA), una tecnologa de transmisin yconmutacin de paquetes de longitud fija (clulas) que proporciona unsoporte muy flexible para el transporte de la informacin.

Cada elemento individual del demostrador, o grupo de ellos, esdesarrollado por un proyecto. Cada proyecto es realizado por un

3 3

consorcio en el que participan empresas y organismos pblicos deinvestigacin (OPIs) que trabajan de forma conjunta durante todo elciclo de vida del proyecto.

La coordinacin se realiza a travs de la participacin de losorganismos gestores y financiadores en el Comit de Gestin PlanBA.Este Comit est soportado en sus actividades por la Oficina de Gestin(Oficina PlanBA). Se ha constituido un grupo de personas conexperiencia multidisciplinar relacionada con la gestin, la investigaciny el desarrollo de proyectos de ingeniera en comunicaciones de bandaancha. La Figura 3.1 representa esquemticamente las interaccionesentre los diferentes agentes involucrados.

Actualmente, PlanBA est en la fase final de su desarrollo,aunque este Captulo se centra en los aspectos de desarrollos queavalen la viabilidad de la nueva tecnologa MTA, desarrollos que seencuadran clsicamente dentro del diseo conceptual en la ingenierade sistemas. La evaluacin de desarrollos sobre una tecnologaconcreta determina el inters de dedicar recursos a esa tecnologa y,lo que es ms importante, permite cuantificar la cantidad de recursosnecesarios. Mediante este tipo de anlisis se pueden establecercalendarios y costes aproximados para la realizacin de prototiposbasados en la tecnologa en cuestin.

3.2. Evaluacin de desarrollos en PlanBA

La Administracin espaola, en base a la tecnologa emergentedel Modo de Transferencia Asncrono, que prometa ser la base de lasfuturas redes de comunicaciones de banda ancha, tom en 1988 lainiciativa de consultar a la industria nacional de telecomunicacionessobre la conveniencia de polarizar hacia el MTA las actividades de I+Den telecomunicaciones. El objetivo era permitir que se posicionaraadecuadamente la industria espaola ante los nuevos objetivos quese apuntaban.

Evaluacin de desarrollos basados en una nueva tecnologa: demostrador PlanBA

3 5

Se acord que la Direccin General de Telecomunicacionesrealizara un estudio de detalle sobre las posibles actuaciones que cabraabordar, con el objetivo de incorporarlo a la nueva versin del PlanNacional de Telecomunicaciones (1991-2002).

La realizacin del estudio convoc a la Administracin, la industriade telecomunicaciones, los operadores de red y los centros de estudioe investigacin. Con objeto de identificar las necesidades, analizar losrequisitos, seleccionar el enfoque y proceder a la definicin funcionaldel programa de actuacin, se crearon cuatro grupos de trabajo: (1)Servicios, (2) Situacin espaola, (3) Tecnologa y (4) Plan de Trabajo.

El modelo conceptual que se deriv de los estudios fue facilitar lacoordinacin e integracin de experiencias previas mediante la participacinconjunta de diferentes agentes en una serie de acciones de I+D encomunicaciones integradas de banda ancha. Acciones encaminadas acomplementar otras similares en el entorno europeo (ESPRIT, RACE, etc)que potenciaran la I+D en la industria y los centros de investigacin. stasdeban permitir la integracin de los resultados en un demostrador quepermitiera comprobar el interfuncionamiento de resultados a la vez quesirviera de demostracin para impulsar servicios y aplicaciones, as comode banco de pruebas para distintas tecnologas, elementos y equipos.

El trabajo se llev a cabo en tres etapas:

1) Identificacin de tecnologas relevantes en banda ancha;2) Identificacin de aplicaciones y usuarios; y3) Definicin del plan de trabajo para la consecucin del

demostrador.

3.2.1 Identificacin de tecnologas relevantes en banda ancha

Se realiz un estudio tomando como material de partida unadefinicin de actividades de I+D en comunicaciones de banda ancha.



En esta definicin participaron empresas y profesionales relevantesdel sector de las telecomunicaciones: operadores, fabricantes, institutosoficiales y universidades.

El estudio inclua una descripcin para cada rea segn elsiguiente esquema: (1) justificacin de la necesidad de la tecnologa,(2) subreas de la tecnologa, (3) objetivos y (4) estrategia.

En total, se identificaron ocho reas tecnolgicas: (1)Microelectrnica, (2) Optoelectrnica, (3) Software, (4) Algoritmos yProceso de Seal, (5) Tecnologa de Conmutacin, (6) Arquitectura deSistemas, (7) Tecnologas de Diseo Fsico y (8) Tecnologas de Usuario.

Estas reas incluan a su vez otras veintiocho subreas. As, enmicroelectrnica se contemplaban tecnologas bsicas y metodologas,en tecnologa de conmutacin se consideraban las subreas deconmutacin MTA y tcnicas de adaptacin e interfuncionamiento, etc.

3.2.2. Identificacin de aplicaciones y usuarios de banda ancha

En esta etapa, se realiz un estudio con los mismos participantesde la etapa anterior para establecer las pautas de cmo debanconsiderarse los escenarios de usuarios y aplicaciones, con objeto dellevar a cabo una eficiente implantacin de las comunicaciones debanda ancha.

Para identificar las potenciales aplicaciones y usuarios de lastecnologas de banda ancha se llevaron a cabo tres anlisisindependientes:

1) Tendencias y perspectivas europeas: en primer lugar seanaliz la disponibilidad previsible de infraestructuras decomunicaciones avanzadas en Europa. Tambin se estudiaron lasexpectativas de mercado y las estimaciones de la demanda de este

3 7

tipo de comunicaciones. Finalmente, se hizo una revisin de pilotoseuropeos de comunicaciones integradas de banda ancha.Principalmente RACE y ESPRIT.

2) Identificacin de las facilidades especficas aadidas por latecnologa de banda ancha. Se realiz un anlisis matricial de acuerdoa las variables siguientes: (1) estratificacin de usuarios, (2) funcionesde los usuarios y (3) aplicaciones genricas.

3) Anlisis de agentes: se identificaron a los particulares, a lasempresas y al sector pblico como los principales agentes.

A partir de los anlisis anteriores se determinaron las aplicacionesms oportunas, con el objetivo de orientar la toma de decisiones en elrea de aplicaciones de PlanBA y de contribuir al dimensionamientode los recursos. Para cada agente identificado se definieron lasaplicaciones siguientes:

1.- Agentes Empresarios: (1) instituciones de crdito y seguroy (2) turismo.

2.- Sector Pblico: (1) Sanidad y Seguridad Social y (2)educacin.

3.- Agentes Particulares: (1) teleeducacin, (2) teletrabajo, (3)telecompra y (4) ocio y entretenimiento.

3.2.3. Definicin del plan de trabajo para la consecucin deldemostrador

A partir del anlisis de las reas tecnolgicas ms relevantespara las comunicaciones integradas en banda ancha, los mdulosincorporados en otros pilotos europeos de los anlisis de demandade este tipo de tecnologas y las aplicaciones de mayor inters, segn



los expertos participantes en las reuniones de definicin, seidentificaron una serie de elementos a desarrollar en el demostrador(ver Figura 3.2).

Se procedi a la identificacin y cuantificacin de medios(recursos humanos, inversiones en equipamiento, etc.) de forma queintegrados y secuenciados debidamente en el tiempo permitieran larealizacin del demostrador para satisfacer las necesidades y losobjetivos estratgicos planteados en la definicin de las acciones. Apartir de las experiencias aportadas por los expertos se elabor unatabla de estimaciones para los recursos humanos (hombres * ao) ylas inversiones requeridas (Mpts.) por cada uno de los elementos deldemostrador (ver Tabla 3.1).

Se estim que era conveniente la existencia de un Proyecto deIntegracin para asegurar la funcionalidad coherente de la red ygarantizar la compatibilidad entre las actividades desarrolladas (verFigura 3.3).

Para el desarrollo de cada elemento se sugiri la formacin deconsorcios entre empresas y centros pblicos de investigacin conobjeto de que se desarrollara en lo posible un nico proyecto por cadauno de los elementos a desarrollar.

Finalmente, se previ una dotacin econmica (Fondo deIntegracin) para la inversin en posibles rplicas de prototipos noprevistas inicialmente o para aumentar la funcionalidad de ciertoselementos.

3.3. Evolucin del proyecto integrado PlanBA

Desde su inicio en 1992 hasta 1995 se incorporaron 16 proyectosque cubran los objetivos generales establecidos al inicio. En losproyectos aprobados intervienen: 22 empresas pertenecientes al sector

3 9Evaluacin de desarrollos basados en una nueva tecnologa: demostrador PlanBA

4 1

de las tecnologas de la informacin y las comunicaciones, 10 gruposinvestigadores de universidades y centros pblicos de investigacin y8 usuarios de aplicaciones (hospitales, cadenas hoteleras y organismosrelacionados con la educacin).

El proceso de evolucin posterior del programa se detalla en laFigura 3.4.

Los desarrollos PlanBA finalizan en diciembre de 1995. En elprimer trimestre de 1996 se esperan realizar demostraciones pblicasde los logros obtenidos por la industria y la universidad espaola en elmarco de este programa.


4 3

Especificacinde requisitos

en el programaMIDS

4


4.1. El sistema MIDS

MIDS ("Multifunctional Information Distribution System", SistemaMultifuncional de Distribucin de Informacin), es un sistema decomunicaciones, navegacin e identificacin (de aqu lamultifuncionalidad) que permite intercambiar voz y datos entre usuariosdistribuidos en una amplia zona geogrfica.

Los usuarios del MIDS son los aviones y helicpteros militares,buques de guerra y unidades terrestres. Las ventajas que aporta lautilizacin del MIDS en relacin con los sistemas actualmente existentesson bsicamente tres:

1. La seguridad de las comunicaciones, ya que es muy difcilinterceptar los mensajes transmitidos por el sistema MIDS.

2. La resistencia a las interferencias externas de radio, enambientes electromagnticamente muy densos, como sonlos que suelen encontrarse en las operaciones militares.

3. La interoperatividad entre usuarios muy diversos, de ejrcitos eincluso pases distintos, al aportar un alto grado de estandarizacinen la obtencin de las funciones suministradas por el sistema.

Tcnicamente el MIDS es un sistema muy complejo [11, 12],que funciona con un alto grado de automatizacin e incorpora

4 5Especificacin de requisitos en el programa MIDS

tecnologas muy avanzadas. Los equipos para el intercambio deinformacin a travs del MIDS se llaman terminales y el programamultinacional MIDS que aqu se comenta tiene por objeto el diseo,desarrollo y produccin masiva de un modelo nico de terminal MIDSvlido para todo tipo de usuarios, terrestres, navales y areos.

4.2. El programa MIDS

En la actualidad, el programa se encuentra en su fase de diseoy desarrollo. Las actividades de ingeniera de sistemas que secomentan en este Captulo se realizaron durante la fase deespecificacin de requisitos, previa a la de desarrollo.

En la Figura 4.1 puede verse un esquema de las partes queintervienen en el programa para desarrollar un terminal que cumplalas especificaciones del sistema MIDS. Existe un acuerdo entre losgobiernos de cinco naciones para la realizacin del citado programa.En cada una de estas naciones existe una Oficina Nacional dePrograma, que coordina todas las actividades nacionales einternacionales del programa y se ocupa del funcionamiento da a dadel mismo.

Por otra parte, se ha constituido un Comit Director del programa,que toma las decisiones de gestin del programa, y tiene delegadasciertas atribuciones en una Oficina Internacional de Programa (IPO).Tanto en la IPO como en el Comit Director estn representadas todaslas naciones participantes.

En la parte industrial, existe un acuerdo de cinco empresasprocedentes de las cinco naciones participantes. Dichas empresashan constituido un consorcio denominado MIDSCO del cual son a suvez socios y subcontratistas. El programa MIDS se realiza a travs deun contrato nico firmado por la IPO y MIDSCO, que actan pordelegacin de las distintas partes.


4.3. Actividades previas a la fase de desarrollo

A continuacin se comentan brevemente las actividades principalesdel programa durante la fase de especificacin de requisitos. La lista noes completa, ya que no figuran en ella, por ejemplo, los aspectos logsticos.Slo se pretende exponer unos cuantos ejemplos tpicos que sirvan parailustrar el proceso de la ingeniera de sistemas. Isdefe ha participado entodas las actividades descritas a lo largo de esta Seccin.

4.3.1. Preparacin de la peticin de oferta

La peticin de oferta incluye: clusulas contractuales;especificaciones tcnicas; definicin de trabajos / desglose de tareas; ylista de productos entregables.

La peticin de oferta constituye un extenso paquete dedocumentos que contiene toda la informacin detallada necesaria para


contratar los trabajos industriales del programa. La participacin delos grupos de ingeniera en estas actividades ha sido muy intensa enlas siguientes reas:

1) Clusulas contractuales

Se han discutido con otras naciones qu elementos de configuracinhardware, software y servicios eran exactamente objeto de contrato, y enqu condiciones. Los principales elementos contratados son:

a) Diseo del terminal MIDS.b) Diseo de un simulador de interfaz del MIDS.c) Prototipos de terminales.d) Simuladores.e) Apoyo logstico para todo lo anterior (repuestos, formacin,

mantenimiento, etc).

Para disponer de una versin definitiva de clusulascontractuales, se ha realizado una labor de anlisis de las clusulasde las FAR (Federal Acquisition Regulations, Regulaciones Federalesde Adquisicin), que deban incluirse en el contrato, dado que elcontrato se firma entre un representante de la Oficina Internacional dePrograma (IPO) y un representante del consorcio industrial MIDSCO.La legislacin aplicable es en consecuencia la estadounidense, por locual el contrato ha de ajustarse a las FARs, equivalentes a la Ley deContratos del Estado y Disposiciones Complementarias.

2) Especificaciones tcnicas

La redaccin de las especificaciones tcnicas que debe cumplirel terminal MIDS ha sido sin duda la actividad que ms recursos deingeniera ha consumido en toda la preparacin previa a la fase dedesarrollo. Para ello, se han formado varios grupos multinacionales, conrepresentantes tcnicos de todas las naciones participantes, y se hanido discutiendo todos los temas tcnicos que intervienen en el terminal.


3) Seleccin de la documentacin aplicable

Una parte importante de la actividad de los grupos tcnicosresponsables de la redaccin de especificaciones tcnicas es el anlisisy seleccin de la normativa aplicable para cada elemento hardware ysoftware del futuro terminal MIDS. Esto supone el estudio de un altonmero de estndares de diversa procedencia: Normas yespecificaciones militares de Estados Unidos (MIL-STD), STANAGspromulgados por la OTAN, normas IEEE, ISO, ANSI, etc.

Para cada documento que se incluye como referencia en lasespecificaciones, se ha de definir su aplicabilidad. Esto quiere decirque no basta con citar una norma aplicable, sino que, desde el momentoen que se incluye en el documento de especificaciones, se ha dedeterminar qu secciones de la misma se aplican y en qu medida.

Otro problema que se discuti en los grupos de trabajo, fue laarmonizacin de las distintas normativas existentes en relacin conun mismo tema. Cuando existen varias posibles normas aplicablespara definir un determinado requisito, y se estima que la toma dedecisiones no es inmediata, se forma un subgrupo de trabajo constituidopor expertos en el tema de que se trate, al que se asigna laresponsabilidad de analizar las distintas normas existentes y proponeruna decisin final debidamente razonada y documentada. Un tematpico que ha exigido varias actuaciones de este tipo es el de lacompatibilidad electromagntica (Electromagnetic Compatibility, EMC).

4) Metodologa de trabajo

Para preparar el documento de especificaciones tcnicas, seha seguido un procedimiento iterativo de reuniones de trabajomultinacionales, perodos de estudio en las distintas naciones paraasimilar las propuestas presentadas en las reuniones, y nuevasreuniones para incorporar nuevos cambios y discutir su impacto enlos sucesivos borradores de trabajo.


De esta forma se ha ido consolidando un documento cuya versindefinitiva es el documento de especificaciones tcnicas del terminalMIDS, cuyo nombre es System Segment Specification (SSS) y queestablece cul ha de ser el funcionamiento global del terminal y losrequisitos a los que deber ajustarse su cualificacin completa.

La organizacin general del documento de especificaciones seajust a lo establecido en la norma DI-CMAN-80008A: Data ItemDescription/System Segment Specification, que contiene directrices parala definicin de especificaciones tcnicas. El documento SSS contieneen primer lugar el alcance e identificacin de la especificacin. Acontinuacin se listan los documentos aplicables, tanto generados porel gobierno como de otras procedencias. Seguidamente se especificanlos requisitos de prestaciones del terminal MIDS, sus caractersticasfsicas y los estndares mnimos que ha de satisfacer su diseo yconstruccin. Esta seccin de requisitos es la ms voluminosa de laSSS y la que ms recursos exige en su preparacin. A continuacin seincluye una seccin sobre requisitos en materia de garanta de calidad,otra seccin sobre preparacin para entrega de terminales a los usuarios,y una ltima seccin con informacin complementaria para aclarardeterminados aspectos de las secciones anteriores.

Dado que el terminal MIDS ha de servir para una amplia variedadde plataformas, se revel prcticamente imposible reunir en un nicodocumento comn todos los requisitos exigibles a las distintasplataformas usuarias. Por ello, se recurri, a aadir al final deldocumento SSS una serie de anexos, uno por cada plataforma usuariadel MIDS, en los que se contemplaban los requisitos exclusivos decada plataforma. Durante todo el trabajo de preparacin de la SSS, sepuso el mayor inters en que dichos anexos contuvieran el mnimo derequisitos exclusivos, de forma que la mayora de los requisitos de lasplataformas estuviera ya contemplada en el cuerpo principal comnde la SSS. Se adopt esta filosofa para obtener un diseo comn, yaque esta comunalidad es precisamente un objetivo bsico delprograma.


Las principales categoras de elementos objeto de especificacindurante esta actividad fueron las siguientes: proceso de seal MIDS;estructura de mensajes/proceso de mensajes; esquemas de modulaciny demodulacin; interfaces externas del terminal; caractersticas fsicas;fiabilidad, mantenibilidad y prueba incorporada (Built-In Test, BIT);condiciones ambientales; alimentacin; logstica/adiestramiento/personal; y verificacin.

De esta forma se ha ido consolidando un borrador, cuyaversin definitiva es la Especificacin de Segmentos del Sistema.Una vez finalizado el documento, es posible realizar cambiosformales en el mismo, siempre que se respeten los procedimientosestablecidos de control de configuracin y se acepten por todas lasnaciones las consecuencias tcnicas, econmicas y operativas delos cambios introducidos. Esta actividad de refinamiento deldocumento contina an en la actualidad, si bien con una reducidaaportacin de recursos.

5) Verificacin de requisitos/matriz de verificacin

En la seccin de la Especificacin de Segmentos del Sistemadedicada a la garanta de calidad, se incluyeron los requisitosnecesarios para la verificacin del diseo y comportamiento delhardware y el software del terminal MIDS. Las distintas verificacionescontempladas en la SSS se clasificaron en cuatro grupos:

Verificaciones de ingeniera, para detectar y corregir a tiempolas deficiencias del diseo. Estas pruebas se realizan en paralelo conel trabajo de desarrollo y en general no van asociadas a un requisitoformal de planes y procedimientos de verificacin debidamenteaprobados.

Verificaciones de alistamiento para la integracin, paragarantizar que el desarrollo del terminal MIDS ha progresado losuficiente como para poder abordar los trabajos de integracin en la


plataforma anfitriona y comenzar las pruebas de campo. Estaspruebas son las primeras que se realizan a nivel de terminal MIDScompleto.

Verificaciones de cualificacin, para demostrar que un diseomaduro satisface todos los requisitos especificados. Estas pruebasdeben realizarse utilizando planes y procedimientos preparados porMIDSCO y aprobadas por las naciones. Dichos planes contemplan lassiguientes categoras de pruebas: funcionalidad; software; ambientales;compatibilidad e interferencia electromagnticas; fiabilidad ymantenibilidad; calidad de la voz/tasa de errores; alimentacin/pruebastrmicas; diseo estructural; e interoperatividad.

Verificaciones de aceptacin, para comprobar que todo elementoentregado por MIDSCO est en buen estado. Estas pruebas se aplicantanto a los distintos mdulos que configuran el terminal MIDS, como alpropio terminal completo. Tambin en este tipo de pruebas se exigi laadopcin de planes y procedimientos aprobados por las naciones.

En cuanto a los mtodos de verificacin, se identificaron loscinco siguientes, por orden creciente de complejidad y profundidad:inspeccin, anlisis, certificacin, demostracin y prueba.

En base a todos los elementos anteriores, se construy unamatriz de verificacin, en la que se identificaban todos los requisitosespecificados para el terminal MIDS, y el mtodo de verificacin autilizar en las pruebas formales (cualificacin y aceptacin).

6) Definicin de trabajos / desglose de tareas

Adems de definir las caractersticas tcnicas que ha de tenerel producto del programa (el terminal MIDS), se discutierondetalladamente las actividades que se espera realice el contratistaprincipal o cualquiera de sus subcontratistas de primer nivel (lasempresas nacionales que participan en el programa).


Esta definicin de tareas se especifica en el Statement OfWork (SOW) que es la Definicin deTrabajos, donde se explicantodas las tareas a realizar, se indican las normas que ha de cumplirel contratista en la realizacin de dichas tareas y se asocia cadatarea especificada con el contenido de las clusulas contractualesy, en algunos casos, con productos entregables, al objeto de poderrealizar posteriormente el seguimiento de dichas tareas. Tambinen el caso del SOW se ha especificado la aplicabilidad y el alcancede los estndares incluidos.

Estrechamente asociada con el SOW est el desglose de tareasdel programa completo, o Work Breakdown Structure (WBS) quepermite asociar las tareas realizadas con los costes del programa. Eldesglose de tareas es una descomposicin en rbol de todo elprograma, que puede analizarse a distintos niveles de agregacin,desde el programa completo, hasta las actividades ms elementales.

7) Lista de productos entregables

Todos los productos entregables estn descritos en una listade documentos denominados CDRLs (pronunciado sidrals). Elsignificado de este acrnimo en ingls es Contractor DataRequirement List, es decir, lista de requisitos que han de cumplirlos datos entregados por el contratista. Se trata de especificacionesparticulares que ha de cumplir cada documento o productoentregable, con indicacin asimismo de lugar de entrega, plazo deentrega, lista de distribucin, etc.

La informacin asociada con cada entregable del CDRL vacomplementada con el correspondiente documento DID, Data ItemDescription. El DID es generalmente un documento ya existente en laliteratura tcnica. Por ejemplo, existen DIDs para informes de reunin,para documentos de interfaz, para planos mecnicos, etc. En los casosen que no se dispone de un DID para una necesidad especfica, seredacta uno nuevo para cubrir dicha necesidad, y se incorpora en el


paquete de documentacin contractual, asociado con uno o msdocumentos del CDRL.

4.3.2. Reduccin de prestaciones tcnicas

Cuando las naciones participantes dispusieron de una ofertaformal de MIDSCO, conforme con el paquete contractual que se habaemitido, los precios ofertados se consideraron demasiado elevados.Al margen de una negociacin del precio, discutiendo uno tras otrotodos los elementos que figuran en el contrato, las naciones acordaronreducir ligeramente algunas de las prestaciones tcnicas, siempre queel impacto resultante sobre la operatividad del terminal MIDS fuesetolerable.

Para realizar esta labor de reduccin de prestaciones tcnicas,fue preciso revisar completamente las especificaciones tcnicas,analizando en qu medida se podan realizar cambios en los requisitoscontemplados en dicho documento. Este trabajo se realiz en dos fases,y se ha prolongado aproximadamente durante un ao. El mtodo detrabajo a seguir ha sido anlogo al de redaccin de especificacionestcnicas. Las naciones presentaban sus propuestas de reduccin, seformaba una propuesta consolidada y peridicamente se reunangrupos de trabajo especializados, con asistencia de personal tcnicoy de costes, y se analizaban las propuestas.

Posteriormente las propuestas se presentaban a la OficinaInternacional del Programa quien, tras una nueva labor de filtrado laselevaba al Comit Director para su aprobacin formal o devolucin.

4.3.3. Negociacin del precio

La totalidad del contrato del MIDS supone aproximadamente1.300 paquetes de trabajo bien definidos que han sido adecuadamente


descritos y valorados por MIDSCO en su oferta, y que el rgano decontratacin (la Oficina Internacional del Programa), ha tenido queanalizar, discutir y aceptar o rechazar.

La negociacin de todos estos paquetes se ha distribuido entrevarios equipos especializados, formados por personal de la IPO ypersonal de MIDSCO y de las cinco empresas subcontratistas: GEC,THOMSON-CSF, ITALTEL, SIEMENS y ENOSA.

4.3.4. Establecimiento de la lnea base

Una vez aceptada la reduccin de prestaciones, negociado losprecios de todos los paquetes de trabajo y en consecuencia del contratoglobal, aceptadas las cifras de beneficio y bonificaciones openalizaciones, etc, se ha procedido al establecimiento de la lneabase.

Esto significa que, dada la complejidad de las tareas a realizar,los mltiples cambios introducidos, y las discusiones relacionadas conel reparto de tareas y costes entre empresas nacionales, es precisorealizar una revisin completa de la configuracin resultante delcontrato. Este proceso de revisin de lnea base est finalizando en laactualidad.

4.3.5. Seguimiento industrial

Una vez comenzado el programa, es preciso llevar unseguimiento cercano de todas y cada una de las actividadesindustriales que se realizan en el mismo. Dada la gran cantidad detareas a realizar, de documentos entregables y, en su momento, depruebas e informes de pruebas, el seguimiento industrial es bsicopara aprovechar al mximo la participacin de las naciones en elprograma.

5 5

Dentro de las actividades del seguimiento industrial, losprincipales hitos en este programa son los siguientes:

a) Revisin preliminar del diseo.b) Revisin crtica del diseo.c) Ensayo preliminar de cualificacin.d) Auditora de cualificacin formal.

4.3.6. Seguimiento de costes

El contrato del MIDS es del tipo de costes incurridos, en el que seresarce al contratista de todos sus costes, y se le paga adems unbeneficio que ha sido objeto de negociacin. Por eso es del mximointers para el cliente (las naciones participantes) realizar un seguimientode costes, al objeto de ir analizando el progreso del programa. En estecontexto resulta bsico el concepto de valor ganado, que va ms allde una mera cuenta del gasto producido. El valor ganado es una medidadel trabajo realmente realizado por el contratista en un perododeterminado, e indica a un cierto nivel, lo que realmente se obtienecomo contraprestacin del dinero que se ha gastado en dicho perodo.En el programa MIDS el valor ganado se mide con periodicidad mensual.Para ello los contratistas han de presentar unos informes de seguimientode costes que permiten calcular, al nivel de agregacin del desglose detareas que se desee, el valor ganado terico (el establecido en la lneabase del contrato), el valor ganado real, y las desviaciones producidas,tanto en costes como en plazos de ejecucin. Una vez conocidas lasdesviaciones producidas, se estudia la posibilidad de adoptar o noacciones correctoras.

4.3.7. Gestin del espectro radioelctrico

Dado que el MIDS es un sistema de transmisin por radio, en labanda de UHF, su utilizacin real requiere una autorizacin

Especificacin de requisitos en el programa MIDS


administrativa para la utilizacin del espectro radioelctrico. La bandade frecuencias en que funciona el sistema MIDS es utilizada tambinpor otros sistemas aeronuticos, lo cual obliga a coordinar lastransmisiones 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 tcnicos para determinar en qu condicio-nes se podran realizar las transmisiones, por ejemplo, fijando unasdistancias mnimas entre emisores, zonas de exclusin, reduciendo ladensidad de pulsos, etc. En todos los casos, el MIDS acta como usua-rio secundario de la banda, lo cual significa, segn el Reglamento deRadiocomunicaciones que, en caso de interferencias, los dems sis-temas tendrn prioridad sobre el MIDS.

Todos estos trabajos, de alto contenido tcnico, se desarrollandentro de otro grupo, separado de la actividad industrial de desarrollodel terminal MIDS. El grupo de Gestin de Espectros realizasimulaciones de todos los equipos que operan en la misma banda,as como pruebas de laboratorio y de campo con equipos reales,determinando las condiciones tcnicas y operativas mnimas quedeben cumplir los equipos para operar en la misma banda defrecuencias. La Especificacin de Segmentos del Sistema incluyevarios apartados para definir protecciones especficas contrainterferencias a otros servicios, de forma que cesen las transmisionesMIDS en caso de que se produzcan dichas interferencias por encimade un determinado nivel.


El proceso de definicin de las especificaciones tcnicasdel terminal MIDS fue largo y laborioso, a veces muytedioso, 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 especificacin

5 7

final, se dispone de una alta granularidad en la posterior verificacinde requisitos, y por aadidura, la fase de pruebas ha quedadopreconfigurada desde una fase muy temprana del programa.

En cuanto a la actuacin de Isdefe como parte de larepresentacin espaola, aunque el liderazgo de los grupos tcnicosde especificacin estuvo ostentado por otro pas (EEUU), laparticipacin directa en las discusiones ha permitido acumular unaamplia base metodolgica y tcnica de conocimientos a los que no sepuede acceder por otras vas. En otras palabras, gran parte de loaprendido como consecuencia de la participacin en la definicin deespecificaciones del MIDS es consecuencia del trabajo diario de unosequipos punteros dentro de su sector.

Especificacin de requisitos en el programa MIDS

5 9

Anlisis de riesgosdurante la evaluacin

de ofertas en elprograma SANTIAGO

5


5.1. El programa SANTIAGO

El objeto principal del programa SANTIAGO es la captacin deemisiones electromagnticas y de imgenes en las zonas definidascomo de inters estratgico para la seguridad nacional. El sistemaobtenido deber complementar los medios especficos ya existentes anivel estratgico, con el fin de: apoyar a los centros de fusin y anlisisde datos de guerra electrnica; servir de sensor y alerta al sistema demando y control militar; y cooperar con otros sistemas de mando ycontrol.

Para cumplir este objetivo, es necesario el establecimiento deuna red de sensores mviles, semimviles y fijos que, disponiendo decapacidades de inteligencia de comunicaciones, inteligencia electrnicae inteligencia ptica, proporcionen una cobertura ptima del espacioestratgico de inters nacional.

El sistema SANTIAGO, por su volumen y complejidad, est dividoen diversos subsistemas. Estos se han abordado secuencialmente enel tiempo, siendo el ltimo de ellos el de integracin global. Algunosde estos subsistemas se encuentran en su fase ms temprana, laespecificacin de requisitos (estudios de viabilidad), otros en la fasede diseo y desarrollo y otros en la fase final de construccin (pruebastipo 3, [6]).

6 1Anlisis de riesgos durante la evaluacin de ofertas en el programa SANTIAGO

5.2. Anlisis de riesgos

En este Captulo se describe la metodologa empleada durantelos dos ltimos aos en el programa SANTIAGO, para efectuar elanlisis de riesgos durante el proceso de evaluacin de las ofertaspresentadas para los diferentes subsistemas. Este anlisis abarca losprocesos de identificacin y valoracin de los riesgos, sin entrar en eltratamiento de la gestin y reduccin de los mismos. Dentro de esteesquema el anlisis de riesgos ha servido como un elemento ms deapoyo a la toma de decisin.

Esto supone que dentro de este Captulo nos ceiremos,dentro del proceso general de ingeniera de sistemas, a la fase deevaluacin de ofertas situada en la lnea divisoria entre el diseoconceptual y el diseo preliminar del subsistema. Debe quedar claro,sin embargo, que el anlisis de riesgos es un proceso iterativo quese extiende ms all de esta fase del ciclo de vida, abarcando desdeel estudio de viabilidad hasta la puesta en funcionamiento delsistema.

Dentro del programa SANTIAGO se sigue la metodologapara adquisicin de sistemas de armas Phased ArmamentsProgramming System (PAPS) de la OTAN. Esta metodologaimpone la realizacin previa de estudios de viabilidad y definicinde los sistemas. En los estudios de viabilidad se realiza un anlisisde los riesgos tecnolgicos asociados a los mismos que,lgicamente, es utilizado como punto de referencia fundamentalen el momento de definir la solucin final propuesta. La propiaredaccin del Pliego de Bases es otro de los elementos crticosen el proceso de anlisis y gestin del riesgo. Desde un punto devista conceptual todo el Pliego de Bases tiene por objetoespecificar suficientemente, tanto el sistema como los trabajos quedeben realizarse para su consecucin, de manera que se minimiceel riesgo de que el sistema final no satisfaga la necesidad operativaque origin su desarrollo.


5.3. La metodologa utilizada

5.3.1. Objetivos

Cuando se comenz a disear la metodologa que debaemplearse para efectuar el anlisis de riesgos dentro del procesogeneral de evaluacin de ofertas, se establecieron tres objetivosprioritarios, en orden de importancia:

1) Centrarse en el estudio de las posibles desviaciones entrelo ofertado y el producto final que pudiera conseguirse, yno en las desviaciones existentes entre lo ofertado y loespecificado en el Pliego de Bases. Estas ltimasdesviaciones son el objeto de la valoracin de las ofertas,no de su anlisis de riesgo. El proceso de valoracin deofertas se trata especficamente en el captulo dedicado alprograma SIMCA de esta monografa.

2) Permitir la comparacin directa de los resultados conseguidospara las distintas alternativas (ofertas). La necesidad de lacomparacin directa se deriva de la utilizacin del anlisisde riesgos como soporte a una toma de decisin.

3) Facilitar la incorporacin a la metodologa de lo aprendidoen cada aplicacin de la misma, puesto que se pensaba ensu utilizacin reiterada.

La metodologa diseada finalmente, que aparece resumida enla Figura 5.1, se descompone en cuatro grandes fases: (A) identificacinde riesgos; (B) evaluacin del impacto que la aparicin de cada unode los riesgos identificados tendra en el desarrollo del programa; (C)cuantificacin de la probabilidad de aparicin de cada uno de losriesgos; y (D) integracin de los resultados. Esta metodologa se utilizpor primera vez durante la evaluacin de ofertas de uno de lossubsistemas del segmento terrestre.


5.3.2. Identificacin

La identificacin de riesgos es el primer paso de la metodologa;consisti en enumerar las posibles desviaciones que podan producirseen el subsistema respecto a lo ofertado. Para afrontar el requisitorelativo a la necesidad de la comparacin directa del riesgo de lasdiferentes ofertas, se identificaron los riesgos asociados al pliego, esdecir, se gener un diccionario de riesgos asociados a l. Esta laborse realiz durante el proceso de preparacin de la evaluacin, previaa la recepcin de las ofertas.

La generacin de este diccionario de riesgos se efectumediante una descomposicin descendente. El pl iego sedescompuso en grandes reas de r iesgo. Aunque no esimprescindible, desde que esta metodologa se est aplicandodentro del programa SANTIAGO, las reas de riesgo han coincididocon las consideradas para la evaluacin: tcnica, gestin, industrial


y econmica. Estas reas tratan con los riesgos asociados aldesarrollo del sistema en los aspectos de prestaciones tcnicas,calendarios, retorno industrial y costes. Cada una de estas reasse descompuso, a su vez, en bloques de riesgo, agrupacioneslgicas y estructuradas de informacin bajo la ptica de cada unade las reas. As, por ejemplo, el rea tcnica se descompuso enlos siguientes bloques:

a) Funciones: agrupamiento de riesgos asociados a lasfunciones que debe verificar el sistema.

b) Operatividad: agrupamiento de riesgos asociados a losmodos de operacin y recursos operativos que debeproporcionar el sistema.

c) Desarrollo software: agrupamiento de riesgos asociados ala metodologa y normativa de desarrollo.

d) Instalacin: agrupamiento de riesgos asociados a latransicin o instalacin del nuevo sistema.

e) Apoyo Logstico: agrupamiento de riesgos asociados a lafiabilidad, mantenibilidad, abastecimiento y formacin.

El ultimo paso en el proceso de identificacin fue ladescomposicin de cada uno de estos bloques en elementos de riesgo.Un elemento de riesgo se defini como una posible desviacin respectode lo ofertado. Sin embargo, como resultado de la aplicacin prcticade esta metodologa, se detect la necesidad de incluir tambin comoelemento de riesgo la falta de una definicin detallada de lo ofertado,ya que efectivamente la falta de definicin de la oferta introduca unevidente grado de incertidumbre sobre el resultado final a obtener.Con objeto de facilitar la cuantificacin de los elementos de riesgo,para cada una de las ofertas, stos iban acompaados por unadescripcin de lo que deba cuantificarse.


Aunque la identif icacin de riesgos se llev a cabofundamentalmente durante el proceso de preparacin de laevaluacin, tras la recepcin de las distintas ofertas se detectaronnuevos elementos de riesgo, que fueron incorporados al diccionarioinicial.

5.3.3. Evaluacin del impacto

El segundo paso consisti en la evaluacin del impacto que laaparicin de cada uno de los elementos de riesgo, identificados en elproceso anterior, podra tener para el desarrollo del subsistema. Elobjetivo fundamental de esta evaluacin del impacto fue estimar elefecto que cada una de las posibles desviaciones detectadas causaraen el subsistema final a obtener. Esta tarea se realiz antes de larecepcin de las ofertas y simultneamente a la identificacin de losriesgos.

Con objeto de facilitar el proceso, la evaluacin se efectusiguiendo la misma descomposicin descendente que se generaba enla identificacin de los riesgos. Para ello se estableci una importanciao peso relativo a cada una de las reas de riesgo identificadas.Posteriormente se asign un peso, dentro de cada una de las reas, alos bloques de riesgo que la constituan. Por ltimo se asignaron pesosa los elementos de riesgo identificados dentro de cada uno de losbloques.

Estos pesos fueron normalizados de modo que la suma de lospesos correspondientes a todas la reas de riesgo fuera igual a launidad. Esta normalizacin se aplic igualmente para todos lo bloquesde cada una de la reas y para todos los elementos de cada uno delos bloques. De este modo el impacto final, sobre el programa, decada uno de los elementos de riesgo identificados, se pudo obtenerefectuando el producto de los pesos del propio elemento, del bloquede riesgo al que perteneca y del rea que contena dicho bloque.


Desde el momento de la propia concepcin de la metodologadescrita se detect que la evaluacin del impacto no poda sernicamente el resultado de un proceso tcnico. La evaluacin del impactodeba estar condicionada por las prioridades de programa evaluado ypor la propia sensibilidad del decisor, responsable final de la adjudicacin,es decir, por su funcin de utilidad. Para ello, la asignacin de pesosanteriormente descrita se realiz, al menos en los niveles superiores dela estructura jerrquica, siguiendo los criterios del Jefe de Programa.

5.3.4. Cuantificacin de la probabilidad

Una vez recibidas las ofertas se procedi a la cuantificacin dela probabilidad de los elementos de riesgo para cada una de lasofertas. Debe destacarse que, con la metodologa descrita, no sepretendi en absoluto establecer una verdadera probabilidad, es decir,un conjunto de valores que cumplan los axiomas de probabilidad, sinonicamente cuantificar un ndice, para cada una de las ofertas, delgrado de ocurrencia de los elementos de riesgo identificados. Estacuantificacin para las distintas ofertas se tradujo, de forma prctica,en la asignacin de un valor, entre muy alto (9) y muy bajo (1), delgrado de ocurrencia de cada uno de los elementos de riesgo.

Este tipo de asignacin, aunque se efecto de la forma ms objetivaposible, carece de las ventajas asociadas al formalismo matemtico. Lacuantificacin del grado de ocurrencia por mtodos matemticamenteformales no fue realizada por dos causas fundamentales:

1) Estimar estas probabilidades de modo estadstico resultimposible debido a la ausencia de un espacio muestralnacional sobre el que extraer datos.

2) La estimacin de una probabilidad, en el sentido axiomticodel trmino, mediante tcnicas como la de Churchman-Ackoff, Delphi o similares, hubiera requerido un esfuerzo


muy significativo en trminos de horas-hombre. Comoresultado de este esfuerzo se obtendran nicamente lasventajas asociadas al puro formalismo matemtico, pero secomplicara notablemente la metodologa sin aportar unincremento de la objetividad.

El mecanismo de asignacin adoptado supuso, desde el puntode vista prctico, algunas ventajas importantes: sencillez, facilidad demodificacin, comprensin por parte del decisor y adecuacin a lapercepcin subjetiva del evaluador. Para un mejor aprovechamientola cuantificacin numrica se acompa de unos comentariosjustificativos de la misma, los cuales incluan la identificacin de lospuntos o prrafos de la oferta en los que se haba detectado la posibleaparicin del elemento de riesgo.

Merece destacarse que, mientras la identificacin y la evaluacindel impacto de los riesgos se realizaron en el proceso de preparacinde la evaluacin, la cuantificacin de los mismos se efectuespecficamente para cada una de las ofertas durante el proceso deevaluacin propiamente dicho. La Figura 5.2 muestra la relacin entreel anlisis de riesgos y el procedimiento general de evaluacin deofertas. Adems, y a diferencia de los procesos anteriores que seajustan a una descomposicin descendente, la cuantificacin de riesgosse realiz nicamente para el nivel inferior de dicha descomposicin.

5.3.5. Integracin

Finalmente se procedi a la integracin de los resultadosobtenidos mediante el anlisis de riesgo de las distintas ofertas. Dichaintegracin se llev a cabo recorriendo, desde los niveles inferioreshacia los superiores, la jerarqua generada para la identificacin deriesgos. Esta operacin permiti asignar un valor numrico al nivel deriesgo asociado a cada una de las ofertas, as como a las reas ybloques de riesgo en que se descomponen.

6 9

El nivel de riesgo asociado a un bloque, para una determinadaoferta, se construy sumando, para todos elementos de riesgo en quese descompona, el producto de su probabilidad, o grado de ocurrencia,por su impacto, o peso ponderado, dentro del bloque. De forma anlogase obtuvo el nivel de riesgo para cada una de las reas y para elglobal de las diferentes ofertas, consiguindose un valor del nivel deriesgo, para las diferentes ofertas, que poda variar tericamente entre:Cero (grado de ocurrencia nula de cualquier factor de riesgo quepudiera tener algn impacto sobre el desarrollo del programa) y Diez(probabilidad casi segura, o grado de ocurrencia evidente, defactores de riesgo que impediran el desarrollo esperado del programa).

En la prctica los resultados variaron entre 3,9 y 5,6. Merecedestacarse que, en las primeras aplicaciones de la metodologa, seha observado una cierta aversin de los evaluadores a asignarprobabilidades muy altas o muy bajas a la aparicin de los elementosde riesgo.

Los resultados de esta integracin, adems de en un formatotabular numrico y comentado, se ofrecieron al decisor en forma degrficos comparados para las distintas ofertas. Estos grficospresentaban tanto el perfil como la contribucin al riesgo de cada unade las ofertas. Los grficos de perfil de riesgo permitan visualizar, porejemplo, los niveles de riesgo de las diferentes reas obtenidos paracada una de las ofertas evaluadas. Los grficos de contribucin alriesgo presentan la misma informacin, pero ponderada por el impactoo peso relativo de cada una de las reas. La inclusin de este tipo degrficos result una ayuda valiosa para detectar en qu reas o bloquesla presencia de altos niveles de riesgo era especialmente indeseable.

5.3.6. Automatizacin del proceso

Toda la metodologa descrita en este captulo se implement enuna herramienta informtica, EVALOFER, que integra los cuatro pasos

Anlisis de riesgos durante la evaluacin de ofertas en el programa SANTIAGO


descritos para el anlisis de riesgo dentro del proceso global de laevaluacin de ofertas. Esta herramienta, aunque conceptualmentesencilla, ha tenido que ser desarrollada especficamente para tal fin.La utilizacin de EVALOFER, junto con la aplicacin de unametodologa normalizada, que especifica procesos y asignaresponsabilidades dentro del programa SANTIAGO, ha permitido tantola automatizacin relativa del proceso como la obtencin de resultadosobjetivos y fcilmente manejables. La Figura 5.3 muestra una pantallade la mencionada herramienta informtica correspondiente a laintegracin de resultados.

El anlisis de riesgos debe contemplarse como una de las reasfundamentales dentro de la ingeniera de sistemas con un influenciadirecta en el apoyo a la toma de decisiones. Este tipo de anlisis esuna labor recurrente que debe efectuarse tanto durante la fase deseleccin de alternativas como durante el seguimiento de losprogramas. Todo ello con el doble propsito de tratar de cuantificar,

7 1

a priori, los riesgos asociados a las distintas alternativas y apoyar lagestin de riesgos encaminada a su minimizacin.


La frecuencia con que, durante el desarrollo de un programa, sepresentan desajustes entre los costes, plazos y prestaciones tcnicasprevistas y las finalmente alcanzadas deben hacernos reflexionar sobrela importancia que debe concederse al anlisis de riesgos desde lasfases ms tempranas del desarrollo de un programa.

La dificultad principal con que tropieza el anlisis de riesgosdurante las fases iniciales del desarrollo de un sistema es la escasezde informacin y definicin. Esta escasez impide en muchasocasiones la cuantificacin formal del riesgo, conduciendo a unentorno de decisin de casi incertidumbre. La forma ms eficaz desuperar estas dificultades es utilizar la experiencia acumulada enproyectos anteriores, articulando un procedimiento que facilite estareutilizacin.

Estamos seguros que la metodologa aqu descrita esperfeccionable, de hecho se mejora con cada aplicacin de la misma.Pese a ello no pueden dejar de destacarse algunos logros que, talvez por la simple sistematizacin, y pese a los diseadores yoperadores de la metodologa, se han hecho patentes con eltranscurrir del tiempo:

1) El empleo de esta metodologa resalta aquellos aspectosde cada una de las ofertas que pueden constituir elementosde riesgo. La enfatizacin de estos aspectos permite, almenos, la peticin de una clarificacin sobre los mismos.En muchos casos es posible la realizacin de unanegociacin especfica, sobre los puntos crticos, previa ala adjudicacin.

Anlisis de riesgos durante la evaluacin de ofertas en el programa SANTIAGO


2) El diccionario de riesgos generado por la aplicacin sucesivade la metodologa descrita, y posterior seguimiento de lossubprogramas, se ha mostrado como un punto de partidaeficaz en el momento de encarar la realizacin del anlisisde riesgos correspondiente a un nuevo proceso deevaluacin de ofertas.

3) La sencillez formal de la metodologa utilizada, pese a losinconvenientes anteriormente expuestos, se traduce en unalto nivel de confianza en la misma por parte del decisor, elcual, adems de comprender su enfoque global, es capazde controlar la importancia relativa de sus distintoscomponentes.

7 5

Procedimiento deevaluacin de

ofertas en elprograma SIMCA

6


6.1. Descripcin general del programa SIMCA

El programa Sistema de Mando y Control Areo (SIMCA) delEjrcito del Aire tiene como objetivo disponer de un sistema que permitaconocer la situacin en todo el espacio areo de responsabilidad yque facilite la toma de decisiones en la conduccin de las operacionesareas tanto defensivas como ofensivas y las de apoyo en situacionesde paz o de crisis. El SIMCA debe ser un sistema fiable, seguro, debeoperar ininterrumpidamente, y ha de poder intercambiar informacincon otros sistemas. Consta de tres subsistemas: Mando y Control,Vigilancia y Comunicaciones.

El SIMCA sustituir al actual sistema Semiautomtico de DefensaArea (SADA), operativo desde el ao 1977 y formar parte del futuroSistema de Mando y Control Areo de la OTAN (ACCS) que a su vezsustituir al sistema actual de control y deteccin de la Alianza NADGE(NATO Air Defence Ground Environment) [13,14].

Para realizar dicha transformacin se estn realizandoproyectos, en cada uno de los tres subsistemas mencionados, quese encuentran en diversas fases de ejecucin. Unos se encuentranen fase de definicin y especificacin de requisitos, otros en fase deevaluacin de ofertas y otros en estado ms avanzado como son larealizacin de revisiones crticas, fabricacin y produccin deprototipos y primeras series con la realizacin de las correspondientespruebas de validacin.

7 7

Las reas de actividad en las cuales se est desarrollando laparticipacin de Isdefe dentro del programa SIMCA se puedenenglobar principalmente en tres bloques que se corresponden conlos subsistemas en que se divide el programa: Mando y Control,Vigilancia y Comunicaciones. En ellas se participa dando apoyo a laOficina de Programa, en los siguientes aspectos:

a) Anlisis de necesidades;b) Estudios de alternativas;c) Especificacin de requisitos (operativos, funcionales y

tcnicos);d) Evaluacin de ofertas;e) Seguimiento y control de proyectos;f) Pruebas de aceptacin del sistema;g) Auditoras y dictmenes tcnicos; yh) Garanta de calidad.

En el seguimiento de los proyectos del programa SIMCA elcaptulo relativo a la evaluacin de las ofertas presentadas por losposibles contratistas, en respuesta a un Pliego de PrescripcionesTcnicas (PPT) donde se definen los requisitos tcnicos y operativosque deben cumplir los sistemas o equipos requeridos, es un aspectoque condiciona la obtencin de un producto que satisfaciendo lasnecesidades del cliente minimice los costes.

Existe otro concepto que debido a los puntos de similitudque posee con la evaluacin de ofertas se puede confundir coneste y que es el del anlisis de riesgos. Este ltimo se empleacomo complemento del anterior en aquellos proyectos en loscuales, a la hora de tener que tomar una decisin sobre una uotra solucin propuesta, estas se basen en nuevos diseos odesarrollos (I+D) que impliquen o conlleven cierto riesgo en suejecucin. Aspectos especficos relativos al anlisis de riesgosse tratan en el Captulo dedicado al programa SANTIAGO de estamonografa.

Procedimiento de evaluacin de ofertas en el programa SIMCA


El proceso de evaluacin de ofertas es una parte decisiva y quese lleva a cabo al inicio del proyecto, determinando en gran medida labuena marcha de las fases posteriores del mismo. La eleccin de unequipo o sistema con unas prestaciones o caractersticas degradadas,comparndolas con las requeridas, puede suponer un encarecimientoconsiderable del ciclo de vida logstico del producto adems de lainsatisfaccin del usuario.

El procedimiento de evaluacin debe basarse en mtodos loms objetivos posibles, de manera que dicho procedimiento seatransparente.

6.2. Evaluacin de ofertas. Metodologa

6.2.1. Introduccin

En el proceso de evaluacin de ofertas, y principalmente enproyectos donde los sistemas o productos a obtener sean de ciertaenvergadura tanto tcnica como econmica, como ocurre en elprograma SIMCA, es preciso tener en cuenta no solo el sistema aadquirir como tal (radar, equipamiento de Centro de Mando y Control,equipo de comunicaciones, red de microondas, etc) sino tambin otrosaspectos que van ligados al ciclo de vida del producto tales como sumantenibilidad, fiabilidad, disponibilidad, coste,... etc. [6]. Es pues, este,un proceso complejo y delicado que implica el concurso de especialistaspor temas o reas y en el que partiendo de una especificacin derequisitos se trata de sopesar los aspectos o soluciones contenidosen las diversas ofertas suministr

5 ingenieria de sistemas aplicada

Documents