Riesgos comunes en los proyectos de software.

(Seleccionar 05 riesgos de la lista proporcionada líneas

abajo. Completar una tabla con el siguiente análisis:)

Riesgo % Probabilidad Impacto Estrategia

Desarrolladores Proceso de
ineficientes (no selección de
saben analizar, no 25% Alto personal con
saben programar, pruebas de
etc.) conocimiento
Cambio de Desde un principio
plataforma sobre la es hacer que la
25% Medio
que se correrá el aplicación sea
software. multiplataforma.
Usuarios finales
que insisten en Reprogramar
nuevos fechas de entrega
75% Medio
requerimientos a lo para nuevos
largo de todo el requerimientos.
proyecto.
El cliente no
acepta el proyecto
como terminado Buscar
hasta que no estén Asesoramiento de
75% Alto
todos sus Profesional más
requerimientos por Capacitado
muy complicados
que estos sean.
Contratar
Desarrolladores
Practicantes para
"siempre 25% Medio
desarrollo de
ocupados".
procesos simples
Dónde:
Riesgo: Es la descripción textual del riesgo proyectado, en un texto corto.
%Probabilidad: La probabilidad en porcentaje de que el riesgo ocurra.
Impacto: El impacto asociado al riesgo (Alto, Medio, Bajo)
Estrategia: ¿Cómo se afrontará el riesgo cuando ocurra? (En un texto corto)

Lista de Riesgos comunes en los Proyectos de Software:

1. Hacer cronogramas muy optimistas, pensando en "el mundo ideal".

2. Se omiten actividades en el cronograma que al final se tienen que hacer y
terminan impactando negativamente al proyecto.
3. La falta de conocimiento de una metodología o algún paso necesario para la
ejecución del proyecto.
4. La falta de un propietario o patrocinador del sistema que esté involucrado al
100%.
5. Que el contenido de la planeación y propuesta no sea realmente definido por
el equipo, sino que solo escriban lo que el cliente les dicta.
6. Desarrolladores ineficientes (no saben analizar, no saben programar, etc.)
7. Falta de organización del equipo de desarrollo.
8. Poca retroalimentación del usuario final.
9. Instalaciones de desarrollo no disponibles.
10. Falta de disponibilidad de herramientas (CASE, lenguajes, SMBD, etc)
11. Falta de conocimiento de herramientas.
12. Falta de disponibilidad de recursos de hardware.
13. Mala elección de herramientas.
14. Usuarios finales que insisten en nuevos requerimientos a lo largo de todo el
proyecto.
15. Usuarios finales que a la conclusión del proyecto quedan insatisfechos.
16. Usuarios finales que nunca "compraron" la idea del proyecto y solo
participaron por obligación.
17. No hay suficientes talleres con los usuarios finales y se hace un sistema como se
cree que el usuario lo esperaría pero sin su aprobación.
18. La disponibilidad de los usuarios finales clave es poca.
19. El cliente insiste en involucrarse en decisiones técnicas.
20. El cliente quiere interfaces para las cuales no hay herramientas.
21. El cliente no acepta el proyecto como terminado hasta que no estén todos sus
requerimientos por muy complicados que estos sean.
22. Los usuarios finales no saben explicar qué es lo que realmente requieren (y el
líder no sabe cómo preguntárselos)
23. Cambio de plataforma sobre la que se correrá el software.
24. El software requiere interactuar con alguna nueva herramienta.
25. Desarrolladores con problemas de motivación.
26. Desarrolladores "siempre ocupados".
27. No hay suficiente gente para el tamaño del proyecto.
28. Conflictos entre miembros de equipo.
29. El equipo de desarrollo acostumbra trabajar en forma ineficiente.
30. Estándares confusos en las interfaces (generados por el usuario o por el
desarrollador).