Administracion de proyectos de software.
Francisco CuencaTarea7 de Marzo de 2016
3.506 Palabras (15 Páginas)416 Visitas
Proyecto APS 2015
Análisis de riesgos - Plan RSGR - Análisis de Requerimientos
Agustín Orge Queiruga, lu: 85538
Francisco Cuenca, lu: 94294
Contenido
Documento de Análisis de Riesgos 2
Riesgos 2
Baja disponibilidad de la Base de Datos de la UNS 2
Pérdida de algún integrante del equipo 2
Incumplimiento de fecha de entrega 2
Cambios en la interfaz de la Base de Datos de la UNS 2
Subestimación de cantidad de usuarios 2
Consultas con información errónea 2
Tabla de riesgos 3-4
Plan de RSGR (Reducción, Supervisión y Gestión del Riesgo) 5
Baja disponibilidad de la Base de Datos de la UNS 5
Pérdida de algún integrante del equipo 5
Cambios en la interfaz de la Base de Datos de la UNS 5
Especificación de requerimientos 6
Plantilla de requerimientos 6
Requerimientos funcionales 7-18
Requerimientos no funcionales 19-21
Atributos críticos 21
Glosario 22
Documento de Análisis de Riesgos
Antes de comenzar el desarrollo del proyecto se deben analizar los posibles problemas que pueden ocurrir en el transcurso del mismo. Se ha decidido tomar una actitud proactiva por lo que se identificaran los riesgos potenciales, se valorará su probabilidad e impacto y se priorizan de acuerdo a su importancia. A partir de la importancia de los mismos se establecerá un plan para controlarlos.
A continuación se listaran los riesgos encontrados junto con la descripción correspondiente de cada uno y lo que nos llevó a detectar los mismos.
Riesgos
- Baja disponibilidad de la Base de Datos de la UNS: Para acceder la información sobre los alumnos, aulas, profesores, etc. es necesario compartir información entre el sistema que administra los datos para la UNS y la aplicación AppUNS. Existe el riesgo, que la base de datos de la UNS no soporte el flujo de datos entre ellos.
- Pérdida de algún integrante del equipo: Es posible que algún integrante del equipo de programadores abandone el proyecto, ya sea por decisión propia o por alguna circunstancia que no le permita continuar con el mismo.
- Incumplimiento de fecha de entrega: dado que la versión final del producto debe ser entregada obligatoriamente a fin de año no es posible renegociar con el cliente una nueva fecha en caso de retrasos. Si no se cumplen con los deadlines en el tiempo previsto el proyecto no va a ser aceptado.
- Cambios en la interfaz de la Base de Datos de la UNS: Se pueden producir cambios en la interfaz para consultas de la base de datos de la uns debido a mantenimiento del sistema.
- Subestimación de cantidad de usuarios: Las estimaciones de la cantidad de usuarios que utilizaran el sistema pueden ser desacertadas dando como resultado un colapso en la base de datos propia.
- Consultas con información errónea: Debido a que el sistema utilizará sistemas externos para obtener la información que se va a mostrar, no se tiene control sobre el contenido. Puede darse el caso que haya información errónea.
Tabla de riesgos
Para analizar los riesgos es importante medir el nivel de incertidumbre y el impacto asociado a cada riesgo. El nivel de incertidumbre es la probabilidad de que el hecho descrito en el riesgo ocurra, mientras que el impacto es cómo afecta el riesgo al producto.
El impacto de cada riesgo se divide en cuatro tipos:
- Catastrófico (1)
- Crítico (2)
- Marginal (3)
- Despreciable (4)
A continuación se establecerá una escala que refleje la probabilidad del riesgo, se definirán sus consecuencias, se estimará su impacto en el proceso y en el producto y se construirá una Tabla de Riesgos:
Id | Riesgos | Categoría | Probabilidad | Impacto | Orden | Plan RSGR |
11 | Pérdida de algún integrante del equipo | PE | 50% | 2 (Crítico) | 1.5 | [pic 1] |
2 | Baja disponibilidad de la BD de la UNS | TE | 25% | 1 (Catastrófico) | 1 | [pic 2] |
3 | Cambios en la interfaz de la BD de la UNS | TE | 25% | 1 (Catastrófico) | 1 | [pic 3] |
4 | Incumplimiento de fecha de entrega | NE | 20% | 1 (Catastrófico) | 0.8 | [pic 4] |
5 | Subestimación cantidad de usuarios | TA | 15% | 2 (Crítico) | 0.45 | [pic 5] |
6 | Consultas con información errónea | EX | 10% | 3(Marginal) | 0.2 | [pic 6] |
Referencias:
- Categoría:
- TA: Tamaño.
- NE: Negocio.
- DE: Desarrollo.
- PE: Personal.
- TE: Técnico.
- EX: Externos.
Se ha utilizado una fórmula para determinar el orden de los riesgos. El orden determina la necesidad de armar un plan de control para dicho riesgo. La fórmula utilizado para determinar el orden es la siguiente:
Orden = (Probabilidad * (5 - Impacto) ) / 100
Dicha fórmula genera un índice, a partir del mismo se establecerá un orden para seleccionar qué riesgos formarán parte del plan de control de riesgos. Decidimos que se implementarán planes para los 3 primeros para que la administración de riesgos no sobrecargue el trabajo del proyecto.
Plan de RSGR (Reducción, Supervisión y Gestión del Riesgo)
Cuando el orden de los riesgos supera la línea de corte de debe de desarrollar un plan de reducción, supervisión y gestión del riesgo. Las tareas están encaminadas a reducir las posibilidades de que los riesgos ocurran. A medida que el proyecto avanza se debe supervisar el riesgo. La gestión y los planes asumen que los esfuerzos de reducción han fracasado y el riesgo se ha convertido en realidad.
Baja disponibilidad de la Base de Datos de la UNS
- Reducción: tener una comunicación constante con los administradores del sistema de Base de Datos de la UNS, y realizar una planificación sobre el tráfico extra que demandará el uso de esta aplicación.
- Supervisión: verificar que exista una estrecha comunicación entre los desarrolladores de AppUNS y los administradores de la Base de Datos de la UNS.
- Gestión: comunicarse con la administración informando el problema y tratar de llegar a una solución que sea productiva para ambas partes.
Pérdida de algún integrante del equipo
- Reducción: Tener una comunicación constante con los desarrolladores y realizar una planificación adecuada sobre las tareas a realizar a lo largo del proyecto intentando que el trabajo de los desarrolladores sea lo más simple y adecuado a sus tiempos.
Generar documentación clara y precisa de todo el desarrollo.
Tener backup de personal en los componentes más críticos del sistema.
- Supervisión: tener una comunicación constante con los desarrolladores para tener conocimiento de la situación en la que se encuentran en cada momento.
Controlar la documentación.
Controlar la asignación de tareas.
- Gestión: comunicarse con la administración informando el problema y tratar de llegar a un acuerdo que se sea conveniente para las partes y lograr así finalizar el proyecto en tiempo y forma.
Reasignacion de personal a las tareas que lo requieran.
Evaluar si es necesario la contratación de un nuevo recurso
Cambios en la interfaz de la Base de Datos de la UNS
- Reducción: tener una comunicación constante con los administradores del sistema de Base de Datos de la UNS. De esta manera se está al tanto de posibles modificaciones futuras.
- Supervisión: monitorear los resultados de las consultas realizadas para determinar si la interfaz sigue siendo válida.
- Gestión: adaptación de los componentes que interactúan con las base de datos de la UNS para adecuarse a los cambios.
Especificación de requerimientos
Un requerimiento es una característica deseada del sistema que debe satisfacerse con el fin de que el problema del cliente sea adecuadamente solucionado. Es de suma importancia que sean claros y precisos. Para la definición de los requerimientos se utilizaron los siguientes templetes:
...