Grupo Lermi

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB>

Risk List (Identificación y Gestión de Riesgos) Versión <1.2>

Integrantes

Richard Alexander Ortiz Salinas.

Cristian Raúl Pineda Rodríguez.

Manuel Felipe Echevarría Orozco.

Iván Fernando López Casanova.

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 2

Historial de Revisiones Fecha Versión Descripción Autor

<21/08/11> <1.0> <Documento que establece el listado inicial

de riesgos>

<Grupo Lermi>

<30/08/11> <1.1> <Documento que establece el listado inicial

de riesgos>

<Grupo Lermi>

<20/09/11> <1.2> <Documento que establece el listado inicial

de riesgos>

<Grupo Lermi>

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 3

Tabla de Contenido

1. Introducción 4

1.1 Propósito 4 1.2 Alcance 4 1.3 Definiciones, Acrónimos y Abreviaturas 4

2. Riesgos de Planificación 4

2.1 Identificación 4 2.1.1 Listado de riesgos 4

2.2 Estimación 6 2.2.1 Análisis y Priorización 6

3. Planificación de Respuestas 10

4. Fuentes 10

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 4

Risk List (Identificación y Gestión de Riesgos)

1. Introducción

La importancia de realizar una adecuada gestión de riesgos en los proyectos software, influye en el normal

desarrollo del proyecto. La toma de decisiones a tiempo puede significar un ahorro significativo de recursos

y tiempo en el propósito a desarrollar.

1.1 Propósito

El propósito de este documento es identificar, estudiar y eliminar las fuentes de riesgo antes de que

empiecen a amenazar la finalización satisfactoria de este proyecto de desarrollo de software.

1.2 Alcance

Este documento define el listado de riesgos y proporciona herramientas para su evaluación y calificación.

1.3 Definiciones, Acrónimos y Abreviaturas

Ver Documento Glosario del Proyecto.

.

2. Riesgos de Planificación

2.1 Identificación

Los riesgos potenciales que pueden ocurrir en el proyecto. Los más habituales (aunque no de obligada

aparición) en proyectos software son los mostrados en la tabla siguiente:

– Cambio de requisitos

– Meticulosidad en requerimientos o de los desarrolladores

– Escatimar en la calidad

– Planificaciones demasiado optimistas

– Diseño inadecuado

– Síndrome de la panacea (“esta herramienta ahorrará la mitad del trabajo”)

– Desarrollo orientado a la investigación (proyectos muy novedosos, más propios de investigación que de

desarrollo)

– Personal mediocre

– Errores en la contratación

– Diferencias con los clientes

2.1.1 Listado de riesgos

Este listado se construye a partir de información basada en la poca experiencia en procesos de desarrollo de

los integrantes del grupo. Teniendo en cuenta que es prácticamente imposible tener una lista que incluye

todos los posibles riesgos en un proyecto software. Se resuelve utilizando la lista como punto de partida,

pero permitiendo después incluir nuevos riesgos específicos del proyecto.

2.1.1.1 Elaboración de la Planificación

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 5

a) No se puede construir un producto de tal envergadura en el tiempo asignado.

b) La reestimación debida a un retraso en la planificación es demasiado optimista o ignora la

experiencia de los integrantes del proyecto.

c) La presión excesiva en la planificación reduce la productividad.

d) Un retraso en una tarea produce retrasos en cascada en las tareas dependientes.

e) Las áreas desconocidas del producto llevan más tiempo del esperado en el diseño y en la

implementación.

2.1.1.2 Organización y Gestión

a) El tamaño reducido de la plantilla reduce la capacidad del equipo.

b) La estructura inadecuada de un equipo reduce la productividad.

2.1.1.3 Ambiente/Infraestructura de Desarrollo

a) Las herramientas de desarrollo no funcionan como se esperaba; el personal de desarrollo

Necesita tiempo para resolverlo o adaptarse a las nuevas herramientas.

b) La curva de aprendizaje para la nueva herramienta de desarrollo es más larga de lo esperado.

2.1.1.4 Usuarios Finales

a) En el último momento, a los usuarios finales no les gusta el producto, por lo que hay que volver a

diseñarlo y a construirlo.

2.1.1.5 Cliente

a) El cliente no acepta el software entregado, incluso aunque cumpla todas sus especificaciones.

b) El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar.

2.1.1.6 Requisitos

a) Los requisitos no se han definido correctamente. y su redefinición aumenta el ámbito del proyecto.

b) Las partes del proyecto que se no se han especificado claramente consumen más tiempo del

esperado.

2.1.1.7 Producto

a) El desarrollo de funciones software erróneas requiere volver a diseñarlas y a implementarlas.

b) El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla y a implementarla.

c) El desarrollo de funciones software innecesarias alarga la planificación.

d) Los requisitos para crear interfaces con otros sistemas, otros sistemas complejos, u otros sistemas

que no están bajo el control del equipo de desarrollo suponen un diseño, implementación y prueba

no previstos.

e) El trabajo con un entorno software desconocido causa problemas no previstos.

2.1.1.8 Personal

a) Los miembros del equipo no se implican en el proyecto, y por lo tanto no alcanzan el nivel de

rendimiento deseado.

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 6

b) La falta de motivación y de moral reduce la productividad.

c) La falta de la especialización necesaria aumenta los defectos y la necesidad de repetir el trabajo.

d) El personal necesita un tiempo extra para acostumbrarse a trabajar con herramientas o entornos

nuevos.

e) El personal necesita un tiempo extra para aprender un lenguaje de programación nuevo.

f) Alguien de la plantilla abandona el proyecto antes de su finalización.

g) Los miembros del equipo no trabajan bien juntos.

h) Los conflictos entre los miembros del equipo conducen a problemas en la comunicación y en el

diseño, errores en la interfaz y tener que repetir algunos trabajos.

i) Las personas clave sólo están disponibles una parte del tiempo.

j) No hay suficiente personal disponible para el proyecto.

2.1.1.9 Diseño e Implementación

c) Un diseño demasiado sencillo no cubre las cuestiones principales, con lo que hay que volver a

diseñar e implementar.

d) Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e improductivas

en la implementación.

e) La utilización de metodologías desconocidas deriva en un periodo extra de formación y tener que

volver atrás para corregir los errores iniciales cometidos en la metodología.

f) No se puede implementar la funcionalidad deseada con el lenguaje o bibliotecas utilizados: el

personal de desarrollo tiene que utilizar otras bibliotecas, o crearlas él mismo para conseguir la

funcionalidad deseada.

g) Los componentes desarrollados por separado no se pueden integrar de forma sencilla, teniendo que

volver a diseñar y repetir algunos trabajos.

2.1.1.10 Proceso

a) La falta de un seguimiento exacto del progreso hace que se desconozca que el proyecto esté

retrasado hasta que está muy avanzado.

b) Un control de calidad inadecuado hace que los problemas de calidad que afectan a la planificación

se conozcan tarde.

c) La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software) conduce a fallos

de comunicación, problemas de calidad y repetición del trabajo. Un consumo de tiempo

innecesario.

d) La gestión de riesgos del proyecto software consume más tiempo del esperado.

2.2 Estimación

2.2.1 Análisis y Priorización

Para el proceso de priorización, se llevara a cabo el análisis de cada uno de los riesgos identificados,

basándose en los siguientes indicadores:

- Probabilidad (P): Porcentaje de probabilidad de que ocurra el riesgo, en una escala de 1 a 100, siendo

1: baja probabilidad, y 100: máxima probabilidad.

- Impacto (I): Efecto sobre los objetivos del proyecto en caso de ocurrir el riesgo. Se computa en

unidades de acuerdo a alcance negativo sobre el proyecto. En una escala de 1 a 10 siendo 1: bajo

alcance, y 10: máximo alcance.

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 7

- Puntuación (P*I): Es el resultado de la multiplicación de la probabilidad y el impacto del riesgo.

2.2.1.1 Elaboración de la Planificación

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

No se puede construir un producto de tal envergadura en el tiempo asignado.

30% 5 1.5

La reestimación debida a un retraso en la planificación es demasiado optimista o ignora la experiencia de los integrantes del proyecto.

30% 7 2.1

La presión excesiva en la planificación reduce la productividad

15% 3 0.45

Un retraso en una tarea produce retrasos en cascada en las tareas dependientes.

35% 7 2.45

Las áreas desconocidas del producto llevan más tiempo del esperado en el diseño y en la implementación.

25% 6 1.5

2.2.1.2 Organización y Gestión

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

El tamaño reducido de la plantilla reduce la capacidad del equipo.

20% 5 1

La estructura inadecuada de un equipo reduce la productividad.

20% 5 1

2.2.1.3 Ambiente/Infraestructura de Desarrollo

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

Las herramientas de desarrollo no funcionan como se esperaba; el personal de desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas

25% 6 1.5

La curva de aprendizaje para la nueva herramienta de desarrollo es más larga de lo esperado

20% 4 0.8

2.2.1.4 Usuarios Finales

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

En el último momento, a los usuarios finales no les gusta el producto, por lo que hay que volver a diseñarlo y a construirlo

15% 9 1.35

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 8

2.2.1.5 Cliente

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

El cliente no acepta el software entregado, incluso aunque cumpla todas sus especificaciones

15% 9 1.35

El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar

5% 4 0.2

2.2.1.6 Requisitos

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

Los requisitos no se han definido correctamente y su redefinición aumenta el ámbito del proyecto

15% 8 1.2

Las partes del proyecto que se no se han especificado claramente consumen más tiempo del esperado.

20% 6 1.2

2.2.1.7 Producto

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

El desarrollo de funciones software erróneas requiere volver a diseñarlas y a implementarlas.

25% 5 1.25

El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla y a implementarla

15% 5 0.75

El desarrollo de funciones software innecesario alarga la planificación.

20% 5 1

Los requisitos para crear interfaces con otros sistemas, otros sistemas complejos, u otros sistemas que no están bajo el control del equipo de desarrollo suponen un diseño, implementación y prueba no previstos

25% 6 1.5

El trabajo con un entorno software desconocido causa problemas no previstos

30% 6 1.8

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 9

2.2.1.8 Personal

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

Los miembros del equipo no se implican en el proyecto, y por lo tanto no alcanzan el nivel de rendimiento deseado

20% 8 1.6

La falta de motivación y de moral reduce la productividad.

30% 6 1.8

El personal necesita un tiempo extra para acostumbrarse a trabajar con herramientas o entornos nuevos.

20% 6 1.2

El personal necesita un tiempo extra para aprender un lenguaje de programación nuevo.

25% 6 1.5

Alguien de la plantilla abandona el proyecto antes de su finalización

35% 8 3

Los miembros del equipo no trabajan bien juntos 15% 5 0.75

Los conflictos entre los miembros del equipo conducen a problemas en la comunicación y en el diseño, errores en la interfaz y tener que repetir algunos trabajos.

30% 6 1.8

Las personas clave sólo están disponibles una parte del tiempo

10% 8 0.8

No hay suficiente personal disponible para el proyecto. 15% 8 1.2

La falta de la especialización necesaria aumenta los defectos y la necesidad de repetir el trabajo

25% 5 1.25

2.2.1.9 Diseño e Implementación

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

Un diseño demasiado sencillo no cubre las cuestiones principales, con lo que hay que volver a diseñar e implementar

25% 4 1

Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e improductivas en la implementación.

25% 4 1

La utilización de metodologías desconocidas deriva en un periodo extra de formación y tener que volver atrás para corregir los errores iniciales cometidos en la metodología.

30% 4 1.2

No se puede implementar la funcionalidad deseada con el lenguaje o bibliotecas utilizados: el personal de desarrollo tiene que utilizar otras bibliotecas, o crearlas él mismo para conseguir la funcionalidad deseada.

30% 6 1.8

Los componentes desarrollados por separado no se pueden integrar de forma sencilla, teniendo que volver a diseñar y repetir algunos trabajos.

25% 6 1.5

<Prototipo de Entretenimiento y Aprendizaje Inmunológico PEAI-IB> Versión: <1.2>

Risk List (Identificación y Gestión de Riesgos) Date: <21/08/11>

<Doc.- A001>

PP Grupo Lermi, 2011 Página 10

2.2.1.10 Proceso

RIESGO Probabilidad (P)

(1-100%) Impacto (I)

(1-10) Puntuación

(P*I)

La falta de un seguimiento exacto del progreso hace que se desconozca que el proyecto esté retrasado hasta que está muy avanzado

35% 5 1.75

Un control de calidad inadecuado hace que los problemas de calidad que afectan a la planificación se conozcan tarde.

35% 4 1.4

La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software) conduce a fallos de comunicación, problemas de calidad y repetición del trabajo. Un consumo de tiempo innecesario

20% 4 0.8

La gestión de riesgos del proyecto software consume más tiempo del esperado.

15% 4 0.6

3. Planificación de Respuestas

Ver documento: Plan de Respuestas a Riesgos

4. Fuentes

- Principies of Software Engineering Management (Gilb, 1998).

- Software Risk Management (Boehm, 1989).

- A Manager's Guide to Software Engineering (Pressman, 1993).

- Third Wave Project Management (Thomsett, 1993).

- Assessment and Control of Software Risks (Jones, 1994)