Tesis Sobre TI

A PL IC A C I N DE CONCEPTOS DE GESTIN DE PRO YECTOS Y GESTIN
DE R IE S G O EN EL DESARROLLO DE PRODUCTOS NUEVOS EN EL CAMPO

DE TECNO LO G A DE IN FORM ACIN
por
Catherine Aguilar Ramos
Proyecto sometido en cumplimiento parcial
de los requisitos para el grado de
MAESTRO EN INGENIERA
en
Sistemas Gerendales
UNIVERSIDAD DE PUERTO RICO
RECINTO UNIVERSITARIO DE MAYAGEZ
Diciembre de 2005
Aprobado por:
Pedro Resto Batalla, PhD.
Fecha
Miembro del Comit Graduado
Miguel Segu Figueroa, LL.M
Fecha
Miembro del Comit Graduado
Viviana Cesan Vzquez, Ph.D.
Fecha
Presidente del Comit Graduado
Antonio A. Gonzlez Quevedo, Ph.D.
Fecha
Representante de Estudios Graduados
Agustn Rulln Toro, Ph.D.
Fecha
Director del Departamento
R eproduced with perm ission of the copyright owner. Further reproduction prohibited without permission.
UMI Number: 1431301
INFORMATION TO USERS
The quality of this reproduction is dependent upon the quality of the copy
submitted. Broken or indistinct print, colored or poor quality illustrations and
photographs, print bleed-through, substandard margins, and improper
alignment can adversely affect reproduction.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, these will be noted. Also, if unauthorized
copyright material had to be removed, a note will indcate the deletion.
UMI
UMI Microform 1431301
Copyright 2006 by ProQuest Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying underTitle 17, United States Code.
ProQuest Information and Learning Company

300 North Zeeb Road
P.O. Box 1346
Ann Arbor, MI 48106-1346
ABSTRACT
Small software development companies exhibit poor response toward risk because
they either do not have a formal risk management approaches or rely on an informal one.
This project presents the development of an innovative risk management methodology in
a startup company working on short lifecycle projects. The methodology includes
identifying and valuing the risks o f projects, giving priority to the most relevant risks, and
developing strategies to deal with the major risks in a proactive way throughout the
duration o f project The proposed approach combines existing methodologies for risk
management, such as the ones developed by the SEI (Software Engineering Institute) and
the PMI (Project Management Institute) and statistical techniques such as factor and
regression analyses. The methodology proposed in this project can be extended to other
companies with similar characteristics. This project provides emprica! evidence o f risk
assessment in the field o f Information Technology, an aspect notably absent in the
literature.
RESUM EN
Compaas de desarrollo de programas demuestran una gestin de riesgos pobre en

el campo de tecnologa de informacin; utilizando algn enfoque informal de gestin de
riesgos o ignorando los posibles riesgos a desarrollarse en el avance del proyecto. Este
proyecto desarrolla una metodologa de gestin de riesgos innovadora en una compaa
pequea de desarrollo de software. Se identific una compaa como caso de estudio y se
desarroll un proceso formal de gestin de riesgos en donde los factores de riesgos fueron
identificados, evaluados y mitigados, tomando como base las metodologas de gestin de
riesgos desarrolladas por el SEI (Software Engineering Institute), PMI (Project
Management Institute) y tcnicas estadsticas como anlisis factorial y anlisis de
regresin. De est forma compaas con caractersticas similares podrn tomar como gua
a este proyecto, aprendiendo de las herramientas y los mtodos de gestin de riesgos a
utilizar. Finalmente, otra de las contribuciones de este proyecto es proveer evidencia
emprica de la gestin de riesgos, ante la falta de casos reales en la literativa.
DEDICATORIA
A la memoria de mis abuelas Deyanira Llanos y Ersilda Barreiro, que

Dios me las cuide por siempre.
A mis Padres Evelio y Bertha Ligia y a mis hermanos Sara Mario y Juan
Camilo; por su amor incondicional y su paciencia, pero sobre todo por
creer en mi y apoyarme en la lucha por mis propios sueos.
AGRADECIM IENTOS
Inmenso agradecimiento a mi asesora de tesis, Dra. Viviana Cesan, por su

paciencia, apoyo y ayuda durante la realizacin de este proyecto y durante mis aos como
estudiante graduada.
A los miembros del comit graduado, Dr. Pedro Resto y Profesor Miguel Segu, por
el esfuerzo hecho y los conocimientos aportados.
A todo el personal de la compaa donde se realiz este proyecto especialmente al

Dr. Jos Cruz; por su disposicin y colaboracin, haciendo posible la culminacin de este
trabajo
Al Recinto Universitario de Mayagez de la Universidad de Puerto Rico por

ofrecerme la oportunidad de obtener el grado de Maestro en Ingeniera y aquellas
personas que fueron mis profesores y consejeros, durante este tiempo: Dr. Marco Arocha;
Dra. Jeannette Santos, Gregorio Vlez, Dr.Genock Prtela, Dr. Noel Artiles, Dr. Sonia
Bartolomei, Dr. David Gonzlez, y profesora Carmen Castafeyra.
A mis colegas, por aquellos momentos tan especiales durante estos aos: Juan
Guillermo, Giannina, Zuriel, Karina, Martha, Julin, Dermis, Heidy, Rosemary, Jannet,
Damaris. Finalmente a aquellas personas que me apoyaron en momentos difciles y me
brindaron su amistad: Natalia y Viviana.
Y a toda mi familia; gracias por ayudarme en aquellos momentos donde necesite

una mano amiga y por apoyarme en la lucha por mis metas: Merly, Lida, Jorge, Rubn,
Jimena, Cilia, Mnica, Francy y a todos los que olvide mencionar, gracias de todo
corazn.
TABLA DE CONTENIDO
1. IN TR O D U C C I N ................................................................................................................. 1
1.2. Definicin del problema.................................................................................................. 3
1.3 Justificacin.......................................................................................................................4
1.4 Objetivos.............................................................................................................................5
1.5 Alcance...............................................................................................................................6
1.6 Organizacin del documento............................................................................................6
2. REVISIN DE L IT E R A T U R A ......................................................................................... 8
2.1. Riesgos en proyectos de desarrollo de software.............................................................8
2.2 Metodologas existentes para el desarrollo de software............................................ 12
2.2.1 Etapas bsicas del ciclo de vida del desarrollo de software............................................ 12
2.2.2.
Mtodos tradicionales o formales de desarrollo de software....................................... 14
2.2.3 Mtodos giles e iterativos para desarrollo de software............................................... 17
2.3. Gestin de proyectos de desarrollo de software.......................................................... 22

2.4 Gestin de riesgo............................................................................................................. 23
2.4.1 Mtodos de gestin de riesgos......................................................................................... 24
2.4.2 Metodologa de gestin de riesgo desarrollada por el PMI..............................................25
2.5 Conclusiones.................................................................................................................... 30
3. M ETO D O L O G A ............................................................................................................... 31
3.1 Perfil de la compaa en estudio..................................................................................33
3.2. Anlisis general del estado actual del proyecto............................................................34
vi
3.3 Construccin, administracin y anlisis de una herramienta de identificacin de

riesgos........................................................................................................................................... 34
3.3.1 Construccin del cuestionario de identificacin de riesgos.............................................35
3.3.2.
Administracin y anlisis de laherramienta de identificacinde riesgos.....................42
3.3.2.1.Validacin del cuestionario......................................................................................43

3.3.2.2 Tamao de muestra del cuestionario.......................................................................43
3.3.2.3 Anlisis Factorial...................................................................................................... 44
3.3.2.4 Anlisis de regresin...............................................................................................46
3.4 Gestin de riesgos........................................................................................................... 49

3.4.1 Fase 1: Planificacin de riesgos....................................................................................... 50
3.4.2 Fase 2: Identificacin de riesgos.................................................................................... 54
3.4.3 Fase 3. Anlisis de los riesgos........................................................................................ 55
3.4.4 Fase 4. Planeacin de respuesta al riesgo....................................................................... 60
3.4.5 Fase 5. Seguimiento y control del riesgo....................................................................... 62
3.5 Conclusiones del proceso de gestin de riesgos.............................................................63
4. CASO DE ESTU D IO ........................................................................................................ 64

4.1 Descripcin del caso de estudio................................................................................... 64
4.1.1 Perfil de la compaa....................................................................................................... 64
4.1.2 Administracin de los proyectos y gestin de riesgo.......................................................66
4.1.3 Mtodos, herramientas y tcnicas paraplanificar y controlar losproyectos.....................66
4.1.3.1 Metodologa de desarrollo de software....................................................................67
4.1.3.2 Procesos y herramientas de planificacin y control de proyectos............................70
4.2. Riesgos percibidos.......................................................................................................72

4.3
Administracin y anlisis de resultados de la herramienta de identificacin de
riesgos propuesta......................................................................................................................... 75
4.3.1 Validacin del cuestionario.............................................................................................. 76
4.3.2 Tamao demuestrael cuestionario.................................................................................. 76
4.3.3 Anlisis de Factores......................................................................................................... 78
4.3.4 Regresin lineal............................................................................................................... 92
4.3.5 Implicaciones de los resultados y conclusiones............................................................... 96
vii
5. GESTIN DE R IESG O S...................................................................................................97

5.1 Fase 1: Planificacin de riesgos..................................................................................... 97
5.2 Fase 2: Identificacin de riesgos.................................................................................... 98
5.2.1 Identificacin de la lista maestra inicial de riesgos del proyecto.....................................98
5.2.2 Lista Maestra de riesgos actualizada.............................................................................. 100
5.3 Fase 3. Anlisis de los riesgos.......................................................................................103

5.3.1.
Anlisis cualitativo de los riesgos.............................................................................. 103
5.3.2 Anlisis Cuantitativo de los riesgos............................................................................... 105
5.4 Fase 4. Planeadn de respuesta al riesgo....................................................................106

5.5 Fase 5. Seguimiento y control del riesgo......................................................................115
6. CONCLUSIONES Y TRABAJOS FU TU R O S........................................................... 117

6.1 Conclusiones y recomendaciones.................................................................................117
6.2 Limitaciones del estudio................................................................................................121
6.3 Recomendaciones para trabajos futuros.....................................................................121
5. B IB L IO G R A FIA .............................................................................................................122
viii
LISTA DE FIGURAS
Figura 1. Ciclo de vida clsico (Ranean, 2003).............................................................................................15

Figura 2. Modelo Espiral (lvarez, 2002).................................................................................................... 16
Figura 3. Ciclo de vida del proceso unificado (RUP, 2002)......................................................................... 21
Figura 4. Diagrama de Flujo de losprocesos............................................................................................... 26
Figura 5. Datos de entrada, herramientas y resultados del proceso de planificacin del riesgo.................27
Figura 6. Datos de entrada, herramientas y resultados del proceso de identificacin de riesgo................27
Figura 7. Datos de entrada, herramientas y resultados del proceso de anlisis de riesgo cualitativa.
(PMBOK Guide, 2004).................................................................................................................................. 28
Figura 8. Datos de entrada, herramientas y resultados del proceso de anlisis de riesgo cuantitativo.
(PMBOK Cuide, 2004)..................................................................................................................................28
Figura 9. Datos de entrada, herramientas y resultados del proceso de respuesta al riesgo....................... 29
Figura 10. Datos de entrada, herramientas y resultados del proceso de seguimiento y control del riesgo.
(PMBOK Cuide, 2004).................................................................................................................................. 30
Figura 11. Metodologa aplicada.................................................................................................................. 32
Figura 12. Etapas de construccin del cuestionario de identificacin de riesgos........................................35
Figura 13. Redaccin de la pregunta y manejo de escala............................................................................ 38
Figura 14. Pasospara realizar un anlisis factorial.................................................................................... 45
Figura 15. Pasos a seguirpara realizar un anlisis de regresin................................................................ 47
Figura 16. Proceso de gestin de riesgos contino...................................................................................... 51
Figura 17. Herramientas y tcnicas utilizadas en el proceso de gestin de riesgos.....................................53
Figura 18. Proceso de identificacin de riesgos........................................................................................... 54
Figura 19. Proceso de anlisis cualitativo de los riesgos............................................................................. 56
Figura 20. Proceso de anlisis cuantitativo de los riesgos........................................................................... 60
Figura 21. Proceso deplaneacin de respuesta al riesgo............................................................................ 61
Figura 22. Estructura arganizacional de la compaa - caso de estudio....................................................65
Figpra 23. Metodologa de desarrollo de software vieja............................................................................. 68
Figura 24. Metodologa de desarrollo de software actual........................................................................... 69
Figura 25. Tiempo de experiencia del personal en la compaa de estudio................................................. 77
Figura 26. Tiempo de experiencia del personal en desarrollo de software.................................................. 77
Figura 27. Grfica de correlaciones-grupo de preguntas 53-60y 61-69..................................................... 79
Figura 28. Corrida del programa R -Anlisis factorial inicial.................................................................... 81
Figura 29. Grfica de factores. Grupos53-60y 61-69................................................................................ 82
Figura 30. Corrida del programa R - rotacin varimax................................................................................83
Figura 31. Grfica de factores. Grupos 53-60y 61-69.................................................................................83
ix
Figura 32. Grfica eprobabilidad normal de los residuales........................................................................ 94

Figura 33. Prueba de bondad de ajuste Kolmogorv Smirnov....................................................................... 95
Figura 34. Flujograma de la fase de seguimiento y control........................................................................115
LISTA DE TABLAS
Tabla 1. Herramientas de identificacin de riesgos en proyectos de software............................................... 9

Tabla 2. Resumen de losfactores de riesgos en proyectos de desarrollo de software presentados por
diferentes autores expertos en el tema...........................................................................................................11
Tabla 3. Mtodos de gestin de riesgo (Estvez, 2000)............................................................................... 25
Tabla 4. Estructura del cuestionario desarrollado por el SEI...................................................................... 37
Tabla 5. Estructura del cuestionario desarrollada en este proyecto............................................................. 40
Tabla 6. Definicin de la escala de probabilidad d ocurrencia.................................................................... 57
Tabla 7. Definicin de la escala de impacto negativo en los objetivos del proyecto.................................... 58
Tabla 8. Matriz de probabilidad e impacto................................................................................................... 59
Tabla 9. Seguimiento de las actividades del personal....................................................................................71
Tabla 10. Matriz de correlaciones grupa 53-60............................................................................................79
Tabla 11. Matriz de correlaciones grupo 61-69............................................................................................ 80
Tabla 12. Clculo del determinante............................................................................................................. 80
Tabla 13. Resumen de factores de riesgos encontrado en el anlisisfactorial............................................ 84
Tabla 14. Agrupacin de variables grupos 16-25, 26-35, 53-60.................................................................. 89
Tabla 15. Agrupacin de variables grupos 61-69, 79-87, 98-108................................................................ 90
Tabla 16 Agrupacin de variables grupos 109-115, 116-124.......................................................................91
Tabla 17. Modelo de seleccin y validacin de la respuesta.........................................................................93
Tabla 18 Coeficientes de regresin...............................................................................................................93
Tabla 19. Ponderaciones ms significativas de anlisis de regresin.......................................................... 94
Tabla 20. Factores resultantes del anlisis de cuestionario..........................................................................99
Tabla 21. Lista de riesgospercibidos por los lideres.................................................................................... 99
Tabla 22 Comparacin de riesgos encontrados versus riesgos en la literatura........................................ 101
Tabla 23. Lista maestra de los riesgos actualizada....................................................................................102
Tabla 24. Evaluacin de los riesgos en la matriz de severidad de riesgo....................................................104
Tabla 25. Formulario para la etapa deplaneacin de la respuesta a los riesgos...................................... 114
Tabla 26 Formulario para el proceso de control de riesgos.......................................................................116
LISTA DE ANEJOS
Anejo 1. Cronograma de actividades - Caso de estudio............................................................................. 25

Anejo 2. Herramienta de identificacin de riesgos..................................................................................... 128
Anejo 3. Lista de cotejo para validar la construccin del cuestionario...................................................... 145
Anejo 4. Matriz numrica de correlaciones y grfica de correlaciones...................................................... 147
Anejo 5. Extraccin de factores inicial........................................................................................................158
Anejo 6. Grfica de factores sin rotar..........................................................................................................163
Anejo 7. Rotacin Varimaxpreguntas 1-124.............................................................................................. 167
Anejo 8. Representacin grfica de las variables respecto a los ejes factoriales rotados, utilizando
VARIMAX.................................................................................................................................................... 172
Anejo 9. Rotacin PROMAX........................................................................................................................176
xi
1. INTRODUCCIN
Gestionar un proyecto de desarrollo de software como si se tratara de un proyecto

de fabricacin, es nn error que las compaas no pueden cometer hoy en da. Los
proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniera
tradicional, por diferentes razones: el software se desarrolla, no se fbrica en un sentido
clsico; el software no se deteriora, y el paso del tiempo o males del entorno no inciden
en el aumento de la tasa de fallas. Es por eso que las compaas de desarrollo de software
utilizan metodologas diferentes, a las metodologas tradicionales o formales de gestin
de proyectos, buscando una mayor flexibilidad en el mercado actual.
Uno de los aspectos ms importantes para el xito del desarrollo de un producto

nuevo es la capacidad de ocuparse con eficacia de los riesgos que son parte de cada
proceso del desarrollo de productos. Muchas compaas nuevas de desarrollo de
software, empiezan trabajando sin ninguna metodologa, ya que son un equipo de
emprendedores con talento, capaces de construir sistemas de software con calidad. Los
resultados sern tan buenos como ellos los sepan hacer. El cumplimiento de agendas
depender de su capacidad de previsin y organizacin. Pero no hay que engaarse; en
este caso no se trata de compaas que saben hacer software, sino de personas que saben
hacer software. Esta situacin dibuja el guin comn de todas las pequeas compaas de
desarrollo de software que surgen de cero start-up, impulsadas tan slo por el empuje
de sus emprendedores, las cules pueden llegar tan lejos cmo la combinacin del talento
y de la capacidad de mercadeo de sus creadores les permitan.
Start-up, es un trmino que se refiere a aquellas compaas pequeas de desarrollo

de software, que empiezan trabajando sin ninguna metodologa, ya que son un equipo de
emprendedores con talento capaces de construir sistemas de software con calidad. Su
xito depende de su capacidad de desarrollar tecnologas rpidamente. Deben ser
extremadamente asertivos a las necesidades de cliente y estar dispuestas a agregar
funcionalidad a un producto a cualquier hora dada.
Conseguir clientes e inversionistas es la meta ms importante de esta clase de

compaas. Para ser verdaderamente asertivas, la mayora de las compaas del software
necesitan adquirir clientes mltiples. Para alcanzar este objetivo, deben estar dispuestas a
acelerar su proceso del desarrollo y a hacer excepciones a las reglas que se aplican
normalmente al desarrollo del software.
Por otra parte, la carencia del capital es un problema comn a la mayora de estas
compaas en su fase de inicio. Esta clase de compaas todava no han empezado a
generar beneficios, lo cul las lleva a tener que apoyarse de inversionistas, mientras
ganan clientes potenciales y pueden empezar a generar sus propios beneficios. La
inversin en esta ase tiene un largo perodo de maduracin y tambin suele requerir de la
inyeccin de recursos posteriormente para financiar el crecimiento a lo largo del proceso
de maduracin de sus procesos de desarrollo y de negocio. Los inversionistas que
soportan estn compaas, buscan proyectos empresariales de fuerte contenido innovador,
preferentemente tecnolgico. Es por eso que estas compaas tienen un desarrollo de
software agresivo, con el nimo de crear un producto exitoso en el mercado.
En cuanto a sus proyectos, estos estn asociados intrnsecamente con un conjunto

de riesgos que requieren un plan de manejo claramente establecido, documentado y con
una implementacin eficaz. Es aqu que el proceso de gestin de riesgos es de vital
importancia, permitiendo planificar y prevenir los posibles riesgos, evitando retrasos en
los tiempos de entrega, problemas de calidad en el producto, pobre estimacin de los
recursos o en el peor de los casos, riesgos que puedan afectar la culminacin del
proyecto.
1.2. Definicin del problem a
En los proyectos de tecnologa de informacin (TI), la gestin de riesgos es crucial

para obtener el xito. Las presiones de la competencia, los cambios normativos y la
evolucin de las tcnicas pueden obligar a los equipos de proyectos de TI a alterar los
planes y estrategias en mitad de un proyecto. Los cambios en los requisitos de los
usuarios, las nuevas herramientas y tecnologas, las constantes amenazas de seguridad y
los cambios en la plantilla de empleados aaden ms presin al equipo de proyectos de TI
y pequdican la toma de decisiones.
Muy pocas organizaciones utilizan mtodos de gestin de riesgos en sus proyectos

de desarrollo de software. Estudios realizados en la literatura demuestran esta
problemtica claramente; por ejemplo, durante el ao 2001, KLCI (2001), realiz y
public un estudio con 268 organizaciones de todo el mundo, referente a la aplicacin de
la gestin de riesgos y el resultado fue que el 3% no utilizaba ningn marco de gestin
del riesgo, el 18% utilizaba un marco propio para identificar sus riesgos, el 37% de los
participantes haban utilizado algn marco informal, el 28% utilizaban procedimientos
repetitivos y slo un 14% utilizaba un enfoque formal para identificar riesgos.
Todo esto nos lleva a concluir que aunque, algunas organizaciones usen procesos
formales de gestin del riesgo en otras partes de su negocio, demuestran una gestin de
riesgos pobre en el mbito general de los sistemas de informacin; utilizando algn
enfoque informal de gestin de riesgos o ignorando los posibles riesgos a desarrollarse en
el avance del proyecto.
1.3 Justificacin
Actualmente las pequeas compaas de desarrollo de software, de recin entrada al

mercado no utilizan procesos formales de gestin de riesgos, pues se conforman
solamente con utilizar enfoques informales, debido a factores como:
falta de
conocimiento sobre posibles mtodos y herramientas, limitaciones prcticas y tericas de

los marcos de gestin de riesgos que entorpecen la facilidad de uso de estos mtodos, y
ausencia de estudios reales con evaluaciones sistemticas o cientficas que proporcionen
una retrocomunicacin emprica sobre su viabilidad y beneficios (Kontio, 1997).
Administrar los riesgos por medio de un proceso de desarrollo de software

predecible provee un fundamento para desarrollar en forma consistente un mejor
software, ms rpidamente y a un menor costo. Empezando con esta base, se podrn
adoptar tcnicas y herramientas para lograr que los desarrolladores sean ms productivos,
para elevar la calidad del software, y para automatizar muchos de los procesos de gestin
del software, liberando de esta manera ms tiempo para el desarrollo de las aplicaciones.
Por lo tanto el propsito de este proyecto es aplicar los conceptos de la gestin de

proyectos y gestin de riesgos en proyectos de desarrollo de software en plazos de tiempo
corto; implementando un proceso proactivo de administracin de riesgos, a lo largo del
ciclo de vida del proyecto. De esta forma otras compaas con similares caractersticas
podrn tomar idea de este estudio, aprendiendo de las herramientas y los mtodos de
gestin de riesgos a utilizar.
1.4 Objetivos
1. Analizar la situacin actual de las compaas pequeas de desarrollo de

software, sus procesos y tcnicas de gestin de proyecto.
2. Identificar los riesgos ms relevantes en compaas pequeas de desarrollo de

software en plazos de tiempo corto, utilizando una herramienta de
identificacin de riegos; para luego compararlos posteriormente con los
riesgos existentes en la literatura.
3. Realizar una compilacin final de los riesgos ms importantes del producto en

estudio, teniendo en cuenta los riesgos percibidos y los riesgos reales.
4.
Desarrollar y probar una metodologa continua de gestin de riesgos

innovadora; identificando y valorando ininterrumpidamente aquellos riesgos
tcnicos y no tcnicos internos de la organizacin; dando prioridad a los
riesgos ms potenciales y desarrollando estrategias para tratar los riesgos de
forma proactiva a lo largo del ciclo de vida del proyecto; utilizando como
base las metodologas (herramientas y tcnicas) de gestin de riesgos
existentes.
1.5 Alcance
Esta investigacin presenta los resultados de un caso estudio realizado en el rea
Oeste de Puerto Rico. La compaa seleccionada es una compaa nueva (Start-up) de
desarrollo de software en plazos de tiempo corto; que poco a poco ha desarrollado sus
procesos para ser ms competitiva en el mercado. El resultado de este proyecto es una
metodologa continua de gestin de riesgos innovadora, con el propsito de desarrollar
estrategias para tratar los riesgos de forma proactiva a los largo del ciclo de vida del
proyecto.
1.6 Organizacin del documento
El Captulo 2 presenta las diferentes herramientas de identificacin de riesgos

encontradas en la literatura y los riesgos investigados por diferentes autores en proyectos
de desarrollo de software. Posteriormente se describen las diferentes metodologas de
gestin de proyectos en el rea de desarrollo de software y se describe el proceso de
gestin de riesgo desarrollado por el PMI (Project Management Institute).
El Captulo 3 presenta la metodologa propuesta. sta fundamentalmente se

encuentra dividida en dos. La primera parte describe los aspectos a tratar en el perfil de la
compaa. Posteriormente se describe la construccin y administracin de una
herramienta de identificacin de riesgos, desarrollada especficamente para identificar los
riesgos tcnicos y organizacionales existentes en el desarrollo de software. La segunda
parte describe la gestin de riesgos propuesta, identificando los mtodos, tcnicas y
recursos a utilizar en cada fase.
El Captulo 4 describe el Caso de estudio desarrollado en una compaa de

desarrollo de software ubicada en el rea Oeste de Puerto Rico. Se presenta el perfil de la
compaa y un anlisis general de su estado actual. Se describe la administracin y el
anlisis de los datos recolectados con la herramienta de identificacin de riesgos
propuesta, aplicada al caso estudio. Posteriormente se plantea un anlisis de factores,
identificando los factores de riesgos y un anlisis de regresin, con el propsito de
conocer los factores ms relevantes. Finalmente, se presentan los hallazgos encontrados.
El Captulo 5 describe la gestin de riesgos desarrollada en la compaa caso

estudio, abarcando todo el proceso de identificacin, anfisis y control de los riesgos. Se
plantean alternativas de respuesta a los riesgos encontrados y se presentan patrones de
desarrollo recomendados para mantener un proceso continuo de gestin de riesgos
Finalmente en el Captulo 6 presenta las conclusiones, recomendaciones y trabajos

futuros relacionados con el tema de estudio.
2. REVISIN DE LITERATURA
Desarrollar proyectos de software es un negocio que involucra muchos riesgos. Una

organizacin de desarrollo de software que no cuente con un adecuado control de sus
proyectos; siempre se encontrar con atrasos en su plan de trabajo, por encima del
presupuesto asignado y en general, con resultados que son altamente costosos. Tratar de
hacer un mejor trabajo de desarrollo de software,
sin contar con un proceso bien
definido; conlleva a que las buenas ideas no puedan ser integradas efectivamente al
interior de la organizacin. Es ms, el tratar de apagar incendios (resolver mltiples
problemas) desperdicia demasiado tiempo y atencin que deberan estar enfocados a la
mejora del desarrollo del software.
2.1. Riesgos en proyectos de desarrollo de software

Actualmente, se encuentra disponible una gran cantidad de material bibliogrfico,
herramientas y software que sirven como colaboradores en las actividades de un gestin
de proyectos y, entre ellas y particularmente, en las tareas relacionadas con la gestin de
riesgos. Dentro de este contexto, las actividades de identificacin de riesgos han sido
ampliamente estudiadas y documentadas, constituyendo de este modo uno de los
principales aspectos de anlisis dentro de la teora general.
La identificacin de riesgos en base a taxonomas ha sido motivo de inters

creciente en la industria de software y tiene su referencia fundamental en el trabajo
presentado por el SEI en el ao 1993 y titulado Taxonomy-Based Risk Identification
[Carr., 1993]; el mismo propone una metodologa basada en un cuestionario desarrollado
por el SEI cuyo objetivo es colaborar en la identificacin de riesgos segn categoras
tpicas, dicho cuestionario posibilita a los equipos de proyecto explorar riesgos
potenciales que podran no haber sido considerados de otro modo.
Existen adems una gran cantidad de herramientas de software disponibles en el

mercado y relacionadas con la identificacin de riesgos. Estas herramientas se enfocan
slo en una categora de riesgos (TRIMS-Technical Risk Identification and Mitigation
System), o estn orientadas a compaas que poseen una amplia base de datos
organizacional que les permite generar informacin de categoras propias de riesgos
(RiskTrak y WelcomRisk), o bien emplean un mecanismo que no se orienta al uso de
Taxonomas (ARM-Active Risk Manager). La Tabla 1, resume las caractersticas
principales de las herramientas de software que se encuentran disponibles actualmente y
que estn relacionadas con la identificacin de riesgos en proyectos de desarrollo de
software.
Tabla 1. Herramientas de identificacin de riesgos en proyectos de software
Maniasi. (2004)
Active Risk
Manager
(ARM)
Strategic
Thought
Herramienta integrada de gestin de riesgos que

brinda una solucin para la identificacin de
riesgos mediante la utilizacin de la informacin
contenida en el WBS de proyecto.
Web Based
Technical Risk
Identification
and
Mitigation
System
(TRIMS)
Best
Manufacturing
Practices

emplea ingeniera de conocimientos y que se
enfoca en la identificacin y medicin de riesgos
tcnicos de proyectos.
Win32
RiskTrak
Risk Services &

Technology

brinda una solucin para la identificacin de
riesgos mediante el empleo de base de datos.
Win32
Welcom

brinda una solucin para la identificacin
sistemtica de riesgos mediante la utilizacin de
bibliotecas configurables de categoras de riesgos.
Win32
WelcomRisk
A continuacin se describen los factores de riesgos ms significativos encontrados

en la literatura.
10
Boehm (1991) identifica 10 factores de riesgo presentes en proyectos de desarrollo

de software. Estos hacen referencia a riesgos relacionados con el personal, itinerarios,
funcionalidad del sistema, gestin de requerimientos, proveedores y el uso y desempeo
de los recursos.
Barki (1993) presenta 5 factores, los cules fueron clasificados de la siguiente

forma: El factor 1 se le dio el nombre de nueva tecnologa; ya que de las cinco variables
que lo conforman, cuatro de ellas estn relacionadas con tecnologa; el factor 2 se le
nombr tamao o alcance de la aplicacin, ya que de las cinco variables que lo
conforman, cuatro hacen referencia a el nmero de personas en el equipo, diversidad del
equipo, nmero de usuarios futuros, y nmero de niveles jerrquicos ocupados por los
usuarios futuros. En el factor 3, cuatro de las cinco variables se refieren a la experiencia
del equipo, nombrando de esta forma al factor. En el factor 4, las variables hacen
referencia a la complejidad tcnica, y al nmero de enlaces de la aplicacin, nombrando
al factor como complejidad de la aplicacin. Finalmente al quinto factor se le llam
ambiente organizadonal, puesto que est compuesto por variables relacionadas con la
aplicacin o con el personal de la organizacin.
Jones (1998) presenta 3 factores de riesgos principalmente incurridos por los

administradores del proyecto. El factor 1 hace referencia a los riesgos asociados con la
estimacin y planificacin inexacta, el factor 2 se refiere a los reportes y estados
incorrectos u optimistas y el factor 3 se refiere a las presiones externas.
Finalmente tenemos los factores presentados por (Estvez y Pastor, 2000). Estos
presentan factores que abarcan primordialmente los riesgos organizacionales y
estratgicos de la organizacin. La perspectiva estratgica trata sobre las competencias
claves para lograr los objetivos de la organizacin a largo plazo, mientras que la
perspectiva tctica afecta a las actividades de negocio con objetivos a corto plazo.
La Tabla 2 presenta un resumen de los riesgos encontrados en la literatura.
11
Tabla 2. Resumen dlos factores de riesgos en proyectos de desarrollo de software presentados

por diferentes autores expertos en el tema
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Factor 6
Factor 7
Factor 8
Factor 9
Factor 10
Falta de personal cualificado

Itinerario y presupuestos poco realistas
Desarrollo incorrecto de las funciones del software
Desarrollo incorrecto de las interfaces del usuario
Adicin de funciones o caractersticas innecesarias
Cambio constante en los requerimientos
Fallas en los componentes subcontratados
Pobre calidad de las tareas subcontratadas
Fallas en Tiempo real de respuesta
Inhabilidad para implementar soluciones tcnicas debido a la pobre
capacidad de conocimientos en la ciencia de computacin
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Tecnolgico
Tamao de la aplicacin
Falta de experiencia
Complejidad de la aplicacin
Ambiente organizacional
Factor 1
Factor 2
Factor 3
Estimacin y planeacin inexacta del itinerario

Reporte de estatus incorrecto y optimistas
Presiones extemas las cuales daan los proyectos de software
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Factor 6
Factor 7
Factor 8
Factor 9
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Factor 6
Factor 7
Factores estratgicos
Apoyo continuo de la alta direccin
Gestin efectiva del cambio organizacional
Buenagestin del mbito del proyecto
Composicin adecuada del equipo del proyecto
Rediseo adecuado de los procesos de negocio
Papel adecuado del lder del proyecto
Papel adecuado del jefe del proyecto
Implicacin y participacin de los usuarios
Confianza entre actores
Factores tcticos
Equipo y consultores dedicados
Comunicacin interna y extema
Plan formalizado del proyecto
Programa de formacin adecuado
Precisin de problemas inesperados
Uso adecuado de consultores
Responsables debidamente autorizados
12
2.2 Metodologas existentes para el desarrollo de software

Muchas veces las compaas no encuentran la metodologa ms adecuada para su
estilo organizacional y terminan por hacer o disear una metodologa propia, algo que por
supuesto no est mal, siempre y cuando cumpla con el objetivo. Una metodologa
consiste en concretar el tipo de ciclo de vida que se va a seguir y la forma en la que se
realizan las actividades dentro de cada etapa. Si analizamos detenidamente el ciclo de
vida del desarrollo del producto, cada etapa tiene datos de entrada y resultados
especficos, las cules presentan riesgos que son importantes atacar a tiempo. Es por eso
la importancia del estudio de los diferentes ciclos de vida.
No existe una metodologa universal para hacer frente con xito a cualquier
proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del
proyecto: recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.
Histricamente, las metodologas tradicionales en el campo de desarrollo de software,
han intentado abordar la mayor cantidad de situaciones de contexto del proyecto,
exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos
y con requisitos muy cambiantes. En su lugar las metodologas giles emergen como una
posible respuesta para llenar ese vaco metodolgico. Por estar especialmente orientadas
a proyectos pequeos y a la gestin de riesgos, las metodologas giles constituyen una
solucin a la medida para ese entorno.
2.2.1 Etapas bsicas del ciclo de vida del desarrollo de software

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren un
tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un
perodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la
necesidad de construir un sistema de software hasta que este es retirado, se identifican
varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso,
13
en funcin de cules sean las caractersticas del proyecto, se configurar el ciclo de vida
de forma diferente. Las etapas principales a realizar en cualquier ciclo de vida son:
1. Anlisis de requerimientos: El objetivo de esta fase es identificar los

requerimientos del sistema.
2. Disefio: El objetivo de esta fase es desarrollar una representacin coherente y

organizada del producto software que satisfaga la especificacin de requerimientos. La
estructura de datos (diseo de datos), la arquitectura del software (diseo arquitectnico),
la caracterizacin de las interfaces (diseo de interfaces) y la interfaz de usuario, son
realizadas en esta fase.
3. Codificacin: En esta fase se lleva a cabo la traduccin del diseo a un lenguaje

de programacin que pueda ser luego interpretado por la mquina. Se pretende traducir el
diseo en un cdigo fuente. El cdigo fuente debe estar acompaado de la documentacin
correspondiente, que constituye la manifestacin fsica del diseo de acuerdo a los
estndares y metodologas adoptados para el proyecto.
4. Pruebas: Esta fase constituye la revisin final de las especificaciones, el diseo y

la codificacin y puede ser considerada crtica para asegurar la calidad del producto
generado. En ella se ejecutar el software con determinados datos de entrada, observando
los resultados que se producen y comparndolos con los que, tericamente y segn las
especificaciones, el sistema debera producir, detectando as posibles fallos.
5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega se asegura que
el sistema siga funcionando y adaptndose a nuevos requisitos.
14
2.2.2. Mtodos tradicionales o formales de desarrollo de software
Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en las

diferentes fases de cada uno de los mtodos pueden dar lugar a un tipo de ciclo de vida
diferente. A continuacin se describen brevemente los modelos de ciclos de vida de los
mtodos tradicionales y los mtodos alternativos (giles) que se utilizan actualmente en
compaas pequeas de desarrollo de producto en plazos de tiempo cortos.
Uno de los grandes pasos dados en la industria del software lo fue el desarrollo del
modelo en Cascada. El mismo surge como respuesta al modelo Codificar y Probar que
era el que predominaba en la dcada de los 60. A continuacin se describe el modelo en
Cascada.
1.
Mtodo de ciclo de vida clsico (M odelo en Cascada): Este mtodo fue
aplicado con xito para estructurar y gestionar grandes proyectos de software en

importantes compaas de desarrollo. Este modelo (Ranean, 2003) puede ser visto como
un modelo con forma de Cascada de agua de varios saltos, en la que cada salto representa
cada una de las fases del ciclo de vida La Figura 1 permite visualizar la evolucin del
producto software como una secuencia ordenada de transiciones, de fase en fase, que
evoluciona en forma lineal, exige un enfoque sistemtico y secuendal del desarrollo del
producto software y contempla las siguientes fases: ingeniera y anlisis del sistema
global, anlisis de requisitos de software, diseo, codificacin, prueba y mantenimiento.
15
Ingenela d
R o y u s ' $ 7C
! A.......
L'sxittf&cori
f t to r tte n im ic r ilc
Figura 1. Ciclo de vida clsico (Ranean, 2003)
De esta manera y en forma bastante temprana en algunos casos, fueron surgiendo

diversos procesos denominados iterativos que proponan lidiar con la poca predictibilidad
del software (mejorando muchas de las fallas del modelo en Cascada), mitigando de esta
forma los riesgos en forma temprana. Posterior a los procesos iterativos, se comenzaron a
desprender diversas ramas; como son el modelo Iterativo e Incrementa!, el modelo en
Espiral, el modelo basado en Prototipo, entre otros. Bsicamente, la postura de estos
modelos es la de basar el desarrollo en iteraciones e ir construyendo la aplicacin en
forma progresiva, agregando funcionalidad sucesivamente. Las iteraciones representan un
mini-proyecto, el cual est compuesto por todas las fases del desarrollo (requerimientos,
diseo, implementacin
y prueba. A continuacin se describen algunos de estos
modelos.
2.
Modelo en E spiral W in W in: Boehm, (1986) fue el autor que desarrollo el
modelo espiral. De este surgi una de las ideas fundamentales que las metodologas
posteriores adoptaran: el anlisis de riesgos.
16
Como muestra la Figura 2 este modelo de carcter iterativo en sus primeras fases,
plantea la necesidad de realizar al principio diversas iteraciones dirigidas a mitigar los
riesgos ms crticos encontrados en el proyecto, mediante la realizacin de prototipos o
simulaciones desechables tendientes a probar algn concepto. Una vez que esos
prototipos son validados, se suceden iteraciones del tipo de determinar objetivos, evaluar,
desarrollar y planear.
Es ideal para manejar proyectos que requieran la incorporacin de nuevas
tecnologas, o para desarrollar productos completamente nuevos o con un nivel alto de
inestabilidad de los requerimientos. Esta nueva filosofa se encuentra representada por
ciclos de desarrollo evolutivo e iterativo en forma de espiral, cuyo avance angular
representa el progreso del desarrollo, en tanto que el desplazamiento radial desde el
centro h a d a fuera indica el incremento de los costos de desarrollo en forma acumulativa.
La Figura 2 permite visualizar grficamente el comportamiento de este tipo de ciclo de
vida.
\ Pisa desuYaf
VWifhE'j^tStw v
''"* X "
\fnatae\:*'3**ta
lele-
wt i i a r i r : V
' x
. /
.X
'
Figura 2. Modelo Espiral (lvarez, 2002)
17
2.2.3 Mtodos giles e iterativos para desarrollo de software
A principios de la dcada del 90, surgi un enfoque que fue bastante

revolucionario para su momento ya que iba en contra de la creencia de que mediante
procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la
calidad requerida. El enfoque fue planteado por primera vez por Martn (1991) y se di a
conocer en la comunidad de ingeniera de software con el mismo nombre que su libro,
RAD o Rapid Application Development. RAD consista en un entorno de desarrollo
altamente productivo, en el que participaban grupos pequeos de programadores
utilizando herramientas que generaban cdigo en forma automtica tomando como
entradas sintaxis de alto nivel. Estos modelos se basan en iteraciones. El desarrollo
iterativo es un mtodo de construccin de productos cuyo ciclo de vida est compuesto
por un conjunto de iteraciones, las cuales tienen como objetivo entregar versiones del
software.
El trmino Mtodos giles (Larman, 2003), se utiliza para definir aquellos
mtodos que estaban surgiendo como alternativa a las metodologas formales, las cules
se consideran excesivamente pesadas y rgidas por su carcter normativo y fuerte
dependencia de planificaciones detalladas, previas al desarrollo. Las metodologas giles
reconocen las caractersticas inherentes de complejidad del software, y el carcter
emprico que debe tener un proceso de desarrollo del mismo. Entre las metodologas
giles ms destacadas hasta el momento podemos nombrar:
XP - Extreme Programming
Serum
Crystal Clear
DSDM - Dynamic Systems Developmemt Method
FDD - Feature Driven Development
ASD - Adaptive Software Development
XBreed
Extreme Modeling
18
Estos mtodos se guan por cuatro postulados que comprende el espritu en el que
se basan estos mtodos; lo cual se denomina Manifiesto gil. A continuacin se
describe los postulados y principios giles:
I. Postulados del Manifiesto gil
Estos mtodos valoran:
Los individuos y su interaccin, por encima de los procesos y las

herramientas.
El desarrollo del software, por encima de la documentacin exhaustiva.
La colaboracin con el cliente, por encima la negociacin contractual.
La respuesta al cambio, por encima seguimiento de un plan.
II. Principios del Manifiesto gil

Los 12 principios del Manifiesto gil plantean principios que pueden resultar
viables para los proyectos de software de determinadas caractersticas. A continuacin se
describe cada uno de ellos:
Nuestra principal prioridad es satisfacer al cliente a travs de la entrega

temprana y continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos giles se doblegan al cambio como ventaja
competitiva para el cliente.
Entregar frecuentemente software, en periodos de un par de semanas hasta un
par de meses, con preferencia en perodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a travs del proyecto.
Construccin de proyectos en tomo a individuos motivados, dndoles la
oportunidad y el respaldo que necesitan y procurndoles confianza para que
realicen la tarea.
19
La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversacin cara a cara.
El software desarrollado es la principal medida del progreso.
Los procesos giles promueven el desarrollo sostenido.
Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo

constante de forma indefinida.
La atencin continua a la excelencia tcnica enaltece la agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es

esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos que se

auto-organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser ms

efectivo y ajusta su conducta como consecuencia.
A continuacin, se describen las metodologas ms importantes:
1.
M todo Extrem e Program m ing (XP): Es una de las metodologas de desarrollo
de software ms exitosas en la actualidad, utilizadas para proyectos de corto plazo. Su

creador, Kent Beck fue el padre del Manifiesto gil. Su principal asuncin es que con un
poco de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si
se est siguiendo un camino acertado o equivocado, evitando as tener que echar marcha
atrs demasiado tarde. La metodologa consiste en una programacin rpida o extrema,
cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los
requisitos para llegar al xito del proyecto. XP se basa en retrocomunicacin continua
entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los
participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios. XP se define especialmente para proyectos con requerimientos imprecisos y
muy cambiantes, y para proyectos donde exista un alto riesgo tcnico (Grupo SSI, 2003).
20
2. Serum: Uno de los anlisis ms importantes en est metodologa desemboc en

un libro escrito por dos de sus creadores, Ken Schwaber y Mike Beedle. (Schwaber,
2001). Serum define mtodos de gestin y control para complementar la aplicacin de
otros mtodos giles como XP, que centrados en prcticas de tipo tcnico, carecen de
ellas. Los principios de Serum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra
Reuniones diarias con los miembros del equipo.
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales

se presenta el resultado a los externos del equipo de desarrollo, y se realiza
una planificacin de la siguiente iteracin, guiada por cliente.
A continuacin se describen los modelos de propiedad comercial:
3. Microsoft Solution Framework (MSF): MSF es la metodologa empleada por

Microsoft para el desarrollo de software. Esta es una metodologa flexible e
interrelacionada con una serie de conceptos, modelos y practicas de uso, que controlan la
planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los
modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas
(Snchez, 2003). El marco MSF se asienta sobre unos principios fundamentales que
definen la cultura del entorno de desarrollo:
1. Fomentar la comunicacin abierta.
2. Trabajar en tomo a una visin compartida.
3. Apoderar a los integrantes del equipo (empowerment)
4. Establecer responsabilidades claras y compartidas.
5. Centrar el objetivo en la entrega de valor para el negocio.
6. Permanecer giles y esperar al cambio.
7. Invertir en calidad.
8. Aprender de la experiencia.
21
4.
M todo RUP (Proceso Unificado): RUP es un modelo-producto desarrollado
y mantenido por Racional Software, integrado en su conjunto de herramientas de

desarrollo, y distribuido por IBM. La metodologa se conoce como RUP, llamada as por
sus siglas en ingls Rational Unified Process.
El proceso unificado consiste en una serie de ciclos. Al final de cada ciclo se tiene
una versin del producto. Los objetivos de una iteracin se establecen en funcin de la
evaluacin de las iteraciones precedentes. La Figura 3, muestra las fases de cada ciclo en
este mtodo: inicio, elaboracin, construccin y transicin. (RUP, 2002).
Versin 1
t
Ciclo 1
Inieio
1 C klo 2
Versin 2
Versin n
i
. .
Construccin
Ciclo n
Transicin
Requisitos
Anlisis
Diseo
Implementadn
ftueba
Figura 3. Ciclo de vida del proceso unificado (RUP, 2002)
22
2.3. Gestin de proyectos de desarrollo de software

Existen diferentes metodologas de gestin de proyectos propuestas por diferentes
organizaciones; metodologas formales como PMI (Project Management Institute), SEI
(Software Engineering Institute), y metodologas giles, como son RUP, SCRUM, MSF,
entre otras; que ofrecen herramientas de planificacin, anlisis y control de los proyectos,
necesarias para una buena administracin. Estos mtodos son indispensables en las
organizaciones; ya que para conseguir un proyecto de software fructfero se debe
comprender el mbito del trabajo a realizar, los riesgos en los que se puede incurrir, los
recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a
seguir.
La gestin formal de proyectos se asienta sobre la direccin del proyecto sobre un

plan general con visibilidad y mbito de certidumbre hasta el final del proyecto. La
gestin formal hace hincapi en la necesidad de conocer con el mayor detalle los
requerimientos desde el principio para dar rigor al plan del proyecto. Las principales
referencias de la gestin formal de proyectos son las asociaciones: PMI (Project
Management Institute), IPMA (fritemational Project Management Asociation) y la
metodologa PRINCE2 (Projects in Controlled Environments). PMI e IPMA son
organizaciones que han ido desarrollando estndares, mtodos y modelos de certificacin
profesional.
Por otro lado, la planificacin de la gestin gil es informal (algunos modelos

llegan a prohibir el uso de diagramas de Gantt) y solo cubren el ciclo de software que se
est elaborando (generalmente un mes). Las principales referencias de la gestin gil de
proyectos son: Serum, Rational Unified Process (RUP) y Microsoft Solutions Framework
(MSF). Serum es un modelo gil no centrado en prcticas de programacin como XP,
sino en prcticas de gestin. Rational Unified Process es un proceso iterativo para
desarrollo de software creado por Rational Software (IBM). MSF es un marco de
desarrollo que define procesos, principios, modelos, disciplinas, conceptos y practicas
23
contrastadas por Microsoft. Cabe aclarar que estos no son modelos de procesos sino
marcos de trabajo adaptables a las circunstancias de las organizaciones de los proyectos.
Muchas organizaciones exitosas hoy da, utilizan una combinacin de metodologas
formales e informales de desarrollo, y una mezcla de herramientas, para conducir
proyectos de manera predecible, que aceleren el desarrollo y reduzcan los riesgos innatos
en estos.
2.4 Gestin de riesgo

El riesgo es una condicin futura o circunstancia que existe por fuera del control del
gerente del proyecto y de su equipo y que puede tener un impacto negativo (amenaza) o
positivo (oportunidad) por lo menos en uno de los objetivos del proyecto: costos (cumplir
con los costos planificados al principio del proyecto), tiempo (obtener cada versin del
software en el tiempo acordado), alcance (cumplir con las caractersticas del producto
que se acordaron) y calidad (cumplir con los requerimientos de calidad pactados).
(PMBOK, 2004).
La gestin de riesgos es el conjunto de procesos que se relacionan con la

identificacin, el anfisis y la respuesta a la incertidumbre (carencia de conocimiento de
eventos futuros). Esto incluye la maximizadn de los resultados de los eventos positivos
y la minimizacin de las consecuendas de los eventos adversos. (PMBOK, 2004)
La gestin de riesgos permite identificar los riesgos que impacten a favor o en

contra los objetivos, los tiempos y los costos del correspondiente proyecto. Tambin
cuantifica el impacto y la probabilidad de cada uno de ellos, generando un plan de acdn
para responder a esos riesgos cuando se presenten y as poder controlar esa respuesta.
24
Los riesgos se pueden clasificar de acuerdo a su origen:
1. Externos, imprededbles e incontrolables: problemas polticos, sociales, etc.

2. Externos, predecibles e inciertos: impacto ambiental, impacto social,
inflacin e impuestos.
3. Internos y no tcnicos: gerencia, planificacin.
4. Tcnicos: desempeo o rendimiento, diseo, complejidad del proyecto.
5. Legales: licencias, patentes, contratos, etc.
En este proyecto se propone identificar aquellos riesgos tcnicos y no tcnicos

internos de la compaa, con el propsito de mejorar los procesos de gerencia y tcnicos
de desarrollo de software.
2.4.1 Mtodos de gestin de riesgos

Existen diferentes mtodos para organizar la implementadn de las funciones
bsicas que deben llevarse a cabo para una gestin efectiva de los riesgos antes de que
estos lleguen a ser amenazas para el xito. La Tabla 3 muestra los diferentes mtodos de
gestin de riesgos ampliamente conoddos y fcilmente accesibles por sus nombres o por
las organizadones que los avalan: Euromethod, Safe, SEI-CRM, Risklt y los mtodos
para la gestin de riesgos del IEEE y del PMI (Project Management Institute). Es
importante tener presente que cada mtodo establece categoras para las funciones del
riesgo en diferentes fases. La Tabla 3 describe las categoras de cada mtodo (Estvez,
2000).
25
Tabla 3. Mtodos de gestin de riesgo (Estvez, 2000)
Flan de gestin
9
Tratamiento
Seguimiento y control
Identificacin
Estimacin
Evaluacin
Planificacin
Comunicacin
2.4.2 Metodologa de gestin de riesgo desarrollada por el PMI
Con el propsito de plantear una gestin de riesgos eficiente para compaas que
utilizan una mezcla de mtodos giles de desarrollo de software, se utiliza como base la
gestin de riesgos utilizada por el PMI, unido a la utilizacin de herramientas de otras
organizaciones y a las practicas de gestin gil de proyectos.
La gestin de proyecto es la aplicacin de los conocimientos, habilidades,

herramientas y tcnicas necesarias a las actividades de un proyecto, para cumplir con sus
requerimientos. (PMBOK Guide, 2004)
El Project Management Body o f Knowledge del Project Management Institute,

define un proyecto como un esfuerzo temporal, dirigido a crear un producto, servicio o
resultado nico . Temporal no significa necesariamente de corta duracin, ya que
muchos proyectos pueden durar varios aos. Temporal significa que cada proyecto tiene
un comienzo y un final definido. Se alcanza el final cuando se han logrado los objetivos
del proyecto; cuando llega a estar claro que los objetivos del proyecto no pueden ser
satisfechos; o cuando la necesidad del proyecto ya no existe dando este por terminado.
26
La metodologa desarrollada por el PMI, consta de cinco procesos. Cada proceso

ocurre por lo menos una vez en cada proyecto. A continuacin se explicarn
detalladamente, cada uno los procesos que conforman la gestin del riesgo. La Figura 4
presenta el diagrama de flujo de la gestin del riesgo (PMBOK Guide, 2004)
Fase 1: Planificacin
de los riesgos
Fase 2:
Identificacin
de los riesgos
Fase 3: Anlisis
de los riesgos
Fase 4: Respuesta
a los riesgos
Fase 5:
Seguimiento y control
Figura 4. Diagrama de Flujo dlos procesos

de gestin del riesgo
A continuacin se describe paso a paso cada fase del proceso de gestin de riesgos.
Fase 1. Planificacin del riesgo: La planificacin de la gestin de riesgo es el

proceso en donde se definen y planifican las actividades de un proyecto. La Figura 5
presntalos datos de entrada, las herramientas utilizadas y los resultados de este proceso.
27
1.
Datos de entrada
Polticas de la organizacin.
Descripcin del alcance del
proyecto.
2. Herramientas y
tcnicas
Planificacin de
Reuniones, y anlisis
Roles y responsabilidades.
3. Resultados
Plan de riesgos: metodologa,
roles y responsabilidades,
presupuesto para implementar el
plan de riesgos, itinerario, etc.
Plan bsico de la gestin del

proyecto.
Estructuracin de las etapas del
proyecto. (WBS)
Figura 5. Datos de entrada, herramientas y resultados del proceso de planificacin del riesgo
(PMBOK Guide, 2004)
Fase 2: Identificacin del riesgo: La identificacin de riesgos en proyectos consiste

en la determinacin de elementos de riesgos potenciales mediante la utilizacin de algn
mtodo consistente y estructurado. La Figura 6
presenta los datos de entrada, las
herramientas utilizadas y los resultados de este proceso.
l.Datos de entrada
2. Herramientas y tcnicas
Informacin publicada en
la literatura
Revisin de la documentacin:
revisin de los planes y de las
presunciones del proyecto.
Informacin histrica de
proyectos anteriores.
Plan de riesgos planificado
en la etapa anterior.
Plan bsico de la gestin
del proyecto: descripcin
del proyecto, itinerario del
proyecto, plan de recursos
y estimaciones de los
costos y duracin.
Tcnicas de recoleccin de la
informacin: tormenta de ideas
(Brainstorming), tcnica Delphi,
entrevistas, anlisis SWOT (anlisis
de fortalezas, debilidades, amenazas
y oportunidades).
3. Resultados
Registro de los
riesgos: lista de los
riesgos identificados,
causas de los riesgos,
actualizacin de las
categoras de los
riesgos.
Listas de cotejo.
Anlisis de las presunciones.
Tcnicas de representaciones:
diagramas causa-efecto, diagramas
del flujo del proceso, etc.
Figura 6. Datos de entrada, herramientas y resultados del proceso de identificacin de riesgo

(PMBOK Guide, 2004)
28
Fase 3: Anlisis del riesgo: Esta etapa del proceso est partida generalmente en dos
sub-etapas; un anlisis cualitativo, que se centra en la priorizacin de los riesgos
subjetivamente y un anlisis cuantitativo que se centra en la cuantificadn y priorizadn
de los riesgos objetivamente. La Figura 7 presenta los datos de entrada al sistema, las
herramientas utilizadas y la salida para el anlisis cualitativo.
1. Datos de entrada
2. Herramientas y
tcnicas
Informacin histrica de riesgos de

proyectos anteriores.
Probabilidad e impacto
del riesgo.
Plan de riesgos del proyecto.
Matriz de probabilidad e
impacto.
Registro de los riesgos: lista de los

riesgos identificados, causas de los
riesgos, actualizacin de las
categoras de los reseos
Categorizacin de los
riesgos
3. Resultados
Registro de los riesgos

actualizado. Este incluye:
lista priorizada de los
riesgos, riesgos agrupados
por categoras, lista de
riesgos (pie necesitan una
accin inmediata, lista de
riesgos para anlisis
adicionales
Figura 7. Datos de entrada, herramioitas y resultados del proceso de anlisis de riesgo

cualitativo. (PMBOK Guide, 2004)
La Figura 8 presenta los datos de entrada del sistema, las herramientas utilizadas y
los resultados del anlisis cuantitativo
1.
Datos de entrada
Informacin histrica de
riesgos de proyectos
anteriores.
Plan de riesgos.
Registro de riesgos etapa
anterior: lista de riesgos por
importancia, lista de riesgos
para posteriores anlisis,
tendencias y resultados de
anlisis cualitativos.
Plan de lagestin del
proyecto: plan de itinerario y
plan de costos.
2. Herramientas y tcnicas
Tcnicas de recoleccin de
datos: entrevistas,
distribuciones de
probabilidad, y juicio de los
expertos.
Tcnicas de modelacin y
anlisis cuantitativo de los
riesgos: anlisis de
sensibilidad, valor monetario
esperado (EMV), simulacin
montecarlo, Arboles de
decisin
3. Resultados
Registro de riesgos
actualizados: lista de los
riesgos cuantificados,
anlisis probabilistico del
proyecto, anlisis de
probabilidad del costo y
tiempo de ejecucin
Figura 8. Datos de entrada, herramientas y resultados del proceso de anlisis de riesgo

cuantitativo. (PMBOK Guide, 2004)
29
Fase 4 : Respuesta del riesgo: La planificacin de la respuesta del riesgo es el

proceso de desarrollar opciones y de determinar acciones para reducir las amenazas de
los objetivos del proyecto. Incluye la identificacin y la asignacin de individuos para
tomar la responsabilidad de cada respuesta de cada riesgo. Este proceso asegura de que
los riesgos identificados sean tratados correctamente. La eficacia de la planificacin de la
respuesta se determinar directamente si el riesgo aumenta o disminuye para el proyecto.
La Figura 9 presenta los datos de entrada, las herramientas utilizadas y los resultados del
proceso de respuesta al riesgo.
1.
Datos de entrada
Plan de riesgo de la gestin.

actualizados.
Tendencias cualitativas y
cuantitativas del anlisis del
riesgo
2. Haramientas y
tcnicas
Estrategias para los

riesgos negativos: evitar,
transferir, eliminar,
reducir y aceptar.
Estrategias para los
riesgos
positivos
y
oportunidades
3. Respuestas
Registro de riesgos
actualizado.
Plan de gestin del
proyecto actualizado.
Plan de contingencia de
respuesta al riesgo
Planes de contingencia
Figura 9. Datos de entrada, herramientas y resultados del proceso de respuesta al riesgo

(PMBOK Guide, 2004)
Fase 5: Seguimiento y control del riesgo: El seguimiento y control del riesgo es el

proceso de no perder de vista los riesgos identificados, de supervisar riesgos residuales y
de identificar nuevos riesgos, de asegurar la ejecucin de los planes del riesgo y de
evaluar su eficacia en la reduccin de riesgo. El propsito del seguimiento del riesgo es
determinar si las respuestas al riesgo se han puesto en ejecucin segn lo previsto; si han
sido eficaces o si se han desarrollado nuevas respuestas. Determinar si los supuestos del
proyecto siguen siendo vlidos; verificar si la exposicin del riesgo ha cambiado de su
estado anterior y analizar si se siguen las polticas y los procedimientos apropiados.
30
La Figura 10 muestra los datos de entrada, herramientas y resultados del proceso de

seguimiento y control del riesgo.
1. Datos de entrada
Plan de riesgos de la
gerencia.
actualizados.
Cambios aprobados por
la gerencia
Informacin del
desempeo de trabajo.
2. Herramientas y
tcnicas
3. Respuestas
Acciones correctivas.
Auditoria del plan de

respuesta al riesgo.
Sugerencias de cambios
en el proyecto.
Resmenes peridicos de
los planes de riesgo.
Actualizacin del plan

de respuesta al riesgo.
Tcnicas de medicin de
desempeo.
Recomendaciones de
acciones preventivas.
Reportes de rendimiento
Gestin del proyecto

actualizado
Figura 10. Datos de entrada, herramientas y resultados del proceso de seguimiento y control
del riesgo. (PMBOK Guide, 2004)
2.5 Conclusiones
Aunque un proyecto puede tener ms o menos riesgos que otro, no existe ningn
proyecto que no se vea amenazado por algn riesgo. Los proyectos se desarrollan para
que una organizacin alcance un objetivo que le proporcione unos beneficios. Pero
siempre existen algunas dudas en tomo al proyecto que pueden incidir negativamente en
la consecucin del objetivo.
La gestin de riesgos es un proceso que debera llevarse a cabo como parte de las
actividades habituales de toda organizacin dedicada a la generacin y/o mantenimiento
de software. Existen varios modelos de gestin de riesgos, pero el ms aceptado consta de
cinco pasos (Identificacin, Anlisis, Planificacin, Seguimiento y Control).
El propsito de este proyecto fue crear una metodologa continua de gestin de

riesgos innovadora, con el propsito de desarrollar estrategias para tratar los riesgos de
forma proactiva a lo largo del ciclo de vida del proyecto.
3. M ETO D OLOG A
La metodologa propuesta fue desarrollada utilizando como base la metodologa de

gestin de riesgos desarrollada por el PMI, y la metodologa de MSF desarrollada por
Microsoft para desarrollo de software con modelos giles. Adems de eso se
seleccionaron herramientas de identificacin de riesgos, desarrolladas por otras
organizaciones como el SEI (Software Engineering Institute). De esta manera, se puede
decir que la estrategia de identificacin y gestin de riesgos propuesta en este proyecto
resulta innovadora, pues se propone una metodologa de riesgos adecuada a proyectos de
desarrollo de software que utilizan modelos giles. El Anejo 1, describe el cronograma de
actividades desarrollado en este proyecto.
La Figura 11 presenta un flujograma que resume los mtodos y tcnicas que fueron
utilizados en la metodologa. Esta fundamentalmente se encuentra dividida en dos. La
primera parte describe los aspectos a tratar en el perfil de la compaa. Posteriormente se
describe la construccin y administracin de una herramienta de identificacin de riesgos,
desarrollada especficamente para identificar los riesgos tcnicos y organizacionales
existentes en el desarrollo de software. La segunda parte describe la gestin de riesgos
propuesta; que comienza desde la fase de identificacin de riesgos, seguida por la fase de
anfisis utilizando mtodos de anlisis cualitativo y cuantitativo para evaluar los riesgos;
para luego continuar con las fases de planean de respuesta al riesgo, y la fase de
seguimiento y control.
31
32
Perfil d la compaa
Anlisis General del estado actual del proyecto
Evaluacin general del estado actual
Existe alguna
etapa que
necesite una
evaluacin de
V riesgos? .
C onstruccin y adm inistracin de una

herram ienta de identificacin de riesgos
Gestin de Riesgos
Fase 1. Planificacin de los riesgos
Fase 2. Identificacin del riesgo

Identificacin de los riesgos
Anlisis estadstico de los datos
F ase3. Anlisis cualitativo de los riesgos
E v a lu a d n de la probabili dad e im pacto
Evaluacin de los riesgos m s im portantes
E s necesario ^
cuantifcarlos
riesgos para tom ar
la decisin?
Fase 4. Anlisis cuantitativo:

Cuantificacin de los riesgos aplicando
u na herram ienta de anlisis de riesgos.
No
Fase 5. Evaluacin y respuesta de los riesgos

4
4
A nalizar lo s factores de riesgo m s im portantes

D esarrollo de planes de respuesta a los riesgos
Fase 6. Seguimiento y control de los

riesgos
Figura 11. Metodologa aplicada
33
3.1 Perfil de la compaa en estudio

Seleccionar una compaa de desarrollo de software, para poder desarrollar la
metodologa de riesgos no fue tarea fcil. La compaa seleccionada es una compaa
nueva (Start-up) de desarrollo de software en plazos de tiempo corto; que poco a poco ha
desarrollado sus procesos para ser ms competitiva en el mercado. De todas las
compaas que se investigaron, se escogi sta; ya que al estar en expansin, tiene la
necesidad de ir incorporando procesos necesarios que le permitan ser ms competitiva en
el mercado. Posteriormente, con el propsito de conocer la situacin actual, se desarroll
el perfil de la compaa objeto de estudio. Entre los aspectos a mencionar se describen los
siguientes:
Aspectos generales: Historia de la compaa, cantidad de empleados, cantidad

de proyectos capaz de soportar, productos, servicios prestados, entre otros.
Proyecto seleccionado: Descripcin del proyecto seleccionado en el estudio.
Gestin de recursos humanos: Descripcin de la estructura organizacional de la
compaa, la forma de administrar las responsabilidades dentro de los proyectos
y la administracin de los recursos.
Metodologa aplicada: Descripcin de la metodologa desarrollada por la
compaa, el ciclo de vida utilizado y su forma de desarrollar los proyectos.
Tcnicas de planificacin y control de proyectos: Descripcin de los mtodos y
herramientas utilizadas por la compaa para la gestin de proyectos:
planificacin del itinerario y el presupuesto, manejo de la comunicacin interna
y externa y planificacin de las actividades del proyecto.
Gestin de riesgos: Descripcin de la forma de manejar los riesgos en los
proyectos, sus mtodos y tcnicas.
34
3.2. Anlisis general del estado actual del proyecto

En sta etapa se identifica y analiza la viabilidad de la gestin de riesgos en el
proyecto. Se realizaron entrevistas informales con los lderes de los equipos de desarrollo
y con el supervisor de stos; con el propsito de conocer su punto de vista sobre la
compaa. Por otra parte se cont con personal experto en el tema como apoyo para
analizar el proyecto desde un punto de vista ajeno a cualquier inters. Con esto y con la
informacin recogida en el perfil de la compaa se concretiz la viabilidad de la gestin
de riesgos en este proyecto.
3.3 Construccin, administracin y anlisis de una herramienta de identificacin de

riesgos.
La identificacin de riesgos en proyectos de software consiste en la determinacin
de elementos de riesgos potenciales mediante la utilizacin de algn mtodo consistente y
estructurado. Actualmente, no existen herramientas que brinden un soporte adecuado y
estandarizado a los administradores de proyectos durante la fase de identificacin de
riesgos, para aquellas organizaciones que estn implementando formalmente las tareas de
gestin de riesgos. (Peteison, 2000).
La herramienta seleccionada en este proyecto consiste en la construccin de un

cuestionario especializado en identificar riesgos tcnicos y organizadonales en el
desarrollo de software; tomando como base las herramientas de identificacin de riesgos
desarrolladas por el SEI. En esta etapa se describen las herramientas utilizadas y el
proceso llevado a cabo para administrar, disear y analizar
una herramienta de
identificacin de riesgos.
35
3.3.1 Construccin del cuestionario de identificacin de riesgos

Un cuestionario es el procedimiento de recoleccin
de informacin de una
investigacin. Por tanto, no puede haber preguntas infundadas, sino que, por el contrario,
cada una de ellas debe estar conectada con algn aspecto del problema planteado en la
investigacin.
Autores como Peterson (2000) presentan una serie de tareas que se deben realizar
para construir cuestionarios efectivos. La Figura 12 describe los pasos realizados en este
proyecto para la construccin del cuestionario.
Revisin de la informacin que se quiere

obtener por medio del cuestionario
Identificacin de preguntas, redaccin y
diseo del cuestionario
1. Bsqueda
de
herramientas
de
identificacin de riesgos en la literatura.
2. Depuracin del cuestionario encontrado
en la literatura
3.Refoimulacin de las preguntas
cambio de escala
4. Identificacin y redaccin de nuevas

preguntas potenciales.
Estructuracin del cuestionario
Validacin y cuestionario final
Figura 12. Etapas de construccin dd cuestionario de identificacin de riesgos
36
1. Revisin de la inform acin que se requiere recoger p o r medio del

cuestionario de identificacin de riesgos: El objetivo del cuestionario es identificar los
riesgos tcnicos y organizadonales a los cuales se enfrentan compaas pequeas de
desarrollo de software en plazos cortos.
2. Identificacin de preguntas, redaccin y diseo del cuestionario: La

investigacin por cuestionarios se fundamenta en la informacin que se extrae
interrogando a los sujetos que componen la muestra mediante una serie de preguntas
dirigidas. La exactitud de los datos obtenidos depende, netamente, de cmo est
formulado el instrumento. Su redaccin es una tarea compleja que exige prestar atencin
a multitud de cuestiones. A continuacin se describen las pasos desarrollados en la
identificacin, redaccin y diseo del cuestionario.
a. Bsqueda de herram ientas de identificacin de riesgos en la literatura:

Luego de tener claro el propsito del cuestionario, se realiz una indagacin previa al
diseo del cuestionario sobre herramientas ya elaboradas por otros autores, relacionados
con la identificacin de riesgos en proyectos de desarrollo de software. Esto incluye
consultar a expertos, revisar la bibliografa y en los archivos de datos de encuestas.
Cea (1996) seala que algunas de las ventajas de utilizacin de cuestionarios hechos
por otros autores es que permite replicar los hallazgos de estudios anteriores en una
poblacin distinta o en una fecha posterior; es posible estimar la fiabilidad de las
respuestas, contrastndolas con las recogidas en estudios realizados con poblaciones y
contextos similares y posibilita analizar la tendencia de los datos si se observan cambios
en los resultados obtenidos con respecto a los estudios anteriores.
Dentro de la bsqueda en la literatura, se encontr que la identificacin de riesgos a

base de taxonomas ha sido motivo de inters creciente en la industria de software y tiene
su referencia fundamental en el trabajo presentado por el SEI en el ao 1993, titulado
Taxonomy-Based Risk Identification (Carr, 1993).
37
Su objetivo es colaborar en la identificacin de riesgos segn categoras tpicas,

facilitando a los equipos de proyecto explorar riesgos potenciales que podran no haber
sido considerados de otro modo. Por estas razones, se decidi tomar como base la
herramienta desarrollada por el SEI. La Tabla 4 muestra la estructura de esta taxonoma.
Tabla 4. Estructura dd cuestionario desarrollado por d SEI
Requerimientos
1
Ingeniera del
producto
Diseo
Cdigo y Unidad de prueba
Integracin y prueba
Especialidades ingeniera
Desarrollo de procesos
Ambiente
de
desarrollo
Desarrollo del sistema

Gestin de los procesos
Gestin de los mtodos
Ambiente laboral
Restricciones
del programa
Recursos
Contrato
Programa de interfaces
b.
Depuracin del cuestionario encontrado en la revisin de literatu ra: En esta
etapa se identificaron las preguntas ms relevantes del cuestionario desarrollado por el

SEI. Se trabaj con personal experto en el tema (Ing. de software Elizabeth Crdoba e
Ing. Arturo Silva). Estos se encargaron de asegurar que el cuestionario a desarrollar sea
adecuado para compaas pequeas de desarrollo de software; seleccionando slo las
preguntas relevantes y eliminando aquellas que no aportan nada a este proyecto.
38
c.
Reform ulacin de las preguntas y cambio de escala: Debido a que el
cuestionario base del SEI, est diseado con preguntas cerradas en una escala discreta (S
y No), se reformularon las preguntas, a preguntas cerradas usando la escala de Likert,
con el propsito de evitar la fatiga del personal y facilitar el proceso de anlisis.
La tcnica de Likert es una de las ms utilizadas para medir actitudes. Se presentan

un conjunto de declaraciones positivas y negativas referidas a lo que se desea medir y se
le pide que muestre su grado de acuerdo o desacuerdo con cada afirmacin. Aunque la
forma de responder puede variar, las categoras de respuesta suelen ser: a)
Completamente de acuerdo; b) De acuerdo; c) Indiferente; d) En desacuerdo; e)
Completamente en desacuerdo. En este caso se utiliz las siguientes categoras: Nunca,
En ocasiones, En promedio, Casi siempre, Siempre. La Figura 13 muestra un ejemplo
de las preguntas y la escala seleccionada.
B.4 AM B IE N TE LABORAL
C oopw acin_____________________
|
[121] El personal trabaja en equipo para alca n za rla s

m etas en comn?
r
|
Nunca
o casio n es
En promedio
Casi siem pre
Siempre
Figura 13. Redaccin de la pregunta y manejo de escala
d.
Identificacin y redaccin de nuevas preguntas potenciales: En esta etapa se
elaboraron en conjunto con el personal experto en el tema, aquellas preguntas necesarias

para completar el cuestionario de identificacin de riesgos para compaas pequeas
desarrollo de software en plazos cortos. Estas preguntas se desarrollaron siguiendo el
mismo estilo que las anteriores; preguntas cerradas con escala de Likert.
39
3. E structuracin del cuestionario: Seleccionadas las preguntas potenciales, se

procede a organizaras de acuerdo a un orden. El orden en que se coloquen las preguntas
es tambin un tema de gran importancia. En esta etapa se realiz el orden lgico del
cuestionario. Para empezar se desarroll un breve mensaje de presentacin, explicando
quin realiza la encuesta, adems de los objetivos perseguidos en este estudio, el tipo de
informacin que se precisa y motivando al encuestado con los beneficios que puede
reportar su participacin. Adems, de esto se garantiz el anonimato, pues en ninguna
parte hace referencia al nombre del encuestado. En cuanto al flujo del cuestionario, se
realiz de una manera lgica. Las preguntas relativas a un mismo tema se presentaron
juntas, formando grupos de preguntas comunes.
4. Validacin del cuestionario y cuestionario final: Una vez que se ha diseado el

cuestionario con el que se va a recolectar la informacin que se busca con la
investigacin, es preciso validar el instrumento. Para esto se cont con personal de la
compaa, permitindonos medir el grado de efectividad de la herramienta. El propsito
es evaluar cada una de las preguntas: si las preguntas tienen sentido y si la categorizadn
de las preguntas cerradas y su codificadn es correcta, si se comprenden bien las
instrucdones y si la duracin del cuestionario no cansa al encuestado. Cmo resultado,
las preguntas que se determin no estaban claras, fueron revisadas y refraseadas.
Posteriormente se evaluaron nuevamente, hasta que se determin que todas las preguntas
estaban claras y los errores potenciales haban sido eliminados.
Finalmente, se obtuvo un cuestionario con 124 preguntas de selecdn mltiple

conformado por una escala de 5 tems (Nunca, En ocasiones, En promedio, Casi siempre
y Siempre) y 9 preguntas abiertas, dirigido prindpalmente al personal de la compaa en
general, concentrndose en la identificacin de riesgos tcnicos y organizadonales;
dejando por fuera los riesgos polticos, del ambiente, de negocios, entre muchos ms. La
Tabla 5 muestra la estructura del cuestionario desarrollado en este proyecto. El
cuestionario detallado se encuentra en el Anejo 2.
40
Tabla 5. Estructura del cuestionado desarrollado en este proyecto
Grupo de preguntas
Ingeniera
del producto
1-7
Estructura de los requerimientos
8-15
Factibilidad de los requerimientos
16-25
Estructura del Diseo
26-35
Diseo desarrollado y reusado
36-43
Desarrollo del cdigo e implementacin
44-52
Lenguajes y tecnologa existente
53-60
Ambiente de integracin y prueba (testing)
61-69
Integracin del producto, del sistema y prueba (testing)
70-78
Especialidades de Ingeniera: Entendimiento y

mantenimiento del software
Especialidades de Ingeniera: Desarrollo de los
requerimientos de seguridad y confiabilidad
Especialidades de Ingeniera: Desarrollo de
requerimientos de proteccin al software, requerimientos
de factores humanos y desarrollo de especificaciones.
Desarrollo de procesos y del sistema
79-87
88-97
Entorno de
desarrollo
Nombre del grupo
98-108
109-115
Gestin de los procesos
116-124
Comunicacin entre los participantes
La estructura del cuestionario, qued dividida en 14 grupos, conformados por

preguntas relacionadas al tema. La idea es conocer los factores ms importantes que
pueden presentar un riesgo en todo el ciclo de vida de desarrollo del software.
Las preguntas del 1-7, conforman el grupo de estructura de los requerimientos. El

propsito es identificar
en qu se est fallando al definir los requerimientos. Las
preguntas desarrolladas hacen referencia a atributos como: estabilidad, complejidad,

claridad, entre otros.
Las preguntas 8-15, conforman el grupo de factibilidad de los requerimientos.

Aspectos como factibilidad, precedencia, complejidad son analizados, con el propsito de
identificar las variables que ms afectan este proceso.
41
Las preguntas 16-25, conforman el grupo de preguntas relacionadas con la

estructura del diseo. Aspectos como factibilidad del diseo, complejidad y definicin
del diseo, son planteados con el propsito de conocer las variables que ms afectan la
etapa de diseo.
Las preguntas 26-35, conforman el grupo de diseo desarrollado y cdigo re-usado.

Aspectos como sencillez del diseo, limitaciones, complejidad, son planteados con el
objetivo de conocer las variables que ms afectan el desarrollo del diseo.
Las preguntas
36-43,
conforman
el grupo
de desarrollo
del
cdigo
implementacin. Aspectos como la calidad y estabilidad del software o especificaciones

de interfaces y restricciones que se pueden presentar en la implementacin; son tratados
en este grupo.
Las preguntas 44-52, conforman el grupo de lenguajes y tecnologa existente.

Aspectos como viabilidad del lenguaje utilizado y dificultad en el desarrollo de las
aplicaciones con la tecnologa existente; son planteados para conocer las variables ms
importantes en la utilizacin de lenguajes y tecnologa.
Las preguntas 53-60, conforman el grupo de ambiente de integracin y prueba.

Aspectos como disponibilidad y limitaciones de los recursos son planteados con el
propsito de conocer las variables que ms afectan este grupo.
Las preguntas 61-69, conforman el grupo de integracin del producto, del sistema
y prueba. Aspectos como definicin del proceso de integracin, tiempo asignado, son
planteados con el propsito de conocerlas variables ms importantes.
Las preguntas 70-78, 79-87 y 88-97 conforman el grupo Especialidades de

Ingeniera. Se llama as, porque son especialidades que necesitan de un conocimiento ms
especfico.
42
Las preguntas
70-78 identifican los problemas
con
el entendimiento y
mantenimiento del software. Las preguntas 79-87, identifican los problemas referentes al
desarrollo de los requerimientos de seguridad y confiabilidad del software. Las preguntas
88-97, identifican los problemas referentes al desarrollo de los requerimientos de
seguridad (proteccin externa), desarrollo de los requerimientos humano computador y
desarrollo de las especificaciones.
Las preguntas 98-108, conforman el grupo de desarrollo de procesos y del sistema.
Aspectos como control de cambios, recursos, infraestructura, pueden afectar este grupo.
Las preguntas 109-115, conforman el grupo de gestin de procesos. Aspectos como
planificacin de las actividades, planes de contingencia, experiencia del personal, son
planteados con el objetivo de conocerlas variables que ms afecta este grupo.
Las preguntas
116-124, conforman el gmpo
de comunicacin entre los
participantes. Aspectos como conflictos con el cliente, satisfaccin del cliente, relacin
con el equipo de trabajo, son planteados.
La herramienta de identificacin de riesgos propuesta tiene como objetivo captar
los factores que ms afectan el proceso de desarrollo de software en plazos cortos en
compaas pequeas. Se administra la herramienta al personal de la compaa caso
estudio, se realiza un anfisis estadstico y se describen los factores; los cuales sern
utilizados en el proceso de gestin de riesgos.
3.3.2. A dm inistracin y anlisis de la herram ienta de identificacin de riesgos

l anfisis de los datos persigue dar respuesta a las cuestiones planteadas, que sern
de dos tipos: una primera aproximacin que nos informa de las opiniones de los
encuestados en cada pregunta realizada y en segundo lugar, los resultados que proceden
de cruzar las respuestas de un grupo de preguntas, respondiendo de esta forma a
interrelaciones entre variables.
43
Los pasos para identificar los factores de riesgos ms significativos son: Anlisis de
confiabilidad y validacin; descripcin del tamao de muestra, identificacin de los
principales factores de riesgos aplicando anlisis factorial; con el propsito de encontrar
grupos de variables con significado comn y conseguir de esta manera el nmero de
dimensiones necesarias para explicar las respuestas de los sujetos y anlisis de resultados.
3.3.2.1. Validacin del cuestionario
Luego de que todas las precauciones y cuidados han sido tomados cuando se disea
el cuestionario es necesario verificar su validez. Se verific la validez de contenido y la
validez de construccin.
Para verificar la construccin de la herramienta, se aplic una lista de cotejo

encontrada en la literatura referente a la construccin de cuestionarios; preguntas,
escala y dems. Ver anej o 3.
Validacin de construccin: En la etapa de construccin del cuestionario, se

seleccion una muestra conformada por personas de la compaa, con el propsito
de evaluar el cuestionario en general, identificando las preguntas que no tienen
sentido y verificando la codificacin en general.
3.3.2.2 Tamao de muestra del cuestionario

Constituye una de las fases ms importantes del estudio, pues se seleccionan a los
sujetos concretos que formarn la muestra. En esta etapa se describe el tamao de
muestra del cuestionario y se realiza un perfil de los encuestados.
44
3.3.2.3 Anlisis Factorial
Con el propsito de identificar cuantitativamente los riesgos ms importantes se

utilizan las tcnicas de anlisis multivariado. El anlisis multivariado es el conjunto de
mtodos estadsticos cuya finalidad es analizar simultneamente conjuntos de datos
multivaiiantes en el sentido de que hay varias variables medidas para cada individuo
objeto estudiado. Su razn de ser radica en un mejor entendimiento del fenmeno objeto
de estudio obteniendo informacin que los mtodos estadsticos univariantes y
bivaiiantes son incapaces de conseguir (Figueras, 2000).
El anlisis factorial es una tcnica utilizada para explicar un conjunto de variables

observables mediante un nmero reducido de variables no observables llamadas factores.
La razn de utilizar el anlisis factorial es porque en ste, todas las variables son
independientes en el sentido que no existe a priori una dependencia conceptual de unas
variables sobre otras; a diferencia de lo que ocurre en otras tcnicas como el anlisis de
varianza o de regresin. El anlisis empieza con una evaluacin sobre la adecuacin del
anlisis factorial mediante el anlisis de correlacin; posteriormente se desarroll la
extraccin de factores por el mtodo de componentes principales y se realiz una rotacin
posterior por el mtodo ortogonal Varimax; identificando finalmente los factores
principales de riesgo. La Figura 14 m ustralas etapas del anlisis factorial.
45
Anlisis de la matriz de correlaciones
Extraccin del nmero ptimo de factores

Extraccin y grfica de factores iniciales
Rotacin de la solucin para una mayor

interpretacin. Mtodo usado VARIMAX
Seleccin de las variables que conforman
el factor y nombramiento del factor
Figura 14. Pasos para realizar un anlisis factorial
1. Anlisis de la m atriz de correlaciones: Para decidir el uso del anlisis factorial

se analiz la matriz de correlaciones y se calcul su determinante con el propsito de
comprobar estadsticamente si existe o no correlaciones entre las variables.
2. Extraccin del nm ero ptimo de factores: Con el propsito de evaluar el

nmero Optimo de factores, se emplea la prueba de bondad y ajuste para el modelo de
anlisis de tactores (tests of overall goodness-of-fit o fthe factor analysis model).
3. Factorizacin o extraccin de factores y grfica de factores: Una vez fijado el

nmero de factores, puede precederse a realizar el anlisis de factores definitivo, cuyo
objetivo es averiguar el nmero de factores comunes necesarios para explicar las
correlaciones halladas. Para esto existen distintos mtodos, entre los ms importantes se
encuentran el mtodo de ejes principales y el mtodo de componentes principales. En este
caso se us el mtodo de componentes principales que se emplea dentro del anlisis
factorial, porque usa algoritmos similares y porque explora toda la varianza de cada
variable.
R eproduced with perm ission o fth e copyright owner. Further reproduction prohibited without permission.
46
4. Rotacin de la solucin p ara facilitar su interpretacin: Para facilitar la

interpretacin, se procede a realizar la rotacin de los factores, con el propsito de
conseguir soluciones factoriales menos ambiguas y ms significativas. La rotacin de los
factores es una tcnica iterativa que supone girar en el origen los ejes de referencia de los
factores hasta alcanzar cierta posicin. El tipo de rotacin ms usada es la ortogonal, al
mantener independiente los componentes finales. Por su parte la rotacin oblicua muestra
una mayor interpretabilidad, permitiendo que los componentes estn relacionados entre
s. Dentro de los modelos de rotacin ortogonal se encuentran distintas tcnicas, como
varimax, equamax y quartimax y en los modelos de rotacin oblicua tenemos promax y
oblimin.
5. Factores principales en el desarrollo de software: Una vez obtenido el anlisis

factorial definitivo, basndose en los valores de las cargas factoriales de cada variable
obtenidas por el mtodo de rotacin elegido, se interpreta la naturaleza de lo que se est
midiendo con cada uno de los factores.
3.3.2.4 Anlisis de regresin

En esta etapa los factores definidos en el anlisis factorial se utilizan en el anlisis
de regresin contra una variable dependiente, para conocer cuales son los factores ms
relevantes estadsticamente. El anlisis de regresin se utiliz, ya que es una tcnica
estadstica creada para investigar y modelar la relacin entre variables. La Figura 15
resume los pasos para realizar el anlisis de regresin (Chatteqje, 2000; Montgomery,
2001).
47
Formulacin del problema
Identificacin de las variables
Recoleccin de informacin
Formulacin preliminar del modelo
Estimacin de los parmetros
Comprobacin de la significancia del modelo
Recalculo de los parmetros con las

mejoras sugeridas en el anlisis de
residuales
Utilizacin del modelo seleccionado para

predecir
Figura 15. Pasos a seguir para realizar un anlisis de regresin
1. Form ulacin del problem a: En esta etapa se formula el problema que se desea
investigar, con el propsito de no perder tiempo ms adelante en resultados inesperados.
2. Identificacin de las variables relevantes: Se identifican las variables

relevantes, las cuales pueden ser de dos tipos: variable dependiente o variable respuesta
(Y) y variables independientes, tambin llamadas de prediccin o regresoras, (X I, X 2 ,...,
Xp) siendo p el nmero de variables independientes. Sin embargo, desde el punto de vista
estadstico, hay que tener en cuenta la correlacin entre las variables, independientes y
dependiente, que forman parte del modelo. Para el anlisis estadstico, la situacin ideal
es la de un conjunto de variables independientes correlacionadas significativamente con
la variable dependiente, y dbilmente correlacionadas entre s.
48
3. Recoleccin de los datos: Una buena recoleccin de datos asegura un anlisis

simplificado y un modelo ms aplicable. En esta fase la informacin de entrada se
recolecto del anlisis de factores realizado anteriormente.
4. Form ulacin prelim inar del modelo: El modelo de regresin puede ser lineal o
no lineal. La ecuacin de regresin puede ser clasificada como simple o mltiple. La
ecuacin de regresin simple tiene solo una variable regresora (X), por otro lado la
ecuacin de regresin mltiple tiene ms de una variable regresora. Herramientas como
diagramas de dispersin (grficas de Y vs X) y anlisis de correlacin, permiten
identificar la forma preliminar del modelo.
5. Estim acin de los parm etros: El mtodo de cuadrados mnimos es utilizado

para estimar los coeficientes de regresin o parmetros Po hasta Pj, donde PO es el
intercepto y Pj es la pendiente. El estimado de la varianza es requerido para hacer las
pruebas de hiptesis y construir intervalos estimados de la regresin del modelo.
6. Anlisis
si el modelo es significativo: Un modelo es significativo si las
variables independientes son capaces de predecir el comportamiento de la variable

dependiente. La prueba de hiptesis a probar es:
H0: B i=B2=. . .=Bk=0
Ha= Bj 4 0 para al menos una j . Si el valor P es menor o igual que rechazo H0 lo que
indica que el modelo es significativo.
Adems de esto, debe cumplir con las siguientes presunciones bsicas:
La relacin entre la variable respuesta y las variables regresoras es linear, al

menos aproximadamente.
El promedio de los errores (pe) es igual a cero.

La varianza (o2) de los errores es constante.
Los errores estn normalmente distribuidos.
Los errores son independientes.
49
En caso que alguna de estas presunciones no se cumplan, se tendr un modelo

instable en el sentido de que con una muestra diferente las conclusiones pueden ser
diferentes y opuestas. Una vez se determina que se cumple con las presunciones para
realizar una regresin, mediante el anlisis de residuales se identifica si es necesario
mejorar el modelo; ya sea realizando trasformadones, aadiendo nuevas variables o
eliminando los puntos espurios.
8. Reclculo de los parm etros con las m ejoras sugeridas en el anlisis de

residuales: Una vez mejorado el modelo se vuelven a calcular los parmetros de
regresin utilizando el mtodo de cuadrados mnimos.
9. Utilizacin del modelo seleccionado p ara predecir: En este paso el modelo

puede ser utilizado para predecir observadones futuras correspondiendo a valores
espedirnos de las variables regresoras.
3.4 Gestin de riesgos
El objetivo de la gestin de riesgos es identificar, estudiar y eliminar las fuentes de

riesgo antes de que empiecen a amenazar el cumplimiento satisfactorio de un proyecto de
software. En esta seccin se trata de propordonar una visin general del proceso de
gestin de riesgos diseado y utilizado en el proyecto en estudio. Incluye la selecdn de
un marco de gestin de riesgos, el equipo encargado para llevar a cabo el proceso y la
descripdn del plan de gestin de riesgos.
La metodologa propuesta fue desarrollada utilizando como base la metodologa de

gestin de proyectos del PMI. Esta se seleccion por dos motivos: PMI -Project
Management Institute es una organizacin mundialmente reconocida y su metodologa de
gestin de proyectos est muy detallada y es aplicada en la industria frecuentemente.
50
Adems de eso se seleccionaron herramientas de identificacin de riesgos,

desarrolladas por otras organizaciones como el SEI (Software Engineering Institute); con
el propsito de desarrollar una metodologa gestin de riesgos innovadora compaas
pequeas de desarrollo de software; ya que combina las diferentes herramientas de los
mtodos ms eficientes en el tema de gestin de proyectos. A continuacin se describen
las diferentes fases de gestin de riesgo en el proyecto abordado.
3.4.1 Fase 1: Planificacin de riesgos
El objetivo de esta fase es describir como sern abordados y planeadas las

actividades de riesgos del proyecto. Como resultado se desarrollar un plan de manejo de
riesgos, que documente como sern estructurados y realizados los procesos de
identificacin, anlisis cualitativo, cuantitativo, planeadn de respuesta, monitoreo y
control. Adems de eso, se definen las responsabilidades y recursos recomendados para
administrar los riesgos del proyecto en estudio y sigue las recomendaciones de las
metodologas tradicionales descritas anteriormente.
El proceso comienza con la identificacin inicial de la lista de riesgos.

Posteriormente se analiza cada uno de estos riesgos, identificando y priorizando los
riesgos ms importantes. Se plantean estrategias de respuesta a los riesgos y se les da
seguimiento. La Figura 16, describe el proceso de gestin de riesgos continuo propuesto,
como tambin los roles principales y las responsabilidades necesarias para que ste
funcione.
51
Riesgos
importantes
Jefe del proyecto
Asignar
Manej o de riesgos
Responsabilidades
P orizar
A signar
Controlar
A nlis de riesgos
Responsables
de Area
Planificacin de
respuesta a los riesgos
C lasificar
C uantificar
Im pacto..........
Probabilidad
Equipo interno
de la gestin
de riesgos
A probar planes
R ecom endar planes
Indicadores
Riesgos
Personal
Identificacin de riesgos
Seguimiento
Estado
Progreso
Estado
Reporte
Pronsticos
Figura 16. Proceso de gestin de riesgos contino
En este proyecto se plantea la gestin de riesgos inicial, y se proponen

recomendaciones para que el proceso sea continuo. A continuacin se describen los roles
y responsabilidades que deben ser asignadas al personal para dar continuidad a la gestin
de riesgos propuesta.
Personal del proyecto: El personal de la compaa deber ser responsable de

identificar los nuevos riesgos, estimar su probabilidad e impacto, clasificar los
riesgos, recomendar acciones de respuesta a los riesgos, dar seguimiento a los
riesgos y ayudar a priorizar los riesgos.
Responsables de rea: Los responsables de cada equipo o rea, en este caso los
Team Leader; debern integrar la informacin de todos los riesgos, asegurar la
precisin de las estimaciones de probabilidad, del impacto y la clasificacin,
reconsiderar la prioridad de todos los riesgos para determinar los riesgos ms
importantes,
revisar recomendaciones
para las
acciones
de
mitigacin,
52
implementar decisiones de control sobre los riesgos, construir planes de accin,

recoger e informar sobre las medidas del riesgo, e informar peridicamente al jefe
del proyecto sobre la situacin de los riesgos.
Jefe del proyecto: Este deber autorizar recursos para la mitigacin, integrar la
informacin recolectada por todos los responsables de rea sobre los riesgos,
revisar la prioridad de todos los riesgos para determinar cules son los riesgos
importantes, tomar decisiones de control sobre estos riesgos, asignar y cambiar
responsabilidades de los riesgos y sus planes de mitigacin dentro del proyecto,
revisando las mtricas peridicamente y conjuntamente con el rea de calidad,
para evaluar la efectividad de la gestin del riesgo.
Equipo interno de gestin del riesgo: Se recomienda formar un equipo interno

de gestin de riesgos, el cual estar encargado de coordinar las actividades para
identificar y analizar los riesgos, mantener la lista de los riesgos del proyecto,
notificar nuevos riesgos e informar peridicamente al jefe del proyecto el estado
actual de los riesgos. Este proceso tambin puede ser realizado por el personal
encargado de supervisar la calidad del producto.
La Figura 17 presenta las herramientas y tcnicas a utilizar en este proyecto de

gestin de riesgos.
Reproduced with permission ofthe copyright owner. Further reproduction prohibited without permission.
Anlisis general de la compaa

Lista de riesgos de proyectos anteriores
Lista de riesgos publicados en la literatura
Salidas de planificacin de otras reas
Plan de gestin de riesgos
riesgos
lis ta de riesgos desarrollado m a e apa deidentifit acin

Escala de probabilidad e impacto
"Tipo de proyecto
C/StaoQ oei proyecto-
Tiempo real d elo stiem o o s de eiecu :in
Seales de alarma
Entradas a otros procesos
dentiEpadnid:
Riesgos
Categorizacin de los riesgos^
Anlisis
cualitativo d los
riesgos
Lista p no rizada de riesgos

Riesgos pn onzados
Lista priorizada de riesgos
Probabilidad de cumplir con las fech|s y costos
A n ia s
Cuantitativo de
lsriesgos
Lista de nesgos pnonzados
Salidas de planificacin de otras re
Top 10 de riesgos
Planificacin de los recursos
Estr#egias mitigacin de n esgos
Planes de contingencias
^ l i t a c i n de
r e ^ ip t a a l
. :L:igo
Plan de respuesta a lo s riesgos
Nuevos riesgos
Estado de los planes de accinfc

Estado de la tu a d n de los riesgos
Seguimiento y Planes de control de riesgos
control de riesgos Identificacin de nuevos
Asignacin de responsables para c/riesgo
Revisin peridica de los r i e s e s
Figura 17. Herramientas y tcnicas utilizadas en d proceso de gestin de riesgos.
U\
54
3.4.2 Fase 2: Identificacin de riesgos
La meta en la identificacin de riesgos es la elaboracin de una lista de los riesgos

con los que el equipo deber enfrentarse. Esta lista debe ser lo ms extensa posible y
deber cubrir todas las reas del proyecto. En Figura 18 se describe el proceso de
identificacin de riesgos que se plantean en este proyecto: entradas, actividades y salidas.
Cuestionario final,
tomando como base
al cuestionario del
S E I ____
1. Identificacin de la lista
de riesgos del proyecto
Anlisis general
proyecto y lista de
riesgos de proyectos
similares en la
compaa
Lista provisional de los

riesgos del proyecto
Lista de riesgos
publicados en la
lite ra tu ra ___
Comparacin de la lista de
riesgos del proyecto con
otras listas
2. Proceso
continuo de
identificacin
de riesgos
Lista final de riesgos del

proyecto
Figura 18. Proceso de identificacin de riesgos
1.
Datos de entrada: La identificacin de riesgos tiene como insumo toda la
informacin disponible acerca de riesgos generales y especficos de los proyectos, tanto

en las reas de negocios, tcnicos, organizativos y del entorno. Otros aspectos adicionales
son la experiencia del equipo, el enfoque organizativo actual ante los riesgos e
informacin acerca del proyecto, incluido su estado actual y su historial.
55
El equipo es libre de poder elegir otras fuentes de informacin. Debe tenerse en

cuenta todo aquello que el equipo considere de ayuda para identificar el riesgo. Al iniciar
el proyecto es muy til compartir los conocimientos, realizar sesiones dirigidas o incluso
talleres para obtener informacin sobre las percepciones que el equipo del proyecto y los
accionistas tienen acerca de los riesgos y las oportunidades.
2.
Actividades: Para identificar los riesgos relevantes de los proyectos, se
desarroll una herramienta de identificacin de riesgos propia, la cual fue aplicada en la

compaa caso estudio, tomando como base las herramientas de identificacin de riesgos
desarrolladas por el SEI. De todas formas el equipo est en la capacidad de recurrir a
otras herramientas existentes en la literatura; como los esquemas de clasificacin de la
industria, la taxonoma de riesgos de SEI Software, las listas de control de proyectos, los
informes de resumen de proyectos anteriores, as como cualquier flente de informacin
publicada.
Una vez aplicada la herramienta, se procede a identificar la lista inicial de riesgos.
Posteriormente se realizan entrevistas informales a los lderes del equipo y supervisores
para obtener un panorama de los riesgos existentes de acuerdo a su experiencia y
lecciones aprendidas. Esto, unido a las listas de riesgos recolectadas en la literatura, nos
ayudan a obtener una lista maestra de riesgos actualizada, por todos los miembros del
equipo, personal de desarrollo, supervisores y especialistas en el tema.
3.4.3 Fase 3. Anlisis de los riesgos
La asignacin de prioridades a los riesgos permite a los integrantes del equipo tratar
en primer lugar los riesgos ms importantes del proyecto. Esta fase tiene como propsito
realizar un anfisis cualitativo de los riesgos para piiorizar sus efectos sobre los objetivos
del proyecto, lo cual conlleva a evaluar el impacto y probabilidad de los riesgos
identificados. El anfisis de riesgos en el proyecto en estudio se organiz en tres pasos:
anfisis cualitativo de los riesgos, clasificacin y priorizacin de los riesgos.
Posteriormente se proceder a cuantificarlos en caso de ser necesario.
56
1.
Anlisis cualitativo de los riesgos: Durante sta etapa, el equipo examina la lista
de elementos obtenidos en la identificacin de riesgos y les asigna una prioridad,

registrando el orden final en la lista maestra de riesgos. Usando esta lista, el equipo puede
determinar los riesgos que son ms importantes y reservar recursos para planificar y
ejecutar una estrategia especfica. El equipo tambin puede identificar los riesgos que,
por su poca prioridad, pueden quitarse de la lista.
A medida que el proyecto se acerca al final y las circunstancias del mismo van
cambiando, la identificacin y el anlisis de riesgos se repetirn y la lista maestra de
riesgos se modificar. Puede que surjan nuevos riesgos y puede que los riesgos ms
antiguos que han bajado de prioridad se eliminen o desactiven. Estos anlisis de riesgos
deben llevarse a cabo como apoyo para la asignacin de prioridades empleada en la toma
de decisiones y nunca debe realizarse pensando nicamente en el anlisis. Los datos de
entrada y las salidas de esta fase estn representados en la Figura 19.
Listamaestra de
riesgos desarrollada
en la etapa de
identificacin
Definicin y evaluacin de
probabilidad e impacto
Clasificacin inicial y priorzacin

de los riesgos
Actualizacin de la lista inicial de

riesgos
Figura 19. Proceso de anlisis cualitativo dlos riesgos
1.
Datos de entrada: El equipo recurrir a la experiencia e informacin en la
literatura, en la seleccin de las escalas para medir cualitativamente el riesgo. La

informacin necesaria para priorizar los riesgos cualitativamente se recoger del paso
anterior, en donde se obtuvo la lista maestra de los riesgos.
57
2.
Actividades: En la literatura existen varias tcnicas cualitativas y cuantitativas
para asignar las prioridades a una lista de riesgos. El PMI recomienda la evaluacin de la
matriz de probabilidad e impacto. sta consiste en tomar las decisiones reunidas por el
equipo en dos de los componentes de riesgo ms universales: probabilidad (la
probabilidad de que el riesgo ocurra) e impacto (la prdida o efecto negativo en un
proyecto en caso de que ocurra el riesgo). Posteriormente se multiplican los valores de
probabilidad e impacto, dando origen a una mtrica denominada exposicin al riesgo.
a.
Definicin de la m atriz de probabilidad e impacto: La severidad de cualquier
riesgo se define en trminos del impacto en los objetivos del proyecto y la probabilidad
de ocurrencia del riesgo. Este paso se divide en dos: definicin de la escala a utilizar en la
matriz y evaluacin de los riesgos en la matriz de probabilidad e impacto.
La probabilidad de un riesgo debe ser mayor que cero o el riesgo no representa una
amenaza para el proyecto. Las probabilidades son difciles de calcular y aplicar; sin
embargo, la mayora de los equipos de proyecto pueden expresar con palabras sus
experiencias, interpretar los informes y proporcionar una amplia gama de expresiones de
lenguaje natural para indicar rangos de probabilidad numricos. La Tabla 6 siguiente
describe la escala a utilizar cuando se define la probabilidad.
Tabla 6. Definicin de la escala de probabilidad d ocurrencia

(Roger Graves, 2000)
Escala
0.1
0.3
0.5
0.7
0.9
Definicin
Muy improbable
Poco probable
Probable
Altamente probable
Casi cierto
Descripcin
Me sorprendera si ocurre
Mas probable que no ocurra a que si
Tan probable que ocurra como que no ocurra
Ms probable que ocurra a que no ocurra
Me sorprendera si no ocurriese
58
Casi cualquier riesgo puede tener efectos en costos (aumento), en el cronograma de

la entrega de las etapas (atraso), en la funcionalidad (disminucin de nivel de desempeo)
y en la calidad (reduccin). Para medir el impacto se us una escala de valores no lineales
(0.05, 0.10, 0.20, 0.40, 0.80). La Tabla 7 describe la escala a utilizar cuando se trata el
impacto negativo de los riesgos en los objetivos del proyecto.
Tabla 7. Definicin de la escala de impacto negativo en los objetivos del proyecto

(PMBOK Guide, 2004)
Objetivos
del
proyecto
Escala
Muy poco (0.05)
Poco (0.10)
Costo
Incremento
insignificante
Incremento en
costo <5%
Tiempo
insignificante
Retraso < 5%
Alcance
Reduccin
escasamente
apreciable
reas menores
de alcance
afectadas
reas mayores
de alcance
afectadas
Calidad
Degradacin
escasamente
apreciable
Solo
aplicaciones
muy exigentes
se afectan
Reduccin de
calidad que
requiere
aprobacin
Moderado (0.20)
Incrementos en
costos entre 510%
Retraso global
entre 5-10%
Alto (0.40)
Incremento en
costos entre 1020%
Retraso global
10-20%
Reduccin de
alcance
inaceptable a la
Empresa
Reduccin de
calidad
inaceptable por
la Empresa
Muy alto (0.80)

Incremento en
costos > 20%
Retraso global >
20%
Fin del Proyecto,
tem es
inutilizable
Fin del Proyecto,
tem es
efectivamente
inutilizable
Finalmente teniendo la probabilidad y el impacto, se calcula la exposicin al riesgo.

El equipo puede usar la magnitud de la exposicin al riesgo para clasificar los riesgos. En
el caso ms simple de anlisis de riesgo cuantitativo, la exposicin al riesgo se calcula
multiplicando la probabilidad de riesgo por el impacto. Es muy prctico crear una matriz
que tenga en cuenta las posibles combinaciones de las puntuaciones y las clasifique en
categoras de riesgo bajo, medio o alto. La Tabla 8 describe las tres escalas de exposicin
al riesgo que se utilizan.
Bajo: Los valores de impacto y probabilidad son slo adivinanzas.
Medio: Los valores de impacto y nrnhabilidad se consideran precisos dentro

de + o - un nivel.
Alto: Los valores de impacto y probabilidad se consideran exactos.
59
El rea gris oscura representa los riesgos ms altos, el rea de gris intermedio
representa los riesgos menos importantes y el rea de gris ms claro represntalos riesgos
moderados. Aquellos riesgos que se encuentran en el rea de gris oscuro, son riesgos que
tiene un alto impacto en los objetivos del proyecto y requieren darle prioridad sobre los
otros, planteando estrategias agresivas de mitigacin.
Tabla 8. Matriz de probabilidad e impacto

(PMBOK Guide, 2004)
Probabilidad
Amenazas
11
WBBBW
0.90
0.05
0.09
0.70
0.04
0.07
0.14
0.50
0.03
0.05
0.10
0.30
0.02
0.03
0.06
0.12
0.10
0.01
0.01
0.02
0.04
0.08
0.05
0.10
0.20
0.40
0.80
b.
IH
bbbiib|iai
m
Priorizacin de la lista m aestra: Una vez definidas las escalas de probabilidad
e impacto, se toma como insumo la lista de los riesgos de la etapa de identificacin, se

describen los potenciales efectos adversos (consecuencias), se calcula la exposicin al
riesgo y se prioriza de acuerdo a esto. Posteriormente se plantean alternativas de
respuesta a los riesgos.
2.
Anlisis cuantitativo de los riesgos: En este paso se recoge informacin de la
gestin de riesgos del proyecto y de la gestin de los proyectos planteados por la

compaa. Algunos equipos pueden realizar niveles adicionales de anlisis para clarificar
su comprensin del riesgo de un proyecto. Tcnicas como el anlisis de rbol de decisin,
el anlisis causal, el anlisis Paretto, la simulacin y el anlisis de sensitividad se han
utilizado para conseguir una comprensin cuantitativa ms amplia de los riesgos de los
proyectos. Estas herramientas deben utilizarse si el equipo cree que pueden aportar algo
positivo a la asignacin de prioridades o al proceso de planeamiento.
60
La Figura 20 describe el proceso cuantitativo de los riesgos, en caso de utilizar

alguna de estas tcnicas.
Lista inicial de
riesgos de la
Etapa de
identificacin
Tcnicas de anlisis cuantitativo
Anlisis del proyecto

Plan de gestin del
proyecto
Gestin de itinerario
Gestin de costo
i
Lista maestra de riesgos
actualizada
Figura 20. Proceso de anlisis cuantitativo dlos riesgos
Finalmente el anlisis de riesgos proporciona al equipo una lista de prioridades de

riesgos muy til para planear las actividades de respuesta de riesgos. La informacin
detallada de los riesgos, las consecuencias y la unidad de medicin utilizada para la
asignacin de prioridades (probabilidad, impacto, exposicin), se registran a menudo para
cada riesgo en el formulario de declaracin de riesgos.
3.4.4 Fase 4. Planeacin de respuesta al riesgo
El planeamiento de riesgos toma la informacin obtenida tras el anlisis de riesgos

y la utiliza para trazar estrategias, planes y acciones. El principal objetivo del
planeamiento y programacin de riesgos consiste en desarrollar un plan detallado para
controlar los riesgos ms importantes identificados durante el anlisis de riesgos e
integrarlo en los procesos de administracin estndar del proyecto para garantizar su
realizacin. En esta fase se decidi qu hacer y cundo, para cada uno de los riesgos de la
lista. Tomando como insumo la lista priorizada de riesgos, y tomando en cuenta slo los
riesgos con media o alta importancia, se plantean las estrategias para cada uno de ellos.
61
Las acciones a seguir pueden ser: transferir, mitigar, evitar o ignorar y
aceptar. Ver
Figura 21.
Lista maestra de
riesgos priorizada
etapa anterior
Lista de los 10 riegos ms

importantes
Plan de gestin
de los riesgos
Plan de gestin
del proyecto
Gestin de
itinerario
Gestin de
costo
-----
1. Plan de accin para cada riesgo.

Estrategias de respuesta al
riesgo: Evitar, transferir,
mitigar y aceptar.
2. Asignacin de recursos
3. Plan de mitigacin
de respuesta a los riesgos
Lista de riesgos actualizada

Gestin del proyecto actualizado
Figpra 21. Proceso de planeacin de respuesta al riesgo
1. Datos de entrada: Los datos de entrada en el proceso de planeacin de riesgos

no slo se incluyen la lista maestra de riesgos, y la informacin base de gestin de
riesgos, sino tambin los planes de gestin de costo, de itinerario, etc.
2. Actividades: Una tcnica sencilla pero eficaz para vigilar el riesgo consiste en
desarrollar una lista de los riesgos ms importantes para el proyecto. Todos los
patrocinadores del proyecto deben contar con esta lista que puede incluirse en el
documento que establece el objetivo (la visin) o el mbito del plan del proyecto. Lo
fundamental es identificar una cantidad limitada de los riesgos importantes que deben
administrarse (por lo general 10 o menos). Aunque el equipo desee administrar ms de 10
riesgos, es ms efectivo centrarse en primer lugar en un nmero reducido de riesgos
importantes y luego administrar los menos importantes cuando el primer grupo ya est
controlado. Tras clasificar los riesgos, el equipo deber centrarse en elaborar una
estrategia de gestin de riesgos y en cmo incorporar los planes de accin al plan general.
62
Existen diversos enfoques para reducir la exposicin al riesgo. Entre estos se

cuentan con:
Evitar: Es cambiar el plan del proyecto para eliminar el riesgo o para proteger sus
objetivos, del impacto sin necesidad de realizar actividades arriesgadas. Ejemplos:
reducir el alcance, agregar recursos, agregar tiempo, adoptar enfoques conocidos
y no innovadores y evitar contratistas no bien conocidos.
T ransferir:
A veces, un riesgo puede transferirse para que pueda ser
administrado por otra entidad fuera del proyecto. La transferencia del riesgo no
significa que el riesgo se haya eliminado. En general, una estrategia de
transferencia de riesgos generar riesgos que seguirn necesitando una
administracin proactiva pero que reducen el grado de riesgo a un nivel aceptable.
M itigar: La mitigacin de riesgos implica acciones y actividades que se realizan

con anticipacin para evitar que se produzca un riesgo o para reducir el impacto o
las consecuencias a un nivel aceptable. Ejemplos: Adoptar procesos menos
complejos, escoger un proveedor mas estable, agregar mas recursos, obtener ms
tiempo y desarrollar prototipos.
A ceptar: En algunos riesgos ya no es posible intervenir con medidas preventivas

ni correctivas efectivas, pero aun as el equipo decide simplemente aceptar el
riesgo para materializar la oportunidad. As pues, el plan deber incluir los
motivos que han empujado al equipo a aceptar el riesgo sin desarrollar ningn
plan de mitigacin o contingencia.
3.4.5 Fase 5. Seguimiento y control del riesgo
En esta etapa se plante la forma de darle seguimiento a los riesgos, con el objetivo
de conocer los riesgos que estn en observacin o mitigacin. Adems de esto se plantean
alternativas de cmo controlar los riesgos que puedan aparecer en el entorno a medida
que el proyecto avanza.
63
3.5 Conclusiones del proceso de gestin de riesgos

Este captulo provee una visin general del proceso de gestin de riesgos diseado
y utilizado en gran parte, en una compaa pequea de desarrollo de software en plazos
de tiempo cortos.
Al realizar la identificacin de riesgos, es fundamental lograr una clara descripcin

del riesgo de forma tal de que el mismo pueda ser comprendido y manejado
adecuadamente; cuando se lo enuncia, no solo debe considerarse el sntoma sino tambin
sus consecuencias.
Por ltimo, como la gestin de riesgos es un proceso continuo, la identificacin no

es un evento que se debe hacer por una sola vez; debe realizarse en forma regular durante
toda la vida del proyecto.
4. CASO DE ESTUDIO
4.1 Descripcin del caso de estudio

Este captulo describe la compaa que se utiliza como caso de estudio.
La
compaa seleccionada es una compaa nueva (Start-up) de desarrollo de software en

plazos de tiempo corto; que poco a poco ha desarrollado sus procesos para ser ms
competitiva en el mercado. A continuacin se describe el perfil y el anlisis del estado
actual de la compaa.
4.1.1 Perfil de la com paa
Es lder en un mercado emergente debido a su entrada temprana al campo y su

habilidad de proveer soluciones
a sus clientes que incluyen diseo de hardware /
software e implementacin, diseo industrial, manufactura y certificaciones.
La compaa se concentra en dos estrategias, una la de desarrollar software para

chentes especficos y la otra en desarrollar software propio para atraer a todos los
consumidores. En este caso, se analizar la gestin de proyectos en el desarrollo de
software propio
1.
E stru ctu ra O rganizacional: El grupo de desarrollo de software se encuentra
organizado en equipos de trabajo encargados de un rea especfica, dirigidos por lideres

de equipos (team leaders), los cules son supervisados por el director de arquitectura de
software; que a su vez informa al jefe principal de tecnologa. La Figura 22 describe la
estructura de la organizacin.
64
65
Chief Technical OSicer
I
Software Architecture
Group Director
Team Leader
Core Application
Team
Team Leader
Core Tecnnology
Team
Team Leader
Domain Application
Chief Technical Officer
Team
Team
Figura 22. Estructura organizadonal d la compaa - caso de estudio
2.
Planificacin de la contratacin de los recursos: Una vez se determina la
necesidad de recursos, se publica en el peridico el puesto a competir y se evalan los

resums. De estos se seleccionan las personas a ser entrevistadas y el grupo de
reclutamiento recomienda a la compaa a las personas que lograron satisfacer sus
expectativas. Posteriormente se contrata al personal seleccinado y los lderes del equipo
(team leaders) que han participado en el proceso de seleccin, analizan su ubicacin en
los equipos de desarrollo. Sin embargo esto es flexible, pues si la persona quiere trabajar
en otro campo se integra a otro equipo sin ningn problema.
En cuanto al rea de capacitacin, la compaa busca personas con experiencia en el

rea donde se necesita ms personal o sino asesora al personal nuevo con personas con
mayor experiencia en la compaa.
66
4.1.2 Administracin de los proyectos y gestin de riesgo
El proyecto como un todo es manejado por el Director de grupos. Est dividido en

mdulos, los cules a su vez se asignan a miembros de uno o ms grupos de desarrollo
dentro de la estructura de la compaa. Cada grupo tiene un lder responsable de manejar
las tareas asignadas al grupo y de mantener el estado (status) de progreso de cada
miembro en la Web interna de la compaa. Cada desarrollador es responsable de detectar
posibles riesgos en su itinerario de trabajo y reportrselo a su lder de grupo. El lder es
responsable de reasignar prioridades dentro de su grupo para minimizar el impacto que
estos problemas puedan tener sobre el trabajo de otros grupos. Si el lder estima que
puede impactar negativamente otro grupo, se lo informa al director de grupos para tratar
de conseguir una solucin al problema.
4.1.3 Mtodos, herramientas y tcnicas para planificar y controlar los proyectos
Actualmente la compaa est evaluando la mejor forma de trabajar en este tipo de

ambiente, as que lo que est haciendo es implementar mtodos que le ayuden a ser ms
eficientes agregando o eliminando principios seleccionados en consenso por el grupo de
desarrollo. La compaa ha implementado varias ideas de proyectos giles, en especial
XP (Xtreme Programming), con el propsito de mejorar su forma de trabajar en este tipo
de ambientes tan flexibles. A continuacin se describen los principios implementados por
la compaa, algunos
de ellos pertenecen a XP y otros son ideas tomadas de la
experiencia del personal.
El juego de Planificacin: Consiste en determinar rpidamente el alcance del

prximo plan (entrega), mediante la combinacin de prioridades del negocio y
estimaciones tcnicas. A medida que la realidad va cambiando, el plan se va
actualizando. Se planifica en detalle solo la iteracin en curso. Es decir no se
67
planean a un mismo tiempo todas las iteraciones a realizar. Motivo: Es perder el

tiempo, el proyecto cambiara.
Pequeas
entregas
(Releases):
Poner un
sistema simple en produccin
rpidamente, luego liberar nuevas versiones en ciclos muy cortos.
Programacin individual: Cada tarea se responsabiliza a una persona. Las tareas

se asignan a los programadores y son estos junto con el lder los que estiman el
tiempo que puede tardar la implementacin de la tarea que se comprometen a
hacer.
Comunicacin efectiva: Reuniones semanales con el personal y bisemanales con

los lderes.
Recursos: Sala de conferencias a espacio abierto, presentaciones informales.
4.1.3.1 Metodologa de desarrollo de software
Anteriormente el proceso de desarrollo de software consista en definir la lista de

requerimientos del cliente, y subdividir las tareas en subtareas, asignando responsables y
fechas de entrega. Los proyectos se trabajaban por prioridad, dependiendo del potencial
del cliente y de la oportunidad. El equipo comienza la etapa de desarrollo, pero en el
transcurso suele suceder que el cliente cambie de requerimientos o que lleguen nuevos
requerimientos de otros proyectos al sistema. En este caso se prioritizan los
requerimientos, dejando a un lado los anteriores y se trabaja en lo ms urgente. La Figura
23 describe la situacin presentada.
68
R equerim ientos 1
R equenm ientos 2
Cambi o de
priori dades
10
11
12
13
14
i3
Requerim ientos 3
Cambi o de
prioridades
F echa de
entrega
Figura 23. Metodologa de desarrollo de software vieja
Uno de los problemas de esta metodologa de desarrollo, era la planificacin, pues

no era fcil cuantificar las tareas que se podan hacer en ese perodo de tiempo y no era
fcil planear que se poda terminar en ese perodo de tiempo que se haba definido como
fecha de entrega. Actualmente, se est probando una nueva forma de planificacin y
desarrollo. En la literatura se conoce como metodologa por ciclos, definida en los
mtodos giles. sta consiste en pequeos incrementos y entregas frecuentes a los
usuarios finales, lo cual permite obtener informacin de incalculable valor sobre el
equipo y una retrocomunicacin rpida. Como se quera un desarrollo de calendario
ambicioso, se planificaron ciclos de 7 semanas, en donde al final del ciclo haba metas
definidas que se tenan que cumplir. La primera semana del ciclo es de planificacin
(planning), las siguientes cuatro semanas son especficamente para desarrollo del
software (ejecucin), y las siguientes dos semanas para integracin y prueba. En la etapa
de integracin y prueba el personal deber someter todo el cdigo desarrollado y se hace
un proceso de revisin, el cual consta de un grupo de 4 a 5 personas, donde el dueo del
cdigo presenta su trabajo. En esta ltima etapa, se cuantifica el tiempo gastado en
preparase para la revisin del cdigo, el tiempo para revisar el cdigo, y el tiempo
gastado en el proceso de revisin y en hacer las modificaciones. Con esta informacin,
ms el tiempo empleado por la persona en desarrollar ese cdigo originalmente, se puede
sacar un estimado del tiempo promedio en desarrollar un cdigo y as tener una base para
seleccionar las tareas que se van a planificar en el prximo ciclo.
69
Con esta nueva metodologa, la compaa pretende definir un perodo de tiempo

fijo de entrega donde se definirn con claridad todo lo que se va a entregar. En la
metodologa anterior se empezaba a desarrollar, acumulndose todos los requerimientos,
dejando otros atrs, entregando al final pedazos de cada requerimiento. Por lo tanto, con
esta nueva metodologa se pretende estimar mejor cual es la velocidad de trabajo o la
capacidad de trabajo que se puede desarrollar en este tipo de perodo de tiempo. Este
proceso facilita cuantificar el desarrollo del cdigo y decidir mejor que tareas pueden
realizarse en determinado tiempo y cuales no.
La Figura 24, muestra el proceso
grficamente.
E ntregas increm ntales c a d a 4
Ciclo I
Plae acin
Ejecucin
Entrega del
ciclo 1
Integracin y prueba
Planeacin
Ejecucin
E ntrega del
- ciclo 2
planeacin
Ejecucin
Integracin y prueba
Figura 24. Metodologa de desarrollo de software actual
70
Con esta nueva metodologa, cuando empiece a llegar los nuevos requerimientos, lo
suficientemente temprano al prximo ciclo, se podr planificar cuales son las prioridades
y empezar a desarrollar en el ciclo prximo, sin cambiar las tareas que se estn haciendo
en el ciclo actual. En caso que lleguen dos requerimientos nuevos con espacio de tiempo
muy reducido, en la fase de planificacin se determina que es lo ms importante a
desarrollar, cuestin de mover las tareas que se estaban haciendo para el requerimiento
x a un dclo futuro o desarrollar ests tareas en el ciclo actual y planificar los nuevos
requerimientos para el prximo dclo. Con esta funcionalidad de dclos, se tienen entregas
(releases) relativamente frecuentes y si hay requerimientos que confligen, poder tomar la
decisin de cual se va a desarrollar ahora y cual despus. Es importante la comunicadn
con el chente, pues en el caso que ste no pueda esperar, se espedfica que se va a
desarrollar lo que el cliente considera ms importante y lo dems se pospone para el dclo
prximo, as todas las tareas no se acumulan y se pueden hacer entregas con
caractersticas ms avanzadas.
4.1.3.2 Procesos y herram ientas de planificacin y control de proyectos
1.
Proceso de cap tu ra de requerim ientos: Este proceso se realiza de form a
inform al. El rea de negocios se encarga de conseguir clientes potenciales; una vez el
chente esta interesado, se plantea los requerimientos del chente. Se realiza una lista de las
caractersticas (features) del producto, la cual se pasa al equipo de desarrollo, en donde
los lderes de los grupos tcnicos se renen para ver cules de esas caractersticas
(features) son posibles, y para priorizar las tareas a realizar. Posteriormente se pasa la
lista priorizada de nuevo al chente para que estos tambin la prioriticen y as decidir en
conjunto que requerimientos se van a trabajar primero. El problema es la indecisin de
los chentes, pues en ocasiones los clientes cambian su necesidad, cuando la compaa se
encuentra en su etapa de desarrollo; o en ocasiones se presentan nuevos requerimientos,
lo que obhga a la compaa a reprioiizar las tareas segn lo ms importante.
71
2. Code Review (revisin del cdigo): Proceso realizado al final de la etapa de

desarrollo. En este proceso el personal debe someter el cdigo y pasarlo por una fase de
revisin. El grupo esta confirmado con un mnimo de 4 personas: el autor, un moderador
de la reunin y dos a tres invitados al proceso de revisin (reviewers), los cuales deben
ser personas que tienen bastante experiencia.
3. Testing (integracin y prueba): El proceso de prueba est bien definido. En
este proceso se define una serie de pruebas con el objetivo de validar el software.
4. Issues resolution (resolucin de problem as): Proceso que define la forma de
actuar desde que se presenta un problema, hasta someter el cdigo de este.
5. Bug rep o rt (informes de problem as): Proceso donde se define como reportar
los problemas.
6. Coding Standards (estandarizacin del cdigo): Proceso donde se define como
documentar un cdigo, como nombrar funciones, etc.
7. Proceso de seguimiento de actividades: Existen diferentes herramientas de

seguimiento y control de proyectos, tanto
ales como informales. La compaa
desarroll por Web una tabla de seguimiento y control, de proyectos, estado de

requerimientos y tareas asignadas; de tal forma que la vista de proyecto sea slo para los
chentes, la de requerimientos para los lderes y la tareas para el personal;
as cada
participante puede ver la informacin que le interesaba, sin ser intimidante. De esta forma
los lderes pueden dar seguimiento al personal, permitiendo tener un mejor panorama del
estado actual del trabajo de cada uno. La Tabla 9 describe la tabla de seguimiento para el
personal de desarrollo.
Tabla 9. Seguimiento dlas actividades del personal
ID
T a re a
A sig n ad o
E stim a c i n
o rig in al
H o ra s
in v e rtid a s
H o ra s
re s ta n te s
Fecha
lim ite
Fecha de
e n tre g a
P r io rid a d
re la tiv a
72
Por otro lado, es importante mencionar que la compaa al ser un Start-up, est
probando diferentes formas de trabajar, es por eso que se puede observar que en algunos
grupos se trabaja de una forma, mientras que en otros no. Recientemente los lderes estn
implementando reuniones informales diarias, con el propsito de conocer al detalle el
desempeo diario de cada persona, y determinar el estado actual de las tareas.
Actualmente se pretende llevar esta idea a un nivel superior, en donde los lderes
informen el estado actual a la gerencia con mayor frecuencia.
4.2. Riesgos percibidos

Una vez realizada la descripcin de los mtodos, y herramientas utilizadas por la
compaa, se procede a realizar un anlisis general, para decidir si es viable o necesario
realizar un anlisis de riesgos. Este anlisis se realiz a base a observacin y con ayuda
del personal de la compaa: lderes y supervisores, gracias a su experiencia en esta clase
de proyecto y a las lecciones aprendidas en el da a da. Entre los riesgos ms
predominantes, se encuentran los relacionados con planificacin, el desarrollo y la
organizacin. A continuacin se describen cada uno de ellos:
1. Amplio enfoque estratgico del rea de negocio: La compaa actualmente se
encuentra enfocada h a d a dos estrategias; des
ar productos para clientes espedirnos y
desarrollar sus mismos productos para todo tipo de clientes en un futuro. Por lo tanto, el
rea de negodos continuamente est trabajando en entrar a estos mercados, ocasionando
trabajo excesivo.
2. Falta Apoyo sostenido de la gerenda con la organizadn: En ocasiones el rea
de negocios se compromete demasiado con los clientes, con fechas de entrega agresivas;
sin estimar robustamente
la duradn de cada requerimiento; si tener en cuenta la
dificultad de la tarea y el alcance de esta. Una de las causas ms comunes de esto, es la

falta de participacin del rea de desarrollo, en el momento de negodar con el chente;
generando expectativas poco realistas.
73
3. Cambio constante de los requerimientos: Actualmente los requerimientos son

inestables, esto debido a que no existe formalmente un proceso estructurado de captura de
requerimientos, pues actualmente se hace de manera forma informal y no se firma un
contrato de acuerdo con los posibles clientes. El cliente tiene el poder de cambiar de idea
continuamente, sin importar el estado actual de los requerimientos pactados.
4. Tiempo inadecuado para planificar: Este proceso, es una de las partes ms
importantes de desarrollo de software. Actualmente el tiempo que se da a la etapa de
planificacin es bien poco; si se tiene en cuenta que el personal encargado de esto,
cumple otras funciones en la organizacin. Esto trae como consecuencia una pobre
estimacin de tareas.
5. Planificacin ambiciosa del calendario de trabajo: Los retos a los que se enfrenta
alguien que desarrolla una aplicacin en tres meses son muy diferentes de aquellos a los
que se enfrenta alguien que desarrolla una aplicacin que necesita un ao. Fijar un plan
excesivamente agresivo predispone a que el proyecto falle por falta de tiempo, minando
la planificacin efectiva, y reduciendo las actividades crticas para el desarrollo, como el
anlisis de requerimientos o el diseo. Tambin supone una excesiva presin para los
desarrolladores, quienes a largo plazo se ven afectados en su motivacin y su
productividad.
6. Dependencia de las tareas: Los lderes de cada equipo, subdividen las tareas
principales en pequeas subtareas. En ocasiones existen tareas que dependen de otras.
Esto es un problema en el momento de planificar, pues afecta el desarrollo del software,
si no se tiene a consideracin.
7. Falta de flexibilidad del diseo: Debido a la flexibilidad de la compaa, los
diseos deben ser lo suficientemente flexibles como para ser reusados en otras partes. En
ocasiones por falta de tiempo se desarrollan diseos demasiado acoplados a la aplicacin
en especfico.
74
8. Demora del proceso de revisin del cdigo: El personal debe someter el cdigo
para luego ser integrado y probado. El problema es que la fase de someter el cdigo
consume mucho tiempo, ya que todo el cdigo desarrollado es revisado. Por otra parte;
como el tiempo de desarrollo es demasiado agresivo, parte del personal no alcanza a
someter el cdigo pues las tareas asignadas son demasiado complejas.
9. Problemas inesperados en la etapa de integracin: En la integracin se juntan los
pequeos mdulos de software desarrollados y que parece que funcionan. En ocasiones
surgen errores al integrarlos y se debe te n erla capacidad de afrontarlos rpidamente.
10. Problemas en la efectividad de las herramientas de desarrollo (development
tools): Debido al alto costo de las herramientas de desarrollo de software para diseo,
validacin y dems, la compaa trabaja con recursos de libre acceso o diseados por el
equipo de desarrollo. El problema es que estas herramientas no son tan efectivas como las
comerciales y no tienen ningn servicio de ayuda.
11. Problemas en el servicio de calidad de tecnologa subcontratada: Existe

servicios subcontratados, como lo es el servidor de las pginas amarillas. Este no puede
ser controlado por la compaa y en ocasin
presentan problemas de disponibilidad,
tiempo de respuesta, veracidad de los datos, etc.

12. Inexperiencia del personal: La mayora del personal contratado tiene mucho
potencial pero poca experiencia laboral; debido a que contratar personas con experiencia
es demasiado costoso. Actualmente, cada persona esta encargada de una tarea en
especfica, la cual es desarrollada hasta el final; es decir cada persona se le asigna una
tarea dependiendo de su
rea fuerte. Esto ocasiona que la carga laboral est mal
distribuida, pues existen equipos con demasiado trabajo o personal sobrecargado.

13. Pobre planificacin del programa de formacin de gestin de procesos:
Incorporar las metodologas requiere entrenamiento, la gente est acostumbrada a trabajar
de una forma y se debe dar seguimiento de cmo trabajar de otra forma.
75
La curva de aprendizaje es lenta, ya que no se le da prioridad a esto, si no al

cumplimiento de las metas. El personal esta demasiado ocupado y estandarizar o
introducir procesos en este tipo de ambiente es difcil sin un entrenamiento adecuado y un
continuo seguimiento.
14. Inexistencia de un proceso de evaluacin de desempeo del personal: No existe
un proceso de evaluacin del personal, es decir no hay mtricas para medir su desempeo
y poder dar retroalimentacin de su trabajo.
15. Gestin de riesgos insuficiente: No existe ningn proceso de gestin de riesgos.
Se ha pensado en una lista de riesgos en un futuro, pero no existe un proceso definido de
cmo analizar y controlar los riesgos en esta clase de ambientes.
En conclusin, de acuerdo al anlisis general realizado, la compaa debido a su
flexibilidad para manejar proyectos en plazos de tiempo tan cortos, se desarrolla en un
ambiente de altos riesgos. Con el objetivo de considerar el punto de vista del personal de
la organizacin, se desarrolla una herramienta de gestin de riesgos, la cual se describe a
continuacin.
4.3 Administracin y anlisis de resultados de la herramienta de identificacin de

riesgos propuesta
El propsito de esta herramienta de identificacin de riesgos, es brindarle a

cualquier compaa pequea de desarrollo de software, una solucin que sirva como base
para comenzar con el proceso de gestin de riesgo. En esta etapa se implemento la
herramienta de identificacin de riesgos desarrollada el captulo 3, seccin 3.3. Los
resultados fueron tabulados y por medio de un anfisis estadstico se identificaron los
riesgos ms importantes.
76
4.3.1 Validacin del cuestionario
La validacin se realizan con el obj etiv
isegurar que la herramienta utilizada no
de conclusiones errneas. A continuacin se uescriben los procesos para validar la

herramienta utilizada.
Para verificar la construccin de la herramienta, se aplic una lista de cotejo

encontrada en la literatura referente a la construccin del cuestionario;
preguntas, escala y dems. De acuerdo con esto, el cuestionario cumple con
los principales criterios de desarrollo de cuestionarios. Favor refirase al
Anejo 3.
Validacin de construccin: Se verific la validez de construccin mediante el

uso y las tcnicas de anlisis de correlacin y de anlisis de factores.
Posteriormente se analiz utilizando anlisis de regresin.
4.3.2 Tamao de muestra el cuestionario
Para recolectar los datos se utiliz la herramienta de identificacin de riesgo

descrita en el captulo 3, seccin 3.3. Este fue entregado a 13 personas de la compaa, un
nmero bastante representativo ya que se trata de una compaa pequea conformada por
un total de 24 personas. Los participantes finales son ingenieros de computadoras,
excepto uno que es diseador grfico. Entre los diferentes cargos podemos encontrar los
siguientes: coordinadores, personal de desarrollo
y personal de prueba (testing).
En cuanto a la experiencia del personal al que se le aplic el instrumento, se
encuentra entre el mes y los 15 meses de experiencia en la compaa. En cuanto a la
experiencia en el campo de desarrollo de software, se encuentra entre los 2 meses hasta
los 15 aos de experiencia, lo cual nos indica que en promedio existe personal preparado
experto en el rea. La Figura 25 y 26 describen grficamente esta informacin.
77
Experenci
co m p a a
20
18
|
15 -
15
16
s ,4
12
1 124
12
9 , 9
10
S 8
*
64
i 4
3,5
P 2
HL
1
UL
<m "* i J i '
10
11
12
r - '
13
Persona ncuestada
Figura 25. Tiempo de experiencia del personal en la compaa de estudio
E x p erie n cia en d esarro llo de so ftw a re
f 1:25
10
11
12
13
P e r s o n a E n c u e sta d a
Figura 26. Tiempo de experiencia del personal en desarrollo de software
78
4.3.3 Anlisis de Factores
El tratamiento estadstico de los datos se ha realizado con el programa estadstico R,

en donde se desarroll el anlisis factorial para identificar los factores que explicarn el
mximo de variabilidad. Cmo el cuestionario est dividido en grupo de preguntas, se
realizaron mltiples anlisis factoriales, con el propsito de identificar los factores ms
significativos por grupo.
A continuacin se presenta los resultados de la tcnica factorial aplicada a la

herramienta de identificacin de riesgos propuesta en el captulo 3. Siguiendo las fases
principales del anlisis factorial tenemos:
1.
Anlisis de la m atriz de correlaciones: En este caso se muestra la matriz de
correlaciones, la grfica de correlaciones y el clculo de su determinante. En la Figura 27

y en las Tabla 10 y 11, se muestran las grficas y la matriz de correlacin de cada gmpo
conformado por todas las variables a ser analizadas. La Tabla 12 muestra el resultado del
determinante de las diferentes matrices. A simple vista se observan colores rojo y verde,
lo cual nos demuestra que existen correlaciones entre las variables. Adems los
determinantes de cada matriz se acercan al 0, lo que indica que las variables estn
linealmente relacionadas, lo que significa que el anlisis factorial en cada grupo de
preguntas es una tcnica pertinente para analizar estas variables. Refirase al Anejo 4
para el resto del anlisis.
79
Grupo de preguntas 53-60
M otirctCor:
Figura 27. Grfica de correlaciones-grupo depreguntas 53-60y 61-69
Tabla 10. Matriz de correlaciones grupo 53-60
0-53
Q.54
0.55
0-56
0-57
Q.58
Q.59
Q.60
0.53
1.000
-0.245
-0.088
0.092
0.227
0.076
0.743
0.618
Q.54
-0.245
1.000
0.200
0.128
0.165
0.494
-0.350
-0.358
Q.55
-0.088
0.200
1.000
0.427
-0.063
0.126
-0.089
0.206
Q.56
0.092
0.128
0.427
1.000
0.631
0.721
0.110
0.294
0.57
0.227
0.165
-0.063
0.631
1.000
0.813
0.165
-0.102
Q.58
0.076
0.494
0.126
0.721
0.813
1.000
0.000
-0.102
Q.59
0.743
-0.350
-0.089
0.110
0.165
0.000
1.000
0.806
Q.60
0.618
-0.358
0.206
0.294
-0.102
-0.102
0.806
1.000
80
Tabla 11. Matriz de correlaciones grupo 61-69
Q.61
0.62
0-63
0-64
Q.65
Q.66
Q.67
Q.68
Q.69
Q.61
1.000
0.080
0.576
0.135
0.318
0.570
0.464
-0.519
0.510
Q.62
0.080
1.000
-0.032
0.139
-0.381
-0.085
-0.497
-0.148
0.009
Q.63
0.576
-0.032
1.000
0.196
0.351
0.867
0.319
-0.680
0.362
0-64
0.135
0.139
0.196
1.000
-0.196
0.000
-0.103
-0.010
-0.054
0-65
0.318
-0.381
0.351
-0.196
1.000
0.592
0.938
-0.483
0.712
Q.66
0.570
-0.085
0.867
0.000
0.592
1.000
0.555
-0.677
0.594
0-67
0.464
-0.497
0.319
-0.103
0.938
0.555
1.000
-0.385
0.719
Tabla 12. Clculo del determinante
Grupo
1-7
8-15
16-25
26-35
36-43
44-52
53-60
61-69
70-78
79-87
88-97
98-108
109-115
116-124
Detenninante
0.089213
0.014074
5.00E-06
8.10E-05
0.007213
0.002143
0.001135
0.000108
0.006413
0.004302
0.00086
1.00E-06
0.002882
0.002155
0-68
-0.519
-0.148
-0.680
-0.010
-0.483
-0.677
-0.385
1.000
-0.638
Q.69
0.510
0.009
0.362
-0.054
0.712
0.594
0.719
-0.638
1.000
81
2. Extraccin del nm ero ptimo de factores: Con el propsito de evaluar el

nmero ptimo de factores, se emplea la prueba de bondad y ajuste para el modelo de
anlisis de factores (tests o f overall goodness-of-fit o f the factor analysis model). Se
realiza la prueba con las siguientes hiptesis:
Ha: "El nmero defactores es suficiente

Ha: "El nmero defiadores no es suficiente
Por tal motivo se escoge el menor nmero de factores para la cual no se rechaza la
hiptesis nula, es decir el primero que indique que el nmero de factores es suficiente.
3. Factorizacin o extraccin de factores y representacin grfica de factores:

La Figura 28 se muestra la matriz factorial que contiene todos los factores que se
obtienen con el mtodo de componentes principales. Cada columna es un factor y hay
tantas filas como variables originales. Cada uno de estos ndices o coeficientes pueden
interpretarse como una correlacin entre el factor y la variable, y reciben el nombre de
pesos, cargas, ponderaciones o saturaciones factoriales. Ver Anejo 5 para todas las
corridas por grupo del programa R-factorizacin inicial completa.
Uniquenesses:
Q.53 Q .54 Q.55 Q.56 Q.57 Q.58 Q.59 Q.60
0.407 0.620 0.981 0.454 0.313 0.005 0.067 0.296
Loadings:
Facto rl
Q.53
Q.54 0.487
Q.55 0.127
Q.56 0.724
Q.57 0.816
Q.58 0.997
Q.59
Q.60
SS loadings
% V ar
Cum Var
Loadings:
F a c to rl
Factor2
Q.61 0.607
0.228
Q.62
-0,546
Q.63 0.942
Q.64 0.114 -0.172
Q.65 0.453
0.827
Q.66 0.929
0.191
Q.67 0.411
0.909
Q.68 -0.737
Q.69 0.507
0.562
Factor2
0.766
-0.378
0.149
0.146
0.966
0.834
F a c to rl
2.454
0.307
0.307
U niquenesses:
Q.61 Q.62 Q.63 Q.64 Q.65 Q.66 Q .67 Q.68 Q.69
0.580 0.702 0.107 0.957 0.111 0.101 0.005 0.448 0.427
Factor2
2.403
0.300
0.607
SS loadings
% V ar
Cum V ar
F a c to rl
3.305
0.367
0.367
Factor2
2.257
0.251
0.618
Figura 28. Corrida del program a R -Anlisis factorial inicial
82
G rfica de factores: La grfica de factores representa el espacio factorial definido

por los factores contenidos en la solucin factorial. (Ver Figura 29). Este es un diagrama
de dispersin en el que los factores definen los ejes del espacio y las variables
constituyen los puntos del diagrama; de tal manera que las coordenadas de una variable
en cada factor corresponden a los valores de la matriz factorial. Ver anejo 6, Grfica de
factores completos.
1o
00
1o
Figura 29. Grfica de factores. Grupos 53-60 y 61-69
4.
Rotacin de la solucin p ara facilitar su interpretacin: En nuestro caso se
corri la rotacin ortogonal y oblicua, varimax y promax respectivamente. Sin embargo,

para propsitos de evaluacin se ha escogido el mtodo de rotacin varimax, ya que este
obtiene la rotacin que maximiza la variabilidad de las cargas factoriales asociadas a cada
factor y es el mtodo de rotacin de mayor aceptacin. La Figura 30 presenta la salida de
la rotacin ortogonal. Refirase a Anejo 7, 8 y 9 para todo el anlisis varimax y promax
respectivamente.
83
R esultados de 53:60
IN IC IO R O T A T IO N V A R IM A X Sloadings
IN IC IO R O T A T IO N V A R IM A X SI oadings
Loadings:
Q .53
Q.54
Q.55
Q.56
Q.57
Q.58
Q.59
Q 60
Loadings:
F a c to rl Factor2
0.112
0.762
0.473
-0.395
0.125
0.729
0.123
0.821
0.117
0.996
0.965
0.836
F acto rl
2.455
0.307
0.307
SS loadings
% V ar
Cum V ar
F acto rl
Q.61 0.546
Q 62 0.125
Q.63 0.937
Q.64 0.147
Q.65 0.272
Q.66 0.869
Q.67 0.215
Q.68 -0.702
Q.69 0.379
Factor2
2.401
0.300
0.607
Factor2
0.349
-0.532
0.120
-0.144
0.903
0.379
0.974
-0.245
0.655
F a c to rl
SS loadings 2.726
% V ar
0.303
Cum V ar
0.303
Srotm a [,1]
[,2]
[1,] 0.99937588 -0.03532484
[2,] 0.03532484 0.99937588
Factor2
2.836
0.315
0.618
ro tm at
[,1]
[,2]
[1,] 0.9784198 0.2066267
[2,] -0.2066267 0.9784198
Figura 30. Corrida del programa R - rotacin varimax
Por otra parte, en la Figura 31 se puede observar las posiciones de las variables,
respecto a los ejes factoriales rotadas. Esto con el objetivo de visualizar grficamente la
interpretacin de los factores.
F acto r Pio i V arbnac Rotacin

Factor Plot lo Varimax R o taro n
**
< * ff
a se
'f t
X
i
- -
....... \
.....
""
.? > *
....
:
i
...........
i.
/
/
G & t*
Q 02*
r ^ < ,?
r .....
.fO
-S
.... t
c i
10
V.-
Figura 31. Grfica de factores. Grupos 53-60 y 61-69
84
5.
Factores principales en el desarrollo de software: Esta fase depende
exclusivamente de la naturaleza de las variables. La relacin entre factores y variables se

obtiene a travs de las cargas factoriales. Finalmente se escogen en cada factor las
variables con cargas ms grandes y de acuerdo a la seleccin de variables se le da un
nombre al factor. El total de factores encontrados fue 20, entre los cuales se encuentran
riesgos tcnicos y organizarionales. Una vez completado el anlisis de factores, se
prosigui a realizar un anlisis de regresin. La Tabla 13 describe el total de factores
extrados de este anlisis.
Tabla 13. Resumen de factores de riesgos encontrado en el anlisis factorial
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Factor 6
Factor 7
Factor 8
Factor 9
Factor 10
Factor 11
Factor 12
Factor 13
Factor 14
Factor 15
Factor 16
Factor 17
Factor 18
Factor 19
Factor 20
Problemas en el proceso de definicin y control de interfaces

Complejidad del diseo e implementacin
Dificultad del producto para probarlo
Problemas en la efectividad de los mdulos reusados
Problemas en la efectividad de herramientas para integracin y prueba
Problemas en la integracin de los componentes del software
Ambiente inadecuado para desarrollo de las aplicaciones
Problemas de confiabilidad del software
Dificultad de desarrollo de los requerimientos de seguridad
Problemas de portabilidad del software
Problemas en el desarrollo estndares de seguridad
Pobre control de los procesos
Falta de disponibilidad efectiva de los recursos
Pobre precisin de problemas inesperados
Cambios constantes en la estimacin del plan
Falta de participacin entre los implicados
Problemas de usabilidad del software
Pobre participacin del usuario
Pobre comunicacin interna y externa
Satisfaccin del cliente inestable
El Factor 1 hace referencia a la definicin y control de las interfaces: Al no existir

un proceso estndar de diseo; aspectos como cambios continuos en los requerimientos
de software y de hardware dan origen a un diseo un poco riesgoso.
85
El Factor 2 hace referencia a la complejidad del diseo e implementadn:

Requerimientos basados en asunciones poco realistas, sumado a la complejidad de los
requerimientos, son variables que afectan este factor. Proyectos acelerados generan un
entorno de alta presin; que hace difcil la posibilidad de considerar alternativas en el
diseo. El nfasis en el diseo est ms orientado a la conveniencia que a la calidad.
El Factor 3 se refiere a la dificultad del diseo para probarlo: En ocasiones se

disea de manera compleja. Puede ocurrir que el diseo desarrollado sea muy complicado
y requiera de mucho tiempo para desarrollarlo y poder probarlo. Variables como falta de
caractersticas de diseo para ayudar a la prueba y poco involucramiento del personal de
prueba (testing) en la etapa de diseo, afectan este factor.
El Factor 4 se refiere a la efectividad de los mdulos reusados. Variables como

restricciones del hardware y seleccin de estos mdulos, afectan el desarrollo efectivo del
cdigo.
El Factor 5 se refiere a la efectividad de herramientas para integracin y prueba: Por

ser una compaa pequea, no se tiene demasiado capital para invertir en herramientas de
desarrollo (development tools), ya que stas tiene un costo significativo. Por lo tanto las
herramientas que se utilizan en el rea de integracin y prueba son de libre acceso;
afectando un poco el desempeo, pues son herramientas no tan efectivas como las
comerciales.
El Factor 6 se refiere a los problemas de integracin de los componentes del

software: El trabajo consiste en presentar avances del producto continuamente.
Actualmente con la metodologa de ciclos se pretende realizar una entrega cada 7
semanas. En la integracin se juntan los pequeos mdulos de software desarrollados que
parece que funcionan, pero resulta que esos pequeos trozos solo han superado pruebas
de unidad donde no han tenido que interactuar con otros mdulos. El problema es que
existen errores que slo surgen en esa interaccin y hay que tener la capacidad para
afrontarlos rpidamente.
86
El Factor 7 se refiere al ambiente adecuado para el desarrollo de las aplicaciones:

En ocasiones se presentan problemas en el desarrollo de las aplicaciones; como por
ejemplo: problemas con el sistema operativo o con las herramientas de desarrollo
utilizadas.
El Factor 8 se refiere a la confiabilidad del software: Debido al poco tiempo que se

tiene en todo el dclo de desarrollo del cdigo, se pueden presentar problemas de
inestabilidad del cdigo.
El Factor 9 se refiere a la dificultad de desarrollo de los requerimientos de

seguridad: En ocasiones se presentan inconvenientes, ocasionados por la disponibilidad
de los recursos.
El Factor 10 se refiere a la portabilidad del software: El software desarrollado

depende de una tecnologa, por lo tanto en ocasiones se pueden presentar problemas de
portabilidad.
El Factor 11 se refiere a desarrollo de estndares de seguridad: En ocasiones el

nivel de seguridad exigido es superior a nivel de conocimiento del desarrollador.
El Factor 12 se refiere a control de los procesos: No existe un proceso formal de

control de cambios en los requerimientos: surge el cambio, se informa al personal y se
trabaja en este. Tampoco existe un proceso para definir cundo se debe y cundo no
entrar nuevos requerimientos. Ahora con la metodologa de ciclo se esta tratando de
mejorar esto.
El Factor 13 se refiere a la disponibilidad efectiva de los recursos: A veces se

presentan problemas de disponibilidad de recursos, tanto propios como subcontratados.
La disponibilidad de los recursos a travs de la red, disponibilidad del servidor y dems
son un ejemplo de esto. En el caso de los recursos subcontratados, existe una gran
dependencia, pues el servicio que se presenta no es tan eficiente como el esperado.
87
El Factor 14 se refiere a la precisin de problemas inesperados: Continuamente se

estn apagando fuegos, se presentan factores sorpresa; y como no hay tiempo para
desarrollar planes de contingencia, los problemas que se van presentando se van
solucionando al tiempo.
El Factor 15 se refiere a reestimacin del plan, planificar o ponerse al da ms

adelante: Un tipo de reestimacin es responder inapropiadamente al retraso del plan. En
caso de ocurrir retrasos de un plan, se plantea recuperar el retraso, pero nunca se hace; al
final se presiona al personal a entregar segn la fecha. En este caso, cuando ocurren
factores sorpresa, se presiona al personal a trabajar a su mxima capacidad y cumplir con
la fecha de entrega, sin importar como salga el producto.
Otro tipo de error es la reestimacin que se debe a cambios en el producto.

Actualmente cuando ocurre un cambio en las caractersticas de los requerimientos o se
incorporan nuevos requerimientos, no se ajusta el plan en lo que ser refiere a la fecha de
entrega, sino que se prioriza los requerimientos ms importantes y se intenta satisfacer
todas las necesidades que hay actualmente, incorporando demasiado trabajo al personal.
Actualmente el personal no planifica, son los lderes los que priorizar las tareas y replanifican en caso de entrar nuevos requerimientos.
El Factor 16 se refiere a la confianza entre los implicados: Todos los principales

participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto.
Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo,
usuarios finales, etc. En ocasiones no existe una buena participacin entre los implicados,
debido a la falta de tiempo del personal en este tipo de ambientes de trabajo.
El Factor 17 se refiere a la usabilidad del software: Es el grado de dificultad en

aprender a manejar el sistema por parte de un usuario que no tiene por que ser
programador. En ocasiones, se necesita de dos o ms iteraciones para desarrollar una
aplicacin de completo entendimiento para el cliente.
88
El Factor 18 se refiere a la falta de participacin del usuario: Los proyectos que no

implican al usuario desde el principio corren el riesgo de que no se comprendan los
requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones
que ms tarde retrasarn el proyecto. En ocasiones los requerimientos desarrollados no
eran los esperados, debido a la falta de involucramiento del cliente en el proceso.
El Factor 19 se refiere a la comunicacin interna y externa. La comunicacin con

los supervisores es buena, pues se sienten en capacidad de comunicar sus necesidades a
estos. Por otra parte, la compaa tiene la casa matriz en Colorado y solo el rea de
negocios puede tener comunicacin con esta.
El Factor 20 se refiere a la satisfaccin del cliente. En ocasiones, debido a la

naturaleza de esta clase de compaas, en donde el tiempo es lo ms importantes, se
desarroll pensando en la conveniencia y no en la calidad. En ocasiones no se puede
entregar a tiempo lo pactado, los requerimientos desarrollados no eran lo que el cliente
esperaba debido a la pobre comunicacin por falta de tiempo o por factores sorpresa, no
se logra en una primera iteracin un nivel adecuado de satisfaccin del cliente.
A continuacin las Tablas 14, 15 y 16 describen las variables que conforman cada
factor.
89
Tabla 14. Agrupacin de variables grupos 16-25, 26-35,53-60
! Factor 1: Problemas en el proceso de definicin y control dlas interfaces

Variables
Descripcin
Q.20
Proceso de definicin de interfaces
Q.21
Requerimientos difciles de disear
Q.22
Cambio de los requerimientos del hardware
Q.25
Anlisis de rendimiento
Factor 2: Comple; idad del diseo e implementacin
Variables
Descripcin
Q.17
Requerimientos basados en asunciones poco realistas
Dificultad de desarrollo de los requerimientos
0-18
0-24
Problemas del rendimiento del sistema
| Factor 3: Dificultad del diseo para probarlo
Descripcin
Variables
0-27
Caractersticas de la etapa de diseo para ayudar al testing
Q.28
Involucramiento del personal de testing en la etapa de diseo
Q.29
Elaboracin de prototipos y demos
Q.33
Rendimiento del sistema afectado
Factor 4: Problemas en la efectividad de los mdulos reusados / Problemas
Variables
Descripcin
0-30
Restricciones del hardware para desarrollar el diseo
Reutilizacin de mdulos
0-31
0-32
Proceso formal para reutilizar los mdulos
Factor 5: Problemas en la efectividad dlas herramientas para desarrollar la integracin y
prueba
Variables
Descripcin
0.54
Desarrollo de escenarios y data testing
0-56
Validacin de las especificaciones del laboratorio de prueba
0-57
Eficiencia del banco de prueba o data testing
0-58
Validacin de los procesos
90
Tabla 15. Agrupacin de variables grupos 61-69, 79-87,98-108
1 Factor 6: Problemas en la integracin dlos componentes del software

Variables
Descripcin
Q.61
Definicin de las interfaces externas
Q.63
Detalle del proceso de integracin del producto
Q.66
Detalle del proceso de integracin del sistema
Q.68
Integracin del producto dentro de un sistemaya existente
| Factor 7: Ambiente inadecuado para el desarrollo de las aplicaciones
Descripcin
Variables
0.82
Asignacin de requerimientos de seguridad
0.83
Ambiente seguro para desarrollo de las aplicaciones
Factor 8: Problemas de confiabilidad del software
Variables
Descripcin
Capacidad del software de coexistir con otros en un ambiente comn
0.81
Q.84
Ambiente de memoria protegida
Factor 9: Dificultad de desarrollo de los requerimientos de seguridad, confiabilidad. (seguridad
significa asegurarse de hacer las cosas de la mejor manera, con calidad)
Variables
Descripcin
Inconvenientes en el desarrollo de requerimientos de seguridad
0.85
Factor 10: Problemas deportabilidad del software
Descripcin
Variables
Fcil instalacin del software
Q.80
Factor 11: Problemas en el desarrollo de estndares de seguridad
Descripcin
Variables
Acceso externo a las aplicaciones es seguro
Q. 87
Factor 12: Pobre control de los procesos
Variables
Descripcin
Proceso formal de control de cambios de requerimientos, diseo, cdigo
Q.98
Proceso para adicionar nuevos requerimientos al sistema
Q.99
Actualizacin
de los test plan y procedimientos
Q.101
Desarrollo del sistema soporta todos los aspectos del programa
Q.107
I Factor 13: Falta de disponibilidad efectiva dlos recursos
Variables
Descripcin
Q.104
Disponibilidad de los recursos a travs de la red
Facilidad de acceso al sistema
0.105
Q.106
Funcionamiento del equipo para acceso a internet y servidor
91
Tabla 16. Agrupacin de variables grupos 109-115,116-124
| Factor 14: Pobre precisin de problemas inesperados

V ariables
Descripcin
Q.113
Planes de contingenciaparariesgos conocidos
Q.114
Recursos para soportar algunafalla
Q. 115
Gerentes con experiencia
Factor 15: Cambios constantes en la estimacin del plan
Variables
Descripcin
Q. 111
Proceso de re-planeacin cuando ocurren las interrupciones en equipo o grupal
Q.112
Proceso de planeacin individual
| Factor 16: Falta de participacin entre los implicados

V ariables
Descripcin
Q.117
Involucramiento del personal con el cliente
Trabajo en equipo para alcanzar las metas en comn
0-121
0-124
Confianza en pedir ayuda a los jefes
Factor 17: Problemas deusabilidad del software
V ariables
Descripcin
Q.118
Interaccin del usuario con los interfaces es intuitiva
Factor 18: Pobre participacin del usuario
Descripcin
Q.116
Los conflictos con el cliente se documentan y resuelven efectivamente
Q.120
Satisfaccin del cliente con los requerimientos desarrollados
Presencia de problemas, requiere intervencin del gerente
Q.122
Factor 19: Pobre comunicacin interna y externa
Variables
Descripcin
Q.121
Trabajo en equipo para alcanzar las metas en comn
Q.122
Presencia de problemas, requiere intervencin del gerente
Comunicacin efectiva entre el personal
Q.123
Factor 20: Satisfaccin del cliente inestable
V ariables
Descripcin
Nivel
de conformidad del cliente
0.119
Luego de tener claramente definidos los factores presentes se utiliz como

herramienta estadstica el anlisis de regresin para poder evaluar la aportacin de cada
uno de los factores a la percepcin del nivel de riesgos en proyectos de desarrollo de
software. A continuacin se presenta la regresin.
92
4.3.4 Regresin lineal
Como nuestro estudio tiene ms variables que individuos, no se pueden utilizar las
tcnicas de regresin tradicionales. Actualmente una tcnica que se est utilizando es la
regresin por mnimos cuadros parciales (PLS).
La regresin por mnimos cuadrados parciales (regresin PLS, por sus siglas en
ingls), fue introducida por Hermn Wold (1975) para ser aplicada en ciencias
econmicas y sociales. Sin embargo, gracias a las contribuciones de su hijo Svante Wold,
ha ganado popularidad en el rea de la qumica conocida como Chemometrics, en donde
se analizan datos que se caracterizan por muchas variables predictoras y pocas unidades
experimentales en estudio.
La metodologa PLS generaliza y combina caractersticas del Anlisis de
componentes principales y anlisis de regresin mltiple. La demanda por esta
metodologa y la evidencia de que trabaja bien, van en aumento y as, la metodologa
PLS est siendo aplicada en muchas ramas de la ciencia. A continuacin se describe los
resultados del anlisis de regresin y se recogen los factores que ms influyen en la
variable de respuesta. Segn los resultados presentados en la Tablas 17 y 18; este modelo
es significativo y explica el 99.82% de la variabilidad de los datos.
PLS Regression: Respuesta versus Factor 1, Factor 2, Factor 3, Factor 4

Number o f components set to: 10
Analysis o f Variance for Respuesta
Source
Regression
DF
SS
10
6.50652
Residual Error 2
0.00117
Total
6.50769
12
MS
0.650652
1113.43 0.001
0.000584
93
T abla 17. Modelo de seleccin y validadn de la respuesta
0.174618
2.79722
0.570167
0.336305
1.30746
0.799091
0.446921
0.62345
0.904199
0.582209
0.46615
0.928369
0.649440
0.24796
0.961897
0.707359
0.07963
0.987763
0.811323
0.02343
0.996399
0.871995
0.01409
0.997834
0.917109
0.00863
0.998674
10
0.933298
0.00117
0.99820
T a b la 18. Coeficientes de regresin
Constant
Factor 1
Factor 2
Factor 3
Factor 4
Factor 5
Factor 6
Factor 7
Factor 8
Factor 9
Factor 10
Factor 11
Factor 12
Factor 13
Factor 14
Factor 15
Factor 16
Factor 17
Factor 18
Factor 19
Factor 20
10.1479
0.0516
-0.0270
0.0759
-0.0318
-0.1139
-0.1146
-0.1371
0.1805
-0.5634
-0.1692
0.0084
-0.0603
0.2214
-0.0172
-0.2150
0.0637
-0.0135
0.1940
-0.0163
-0.1974
0.000000
0.213134
-0.059142
0.317405
-0.071570
-0.420297
-0.433563
-0.211570
0.396024
-0.475783
-0.298056
0.016437
-0.269941
0.443219
-0.061412
-0.540387
0.134902
-0.014041
0.385015
-0.027699
-0.189123
94
La variable respuesta a medir es el nivel de riesgo en este tipo de proyectos. Los

resultados obtenidos en el anlisis de regresin, muestran que 7 de los 20 factores afectan
positivamente el riesgo en este tipo de proyecto de desarrollo de software. El factor 11
fue eliminado del anlisis, ya que su valor no es significativo. La Tabla 19, presenta los
factores que ms afectan el nivel de riesgos de esta clase de proyectos, segn el punto de
vista del personal de desarrollo.
Tabla 19. Ponderaciones ms significativas de anlisis de regresin
0.443219
Factor 13
0.396024
Factor 8
0.385015
Factor 18
0.317405
Factor 3
Dificultad del disefio para probarlo
0.213134
Factor 1
0.134202
Factor 16
Una vez identificado que el modelo era significativo se prosigui a verificar si se

cumplan las presunciones bsicas del anlisis de regresin. Se utiliz la grfica de
probabilidad normal de residuales, para comprobar la presuncin de normalidad. La
Figura 32 muestra la probabilidad normal de los residuales.
Pi S Residual Normal Plot

Normal - 95% CI
(response is RESPIES A)
10 corrponents
70
Figura 32. Grfica eprobabilidad normal de los residuales
95
Como es difcil de asegurar a simple vista si la grfica representa una lnea recta, se
realiz una prueba de bondad de ajuste Kolmogorov-Smimov, utilizando el programa
Minitab, para determinar con mayor certeza si los datos ajustan o no a una distribucin
normal. La prueba consisti de:
Ho: los residuales estn normalmente distribuidos.
Ha: los residuales no estn normalmente distribuidos.
Los resultados arrojados por el programa para esta prueba son presentados en la
Figura 33. Como el valor P es alto no se puede rechazar la hiptesis nula; concluyendo
que los residuales estn normalmente distribuidos.
Normality Test Kolmogorov-Smirnov

N o rm a l
M ean
StD ev
N
KS
P-Value
95
-4.85O02E-15
0.01076
13
0.107
>0.150
80
70
60
50
40
30
20
10
5
1
-Q .03
-0.Q 2
0.01
- 0.01
0 .0 3
Resid
Figura 33. Prueba de bondad de ajuste Kolmogorv Smirnov.
96
4.3.5 Implicaciones de los resultados y conclusiones
La herramienta de identificacin de riesgos propuesta, permiti conocer los factores

que ms afectan la variable de respuesta; en este caso el nivel de riesgo de sta clase de
proyectos. De acuerdo con los resultados encontrados, el instrumento de medida result
ser vlido y confiable. Al compararlo con los riesgos identificados en otros proyectos,
observamos que el Factor 1 con nombre definicin y control de las interfaces, el Factor
18 con nombre participacin del usuario y el Factor 16 con nombre confianza entre los
implicados; son factores encontrados en estudios posteriores de identificacin de riesgos.
A continuacin se desarrolla en el caso estudio la metodologa de gestin de riesgos
planteada en el captulo 3, seccin 3.4. Los datos a utilizar como datos de entrada, son los
factores de riesgos encontrados en este captulo.
5. GESTIN DE RIESGOS
Si en un proyecto se planifican los recursos, el presupuesto y el esfuerzo para

reducir las probabilidades y el impacto de los riesgos, entonces se puede considerar que
hay una gestin de riesgos. A continuacin se describe la metodologa propuesta para el
proyecto en estudio.
5.1 Fase 1: Planificacin de riesgos

Para desarrollar el plan de gestin de riesgos propuesto, se utiliz como
metodologa base el modelo del PMI, el cual tiene como objetivo garantizar que los
riesgos del proyecto sean identificados, analizados, documentados, mitigados y
controlados correctamente durante todo el ciclo de vida del proyecto. En esta Fase se
plantea un proceso de planificacin, pero se recomienda que cada proyecto defina el
momento y la forma en que el proceso de gestin de riesgos ser iniciado y las
circunstancias bajo las que se producirn las transiciones entre los pasos para cada riesgo
o grupo de riesgos.
La metodologa a seguir consta de 4 etapas: identificacin de riesgos, anlisis,

planeacin de respuesta y seguimiento y control. En identificacin se descubrirn los
riesgos, antes de que se conviertan en problemas, en el anlisis se clasificarn y
priorizarn los riesgos. Posteriormente se planean las estrategias de respuesta al riesgo y
se da seguimiento a aquellos riesgos potenciales que estn en observacin o mitigacin.
Los roles del equipo se recomendaron en la descripcin de la metodologa, captulo 3.
97
98
5.2 Fase 2: Identificacin de riesgos

El proceso de identificacin de riesgos tiene como propsito identificar los riesgos
que pueden afectar el proyecto potencialmente. La informacin a utilizar ser, la
informacin de la compaa sobre proyectos anteriores, el plan de riesgos de la fase
anterior, el plan de gestin de proyectos (descripcin del proyecto, el cronograma de
actividades, recursos asignados, el proceso de estimacin de tiempos, costos y
presupuesto, las restricciones y dems) y el punto de vista del personal.
Entre las herramientas y tcnicas se elabor un cuestionario de identificacin de

riesgos basado en la taxonoma de riesgos del SEI; con el propsito de identificar la lista
provisional de los factores principales de riesgos. Posteriormente se analiz la
informacin disponible sobre toda la gestin del proyecto y la informacin de riesgos
acerca de otros proyectos similares dentro de la misma organizacin, completando la lista
maestra de riesgos del proyecto. A continuacin se describe el proceso en la compaa
caso estudio
5.2.1 Identificacin de la lista m aestra inicial de riesgos del proyecto
A continuacin se describe todo este proceso de identificacin de los riesgos,

mostrando al final los datos ms relevantes.
1.
Identificacin de la lista inicial de riegos: En este paso se recogen los
resultados del anlisis de factores y anlisis de regresin realizado anteriormente. Este

tipo de anlisis se recomienda hacerlo siempre que se comience un nuevo proyecto con el
propsito de identificar inicialmente los riesgos. Posteriormente, se recomiendan otras
tcnicas de identificacin ms sencillas para darle seguimiento y control a los riesgos. La
Tabla 20 muestra los factores resultantes del anlisis de la herramienta de identificacin
de riesgos propuesta en el captulo 4, seccin 4.3.3 y 4.3.4.
99
Tabla 20. Factores resultantes del anlisis de cuestionario
Factor 13
Factor 8
Factor 18
Factor 3
Factor 1
Factor 16
2.

Dificultad del diseo para probarlo
Lista provisional: Se utilizan como insumo aquellos riesgos percibidos por el
personal de desarrollo, supervisores y coordinadores de la compaa, en la etapa de perfil

de la compaa, captulo 4, seccin 4.2. Estos fueron agregados a la lista de riesgos
actual. Adems de eso se recomienda tener una lista de riesgos de proyectos realizados
por la compaa, en caso de que la compaa realice una buena documentacin de los
riesgos y lecciones aprendidas. En nuestro caso, la compaa no cuenta con esta
informacin documentada, pero los lderes tienen la experiencia en sta clase de
proyecto, gracias a las lecciones aprendidas del da a da. La Tabla 21, describe los
riesgos percibidos por los lderes de los equipos y los coordinadores.
Tbla 21. Lista de riesgos percibidos por los lderes
Amplio enfoque estratgico del rea de negocio
Falta de apoyo sostenido de la gerencia
Cambio constante de los requerimientos
Tiempo inadecuado para planificar
Planificacin ambiciosa del calendario de trabajo
Dependencia de las tareas
Falta de flexibilidad del diseo desairollado
Demora del proceso de revisin del cdigo
Problemas inesperados en la etapa integracin
10
Problemas en la efectividad de las herramientas de desarrollo
11
Problemas en el servicio de calidad de la tecnologa subcontratada
12
Inexperiencia del personal
13
Pobre planificacin del programa de formacin de gestin de procesos
14
Inexistencia de un [proceso de evaluacin del desempeo del personal

Gestin de riesgos insuficiente
15
100
3. Com paracin de la lista de riesgos con otras listas de la literatura: Se

compara la lista de riesgos con otras listas de riesgos encontradas en la literatura, con el
propsito de identificar aquellos riesgos que no se capturaron en el anlisis anterior.
Existen muchas taxonomas o clasificaciones para los riesgos de proyectos generales de
desarrollo de software. Entre las clasificaciones conocidas y ms mencionadas que
describen las fuentes de riesgo de proyectos de desarrollo de software se incluyen las
realizadas por Barry Boehm (1991), Caper Jones (1998) y SEI Software Risk Taxonomy.
En el captulo 2, la Tabla 2 describe los riesgos identificados en la literatura por
diferentes autores.
Al comparar la lista de riesgos con los riesgos encontrados por diferentes autores,
observamos que existen riesgos similares; por lo tanto se reemplaza el riesgo por el
nombre del factor encontrado en la literatura y se agregan nuevos riesgos, en caso que
exista alguno que aplique al proyecto. Ver Tabla 22.
4. Lista final de riesgos: Al realizar la identificacin de riesgos, es fundamental

lograr una clara descripcin del riesgo de forma tal que el mismo pueda ser comprendido
y manejado adecuadamente cuando se lo enuncia; considerando no slo el sntoma sino
tambin sus consecuencias. La Tabla 23 muestra la lista maestra de riesgos, con las
consecuencias y la clasificacin del riesgo.
5.2.2 Lista M aestra de riesgos actualizada
Finalmente se tiene la lista final de los riesgos, resultado de la compilacin de los

riesgos encontrados con la herramienta de identificacin de riesgos, los riesgos
percibidos, los riesgos de proyectos anteriores y los riesgos encontrados en la literatura.
101
Tabla 22. Comparacin de riesgos encontrados versus riesgos en la literatura

Dificultad del diseo para probarlo
Problemas en el proceso de definicin y control
de interfaces
Desarrollo incorrecto de las interfaces de

usuario (Boehm, 1991)
Confianza entre actores

Cambio constante en los requerimientos

(Boehm, 1991)

Falta de flexibilidad del diseo desarrollado
Demora del proceso de revisin del cdigo
Problemas inesperados en la etapa integracin
Problemas en la efectividad de las herramientas
de desarrollo
Problemas en el servicio de calidad de la
tecnologa subcontratada
Itinerario y presupuestos poco realistas

(Boehm, 1991)
Pobre calidad de las tareas subcontratadas

(Boehm, 1991)
Falta de personal cualificado
(Boehm, 1991)
Pobre planificacin del programa de formacin

de gestin de procesos
Inexistencia de un proceso de evaluacin del
desempeo del personal
Desarrollo incorrecto de las funciones
software
(Boehm, 1991)
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Tabla 23. Lista maestra dlos riesgos actualizada
1
2
3
4
5

7
8
9
10
11
12

Desarrollo incorrecto de las interfaces de usuario
Problemas inesperados en la etapa de integracin
Desarrollo incorrecto de las funciones software
Problemas en la efectividad de las herramientas de
desarrollo
Problemas en el servicio de calidad de la tecnologa
subcontratada
13
14
15
16
17
Falta de implicacin y participacin de los usuarios
18
Pobre planificacin del programa de formacin de

gestin de procesos
19
20
21
Inexistencia de un proceso de evaluacin del desempeo

del personal
Gestin de procesos inadecuada / Alcance

Acumulacin del trabajo / Afecta tiempo
Inestabilidad del cdigo / Afecta calidad
Pobre gestin del proyecto / Afecta alcance
Mala subdivisin de tareas / Afecta tiempo
Afecta actividades crticas de desarrollo: anlisis de
requerimientos y diseo. Por otro lado afecta la
productividad del personal
Desarrollo lento /Afecta tiempo
Inestabilidad del software / Afecta calidad
Diseo ineficiente, no se puede reusar / Afecta calidad
Problemas de compatibilidad / Afecta calidad
Inconformidad del cliente / Afecta costos
Organizacional
Organizacional
Organizacional
Organizacional
Planificacin
Afecta calidad del software
Tecnolgico
Afecta calidad
Afecta el desarrollo del software / afecta calidad
Proceso
Tecnolgico
Requerimientos inestables / Retraso del proyecto
Tecnolgico
Planificacin
Planificacin
Proceso
Proceso
Proceso
Proceso
Proceso
Desarrollo de requerimientos incorrectos / Se afecta la

calidad del sistema
Pobre efectividad de las herramientas de seguimiento y
control de las tareas / Poca visin sobre la capacidad
del equipo
Sobrecarga de trabajo en equipos o personas en
especfico/ Afecta tiempo
Planificacin
Afecta calidad
Organizacional
Desarrollo lento / Afecta tiempo
Proceso
Organizacional
Organizacional
102
103
5.3 Fase 3. Anlisis de los riesgos

El anlisis de riesgos consiste en convertir los atributos del riesgo en informacin
que sirva como base para tomar decisiones. El anlisis de riesgos en el proyecto en
estudio se organiz en tres pasos: anlisis cualitativo de los riesgos, anlisis cuantitativo
de los riesgos y clasificacin y priorizacin de los riesgos.
5.3.1. Anlisis cualitativo de los riesgos
En esta etapa se desarroll una matriz de severidad de riesgo, en donde se

identifican los riesgos usando la probabilidad de ocurrencia y el impacto en los objetivos
del proyecto, en caso de que los riesgos llegaran a ocurrir.
1.
Evaluacin de los riesgos en la m atriz de severidad del riesgo: La escala a
utilizar y dems aspectos fueron descritos en el captulo 3, seccin 3.4.3. En esta etapa se
utiliza la lista de riesgos recolectada en la etapa de identificacin anterior, con el
propsito de clasificar los riesgos que ms impactan al proyecto.
La forma en que el personal debe analiza r los riesgos es tomando cada riesgo,
perteneciente a la lista maestra de riesgos recolectada en la etapa anterior, identificado los
potenciales efectos adversos (consecuencia) y el criterio o informacin utilizado para la
clasificacin, valorando su probabilidad y luego su impacto. Posteriormente se
multiplican estos dos factores y se calcula el valor de exposicin, lo cual dar a conocer
si el riesgo es alto, moderado o bajo. Finalmente se ordena la lista por el nivel de
clasificacin (alto a bajo), lo cual proporciona una base para asignar prioridades en el
proceso de planificacin. La Tabla 24 describe el proceso realizado en el proyecto.
Tabla 24. Evaluacin de los riesgos en la matriz de severidad de riesgo
1
2
3
4
5

0.70
0.90
0.90
0.70
0.70
0.20
0.40
0.40
0.20
0.40
0.14
0.36
0.36
0.14
0.28
5
1
1
5
2
0.90
0.40
0.36

Desarrollo incorrecto de las interfaces de usuario
Gestin de procesos inadecuada / Alcance

Acumulacin del trabajo / Afecta tiempo
Inestabilidad del cdigo / Afecta calidad
Pobre gestin del proyecto / Afecta alcance
Mala subdivisin de tareas / Afecta tiempo
Afecta actividades crticas de desarrollo: anlisis de
requerimientos y diseo. Por otro lado afecta la
productividad del personal
Desarrollo lento /Afectatiempo
Inestabilidad del software / Afecta calidad
7
8
9
0.50
0.50
0.50
0.20
0.20
0.40
0.10
0.10
0.20
6
6
3
10
Diseo ineficiente, no se puede reusar / Afecta calidad
0.50
0.20
0.10
11
12
Problemas inesperados en la etapa de integracin

Desarrollo incorrecto de las funciones sofiware
Problemas en la efectividad de las herramientas de
desarrollo
Problemas en el servicio de calidad de la
tecnologa subcontratada
Falta de implicacin y participacin de los
usuarios
Problemas de compatibilidad / Afecta calidad

Inconformidad del cliente / Afecta costos
0.90
0.50
0.20
0.40
0.18
0.20
4
3
0.70
0.20
0.14
0.70
0.70
0.20
0.20
0.14
0.14
5
5
0.50
0.20
0.10
0.90
0.40
0.36
0.70
0.20
0.14
0.70
0.40
0.28
0.70
0.10
0.07
0.90
0.40
0.36
13
14
15
16
17
18
Pobre planificacin del programa de formacin de

gestin de procesos
19
20
21
Inexistencia de un proceso de evaluacin del

desempeo del personal
Afecta calidad del software

Afecta calidad
Afecta el desarrollo del software / afecta calidad
Requerimientos inestables / Demoraretraso del
proyecto
Desarrollo de requerimientos incorrectos / Se afecta la
calidad del sistema
Pobre efectividad de las herramientas de seguimiento y
control de las tareas / Poca visin sobre la capacidad del
equipo
Sobrecarga de trabajo en equipos o personas en
especfico/ Afecta tiempo
Afecta calidad
Desarrollo lento / Afectatiempo
-t.
105
Esta lista priorizada es un punto de partida del proceso de gestin de riesgos

subsiguiente y por ello debe actualizarse a lo largo de todo el dclo de anlisis,
planeamiento y supervisin de los riesgos.
Si se observa, de acuerdo a la probabilidad e impacto, a cada riesgo se le asigna

un factor de exposicin al riesgo. De acuerdo a su valor se clasifica en la matriz de
impacto - probabilidad y se asigna una categora, que puede ser riesgo bajo, alto o
moderado. A continuacin se nombran los riesgos cuya exposicin se clasifica dentro de
la matriz de probabilidad e impacto como de alto riesgo.
1. Amplio enfoque estratgico del rea de negocio

2. Cambio constante en los requerimientos
3. Planificacin ambiciosa del calendario de trabaj o
4. Falta de implicacin y participacin de los usuarios
5. Gestin de riesgos insuficiente
6. Tiempo inadecuado para planificar
7. Inexperiencia del personal
8. Desarrollo incorrecto de las interfaces de usuario
9. Problemas inesperados en la etapa de integracin
5.3.2 Anlisis Cuantitativo de los riesgos
Es importante aclarar en esta etapa, que debido a su naturaleza la compaa est

tratando de mejorar sus tcnicas de seguimiento y control; pero por aspectos como falta
de tiempo y acumulacin del trabajo, todava no ha logrado hacer un seguimiento en
tiempo real a las tareas realizadas. Actualmente la forma de dar seguimiento a las tareas,
es mediante la planificacin exhaustiva de lo que se pretende hacer en un ciclo.
106
Las tareas son subdivididas y el tiempo es asignado en consenso entre el lder y los
participantes. El problema est en dar seguimiento en tiempo real. El desarrollador debe
de colocar las horas trabajadas en una tarea en tiempo real, pero cmo no es prioridad, a
veces se hace y en ocasiones no se hace.
En promedio se planifican un total de 20 a 40 requerimientos, dependiendo de las

prioridades del momento y del mercado. Actualmente se cuenta con 18 personas a tiempo
completo y 5 personas a tiempo parcial, sin contar con el personal que est planeado
contratar. El personal est trabajando el doble de lo deseado, debido a l a agresividad de la
metodologa por ciclos planteada. Lo ideal es llegar a un punto en donde se logre
satisfacer las expectativas del rea de negocio y el cliente al final de un ciclo y a la vez se
logre un balance de la carga laboral del personal.
5.4 Fase 4. Planeacin de respuesta al riesgo

El principal objetivo de esta fase de planeacin de respuesta al riesgo, consiste en
desarrollar un plan detallado para controlar los riesgos ms importantes identificados
durante el anlisis de riesgos e integrarlos en los procesos de administracin estndar del
proyecto para garantizar su realizacin.
Durante el planeamiento de la accin de riesgos, el equipo debe tener en cuenta las

cuatro alternativas: Mitigar, evitar, transferir y aceptar. A continuacin se plantean las
estrategias a seguir para los riesgos identificados en la etapa de anlisis de riesgos.
1. Riesgo: Amplio enfoque estratgico del rea de negocio
Tipo: Organizacional
Probabilidad: 0.90
Impacto: 0.40
Riesgo Percibido. 0.36
107
Detalle: En ocasiones el rea de negocios se compromete demasiado con los clientes, con
fechas de entrega agresivas; sin estimar robustamente la duracin de cada requerimiento;
teniendo en cuenta la dificultad de la tarea y el alcance de sta.
Respuesta, al riesgo: Aceptar

Estrategia Recomendada: Negociacin con el rea de negocios sobre el trabajo a
desarrollar en cada ciclo. Es importante que el rea de negocios de mayor importancia al
criterio del rea de desarrollo, pues son estos que conocen la dificultad del trabajo y la
capacidad del personal.
2. Riesgo: Cambio constante de los requerimientos
Probabilidad: 0.90
Impacto: 0.40
Riesgo Percibido: 0.36
Detalle: Actualmente los requerimientos son inestables. El cliente tiene el poder de

cambiar de idea continuamente, sin importar el estado actual de los requerimientos
pactados. Esto debido a que no hay un acuerdo formal entre cliente y el rea de negocios.
Respuesta al riesgo: Mitigar

Estrategia Recomendada. Proceso de captura de los requerimientos. En ste se debe
tener especial consideracin con los criterios del rea de desarrollo. U na vez el cliente
haya identificado sus necesidades, el rea de negocios junto con la lista de requerimientos
deber negociar directamente con el rea de desarrollo con el propsito de identificar la
viabilidad de los requerimientos y las prioridades. Finalmente la lista actualizada deber
regresar de nuevo al cliente y en conjunto con el rea de negocios se decidir si las partes
estn de
acuerdo,
firmando
finalmente un
contrato
para
cerrar el negocio;
comprometiendo de esta forma al cliente.
3. Riesgo: Planificacin ambiciosa del calendario de trabajo
Probabilidad: 0.90
Impacto: 0.40
108
Detalle: Actualmente la metodologa para el desarrollo de software es bastante agresiva,

pues consta de plazos de entrega muy cortos. Fijar un plan excesivamente agresivo
predispone a que el proyecto falle por falta de tiempo, minimizando la planificacin
efectiva y reduciendo las actividades crticas para el desarrollo del software, como el
anlisis de requerimientos o el diseo. Tambin supone una excesiva presin para los
desarrolladores, quienes a largo plazo se ven afectados en su motivacin y su
productividad.

Estrategia Recomendada: Invertir en programas de planificacin y seguimiento y control
sera de gran ayuda para la compaa. Esto disminuira el tiempo en planificacin y
permitira una estimacin en tiempo real de las tareas.
4. Riesgo: Implicacin y participacin de los usuarios
Probabilidad: 0.90
Impacto: 0.40
Detalle: Cuando se inicia un proyecto de desarrollo de software se conoce la importancia

de la participacin del cliente para lograr su terminacin exitosa. La compaa involucra
al cliente solamente al inicio y al final del proyecto, pero no
existe una
retrocomunicadn con el personal en la etapa de desarrollo, lo que en la mayora de los

casos produce un alto grado de insatisfacdn en el usuario al no obtener el producto con
las espedficadones esperadas. El cliente es quien realmente conoce el valor que aportar
el producto que est siendo desarrollado y puede definir las prioridades desde la
perspectiva organizacional.
109
Estrategia Recomendada: Contar con la participacin del cliente en el proceso de

planificacin de las fases y de las iteraciones. Posteriormente se requiere su participacin
en cada iteracin para proveer retroalimentadn temprana al equipo de desarrolladores,
garantizando el cumplimiento de las expectativas que tiene, adems de ofrecerle una
visibilidad permanente del estado del proyecto, asegurando su compromiso para
terminarlo exitosamente. Se debe tener en cuenta que el cliente no se interesa por los
aspectos tcnicos de alta complejidad y riesgo, razn por la cual se debe combinar esta
prctica con una orientacin al manejo del riesgo.
5. Riesgo: Gestin de riesgos insuficiente
Probabilidad: 0.90
Impacto: 0.40
Detalle: Actualmente no existe ningn proceso de gestin de riesgos. Se ha pensado en

una lista de riesgos en un futuro, pero no existe un proceso definido de cmo analizar y
controlar los riesgos en esta clase de ambientes.

Estrategia Recomendada: Implementar en la cultura de la compaa metodologas como
la planteada, entrenando al personal en estos mtodos. Otro aspecto importante es la
comunicacin, ya que para tener una gestin eficaz, se debe tener una comunicacin
abierta y ejercida de una manera continua. Para esto, se plantea llevar a cabo reuniones,
informes peridicos del estado de los riesgos, documentacin en tiempo real por Web,
entre otras.
6. Riesgo: Tiempo adecuado para planificar
Probabilidad: 0.70
Impacto: 0.40
110
Detalle: Actualmente el tiempo que se da a la etapa de planificacin es bien poco. El

trabajo de los lderes se acumula, pues continuamente estn resolviendo problemas
inesperados debido a la agresividad de la metodologa por ciclos desarrollada. Por otra
parte, el personal encargado de planificacin no slo est dedicado a eso, sino que a su
vez cumple las funciones de desarrollador y lder. Esto unido a que en cualquier
momento puede ocurrir nuevas entradas de requerimientos o cambios inesperados.

Estrategia Recomendada: Aumento en una semana de la etapa de planificacin, para que
el personal puede estimar correctamente las actividades a realizar. Es decir que en lugar
de 7 semanas que dura el ciclo, extenderlo a 8 semanas.
7. Riesgo: Inexperiencia del personal
Probabilidad: 0.70
Impacto: 0.40
Detalle: La mayora del personal contratado tiene mucho potencial pero poca experiencia
laboral; debido a que contratar personas con experiencia es demasiado costoso.
Actualmente, cada persona est encargada de una tarea en especfico, la cual es
desarrollada hasta el final; es decir a cada persona se le asigna una tarea dependiendo de
su rea fuerte. Esto ocasionada que la carga laboral est mal distribuida, pues existen
equipos con demasiado trabajo o personal sobrecargado.

Estrategia Recomendada:
1.
Programacin por parejas (pair programming): Est basado en el principio de que
dos personas trabajando juntas pueden hacer ms que por separado. El resultado de esto
es una mejora en la calidad del cdigo, adems no supone tardar ms tiempo.
111
2.
Rotar al personal dentro del equipo: No se puede permitir que todo el equipo
dependa de que la nica persona que conoce algo, est disponible o no. Puede ocurrir que
esa persona deje la compaa o que est sobrecargada en un momento dado. Por lo tanto
al rotar al personal a una parte del sistema distinta en cada iteracin, se evitaran las islas
de conocimiento, se aumentara la flexibilidad del equipo y se contara con personal
preparado para ser reasignado en caso de ser necesitado en otra rea.
8 . Riesgo: Desarrollo incorrecto de las interfaces de usuario
Tipo: Proceso
Probabilidad: 0.50
Impacto: 0.40
Detalle: Al no existir un proceso estndar de diseo; aspectos como cambios continuos

en los requerimientos de software y de hardware; dan origen a problemas de
inestabilidad de diseo e inestabilidad del cdigo.

Estrategia Recomendada: Se proponen formas de trabajo giles, que puedan ayudar a
evitar muchos de estos errores. Adems de sto debe existir una comunicacin con el
cliente de forma proactiva. A continuacin se plantean algunas estrategias a seguir:
1.- Simplicidad de cdigo y de diseo para producir software fcil de modificar.

2.- Reingeniera contina para lograr que el cdigo tenga un diseo ptimo: A veces
mantener cdigo antiguo no slo no supone un ahorro de tiempo, sino un serio
inconveniente. Si es necesario se debe eliminar la redundancia, las funcionalidades que
no se usan en mucho tiempo o cambiar diseos antiguos.
112
3 - Desarrollar estndares de codificacin para comunicar ideas con claridad a

travs del cdigo. Existen publicadas algunas normas sobre como se debe codificar en un
lenguaje. Es conveniente seguir alguno de esos estndares por todos los miembros del
equipo para que el cdigo sea luego fcil de comprender y de mantener por todos.
4.- Desarrollar un vocabulario comn para comunicar las ideas sobre el cdigo con
claridad: La nomenclatura es la forma en la que se escoge el nombre de las cosas. De cara
a comprender bien el diseo general del sistema y poder reutilizar el cdigo hay que
escoger una forma de dar nombre a las clases y mtodos de forma que todo el mundo lo
pueda comprender fcilmente y que sea consistente.
9. Riesgo: Problemas inesperados en la etapa de integracin
Probabilidad: 0.90
Impacto: 0.20
Detalle: En la integracin se juntan los pequeos mdulos de software que tenemos y que
parece que funcionan, pero resulta que esos pequeos trozos slo han superado pruebas
de unidad donde no han tenido que interactuar con otros mdulos. El problema es que
existen errores que slo surgen en esa interaccin y ese es precisamente el problema de la
integracin.

Estrategias recomendadas:
1. Adoptar un mtodo de desarrollo basado en las pruebas para asegurar que el
cdigo se comporta segn lo esperado.
2. Asumir la propiedad colectiva del cdigo, para que todo el equipo sea
responsable de l, de tal forma que cualquier persona del equipo pueda corregir errores,
aadir funcionalidades, no slo de su cdigo, sino tambin del de los dems. Lo que se
pretende es que todos puedan aportar algo.
113
Esto significa que la arquitectura del sistema en cierto modo la decide el equipo en
su conjunto, lo cual resulta chocante para la mentalidad de la programacin estructurada.
De esta manera el cdigo va a hacer ms fiable y si una persona se atasca en un
problema, se le ayuda y as de esta forma su parte es un problema para otros.
3.
Integracin continua, para reducir el impacto de la incorporacin de nuevas
funcionalidades: Actualmente se somete el cdigo y se hace la integracin una sola vez.

Se propone hacerla de forma secuencia! En un mismo momento slo puede existir una
pareja de programadores integrando su cdigo. La integracin debe hacerse cada poco
tiempo, idealmente, cada pocas horas hay que dejar cdigo nuevo en el almacn.
Todo el mundo debe hacer integraciones con la ltima versin disponible, de sta
forma se evita trabajar con un cdigo obsoleto. De esta manera, haciendo muchas mini
integraciones los problemas que surgan al final cuando se haca la nica integracin se
van resolviendo sobre la marcha.
Una vez planteadas las acciones de respuesta a los riesgos potenciales, se debern
planificar los recursos y las actividades de mitigacin para los riesgos con importancia
alta. Para esto se deben asignar responsables, crear un plan de accin para cada riesgo,
crear un plan de mitigacin si la accin es mitigar. La Tabla 25 presenta un formulario
para documentar el proceso de planeacin de respuesta al riesgo.
Tabla 25. Formulario para la etapa de planeacin de la respuesta a los riesgos
Prioridad
Cdigo
del
n esgo
Prioridad
identifica
da en la
etapa de
anlisis de
riesgo
Fecha de
Identificado
n
Respuesta al
riesgo
Planes de
mitigadon
Planes de
contingencia
Fecha de
activacin de
los planes
Identifique la
fecha donde
fue
identificado
el riesgo
E strategia de
respuesta al
riesgo:
transferir,
m itigar,
evitar o
aceptar
Identifique las
estrategias a
seguir para
re d u c irla
probabilidad
que el riesgo
ocurra
Identifique
las
estrategias a
seguir para
reducir el
im pacto del
riesgo en los
objetivos del
proyecto
Identifique la
fecha de
activacin de
los planes de
contingencia
Persona
responsable
del plan
Actividades
y tareas
Duracin de
las tareas
Fecha limite
para
realizar el
plan
Persona
responsable
del plan
Identifique
las tareas y
las
actividades
asociadas
para h acer
cum plir el
plan
Identifique
p ara cada
tarea
planificada,
la fecha de
inicio y la
fecha de
term inacin
F e c h a limite
del plan
Identifique
los recursos
y
requerim i ent
115
5.5 Fase 5. Seguimiento y control del riesgo

El seguimiento de riesgos supervisa el estado de los riesgos y el progreso de sus
planes de accin. El seguimiento de riesgos incluye la supervisin de probabilidades,
impactos, exposiciones y otras medidas de riesgo para los cambios que pudiesen
alterar los planes de prioridades o de riesgos y las caractersticas, los recursos o la
programacin del proyecto.
Por otra parte, la fase de control tiene como objetivo corregir las desviaciones
de los planes de mitigacin, adems de controlar los riesgos de la lista actual del
proyecto. Por lo tanto se debe de estar atento a nuevos riesgos que puedan aparecer en
su entorno a medida que el proyecto avanza. La Figura 34 describe el proceso de
seguimiento y control propuesto.
Plan de manejo de.

riesgos
Plan de respuesta
de riesgos
Plan de
comunicaciones
del proyecto^-"
Auditoria de respuesta al
riesgo
Revisiones peridicas de
los riesgos del proyecto
Mediciones de desempeo
tcnico
Lista adicional de
otros riesgos para
___
anlisis
Planeacin adicional de
respuesta al riesgo
Etapa de anlisis de riesgo
Actualizacin de la lista
maestra de riesgos.
Figura 34. Flujograma de la fase de seguimiento y control
116
La Tabla 26, presenta un formulario de seguimiento y control de riesgos. Este le

ayuda al personal a tener una visin de los estados de los riesgos de la organizacin.
Tabla 26. Formulario para el proceso de control de riesgos
Alta, media
o baja
Acciones planteadas
Activo o
inactivo
Fecha
Nombre de la
persona que
esta haciendo
control de los
riesgos
Finalmente para una gestin eficaz de los riesgos, una organizacin debe tener
una comunicacin abierta ejercida de manera continua. sta puede ser tanto formal
como informal. Se recomienda llevar a cabo las siguientes actividades: presentaciones
y talleres de gestin del riesgo a los miembros del equipo, publicacin de la lista de
riesgos, informes peridicos del estado de los riesgos del proyecto a los directores
tcnicos, al jefe del proyecto y a la comisin de seguimiento. Adems todos estos
documentos debern ser parte integral del proceso de planificacin.
6. CONCLUSIONES Y TRABAJOS FUTUROS
Este captulo resume los hallazgos encontrados en este proyecto. Est divido en:
conclusiones y recomendaciones, limitaciones del estudio y recomendaciones para
trabajos futuros.
6.1 Conclusiones y recomendaciones
La finalidad de este proyecto es desarrollar y probar una metodologa de gestin

de riesgos, aplicada en una compaa pequea de desarrollo de software de proyectos
cortos; tomando como base diferentes enfoques, mtodos formales desarrollados por
el PMI (Project Management Institute), SEI (software Engineering Institute) y
mtodos giles como los desarrollados por Microsoft. La metodologa se divide
principalmente en dos etapas: La primera parte es el anlisis del perfil de la
compaa: misin, visin, productos, metodologa de desarrollo de software
utilizadas, tcnicas de seguimiento y control, entre otras. Adicionalmente se
identifican los riesgos percibidos por parte del personal, con el propsito de analizar
el estado actual de la compaa y definir la viabilidad de una metodologa de gestin
de riesgos. La segunda parte de la metodologa tiene como propsito proveer
evidencia emprica de la gestin de riesgos en compaas de desarrollo de tecnologa
de informacin, ante la falta de casos reales en este campo. Se identific una
compaa como caso estudio y se desarroll un proceso formal de gestin de riesgos
en donde los factores de riesgos fueron identificados, evaluados y mitigados, tomando
como base las herramientas y tcnicas existentes; abordando de forma sistemtica la
gestin de riesgos en esta clase de proyectos.
117
118
Un tema a resaltar es la metodologa de desarrollo de software adoptada por la

compaa. Esta se basa en una metodologa iterativa y de desarrollo incremental. Las
iteraciones se entienden como ejecuciones reducidas del proyecto que aaden nueva
funcionalidad al sistema. Para ejecutarlas se capturan los requerimientos y se realiza
el ciclo de vida clsico de desarrollo de software (anlisis, diseo, implementacin y
prueba). Entre las ventajas obtenidas, la metodologa por ciclos permiti a la
compaa tener un mejor control y seguimiento del trabajo, mejorando las
estimaciones de entrega, abordando los problemas ms graves al principio del
proyecto evitando sorpresas desagradables en etapas avanzadas; y logrando una
mayor fiabilidad, ya que cada iteracin es probada. Entre las desventajas se observ
que sta exige especial cuidado en la planificacin, pues los ciclos son bien agresivos
en cuanto a tiempo y podra ocasionar acumulacin de trabajo; mientras se aprende
cul es la capacidad del equipo y hasta donde se puede comprometer. En conclusin,
debido a la naturaleza de esta clase de compaas, a su flexibilidad y a la agresividad
de la metodologa de desarrollo de software; se recomienda el desarrollo de la gestin
de riesgos para que sta pueda reaccionar de manera proactiva a las amenazas del
entorno.
En cuanto a la segunda parte de la metodologa, se desarroll una herramienta

con el propsito de brindar un soporte adecuado y estandarizado a los administradores
de proyectos, especficamente durante la fase de identificacin de riesgos en
organizaciones que comienzan con la implementacin formal de las tareas de gestin
de riesgos. Posteriormente se administr la herramienta y se identificaron
cuantitativamente los riesgos ms relevantes utilizando tcnicas de anlisis
multivariado. Una vez definidos los factores, se realiz un anlisis de regresin contra
una variable dependiente (nivel de riesgos en esta clase de proyectos), para conocer
cules son los factores ms relevantes estadsticamente. Finalmente se unific la
informacin obtenida con aquellos riesgos que aplicaban en este caso, encontrados en
la literatura y en proyectos anteriores, obteniendo de esta forma la lista maestra de
riesgos del proyecto.
119
El total de factores encontrados fue de 21, entre los cuales se encuentran 14

riesgos tcnicos y 7 organizacionales: amplio enfoque estratgico del rea de negocio,
falta de apoyo sostenido de la gerencia, cambio constante de los requerimientos, falta
de
participacin
entre
los
implicados, tiempo
inadecuado
para planificar,
planificacin ambiciosa del calendario de trabajo, dependencia de las tareas, precisin

de problemas inesperados, desarrollo incorrecto de las interfaces de usuario, falta de
flexibilidad del diseo desarrollado, problemas inesperados en la etapa de integracin,
desarrollo incorrecto de las funciones software, problemas en la efectividad de las
herramientas de desarrollo, problemas de confiabilidad del software, falta de
disponibilidad efectiva de los recursos, problemas en el servicio de calidad de la
tecnologa subcontratada, falta de implicacin y participacin de los usuarios, pobre
planificacin del programa de formacin de gestin de procesos, inexperiencia del
personal, inexistencia de un proceso de evaluacin del desempeo del personal y
gestin de riesgos insuficiente.
Analizando los factores de riesgos ms relevantes se encontr que los riesgos

ms importantes hacen referencia en su mayora a riesgos organizacionales. Esto es
debido a que el personal se siente ms amenazado por estos riesgos que por lo
tcnicos. Los riesgos tcnicos tienen siempre una solucin, que en la mayora de los
casos depende en su mayor parte del presupuesto y la disponibilidad de la tecnologa;
mientras que los riesgos organizacionales van ms all de las fronteras del proyecto..
Sin embargo, aparte de la herramienta de identificacin de riesgos se utilizaron

otras tcnicas de recoleccin de informacin como entrevistas y listas de riesgos
existentes en la literatura. En este proyecto las entrevistas realizadas a los directores
tcnicos fueron de gran ayuda para la recoleccin de datos referentes a los riesgos.
Autores como (Kontio,1997), mencionan que la informacin de entrevistas es ms
detallada y permite una mejor calidad de los resultados de la gestin de riesgos,
quizs debido a la naturaleza confidencial de las entrevistas y a la posibilidad de
concentrarse y profundizar de forma abierta en temas mas concretos.
120
En cuanto a la viabilidad de la metodologa propuesta, en trminos generales,

las personas que participaron en el proceso de gestin del riesgo estn de acuerdo con
que este tipo de metodologas presentan un enfoque vlido y positivo para abordar la
gestin de riesgos en proyectos de desarrollo de software.
Recomendaciones p ara tener una buena respuesta a los riesgos
Si uno considera que las respuestas al riesgo tienen la misma importancia que
otras tareas del
proyecto, esto animar a la gente a implementarlas. Cuando los
interesados en las repuestas se dan cuenta de que estas acciones son importantes para
el xito del proyecto y que las respuestas al riesgo se tratarn como tareas legtimas
de proyecto, entonces se les dar el mismo grado de atencin y esfuerzo que a sus
otras tareas. Al considerar las respuestas al riesgo como trabajo adicional, optativo,
diferente, uno les est considerando como de segunda clase, algo aparte del trabajo
serio. Aceptando que son tareas vlidas e indispensables que hacen una contribucin
significativa al realizar objetivos asegura que se tratarn con seriedad y se
implementarn de hecho. Despus de todo, identificar respuestas al riesgo pero no
implementarlas es una prdida de tiempo completa.
A continuacin se plantean, algunas ideas para que el proceso de responder a los

riesgos se integre en la organizacin:
Asegurar que cada respuesta al riesgo se defina plenamente, con duracin,

costos, requisitos de recursos, interesados, etctera.
Aadir una tarea adicional al plan del proyecto para cada respuesta convenida
(aceptando que esto podra exigir tambin cambios en el presupuesto o plazo
del proyecto).
Seguimiento continuo al progreso de las tareas de responder al riesgo de la

misma manera como para todas las otras tareas, incluido el exigir informes de
interesados y evaluacin en las reuniones de proyecto.
121
6.2 Limitaciones del estudio

Los resultados obtenidos en este proyecto se encuentran limitados por diferentes
factores:
El tamao de muestra utilizado puede no ser representativo de una poblacin

entera.
Pobre involucramiento del cliente: debido a problemas de localizacin, no se

pudo obtener la retrocomunicadn del cliente.
6.3 Recomendaciones p ara trab ajo s futuros
Algunas recomendadones para investigaciones futuras son:
Se recomienda para futuros proyectos, incorporar tcnicas de recoleccin de

inform adn en tiempo real, con el propsito de obtener una mayor cantidad
de datos cuantitativos.
Extender este estudio, partiendo del repositorio de riesgos desarrollado en este

proyecto; con la partidpacin de todos los implicados: personal, proveedores,
rea de negocios y clientes finales.
Desarrollo de herramientas de identificacin de riesgos, ms concisas, con el

propsito de hacer ms efectivo el proceso inidal de identificadn de riesgos.
Extender este estudio, utilizando como herramienta el despliegue de la

fundn de calidad, con el propsito de convertir la demanda de clientes en
caractersticas de calidad y de desarrollar un plan de calidad que muestre un
despliegue de la reladn entre las demandas de los clientes y las
caractersticas de calidad que debe poseer ese producto o servido (Prasad,
1998).
5. BIBLIO G RAFIA
Alarcn, C., Figueroa, L. (2005). Planificacin y control de proyectos. Diplomado de

Extensin en Administracin y Direccin de Proyectos.
PMBOK Guide. (2004). A Guide to the Project Management Body o f Knowledge,
Newtown Square: Project Management Institute.
Barki, H.A. (1993). Toward an assessment o f software development risk. Journal of
Management Information System risk. Vol. 10, Iss.2; pg.203, 23 pgs.
Boehm, B.W. (1986). A spiral model o f software development and enhancement.

ACM Sigsoft Software Engineering Notes.
Boehm, B.W. (1991). Software risk management : principies and practices. IEEE
Software, pp.32-41.
Carr, S., Marvin, J. (1993). Taxonomy-Based Risk Identification, CMU/SEI-93-TR-6,
Software Engineering Institute. Camegie Mellon University, Pittsburgh,
Pennsylvania.
Cea, MA. (1996). Metodologa cuantitativa: Estrategias y tcnicas de investigacin
social. Madrid.
Chatterjjee, S., Hadi, A. (2000). Regression Analysis by Example. John Wiley &
Sons, Inc, New York, USA.
Esteves, J., Pastor, J. (2000). Towards the Unification o f Critical Success Factors for
ERP implementations, lOth Annual BIT conference, Manchester, UK.
Figueras, M. (2000). Introduccin al Anlisis Multivariante.
http://www.5campus.comfleccion/anamul.
Graves, Roger. (2000). PM QualitativeRiskAssesment-NetWork October.
122
123
Grupo ISSI. (2003). Ingeniera del Software y Sistemas de Informadn.

Colaboradores. Universidad Politcnica de valencia. Taller realizado en el marco de
las VIII Jomadas de Ingeniera del Software y Bases de Datos.
Hoffman, T. (1998). Risk Management sti.ll a wild frontier. Computerworld, 32 (7),
p.10.
Jones, C. (1998). Minimizing the risks o f software development. Cutter IT Journal
vol. 11 (6), 13-21.
KLCI. (2001). Software Risk Management Piactices. KLCL research group report,
available at http://www.klci.com .
Kontio, J. (1997). Empirical Evaluation o f a risk management Method. SEI
conference on risk management, USA.
Larman, Craig. (2003). Age and Iterative Development: A Managers Guide.
Addison-Wesley Agile Software Development Series.
Mendoza, Mara, A. (2004). Metodologas De Desarrollo De Software. UNT
Microsoft Certified Professional Per S.A.C.
Maniasi, Sebastian. (2000). Identificacin de riesgos de proyectos de software en base
a taxonomas.
Martin, J. (1991). Rapid Application Development, Macmillan Inc., New York.
Montgomery, D., Peck, E and Vining, G. (2001). Introduction to Linear Regression
Analysis.
Project Risk Management Handbook. (2003). Office of Project Management Process
Improvement. First Edition.
Project Management Institute. (2004). A Guide to the Project Management Body of
Knowledge (PMBOK Guide). Newtown Square: Project Management Institute.
Peterson, R. (2000).
Publishing Inc.
Constructing
Effective Questionaries.
California:
Sage
124
Rancn, Claudio. (2003). Gestin de configuracin de productos software en etapa de

desarrollo.
RUP. (2002). Rational Unified Process. Copyright Rational Software Corporation,
All Rights Reserved.
Schwaber, K., Ken, Mike Beedle, (2001). Agile Software Development with Serum.
Prenti.ee Hall.
Snchez, M. (2003). Metodologas de Desarrollo de Software. Disponible en
http://www.informatizate.net.
Simn, P., Hillson, D. and Newland, K. (1997). Project risk analysis and management
guide. Association for Project Management.
Vargas, Marcela. (2000). Gestin de Proyectos de Desarrollo de Software.
Departamento de Ingeniera Informtica y Ciencias de la Computacin. Facultad de
Ingeniera Universidad de Concepcin.
Anejo 1. Cronograma de actividades - Caso de estudio
T ask am e
Duration
Start
Finish
Proyecto gestin de proyectos y de riesgos en en el desarrollo de sistemas de Informacin

Revisin de literatura
312 days
SO days
Mon 8/16/04
Tue 1025/05
Mon 0/16/04
Fri 1022/04
B squeda d e informacin
30 d ay s
Mon 8/16/04
Fri 9 2 4 /0 4
identificacin del secto r de estudio
20 d ay s
Mon 9/27/04
Fri 10/22/64
Anlisis del sector
25 days
Mon 1025/04
Prei (V
|
3
Fri 1126/04
B squeda d e co m p a as para ca so estudio
15 d ay s
Mon 10/25/04
Fri 11/124)4
Entrevista con las co m p a as seleccio n ad as
10 d ay s
Mon 11/15/04
Fn 11/26 4X4
Familiarizacin con la compaa caso estudio
25 days
Mon 1129/04
Entrevista con el director
5 days
Mon 11/29/04
Entrevista con los coordinadores
5 days
Mon i 2/6434
15 d ay s
Mon 12/13/04
212 days
Mon 1/3/05
Conocim iento general con el am biente laboral de la com paa
Desarrollo de la metodologa
Fri 12/31/04
Fri 12/3/04
Fri 12/104)4 ! 9
Fri 12/314)4
10
Tue 1025/05
Identificacin de herram ien tas y m todos de gestin de riesgos
20 d ay s
Mon 1/3/05
Fri 1/2B/05
D escripcin las f a s e s de la m etodologa
20 days
Mon 1/31/05
Fii 2/25/05
13
Construccin de una herramienta de identificacin de riesgos
50 days
Mon 220/05
Fri 5/6/05
B squeda de h erram ien tas de identificacin de riesgos en la literatura
20 d ay s
Mon 2/2B/05
Fri 3/25/05
14
D epuracin del cuestionario encontrado en la revisin de literatura
10 d ay s
Mon 3/2B/05
Fri 4/8/05
16
Reform ulacin de las p reg u n tas y cambio de escala
10 d ay s
Mon 4/11/05
Fri 4/22/05
17
Identificacin y redaccin de n u ev as p reg u n tas potenciales
10 d ay s
Mon 4/25/05
Fri 5/8/05
10
5 days
Mon 5/9/D5
V alidacin del cuestionario final
Administracin y anlisis de la herramienta de identificacin de riesgos

Identificacin del tam ao de m uestra
05 days
Mon 5/164)5
5 days
Mon 5/16/05
Administracin de la herram ienta al p erso n al de la com paa ca so estudio
50 d ay s
Mon 5/23/05
A nlisis estadstico de lo s datos
20 d ay s
Mon 8/1/05
H allazgos en co n trad o s
Gestin de riesgos en la compaa caso estudio

Elaboracin de la lista m aestra de los riesgos
A nlisis de los riesgos
Planeacin de re sp u e sta a los riesgos
Seguim iento y control d e riesgos
Presentacin de resultados
Fri 5 /1 3 /0 6 " .1 5 "
Fri 9/9/05
Fri 5 / 2 0 / t j f ; 20
Fri 729435
22
Fri 8 2 6 /0 5 >23
10 d ay s
Mon 8 2 9 /0 5
Fri 9/9/05
25 days
Mon 9/124)5
Fri 10/14/05
24
5 days
Mon 9/12/05
Fri 9/16/05
1D days
Mon 9/19/05
Fri 9/30/05
27
5 days
Mon 10/3/05
Fri 10/7/05
2B
Fri 10/144)5
29
5 days
Mon 1D/1D/05
21
7 days
Mon 10/17/05
C onclusiones y recom endaciones
5 days
Mcn 10/1//0 5
Fr. 1 0 2 1 4 )5
26
T rabajos futuros
2 days
Mon 1 0 2 4 /0 5
Tue 1 0 2 5 /0 5
32
Tue 10254)5
2 n d H a lf
ID
T ask am e
Ju l iA ug | S e p
O ct i N o / P e e
1 s t H a lf
2 n d H a lf
J a n , r e t) M ari A pr | M ay | J u n
J u l |A u g I S e p , O c t
Proyecto gestin de proyectos y de riesgos en en el desarrollo de sistemas de informal

Revisin de literatura
Anlisis del sector
B s q u e d a d e c o m p a a s p a ra c a s a e s tu d ia
E n tr e v is ta c o n la s c o m p a a s s e l e c c i o n a d a s
Familiarizacin con la compaa caso estudio

E n tr e v is ta c o n e l d ir e c to r
10
E n tr e v is ta c o n lo s c o o r d in a d o r e s
C o n o c i m i e n t o g e n e r a l c o n e l a m b i e n t e l a b o r a l d e la c o m p a a
12
Desarrollo de la metodologa
13
I d e n ti f ic a c i n d e h e r r a m i e n t a s y m t o d o s d e g e s t a n d e r i e s g o s
14
D e s c rip c i n la s f a s e s d e la m e to d o lo g a
15
Construccin de una herramienta de identificacin de riesgos
16
B s q u e d a d e h e r r a m i e n t a s d e i d e n t i f i c a c i n d e n e s g u s e n la l i t e r a t u r a
17
D e p u r a c i n d e l c u e s t i o n a r l o e n c o n t r a d o e n ia r e v is i n d e l i te r a t u r a
10
R e f o r m u la c i n d e l a s p r e g u n ta s y c a m b io d e e s c a l a
19
I d e n ti f ic a c i n y r e d a c c i n d e n u e v a s p r e g u n t a s p o t e n c i a l e s
20
V a l i d a c i n d e l c u e s t i o n a r i o fin a l
21
Administracin y anlisis de la herramienta de identificacin de riesgos
22
I d e n ti f ic a c i n d e l t a m a o d e m u e s t r a
23
A d m i n i s t r a c i n d e l a h e r r a m i e n t a al p e r s o n a l d e la c o m p a a c a s o e s t u d i o
24
A n lis is e s ta d s tic o d e lo s d a to s
25
26
H a lla z g o s e n c o n tr a d o s
Gestin de riesgos en la compaa caso estudio
27
E la b o r a c i n d e la lista m a e s t r a d e io s r ie s g o s
20
A n lis is d e lo s r ie s g o s
29
P l a n e a c i n d e r e s p u e s t a a lo s r i e s g o s
30
T~
S e g u im ie n to y c o n tro l d e r ie s g o s
Presentacin de resultados
to
-O
128
Anejo 2. H erram ienta de identificacin de riesgos
129
A. INGENIERIA DE PRODUCTO
R E Q U E R IM E N T O S
Nunca
En promedia
Siempre
[1) Los requerimientos det proyecto actual son estables?
I~1 Nunca
p]Las interfaces externas estn cambiando continuamente?
[3] Ewsten requerimientos que deberan estar en las especificaciones pero que no
lo estn?
En ocasiones
En promedio
Casi siem pre
Siempre
Nunca
En ocasiones
En promedio
O Casi siem pre
siem pre
D . Nunca_______
[4] Existen requerimientos por parte del cliente que no s e alcanzaron a capturar,
ni definir ?
\ Ig n ocasiones
En promedio
I I Casi siem pre

I I Siempre
{5] Las interfaces externas se encuentran completamente definidas o son

subjetivas ?
[6] Usted e s capaz de entender los requerimientos as como estn escritos?
Nunca
En ocasiones
En promedio
Casi siem pre
Siempre
Nunca
En ccasiones
C ] En promedio
H
siem pre
i I Siempre
n
[7] Las am bigedades a problemas de interpretacin de los requerimientos han
sido resueltos satisfactoriamente?
N unca_______
En ocasiones
En promedio
I {casi siem pre

I I Siempre
f l N u n c a __________
I lEn [rasiones
[0] Existen requerimientos que pueden que no especifiquen lo que el cliente
realmente quiere?
En promedio
I Icasi siempre
siempre
Nu
[9] Usted y su c tente entienden de igual forma todas los requerimientos? Nota:
Entindase por cliente a la persona que le pide que realiceX o Y tarea (lider del
equipo, compaero, etc)
I~1 En ocasiones
E n pronedlo
n
Casi siempre
sie m p re
[1Q] Se valan los requerimientos, para asegurarse que estos reflejen las
necesidades del cliente? Ejemplos de como validarlos sera: Prototipos, anlisis a
simulacin.
r~lNmca
Ene
l~ lE n prcmedio
n
Casi siempre
sie m p re
Niea
E n ocasiones
[111 Existen requerimientos que son tcnicamente difciles de implementar?
I~1 En promedio
l~ lc a s l siempre
s ie m p re
Nunca
[12] Existen requerimientos que s e estn desarrollando con los
mtodos,lenguages o harware ms recientes en el mercado (state-of-the-art
requirements}?
f l E n ocasiones
I~1 En promedio
c a s i siempre
siem pre
N i e a
l~ lE n ocasiones
[13] Existen requerimientos donde necesitas ayuda para desarrollarlos, porque e;
necesario poseer conocimientos ms avanzados o por que e s nuevo para usted?
En promedio
f~ l Casi siempre
siem pre
[14] El tamaa del sistema y su complejidad es una preocupacin para el

personal? Nota: A sistema se refiere a la infraestructura, redes, servicios,
networking.
nen gajiare
I lEn promedio
c a s i siempre
s ie m p re
[15] Usted ha realizado anteriormente algn proyecto de igual tamaoy

complejidad?
N unca
l~lEn ocasiones
l~ lE n prcmedio
l~ lc a sl siempre
s ie m p re
131
Mtsio
[18J Se acostum bra a determinar las factibilidad (feas ibility) de las alga ritmas y ti
diseo; cma por tjemplo; anlisis (analysis). prototipos (Prototyping) a simulacin
(S i mua to n ) ?
Nunca
Q eDS
I
l E n prom edia
O s i sier
sem ort
I Minea
[17] Se h a encontrado can algn diseo que depende d e asunciones poco
retete* u optim istas lo cual lo h ag a difcil de lograr?
E n o
I En prom edio
cas i!
l~~l5em D re
I Nunca
I Ieoo
[10] Existen requerimientos ofunciones que p u e d e n s e r difciles de disear?
I I En prom edio
I Icasi:
n
Siempre
Minea
[10] Segn s u criterio las interfaces internas (Sofhware-to-soffaware. Software-to*
hardware) s e encuentran bien definidas?
I lEno
~~l En prom edia
o s i:
I Siempre
Nunca
Din
[2D] E r te un proceso paradefinir las interfaces internas?
[21] E l hardw are s e est desarrollando en paralelo con el so ftw are?
casi;
Siempre
Nunca
En
En prom edia
casis
se m p re
[22] Las especificaciones del hardw are estn cam biando?
En prom edio
I Nunca
En ocasiones
E n prom edia
i Casi r
se m p re
rs
Enocasiones
[23] Las interfaces d e lso ftw a re se encuentran bien d efinidasy d o cu m entadas?
\2 ^ Ejsten problemas eon el rendimiento (perform ance) de lsistem a. Por ejemplo

eon:
Salida del s iste m a (Throghput)
Tiempo
de
resp u e sta
real
(Real-Time
res pense)
Tiempo de recuperacin de datos (Recovery Timelines)
Tiempo de res p u esta ( R e sp o rse Time)
R e sp u e sta d e la b a se d e datas, caneccin y a c c e so (D a ta b a se responso,
contenton, or a c c e ss)
En prom edio
I S e m p re
I Nunca
En
l
lE n prom edio
c a si siem pre
I S a m a re
132
I " ! Nunca
I I En ocas
[25] En este proyecto s e ha realizada algn anlisis de rendimiento (performance
analysis)?
En promedio
casi siem pre

I""! Siem pre
P En<
[26] El software en desarrollo e s fcil d e probar (ta test)?
En promedio
l~ l c a s i siem pre
[27] En la etapa de disea se incluyen caractersticas para ayudar a la prueba (to

test)?
Siem pre
Nunca
En ocasiones
En prom edia
Casi siem pre
Siempre
r
[20] El personal de prueba (testers) est involucrada en el anlisis de
requerimientos?
En ocasiones
En promedia
dCSJi siem nre
siem pre
[ " I Nunca_______
[29] Se elaboran prototipos o dem os, en alguna etapa del desarrollo del software?
En ocasiones
En promedio
f~l Casi siem pre
[30] Existen alguna limitacin por parte del hardware que le dificulte la obtencin
de las requerimientos?
Por ejemplo:
La Arquitectura del hardware (Architecture)
La capacidad de memoria del hardware (Memory capacity)
Salida fThroughput)
Tiempo de resp u esta real (Real-Time R esponse)
Tiempo de resp u esta (R esponse Time)
Rendimiento de la b ase de datos (D atabase performance)
Tiempo de recuperacin (Recovery Timelines)
Funcionalidad (Functionality)
Confiabilidad (ReNability)
Disponibilidad (Availability)
Entre otros
Siem pre
Nunca
En ocasiones
l ~ l En promedio
l ~ l Casi siem pre
f~l Siem pre
Nunca
En ocasicnes
[31]Existen mdulos, diseos, cdigos desarrollados en internet o por un
desabollador de la compaa, que son reutilizadas en nuevas aplicaciones?
En promedia
Casi siemore
Siempre
[ ( Nu n c a
[32] Existe un proceso formal para reutilizar estos mdulos?
En promedia
I I Casi siempre
1 1Nunca
1 | Fn ocasicnes
(33] La reutilizacin de estos mdulos afecta mucho el rendirrento/ performance?
En promedio
Casi siempre
Siempre
I I Nunca______
I l En ocasicnes
[34] Los mdulos reusados presenta un alto grado de corrplejidad en la mayara

de los casos?
~] En promedio
r i c a s i siempre
siempre
[35] Ha tenido problemas utilizando estos mdulos disponibles en internet c

desarrollados por la compaa anteriormente? Por ejemplo, problemas en:
< O ocurre rita cin (Documentation)
Rendinriento (Performance)
Funcionan dad (Functionality)
Interoperabilidad
Tiempo de entrega (Timely delivery)
Customatizacin del cdigo (Customization))
Nunca
Ene
En promedio
casi siempre
siempre
0
AJ CDfGO Y UNQAD DE TEST
1 1Nunca
(36] Faltan detalles o requerimientos adicionales en la implementacin del
producto, que no se han definido en la especificacin de disea o en la etapa de
diseo?
En ocasicnes
En promedio
casi siempre
siempre
1 1Nunca
En ocasiones
[37] Son los algoritmos y el diseo seleccionados fciles de imple mentar?
En promedio
i- ! Casi siempre
Siempre
134
[38] El funcin Tiento d e las diferentes unidades (sistem a,interfaces, etc). s e

prueba, despes d e que verifica el cdigo can respecto al diseo?
h in c a
En ocasicnes
E np ro m ed o
casi siempre
I ISem pre
I I h in c a
I iFn ocasicnes
PQ] Se cuenta con el tiempo suficiente para realizartodes los testing que usted
considera deberan hacerse?
|
PQ) Las especificada nes d e dis en o tienen el suficiente detalle para escribir el
cdigo?
E np ro m ed o
| h in ca
E np ro m ed o
I ) Casi s iempre
Sem p*
I I h in c a
[41] S e h a p re se n ta d o u n caso en donde el d se o cambia constantem ente
mientras s e est desarrollando el cdigo?
En ocasiones
E n p rc m e d a
I (casi siem ere

ii
I I h in c a
[42] Existe un proceso para controlar los cambios en el cdigo? Quien realiza las
cambios y bajo que eircunstandas
En ocasiones
I IE n p ro m ed o
Sem pre
:
(43] E)stenresfriccicnas o limitaciones d e lse te m a , que hacen que el cdigo s e a

difi c d e des arr aliar?
Tiempo del preces ador
Capacidad d d s s ta m a operativo
Almacenamiento interno (capacidad de memoria)
Almacenamiento ederno
f I h in c a
I I En ocasiones
E n p rc m e d a
casi siempre
I ISem pre
I I h in c a
[44] El lenguaje q u e s e est utilizando es el apropiadoparaproducir el software en
este proyecto?
En ocasiones
I lE n o rc m e d a
Sem pre
I (h in c a
(46]Seest utilizan do mu (tiples lenguages para progranar?
I IE n p rc m e d a
Casi siempre
Sem pre
T i h in c a
1 1En ocasiones
[45] En ca se que s e utilice mltiples lenguajes.se ha presentado problemas con
las interfaces entre esto s?
E h o re m e d o
Sem pre
[47] El software puede intaraetuar fcilmente con uno o m s s is te m s

especificadas?
1h in c a
En ocasicnes
E n p ro m ed o
casi siempre
Sem pre
135
I I Nunca
[~1 En ocas
[49] Es difcil lograr una buena interaccin del cdigo que se est desarrollando
con la tecnologa de internet, tecnologa propietaria, etc?
O En promedia
I I Casi siempre
I I Siempre
Nunca
[49J Es buena la integracin del producto con productos similares de otros
fabricantes?
Ene
En promedio
C a s i
siempre
N unca
Ene
[5Q] Existen problemas con la implementacin de protocolos de acceso de
tecnologa de internet? TCP, UPD, FTP.
En promedia
Casi siempre
Siempre
Si hardware esta siendo usado

Nunca
[51] Las especificaciones de hardware son las adecuadas para codificar el
software?
En ocasicnes
En promedio
I Icatf siempre
siempre
Nunca
[52] Las especificaciones de hardware estn cambiando mientras el cdigo se
est escribiendo?
Ene
~1 En promedio
I I Casi sianpre
Siempre
A < NrEGfACtN Y PRUEBA

H ard w are
Nunca
[53] Se cuenta con el harchvare adecuado para realzar una adecuada integracin
y prueba (testing) ?.
En ocasicnes
En promedio
casi siempre
siempre
S o ftw a re
[54] Se ha presentado algn problema con el desarrolllo de escenarios (reaistic

scenarios) y data testing (test data) para probar algunos requerimientos? Por
ejemplo:
Specied datatraffic
Tiempo de respuesta real (Real Time Response)
Multi usuarios (Multi-user intereaction)
Otras causas externas: coma bajn de energa, etc.
N unca
En ocasicnes
D En promedio
Casi siempre
siempre
136
[~~1Nunca_______
I lEn ocasiones
[SS]
U sted puede verificar d peribrm anae ctel producto en s u facilidad a puesto de

trabajo?
I 1En prom edio

I I Casi siem pre
I~1 Siempre
I~~l Nunca_______
O
[56]
Las especificaciones dd laboratorio de prueba son fciles de validar?
n ocasiones
I 1En promedio
casi;i siem pre
I~ l5iem pre
I INunca_______
en ocasiones
[57]
S e cuenta oon i n banco d e pruebas o d otatesting re d m e n te eficiente?
En promedio
I Casi siem pre

(~~l Siem pre
f~ l Nunca_______
[58]
S e cuenta con d g n proceso para verificar que las c o sa s s e estn haciendo

como se supone?
l~~l En ocasiones
I 1En promedio
I 1Casi siem pre
s ie m p re
I~~i Nunca_______
P l E n ocasiones
[59]
EI producto objetivo Target hardware) estar disponible c u s id o s e necesite?
E n prom edio
I Icasi siem pre
I ISiempre
N u n c a _______
I lEn ocasiones
[60] H asta ahora los re h erim ien to s han pasado todos los criterios d e aceptacin?
E n promedio
c a s i siem pre
I Isiern
I I Nunca_______
U | n ocasiones
[61] Las interfaces e d e m a s estn bien definidas,docum entadas y ddim itadas?
En prom edio
casi siem pre
s ie m p re
Nunca___
n
[62] E a ste n recyjerimiertos que podran se r difciles d e proba1(testing)?
En ocasiones
E n prom edio
casi siem pre
siem pre
|N unca_______
D in
i] S e h a detallado sufidentem ente cmo h ac erla integrad en del producto?
xasiones
En promedio
I I Casi siem pre
s ie m p re
I I Mirra
I I Pn r r asi enes
[64] Se ha presentado algn problema en la etapa de integracin del producto?
I l&HTomeda
Casi siemcre
sa n c re
Mirra
[65] El tiempo asignado para realizar la integracin del producto y el testing es
el adecuado?
Fn rrasicnes
n & ic rc m e d o
Casi siemcre
gem cre
I iM irra
n
[66] Se ha detallado suficientemente cmo hacer la integracin del sistema?
Bn ocasiones
&iprcmedG
casi siemcre
gem cre
Nunca
[67] El tiempo asignado para realizar laintegracin del sistem ay el testing es
suficiente?
1 1Fri rrasicnes
Enpromedo
Casi siempre
gem cre
Nunca
[66] El producto que se est desarrollando va a integrarse dentro de un sistema y
existente?
1 i Fri r r asi enes

fin cromado
n
Casi siemcre
g e n e re
Nunca
;69] Existe un perodo de transicin cuando se va a integrar el producto con un
sistema ya existente?
1 1Fin r r asi enes

&i promedo
casi siemcre
gem cre
A S GEfCRAL
Mirra______
[7Q] La arquitectura, el diseo y el cdigo presentan dificultades en el
mantenimiento? Es decir el software desarrollado perrrite hacer cambios, ser
analizado y probado facilrrente.
En ocasicnes
bi
crom ado
casi siempre
gempre
Nunca
[71] Esfcil diagnosticar deficiencias o causas defallas o identificar las partes
que deben ser modificadas ante un carrbio?
En ocasicnes
Enpromedo
Casi siemcre
gem cre
I~~l Nunca_______
I I En ocasiones
[72] El software permiteimpl am entar unam odificadcn fcilmente?
I lE n promedio
1 1Casi s
I i Siempre
f~1 Nunca
[73] E s software e s e s ta b le .e s decir en la mayora d e las ocasiones al realizar

cam bios, no suced en resultados / efectos inesperados?
Eno
I lE n promedio
I I Casi siem pre
I I Siempre
[74] La com paa involucra el persone! de m artenim iento en la etapa del diseo?
Nunca
En o
I lE n promedio
I I Casi siem pre
I I Siempre
[75] S e definen requerimientos d e ccnfietoilidad (reliebility requirem ents)del

software?
E no
I I n promedio
I I Casi s
l~~l Siempre
I I Nunca
[76] S e han presentado problem as en la obtencin d e los re h e rim ie n to s de
confiabilidad?
I I En c
I lE n promedio
I I Casi siem pre
f~| Siempre
I I Nunca
I E n o
[77] E a s te en nivel especificado detolerancia de fallas?
I I En promedio
r i c a s i siemi
I I Siempre
( I Nunca
r i F n ocasiones
[76 E s fecii re cu p erarlo s d d o s directam ente afectados en el c a s o d e una falla?
En promedio
1 1Casi siem pre

1 1Siempre
~~l Nunca
.E n o
[79] EI software tiene facilidad para adaptarlo - a diferentes am bientes
especificados sin utilizar d ro s m edios q u e lo s previstas?
I I En promedio
I Icasi siem pre
Siempre
I~1 Nunca
I i En c
[80] El software e s fcil d e instalar en un entorno especificado?
I I En promedio
I 1 Casi siem pre
I I Siempre
N m ca_______
[01 ] EI software tiene la capacidad de coexstir - con otro software independiente
en un am biente c a n n com partiendo recursos com unes?
I IEn ocasiones
I IEn prom edio
casi siem pre
O Siem pre
Nmca___
[8 2 ]S e asig n er requerimientos d e seguridad (safety requirem ents)al soltwere?
Entindase safetycom o la m anera segura de hacer algo.
I lE n ocasiones
CU En prom edio
[ ICasi siem pre
I I Siem pre
N m ca_______
e n ocasiones
[83]
S e cuenta ccn un ambiente seguro p ara desarrolla las aplicaciones? S e

refiere a ambiente el sistem a op aa tiv o , etc.
I En prom edio
I Ic a a siem pre
CUSiem pre
I N m ca_______
En ocasiones
[04]
S u s qalioaciones ccrren en un am biente de memoria protegida?
En prom edio
I Casi siem pre
I I Siem pre
I IN m ca_______
[05]
S e h an presentado inconvenientes en el desarrollo de losrequerim ientcs de

seguridad (safety requirem ents]?
I lE n ocasiones
I I En prom edio
I Ic a a siem pre
I I Siem ore
I I N iea_______
[86] E s difcil verificar el correcto funcionamiento d la s requerimientos de
seguridad (safety requirem ents)?
I lE n ocasiones
En prom edio
I I Casi siem pre

I I Siem pre
N m ca_______
I lE n ocasiones
[67] El accesoesderno a s u s a p lic a d o n e s e s seguro?
I IEn prom edio
casi siem pre
I ISiem pre
I IN m ca_______
I lE n ocasiones
[08] S e h a desarrollado alguna implementacin d e seguridad para proteger las
aplicaciones?
E n prom edio
I 1C a siem pre
siem pre
I iNmca______
[89] S e acostum bra a implementar algn estndar d e seguridad com o el
ORANGE BOOK?
nenpcasiones
En prom edio
I Icaa siem pre

I I Siem ore
140
Q_Njnca__
~ l En ocasiones
[00] Se han tenida problemas trabajar a cor SSL(SecuritySock Layer)f?
En promedio
flc^i Siempre
O
Sempre
Q_htnca__
p i] Se han presentado alguna dificultad en la obtencin de los requerrnientae dd
cliente?
ocasione!
~ ) En promedio
q s
Sempre
errare
Q_Njnea__
[03] Usted considera que existe limitaciones en las interfaces huraa-computador
(m an-rachine), en las cu d e s se debe v i a j a r ?
En ocasiones
l~~l En promedio
l~~l Q si siempre
O Sempre
Q Nunca
~~l En ocasiones
[03] Est la especificacin de requerimientos bien documentada, co m p ita y
delnida para realizar el diseo del sistema?
D En promedio
o siempre
O Sempre
l~~l Nunca
04] Estn las especif caa an e s de H sdwarebien documentadas, completas y
definidas para reakia' el diseo y la implemartacin del softuare?
I I En ocasiones
l~~l En promedio
l~ t O si sierrpre
l~ l Sempre
D Nunca
[99] Estn los requerimientos de interfaces eidemas bien definidos?
En ocasiones
~ l En promedio
I I Q si sierrpre
I"! Sempre
P0] L x especificaciones de prueba son las adecuadas para realizaruntest

prueba al sistem a?
f~ l En ocasiones
O
En promedio
O r sierrpre
Sempre
D htinca
[97] Son las especificaciones de diseo las adecuadas para realizar la
implementacin dd sistema?
Interfaces internas
l~~1En ocasiones
~1 En promedio
l~~) Casi sierrpre
~~l Sempre
Bi.oesAfOLLOoepmcssos
B.AMBIENTEOE DESARROLLO
P8] S e realiza un proceso fe rral de convol de c a n to s, que cubra todos los

ca nbias en los requernientos, diseo, cdigo y docum entxin?
En ocasiones
I I En promedio
Q_Hinca__
p9] Se realiza un anlisis adecuado cusido los nuew s requerimientos son
adicionados al sistem a?
I I En ocasiones
D En promedio
f t j i sirrprf
Sempre
141
[100] U sted tiene d g in a m anera d e darle seguimiento a las interfaces (track

nterftces J?
Nunca_______
O l a ocasiones
I I En promedio
I I Casi siem pre
I I S em p re
I I Nunca_______
I I En ocasiones
[101 ]Las test plan y ios procedimientos, son actualizados cuando s e realizan
cam bios en los prooesos?
I I En promedio
I I Casi siem pre
S em p re
0 2 DESARROLLO DEL SISTEMA
I I Nunca
[102] Hat' suficientes e la c io n e s y capacidad d e procesam iento para todo d
p erso n d ? C ^ ia b d ed s e refiere si cada perscna tiene s u s propios recu rso s o los
comparten.
[71En ocasi
I I En promedio
I I Casi si<
siem pre
[71 S em p re
I I Nunca
[103] Hay un program a requerido de entrenamiento (training) en software para
c ada equipo d e trab a ja a n d isistas, diseadores, desarrall adores, personal de
testing, etc...
I I En ocasiones
I I En promedio
i I Casi siem pre
s e m p re
I [N unca
[104] Los recursos que s e requieren a travs d e la red; c o t o ac ce so a internet,

ac ce so a bese d e detos, estn disponibles/ funcionan todo el tiem po?
Ene
I I En prom edio
I I Casi siem pre
s e m p re
I I Nunca
[105] Si s e tiene acceso ainternet todo d tiempo, s e presenten problem as con d
a cceso a los siste m es?
En
I I En promedio
I I Casi s
S em p re
D Nunca
[106] El equipo activo como routers, concentradores, sW tohes; necesario pare d

acceso a s u s servidores y a internet, funciona adecuadam ente todo el tiempo?
En o
l~~lEn promedio
! I Casi siem pre
[107] El desarrdlo dd sistem a soporta to d o s los asp e cto s del program a?

Anlisis d e requerimientos (Requirem ents analysis)
Anlisis de Rendimiento (Perform ance analysis)
Diseo(O esign)
Cdigo (Coding)
P rueba (T est)
Documentacin (D ocum ertation)
Configuracin (Ccnfiguration m anagement)
Seguimiento (Management tracking)
Seguimiento d lo s requerimientos (Requirem entstraceability)
S em pre
I I Nunca
r~lEno
En prom edio
Casi siem
Siempre
[108] S egn su criterio el sistem a e s considerado confiable? Los siguientes tem s
son confiables
I I En ocasiones
Compilador (C om piler)
Nunca_______
En prom edio
casi siem ore
Siempre
Desarrollo d e h erram ientas (Oevelcpment tools)

Hardware
BJ.G R M C iA DE LOS PROCESOS
I I Nunca
I I En ocasiones
[109] El desarrollo del program a esta corriendode acuerdo a lo plvieado?
l~ l En prom edia
casi siem ore
Siempre
I I Nunca
[110] F recuentem ente el personal resuelve problem as no pleneados?(get pulled
aw aylp fight fires)
I lE n ocasiones
I I En prom edio
casi siem ore
f~] Siempre
I I Nunca
I" ! En ocasiones
[111] S e realiza un proceso de re-planeacin cuando ocurren lasinterrupciones?
En prom edio
I I Casi siem ore
Siempre
I I Nunca
I" ! En ocasiones
[112] Todo el personal reafiza un proceso d e planeacin para realizar su trebejo?
En prom edio
Casi siem pre
Siempre
[__l Nunca
I
[113] Existen planes d e contingencia pera los riesgos conocidos?
I En ocasiones
l~ l En prom edio
I ! Casi siem pre
[
[114] Dentro de s u s planes de contingencia s e cuenta con power supply, m anejo
d e backup, mirrcring, raid, etc.
Siempre
I Nunca
En ocasiones
En prom edio
I Ic asi siem pre
[115] La com paa cu e n ta con m anagers con experiencia?

Software m anagem ent
a Hands-cn software development
W iththis development process
In th e appliceticn domain
Program size orcomplexdty
Siempre
Nunca
I I En ocasiones
En prom edio
Casi siem pre
Siempre
143
Nunca
(110] L o conflictos con I cliente s e docum entan y s resuelven d t una m anera
oportuna?
[117]
Le g e re n c ij imtolucr a al personal en las reuniones can el d ie n te ?
Lderes (Technical ieadeis)

Desarrolladores (Developers)
iEn o
l~~En prom edio

I
I Casi siei
sem p re
Nunca_______
En ocasiones
En prom edio
lCasi s e m p re
A n a lista (A n a l^ ts)
sem p re
l~~lNmca
[118]
La interaccin del usuario con las interfaces en la mayora d e las ocasiones
es intuitiva? Es decir el u suario entiende de inmediato las c a r a c te rs tic a del
pro d u c to ,sin necesidad de s er asesorado por un representante d e la co m paa?
r ~ t En ocasiones
I
lE n prom edio
c i siem pre
S e m p re
En prom edio
[110] En la m ira ra d e les casos s e logra inm ediatam ente u n nivel de conform idad
con el cliente cuando s e le presenta el producto?
[120] S e han presen ta c a sa s donde las requerimientos desarrollados, n o eran

exactam ente le que el cliente experaba?
BAM BtE NTELABO ftA L
[121] El personal trabaja e n equipo p ara alcanzar l a
com n?
[122] C u a n d o s c presenta un problema en el equipa d e ta b a ja , s e require la

intervencin de la gerencia o del jefe?
[123] Bciste una buena com unicacin entre las m iembros del program a?
J efes (M anageis)
Lderes (technical leadeis)
D es arrollad ores (developers)
P e rsonal de p ru e b a(testers)
etc...
I Nunca
En ocasiones
[ " I En prom edio
c asi siem pre
s e m p re
[124]U steds a s ie n te en la libertad de pedir ayuda a su s je fe s ?
144
P R E G U N T A S A B IE R T A S
[1 ] Cul e s la opinin que usted tiene del sid em a? Sistem a e s d conjunto de

tems relacionados c c r el producto: software, Hwdware y txgarizaan.
[2} C ules son los aspectos o ven ta ja sm sim p o rta n tesd e s u sistem a?
(3]
[4]
[S]
[6]
C ules son las desventajas ?
C ules son los problemas que s e han presentado o s e pueden presentar en

este proyecto?
Cmo maneja la seguridad de s u informacin, interna o e te rn a m e n te ? Utilizan

backup?
Como s e define la distribucin del trabajo entre el equipo d e desarrdlo del

software?
[7]
Como e s la relacin con tu s com paeros de equipo?
[8]
Segn s u criterio, que riesgos p re sen ta la c a m p an a?
[9] Tiene usted dguna d r a Observacin que quisiera comentar d e su com paa"
145
Anejo 3. Lista de cotejo para validar la construccin del cuestionario
146
Question-W riting Checklist

Stephen P. Sa?gati
Target the vocabulary and grammar to the population be surveyed.
Avoid ambiguity, confusin, and vagueness.
Avoid emotional language, prestige bias and leading questions
Avoid double-barrelled questions
Don't assume therespandent is an expert on themselves (unlessyou h aven o chace)
Avoid asking questions beyond arespondent's capabilities
Avoid false premises
Avoid negatives and especially double negatives
147
Anejo 4. M atriz num rica de correlaciones y grfica de correlaciones
148
0.539
0,372
0,157
-0.303
-0.103
Q.22
Q.23
Q.24
Q.25
Q.19
Q.20
0.416
1.000
O
o
o
0.670
0.416
s
p
0.578
0.292
0.578
0.292
0.351
0,329
0512
0 076
o
o
o
O o
0089
0.202
0.274
<y
Q.35
0.311
Reproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
-0.228
-0.459
-0.532
0 279
-0.026
0.583
0.377
-0.532
-0.043
-0.043
0.377
1.000
0 279
O
-0.271
-0.293
0.173
TT
O
0,583
o
o
0.119
0.440
-0.378
0.281
-0.316
-0.347
0.062
0.119
-0.271
-0.026
-0.293
0.173
-0.378
0.440
oo
-0.304
-0.528
-0.347
0.281
0.636
-0.191
-0.194
0.636
-0.191
<0
O
0 340
o
o
o
o
-0.236
-0.558
S
O
Q.33
Q.31
-0.228
-0.459
-0.071
-0.316
-0.528
0.062
00
o
0.151
1
0.311
Q.35
0.274
Q.34
0.202
Q.33
9
Q.32
0.084
-0.200
Q.30
-0 558
-0.368
Q.29
0.528
0.781
-0.233
0.349
0.151
0.528
-0,233
0.781
0.423
0.642
0.642
0331
-0 552
0.326
0.351
0 621
0.388
0.387
-0.346
-0.213
-0.236
0.326
-0.441
pn
p
8610-
Q.28
Q.32
0.621
-0.441
-0.181
-0.260
0 069
-0.053
0.636
0.342
0.476
0.113
0.288
Q.25
-0 103
Q.24
0001
o
o
Q.27
Q.31
J
-0.200
0.351
00
o
0.349
-0.260
o
o
o
o
Q.30
Q.28
0.423
Q.27
0.331
Q.26
o
o
-0.368
0.387
-0.346
-0.213
0.670
0.748
-0.076
0.212
0110
Q.23
0.157
Q.29
0.388
-0.053
0.636
Q 22
0372
-0.179
0.403
CN
m
Q.26
0 342
0.476
00
00
CM
O
o
o
0.113
Tf
O
O
O
000 1
o
690 0
-0.179
0.403
Q.21
Q. 18
0.351
Q 17
r
00
o
Q.20
-0.121
O
o
o
0.329
0.512
O
o
o
0.076
O
o
o
Q.19
-0.121
ro\ O 00
00 o TT
lO o [-o
O
o
o
p
O
8
861 0-
00 3
o
<y o
O
Z IZ 0
(y
DO
O
^r
*o
o
o
O
O
o O o
o
p
o
o
000 1
04
C7
Q.16
T\
o C
m
in
O o
689 0
Q.16
149
O
O
ro
o
150
0 .7 4 3
0 .0 7 6
0 .2 2 7
0 .0 9 2
Q .6 2
-0 .0 3 2
0 .1 3 9
Q .6 1
0 .5 7 6
0 .1 3 5
0 .4 6 4
-0 .5 1 9
0 .5 1 0
Q .6 8
Q .6 9
9 9 'Q
Q .6 7
0 .5 7 0
Q .6 3
0 .5 7 6
-0 .0 3 2
-0 .3 5 8
-0 .3 5 0
0 .4 9 4
0 .1 6 5
0 .2 0 0
Q .6 4
0 .1 3 9
0 .1 3 5
0 .7 2 1
0 .6 3 1
Q .6 5
0 .8 6 7
S 00
00 00 O
o
o o o o
1 1' 1 1
0 .7 1 2
-0 .4 8 3
-0 .6 8 0
0 .5 9 4
-0 .6 7 7
0 .5 5 5
0 .9 3 8
0 .9 3 8
-0 .1 0 3
0 .3 1 9
0 .7 1 9
-0 .3 8 5
Q .5 9
0 .7 4 3
-0 .3 5 0
-0 .4 9 7
0 .5 5 5
r00
00
o
0 .3 1 9
Q .6 7
0 .4 6 4
0 .5 9 2
O
O
o
1
-0 .0 5 4
-0 .0 8 5
0 .5 7 0
0 .3 5 1
-0 .3 8 1
0 .3 1 8
O
o
p
i*4
0 .3 6 2
Q .6 6
0 .7 2 1
0 .1 2 6
0 .4 9 4
-0 .1 0 2
-0 .1 9 6
0 .2 9 4
Q .5 8
0 .0 7 6
-0 .1 0 2
0 .6 3 1
0 .1 6 5
- 0 .0 6 3
0 .1 2 8
0 .4 2 7
O
o
o
o
0 .3 5 1
0 .2 0 6
-0 .0 8 9
0 .1 2 6
- 0 .0 6 3
0 .4 2 7
1 1
0 .3 1 8
0 .2 0 0
o
o
o
Q .6 5
Q .6 4
Q .6 3
Q .6 2
Q .6 1
Q .6 0
Q .5 9
Q .5 8
Q .5 7
Q .5 6
-0 .0 8 8
-0 .2 4 5
Q .5 7
0 .2 2 7
Q .6 8
-0 .1 4 8
-0 .5 1 9
Q .6 0
-0 .1 0 2
-0 .1 0 2
0 .2 9 4
0 .2 0 6
-0 .3 5 8
Q .6 9
0 .5 1 0
0 .3 6 2
-0 .6 3 8
-0 .6 3 8
0 .7 1 9
0 .5 9 4
- 0 .3 8 5
0 .7 1 2
-0 .6 7 7
-0 .0 5 4
-0 .4 8 3
O
8
6000
Q .5 5
9610
OOO'I
Q .5 4
Q .5 6
0 .0 9 2
Z 6S0
9610
OOO'I
8190
O O
00 o
o o
o
8
o
o
ro
o
OOO'I
O
1
4
O
o
1
OOO'I
o:
o
o
o
o
9610-
Q .5 5
S 9I0
Q .5 4
o
o
o
lH
180
O
o
o
o
0-
O
o
00 o
o
089
908
- 0 .2 4 5
000
Q .5 3
000
1
00
f-H
o
C*i
908
O
o
p
S 9I0
O
000
OOO'I
000
O
o
o
0-
9
680
OO
co
o
O
t-H
6000
8190
Q .5 3
151
8
O
Q .7 8
Q .7 7
Q .7 6
Q .7 5
Q .7 4
0 .7 3
Reproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission.
Q.87
-0 .6 7 7
Q.79
0 .2 7 7
0.550
0.350
-0.011
0.219
0.225
-0.023
!
orH
O
o
98 Q
Q.82
Q.83
Q.84
Q.85
0 .6 1 7
0 .3 0 3
-0 .2 7 0
OOO'I
rH
t-* 00
6>
0 .1 7 3
0 .1 7 3
- 0 .2 7 1
0.205
0.396
0.143
0.100
0.248
-0.099
-0.090
Q.80
0.550
-0 .5 2 5
0 .0 6 7
-0 .1 2 8
0 .1 8 7
0 .1 8 7
0 .0 2 8
-0 .0 2 2
-0 .2 7 1
0 .4 3 9
0 .1 0 2
-0 .1 7 1
-0 .1 7 5
-0 .3 5 5
0 .5 5 7
0 .0 3 7
0 .1 5 8
0 .0 2 8
Q .7 4
Q .7 5
-0 .1 2 8
0 .2 0 9
0 .0 3 7
-0 .2 3 0
0 .0 5 3
Q.84
0.219
0 .4 4 3
Q.83
0.143
0.278
0.508
Q.82
0.278
0.489
0.227
0.231
0.411
Q.81
0.350
0.205
0.508
0.361
0.228
-0.127
0.351
Q .7 6
Q.85
0.225
0.248
0.227
-0 .0 4 7
- 0 .4 2 3
-0.274
0.260
0.173
0.460
-0.126
o
o
t
o1
0.037
0.598
0.489
0.361
0.492
-0 .2 3 0
0 .4 3 9
-0 .1 7 5
O
oo
rH
OOO'I
0 -7 2
Q .7 3
0 .6 1 7
O
8
rH
9100
890
Q .7 1
0 -7 2
0 .3 0 3
O
oo
^4
O
o
o1
9ZI0z e ro
OOO'I
Q .7 1
-0 .2 7 0
9100
96E0
60Z 0
O
O1
o
o
orH
o
o
ooro
1900-
0 -7 0
00
rH
rH
rH
O1
^^H
H
O
o1
Q .7 7
-0 .4 0 9
0 .1 0 2
-0 .3 5 5
0 .1 5 8
-0 .4 2 3
Q.86
-0.023
-0.099
0.231
-0.127
0.037
0.173
-0.274
-0 .0 3 3
0.217
Q .7 8
-0 .5 2 5
0 .2 7 7
- 0 .0 3 3
-0 .0 4 7
0 .0 5 3
0 .4 4 3
0 .5 5 7
Q.87
-0.090
0.411
0.351
0.598
0.260
0.217
O
'O
o
OOO'I
oo
O
o
o
o
8ZZ0
ZZO'O-
O
i-H
^H
!O
1
O
;
O
O
1
1
OOO'I
1-H
rH
9990
O
o
000
rH
1
o
o
000
S
O
1-H
1900-
O
o
O
O
o
rH1
rH
O1
o
o
t"
OEO'O
O1
O
o
000
o1
00
0
'O
00
o
o
999
8900
h900
0 -7 0
152
O
o
o
1
O1
o
o
1
1
O
o
o
o
0.259
0.126
0.127
0.358
o .io o
0.139
-0.416
0.771
0.838
0.771
0-98
-0.118
0.117
-0.358
o!
o
o
^4
-0.358
-0.066
-0.066
-0.082
0.092
0.117
0.185
0.185
00
^H
0.342
0.198
0.199
0.323
0.030
-0.281
0.329
0.248
0.271
-0.067
0.506
Q.104
0.175
0.260
0.367
-0.066
0.476
-0.176
-0.043
0.056
0.078
0.95
0.127
Q.105
0.427
0.427
0.257
0.506
0-106
0.416
-0.078
0.012
800
900
00
-0.176
0.251
0.405
0.476
0.386
-0.158
0.185
-0.066
0.323
0.277
0.346
0.025
0.96
0.358
^H
O
0.349
0.077
-0.184
-0.416
0.838
0.139
0.94
^H
00
00 i-H
1
o
00
-4,
0.678
0.289
00
'
9
-0.158
-0.158
-0.078
0.344
0.295
0-103
0.257
0.271
00
o
^H
d
00'
H1
0.260
0.386
0.416
0.144
-0.067
0.047
0.207
0.160
0.588
0.381
0.357
-0.106
0.144
-0.368
0.138
Q.93
0.259
0.102
0-101
Q.92
i
o
^4
d
O
o
o
1-H
0.175
9110-
0.190
0.602
0.229
0.138
0.357
0.271
0.056
0.346
-0.689
0.229
0.295
0.295
-0.689
-0.368
0.381
0.248
-0.043
0.277
0.367
9080
0-102
0.103
Q.104
0.105
Q.106
Q.107
Q.108
0.637
-0.296
0900
OOO'I
I0I
oo r
660
86
Q.89
Q.90
0-91
Q.92
0.93
0.94
0-95
Q.96
0.97
Q-91
-0.296
1
00 *0
^H 00
^H
d d
i
9810
OOO'I
090 0
069 0
OOO'I
6610
'
i
O
^H1
9810
OOO'I
P
O
!
C*Y
!
069 0
0.90
0.637
Q.97
0.367
-0.118
0.160
0.271
0.367
0.048
0.054
0.092
0.329
0.251
0.405
0.133
1.000
Q.107
0.678
0.428
0.344
0.342
-0.082
-0.281
-0.176
-0.185
Q.108
0.289
0.349
0.295
9ro-
i
i
vo
^H
d
i
908 0
P
O1
o
00
0.133
00
OOO'I
861 0
901 0-
090 0
d
1900
O
o
o
O 00
o
o o
o o
00
o
o
66
O
oo
^H
S200
0.482
O
oo
O
o
o o
o
800
8
O
^H
00
00
009 0
O
o
o
*4
O
oO
^H
ro
o
O
o
o
o
000'T
O
o
o
o
ro
o
000 0
000'T
209 0
28*0
OOO'I
00
00
<y
O
o
o
o
000'T
090 0
L Q-89
O
%
o
0090
9210
Q.88
153
00
^H
Q.117
Q.116
-0.118
0.194
0.304
0.425
0.576
0.489
0.299
O o
^H o
t->
0.634
Q.122
0.059
0.797
O
o
o
i-H t
1
1
-0.312
0.339
0.481
-0.312
o
-0.468
-0.254
-0.402
0.207
0.634
Q.114
0.291
-0.137
-0.084
Q.121
-0.137
0.548
-0.030
0.299
0.568
0.706
-0.030
0.161
-0.278
1 .0 0 0
Q.113
-0.045
-0.472
0.135
0.576
Q.120
0.425
0.221
0.706
0.489
Q.119
0.304
0.256
0.568
Q.118
0.194
0.483
0.575
0.135
-0.084
O
o
o
00
^H r8 00
O
o
-0.220
-0.155
Q.112
0.232
-0.553
0.575
0.115
0.156
-0.214
0.633
0.797
Q.123
-0.064
-0.278
-0.196
0.339
-0.468
0.314
Q.124
-0.220
0.508
0.094
-0.254
0.314
0.059
0.256
0.221
0.548
0.031
-0.064
0.508
Q.lll
00
zzro -
Q.116
Q.117
Q.118
Q.119
Q.120
Q.121
Q.122
Q.123
Q.124
0.232
-0.045
0.291
0.156
-0.303
Q.110
-0.303
1.000
-0.155
-0.553
-0.472
-0.137
-0.214
00
8
O1
00
o
o
8900
Q.109
00
rsf
i-H
1600
9610-
^*H
1^1
O 1
CJ1
O 1
1
000 1
n
O
o
^H p 00
O ^H o
1
1600
ro
o
890 0
1910
XEO'O
o
o
o
O
C'J
zo vo -
^H
^H
O
o
p
i-H
z zro -
o
o
o
o
6600
O
O
8
O
o
o
90
o
o
00 C4
s O
o O
1
000 1
O
t6600
00
^H
Q.109
Q.110
Q.lll
Q.112
Q.113
Q.114
Q.115
154
O
O
i-H
3
O
o
155

Determinante =0.089213
Matriz
do Correlacin
c
a
G rupo de preguntas 8-15

D eterm inante =0.014074
Mrtri/ de r.nrrft nc. rn
156
Grupo de preguntes 16-25

Determinante =5e-6
JoCc'eoci-M
a
? i *

Determinante =0 007213
Mari? > Csmfa?. m
Grupo de preguntes 26-3 5

D eterm inante =8.1 e -5
Mwi::W
>

Determinante =0 0 02143
^tintrMmv' *>".
M-Yft? fif< l'AiV-iV fs

Determinante = 0 .0 0 1135
OHiWrS4**S
Cit'Xfyti

Determinante =0 0 00108
157


D eterm inante = 0.00086
lJ
i.
um
3?

G rupo de p reguntas 98-108

D eterm inante = le -0 6
MiHZ-X l i : KAmin.i-:.

D eterm inante = 0.002882
G rupo de p reguntas 116-124

D eterm inante =0.002155
Anejo 5. Extraccin de factores inicial
159
Extraccin de factores inicial
P -value p ara nm ero de factores significativos

[1] 0.415Q281 0.6483697 0.6317412 1.0000000 1.0000000
Uniquenesses:
Q.l
Q.2 Q.3 Q.4
Q.5
Q.6
Q.7
0.005 0.662 0.005 0.940 0.870 0.777 0.478
Loadings:
F acto rl Factor2
Q .l 0.104 0.992
Q.2
0.577
Q.3 0.966 -0.248
Q .4 -0.162 0.185
Q.5 0.361
Q.6 0.435 0.183
Q.7 0,616 0.377
SS loadings
% V ar
C u m V ar
F a c to rl
1.675
0.239
0.239
Factor2
1.589
0.227
0.466
P-value para nmero de tactores significativos

[1] 0.2543259 0.5456774 0.9623886 0.8167182 1.0000000
Uniquenesses:
Q.8 Q.9 Q. 10 Q.l 1 Q.12 Q.13 Q.14 Q.15
0.946 0.970 0.005 0.747 0.575 0.005 0.487 0.580
Loadings:
F a c to rl Factor2
Q.8
0.227
Q.9 0.164
Q.10 0.864 -0.498
Q .l 1 0.306 0.399
Q.12 0.650
Q.13 -0.125 0.990
Q.14 0.671 0.249
Q.15 0.554 0.336
SS loadings
% V ar
C u m V ar
F a c to rl Factor2
2.065 1.619
0.258 0.202
0.258 0 461
160
P-value para numero de factores signficativos

[11 0.0002598599 0.0049868160 0.0098793218 0.0313342485
0.0408185013
Uniquenesses:
Q.16 Q.17 Q.18 Q.19 Q.30 Q.21 Q.22 Q.23 Q.24 Q.25
0.930 0.600 0.129 0.826 0.005 0.344 0.424 0.859 0.330 0.316
Uniquenesses:
Q.26 Q.27 Q.28 Q.29 Q.30 Q.31 Q.32 Q.33 Q.34 Q.35
0.829 0.251 0.359 0.068 0.290 0.237 0.795 0.770 0.755 0.874
Loadings:
F acto rl
Q.26 0.256
Q.27 0.826
Q.28 0.794
Q.29 0.746
Q.30
Q.31 0.382
Q.32 0.253
Q.33 -0.478
Q.34 -0.465
Q.35 -0.343
Loadings:
F acto rl F actor2
Q .16 0.252
Q.17
0.629
Q .18 0.183 0.915
Q.19 0.368 0.195
Q.20 0.888 0.454
Q.21 0.807
Q.22 0.759
Q.23 0.375
Q.24 -0 309 0.757
Q.25 0.678 -0.474
SS loadings
% V ar
Cum V ar
P-value para numero de tactores significativos

[1] 0.02704816 0.09031211 0.16264480 0.24105053 0.27768471
F a c to rl Factor2
2.950 2.285
0.295 0.229
0.295 0.523
SS loadings
% V ar
Cum Var
Factor2
-0.325
-0.258
0.100
-0.613
0.841
0.786
0.376
-0.168
F a c to rl
2.710
0.271
0.271
Factor2
2.062
0.206
0.477
P-value para nm ero de factores significativos

[1] 0.1646860 0.6768932 0.6404428 0.7071463 1.0000000
P-value para nmero de factores significativos

[1] 0 1781323 0.4063472 0.6106789 0.76709000.2873605
Uniquenesses:
Q.36 Q.37 Q.38 Q.39 Q.40 Q.41 Q.42 Q.43
0.005 0.678 0.455 0.005 0.602 0.606 0.551 0.505
Uniquenesses:
Q.44 Q.45 Q.46 Q.47 Q.48 Q.49 Q.50 Q.51 Q.52
0.794 0.599 0.398 0.005 0.963 0.500 0.005 0.622 0.769
Loadings:
F a c to rl
Q .44 0.452
Q .45 0.539
Q .4 6 -0.229
Q .4 7 -0.103
Q .48
Q .49 -0.656
Q .50 0.962
Q.51 0.615
Q.52
Loadings:
F acto rl Factor2
Q.36 0.986 -0.148
Q.37 0.410 -0 393
Q.38
0.735
Q.39 0 373 0.925
Q.40 0.581 0.245
Q.41 0.622
Q .4 2 -0.171 -0.648
Q .43 0.673 0.205
SS loadings
% V ar
Cum Var
F a c to rl
2.491
0,311
0.311
Factor2
2.103
0.263
0.574
SS loadings
% V ar
Cum V ar
Factor2
-0.333
-0.741
0.992
0.184
-0.263
-0.263
0.477
F a c to rl
2.298
0 255
0.255
Factor2
2.047
0.227
0.483
161
P-value para nmern de factores significativos

[11 0.01110402 0.16770720 0.73776226
1.00000000
0.82894973
Uniquenesses:
Q.53 Q.54 Q.55 Q.56 Q.57 Q.58 Q.59 Q.60
0.407 0.62 0 0.981 0.454 0.3 13 0.0 05 0.067 0.296
F a c to rl
2.454
0.307
0.307
0.68489319
Uniquenesses
Q.61 Q.62 Q.63 Q.64 Q.65 Q.66 Q.67 Q.68 Q.69
0.580 0.702 0.107 0.957 0.111 0.101 0.005 0.448 0.427
Loadings:
F acto rl Factor2
Q.53
0.766
Q.54 0.487 -0.378
Q.55 0.127
Q.56 0.724 0.149
Q.57 0.816 0.146
Q.58 0.997
Q.59
0.966
0.834
Q.60
SS loadings
% Var
Cum V ar

[11 0.08369687
0.53380251
0.62190666
0.11553942
Loadings:
F acto rl
Factor2
Q.61 0.607
0.228
-0,546
Q.62
Q.63 0.942
Q.64 0.114 -0.172
Q.65 0.453
0 827
Q.66 0.929
0.191
Q.67 0.411
0 909
Q.68 -0.737
Q.69 0.507
0.562
F actor2
2.403
0.300
0.607
SS loadings
% Var
C u m V ar
F a c to rl
3.305
0.367
0.367
Factor2
2.257
0.251
0.618
P-value para nmero de factores significativas

[1] 0.5020110 0.6012633 0.6558159 0.6659497 0.3536387

[1] 0.26677471 0.33676323 0.28116126 0 25463055 0.03302558
Uniquenesses:
Q.70 Q.71 Q.72 Q.73 Q.74 Q.75 Q.76 Q.77 Q.78
0.005 0.476 0.762 0.067 0.455 0.160 0.005 0.005 0.005
Uniquenesses:
Q.79 Q.80 Q 81 Q.82 Q.83 Q.84 Q.85 Q.86 Q.87
0.430 0.101 0.353 0.005 0.377 0.005 0.005 0.778 0.005
Loadings:
F acto rl F actor2 F actor3
Q.70 -0.676 0.236 0.305
Q.71 0.194 -0.694
Q.72
Q.73 -0.195 0.110 0.881
Q.74 0.151 0.522
Q.75 0.906
Q.76 -0.218
Q.77 0.790 0.132 -0.401
Q.78 0.110 0.818 0.560
SS loadings
% V ar
C u m V ar
F acto rf Factor5
0.623
-0.106
0.486
0.478
0.310
0.119
0.959
-0.255
-0.137
0.357
F acto rl Factor2 Factor3 Facto r4 F actcr5

2.061
1.519 1.362 1.237 0.881
0.229
0.169 0.151 0.137 0.098
0.229
0.398 0.549 0.687 0,785
Loadings:
F actorl
Q.79
Q.80 0.254
Q.81
Q.82 0.977
Q.83 0.522
Q.84 0.422
Q.85
Q.86 -0.100
Q.87 0.339
SS loadings
% V ar
C um V ar
Factor2 F actor3 F actor4 Factor5

0.429
0.601
0.908
0.748
0.155 0.204
0.143
0.129 0.151
0.109
-0.118
0.567
0.723
-0.485
0.240
0.971 0.152
-0.121
-0.216
0.404
0.415
0.327 -0.198
0.749
F acto rl Factor2 Factor3 F acto r4 F acto r5

1.613 1.460
1.403 1.317 1.148
0.179 0.162 0.156 0.146 0.128
0.179 0.341 0.497 0.644 0.771
162
P-value p ara nm ero de factores significativos

[1] 0.3067440 0.607820 1 0.6702361 0.5221312 0.4594875
Uniquenesses:
Q.8S Q.89 Q.90 Q.91 Q.92 Q.93 Q.94 Q.95 Q.9d Q.97
0.342 0.284 0.150 0.005 0.625 0.777 0.880 0.970 0.830 0.622
Loadings:
F acto rl
Q.88 0.756
Q.89 0.489
Q.90 0.893
Q.91
Q.92 0.113
Q.93 0.460
Q.94 0.346
Q 95 0.156
Q.96 0.412
Q.97 0.603
SS loadings
% V ar
C u m V ar
Uniquenesses:
Q.98 Q.99 Q.100 Q.101 Q.102 Q.103 Q.104 Q 105 Q 106 Q.107 Q.108
0.152 0.151 0.950 0.213 0.993 0.891 0.520 0.005 0.351 0.586 0,863
Loadings:
F a c to rl F actor2
Q.98
0.917
Q.99
0.887
0.248
Q .l 00 0.131
-0.182
Q.101 0.886
Q.102
Q.103
0.330
Q.104 0.169
0.672
Q.105 0.160
0.985
Q.106 0.192
0.782
Q.107 0.581
-0.276
0.206
Q.108 0.307
Factor2
-0.295
-0.691
0.229
0,998
0,602
-0.106
-0.118
F a c to rl
2.509
0.251
0.251

[1] Q.001800383 0.011980576 0.004849226 0.007651851 0.003958201
Factor2
2.006
0.201
0.451
P-value pata nmero de factores significativos

[1] 0.003232249 0.018343768 0.005628390
SS loadings
% V ar
C um V ar
1.000000000
F a c to rl
2.957
0.269
0.269
Factor2
2 369
0.215
0.484
P-value para nmero de factores significativas

[1] 0.16049380 0.23353012 0.13715729 0.08344508 0.01413303
1.000000000
Uniquenesses:
Q.109 Q.l 10 Q .lll Q.112 Q.113 Q.114 Q. 115
0.877 0.686 0.650 0.005 0.331 0.005 0.258
Loadings:
Facto rl
F actor2
Q.109
0.313 0.159
Q.110 -0.214 -0.518
Q .lll
0.592
Q.112
0.240 0.968
Q.113
0.702 0.420
Q.114
0.987 -0.143
Q .l 15
0.837 0 206
SS loadings
% V ar
C u m V ar
F a c to rl
2.369
0.338
0.338
Factor2
1.820
0.260
0.598
Uniquenesses:
Q.116 Q.117 Q.118 Q.119 Q.120 Q.121 Q.122 Q.123 Q.124
0.740 0.005 0.005 0.005 0.005 0.177 0.312 0.196 0.525
Loadings:
F acto rl
Q.116
Q.117 0.782
Q.118
Q.119 0.246
Q.120 0.110
Q.121 0.858
Q.122 -0.123
Q.123 0.244
Q.124 0.664
SS loadings
% V ar
C um V ar
Factor2 Factor3 Factor4

0.468
0.535
-0.174
0.254
0.910
0.308
0.247
0.333
0.101
0.447
0.863
0.187
-0.110
-0.225
0.412
0.696
-0.150
-0.747
-0.168
F a c to rl
1.943
0.216
0.216
Factor2
1.414
0.157
0.373
Factor5
0.178
0.253
0.867
0.155
-0.135
-0.405
F actor3F actor4F actor5

1.371 1.241 1.060
0.152 0.138 0.118
0.525 0.663 0.781
Anejo 6. Grfica de factores sin rotar
164
Grficas de factores sin rotar
F acto r Plot
Q.2
10
-0.5
0.0
0.5
1.0
-aL'.r.v I
F a c to r P lot
ir.
o
Q11o o ig.v
p
.o
i: .
i.o
Factor!
165
iT
ti
02'h-
-i;.6
-ti:
ti:
o.
*J.o
ix
IlKo'
F a c to r!
0.52
a>l;
-I.C
1:i
i:o
i :i
O .;
[10
Crr-H
Ci?y.
- is
I
-ir
<Y-
10
05
00
00
1o
166
i:
07M
1 :
-o
>:o
i :
1O
(I
*:?>
: i U * /
ta
.'^SSaw/*
10C*
05
c.o
1j
<^5^?
(i *
0**0v
acto?}
Reproduced with perm ission of the copyright owner. Further reproduction prohibited without permission.
10
167
Anejo 7. Rotacin V arim ax preguntas 1-124
168
Rotacin VARIMAX preguntas 1-124
R esultados de 1-7 R equerim ientos

IN IC IO R O TA TIO N V A RIM A X Sloadings
Loadings:
F actor 1
Q .i
Q-2
Q.3 0.993
Q.4 -0.189
Q.5 0.359
Q.6 0.401
Q.7 0.549
SS loadings
% Var
Cum V ar
Factor2
0.996
0.581
0.157
0.250
0.469
F acto rl Factor2
1.617 1.647
0.231 0.235
0.231 0.466
Srotmat [,1]
[,2]
[1.] 0.9874701 0.1578065
[2.]-0.1578065 0.9874701
Resultados de 8-15
IN IC IO R O TA TIO N V A R M A X l oadings
Loadings:
F actorl Factor2
Q.8
0.228
Q.9 0.163
Q. 10 0.878 -0.474
0.407
Q 11 0.295
Q 12 0.651
Q. 13 -0.153
0.986
Q. 14 0.664
0.268
Q .15 0.545
0.352
SS loadings
% V ar
Cum Var
F a c to rl
2.070
0.259
0.259
Factor2
1.614
0.202
0.461
tro tin a
[,1]
[.2]
[1,] 0.99960162 0,02822418
[2 ,]-0.02822418 0.99960162
169
IN IC IO R O T A T IO N V A R IM A X loadings
Loadings:
F acto rl Factor2
Q. 16 0.242 -0.106
Q.17 0.138
0.617
Q. 18 0.282
0.889
Q.19 0.388
0.153
Q.20 0.933
0.354
Q 21 0 7 9 6 -0.148
Q.22 0.753
Q.23 0.374
Q.24 -0,224
0.787
Q.25 0.622 -0.545
SS loadings
Proportion V a r
Cum ulative V a r
$ ro tm a t[,l]
[1,] 0 9939221
[2,] 0.1100859
F acto rl Factor2
2.955 2.280
0.295 0.228
0.295 0,523
[,2]
-0.1100859
0.9939221
Loadings:
F a c to rl
Q 36 0.997
Q.37 0.473
Q.38 -0.192
Q 39 0.202
Q.40 0.528
Q.41 0.596
Q.42
Q.43 0 6 2 6
Factor2
-0.314
0.713
0.977
0 345
0.198
-0.668
0.321
F acto rl Factor2
SS loadings
2.325 2.269
% V ar
0.291 0,284
Cum V a r
0.291 0.574
Srotma
[,1]
[,2]
[1,]
0.9841144 0.1775353
[2.) -0.177 5353 0.9841144
IN IC IO R O T A T IO N V A R IM A X $ loadings
Loadings:
F acto rl
Q .26 0,356
Q .27 0.864
Q .28 0.705
Q .29 0,917
Q .30 -0.351
Q.31
Q .32 0.101
Q .33 -0 435
Q .34 -0.374
Q .35 -0.286
S S loadings
% V ar
C um Var
Factor2
-0.210
0.380
-0.303
0.766
0.871
0.442
-0.200
-0,324
-0.210
F a c to rl Factor2
2.759 2.013
0.276 0,201
0.276 0.477
ro tm a t [.1]
[,2]
[1,] 0.9327569 0,3605059
[2.] -0.3605059 0.9327569
Loadings:
F a c to rl
Q.44 0.453
Q .45 0.567
Q .46 -0.161
Q .47 -0.192
Q .48
Q.49 -0.630
Q .50 0.982
Q.51 0.611
Q .52 -0.101
Factor2
-0.283
-0.759
0.979
0.179
-0.321
-0.175
0,470
F a c to rl Factor2
SS loadings 2.34 2.005
% V ar
0.26 0.223
C um V ar
0.26 0.483
ro tm at [,1]
[,2]
[1,] 0.99590908 0.09036102
[2,] -0.09036102 0.99590908
170
IN IC IO R O T A T IO N V A RIM A X loadings
Loadings:
Loadings:
F acto rl Factor2
Q.53 0.112
0.762
Q.54 0.473
-0.395
Q.55 0.125
Q.56 0.729
0 123
Q.57 0.821
0.117
Q.58 0.996
Q.59
0.965
Q.60
0.836
SS loadings
% V ar
Cum V ar
trotina
[,1]
F a c to rl
2.455
0.307
0.307
Q .70
Q.71
Q .72
Q.73
Q.74
Q.75
Q.76
Q .77
Q.78
Factor2
2.401
0.300
0.607
F a c to rl Factor2
-0.145 0.145
-0.619
0.285
-0.190 0.307
0.236 0.470
0.558
-0 236
0.928
0.948
F acto rl
SS loadings
% V ar
Cum V ar
[,2]
[1.] 0.999375 88 -0.03532484

[2,] 0.03532484 0.99937588
1.424
0.158
0.158
rotmat [,1]
[,2]
[1J 0.70374844 0.0920105 1
[2J 0.14457847 0.93057056
[3J -0.30156118 0.30938189
[4,] -0.03203981 -0.02680727
[5J 0.62599481 -0.17069479
Factor3 Factor4 Factor5

0.350
0.911
0.233
-0.276
0.294
0.250
0.836 -0.150
0.283
0.513
-0.710
0.139
0.963
-0.185 -0.223 -0.224
0.307
Factor2
1.626
0.181
0.339
[,3]
0.1251 658 9
-0.24327753
0.89338172
0.07011081
0.34943258
1.097
0.122
0.461
IN IC IO R O TA TIO N V A R IM A X 1 oadings
Loadings:
Loadings:
Q.6 1
Q.62
Q.63
Q.64
Q.65
Q .66
Q.67
Q.68
Q.6 9
Factor2
0.349
-0.532
0.120
-0.144
0.903
0.379
0.974
-0.245
0.655
F a c to rl
SS loadings 2.726
% V ar
0 303
C um V ar
0.303
ro tm at
[,1]
[,2]
[1.] 0.9784198 0.2066267
[2,] -0.2066267 0.9784198
Q.79
Q.80
Q.81
Q.82
Q.83
Q.84
Q.85
Q.86
Q.87
Factor2
2.836
0 315
0.618
F acto rl Factor2
-0.135
0.395
0.257
-0.157
0.665
0.957
0.407
0.110
0.279
0.811
-0.167
0.163
SS loadings
Proportion V ar
C um ulative V ar
[1,]
[2,]
[3,]
[4,]
[5,]
[.1]
0.979240237
-0.127922586
0.009061448
0.004373097
-0.156917613
0.266
F actorl
0.202
0.111
0.250
0,102
-0.246
-0.404
0.971
-0.299
0.187
F acto rl
Factcr2
1.332
0,148
0.148
1.358
0.151
0.299
[.2]
[.3]
0.106393605 -0.02540925
0.962636743 0.17687404
-0.210575407 0.95210614
0.004071124 0.02167017
-0.132862056 -0.24717251
1.279
0.142
0.603
Factor4
1.635
0.182
0.785
[,4]
[,5]
- 0.01409166 -0.693114 08
0.05671523 0.22524414
-0.06877082 -0.10238836
0.99570678 -0.04367274
0.02057656 0.67562361
F a c to rl
0.546
0.125
0.937
0,147
0.272
0.869
0.215
-0.702
0.379
Factor 3
Factor4
0.593
0 902
0.223
0.163
0.118
Factor5
0,262
0.187
0.609
0.304
0.142 0.114
0.323
-0.116 0.921
Factor3
1.417
0.157
0.456
1.292
0.144
0.600
Factor4
1,541
0.171
0.771
[.4]
[.5]
0.012273493 0.17021366
0.008247528 0.16004332
0.001506992 0.22151190
0.995106063 -0.09622177
0.097688235 0.94185312
171
IN IC IO R O TA TIO N V A R IM A X SI oadmgs
Loadings:
Factorl
Q.88 0.735
Q 89 0.443
Q.90 0.906
Q.91
Q.92 0.152
Q.93 0.453
Q.94 0,345
Q.95 0.160
Q.96 0.412
Q.97 0.594
Loadings:
F a c to rl Factor2
Q.98
0.921
Q.99
0.866 0.315
Q. 100 0.145 -0.171
Q. 101 0.880 0.112
Q. 102
Q. 103
0.327
Q.104 0.117 0,683
Q. 105
0.994
Q. 106 0.132 0.795
Q. 107 0.601 -0,231
Q .108 0.291 0.229
Factor2
-0.343
-0.721
0.171
0 995
0.594
-0,136
-0.156
Facto rl Factor2
% V ar
0.246 0.206
Cum V ar
0.246
0.451
Srolmat [,1]
[1,] 0.99792200
[2.] 0.06443355
Resultados de 98:108
[.2 ]
-0.06443355
0.99792200
F a c to rl Factor2
% V ar
0.262 0.222
Cum V ar
0.262 0.484
ro tm at [,1]
[,2]
[1.] 0.99710632 0.07601967
[2.] -0.07601967 0.99710632
R esultados de 116-124
IN IC IO R O TA TIO N V A R IM A X II oadings
IN IC IO R O TA TIO N V A RIM A X Iloadings
Loadings:
Factorl
Q. 109 0.294
Q.110 -0.157
Q. 111
Q 112 0.135
Q. 113 0.653
Q. 114 0.997
Q. 115 0.810
Factor2
0.192
-0.538
0.588
0.988
0493
0.294
F a c to rl
SS loadings 2.210
% V ar
0.316
Cum V ar
0.316
ro tm at [,1]
[,2]
[1,] 0.9942299 0.1072706
[2,] -0.1072706 0.9942299
Factor2
1.980
0.283
0.598
Loadings:
F acto rl
Q. 116 -0.163
Q. 117 0.943
Q. 118 0.195
Q. 119 0.143
Q. 120
Q. 121 0.687
Q. 122
Q. 123
Q. 124 0.576
S S lo a d n g s
% Var
Cum V ar
F actor2 Factor3 Factor4

0.405
0.310
0.875
0.330
0.182
0.134
0.245
0.378
0889
-0.250
-0.416
0.608
0,552
-0.839
-0.138
-0.322
Factor5
0.259
0.271
0.929
0.234
0.339
-0.107
-0,276
0.182
Factor' Factor2 Factor3 Factor4

1.787
1.153
1.407
1.388
0.199
0.128
0.156
0.154
0.199
0.327
0.483
0.637
Facto
1.295
0.144
0.781
rotmat [,1]
[.4]
[.5]
P]
PJ
[1,] 0.9131420 -0.21802377 0.11410140 -0.25855557 0.19689412
[2.] 0.2444959 0.96322503 0.08555919 0.05081183 -0.05017045
[3.]-0.2098907 -0.01067931 0.93949949 -0.14263218 0.22984480
[4,] 0.2244040 -0 12865243 0.20824933 0.94076219 -0.06848450
[5,]-0.1094636 0.08942977 -0.23158891 0.15871274 0.94931390
172
Anejo 8. R epresentacin grfica de las variables respecto a los ejes factoriales

rotados, utilizando VARIMAX
173
F a c to r Plot in Varim ax R otaton
1.0
- 0 .5
.C
0 .5
'
.0
F a ;:o i 1
F a c to r Plo t In V arim ax R otatlon

w
UD
O
O
irt
o
1.0
-.b
U .J
174
F actor Plot in Varimax Rotafion

Pactar Plot in Varimax Rotation
C 24
o ;-4
n:i
u :
1.0
0.3
FiV.M r'
Fsc.or
Factor Plot in Varimax Rotation
Factor Plot in Varirnax Rotation
I.C
Q '7 y
:j4)
i
J.1
i
0.9
0.3
1.0
f- L-vlfjf'
Factor Plot In Varimax Rotation
I.C

Cl.5T f
5^ '"
O i:
l.
0.5
1.C
1.
C5
1.C
175
F acto r Plot In V arim ax Rotation

u.-
d
0 70
o
.7J
J.
-I.C
.0
1C
1.0
e ctcrl

C.31
- 1J>
/
U.1C f
.icM t
i
Q.1C3 / /
//a ic a *
\
0.102 W
"Of-
O. ICC-
-.5
-a:.h*.r1
o.c
Ic
Ce

u .n f
O 11f? |
^ 111* /
0.117,*
r acorS
1
Q .'2 *
/
..
O.-'M*
Q 2 2 a -U ..-- z ;r
.X-:.24~*
.11U
1. 1.
I0
-n s
nr
F :l:jf 1
A nejo 9. Rotacin PROMAX
177
R esultados de 1:7
IN IC IO R O T A T IO N PR O M A X loadings
Loadings:
Factorl Factor2
Q .l -0.175 1.031
Q.2
0.599
Q.3 1.036 -0.258
Q.4 -0.214 0.192
Q-5 0 366
Q.6 0.384 0.190
Q.7 0.510 0.391
F acto rl Factor2
% V ar
0.243 0.245
Cura V ar 0.243 0.488
ro tm at [,1]
[,2]
[1,] 1.0001072 -0.0003957475
[2,] -0,2812987 1.0389144667
Resultados de 8:15
IN IC IO R O T A T IO N P R O M A X loadings
Loadings:
Factorl
Factor 2
Q.8
0.236
Q.9 0.154
Q. 10 1.024 -0,598
Q. 11 0.202 0.397
Q. 12 0.681 -0.113
Q .l3 -0.404 1.058
Q. 14 0.618 0.209
0.311
Q .l5 0.474
F acto rl
SS loadings 2.348
% V ar
0.293
Cum V ar 0.293
Factor2
1.844
0.231
0.524
ro tm at [,1]
[,2]
[1,] 1.0243747 -0.081379
[2,] -0.2786498 1.058474
178
IN IC IO R O T A T IO N PR O M A X $1 oadngs
Loadings:
Factorl
Q. 16 0.243
Q. 17 0.147
Q. 18 0.296
Q. 19 0.393
Q.20 0.945
Q.21 0.801
Q.22 0.758
Q.23 0 377
Q.24 -0.216
Q .25 0.620
SS loadings
% V ar
Cum Var
Loadings:
F acto rl
Q.26 0,325
Q.27 0,871
Q.28 0.759
Q.29 0.872
Q.30 -0.240
Q.31 0.199
Q.32 0.165
Q.33 -0.464
Q.34 -0.420
Q.35 -0.317
Factor2
0.635
0.925
0,201
0.468
0.761
-0,470
F acto rl
3.008
0.301
0.301
Factor2
2 328
0.233
0.534
SS loadings
% V ar
C um V a r
Factor2
-0.305
-0.190
0.168
-0.553
0.842
0.823
0.400
-0.208
-0.123
F acto rl Factor2
2.820 2.074
0.282 0.207
0.282 0.489
Srotmat [,1]
[,2]
[1.] 1.0014048 0.01097513
[2,] 0.1237063 1.00895707
ro tm a t
[ ,1]
[,2]
[1 J 0.9845856 0.08475553
[2,] -0.2250699 1.00642025
Resultados de 36:43
Loadings:
F acto rl Factor2
Q .36 1.011
Q .37 0.503 -0.376
Q .38 -0.246 0.744
Q 39 0 136 0.963
Q .40 0.512 0.283
Q.41 0.591 0.127
-0.669
Q 42
Q .43 0.613 0.248
SS loadings
% V ar
Cum Var
F acto rl Factor2
2.343 2.235
0.293 0.279
0.293 0.572
Srotmat [, 1]
[.2]
[1,]
0.9873177
0.05819312
[2.] -0,2501997 1. 01686271
Loadings:
F a c to rl Factor2
Q.44 0.454
Q.45 0.567 -0.292
Q.46 -0.161 -0.756
Q.47 -0.193 0.982
0.180
Q.48
Q 4 9 -0.630 -0.311
Q.50 0.982 -0.192
Q 51 0.611
Q.52 -0.101 0.472
SS loadings
% V ar
Cum V ar
F a c to rl Factor2
2.341
2.013
0.260
0.224
0 260
0.484
ro tm a t
[,1]
[.2]
[1 J
0.99597546 0.07386379
[2,] -0.09132224 0.99742218
179
Resultados de 53:60
IN IC IO R O T A T IO N P R O M A X lo ad ings
ro tm at
[1,]
[2,]
Loadings:
F acto rl
Q .53 0.113
Q.54 0.472
Q.55 0.125
Q.56 0.729
Q 57 0.821
Q .58 0.996
Q.59
Q.60
0.966
0.835
SS loadings
% V ar
Cum V ar
F acto rl Factor2
2.456 2.403
0.307 0.300
0.307 0.607
[.1]
IN IC IO R O TA TIO N PR O M A X lo adings
Loadings:
F a c to rl Factor2
Q.61 0.530 0.202
Q.62 0.253 -0.615
Q.63 1.012 -0.171
Q.64 0.194 -0.203
Q.65 0.107 0.889
Q.66 0,881 0.130
Q.67
0.984
Q.68 -0.724
Q.69 0.279 0.586
Factor2
0.764
-0.387
0.135
0.130
SS loadings
% Var
Cum V ar
F a c to rl Factor2
2.797
2.611
0.311
0.290
0.311
0.601
[,2]
ro tm a t [,1]
[,2]
[1,] 1.0389458 -0.09117215
[2,] -0.4398997 1 12454779
0.99945689 - 0.019278 52
0.03781006 0.99998600
Resultados de 79:87
IN IC IO R O T A T IO N PR O M A X lo a d in g s
Loadings:
Facto rl
Q.70 -0.587
Q.71 0.280
Q.72 0.104
Q.73
Q.74 0.214
Q.75 0.957
Q.76
Q 7 7 0.752
Q.78 0.130
Factor2 F acto r3
0.235
-0.690
0.203
-0.196
0.150
0.158
0885
0.408
0.195
-0.102
-0.290
0.953
0.437
SS loadings
ProportionVar
CumulativeVar
Factorl Factor2
1.988 1.625
0.221 0.181
0.221 0.401
rotmat [,1]
[,2]
[,3]
[1J 1.0583891 0.05789951 0.16253896
[2,]-0.1053947 1.01976460 -0.18995648
[3,] 0.1878677 0.18200895 1.03330157
[4,] 0.1846787 -0.18147167 0.07886713
[5,] 0.1471823 -0.39413514 0.11601107
Factor4 Factor5
0.780
0.461
0.985
-0.213
-0,112
0.488
0.283
0.132
-0.296
0.225
Factor3Faclor4Factor5
1.221 1.254 1.091
0.136 0.139 0.121
0.537 0.676 0.798
[,4]
[,5]
0.08646670 -0.215463059
-0.16702789 0.008525701
0.05674361 -0.089115516
1.07505026 0.072763003
0.10476649 1.055156107
Loadings:
F acto rl
Q.79 -0.166
Q.80 0.152
Q. 81 -0.164
Q.82 0.972
Q.83 0.260
Q.84 0.274
Q.85 0.137
Q.86 -0.285
Q.87
SS loadings
% Var
Cum Var
F a c to r2 F a c to r3 Factor4 Factor5
0.376
0.492
-0.105
-0.105
0.943
0.718
0.202
0.153
0.164
-0.176
0.187
0.581
0.820
0.440 -0.113
1.027
0.188
-0.282
0.103
0 383
0.206 0.316
-0,153 0.933
Factorl Factor2 Factor3

1.266
1.392 1.534
0.141 0.155 0.170
0.141 0.295 0.466
rotmat [.1]
[,2]
[1J 1.01595004 0.05697545
[ 2 J -0.04356616 1.11030883
[3J 0.02606634 -0.16358918
[4J -0.14152565 -0.17538163
[ 5 J -0.44944482 -0.34078121
Factor!
1.225
0.136
0.602
Factor5
1.431
0.159
0.761
[,3]
[,4]
[,5]
0.04643624 -0.05514586 -0.01794973
0.11592823 -0.31877330 -0.07546465
1.04145264 -0 07824810 0.34898354
-0.10930964 1.09121094 -0.03639536
-0.14771257 0.31942029 1.13229057
180
Loadings:
F a c to rl Factor2
Q.88 0.717 -0.234
Q.89 0.372 -0.668
Q.90 0.953
0.319
1.030
Q 91 0.183
0.633
Q 92 0.226
Q.93 0.450
Q.94 0.353
Q 95 0.173
Q.96 0.425
Q.97 0.594
F a c to rl
SS loadings 2.537
% V ar
0.254
Cum V ar
0.254
Factor2
2087
0.209
0.462
Srotmat [,1 ]
[,2]
[1,] 1.0206149 0.092984
[2,] 0 1840789 1.032906
SS 1oadings
% Var
Cum V ar
F a c to rl
2.879
0.262
0 262
F actor2
2.410
0.219
0.481
ro tm at
[,1]
[,2 ]
[1,] 1.0013868 -0.00990353
[2,]-0.1366179 1.01061462
Resultados de 116-124
INICIO ROTATION PROMAX loadings
IN IC IO R O T A T IO N P R O M A X lo a n g s
Loadings:
F acto rl
Q .l 09 0.271
Q .l 10
Q .l 11 -0.213
Q .l 12
Q .l 13 0.587
Q .l 14 1.084
Q .l 15 0.803
Factor2
0.136
-0.542
0.650
1.033
0.372
-0.281
0.120
F a c to rl
SS loadings 2.295
% V ar
0.328
0,328
Cum Var
ro tm at [.1]
IN IC IO R O T A T IO N P R O M A X lo a d in g s
Loadings:
F a c to rl Factor2
Q.98 0.930
Q.99 0.855 0.242
Q.100 0.156 -0.185
Q. 101 0.881
Q.102
Q .l 03
0.333
Q .l 04
0.678
Q. 105
0.993
Q.106
0.789
Q .l07 0.620 -0.285
Q. 108 0.280 0.205
[.2]
[1,] 1.0472294 -0.1261924

[2,] -0,3537 205 1.0981270
Factor2
2.034
0.291
0.618
Loadings:
Factorl
Q .ll -0.105
Q.l 17 0.827
Q.l 18 -0.113
Q.l 19 0.153
Q.120
Q.121 0.844
Q.122
Q.123 0.101
Q .l24 0.637
Factor2 Factor3
0.397
0.370
0.947 0.286
0.126
0.310 0.881
0.259
0.202 0.409
0.211
-0.157
Factorl
SS loadings 1.861
% Var
0.207
Cum Var 0.207
Factor2
1.258
0.140
0.347
Factor4
Factori
0.215
-0.151
0.142
-0.131
0.135
0.892
-0.147
0.721
-0.842
-0.176
-0.349
0.202
0.220
Factor3 Factorf Factor5

1.242
1.367 1.077
0.138
0.152 0.120
0.485
0.636 0.756
rotmat [.1]
[,4]
[.5]
[-3]
W
[1,]
1.0525434-0.23118420 0.09154450 0.07171676 0 02845314
[2J -0.1592877 1.12982926 0.07374808 -0 26390976 -0.15769593
[3J -0.0778826 - 0.12865248 1.00570630 - 0 09221782 0.04586014
[4J
0.2827115 -0.30522070 -0.06489205 1.13672120 -0 06347903
[5J -0.0798392-0.02646989 -0.35973266 0.12169942 1.05485412

Tesis Sobre TI

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tesis Sobre TI

Diunggah oleh

Hak Cipta:

Format Tersedia

A PL IC A C I N DE CONCEPTOS DE GESTIN DE PRO YECTOS Y GESTIN

DE R IE S G O EN EL DESARROLLO DE PRODUCTOS NUEVOS EN EL CAMPO

Pedro Resto Batalla, PhD.

Miembro del Comit Graduado

Miguel Segu Figueroa, LL.M

Miembro del Comit Graduado

Viviana Cesan Vzquez, Ph.D.

Presidente del Comit Graduado

Antonio A. Gonzlez Quevedo, Ph.D.

Representante de Estudios Graduados

Agustn Rulln Toro, Ph.D.

Director del Departamento

UMI Number: 1431301

ProQuest Information and Learning Company

Compaas de desarrollo de programas demuestran una gestin de riesgos pobre en

A la memoria de mis abuelas Deyanira Llanos y Ersilda Barreiro, que

Inmenso agradecimiento a mi asesora de tesis, Dra. Viviana Cesan, por su

A todo el personal de la compaa donde se realiz este proyecto especialmente al

Al Recinto Universitario de Mayagez de la Universidad de Puerto Rico por

Y a toda mi familia; gracias por ayudarme en aquellos momentos donde necesite

Mtodos tradicionales o formales de desarrollo de software....................................... 14

2.2.3 Mtodos giles e iterativos para desarrollo de software............................................... 17

2.3. Gestin de proyectos de desarrollo de software.......................................................... 22

3.3 Construccin, administracin y anlisis de una herramienta de identificacin de

Administracin y anlisis de laherramienta de identificacinde riesgos.....................42

3.3.2.1.Validacin del cuestionario......................................................................................43

3.4 Gestin de riesgos........................................................................................................... 49

3.5 Conclusiones del proceso de gestin de riesgos.............................................................63

4. CASO DE ESTU D IO ........................................................................................................ 64

4.2. Riesgos percibidos.......................................................................................................72

Administracin y anlisis de resultados de la herramienta de identificacin de

5. GESTIN DE R IESG O S...................................................................................................97

5.3 Fase 3. Anlisis de los riesgos.......................................................................................103

Anlisis cualitativo de los riesgos.............................................................................. 103

5.3.2 Anlisis Cuantitativo de los riesgos............................................................................... 105

5.4 Fase 4. Planeadn de respuesta al riesgo....................................................................106

6. CONCLUSIONES Y TRABAJOS FU TU R O S........................................................... 117

Figura 1. Ciclo de vida clsico (Ranean, 2003).............................................................................................15

Figura 32. Grfica eprobabilidad normal de los residuales........................................................................ 94

Tabla 1. Herramientas de identificacin de riesgos en proyectos de software............................................... 9

Anejo 1. Cronograma de actividades - Caso de estudio............................................................................. 25

Gestionar un proyecto de desarrollo de software como si se tratara de un proyecto

Uno de los aspectos ms importantes para el xito del desarrollo de un producto

Start-up, es un trmino que se refiere a aquellas compaas pequeas de desarrollo

Conseguir clientes e inversionistas es la meta ms importante de esta clase de

En cuanto a sus proyectos, estos estn asociados intrnsecamente con un conjunto

1.2. Definicin del problem a

En los proyectos de tecnologa de informacin (TI), la gestin de riesgos es crucial

Muy pocas organizaciones utilizan mtodos de gestin de riesgos en sus proyectos

Actualmente las pequeas compaas de desarrollo de software, de recin entrada al

conocimiento sobre posibles mtodos y herramientas, limitaciones prcticas y tericas de

Administrar los riesgos por medio de un proceso de desarrollo de software

Por lo tanto el propsito de este proyecto es aplicar los conceptos de la gestin de

1. Analizar la situacin actual de las compaas pequeas de desarrollo de

2. Identificar los riesgos ms relevantes en compaas pequeas de desarrollo de

3. Realizar una compilacin final de los riesgos ms importantes del producto en

Desarrollar y probar una metodologa continua de gestin de riesgos

1.6 Organizacin del documento

El Captulo 2 presenta las diferentes herramientas de identificacin de riesgos

El Captulo 3 presenta la metodologa propuesta. sta fundamentalmente se

El Captulo 4 describe el Caso de estudio desarrollado en una compaa de

El Captulo 5 describe la gestin de riesgos desarrollada en la compaa caso

Finalmente en el Captulo 6 presenta las conclusiones, recomendaciones y trabajos