Proceso para la gestión de riesgos

Texto completo

(1)PROYECTO DE GRADO. PROCESO PARA LA GESTIÓN DE RIESGOS. SAULO DAVID DAZA SIERRA Código: 200011345 Asesor: Juan Pablo Quiroga. UNIVERSIDAD DE LOS ANDES 2005. 18.

(2) AGRADECIMIENTOS. Para el grupo QUALDEV, por su gran aporte en conocimiento, y en especial para todos aquellos que durante el año 2004 hicieron parte de CHANGESET: Rubby Casallas, Hugo Arboleda, Ugo Posada, Angela Lozano, Manuel Pedraza, Sergio Rodriguez, Camilo Rincón, Diego Ramírez, Carlos Durán. Igualmente a todos aquellos que me apoyaron durante este tiempo, mi familia y mis amigos.. 19.

(3) TABLA DE CONTENIDO. 1. INTRODUCCIÓN. pág. 1. 2. MARCO TEÓRICO. pág. 2. 2.1. Definiciones. pág. 2. 2.2. Mecanismos para control de riesgos. pág. 2. 2.3. Ciclo de la administración de riesgos. pág. 4. 3. METODOLOGÍA PARA EL MANEJO DE RIESGOS. pág. 5. 3.1. Identificación y definición de riesgos. pág. 6. 3.2. Clasificación de riesgos. pág. 7. 3.3. Priorización de riesgos. pág. 9. 3.4. Definición de planes de mitigación. pág. 10. 3.5. Seguimiento de riesgos. pág. 12. 3.6. Control de riesgos. pág. 14. 4. MÉTRICAS. pág. 14. 5. CONCLUSIONES Y TRABAJOS FUTUROS. pág. 15. 6. BIBLIOGRAFÍA. pág. 15. 17.

(4) 1. INTRODUCCIÓN En muchas ocasiones los proyectos de construcción de software tienen desfases significativos que representan perdida de dinero y de oportunidades tanto para la empresa constructora como para la empresa contratante. A pesar de que estos desfases han disminuido notablemente en los últimos años, gracias a la utilización de metodologías más cercanas con la realidad del desarrollo, los desfases siguen siendo muy grandes como para que una empresa los apruebe repetidamente [11]. Un proyecto de desarrollo de software tiene muchas dificultades debido a los inconvenientes que se presentan al trabajar en grupo y a los malentendidos que se presentan debido a la manera distinta como las personas involucradas en el proceso entienden el problema, los requerimientos y las soluciones: cliente, patrocinador, desarrolladores y usuarios finales. Producir un software de calidad no depende solamente de seguir un proceso de desarrollo específico, depende también de muchas variables del entorno que pueden ser predecibles o no y que pueden llegar a afectar el desarrollo del mismo. Algunas de las variables pueden ser cualitativas mientras otras cuantitativas. El éxito del proyecto se logra cuando se evita que estas variables afecten de manera significativa el proceso de desarrollo. Estas variables son definidas como riesgos inherentes al proyecto y dependiendo de la política que se tenga definida para su administración, el impacto de la ocurrencia del riesgo puede afectar enormemente el desarrollo de un proyecto. Los proyectos ágiles son inherentemente riesgosos por el hecho mismo de que no son sistemas creados como algo estático, sino que son construidos para responder al mundo cambiante de los negocios, la inventiva, las nuevas tecnologías y para el servicio de la gente, lo cual lo hace un factor de inestabilidad que se suma a la difícil labor de generar estimativos de tiempo, dinero y recursos en las etapas de lanzamiento y estrategia. [2] En este artículo presentamos una propuesta para la administración de riesgos en un contexto de proyectos ágiles. La propuesta incluye un proceso compuesto por actividades que deben llevarse a cabo, cuándo y quién debe realizarlas, además de propuestas para algunas políticas en los riesgos más comunes en los proyectos ágiles. El presente artículo comienza con la definición de los términos que se utilizarán en el documento, seguido de los diferentes mecanismos para el control de los riesgos que se pueden presentar, igualmente se introduce el ciclo de la administración de riesgos y finalmente se presenta la propuesta para el manejo de riesgos en los proyectos ágiles. 1.

(5) 2. MARCO TEÓRICO 2.1. Definiciones Riesgo es una palabra que es muy utilizada en la vida cotidiana, razón por la que tienden a encontrarse múltiples definiciones, tales como “Fuente de peligro, posibilidad de incurrir en pérdida o desgracia” [16]. “Contingencia o proximidad de un daño” [10]. “potencial para la realización de consecuencias negativas indeseadas de un acontecimiento” [13]. Estas definiciones y otras más tienen en común dos aspectos que vale la pena resaltar; pérdida e incertidumbre. La gerencia del riesgo es una práctica con procesos, métodos y herramientas para manejar en un proyecto que permite la identificación, priorización y estrategias de solución. [14] Entiéndase por proceso la serie de acciones, cambios o funciones que han de ser realizadas para obtener un resultado [4], los métodos son una manera formal y sistemática de hacer algo [3], mientras las herramientas son un instrumento que se utiliza para realizar una operación [5]. Las etapas de desarrollo en un proyecto ágil, están basadas en las metodologías TSP [6] (Proceso de desarrollo de software en equipo), CMM (Modelo de la capacidad de madurez) [12] y propuestas de procesos livianos (lightweight process), y que comprenden lanzamiento, estrategia, planeación, análisis, diseño, codificación, pruebas y postmortem [1]. Los miembros con más responsabilidades en el proceso de gestión de riesgos que se define más adelante son los líderes de proyecto, proceso y desarrollo, los cuales están definidos en la metodología TSP.. 2.2. Mecanismos para el control de riesgos Existen varias formas de administrar los riesgos. Estas son: no hacer nada, al momento de presentarse mirar la mejor forma de solucionarlo, identificar y planear soluciones a posibles riesgos y evitar los riesgos mediante la aplicación de políticas que eviten que ellos aparezcan Cada uno de los mecanismos de administración de riesgo trata el riesgo de una manera diferente, ya que con los riesgos se puede: evitarlos, trasladar este a otra parte del proyecto, eliminar el origen del riesgo o asumir el riesgo [9]. A continuación se muestran las ventajas y desventajas de cada uno de los mecanismos de administración de riesgos: Mecanismo de administración. Ventajas. Desventajas. 2.

(6) No hacer nada. Evita costo de Puede conducir a mayores identificación y planeación. costos o conclusión del producto debido a que en el transcurso del tiempo los cambios pueden ser radicales. Administración No hay costos de Puede causar retrasos en reactiva: esperar a planeación. el proyecto. Es equivalente que se presente el a tener un proyecto sin riesgo para analizar la planeación. mejor forma de controlarlo Identificar y planear Ayuda en la reducción de Inconvenientes al contingencias problemas durante el momento de clasificar los desarrollo del software. riesgos adecuadamente. Evita sobre costos del Se planea la reacción al sistema. riesgo y no la manera de evitarlo. Evitar que los riesgos Permite que el proyecto se Necesita conocimiento se presenten. desarrolle tal como se muy completo del entorno espera. Al tener un alto y su comportamiento. El conocimiento, sus costos costo inicial de son bajos. construcción de conocimiento es alto.. Aunque el último mecanismo de los presentados en la tabla es el ideal de toda compañía, el más utilizado en los proyectos ágiles es el de la identificación de los riesgos y el plan de solución en caso que estos se presenten. Además es importante acordarse de monitorearlos y controlarlos durante todo el proceso. Es por esta razón que en la actualidad se tiene como paradigma de la administración de riesgos el mostrado en la siguiente figura: [15]. 3.

(7) Se observa a la comunicación como la clave de todo el proceso, al igual que es un proceso continuo en el que a pesar de estar controlando los riesgos priorizados se debe seguir identificando nuevos riesgos, para que estos sean analizados, planificados y se les haga el seguimiento correspondiente para poder controlarlos, y así sucesivamente durante la vida entera del proyecto que se esté realizando. El proceso se va a mantener cíclico debido a que el entorno siempre se encuentra en continuo cambio y estos cambios (en ocasiones pequeños, en otros moderados) pueden llegar a afectar el proyecto. 2.3. Ciclo de la administración de riesgos Etapas para el reconocimiento de posibles riesgos, y su forma de mitigarlos. Existen diferentes tipos de prácticas para la administración de los riesgos; desde las que van de basarse en los juicios de expertos, hasta las que conforman toda una metodología de desarrollo. Los juicios de expertos son utilizados por muchas empresas para la identificación de riesgos. Estos juicios son realizados con la intuición y experiencia de quienes los realizan, además que su categorización puede ser basada en técnicas sofisticadas o no [11]. La administración basada en una metodología busca mejorar en la prevención de los riesgos a medida que se realizan proyectos. Estas metodologías usualmente funcionan de la manera que se observa en la siguiente figura: [7]. En la gráfica se observa que después de la definición del proceso a seguir, se empieza por la identificación de los riesgos, identificando responsables. Se sigue con un análisis de los riesgos definidos, donde se define hasta que punto se va a aceptar el riesgo, se generan posibles respuestas a los riesgos, las cuales van a ser implementadas al momento de aparecer el riesgo, luego se evalúa la efectividad de la solución propuesta y finalmente se mejora el proceso con las lecciones aprendidas.. 4.

(8) La diferencia entre los dos tipos de prácticas radica en la cantidad de personas involucradas en el proceso. Mientras en los juicios de expertos, se depende únicamente de la experiencia de ellos, en la segunda el grupo entero participa y llega a conclusiones conjuntas. El trabajo en grupo permite poder definir a los responsables más adecuados, mientras en el primero será encargado a juicio del experto. Igualmente el juicio de experto facilita la valoración de los riesgos, ya que participan menos personas en esta. Los mecanismos que permiten controlar los riesgos de manera preventiva siempre cumplen con las siguientes etapas: identificación, análisis, planeación de la respuesta a riesgos, seguimiento y control. Cada administrador de riesgos decide hasta que etapa llegar de acuerdo con el tipo de proyecto a realizar, al igual que el mecanismo a seguir. 3. METODOLOGÍA PARA EL MANEJO DE RIESGOS Las actividades propuestas para la administración de riesgos en el entorno de proyectos ágiles, son: Identificación y definición de riesgos, clasificación de riesgos, priorización de riesgos a mitigar, definición de planes de mitigación, seguimiento de riesgos y control de riesgos.. La figura anterior muestra la forma en la que se relacionan las diferentes actividades del manejo de riesgos propuesto. Este parte de la identificación y definición, para luego ser clasificados. Luego de la clasificación se realiza una priorización, la cual permite definir los planes de mitigación, que serán utilizados al momento de realizar algún tipo de control. Luego de la priorización se empieza a hacer seguimiento de todos los riesgos identificados y control según corresponda. Finalmente se realizarán las métricas correspondientes para mejorar cada una de las actividades anteriormente nombradas y poder volver a comenzar con la identificación y definición del siguiente ciclo de desarrollo. 3.1. Identificación y definición de riesgos Identificar y definir los riesgos es el primer paso para hacer conciencia de ellos. La integración de todos los integrantes del equipo al proceso de identificación 5.

(9) de riesgos hace que se mezclen diferentes perspectivas de manera que se cubra la mayor cantidad de aspectos que pueden presentar inconvenientes. El propósito de esta actividad es identificar los posibles riesgos asociados a todo nivel dentro del proyecto y debe de ser realizada al inicio de cada ciclo de desarrollo; durante la etapa de estrategia, y revisada al final de este; en el postmortem. Esta tarea tiene como responsable al líder del proyecto, aunque realizada por parte de todos los miembros del equipo, en la que todos generan una lista con los que para cada uno son los riesgos que puede presentar el proyecto; no solo identificarlos, sino también definirlos, de esta manera los integrantes del equipo aprenden a identificar y hacer conciencia de los puntos débiles o no completamente controlados para prepararse ante ellos. Para no comenzar de ceros siempre en cada uno de los ciclos, se debe de partir de los históricos del proyecto, de manera similar a la que se utiliza en el proceso de planeación. A continuación se muestra el template de la lista de chequeos. Adicionalmente se muestra un ejemplo de la forma en que debe de ser llenado. Lista de chequeo Subcategoría. Descripción. Ejemplo de riesgo. Ejemplo de diligenciamiento del mismo Subcategoría. Descripción. Ejemplo de riesgo. Tamaño del producto. Riesgos asociados con el tamaño del software a construir o modificar. Gran número de requerimientos a implementar en poco tiempo. Impacto del negocio. Riesgos asociados con las Alta gerencia no esta condiciones impuestas por el muy convencida de gerente o el mercado apoyar el proyecto.. Características de los clientes. Riesgos asociados con lo sofisticado del cliente y la forma en la que se comunican los clientes con los desarrolladores.. Requerimientos cambiantes debido a modificaciones continuas por parte del cliente.. 6.

(10) Definición del proceso. Riesgos asociados con el Proceso de desarrollo grado de definición del cambiante proceso de desarrollo a seguir continuamente. por parte de los desarrolladores. Ambiente de desarrollo. Riesgos asociados con la Licencias expiran en disponibilidad y calidad de las medio del ciclo de herramientas con las que se desarrollo va a construir el producto. Tecnología con la que se va a desarrollar. Riesgos asociados con la complejidad del sistema a construir y las nuevas tecnologías asociadas al sistema.. Proyecto requiere el uso de herramientas nuevas en el mercado que se encuentran en etapa de pruebas.. Tamaño del grupo y experiencia. Riesgos asociados con la experiencia técnica y en el proyecto de los desarrolladores que harán el trabajo.. Grupo demasiado grande con conocimiento centralizado en pocas personas.. 3.2. Clasificación de riesgos [11] Una vez los riesgos han sido definidos e identificados se clasifican de acuerdo a parámetros preestablecidos. Estos pueden ser probabilidad de ocurrencia, probabilidad de impacto o una combinación de ambos. La manera de medir estos parámetros se realiza de forma subjetiva de acuerdo a la experiencia de la persona y teniendo en cuenta la situación actual del grupo. La clasificación es realizada para lograr establecer un orden en la administración de estos. Esta actividad recoge los diferentes puntos de vista de los integrantes del equipo. Luego de discutirlos, cada miembro del equipo clasifica los riesgos que serán priorizados y eventualmente mitigados de acuerdo a los parámetros del grupo y finalmente el líder del proyecto genera la lista final teniendo en cuenta la clasificación realizada por cada uno de los miembros participantes. A continuación se muestra el template de la escala de probabilidades y de impacto. Adicionalmente se muestra un ejemplo de la forma en que debe de ser llenado. Escala de probabilidad e impacto QUALDEV Proyecto 7.

(11) Creado por: Riesgo Probabilidad. Descripción. 0.1 0.3 0.5 0.7 0.9. Impacto. Descripción. 0.1 0.3 0.5 0.7 0.9 Ejemplo de diligenciamiento de la escala de probabilidad e impacto QUALDEV Proyecto. Changeset. Creado por: Riesgo. Saulo David Daza R1 - Salida de un miembro del grupo. Probabilidad. Descripción. 0.1. Personal muy entusiasmado. 0.3. Personal con compromiso al grupo, integrantes en ocasiones son proactivos. 8.

(12) 0.5. Personal con compromiso al grupo, pero b uscando otras opciones. 0.7. Bajo compromiso de los integrantes, integrantes no son proactivos.. 0.9. Baja motivación de los integrantes. Impacto. Descripción. 0.1. Miemb ro con poco conocimiento de proceso y herramientas. 0.3. Miemb ro con alta capacidad de compromiso.. 0.5. Miemb ro de gran aporte en ideas al grupo y alta capacidad de compromiso.. 0.7. Miemb ro con conocimiento único en proceso o herramientas.. 0.9. Miemb ro con conocimiento único en proceso y herramientas. 3.3. Priorización de riesgos Una vez se tienen clasificados los riesgos según su probabilidad de ocurrencia y el impacto que generarían, se define sobre cuales riesgos se va a enfocar la administración de estos, ya que enfocarse en la totalidad de los riesgos identificados, puede llegar a ser muy costoso para el proyecto. Para los proyectos ágiles como este se realizara sobre los cinco más importantes como máximo, debido a que las etapas de desarrollo son pequeñas y en cada nuevo ciclo se hará una nueva priorización de los riesgos. La priorización de los riesgos debe de realizarse de la manera como se observa en la siguiente figura [11]:. 9.

(13) Los valores 0.2, 0.4,… 1.0 representan el valor probabilística de cada uno de los parámetros de clasificación que se tuvieron en cuenta (probabilidad de falla e impacto de la falla en escala de 0 a 1). Los riesgos más prioritarios se van a encontrar más cerca de la esquina superior derecha de la gráfica, mientras los menos prioritarios se van a encontrar en la esquina inferior izquierda. 3.4. Definición de planes de mitigación Esta actividad consiste en estudiar y definir los posibles planes de mitigación que se deben implantar para los riesgos, una vez estos han sido priorizados. Lo que se busca es evitar la ocurrencia del riesgo y es una tarea que tiene como responsable al líder de proceso, aunque ha de ser llevada a cabo junto con el líder de desarrollo y líder del proyecto. Estos planes han de ser desarrollados a lo largo del ciclo de desarrollo de manera que la inversión sea mínima para cada nuevo periodo de desarrollo. A continuación se muestra el template del plan de mitigación. Adicionalmente se muestra un instructivo de cómo debe de ser llenado. Plan de mitigación QUALDEV Proyecto Creado por: Riesgo Identificador del riesgo: Fecha: Probabilidad: Impacto: Descripción: Responsable del riesgo: Actividades de mitigación: Actividades de monitoreo: Traza:. 10.

(14) Estado actual: Instructivo del plan de mitigación QUALDEV Proyecto. Nomb re del proyecto. Creado por: Riesgo. Nomb re del autor Identificador del riesgo. Identificador del riesgo: Identificador dado al riesgo al que corresponde el plan de mitigación Fecha: Fecha de realización del plan Probabilidad:. Prob ab ilidad de que ocurra el riesgo (inicial). Impacto:. Impacto que tiene el riesgo en caso de presentarse (inicial) Descripción general del plan. Descripción: Responsable del riesgo: Actividades de mitigación: Actividades de monitoreo: Traza: Estado actual:. Persona responsab le de hacer el seguimiento al riesgo Actividades que se llevarán a cab o para que el riesgo no se presente. Actividades que se llevarán a cab o para hacer el seguimiento de la evolución del riesgo Lo que se ha hecho para reducir el impacto o la prob ab ilidad del riesgo. Como se encuentra el riesgo en cuanto a prob ab ilidad de ocurrencia e impacto.. 3.5. Seguimiento de riesgos Esta actividad busca rastrear el desarrollo de los riesgos identificados, para monitorear las actividades que se estén llevando a cabo para evitar los riesgos. El monitoreo busca observar el desarrollo de los riesgos, en especial aquellos con planes de mitigación debido a que los riesgos se siguen presentando a medida que avanza el proyecto e igualmente van cambiando las probabilidades de los riesgos, de la misma manera en la que se pueden presentar nuevos riesgos, que no hayan sido identificados o tenidos en cuenta al momento de realizar los planes de mitigación. Esto debido a que así como el proyecto evoluciona con el paso del tiempo, lo mismo pasa con los riesgos. 11.

(15) El responsable de esta actividad debe de ser el líder del proyecto y en la que participan todos los integrantes del proyecto dando sus comentarios en las reuniones periódicas que tenga el grupo y documentándolas en el reporte entregado. La forma de hacer seguimiento es evaluar la probabilidad de ocurrencia de cada riesgo semanalmente, y realizar una clasificación para observar su comportamiento A continuación se muestra el template del formato de seguimiento. Adicionalmente se muestra un instructivo de cómo debe de ser llenado. Formato de seguimiento QUALDEV Proyecto Creado por: Riesgo Posición. Identificador de Riesgo. Probabilidad de ocurrencia. Impacto. Hace 1 semana. Hace 2 semanas. Hace 3 semanas. Observaciones. 1 2 3 4 5. Instructivo del formato de seguimiento QUALDEV Proyecto. Nomb re del proyecto. Creado por: Riesgo. Nomb re del autor Identificador del riesgo. 12.

(16) Posición. Identificador de Riesgo. Probabilidad de ocurrencia. Impacto. Hace 1 semana. Hace 2 semanas. Hace 3 semanas. Observacion es. 1. Identificador del riesgo. Probabilidad actual para que se presente el riesgo. Impacto actual que tiene el riesgo en caso de presentars e. Posición en la que se encontraba el riesgo hace una semana. Posición en la que se encontraba el riesgo hace dos semana. Posición en la que se encontraba el riesgo hace tres semana. Que se hizo en la semana para reducir probabilidad de ocurrencia o impacto del riesgo. 2 3 4 5. Todos los comentarios que se reciban deben de ser resumidos en un documento que contenga el nuevo orden de prioridad de los riesgos, junto con el histórico del comportamiento del riesgo a lo largo del ciclo de desarrollo, al igual que una observación en la que se indique que se está haciendo para que el riesgo no se presente y disminuya su clasificación, la cual vendrá dada por la probabilidad de ocurrencia y en segunda medida por su impacto. 3.6. Control de riesgos Esta etapa define las acciones necesarias para asegurar que el proyecto se ejecuta de acuerdo con los planes de mitigación establecidos, y para controlar los efectos adversos de los riesgos potenciales que van surgiendo. Dependiendo del desarrollo de los riesgos seleccionados se pueden tomar diferentes acciones: cerrar el riesgo, continuar el seguimiento, tomar las acciones planeadas o replanear. Se cierra el riesgo cuando se considera que el riesgo ha sido eliminado. Se continúa con el seguimiento cuando este se desarrolla de manera esperada. Se toman las acciones planeadas cuando el riesgo se presenta y es necesario activar los planes alternos definidos. Por el contrario se replantea el riesgo cuando a pesar de seguir los planes alternos, este se sigue presentando yse considera que su probabilidad de ocurrencia se hace máxima. Esta actividad se debe hacer de manera semanal, paralelo al seguimiento y debe tener por responsable al líder de proceso, basándose en los resultados del seguimiento y en los acuerdos a los que se llegue en las reuniones. En caso que haya un cambio significativo entre las reuniones de seguimiento, será el encargado de dar a conocer el procedimiento a seguir, bien sea informando al líder del grupo, para que este informe a los miembros involucrados, informando directamente a todo el grupo, o informando al responsable del plan de contingencia del riesgo para que lidere el conjunto de actividades que se habían previsto.. 13.

(17) 4. MÉTRICAS Para poder observar el comportamiento de los planes de mitigación, y poder obtener la retroalimentación necesaria con el fin de mejorar, los puntos clave del proceso a tener en cuenta deben ser: •. Evolución de la probabilidad de ocurrencia del riesgo a través de las diferentes semanas.. •. Evolución de la probabilidad de impacto durante las diferentes semanas del ciclo de desarrollo.. •. Número de riesgos incluidos después de la etapa de identificación.. •. Número de riesgos presentados, de los inicialmente identificados.. •. Número de riesgos presentados no identificados.. •. Tiempo semanal dedicado para el seguimiento de los riesgos.. 5. CONCLUSIONES Y TRABAJOS FUTUROS. Existen diferentes maneras de administrar los riesgos, y la que ha de ser utilizada depende de la evolución que tenga la empresa a implementar el proceso de administración de riesgos. Por experiencia en proyectos ágiles de desarrollo, cuando un grupo nace, la gestión de riesgos comienza con una gestión reactiva y con el paso del tiempo, después de tener definido su proceso de desarrollo, logra llegar a una gestión en la que se busca evitar la presencia de riesgos. El presente documento es de gran ayuda para aquellos grupos ágiles que ya tienen implementado su propio proceso de desarrollo y necesita se ajustado para que el impacto sobre el proceso sea mínimo, debido a que esta basado en la metodología de procesos de desarrollo descritas en el QualDev Process [1]. Sería ideal tener una herramienta de apoyo para la gestión de riesgos, debido a que esto ayudaría a incluir esta metodología dentro de la práctica de procesos del grupo. Considero que esta propuesta debería de ir acompañada de una guía de implantación al proceso que ayude a los diferentes grupos y organizaciones a introducir la gestión de riesgos dentro de los procesos de sus ciclos de vida de desarrollo. Actualmente se está empezando a validar en el proyecto changeset la 14.

(18) forma de implantar la metodología aquí propuesta y esperamos obtener muy resultados que nos permitan la retroalimentación con el fin de mejorar en el corto plazo. 6. BIBLIOGRAFÍA [1] Arboleda, Hugo y Casallas, Rubby. QualDev Process: Procesos adaptab les de desarrollo de software para proyectos ágiles. Artículo no publicado. Universidad de los Andes, Bogotá, Colombia. [2] Casallas, Rubby y Pérez Nelson. Administración de riesgos en proyectos de software. Tesis no publicada. Universidad de los Andes, Bogotá, Colombia. [3] Dictionary.com. Recuperado el 21 de octubre de 2004. De http://dictionary.reference.com/search?q=method&r=67. [4] Dictionary.com. Recuperado el 21 de octubre de 2004. De http://dictionary.reference.com/search?q=process&r=67. [5] Dictionary.com. Recuperado el 21 de octubre de 2004. De http://dictionary.reference.com/search?q=tool&r=67. [6] Humphrey, Watts. “Introduction to the team software process”. Addison-Wesley Professional. 1999 [7] Managing Risk. Recuperado el 21 de octubre de 2004, Succesful Delivery Toolkit, http://www.ogc.gov.uk/sdtoolkit/reference/deliverylifecycle/manage_risk.html. [8] Pressman, Roger. Risk analysis and management en S. Software Engineering. A practitioner’s approach. (pp 145 160). Quinta edición [9] Project Management Institute. PMBOK® Guide, Una Guía a los Fundamentos de la Dirección de Proyectos. Edición 2000 [10] Real Academia Española. Recuperado el 19 de octubre de 2004, de Diccionario de la lengua española, http://www.rae.es/. [11] Schwalbe, Kathy(2002). IT Project Management. Tercera edición. [12]Software Engineering Institute. Carnegie Mellon University. CMM - Capab ility Maturity Model®. Addison-Wesley Professional; 1995 [13] Software Engineering Institute. Recuperado el 19 de octubre de 2004, de Definition of Software Risk Management, http://www.sei.cmu.edu/programs/sepm/risk/definition.html. [14] Software Engineering Institute. Recuperado el 19 de octubre de 2004, de Risk Management FAQ, http://www.sei.cmu.edu/programs/sepm/risk/risk.faq.html#whatis.. 15.

(19) [15] Software Engineering Institute. Recuperado el 19 de octubre de 2004, de Risk Management Paradigm, http://www.sei.cmu.edu/programs/sepm/risk/paradigm.html. [16] Web WorldNet 2.0. Recuperado el 19 de octubre de 2004, de http://www.cogsci.princeton.edu/cgi-bin/webwn?stage=1&word=risk.. 16.

(20)