Beruflich Dokumente
Kultur Dokumente
SISTEMAS COMPLEJOS
MEDIANTE
INGENIERIA DE SISTEMAS
ndice de Contenido
INTRODUCCIN ....................................................................................................1
1.1
1.2
Qu es un Sistema? ......................................................................................2
1.3
2.1.1
2.1.2
2.1.3
2.1.4
Construccin/Produccin ..................................................................... 16
2.2
2.3
3.2
3.3
3.4
CONCLUSIONES................................................................................................... 38
BIBLIOGRAFA ..................................................................................................... 44
ndice de Ilustraciones
Ilustracin 1: Esquema del Ciclo de Vida de un Sistema.........................................................5
Ilustracin 2: Proceso de Anlisis, Sntesis y Evaluacin. .......................................................6
Ilustracin 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema .............................7
Ilustracin 4: Impacto de la IS en el ciclo de vida de un sistema (GDELS, 2012).......................8
Ilustracin 5: Esquema de un Sistema FRACAS .................................................................... 17
Ilustracin 6: Sobrecoste vs Inversin en la Definicin del Sistema (Gruhl, 1992) ................. 25
Ilustracin 7: Diferencia Esfuerzo de Desarrollo - Esfuerzo en IS (Gruhl, 1992) ..................... 25
Ilustracin 8: Presupuesto invertido en IS (Dr. Ave K. Kludze, 2004) .................................... 26
Ilustracin 9: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2004) ................ 27
Ilustracin 10: Coste Incurrido/Coste Planificado vs Esfuerzo en IS (Honour, 2010) .............. 28
Ilustracin 11: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2004) ............... 30
Ilustracin 12: Tiempo Real/Tiempo Planificado vs Esfuerzo en IS (Honour, 2010) ............... 31
Ilustracin 13: Calidad Tcnica vs Esfuerzo de IS (Honour, 2010) ......................................... 33
Ilustracin 14: Hiptesis de partida del estudio del SECOE (Honour, 2004) .......................... 34
Ilustracin 15: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2004) ............................... 34
Ilustracin 16: xito subjetivo vs Esfuerzo de IS (Honour, 2004) .......................................... 35
Ilustracin 17: Calidad del Desarrollo vs Esfuerzo de IS (Honour, 2010) ............................... 35
Ilustracin 18: Cumplimiento de objetivos (adaptacin de Miller, 2000). ............................. 36
Ilustracin 19: Valor intuitivo de IS (Honour, 2006) ............................................................. 39
Ilustracin 20: Percepcin de la Reduccin del Riesgo con IS (Honour, 2006) ....................... 39
Ilustracin 21: Factores Cuantitativos (Honour, 2010) ......................................................... 42
Ilustracin 22: Factores Subjetivos (Honour, 2010) ............................................................. 42
Ilustracin 23: Correlacin Mejorada del Coste Incurrido/Coste Planificado vs Esfuerzo en IS
(Honour, 2010) ........................................................................................................... 42
ndice de Tablas
Tabla 1: Matriz de Trazabilidad - Ejemplo avin de pasajeros ........................................... 13
Tabla 2: Informacin relevante de cada estudio analizado .................................................. 21
Tabla 3: Grados de IS del estudio de Boeing (adaptacin de Frantz, 1995) ........................... 22
Tabla 4: Actividades de IS analizadas en estudio 6 (adaptacin de Honour, 2010) ................ 23
Tabla 5: Indicadores investigados por cada estudio analizado ............................................. 24
Tabla 6: Inversin ptima en IS del estudio 6 (adaptacin de Honour, 2010)........................ 28
Tabla 7: Datos de tiempos del estudio de Boeing (adaptacin de Frantz, 1995) .................... 29
Tabla 8: Datos de calidad del Estudio de Boeing (adaptacin de Frantz, 1995) ..................... 32
1 INTRODUCCIN
El objetivo de este Trabajo Fin de Mster es reflejar las ventajas de la metodologa de
Ingeniera de Sistemas (en adelante IS1) en la gestin de proyectos de gran envergadura. Para
ello se ha realizado una revisin de la literatura sobre la aplicacin de IS en proyectos reales,
recopilando informacin de distintas fuentes y extrayendo posteriormente conclusiones de los
resultados obtenidos al aplicar dicho mtodo en organizaciones conocidas y pertenecientes a
distintos sectores o unidades de negocio.
El documento se compone de cuatro captulos:
En este primer captulo se realiza una introduccin a la IS, empezando por una breve
resea histrica. A continuacin se explica el concepto de Sistema utilizado a lo largo de todo
el documento, seguido de algunas definiciones de la metodologa provenientes de distintas
fuentes.
El segundo captulo describe la metodologa de IS a travs del Ciclo de Vida del Sistema,
que como se ver ms adelante, se divide en dos fases. La primera es la fase de adquisicin,
compuesta por las etapas de diseo conceptual, diseo preliminar, diseo de detalle y
desarrollo y la etapa produccin. La segunda fase es la de utilizacin del sistema, coincidente
con la etapa de uso operacional y mantenimiento del mismo.
El tercer captulo incluye el anlisis de ocho estudios llevados a cabo por diferentes
entidades/autores para determinar el impacto de la aplicacin de IS en diferentes programas.
El anlisis se realiza a travs de lo que se considera como los 4 indicadores principales de los
resultados de un proyecto: coste, tiempo, calidad y xito.
Finalmente, el ltimo captulo recoge las conclusiones derivadas de todo lo expuesto
anteriormente.
1.2 Qu es un Sistema?
Un Sistema es un conjunto complejo de partes sujetas a un plan o propsito comn. En el
sentido ms amplio de la palabra, es algo que proporciona una solucin a un problema
complejo (Faulconbridge & Ryan, 2005). Por ejemplo, el desarrollo y fabricacin de un nuevo
modelo de avin, de un carro de combate o la construccin de una central nuclear.
Existen dos formas de describir un Sistema:
En trminos funcionales, refirindonos al problema que resuelve:
o
Esto es el Dominio Problema y est a cargo del cliente, es decir, de la entidad que ha
detectado la insuficiencia que necesita gestionar.
En trminos fsicos, refirindonos a cmo se ha diseado:
o
Diseo Conceptual
Diseo Preliminar
Fase de Utilizacin: Comienza con la puesta en servicio del sistema y concluye con la
retirada del mismo. Coincide con la etapa de uso operacional del sistema y el
soporte/mantenimiento del mismo.
La lnea entre la fase de adquisicin y la fase de uso es clara y nos permite analizar la
aplicacin de IS en ambas fases por separado a travs de un proceso cclico de Anlisis,
Sntesis y Evaluacin como el de la Ilustracin 2, recurrente en todas sus etapas. Como parte
de la funcin de evaluacin, debe realizarse una revisin de cada una de ellas tras su
finalizacin.
ANLISIS
EVALUACIN
SNTESIS
A lo largo de ambas fases, se llevan a cabo actividades de Test y Evaluacin (T&E4) que
involucran tanto al cliente como al contratista (principal y secundarios), de manera que el
sistema es chequeado de forma continua a lo largo de todo su ciclo de vida, lo que asegura
progresivamente que este es desarrollado conforme a los requisitos de cliente. Las fases de
adquisicin y de uso, todas sus etapas y las actividades de T&E sern explicadas en detalle en
las secciones 2.1, 2.2 y 2.3 (Faulconbridge & Ryan, 2005). Para mayor claridad, en la Ilustracin
3 se muestra un esquema del proceso.
Obviamente no existe una nica solucin vlida para todos los proyectos, por lo que la
aplicacin de esta metodologa a distintos sistemas puede requerir de cierto grado de
personalizacin del procedimiento para adaptarlo a las caractersticas individuales de cada
caso.
En las primeras etapas de un proyecto es dnde la IS tiene mayor potencial, ya que
aproximadamente el 75% del coste del proyecto queda determinado en las etapas iniciales de
diseo del ciclo de vida, lo que se pone de manifiesto en la Ilustracin 4. Cuanto ms se tarde
en descubrir y corregir los problemas mayor ser el impacto negativo en el proyecto, por ello
el mayor esfuerzo o inversin de anlisis debe realizarse en estas primeras etapas.
La implementacin exitosa de los procedimientos y mtodos de IS en un proyecto tiene
mltiples beneficios a lo largo del Ciclo de Vida de un sistema, entre los que podemos destacar
los siguientes:
Ahorro econmico durante toda la vida del sistema.
Aunque implementar la IS supone un coste adicional en el proyecto, sobre todo en las
actividades tempranas del diseo y desarrollo, si el procedimiento es aplicado
correctamente el ahorro resultante a lo largo de todo el Ciclo de Vida compensa
sobradamente esta inversin inicial en recursos e infraestructura.
Reduccin del calendario global hasta la puesta en servicio del sistema.
La IS se encarga de que los requisitos de usuario se reflejen fielmente en el diseo del
sistema, minimizando el coste, en dinero y en retraso del proyecto, de cambios en los
requisitos en etapas posteriores del ciclo de vida. Si fuera necesario hacer cambios en el
diseo estos se detectaran en etapas tempranas. Debido a su riguroso procedimiento, la
IS permite alcanzar un nivel de madurez del diseo elevado mucho antes.
FASE DE ADQUISICIN
Linea Base Funcional
Diseo
conceptual
Identificacin
de requisitos
Anlisis de
viabilidad
Anlisis de
requisitos del
sistema
Sntesis a
nivel de
sistema
Revisin del
diseo del
sistema
Sntesis a
nivel de
subsistema
Revisiones del
diseo
preliminar
Diseo
preliminar
T
&
E
Anlisis de
requisitos de
subsistemas
Distribucin
de los
requisitos
Identificacin
/ diseo de
interfaces
Diseo de
detalle y
desarrollo
Diseo de detalle
de subsistemas y
componentes
Integracin de
subsistemas y
componentes
Desarrollo de
prototipos
Revisiones del
diseo de detalle
Construccin/ Produccin
FASE DE USO
Utilizacin del sistema
Posibles modificaciones
Mantenimiento del sistema
Ilustracin 3: Fases, Etapas y Actividades del Ciclo de Vida de un Sistema
Diseo Conceptual
requisitos Fsicos el tamao, volumen, masa, forma, materiales, etc.; los requisitos de
Funcionamiento las funciones, modos de operacin, caractersticas hardware y software,
etc.
Una vez que las funciones han sido identificadas, es necesario definir los requisitos de
prestaciones del sistema o parmetros de comportamiento de cada uno de los distintos
requisitos funcionales. Es decir, una vez que se ha determinado qu debe hacer el
sistema, ahora debe definirse cmo de bien debe hacerlo. Por ejemplo, para la
temperatura definir el rango tolerado, para la masa el peso mximo, y para las funciones
las horas de operacin cada da y los das de operacin cada ao.
A continuacin, la definicin de requisitos funcionales y de prestaciones se completa con
la definicin de los requisitos de verificacin, que determinan cmo se va a testear el
sistema. Es decir, una vez que se ha determinado qu debe hacer el sistema y cmo debe
hacerlo, ahora debe definirse cmo va comprobarse. En ocasiones el cliente impone sus
propios mtodos de comprobacin en el contrato.
Los requisitos establecidos por el cliente suelen ser de alto nivel, es decir, se centran en
las necesidades a nivel de sistema y suelen ser ms cualitativos que cuantitativos. Es por
esto que es necesario identificar tambin, mediante un anlisis funcional, los llamados
requisitos derivados, es decir, los requisitos que no son establecidos directamente por el
cliente sino que son el resultado de que estos fluyan desde los niveles superiores aguas
abajo. Un ejemplo sencillo de esto sera un requisito en el que nos indicasen que el
sistema avin de pasajeros, que tenemos que disear y construir, debe proporcionar
confort de primera clase. Los requisitos derivados seran, entre otros, establecer el
espacio mnimo para poder estirar las piernas, las dimensiones de los asientos, los
sistemas de entretenimiento a bordo, los baos disponibles y el servicio de catering. Para
cada uno de los requisitos comentados anteriormente, es preciso detallar por qu son
necesarios y en qu nos basamos para ello, de forma que se deje registro del histrico del
fundamento de nuestras decisiones.
La validacin de requisitos del Diseo Conceptual no se realiza de golpe sino de forma
progresiva por lotes, clasificndolos conforme a un nivel de prioridad (requisitos
mandatorios, importantes y deseables) y definiendo las Medidas de las Prestaciones
Tcnicas (Technical Performance Measures, TPM7), es decir, el margen dentro del cual su
valor puede ser considerado como aceptable. Este concepto no es nuevo y se asemeja a
las tcnicas de gestin de proyectos para el seguimiento de costes y de la planificacin
(IEEE.Std1220, 2005).
Una vez identificados, validados y clasificados todos los requisitos se desarrolla el
borrador de la Especificacin Funcional del Sistema (que constituir la Lnea Base
Funcional).
Otro documento resultante de esta etapa es la Declaracin de los Trabajos, documento
contractual que limita el alcance de los trabajos a realizar de forma conjunta con el
10
11
2.1.2
Diseo Preliminar
Tras establecer el Diseo Conceptual, la siguiente etapa del ciclo es el Diseo Preliminar.
En esta etapa, el equipo de trabajo puede ser distinto del equipo que elabor el Diseo
Conceptual, ya que aqu el papel del cliente cambia, evitando involucrarse en las decisiones. La
responsabilidad del resultado recae, por contrato, en el contratista principal.
El punto de partida es la Lnea Base Funcional, configuracin fsica inicial establecida en el
Diseo Conceptual. El objetivo es establecer una Lnea Base Distribuida, dnde los requisitos
funcionales a nivel de sistema son agrupados de forma lgica en los distintos subsistemas que
lo componen. El proceso sera el siguiente:
Anlisis de requisitos de subsistemas:
A partir de la Especificacin de Sistema y las TPMs obtenidas en el Diseo Conceptual, se
sigue un proceso parecido al anlisis de requisitos de sistema, explicado anteriormente,
pero ahora a nivel de subsistema, identificando anlogamente los requisitos funcionales,
de prestaciones de verificacin y requisitos derivados, dejando registro de la justificacin
de las decisiones.
Distribucin de los requisitos:
Es el proceso de agrupar o combinar los requisitos en subdivisiones lgicas que
representen una arquitectura fsica preliminar de los subsistemas, basada en la
configuracin fsica del sistema que ya se estableci en el Diseo Conceptual.
Para ello primero deben determinarse los subsistemas y/o componentes mayores, a cada
uno de los que denominaremos Elemento de Configuracin o Configuration Item (CI8), el
cual ser gestionado de forma individual en el Diseo Preliminar y seleccionado en base a
la complejidad, criticidad, riesgo y coste asociados a su diseo, as como al desarrollo y
suministro y elementos en comn con otros subsistemas.
Continuando con el ejemplo de sistema avin de pasajeros, comentado anteriormente,
una arquitectura fsica preliminar tpica podra estara desglosada en los siguientes
subsistemas o CIs: Tren de Aterrizaje, Alas & Fuselaje, Sistema de Combustible, Sistema
Hidrulico, Mandos de Vuelo, Motor, Avinica e Interior.
Una vez definidos los CIs, los requisitos deben ser distribuidos de forma que se relacionen
los requisitos funcionales con la estructura fsica de los CIs, habitualmente a travs de una
Matriz de Trazabilidad o de Distribucin, en la que la Estructura de Desglose de
Requisitos se muestra en el lateral izquierdo de la matriz, en vertical, y la estructura de
Elementos de Configuracin se muestra en el extremo superior de la matriz, en
horizontal. Para el sistema avin de pasajeros se incluye un ejemplo de la matriz en la
Tabla 1.
12
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
13
14
15
Construccin/Produccin
16
diseo como cambios en los requisitos. Habitualmente, estas modificaciones deben ser
aprobadas por el cliente.
CIERRE DE LA
INCIDENCIA
DETECCIN DEL
FALLO O INCIDENCIA
ACCESO
USUARIOS
IMPLEMENTACIN DE
LAS ACCIONES
APERTURA EN EL
SISTEMA
SI
SOLUCION OPTIMA?
NO
RECOLECCION
DE DATOS
BD FRACAS
EVALUACIN DE LAS
PROPUESTAS
ANALISIS DE CAUSAS
DEL PROBLEMA
PROPUESTAS DE ACCIONES
(SOBRE EL PRODUCTO,
PROCESO, ETC.)
17
18
que asegura no slo que hemos construido un sistema correctamente sino que hemos
construido el sistema correcto.
Hay 3 categoras principales en las actividades de T&E:
T&E de Desarrollo, actividades llevadas a cabo durante la Fase de Adquisicin.
T&E de Aceptacin, actividades llevadas a cabo para la aceptacin formal del sistema
por parte del cliente. Es el lmite entre la Fase de Adquisicin y la Fase de Uso.
T&E Operacional, actividades llevadas a cabo durante la Fase de Uso tras la
aceptacin formal del sistema por el cliente. Realizada por el personal de operacin y
bajo condiciones realistas.
El Plan Maestro de T&E es un documento requerido por contrato, preparado por el
contratista y aprobado por el cliente. Dicho plan debe describir el sistema e incluir un
programa detallado para las distintas actividades de T&E a desarrollar en cada etapa del
proyecto, dnde se especifiquen las responsabilidades de cada parte de la organizacin
involucrada en las mismas, as como los recursos necesarios para llevarlas a cabo (personal,
equipamiento, materiales, repuestos, simuladores, modelos, etc.) y la planificacin de estos en
el tiempo. El resto de documentos relevantes para el plan de T&E deben ser incluidos al menos
como apndices, como por ejemplo los procedimientos a utilizar.
19
20
Ref.
Entidad
Gruhl, 1992
NASA
Barker, 2003
IBM
Fecha/
Dcada
Tamao
Muestra
Finales de
los aos 80
32 proyectos
estudiados
Grandes proyectos de
la NASA desarrollados
entre los aos 70 y 80
Etapas de
definicin
8 proyectos
estudiados
Proyectos de
desarrollos Software
de IBM
Fase de
adquisicin
Principios
del siglo XXI
(en torno al
2000)
Principios
379
Kludze, 2004 NASA/INCOSE del siglo XXI participantes
(en torno al en la encuesta
2000)
3 proyectos
estudiados
Frantz, 1995
BOEING
Aos 90
Honour, 2004
SECOE
2001
2004 a
Actualidad
Ancona, 1990
MIT
Finales de
los aos 80
45 proyectos
estudiados
Miller, 2000
MIT
Finales de
los aos 90
60 proyectos
estudiados
Tipo/s de Proyecto/s
Parte de la IS
Aplicada
Todas
Sistemas de sujecin
de grandes partes de
aviones durante su
fabricacin
44 proyectos
estudiados
48 proyectos
estudiados
hasta 2010
Fase de
adquisicin
Todas
Todas
Proyectos de
desarrollo de
productos
tecnolgicos
Grandes proyectos
desarrollados entre
los aos 80 y 90
Todas
Todas
El estudio 4, realizado en los aos 90, fue realizado por la empresa aeronutica Boeing.
En l se llev a cabo un anlisis del impacto de la implementacin de la metodologa de IS en el
tiempo y la calidad para tres proyectos de sistemas similares que iban a producirse de forma
simultnea (Frantz, 1995). Los proyectos consistan en el desarrollo y fabricacin de sistemas
de sujecin de grandes partes de aviones durante su proceso de produccin, todos ellos de
coste, caractersticas y prestaciones anlogas a priori. La nica diferencia significativa entre los
tres proyectos era el grado de implementacin de IS a lo largo de la fase de adquisicin de los
proyectos, el cual variaba desde prcticamente nulo en uno de ellos hasta un grado medio y
alto respectivamente en los otros dos. En estos ltimos se aplic IS a lo largo de toda la fase de
adquisicin de los mismos, es decir, tanto durante las etapas de diseo y desarrollo como
durante la etapa de fabricacin y pruebas. La diferencia entre los distintos grados de
implementacin de IS en cada proyecto del estudio 4 se puede apreciar en la Tabla 3, en la que
se especifica cmo se llevaron a cabo ciertas actividades concretas del desarrollo de los
proyectos en las que los procedimientos del diseo tradicional difieren completamente de los
de IS, como pueden ser, por ejemplo, la gestin de requisitos o el enfoque de las pruebas.
21
Grado medio
Grado alto
Bajo
Bajo a Medio
Revisiones peridicas de
diseo
Bajo acceso
Requisitos simblicos
Enfoque de diseo
Adherencia a la
especificacin funcional
Revisiones de diseo
Enfoque para las pruebas
de integracin
Enfoque para las pruebas
de aceptacin
Se siguen las
especificaciones a lo largo
No se siguen las especificaciones durante el desarrollo y
del desarrollo y
fabricacin. Estas son actualizadas por requerimiento
fabricacin. Estas son
del diseo
actualizadas a medida que
el diseo madura
Revisiones formales
Revisiones formales
Revisiones semanales por
internas. Atencin
internas. Poca atencin a
equipos
moderada a los inputs
los inputs externos
externos
Definidas temprano en el ciclo de vida y dirigidas por la
Definidas tras el diseo
especificacin funcional
Tests basados en los criterios de aceptacin de la
Tests definidos en el plan
especificacin de requisitos y en la especificacin
general de pruebas
funcional
22
de la correlacin existente entre los 4 indicadores del proyecto (coste, tiempo, calidad y xito)
para las 8 categoras o actividades concretas de IS que se indican en la Tabla 4.
DESCRIPCIN
MD
RE Ingeniera de Requisitos
ACTIVIDAD DE IS
SI
Implementacin del
Sistema
TA Anlisis Tcnico
TM
Gestin
Tcnica/Direccin
23
ESTUDIOS
1
2
3
4
5
6
7
8
COSTE
X
X
X
INDICADORES
TIEMPO CALIDAD
X
X
X
X
X
X
XITO
X
X
X
X
X
X
X
24
25
distintos. El mtodo de los puntos funcin fue definido por Allan Albrecht, de IBM, para valorar
el tamao de proyectos de desarrollo de software, midiendo a travs de dichos puntos la
funcionalidad puesta al servicio del usuario del sistema, independientemente de la tecnologa
utilizada para ello (A.J.Albrecht, 1979). Este mtodo representa hoy da una mtrica habitual
en muchas empresas de desarrollo software. Los resultados de este estudio indican que el uso
de procesos de IS mejoran la productividad de los proyectos en combinacin con una
adecuada gestin de proyectos y procesos de test, ya que las mtricas indicaban que el ahorro
medio en el coste de los proyectos en los que se invirti en IS fue de un 30% respecto a
aquellos en los que no se aplic esta metodologa.
Los resultados en cuanto a coste del estudio 3, encuesta de la NASA y el INCOSE (Kludze,
2004), se muestran en la Ilustracin 8, donde se observa el porcentaje de participantes frente
al porcentaje del presupuesto total de sus proyectos ms recientes invertido en tareas de IS.
26
Por otro lado, en la Ilustracin 9 se muestran los resultados del estudio 5 del SECOE
(Honour, 2004) para los primeros 25 proyectos de la muestra, representndose el ratio entre
el coste real o incurrido para los proyectos de la muestra (Actual Cost) y el coste planificado
para los mismos (Planned Cost), medido hasta la entrega del primer artculo sin incluir los
costes de produccin, frente al esfuerzo invertido en IS (SE Effort) a lo largo de todo el ciclo de
vida, calculado este esfuerzo como el producto entre la calidad de la IS aplicada (SE Quality) y
el ratio entre el coste invertido en IS (SE Cost) y el coste real o incurrido (Actual Cost).
27
PTIMO
1%
2.5%
2.5%
3%
4%
4%
1%
7%
28
Sistema 2
Sistema 3
Medio
Alto
25
10
10
52
30
20
104
48
36
Baja
Alta
Alta
Grado de implementacin de IS
29
Los datos obtenidos para los primeros 25 proyectos del estudio 5 del SECOE (Honour,
2004) respecto al indicador tiempo se muestran en la Ilustracin 11, representndose el ratio
entre el tiempo real invertido en los proyectos de la muestra (Actual Schedule), medido hasta
la entrega del primer artculo, y el tiempo planificado para los mismos (Planned Schedule)
frente al esfuerzo invertido en IS (SE Effort), calculado como el producto entre la calidad de la
IS aplicada (SE Quality) y el ratio entre el coste invertido en IS (SE Cost) y el coste total
incurrido (Actual Cost), medido hasta la entrega del primer artculo.
A partir de la curva de regresin por mnimos cuadrados, se observa que, a medida que
aumenta el esfuerzo invertido en IS, disminuye la desviacin del tiempo real invertido respecto
al tiempo planificado hasta llegar a un punto ptimo, en torno al 15% de esfuerzo invertido en
IS, a partir del cual seguir invirtiendo en IS no aporta beneficio en tiempo a los proyectos.
En la Ilustracin 12, se muestran resultados publicados para el estudio 6 (Honour, 2006 &
2010) posterior. Esta grfica representa los mismos parmetros y mantiene los mismos datos
que la Ilustracin 11 (puntos rojos) junto a los datos nuevos datos (puntos azules). Igual que
para los costes, se reafirman los resultados obtenidos anteriormente en el estudio 5, es decir,
claramente existe un punto ptimo que minimiza la duracin del proyecto para un 15% de
esfuerzo invertido en IS, a partir del cual aumentar la inversin slo supone alargar el dicha
duracin de forma innecesaria.
30
31
Por otro lado, en el estudio 3 tambin se indicaban datos de no calidad, denominada por
el autor como riesgo y definido este como la probabilidad y consecuencias asociadas con el no
cumplimiento de los requisitos del sistema. Los nicos datos obtenidos a este respecto
mediante la encuesta realizada indican que la mayora de los participantes de sta (91% de la
NASA y 94% del INCOSE) afirmaban que la IS reduce el riesgo en los proyectos.
Los datos obtenidos en el estudio 4 de Boeing para el indicador calidad se resumen en la
Tabla 8 (Frantz, 1995), en la que se observa que en el proyecto con un grado de
implementacin de IS bajo (casi nulo) el resultado fue un nivel de calidad tambin bajo (calidad
relativa, por comparacin con los otros proyectos) ya que slo se cumplieron los requisitos de
fabricacin, mientras que en los proyectos con un grado medio y alto de IS se detectaron
oportunidades de mejora con un incremento de coste mnimo, gracias a las sesiones de trabajo
intensivas, que permitieron implementar algunas funcionalidades adicionales a los sistemas e
incrementando el grado de complejidad de los mismos. Un ejemplo de estas prestaciones
adicionales era la capacidad de detectar cierto grado de deformacin en las estructuras
sujetadas, as como de analizar si esto producira algn tipo de interferencia en la mquina de
control numrico durante el procesamiento de la pieza, en cuyo caso se produca la
rectificacin de la programacin en tiempo real.
Sistema 1
Bajo (casi nulo)
Bajo (solo se
Grado de cumplimiento de los
cumplieron los
requisitos del cliente
requisitos de
fabricacin)
Complejidad relativa de los sistemas
Baja
Grado de implementacin de IS
Sistema 2
Medio
Sistema 3
Alto
Alta
Los datos obtenidos para el estudio 6 (Honour, 2006 & 2010) se muestran en la
Ilustracin 13, representndose la calidad del sistema (Technical Quality) frente al esfuerzo
invertido en IS (SE Effort), calculado como el producto entre la calidad de la IS (SE Quality) y el
ratio entre el coste invertido en IS (SE Cost) y el coste total incurrido (Actual Cost), medido este
hasta la entrega del primer artculo. La calidad fue medida mediante la cuantificacin del nivel
de cumplimiento del sistema con los parmetros clave de prestaciones definidos para el
mismo (KPPs = Key Performance Parametres) a travs de la opinin subjetiva del personal
entrevistado. La escala utilizada va de 0 a 2.0, en la que 0 indica que no se cumplieron ninguno
de los parmetros clave, 1.0 indica que el nivel de cumplimiento est en el umbral de lo
aceptable y 2.0 que este es excelente. Para cada parmetro clave se cuantific su valor de esta
forma, calculndose posteriormente la media de todos los valores. En la Ilustracin 13 se traza
la recta de aproximacin de los datos anteriores. Como puede observarse, los resultados
obtenidos indican que no existe correlacin aparente entre la calidad tcnica del sistema y el
esfuerzo invertido en IS para los proyectos de la muestra, lo que indica que en dichos
32
proyectos los esfuerzos se concentraron principalmente en cubrir los objetivos mnimos para
conseguir la aceptacin del sistema por parte del cliente.
Al igual que para los indicadores anteriores, este estudio tambin proporciona
informacin respecto a la relacin existente entre las 8 actividades de IS de la Tabla 4 y la
calidad tcnica del proyecto. Para cada una de ellas compara dicha calidad, medida a travs de
las valoraciones subjetivas de los participantes del estudio (anlogamente a la Ilustracin 13),
frente al esfuerzo invertido en esa actividad concreta de IS. Los resultados obtenidos indican
que no existe correlacin aparente entre la calidad tcnica del sistema y el esfuerzo invertido
en cada una de las actividades de IS.
33
Ilustracin 14: Hiptesis de partida del estudio del SECOE (Honour, 2004)
Los datos obtenidos al respecto para los primeros 25 proyectos de la muestra se observan
en la Ilustracin 15, donde se representa la calidad del desarrollo (Development Quality) para
dichos proyectos frente al esfuerzo invertido en IS (SE Effort), calculado este de nuevo igual
que en la seccin 3.1, es decir, como el producto entre la calidad de la IS aplicada (SE Quality) y
el ratio entre el coste invertido en IS (SE Cost) y el coste real o incurrido (Actual Cost).
La curva de regresin muestra que, a medida que aumenta el esfuerzo invertido en IS,
aumenta la calidad del desarrollo hasta llegar a un punto ptimo, en torno al 15% de esfuerzo
invertido en IS, a partir del cual seguir invirtiendo en IS no sigue aumentando la calidad del
desarrollo o xito de los proyectos sino todo lo contrario. En la Ilustracin 16 se muestran ms
resultados del estudio 5 con respecto del indicador xito, pero en esta ocasin medido a travs
de las valoraciones subjetivas de los participantes del estudio, usando una escala de 0 a 10, en
la que 0 indica que el proyecto fracas completamente, 5 indica que el nivel de xito fue
34
similar al de otros proyectos y 10 indica que los resultados del proyecto fueron excepcionales.
Se observa que la tendencia de esta grfica, aunque est basada en opiniones, es muy similar a
la de la grfica de la Ilustracin 15. Finalmente, en la Ilustracin 17, se muestran resultados
publicados para el estudio 6 (Honour, 2006 & 2010), donde la grfica representa los mismos
parmetros de la Ilustracin 16 incorporando los datos de los dos estudios y observndose la
misma tendencia que para los dems indicadores.
35
con los mismos resultados presentados anteriormente en la Tabla 6 (con los mismos valores
que minimizan los sobrecostes del proyecto y el tiempo de ejecucin).
En el estudio 7, MIT (Ancona & Caldwell, 1990), las observaciones realizadas respecto al
tiempo que los miembros de los equipos de trabajo dedicaban a cada tarea demostraron que
se empleaba una proporcin significativa del tiempo del proyecto (14% de media) en trabajar
fuera de los lmites del equipo de trabajo, es decir, en las relaciones con el resto de equipos y
organizaciones del proyecto, por ejemplo en tareas de coordinacin, planificacin,
negociacin, soporte o estrategia, entre otras. Los resultados de este estudio indican que los
equipos que obtuvieron productos de ms xito, entendido este como el nivel de calidad y
comercializacin del producto, haban invertido ms tiempo en trabajos de gestin de las
relaciones que otros equipos. Dichas tareas son las tpicamente desarrolladas por los
ingenieros de sistemas como aplicacin de la metodologa de IS en las distintas fases del
proyecto, por lo que podemos decir que en los casos bajo estudio se aplicaron de forma parcial
tcnicas de IS, y que esto estadsticamente parece guardar relacin con la obtencin de unos
mejores resultados. Adems, no se encontr correlacin entre el xito de los proyectos y los
procesos internos del equipo, es decir, las capacidades y recursos tcnicos del proyecto.
Los datos obtenidos en el estudio 8, tambin del MIT pero de distinto autor (Miller,
2000), se resumen en la Ilustracin 18, donde se indica el porcentaje de los proyectos que
cumplieron con sus metas u objetivos iniciales. Se observa que a pesar de disponer de las
capacidades tcnicas necesarias, menos de la mitad de los proyectos (45%) alcanzaban
plenamente sus objetivos tcnicos, as como que una proporcin significativa de los mismos no
alcanzaba completamente sus objetivos de presupuesto y plazo (18% y 28% respectivamente).
Adems, los resultados de los proyectos eran mejores en los casos en que la estructura
organizativa estaba mejor desarrollada, aunque las capacidades tcnicas fueran ms
mediocres que en otros casos.
Porcentaje de los proyectos que cumplieron sus objetivos de:
Presupuesto total
82%
18%
Plazo total
72%
Objetivos tcnicos
45%
28%
18%
37%
36
La conclusin comn de ambos estudios del MIT es que el disponer de unas capacidades
tcnicas adecuadas, aunque es condicin necesaria para poder llevar a cabo un proyecto, no es
condicin suficiente para garantizar el xito del mismo. El verdadero factor determinante en
este aspecto es una buena gestin del proyecto, que es precisamente lo que se puede
conseguir a travs de la metodologa de IS, es decir, una gestin eficiente.
37
4 CONCLUSIONES
En general, el objetivo de cualquier proyecto de desarrollo de un sistema, sea del tipo que
sea, es cumplir con las necesidades que motivaron la existencia del mismo. Adems, este
objetivo debe conseguirse con resultados ptimos en los indicadores coste del proyecto,
tiempo para llevarlo a cabo, calidad del sistema resultante. En definitiva, se trata de conseguir
el xito del proyecto, entendido este como una combinacin de los 3 indicadores anteriores.
Maximizar el xito en ocasiones es complicado, sobre todo cuando se trata de proyectos
grandes y complejos tcnicamente, donde son muchos los actores y organizaciones
involucrados. La gestin de los recursos disponibles, tanto humanos como materiales, es
fundamental en estos casos, donde las desviaciones respecto de los objetivos y estimaciones
iniciales pueden ser importantes. Adems, muy a menudo, a la complejidad del trabajo tcnico
y las dificultades que conlleva la gestin econmica y organizativa se suman otros factores
relacionados con el cliente/usuario del sistema y el entorno de ejecucin del proyecto. Estos
factores, habitualmente sociales y polticos, pueden ser imprevisibles y por tanto, difcilmente
controlables a priori.
A lo largo de este Trabajo Fin de Mster se ha introducido la metodologa IS como una
herramienta de gestin, potencialmente capaz de aumentar el xito de los proyectos a travs
de un enfoque centrado en el Ciclo de Vida del sistema al completo, de manera que todas las
etapas sean consideradas en los procesos de toma de decisiones. Esto se lleva a cabo mediante
la integracin de diversas disciplinas y especialidades, a travs de un proceso de desarrollo
estructurado que comienza con la deteccin de la necesidad, contina con el diseo,
produccin y puesta en servicio del sistema que intenta satisfacerla, y finaliza con la retirada
del mismo al agotarse su vida til.
Las prcticas de IS prometen sistemas mejores, en menos tiempo, a menor coste y con un
nivel de calidad ms alto. Se ha comentado anteriormente que es en las primeras etapas de un
proyecto en las que la aplicacin de IS tiene mayor potencial de mejorar los indicadores de los
proyectos respecto a otras formas de gestin, centrndose en una correcta definicin del
sistema de forma temprana en el ciclo como medio para mejorar los indicadores del proyecto
y reducir el riesgo tcnico de no cumplimiento de los requisitos.
No cabe duda que cuanto ms se tarda en descubrir y corregir los problemas o
deficiencias de un proyecto, mayor es el impacto negativo en sus indicadores. Por ello en IS se
realiza un mayor esfuerzo de anlisis en dichas etapas, lo que se corresponde tambin con un
mayor nivel de inversin y dedicacin en las mismas. Esto se pone de manifiesto en la
Ilustracin 19 (Honour 2010), en la que se compara el valor intuitivo de la aplicacin de IS
(Systems Thinking Design) frente al enfoque del diseo tradicional (Traditional Design) a lo
largo de las etapas de diseo conceptual y preliminar (System Design), diseo de detalle y
desarrollo (Detail Design), produccin e integracin (Production Integration) y pruebas (Test).
Como puede apreciarse, en el diseo tradicional se concentra un mayor esfuerzo en las etapas
38
En muchas organizaciones este valor intuitivo o percepcin de mejora del xito de los
proyectos en los que se aplica la metodologa de IS es una afirmacin aceptada an sin
disponer de evidencias especficas respecto a la relacin causa-efecto (IS-mejora),
habitualmente debido a una buena experiencia previa en otros proyectos.
Sin embargo, en otros casos, cuando la organizacin se plantea implementar IS por
primera vez suele tener que justificar de antemano la inversin. Adems del aspecto
econmico, el adoptar procedimientos nuevos que implican cambiar los existentes puede
conllevar la oposicin/reticencia de los sectores ms conservadores de la estructura y del
personal que debe adecuarse a una nueva forma de trabajar.
39
40
suficientes para discernir que prcticas de IS hay que potenciar o priorizar, es decir, a qu
actividades ha de dedicarse un mayor nivel de esfuerzo/inversin para llegar al nivel ptimo de
dicho indicador. De todos los estudios analizados, el nico que aporta informacin a este
respecto para 8 categoras o actividades concretas de IS es el estudio 6, en el que se
demuestra que existe una correlacin entre la inversin realizada en ellas y los indicadores
coste, tiempo y xito del proyecto, establecindose puntos ptimos de inversin para los
proyectos de ms xito. Dicha correlacin es dbil, por lo que no pueden extraerse
informacin concluyente al respecto para su aplicacin directa a programas de desarrollo de
sistemas especficos.
El estudio 6 se encuentra a da de hoy an en proceso para continuar con esta lnea de
investigacin abierta (y probablemente se mantenga as por mucho tiempo debido a la
cantidad de datos relevantes necesarios y el ritmo al que es posible obtenerlos), cuyo objetivo
es desarrollar lo siguiente:
Una correlacin estadstica entre las categoras o actividades de IS y el xito de los
proyectos, de manera que quede definido cunto hay que invertir en cada una de ellas
y bajo qu condiciones para optimizar los resultados.
Indicadores que sirvan para dirigir el proyecto durante su ejecucin y para conseguir
los objetivos planificados en base a las categoras o actividades de IS utilizadas.
Identificacin de las buenas prcticas de IS adecuadas para conseguir el xito de los
proyectos bajo distintas condiciones.
Como se ha comentado anteriormente, el xito de los proyectos no slo depende de la
gestin econmica y organizativa, sino que existen otros condicionantes que repercuten en los
resultados, habitualmente relacionados con el cliente/usuario del sistema y el entorno de
ejecucin. Estas variaciones se escapan al control de la IS, por lo que el autor del estudio 6 est
desarrollando lo que denomina parmetros de caracterizacin de los proyectos, de manera
que puedan personalizarse las correlaciones mediante factores de correccin para cada
proyecto especfico. En el momento de la publicacin del estudio 6 (Honour, 2006), los
parmetros de caracterizacin consistan en 7 factores cuantitativos tamao del sistema y 7
factores subjetivos, representados a modo de esquema en la Ilustracin 21 y la Ilustracin 22
respectivamente, indicndose para cada uno de ellos tanto su rango de valores (de menor a
mayor, de izquierda a derecha), como su significacin con respecto al resto de parmetros de
su misma categora (de menor a mayor impacto en los resultados del proyecto, de abajo a
arriba). Es de esperar que con el desarrollo de la investigacin estos parmetros evolucionen
tambin.
Los parmetros de caracterizacin fortalecen la correlacin, tal como se muestra a modo
de ejemplo en la Ilustracin 23, en la que se representan la misma informacin que en la
Ilustracin 10, con la salvedad de que el valor del esfuerzo de IS ha sido corregido con los
parmetros desarrollados hasta el momento, aumentando as el factor de correlacin R2 en
ms de un 50%.
41
42
43
BIBLIOGRAFA
44
45
6 ACRONISMOS Y ABREVIATURAS
1
COTS: Commercials-Off-the-Shelf
10
MOTS: Military-Off-the-Shelf
11
12
46