Sistema de Control

GESTIN DE
SISTEMAS COMPLEJOS
MEDIANTE
INGENIERIA DE SISTEMAS
ESCUELA TCNICA SUPERIOR DE INGENIERA

UNIVERSIDAD DE SEVILLA
MSTER EN ORGANIZACIN INDUSTRIAL
Y GESTIN DE EMPRESAS
TRABAJO FIN DE MSTER
Sonia Pereira lvarez
28 de Noviembre, 2012
ndice de Contenido
INTRODUCCIN ....................................................................................................1
1.1
Historia de la Ingeniera de Sistemas ..............................................................1
1.2
Qu es un Sistema? ......................................................................................2
1.3
Algunas Definiciones de Ingeniera de Sistemas ..............................................3
METODOLOGA DE INGENIERA DE SISTEMAS ........................................................5

2.1
Fase de Adquisicin .......................................................................................8
2.1.1
Diseo Conceptual .................................................................................8
2.1.2
Diseo Preliminar ................................................................................. 12
2.1.3
Diseo de Detalle y Desarrollo .............................................................. 14
2.1.4
Construccin/Produccin ..................................................................... 16
2.2
Fase de Uso ................................................................................................. 17
2.3
Actividades de Test en el Ciclo de Vida ......................................................... 18
INVESTIGACIN 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
CONCLUSIONES................................................................................................... 38
BIBLIOGRAFA ..................................................................................................... 44
ACRONISMOS Y ABREVIATURAS .......................................................................... 46
ndice de Ilustraciones
Ilustracin 1: Esquema del Ciclo de Vida de un Sistema.........................................................5
Ilustracin 2: Proceso de Anlisis, Sntesis y Evaluacin. .......................................................6
Ilustracin 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema .............................7
Ilustracin 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012).......................8
Ilustracin 5: Esquema de un Sistema FRACAS .................................................................... 17
Ilustracin 6: Sobrecoste vs Inversin en la Definicin del Sistema (Gruhl, 1992) ................. 25
Ilustracin 7: Diferencia Esfuerzo de Desarrollo - Esfuerzo en IS (Gruhl, 1992) ..................... 25
Ilustracin 8: Presupuesto invertido en IS (Dr. Ave K. Kludze, 2004) .................................... 26
Ilustracin 9: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2004) ................ 27
Ilustracin 10: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2010) .............. 28
Ilustracin 11: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2004) ............... 30
Ilustracin 12: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2010) ............... 31
Ilustracin 13: Calidad Tcnica vs Esfuerzo de IS (Honour, 2010) ......................................... 33
Ilustracin 14: Hiptesis de partida del estudio del SECOE (Honour, 2004) .......................... 34
Ilustracin 15: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2004) ............................... 34
Ilustracin 16: xito subjetivo vs Esfuerzo de IS (Honour, 2004) .......................................... 35
Ilustracin 17: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2010) ............................... 35
Ilustracin 18: Cumplimiento de objetivos (adaptacin de Miller, 2000). ............................. 36
Ilustracin 19: Valor intuitivo de IS (Honour, 2006) ............................................................. 39
Ilustracin 20: Percepcin de la Reduccin del Riesgo con IS (Honour, 2006) ....................... 39
Ilustracin 21: Factores Cuantitativos (Honour, 2010) ......................................................... 42
Ilustracin 22: Factores Subjetivos (Honour, 2010) ............................................................. 42
Ilustracin 23: Correlacin Mejorada del Coste Incurrido/Coste Planificado vs Esfuerzo en IS
(Honour, 2010) ........................................................................................................... 42
ndice de Tablas
Tabla 1: Matriz de Trazabilidad - Ejemplo avin de pasajeros ........................................... 13
Tabla 2: Informacin relevante de cada estudio analizado .................................................. 21
Tabla 3: Grados de IS del estudio de Boeing (adaptacin de Frantz, 1995) ........................... 22
Tabla 4: Actividades de IS analizadas en estudio 6 (adaptacin de Honour, 2010) ................ 23
Tabla 5: Indicadores investigados por cada estudio analizado ............................................. 24
Tabla 6: Inversin ptima en IS del estudio 6 (adaptacin de Honour, 2010)........................ 28
Tabla 7: Datos de tiempos del estudio de Boeing (adaptacin de Frantz, 1995) .................... 29
Tabla 8: Datos de calidad del Estudio de Boeing (adaptacin de Frantz, 1995) ..................... 32
1 INTRODUCCIN
El objetivo de este Trabajo Fin de Mster es reflejar las ventajas de la metodologa de
Ingeniera de Sistemas (en adelante IS1) en la gestin de proyectos de gran envergadura. Para
ello se ha realizado una revisin de la literatura sobre la aplicacin de IS en proyectos reales,
recopilando informacin de distintas fuentes y extrayendo posteriormente conclusiones de los
resultados obtenidos al aplicar dicho mtodo en organizaciones conocidas y pertenecientes a
distintos sectores o unidades de negocio.
El documento se compone de cuatro captulos:
En este primer captulo se realiza una introduccin a la IS, empezando por una breve
resea histrica. A continuacin se explica el concepto de Sistema utilizado a lo largo de todo
el documento, seguido de algunas definiciones de la metodologa provenientes de distintas
fuentes.
El segundo captulo describe la metodologa de IS a travs del Ciclo de Vida del Sistema,
que como se ver ms adelante, se divide en dos fases. La primera es la fase de adquisicin,
compuesta por las etapas de diseo conceptual, diseo preliminar, diseo de detalle y
desarrollo y la etapa produccin. La segunda fase es la de utilizacin del sistema, coincidente
con la etapa de uso operacional y mantenimiento del mismo.
El tercer captulo incluye el anlisis de ocho estudios llevados a cabo por diferentes
entidades/autores para determinar el impacto de la aplicacin de IS en diferentes programas.
El anlisis se realiza a travs de lo que se considera como los 4 indicadores principales de los
resultados de un proyecto: coste, tiempo, calidad y xito.
Finalmente, el ltimo captulo recoge las conclusiones derivadas de todo lo expuesto
anteriormente.
1.1 Historia de la Ingeniera de Sistemas

La IS es una metodologa que data de mediados del siglo XX. Hay diversidad de opiniones
respecto sus orgenes, aunque todas estn de acuerdo en que surge en respuesta a la
necesidad de gestionar de forma eficiente proyectos complejos de ingeniera (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 metodologa puede ser rastreada hasta principios de los aos 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 compaa Bell Telephone, subsidiaria de investigacin y
desarrollo de la American Telephone & Telegraph en aquel entonces, debido a la acuciante

complejidad que planteaba el desarrollo de redes telefnicas, entre otras cosas.
As, en 1943 se fusionaron sus departamentos de Ingeniera de Conmutacin e Ingeniera
de Transmisin bajo la denominacin de Ingeniera de Sistemas. A juicio de Arthur D. Hall,
pionero en el campo de la IS e ingeniero elctrico de Laboratorios Bell (y que luego se
estableci por su cuenta), la funcin de IS se haba practicado durante muchos aos, pero su
reconocimiento como entidad organizativa gener mayor inters y recursos en la organizacin.
En 1950 se creaba un primer curso de postgrado sobre el tema en el Instituto Tecnolgico de
Massachusetts y, posteriormente, sera el propio Hall el primer autor de un tratado completo
sobre el tema (Hall, 1962).
Ms adelante, en los aos 50, la IS comenz a emerger gracias a la experiencia ganada en
los programas de adquisicin 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 tcnico es alto al involucrar un
gran nmero de disciplinas diferentes y el uso de tecnologa emergente (Faulconbridge &
Ryan, 2005).
Mediante esta metodologa fueron llevados a cabo algunos de los ms 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 exploracin planetaria mediante sondas no
tripuladas. La corporacin americana TRW, cuyos negocios se centran en gran medida en el
sector aeroespacial y responsable de la construccin de las sondas del Programa Pioneer,
tambin se atribuye a s misma el merito de ser pionera en los mtodos de IS, en base a su
trabajo en el desarrollo misiles balsticos intercontinentales (Halverson, 2011) a finales de los
aos 50.
En general, la IS ha ido evolucionando a lo largo de la segunda mitad del siglo XX y hasta
nuestros das, pero que no fue definida formalmente como un campo hasta los aos 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 prcticas profesionales de IS y en la
educacin. Como resultado de la implicacin de ingenieros de sistemas de cualquier parte del
mundo, el nombre de la organizacin 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 propsito comn. En el
sentido ms amplio de la palabra, es algo que proporciona una solucin a un problema
complejo (Faulconbridge & Ryan, 2005). Por ejemplo, el desarrollo y fabricacin de un nuevo
modelo de avin, de un carro de combate o la construccin de una central nuclear.
Existen dos formas de describir un Sistema:
En trminos funcionales, refirindonos al problema que resuelve:
o
Qu tiene que hacer? (funcionalidad)
Cmo de bien tiene que hacerlo? (rendimiento)
Bajo qu condiciones tiene que operar? (entorno)
Sistemas externos implicados en su operacin? (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 trminos fsicos, refirindonos a cmo se ha diseado:
o
Cmo se desglosa? (subsistemas y componentes)
Cmo vamos a dimensionarlo? (diseo)
Cmo vamos a fabricarlo? (procesos de fabricacin)
Cmo vamos a integrarlo? (ensamblaje y pruebas)
Esto es el Dominio Solucin, a cargo del contratista principal, es decir, de la entidad

que disea, 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 solucin. La relacin 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 travs de la definicin de unos requisitos. La
deteccin de la necesidad o carencia representa el punto de partida de su Ciclo de Vida. Este
concepto se explicar en detalle en el captulo 2.
1.3 Algunas Definiciones de Ingeniera de Sistemas

El debate acerca como definir la IS tiene varias dcadas y el nmero de definiciones ha
aumentado significativamente a lo largo de esta ltima. Definiciones clsicas surgieron durante
los aos 60 y 70, todas bastante parecidas en naturaleza, pero con variaciones en relacin a
como la referencian, denominndola en ocasiones como una prctica y otras como un
proceso, un mtodo 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.
Segn la norma militar estadounidense MIL-STD-499B3 (Department of Defense, 1993) la

IS se define como:
Un enfoque interdisciplinar que abarca todo el esfuerzo tcnico 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 Ingeniera de Sistemas abarca:
Desarrollo, fabricacin, verificacin, despliegue, operaciones, soporte, desactivacin y
formacin del usuario en los productos y procesos del sistema.
Gestin de la configuracin del Sistema.
Traslado de la definicin del sistema en estructuras desglosadas de trabajo.
Desarrollo de la informacin para la toma de decisiones de gestin.
Por otro lado, el INCOSE la define como:
Un enfoque interdisciplinar cuyo objetivo es posibilitar la realizacin 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
diseo y validando el sistema, mientras se considera el problema al completo.
La Ingeniera 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 concepcin hasta su produccin y puesta en servicio. La Ingeniera de Sistemas considera las
necesidades del negocio como las necesidades tcnicas de los clientes, con el objetivo de
proveer un producto de calidad que cumpla con necesidades del usuario.
La definicin de Kossiakof & Sweet (Systems Engineering Principles and Practices, 2003)
dice que:
La funcin de la Ingeniera de Sistemas es guiar la ingeniera de sistemas complejos. La
Ingeniera de Sistemas est enfocada en el sistema como un todo y hace nfasis en la
operacin total. Mira al Sistema desde fuera, es decir, a su interaccin con otros sistemas y a su
entorno, as como desde dentro.
Podramos seguir aadiendo decenas de definiciones procedentes de fuentes distintas,
teniendo todas ellas en comn 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.
2 METODOLOGA DE INGENIERA DE SISTEMAS

La IS se centra en el Ciclo de Vida del sistema al completo, y lo tiene en consideracin a lo
largo de todos los procesos de toma las decisiones. El Ciclo de Vida comienza con la deteccin
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 MILSTD-499B (Department of Defense, 1993) y Blanchard & Fabricky (Systems Engineering and
Analysis, 1998), representado en la Ilustracin 1, seleccionado por su sencillez y por la clara
delimitacin entre las 2 grandes fases en que divide el ciclo:
Fase de Adquisicin: Comienza con el establecimiento de la necesidad por parte de
un grupo de usuarios y termina con la construccin o produccin del sistema. Esta
fase se compone de 4 etapas principalmente:
o
Diseo Conceptual
Diseo Preliminar
Diseo de Detalle y Desarrollo
Construccin y/o Produccin
Fase de Utilizacin: 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.
Ilustracin 1: Esquema del Ciclo de Vida de un Sistema
La lnea entre la fase de adquisicin y la fase de uso es clara y nos permite analizar la
aplicacin de IS en ambas fases por separado a travs de un proceso cclico de Anlisis,
Sntesis y Evaluacin como el de la Ilustracin 2, recurrente en todas sus etapas. Como parte
de la funcin de evaluacin, debe realizarse una revisin de cada una de ellas tras su
finalizacin.
ANLISIS
EVALUACIN
SNTESIS
Ilustracin 2: Proceso de Anlisis, Sntesis y Evaluacin.
A lo largo de ambas fases, se llevan a cabo actividades de Test y Evaluacin (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
adquisicin y de uso, todas sus etapas y las actividades de T&E sern explicadas en detalle en
las secciones 2.1, 2.2 y 2.3 (Faulconbridge & Ryan, 2005). Para mayor claridad, en la Ilustracin
3 se muestra un esquema del proceso.
Obviamente no existe una nica solucin vlida para todos los proyectos, por lo que la
aplicacin de esta metodologa a distintos sistemas puede requerir de cierto grado de
personalizacin del procedimiento para adaptarlo a las caractersticas individuales de cada
caso.
En las primeras etapas de un proyecto es dnde la IS tiene mayor potencial, ya que
aproximadamente el 75% del coste del proyecto queda determinado en las etapas iniciales de
diseo del ciclo de vida, lo que se pone de manifiesto en la Ilustracin 4. Cuanto ms se tarde
en descubrir y corregir los problemas mayor ser el impacto negativo en el proyecto, por ello
el mayor esfuerzo o inversin de anlisis debe realizarse en estas primeras etapas.
La implementacin exitosa de los procedimientos y mtodos de IS en un proyecto tiene
mltiples beneficios a lo largo del Ciclo de Vida de un sistema, entre los que podemos destacar
los siguientes:
Ahorro econmico durante toda la vida del sistema.
Aunque implementar la IS supone un coste adicional en el proyecto, sobre todo en las
actividades tempranas del diseo y desarrollo, si el procedimiento es aplicado
correctamente el ahorro resultante a lo largo de todo el Ciclo de Vida compensa
sobradamente esta inversin inicial en recursos e infraestructura.
Reduccin 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 diseo 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
diseo estos se detectaran en etapas tempranas. Debido a su riguroso procedimiento, la
IS permite alcanzar un nivel de madurez del diseo elevado mucho antes.
Reduccin significativa de los riesgos tcnicos asociados al desarrollo del producto.

Los riesgos tcnicos son identificados al principio y monitorizados a lo largo del proceso
usando un sistema de medida de rendimiento, revisiones de diseo y auditoras.
La IS posibilita que todos y cada uno de los requisitos puedan ser trazados en todo
momento aguas abajo hasta el diseo, y viceversa, garantizndose de esta forma que cualquier
cambio en los mismos (o en su interpretacin) es repercutida en las correspondientes
modificaciones del producto, as como que cualquier modificacin del diseo no se traducir
en incompatibilidades con los requisitos.
FASE DE ADQUISICIN
Linea Base Funcional
Diseo
conceptual
Identificacin
de requisitos
Anlisis de
viabilidad
Anlisis de
requisitos del
sistema
Sntesis a
nivel de
sistema
Revisin del
diseo del
sistema
Sntesis a
nivel de
subsistema
Revisiones del
diseo
preliminar
Linea Base Distribuida
Diseo
preliminar
T
&
E
Anlisis de
requisitos de
subsistemas
Distribucin
de los
requisitos
Identificacin
/ diseo de
interfaces
Linea Base de Producto
Diseo de
detalle y
desarrollo
Diseo de detalle
de subsistemas y
componentes
Integracin de
subsistemas y
componentes
Desarrollo de
prototipos
Revisiones del
diseo de detalle
Construccin/ Produccin
FASE DE USO
Utilizacin del sistema
Posibles modificaciones
Mantenimiento del sistema
Ilustracin 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema
Ilustracin 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012)
2.1 Fase de Adquisicin

La fase de adquisicin comprende 4 etapas principales: Diseo Conceptual, Diseo
Preliminar, Diseo de Detalle y Desarrollo y finalmente la Construccin y/o Produccin de
sistema.
2.1.1
Diseo Conceptual
El Diseo 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 prctica la definicin 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 Diseo Conceptual tiene como
objetivo evitar esta ambigedad y establece una Lnea Base Funcional. El proceso sera el
siguiente:
Identificacin 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 Especificacin
de Sistema.
El ingeniero de sistemas debe asegurar la trazabilidad de cada requisito hasta la
Especificacin, asegurndose as que todos y cada uno de ellos hayan sido contemplados.
Tambin debe asegurarse la trazabilidad en sentido contrario, es decir, que cada decisin
de diseo indicada en la Especificacin corresponde al menos con un requisito,
asegurndose as que en la especificacin no haya nada que no haya sido formalmente

solicitado por el cliente.
El Documento de Requisitos de Sistema es el primer documento crtico del proceso de IS
que captura las necesidades del cliente/usuario, dejando completamente definida la
aplicacin o misin del sistema. El primer paso para elaborar el documento es la
identificacin de los recursos humanos involucrados en el proyecto, desde los usuarios
eventuales, operadores y personal de mantenimiento hasta los ingenieros de sistemas y
diseadores, as como el personal de pruebas. En paralelo tambin deben identifican las
restricciones del proyecto y de la empresa, as como las restricciones o limitaciones
externas. A continuacin es necesario definir las necesidades a cubrir, metas y objetivos a
satisfacer, los escenarios operacionales (casos de usos o modos de operacin) y las
medidas de efectividad o mtricas que valoran el grado de satisfaccin del cliente con el
producto. El siguiente paso consiste en definir os lmites del sistema, definiendo las
restricciones de diseo (por ejemplo el uso de ciertas tecnologas 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 disear y qu queda excluido del mismo. Finalmente, se
confirma la estructura del documento seleccionada, teniendo en cuenta las referencias
que proporcionan una gua en este aspecto (ANSI5 & AIAA6, 1992), y el documento se
distribuye y aprueba por todas las partes interesadas.
Anlisis 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 trminos de recursos disponibles como
dinero, tiempo, personal y materiales. En la elaboracin del Documento de Requisitos de
Sistema ya debi ser incluido parte de este estudio de alternativas, al realizar la
identificacin de las restricciones del proyecto y de la empresa. Un correcto anlisis de
viabilidad implica la identificacin de alternativas o soluciones a nivel de sistema,
confirmando para cada una de ellas qu requisitos se cumplen y cules no se cumplen.
Adems, es necesario evaluar el potencial de cada alternativa en trminos de viabilidad,
rendimiento, efectividad, riesgo tcnico y del proyecto y otras medidas del rendimiento,
recomendando la mejor de las posibles soluciones.
Anlisis de requisitos del sistema:
Este anlisis 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, Fsicos, 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 presin, temperatura, humedad, etc; los
requisitos Fsicos el tamao, volumen, masa, forma, materiales, etc.; los requisitos de
Funcionamiento las funciones, modos de operacin, caractersticas hardware y software,
etc.
Una vez que las funciones han sido identificadas, es necesario definir los requisitos de
prestaciones del sistema o parmetros 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 cmo de bien debe hacerlo. Por ejemplo, para la
temperatura definir el rango tolerado, para la masa el peso mximo, y para las funciones
las horas de operacin cada da y los das de operacin cada ao.
A continuacin, la definicin de requisitos funcionales y de prestaciones se completa con
la definicin de los requisitos de verificacin, que determinan cmo se va a testear el
sistema. Es decir, una vez que se ha determinado qu debe hacer el sistema y cmo debe
hacerlo, ahora debe definirse cmo va comprobarse. En ocasiones el cliente impone sus
propios mtodos de comprobacin 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 ms cualitativos que cuantitativos. Es por
esto que es necesario identificar tambin, mediante un anlisis 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 sera un requisito en el que nos indicasen que el
sistema avin de pasajeros, que tenemos que disear y construir, debe proporcionar
confort de primera clase. Los requisitos derivados seran, entre otros, establecer el
espacio mnimo para poder estirar las piernas, las dimensiones de los asientos, los
sistemas de entretenimiento a bordo, los baos 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 histrico del
fundamento de nuestras decisiones.
La validacin de requisitos del Diseo Conceptual no se realiza de golpe sino de forma
progresiva por lotes, clasificndolos conforme a un nivel de prioridad (requisitos
mandatorios, importantes y deseables) y definiendo las Medidas de las Prestaciones
Tcnicas (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 tcnicas de gestin de proyectos para el seguimiento de costes y de la planificacin
(IEEE.Std1220, 2005).
Una vez identificados, validados y clasificados todos los requisitos se desarrolla el
borrador de la Especificacin Funcional del Sistema (que constituir la Lnea Base
Funcional).
Otro documento resultante de esta etapa es la Declaracin de los Trabajos, documento
contractual que limita el alcance de los trabajos a realizar de forma conjunta con el
10
Documento de Requisitos de Sistema y que establece las consideraciones adicionales que

no estn recogidas en la Estructura de Desglose de Requisitos (marco de la futura
Especificacin de Sistema). Es decir, no slo indica los elementos o subsistemas fsicos
necesarios para producir el Sistema, sino el resto de consideraciones y actividades del
proceso de IS en relacin a la gestin del esfuerzo del diseo y desarrollo del Sistema,
como los entregables de documentacin (asociados habitualmente con hitos de pago), las
revisiones tcnicas y auditoras a llevar a cabo, la gestin de la configuracin y las
actividades de T&E, entre otras cosas. Tambin debe incluir la definicin del soporte
logstico a proporcionar (mantenimientos, repuestos, etc.) y las responsabilidades
organizativas de todos los implicados (contratista y cliente) a travs de todas las etapas
del Ciclo de Vida del Sistema. La elaboracin de este documento es parte de la gestin del
jefe de proyecto.
Sntesis a nivel de sistema:
Se trata de establecer una configuracin fsica inicial representativa de la forma final que
tomar el sistema. En este punto el diseo an no es lo suficientemente maduro,
asumindose por tanto que dicha configuracin no es la definitiva y que esta sufrir
cambios significativos a lo largo del resto del diseo. El primer paso es identificar
soluciones potenciales para la arquitectura del sistema y recopilar informacin de cada
una de las mismas, en trminos de procesos, costes a lo largo de todo el ciclo de vida,
aseguramiento de la calidad, pruebas, mantenimiento, soporte logstico integrado, etc.,
de manera que sea posible evaluarlas e identificar las discrepancias. Tras dicha
evaluacin, se seleccionar la solucin preferida, actualizndose el borrador que
tenamos de la Especificacin de Sistema. Este documento es quiz el ms importante de
todos los de IS, ya que es la referencia para todas las dems especificaciones
subordinadas producidas posteriormente.
Revisin de diseo del sistema:
Esta revisin consiste en chequear el Diseo Conceptual con respecto a los requisitos de
la Especificacin de Sistema. Antes de llevarla a cabo, es necesario prepararla
convenientemente, confirmando los criterios de entrada/salida, preparando la
documentacin a revisar y estableciendo una agenda. El resultado de dicha revisin debe
ser la confirmacin de la solucin a nivel de sistema, mediante la Evaluacin de la
propuesta de diseo a nivel de sistema, la aprobacin de la Especificacin de Sistema, y el
establecimiento de la Lnea Base Funcional inicial, a partir de la cual se desarrollar el
resto del diseo.
Al finalizar deben acordarse acciones respecto a temas que puedan quedar pendientes
durante la revisin. Dichas acciones se llevarn a cabo en paralelo al Diseo Preliminar y
su ejecucin ser chequeada en revisiones o auditorias posteriores.
11
2.1.2
Diseo Preliminar
Tras establecer el Diseo Conceptual, la siguiente etapa del ciclo es el Diseo Preliminar.
En esta etapa, el equipo de trabajo puede ser distinto del equipo que elabor el Diseo
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 Lnea Base Funcional, configuracin fsica inicial establecida en el
Diseo Conceptual. El objetivo es establecer una Lnea Base Distribuida, dnde los requisitos
funcionales a nivel de sistema son agrupados de forma lgica en los distintos subsistemas que
lo componen. El proceso sera el siguiente:
Anlisis de requisitos de subsistemas:
A partir de la Especificacin de Sistema y las TPMs obtenidas en el Diseo Conceptual, se
sigue un proceso parecido al anlisis de requisitos de sistema, explicado anteriormente,
pero ahora a nivel de subsistema, identificando anlogamente los requisitos funcionales,
de prestaciones de verificacin y requisitos derivados, dejando registro de la justificacin
de las decisiones.
Distribucin de los requisitos:
Es el proceso de agrupar o combinar los requisitos en subdivisiones lgicas que
representen una arquitectura fsica preliminar de los subsistemas, basada en la
configuracin fsica del sistema que ya se estableci en el Diseo Conceptual.
Para ello primero deben determinarse los subsistemas y/o componentes mayores, a cada
uno de los que denominaremos Elemento de Configuracin o Configuration Item (CI8), el
cual ser gestionado de forma individual en el Diseo Preliminar y seleccionado en base a
la complejidad, criticidad, riesgo y coste asociados a su diseo, as como al desarrollo y
suministro y elementos en comn con otros subsistemas.
Continuando con el ejemplo de sistema avin de pasajeros, comentado anteriormente,
una arquitectura fsica preliminar tpica podra estara desglosada en los siguientes
subsistemas o CIs: Tren de Aterrizaje, Alas & Fuselaje, Sistema de Combustible, Sistema
Hidrulico, Mandos de Vuelo, Motor, Avinica e Interior.
Una vez definidos los CIs, los requisitos deben ser distribuidos de forma que se relacionen
los requisitos funcionales con la estructura fsica de los CIs, habitualmente a travs de una
Matriz de Trazabilidad o de Distribucin, 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 Configuracin se muestra en el extremo superior de la matriz, en
horizontal. Para el sistema avin de pasajeros se incluye un ejemplo de la matriz en la
Tabla 1.
12
Tren de Alas & Sistema de Sistema Mandos

Aterrizaje Fuselaje Combustible Hidrulico de Vuelo Motor Avinica Interior
Funcional
Largo de la pista
Asientos
Entretenimiento a bordo
Instalaciones
Catering
Repostaje
Economa de combustible
Carga/descarga
Velocidad de crucero
Grabacin
Configuracin
Equipo de seguridad
Salidas de emergencia
Interface
Ayudas a la navegacin
Ayudas despegue/aterrizaje
Sistemas de comunicaciones
Fsico
Peso del avin
Espacio para las piernas
Dimensiones de asientos
Espacio equipaje de mano
N de pasajeros
Medioambiente
Superficie de la pista
Calidad
Mantenimiento operacional
Personal necesario
Restricciones
N de motores
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabla 1: Matriz de Trazabilidad - Ejemplo avin de pasajeros
A partir de dicha matriz y del documento de Declaracin de los Trabajos definido en el

Diseo Conceptual, se desarrollar la Estructura de Desglose de los Trabajos, en la que se
incluyen no slo los paquetes fsicos 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, produccin y test, entre otras cosas.
Para cada CI debe elaborarse una Especificacin Tcnica, cuya forma depender de la
alternativa seleccionada para la produccin del elemento en cuestin. 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 elaborarn Especificaciones de Producto.
Identificacin/diseo de interfaces:
En la seleccin y definicin de los CIs que componen el sistema deben identificarse los
interfaces entre ellos (fsicos, elctricos, electrnicos, hidrulicos/neumticos, software,
13
etc.), elaborndose habitualmente un Documento de Control de Interfaces para cada

uno de ellos. Esta parte del Diseo Preliminar es crtica, ya que no solo garantiza el xito
en la integracin de los distintos subsistemas sino que, adems, impone limitaciones y
requisitos adicionales en el diseo de cada CI individualmente.
Sntesis a nivel de subsistema.
Para cada subsistema partimos de la revisin de su Especificacin Tcnica y de su
Documento de Control de Interfaces para investigar las alternativas disponibles para su
desarrollo y produccin, es decir, para definir si se usarn Commercials-Off-the-Shelf
(COTS9 o MOTS10, estos ltimos especficos para aplicaciones militares), COTS modificados
o elementos de desarrollo.
Para la seleccin 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 diseo y adoptar soluciones de compromiso.
Revisiones del diseo preliminar:
Para sistemas complejos y/o de gran tamao, lo habitual es establecer una revisin para
cada CI. Se trata de una revisin formal cuyo objetivo es asegurar que el Diseo
Preliminar es adecuado antes de pasar al Diseo de Detalle. Antes de llevarla a cabo, es
necesario prepararla convenientemente, confirmando los criterios de entrada/salida,
preparando la documentacin a revisar y estableciendo una agenda. Dicha
documentacin 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 continuacin
debe confirmarse la completa trazabilidad entre los requisitos de la Lnea Base Funcional
del Diseo Conceptual y la arquitectura fsica resultado del Diseo Preliminar y viceversa,
esto ltimo para asegurar que no hay requisitos innecesarios ocultos entre los necesarios.
El resultado ser el establecimiento de la Lnea Base Distribuida, a partir de la cual se
desarrollar el resto del diseo. Al finalizar la revisin deben acordarse acciones respecto
a temas que puedan quedar pendientes, como desviaciones respecto a los requisitos que
deban corregidas y cuya ejecucin ser chequeada en revisiones o auditorias posteriores.
2.1.3
Diseo de Detalle y Desarrollo
El Diseo de Detalle y Desarrollo contina el esfuerzo de IS desde los resultados de las

fases anteriores de diseo, es decir, parte de la Lnea Base Funcional y la Especificacin de
Sistema del Diseo Conceptual, as como de la Lnea Base Distribuida y del conjunto de
Especificaciones de Desarrollo de los CIs del Diseo Preliminar.
14
Diseo de detalle e integracin 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 integracin de todos los componentes entre s. De esta
forma, dichos componentes podrn 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 integracin de los
distintos subsistemas entre s dentro de las actividades de Test y Evaluacin (T&E). Dichas
actividades sern explicadas con ms detalle en la seccin 2.3.
Desarrollo de prototipos:
En esta etapa es habitual el desarrollo y produccin de prototipos del sistema completo o
al menos de modelos reducidos para probar funcionalidades concretas. Sobre dichos
prototipos y modelos tambin se llevarn a cabo actividades de T&E que verificarn el
diseo.
Para asegurar la optimizacin de dichas actividades, sumamente caras y grandes
consumidoras de recursos, es habitual que el cliente requiera, de forma contractual, un
chequeo previo o Revisin de la Preparacin 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 documentacin 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 diseo de detalle:
A lo largo del Diseo de Detalle se organizan un gran nmero de revisiones informales de
seguimiento de la evolucin del diseo. Al terminar este, se lleva a cabo la Revisin Crtica
de Diseo, es decir, la revisin formal final antes de pasar a la Fase de Produccin. Al igual
que suceda con la Revisin del Diseo Preliminar, para sistemas complejos y/o de gran
tamao, lo habitual es establecer una revisin para cada CI.
Las Revisiones Crticas de Diseo evalan el Diseo de Detalle mediante la revisin 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 Diseo Preliminar como problemas potenciales, as como la rectificacin de
las discrepancias levantadas durante las Revisiones de Diseo Preliminar.
Para asegurar la preparacin para la produccin/construccin, tambin deben revisarse el
Plan de Produccin y del Plan de Aseguramiento de la Calidad.
Respecto al Plan de Produccin deben chequearse como mnimo los recursos necesarios
(instalaciones, personal, formacin requerida), las consideraciones de ingeniera de
15
produccin (planificacin, mtodos de fabricacin y procesos as como utillaje especial),

los materiales y compras (lead times largos), la gestin (control de procesos, de la
produccin y seguimiento de subcontratistas) y la logstica (requisitos especiales de
empaquetado, almacenamiento y tratamiento).
Finalmente, debe determinarse la compatibilidad del diseo, referido a la compatibilidad
de los CIs con otros aspectos del sistema, como por ejemplo las instalaciones. Si la
Revisin Crtica termina satisfactoriamente, el conjunto de las especificaciones de
definicin de los componentes del sistema establece la Lnea Base de Producto, lo que
supone la congelacin del diseo.
2.1.4
Construccin/Produccin
La construccin o produccin del sistema es la etapa final de la Fase de Adquisicin, en la

que el sistema ser producido segn la Lnea Base de Producto obtenida en la etapa de Diseo
de Detalle y Desarrollo, y dnde de nuevo se llevarn a cabo actividades de T&E para asegurar
que la configuracin final del mismo cumple con el propsito para el que fue concebido.
Asimismo, durante esta etapa es imprescindible llevar a cabo actividades de gestin de la
configuracin, entre las que se incluyen auditoras de control de configuracin, para
comprobar que efectivamente el sistema se produce acorde a la Lnea Base de Producto.
Algunos proyectos estn dirigidos a producir un nico sistema, como la construccin de
un centro comercial o de un buque, mientras que en otras ocasiones, el objetivo es la
produccin de mltiples copias del sistema e incluso la produccin a gran escala. En este
segundo caso, el primer sistema producido lo ser como prototipo, soportando la verificacin
del diseo y la validacin del usuario. Lgicamente, el proceso de produccin de los sistemas
en los que slo va a producirse una unidad difiere totalmente de los sistemas de produccin
mltiple.
Los requisitos de produccin deben ser considerados en etapas tempranas de la Fase de
Adquisicin para asegurar que los riesgos relacionados son identificados y dirigidos lo antes
posible. Para ello, los ingenieros de produccin deben trabajar en equipo con los ingenieros de
diseo desde las primeras actividades para asegurar que el diseo es fabricable, de manera
que todos los aspectos relacionados con la fabricacin sean tenidos en cuenta en el diseo y
monitorizados a lo largo del mismo. De hecho, como ya se coment anteriormente, el Plan de
Produccin debe ser elaborado antes de llegar a la etapa de produccin, durante el Diseo de
Detalle y Desarrollo, y aprobado en la Revisin Crtica de Diseo.
Sin embargo, an siguiendo escrupulosamente el procedimiento durante el diseo, es
muy probable que durante la etapa de produccin se haga evidente, incluso antes de terminar,
que el sistema no va a cumplir con todos los requisitos especificados en las Lneas Base. Para
cubrir esta posibilidad, desde la gestin de la configuracin se debe considerar un sistema de
gestin de modificaciones, desviaciones y concesiones, que contemple tanto cambios de
16
diseo 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 auditoras de validacin est listo para
su entrada en servicio, es decir, para su fase de uso. Las actividades mayores que se realizar
durante esta fase la utilizacin operativa del sistema, posibles modificaciones y
mantenimiento.
Las actividades de IS continan aqu, dando soporte a las posibles modificaciones del
sistema para rectificar los dficits 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 adquisicin son detectados a
posteriori, cuando el sistema se sita en su verdadero entorno operacional y se prueba su
propsito. Para la deteccin, anlisis y establecimiento de acciones correctivas se usa el
sistema FRACAS11 (Failure Reporting Analysis and Corrective Action System), cuyo
procedimiento, segn la (MIL-STD-2155, 1985), consiste en un ciclo continuo como el
representado en la Ilustracin 5.
TESTEO Y OPERACIN
DEL SISTEMA
CIERRE DE LA
INCIDENCIA
DETECCIN DEL
FALLO O INCIDENCIA
ACCESO
USUARIOS
IMPLEMENTACIN DE
LAS ACCIONES
APERTURA EN EL
SISTEMA
SI
SOLUCION OPTIMA?
NO
RECOLECCION
DE DATOS
BD FRACAS
EVALUACIN DE LAS
PROPUESTAS
ANALISIS DE CAUSAS
DEL PROBLEMA
PROPUESTAS DE ACCIONES
(SOBRE EL PRODUCTO,
PROCESO, ETC.)
Ilustracin 5: Esquema de un Sistema FRACAS
17
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 tecnologa utilizada o el efecto ltimo
modelo.
La gestin de la configuracin debe seguir aplicndose cuando existen modificaciones, de
forma que se asegure en todo momento que el sistema est bien documentado, ya que las
diferencias entre la configuracin fsica real del sistema y su documentacin implican una
operacin y mantenimiento difcil y potencialmente peligroso.
Esto se pone de manifiesto claramente en sistemas repetitivos debido a la produccin en
serie de una flota (aviones, barcos, tanques, etc.), donde las diferencias entre los distintos
sistemas suelen ser pequeas y asociadas a unas efectividades. En este tipo de sistemas las
modificaciones no gestionadas/documentadas impactan muy negativamente en su operacin,
mantenimiento y seguridad.
Al finalizar la Fase de Uso del sistema este es retirado de servicio, lo que completara su
ciclo de vida. Durante el diseo tambin 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 difcil, como por ejemplo en los
casos de material radiactivo, criptogrfico o material de construccin, 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 funcin 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 adquisicin y uso, para evitar modificaciones de diseo
costosas en tiempo y dinero si estas deben ser implementadas al final del ciclo, de manera que
pueden ser consideradas como una medida de mitigacin de riesgos.
El objetivo del proceso completo de IS es producir un sistema que pueda ser verificado
contra la documentacin producida durante el diseo 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 Verificacin y Validacin, lo
18
que asegura no slo que hemos construido un sistema correctamente sino que hemos
construido el sistema correcto.
Hay 3 categoras principales en las actividades de T&E:
T&E de Desarrollo, actividades llevadas a cabo durante la Fase de Adquisicin.
T&E de Aceptacin, actividades llevadas a cabo para la aceptacin formal del sistema
por parte del cliente. Es el lmite entre la Fase de Adquisicin y la Fase de Uso.
T&E Operacional, actividades llevadas a cabo durante la Fase de Uso tras la
aceptacin formal del sistema por el cliente. Realizada por el personal de operacin 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, dnde se especifiquen las responsabilidades de cada parte de la organizacin
involucrada en las mismas, as como los recursos necesarios para llevarlas a cabo (personal,
equipamiento, materiales, repuestos, simuladores, modelos, etc.) y la planificacin de estos en
el tiempo. El resto de documentos relevantes para el plan de T&E deben ser incluidos al menos
como apndices, como por ejemplo los procedimientos a utilizar.
19
3 INVESTIGACIN DEL IMPACTO DE LA IS EN LOS PROYECTOS

En ocasiones es bastante difcil poder demostrar dentro de una organizacin el beneficio
o valor aadido que aporta la prctica de la IS de forma que se justifiquen sus costes. En este
sentido, esta metodologa 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 captulo 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 revisin de la literatura sobre la aplicacin de la IS en
proyectos reales.
En la Tabla 2 se resume la informacin relevante de cada uno de dichos estudios. Son
diferentes anlisis 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 aos 80, se basa en una muestra de 32
grandes proyectos llevados a cabo entre los aos 70 y 80 por dicha organizacin (Gruhl, 1992).
A lo largo del mismo se recopilaron datos de costes durante las etapas de definicin de cada
uno de los sistemas, correspondientes al diseo conceptual, diseo preliminar y diseo de
detalle y desarrollo de la metodologa de IS.
El estudio 2 fue llevado a cabo a principios del siglo XXI por la divisin de productos
comerciales de IBM (Barker, 2003), al implementar la metodologa de IS en sus desarrollos de
software comercial. Durante dicha implementacin 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 adquisicin 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 implementacin de IS en proyectos complejos (Kludze, 2004) a lo
largo del ciclo de vida de cada uno segn la percepcin de empleados de ambas
organizaciones. Dichos empleados estaban involucrados directamente en la gestin y
desarrollo de los sistemas resultantes (personal con perfil de jefe de proyecto, ingeniero de
sistemas o similar), obtenindose resultados en cuanto a costes, tiempo y calidad de los
proyectos.
20
Ref.
Entidad
Gruhl, 1992
NASA
Barker, 2003
IBM
Fecha/
Dcada
Tamao
Muestra
Finales de
los aos 80
32 proyectos
estudiados
Grandes proyectos de
la NASA desarrollados
entre los aos 70 y 80
Etapas de
definicin
8 proyectos
estudiados
Proyectos de
desarrollos Software
de IBM
Fase de
adquisicin
Principios
del siglo XXI
(en torno al
2000)
Principios
379
Kludze, 2004 NASA/INCOSE del siglo XXI participantes
(en torno al en la encuesta
2000)
3 proyectos
estudiados
Frantz, 1995
BOEING
Aos 90
Honour, 2004
SECOE
2001
Honour, 2006 Univ. del Sur

& 2010
de Australia
2004 a
Actualidad
Ancona, 1990
MIT
Finales de
los aos 80
45 proyectos
estudiados
Miller, 2000
MIT
Finales de
los aos 90
60 proyectos
estudiados
Tipo/s de Proyecto/s
Parte de la IS
Aplicada
Todas
Sistemas de sujecin
de grandes partes de
aviones durante su
fabricacin
44 proyectos
estudiados
48 proyectos
estudiados
hasta 2010
Fase de
adquisicin
Todas
Todas
Proyectos de
desarrollo de
productos
tecnolgicos
Grandes proyectos
desarrollados entre
los aos 80 y 90
Todas
Todas
Tabla 2: Informacin relevante de cada estudio analizado
El estudio 4, realizado en los aos 90, fue realizado por la empresa aeronutica Boeing.
En l se llev a cabo un anlisis del impacto de la implementacin de la metodologa de IS en el
tiempo y la calidad para tres proyectos de sistemas similares que iban a producirse de forma
simultnea (Frantz, 1995). Los proyectos consistan en el desarrollo y fabricacin de sistemas
de sujecin de grandes partes de aviones durante su proceso de produccin, todos ellos de
coste, caractersticas y prestaciones anlogas a priori. La nica diferencia significativa entre los
tres proyectos era el grado de implementacin de IS a lo largo de la fase de adquisicin de los
proyectos, el cual variaba desde prcticamente 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
adquisicin de los mismos, es decir, tanto durante las etapas de diseo y desarrollo como
durante la etapa de fabricacin y pruebas. La diferencia entre los distintos grados de
implementacin de IS en cada proyecto del estudio 4 se puede apreciar en la Tabla 3, en la que
se especifica cmo se llevaron a cabo ciertas actividades concretas del desarrollo de los
proyectos en las que los procedimientos del diseo tradicional difieren completamente de los
de IS, como pueden ser, por ejemplo, la gestin de requisitos o el enfoque de las pruebas.
21
Grado casi nulo

Nivel de experiencia en
gestin de sistemas por IS
Gestin de
subcontratistas
Acceso y soporte
disciplinas de gestin de
sistemas
Enfoque de la gestin de
requisitos
Grado medio
Grado alto
Bajo
Bajo a Medio
Revisiones peridicas de
diseo
Ingenieros de sistemas full-time en los subcontratistas

mayores
Bajo acceso
Requisitos simblicos
Gran acceso pero poca

atencin
Gran acceso y gran atencin
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
Buenas especificaciones de Especificaciones funcionales dirigidas va requisitos. HW

HW y SW
y SW, procesos e interfaces totalmente incluidos en ellas
Enfoque de diseo
Adherencia a la
especificacin funcional
Revisiones de diseo
Enfoque para las pruebas
de integracin
Enfoque para las pruebas
de aceptacin
Se siguen las
especificaciones a lo largo
No se siguen las especificaciones durante el desarrollo y
del desarrollo y
fabricacin. Estas son actualizadas por requerimiento
fabricacin. Estas son
del diseo
actualizadas a medida que
el diseo madura
Revisiones formales
Revisiones formales
Revisiones semanales por
internas. Atencin
internas. Poca atencin a
equipos
moderada a los inputs
los inputs externos
externos
Definidas temprano en el ciclo de vida y dirigidas por la
Definidas tras el diseo
especificacin funcional
Tests basados en los criterios de aceptacin de la
Tests definidos en el plan
especificacin de requisitos y en la especificacin
general de pruebas
funcional
Tabla 3: Grados de IS del estudio de Boeing (adaptacin 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 investigacin para intentar cuantificar el beneficio
aportado por la IS a lo largo del ciclo de vida de un proyecto. Hasta el momento de la
publicacin se analizaron datos de costes, tiempos y xito de 25 proyectos reales (Honour,
2004), aadindose posteriormente al estudio los resultados de 19 proyectos ms.
El autor del estudio 5 contina su trabajo justo despus de la publicacin del mismo
mediante el estudio 6 (Honour, 2006 & 2010) a travs de la Universidad del Sur de Australia,
investigacin que an sigue abierta y en proceso, ofreciendo a las empresas que quieran
participar en ella un estndar de comparacin para su negocio. En el documento publicado con
los resultados obtenidos hasta la fecha (Honour, 2010), el autor mantiene la informacin de los
44 proyectos del estudio 5 y le aade datos de 48 proyectos ms, de forma que el tamao de
la muestra va siendo ms significativo cada vez, en total 92 proyectos analizados, incluyendo
adems datos del indicador calidad, no analizados en el estudio 5. Tambin incluye la medida
22
de la correlacin existente entre los 4 indicadores del proyecto (coste, tiempo, calidad y xito)
para las 8 categoras o actividades concretas de IS que se indican en la Tabla 4.
DESCRIPCIN
MD
Definicin del Propsito Identificacin y anlisis de requisitos de sistema.

del Sistema
(Actividad tpica del diseo conceptual)
RE Ingeniera de Requisitos
Identificacin y anlisis de requisitos de subsistemas y componentes.

(Actividad tpica del diseo preliminar)
Sintetizar el diseo de un sistema a travs de la arquitectura de sus

SA Arquitectura del Sistema componentes y su integracin.
(Forma parte del diseo de detalle, desarrollo)
ACTIVIDAD DE IS
SI
Implementacin del
Sistema
Esfuerzo de soporte a la creacin del primer prototipo.

(Forma parte del diseo de detalle, desarrollo)
Verificacin del sistema fsico contra sus requisitos y validacin del

VV Verificacin y Validacin mismo contra su propsito u objetivo.
(Actividades de Test)
TA Anlisis Tcnico
Anlisis multidisciplinar de propiedades del sistema en desarrollo,

orientado a predecir las prestaciones del sistema y dar soporte en la
toma de decisiones de compromiso.
(Forma parte del diseo preliminar)
SM Gestin del Alcance
Gestin 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
Gestin
Tcnica/Direccin
Esfuerzo de guiar y coordinar al personal hacia el xito del proyecto.

Abarca tareas de planificacin del programa, gestin tcnica, gestin
de equipos, gestin del riesgo y gestin de la configuracin (entre
otras).
(Se prolonga a lo largo de todo el ciclo de vida)
Tabla 4: Actividades de IS analizadas en estudio 6 (adaptacin de Honour, 2010)
El estudio 7, realizado por el Instituto Tecnolgico de Massachusetts (MIT12), fue llevado

a cabo a finales de los aos 80 e investiga la gestin del tiempo en proyectos de ingeniera
(Ancona & Caldwell, 1990). Se recopilaron datos de 45 equipos de desarrollo de productos
tecnolgicos, identificando las mltiples tareas realizadas por sus miembros a lo largo de la
fase de adquisicin de los proyectos y midiendo el tiempo dedicado a cada una de ellas.
Tambin se midi el xito de cada proyecto, entendido este como el nivel de calidad y
comercializacin del producto.
El estudio 8, tambin llevado a cabo por el MIT a finales de los aos 90, investiga la
gestin estratgica de grandes proyectos de ingeniera (Miller, 2000). El estudio recopila datos
de una muestra de 60 grandes proyectos de ingeniera de diversas reas realizados desde los
aos 80 hasta el momento del estudio. Dichos datos relacionaban el tipo de gestin 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.
23
ESTUDIOS
En la en la Tabla 5 se recogen los indicadores investigados por cada estudio. En las

secciones a continuacin se analizan los resultados obtenidos para dichos indicadores.
1
2
3
4
5
6
7
8
COSTE
X
X
X
INDICADORES
TIEMPO CALIDAD
X
X
X
X
X
X
XITO
X
X
X
X
X
X
X
Tabla 5: Indicadores investigados por cada estudio analizado
3.1 Impacto de la IS en los Costes

Segn 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 inversin durante la definicin del sistema (periodo en el que se
llevan a cabo las etapas de diseo conceptual, diseo preliminar y diseo de detalle y
desarrollo de IS). En la Ilustracin 6 se muestran los datos respecto a este indicador para cada
uno de los 32 proyectos de dicho estudio, representndose el porcentaje del sobrecoste
incurrido a lo largo del proyecto (Program Overrun) frente al porcentaje invertido en la
definicin 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 definicin (Target), mas una parte variable consistente en la cantidad invertida
en la definicin (Definition$).
Como puede observarse en la grfica, cuanto mayor era el gasto en las etapas de
definicin del proyecto, menor era el sobrecoste incurrido a lo largo del proyecto completo.
Adems, 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 mayora de los proyectos, la inversin en la definicin del sistema era menor del
10% del coste total.
El mnimo de la curva de aproximacin del sobrecoste est en torno al 15% de
inversin en la definicin.
Sin embargo, el coste de definicin de los proyectos no se corresponde exactamente con
el coste de IS en dicho periodo, aunque s se puede considerar como una buena aproximacin,
24
tal y como se indica en la Ilustracin 7, en la que se muestra el esfuerzo de desarrollo

(Development Effort) a lo largo del tiempo para un proyecto tipo de la NASA, comparndose el
esfuerzo total a lo largo del mismo (Total Project Effort), con la parte o fraccin de dicho
esfuerzo invertido en la aplicacin de IS (Systems Engineering Effort).
Como puede observarse, gran parte del esfuerzo del proyecto en la definicin del sistema
se corresponde con el esfuerzo de aplicacin de IS en dicho periodo, y por lo tanto con la
inversin en esta. Por lo tanto, podemos extrapolar que el nivel ptimo de inversin en las
correspondientes etapas de IS (diseo conceptual, diseo preliminar y diseo de detalle y
desarrollo de IS) que minimiza el sobrecoste podra estar tambin prximo al 15% del
presupuesto total o al menos en un entorno cercano a este valor.
Ilustracin 6: Sobrecoste vs Inversin en la Definicin del Sistema (Gruhl, 1992)
Ilustracin 7: Diferencia Esfuerzo de Desarrollo - Esfuerzo en IS (Gruhl, 1992)
En el estudio 2, de IBM (Barker, 2003), se recurri a mtricas de productividad que

calculan el coste relativo de los sistemas respecto a su tamao, dividiendo el coste absoluto de
cada proyecto entre el nmero de puntos funcin del sistema en cuestin (ya utilizadas en IBM
previamente al estudio), lo que permita poder comparar entre s los costes de sistemas
25
distintos. El mtodo de los puntos funcin fue definido por Allan Albrecht, de IBM, para valorar
el tamao de proyectos de desarrollo de software, midiendo a travs de dichos puntos la
funcionalidad puesta al servicio del usuario del sistema, independientemente de la tecnologa
utilizada para ello (A.J.Albrecht, 1979). Este mtodo representa hoy da una mtrica 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 combinacin con una
adecuada gestin de proyectos y procesos de test, ya que las mtricas 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 metodologa.
Los resultados en cuanto a coste del estudio 3, encuesta de la NASA y el INCOSE (Kludze,
2004), se muestran en la Ilustracin 8, donde se observa el porcentaje de participantes frente
al porcentaje del presupuesto total de sus proyectos ms recientes invertido en tareas de IS.
Ilustracin 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 podan haberse visto sesgados por la
interpretacin de proyectos ms recientes por parte de los participantes, de forma que estos
incluyeran slo datos de los proyectos recientes en los que hubieran implementado IS a alto
nivel, es decir, proyectos en los que la inversin en IS era siempre alta, en lugar de incluir datos
de todos sus proyectos recientes con implementacin 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 mayora 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 ms de la mitad de los participantes (> 60%) dijo haber notado
reduccin en el coste de los proyectos tras la aplicacin de IS, aunque la mayora no era capaz
de determinar el porcentaje de disminucin. Adems, la mayora de los participantes (76% de
la NASA y 84% del INCOSE) indicaba que la relacin Coste-Beneficio de la IS en los proyectos
era buena o excelente, es decir, consideraban rentable la aplicacin de la metodologa desde el
punto de vista econmico.
26
Por otro lado, en la Ilustracin 9 se muestran los resultados del estudio 5 del SECOE
(Honour, 2004) para los primeros 25 proyectos de la muestra, representndose 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 artculo sin incluir los
costes de produccin, 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).
Ilustracin 9: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2004)
Teniendo en cuenta la curva de regresin por mnimos cuadrados, se observa que a

medida que aumenta el esfuerzo invertido en IS disminuye la desviacin 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 econmico a los
proyectos.
En la Ilustracin 10, se muestran resultados publicados para el estudio 6 (Honour, 2006 &
2010), continuacin del trabajo del estudio 5. Esta grfica representa los mismos parmetros
de la Ilustracin 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 publicacin (puntos azules). La lnea continua negra representa la curva de regresin por
mnimos cuadrados de los puntos representados.
27
Ilustracin 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 inversin en IS respecto al coste completo del
proyecto. A partir de dicho punto, seguir invirtiendo solo supone un extracoste sin beneficios.
Este estudio tambin proporciona informacin respecto a la relacin 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 artculo sin incluir los costes de produccin), 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 dbil correlacin entre las
actividades de IS y el nivel de cumplimiento en costes, excepto para la actividad de definicin
del propsito del sistema en la que la correlacin es prcticamente inexistente. Esto se justifica
con el hecho de que casi todos los proyectos comienzan con esta actividad ya desarrollada
fuera de la organizacin, por lo que el esfuerzo invertido en ella es casi nulo. Para los
programas de mayor xito, el punto ptimo de inversin que minimiza el sobrecoste del
proyecto para cada una de las actividades analizadas se indica en la Tabla 6.
ACTIVIDAD
Definicin del Propsito del Sistema
Ingeniera de Requisitos
Arquitectura del Sistema
Implementacin del Sistema
Verificacin y Validacin
Anlisis Tcnico
Gestin del Alcance
Gestin Tcnica/Direccin
PTIMO
1%
2.5%
2.5%
3%
4%
4%
1%
7%
Tabla 6: Inversin ptima en IS del estudio 6 (adaptacin de Honour, 2010)
28
3.2 Impacto de la IS en el Tiempo

Segn la Tabla 5 los estudios 3, 4, 5 y 6 presentan resultados para el indicador tiempo en
proyectos dnde 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 aadido una ltima fila donde se indica la complejidad
relativa de los sistemas entre s, ya que aunque a priori los tres tenan las mismas
caractersticas, 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 metodologa. Esto ltimo se comenta con
detalle en la seccin 3.3 Impacto de la IS en la Calidad.
Sistema 1
Bajo (casi
nulo)
Sistema 2
Sistema 3
Medio
Alto
Duracin de la gestin de requisitos (en semanas)
25
10
10
Duracin del diseo y produccin (en semanas)
52
30
20
Duracin 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
Grado de implementacin de IS
Tabla 7: Datos de tiempos del estudio de Boeing (adaptacin de Frantz, 1995)
Los resultados extrados de los datos anteriores son los siguientes:

El tiempo necesario para la gestin de requisitos del sistema con un nivel alto de IS
(durante las etapas de diseo conceptual y preliminar) fue un 60% menor que en el
sistema con un nivel bajo de IS.
El tiempo necesario para el diseo y produccin del sistema con un nivel alto de IS
(etapas de diseo de detalle y desarrollo y etapa de produccin) 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
adquisicin 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 prcticamente nulo). Es necesario
recalcar que estos resultados ms favorables se consiguieron incluso siendo estos sistemas
ms complejos, tal y como se ha comentado anteriormente.
29
Los datos obtenidos para los primeros 25 proyectos del estudio 5 del SECOE (Honour,
2004) respecto al indicador tiempo se muestran en la Ilustracin 11, representndose el ratio
entre el tiempo real invertido en los proyectos de la muestra (Actual Schedule), medido hasta
la entrega del primer artculo, 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 artculo.
Ilustracin 11: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2004)
A partir de la curva de regresin por mnimos cuadrados, se observa que, a medida que
aumenta el esfuerzo invertido en IS, disminuye la desviacin 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 Ilustracin 12, se muestran resultados publicados para el estudio 6 (Honour, 2006 &
2010) posterior. Esta grfica representa los mismos parmetros y mantiene los mismos datos
que la Ilustracin 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 duracin del proyecto para un 15% de
esfuerzo invertido en IS, a partir del cual aumentar la inversin slo supone alargar el dicha
duracin de forma innecesaria.
30
Ilustracin 12: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2010)
El estudio 6 tambin proporciona informacin respecto a la relacin existente entre las 8

actividades de IS de la Tabla 4 y el tiempo de ejecucin 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 artculo) 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 entre el coste invertido en esa actividad de IS y el coste real de los
proyectos.El resultado es una evidente aunque dbil correlacin entre las actividades de IS y el
nivel de cumplimiento en costes, excepto para la actividad de definicin del propsito del
sistema en la que la correlacin es prcticamente inexistente. Esto se justifica con el hecho de
que casi todos los proyectos comienzan con esta actividad ya desarrollada fuera de la
organizacin, por lo que el esfuerzo invertido en ella es casi nulo. Para los programas de
mayor xito, el punto ptimo de inversin que minimiza el tiempo de ejecucin del proyecto
para cada una de las actividades analizadas son los mismos que minimizan los sobrecostes del
proyecto indicados previamente.
3.3 Impacto de la IS en la Calidad

Los estudios 3, 4 y 6 presentan resultados para el indicador calidad en proyectos dnde
se aplica IS. Definimos la calidad como el grado de cumplimiento de los requisitos del cliente
por parte del sistema o producto desarrollado.
En el estudio 3, encuesta de la NASA y el INCOSE (Kludze, 2004), los datos obtenidos
respecto al indicador calidad arrojan como resultado que la mayora de los participantes (84%
de la NASA y 93% del INCOSE) crea firmemente que la IS aumenta las prestaciones tcnicas del
sistema. Esto reitera que un buen entendimiento de las necesidades del cliente se traslada en
buenos requisitos de sistema, lo que puede llevar al desarrollo de un buen sistema que cumpla
con las expectativas del cliente.
31
Por otro lado, en el estudio 3 tambin se indicaban datos de no calidad, denominada por
el autor como riesgo y definido este como la probabilidad y consecuencias asociadas con el no
cumplimiento de los requisitos del sistema. Los nicos datos obtenidos a este respecto
mediante la encuesta realizada indican que la mayora de los participantes de sta (91% de la
NASA y 94% del INCOSE) afirmaban que la IS reduce el riesgo en los proyectos.
Los datos obtenidos en el estudio 4 de Boeing para el indicador calidad se resumen en la
Tabla 8 (Frantz, 1995), en la que se observa que en el proyecto con un grado de
implementacin de IS bajo (casi nulo) el resultado fue un nivel de calidad tambin bajo (calidad
relativa, por comparacin con los otros proyectos) ya que slo se cumplieron los requisitos de
fabricacin, mientras que en los proyectos con un grado medio y alto de IS se detectaron
oportunidades de mejora con un incremento de coste mnimo, gracias a las sesiones de trabajo
intensivas, que permitieron implementar algunas funcionalidades adicionales a los sistemas e
incrementando el grado de complejidad de los mismos. Un ejemplo de estas prestaciones
adicionales era la capacidad de detectar cierto grado de deformacin en las estructuras
sujetadas, as como de analizar si esto producira algn tipo de interferencia en la mquina de
control numrico durante el procesamiento de la pieza, en cuyo caso se produca la
rectificacin de la programacin en tiempo real.
Sistema 1
Bajo (casi nulo)
Bajo (solo se
Grado de cumplimiento de los
cumplieron los
requisitos del cliente
requisitos de
fabricacin)
Complejidad relativa de los sistemas
Baja
Grado de implementacin de IS
Sistema 2
Medio
Sistema 3
Alto
Alto (identificacin de nuevas

oportunidades)
Alta
Alta
Tabla 8: Datos de calidad del Estudio de Boeing (adaptacin de Frantz, 1995)
Los datos obtenidos para el estudio 6 (Honour, 2006 & 2010) se muestran en la
Ilustracin 13, representndose la calidad del sistema (Technical Quality) frente al esfuerzo
invertido en IS (SE Effort), calculado como el producto entre la calidad de la IS (SE Quality) y el
ratio entre el coste invertido en IS (SE Cost) y el coste total incurrido (Actual Cost), medido este
hasta la entrega del primer artculo. La calidad fue medida mediante la cuantificacin del nivel
de cumplimiento del sistema con los parmetros clave de prestaciones definidos para el
mismo (KPPs = Key Performance Parametres) a travs de la opinin subjetiva del personal
entrevistado. La escala utilizada va de 0 a 2.0, en la que 0 indica que no se cumplieron ninguno
de los parmetros clave, 1.0 indica que el nivel de cumplimiento est en el umbral de lo
aceptable y 2.0 que este es excelente. Para cada parmetro clave se cuantific su valor de esta
forma, calculndose posteriormente la media de todos los valores. En la Ilustracin 13 se traza
la recta de aproximacin de los datos anteriores. Como puede observarse, los resultados
obtenidos indican que no existe correlacin aparente entre la calidad tcnica del sistema y el
esfuerzo invertido en IS para los proyectos de la muestra, lo que indica que en dichos
32
proyectos los esfuerzos se concentraron principalmente en cubrir los objetivos mnimos para
conseguir la aceptacin del sistema por parte del cliente.
Ilustracin 13: Calidad Tcnica vs Esfuerzo de IS (Honour, 2010)
Al igual que para los indicadores anteriores, este estudio tambin proporciona
informacin respecto a la relacin existente entre las 8 actividades de IS de la Tabla 4 y la
calidad tcnica del proyecto. Para cada una de ellas compara dicha calidad, medida a travs de
las valoraciones subjetivas de los participantes del estudio (anlogamente a la Ilustracin 13),
frente al esfuerzo invertido en esa actividad concreta de IS. Los resultados obtenidos indican
que no existe correlacin aparente entre la calidad tcnica del sistema y el esfuerzo invertido
en cada una de las actividades de IS.
3.4 Impacto de la IS en el xito

Los estudios 5, 6, 7 y 8 presentan resultados para el xito de los proyectos. En el estudio 5
del SECOE (Honour, 2004) se calcula el xito de los proyectos de la muestra mediante lo que el
autor denomina calidad del desarrollo. Consisten en una funcin dependiente de los
indicadores coste, tiempo, calidad, y del tamao y complejidad tcnica del sistema. La
hiptesis de partida es que existe un valor ptimo de inversin en IS que maximiza la calidad
del desarrollo, punto por encima del cual seguir invirtiendo en IS es perjudicial para el
proyecto, tal y como se indica en la Ilustracin 14. Por falta de datos el autor realiz una
aproximacin del xito como funcin del coste y del tiempo mediante la inversa de la media
de los ratios del coste y el tiempo (ya definidos en las secciones 3.1 y 3.2) as:
CD = 1 / [(CR/CP + TR/TP)/2] = 2 / [CR/CP + TR/TP], dnde:
CD= Calidad del Desarrollo
CR/CP = Ratio [Coste Real/Coste Planificado]
TR/TP = Ratio [Tiempo Real/Tiempo Planificado]
33
De esta forma, cuando un proyecto cumple en coste y plazo el valor de CD = 1, mientras

que los proyectos que se exceden en coste y plazo tendrn valores de CD < 1.
Ilustracin 14: Hiptesis de partida del estudio del SECOE (Honour, 2004)
Los datos obtenidos al respecto para los primeros 25 proyectos de la muestra se observan
en la Ilustracin 15, donde se representa la calidad del desarrollo (Development Quality) para
dichos proyectos frente al esfuerzo invertido en IS (SE Effort), calculado este de nuevo igual
que en la seccin 3.1, es decir, 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).
Ilustracin 15: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2004)
La curva de regresin muestra que, a medida que aumenta el esfuerzo invertido en IS,
aumenta la calidad del desarrollo hasta llegar a un punto ptimo, en torno al 15% de esfuerzo
invertido en IS, a partir del cual seguir invirtiendo en IS no sigue aumentando la calidad del
desarrollo o xito de los proyectos sino todo lo contrario. En la Ilustracin 16 se muestran ms
resultados del estudio 5 con respecto del indicador xito, pero en esta ocasin medido a travs
de las valoraciones subjetivas de los participantes del estudio, usando una escala de 0 a 10, en
la que 0 indica que el proyecto fracas completamente, 5 indica que el nivel de xito fue
34
similar al de otros proyectos y 10 indica que los resultados del proyecto fueron excepcionales.
Se observa que la tendencia de esta grfica, aunque est basada en opiniones, es muy similar a
la de la grfica de la Ilustracin 15. Finalmente, en la Ilustracin 17, se muestran resultados
publicados para el estudio 6 (Honour, 2006 & 2010), donde la grfica representa los mismos
parmetros de la Ilustracin 16 incorporando los datos de los dos estudios y observndose la
misma tendencia que para los dems indicadores.
Ilustracin 16: xito subjetivo vs Esfuerzo de IS (Honour, 2004)
Ilustracin 17: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2010)
Respecto a la relacin existente entre las 8 actividades de IS de la Tabla 4 y el xito del

proyecto, se compara dicho xito, medido a travs de las valoraciones subjetivas de los
participantes del estudio (anlogamente a la Ilustracin 16), 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 muestra correlacin entre las actividades de IS y el xito del proyecto,
35
con los mismos resultados presentados anteriormente en la Tabla 6 (con los mismos valores
que minimizan los sobrecostes del proyecto y el tiempo de ejecucin).
En el estudio 7, MIT (Ancona & Caldwell, 1990), las observaciones realizadas respecto al
tiempo que los miembros de los equipos de trabajo dedicaban a cada tarea demostraron que
se empleaba una proporcin significativa del tiempo del proyecto (14% de media) en trabajar
fuera de los lmites del equipo de trabajo, es decir, en las relaciones con el resto de equipos y
organizaciones del proyecto, por ejemplo en tareas de coordinacin, planificacin,
negociacin, soporte o estrategia, entre otras. Los resultados de este estudio indican que los
equipos que obtuvieron productos de ms xito, entendido este como el nivel de calidad y
comercializacin del producto, haban invertido ms tiempo en trabajos de gestin de las
relaciones que otros equipos. Dichas tareas son las tpicamente desarrolladas por los
ingenieros de sistemas como aplicacin de la metodologa de IS en las distintas fases del
proyecto, por lo que podemos decir que en los casos bajo estudio se aplicaron de forma parcial
tcnicas de IS, y que esto estadsticamente parece guardar relacin con la obtencin de unos
mejores resultados. Adems, no se encontr correlacin entre el xito de los proyectos y los
procesos internos del equipo, es decir, las capacidades y recursos tcnicos del proyecto.
Los datos obtenidos en el estudio 8, tambin del MIT pero de distinto autor (Miller,
2000), se resumen en la Ilustracin 18, donde se indica el porcentaje de los proyectos que
cumplieron con sus metas u objetivos iniciales. Se observa que a pesar de disponer de las
capacidades tcnicas necesarias, menos de la mitad de los proyectos (45%) alcanzaban
plenamente sus objetivos tcnicos, as como que una proporcin significativa de los mismos no
alcanzaba completamente sus objetivos de presupuesto y plazo (18% y 28% respectivamente).
Adems, los resultados de los proyectos eran mejores en los casos en que la estructura
organizativa estaba mejor desarrollada, aunque las capacidades tcnicas fueran ms
mediocres que en otros casos.
Porcentaje de los proyectos que cumplieron sus objetivos de:
Presupuesto total
82%
18%
Plazo total
72%
Objetivos tcnicos
45%
28%
18%
37%
Cumplimiento total de sus objetivos

Cumplimiento parcial de sus objetivos
No cumplimiento de sus objetivos
Ilustracin 18: Cumplimiento de objetivos (adaptacin de Miller, 2000).
36
La conclusin comn de ambos estudios del MIT es que el disponer de unas capacidades
tcnicas adecuadas, aunque es condicin necesaria para poder llevar a cabo un proyecto, no es
condicin suficiente para garantizar el xito del mismo. El verdadero factor determinante en
este aspecto es una buena gestin del proyecto, que es precisamente lo que se puede
conseguir a travs de la metodologa de IS, es decir, una gestin eficiente.
37
4 CONCLUSIONES
En general, el objetivo de cualquier proyecto de desarrollo de un sistema, sea del tipo que
sea, es cumplir con las necesidades que motivaron la existencia del mismo. Adems, este
objetivo debe conseguirse con resultados ptimos en los indicadores coste del proyecto,
tiempo para llevarlo a cabo, calidad del sistema resultante. En definitiva, se trata de conseguir
el xito del proyecto, entendido este como una combinacin de los 3 indicadores anteriores.
Maximizar el xito en ocasiones es complicado, sobre todo cuando se trata de proyectos
grandes y complejos tcnicamente, donde son muchos los actores y organizaciones
involucrados. La gestin de los recursos disponibles, tanto humanos como materiales, es
fundamental en estos casos, donde las desviaciones respecto de los objetivos y estimaciones
iniciales pueden ser importantes. Adems, muy a menudo, a la complejidad del trabajo tcnico
y las dificultades que conlleva la gestin econmica y organizativa se suman otros factores
relacionados con el cliente/usuario del sistema y el entorno de ejecucin del proyecto. Estos
factores, habitualmente sociales y polticos, pueden ser imprevisibles y por tanto, difcilmente
controlables a priori.
A lo largo de este Trabajo Fin de Mster se ha introducido la metodologa IS como una
herramienta de gestin, potencialmente capaz de aumentar el xito de los proyectos a travs
de un enfoque centrado en el Ciclo de Vida del sistema al completo, de manera que todas las
etapas sean consideradas en los procesos de toma de decisiones. Esto se lleva a cabo mediante
la integracin de diversas disciplinas y especialidades, a travs de un proceso de desarrollo
estructurado que comienza con la deteccin de la necesidad, contina con el diseo,
produccin y puesta en servicio del sistema que intenta satisfacerla, y finaliza con la retirada
del mismo al agotarse su vida til.
Las prcticas de IS prometen sistemas mejores, en menos tiempo, a menor coste y con un
nivel de calidad ms alto. Se ha comentado anteriormente que es en las primeras etapas de un
proyecto en las que la aplicacin de IS tiene mayor potencial de mejorar los indicadores de los
proyectos respecto a otras formas de gestin, centrndose en una correcta definicin del
sistema de forma temprana en el ciclo como medio para mejorar los indicadores del proyecto
y reducir el riesgo tcnico de no cumplimiento de los requisitos.
No cabe duda que cuanto ms se tarda en descubrir y corregir los problemas o
deficiencias de un proyecto, mayor es el impacto negativo en sus indicadores. Por ello en IS se
realiza un mayor esfuerzo de anlisis en dichas etapas, lo que se corresponde tambin con un
mayor nivel de inversin y dedicacin en las mismas. Esto se pone de manifiesto en la
Ilustracin 19 (Honour 2010), en la que se compara el valor intuitivo de la aplicacin de IS
(Systems Thinking Design) frente al enfoque del diseo tradicional (Traditional Design) a lo
largo de las etapas de diseo conceptual y preliminar (System Design), diseo de detalle y
desarrollo (Detail Design), produccin e integracin (Production Integration) y pruebas (Test).
Como puede apreciarse, en el diseo tradicional se concentra un mayor esfuerzo en las etapas
38
de produccin, integracin y pruebas, mientras que en el enfoque de IS se hace ms nfasis en

la definicin inicial del sistema, lo que repercute favorablemente en el resto de etapas,
reducindose el esfuerzo necesario en las mismas. El resultado es un ahorro global en coste y
tiempo para el proyecto completo (Saved Time/Cost).
Ilustracin 19: Valor intuitivo de IS (Honour, 2006)
Por otro lado, en la Ilustracin 20 se muestra la percepcin de que la aplicacin de IS

disminuye el riesgo tcnico frente al enfoque del diseo tradicional, a lo largo de las mismas
etapas de la Ilustracin 19.
Ilustracin 20: Percepcin de la Reduccin del Riesgo con IS (Honour, 2006)
En muchas organizaciones este valor intuitivo o percepcin de mejora del xito de los
proyectos en los que se aplica la metodologa de IS es una afirmacin aceptada an sin
disponer de evidencias especficas respecto a la relacin causa-efecto (IS-mejora),
habitualmente debido a una buena experiencia previa en otros proyectos.
Sin embargo, en otros casos, cuando la organizacin se plantea implementar IS por
primera vez suele tener que justificar de antemano la inversin. Adems del aspecto
econmico, el adoptar procedimientos nuevos que implican cambiar los existentes puede
conllevar la oposicin/reticencia de los sectores ms conservadores de la estructura y del
personal que debe adecuarse a una nueva forma de trabajar.
39
En el captulo 3 de este documento se han mostrado los resultados de la investigacin

realizada para tratar de evidenciar la relacin entre la inversin en IS y la mejora
experimentada en los resultados de los proyectos como consecuencia de estas prcticas, de
forma que se justifique su aplicacin, confirmndose que, efectivamente, existe una
correlacin entre el esfuerzo invertido en esta metodologa y el xito de mismos. Las
conclusiones del documento, objeto de este captulo, reflejan fundamentalmente los
resultados obtenidos en los estudios 5 y 6 (Honour, 2004, 2006 y 2010).
Respecto a los indicadores coste y tiempo, se demuestra que existe una correlacin entre
su valor y el nivel de inversin en IS, relacionndose un nivel alto de dicha magnitud con
importantes reducciones tanto en los costes de los proyectos como en su calendario, llegando
a conseguirse en los proyectos investigados hasta un ahorro medio en coste del 30% y
reducciones del calendario de ms del 50%. Asimismo, se demuestra que existe un punto
ptimo de inversin en IS que minimiza el valor de ambos indicadores y que podra estar entre
el 15% y el 20% del presupuesto total de los proyectos. Una vez sobrepasado dicho punto,
seguir aumentando la inversin en IS no aporta valor adicional, ya que slo supone sobrecoste
y retraso en la finalizacin del proyecto.
En cuanto al indicador calidad de los sistemas resultantes, un alto nivel de inversin en IS
se relaciona con procedimientos que favorecen un buen entendimiento de las necesidades del
cliente. Esto debera trasladarse en una buena definicin de requisitos y con ello el desarrollo
de un sistema cuyas prestaciones cumplan con los objetivos marcados, pudiendo incluso
superarse las expectativas, al aumentar la probabilidad de detectar oportunidades de mejora
de dichas prestaciones, gracias al procedimiento establecido.
Sin embargo, aunque esta relacin entre la inversin en IS y la calidad parece evidente, en
la prctica puede ser que esta no sea la percepcin general del personal involucrado en los
proyectos. Con las evidencias disponibles hasta el momento, no se puede afirmar que exista
una correlacin entre ambas magnitudes. En lo que a lo riesgos tcnicos se refiere, la
impresin generalizada del personal que trabaja con esta metodologa es que la IS reduce el
riesgo en sus proyectos (Kludze, 2004), aunque no se ha establecido una correlacin entre
ambas magnitudes. Esto no quiere decir que dicha relacin no exista, sino que no se dispone
de datos suficientes para sacar conclusiones al respecto.
Respecto al indicador xito, como se ha comentado anteriormente, este depende del
coste del proyecto, tiempo de ejecucin, calidad del sistema o producto desarrollado y riesgo
de que este no cumpla con los requisitos tcnicos. Este sigue la misma tendencia que los
indicadores coste y tiempo, se demuestra que existe una correlacin entre su valor y el nivel
de inversin en IS, relacionndose un nivel alto de dicha magnitud con un alto nivel de xito
hasta un punto ptimo de inversin en IS que maximiza su valor y que podra estar entre el
15% y el 20% del presupuesto total de los proyectos. Una vez sobrepasado dicho punto, seguir
aumentando la inversin en IS perjudica al proyecto.
Los resultados de la investigacin hasta este momento, aunque tiles a nivel general, ya
que demuestran que la metodologa efectivamente aumenta el xito de los proyectos, no son
40
suficientes para discernir que prcticas de IS hay que potenciar o priorizar, es decir, a qu
actividades ha de dedicarse un mayor nivel de esfuerzo/inversin para llegar al nivel ptimo de
dicho indicador. De todos los estudios analizados, el nico que aporta informacin a este
respecto para 8 categoras o actividades concretas de IS es el estudio 6, en el que se
demuestra que existe una correlacin entre la inversin realizada en ellas y los indicadores
coste, tiempo y xito del proyecto, establecindose puntos ptimos de inversin para los
proyectos de ms xito. Dicha correlacin es dbil, por lo que no pueden extraerse
informacin concluyente al respecto para su aplicacin directa a programas de desarrollo de
sistemas especficos.
El estudio 6 se encuentra a da de hoy an en proceso para continuar con esta lnea de
investigacin abierta (y probablemente se mantenga as por mucho tiempo debido a la
cantidad de datos relevantes necesarios y el ritmo al que es posible obtenerlos), cuyo objetivo
es desarrollar lo siguiente:
Una correlacin estadstica entre las categoras o actividades de IS y el xito de los
proyectos, de manera que quede definido cunto hay que invertir en cada una de ellas
y bajo qu condiciones para optimizar los resultados.
Indicadores que sirvan para dirigir el proyecto durante su ejecucin y para conseguir
los objetivos planificados en base a las categoras o actividades de IS utilizadas.
Identificacin de las buenas prcticas de IS adecuadas para conseguir el xito de los
proyectos bajo distintas condiciones.
Como se ha comentado anteriormente, el xito de los proyectos no slo depende de la
gestin econmica y organizativa, sino que existen otros condicionantes que repercuten en los
resultados, habitualmente relacionados con el cliente/usuario del sistema y el entorno de
ejecucin. Estas variaciones se escapan al control de la IS, por lo que el autor del estudio 6 est
desarrollando lo que denomina parmetros de caracterizacin de los proyectos, de manera
que puedan personalizarse las correlaciones mediante factores de correccin para cada
proyecto especfico. En el momento de la publicacin del estudio 6 (Honour, 2006), los
parmetros de caracterizacin consistan en 7 factores cuantitativos tamao del sistema y 7
factores subjetivos, representados a modo de esquema en la Ilustracin 21 y la Ilustracin 22
respectivamente, indicndose para cada uno de ellos tanto su rango de valores (de menor a
mayor, de izquierda a derecha), como su significacin con respecto al resto de parmetros de
su misma categora (de menor a mayor impacto en los resultados del proyecto, de abajo a
arriba). Es de esperar que con el desarrollo de la investigacin estos parmetros evolucionen
tambin.
Los parmetros de caracterizacin fortalecen la correlacin, tal como se muestra a modo
de ejemplo en la Ilustracin 23, en la que se representan la misma informacin que en la
Ilustracin 10, con la salvedad de que el valor del esfuerzo de IS ha sido corregido con los
parmetros desarrollados hasta el momento, aumentando as el factor de correlacin R2 en
ms de un 50%.
41
Ilustracin 21: Factores Cuantitativos (Honour, 2010)
Ilustracin 22: Factores Subjetivos (Honour, 2010)
Ilustracin 23: Correlacin Mejorada del Coste Incurrido/Coste Planificado vs Esfuerzo en IS

(Honour, 2010)
42
A la vista de los resultados comentados anteriormente, puede concluirse que la IS es

ciertamente un factor causal del xito de los proyectos. Una vez demostrada esta evidente
relacin causa-efecto, el reto de la investigacin se centra en intentar cuantificarla de forma
exacta y personalizada para todo proyecto, sean cuales sean las caractersticas y
condicionantes de este, de forma que sea posible ajustar la inversin en IS al valor que
optimiza los resultados de dichos proyectos, maximizando el xito, y conociendo de antemano
el nivel de retorno de dicha inversin.
43
BIBLIOGRAFA
A.J.Albrecht. (1979). Measuring Application Development Productivity. Proceeding IBM

Application Development Symposium. Monterey, California.
Ancona, & Caldwell. (1990). Boundary Management. Research Technology Management.
ANSI, & AIAA. (1992). Guide to the Preparation of Operational Concept Documents, G-0431992.
Barker, B. (2003). Determining Systems Engineering Effectiveness. Conference on Systems
Integration, Stevens Institute of Technology. Hoboken, NJ.
Blanchard, B. S., & Fabricky, W. J. (1998). Systems Engineering and Analysis. Prentice Hall.
Department of Defense, U. (1993). MIL-STD-499B.
Dr. Ave K. Kludze, J. (2004). The Impact of Systems Engineering on Complex Systems.
Paper #152 (based on a doctoral dissertation of the George Washignton University). NASA
Langley Research Center.
Fairley, R. (1985). Software Engineering Concepts. New York: MCGraw-Hill.
Faulconbridge, R. I., & Ryan, M. J. (2005). Engineering a System: Managing Complex
Technical Projects. Canberra, Australia: Argos Press.
Frank, M. (2000). Cognitive and Personality Characteristics of Successful Systems
Engineers. INCOSE Internation Symposium. Seattle.
Frantz, W. F. (1995). The Impact of Systems Engineering on Quality & Shedule - Empirical
Evidence. INCOSE International Symposium. St. Louis.
GDELS. (2012). Engineering Process. Training Course Presentation .
Gruhl, W. (1992). Lessons Learned, Cost/Schedule Assessment Guide. Internal
Presentation, NASA.
Hall, A. D. (1962). A Methodology for Systems Engineering. Van Nostrand .
Halverson, M. (2011). A Brief History of Systems Engineering. INCOSE Presentation. San
Diego.
Honour, E. (2006). A Practical Program of Reasearch to Measure Systems Engineering
Return on Investment. Proceeding of the Sixteenth Annual Symposium of the International
Council on Systems Engineering. Orlando, Florida.
Honour, E. (2001). Optimising the Value of Systems Engineering. Proceeding of the
INCOSE International Symposium. Seattle.
Honour, E. (2010). Systems Engineering Retourn on Investment. Proceeding of the INCOSE
International Symposium. Chicago.
44
Honour, E. (2004). Understanding the Value of Systems Engineering. Proceeding of the

INCOSE International Symposium. Toulouse, France.
Honour, E., & Mar, B. (2002). Value of Systems Engineering - SECOE Research Project
Progress Report. Proceeding of the Incose International Symposium. Las Vegas.
IEEE.Std1220. (2005). Systems engineering. Application and management of the systems
engineering process.
INCOSE. (s.f.). Recuperado el Juio, 2012, de www.incose.com
Kossiakof, A., & Sweet, W. (2003). Systems Engineering Principles and Practices. NY: Wiley
& Sons.
Miller, R. (2000). The Strategic Management of Large Engineering Projects. MIT Press.
MIL-STD-2155. (Julio, 1985). FAILURE REPORTING, ANALYSIS AND CORRECTIVE ACTION
SYSTEM (FRACAS).
Ministerio de Defensa de Espaa. (s.f.). Recuperado el Octubre de 2012, de
www.defensa.gob.es
Project Management Institute. (1996). A Guide to the Project Management Body of
Knowledge.
RAE. (23 Edicin, 2012). Dicccionario de la Lengua Espaola.
Rhodes, D., & Hastings, D. (March 2004). MIT Engineering Systems Symposium. The Case
of Evolving Systems Engineering as a Field within Engineering Systems.
Scribd. (Agosto de 2012). Obtenido de http://www.scribd.com/doc/21229743/METODOSEMPIRICOS
Valerdi, R., & Davidz, H. L. (2007). Empirical Research in Systems Engineering: Challenges
and Opportunities of a New Frontier. PROCEEDINGS CSER 2007. Hoboken, NJ, USA.
Von Bertalanffy, L. (1976). Teora General de Sistemas. Petrpolis, Vozes.
Wikipedia. (s.f.). Recuperado el 2012, de www.wikipedia.com
45
6 ACRONISMOS Y ABREVIATURAS
1
IS: Ingeniera de Sistemas
INCOSE: International Council On Systems Engineering
MIL-STD-499B: Military Standard 499B
T&E: Test & Evaluation
ANSI: American National Standards Institute
AIAA: American Institute of Aeronautics and Astronautics
TPM: Technical Performance Measures
CI: Configuration Item
COTS: Commercials-Off-the-Shelf
10
MOTS: Military-Off-the-Shelf
11
FRACAS: Failure Reporting Analysis and Corrective Action System
12
MIT: Massachusetts Institute of Technology
46

Sistema de Control

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sistema de Control

Загружено:

Авторское право:

Доступные форматы

GESTIN DE

ESCUELA TCNICA SUPERIOR DE INGENIERA

Historia de la Ingeniera de Sistemas ..............................................................1

Algunas Definiciones de Ingeniera de Sistemas ..............................................3

METODOLOGA DE INGENIERA DE SISTEMAS ........................................................5

Fase de Adquisicin .......................................................................................8

Diseo Conceptual .................................................................................8

Diseo Preliminar ................................................................................. 12

Diseo de Detalle y Desarrollo .............................................................. 14

Fase de Uso ................................................................................................. 17

Actividades de Test en el Ciclo de Vida ......................................................... 18

INVESTIGACIN DEL IMPACTO DE LA IS EN LOS PROYECTOS................................. 20

Impacto de la IS en los Costes ...................................................................... 24

Impacto de la IS en el Tiempo ...................................................................... 29

Impacto de la IS en la Calidad ....................................................................... 31

Impacto de la IS en el xito .......................................................................... 33

ACRONISMOS Y ABREVIATURAS .......................................................................... 46

TRABAJO FIN DE MSTER

1.1 Historia de la Ingeniera de Sistemas

TRABAJO FIN DE MSTER

desarrollo de la American Telephone & Telegraph en aquel entonces, debido a la acuciante

TRABAJO FIN DE MSTER

Qu tiene que hacer? (funcionalidad)

Cmo de bien tiene que hacerlo? (rendimiento)

Bajo qu condiciones tiene que operar? (entorno)

Sistemas externos implicados en su operacin? (interfaces)

Cmo se desglosa? (subsistemas y componentes)

Cmo vamos a dimensionarlo? (diseo)

Cmo vamos a fabricarlo? (procesos de fabricacin)

Cmo vamos a integrarlo? (ensamblaje y pruebas)

Esto es el Dominio Solucin, a cargo del contratista principal, es decir, de la entidad

1.3 Algunas Definiciones de Ingeniera de Sistemas

TRABAJO FIN DE MSTER

Segn la norma militar estadounidense MIL-STD-499B3 (Department of Defense, 1993) la

TRABAJO FIN DE MSTER

2 METODOLOGA DE INGENIERA DE SISTEMAS

Diseo de Detalle y Desarrollo

Construccin y/o Produccin

Ilustracin 1: Esquema del Ciclo de Vida de un Sistema

TRABAJO FIN DE MSTER

Ilustracin 2: Proceso de Anlisis, Sntesis y Evaluacin.

TRABAJO FIN DE MSTER

Reduccin significativa de los riesgos tcnicos asociados al desarrollo del producto.

Linea Base Distribuida

Linea Base de Producto

TRABAJO FIN DE MSTER

Ilustracin 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012)

2.1 Fase de Adquisicin

El Diseo Conceptual es un esfuerzo inicial de la IS centrado en conseguir un paquete de

TRABAJO FIN DE MSTER

asegurndose as que en la especificacin no haya nada que no haya sido formalmente

TRABAJO FIN DE MSTER

TRABAJO FIN DE MSTER

Documento de Requisitos de Sistema y que establece las consideraciones adicionales que

TRABAJO FIN DE MSTER

TRABAJO FIN DE MSTER

Tren de Alas & Sistema de Sistema Mandos

Tabla 1: Matriz de Trazabilidad - Ejemplo avin de pasajeros

A partir de dicha matriz y del documento de Declaracin de los Trabajos definido en el

TRABAJO FIN DE MSTER

etc.), elaborndose habitualmente un Documento de Control de Interfaces para cada

Diseo de Detalle y Desarrollo

El Diseo de Detalle y Desarrollo contina el esfuerzo de IS desde los resultados de las