Análisis de riesgo

En este documento vamos a encontrar feedback respecto a los posibles riesgos de nuestro proyecto.

Semana 1

Realizar el análisis de riesgo teniendo en cuenta los posibles problemas que pueden surgir a lo largo del desarrollo de la aplicación, para encontrar formas de neutralizarlos o disminuir su impacto. Ejemplos de posibles riesgos es que aparezca un nuevo competidor, que la tecnología o la idea quede obsoleta, o que un miembro del equipo abandone el proyecto.
Identificar eventos de riesgo y establecer planes de contingencia.
Diferenciar entre problemas y riesgos, abordándolos de manera distinta.
Presentar medidas preventivas y correctivas para cada riesgo identificado.
Asegurarse de que las medidas sean claras, efectivas y aplicables en el tiempo.

Se tiene que ser cuidadoso en los riesgos y no se deben de asumir como un hecho.
Condensar la información sobre riesgos en diapositivas más concisas.
Proporcionar un resumen claro de las estrategias de mitigación para cada riesgo.
Matizar los riesgos y no ponerlos de forma general.
Se deberá hacer un seguimiento de los riesgos a lo largo del proyecto. Establecer consecuencias a incumplir el agreement.
Incluir la probabilidad de cada riesgo y la efectividad prevista de las medidas de mitigación.
Utilizar íconos o indicadores visuales para representar el estado de cada riesgo en las presentaciones.

No representar falta de usuarios piloto como riesgo, implica falta de confianza.
No hacer tan ambiguo el estudio de riesgos con iconos, no se sabe a q eu se refiere.

Para la semana del 19/03/2024 se ha pedido hablar de los riesgos, y además de los problemas que se han generado.
Se tiene que indicar cómo se van a reaccionar, qué medidas se van a tomar y si ya se está actuando en ello o cuándo se va a actuar.

Es necesario tener planes de contingencia por si algun miembro tuviera algún problema (En especial si se trata de un presentador que no pueda presentar).

Problema-Solución. ¿Cómo se mide? ¿Estamos llegando al objetivo?, debemos tener en cuenta esas preguntas a la hora de desarrollarlo.

Tener métricas y umbrales para medir si solucionamos los problemas y tener fechas. ES IMPORTANTE. IMPLICA SUSPENSO SI NO SE HACE.
Por cada riesgo o problema que se presente, debe haber acciones de consolidación, pero lo más importante es que además deben haber métricas y se deben exponer en la presentación. “Vamos a reunirnos cada 2 días” “Vamos a …” Debe haber una métrica para medir el grado de satisfacción de la medida y un umbral que mida cuando se ha solucionado.
Incluir cómo se van a medir y qué horizontes se van a poner a las métricas para resolver los problemas.
Especificar los bugs que se han detectado y de qué manera se han solucionado.
Cuando se hable de los problemas que han aparecido, reflejar de alguna manera (una tabla es lo más sencillo para que lo vean claro los profesores) que se vea: Problema – Medida – Métrica - Estado
Se debería de prever con anterioridad a padecer el problema el pasarse de las horas estipuladas en la asignatura. Si ya ha pasado no se ha tratado de manera correcta.
Si no se pueden realizar los test de carga sobre el AppEngine es conveniente buscar alternativas, aunque sea probarlo el local y extrapolar al despliegue real.