Diseño digital

Vista previa del material en texto

GESTIÓN DE 
SISTEMAS COMPLEJOS 
MEDIANTE 
INGENIERIA DE SISTEMAS 
 
 
 
 
 
 
 
 
 
 
 
 
 
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA 
UNIVERSIDAD DE SEVILLA 
MÁSTER EN ORGANIZACIÓN INDUSTRIAL 
Y GESTIÓN DE EMPRESAS 
TRABAJO FIN DE MÁSTER 
Sonia Pereira Álvarez 
28 de Noviembre, 2012 
 
 
 
 
 
Índice de Contenido 
 
1 INTRODUCCIÓN .................................................................................................... 1 
1.1 Historia de la Ingeniería de Sistemas .............................................................. 1 
1.2 ¿Qué es un Sistema? ...................................................................................... 2 
1.3 Algunas Definiciones de Ingeniería de Sistemas .............................................. 3 
2 METODOLOGÍA DE INGENIERÍA DE SISTEMAS ........................................................ 5 
2.1 Fase de Adquisición ....................................................................................... 8 
2.1.1 Diseño Conceptual ................................................................................. 8 
2.1.2 Diseño Preliminar ................................................................................. 12 
2.1.3 Diseño de Detalle y Desarrollo .............................................................. 14 
2.1.4 Construcción/Producción ..................................................................... 16 
2.2 Fase de Uso ................................................................................................. 17 
2.3 Actividades de Test en el Ciclo de Vida ......................................................... 18 
3 INVESTIGACIÓN DEL IMPACTO DE LA IS EN LOS PROYECTOS ................................. 20 
3.1 Impacto de la IS en los Costes ...................................................................... 24 
3.2 Impacto de la IS en el Tiempo ...................................................................... 29 
3.3 Impacto de la IS en la Calidad ....................................................................... 31 
3.4 Impacto de la IS en el Éxito .......................................................................... 33 
4 CONCLUSIONES ................................................................................................... 38 
5 BIBLIOGRAFÍA ..................................................................................................... 44 
6 ACRONISMOS Y ABREVIATURAS .......................................................................... 46 
 
 
Índice de Ilustraciones 
 
Ilustración 1: Esquema del Ciclo de Vida de un Sistema ......................................................... 5 
Ilustración 2: Proceso de Análisis, Síntesis y Evaluación. ....................................................... 6 
Ilustración 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema ............................. 7 
Ilustración 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012) ....................... 8 
Ilustración 5: Esquema de un Sistema FRACAS .................................................................... 17 
Ilustración 6: Sobrecoste vs Inversión en la Definición del Sistema (Gruhl, 1992) ................. 25 
Ilustración 7: Diferencia Esfuerzo de Desarrollo - Esfuerzo en IS (Gruhl, 1992) ..................... 25 
Ilustración 8: Presupuesto invertido en IS (Dr. Ave K. Kludze, 2004) .................................... 26 
Ilustración 9: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2004) ................ 27 
Ilustración 10: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2010) .............. 28 
Ilustración 11: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2004) ............... 30 
Ilustración 12: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2010) ............... 31 
Ilustración 13: Calidad Técnica vs Esfuerzo de IS (Honour, 2010) ......................................... 33 
Ilustración 14: Hipótesis de partida del estudio del SECOE (Honour, 2004) .......................... 34 
Ilustración 15: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2004) ............................... 34 
Ilustración 16: Éxito subjetivo vs Esfuerzo de IS (Honour, 2004) .......................................... 35 
Ilustración 17: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2010) ............................... 35 
Ilustración 18: Cumplimiento de objetivos (adaptación de Miller, 2000). ............................. 36 
Ilustración 19: Valor intuitivo de IS (Honour, 2006) ............................................................. 39 
Ilustración 20: Percepción de la Reducción del Riesgo con IS (Honour, 2006) ....................... 39 
Ilustración 21: Factores Cuantitativos (Honour, 2010) ......................................................... 42 
Ilustración 22: Factores Subjetivos (Honour, 2010) ............................................................. 42 
Ilustración 23: Correlación Mejorada del Coste Incurrido/Coste Planificado vs Esfuerzo en IS 
(Honour, 2010) ........................................................................................................... 42 
 
 
Índice de Tablas 
 
Tabla 1: Matriz de Trazabilidad - Ejemplo “avión de pasajeros” ........................................... 13 
Tabla 2: Información relevante de cada estudio analizado .................................................. 21 
Tabla 3: Grados de IS del estudio de Boeing (adaptación de Frantz, 1995) ........................... 22 
Tabla 4: Actividades de IS analizadas en estudio 6 (adaptación de Honour, 2010) ................ 23 
Tabla 5: Indicadores investigados por cada estudio analizado ............................................. 24 
Tabla 6: Inversión óptima en IS del estudio 6 (adaptación de Honour, 2010) ........................ 28 
Tabla 7: Datos de tiempos del estudio de Boeing (adaptación de Frantz, 1995) .................... 29 
Tabla 8: Datos de calidad del Estudio de Boeing (adaptación de Frantz, 1995) ..................... 32 
 
 
 
 
TRABAJO FIN DE MÁSTER 
 
 
 
 1 
1 INTRODUCCIÓN 
El objetivo de este Trabajo Fin de Máster es reflejar las ventajas de la metodología de 
Ingeniería de Sistemas (en adelante IS1) en la gestión de proyectos de gran envergadura. Para 
ello se ha realizado una revisión de la literatura sobre la aplicación de IS en proyectos reales, 
recopilando información de distintas fuentes y extrayendo posteriormente conclusiones de los 
resultados obtenidos al aplicar dicho método en organizaciones conocidas y pertenecientes a 
distintos sectores o unidades de negocio. 
El documento se compone de cuatro capítulos: 
En este primer capítulo se realiza una introducción a la IS, empezando por una breve 
reseña histórica. A continuación se explica el concepto de Sistema utilizado a lo largo de todo 
el documento, seguido de algunas definiciones de la metodología provenientes de distintas 
fuentes. 
El segundo capítulo describe la metodología de IS a través del Ciclo de Vida del Sistema, 
que como se verá más adelante, se divide en dos fases. La primera es la fase de adquisición, 
compuesta por las etapas de diseño conceptual, diseño preliminar, diseño de detalle y 
desarrollo y la etapa producción. La segunda fase es la de utilización del sistema, coincidente 
con la etapa de uso operacional y mantenimiento del mismo. 
El tercer capítulo incluye el análisis de ocho estudios llevados a cabo por diferentes 
entidades/autores para determinar el impacto de la aplicación de IS en diferentes programas. 
El análisis se realiza a través de lo que se considera como los 4 indicadores principales de los 
resultados de un proyecto: coste, tiempo, calidad y éxito. 
Finalmente, el último capítulo recoge las conclusiones derivadas de todo lo expuesto 
anteriormente. 
1.1 Historia de la Ingeniería de Sistemas 
La IS es una metodología que data de mediados delsiglo XX. Hay diversidad de opiniones 
respecto sus orígenes, aunque todas están de acuerdo en que surge en respuesta a la 
necesidad de gestionar de forma eficiente proyectos complejos de ingeniería (Faulconbridge & 
Ryan, 2005), identificando las propiedades del Sistema como un todo, es decir, teniendo en 
cuenta el ciclo de vida del proyecto al completo, al comprender que las decisiones tomadas al 
comienzo del mismo tienen grandes consecuencias posteriormente. 
Esta metodología puede ser rastreada hasta principios de los años 40, en los Laboratorios 
Bell (Valerdi & Davidz, 2007, y Von Bertalanffy, 1976). La primera referencia que describe 
ampliamente el procedimiento de IS fue publicada en 1950 por Melvin J. Kelly, entonces 
director de los laboratorios de la compañía Bell Telephone, subsidiaria de investigación y 
TRABAJO FIN DE MÁSTER 
 
 
 
 2 
desarrollo de la American Telephone & Telegraph en aquel entonces, debido a la acuciante 
complejidad que planteaba el desarrollo de redes telefónicas, entre otras cosas. 
Así, en 1943 se fusionaron sus departamentos de Ingeniería de Conmutación e Ingeniería 
de Transmisión bajo la denominación de Ingeniería de Sistemas. A juicio de Arthur D. Hall, 
pionero en el campo de la IS e ingeniero eléctrico de Laboratorios Bell (y que luego se 
estableció por su cuenta), la función de IS se había practicado durante muchos años, pero su 
reconocimiento como entidad organizativa generó mayor interés y recursos en la organización. 
En 1950 se creaba un primer curso de postgrado sobre el tema en el Instituto Tecnológico de 
Massachusetts y, posteriormente, sería el propio Hall el primer autor de un tratado completo 
sobre el tema (Hall, 1962). 
Más adelante, en los años 50, la IS comenzó a emerger gracias a la experiencia ganada en 
los programas de adquisición del Departamento de Defensa de EEUU (aviones, carros de 
combate, buques y misiles), sobre todo como consecuencia directa de la Segunda Guerra 
Mundial. Estos programas a menudo implican requisitos de usuario complejos que tienden a 
ser incompletos y definidos pobremente, en los que el riesgo técnico es alto al involucrar un 
gran número de disciplinas diferentes y el uso de tecnología emergente (Faulconbridge & 
Ryan, 2005). 
Mediante esta metodología fueron llevados a cabo algunos de los más famosos proyectos 
aeroespaciales de la NASA, como el Programa Apolo (1961-1972) para llevar al hombre a la 
Luna o el Programa Pioneer (1958-1978), de exploración planetaria mediante sondas no 
tripuladas. La corporación americana TRW, cuyos negocios se centran en gran medida en el 
sector aeroespacial y responsable de la construcción de las sondas del Programa Pioneer, 
también se atribuye a sí misma el merito de ser pionera en los métodos de IS, en base a su 
trabajo en el desarrollo misiles balísticos intercontinentales (Halverson, 2011) a finales de los 
años 50. 
En general, la IS ha ido evolucionando a lo largo de la segunda mitad del siglo XX y hasta 
nuestros días, pero que no fue definida formalmente como un campo hasta los años 90, 
cuando se fundó el National Council On Systems Engineering (Valerdi & Davidz, 2007), 
sociedad formada por representantes de corporaciones y organizaciones de EEUU con el 
objetivo de tratar la necesidad de mejoras en las prácticas profesionales de IS y en la 
educación. Como resultado de la implicación de ingenieros de sistemas de cualquier parte del 
mundo, el nombre de la organización se cambió a International Council On Systems 
Engineering, INCOSE2, en 1995. 
1.2 ¿Qué es un Sistema? 
Un Sistema es un conjunto complejo de partes sujetas a un plan o propósito común. En el 
sentido más amplio de la palabra, es algo que proporciona una solución a un problema 
TRABAJO FIN DE MÁSTER 
 
 
 
 3 
complejo (Faulconbridge & Ryan, 2005). Por ejemplo, el desarrollo y fabricación de un nuevo 
modelo de avión, de un carro de combate o la construcción de una central nuclear. 
Existen dos formas de describir un Sistema: 
 En términos funcionales, refiriéndonos al problema que resuelve: 
o ¿Qué tiene que hacer? (funcionalidad) 
o ¿Cómo de bien tiene que hacerlo? (rendimiento) 
o ¿Bajo qué condiciones tiene que operar? (entorno) 
o ¿Sistemas externos implicados en su operación? (interfaces) 
Esto es el Dominio Problema y está a cargo del cliente, es decir, de la entidad que ha 
detectado la insuficiencia que necesita gestionar. 
 En términos físicos, refiriéndonos a cómo se ha diseñado: 
o ¿Cómo se desglosa? (subsistemas y componentes) 
o ¿Cómo vamos a dimensionarlo? (diseño) 
o ¿Cómo vamos a fabricarlo? (procesos de fabricación) 
o ¿Cómo vamos a integrarlo? (ensamblaje y pruebas) 
Esto es el Dominio Solución, a cargo del contratista principal, es decir, de la entidad 
que diseña, fabrica e integra los sistemas capaces de cumplir los requisitos del 
dominio problema. 
Ambos dominios dependen uno del otro, de la misma forma que existe trazabilidad entre 
un problema y su solución. La relación entre cliente y contratista principal es el contrato. 
Un Sistema debe cumplir con las metas y objetivos del cliente, que deben estar claramente 
establecidos por el mismo en dicho contrato a través de la definición de unos requisitos. La 
detección de la necesidad o carencia representa el punto de partida de su Ciclo de Vida. Este 
concepto se explicará en detalle en el capítulo 2. 
1.3 Algunas Definiciones de Ingeniería de Sistemas 
El debate acerca como definir la IS tiene varias décadas y el número de definiciones ha 
aumentado significativamente a lo largo de esta última. Definiciones clásicas surgieron durante 
los años 60 y 70, todas bastante parecidas en naturaleza, pero con variaciones en relación a 
como la referencian, denominándola en ocasiones como una práctica y otras como un 
proceso, un método o un enfoque (Rhodes & Hastings, March 2004). 
Así, en la literatura podemos encontrar tantas definiciones distintas como autores han 
estudiado este tema. En cierta forma, cada una ha sido enfocada de forma particular al 
objetivo de su autor. 
TRABAJO FIN DE MÁSTER 
 
 
 
 4 
Según la norma militar estadounidense MIL-STD-499B3 (Department of Defense, 1993) la 
IS se define como: 
“Un enfoque interdisciplinar que abarca todo el esfuerzo técnico para desarrollar y 
verificar una serie de soluciones equilibradas del sistema a nivel producto y proceso, de forma 
integrada a lo largo de su ciclo de vida, de forma que se satisfagan las necesidades del cliente. 
La Ingeniería de Sistemas abarca: 
 Desarrollo, fabricación, verificación, despliegue, operaciones, soporte, desactivación y 
formación del usuario en los productos y procesos del sistema. 
 Gestión de la configuración del Sistema. 
 Traslado de la definición del sistema en estructuras desglosadas de trabajo. 
 Desarrollo de la información para la toma de decisiones de gestión. “ 
Por otro lado, el INCOSE la define como: 
“Un enfoque interdisciplinar cuyo objetivo es posibilitar la realización de Sistemas con 
éxito. Se centra en definir las necesidades del cliente y la funcionalidad requerida de forma 
temprana en el ciclo de desarrollo del proyecto, documentando los requisitos, sintetizando el 
diseño y validando el sistema, mientras se considera el problema al completo. 
La Ingeniería de Sistemas integra todas las disciplinas y especialidades en un esfuerzo de 
equipo, formando un proceso de desarrollo estructurado para llevar a cabo el proyecto desde 
su concepción hasta su producción y puesta en servicio. La Ingeniería de Sistemas considera las 
necesidades del negocio como las necesidades técnicas de los clientes, con el objetivo de 
proveer un producto de calidad que cumpla con necesidades del usuario”. 
La definición de Kossiakof & Sweet (Systems Engineering Principles and Practices, 2003) 
dice que: 
“La función de la Ingeniería de Sistemas es guiar la ingeniería de sistemas complejos.La 
Ingeniería de Sistemas está enfocada en el sistema como un todo y hace énfasis en la 
operación total. Mira al Sistema desde fuera, es decir, a su interacción con otros sistemas y a su 
entorno, así como desde dentro.” 
Podríamos seguir añadiendo decenas de definiciones procedentes de fuentes distintas, 
teniendo todas ellas en común la palabra Sistema y el objetivo de la IS de dirigir el esfuerzo de 
desarrollo del mismo a lo largo de todo su ciclo de vida. 
 
TRABAJO FIN DE MÁSTER 
 
 
 
 5 
2 METODOLOGÍA DE INGENIERÍA DE SISTEMAS 
La IS se centra en el Ciclo de Vida del sistema al completo, y lo tiene en consideración a lo 
largo de todos los procesos de toma las decisiones. El Ciclo de Vida comienza con la detección 
de la necesidad de un sistema por parte del usuario y termina con la retirada de servicio del 
mismo, aunque no hay un acuerdo universalmente aceptado acerca de cuantas fases y etapas 
tiene. 
Existen muchos modelos de ciclo de vida. En este documento se presenta el de la MIL-
STD-499B (Department of Defense, 1993) y Blanchard & Fabricky (Systems Engineering and 
Analysis, 1998), representado en la Ilustración 1, seleccionado por su sencillez y por la clara 
delimitación entre las 2 grandes fases en que divide el ciclo: 
 Fase de Adquisición: Comienza con el establecimiento de la necesidad por parte de 
un grupo de usuarios y termina con la construcción o producción del sistema. Esta 
fase se compone de 4 etapas principalmente: 
o Diseño Conceptual 
o Diseño Preliminar 
o Diseño de Detalle y Desarrollo 
o Construcción y/o Producción 
 Fase de Utilización: Comienza con la puesta en servicio del sistema y concluye con la 
retirada del mismo. Coincide con la etapa de uso operacional del sistema y el 
soporte/mantenimiento del mismo. 
 
Ilustración 1: Esquema del Ciclo de Vida de un Sistema 
La línea entre la fase de adquisición y la fase de uso es clara y nos permite analizar la 
aplicación de IS en ambas fases por separado a través de un proceso cíclico de Análisis, 
Síntesis y Evaluación como el de la Ilustración 2, recurrente en todas sus etapas. Como parte 
de la función de evaluación, debe realizarse una revisión de cada una de ellas tras su 
finalización. 
TRABAJO FIN DE MÁSTER 
 
 
 
 6 
 
Ilustración 2: Proceso de Análisis, Síntesis y Evaluación. 
A lo largo de ambas fases, se llevan a cabo actividades de Test y Evaluación (T&E4) que 
involucran tanto al cliente como al contratista (principal y secundarios), de manera que el 
sistema es chequeado de forma continua a lo largo de todo su ciclo de vida, lo que asegura 
progresivamente que este es desarrollado conforme a los requisitos de cliente. Las fases de 
adquisición y de uso, todas sus etapas y las actividades de T&E serán explicadas en detalle en 
las secciones 2.1, 2.2 y 2.3 (Faulconbridge & Ryan, 2005). Para mayor claridad, en la Ilustración 
3 se muestra un esquema del proceso. 
Obviamente no existe una única solución válida para todos los proyectos, por lo que la 
aplicación de esta metodología a distintos sistemas puede requerir de cierto grado de 
personalización del procedimiento para adaptarlo a las características individuales de cada 
caso. 
En las primeras etapas de un proyecto es dónde la IS tiene mayor potencial, ya que 
aproximadamente el 75% del coste del proyecto queda determinado en las etapas iniciales de 
diseño del ciclo de vida, lo que se pone de manifiesto en la Ilustración 4. Cuanto más se tarde 
en descubrir y corregir los problemas mayor será el impacto negativo en el proyecto, por ello 
el mayor esfuerzo o inversión de análisis debe realizarse en estas primeras etapas. 
La implementación exitosa de los procedimientos y métodos de IS en un proyecto tiene 
múltiples beneficios a lo largo del Ciclo de Vida de un sistema, entre los que podemos destacar 
los siguientes: 
 Ahorro económico durante toda la vida del sistema. 
Aunque implementar la IS supone un coste adicional en el proyecto, sobre todo en las 
actividades tempranas del diseño y desarrollo, si el procedimiento es aplicado 
correctamente el ahorro resultante a lo largo de todo el Ciclo de Vida compensa 
sobradamente esta inversión inicial en recursos e infraestructura. 
 Reducción del calendario global hasta la puesta en servicio del sistema. 
La IS se encarga de que los requisitos de usuario se reflejen fielmente en el diseño del 
sistema, minimizando el coste, en dinero y en retraso del proyecto, de cambios en los 
requisitos en etapas posteriores del ciclo de vida. Si fuera necesario hacer cambios en el 
diseño estos se detectarían en etapas tempranas. Debido a su riguroso procedimiento, la 
IS permite alcanzar un nivel de madurez del diseño elevado mucho antes. 
SÍNTESIS
ANÁLISIS
EVALUACIÓN
TRABAJO FIN DE MÁSTER 
 
 
 
 7 
 Reducción significativa de los riesgos técnicos asociados al desarrollo del producto. 
Los riesgos técnicos son identificados al principio y monitorizados a lo largo del proceso 
usando un sistema de medida de rendimiento, revisiones de diseño y auditorías. 
La IS posibilita que todos y cada uno de los requisitos puedan ser trazados en todo 
momento aguas abajo hasta el diseño, y viceversa, garantizándose de esta forma que cualquier 
cambio en los mismos (o en su interpretación) es repercutida en las correspondientes 
modificaciones del producto, así como que cualquier modificación del diseño no se traducirá 
en incompatibilidades con los requisitos. 
 
 
Ilustración 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema 
Diseño
conceptual
Identificación 
de requisitos
Análisis de 
viabilidad
Análisis de 
requisitos del 
sistema
Síntesis a 
nivel de 
sistema
Revisión del 
diseño del 
sistema
Diseño
preliminar
Análisis de 
requisitos de 
subsistemas
Distribución 
de los 
requisitos
Identificación
/ diseño de 
interfaces
Síntesis a 
nivel de 
subsistema
Revisiones del 
diseño 
preliminar
Diseño de 
detalle y 
desarrollo
Diseño de detalle
de subsistemas y 
componentes
Integración de 
subsistemas y 
componentes
Desarrollo de 
prototipos
Revisiones del 
diseño de detalle
Construcción/ Producción
FASE DE ADQUISICIÓN
Linea Base Funcional
Linea Base Distribuida
Linea Base de Producto
T
&
E
FASE DE USO
Utilización del sistema
Posibles modificaciones
Mantenimiento del sistema
TRABAJO FIN DE MÁSTER 
 
 
 
 8 
 
Ilustración 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012) 
2.1 Fase de Adquisición 
La fase de adquisición comprende 4 etapas principales: Diseño Conceptual, Diseño 
Preliminar, Diseño de Detalle y Desarrollo y finalmente la Construcción y/o Producción de 
sistema. 
2.1.1 Diseño Conceptual 
El Diseño Conceptual es un esfuerzo inicial de la IS centrado en conseguir un paquete de 
requisitos de usuario claramente definidos a nivel de sistema. En la práctica la definición de los 
requisitos funcionales del sistema suele ser pobre e incompleta, ya que los clientes a menudo 
describen sus necesidades de forma ambigua para protegerse de cambios y necesidades que 
les puedan ir surgiendo durante el desarrollo del proyecto. El Diseño Conceptual tiene como 
objetivo evitar esta ambigüedad y establece una Línea Base Funcional. El proceso sería el 
siguiente: 
 Identificación de requisitos: 
Se trata de tener una idea completamente clara de lo que se pretende conseguir con el 
sistema antes de desarrollarlo. El resultado será un Documento de Requisitos de Sistema, 
documento de trabajo que permitirá al ingeniero de sistemas desarrollar la Especificación 
de Sistema. 
El ingeniero de sistemas debe asegurar la trazabilidad de cada requisito hasta la 
Especificación, asegurándose así que todos y cada uno de ellos hayan sido contemplados. 
También debe asegurarse la trazabilidad en sentido contrario, es decir, que cada decisión 
de diseño indicada en la Especificación corresponde al menos con un requisito, 
TRABAJO FINDE MÁSTER 
 
 
 
 9 
asegurándose así que en la especificación no haya nada que no haya sido formalmente 
solicitado por el cliente. 
El Documento de Requisitos de Sistema es el primer documento crítico del proceso de IS 
que captura las necesidades del cliente/usuario, dejando completamente definida la 
aplicación o misión del sistema. El primer paso para elaborar el documento es la 
identificación de los recursos humanos involucrados en el proyecto, desde los usuarios 
eventuales, operadores y personal de mantenimiento hasta los ingenieros de sistemas y 
diseñadores, así como el personal de pruebas. En paralelo también deben identifican las 
restricciones del proyecto y de la empresa, así como las restricciones o limitaciones 
externas. A continuación es necesario definir las necesidades a cubrir, metas y objetivos a 
satisfacer, los escenarios operacionales (casos de usos o modos de operación) y las 
medidas de efectividad o métricas que valoran el grado de satisfacción del cliente con el 
producto. El siguiente paso consiste en definir os límites del sistema, definiendo las 
restricciones de diseño (por ejemplo el uso de ciertas tecnologías o herramientas), los 
interfaces existentes (presentes y futuros) y el alcance del suministro. Esta última parte es 
especialmente importante para los jefes de proyectos, que deben conocer de antemano 
qué debe incluir el sistema a diseñar y qué queda excluido del mismo. Finalmente, se 
confirma la estructura del documento seleccionada, teniendo en cuenta las referencias 
que proporcionan una guía en este aspecto (ANSI5 & AIAA6, 1992), y el documento se 
distribuye y aprueba por todas las partes interesadas. 
 Análisis de viabilidad: 
Cuando los requisitos han sido identificados y articulados de forma satisfactoria, deben 
determinarse las alternativas para cumplir con las necesidades que estos representan. 
Dichas alternativas deben ser consideradas en términos de recursos disponibles como 
dinero, tiempo, personal y materiales. En la elaboración del Documento de Requisitos de 
Sistema ya debió ser incluido parte de este estudio de alternativas, al realizar la 
identificación de las restricciones del proyecto y de la empresa. Un correcto análisis de 
viabilidad implica la identificación de alternativas o soluciones a nivel de sistema, 
confirmando para cada una de ellas qué requisitos se cumplen y cuáles no se cumplen. 
Además, es necesario evaluar el potencial de cada alternativa en términos de viabilidad, 
rendimiento, efectividad, riesgo técnico y del proyecto y otras medidas del rendimiento, 
recomendando la mejor de las posibles soluciones. 
 Análisis de requisitos del sistema: 
Este análisis comienza estableciendo un marco para los requisitos ó Estructura de 
Desglose de Requisitos, sobre la que se agrupan los distintos requisitos funcionales, como 
por ejemplo: Requisitos Medioambientales, Físicos, de Funcionamiento, de Interfaces, de 
Calidad y de Mantenimiento (entre otros). Estos requisitos son llamados requisitos 
funcionales, ya que definen las distintas funciones que el sistema necesita desarrollar. Por 
ejemplo, los requisitos de Entorno pueden ser la presión, temperatura, humedad, etc; los 
TRABAJO FIN DE MÁSTER 
 
 
 
 10 
requisitos Físicos el tamaño, volumen, masa, forma, materiales, etc.; los requisitos de 
Funcionamiento las funciones, modos de operación, características hardware y software, 
etc. 
Una vez que las funciones han sido identificadas, es necesario definir los requisitos de 
prestaciones del sistema o parámetros de comportamiento de cada uno de los distintos 
requisitos funcionales. Es decir, una vez que se ha determinado qué debe hacer el 
sistema, ahora debe definirse cómo de bien debe hacerlo. Por ejemplo, para la 
temperatura definir el rango tolerado, para la masa el peso máximo, y para las funciones 
las horas de operación cada día y los días de operación cada año. 
A continuación, la definición de requisitos funcionales y de prestaciones se completa con 
la definición de los requisitos de verificación, que determinan cómo se va a testear el 
sistema. Es decir, una vez que se ha determinado qué debe hacer el sistema y cómo debe 
hacerlo, ahora debe definirse cómo va comprobarse. En ocasiones el cliente impone sus 
propios métodos de comprobación en el contrato. 
Los requisitos establecidos por el cliente suelen ser de alto nivel, es decir, se centran en 
las necesidades a nivel de sistema y suelen ser más cualitativos que cuantitativos. Es por 
esto que es necesario identificar también, mediante un análisis funcional, los llamados 
requisitos derivados, es decir, los requisitos que no son establecidos directamente por el 
cliente sino que son el resultado de que estos fluyan desde los niveles superiores aguas 
abajo. Un ejemplo sencillo de esto sería un requisito en el que nos indicasen que el 
sistema “avión de pasajeros”, que tenemos que diseñar y construir, debe proporcionar 
confort de primera clase. Los requisitos derivados serían, entre otros, establecer el 
espacio mínimo para poder estirar las piernas, las dimensiones de los asientos, los 
sistemas de entretenimiento a bordo, los baños disponibles y el servicio de catering. Para 
cada uno de los requisitos comentados anteriormente, es preciso detallar por qué son 
necesarios y en qué nos basamos para ello, de forma que se deje registro del histórico del 
fundamento de nuestras decisiones. 
La validación de requisitos del Diseño Conceptual no se realiza de golpe sino de forma 
progresiva por lotes, clasificándolos conforme a un nivel de prioridad (requisitos 
mandatorios, importantes y deseables) y definiendo las Medidas de las Prestaciones 
Técnicas (Technical Performance Measures, TPM7), es decir, el margen dentro del cual su 
valor puede ser considerado como aceptable. Este concepto no es nuevo y se asemeja a 
las técnicas de gestión de proyectos para el seguimiento de costes y de la planificación 
(IEEE.Std1220, 2005). 
Una vez identificados, validados y clasificados todos los requisitos se desarrolla el 
borrador de la Especificación Funcional del Sistema (que constituirá la Línea Base 
Funcional). 
Otro documento resultante de esta etapa es la Declaración de los Trabajos, documento 
contractual que limita el alcance de los trabajos a realizar de forma conjunta con el 
TRABAJO FIN DE MÁSTER 
 
 
 
 11 
Documento de Requisitos de Sistema y que establece las consideraciones adicionales que 
no están recogidas en la Estructura de Desglose de Requisitos (marco de la futura 
Especificación de Sistema). Es decir, no sólo indica los elementos o subsistemas físicos 
necesarios para producir el Sistema, sino el resto de consideraciones y actividades del 
proceso de IS en relación a la gestión del esfuerzo del diseño y desarrollo del Sistema, 
como los entregables de documentación (asociados habitualmente con hitos de pago), las 
revisiones técnicas y auditorías a llevar a cabo, la gestión de la configuración y las 
actividades de T&E, entre otras cosas. También debe incluir la definición del soporte 
logístico a proporcionar (mantenimientos, repuestos, etc.) y las responsabilidades 
organizativas de todos los implicados (contratista y cliente) a través de todas las etapas 
del Ciclo de Vida del Sistema. La elaboración de este documento es parte de la gestión del 
jefe de proyecto. 
 Síntesis a nivel de sistema: 
Se trata de establecer una configuración física inicial representativa de la forma final que 
tomará el sistema. En este punto el diseño aún no es lo suficientemente maduro, 
asumiéndose por tanto que dicha configuración no es la definitiva y que esta sufrirá 
cambios significativos a lo largo del resto del diseño. El primer paso es identificar 
soluciones potenciales para la arquitectura del sistema y recopilar información de cada 
una de las mismas, en términos de procesos, costes a lo largo de todo el ciclo de vida, 
aseguramientode la calidad, pruebas, mantenimiento, soporte logístico integrado, etc., 
de manera que sea posible evaluarlas e identificar las discrepancias. Tras dicha 
evaluación, se seleccionará la solución preferida, actualizándose el borrador que 
teníamos de la Especificación de Sistema. Este documento es quizá el más importante de 
todos los de IS, ya que es la referencia para todas las demás especificaciones 
subordinadas producidas posteriormente. 
 Revisión de diseño del sistema: 
Esta revisión consiste en chequear el Diseño Conceptual con respecto a los requisitos de 
la Especificación de Sistema. Antes de llevarla a cabo, es necesario prepararla 
convenientemente, confirmando los criterios de entrada/salida, preparando la 
documentación a revisar y estableciendo una agenda. El resultado de dicha revisión debe 
ser la confirmación de la solución a nivel de sistema, mediante la Evaluación de la 
propuesta de diseño a nivel de sistema, la aprobación de la Especificación de Sistema, y el 
establecimiento de la Línea Base Funcional inicial, a partir de la cual se desarrollará el 
resto del diseño. 
Al finalizar deben acordarse acciones respecto a temas que puedan quedar pendientes 
durante la revisión. Dichas acciones se llevarán a cabo en paralelo al Diseño Preliminar y 
su ejecución será chequeada en revisiones o auditorias posteriores. 
TRABAJO FIN DE MÁSTER 
 
 
 
 12 
2.1.2 Diseño Preliminar 
Tras establecer el Diseño Conceptual, la siguiente etapa del ciclo es el Diseño Preliminar. 
En esta etapa, el equipo de trabajo puede ser distinto del equipo que elaboró el Diseño 
Conceptual, ya que aquí el papel del cliente cambia, evitando involucrarse en las decisiones. La 
responsabilidad del resultado recae, por contrato, en el contratista principal. 
El punto de partida es la Línea Base Funcional, configuración física inicial establecida en el 
Diseño Conceptual. El objetivo es establecer una Línea Base Distribuida, dónde los requisitos 
funcionales a nivel de sistema son agrupados de forma lógica en los distintos subsistemas que 
lo componen. El proceso sería el siguiente: 
 Análisis de requisitos de subsistemas: 
A partir de la Especificación de Sistema y las TPMs obtenidas en el Diseño Conceptual, se 
sigue un proceso parecido al análisis de requisitos de sistema, explicado anteriormente, 
pero ahora a nivel de subsistema, identificando análogamente los requisitos funcionales, 
de prestaciones de verificación y requisitos derivados, dejando registro de la justificación 
de las decisiones. 
 Distribución de los requisitos: 
Es el proceso de agrupar o combinar los requisitos en subdivisiones lógicas que 
representen una arquitectura física preliminar de los subsistemas, basada en la 
configuración física del sistema que ya se estableció en el Diseño Conceptual. 
Para ello primero deben determinarse los subsistemas y/o componentes mayores, a cada 
uno de los que denominaremos Elemento de Configuración o Configuration Item (CI8), el 
cual será gestionado de forma individual en el Diseño Preliminar y seleccionado en base a 
la complejidad, criticidad, riesgo y coste asociados a su diseño, así como al desarrollo y 
suministro y elementos en común con otros subsistemas. 
Continuando con el ejemplo de sistema “avión de pasajeros”, comentado anteriormente, 
una arquitectura física preliminar típica podría estaría desglosada en los siguientes 
subsistemas o CIs: Tren de Aterrizaje, Alas & Fuselaje, Sistema de Combustible, Sistema 
Hidráulico, Mandos de Vuelo, Motor, Aviónica e Interior. 
Una vez definidos los CIs, los requisitos deben ser distribuidos de forma que se relacionen 
los requisitos funcionales con la estructura física de los CIs, habitualmente a través de una 
Matriz de Trazabilidad o de Distribución, en la que la Estructura de Desglose de 
Requisitos se muestra en el lateral izquierdo de la matriz, en vertical, y la estructura de 
Elementos de Configuración se muestra en el extremo superior de la matriz, en 
horizontal. Para el sistema “avión de pasajeros” se incluye un ejemplo de la matriz en la 
Tabla 1. 
TRABAJO FIN DE MÁSTER 
 
 
 
 13 
 
Tabla 1: Matriz de Trazabilidad - Ejemplo “avión de pasajeros” 
A partir de dicha matriz y del documento de Declaración de los Trabajos definido en el 
Diseño Conceptual, se desarrollará la Estructura de Desglose de los Trabajos, en la que se 
incluyen no sólo los paquetes físicos de elementos y subsistemas a suministrar, entre los 
deben que incluirse todos los CIs, sino los paquetes de actividades o trabajos necesarios 
para su desarrollo, producción y test, entre otras cosas. 
Para cada CI debe elaborarse una Especificación Técnica, cuya forma dependerá de la 
alternativa seleccionada para la producción del elemento en cuestión. Para el caso de los 
elementos a producir mediante un desarrollo interno, en esta etapa deben comenzar a 
elaborarse los borradores de las correspondientes Especificaciones de Desarrollo. Por 
otra parte, para los elementos comerciales se elaborarán Especificaciones de Producto. 
 Identificación/diseño de interfaces: 
En la selección y definición de los CIs que componen el sistema deben identificarse los 
interfaces entre ellos (físicos, eléctricos, electrónicos, hidráulicos/neumáticos, software, 
Tren de 
Aterrizaje
Alas & 
Fuselaje
Sistema de 
Combustible
Sistema 
Hidráulico
Mandos 
de Vuelo Motor Aviónica Interior
Funcional
Largo de la pista X X X
Asientos X
Entretenimiento a bordo X
Instalaciones X
Catering X
Repostaje X
Economía de combustible X X X
Carga/descarga X
Velocidad de crucero X X
Grabación X
Configuración
Equipo de seguridad X
Salidas de emergencia X
Interface
Ayudas a la navegación X
Ayudas despegue/aterrizaje X
Sistemas de comunicaciones X
Físico
Peso del avión X X X X X X X X
Espacio para las piernas X
Dimensiones de asientos X
Espacio equipaje de mano X
Nº de pasajeros X X
Medioambiente
Superficie de la pista X
Calidad
Mantenimiento operacional X X X X X X X X
Personal necesario X X
Restricciones
Nº de motores X X
TRABAJO FIN DE MÁSTER 
 
 
 
 14 
etc.), elaborándose habitualmente un Documento de Control de Interfaces para cada 
uno de ellos. Esta parte del Diseño Preliminar es crítica, ya que no solo garantiza el éxito 
en la integración de los distintos subsistemas sino que, además, impone limitaciones y 
requisitos adicionales en el diseño de cada CI individualmente. 
 Síntesis a nivel de subsistema. 
Para cada subsistema partimos de la revisión de su Especificación Técnica y de su 
Documento de Control de Interfaces para investigar las alternativas disponibles para su 
desarrollo y producción, es decir, para definir si se usarán Commercials-Off-the-Shelf 
(COTS9 o MOTS10, estos últimos específicos para aplicaciones militares), COTS modificados 
o elementos de desarrollo. 
Para la selección de los distintos subsistemas es importante recordar que lo fundamental 
es asegurar unas prestaciones óptimas para el sistema completo frente a las prestaciones 
de cada subsistema o componente individual. Esto conlleva hacer un buen uso del 
espacio de diseño y adoptar soluciones de compromiso. 
 Revisiones del diseño preliminar: 
Para sistemas complejos y/o de gran tamaño, lo habitual es establecer una revisión para 
cada CI. Se trata de una revisión formal cuyo objetivo es asegurar que el Diseño 
Preliminar es adecuado antes de pasar al Diseño de Detalle. Antes de llevarla a cabo, es 
necesario prepararla convenientemente, confirmando los criterios de entrada/salida, 
preparando la documentación a revisar y estableciendo una agenda. Dicha 
documentación consiste en los borradores de las Especificaciones de Desarrollo y en los 
Documentos de Control de Interfaces. 
Durante estas revisiones debe confirmarse la arquitectura de los CIs, así como sus 
Especificaciones de Desarrollo y los Documentos de Control de Interfaces. A continuación 
debe confirmarsela completa trazabilidad entre los requisitos de la Línea Base Funcional 
del Diseño Conceptual y la arquitectura física resultado del Diseño Preliminar y viceversa, 
esto último para asegurar que no hay requisitos innecesarios ocultos entre los necesarios. 
El resultado será el establecimiento de la Línea Base Distribuida, a partir de la cual se 
desarrollará el resto del diseño. Al finalizar la revisión deben acordarse acciones respecto 
a temas que puedan quedar pendientes, como desviaciones respecto a los requisitos que 
deban corregidas y cuya ejecución será chequeada en revisiones o auditorias posteriores. 
2.1.3 Diseño de Detalle y Desarrollo 
El Diseño de Detalle y Desarrollo continúa el esfuerzo de IS desde los resultados de las 
fases anteriores de diseño, es decir, parte de la Línea Base Funcional y la Especificación de 
Sistema del Diseño Conceptual, así como de la Línea Base Distribuida y del conjunto de 
Especificaciones de Desarrollo de los CIs del Diseño Preliminar. 
TRABAJO FIN DE MÁSTER 
 
 
 
 15 
 Diseño de detalle e integración de los elementos del sistema: 
Llegados a este punto ya pueden definirse los requisitos detallados para unidades, 
montajes y componentes, así como los requisitos detallados para sus interfaces, 
imprescindible para una buena integración de todos los componentes entre sí. De esta 
forma, dichos componentes podrán ser comprados (COTS), comprados y modificados 
(COTS modificados) o construidos (desarrollados). Para los elementos comerciales será 
necesario definir las correspondientes Especificaciones de Producto. 
Durante esta etapa deben llevarse a cabo actividades y tests de integración de los 
distintos subsistemas entre sí dentro de las actividades de Test y Evaluación (T&E). Dichas 
actividades serán explicadas con más detalle en la sección 2.3. 
 Desarrollo de prototipos: 
En esta etapa es habitual el desarrollo y producción de prototipos del sistema completo o 
al menos de modelos reducidos para probar funcionalidades concretas. Sobre dichos 
prototipos y modelos también se llevarán a cabo actividades de T&E que verificarán el 
diseño. 
Para asegurar la optimización de dichas actividades, sumamente caras y grandes 
consumidoras de recursos, es habitual que el cliente requiera, de forma contractual, un 
chequeo previo o Revisión de la Preparación para los Tests en la que debe revisarse el 
Plan Maestro de T&E, los resultados formales e informales de las pruebas previas que ya 
hayan sido realizadas, la documentación de soporte (como manuales y especificaciones) y 
el listado exhaustivo de repuestos, equipamiento e instalaciones necesarias, para que 
todo esté preparado y disponible antes de comenzar con las pruebas. 
 Revisiones del diseño de detalle: 
A lo largo del Diseño de Detalle se organizan un gran número de revisiones informales de 
seguimiento de la evolución del diseño. Al terminar este, se lleva a cabo la Revisión Crítica 
de Diseño, es decir, la revisión formal final antes de pasar a la Fase de Producción. Al igual 
que sucedía con la Revisión del Diseño Preliminar, para sistemas complejos y/o de gran 
tamaño, lo habitual es establecer una revisión para cada CI. 
Las Revisiones Críticas de Diseño evalúan el Diseño de Detalle mediante la revisión de las 
Especificaciones de Producto, los Documentos de Control de Interfaces, los planos 
generados y el progreso de las TPMs, en especial de aquellas que se resaltaron en las 
revisiones de Diseño Preliminar como problemas potenciales, así como la rectificación de 
las discrepancias levantadas durante las Revisiones de Diseño Preliminar. 
Para asegurar la preparación para la producción/construcción, también deben revisarse el 
Plan de Producción y del Plan de Aseguramiento de la Calidad. 
Respecto al Plan de Producción deben chequearse como mínimo los recursos necesarios 
(instalaciones, personal, formación requerida), las consideraciones de ingeniería de 
TRABAJO FIN DE MÁSTER 
 
 
 
 16 
producción (planificación, métodos de fabricación y procesos así como utillaje especial), 
los materiales y compras (lead times largos), la gestión (control de procesos, de la 
producción y seguimiento de subcontratistas) y la logística (requisitos especiales de 
empaquetado, almacenamiento y tratamiento). 
Finalmente, debe determinarse la compatibilidad del diseño, referido a la compatibilidad 
de los CIs con otros aspectos del sistema, como por ejemplo las instalaciones. Si la 
Revisión Crítica termina satisfactoriamente, el conjunto de las especificaciones de 
definición de los componentes del sistema establece la Línea Base de Producto, lo que 
supone la congelación del diseño. 
2.1.4 Construcción/Producción 
La construcción o producción del sistema es la etapa final de la Fase de Adquisición, en la 
que el sistema será producido según la Línea Base de Producto obtenida en la etapa de Diseño 
de Detalle y Desarrollo, y dónde de nuevo se llevarán a cabo actividades de T&E para asegurar 
que la configuración final del mismo cumple con el propósito para el que fue concebido. 
Asimismo, durante esta etapa es imprescindible llevar a cabo actividades de gestión de la 
configuración, entre las que se incluyen auditorías de control de configuración, para 
comprobar que efectivamente el sistema se produce acorde a la Línea Base de Producto. 
Algunos proyectos están dirigidos a producir un único sistema, como la construcción de 
un centro comercial o de un buque, mientras que en otras ocasiones, el objetivo es la 
producción de múltiples copias del sistema e incluso la producción a gran escala. En este 
segundo caso, el primer sistema producido lo será como prototipo, soportando la verificación 
del diseño y la validación del usuario. Lógicamente, el proceso de producción de los sistemas 
en los que sólo va a producirse una unidad difiere totalmente de los sistemas de producción 
múltiple. 
Los requisitos de producción deben ser considerados en etapas tempranas de la Fase de 
Adquisición para asegurar que los riesgos relacionados son identificados y dirigidos lo antes 
posible. Para ello, los ingenieros de producción deben trabajar en equipo con los ingenieros de 
diseño desde las primeras actividades para asegurar que el diseño es fabricable, de manera 
que todos los aspectos relacionados con la fabricación sean tenidos en cuenta en el diseño y 
monitorizados a lo largo del mismo. De hecho, como ya se comentó anteriormente, el Plan de 
Producción debe ser elaborado antes de llegar a la etapa de producción, durante el Diseño de 
Detalle y Desarrollo, y aprobado en la Revisión Crítica de Diseño. 
Sin embargo, aún siguiendo escrupulosamente el procedimiento durante el diseño, es 
muy probable que durante la etapa de producción se haga evidente, incluso antes de terminar, 
que el sistema no va a cumplir con todos los requisitos especificados en las Líneas Base. Para 
cubrir esta posibilidad, desde la gestión de la configuración se debe considerar un sistema de 
gestión de modificaciones, desviaciones y concesiones, que contemple tanto cambios de 
TRABAJO FIN DE MÁSTER 
 
 
 
 17 
diseño como cambios en los requisitos. Habitualmente, estas modificaciones deben ser 
aprobadas por el cliente. 
2.2 Fase de Uso 
Una vez que el sistema ha pasado todos los tests y auditorías de validación está listo para 
su entrada en servicio, es decir, para su fase de uso. Las actividades mayores que se realizar 
durante esta fase la utilización operativa del sistema, posibles modificaciones y 
mantenimiento. 
 Las actividades de IS continúan aquí, dando soporte a las posibles modificaciones del 
sistema para rectificar los déficits de funcionamiento y/o rendimiento que pueda presentar, 
normalmente debido a: 
 Defectos detectados a posteriori de la entrega del sistema al cliente. 
Los fallos de funcionamiento no detectados en la fase de adquisición son detectados a 
posteriori, cuando el sistema se sitúaen su verdadero entorno operacional y se prueba su 
propósito. Para la detección, análisis y establecimiento de acciones correctivas se usa el 
sistema FRACAS11 (Failure Reporting Analysis and Corrective Action System), cuyo 
procedimiento, según la (MIL-STD-2155, 1985), consiste en un ciclo continuo como el 
representado en la Ilustración 5. 
 
Ilustración 5: Esquema de un Sistema FRACAS 
DETECCIÓN DEL 
FALLO O INCIDENCIA
PROPUESTAS DE ACCIONES 
(SOBRE EL PRODUCTO, 
PROCESO, ETC.)
ANALISIS DE CAUSAS 
DEL PROBLEMA
IMPLEMENTACIÓN DE 
LAS ACCIONES
CIERRE DE LA 
INCIDENCIA
BD FRACAS
ACCESO 
USUARIOS
TESTEO Y OPERACIÓN 
DEL SISTEMA
RECOLECCION 
DE DATOS
SOLUCION OPTIMA? 
EVALUACIÓN DE LAS 
PROPUESTAS
SI
NO
APERTURA EN EL 
SISTEMA
TRABAJO FIN DE MÁSTER 
 
 
 
 18 
La diferencia fundamental entre un sistema de mantenimiento y el sistema FRACAS es 
que el primero rectifica el fallo y el segundo rectifica la causa del fallo. 
 Cambios en los requisitos operativos del sistema, normalmente los cambios en los 
requisitos se deben a cambios en el entorno de trabajo del sistema (limitaciones 
externas). 
 Cambios necesarios para facilitar y/o mejorar el mantenimiento del sistema. 
 Modificaciones enfocadas a aumentar las prestaciones y/o fiabilidad del sistema, 
normalmente debidos a la obsolescencia de la tecnología utilizada o el efecto último 
modelo. 
La gestión de la configuración debe seguir aplicándose cuando existen modificaciones, de 
forma que se asegure en todo momento que el sistema está bien documentado, ya que las 
diferencias entre la configuración física real del sistema y su documentación implican una 
operación y mantenimiento difícil y potencialmente peligroso. 
Esto se pone de manifiesto claramente en sistemas repetitivos debido a la producción en 
serie de una flota (aviones, barcos, tanques, etc.), donde las diferencias entre los distintos 
sistemas suelen ser pequeñas y asociadas a unas efectividades. En este tipo de sistemas las 
modificaciones no gestionadas/documentadas impactan muy negativamente en su operación, 
mantenimiento y seguridad. 
Al finalizar la Fase de Uso del sistema este es retirado de servicio, lo que completaría su 
ciclo de vida. Durante el diseño también es necesario tener en cuenta esta última actividad, ya 
que hay que tener ciertas consideraciones en lo que concierne a la retirada de ciertos 
materiales, ya que habitualmente esta pueda ser cara y/o difícil, como por ejemplo en los 
casos de material radiactivo, criptográfico o material de construcción, como por ejemplo 
asbestos. 
A menudo el fin del ciclo de vida de un sistema marca el comienzo del ciclo de vida de 
otro sistema al establecerse una nueva necesidad. 
2.3 Actividades de Test en el Ciclo de Vida 
La función de T&E es llevada a cabo a lo largo de todo el ciclo de vida del sistema e 
involucra tanto al cliente como al contratista. La idea es testear y evaluar el sistema de forma 
progresiva a lo largo de las fases de adquisición y uso, para evitar modificaciones de diseño 
costosas en tiempo y dinero si estas deben ser implementadas al final del ciclo, de manera que 
pueden ser consideradas como una medida de mitigación de riesgos. 
El objetivo del proceso completo de IS es producir un sistema que pueda ser verificado 
contra la documentación producida durante el diseño del sistema y validado contra las 
necesidades, metas y objetivos que iniciaron el desarrollo del sistema en primer lugar. Estos 
dos conceptos a menudo son combinados en lo que se denomina Verificación y Validación, lo 
TRABAJO FIN DE MÁSTER 
 
 
 
 19 
que asegura no sólo que hemos construido un sistema correctamente sino que hemos 
construido el sistema correcto. 
Hay 3 categorías principales en las actividades de T&E: 
 T&E de Desarrollo, actividades llevadas a cabo durante la Fase de Adquisición. 
 T&E de Aceptación, actividades llevadas a cabo para la aceptación formal del sistema 
por parte del cliente. Es el límite entre la Fase de Adquisición y la Fase de Uso. 
 T&E Operacional, actividades llevadas a cabo durante la Fase de Uso tras la 
aceptación formal del sistema por el cliente. Realizada por el personal de operación y 
bajo condiciones realistas. 
El Plan Maestro de T&E es un documento requerido por contrato, preparado por el 
contratista y aprobado por el cliente. Dicho plan debe describir el sistema e incluir un 
programa detallado para las distintas actividades de T&E a desarrollar en cada etapa del 
proyecto, dónde se especifiquen las responsabilidades de cada parte de la organización 
involucrada en las mismas, así como los recursos necesarios para llevarlas a cabo (personal, 
equipamiento, materiales, repuestos, simuladores, modelos, etc.) y la planificación de estos en 
el tiempo. El resto de documentos relevantes para el plan de T&E deben ser incluidos al menos 
como apéndices, como por ejemplo los procedimientos a utilizar. 
 
 
TRABAJO FIN DE MÁSTER 
 
 
 
 20 
3 INVESTIGACIÓN DEL IMPACTO DE LA IS EN LOS PROYECTOS 
En ocasiones es bastante difícil poder demostrar dentro de una organización el beneficio 
o valor añadido que aporta la práctica de la IS de forma que se justifiquen sus costes. En este 
sentido, esta metodología puede considerarse una especie de medicina preventiva, ya que a 
priori es complicado conocer de forma precisa cuantos problemas ha evitado ni hasta qué 
punto ha mejorado los resultados del proyecto. 
En este capítulo se pretende plasmar el impacto de la IS sobre los proyectos mediante la 
medida de distintos indicadores de los resultados de un proyecto: coste, tiempo, calidad del 
sistema resultante y éxito. Para ello, se han analizado 8 estudios llevados a cabo por diferentes 
entidades encontrados tras una revisión de la literatura sobre la aplicación de la IS en 
proyectos reales. 
En la Tabla 2 se resume la información relevante de cada uno de dichos estudios. Son 
diferentes análisis de proyectos realizados por entidades en los que se han tomado datos y 
realizado medidas. Todos ellos son estudios cuantitativos, salvo el estudio 3 en el que se ha 
realizado una encuesta. Para cada uno de ellos se especifica qué parte de la IS se ha aplicado 
en los proyectos analizados. 
El estudio 1, realizado por la NASA a finales de los años 80, se basa en una muestra de 32 
grandes proyectos llevados a cabo entre los años 70 y 80 por dicha organización (Gruhl, 1992). 
A lo largo del mismo se recopilaron datos de costes durante las etapas de definición de cada 
uno de los sistemas, correspondientes al diseño conceptual, diseño preliminar y diseño de 
detalle y desarrollo de la metodología de IS. 
El estudio 2 fue llevado a cabo a principios del siglo XXI por la división de productos 
comerciales de IBM (Barker, 2003), al implementar la metodología de IS en sus desarrollos de 
software comercial. Durante dicha implementación se realizó el seguimiento de la efectividad 
del cambio en una muestra de 8 proyectos, aplicando IS en cinco de ellos a lo largo de la fase 
de adquisición de los sistemas y midiendo costes en todos ellos. 
El estudio 3 es una encuesta de la NASA e INCOSE en el que se pretende analizar el 
beneficio obtenido con la implementación de IS en proyectos complejos (Kludze, 2004) a lo 
largo del ciclo de vida de cada uno según la percepción de empleados de ambas 
organizaciones. Dichos empleados estaban involucrados directamente en la gestión y 
desarrollo de los sistemas resultantes (personal con perfil de jefe de proyecto, ingeniero de 
sistemas o similar), obteniéndose resultados en cuanto a costes, tiempo y calidad de los 
proyectos. 
TRABAJO FIN DE MÁSTER 
 
 
 
 21 
 
Tabla 2: Información relevante de cada estudio analizado 
El estudio 4, realizado en los años 90, fue realizado por la empresa aeronáutica Boeing. 
En él se llevó a cabo un análisis del impacto de la implementación de la metodología de IS en el 
tiempoy la calidad para tres proyectos de sistemas similares que iban a producirse de forma 
simultánea (Frantz, 1995). Los proyectos consistían en el desarrollo y fabricación de sistemas 
de sujeción de grandes partes de aviones durante su proceso de producción, todos ellos de 
coste, características y prestaciones análogas a priori. La única diferencia significativa entre los 
tres proyectos era el grado de implementación de IS a lo largo de la fase de adquisición de los 
proyectos, el cual variaba desde prácticamente nulo en uno de ellos hasta un grado medio y 
alto respectivamente en los otros dos. En estos últimos se aplicó IS a lo largo de toda la fase de 
adquisición de los mismos, es decir, tanto durante las etapas de diseño y desarrollo como 
durante la etapa de fabricación y pruebas. La diferencia entre los distintos grados de 
implementación de IS en cada proyecto del estudio 4 se puede apreciar en la Tabla 3, en la que 
se especifica cómo se llevaron a cabo ciertas actividades concretas del desarrollo de los 
proyectos en las que los procedimientos del diseño tradicional difieren completamente de los 
de IS, como pueden ser, por ejemplo, la gestión de requisitos o el enfoque de las pruebas. 
Ref. Entidad
Fecha/ 
Década 
Tamaño 
Muestra Tipo/s de Proyecto/s
Parte de la IS 
Aplicada
1 Gruhl, 1992 NASA
Finales de 
los años 80
32 proyectos 
estudiados
Grandes proyectos de 
la NASA desarrollados 
entre los años 70 y 80
Etapas de 
definición
2 Barker, 2003 IBM
Principios 
del siglo XXI 
(en torno al 
2000)
8 proyectos 
estudiados
Proyectos de 
desarrollos Software 
de IBM
Fase de 
adquisición
3 Kludze, 2004 NASA/INCOSE
Principios 
del siglo XXI 
(en torno al 
2000)
379 
participantes 
en la encuesta
Todas
4 Frantz, 1995 BOEING Años 90
3 proyectos 
estudiados
Sistemas de sujeción 
de grandes partes de 
aviones durante su 
fabricación
Fase de 
adquisición
5 Honour, 2004 SECOE 2001
44 proyectos 
estudiados
Todas
6
Honour, 2006 
& 2010
Univ. del Sur 
de Australia
2004 a 
Actualidad
48 proyectos 
estudiados 
hasta 2010
Todas
7 Ancona, 1990 MIT
Finales de 
los años 80
45 proyectos 
estudiados
Proyectos de 
desarrollo de 
productos 
tecnológicos
Todas
8 Miller, 2000 MIT
Finales de 
los años 90
60 proyectos 
estudiados
Grandes proyectos 
desarrollados entre 
los años 80 y 90
Todas
TRABAJO FIN DE MÁSTER 
 
 
 
 22 
 
 
Tabla 3: Grados de IS del estudio de Boeing (adaptación de Frantz, 1995) 
El estudio 5, realizado por el SECOE, Centro de Excelencia en IS del INCOSE, comenzó en 
2001, llevando a cabo un proyecto de investigación para intentar cuantificar el beneficio 
aportado por la IS a lo largo del ciclo de vida de un proyecto. Hasta el momento de la 
publicación se analizaron datos de costes, tiempos y éxito de 25 proyectos reales (Honour, 
2004), añadiéndose posteriormente al estudio los resultados de 19 proyectos más. 
El autor del estudio 5 continúa su trabajo justo después de la publicación del mismo 
mediante el estudio 6 (Honour, 2006 & 2010) a través de la Universidad del Sur de Australia, 
investigación que aún sigue abierta y en proceso, ofreciendo a las empresas que quieran 
participar en ella un estándar de comparación para su negocio. En el documento publicado con 
los resultados obtenidos hasta la fecha (Honour, 2010), el autor mantiene la información de los 
44 proyectos del estudio 5 y le añade datos de 48 proyectos más, de forma que el tamaño de 
la muestra va siendo más significativo cada vez, en total 92 proyectos analizados, incluyendo 
además datos del indicador calidad, no analizados en el estudio 5. También incluye la medida 
Grado casi nulo Grado medio Grado alto
Nivel de experiencia en 
gestión de sistemas por IS
Bajo
Gestión de 
subcontratistas
Revisiones periódicas de 
diseño
Acceso y soporte 
disciplinas de gestión de 
sistemas
Bajo acceso
Gran acceso pero poca 
atención
Gran acceso y gran atención
Enfoque de la gestión de 
requisitos
Requisitos simbólicos
Enfoque de diseño
Buenas especificaciones de 
HW y SW
Adherencia a la 
especificación funcional
Se siguen las 
especificaciones a lo largo 
del desarrollo y 
fabricación. Estas son 
actualizadas a medida que 
el diseño madura
Revisiones de diseño
Revisiones semanales por 
equipos
Revisiones formales 
internas. Poca atención a 
los inputs externos
Revisiones formales 
internas. Atención 
moderada a los inputs 
externos
Enfoque para las pruebas 
de integración
Definidas tras el diseño
Enfoque para las pruebas 
de aceptación
Tests definidos en el plan 
general de pruebas
Tests basados en los criterios de aceptación de la 
especificación de requisitos y en la especificación 
funcional
Bajo a Medio
Ingenieros de sistemas full-time en los subcontratistas 
mayores
Requisitos integrados, detallados y completos 
desarrollados por todos los actores implicados. Sesiones 
de trabajo intensivas hasta llegar a un 95% de consenso 
entre todas las partes
Especificaciones funcionales dirigidas vía requisitos. HW 
y SW, procesos e interfaces totalmente incluidos en ellas
No se siguen las especificaciones durante el desarrollo y 
fabricación. Estas son actualizadas por requerimiento 
del diseño
Definidas temprano en el ciclo de vida y dirigidas por la 
especificación funcional
TRABAJO FIN DE MÁSTER 
 
 
 
 23 
de la correlación existente entre los 4 indicadores del proyecto (coste, tiempo, calidad y éxito) 
para las 8 categorías o actividades concretas de IS que se indican en la Tabla 4. 
 
Tabla 4: Actividades de IS analizadas en estudio 6 (adaptación de Honour, 2010) 
El estudio 7, realizado por el Instituto Tecnológico de Massachusetts (MIT12), fue llevado 
a cabo a finales de los años 80 e investiga la gestión del tiempo en proyectos de ingeniería 
(Ancona & Caldwell, 1990). Se recopilaron datos de 45 equipos de desarrollo de productos 
tecnológicos, identificando las múltiples tareas realizadas por sus miembros a lo largo de la 
fase de adquisición de los proyectos y midiendo el tiempo dedicado a cada una de ellas. 
También se midió el éxito de cada proyecto, entendido este como el nivel de calidad y 
comercialización del producto. 
El estudio 8, también llevado a cabo por el MIT a finales de los años 90, investiga la 
gestión estratégica de grandes proyectos de ingeniería (Miller, 2000). El estudio recopila datos 
de una muestra de 60 grandes proyectos de ingeniería de diversas áreas realizados desde los 
años 80 hasta el momento del estudio. Dichos datos relacionaban el tipo de gestión llevada a 
cabo en cada proyecto con el éxito del mismo, entendido este como los resultados obtenidos a 
nivel de coste, tiempo y cumplimiento de los objetivos marcados a su inicio. 
DESCRIPCIÓN
MD
Definición del Propósito 
del Sistema
Identificación y análisis de requisitos de sistema. 
(Actividad típica del diseño conceptual)
RE Ingeniería de Requisitos
Identificación y análisis de requisitos de subsistemas y componentes. 
(Actividad típica del diseño preliminar)
SA Arquitectura del Sistema
Sintetizar el diseño de un sistema a través de la arquitectura de sus 
componentes y su integración. 
(Forma parte del diseño de detalle, desarrollo)
SI
Implementación del 
Sistema
Esfuerzo de soporte a la creación del primer prototipo. 
(Forma parte del diseño de detalle, desarrollo)
VV Verificación y Validación
Verificación del sistema físico contra sus requisitos y validación del 
mismo contra su propósito u objetivo. 
(Actividades de Test)
TA Análisis Técnico
Análisis multidisciplinar depropiedades del sistema en desarrollo, 
orientado a predecir las prestaciones del sistema y dar soporte en la 
toma de decisiones de compromiso. 
(Forma parte del diseño preliminar)
SM Gestión del Alcance
Gestión del alcance del suministro, tanto con los suministradores 
como con los clientes, así como de las relaciones contractuales con 
ambos. 
(Se prolonga a lo largo de todo el ciclo de vida)
TM
Gestión 
Técnica/Dirección
Esfuerzo de guiar y coordinar al personal hacia el éxito del proyecto. 
Abarca tareas de planificación del programa, gestión técnica, gestión 
de equipos, gestión del riesgo y gestión de la configuración (entre 
otras). 
(Se prolonga a lo largo de todo el ciclo de vida)
A
C
TI
V
ID
A
D
 D
E 
IS
TRABAJO FIN DE MÁSTER 
 
 
 
 24 
En la en la Tabla 5 se recogen los indicadores investigados por cada estudio. En las 
secciones a continuación se analizan los resultados obtenidos para dichos indicadores. 
 
 Tabla 5: Indicadores investigados por cada estudio analizado 
3.1 Impacto de la IS en los Costes 
Según se indica en la Tabla 5, en los estudios 1, 2, 3, 5 y 6 se obtuvieron resultados para el 
indicador coste. En el estudio 1, realizado por la NASA (Gruhl, 1992), se compara el sobrecoste 
total del proyecto frente a la inversión durante la definición del sistema (periodo en el que se 
llevan a cabo las etapas de diseño conceptual, diseño preliminar y diseño de detalle y 
desarrollo de IS). En la Ilustración 6 se muestran los datos respecto a este indicador para cada 
uno de los 32 proyectos de dicho estudio, representándose el porcentaje del sobrecoste 
incurrido a lo largo del proyecto (Program Overrun) frente al porcentaje invertido en la 
definición de los sistemas (Definition Percent of Total Estimate), ambos porcentajes calculados 
sobre el presupuesto objetivo total (Target + Definition$). Dicho presupuesto objetivo total se 
divide en una parte fija, consistente en el presupuesto objetivo para todo el proyecto excepto 
las etapas de definición (Target), mas una parte variable consistente en la cantidad invertida 
en la definición (Definition$). 
Como puede observarse en la gráfica, cuanto mayor era el gasto en las etapas de 
definición del proyecto, menor era el sobrecoste incurrido a lo largo del proyecto completo. 
Además, se pueden extraer las siguientes observaciones: 
 En gran parte de los proyectos, el sobrecoste incurrido a lo largo del proyecto era 
mayor del 40% del coste total. 
 En la mayoría de los proyectos, la inversión en la definición del sistema era menor del 
10% del coste total. 
 El mínimo de la curva de aproximación del sobrecoste está en torno al 15% de 
inversión en la definición. 
Sin embargo, el coste de definición de los proyectos no se corresponde exactamente con 
el coste de IS en dicho periodo, aunque sí se puede considerar como una buena aproximación, 
COSTE TIEMPO CALIDAD ÉXITO
1 X
2 X
3 X X X
4 X X
5 X X X
6 X X X X
7 X
8 X
INDICADORES
ES
TU
D
IO
S
TRABAJO FIN DE MÁSTER 
 
 
 
 25 
tal y como se indica en la Ilustración 7, en la que se muestra el esfuerzo de desarrollo 
(Development Effort) a lo largo del tiempo para un proyecto tipo de la NASA, comparándose el 
esfuerzo total a lo largo del mismo (Total Project Effort), con la parte o fracción de dicho 
esfuerzo invertido en la aplicación de IS (Systems Engineering Effort). 
Como puede observarse, gran parte del esfuerzo del proyecto en la definición del sistema 
se corresponde con el esfuerzo de aplicación de IS en dicho periodo, y por lo tanto con la 
inversión en esta. Por lo tanto, podemos extrapolar que el nivel óptimo de inversión en las 
correspondientes etapas de IS (diseño conceptual, diseño preliminar y diseño de detalle y 
desarrollo de IS) que minimiza el sobrecoste podría estar también próximo al 15% del 
presupuesto total o al menos en un entorno cercano a este valor. 
 
Ilustración 6: Sobrecoste vs Inversión en la Definición del Sistema (Gruhl, 1992) 
 
Ilustración 7: Diferencia Esfuerzo de Desarrollo - Esfuerzo en IS (Gruhl, 1992) 
En el estudio 2, de IBM (Barker, 2003), se recurrió a métricas de productividad que 
calculan el coste relativo de los sistemas respecto a su tamaño, dividiendo el coste absoluto de 
cada proyecto entre el número de puntos función del sistema en cuestión (ya utilizadas en IBM 
previamente al estudio), lo que permitía poder comparar entre sí los costes de sistemas 
TRABAJO FIN DE MÁSTER 
 
 
 
 26 
distintos. El método de los puntos función fue definido por Allan Albrecht, de IBM, para valorar 
el tamaño de proyectos de desarrollo de software, midiendo a través de dichos puntos la 
funcionalidad puesta al servicio del usuario del sistema, independientemente de la tecnología 
utilizada para ello (A.J.Albrecht, 1979). Este método representa hoy día una métrica habitual 
en muchas empresas de desarrollo software. Los resultados de este estudio indican que el uso 
de procesos de IS mejoran la productividad de los proyectos en combinación con una 
adecuada gestión de proyectos y procesos de test, ya que las métricas indicaban que el ahorro 
medio en el coste de los proyectos en los que se invirtió en IS fue de un 30% respecto a 
aquellos en los que no se aplicó esta metodología. 
Los resultados en cuanto a coste del estudio 3, encuesta de la NASA y el INCOSE (Kludze, 
2004), se muestran en la Ilustración 8, donde se observa el porcentaje de participantes frente 
al porcentaje del presupuesto total de sus proyectos más recientes invertido en tareas de IS. 
 
Ilustración 8: Presupuesto invertido en IS (Dr. Ave K. Kludze, 2004) 
Como puede observarse, el resultado obtenido a priori es bimodal, aunque 
posteriormente se determinó que los resultados podían haberse visto sesgados por la 
interpretación de “proyectos más recientes” por parte de los participantes, de forma que estos 
incluyeran sólo datos de los proyectos recientes en los que hubieran implementado IS a alto 
nivel, es decir, proyectos en los que la inversión en IS era siempre alta, en lugar de incluir datos 
de todos sus proyectos recientes con implementación de IS tanto a alto como a bajo nivel. 
Conforme a lo anterior, si se eliminan los datos en los que el porcentaje invertido es > 16%, se 
obtiene que para la mayoría de los participantes (74% de la NASA y el 79% del INCOSE) el 
porcentaje del presupuesto total de sus proyectos destinado a IS era menor del 6%. Asimismo, 
la encuesta reveló que más de la mitad de los participantes (> 60%) dijo haber notado 
reducción en el coste de los proyectos tras la aplicación de IS, aunque la mayoría no era capaz 
de determinar el porcentaje de disminución. Además, la mayoría de los participantes (76% de 
la NASA y 84% del INCOSE) indicaba que la relación Coste-Beneficio de la IS en los proyectos 
era buena o excelente, es decir, consideraban rentable la aplicación de la metodología desde el 
punto de vista económico. 
TRABAJO FIN DE MÁSTER 
 
 
 
 27 
Por otro lado, en la Ilustración 9 se muestran los resultados del estudio 5 del SECOE 
(Honour, 2004) para los primeros 25 proyectos de la muestra, representándose el ratio entre 
el coste real o incurrido para los proyectos de la muestra (Actual Cost) y el coste planificado 
para los mismos (Planned Cost), medido hasta la entrega del primer artículo sin incluir los 
costes de producción, frente al esfuerzo invertido en IS (SE Effort) a lo largo de todo el ciclo de 
vida, calculado este esfuerzo como el producto entre la calidad de la IS aplicada (SE Quality) y 
el ratio entre el coste invertido en IS (SE Cost) y el coste real o incurrido (Actual Cost).Ilustración 9: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2004) 
Teniendo en cuenta la curva de regresión por mínimos cuadrados, se observa que a 
medida que aumenta el esfuerzo invertido en IS disminuye la desviación del coste incurrido 
respecto al coste planificado hasta llegar a un punto óptimo, en torno al 15% de esfuerzo 
invertido en IS, a partir del cual seguir invirtiendo en IS no aporta beneficio económico a los 
proyectos. 
En la Ilustración 10, se muestran resultados publicados para el estudio 6 (Honour, 2006 & 
2010), continuación del trabajo del estudio 5. Esta gráfica representa los mismos parámetros 
de la Ilustración 9 (puntos rojos) e incorpora tanto los datos de los 44 proyectos de la muestra 
del estudio 5 (puntos rojos) como los datos nuevos del estudio 6 obtenidos hasta el momento 
de la publicación (puntos azules). La línea continua negra representa la curva de regresión por 
mínimos cuadrados de los puntos representados. 
TRABAJO FIN DE MÁSTER 
 
 
 
 28 
 
Ilustración 10: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2010) 
Mediante el estudio 6 se reafirman los resultados obtenidos anteriormente en el estudio 
5, es decir, claramente existe un punto óptimo que minimiza el sobrecoste incurrido. Dicho 
punto se encuentra en torno al 15% de inversión en IS respecto al coste completo del 
proyecto. A partir de dicho punto, seguir invirtiendo solo supone un extracoste sin beneficios. 
Este estudio también proporciona información respecto a la relación existente entre las 8 
actividades de IS de la Tabla 4 y los costes de los proyectos. Para cada una de ellas compara el 
ratio entre el coste real de los proyectos de la muestra con el coste planificado para los 
mismos (hasta la entrega del primer artículo sin incluir los costes de producción), frente al 
esfuerzo invertido en esa actividad concreta de IS, calculado este esfuerzo como el producto 
entre la calidad de esa actividad de IS y el ratio entre el coste invertido en esa actividad de IS y 
el coste real de los proyectos. El resultado es una evidente aunque débil correlación entre las 
actividades de IS y el nivel de cumplimiento en costes, excepto para la actividad de definición 
del propósito del sistema en la que la correlación es prácticamente inexistente. Esto se justifica 
con el hecho de que casi todos los proyectos comienzan con esta actividad ya desarrollada 
fuera de la organización, por lo que el esfuerzo invertido en ella es casi nulo. Para los 
programas de mayor éxito, el punto óptimo de inversión que minimiza el sobrecoste del 
proyecto para cada una de las actividades analizadas se indica en la Tabla 6. 
 
Tabla 6: Inversión óptima en IS del estudio 6 (adaptación de Honour, 2010) 
ACTIVIDAD ÓPTIMO
Definición del Propósito del Sistema 1%
Ingeniería de Requisitos 2.5%
Arquitectura del Sistema 2.5%
Implementación del Sistema 3%
Verificación y Validación 4%
Análisis Técnico 4%
Gestión del Alcance 1%
Gestión Técnica/Dirección 7%
TRABAJO FIN DE MÁSTER 
 
 
 
 29 
3.2 Impacto de la IS en el Tiempo 
Según la Tabla 5 los estudios 3, 4, 5 y 6 presentan resultados para el indicador tiempo en 
proyectos dónde se aplica IS. Los datos del estudio 3, encuesta de la NASA y el INCOSE (Kludze, 
2004), respecto al indicador tiempo arrojan como resultado que casi la mitad de los 
participantes (48%) afirmaba que la IS acortaba el calendario total de sus proyectos. 
Los tiempos medidos para cada proyecto del estudio 4 de Boeing (Frantz, 1995) se 
resumen en la Tabla 7, en la que se ha añadido una última fila donde se indica la complejidad 
relativa de los sistemas entre sí, ya que aunque a priori los tres tenían las mismas 
características, es decir, las mismas prestaciones, finalmente en los dos sistemas de grado 
medio y alto de IS se implementaron funcionalidades extra, como consecuencia de las 
oportunidades de mejora detectadas gracias a esta metodología. Esto último se comenta con 
detalle en la sección 3.3 Impacto de la IS en la Calidad. 
 
Tabla 7: Datos de tiempos del estudio de Boeing (adaptación de Frantz, 1995) 
Los resultados extraídos de los datos anteriores son los siguientes: 
 El tiempo necesario para la gestión de requisitos del sistema con un nivel alto de IS 
(durante las etapas de diseño conceptual y preliminar) fue un 60% menor que en el 
sistema con un nivel bajo de IS. 
 El tiempo necesario para el diseño y producción del sistema con un nivel alto de IS 
(etapas de diseño de detalle y desarrollo y etapa de producción) fue un 62% menor 
que en el sistema con un nivel bajo de IS. 
 Los sistemas con un grado medio y alto de IS se desarrollaron y fabricaron (fase de 
adquisición completa) en menos de la mitad de tiempo que el sistema con un grado 
casi nulo de IS. 
En general, los tiempos de las distintas etapas de cada proyecto, desde su inicio hasta la 
puesta en servicio del sistema resultante, fueron menores en los dos casos en los que se aplicó 
IS respecto del proyecto en el que no se aplicó (grado prácticamente nulo). Es necesario 
recalcar que estos resultados más favorables se consiguieron incluso siendo estos sistemas 
más complejos, tal y como se ha comentado anteriormente. 
Sistema 1 Sistema 2 Sistema 3
Grado de implementación de IS
Bajo (casi 
nulo)
Medio Alto
Duración de la gestión de requisitos (en semanas) 25 10 10
Duración del diseño y producción (en semanas) 52 30 20
Duración total desde el inicio hasta la puesta en 
servicio del sistema (en semanas)
104 48 36
Complejidad relativa de los sistemas resultantes Baja Alta Alta
TRABAJO FIN DE MÁSTER 
 
 
 
 30 
Los datos obtenidos para los primeros 25 proyectos del estudio 5 del SECOE (Honour, 
2004) respecto al indicador tiempo se muestran en la Ilustración 11, representándose el ratio 
entre el tiempo real invertido en los proyectos de la muestra (Actual Schedule), medido hasta 
la entrega del primer artículo, y el tiempo planificado para los mismos (Planned Schedule) 
frente al esfuerzo invertido en IS (SE Effort), calculado como el producto entre la calidad de la 
IS aplicada (SE Quality) y el ratio entre el coste invertido en IS (SE Cost) y el coste total 
incurrido (Actual Cost), medido hasta la entrega del primer artículo. 
 
Ilustración 11: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2004) 
A partir de la curva de regresión por mínimos cuadrados, se observa que, a medida que 
aumenta el esfuerzo invertido en IS, disminuye la desviación del tiempo real invertido respecto 
al tiempo planificado hasta llegar a un punto óptimo, en torno al 15% de esfuerzo invertido en 
IS, a partir del cual seguir invirtiendo en IS no aporta beneficio en tiempo a los proyectos. 
En la Ilustración 12, se muestran resultados publicados para el estudio 6 (Honour, 2006 & 
2010) posterior. Esta gráfica representa los mismos parámetros y mantiene los mismos datos 
que la Ilustración 11 (puntos rojos) junto a los datos nuevos datos (puntos azules). Igual que 
para los costes, se reafirman los resultados obtenidos anteriormente en el estudio 5, es decir, 
claramente existe un punto óptimo que minimiza la duración del proyecto para un 15% de 
esfuerzo invertido en IS, a partir del cual aumentar la inversión sólo supone alargar el dicha 
duración de forma innecesaria. 
TRABAJO FIN DE MÁSTER 
 
 
 
 31 
 
Ilustración 12: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2010) 
El estudio 6 también proporciona información respecto a la relación existente entre las 8 
actividades de IS de la Tabla 4 y el tiempo de ejecución de los proyectos. Para cada una de ellas 
compara el ratio entre el tiempo real invertido en los proyectos de la muestra (hasta la entrega 
del primer artículo) y el tiempo planificado para los mismos, frente al esfuerzo invertido en esa 
actividad concreta de IS, calculado este esfuerzo como el producto entre la calidad de esa 
actividad de IS y el ratio