Ingenieria de Sistemas Aplicada

Publicaciones de Ingeniería de Sistemas
5
Otros títulos publicados:
COMITÉ DE REDACCIÓN 1. Ingeniería de Sistemas. Benjamin S. Blanchard.

2. La Teoría General de Sistemas. Ángel A. Sarabia.
INGENIERÍA DE SISTEMAS
Presidente
Sr. D. Martín Aleñar Ginard
3. Dinámica de Sistemas. Javier Aracil.
4. Dinámica de Sistemas Aplicada. Ronald R. Drew. APLICADA Isdefe ha acumulado, en estos primeros
diez años, más de 1.6 millones de horas de
Teniente General (R) del Ejército de Tierra
5. Ingeniería de Sistemas Aplicada. Isdefe. ingeniería colaborando en diferentes pro-
6. CALS (Adquisición y apoyo continuado durante el ciclo de Isdefe gramas, en las áreas de mando y control,
vida). Rowland G. Freeman III. apoyo logístico, telecomunicaciones, tec-
Vocales nologías de la información, navegación
Sr. D. Eduardo Avanzini Blanco aérea, investigación operativa, simulación,
General de Brigada Ingeniero del Ejército del Aire
seguridad, protección del medio ambiente,
Sr. D. Carlos Casajús Díaz y formación de personal, siempre bajo la
INGENIERÍA DE SISTEMAS APLICADA. Isdefe

Vicealmirante Ingeniero de la Armada perspectiva del enfoque sistémico. Aproxi-
Sr. D. Luis García Pascual madamente un 70 % de esas horas han
Vice-Rector de Investigación y Postgrado de la UPCO correspondido a programas del sector de-
fensa y el 30 % restante al sector civil.
Sr. D. Ricardo Torrón Durán
General de Brigada Ingeniero del Ejército de Tierra
El objetivo de esta monografía es resumir la
Sr D. Alberto Sols Rodríguez-Candela experiencia adquirida por Isdefe en el campo
Ingeniero de Sistemas. Isdefe de la ingeniería de sistemas. Para ello se
Sra. Dña. Mª Fernanda Ruiz de Azcárate Varela han seleccionado once de los principales
Imagen Corporativa. Isdefe 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.
Ingeniería de Sistemas
c/ Edison, 4
28006 Madrid
Teléfono (34-1) 411 50 11
Fax (34-1) 411 47 03
E-mail: monografias@isdefe.es P.V.P.: 1.000 Ptas.
(IVA incluido) ILUSTRACIÓN DE PORTADA
Torno plano de 1850
1
No está permitida la reproducción total o

parcial de este libro, ni su tratamiento
informático, ni la transmisión de ninguna
forma o por cualquier medio, ya sea
electrónico, por fotocopia, por registro o por
otros métodos, sin el previo consentimiento
por escrito de los titulares del Copyright.
Primera Edición: Septiembre - 1995

1.250 ejemplares
© Isdefe
c/ Edison, 4
28006 Madrid.
Diseño:
HB&h Dirección de arte y producción
Infografía de portada:
Salvador Vivas
Fotomecánica:
Microprint, S.A.
Impresión:
Gráficas Forma, S.A. (Madrid)
ISBN: 84-89338-05-1
Depósito legal: M- -1995
Printed in Spain - Impreso en España.
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 madu-
rado rápidamente y se ha consolidado como una compañía de inge-
niería de sistemas capaz de apoyar eficazmente a las Fuerzas Arma-
das, al Ministerio de Defensa y en general a la Administración Públi-
ca. 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 la Administración
española, donde se refleja parte de la experiencia vivida durante es-
tos primeros diez años 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 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) 9
1.1. Evolución de la complejidad de los sistemas 10
1.2. El enfoque sistémico 10
1.3. La creación de Isdefe 12
1.4. Experiencia de Isdefe en ingeniería de sistemas 13
1.5. Desarrollo de la monografía 14
2. AEGIS: DISEÑO CONCEPTUAL DEL FUTURO SISTEMA

DE GESTIÓN DEL TRÁNSITO AÉREO (Trudi Kiebala Xiol) 19
2.1. Descripción global del proyecto AEGIS 20
2.2. Relación del proyecto con la ingeniería de sistemas 21
2.3. Fase 1: evaluación 21
2.4. Fase 2: mejora 26
2.5. Fase 3: consolidación 28
2.6. Valor añadido del proyecto 28
2.7. Consideraciones finales 29
3. EVALUACIÓN DE DESARROLLOS BASADOS EN UNA NUEVA

TECNOLOGÍA: DEMOSTRADOR PlanBA (Rafael García Vázquez) 31
3.1. El programa PlanBA 32
3.2. Evaluación de desarrollos en PlanBA 33
3.2.1. Identificación de tecnologías relevantes en banda ancha 35
3.2.2. Identificación de aplicaciones y usuarios de banda ancha 36
3.2.3. Definición del plan de trabajo para la consecución del
demostrador 37
3.3. Evolución del proyecto integrado PlanBA 38
4. ESPECIFICACIÓN DE REQUISITOS EN EL
PROGRAMA MIDS (Luis Rodríguez Palencia) 43
4.1. El sistema MIDS 44
4.2. El programa MIDS 45
4.3. Actividades previas a la fase de desarrollo 46
4.3.1. Preparación de la petición de oferta 46
4.3.2. Reducción de prestaciones técnicas 53
4.3.3. Negociación del precio 53
4.3.4. Establecimiento de la línea base 54
4.3.5. Seguimiento industrial 54
4.3.6. Seguimiento de costes 55
4.3.7. Gestión del espectro radioeléctrico 55
5. 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 60
5.2. Análisis de riesgos 61
6
5.3. La metodología utilizada 62

5.3.1. Objetivos 62
5.3.2. Identificación 63
5.3.3. Evaluación del impacto 65
5.3.4. Cuantificación de la probabilidad 66
5.3.5. Integración 67
5.3.6. Automatización del proceso 69
6. PROCEDIMIENTO DE EVALUACIÓN DE OFERTAS
EN EL PROGRAMA SIMCA (Jorge Parra Gila) 75
6.1. Descripción general del programa Simca 76

6.2. Evaluación de ofertas. Metodología 78
6.2.1. Introducción 78
6.2.2. Procedimiento de evaluación 79
7. 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 92
7.2. Análisis de valor en el programa F-100 92
7.3. Análisis de costes. Estudios paramétricos 93
7.3.1. Generalidades 93
7.3.2. Análisis de costes 96
7.3.3. Herramienta paramétrica de estimación de costes 97
7.3.4. Aplicación de los análisis paramétricos
de ingeniería de costes en la fragata F-100 100
8. GESTIÓN DE LA CONFIGURACIÓN EN EL SCTM

(Juan Méndez Fariñas) 105
8.1. Programa SCTM 106
8.2. Gestión de la configuración aplicada al SCTM 107
8.3. Concepto de gestión de la configuración 108
8.3.1. Elementos de gestión de la configuración 110
8.4. Descripción de actividades 113
9. PROCESO DE SELECCIÓN DE EQUIPOS Y SUMINISTRADORES

EN EL PROGRAMA EF2000 (José Manuel Buergo Villanueva) 121
9.1. Descripción del programa 122
9.2. Participación de la industria española 122
9.3. Equipos de avión y accesorios de motor 123
9.4. Proceso de gestión del desarrollo 125
9.5. Proceso de selección 126
9.5.1. Principios del proceso de selección 126
9.5.2. Evaluación y aprobación de especificaciones 127
9.5.3. Selección de suministradores de equipos 128
9.5.4. Criterios de evaluación y selección 132
7
10. VERIFICACIÓN Y VALIDACIÓN EN EL PROGRAMA EUROMAYA

(Juan Revuelta Lapique) 141
10.1. Descripción del programa Euromaya 142
10.2. Verificación y validación 145
10.3. Descripción de actividades 147
10.3.1. Auditorías e inspecciones 148
10.3.2. Revisiones 149
10.3.3. Pruebas 150
11. TRANSICIÓN OPERATIVA EN EL PROGRAMA SACTA

(Miguel Baragaño Fueyo) 157
11.1. Descripción del programa SACTA 158
11.2. Transición operativa 161
11.2.1. Características generales 161
11.2.2. Planificación de la transición 162
11.2.3. Preparación de la transición 164
11.2.4. Ejecución de la transición 165
11.3. Ejemplo de transición (Madrid) 165
12. SISTEMAS DE GESTIÓN INTEGRADA DEL PROGRAMA TLE

(Álvaro Manresa Sánchez) 169
12.1. Introducción 170
12.2. Descripción del programa TLE 170
12.2.1. Objetivo 170
12.2.2. Situación actual del programa 171
12.3. La gestión del programa TLE 172
12.3.1. Ingeniería y gestión 172
12.3.2. Colaboración de Isdefe en el programa TLE 173
12.3.3. El sistema de gestión integrada del programa TLE 174
12.3.4. Elementos del diseño del sistema de gestión 174
12.3.5. Proceso de datos y generación de informes 180
13. EPÍLOGO (Alberto Sols Rodríguez-Candela) 187

13.1. Introducción 188
13.2. La rueda es redonda y rueda bien 188
13.3. Resumen de lecciones aprendidas 189
13.4. Kaizen 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 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 toma-
das en cada fase. La relación entre los costes incurridos y los compro-
misos 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 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 creación de Isdefe
En el final de la década de los 70 se vivió un fuerte aumento de la

relación de nuestras 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. 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. Experiencia de Isdefe en ingeniería de 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 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], ilustra a través de varios ejemplos la aplicabilidad de
la Dinámica de Sistemas (expuesta de forma conceptual en la tercera
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].
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 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. Desarrollo de la monografía
Cada uno de los siguientes once capítulos ilustra un aspecto

relacionado con la ingeniería de 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
se indica la faceta a resaltar y su integración en el proceso de
ingeniería de 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
21
AEGIS: Diseño conceptual del futuro sistema de gestión del tránsito aéreo
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
23
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
25
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
27
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
29
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 especializa-
da 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
35
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
37
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
39
40
41
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
45
Especificación de requisitos en el programa MIDS
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
47
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) Diseño del terminal MIDS.

b) Diseño de un simulador de interfaz del MIDS.
c) Prototipos de terminales.
d) Simuladores.
e) 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.
49
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
51
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
53
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.
55
Dentro de las actividades del seguimiento industrial, los

principales hitos en este programa son los siguientes:
a) Revisión preliminar del diseño.

b) Revisión crítica del diseño.
c) Ensayo preliminar de cualificación.
d) Auditoría de cualificación formal.
4.3.6. 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é condicio-
nes 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 usua-
rio secundario de la banda, lo cual significa, según el Reglamento de
Radiocomunicaciones que, en caso de interferencias, los demás sis-
temas 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.
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
57
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.
63
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.
65
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 Churchman-
Ackoff, Delphi o similares, hubiera requerido un esfuerzo
67
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
69
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,
71
a priori, los riesgos asociados a las distintas alternativas y apoyar la

gestión de riesgos encaminada a su minimización.
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.
73
74
75
6
Procedimiento de
evaluación de
ofertas en el
programa SIMCA
76
6.1. Descripción general del programa 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
conocer la situación en todo el espacio aéreo de responsabilidad y
que facilite la toma de decisiones en la conducción de las operaciones
aéreas tanto defensivas como ofensivas 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 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álisis de necesidades;
b) Estudios de alternativas;
c) Especificación de requisitos (operativos, funcionales y
técnicos);
d) Evaluación de ofertas;
e) Seguimiento y control de proyectos;
f) Pruebas de aceptación del sistema;
g) Auditorías y dictámenes técnicos; y
h) Garantí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 y operativos
que deben cumplir los sistemas o equipos requeridos, 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 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,
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. Evaluación de ofertas. Metodologí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, fiabilidad, 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 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
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) Objetividad y transparencia en el proceso;

b) Precisión;
c) Agilizar y facilitar la evaluación;
d) 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) Reducir, o al menos ponderar, la incertidumbre;

b) Facilitar la posterior utilización de resultados;
c) Normalizar el proceso de presentación y selección;
d) Aumentar la transparencia del proceso de selección;
e) Aumentar la credibilidad del organismo evaluador; y
f) 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
81
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.
83
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) Valoración de aspectos globales;

2) Criterios técnicos y operativos;
3) Apoyo logístico y calidad del suministrador; y
4) 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
85
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:
∑ P u n tu a c io n e s e le m e n ta le s (T . In fe rio r)
Puntuación parcial (Tabla superior)= x5
∑ M a x im o s e le m e n ta le s (T . In fe rio 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
87
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.
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.
89
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.
95
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
97
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
99
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, 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
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.4. Aplicación de los análisis paramétricos de ingeniería 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.
101
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
El valor de cualquier sistema de armas es un condicionante 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, 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.
103
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 PAPS (Periodic Armaments Planning System) de
la 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ón de la configuración aplicada 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
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 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. Concepto de gestión de la configuración
En su concepción genérica, la gestión de 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.
109
En el caso específico de un sistema de telecomunicaciones, la

gestión de configuración engloba el conjunto de capacidades que
permiten identificar los componentes del sistema, definir las conexiones
entre ellos, recoger los datos de funcionamiento (control de estados) 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 y control de tiempo real de los
elementos del sistema, permitirán apoyar el desarrollo de actividades
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 de datos gráfica, compuesta por el conjunto de planos

estáticos y dinámicos que representan la configuración de
la red.
2) Base de datos alfanumérica, que incluye la identificación 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.3.1. Elementos de gestión de la configuración
La función de Gestión de la Configuración estará soportada por

el conjunto de procedimientos y herramientas (programas software),
que apoyándose en la arquitectura hardware del Subsistema de Gestión
y Supervisión del SCTM, permitirá:
a) La identificación de los elementos de la red.
b) El control de cambios, así como su distribución automática

a los órganos responsables de la obtención y funcionamiento
de la red.
c) El control de estado de los elementos de la 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:
111
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.
113
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.
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
115
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,
117
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.
119
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.
125
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.
127
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
129
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.
131
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
133
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. Prestaciones.
2. Fiabilidad y Seguridad, Mantenibilidad y Capacidad de
Prueba.
3. Características Técnicas y Aspectos de Programa.
4. 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,
135
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ómico-
contractuales) 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
137
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.
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.).
139
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
145
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écnico-
operativos 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.
147
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.
149
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:
151
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
153
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.
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.
155
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.
161
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;
163
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 entre-
namiento 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);
165
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) Preparación de las medidas restrictivas del entorno

operativo, y notificación a los organismos nacionales e
internacionales involucrados.
11.2.4. 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.
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.
167
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.
173
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»).
175
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
177
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
179
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.
181
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
183
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.
185
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

[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

[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.): Quality Function Deployment,

Productivity Press, Portland, OR, 1990.
Akigama, K.: Function Analysis,
Productivity Press, Cambridge, MA, 1991.
Blanchard, B.S.: Engineering Organization and Management,
Prentice-Hall Inc., Englewood Cliffs, NJ, 1986.
Blanchard, B.S. &
W.J. Fabrycky: Life Cycle Cost And Economics Analysis,
Prentice-Hall, Englewood Cliffs, N.J., 1991.
Canada, J.R. &
W. G. Sullivan: Economic and Multiattribute Evaluation of Advanced Manufacturing
Systems,
Prentice-Hall, Inc., 1989.
Cuthbertr, L.G. &
J.C. Sapanel: ATM. The Broadband Telecommunications Solution,
IEE Telecommunication Series 29, Londres, 1993.
Fishburn, P.C.: Uthility Theory for Decision Making,
John Wiley & Sons, Inc., Nueva York, 1970.
Gregory, G.: Decision Analysis,
Plenum Publishing Co., 1988.
Hammer, C. &
J. Champy: Reingeniería de la Empresa,
Parramón Ediciones, Barcelona, 1994.
Handel , R. &
M.N. Huber: 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 susceptibi-

lidad 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
211
Esta primera edición de

de la serie de
Monografías de Ingeniería de Sistemas
se terminó de imprimir el día
15 de septiembre de 1995.

Ingenieria de Sistemas Aplicada

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Sistemas Aplicada

Cargado por

Copyright:

Formatos disponibles

Publicaciones de Ingeniería de Sistemas

COMITÉ DE REDACCIÓN 1. Ingeniería de Sistemas. Benjamin S. Blanchard.

INGENIERÍA DE SISTEMAS APLICADA. Isdefe

No está permitida la reproducción total o

Primera Edición: Septiembre - 1995

Madrid, 15 de septiembre de 1995

Han transcurrido ya diez años desde la creación de Isdefe en

La serie de monografías que estamos editando está orientada a

La intención de la monografía que ahora se presenta es reflejar,

Quiero agradecer al personal de la empresa que está colabo-

José Vicente Cebrián

2. AEGIS: DISEÑO CONCEPTUAL DEL FUTURO SISTEMA

3. EVALUACIÓN DE DESARROLLOS BASADOS EN UNA NUEVA

5. ANÁLISIS DE RIESGOS DURANTE LA EVALUACIÓN DE OFERTAS

5.3. La metodología utilizada 62

6.1. Descripción general del programa Simca 76

7. ANÁLISIS DE VALOR EN LA F-100

8. GESTIÓN DE LA CONFIGURACIÓN EN EL SCTM

9. PROCESO DE SELECCIÓN DE EQUIPOS Y SUMINISTRADORES

10. VERIFICACIÓN Y VALIDACIÓN EN EL PROGRAMA EUROMAYA

11. TRANSICIÓN OPERATIVA EN EL PROGRAMA SACTA

12. SISTEMAS DE GESTIÓN INTEGRADA DEL PROGRAMA TLE

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

1.1. Evolución de la complejidad de los sistemas

En su apasionante novela «2001: Una odisea del espacio» [1],

1.2. El enfoque sistémico

Tanto el concepto de sistema como el modelo empleado para su

del presente siglo el paradigma empleado en la conceptualización de

La Figura 1.1 muestra la relación entre la cantidad y calidad de

los compromisos que al tomarlas se contraen, hace especialmente

1.3. La creación de Isdefe

En el final de la década de los 70 se vivió un fuerte aumento de la

Dentro de esa nueva maquinaria que se iba concibiendo en esos

equivalentes a las de los países aliados, se detectaron numerosos

La propia concepción de Isdefe como un engranaje más de esa

1.4. Experiencia de Isdefe en ingeniería de sistemas

Isdefe ha acumulado, en estos primeros diez años, más de 1.6

sistémico. Aproximadamente un 70% de esas horas han correspondido

Si la cuarta monografía de esta serie, Dinámica de Sistemas

El objetivo de esta monografía es resumir la experiencia

1.5. Desarrollo de la monografía

Cada uno de los siguientes once capítulos ilustra un aspecto

sino reflejar las actividades realizadas en ellos por Isdefe en relación

En el Epílogo se resumen las lecciones aprendidas, fruto de las

2.1. Descripción global del proyecto AEGIS

En los últimos años distintas organizaciones europeas e

Los miembros del consorcio AEGIS eran Aérospatiale, BNR

El proyecto se dividió en tres fases: evaluación, mejora y

de trabajo técnicos y uno de gestión. En la fase de evaluación, el

Isdefe participó en el proyecto AEGIS como coordinador.

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

2.3. Fase 1: evaluación

Como primer paso de la fase de evaluación, el consorcio

nivel de descripción, si eran generales o específicos, si proponían un

Antes de proceder a desarrollar una metodología para la

Basándose en el ciclo de vida del sistema, el consorcio definió

1) Identificación de las necesidades del cliente: consideración

2) Elaboración de esquemas de soluciones: delimitación del

3) Desarrollo de soluciones: exposición en detalle de las

4) Transición: definición de uno o varios caminos alternativos

5) Mejoras previstas: identificación de los efectos y beneficios

6) Conclusiones: resumen de los resultados del escenario y

Aplicando esta metodología, el consorcio definió las necesidades