Ingeniería del Software

EMERSOFT
Análisis de Riesgos
Versión 1.0
EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

Historial de Revisiones

Fecha Versión Descripción Autor

Ingeniería de Software Página 2 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

Índice
1 Introducción .....................................................................................................................................6
1.1 Propósito ..................................................................................................................................6
1.2 Ámbito .....................................................................................................................................6
1.3 Definiciones, Acrónimos y Abreviaturas .................................................................................6
1.4 Referencias ...............................................................................................................................6
1.5 Referencias bibilográficas: ......................................................................................................6
1.6 Perspectiva general ..................................................................................................................6
2 Riesgos ............................................................................................................................................7
2.1 R01- Cambios en los requisitos................................................................................................7
2.2 R02- Bajas en el equipo de desarrollo .....................................................................................8
2.3 R03- Falta de experiencia en tareas de planificación...............................................................9
2.4 R04- Diseño erróneo. ...............................................................................................................9
2.5 R05- Pérdidas de datos. .........................................................................................................10
2.6 R-06 Errores producidos por la mezcla de versiones. ...........................................................10
2.7 R-07 Errores producidos por software de terceros. ...............................................................11
2.8 R-08 No cumplir con las fechas de entrega. ..........................................................................12
2.9 R-09 Problema con el repositorio. .........................................................................................12
2.10 R-10 Incompatibilidad con el servidor en fase de transición. ..............................................13
2.11 R-11 Fallo en el servidor en fase de transición. ...................................................................13

Ingeniería de Software Página 3 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

1 Introducción

1.1 Propósito
Este documento pretende listar los posibles riesgos encontrados en la etapa inicial de planificación
del proyecto EMERSOFT . Además de la identificación de dichos riesgos se proponen planes de
contingencia para evitarlos o al menos reducir su efecto.

1.2 Ámbito
El ámbito de este documento abarca todas las fases de nuestro proyecto. Es redactado inicialmente
pero deberá ser revisado y modificado (en caso de ser necesario) a lo largo del desarrollo del
proyecto.

1.3 Definiciones, Acrónimos y Abreviaturas

Véase el Glosario.

1.4 Referencias
En este documento se hace referencia a los siguientes documentos:
• Glosario.pdf
• Plan_desarrollo_software.pdf

1.5 Referencias bibilográficas:

• Booch, Grady; Jacobson, Ivar; Rumbaugh, James. "El Proceso Unificado de Desarrollo
Software". PEARSON Addison Wesley, 2005.

• http://www.yoopeedoo.org/upedu/. Unified Process for EDUcation [UPEDU].

1.6 Perspectiva general

En este documento vamos a encontrar un listado de riegos identificados además de posibles planes
de contingencia.

Ingeniería de Software Página 4 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

2 Riesgos

Todos los riesgos identificados y analizados cada uno en los siguientes apartados:

• Magnitud. Estimación de la importancia de sus efectos en caso de que se convierta en un

hecho. Se evalúa como muy baja, baja, media, alta, muy alta o catastrófica.
• Descripción. Breve descripción textual.
• Impacto. Descripción textual de los efectos sobre el proyecto de la transformación del
riesgo
en un hecho.
• Indicadores. Magnitudes a observar para intuir la aparición del riesgo.
• Plan de acción. Medidas a tomar en el proyecto para evitar la aparición del riesgo o
minimizar su futuro impacto, aplicadas antes de que el riesgo se convierta en un hecho.
• Plan de contingencia. Medidas a tomar en el proyecto una vez que el riesgo se haya
transformado en un hecho.

2.1 R01- Cambios en los requisitos

2.1.1 Magnitud.
Será variable dependiendo en la fase que nos encontremos, concretamente:

Inicio: baja.
Elaboración: media.
Construcción: alta.
Transición: muy alta.

2.1.1 Descripción.
El cliente puede cambiar algún requisito o simplemente añadirlo en cualquier momento, debido a
que no tenga claro las funcionalidades de la aplicación, se le ocurran nuevas ideas o descubra que
hay alguno erróneo.
Se supone que la mayoría de estos cambios se producirán en la fases de inicio o elaboración, pero
en ningún caso hay que descartarlas en fases más avanzadas.

2.1.1 Impacto.
Tiene un impacto alto ya que afectará a toda la documentación desarrollada hasta el momento. Por
esta razón, el impacto será mucho mayor cuanto más avanzada sea la fase, hasta el punto que habrá
algún momento, dependiendo del cambio o adhesión, en el que será inasumible.

2.1.1 Indicadores.
El cliente informa directamente.

Ingeniería de Software Página 5 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

2.1.1 Plan de acción.

Realizar reuniones frecuentes con el cliente. Inicialmente muy frecuentes e ir descendiendo según
vamos avanzando a lo largo de nuestras fases.
Dejar claro al cliente desde el principio que lo requisitos que elija tienen que ser definitivos por lo
que tiene que estar muy seguro de ellos.

2.1.1 Plan de contingencia.

Tendremos dos opciones dependiendo de la fase en la que nos encontremos y de la magnitud del
cambio.
Por un lado, si estamos en una fase inicial, se aceptará el cambio sin problemas y por tanto habrá
que revisar todo lo generado hasta el momento.
Por otro lado, si estamos en un fase más avanzada, habrá que valorar la magnitud del cambio y para
ello habrá que hacer una estimación del trabajo necesario para adoptarlo, es decir, horas de trabajo.
En caso de decidir aceptar el cambio habrá que revisar todo lo generado hasta el momento. En caso
contrario habrá que hablar con el cliente y decirle que no es posible dicho cambio de requisito.
En caso de que el cliente piense que el cambio es vital y el coste es muy alto, habrá que replanificar
todo el proyecto, lo que se podría convertir tanto en mayor tiempo como en mayores recursos.

2.2 R02- Bajas en el equipo de desarrollo

2.2.1 Magnitud.
Alta, cuando afecta a un solo miembro. Muy alta, si afecta a más de uno.

2.2.1 Descripción.
Algún miembro del proyecto no se encuentra disponible por cualquier motivo externo
(enfermedad, lesión, etc) mientras tiene actividades planificadas.
Otro motivo de la baja puede ser porque uno de los miembros del grupo encuentre trabajo, por lo
que su rendimiento bajaría.

2.2.1 Impacto.
Puede provocar un descenso en la calidad del producto, ya que es imposible buscar un sustituto y la
fecha de entrega no se puede mover.

2.2.1 Indicadores.
Para este tipo de riesgos no hay ninguno ya que es impredecible.

2.2.1 Plan de acción.

Tratar de cumplir las metas y objetivos antes de lo estimado en la planificación siempre que sea
posible, para que un posible retraso no suponga nada importante.

2.2.1 Plan de contingencia.

Se intentará cubrir por el resto del equipo el trabajo de las personas que han causado baja, de esta

Ingeniería de Software Página 6 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

forma, tendremos que reajustar la planificación.

2.3 R03- Falta de experiencia en tareas de planificación.

2.3.1 Magnitud.
Media - Alta.

2.3.2 Descripción.
Todos los miembros del grupo se enfrentan por primera vez a una planificación de este tipo.

2.3.3 Impacto.
Puesto que la planificación guía todo el desarrollo del proyecto, el impacto puede incidir
directamente sobre los resultados obtenidos.
Destacar que mediante el uso de iteraciones se puede reducir este impacto.

2.3.4 Indicadores.
Diferencias entre el desarrollo real del proyecto y la planificación estimada.

2.3.5 Plan de acción.

El uso de UPEDU como proceso de desarrollo. Realización de reuniones entre los miembros del
proyecto para la evaluación de la marcha del proyecto y consultas al tutor.

2.3.6 Plan de contingencia.

Se observarán las diferencias entre la planificación de cada iteración y el informe de seguimiento de
su ejecución, analizando las causas de sus diferencias para tratar de detectar y corregir errores de
planificación en las iteraciones posteriores.

2.4 R04- Diseño erróneo.

2.4.1 Magnitud.
Baja en Elaboración, alta en Construcción.

2.4.2 Descripción.
El diseño del sistema resulta inadecuado. Al realizar actividades de implementación puede
encontrase que el diseño carece del suficiente nivel de detalle o está mal enfocado, bien por la
naturaleza del problema, o bien por restricciones de uso impuestas por tecnologías de terceros.

2.4.3 Impacto.
Puede introducir retrasos además de poderse ver afectado el resultado final.

Ingeniería de Software Página 7 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

2.4.4 Indicadores.
La arquitectura no cumple las expectativas. Se complica la implementación.

2.4.5 Plan de acción.

Se realizará durante la fase de elaboración un prototipo para comprobar que la arquitectura es la
adecuada, en caso de no serlo se modificará el diseño.

2.4.6 Plan de contingencia.

Si el riesgo se convierte en hecho durante la fase de Elaboración, se revisará y modificará la
documentación de diseño afectada.
Si lo hace durante la fase de construcción, se estudiará una solución acorde a los tiempos de plazo
de que se dispone.
La planificación se reajustará si fuera necesario.

2.5 R05- Pérdidas de datos.

2.5.1 Magnitud.
Alta.

2.5.2 Descripción.
De alguna manera, se produce la pérdida de datos.

2.5.3 Impacto.
Variable, puede suponer una catástrofe o un simple retraso.

2.5.4 Indicadores.
Ninguno.

2.5.5 Plan de acción.

Se usará un repositorio para el control de versiones. Se realizarán copias de seguridad en los
ordenadores personales de cada uno de los miembros del equipo de desarrollo.

2.5.6 Plan de contingencia.

Recuperar la versión anterior a la versión perdida y tratar de reconstruirla.

2.6 R-06 Errores producidos por la mezcla de versiones.

2.6.1 Magnitud.
M ed i a.

Ingeniería de Software Página 8 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

2.6.2 Descripción.
Aparecen errores debido a una mala unificación de versiones entre archivos que han sido
modificados por varias personas del grupo durante un mismo periodo de tiempo.

2.6.3 Impacto.
Si se producen repetidamente este tipo de errores se podría llegar a alargar el desarrollo del
proyecto, lo cual complica el cumplimiento de la planificación.

2.6.4 Indicadores.
Algo que se suponía que funcionaba resulta que no funciona.

2.6.5 Plan de acción.

Bloquear los archivos cuando un integrante del grupo los esté usando.

2.6.6 Plan de contingencia.

En caso de detectar un problema de este tipo, habrá que volver a una versión anterior y volver a
mezclarlos estando presentes los miembros del grupo que hallan modificado dicho archivo.

2.7 R-07 Errores producidos por software de terceros.

2.7.1 Magnitud.
Variable, aunque magnitud media de promedio.

2.7.2 Descripción.
Aparecen errores en la implementación del sistema debido al software empleado para el desarrollo
del mismo (servidor web, sistema gestor de bases de datos, librerías utilizadas, etc…).

2.7.3 Impacto.
Mayor dificultad de corrección o control de los errores, al ser provocados por una causa no
esperada. Si el error fuera grave, podría ser necesario sustituir el software por otra versión u otro
producto, lo que incidiría negativamente sobre el tiempo empleado en la actividad en cuestión.

2.7.4 Indicadores.
Origen de un error en la implementación del sistema.

2.7.5 Plan de acción.

Estudio de los elementos que van a componer el sistema para detector posibles incompatibilidades
o errores.

2.7.6 Plan de contingencia.

Ingeniería de Software Página 9 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

En caso de necesidad, se valorará la posibilidad de cambiar el software problemático por una

versión posterior o por otro software equivalente.

2.8 R-08 No cumplir con las fechas de entrega.

2.8.1 Magnitud.
M ed i a

2.8.2 Descripción.
Debido a que varios miembros del grupo trabajan tiempo parcial, aunque esto ha sido tenido en
cuenta a la hora de hacer la planificación, puede que se intensifique su trabajo externo y se vea
comprometida su entrega a nuestro proyecto, por lo que podrían verse comprometidas las fechas de
entrega.

2.8.3 Impacto.
Puesto que las fechas de entrega son inamovibles, que hallan un retraso grave provocaría un
proyecto inacabado, por lo tanto es un impacto directo sobre los resultados del desarrollo.

2.8.4 Indicadores.
Incumplimiento de las tareas asignadas por la planificación para algún miembro del grupo.

2.8.5 Plan de acción.

Estar continuamente comparando lo realizado con la planificación, en el momento que se detecte
un retraso, intentar reajustarlo.

2.8.6 Plan de contingencia.

En caso de necesidad, se valorará la posibilidad de reajustar la planificación dando más trabajo a los
integrantes del grupo que no tengan trabajos externos.

2.9 R-09 Problema con el repositorio.

2.9.1 Magnitud.
M ed i a.

2.9.2 Descripción.
Podemos tener problemas con el repositorio ya que es externo a nosotros.

2.9.3 Impacto.
Si fallara habría que conseguir una versión estable mediante los archivos locales que cada uno tenga
en sus ordenadores personales.

Ingeniería de Software Página 10 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

2.9.4 Indicadores.
No hay, es impredecible.

2.9.5 Plan de acción.

Utilizar un repositorio que nos dé la máxima confianza. Por ejemplo, Google Code.

2.9.6 Plan de contingencia.

En caso de necesidad, se valorará la posibilidad de cambiar a otro repositorio.

2.10 R-10 Incompatibilidad con el servidor en fase de transición.

2.10.1 Magnitud.
Alta

2.10.2 Descripción.
Aparición de errores en la fase de transición a jair.

2.10.3 Impacto.
Puede provocar retrasos en las fechas en caso de aparecer muchos errores de incompatibilidad ya
que generaría trabajo extra.

2.10.4 Indicadores.
Algunas cosas que funcionaban en local no funcionan en el servidor.

2.10.5 Plan de acción.

Utilizar las herramientas en las mismas versiones que están instaladas en el servidor y configurar en
la medida de lo posibles todo del mismo modo.
Probar los prototipos de forma general en el servidor aunque genere un poco más de trabajo.

2.10.6 Plan de contingencia.

Repartir los nuevos problemas producidos por la transición.

2.11 R-11 Fallo en el servidor en fase de transición.

2.11.1 Magnitud.
Alta.

2.11.2 Descripción.

Ingeniería de Software Página 11 de 12

EMERSOFT Versión: 1.0
Análisis de Riesgos Fecha: 28 de noviembre de 2010
Análisis de Riesgos.odt

Puede ocurrir que el servidor no esté operativo durante la fase de transición que hemos planificado.

2.11.3 Impacto.
Retraso indefinido de la entrega final.

2.11.4 Indicadores.
No hay.

2.11.5 Plan de acción.

No es posible.

2.11.6 Plan de contingencia.

No hay.

Ingeniería de Software Página 12 de 12