Isdefe - Ingenieria de Sistemas Aplicada PDF

Publicaciones de Ingeniera de Sistemas
5
Otros ttulos publicados:
COMIT DE REDACCIN 1. Ingeniera de Sistemas. Benjamin S. Blanchard.

2. La Teora General de Sistemas. ngel A. Sarabia.
INGENIERA DE SISTEMAS
Presidente
Sr. D. Martn Alear Ginard
3. Dinmica de Sistemas. Javier Aracil.
4. Dinmica de Sistemas Aplicada. Ronald R. Drew. APLICADA Isdefe ha acumulado, en estos primeros
diez aos, ms de 1.6 millones de horas de
Teniente General (R) del Ejrcito de Tierra
5. Ingeniera de Sistemas Aplicada. Isdefe. ingeniera colaborando en diferentes pro-
6. CALS (Adquisicin y apoyo continuado durante el ciclo de Isdefe gramas, en las reas de mando y control,
vida). Rowland G. Freeman III. apoyo logstico, telecomunicaciones, tec-
Vocales nologas de la informacin, navegacin
Sr. D. Eduardo Avanzini Blanco area, investigacin operativa, simulacin,
General de Brigada Ingeniero del Ejrcito del Aire
seguridad, proteccin del medio ambiente,
Sr. D. Carlos Casajs Daz y formacin de personal, siempre bajo la
INGENIERA DE SISTEMAS APLICADA. Isdefe

Vicealmirante Ingeniero de la Armada perspectiva del enfoque sistmico. Aproxi-
Sr. D. Luis Garca Pascual madamente un 70 % de esas horas han
Vice-Rector de Investigacin y Postgrado de la UPCO correspondido a programas del sector de-
fensa y el 30 % restante al sector civil.
Sr. D. Ricardo Torrn Durn
General de Brigada Ingeniero del Ejrcito de Tierra
El objetivo de esta monografa es resumir la
Sr D. Alberto Sols Rodrguez-Candela experiencia adquirida por Isdefe en el campo
Ingeniero de Sistemas. Isdefe de la ingeniera de sistemas. Para ello se
Sra. Da. M Fernanda Ruiz de Azcrate 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 ingeniera de
sistemas y se abarquen, adems, las
diferentes fases del ciclo de vida de los
sistemas.
Ingeniera de Sistemas
c/ Edison, 4
28006 Madrid
Telfono (34-1) 411 50 11
Fax (34-1) 411 47 03
E-mail: monografias@isdefe.es P.V.P.: 1.000 Ptas.
(IVA incluido) ILUSTRACIN DE PORTADA
Torno plano de 1850
1
No est permitida la reproduccin total o

parcial de este libro, ni su tratamiento
informtico, ni la transmisin de ninguna
forma o por cualquier medio, ya sea
electrnico, por fotocopia, por registro o por
otros mtodos, sin el previo consentimiento
por escrito de los titulares del Copyright.
Primera Edicin: Septiembre - 1995

1.250 ejemplares
Isdefe
c/ Edison, 4
28006 Madrid.
Diseo:
HB&h Direccin de arte y produccin
Infografa de portada:
Salvador Vivas
Fotomecnica:
Microprint, S.A.
Impresin:
Grficas Forma, S.A. (Madrid)
ISBN: 84-89338-05-1
Depsito legal: M- -1995
Printed in Spain - Impreso en Espaa.
3
Madrid, 15 de septiembre de 1995
Han transcurrido ya diez aos desde la creacin de Isdefe en

1985 y puede decirse hoy con satisfaccin que la empresa ha madu-
rado rpidamente y se ha consolidado como una compaa de inge-
niera de sistemas capaz de apoyar eficazmente a las Fuerzas Arma-
das, al Ministerio de Defensa y en general a la Administracin Pbli-
ca. Los trabajos desarrollados en estos aos han permitido consolidar
conocimientos y adquirir una experiencia significativa.
La serie de monografas que estamos editando est orientada a

divulgar los fundamentos de la ingeniera de sistemas. Sus autores
son profesionales cualificados que explican, de forma clara y sencilla,
los aspectos bsicos de la ingeniera de sistemas y sus disciplinas
asociadas.
La intencin de la monografa que ahora se presenta es reflejar,

de forma coherente con la serie en la que se integra, actuaciones de
ingeniera de sistemas realizadas por Isdefe para la Administracin
espaola, donde se refleja parte de la experiencia vivida durante es-
tos primeros diez aos de andadura, en este apasionante campo.
Quiero agradecer al personal de la empresa que est colabo-

rando con la serie y especialmente a los autores de las monografas
y a los miembros del Comit de Redaccin, la ilusin volcada en
este proyecto.
Jos Vicente Cebrin

Consejero Delegado de Isdefe
4
INGENIERA DE SISTEMAS APLICADA
5
NDICE GENERAL
1. INTRODUCCIN (Alberto Sols Rodrguez-Candela) 9
1.1. Evolucin de la complejidad de los sistemas 10
1.2. El enfoque sistmico 10
1.3. La creacin de Isdefe 12
1.4. Experiencia de Isdefe en ingeniera de sistemas 13
1.5. Desarrollo de la monografa 14
2. AEGIS: DISEO CONCEPTUAL DEL FUTURO SISTEMA

DE GESTIN DEL TRNSITO AREO (Trudi Kiebala Xiol) 19
2.1. Descripcin global del proyecto AEGIS 20
2.2. Relacin del proyecto con la ingeniera de sistemas 21
2.3. Fase 1: evaluacin 21
2.4. Fase 2: mejora 26
2.5. Fase 3: consolidacin 28
2.6. Valor aadido del proyecto 28
2.7. Consideraciones finales 29
3. EVALUACIN DE DESARROLLOS BASADOS EN UNA NUEVA

TECNOLOGA: DEMOSTRADOR PlanBA (Rafael Garca Vzquez) 31
3.1. El programa PlanBA 32
3.2. Evaluacin de desarrollos en PlanBA 33
3.2.1. Identificacin de tecnologas relevantes en banda ancha 35
3.2.2. Identificacin de aplicaciones y usuarios de banda ancha 36
3.2.3. Definicin del plan de trabajo para la consecucin del
demostrador 37
3.3. Evolucin del proyecto integrado PlanBA 38
4. ESPECIFICACIN DE REQUISITOS EN EL
PROGRAMA MIDS (Luis Rodrguez 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. Preparacin de la peticin de oferta 46
4.3.2. Reduccin de prestaciones tcnicas 53
4.3.3. Negociacin del precio 53
4.3.4. Establecimiento de la lnea base 54
4.3.5. Seguimiento industrial 54
4.3.6. Seguimiento de costes 55
4.3.7. Gestin del espectro radioelctrico 55
5. ANLISIS DE RIESGOS DURANTE LA EVALUACIN DE OFERTAS

EN EL PROGRAMA SANTIAGO (Juan Jos Martnez Dopico) 59
5.1. El programa Santiago 60
5.2. Anlisis de riesgos 61
6
5.3. La metodologa utilizada 62

5.3.1. Objetivos 62
5.3.2. Identificacin 63
5.3.3. Evaluacin del impacto 65
5.3.4. Cuantificacin de la probabilidad 66
5.3.5. Integracin 67
5.3.6. Automatizacin del proceso 69
6. PROCEDIMIENTO DE EVALUACIN DE OFERTAS
EN EL PROGRAMA SIMCA (Jorge Parra Gila) 75
6.1. Descripcin general del programa Simca 76

6.2. Evaluacin de ofertas. Metodologa 78
6.2.1. Introduccin 78
6.2.2. Procedimiento de evaluacin 79
7. ANLISIS DE VALOR EN LA F-100

(Fernando J. Morales Moreno y Jos Luis Snchez Menndez) 91
7.1. El programa F-100 92
7.2. Anlisis de valor en el programa F-100 92
7.3. Anlisis de costes. Estudios paramtricos 93
7.3.1. Generalidades 93
7.3.2. Anlisis de costes 96
7.3.3. Herramienta paramtrica de estimacin de costes 97
7.3.4. Aplicacin de los anlisis paramtricos
de ingeniera de costes en la fragata F-100 100
8. GESTIN DE LA CONFIGURACIN EN EL SCTM

(Juan Mndez Farias) 105
8.1. Programa SCTM 106
8.2. Gestin de la configuracin aplicada al SCTM 107
8.3. Concepto de gestin de la configuracin 108
8.3.1. Elementos de gestin de la configuracin 110
8.4. Descripcin de actividades 113
9. PROCESO DE SELECCIN DE EQUIPOS Y SUMINISTRADORES

EN EL PROGRAMA EF2000 (Jos Manuel Buergo Villanueva) 121
9.1. Descripcin del programa 122
9.2. Participacin de la industria espaola 122
9.3. Equipos de avin y accesorios de motor 123
9.4. Proceso de gestin del desarrollo 125
9.5. Proceso de seleccin 126
9.5.1. Principios del proceso de seleccin 126
9.5.2. Evaluacin y aprobacin de especificaciones 127
9.5.3. Seleccin de suministradores de equipos 128
9.5.4. Criterios de evaluacin y seleccin 132
7
10. VERIFICACIN Y VALIDACIN EN EL PROGRAMA EUROMAYA

(Juan Revuelta Lapique) 141
10.1. Descripcin del programa Euromaya 142
10.2. Verificacin y validacin 145
10.3. Descripcin de actividades 147
10.3.1. Auditoras e inspecciones 148
10.3.2. Revisiones 149
10.3.3. Pruebas 150
11. TRANSICIN OPERATIVA EN EL PROGRAMA SACTA

(Miguel Baragao Fueyo) 157
11.1. Descripcin del programa SACTA 158
11.2. Transicin operativa 161
11.2.1. Caractersticas generales 161
11.2.2. Planificacin de la transicin 162
11.2.3. Preparacin de la transicin 164
11.2.4. Ejecucin de la transicin 165
11.3. Ejemplo de transicin (Madrid) 165
12. SISTEMAS DE GESTIN INTEGRADA DEL PROGRAMA TLE

(lvaro Manresa Snchez) 169
12.1. Introduccin 170
12.2. Descripcin del programa TLE 170
12.2.1. Objetivo 170
12.2.2. Situacin actual del programa 171
12.3. La gestin del programa TLE 172
12.3.1. Ingeniera y gestin 172
12.3.2. Colaboracin de Isdefe en el programa TLE 173
12.3.3. El sistema de gestin integrada del programa TLE 174
12.3.4. Elementos del diseo del sistema de gestin 174
12.3.5. Proceso de datos y generacin de informes 180
13. EPLOGO (Alberto Sols Rodrguez-Candela) 187

13.1. Introduccin 188
13.2. La rueda es redonda y rueda bien 188
13.3. Resumen de lecciones aprendidas 189
13.4. Kaizen 193
REFERENCIAS 195
BIBLIOGRAFA 199
GLOSARIO 203
8
9
1
Introduccin
10
1.1. Evolucin de la complejidad de los sistemas
En su apasionante novela 2001: Una odisea del espacio [1],

Arthur C. Clarke narra la evolucin de la especie humana desde el
despertar de la inteligencia en los pre-homnidos, en la Noche
Primigenia, a los viajes de la era espacial de un futuro prximo. Carl
Sagan, en su ensayo cientfico Los dragones del Edn [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 disear y
desarrollar cosas cada vez ms complejas. Entre las hachas de piedra
del Paleoltico y los transbordadores y estaciones espaciales de
nuestros das no slo median dos millones de aos, sino un incremento
colosal en la complejidad de los sistemas diseados por el hombre.
Esa complejidad crece exponencialmente, de forma que la mayora de
los diseos de hace unas pocas dcadas estn hoy tecnolgica y
funcionalmente obsoletos. Con ello ha ido aumentando nuestra
necesidad de un modelo o paradigma capaz de posibilitar el diseo y
desarrollo de sistemas.
1.2. El enfoque sistmico
Tanto el concepto de sistema como el modelo empleado para su

estudio ha evolucionado notablemente con el tiempo [3]. Desde mediados
11
Introduccin
del presente siglo el paradigma empleado en la conceptualizacin de

sistemas es el denominado enfoque sistmico, que aporta frente a su
predecesor (el enfoque reduccionista de la Revolucin Industrial) la
consideracin explcita de que un sistema lo componen no slo sus
partes integrantes, sino tambin las interrelaciones entre ellas. Esa no
independencia de las partes es una de las caractersticas
fundamentales del enfoque sistmico, distinguido adems por su
consideracin del ciclo de vida de los sistemas.
La Figura 1.1 muestra la relacin entre la cantidad y calidad de

la informacin 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 relacin entre los costes incurridos y los compro-
misos contrados (coste, tecnologa, arquitectura del sistema, etc.) se
muestra en la Figura 1.2. El hecho de que en las fases iniciales la
informacin sobre el sistema sea relativamente escasa y poco precisa
y que las decisiones adoptadas sean las ms importantes, por todos
12
los compromisos que al tomarlas se contraen, hace especialmente

importante la consideracin, desde esas etapas iniciales, del conjunto
del sistema como algo dinmico a lo largo de un ciclo de vida; es decir,
es esencial un enfoque sistmico.
1.3. La creacin de Isdefe
En el final de la dcada de los 70 se vivi un fuerte aumento de la

relacin de nuestras Fuerzas Armadas con las de otros pases. Ello puso
de manifiesto ciertas carencias y limitaciones, que era preciso solventar
de cara a posibilitar su autntica integracin en foros internacionales. Se
emprendi as un ambicioso proyecto de modernizacin de las Fuerzas
Armadas.
Dentro de esa nueva maquinaria que se iba concibiendo en esos

aos como el futuro Ministerio de Defensa, con capacidades
13
Introduccin
equivalentes a las de los pases aliados, se detectaron numerosos

engranajes nuevos que se hacan necesarios. Uno de ellos, destinado
a contribuir como un elemento ms a la modernizacin y capacitacin
tecnolgica de las Fuerzas Armadas, era una ingeniera propia de
defensa, del estilo de las existentes en otros pases 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 ingeniera de sistemas y en consultora a
organismos de la Administracin, especialmente al Ministerio de
Defensa y a las Fuerzas Armadas. Entre las misiones de Isdefe
destacan el ayudar a la definicin tcnica de las necesidades que
determinen operativamente los Estados Mayores; el apoyar en la
elaboracin de las especificaciones tcnicas de los sistemas, el anlisis
de las ofertas y el seguimiento de los programas; el colaborar en la
ordenada planificacin de las adquisiciones de Defensa; el disponer
de un personal de alta cualificacin en tecnologas especficas; y el
hacer extensivas esas capacidades al resto de la Administracin en
sistemas relacionados con la seguridad nacional.
La propia concepcin de Isdefe como un engranaje ms de esa

gran maquinaria de relojera que deba ser el Ministerio de Defensa
pone de manifiesto la excelente visin sistmica de los relojeros
que disearon la maquinaria, que ciertamente demostraron ser mucho
menos ciegos que nuestro relojero genrico del cuadernillo de
presentacin de esta serie de monografas.
1.4. Experiencia de Isdefe en ingeniera de sistemas
Isdefe ha acumulado, en estos primeros diez aos, ms de 1.6

millones de horas de ingeniera colaborando en diferentes programas,
en las reas de mando y control, apoyo logstico, telecomunicaciones,
tecnologas de la informacin, navegacin area, investigacin
operativa, simulacin, seguridad, proteccin del medio ambiente, y
formacin de personal, siempre bajo la perspectiva del enfoque
14
sistmico. Aproximadamente un 70% de esas horas han correspondido

a programas del sector defensa y el 30% restante al sector civil.
Si la cuarta monografa de esta serie, Dinmica de Sistemas

Aplicada [4], ilustra a travs de varios ejemplos la aplicabilidad de
la Dinmica de Sistemas (expuesta de forma conceptual en la tercera
monografa) [5] tanto en el sector defensa como en el civil, esta
monografa refleja aplicaciones concretas en la Administracin
espaola y en la europea de algunos de los aspectos del proceso
descrito en la primera monografa de la serie, Ingeniera de
Sistemas [6].
El objetivo de esta monografa es resumir la experiencia

adquirida por Isdefe en el campo de la ingeniera 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 ingeniera de sistemas y se abarquen,
adems, las diferentes fases del ciclo de vida de los sistemas. La Figura
1.3 muestra los programas seleccionados para ilustrar la experiencia
adquirida, indicndose adems el aspecto a resaltar de cada uno en
la fase correspondiente del ciclo de vida.
1.5. Desarrollo de la monografa
Cada uno de los siguientes once captulos ilustra un aspecto

relacionado con la ingeniera de sistemas, a travs 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 integracin en el proceso de
ingeniera de sistemas, especificando la fase en la que se materializ
la colaboracin de Isdefe en el programa. Finalmente se describen
las actividades realizadas en relacin con la faceta seleccionada.
No se pretende describir en detalle los programas seleccionados,
15
Introduccin
16
sino reflejar las actividades realizadas en ellos por Isdefe en relacin

con aspectos concretos de la ingeniera de sistemas,
salvaguardando siempre aquellos de naturaleza clasificada o
sensible. Algunos programas abarcan, en su desarrollo real, varias
fases del ciclo de vida. Aqu slo se muestra alguna de ellas (para
cada uno), a fin de dar cabida a diferentes mbitos y programas.
En el Eplogo se resumen las lecciones aprendidas, fruto de las

colaboraciones de Isdefe en los programas en los que ha participado.
El proceso de ingeniera de sistemas descansa en modelos
matemticos y, como dijo Einstein, en la medida en la que los modelos
matemticos 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 prctica
acumulada en su utilizacin los confirma y refuerza; la deteccin de
deficiencias o limitaciones implica una modificacin de los modelos y,
eventualmente, su evolucin a otros. Un modelo conceptual o terico
carece de valor si no est respaldado por la evidencia de la prctica.
Como dice el refrn ingls, la prueba del pudding est en comrselo.
17
Introduccin
18
19
2
AEGIS:
Diseo conceptual
del futuro sistema
de gestin del
trnsito areo
20
2.1. Descripcin global del proyecto AEGIS
En los ltimos aos distintas organizaciones europeas e

internacionales han desarrollado escenarios y programas para la
implantacin de un sistema mejorado de gestin del trnsito areo (Air
Traffic Management, ATM). El futuro sistema deber ser capaz de
satisfacer el aumento previsto en la demanda antes del ao 2010 (entre
el 70 y el 133 por ciento del actual). Estos escenarios no son
homogneos: 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 Direccin General de Transporte de
la Comisin 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 unificacin de los
escenarios existentes en el campo de ATM, mediante la ampliacin
del mbito de investigacin y las aportaciones de la variada experiencia
tcnica de un consorcio multidisciplinario.
Los miembros del consorcio AEGIS eran Arospatiale, BNR

Europe Ltd., Isdefe, National Technical University of Athens, Queen
Mary and Westfield College (University of London), Sextant Avionique,
Sofravia y Syseca.
El proyecto se dividi en tres fases: evaluacin, mejora y

consolidacin, subdivididas, a su vez, en un total de nueve paquetes
21
AEGIS: Diseo conceptual del futuro sistema de gestin del trnsito areo
de trabajo tcnicos y uno de gestin. En la fase de evaluacin, el

consorcio analiz y compar los escenarios y conceptos existentes,
elabor una definicin del trmino escenario, estableci una
metodologa para desarrollar escenarios y aplic esta metodologa para
obtener un escenario base. En la fase de mejora, se identificaron e
integraron en el escenario base una serie de mejoras organizativas,
tcnicas y de entorno. Finalmente, en la fase de consolidacin, el
consorcio desarroll una metodologa para analizar los costes y
beneficios de escenarios para ATM y valid el escenario mejorado
aplicando esta metodologa. La Figura 2.1 presenta estas tres fases
de forma esquemtica.
Isdefe particip en el proyecto AEGIS como coordinador.

Asimismo, fue responsable directo del estudio coste/beneficio que se
llev a cabo y de la consolidacin final del escenario.
2.2. Relacin del proyecto con la ingeniera de sistemas
La totalidad del trabajo que se ha llevado a cabo en el 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
diseo conceptual de la ingeniera de sistemas aplicada al campo de
la gestin del trnsito areo. Basndose en las necesidades del cliente,
se identificaron y analizaron los requisitos del futuro sistema ATM, se
propuso una solucin coherente para satisfacer estos requisitos y se
definieron los pasos de transicin necesarios para lograr la solucin
propuesta.
2.3. Fase 1: evaluacin
Como primer paso de la fase de evaluacin, 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 descripcin, si eran generales o especficos, si proponan un

sistema totalmente automatizado o un sistema que conservara la
intervencin 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 gestin de
afluencia, la gestin del espacio areo, el control de trfico areo,
comunicaciones/navegacin/vigilancia, la integracin aire/tierra, el
papel del hombre en el sistema y la interfaz hombre-mquina, la gestin
del trnsito areo o los costes. Asimismo, se identificaron conceptos
en cinco dominios: gestin de vuelo a bordo (Air Flight Management,
AFM), ATM, comunicaciones, arquitectura del sistema y entorno.
Antes de proceder a desarrollar una metodologa para la

elaboracin de escenarios, se defini el trmino escenario como "la
descripcin preceptiva del estado futuro de un sistema o subsistema,
teniendo en cuenta las diversas restricciones y problemas que se
pretenden resolver con la implantacin de conceptos existentes o
nuevos". Desde la perspectiva de AEGIS, un escenario debera ser un
planteamiento vivo de un sistema, que se realimente de todos los
conocimientos y experiencias que se obtengan en el proceso de
investigacin y desarrollo que forma parte de su ciclo de vida. Este
ciclo de vida se muestra en la Figura 2.2.
Basndose en el ciclo de vida del sistema, el consorcio defini

una metodologa para elaborar escenarios, que se plasm en el
siguiente esquema o ndice:
1) Identificacin de las necesidades del cliente: consideracin

de las tendencias de la poltica y desarrollo de un esquema
inicial de soluciones;
2) Elaboracin de esquemas de soluciones: delimitacin del

rea temtica sobre el que versar el escenario y desarrollo
de grupos de objetivos/principios/soluciones para iniciar la
identificacin de soluciones alternativas;
24
3) Desarrollo de soluciones: exposicin en detalle de las

soluciones que propone el escenario;
4) Transicin: definicin de uno o varios caminos alternativos

para llegar al estado futuro que se propone, partiendo
del estado actual;
5) Mejoras previstas: identificacin de los efectos y beneficios

que se espera obtener con la implantacin del escenario; y
6) Conclusiones: resumen de los resultados del escenario y

planteamiento de propuestas para futuros trabajos.
Aplicando esta metodologa, el consorcio defini las necesidades

del cliente, basndose en los requisitos de alto nivel contenidos en el
anexo tcnico del contrato con la Comisin Europea y en las opiniones
de las lneas areas (usuarios del sistema ATM) expresadas en el libro
25
blanco editado por la Asociacin de Lneas Areas 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. Especficamente,

se requera un escenario de transicin hasta el ao 2015,
que contemplara mantener la intervencin humana en el
ciclo de toma de decisiones.
2) Estudio de las interacciones entre las lneas areas y los

sistemas ATM (por ejemplo, cooperacin entre los
sistemas embarcados y de tierra).
3) Identificacin de propuestas para aumentar la capacidad,

seguridad y calidad de los servicios del sistema de gestin
del trnsito areo.
Partiendo de estos objetivos generales, se definieron las seis reas

generales en que se iba a centrar el futuro escenario: (1) la organizacin
de ATM; (2) las alternativas para la gestin del espacio areo; (3) la
estrategia de automatizacin; (4) los aspectos funcionales; (5) el reparto
de tareas entre los sistemas embarcados y de tierra, entre sectores y
entre el hombre y la mquina; y (6) los aspectos de transicin. Estas
reas se desglosaron en las siguientes subreas: filosofa del sistema,
gestin del espacio areo, gestin de afluencia, comparticin de tareas
entre aire y tierra, estrategia de automatizacin, reparto de tareas entre el
hombre y la mquina, organizacin de la unidad de control, relaciones
entre ATM y las lneas areas, relaciones entre ATM y los aeropuertos,
relaciones entre ATM y el sistema militar, y comunicaciones/navegacin/
vigilancia (Communications/Navigation/Surveillance, CNS). Para cada
una de estas subreas, se identificaron varios conceptos, clasificados
globalmente como de carcter conceptual, organizativo o tcnico. Estos
conceptos se utilizaron para definir, en cada subrea, los objetivos del
futuro escenario, los principios que lo guiaran y las soluciones propuestas
para lograr los objetivos cumpliendo con los principios establecidos.
26
A continuacin, los conceptos se dispusieron en una matriz para

identificar su compatibilidad, incompatibilidad o independencia entre
s. El resultado de este ejercicio fue la identificacin de aquellos
conceptos que podran definir el futuro escenario AEGIS:
1) Filosofa ATM: no determinista (la situacin actual), o

determinista.
2) Estructura de ATM: integrada o en niveles.
3) Estrategia de automatizacin: completamente automatizado,

principalmente dependiente de la tecnologa o centrado en
la intervencin humana.
4) Gestin del espacio areo: cielos abiertos, concepto de

rutas fijas aeronuticas o cielos semi-abiertos.
5) Organizacin del control de trfico areo: AFM ejercido en

tierra, control de trfico areo 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 valoracin 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 Genrico e
Integrado para ATM y Redes (GIANTS). Otro escenario, el Sistema de
Trfico Areo 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 intervencin humana en el sistema, su carcter no determinista y su

estructura en seis niveles temporales decrecientes. Estos niveles, que
serviran de filtros sucesivos para ajustar la capacidad del sistema a la
demanda en cualquier momento dado, fueron los siguientes: gestin global
del sistema, planificacin estratgica, planificacin preoperativa, operacin
en tiempo real, redes de seguridad y anlisis posterior de datos.
En el desarrollo del escenario, se hicieron propuestas en cuatro

reas. En la primera, cooperacin entre aire y tierra, el escenario propuso
tres conceptos: la redundancia entre los sistemas embarcados y los de
tierra, la aeronave autnoma y la cooperacin 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 cooperacin
eficaz entre aire y tierra.
En las reas segunda y tercera, AFM ejercido en tierra y control

de trnsito areo 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 disearan
basndose en un anlisis detallado de las tareas que deben desempear.
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 transicin: hasta el ao

2000, del ao 2000 al 2005, y del ao 2005 al 2010. Se definieron los
requisitos para la transicin del sistema para cada una de estas fases.
2.5. Fase 3: consolidacin
En la tercera fase del proyecto se consolidaron los resultados

obtenidos en las primeras dos fases. Una vez definidos los requisitos
tcnicos y de transicin del escenario GIANTS, el consorcio dise una
metodologa especializada para analizar los costes y beneficios de
cualquier inversin en el sistema ATM. La metodologa, una vez
particularizada para el anlisis del escenario GIANTS, consisti en dos
pasos: (1) la obtencin de los parmetros de eficacia del sistema,
partiendo de los parmetros tcnicos, y (2) partiendo de los parmetros
de eficacia del sistema, la obtencin de los costes diferenciales de
operacin de las lneas areas que, por hiptesis, se consideraron los
beneficios del escenario.
El estudio concluy con un anlisis de sensibilidad. Este anlisis

dio por resultado que los beneficios diferenciales esperados tras la
implantacin del escenario GIANTS eran de un orden de magnitud mayor
que los costes diferenciales.
2.6. Valor aadido del proyecto
El escenario GIANTS que se ha propuesto en el proyecto AEGIS

deber ser capaz de resolver la mayora de los problemas actuales de
29
la gestin del trnsito areo. Sin embargo, se requerir una validacin

posterior de sus soluciones conceptuales, organizativas y tcnicas en
futuros estudios de investigacin y desarrollo, sobre todo de la nueva
estructura organizativa que se propone.
Como valor aadido, el proyecto AEGIS ha desarrollado dos

metodologas que se pueden aplicar en otros proyectos: una
metodologa para elaborar escenarios y una metodologa especializa-
da para el anlisis de los costes y beneficios de cualquier sistema de
gestin del trnsito areo.
2.7. Consideraciones finales
El proyecto AEGIS es un ejemplo de la primera fase del ciclo de

vida de un sistema: la identificacin o definicin de la necesidad.
Habiendo determinado que la capacidad actual del sistema de gestin
de trfico areo 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 definicin del futuro sistema, se

estudiaron diversos escenarios ATM (descripciones del estado futuro
del sistema de gestin de trnsito areo) 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 debern ser validadas por otros
proyectos, podrn servir de base para la definicin de los requisitos
operativos del futuro sistema, en un siguiente paso hacia el diseo del
sistema ATM del siglo XXI.
El planteamiento metdico y estructurado para determinar y

desarrollar las necesidades del cliente que se ha seguido en el proyecto
AEGIS puede ayudar en la definicin ms precisa de los requisitos
conceptuales de cualquier sistema.
30
31
3
Evaluacin de
desarrollos
basados en una
nueva tecnologa:
demostrador
PlanBA
32
3.1. El programa PlanBA
PlanBA (Plan de accin nacional para la Investigacin y

Desarrollo [I+D] en comunicaciones integradas de Banda Ancha) es
un programa promovido y financiado parcialmente por la Administracin
espaola. Su principal objetivo es disponer, a finales de 1995, de un
demostrador experimental de banda ancha que tome como ncleo la
red RECIBA desarrollada por Telefnica. PlanBA (1992-1995) es una
accin coordinada con la industria nacional sobre actividades de I+D
en banda ancha, en la que estn involucrados operadores, fabricantes
de productos de telecomunicacin y centros pblicos de investigacin.
En su organizacin, gestin y financiacin intervienen los organismos
de la Administracin con responsabilidad en la promocin de la
tecnologa de telecomunicaciones.
El ncleo de la actividad PlanBA consiste en la integracin y

puesta en operacin 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 Asncrono (MTA), una tecnologa de transmisin y
conmutacin de paquetes de longitud fija (clulas) que proporciona un
soporte muy flexible para el transporte de la informacin.
Cada elemento individual del demostrador, o grupo de ellos, es

desarrollado por un proyecto. Cada proyecto es realizado por un
33
Evaluacin de desarrollos basados en una nueva tecnologa: demostrador PlanBA
consorcio en el que participan empresas y organismos pblicos de

investigacin (OPIs) que trabajan de forma conjunta durante todo el
ciclo de vida del proyecto.
La coordinacin se realiza a travs de la participacin de los

organismos gestores y financiadores en el Comit de Gestin PlanBA.
Este Comit est soportado en sus actividades por la Oficina de Gestin
(Oficina PlanBA). Se ha constituido un grupo de personas con
experiencia multidisciplinar relacionada con la gestin, la investigacin
y el desarrollo de proyectos de ingeniera en comunicaciones de banda
ancha. La Figura 3.1 representa esquemticamente las interacciones
entre los diferentes agentes involucrados.
Actualmente, PlanBA est en la fase final de su desarrollo,

aunque este Captulo se centra en los aspectos de desarrollos que
avalen la viabilidad de la nueva tecnologa MTA, desarrollos que se
encuadran clsicamente dentro del diseo conceptual en la ingeniera
de sistemas. La evaluacin de desarrollos sobre una tecnologa
concreta determina el inters de dedicar recursos a esa tecnologa y,
lo que es ms importante, permite cuantificar la cantidad de recursos
necesarios. Mediante este tipo de anlisis se pueden establecer
calendarios y costes aproximados para la realizacin de prototipos
basados en la tecnologa en cuestin.
3.2. Evaluacin de desarrollos en PlanBA
La Administracin espaola, en base a la tecnologa emergente

del Modo de Transferencia Asncrono, que prometa 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 espaola ante los nuevos objetivos que
se apuntaban.
34
35
Se acord que la Direccin General de Telecomunicaciones

realizara un estudio de detalle sobre las posibles actuaciones que cabra
abordar, con el objetivo de incorporarlo a la nueva versin del Plan
Nacional de Telecomunicaciones (1991-2002).
La realizacin del estudio convoc a la Administracin, la industria

de telecomunicaciones, los operadores de red y los centros de estudio
e investigacin. Con objeto de identificar las necesidades, analizar los
requisitos, seleccionar el enfoque y proceder a la definicin funcional
del programa de actuacin, se crearon cuatro grupos de trabajo: (1)
Servicios, (2) Situacin espaola, (3) Tecnologa y (4) Plan de Trabajo.
El modelo conceptual que se deriv de los estudios fue facilitar la

coordinacin e integracin de experiencias previas mediante la participacin
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 potenciaran la I+D en la industria y los centros de investigacin. stas
deban permitir la integracin de los resultados en un demostrador que
permitiera comprobar el interfuncionamiento de resultados a la vez que
sirviera de demostracin para impulsar servicios y aplicaciones, as como
de banco de pruebas para distintas tecnologas, elementos y equipos.
El trabajo se llev a cabo en tres etapas:
1) Identificacin de tecnologas relevantes en banda ancha;

2) Identificacin de aplicaciones y usuarios; y
3) Definicin del plan de trabajo para la consecucin del
demostrador.
3.2.1 Identificacin de tecnologas relevantes en banda ancha
Se realiz un estudio tomando como material de partida una

definicin de actividades de I+D en comunicaciones de banda ancha.
36
En esta definicin participaron empresas y profesionales relevantes

del sector de las telecomunicaciones: operadores, fabricantes, institutos
oficiales y universidades.
El estudio inclua una descripcin para cada rea segn el

siguiente esquema: (1) justificacin de la necesidad de la tecnologa,
(2) subreas de la tecnologa, (3) objetivos y (4) estrategia.
En total, se identificaron ocho reas tecnolgicas: (1)

Microelectrnica, (2) Optoelectrnica, (3) Software, (4) Algoritmos y
Proceso de Seal, (5) Tecnologa de Conmutacin, (6) Arquitectura de
Sistemas, (7) Tecnologas de Diseo Fsico y (8) Tecnologas de Usuario.
Estas reas incluan a su vez otras veintiocho subreas. As, en

microelectrnica se contemplaban tecnologas bsicas y metodologas,
en tecnologa de conmutacin se consideraban las subreas de
conmutacin MTA y tcnicas de adaptacin e interfuncionamiento, etc.
3.2.2. Identificacin de aplicaciones y usuarios de banda ancha
En esta etapa, se realiz un estudio con los mismos participantes

de la etapa anterior para establecer las pautas de cmo deban
considerarse los escenarios de usuarios y aplicaciones, con objeto de
llevar a cabo una eficiente implantacin de las comunicaciones de
banda ancha.
Para identificar las potenciales aplicaciones y usuarios de las

tecnologas de banda ancha se llevaron a cabo tres anlisis
independientes:
1) Tendencias y perspectivas europeas: en primer lugar se

analiz la disponibilidad previsible de infraestructuras de
comunicaciones avanzadas en Europa. Tambin se estudiaron las
expectativas de mercado y las estimaciones de la demanda de este
37
tipo de comunicaciones. Finalmente, se hizo una revisin de pilotos

europeos de comunicaciones integradas de banda ancha.
Principalmente RACE y ESPRIT.
2) Identificacin de las facilidades especficas aadidas por la

tecnologa de banda ancha. Se realiz un anlisis matricial de acuerdo
a las variables siguientes: (1) estratificacin de usuarios, (2) funciones
de los usuarios y (3) aplicaciones genricas.
3) Anlisis de agentes: se identificaron a los particulares, a las

empresas y al sector pblico como los principales agentes.
A partir de los anlisis anteriores se determinaron las aplicaciones

ms 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 crdito y seguro

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

educacin.
3.- Agentes Particulares: (1) teleeducacin, (2) teletrabajo, (3)

telecompra y (4) ocio y entretenimiento.
3.2.3. Definicin del plan de trabajo para la consecucin del

demostrador
A partir del anlisis de las reas tecnolgicas ms relevantes

para las comunicaciones integradas en banda ancha, los mdulos
incorporados en otros pilotos europeos de los anlisis de demanda
de este tipo de tecnologas y las aplicaciones de mayor inters, segn
38
los expertos participantes en las reuniones de definicin, se

identificaron una serie de elementos a desarrollar en el demostrador
(ver Figura 3.2).
Se procedi a la identificacin y cuantificacin de medios

(recursos humanos, inversiones en equipamiento, etc.) de forma que
integrados y secuenciados debidamente en el tiempo permitieran la
realizacin del demostrador para satisfacer las necesidades y los
objetivos estratgicos planteados en la definicin de las acciones. A
partir de las experiencias aportadas por los expertos se elabor una
tabla de estimaciones para los recursos humanos (hombres * ao) 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

Integracin 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 formacin de

consorcios entre empresas y centros pblicos de investigacin con
objeto de que se desarrollara en lo posible un nico proyecto por cada
uno de los elementos a desarrollar.
Finalmente, se previ una dotacin econmica (Fondo de

Integracin) para la inversin en posibles rplicas de prototipos no
previstas inicialmente o para aumentar la funcionalidad de ciertos
elementos.
3.3. Evolucin del proyecto integrado PlanBA
Desde su inicio en 1992 hasta 1995 se incorporaron 16 proyectos

que cubran los objetivos generales establecidos al inicio. En los
proyectos aprobados intervienen: 22 empresas pertenecientes al sector
39
40
41
de las tecnologas de la informacin y las comunicaciones, 10 grupos

investigadores de universidades y centros pblicos de investigacin y
8 usuarios de aplicaciones (hospitales, cadenas hoteleras y organismos
relacionados con la educacin).
El proceso de evolucin 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 pblicas
de los logros obtenidos por la industria y la universidad espaola en el
marco de este programa.
42
43
4
Especificacin
de requisitos
en el programa
MIDS
44
4.1. El sistema MIDS
MIDS ("Multifunctional Information Distribution System", Sistema

Multifuncional de Distribucin de Informacin), es un sistema de
comunicaciones, navegacin e identificacin (de aqu la
multifuncionalidad) que permite intercambiar voz y datos entre usuarios
distribuidos en una amplia zona geogrfica.
Los usuarios del MIDS son los aviones y helicpteros militares,

buques de guerra y unidades terrestres. Las ventajas que aporta la
utilizacin del MIDS en relacin con los sistemas actualmente existentes
son bsicamente tres:
1. La seguridad de las comunicaciones, ya que es muy difcil

interceptar los mensajes transmitidos por el sistema MIDS.
2. La resistencia a las interferencias externas de radio, en

ambientes electromagnticamente muy densos, como son
los que suelen encontrarse en las operaciones militares.
3. La interoperatividad entre usuarios muy diversos, de ejrcitos e

incluso pases distintos, al aportar un alto grado de estandarizacin
en la obtencin de las funciones suministradas por el sistema.
Tcnicamente el MIDS es un sistema muy complejo [11, 12],

que funciona con un alto grado de automatizacin e incorpora
45
Especificacin de requisitos en el programa MIDS
tecnologas muy avanzadas. Los equipos para el intercambio de

informacin a travs del MIDS se llaman terminales y el programa
multinacional MIDS que aqu se comenta tiene por objeto el diseo,
desarrollo y produccin masiva de un modelo nico de terminal MIDS
vlido para todo tipo de usuarios, terrestres, navales y areos.
4.2. El programa MIDS
En la actualidad, el programa se encuentra en su fase de diseo

y desarrollo. Las actividades de ingeniera de sistemas que se
comentan en este Captulo se realizaron durante la fase de
especificacin 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 realizacin 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 da a da
del mismo.
Por otra parte, se ha constituido un Comit Director del programa,

que toma las decisiones de gestin del programa, y tiene delegadas
ciertas atribuciones en una Oficina Internacional de Programa (IPO).
Tanto en la IPO como en el Comit Director estn 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 travs de
un contrato nico firmado por la IPO y MIDSCO, que actan por
delegacin de las distintas partes.
46
4.3. Actividades previas a la fase de desarrollo
A continuacin se comentan brevemente las actividades principales

del programa durante la fase de especificacin de requisitos. La lista no
es completa, ya que no figuran en ella, por ejemplo, los aspectos logsticos.
Slo se pretende exponer unos cuantos ejemplos tpicos que sirvan para
ilustrar el proceso de la ingeniera de sistemas. Isdefe ha participado en
todas las actividades descritas a lo largo de esta Seccin.
4.3.1. Preparacin de la peticin de oferta
La peticin de oferta incluye: clusulas contractuales;

especificaciones tcnicas; definicin de trabajos / desglose de tareas; y
lista de productos entregables.
La peticin de oferta constituye un extenso paquete de

documentos que contiene toda la informacin detallada necesaria para
47
contratar los trabajos industriales del programa. La participacin de

los grupos de ingeniera en estas actividades ha sido muy intensa en
las siguientes reas:
1) Clusulas contractuales
Se han discutido con otras naciones qu elementos de configuracin

hardware, software y servicios eran exactamente objeto de contrato, y en
qu condiciones. Los principales elementos contratados son:
a) Diseo del terminal MIDS.

b) Diseo de un simulador de interfaz del MIDS.
c) Prototipos de terminales.
d) Simuladores.
e) Apoyo logstico para todo lo anterior (repuestos, formacin,
mantenimiento, etc).
Para disponer de una versin definitiva de clusulas

contractuales, se ha realizado una labor de anlisis de las clusulas
de las FAR (Federal Acquisition Regulations, Regulaciones Federales
de Adquisicin), que deban 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 legislacin 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 tcnicas
La redaccin de las especificaciones tcnicas que debe cumplir

el terminal MIDS ha sido sin duda la actividad que ms recursos de
ingeniera ha consumido en toda la preparacin previa a la fase de
desarrollo. Para ello, se han formado varios grupos multinacionales, con
representantes tcnicos de todas las naciones participantes, y se han
ido discutiendo todos los temas tcnicos que intervienen en el terminal.
48
3) Seleccin de la documentacin aplicable
Una parte importante de la actividad de los grupos tcnicos

responsables de la redaccin de especificaciones tcnicas es el anlisis
y seleccin de la normativa aplicable para cada elemento hardware y
software del futuro terminal MIDS. Esto supone el estudio de un alto
nmero de estndares 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

armonizacin de las distintas normativas existentes en relacin 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 decisin final debidamente razonada y documentada. Un tema
tpico que ha exigido varias actuaciones de este tipo es el de la
compatibilidad electromagntica (Electromagnetic Compatibility, EMC).
4) Metodologa de trabajo
Para preparar el documento de especificaciones tcnicas, se

ha seguido un procedimiento iterativo de reuniones de trabajo
multinacionales, perodos 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 versin

definitiva es el documento de especificaciones tcnicas del terminal
MIDS, cuyo nombre es System Segment Specification (SSS) y que
establece cul ha de ser el funcionamiento global del terminal y los
requisitos a los que deber ajustarse su cualificacin completa.
La organizacin 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 definicin de especificaciones tcnicas. El documento SSS contiene
en primer lugar el alcance e identificacin de la especificacin. A
continuacin 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 caractersticas
fsicas y los estndares mnimos que ha de satisfacer su diseo y
construccin. Esta seccin de requisitos es la ms voluminosa de la
SSS y la que ms recursos exige en su preparacin. A continuacin se
incluye una seccin sobre requisitos en materia de garanta de calidad,
otra seccin sobre preparacin para entrega de terminales a los usuarios,
y una ltima seccin con informacin complementaria para aclarar
determinados aspectos de las secciones anteriores.
Dado que el terminal MIDS ha de servir para una amplia variedad

de plataformas, se revel prcticamente imposible reunir en un nico
documento comn todos los requisitos exigibles a las distintas
plataformas usuarias. Por ello, se recurri, a aadir 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 preparacin de la SSS, se
puso el mayor inters en que dichos anexos contuvieran el mnimo de
requisitos exclusivos, de forma que la mayora de los requisitos de las
plataformas estuviera ya contemplada en el cuerpo principal comn
de la SSS. Se adopt esta filosofa para obtener un diseo comn, ya
que esta comunalidad es precisamente un objetivo bsico del
programa.
50
Las principales categoras de elementos objeto de especificacin

durante esta actividad fueron las siguientes: proceso de seal MIDS;
estructura de mensajes/proceso de mensajes; esquemas de modulacin
y demodulacin; interfaces externas del terminal; caractersticas fsicas;
fiabilidad, mantenibilidad y prueba incorporada (Built-In Test, BIT);
condiciones ambientales; alimentacin; logstica/adiestramiento/
personal; y verificacin.
De esta forma se ha ido consolidando un borrador, cuya

versin definitiva es la Especificacin 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 configuracin y se acepten por todas las
naciones las consecuencias tcnicas, econmicas y operativas de
los cambios introducidos. Esta actividad de refinamiento del
documento contina an en la actualidad, si bien con una reducida
aportacin de recursos.
5) Verificacin de requisitos/matriz de verificacin
En la seccin de la Especificacin de Segmentos del Sistema

dedicada a la garanta de calidad, se incluyeron los requisitos
necesarios para la verificacin del diseo y comportamiento del
hardware y el software del terminal MIDS. Las distintas verificaciones
contempladas en la SSS se clasificaron en cuatro grupos:
Verificaciones de ingeniera, para detectar y corregir a tiempo

las deficiencias del diseo. 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 verificacin debidamente
aprobados.
Verificaciones de alistamiento para la integracin, para

garantizar que el desarrollo del terminal MIDS ha progresado lo
suficiente como para poder abordar los trabajos de integracin 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 cualificacin, para demostrar que un diseo

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 categoras de pruebas: funcionalidad; software; ambientales;
compatibilidad e interferencia electromagnticas; fiabilidad y
mantenibilidad; calidad de la voz/tasa de errores; alimentacin/pruebas
trmicas; diseo estructural; e interoperatividad.
Verificaciones de aceptacin, para comprobar que todo elemento

entregado por MIDSCO est en buen estado. Estas pruebas se aplican
tanto a los distintos mdulos que configuran el terminal MIDS, como al
propio terminal completo. Tambin en este tipo de pruebas se exigi la
adopcin de planes y procedimientos aprobados por las naciones.
En cuanto a los mtodos de verificacin, se identificaron los

cinco siguientes, por orden creciente de complejidad y profundidad:
inspeccin, anlisis, certificacin, demostracin y prueba.
En base a todos los elementos anteriores, se construy una

matriz de verificacin, en la que se identificaban todos los requisitos
especificados para el terminal MIDS, y el mtodo de verificacin a
utilizar en las pruebas formales (cualificacin y aceptacin).
6) Definicin de trabajos / desglose de tareas
Adems de definir las caractersticas tcnicas 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 definicin de tareas se especifica en el Statement Of

Work (SOW) que es la Definicin deTrabajos, donde se explican
todas las tareas a realizar, se indican las normas que ha de cumplir
el contratista en la realizacin de dichas tareas y se asocia cada
tarea especificada con el contenido de las clusulas contractuales
y, en algunos casos, con productos entregables, al objeto de poder
realizar posteriormente el seguimiento de dichas tareas. Tambin
en el caso del SOW se ha especificado la aplicabilidad y el alcance
de los estndares 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 descomposicin en rbol de todo el
programa, que puede analizarse a distintos niveles de agregacin,
desde el programa completo, hasta las actividades ms elementales.
7) Lista de productos entregables
Todos los productos entregables estn descritos en una lista

de documentos denominados CDRLs (pronunciado sidrals). El
significado de este acrnimo en ingls 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 indicacin asimismo de lugar de entrega, plazo de
entrega, lista de distribucin, etc.
La informacin 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 tcnica. Por ejemplo, existen DIDs para informes de reunin,
para documentos de interfaz, para planos mecnicos, etc. En los casos
en que no se dispone de un DID para una necesidad especfica, se
redacta uno nuevo para cubrir dicha necesidad, y se incorpora en el
53
paquete de documentacin contractual, asociado con uno o ms

documentos del CDRL.
4.3.2. Reduccin de prestaciones tcnicas
Cuando las naciones participantes dispusieron de una oferta

formal de MIDSCO, conforme con el paquete contractual que se haba
emitido, los precios ofertados se consideraron demasiado elevados.
Al margen de una negociacin del precio, discutiendo uno tras otro
todos los elementos que figuran en el contrato, las naciones acordaron
reducir ligeramente algunas de las prestaciones tcnicas, siempre que
el impacto resultante sobre la operatividad del terminal MIDS fuese
tolerable.
Para realizar esta labor de reduccin de prestaciones tcnicas,

fue preciso revisar completamente las especificaciones tcnicas,
analizando en qu medida se podan realizar cambios en los requisitos
contemplados en dicho documento. Este trabajo se realiz en dos fases,
y se ha prolongado aproximadamente durante un ao. El mtodo de
trabajo a seguir ha sido anlogo al de redaccin de especificaciones
tcnicas. Las naciones presentaban sus propuestas de reduccin, se
formaba una propuesta consolidada y peridicamente se reunan
grupos de trabajo especializados, con asistencia de personal tcnico
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 aprobacin formal o devolucin.
4.3.3. Negociacin 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

contratacin (la Oficina Internacional del Programa), ha tenido que
analizar, discutir y aceptar o rechazar.
La negociacin 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 lnea base
Una vez aceptada la reduccin 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 lnea
base.
Esto significa que, dada la complejidad de las tareas a realizar,

los mltiples cambios introducidos, y las discusiones relacionadas con
el reparto de tareas y costes entre empresas nacionales, es preciso
realizar una revisin completa de la configuracin resultante del
contrato. Este proceso de revisin de lnea 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 bsico
para aprovechar al mximo la participacin de las naciones en el
programa.
55
Dentro de las actividades del seguimiento industrial, los

principales hitos en este programa son los siguientes:
a) Revisin preliminar del diseo.

b) Revisin crtica del diseo.
c) Ensayo preliminar de cualificacin.
d) Auditora de cualificacin formal.
4.3.6. Seguimiento de costes
El contrato del MIDS es del tipo de costes incurridos, en el que se

resarce al contratista de todos sus costes, y se le paga adems un
beneficio que ha sido objeto de negociacin. Por eso es del mximo
inters para el cliente (las naciones participantes) realizar un seguimiento
de costes, al objeto de ir analizando el progreso del programa. En este
contexto resulta bsico el concepto de valor ganado, que va ms all
de una mera cuenta del gasto producido. El valor ganado es una medida
del trabajo realmente realizado por el contratista en un perodo
determinado, e indica a un cierto nivel, lo que realmente se obtiene
como contraprestacin del dinero que se ha gastado en dicho perodo.
En el programa MIDS el valor ganado se mide con periodicidad mensual.
Para ello los contratistas han de presentar unos informes de seguimiento
de costes que permiten calcular, al nivel de agregacin del desglose de
tareas que se desee, el valor ganado terico (el establecido en la lnea
base del contrato), el valor ganado real, y las desviaciones producidas,
tanto en costes como en plazos de ejecucin. Una vez conocidas las
desviaciones producidas, se estudia la posibilidad de adoptar o no
acciones correctoras.
4.3.7. Gestin del espectro radioelctrico
Dado que el MIDS es un sistema de transmisin por radio, en la

banda de UHF, su utilizacin real requiere una autorizacin
56
administrativa para la utilizacin del espectro radioelctrico. La banda

de frecuencias en que funciona el sistema MIDS es utilizada tambin
por otros sistemas aeronuticos, 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 tcnicos para determinar en qu condicio-
nes se podran realizar las transmisiones, por ejemplo, fijando unas
distancias mnimas entre emisores, zonas de exclusin, reduciendo la
densidad de pulsos, etc. En todos los casos, el MIDS acta como usua-
rio secundario de la banda, lo cual significa, segn el Reglamento de
Radiocomunicaciones que, en caso de interferencias, los dems sis-
temas tendrn prioridad sobre el MIDS.
Todos estos trabajos, de alto contenido tcnico, se desarrollan

dentro de otro grupo, separado de la actividad industrial de desarrollo
del terminal MIDS. El grupo de Gestin 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 tcnicas y operativas mnimas que
deben cumplir los equipos para operar en la misma banda de
frecuencias. La Especificacin de Segmentos del Sistema incluye
varios apartados para definir protecciones especficas 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 definicin de las especificaciones tcnicas

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 especificacin
57
final, se dispone de una alta granularidad en la posterior verificacin

de requisitos, y por aadidura, la fase de pruebas ha quedado
preconfigurada desde una fase muy temprana del programa.
En cuanto a la actuacin de Isdefe como parte de la

representacin espaola, aunque el liderazgo de los grupos tcnicos
de especificacin estuvo ostentado por otro pas (EEUU), la
participacin directa en las discusiones ha permitido acumular una
amplia base metodolgica y tcnica de conocimientos a los que no se
puede acceder por otras vas. En otras palabras, gran parte de lo
aprendido como consecuencia de la participacin en la definicin de
especificaciones del MIDS es consecuencia del trabajo diario de unos
equipos punteros dentro de su sector.
58
59
5
Anlisis de riesgos
durante la evaluacin
de ofertas en el
programa SANTIAGO
60
5.1. El programa SANTIAGO
El objeto principal del programa SANTIAGO es la captacin de

emisiones electromagnticas y de imgenes en las zonas definidas
como de inters estratgico para la seguridad nacional. El sistema
obtenido deber complementar los medios especficos ya existentes a
nivel estratgico, con el fin de: apoyar a los centros de fusin y anlisis
de datos de guerra electrnica; 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 mviles, semimviles y fijos que, disponiendo de
capacidades de inteligencia de comunicaciones, inteligencia electrnica
e inteligencia ptica, proporcionen una cobertura ptima del espacio
estratgico de inters 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 integracin global. Algunos
de estos subsistemas se encuentran en su fase ms temprana, la
especificacin de requisitos (estudios de viabilidad), otros en la fase
de diseo y desarrollo y otros en la fase final de construccin (pruebas
tipo 3, [6]).
61
Anlisis de riesgos durante la evaluacin de ofertas en el programa SANTIAGO
5.2. Anlisis de riesgos
En este Captulo se describe la metodologa empleada durante

los dos ltimos aos en el programa SANTIAGO, para efectuar el
anlisis de riesgos durante el proceso de evaluacin de las ofertas
presentadas para los diferentes subsistemas. Este anlisis abarca los
procesos de identificacin y valoracin de los riesgos, sin entrar en el
tratamiento de la gestin y reduccin de los mismos. Dentro de este
esquema el anlisis de riesgos ha servido como un elemento ms de
apoyo a la toma de decisin.
Esto supone que dentro de este Captulo nos ceiremos,

dentro del proceso general de ingeniera de sistemas, a la fase de
evaluacin de ofertas situada en la lnea divisoria entre el diseo
conceptual y el diseo preliminar del subsistema. Debe quedar claro,
sin embargo, que el anlisis de riesgos es un proceso iterativo que
se extiende ms 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 metodologa

para adquisicin de sistemas de armas Phased Armaments
Programming System (PAPS) de la OTAN. Esta metodologa
impone la realizacin previa de estudios de viabilidad y definicin
de los sistemas. En los estudios de viabilidad se realiza un anlisis
de los riesgos tecnolgicos asociados a los mismos que,
lgicamente, es utilizado como punto de referencia fundamental
en el momento de definir la solucin final propuesta. La propia
redaccin del Pliego de Bases es otro de los elementos crticos
en el proceso de anlisis y gestin 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 consecucin, 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 metodologa utilizada
5.3.1. Objetivos
Cuando se comenz a disear la metodologa que deba

emplearse para efectuar el anlisis de riesgos dentro del proceso
general de evaluacin 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 valoracin de las ofertas,
no de su anlisis de riesgo. El proceso de valoracin de
ofertas se trata especficamente en el captulo dedicado al
programa SIMCA de esta monografa.
2) Permitir la comparacin directa de los resultados conseguidos

para las distintas alternativas (ofertas). La necesidad de la
comparacin directa se deriva de la utilizacin del anlisis
de riesgos como soporte a una toma de decisin.
3) Facilitar la incorporacin a la metodologa de lo aprendido

en cada aplicacin de la misma, puesto que se pensaba en
su utilizacin reiterada.
La metodologa diseada finalmente, que aparece resumida en

la Figura 5.1, se descompone en cuatro grandes fases: (A) identificacin
de riesgos; (B) evaluacin del impacto que la aparicin de cada uno
de los riesgos identificados tendra en el desarrollo del programa; (C)
cuantificacin de la probabilidad de aparicin de cada uno de los
riesgos; y (D) integracin de los resultados. Esta metodologa se utiliz
por primera vez durante la evaluacin de ofertas de uno de los
subsistemas del segmento terrestre.
63
5.3.2. Identificacin
La identificacin de riesgos es el primer paso de la metodologa;

consisti en enumerar las posibles desviaciones que podan producirse
en el subsistema respecto a lo ofertado. Para afrontar el requisito
relativo a la necesidad de la comparacin 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 preparacin de la evaluacin, previa
a la recepcin de las ofertas.
La generacin de este diccionario de riesgos se efectu

mediante una descomposicin descendente. El pliego se
descompuso en grandes reas de riesgo. Aunque no es
imprescindible, desde que esta metodologa se est aplicando
dentro del programa SANTIAGO, las reas de riesgo han coincidido
con las consideradas para la evaluacin: tcnica, gestin, industrial
64
y econmica. Estas reas tratan con los riesgos asociados al

desarrollo del sistema en los aspectos de prestaciones tcnicas,
calendarios, retorno industrial y costes. Cada una de estas reas
se descompuso, a su vez, en bloques de riesgo, agrupaciones
lgicas y estructuradas de informacin bajo la ptica de cada una
de las reas. As, por ejemplo, el rea tcnica 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 operacin y recursos operativos que debe
proporcionar el sistema.
c) Desarrollo software: agrupamiento de riesgos asociados a

la metodologa y normativa de desarrollo.
d) Instalacin: agrupamiento de riesgos asociados a la

transicin o instalacin del nuevo sistema.
e) Apoyo Logstico: agrupamiento de riesgos asociados a la

fiabilidad, mantenibilidad, abastecimiento y formacin.
El ultimo paso en el proceso de identificacin fue la

descomposicin de cada uno de estos bloques en elementos de riesgo.
Un elemento de riesgo se defini como una posible desviacin respecto
de lo ofertado. Sin embargo, como resultado de la aplicacin prctica
de esta metodologa, se detect la necesidad de incluir tambin como
elemento de riesgo la falta de una definicin detallada de lo ofertado,
ya que efectivamente la falta de definicin de la oferta introduca un
evidente grado de incertidumbre sobre el resultado final a obtener.
Con objeto de facilitar la cuantificacin de los elementos de riesgo,
para cada una de las ofertas, stos iban acompaados por una
descripcin de lo que deba cuantificarse.
65
Aunque la identificacin de riesgos se llev a cabo

fundamentalmente durante el proceso de preparacin de la
evaluacin, tras la recepcin de las distintas ofertas se detectaron
nuevos elementos de riesgo, que fueron incorporados al diccionario
inicial.
5.3.3. Evaluacin del impacto
El segundo paso consisti en la evaluacin del impacto que la

aparicin de cada uno de los elementos de riesgo, identificados en el
proceso anterior, podra tener para el desarrollo del subsistema. El
objetivo fundamental de esta evaluacin del impacto fue estimar el
efecto que cada una de las posibles desviaciones detectadas causara
en el subsistema final a obtener. Esta tarea se realiz antes de la
recepcin de las ofertas y simultneamente a la identificacin de los
riesgos.
Con objeto de facilitar el proceso, la evaluacin se efectu

siguiendo la misma descomposicin descendente que se generaba en
la identificacin 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 constituan. 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 normalizacin 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 perteneca y del rea que contena dicho bloque.
66
Desde el momento de la propia concepcin de la metodologa

descrita se detect que la evaluacin del impacto no poda ser
nicamente el resultado de un proceso tcnico. La evaluacin del impacto
deba estar condicionada por las prioridades de programa evaluado y
por la propia sensibilidad del decisor, responsable final de la adjudicacin,
es decir, por su funcin de utilidad. Para ello, la asignacin de pesos
anteriormente descrita se realiz, al menos en los niveles superiores de
la estructura jerrquica, siguiendo los criterios del Jefe de Programa.
5.3.4. Cuantificacin de la probabilidad
Una vez recibidas las ofertas se procedi a la cuantificacin de

la probabilidad de los elementos de riesgo para cada una de las
ofertas. Debe destacarse que, con la metodologa 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
cuantificacin para las distintas ofertas se tradujo, de forma prctica,
en la asignacin 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 asignacin, aunque se efecto de la forma ms objetiva

posible, carece de las ventajas asociadas al formalismo matemtico. La
cuantificacin del grado de ocurrencia por mtodos matemticamente
formales no fue realizada por dos causas fundamentales:
1) Estimar estas probabilidades de modo estadstico result

imposible debido a la ausencia de un espacio muestral
nacional sobre el que extraer datos.
2) La estimacin de una probabilidad, en el sentido axiomtico

del trmino, mediante tcnicas como la de Churchman-
Ackoff, Delphi o similares, hubiera requerido un esfuerzo
67
muy significativo en trminos de horas-hombre. Como

resultado de este esfuerzo se obtendran nicamente las
ventajas asociadas al puro formalismo matemtico, pero se
complicara notablemente la metodologa sin aportar un
incremento de la objetividad.
El mecanismo de asignacin adoptado supuso, desde el punto

de vista prctico, algunas ventajas importantes: sencillez, facilidad de
modificacin, comprensin por parte del decisor y adecuacin a la
percepcin subjetiva del evaluador. Para un mejor aprovechamiento
la cuantificacin numrica se acompa de unos comentarios
justificativos de la misma, los cuales incluan la identificacin de los
puntos o prrafos de la oferta en los que se haba detectado la posible
aparicin del elemento de riesgo.
Merece destacarse que, mientras la identificacin y la evaluacin

del impacto de los riesgos se realizaron en el proceso de preparacin
de la evaluacin, la cuantificacin de los mismos se efectu
especficamente para cada una de las ofertas durante el proceso de
evaluacin propiamente dicho. La Figura 5.2 muestra la relacin entre
el anlisis de riesgos y el procedimiento general de evaluacin de
ofertas. Adems, y a diferencia de los procesos anteriores que se
ajustan a una descomposicin descendente, la cuantificacin de riesgos
se realiz nicamente para el nivel inferior de dicha descomposicin.
5.3.5. Integracin
Finalmente se procedi a la integracin de los resultados

obtenidos mediante el anlisis de riesgo de las distintas ofertas. Dicha
integracin se llev a cabo recorriendo, desde los niveles inferiores
hacia los superiores, la jerarqua generada para la identificacin de
riesgos. Esta operacin permiti asignar un valor numrico 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 descompona, el producto de su probabilidad, o grado de ocurrencia,
por su impacto, o peso ponderado, dentro del bloque. De forma anloga
se obtuvo el nivel de riesgo para cada una de las reas y para el
global de las diferentes ofertas, consiguindose un valor del nivel de
riesgo, para las diferentes ofertas, que poda variar tericamente entre:
Cero (grado de ocurrencia nula de cualquier factor de riesgo que
pudiera tener algn impacto sobre el desarrollo del programa) y Diez
(probabilidad casi segura, o grado de ocurrencia evidente, de
factores de riesgo que impediran el desarrollo esperado del programa).
En la prctica los resultados variaron entre 3,9 y 5,6. Merece

destacarse que, en las primeras aplicaciones de la metodologa, se
ha observado una cierta aversin de los evaluadores a asignar
probabilidades muy altas o muy bajas a la aparicin de los elementos
de riesgo.
Los resultados de esta integracin, adems de en un formato

tabular numrico y comentado, se ofrecieron al decisor en forma de
grficos comparados para las distintas ofertas. Estos grficos
presentaban tanto el perfil como la contribucin al riesgo de cada una
de las ofertas. Los grficos de perfil de riesgo permitan visualizar, por
ejemplo, los niveles de riesgo de las diferentes reas obtenidos para
cada una de las ofertas evaluadas. Los grficos de contribucin al
riesgo presentan la misma informacin, pero ponderada por el impacto
o peso relativo de cada una de las reas. La inclusin de este tipo de
grficos result una ayuda valiosa para detectar en qu reas o bloques
la presencia de altos niveles de riesgo era especialmente indeseable.
5.3.6. Automatizacin del proceso
Toda la metodologa descrita en este captulo se implement en

una herramienta informtica, EVALOFER, que integra los cuatro pasos
70
descritos para el anlisis de riesgo dentro del proceso global de la

evaluacin de ofertas. Esta herramienta, aunque conceptualmente
sencilla, ha tenido que ser desarrollada especficamente para tal fin.
La utilizacin de EVALOFER, junto con la aplicacin de una
metodologa normalizada, que especifica procesos y asigna
responsabilidades dentro del programa SANTIAGO, ha permitido tanto
la automatizacin relativa del proceso como la obtencin de resultados
objetivos y fcilmente manejables. La Figura 5.3 muestra una pantalla
de la mencionada herramienta informtica correspondiente a la
integracin de resultados.
El anlisis de riesgos debe contemplarse como una de las reas

fundamentales dentro de la ingeniera de sistemas con un influencia
directa en el apoyo a la toma de decisiones. Este tipo de anlisis es
una labor recurrente que debe efectuarse tanto durante la fase de
seleccin de alternativas como durante el seguimiento de los
programas. Todo ello con el doble propsito de tratar de cuantificar,
71
a priori, los riesgos asociados a las distintas alternativas y apoyar la

gestin de riesgos encaminada a su minimizacin.
La frecuencia con que, durante el desarrollo de un programa, se

presentan desajustes entre los costes, plazos y prestaciones tcnicas
previstas y las finalmente alcanzadas deben hacernos reflexionar sobre
la importancia que debe concederse al anlisis de riesgos desde las
fases ms tempranas del desarrollo de un programa.
La dificultad principal con que tropieza el anlisis de riesgos

durante las fases iniciales del desarrollo de un sistema es la escasez
de informacin y definicin. Esta escasez impide en muchas
ocasiones la cuantificacin formal del riesgo, conduciendo a un
entorno de decisin de casi incertidumbre. La forma ms eficaz de
superar estas dificultades es utilizar la experiencia acumulada en
proyectos anteriores, articulando un procedimiento que facilite esta
reutilizacin.
Estamos seguros que la metodologa aqu descrita es

perfeccionable, de hecho se mejora con cada aplicacin de la misma.
Pese a ello no pueden dejar de destacarse algunos logros que, tal
vez por la simple sistematizacin, y pese a los diseadores y
operadores de la metodologa, se han hecho patentes con el
transcurrir del tiempo:
1) El empleo de esta metodologa resalta aquellos aspectos

de cada una de las ofertas que pueden constituir elementos
de riesgo. La enfatizacin de estos aspectos permite, al
menos, la peticin de una clarificacin sobre los mismos.
En muchos casos es posible la realizacin de una
negociacin especfica, sobre los puntos crticos, previa a
la adjudicacin.
72
2) El diccionario de riesgos generado por la aplicacin sucesiva

de la metodologa descrita, y posterior seguimiento de los
subprogramas, se ha mostrado como un punto de partida
eficaz en el momento de encarar la realizacin del anlisis
de riesgos correspondiente a un nuevo proceso de
evaluacin de ofertas.
3) La sencillez formal de la metodologa utilizada, pese a los

inconvenientes anteriormente expuestos, se traduce en un
alto nivel de confianza en la misma por parte del decisor, el
cual, adems de comprender su enfoque global, es capaz
de controlar la importancia relativa de sus distintos
componentes.
73
74
75
6
Procedimiento de
evaluacin de
ofertas en el
programa SIMCA
76
6.1. Descripcin general del programa SIMCA
El programa Sistema de Mando y Control Areo (SIMCA) del

Ejrcito del Aire tiene como objetivo disponer de un sistema que permita
conocer la situacin en todo el espacio areo de responsabilidad y
que facilite la toma de decisiones en la conduccin de las operaciones
areas 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 informacin
con otros sistemas. Consta de tres subsistemas: Mando y Control,
Vigilancia y Comunicaciones.
El SIMCA sustituir al actual sistema Semiautomtico de Defensa

Area (SADA), operativo desde el ao 1977 y formar parte del futuro
Sistema de Mando y Control Areo de la OTAN (ACCS) que a su vez
sustituir al sistema actual de control y deteccin de la Alianza NADGE
(NATO Air Defence Ground Environment) [13,14].
Para realizar dicha transformacin se estn realizando

proyectos, en cada uno de los tres subsistemas mencionados, que
se encuentran en diversas fases de ejecucin. Unos se encuentran
en fase de definicin y especificacin de requisitos, otros en fase de
evaluacin de ofertas y otros en estado ms avanzado como son la
realizacin de revisiones crticas, fabricacin y produccin de
prototipos y primeras series con la realizacin de las correspondientes
pruebas de validacin.
77
Procedimiento de evaluacin de ofertas en el programa SIMCA
Las reas de actividad en las cuales se est desarrollando la

participacin 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) Anlisis de necesidades;
b) Estudios de alternativas;
c) Especificacin de requisitos (operativos, funcionales y
tcnicos);
d) Evaluacin de ofertas;
e) Seguimiento y control de proyectos;
f) Pruebas de aceptacin del sistema;
g) Auditoras y dictmenes tcnicos; y
h) Garanta de calidad.
En el seguimiento de los proyectos del programa SIMCA el

captulo relativo a la evaluacin de las ofertas presentadas por los
posibles contratistas, en respuesta a un Pliego de Prescripciones
Tcnicas (PPT) donde se definen los requisitos tcnicos y operativos
que deben cumplir los sistemas o equipos requeridos, es un aspecto
que condiciona la obtencin 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 evaluacin de ofertas se puede confundir con
este y que es el del anlisis de riesgos. Este ltimo se emplea
como complemento del anterior en aquellos proyectos en los
cuales, a la hora de tener que tomar una decisin sobre una u
otra solucin propuesta, estas se basen en nuevos diseos o
desarrollos (I+D) que impliquen o conlleven cierto riesgo en su
ejecucin. Aspectos especficos relativos al anlisis de riesgos
se tratan en el Captulo dedicado al programa SANTIAGO de esta
monografa.
78
El proceso de evaluacin 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 eleccin de un
equipo o sistema con unas prestaciones o caractersticas degradadas,
comparndolas con las requeridas, puede suponer un encarecimiento
considerable del ciclo de vida logstico del producto adems de la
insatisfaccin del usuario.
El procedimiento de evaluacin debe basarse en mtodos lo

ms objetivos posibles, de manera que dicho procedimiento sea
transparente.
6.2. Evaluacin de ofertas. Metodologa
6.2.1. Introduccin
En el proceso de evaluacin de ofertas, y principalmente en

proyectos donde los sistemas o productos a obtener sean de cierta
envergadura tanto tcnica como econmica, 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 tambin 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 especificacin 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 adquisicin del sistema o equipo

que satisfaga las necesidades del usuario depender en gran medida,
adems del nivel de detalle y calidad con el que haya sido
confeccionada la especificacin de requisitos tcnicos, del mtodo de
evaluacin utilizado para seleccionar la oferta ms adecuada.
79
Existen diversos mtodos o procedimientos para la realizacin

de evaluaciones, pero independientemente de cual sea el elegido todos
ellos deben cumplir o perseguir una serie de objetivos bsicos:
a) Objetividad y transparencia en el proceso;

b) Precisin;
c) Agilizar y facilitar la evaluacin;
d) Obtencin de un producto acorde con los requisitos y que
satisfaga o posea la mejor relacin calidad-precio; y
e) Permitir la justificacin de la eleccin realizada.
Entre las ventajas que comporta la realizacin de una evaluacin

llevada a cabo en base a una metodologa objetiva se pueden destacar
las siguientes:
a) Reducir, o al menos ponderar, la incertidumbre;

b) Facilitar la posterior utilizacin de resultados;
c) Normalizar el proceso de presentacin y seleccin;
d) Aumentar la transparencia del proceso de seleccin;
e) Aumentar la credibilidad del organismo evaluador; y
f) Mejorar la comunicacin tanto interna del organismo que
evala como externa con las empresas.
6.2.2. Procedimiento de evaluacin
6.2.2.1. Principios bsicos
El procedimiento de evaluacin utilizado en los proyectos

involucrados en el programa SIMCA al igual que cualquier
procedimiento de evaluacin que se considere, se basa en los tres
principios o premisas siguientes:
1. Estricto seguimiento de unos procedimientos de evaluacin

bien definidos y uniformes para todos los casos.
80
Los procedimientos definen claramente la forma en que debe

realizarse la evaluacin incluyendo: formatos, mtodos de evaluacin
a utilizar, forma de asignacin de grupos evaluadores, generacin de
informes, archivo y tratamiento de la documentacin generada en el
proceso de evaluacin, etc. En particular el procedimiento de
evaluacin est formado por dos grupos de valoraciones:
a) Valoracin global.
Constituye el primer paso en el estudio de la oferta donde se

realiza un anlisis general de los siguientes temas, que deben
estar convenientemente explicados en la misma: (1)
cumplimiento de los criterios excluyentes, si los hubiera; (2)
requisitos tcnicos y operativos; (3) apoyo logstico y calidad
del suministrador; y (4) criterios especficos para el proyecto,
como pueden ser la planificacin y el plan de pruebas.
b) Valoracin detallada.
Se realiza utilizando el mtodo de Atributos Ponderados

Jerarquizados, usando una combinacin 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 bsicamente 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 ponderacin de cada criterio suele
realizarse asignando un valor numrico 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 mrito de la
81
oferta, bien directamente o como porcentaje del valor

mximo alcanzable.
Las listas de control tienen las siguientes ventajas: (1)

versatilidad para adaptarse a cualquier tipo de oferta; (2)
sencillez en su cumplimentacin; (3) determinacin de
puntos fuertes y dbiles; y (4) jerarquizacin de las ofertas
en funcin de su ndice de mrito.
Estas listas presentan, sin embargo, los inconvenientes

siguientes: (1) subjetividad en la valoracin de los criterios,
solo corregible con la intervencin de diferentes
especialistas; y (2) necesidad de amplia experiencia en su
utilizacin, si se usa el ndice de mrito como base exclusiva
de aceptacin y ponderacin elegida.
El condicionante mayor de las listas de control lo constituye

la eleccin de los criterios de evaluacin, as como la escala
de valoracin y la ponderacin elegida.
Los ndices de Rentabilidad son mtodos cuantitativos

en los que se valoran aspectos financieros de la empresa.
Estos ndices tienen la gran ventaja de utilizar trminos
financieros de fcil comprensin y facilitar la comparacin
de unas ofertas con otras al reducirse a trminos
econmicos.
Sin embargo, presentan el inconveniente de que

anteproyectos de muy distinta credibilidad y atractivo pueden
tener ndices iguales.
2. Definicin de unos criterios de evaluacin 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
caractersticas.
82
Los criterios definen los subsistemas, reas y atributos que

son objeto de calificacin durante el proceso de evaluacin. Se asigna
un peso a cada uno de dichos parmetros. La definicin de criterios
se efecta por un grupo de expertos en el tipo de sistema considerado.
3. Creacin 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 puntuacin numrica subjetiva a cada rea o atributo
objeto de calificacin, reflejando el grado en que las ofertas presentadas
satisfacen los criterios establecidos.
6.2.2.2. Definicin de los criterios en la evaluacin de ofertas
La definicin 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 puntuacin numrica o CALIFICACIN a cada
uno de los atributos.
Para calificar los atributos, se define una escala numrica 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 puntuacin y para dar ms

relevancia a unos que a otros, se les asigna a cada uno un peso que
sirve como factor de ponderacin. Combinando entre s las
calificaciones de los atributos de cada rea, se obtiene la calificacin
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 calificacin final de cada oferta, que constituye el
ndice de mrito de la misma. Los criterios se visualizan, una vez
definidos, mediante unas tablas jerarquizadas.
Con objeto de comprender ms claramente la estructura y el

proceso de valoracin de criterios se muestra el ejemplo concreto de
la valoracin 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) Valoracin de aspectos globales;

2) Criterios tcnicos y operativos;
3) Apoyo logstico y calidad del suministrador; y
4) Criterios especficos para el proyecto.
Cada uno de los cuales se subdivide a su vez en nuevos criterios

que constituyen las tablas de orden jerrquico inferior. El mtodo de
valoracin de los atributos se realiza estableciendo una escala de
puntuacin para cada atributo entre 0 y 5 con valores naturales,
entendindose que los valores 0, 1, 2 indicaran 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 cuestin, criterios excluyentes de manera que una puntuacin por
debajo de 3 de algn atributo, elegido previamente, supone el rechazo
automtico de la oferta en cuestin.
Cuando algn punto de una tabla de orden superior se

descompone en una tabla de orden inmediatamente inferior, la
aportacin de la tabla de nivel inferior a la superior se convierte a una
puntuacin 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)
Puntuacin parcial (Tabla superior)= x5
M a x im o s e le m e n ta le s (T . In fe rio r)
La contribucin de las tablas principales a la tabla de valoracin

total son los valores de la suma de puntuaciones (Pi) y la suma de
mximos (Mi) como puede verse en las Figuras 6.2 y 6.3.
86
6.2.2.3. Fases en el procedimiento de evaluacin
En la Figura 6.4 se pueden observar en forma de organigrama

las fases principales de que consta el procedimiento o proceso de
evaluacin de ofertas.
Aunque no sea parte propiamente dicha del propio proceso de

evaluacin se parte del PPT, como documento de referencia en la
documentacin, para la peticin de ofertas a las empresas, as como
del procedimiento de evaluacin. Se crea un grupo formado por
expertos en las tecnologas 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 ponderacin de
los mismos siguiendo el procedimiento de evaluacin elegido. Se crea
tambin un grupo evaluador por la autoridad que corresponda, formado
por especialistas por temas, cuya misin ser la de evaluar-calificar
los apartados o aspectos de las ofertas presentadas comparndolos
87
88
con el documento de referencia que es el PPT. Una vez recibidas las

ofertas, que debern 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 aclaracin que estima oportunas, las cuales son
respondidas por escrito. Una vez que el grupo evaluador realiza la
calificacin de las ofertas recibidas y, obtenido el ndice de mrito,
realiza el informe final terminndose as el proceso.
El proceso de evaluacin 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 eleccin de un
equipo o sistema con unas prestaciones o caractersticas degradadas,
comparndolas con las requeridas, puede suponer un encarecimiento
considerable del ciclo de vida logstico del producto adems de la
insatisfaccin del usuario.
El procedimiento de evaluacin debe basarse en mtodos lo

ms objetivos posibles de manera que dicho procedimiento sea
transparente.
89
90
91
7
Anlisis 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 construccin de nuevas
unidades y sigue para su realizacin la metodologa de programacin
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 definicin del proyecto (diseo) del buque. Esta
fase es previa a la de produccin.
7.2. Anlisis de valor en el programa F-100
Isdefe particip en el Estudio de la Fase de Viabilidad del diseo

del buque (segunda fase del ciclo de vida del sistema) como contratista
principal, con responsabilidad directa en las reas de Sistema de
Combate, Planificacin, Anlisis Industrial, Logstica y Costes.
El estudio tuvo dos fases. La primera consisti en explorar y

estudiar un nmero limitado de variantes de un diseo base (Proyecto
Preliminar) que cumpliesen con lo establecido por los requisitos de
la Armada y que posibilitase un proceso de comparacin riguroso,
para la seleccin de uno de ellos o de uno compuesto por partes de
93
Anlisis 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 (definicin de proyecto) con un estado del estudio
suficientemente avanzado y los principales aspectos del proyecto
definidos.
Uno de los aspectos ms novedosos de este estudio fue la

realizacin, dentro de la primera fase, de los anlisis 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 contencin de costes del
programa en funcin de las desviaciones encontradas.
Los requisitos de la Armada impusieron inicialmente que las

fragatas tuviesen como misin principal la lucha antisubmarina, aunque
durante el desarrollo del Estudio de Viabilidad se contempl tambin
la alternativa de lucha antiarea como misin principal, lo que oblig a
estudiar un nmero elevado de alternativas debido a unas
configuraciones de buque tan diferentes.
7.3. Anlisis de costes. Estudios paramtricos
7.3.1. Generalidades
Las estimaciones de costes de un buque, o de cualquier sistema,

deben realizarse desde las fases ms tempranas del proyecto utilizando
diferentes tcnicas de estimacin puesto que las decisiones de diseo
o logsticas, 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 estimacin del coste de un sistema
evoluciona y se refina segn se desarrolla el programa. La precisin
en la estimacin depende de forma muy importante en la fiabilidad de
los datos de los elementos de coste.
94
Las tcnicas ms comnmente utilizadas son: (1) estimacin

paramtrica, (2) estimacin por analoga y (3) estimacin Integradora.
La estimacin paramtrica se emplea en estudios en los que el

nivel de definicin del buque no es muy alto y no se tienen datos
comerciales para realizar valoraciones segn precios de mercado, si no
fundamentalmente datos tcnicos, o el tiempo disponible para la
realizacin de la estimacin es escaso, con este mtodo se llega a una
estimacin de coste de las unidades en estudio con un grado de fiabilidad
que depender de las herramientas empleadas y del nivel de definicin
del proyecto, permitiendo analizar diferentes alternativas de configuracin
del buque y controlar las posibles desviaciones del coste objetivo.
La estimacin por analoga se realiza en las fases muy iniciales

de los proyectos y consiste en estimar el coste del buque por analoga
con otros ya construidos; se usa para validar estudios realizados con
otras herramientas.
95
La estimacin integradora (bottom-up) exige un conocimiento

muy detallado del buque a nivel de equipos y se utiliza en fases ms
avanzadas del desarrollo del proyecto. Para su realizacin necesita la
utilizacin de muchos recursos tanto humanos como de tiempo, as
como de datos fiables de coste de equipos histricos o actuales.
En la Figura 7.2 se presentan las diferentes tcnicas de

estimacin de coste en funcin de las fases de evolucin del
programa.
Existen diferentes tipos de herramientas paramtricas:

especficas y generales. Dentro de las primeras estn las que realizan
las empresas para la prediccin de sus propios productos o las que se
conciben para un tipo de sistema (buques, aeronaves, etc.) con una
gama de aplicacin ms amplia. Las segundas permiten predecir el
coste de cualquier sistema en funcin de parmetros genricos (peso,
volumen, etc.) que lo caracterizan.
96
7.3.2. Anlisis de costes
Durante el Estudio de Viabilidad de la fragata F-100 se realizaron

dos tipos de estimaciones de las tres mencionadas: estimaciones
paramtricas y estimaciones integradoras. En la primera fase se estudi
paramtricamente 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 realizacin del anlisis y estimacin 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 divisin fue que los equipos del sistema de combate son
difciles de estimar por mtodos paramtricos, 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 especficos de alta
tecnologa, as como al gran nmero de configuraciones posibles
de sistemas de combate que se contemplaban, mientras que la
plataforma es ms fcilmente parametrizable debido a sus
caractersticas.
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 ms capaces se asociaron a plataformas de
mayores prestaciones, disminuyndolas segn se rebajaba la
capacidad y prestaciones del sistema de combate.
En la Figura 7.3 se presentan las diferentes configuraciones

de los buques en funcin 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 realizacin de los anlisis de las diez alternativas se

utilizaron herramientas paramtricas de estimacin de coste
especficas de buques, contrastadas anteriormente en otros
programas navales (estudio de la NFR90 - Nato Frigate Replacement
for 90s).
7.3.3. Herramienta paramtrica de estimacin de costes
La herramienta paramtrica utilizada en el estudio funciona de

la forma que se representa esquemticamente 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-autonoma; Dimensiones del buque (Rango: Mximas,

mnimas); Coeficientes hidrodinmicos; Tipo de propulsin; Tipo de
material del casco; Tripulacin; Requisitos elctricos; Mrgenes.
Se introducen tambin 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 instalacin estimadas, as como los parmetros indicadores
de la incidencia del sistema de combate en la plataforma.
Por ltimo, se introducen los parmetros especficos de

costes, como son: ao para el clculo del presupuesto, nmero
de buques para prever efecto serie o no, productividad del astillero
constructor, tasas de inflacin en porcentaje, valores de coste
horarios y gastos generales.
Con los datos aportados el modelo paramtrico realiza los

clculos internos y devuelve como salida los resultados de las
caractersticas tcnicas (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 considerarn 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
anlogos entre los predichos por el programa paramtrico y los datos
tcnicos del proyecto. Una vez logrado un acuerdo entre stos, los
resultados de costes que se obtienen tambin se consideran
adecuados.
Esta tcnica permite predecir el coste de las alternativas y

posibilita una vez encajado un buque, en cuanto a sus caractersticas
tcnicas, realizar modificaciones con una gran rapidez para conseguir
costes de alternativas. Se debe hacer notar que una modificacin de
algn elemento del sistema de combate lleva aparejada modificaciones
en la plataforma, lo que sera muy costoso de analizar caso por caso,
100
mientras que el anlisis paramtrico tiene en cuenta estas

modificaciones y las realiza de una forma prcticamente inmediata.
7.3.4. Aplicacin de los anlisis paramtricos de ingeniera de

costes en la fragata F-100
Partiendo de las caractersticas tcnicas de la fragata F-100 y

de los datos de la lista de equipos ms importantes, aproximadamente
unos cuarenta, que configuraban el sistema de combate del buque de
mximo cumplimiento de requisitos (alternativa 1A), se realiz el encaje
del primer buque y a continuacin se obtuvieron los costes de las
otras nueve siguientes variantes, lo que supuso finalmente el anlisis
del coste de diez alternativas.
En la Figura 7.5 se ha representado la relacin 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
desviacin 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 desviacin de cada alternativa estudiada sobre el objetivo
de coste (100) y la distribucin del coste total entre las dos partes
principales en que se han dividido el buque: plataforma y sistema de
combate.
El anlisis de estas diez alternativas de buques, permiti a la

Armada contemplar soluciones de diseo muy diferentes, segn el
nivel de cumplimiento de los requisitos tcnicos y de coste, logrando
con ello que la toma de decisin final sobre el buque fuese lo ms
adecuada a sus necesidades.
102
El valor de cualquier sistema de armas es un condicionante muy

fuerte durante el proceso de adquisicin. Por tanto la estimacin del
coste se debe realizar desde las fases ms tempranas del proyecto.
La utilizacin de las herramientas de estimacin paramtricas ayudan
en este proceso.
Las estimaciones paramtricas de coste permiten analizar

diferentes alternativas de los sistemas de armas con una inversin de
recursos limitada y con una precisin aceptable en los resultados.
La estimacin paramtrica de costes es necesaria en las fases

iniciales de cualquier sistema, permitiendo analizar alternativas de
diseo que posibiliten una toma de decisin lo ms correcta posible, y
puede llevar a ahorros considerables en el coste del ciclo de vida del
sistema con pequeas variaciones en el cumplimiento de los requisitos.
103
104
105
8
Gestin de la
configuracin
en el SCTM
106
8.1. Programa SCTM
El programa SCTM est incluido dentro del contexto de

planeamiento e implantacin del Sistema Defensa C3 (Mando, Control
y Coordinacin) y su finalidad es la obtencin 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 telecomunicacin (voz, mensajes, datos e
imgenes) que requieren los usuarios y sistemas del Mando y Control
Militar. El SCTM dispone de puntos de interconexin con otros sistemas
o redes de telecomunicaciones que permiten ampliar la cobertura de
interfuncionamiento con otros usuarios varios (Tcticos, Satlite, OTAN,
Pblicos y Privados). El carcter conjunto del SCTM se fundamenta en
que posibilita la preparacin y conduccin 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 dinmico y

abierto, cuyo diseo e implantacin viene siendo progresivo y gradual en
funcin de la propia evolucin de las necesidades operativas que ha de
satisfacer, su situacin actual responde a dos vertientes, una de medios ya
en servicio, cuyo funcionamiento est soportado por las estructuras logsticas
asignadas de operacin y sostenimiento de las Fuerzas Armadas, y otra de
obtencin de nuevos medios, que potencien y amplen los existentes
mediante la ejecucin de los correspondientes proyectos de implantacin.
107
Gestin de la configuracin en el SCTM
Esta simultaneidad de medios en servicio y en proceso de

obtencin hace que en el desarrollo del SCTM coexistan las diferentes
fases del ciclo de vida de un sistema: (anlisis de la necesidad,
especificacin de requisitos, diseo, desarrollo, produccin/
implantacin, empleo y apoyo al sistema).
El planeamiento del SCTM llevado a cabo en los ltimos aos se

ajust a la metodologa PAPS (Periodic Armaments Planning System) de
la OTAN, y como resultado de la ltima fase realizada (Fase de Definicin)
se elaboraron las especificaciones de diseo y desarrollo (ao 1990).
En concordancia con las actualizaciones de requisitos operativos

y priorizacin de necesidades existentes, actualmente el programa
SCTM tiene en proceso de implantacin diversos proyectos que, en
su conjunto, completarn y potenciarn las estructuras de red y
logsticas existentes del SCTM, proporcionando a su vez servicios de
telecomunicacin a usuarios prioritarios de mando y control.
8.2. Gestin de la configuracin aplicada al SCTM
En su perspectiva actual, la concepcin de la arquitectura del

SCTM responde a una estructura integrada de subsistemas
componentes: Transmisin, Conmutacin de Circuitos, Conmutacin
de Paquetes y Tratamiento de Mensajes, Seguridad de Comunicaciones
y Gestin y Supervisin.
Dentro de la funcionalidad general soportada por esta arquitectura,

el Subsistema de Gestin y Supervisin tiene como objetivo principal
posibilitar la operacin, administracin 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 Gestin
y Supervisin es la funcin de Gestin de Configuracin, cuyo concepto
es objeto de enfoque y aspecto a resaltar en este Captulo de la monografa.
108
Como es sabido, la implantacin de los conceptos y principios

de ingeniera de sistemas requiere de una gestin de configuracin
que asegure disponer a lo largo del ciclo de vida de un sistema de una
configuracin actualizada del mismo, permitiendo controlar los cambios
producidos en ella tanto en las fases de diseo e implantacin como
en la vida operativa del sistema. Asimismo, la disponibilidad de esta
configuracin actualizada implica y debe ser referencia comn del
conjunto de organizaciones que tienen responsabilidades en la
obtencin de un sistema (Oficina de Programa y contratistas) y en el
funcionamiento del mismo (organizaciones de operacin y apoyo
asignadas).
La obtencin de un sistema de informacin que, dentro del contexto

general de la gestin y supervisin del SCTM, soportase la funcin de
gestin de configuracin, ha sido un objetivo prioritario y consustancial
con el proceso de planificacin y adquisicin del SCTM. Este sistema
est actualmente en fase de implantacin (Diseo Detallado, Desarrollo
e Instalacin), despus de la realizacin anterior de diversos estudios y
elaboracin de especificaciones que junto a aplicaciones de prototipados
completaron las fases de Diseo Conceptual y Preliminar del sistema.
Con la implantacin de este sistema se pretende satisfacer la

operatividad requerida por los rganos responsables del funcionamiento
del SCTM (rganos de direccin y ejecucin que constituyen la estructura
de operacin y sostenimiento) y de su obtencin (Oficina de Programa),
apoyando la explotacin de los medios en servicio y facilitando el proceso
de implantacin de nuevos medios.
8.3. Concepto de gestin de la configuracin
En su concepcin genrica, la gestin de la configuracin de un

sistema comprende las siguientes reas funcionales: identificacin de
la configuracin, control de la configuracin, registro de estado de
configuracin y auditoras de configuracin.
109
En el caso especfico de un sistema de telecomunicaciones, la

gestin de configuracin 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 reconfiguracin en caso necesario de los recursos de red
disponibles.
En su aplicacin al SCTM, el concepto concebido de gestin

de configuracin se enmarca dentro del contexto de funciones de
gestin que, junto a las de supervisin y control de tiempo real de los
elementos del sistema, permitirn apoyar el desarrollo de actividades
y tareas asociadas a su planificacin, implantacin y operacin y
apoyo.
La organizacin de estas funciones de gestin que incluyen

las aplicables al control de configuracin de la red (fsica y lgica)
y apoyo logstico (mantenimiento y abastecimiento), responde al
esquema que se representa en la Figura 8.1. Estas funciones
estarn soportadas por un conjunto de aplicaciones informticas
que se apoyan en una base de datos constituida por dos partes
diferenciadas:
1) Base de datos grfica, compuesta por el conjunto de planos

estticos y dinmicos que representan la configuracin de
la red.
2) Base de datos alfanumrica, que incluye la identificacin y

descripcin de los elementos componentes de la red.
Para asegurar la seguridad e integridad de los datos bajo control

de las aplicaciones, existir una aplicacin especfica de Gestin 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 gestin de la configuracin
La funcin de Gestin de la Configuracin estar soportada por

el conjunto de procedimientos y herramientas (programas software),
que apoyndose en la arquitectura hardware del Subsistema de Gestin
y Supervisin del SCTM, permitir:
a) La identificacin de los elementos de la red.
b) El control de cambios, as como su distribucin automtica

a los rganos responsables de la obtencin y funcionamiento
de la red.
c) El control de estado de los elementos de la red.
Segn se representa en la Figura 8.1, la funcin de gestin de

la configuracin se ha subdividido en las siguientes reas funcionales:
111
1) Configuracin fsica, que comprende las funciones de

identificacin y control de los elementos de planta que
constituyen la red.
2) Configuracin lgica, que incluye las funciones que

permiten la planificacin y explotacin 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. Configuracin fsica
Se basa en la modelizacin 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 smbolo. La
asociacin de smbolos en una pgina constituye los mapas de red,
cuya visualizacin permite al operador transitar por las diversas rutas y
estaciones que configuran la red.
La funcin de identificacin de los elementos de red estar

soportada por dos aplicaciones informticas enlazadas entre s: Gestin
de Planos y Control de Inventario. Esta identificacin se realizar a
dos niveles:
1) Mediante la posicin que ocupa el equipamiento en la planta

y alzado de la estacin, as como por su composicin hasta
el nivel de elemento mnimo reemplazable.
2) Mediante un nmero de inventario asignado a cada elemento

componente del equipamiento de la estacin.
La modificacin de los elementos de un determinado equipo,

implicar la modificacin automtica de los planos de la base de datos
que corresponden a dicho equipo.
112
A su vez, la funcin de control de la documentacin y

manuales descriptivos de la red, estar soportada por la
correspondiente aplicacin informtica.
La funcin de control de cambios permitir realizar el seguimiento

e historial de los cambios realizados sobre los elementos de la red, y
su correspondiente aplicacin de soporte implicar a los elementos
de configuracin fsica de la red, as como a la informacin descriptiva
de sta.
8.3.1.2. Configuracin lgica
La funcin de configuracin lgica estar soportada por una

aplicacin basada en los conceptos de simulacin discreta aplicables
a una red de transmisin, y con ella se pretende disponer de las
siguientes capacidades:
a) Identificacin y control de los enlaces y servicios disponibles

en la red.
b) Verificacin de los niveles de supervivencia de la red,

mediante la simulacin de cada de nodos y/o
enlaces.
c) Visualizacin de los mapas de conectividad de la red.
d) Estadsticas sobre recursos de red disponibles.
e) Gestin de altas y bajas de servicios.
En relacin con la operacin de red, esta aplicacin 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. Descripcin de actividades
Como se ha indicado en la seccin 8.2, la obtencin del sistema

de gestin de configuracin aplicable al SCTM est en fase de
implantacin mediante proyecto en ejecucin, despus de haber sido
cubiertas las fases de Diseo Conceptual y Preliminar dentro del
proceso general de planificacin del SCTM.
La Fase de Diseo Conceptual fue completada mediante estudios

y trabajos de ingeniera llevados a cabo en las distintas etapas de la
metodologa PAPS (Previabilidad, Viabilidad, Definicin, Diseo y
Desarrollo), y que en lo relativo a la gestin de configuracin, permitieron
obtener las correspondientes Especificaciones de Sistema (Tipo A)
y un Plan Preliminar de Gestin de la Configuracin.
Durante la Fase de Diseo Preliminar, en sntesis se realizaron

las siguientes actividades y trabajos:
Anlisis funcional y asignacin de requisitos de la

arquitectura del sistema de gestin de configuracin
especificado.
Implantacin de un prototipo de sistema informtico que

permiti, por una parte, establecer un embrin de
arquitectura para analizar su funcionalidad y apoyar la
definicin de especificaciones tcnicas de la misma y, por
otra parte, disponer en base de datos de un primer nivel de
planos informatizados que representan la configuracin de
gran parte de la estructura de red en servicio del SCTM.
Elaboracin de los Pliegos de Prescripciones Tcnicas del

expediente de suministro actualmente en ejecucin y que
incluyen los requisitos tcnicos y la metodologa que aplican
al diseo detallado e implantacin del sistema de gestin
de la configuracin objeto de obtencin.
114
El prototipo de sistema implantado se concibi en base a una

arquitectura hardware de estaciones de trabajo, una estructura bsica
de aplicaciones informticas (gestin 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 irn completando mediante
sucesivas implantaciones del SCTM. A ttulo 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 visualizacin 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 ingeniera de sistemas que

permitan armonizar y supervisar los procesos de obtencin desde las
etapas iniciales de diseo, es garanta de alcanzar en plazos y costes
los objetivos operativos planteados para la adquisicin de un sistema.
En particular, ello es tanto ms necesario en aquellos casos de proyectos
cuyo alcance de implantaciones impliquen nuevos desarrollos.
La gestin de la configuracin es una funcin esencial cuya

ejecucin abarca todo el ciclo de vida de un sistema y que facilita en
gran medida su obtencin y posterior funcionamiento. La implantacin
de los conceptos y principios de ingeniera de sistemas requiere
disponer de una buena gestin de la configuracin.
En su concepcin genrica la gestin de la configuracin es

comn para todo tipo de sistemas y comprende las siguientes reas
funcionales: Identificacin, Control, Registro de Estados y Auditoras
de Configuracin.
De la experiencia obtenida de los trabajos llevados a cabo para la

definicin e implantacin del sistema de gestin de configuracin 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 diseo
y completar las especificaciones tcnicas del sistema objeto de obtencin
en concordancia con la funcionalidad operativa requerida.
Aspectos que se consideran fundamentales para desarrollar la

funcin de gestin de la configuracin, adems de disponer de las
correspondientes capacidades tcnicas y elementos de soporte, son
los concernientes al establecimiento de una estructura de organizacin
y unos procedimientos que aseguren en todo momento la consistencia
e integridad de la informacin asociada a los elementos del sistema
objeto de gestin de la configuracin.
Estos aspectos de organizacin y procedimientos de gestin de

configuracin son tanto ms crticos en sistemas abiertos y dinmicos,
como es el SCTM, cuya obtencin y funcionamiento de medios en
servicio implica a diversos rganos asignados de las Fuerzas Armadas,
117
118
y que en estrecha coordinacin e interoperatividad con las

organizaciones de los contratistas de expedientes de implantacin y
apoyo logstico, tienen la misin de asegurar en todo momento los
objetivos operativos del SCTM.
119
120
121
9
Proceso
de seleccin
de equipos y
suministradores en
el programa EF2000
122
9.1. Descripcin del programa
El programa de Avin de Combate Europeo, Eurofighter 2000

(EF2000), es un proyecto multinacional en el que participan Alemania,
Gran Bretaa, Italia y Espaa. En la actualidad se encuentra en la fase
de desarrollo, a la que los cuatro pases contribuyen respectivamente
con el 33%, 33%, 21% y 13%.
Para la gestin 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 composicin
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 integracin de la avinica, del motor, etc. La estructura
organizativa del programa EF2000 se muestra en la Figura 9.1.
9.2. Participacin de la industria espaola
El EF2000, sin duda el mayor proyecto de colaboracin que ha

existido en Europa, ha proporcionado a nuestra industria aeronutica y
electrnica la oportunidad de participar por primera vez como socios
en el diseo y desarrollo de un proyecto de la ms alta tecnologa junto
con las empresas de los pases europeos ms avanzados en el campo
aeronutico (exceptuando a Francia).
123
Proceso de seleccin 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 ingeniera de diseo del avin, en la estructura,
en la integracin de sistemas y equipos, en la integracin del motor, as
como en la utilizacin de nuevos materiales en procesos avanzados de
fabricacin, y en la fabricacin y ensamblaje de los prototipos de avin y
motor. Igualmente participa en el diseo, desarrollo y fabricacin de
prototipos de los equipos asociados al sistema de avinica (navegacin,
guerra electrnica, comunicaciones, identificacin y ataque, presentacin
de datos y simbologa, etc.) y a los sistemas generales (control de vuelo,
combustible, elctrico, hidrulico, refrigeracin y control ambiental, etc.).
9.3. Equipos de avin y accesorios de motor
Uno de los aspectos ms importantes y complejos del programa

EF2000 es el relacionado con el desarrollo de los equipos de avin y
124
accesorios (equipos) de motor, del cual forman parte esencial los

procesos de elaboracin y aprobacin de especificaciones y la posterior
seleccin 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 aplicacin de los conceptos sistmicos al tratamiento prctico de un
sistema complejo.
Gran parte de esta complejidad es debida al elevado nmero de

equipos (285) y accesorios (24) a desarrollar, a la gran cantidad de
ofertas presentadas, bien en colaboracin o de forma individual, y al
alto nivel de exigencia tanto de las especificaciones de desarrollo como
del resto de la documentacin asociada al paquete de peticin de
Ofertas. Como resultado del proceso de seleccin, el nmero de
empresas de los cuatro pases del programa EF2000 que participan
es de 120, asociadas la mayora de las veces en consorcios.
Los equipos y accesorios se han clasificado en tres grupos o

categoras, A, B y C, segn su importancia en el sistema EF2000 y su
complejidad y exigencia tecnolgica, a la que normalmente va asociado
un elevado importe econmico. En lo sucesivo se har referencia a
equipos, entendindose que se aplica tanto a los equipos de avin
como a los accesorios de motor.
Una de las reglas fundamentales de este programa

multinacional establece que la aportacin econmica (costshare)
de cada pas participante ha de ser igual a su participacin industrial
(workshare). De esta forma cada pas se asegura el justo retorno a
la inversin que realiza, y se favorece la colaboracin entre empresas
en el mbito del programa y la formacin de consorcios industriales.
En consecuencia, el aseguramiento de la participacin industrial
compatible con el resultado ms competitivo posible desde el punto
de vista coste-eficacia, ha sido uno de los factores a tener en cuenta
en la seleccin y adjudicacin de ofertas, como veremos ms
adelante.
125
9.4. Proceso de gestin del desarrollo
Dentro del marco de asistencia tcnica a la gestin del

programa EF2000, Isdefe colabora con la Oficina del Programa del
Ministerio de Defensa en los procesos de aprobacin de
especificaciones, de evaluacin y adjudicacin de ofertas y seleccin
de suministradores, as como en el seguimiento y control del
desarrollo, calificacin y entregas de prototipos de equipos con objeto
de:
a) Asegurar que los sistemas, subsistemas y equipos del avin

cumplen los requisitos del sistema EF2000;
b) Asegurar que los desarrollos de los equipos se ajustan a lo

especificado en los aspectos tcnicos, de coste y plazos;
c) Asegurar que el reparto de trabajo para las empresas

espaolas miembros de consorcios est en lnea con nuestro
nivel de participacin tanto en cantidad (volumen de trabajo)
como en calidad (tecnologa); y
d) Contribuir a solucionar los problemas que se presentan a

los suministradores a lo largo del desarrollo.
Este Captulo se centra en la parte inicial de este proceso, hasta

la contratacin del equipo con la empresa/consorcio seleccionada.
Al trmino de la fase de definicin, el sistema ha quedado definido

(Especificacin General del Sistema), habindose realizado el anlisis
funcional, con la consiguiente asignacin de requisitos, y su
transformacin en criterios de diseo [6].
El proceso que se describe a continuacin se enmarca en la

etapa inicial de la fase de desarrollo, en la que se consolidan tanto el
anlisis funcional de los requisitos como las interfaces entre sistemas,
126
subsistemas y equipos, y se establecen de manera detallada las

especificaciones tcnicas de todos los equipos del avin, que sern
parte fundamental del paquete de peticin de ofertas a partir del cual
se seleccionar a los suministradores.
9.5. Proceso de seleccin
El marco en el que se encuadra el proceso de validacin de

especificaciones, evaluacin de ofertas y seleccin de suministradores
est determinado por dos aspectos fundamentales:
1) Principios.
2) Criterios de evaluacin y seleccin.
9.5.1. Principios del proceso de seleccin
Dadas las caractersticas especficas de este programa

multinacional, en el que se busca fomentar la colaboracin entre la
industria europea y a la vez respetar los principios de retorno
industrial a cada pas y libre competencia, se consensuaron unas
reglas de juego que, en esencia, se pueden traducir en los siguientes
puntos:
a) La seleccin se realiza mediante concurso de ofertas en

competencia genuina, definida as cuando se hayan recibido
dos o ms ofertas independientes de entre tres o ms
empresas independientes invitadas a concursar.
b) Las ofertas tienen que incorporar una distribucin equilibrada

de las reas de tecnologa nuevas o avanzadas que
intervienen en el desarrollo de cada equipo (categoras A y
B), de acuerdo con los porcentajes de participacin industrial
nacionales.
127
c) Con el fin de cumplir los requisitos de participacin industrial

del programa, se favorece que las empresas invitadas a
concursar (suministradores potenciales) presenten ofertas
en colaboracin o consorcio siempre que sea posible. En la
evaluacin de ofertas se da un mayor peso a las ofertas en
colaboracin frente a las ofertas individuales, aunque stas
tambin se consideran en las evaluaciones.
Una oferta se considera en colaboracin cuando dos o ms

empresas de dos o ms pases participantes en el programa
presentan una oferta conjunta regulada por un acuerdo
formal en el que se detallan las condiciones de colaboracin,
de reparto de trabajo (workshare) y la transferencia de
tecnologa.
d) En las ofertas en colaboracin para la fase de desarrollo, no

se admiten duplicidades de trabajo o redundancias entre
los socios del consorcio.
9.5.2. Evaluacin y aprobacin de especificaciones
Cada una de las naciones, as como las secciones de la Agencia

NEFMA involucradas, llevan a cabo la evaluacin de los distintos
apartados de la especificacin. NEFMA realiza las tareas de
coordinacin de los comentarios y posturas respectivas de cada nacin,
pudiendo convocarse reuniones de especialistas en caso necesario.
Si como resultado de estas reuniones se sigue sin poder aceptar

la especificacin, dependiendo del grado de discrepancia, se plantean
dos alternativas:
a) convocar una reunin del Panel de Seleccin de Equipos

(Equipment Selection Panel, EQSP) para consolidar posturas
y llegar a un punto de acuerdo con EF.
128
b) remitir la especificacin a EF para su revisin, segn las

directrices establecidas por el EQSP, si las discrepancias
son insuperables.
Este proceso est reflejado esquemticamente en la Figura 9.2.
9.5.3. Seleccin de suministradores de equipos
Cada nacin, as como los departamentos de NEFMA implicados,

evalan todas las ofertas recibidas en sus aspectos tcnico, econmico
y contractual, y los califican de acuerdo con unos criterios y baremos
establecidos para cada caso concreto, basados en los criterios de
seleccin y factores de ponderacin de la Seccin 9.5.4. Estas
valoraciones se comparan con la seleccin realizada por EF.
NEFMA ejerce la funcin de coordinar las diferentes posturas

nacionales, pudiendo celebrarse reuniones de coordinacin previas al
EQSP, en las que se decidir si es necesario debatir aspectos de la
evaluacin de ofertas a nivel de especialistas de las cuatro naciones
junto con NEFMA y EF.
Posteriormente se convoca el EQSP, que en una sesin cerrada

(NEFMA/naciones) unifica y consolida las posturas de sus miembros y
comprueba si se satisfacen los requisitos de la participacin industrial
y en sesin abierta con EF le comunica a ste su decisin, que puede
contemplar las siguientes posibilidades:
a. Ratificacin de la seleccin recomendada por EF y

adjudicacin definitiva del concurso a la oferta ganadora.
EF puede proceder de inmediato a contratar con la empresa
o consorcio adjudicatario.
b. Aceptacin de la oferta seleccionada desde el punto de vista

tcnico, econmico y contractual que, sin embargo, incumple
129
130
el requisito de la participacin industrial establecido. El

EQSP concede una adjudicacin 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
adjudicacin se convierte en definitiva. Por el contrario, si el
lder del consorcio se opone a una redistribucin de la
participacin industrial, dado el peso que este factor tiene
en la valoracin de las ofertas, esta quedara descartada.
c. El EQSP acepta la oferta recomendada por EF, pero sta

no cumple la totalidad de los requisitos tcnicos de la
especificacin o de los requisitos contractuales de la
documentacin 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 adjudicacin 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 adjudicara a dicho consorcio.
d. Si la oferta seleccionada y recomendada por EF tiene

carencias o incumplimientos bsicos en las reas tcnica
(fundamentalmente) o contractual, o bien se considera que
el precio ofertado es excesivamente alto, el EQSP rechazara
la oferta despus de consultar con EF y le dara instrucciones
para realizar un nuevo concurso de ofertas ampliando la lista
de empresas suministradoras potenciales a otros pases no
participantes en el programa EF2000. Este caso raramente
se presenta, puesto que normalmente EF lo detectar en su
proceso interno de evaluacin, seleccin y recomendacin,
e inmediatamente lo notificara al cliente. La Figura 9.3
describe grficamente el proceso de evaluacin de ofertas y
adjudicacin del concurso al suministrador seleccionado.
131
132
9.5.4. Criterios de evaluacin y seleccin
9.5.4.1. Evaluacin
La evaluacin de las ofertas se hace siguiendo el esquema

detallado de criterios de seleccin, y la gua de puntuacin y factores
de ponderacin 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
especificacin y documentacin asociada al paquete de peticin de
ofertas a nivel de bloques (1 nivel) y reas (2 nivel), mientras que el
esquema detallado continua el desglose hasta subrea (3 nivel) y
elementos (4 nivel).
Para la evaluacin de los aspectos tcnicos de la oferta se

ha utilizado la metodologa siguiente:
a. Se establece el concepto de puntuacin bsica, que

expresa el grado de cumplimiento de cada elemento de la
oferta respecto a la especificacin. Los especialistas
califican cada elemento de la oferta presentada con una
puntuacin que puede variar desde 0 (incumplimiento total)
hasta 10.
b. Cada bloque, rea, subrea y elemento tienen asignado un

factor de ponderacin, que refleja la importancia relativa de
las diferentes caractersticas tcnicas, funcionales, etc. del
equipo considerado. Para cada elemento evaluado, la
puntuacin bsica se multiplica por el factor de peso
asignado a cada elemento, obtenindose as la puntuacin
elaborada por elemento. Sumando en secuencia las
puntuaciones elaboradas por elemento se obtiene la
puntuacin por subrea. Afectando a este valor del factor
de ponderacin de cada subrea, se obtiene la puntuacin
elaborada por subrea. Procediendo de forma anloga se
133
van agregando las puntuaciones hasta obtener la puntuacin

por rea y seguidamente la puntuacin elaborada por cada
bloque.
Desde el punto de vista de la evaluacin tcnica, los bloques

(1 nivel) son los siguientes:
1. Prestaciones.
2. Fiabilidad y Seguridad, Mantenibilidad y Capacidad de
Prueba.
3. Caractersticas Tcnicas y Aspectos de Programa.
4. Aspectos Logsticos.
De esta forma las puntuaciones as elaboradas por cada

bloque dan una idea muy completa de cul es el equipo
que propone el suministrador y, al mismo tiempo, permiten
la comparacin con las ofertas de los dems concursantes.
c. Dado que el esquema se ha elaborado para evaluar cualquier

equipo (de avinica, mecnico, hidrulico, 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 caractersticos o fundamentales en el equipo
considerado, de forma que si la puntuacin de alguno de
esos elementos fuera muy baja o prxima a cero, la oferta
quedara automticamente rechazada.
d. Otro concepto importante a tener en cuenta en la evaluacin

es la valoracin del riesgo, enfocada fundamentalmente
al Bloque 1 (Prestaciones) y ciertos aspectos del Bloque 3
(Diseo, Integracin, Instalacin y caractersticas tcnicas).
Esta se define como el grado de dificultad que cada
suministrador encuentra para llevar a buen trmino la
propuesta de equipo que ha ofertado.
134
Este factor vara de 0 a 10. Para un equipo que cumple

ntegramente los requisitos de la especificacin y est
disponible en el momento de presentar la oferta (off-the-shelf),
la puntuacin del riesgo sera 10 (muy bajo). Por el contrario,
si un suministrador oferta a un equipo en el que no tiene
experiencia previa, la puntuacin estar prxima a cero,
debido al alto riesgo que supondra que ese suministrador
desarrollara un equipo que a un coste razonablemente bajo
satisfaciera todos los requisitos de la especificacin dentro
de los plazos de tiempo establecidos. Por tanto, cuanto ms
prximo a un diseo existente est el diseo presentado,
menor es el riesgo y mayor ser la puntuacin.
La valoracin del riesgo es un valor absoluto y un concepto

independiente del resto de la evaluacin y, como tal, debe
mantenerse al margen de la puntuacin bsica, factores de
peso y del esquema de seleccin.
e. La evaluacin de los aspectos comerciales (econmicos y

contractuales) de la oferta sigue los procedimientos
anteriormente descritos para el rea tcnica. Agregando las
puntuaciones bsicas, junto con los factores de peso
correspondientes, se obtienen las puntuaciones elaboradas
por bloque, que para la evaluacin comercial son los siguientes:
(1) precios; (2) colaboracin; (3) participacin industrial; y (4)
condiciones contractuales, dando una valoracin exhaustiva
del rea comercial de la oferta y permitiendo la comparacin
directa y sistemtica con el resto de las ofertas.
f. Es importante resaltar que en la peticin de ofertas para la

fase de desarrollo, en el Bloque 1 (Precios), adems del
precio de desarrollo del equipo los suministradores
potenciales deben de cotizar los precios correspondientes
a las siguientes fases del programa, inversiones para la
produccin, produccin en serie y apoyo en servicio,
135
considerndose por tanto todos los costes del ciclo de vida

en la valoracin econmica.
g. Una puntuacin notablemente baja en ciertos aspectos que

se puedan considerar fundamentales o de obligado
cumplimiento sera motivo para descalificar la oferta,
independientemente de cualquier otra consideracin.
9.5.4.2. Criterios de seleccin
El esquema general que recoge los criterios de seleccin a nivel

de bloque y rea (1 y 2 nivel) se divide en dos grandes grupos, que
engloban los aspectos tcnicos y los aspectos comerciales (econmico-
contractuales) y se muestra en las Figuras 9.4 y 9.5.
9.5.4.3. Sntesis
La seleccin de suministradores se basa en favorecer la

competencia industrial entre empresas y consorcios fundamentalmente
de los cuatro pases participantes, aunque no se excluyen a empresas
de otros pases. En esta lnea, el criterio fundamental que se sigue
para la adjudicacin definitiva de un contrato en el programa es el
siguiente:
1. Identificacin de las ofertas que hayan tenido mayor

valoracin desde el punto de vista tcnico, es decir, de
cumplimiento de la especificacin del equipo, as como de
valoracin del riesgo.
2. Grado de cumplimiento de estas ofertas de los trminos y

condiciones contractuales del programa EF2000, los cuales
forman parte, junto con la especificacin, del paquete de
documentacin asociado a la peticin de ofertas.
136
137
138
3. Seleccin y adjudicacin del contrato a aquella oferta que

habiendo cumplido los dos puntos anteriores, obtenga la
mejor valoracin econmica.
La realizacin del trabajo descrito en este Captulo dentro del

marco del programa EF2000, con 285 equipos de avin y 24 accesorios
(equipos) de motor, todos ellos de nuevo desarrollo y marcando el
estado del arte de la tecnologa europea ha significado una experiencia
muy valiosa y establece una metodologa en un rea fundamental como
es la seleccin de suministradores. Esta metodologa no es solamente
de aplicacin en el mbito de equipos embarcados, sino a nivel de
sistema completo, con un amplsimo campo de actuacin en cualquier
programa de adquisicin de un sistema, ya sea de nuevo desarrollo,
de modernizacin o de adquisicin directa (nacionalizacin,
compensaciones, etc.).
139
140
141
10
Verificacin y
validacin en el
programa EUROMAYA
142
10.1. Descripcin del programa Euromaya
El programa EUROMAYA, se enmarca dentro de los Programas

de cooperacin y ayuda al desarrollo que la Comisin Europea lleva a
cabo en Amrica Latina, recibiendo la denominacin formal de Proyecto
ALA 88/19.
El programa se desarrolla para la Corporacin Centro Americana

de Servicios de Navegacin Area (COCESNA) formada por Belice,
Costa Rica, Guatemala, Honduras, Nicaragua y El Salvador, siendo el
organismo contratante y regulador de la subvencin la Direccin
General I de la Comisin Europea. Los fondos econmicos iniciales
del programa provienen de la Comisin Europea (64%), del Estado
Italiano (32%) y de la propia COCESNA (4%). La Figura 10.1 muestra
el esquema de gestin.
El programa Euromaya tiene por objetivo incorporar en Centro

Amrica las modernas tecnologas de Control de Trfico Areo,
aumentando la capacidad y seguridad del Sistema de Navegacin Area,
y capacitando al personal de COCESNA en estas nuevas tecnologas.
143
Verificacin y validacin en el programa EUROMAYA
Los principales componentes del proyecto, son:
a) Instalacin de 4 radares secundarios monopulso y del sistema

de comunicaciones para su conexin con el Centro de Control.
b) Construccin de un nuevo Centro de Control en Tegucigalpa.
c) Sistema de Control de Trafico Areo.
d) Obras civiles para infraestructura de apoyo.
En la Figura 10.2 se presenta la ubicacin geogrfica de los

componentes del sistema.
Isdefe participa como Asistencia Tcnica a la Oficina de

Programa I.S.E. (Ingeniera de Sistemas Euromaya), en todas las fases
del ciclo de vida, desde el anlisis de necesidades y especificacin de
144
145
requisitos, hasta el proceso de instalacin y pruebas, actualmente en

curso. Tambin est previsto realizar el apoyo a la explotacin del
Sistema tras la puesta en servicio.
Para la realizacin de los trabajos, Isdefe tiene una oficina de

campo en Tegucigalpa en la que estn 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: planificacin, especificacin, y verificacin/validacin. Estas
ltimas actividades son de especial relevancia en la fase de produccin/
implantacin actualmente en curso, dadas las caractersticas especificas
de medios e infraestructura en la zona centroamericana.
10.2. Verificacin y validacin
Las actividades de verificacin y validacin, aunque realizadas a

lo largo de todo el ciclo de vida del sistema (ver Figura 10.3) de acuerdo
a una aproximacin basada en la normativa DOD-STD-2167-A, se han
centrado fundamentalmente en:
a) Revisin de requisitos del sistema; y
b) Pruebas de aceptacin en fabrica y en emplazamiento.
En la fase actual en que se encuentra el sistema EUROMAYA

(produccin / implantacin), las actividades de verificacin y validacin
se concretan en el proceso de ejecucin y gestin 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

ingeniera ha sido la ubicacin geogrfica del sistema, y
146
fundamentalmente la lejana respecto de los centros de produccin,

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 verificacin y

validacin que se realizan tiene una doble vertiente:
a) Asegurar que el contratista ha identificado y comprendido

correctamente todos y cada uno de los requisitos tcnico-
operativos del sistema, y ha establecido un plan de ejecucin
viable y realista; y
b) Garantizar que los diversos componentes del sistema tienen

las funcionalidad y prestaciones requeridas anticipando la
deteccin de no conformidades, mediante la realizacin del
mayor nmero posible de pruebas en fbrica.
147
Esta doble vertiente de los objetivos de la verificacin y

validacin de garantizar la obtencin de un sistema que cumpla los
requisitos establecidos y cuyo desarrollo se realiza en el coste y los
plazos previstos, se encuentra en plena sintona con el marco
establecido por los objetivos de ingeniera de sistemas, orientada a
la adquisicin eficaz y eficiente de sistemas que satisfagan
necesidades identificadas.
10.3.Descripcin de actividades
Las actividades de verificacin y validacin que se estn

realizando, son de 4 tipos (ver Figura 10.4):
a) Revisiones: evaluacin de los productos de una actividad

de desarrollo para determinar la consistencia y correccin
con respecto a los productos estndar suministrados.
148
b) Auditoras: verificacin del grado de implantacin de los

sistemas, tcnicas y procedimientos establecidos para el
desarrollo del EUROMAYA.
c) Inspecciones: comprobacin de los aspectos puntuales de

la ejecucin del proyecto por parte de los contratistas.
d) Pruebas: comprobacin y validacin de que un componente,

subsistema y el sistema EUROMAYA, cumple todos y cada
uno de los requisitos tcnico-operativos especificados.
10.3.1. Auditoras e inspecciones
Como parte del proceso de seguimiento y control de las

actividades realizadas por el contratista, se han llevado a cabo auditoras
e inspecciones en los centros de ingeniera y produccin del contratista.
Estas auditoras se han centrado en:
a) Verificar la cantidad y la adecuacin de los recursos

(humanos y materiales) asignados al proyecto;
b) Verificar el grado de implantacin del sistema de calidad del

contratista en el proyecto EUROMAYA de conformidad con
el plan de calidad establecido;
c) Verificar la adecuacin tcnica de los desarrollos, produccin

e instalacin de los diversos componentes; y
d) Verificar el grado de cumplimiento de la planificacin

establecida, con el fin de anticipar y detectar retrasos.
Para llevar a cabo estas actividades se han definido e implantado

un procedimiento de ejecucin de auditoras y un procedimiento de
anlisis y gestin de riesgos.
149
Con estas actividades se han detectado determinados riesgos

de relevancia para la ejecucin del proyecto lo cual ha permitido tomar
las medidas correctoras con la suficiente anticipacin.
10.3.2. Revisiones
Aunque formalmente existen muchos tipos de revisiones, en el

programa EUROMAYA la ms relevante ha sido la Revisin de Requisitos
del Sistema . Esta actividad se encuadra en lo que en el programa recibe
el nombre genrico de replanteo, que engloba tambin la revisin de
los planes de ejecucin y gestin asociados al proyecto (Plan de Gestin,
Plan de Calidad, Plan de Documentacin, etc...).
Tiene por objeto revisar el documento de Especificaciones de

Requisitos del Sistema elaborado por el contratista para verificar la
adecuacin a los requisitos tcnico-operativos del sistema,
comprobando que son completos (cobertura) y viables (viabilidad y
necesidad de desarrollos). Se tomaron como documentos de referencia
el Pliego de Trminos de Referencia (PTR), la oferta y los documentos
adicionales suministrados por el contratista y que estaban
referenciados en el acta de adjudicacin.
La realizacin del replanteo ha sido de fundamental importancia

prolongndose en el tiempo durante varios meses. Ha permitido identificar:
a) Riesgos de cumplimiento en plazos por parte del contratista,

de determinados requisitos tcnico-operativos; y
b) Desarrollos necesarios para cumplir con todos y cada uno

de los requisitos tcnico-operativos comprometidos por el
contratista.
Esto ha permitido realizar un ajuste final de los aspectos tcnicos y

configuracin del sistema respetando en todo momento los requisitos bsicos
150
e inexcusables de operatividad, seguridad y fiabilidad de un sistema de

Control de Trfico Areo. Adems la identificacin de los desarrollos
requeridos permite focalizar determinados tipos de pruebas en las reas
afectadas por dichos desarrollos, como ms adelante se expone.
10.3.3. Pruebas
Los elementos tcnicos que constituyen el suministro del programa

EUROMAYA se estructuran en los siguientes sistemas: SADR (Sistema
de adquisicin de datos radar), SCDR (Sistema de comunicacin de
datos radar), AFTN (Sistema de conmutacin de mensajes de la red
AFTN), CENAMER (Sistema de control de trfico areo y simulacin).
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. Segn el alcance de la prueba
se han distinguido los siguientes niveles convencionales de pruebas:
pruebas unitarias, pruebas de subsistema, pruebas de sistema, pruebas
de aceptacin (todos los sistemas integrados).
La ISE se ha centrado en el seguimiento, monitorizacin y control

de la ejecucin 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 cualificacin: orientadas a la comprobacin del

diseo, 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 cualificacin se han centrado fundamentalmente

en los subsistemas y sistemas que tenan algn grado de desarrollo
adicional. Especial atencin se ha prestado al Sistema CENAMER en
el que los subsistemas de Supervisin, Tratamiento Radar y
Tratamiento Plan de Vuelo haban requerido desarrollos respecto del
producto estndar del contratista.
Las pruebas funcionales se implantaron para todos los sistemas

y sus correspondientes subsistemas.
10.3.3.3. Fases de las pruebas
La realizacin de pruebas se organiz de forma convencional

en dos fases: pruebas en fabrica y pruebas en emplazamiento.
a) Pruebas en fbrica.
Las pruebas en fbrica se llevan a cabo a nivel de

subsistemas de cada uno de los sistemas, realizndose 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 cualificacin

de diseo ya que las acciones correctoras que podran
152
resultar son ms fciles de llevar a cabo en fabrica que en

el emplazamiento.
Actualmente ya se han realizado las pruebas en fbrica de

SADR, SCDR y AFTN que se encuentran en fase de
instalacin en los emplazamientos. A continuacin 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 aceptacin global. Estas ultimas
corresponden con las asociadas a todos los sistemas
integrados. Actualmente se estn 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 aceptacin y permiten verificar la capacidad y estabilidad
en funcionamiento continuado de todos los sistemas
integrados.
10.3.3.4. Gestin de pruebas
Las pruebas se realizan de acuerdo al Plan de Pruebas y a los

Protocolos de pruebas especficos. Para monitorizacin control y
seguimiento de las pruebas, se han establecido unos documentos de
gestin 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 anomalas detectadas
153
durante la ejecucin de las pruebas; e informe de aceptacin, indica la

aceptacin 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

aceptacin de las pruebas.
Todas las actividades de verificacin y validacin descritas en

esta seccin 10.3, tienen una importancia notable en el proceso de
Ingeniera de Sistemas. Si la Revisin del Sistema de Requisitos puso
de manifiesto riesgos tcnicos, de plazos y econmicos, permitiendo
anticipar las medidas correctoras adecuadas, las pruebas permiten
comprobar que realmente el sistema EUROMAYA se ajusta a lo
especificado en todos sus aspectos tcnicos y operativos.
La deteccin temprana de errores y no conformidades en el

diseo y desarrollo de un sistema, permite prever problemas posteriores
y anticipar las medidas correctoras adecuadas. Las actividades de
verificacin y validacin han permitido en el proyecto EUROMAYA
identificar numerosos problemas que caso de haberse llegado a
concretar hubieran tenido importantes implicaciones tcnico-operativas,
econmicas y de plazos de ejecucin.
Las auditoras e inspecciones permiten detectar problemas que

pueden permanecer ocultos para el propio contratista, y cuya resolucin
redunda en una mayor eficacia y eficiencia de los recursos disponibles.
La realizacin de una exhaustiva revisin de especificaciones de

requisitos ha permitido identificar no conformidades de las propuestas
realizadas por el contratista con los requisitos tcnico-operativos del
sistema, y tomar las acciones correctoras oportunas que garantizan la
consecucin 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 organizacin y estructuracin
permite sistematizar la ejecucin y gestin de las pruebas aumentando
la eficacia de las mismas y reduciendo costes y esfuerzos.
155
156
157
11
Transicin
operativa en el
programa SACTA
158
11.1. Descripcin del programa SACTA
El programa SACTA lanzado por la Direccin General de Aviacin

Civil Espaola a principios de la dcada de los ochenta, tiene por objeto
la homogeneizacin y automatizacin del sistema de control de trfico
areo espaol, tanto de ruta como de aproximacin. En esa poca
existan diversos sistemas en operacin con tecnologas anticuadas y
heterogneas.
El programa, que supuso un reto para la administracin espaola

y para la industria nacional, se estructur en una serie de fases para
llevar a cabo la sustitucin 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, Aproximacin (APP) y Control de

Torre (TWR), seran equipadas, bien con posiciones subsidiarias de
alguno de los centros principales, bien con sistemas simplificados
derivados de los anteriores. Los sistemas se interconectaran entre s,
y responderan a una concepcin, diseo y tecnologa unificados.
El movimiento de aeronaves en el espacio areo espaol se

caracteriza por su gran estacionalidad. Existen das y horas en los que
se producen grandes concentraciones de vuelos. El programa SACTA
ha sido diseado para ayudar al control del trfico areo teniendo en
159
Transicin operativa en el programa SACTA
160
cuenta esas peculiaridades y para ser capaz de trabajar en las

condiciones de mxima capacidad de control exigidas, siempre
respetando los requisitos de seguridad.
El control de trfico areo soportado por el SACTA utiliza

vigilancia radar, gestiona los movimientos de aeronaves con el
tratamiento de la informacin de los Planes de Vuelo y permite las
comunicaciones orales entre piloto y controlador (radio) y entre
controladores (telefona).
Las funciones de control de ruta (sobrevuelos) y de aproximacin

(despegues y aterrizajes) son realizadas desde los Centros de Control
de Madrid, Barcelona, Canarias, Sevilla y Palma, en donde estn
operativos y en servicio los sistemas SACTA.
Isdefe ha participado en la ejecucin del Programa desde su

inicio, prestando asistencia tcnica a la Oficina del Programa (O.P.
SACTA), desde las fases iniciales de planificacin y especificacin de
requisitos (ao 1984, cuando todava Isdefe era ISEL) hasta la transicin
operativa y apoyo a la explotacin. Actualmente se ha cumplido el
objetivo de implantacin de la Versin 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 Versin I).
Especialmente interesante y delicadas han sido las transiciones

operativas que se han llevado a cabo en la instalacin y actualizaciones
posteriores de los sistemas en los distintos centros. Estas transiciones
entre las fases de implantacin 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 dedicacin
para el personal operativo y tcnico de la Administracin 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 trfico areo.
161
11.2. Transicin operativa
11.2.1. Caractersticas generales
Los sistemas de control de trfico areo tienen como

caracterstica principal la necesidad de garantizar una altsima
disponibilidad en la continuidad del servicio (24 horas al da y 365 das
al ao). Como ya se ha indicado con anterioridad la continuidad del
servicio es elemento imprescindible en el proceso de transicin.
Las transiciones que se han llevado a cabo pueden clasificarse

en tres tipos, de acuerdo al siguiente criterio de complejidad creciente:
a) Actualizacin (en uno o varios centros) de la versin/revisin

del sistema SACTA en servicio. Este tipo de transiciones se
produce cada vez que hay una actualizacin significativa de
la versin del SACTA.
b) Sustitucin de un sistema antiguo por el sistema SACTA

manteniendo la localizacin fsica del sistema, como por
ejemplo en los centros de Sevilla (1994), Barcelona (1995)
y Canarias (1994).
c) Sustitucin del sistema y de la ubicacin fsica del mismo

(traslado a otras instalaciones distantes algunos kilmetros).
Cabe resaltar las transiciones de los centros de Palma de
Mallorca (1989) y de Madrid (1990).
En los dos ltimos tipos de transicin es necesario mantener

durante un cierto tiempo los dos sistemas (antiguo y nuevo) funcionando
en paralelo por razones obvias de seguridad y de verificacin final del
sistema en implantacin. En todos los casos es necesario establecer
un Plan de Contingencia que garantice una vuelta atrs (retorno al
sistema antiguo) en caso de anomalas o problemas relevantes en el
nuevo.
162
La transicin operativa se estructura en tres fases: Planificacin,

Preparacin y Ejecucin.
11.2.2. Planificacin de la transicin
Elemento bsico e imprescindible es la realizacin de un Plan de

Transicin. En su elaboracin intervienen expertos de las reas de
ingeniera, operacin (personal de control) y apoyo logstico (personal
de mantenimiento), tanto de la propia O.P. SACTA como de los centros
y dependencias involucrados en el proceso. El Plan de Transicin describe
de una forma exhaustiva y detallada todas y cada una de las fases y
actividades a llevar a cabo durante la preparacin y la ejecucin de la
transicin, desde los puntos de vista tcnico, de logstica y de operacin.
El Plan incluye un calendario detallado (incluso por horas del

da) de todas las actividades de preparacin y ejecucin, 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 atrs.
Durante la planificacin fue necesario prestar especial atencin

entre otros a los siguientes aspectos:
a) Identificar las necesidades de componentes y elementos

(tcnicos y de infraestructura), adicionales a los propiamente
operativos, y que seran necesarios durante la transicin.
Esto fue especialmente critico cuando se realizaron traslados
de edificios, ya que aparecan necesidades de duplicacin
o redundancia para poder mantener los dos sistemas
(antiguo y nuevo) simultneamente en operacin. Por
ejemplo fue necesario identificar y especificar la duplicacin
necesaria y los mecanismos de conmutacin relativos a:
i) lneas de comunicaciones de voz (VHF y telefona);

ii) lneas de comunicacin radar;
163
iii) lneas de comunicacin de datos entre subsistemas y

tambin con centros colaterales (comunicacin
intercentros); y
iv) equipos adicionales de seguridad (ltimos recursos de
comunicaciones de voz, etc...).
b) Especificar las condiciones para iniciar la transicin relativas

al estado de la infraestructura y de los sistemas (hardware
y software), que se iban a poner en operacin, en los
aspectos asociados a su documentacin y a las pruebas.
Por ejemplo era requisito imprescindible que las pruebas
tcnicas (cualificacin de diseo y funcionales) hubieran sido
superadas satisfactoriamente en el emplazamiento.
Si existan anomalas, estas no deban 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 formacin y

entrenamiento del personal operativo y de mantenimiento en
los nuevos sistemas. Un aspecto fundamental a tener en
cuenta era la necesidad de formacin en los procedimientos
operativos especficos de la transicin (especialmente los que
estaran vigentes durante el funcionamiento en paralelo de
los dos sistemas). Hay que tener en cuenta que aunque los
dos sistemas estn en paralelo el control efectivo se realiza
nicamente desde uno de ellos y es necesario establecer
procedimientos de coordinacin muy precisos.
d) Determinacin y especificacin de los recursos humanos y

materiales necesarios para llevar a cabo las actividades de
preparacin y ejecucin de la transicin. En algunos casos
y dado lo ajustado de las plantillas es necesario prever
164
perodos de trabajo extras para determinados colectivos,

con el impacto econmico asociado.
e) Identificacin y especificacin previa de las medidas

restrictivas del entorno operativo. Se prevn las reducciones
en capacidad de trfico, de comunicaciones y de
coordinacin con colaterales, que se establecern
temporalmente durante los perodos iniciales de
funcionamiento del sistema como medida de precaucin.
Por ejemplo se defini la reduccin de numero de vuelos
que se podran controlar simultneamente (por sector de
control y para todo el centro de control), o la reduccin en
frecuencias operativas de comunicacin tierra/aire y de
lneas de telefona.
11.2.3. Preparacin de la transicin
De acuerdo al Plan de Transicin establecido, se realizan todas

las actividades preparatorias. Entre otras cabe resaltar como
significativas:
a) Implantacin previa de la infraestructura, y de la duplicacin

o redundancia de equipos y sistemas (se realizan pruebas
especificas de comprobacin de dichos elementos);
b) Establecimiento de los procedimientos operativos de

aplicacin durante la transicin, as como formacin y entre-
namiento al personal operativo en dichos procedimientos;
c) Formacin y entrenamiento del personal operativo y de

mantenimiento;
d) Comprobacin del estado de los equipos operativos

(documentacin y pruebas);
165
e) Establecimiento de un plan de vuelta atrs, en el caso de

que fuera necesario retornar al sistema (o a la versin)
anterior; y
f) Preparacin de las medidas restrictivas del entorno

operativo, y notificacin a los organismos nacionales e
internacionales involucrados.
11.2.4. Ejecucin de la transicin
La participacin de Isdefe en las diferentes ejecuciones de los

Planes de Transicin 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 transicin (Madrid)
Como ilustracin de las actividades de Isdefe, se describe a

continuacin la ejecucin de la transicin operativa de ACC/TMA
Madrid, por considerarse la transicin al nuevo centro de control de
Torrejn de Ardoz la ms compleja de las realizadas.
Las colaboraciones de Isdefe relacionadas con la transicin

podran clasificarse en tres fases:
a) Planificacin y preparacin.
En esta fase se ha participado en tareas destinadas a

garantizarlos mnimos riesgos en la ejecucin de la
transicin:(1) definicin del Plan de Transicin; (2) pruebas
de carga (protocolos, seguimiento de pruebas, etc.); (3)
pruebas de estabilidad; (4) ensayos de la implantacin de
166
la ejecucin del Plan de Transicin; y (5) formacin del

personal de control y mantenimiento.
El Plan de Transicin de Madrid ha presentado dificultades

(primera implantacin completa del SACTA), funcionales (no
haban sido utilizadas en la prctica las prestaciones de los
sistemas SACTA) y operativas (el personal de control y de
mantenimiento haba recibido cursos pero siempre es necesario
una adaptacin y familiarizacin a los nuevos sistemas).
Como la transicin de Madrid se realizaba entre dos edificios

distanciados (Paracuellos y Torrejn), las vuelta atrs
exigan duplicidad de sistemas y personal operando
coordinada y simultneamente.
b) Ejecucin de la Transicin. Las actividades realizadas han

sido: (1) implantacin del Plan de Transicin; (2) apoyo al
personal de control y mantenimiento en la transicin; (3)
estrategias de reaccin ante eventos de funcionamiento
incorrecto de los sistemas SACTA; (4) seguimiento y anlisis
del comportamiento de los sistemas SACTA; y (5) propuesta
e implantacin de mejora y arreglo de averas en los
sistemas SACTA.
c) Post-transicin. En esta fase se realizan las siguientes

actividades: (1) anlisis y seguimiento de fallos; (2)
estadsticas de comportamiento; (3) implantacin de mejoras
y arreglo de fallos; y (4) estrategias de mantenimiento.
La transicin operativa ha permitido la implantacin de las

capacidades y prestaciones del SACTA de forma gradual e
incrementndose el trfico areo a controlar de forma coordinada.
167
El programa SACTA ha proporcionado al controlador una mayor

fiabilidad y precisin en cuanto a deteccin y localizacin de aeronaves,
ayuda a la toma de decisiones mediante el suministro de datos
auxiliares en tiempo real, deteccin de posibles conflictos entre
aeronaves, mxima flexibilidad en cuanto a configuraciones de los
sistemas y reduccin 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 absorcin
de trfico areo con mayor seguridad y eficacia.
168
169
12
Sistema de
gestin integrada
del programa TLE
170
12.1. Introduccin
El profesor Benjamin Blanchard, en la primera de las monografas

de esta serie, manifiesta que la implantacin con xito de la ingeniera
de sistemas requiere que los principios y elementos en los que sta se
apoya, sean seguidos a lo largo del proceso de obtencin de los
sistemas y abarca tanto la ejecucin y desarrollo de las tcnicas
apropiadas, como los conocimientos de gestin y direccin necesarios
para hacerlos realidad. Para ello debe seguirse un plan bien pensado,
estructurado y ordenado.
Bajo estos dos principios se integran conceptualmente la

planificacin y gestin de un programa entre las disciplinas de ingeniera
de sistemas. El objeto de este Captulo es describir la manera en que
se estn aplicando las tcnicas de planificacin y gestin en el mbito
del programa TLE (Equipos Limitados por el Tratado).
12.2. Descripcin del programa TLE
12.2.1. Objetivo
El Tratado FACE (Fuerzas Armadas Convencionales en Europa)

entre la OTAN y los pases del bloque del Este tiene por objeto la limitacin
del armamento convencional en Europa. Aprovechando este tratado la
OTAN decidi reforzar su flanco Sur transfiriendo coordinadamente
171
Sistema de gestin integrada del programa TLE
determinados equipos TLE (Equipos Limitados por el Tratado) a Grecia,

Turqua, Portugal y Espaa. Como consecuencia de la ratificacin del
Tratado FACE, Espaa decidi aceptar la transferencia de carros de
combate, piezas de artillera y transportes oruga, comprometindose a
mantenerlos operativos y a disposicin del esfuerzo comn, y a destruir
los equipos sobrantes que rebasen el lmite fijado por el Tratado.
A estos efectos se cre en 1992 en el mbito del Cuartel General

del Ejrcito, 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 revisin y potenciacin, constituir unidades operativas con
dichos carros, adquirir el equipamiento y los medios y vehculos auxiliares
precisos, crear una estructura para el mantenimiento en estado operativo,
instruir tripulaciones y especialistas, crear un centro de instruccin,
gestionar el proceso de reduccin 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. Situacin actual del programa
Estas actuaciones se han materializado en ms de cien

expedientes de contratacin o de cesin de crdito, que se estn
gestionando por la Oficina de Programa TLE y que abarcan el mbito
temporal comprendido entre 1992 y 1997, estndose actualmente en
plena fase de produccin/implantacin, habiendo comenzado la vida
operativa para alguno de los equipos transferidos.
En toda esta problemtica de adquisicin y gestin de medios y

recursos que supone el programa TLE y que se coordina desde la Oficina
de Programa, estn involucrados en el cumplimiento de sus funciones
distintos centros y organismos del Ejrcito, como son la Direccin de
Abastecimiento y Mantenimiento con muchas de sus secciones y
negociados, los rganos logsticos centrales, Parque Central de Material
de Automocin, Centros de Mantenimiento de Sistemas Acorazados,
172
Unidades Mviles 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 Espaa,
Portugal, Grecia y Turqua, y la Agencia OTAN de Abastecimiento y
Mantenimiento (NAMSA), as como los mltiples contratistas y
subcontratistas nacionales e internacionales comprometidos.
12.3. La gestin del programa TLE
12.3.1. Ingeniera y gestin
La gestin y control de un programa es un elemento

indispensable en el proceso de la ingeniera de sistemas, aunque con
frecuencia no se considere as. Se requiere de un sistema de
informacin que identifique, recopile y trate los datos precisos para
disponer a tiempo til, de una visin clara, completa y con perspectiva
de la situacin del programa y de su posible evolucin.
Disponer de estos sistemas de informacin para la gestin

posibilita la pronta deteccin de cualquier desviacin o tendencia
anmala aparecida, con la consecuente identificacin de reas
potenciales de riesgo y el inicio inmediato de las acciones correctivas
necesarias.
En este Captulo se describen los pasos dados en el programa

TLE del Ejrcito para disponer, por aplicacin de los conceptos de
ingeniera relativos a planificacin y organizacin y bajo la premisa de
que la base del control est en la accin de medir, de un sistema de
informacin de soporte a la gestin.
La gestin de los proyectos individuales que constituyen el

programa TLE, requiere el control de los riesgos y la correccin 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 informacin que garantice
por un lado la recopilacin de los datos precisos de forma continuada,
y por otro, el tratamiento de dichos datos, de manera que se extraiga la
informacin esencial para que sta le sea presentada al rgano de
gestin de manera clara y concisa.
12.3.2. Colaboracin de Isdefe en el programa TLE
La actuacin de Isdefe se ha centrado en prestar apoyo a la

Oficina de Programa TLE en las siguientes reas:
a) Seguimiento y control de la situacin de los trabajo de los

contratistas en cuanto a adecuacin a las necesidades del
Ejrcito tanto desde el punto de vista operativo/tcnico como
de plazos y costes;
b) Gestin de configuracin de los carros transferidos,

proporcionando la capacidad de mantener el control sobre
la configuracin de estos, desde su inspeccin inicial previa
a la transferencia, a lo largo de su vida operativa; y
c) Gestin de repuestos TLE, coordinando la adquisicin de

repuestos a NAMSA, su recepcin, distribucin,
almacenamiento, y la gestin del proceso de abastecimiento
(peticiones, solicitudes, inventarios, recepcin, expedicin,
informes, etc.).
Entre otros aspectos, el apoyo de Isdefe se ha materializado en

el diseo, desarrollo e implantacin de un sistema de informacin que
posibilita a la Oficina de Programa recoger, procesar, distribuir y archivar
la gran cantidad de datos e informacin a coordinar y gestionar,
proveniente o con destino en las industrias nacionales y extranjeras,
entidades y organismos del Ministerio de Defensa y del Ejrcito que
174
estn involucrados con el programa TLE. Este sistema de informacin

es el Sistema de Gestin Integrada del programa TLE.
12.3.3. El Sistema de Gestin Integrada del programa TLE
Tiene por objetivo proporcionar de forma continua a la Jefatura

de Programa la informacin de la situacin de los contratos del ncleo
del programa de manera que permita la toma de decisiones en tiempo
til. El ncleo del programa, que supone el 50% del presupuesto total
del mismo, lo constituyen cuatro contratos: Reduccin de TLEs, Carros
de Recuperacin, Revisin y Potenciacin de Carros.
Aunque cada contrato o proyecto individual de los que

constituyen el ncleo del programa TLE tiene ciertas peculiaridades
propias, el Sistema de Gestin Integrada trata a todos en base a una
arquitectura funcional similar, en la que estn implicados los mismos
elementos.
12.3.4. Elementos del diseo del sistema de gestin
Adems de otras limitaciones y requisitos menores, el requisito

esencial bajo el que se desarrolla el Sistema de Gestin Integrada del
programa TLE, es, como ya se ha dicho, proporcionar en tiempo til,
la informacin de la situacin de los contratos. El puente entre estos
requisitos y la implementacin que los satisface ha sido el trabajo de
diseo realizado, que, para el Sistema de Gestin, ha seguido dos
etapas: diseo conceptual y diseo detallado.
El objetivo del diseo conceptual (qu hay que hacer) ha sido

el especificar una arquitectura del sistema que satisfaga los requisitos
y limitaciones. El diseo detallado posterior ha proporcionado los
detalles en cuanto al tratamiento y representacin de los datos (cmo
hay que hacerlo).
175
Los procesos integrados bajo la arquitectura del Sistema de

Gestin son los siguientes: captura de datos, transmisin de datos,
anlisis de los datos de gestin y presentacin de informacin. 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 informacin.
Como notacin de diseo se han utilizado los diagramas de flujo

de datos, entre otras razones por la facilidad de estos para representar
cualquier nivel de abstraccin. La Figura 12.2 presenta el diagrama de
contexto que ilustra la arquitectura del Sistema de Gestin al nivel ms
alto, donde se indican las entidades externas que se relacionan con el
sistema (fuentes de informacin y destinatario de los informes), y los
conjuntos de datos que fluyen en cada caso.
Los elementos sobre los que se ha construido el diseo,

recogidos en el diagrama de contexto, han sido:
1) Datos: Constituidos por la informacin 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 anlisis, los informes de gestin
precisos.
Los requisitos del Sistema de Gestin del TLE han hecho posible
considerar tres tipos de datos: referencia, control y logstica.
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 gestin. Los datos de
control se han agrupado en: datos econmicos y datos de
situacin de obra de cada contrato.
c) Datos de logstica: Son los datos integrados por la Base de

Datos de Inspeccin, el Sistema de Gestin de Repuestos y
la Base de Datos de Configuracin. La Base de Datos de
Inspeccin, que junto con la informacin proporcionada por
el Sistema de Gestin 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 Mnimo Operativo Espaol (MOE).
2) Fuentes de informacin: 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 Gestin 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 Contratacin, que genera los datos de referencia

que se encuentran en las prescripciones tcnicas de cada
expediente.
c) Comisin 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 Contratacin. Adems proporciona datos de control relativos
a la gestin del programa y relacionados con la planificacin,
como calendarios de entregas y recepciones de material, etc.
d) Seccin Tcnica a travs de la que se obtienen los datos

tcnicos necesarios relativos a los procesos y trabajos que
comporta cada expediente.
e) Seccin Econmico-Financiera que es quien proporciona

los datos econmicos del programa a nivel de cada
expediente.
f) Inspecciones Tcnico-Receptoras, que proporcionan los

datos de avance de obra, a travs de los Responsables de
Aseguramiento de la Calidad (RAC) de cada contrato.
3) Flujos de datos/canales de transmisin: Es el conjunto de

procedimientos, mtodos y medios, que permiten que los datos se
transmitan, desde las fuentes de informacin hasta el centro de proceso y
anlisis 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 ncleo del programa.
Se recoge en la Figura 12.4 el flujo de datos entre estas entidades

asociadas al Sistema de Gestin Integrada.
a) El flujo de datos que proporcionan las Inspecciones Tcnico

Receptoras consiste esencialmente en:
i) Datos para determinar el grado de avance de los trabajos

(Puntos de Inspeccin 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 identificacin, fecha de envo, fecha de recepcin,
etc.).
180
iii) Datos de tems/equipos a entregar por Ejrcito de Tierra

(datos de filiacin, fecha de recepcin, etc.).
iv) Datos para el control y seguimiento de la planificacin de

los trabajos (fecha de recepcin/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 generacin de informes
Para alcanzar el objetivo de obtener una informacin procesada,

til para la toma de decisiones relacionadas con la gestin de cada
contrato, los datos son sometidos al conjunto de procesos (fusiones,
filtrados, combinaciones y algoritmos) que se describen a continuacin.
181
El diagrama de la Figura 12.5 constituye una descomposicin

funcional de primer nivel del Sistema de Gestin Integrada que se
obtiene abriendo el diagrama de contexto presentado en la Figura 12.2.
Se ha seguido el siguiente convenio de representacin:
a) Los procesos a que se someten los datos se representan

por crculos;
b) Las flechas representan flujos de datos; y
c) Las barras paralelas horizontales representan bases de

datos para almacenamiento de los mismos.
El diseo del Sistema de Gestin realizado, ha permitido

identificar a este nivel los siguientes cinco procesos de datos:
1) Seguimiento de la planificacin del ncleo del programa.

Para cada uno de los contratos del ncleo del programa,
este proceso mantiene actualizada la planificacin 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 planificacin, al objeto de establecer la situacin
respecto al cumplimiento de la misma.
2) Disponibilidad de carros. Aunque los cuatro contratos del

ncleo del programa son tcnicamente independientes, la
disponibilidad de carros operativos en el Ejrcito de Tierra
en un momento dado es el aspecto esencial a travs del
que se relacionan y que incide en todos los contratos. La
informacin 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 ncleo

del programa con Puntos de Inspeccin 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

planificacin prevista y se compara con el avance
realizado hasta la fecha.
c) Nmero de carros, subconjuntos y elementos

importantes que se encuentran reparados y disponibles
para montaje.
d) Planificacin de entregas y recepciones de material por

parte de Ejrcito 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 estndar, de las que estn fuera del proceso
estndar.
5) Situacin econmica del programa. Este proceso genera los

informes de la situacin econmica del programa que a
continuacin se indican, a partir de los datos actualizados
de la base de datos para el Seguimiento de la Gestin de
Presupuestos:
a) Diagrama general del gasto asignado, iniciado, adjudicado

y librado del programa.
b) Resumen de la situacin de la contratacin prevista en el

ao en curso, tanto para mantenimiento como para
inversin.
184
c) Gasto adjudicado a empresas, nacionales o extranjeras,

por anualidades, pendientes de adjudicar en los distintos
elementos de programa, comprometidos para prximas
anualidades, etc.
La informacin 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 situacin de los expedientes.
Estos informes contienen tambin las conclusiones que se

derivan del anlisis de la situacin, y la propuesta de acciones
correctoras en caso de existir desviaciones respecto a los requisitos
de calidad, coste o plazo. Los informes sistemticos que, con una
periodicidad bimensual, genera el Sistema de Gestin son bsicamente
los siguientes:
a) Informe gerencial, en el que se resume la situacin general

del programa a la fecha, y se enumeran los aspectos crticos
y las acciones correctoras propuestas.
b) Situacin econmica del programa, donde se recogen los

diagramas en los que se representa la situacin econmica.
c) Disponibilidad de carros, que recoge la previsin actualizada

de disponibilidad de carros, de acuerdo con las
planificaciones de los expedientes.
d) Planificacin de los expedientes del ncleo del programa,

en donde se presentan las planificaciones actualizadas de
los expedientes del ncleo. En estos diagramas se
incorpora el avance de los trabajos sobre la planificacin
de referencia, y los hechos destacables que hayan tenido
lugar. Tambin 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 inclusin de diagramas
de Puntos de Inspeccin 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
Eplogo
188
13.1. Introduccin
La experiencia es la madre de la ciencia, dice uno de nuestros

ms populares refranes. Y encierra una gran verdad. La teora es
importante, pero la prctica es insustituible. Slo se puede hablar con
propiedad de aquello que se conoce por haberse experimentado. El
objetivo de este ltimo Captulo es resumir la experiencia acumulada
por Isdefe no slo en los once programas que han servido para ilustrar
otros tantos aspectos del proceso de ingeniera de sistemas en los
Captulos precedentes, sino en el conjunto de todos los programas en
los que ha participado desde su creacin.
13.2. La rueda es redonda y rueda bien
Antes de comentar en detalle las lecciones aprendidas por Isdefe

en su aplicacin de los conceptos de ingeniera de sistemas, es
necesario destacar como primera leccin la importancia de no reinventar
la rueda. Con una frecuencia lamentable se tiende a consumir recursos
valiosos y escasos, como el tiempo, en el diseo de procedimientos o
mtodos para la resolucin de problemas bien conocidos y estudiados
con el agravante adicional del riesgo de no encontrar la solucin
adecuada u ptima, cuando una cierta labor de investigacin o
documentacin permitira conocer el mtodo o procedimiento ms
recomendado (si es que no fuera ya directamente conocido) en base a
la experiencia demostrada en su aplicacin.
189
Eplogo
Por ejemplo, supongamos que en el diseo de un sistema es

necesario realizar un anlisis de modos de fallos para identificar reas
crticas del diseo y poder tomar las acciones oportunas (por ejemplo
rediseo, o establecimiento de tareas de mantenimiento preventivo
que eviten la aparicin de ciertos modos de fallos o que al menos
palien sus efectos, si llegan a producirse). No sera lgico ni prctico
tratar de desarrollar un modelo propio para realizar tal tipo de anlisis,
cuando existen procedimientos bien documentados y ampliamente
contrastados (tales como el Anlisis de Modos de Fallos, sus Efectos
y su Criticidad, o el Anlisis de rboles de Fallos) que se ajustan a lo
necesitado. En todo caso, siempre puede modificarse algn
procedimiento o mtodo existente para que refleje aspectos particulares
importantes del caso en estudio.
Es pues tan necesaria la informacin como la formacin. Sin

una buena preparacin es difcil afrontar con xito problemas complejos,
y una falta de informacin puede suponer un aprovechamiento ineficaz
e ineficiente de los recursos empleados por haberse tratado de
reinventar, una vez ms, la rueda.
13.3. Resumen de lecciones aprendidas
Partiendo de la caracterstica teleolgica de los sistemas

diseados por el hombre, un planteamiento metdico y estructurado
de anlisis de las necesidades identificadas es esencial para la precisa
determinacin 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 evolucin 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 planificacin. Sin una
190
rigurosa identificacin, definicin y ordenacin de las actividades a

realizar es imposible alcanzar los objetivos de la ingeniera de sistemas.
Nunca se enfatizar lo suficiente la importancia de una

especificacin de requisitos correcta (que realmente defina la necesidad
identificada) y completa (que cubra todos los aspectos relevantes); no
deben ser ni ms 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 definicin cualitativa y
cuantitativa de lo que el usuario necesita, y una buena especificacin
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 diseos y desarrollos
sobre especificaciones excesivamente incompletas o inestables, en la
creencia de que se va adelantando trabajo, pues las adiciones y
modificaciones posteriores aumentan dramticamente los plazos y
costes de obtencin de los sistemas.
Adems, es vital que los requisitos puedan realmente ser

diseados en el sistema y que su cumplimiento pueda ser
posteriormente comprobado (verificado) por mtodos objetivos. Junto
con la indicacin de los mtodos a seguir, en la demostracin de los
requisitos especificados, deben concebirse, planificarse y
estructurarse desde las fases iniciales del ciclo de vida las pruebas
que sern realizadas en las etapas finales del diseo y de la
produccin.
Muchas de las actividades del proceso de ingeniera de sistemas

requieren la seleccin entre posibles alternativas. Puede tratarse de elegir
entre diferentes ofertas recibidas aquella que ms se ajuste a lo solicitado,
o de seleccionar entre configuraciones alternativas de diseo la que
cumpla en mayor medida con los requisitos establecidos, etc. El hecho
de que las alternativas a evaluar posean mltiples caractersticas, no
todas definibles con una misma medida, hace imprescindible el desarrollo
de modelos multiatributo de evaluacin que permitan sintetizar, de forma
191
Eplogo
objetiva, las mltiples caractersticas de cada alternativa para poder

compararlas entre s.
De forma similar, muchas de las decisiones que deben tomarse

a lo largo del proceso de ingeniera 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 diseo y desarrollo de sistemas se presentan
desviaciones sensibles entre los plazos, prestaciones tcnicas y
costes previstos, y los finalmente alcanzados, marca la importancia
de realizar los oportunos anlisis de riesgos desde las etapas ms
tempranas del ciclo de vida de los sistemas. La dificultad principal
con la que tropieza el anlisis de riesgos durante las fases iniciales
del ciclo de vida es la escasez de informacin, lo que impide en
muchas ocasiones la cuantificacin formal del riesgo, conduciendo a
un entorno de decisin bajo incertidumbre. La forma ms eficaz de
superar estas dificultades es utilizar la experiencia acumulada en
proyectos anteriores, articulando un procedimiento que facilite su
reutilizacin.
Las estimaciones de costes, ya sean paramtricas, integradoras

o por analoga, 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 diseo 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 diseo y de

desarrollo, as como los aspectos relacionados con su utilizacin y
mantenimiento, implican la necesidad de un riguroso control de su
configuracin. La gestin de la configuracin es una funcin esencial
cuya ejecucin abarca todo el ciclo de vida de los sistemas, y que
facilita en gran medida su obtencin y posterior utilizacin. La
implantacin de los conceptos y principios de ingeniera de sistemas
192
requiere disponer de una eficaz gestin de la configuracin. En su

concepcin genrica la gestin de la configuracin es comn para
todo tipo de sistemas y comprende las siguiente reas funcionales :
identificacin, control, registro de estados y auditoras de configuracin.
Para desarrollar la funcin de gestin de la configuracin, adems de
disponer de las correspondientes capacidades tcnicas y elementos
de apoyo, son necesarios los aspectos concernientes al establecimiento
de una estructura de organizacin y de unos procedimientos que
aseguren en todo momento la consistencia e integridad de la informacin
asociada a los elementos del sistema objeto de gestin de la
configuracin.
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 transicin entre ambos. La
transicin debe llevarse a cabo por personal cualificado con elevada
experiencia en los sistemas a implantar, desde puntos de vista tcnicos,
funcionales y de usuario. La previsin de la mayor parte posible de
eventos que puedan presentarse, slo puede ser realizada por personas
que hayan participado en todas las fases previas del programa. La
reaccin ante eventos imprevistos que pueden aparecer en una
transicin debe ser inmediata, efectiva y con la mayor fiabilidad y
seguridad posible. La comprobacin de la bondad de un plan de
transicin slo se realiza de forma completa en el momento de su
implantacin.
En resumen, la ingeniera 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 consideracin 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
Eplogo
13.4. Kaizen
Kaizen significa, en japons, mejora continua [15]. Esa es la

actitud del verdadero ingeniero de sistemas, una constante inquietud
por mejorar su formacin 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 ingeniera de sistemas para obtener sistemas
que satisfagan, de forma eficaz y eficiente, necesidades identificadas;
es imprescindible tener una visin de conjunto y conocer el porqu de
lo que hay que hacer y de cmo hay que hacerlo, que ms que un
estado que alguna vez pueda decirse que se ha alcanzado es la
direccin 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 Teora General de Sistemas, Publicaciones

de Ingeniera de Sistemas, Isdefe, Madrid, 1995.
[4] Drew, D.R., Dinmica de sistemas Aplicada, Publicaciones

[5] Aracil, J., Dinmica de Sistemas, Publicaciones de

Ingeniera de Sistemas, Isdefe, Madrid, 1995.
[6] Blanchard, B. S., Ingeniera de Sistemas, Publicaciones

[7] D. G. Telecomunicaciones, Escenarios de usuarios y

aplicaciones en PlanBA, Madrid, 1991.
[8] D. G. Telecomunicaciones, Tecnologas relevantes en

PlanBA, Madrid, 1991.
[9] D. G. Telecomunicaciones, Plan de Trabajo PlanBA,

Madrid, 1991.
[10] D. G. Telecomunicaciones, Gua para presentar propuestas

a PlanBA, Madrid, 1991.
[11] Stanag 4175, Technical Characteristics of MIDS.
[12] Stanag 5516, Tactical Data Exchange, Link 16.
[13] Quiones, M. R., Sistema SADA Semiautomtico de Defensa

Area, Revista de Aeronutica y Astronutica, noviembre, 1984.
197
Referencias
[14] Sistema de Mando y Control Areo, (ejemplar monogrfico),

Revista de Aeronutica y Astronutica, septiembre 1990.
[15] Imai, M., Kaizen, McGraw-Hill Publishing Co., Nueva

York, 1986.
198
199
Bibliografa
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: Reingeniera de la Empresa,
Parramn Ediciones, Barcelona, 1994.
Handel , R. &
M.N. Huber: Integrated Broadband Networks,
Addisson-Wesley, Gran Bretaa, 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
Bibliografa
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. ANLISIS DE RIESGO. Anlisis matemtico 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 podra ir mal.
2. AUDITORAS DE CONFIGURACIN. Verificacin de la

conformidad de los elementos de configuracin respecto a
especificaciones y otros requisitos establecidos (control de calidad,
planes de gestin de configuracin, etc.). Las auditoras pueden ser
funcionales o fsicas.
3. COMIT DE CONTROL DE CONFIGURACIN. Comit

compuesto por representantes de las funciones tcnicas y
administrativas de un sistema que aprueban o rechazan los cambios
de ingeniera propuestos en una lnea base previamente aprobada.
4. COMUNICACIONES DE BANDA ANCHA. Transmisin y

conmutacin de datos, voz e imagen fija o en movimiento a velocidades
superiores a 2 Mbit/s (tpicamente 34, 155 622 Mbits/s). Las
comunicaciones de banda ancha estn asociadas a tecnologas
avanzadas como la transmisin por fibra ptica, el Modo de
Transferencia Asncrono (MTA) o la microelectrnica de alta velocidad.
5. CONTROL DE CONFIGURACIN. La propuesta

sistemtica, justificacin, evaluacin, coordinacin, aprobacin o
rechazo de los cambios y la implantacin de todos los cambios
205
Glosario
aprobados en la configuracin de un elemento de configuracin

despus del establecimiento formal de su lnea base de referencia. El
control de la configuracin proporciona una metodologa a seguir para
el tratamiento de alteraciones en los componentes y lneas de
referencia. Mediante un soporte tcnico 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 tecnologa de comunicaciones en concreto.
7. ELEMENTO DE CONFIGURACIN. Conjunto de hardware,

firmware, software, o cualquiera de sus elementos discretos, que
satisface una funcin final y forma parte de la gestin de configuracin.
Cualquier elemento requerido para el apoyo logstico y que se puede
adquirir de forma independiente, es un elemento de configuracin y
puede variar en complejidad, tamao y tipo.
8. ELEMENTO DE RIESGO. Una posible desviacin entre lo

ofertado y el subsistema final que pueda conseguirse.
9. ENTORNO DE INCERTIDUMBRE. Entorno de decisin en

el cual no se conocen las distribuciones probabilsticas del espacio de
alternativas.
10. ENTORNO DE RIESGO. Entorno de decisin en el cual se

conocen las distribuciones probabilsticas del espacio de alternativas.
11. ESCENARIO. Descripcin preceptiva del estado futuro de

un sistema o subsistema, teniendo en cuenta las diversas restricciones
y problemas que se pretenden resolver con la implantacin de conceptos
existentes o nuevos.
12. ESTIMACIN DE COSTE INTEGRADORA. Tcnica que

se caracteriza por el anlisis en profundidad de todos los elementos,
206
procesos, componentes y conjuntos que componen un sistema y la

aplicacin de los costes horarios, de materiales y gastos generales a
cada uno de estos elementos.
13. ESTIMACIN DE COSTE POR ANALOGA. Tcnica que

utiliza la similitud entre dos o ms sistemas para la medicin de los
costes asociados con el desarrollo, fabricacin y/o modificacin de un
elemento especfico.
14. ESTIMACIN PARAMTRICA DE COSTE. Tcnica que utiliza

una o ms relaciones de estimacin de coste para medicin de los costes
asociados con el desarrollo, fabricacin, y/o modificacin de un elemento
especfico y se basa en sus caractersticas tcnicas, fsicas u otras.
15. FUNCIN DE UTILIDAD. Funcin del espacio de

alternativas a los nmeros reales que expresa las preferencias del
decisor, esto es: x es preferido a y si y slo si u(x) > u(y).
16. GESTIN DE CONFIGURACIN DE UN SISTEMA. La

parte del proceso de ingeniera de sistemas que identifica las
caractersticas fsicas y funcionales de los elementos de un sistema
durante su ciclo de vida, controla los cambios a dichas caractersticas,
y registra e informa del proceso de cambios y el estado de ejecucin.
17. IDENTIFICACIN DE CONFIGURACIN. El proceso de

documentar los requisitos de prestaciones, cualificacin, fabricacin y
aceptacin de los elementos de la configuracin de un sistema.
Generalmente se desarrolla y mantiene a travs de los distintos niveles
incrementados, cada uno de ellos utilizado para establecer una lnea
base especfica. Estos tres niveles son: (1) identificacin de la
configuracin funcional; (2) identificacin de la configuracin distribuida;
y (3) identificacin de la configuracin de producto.
18. NDICES DE RENTABILIDAD. Mtodos cuantitativos en los

que se valoran aspectos financieros de la empresa.
207
Glosario
19. LISTAS DE CONTROL. Sistemas bsicamente cualitativos

en los que se valoran, de forma subjetiva, diversos criterios de una
oferta.
20. MODO DE TRANSFERENCIA ASNCRONO (MTA).

Tecnologa de transmisin y conmutacin de paquetes de longitud fija
(53 octetos) muy flexible para el transporte de informacin (datos , voz
e imagen fija o en movimiento). Est ligado a las tecnologas de
comunicaciones de banda ancha.
21. PlanBA. Plan de accin nacional para la I+D en

comunicaciones integradas de banda ancha, desde 1992 a 1995.
22. PROBABILIDAD SUBJETIVA. Expresin de la susceptibi-

lidad de prediccin basada en valoraciones personales que cumple
los axiomas de probabilidad.
23. PROCEDIMIENTO. Metodologa que define claramente la

forma en que debe realizarse una evaluacin incluyendo formatos, mtodos
a utilizar, forma de asignacin de grupos evaluadores, generacin de
informes, archivo y tratamiento de la documentacin generada etc.
24. RELACIN DEL ESTADO DE LA CONFIGURACIN.

Suministra la historia de como un sistema ha sido cambiado, registrando
las actividades de las otras funciones de la gestin de la configuracin.
En un momento determinado, disponer de los registros de los cambios
realizados en el sistema permite diagnosticar fallos en el mismo.
25. TRANSICIN OPERATIVA. Accin encaminada a permitir

la entrada en operacin de nuevos sistemas o versiones de un programa
sin afectar a la eficacia, fiabilidad y seguridad del servicio a prestar.
26. VALIDACIN. Proceso de evaluacin de un elemento de

configuracin para determinar el grado de cumplimentacin de los
requisitos especficos.
208
27. VERIFICACIN. Proceso de evaluacin de los productos

de una determinada actividad de desarrollo para determinar la
consistencia y correccin con respecto a los productos suministrados
como entrada a esta actividad, y conforme a las normas y
procedimientos que regulan la ejecucin de la actividad.
209
Glosario
210
211
Esta primera edicin de

de la serie de
Monografas de Ingeniera de Sistemas
se termin de imprimir el da
15 de septiembre de 1995.

Isdefe - Ingenieria de Sistemas Aplicada PDF

Cargado por

Información del documento

Título original

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

Isdefe - Ingenieria de Sistemas Aplicada PDF

Cargado por

Copyright:

Formatos disponibles

Publicaciones de Ingeniera de Sistemas

COMIT DE REDACCIN 1. Ingeniera de Sistemas. Benjamin S. Blanchard.

INGENIERA DE SISTEMAS APLICADA. Isdefe

No est permitida la reproduccin total o

Primera Edicin: Septiembre - 1995

Madrid, 15 de septiembre de 1995

Han transcurrido ya diez aos desde la creacin de Isdefe en

La serie de monografas que estamos editando est orientada a

La intencin de la monografa que ahora se presenta es reflejar,

Quiero agradecer al personal de la empresa que est colabo-

Jos Vicente Cebrin

2. AEGIS: DISEO CONCEPTUAL DEL FUTURO SISTEMA

3. EVALUACIN DE DESARROLLOS BASADOS EN UNA NUEVA

5. ANLISIS DE RIESGOS DURANTE LA EVALUACIN DE OFERTAS

5.3. La metodologa utilizada 62

6.1. Descripcin general del programa Simca 76

7. ANLISIS DE VALOR EN LA F-100

8. GESTIN DE LA CONFIGURACIN EN EL SCTM

9. PROCESO DE SELECCIN DE EQUIPOS Y SUMINISTRADORES

10. VERIFICACIN Y VALIDACIN EN EL PROGRAMA EUROMAYA

11. TRANSICIN OPERATIVA EN EL PROGRAMA SACTA

12. SISTEMAS DE GESTIN INTEGRADA DEL PROGRAMA TLE

13. EPLOGO (Alberto Sols Rodrguez-Candela) 187

1.1. Evolucin de la complejidad de los sistemas

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

1.2. El enfoque sistmico

Tanto el concepto de sistema como el modelo empleado para su

del presente siglo el paradigma empleado en la conceptualizacin de

La Figura 1.1 muestra la relacin entre la cantidad y calidad de

los compromisos que al tomarlas se contraen, hace especialmente

1.3. La creacin de Isdefe

En el final de la dcada 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 pases aliados, se detectaron numerosos

La propia concepcin de Isdefe como un engranaje ms de esa

1.4. Experiencia de Isdefe en ingeniera de sistemas

Isdefe ha acumulado, en estos primeros diez aos, ms de 1.6

sistmico. Aproximadamente un 70% de esas horas han correspondido

Si la cuarta monografa de esta serie, Dinmica de Sistemas

El objetivo de esta monografa es resumir la experiencia

1.5. Desarrollo de la monografa

Cada uno de los siguientes once captulos ilustra un aspecto

sino reflejar las actividades realizadas en ellos por Isdefe en relacin

En el Eplogo se resumen las lecciones aprendidas, fruto de las

2.1. Descripcin global del proyecto AEGIS

En los ltimos aos distintas organizaciones europeas e

Los miembros del consorcio AEGIS eran Arospatiale, BNR

El proyecto se dividi en tres fases: evaluacin, mejora y

de trabajo tcnicos y uno de gestin. En la fase de evaluacin, el

Isdefe particip en el proyecto AEGIS como coordinador.

2.2. Relacin del proyecto con la ingeniera de sistemas

La totalidad del trabajo que se ha llevado a cabo en el proyecto

2.3. Fase 1: evaluacin

Como primer paso de la fase de evaluacin, el consorcio

nivel de descripcin, si eran generales o especficos, si proponan un

Antes de proceder a desarrollar una metodologa para la

Basndose en el ciclo de vida del sistema, el consorcio defini

1) Identificacin de las necesidades del cliente: consideracin

2) Elaboracin de esquemas de soluciones: delimitacin del

3) Desarrollo de soluciones: exposicin en detalle de las

4) Transicin: definicin de uno o varios caminos alternativos

5) Mejoras previstas: identificacin de los efectos y beneficios

6) Conclusiones: resumen de los resultados del escenario y