a) Clasificar cada riesgo de acorde a los siguientes tipos: 1. Riesgo de mercado 2. Riesgo estratgico 3. Riesgo de comercializacin 4.

Riesgo de direccin 5. Riesgo de presupuesto 6. Riesgo asociado al tamao del producto 7. Riesgo asociado al cliente 8. Riesgo asociado al entorno de desarrollo 9. Riesgo tecnolgico 10. Riesgo asociado a la experiencia del equipo de desarrollo

Relacin riesgos
Hacer cronogramas muy optimistas, pensando en el mundo ideal. Se omiten actividades en el cronograma que al final se tienen que hacer y terminan impactando negativamente al proyecto. La falta de conocimiento de una metodologa o algn paso necesario para la ejecucin del proyecto. La falta de un propietario o patrocinador del sistema que est involucrado al 100%. Que el contenido de la planeacin y propuesta no sea realmente definido por el equipo, sino que solo escriban lo que el cliente les dicta. Desarrolladores ineficientes (no saben analizar, no saben programar, etc) Falta de organizacin del equipo de desarrollo. Poca retroalimentacin del usuario final. Instalaciones de desarrollo no disponibles. Falta de disponibilidad de herramientas (CASE, lenguajes, SMBD, etc) Falta de conocimiento de herramientas.

4 x x

10

x x x x x x x x x x x x x x

Falta de disponibilidad de recursos de hardware. Mala eleccin de herramientas. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el proyecto. Usuarios finales que a la conclusin del proyecto quedan insatisfechos. Usuarios finales que nunca compraron la idea del proyecto y solo participaron por obligacin. No hay suficientes talleres con los usuarios finales y se hace un sistema como se cree que el usuario lo esperara pero sin su aprobacin. La disponibilidad de los usuarios finales clave es poca. El cliente insiste en involucrarse en decisiones tcnicas. El cliente quiere interfaces para las cuales no hay herramientas. El cliente no acepta el proyecto como terminado hasta que no estn todos sus requerimientos por muy complicados que estos sean. Los usuarios finales no saben explicar qu es lo que realmente requieren (y el lder no sabe cmo preguntrselos) Cambio de plataforma sobre la que se correr el software. El software requiere interactuar con alguna nueva herramienta. Desarrolladores con problemas de motivacin. Desarrolladores siempre ocupados. No hay suficiente gente para el tamao del proyecto. x x x x x x

x x x x x x x x x x x x x x x x
x x

Conflictos entre miembros de equipo. El equipo de desarrollo acostumbra trabajar en forma ineficiente. Estndares confusos en las interfaces (generados por el usuario o por el desarrollador).

x x x

b) Establecer el impacto de cada riesgo de acorde a los siguientes tipos: 1. Bajo 2. Mediano 3. Alto 4. Catastrfico

Relacin riesgos
Hacer cronogramas muy optimistas, pensando en el mundo ideal. Se omiten actividades en el cronograma que al final se tienen que hacer y terminan impactando negativamente al proyecto. La falta de conocimiento de una metodologa o algn paso necesario para la ejecucin del proyecto. La falta de un propietario o patrocinador del sistema que est involucrado al 100%. Que el contenido de la planeacin y propuesta no sea realmente definido por el equipo, sino que solo escriban lo que el cliente les dicta. Desarrolladores ineficientes (no saben analizar, no saben programar, etc) Falta de organizacin del equipo de desarrollo. Poca retroalimentacin del usuario final. Instalaciones de desarrollo no disponibles. Falta de disponibilidad de herramientas (CASE, lenguajes, SMBD, etc) Falta de conocimiento de herramientas. Falta de disponibilidad de recursos de hardware. Mala eleccin de herramientas. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el proyecto. Usuarios finales que a la conclusin del proyecto quedan insatisfechos. Usuarios finales que nunca compraron la idea del proyecto y solo participaron por obligacin.

1 x x

2 x

x x x x x x x x x x x x x

No hay suficientes talleres con los usuarios finales y se hace un sistema como se cree que el usuario lo esperara pero sin su aprobacin. La disponibilidad de los usuarios finales clave es poca. El cliente insiste en involucrarse en decisiones tcnicas. El cliente quiere interfaces para las cuales no hay herramientas. El cliente no acepta el proyecto como terminado hasta que no estn todos sus requerimientos por muy complicados que estos sean. Los usuarios finales no saben explicar qu es lo que realmente requieren (y el lder no sabe cmo preguntrselos) Cambio de plataforma sobre la que se correr el software. El software requiere interactuar con alguna nueva herramienta. Desarrolladores con problemas de motivacin. Desarrolladores siempre ocupados. No hay suficiente gente para el tamao del proyecto. Conflictos entre miembros de equipo. El equipo de desarrollo acostumbra trabajar en forma ineficiente. Estndares confusos en las interfaces (generados por el usuario o por el desarrollador).

x x x x x x
x x x x x x x x

c) Formular una estrategia para afrontar el riesgo (En un texto corto). 1. Hacer cronogramas muy optimistas, pensando en el mundo ideal. Buscar juicio de expertos y tener en conocimiento que la duracin aconsejable de una actividad: entre 1 y 8 semanas.

2. Se omiten actividades en el cronograma que al final se tienen que hacer y terminan impactando negativamente al proyecto.

Tener el desglose WBS del proyecto para ver el alcance de cada proceso y gestionar c/u.

3. La falta de conocimiento de una metodologa o algn paso necesario para la ejecucin del proyecto. Organizar cursos de capacitacin de la metodologa alcanzada para la ejecucin del proyecto. 4. Que el contenido de la planeacin y propuesta no sea realmente definido por el equipo, sino que solo escriban lo que el cliente les dicta.

Preparar un documento breve para la direccin de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio 5. Desarrolladores ineficientes (no saben analizar, no saben programar, etc) Organizar cursos de capacitacin para el equipo, investigar la posibilidad de contratar una empresa especialista al tema.

6. Falta de organizacin del equipo de desarrollo. Establecer un cuadro de funcionalidades de cada uno del equipo y brindar sugerencias de responsabilidades y cargos dentro de un proyecto segn a la habilidades de cada uno.

7. Poca retroalimentacin del usuario final. Comunicar los avances del proyecto continuamente y dar a conocer que requerimientos hacen falta en el sistema.

8. Instalaciones de desarrollo no disponibles. Tener un presupuesto abarcado exclusivamente a las instalaciones de desarrollo.

9. Falta de disponibilidad de herramientas (CASE, lenguajes, SMBD, etc) Contar con un inventario de activos informticos para saber la disponibilidad de las herramientas usando metodologa ITIL.

10. Falta de conocimiento de herramientas.

Investigar la posibilidad de contratar una empresa especialista al tema o capacitacin del personal de la herramienta a usar. 11. Falta de disponibilidad de recursos de hardware. Promover la existencia de informes o documentos sobre problemas tecnolgicos durante el proyecto

12. Mala eleccin de herramientas.

Investigar cuadros comparativos de tecnologas que sirvan a proyecto de software como el Gardner 13. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el proyecto. Rastrear la informacin para valorar el impacto de los requerimientos, maximizar la informacin oculta en ellos 14. Usuarios finales que a la conclusin del proyecto quedan insatisfechos.

Emplear que el procesos desarrollo del software explicar detalladamente con estrategias de presentacin de diagramas de requerimientos o flujos sobre el funcionamiento del sistemas o tambin emplear utilizar un lenguaje grfico. 15. Usuarios finales que nunca compraron la idea del proyecto y solo participaron por obligacin. Alertar al cliente de las dificultades potenciales y las posibilidades de retraso 16. No hay suficientes talleres con los usuarios finales y se hace un sistema como se cree que el usuario lo esperara pero sin su aprobacin.

Buscar otro medio donde talleres tales como enviar mensajes a los correos indicando que lke gustara que el sistema funcione. Plantear el uso del "Diseo Rpido de Aplicaciones". 17. La disponibilidad de los usuarios finales clave es poca. Usar mtodos como encuestas por web para conocer el valor de los requerimientos del sistema.

18. El cliente insiste en involucrarse en decisiones tcnicas. Establecer en el contrato que las decisiones tcnicas asume el gestor de proyectos. 19. El cliente quiere interfaces para las cuales no hay herramientas. Dar conocer el alcance que empleara el sistema al usuario explicando cuales son los factores de usabilidad en las interfaces. 20. El cliente no acepta el proyecto como terminado hasta que no estn todos sus requerimientos por muy complicados que estos sean. Brindar informacin del sistema interactivo y porque no se cumpla sus requerimiento segn los estipulado en el contrato. 21. Los usuarios finales no saben explicar qu es lo que realmente requieren (y el lder no sabe cmo preguntrselos) Buscar informacin para valorar el impacto de los requerimientos, alcanzando maximizar la informacin oculta en ellos Para ver que es lo que realmente quieren para su sistema.

22. Cambio de plataforma sobre la que se correr el software. Establecer definiciones claras de la plataforma usar durante el anlisis de requerimientos. 23. El software requiere interactuar con alguna nueva herramienta. Gestionar el cambio mediante las ideas del equipo y buscar las vulnerabilidades de la herramienta a usar.

24. Desarrolladores con problemas de motivacin.

Buscar al equipo de trabajo que interactuar en grupos de trabajo, en reuniones, en sesiones participativas y en definitiva en las tareas del da a da y dar conocer el logro del proyecto. 25. Desarrolladores siempre ocupados. Dar a conocer que el equipo el proyecto es de ellos y no de "la Direccin" o de "los consultores". 26. No hay suficiente gente para el tamao del proyecto. Buscar contrataciones temporales o especficas del personal que se usara por un periodo. 27. Conflictos entre miembros de equipo. Realizar una retroalimentacin con el uso de juegos de roles y ver las posiciones diferentes de c/u para ver las deficiencias del equipo. 28. El equipo de desarrollo acostumbra trabajar en forma ineficiente. Generar que el equipo de trabajo debe funcionar en grupos de trabajo, en reuniones las cuales reportan al final el desempeo por cada grupo y reuniones generales. 29. Estndares confusos en las interfaces (generados por el usuario o por el desarrollador). Conocer detalladamente sobre la usabilidad y ergonoma en las interfaces o si es posible buscar un experto en colores lo cual ayudara a enfocar estndares de interfaces.