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