Administración de Riesgos de Software

Sergio ZapataInstituto de Informática

Universidad Nacional de San Juan2010

Definición

Las actividades de análisis y gestión de riesgos incluyen una serie de pasos que ayudan al equipo de software a comprender y gestionar la incertidumbre.

Riesgo: Evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto.

Objetivo de la Gestión del Riesgo: Identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar el cumplimiento satisfactorio de un proyecto software.

Consideraciones El riesgo es a futuro. Los riesgos siempre nos “acompañan”. En general el cambio es el disparador

del riesgo. Una actitud pro-activa es fundamental. El riesgo tiene dos características:

Incertidumbre. Pérdida o Daño. (beneficio?)

¿Qué ejemplos de riesgos me puedes dar?

Categorías de Riesgos Riesgos del Proyecto

Amenazan la planificación y costos de proy. Ej. de rrhh, de infraestructura.

Riesgos Técnicos Afectan la implementación

Ej. Complejidad, performance

Riesgos de Negocio Afectan la viabilidad del sw

Ej. Mercado, normativa legal.

Otra clasificación Riesgos Conocidos

Se infieren de la evaluación de los documentos del proyecto

Riesgos Predecibles Surgen de la experiencia de otros

proyectos Riesgos Impredecibles

No se pueden identificar por adelantado

Algunos riesgos relacionados con el Proceso (Capers Jones)

1.      Planificación excesivamente optimista 2.      Gestión insuficiente de riesgos 4.      Inicio difuso 5.      Programación prematura 6.      Diseño inadecuado 7.      Limitar los procesos de calidad 8.      Entrega prematura 9 Cambiar o adoptar herramientas a mitad del proyecto 10 Falta de control de configuración del sw

Algunos riesgos relacionados con el equipo de desarrollo (capers jones)

1.      Desmotivación del personal 2.      Personal problemático descontrolado 3.      Desarrollador "heroico" 4.      Añadir más personal a un proyecto atrasado 6.      Expectativas irreales 7.      Falta de participación del usuario

1. Uso de métricas inadecuadas de productividad y avance;

2. Reporte incompleto de costos;

3.     Presión excesiva sobre el calendario;

4.     Mala gerencia;

5.     Estimación imprecisa de costos;

6.     Síndrome de la panacea;

7.     Requerimientos crecientes del usuario;

8.     Baja calidad

9.   Productividad baja

10.  Proyectos cancelados. La tasa de cancelación es proporcional al tamaño del software desarrollado y alcanza 50%. Adicionalmente resulta preocupante saber que los proyectos cancelados promedian un año de retraso y han gastado el doble de su presupuesto original para el momento de su cancelación.

Los diez riesgos potencialmente más peligrosos 

(Capers Jones)

Actividades de Administración del Riesgo

Identificación Supervisión Aplicación del plan de contingencia Identificación de oportunidades de

mejora.

Identificación del Riesgo El reconocimiento de que algo puede ir

mal es el primer paso. Si lo identificamos, podemos evitarlo o

al menos controlarlo. La identificación consiste en determinar

los siguientes aspectos del riesgo: Probabilidad, impacto y costo

Medios para Identificar Riesgos Entrevistas Listas de chequeos Experiencia Inspecciones o Revisiones Actualización (papers, revistas técnicas,

etc.)

Paso 1: Determinar Riesgos Utilizando una lista de

comprobación de elementos de riesgos: Tamaño y complejidad del producto Impacto del negocio Características del cliente Definición del proceso de sw Entorno de desarrollo Tecnología a construir Tamaño y experiencia del personal

Paso 2: Impacto del Riesgo Componentes del riesgo:

Rendimiento o Funcionalidad Costo Soporte o Mantenimiento Planificación Temporal

Un riesgo puede afectar a uno o varios de estos componentes

El impacto puede ponderarse como: despreciable, marginal, crítico o

catastrófico.

Paso 3: Probabilidad del Riesgo Dos mecanismos simples para

deter-minar la probabilidad del riesgo: Promedio de la probabilidad individual Escala cuantitativa:

Muy Poco Probable =>1% a 9% Poco Probable => 10 % a 39 % Probable => 40% a 69% Muy Probable => 70% a 100%

Tabla de Riesgos

Riesgo Categoría Probabilidad Impacto Costo Exposición Plan de Mitigación y

Plan de Contingencia

             

             

             

             

Exposición al riesgo

Exposición a riesgos: la probabilidad deocurrencia del riesgo multiplicada por lamagnitud de pérdida del riesgo (costo).

Por ejemplo: si existe un 25% de probabilidad de que ocurra un riesgo que retrasaría el proyecto en 4 semanas, entonces la exposición a este riesgo es de 0,25·4=1 semana.

Riesgos Categoría

Probabilidad

Impacto

RSGR

La estimación del tamaño puede ser significativamente baja Mayor número de usuarios de los previstos Menos reutilización de la prevista Los usuarios finales se resisten al sistema La fecha de entrega estará muy ajustada Se perderán los presupuestos El cliente cambiara los requisitos La tecnología no alcanzará las expectativas Falta de formación en las herramientas Personal sin experiencia Habrá muchos cambios de personal

PS  

PS 

PS 

BU 

BU 

CU 

PS 

TE 

DE 

ST 

ST

60%  

30% 

70% 

40% 

50% 

40% 

80% 

30% 

80% 

30% 

60%

2  3 2 3 2 1 2 1 3 2 2

 

Si debes priorizar riesgos ¿Cómo lo harías?

Estrategia de administración del riesgo

Evitar el riesgo Supervisar el riesgo Comunicar el riesgo Aplicar planes de

contingencia Mejora Continua

Referencias Bibliográficas Hall, E. M. Managing Risk: Methods for

Software Systems Developement. Addison Wesley, 1998.

Bohem B. W. Sosftware Risk Management. IEEE Computes Society Press. 1989.

Taxonomy-based Risk Identifications. Software Engineering Institute. CMU/SEI-93-TR-6, 1993

Presman R. “Ingeniería de Software”, 2000 Capers Jones, Assesment and Control of

Software Risk. Prentice Hall. 1994.

20/04/23

Instituto de Informática Universidad Nacional de San

Juan 22

POR FIN SE TERMINÓ!!! Pero, hay

algo mas!!!

Lista de Comprobación de Riesgos (capers jones)

Tamaño del producto: asociados con el tamaño general del software a construir o a modificar.

Impacto en el negocio: asociados con las limitaciones impuestas por la Administración o por el mercado.

Características del cliente: asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en losmomentos oportunos.

Definición del proceso: asociados con el grado de definición del procesodel software y su seguimiento por la organización de desarrollo.

Entorno de desarrollo: asociados con la disponibilidad y calidad de lasherramientas que se van a emplear en la construcción del producto.

Tecnología a construir: asociados con la complejidad del sistema a construir y la tecnología de punta que contiene el sistema.

Tamaño y experiencia de los rrhh: asociados con experiencia técnica y deproyectos de los ingenieros de software que van a realizar el trabajo.

Tamaño del Producto(Capers Jones)

¿Grado de seguridad en la estimación del tamaño?¿Porcentaje de desviación en el tamaño del producto respecto a la medida de productos anteriores?¿Tamaño de la base de datos creada o empleada por el producto?¿Número de usuarios del producto?¿Número de cambios previstos a los requisitos de producto? ¿Antes de la entrega? ¿Después de la entrega?¿Cantidad de software reutilizado?En cada caso, la información del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviación del porcentaje o si las magnitudes son similares, pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande.

Impacto en el Negocio(Capers Jones)

¿Efecto de este producto en los ingresos de la compañía?

¿Viabilidad de este producto para los Administradores expertos?

¿Es razonable la fecha límite de entrega?

¿Número de otros productos/sistemas con los que ese producto debe tener interoperatividad?

¿Cantidad y calidad de la documentación del producto que debe ser elaborada y entregada al cliente?

¿Costos asociados con un producto defectuoso?

Cada respuesta para el producto a desarrollar debe compararse con la experiencia anterior. Si se obtiene una gran desviación del porcentaje o si las magnitudes son similares, pero los resultados anteriores fueron poco satisfactorios, el riesgo es grande.

Características del Cliente(Capers Jones)

Diferentes Necesidades: algunos saben lo que quieren; otros saben lo que no quieren. Algunos están deseando saber todos los detalles, mientras que otros se quedan satisfechos con vagas promesas.

Diferentes Personalidades: unos disfrutan siendo clientes. Otros preferirían no ser clientes en absoluto. Algunos aceptarían felizmente cualquier cosa que se les entregará y le sacarían el mejor provecho a un producto pobre.

Tienen varios tipos de asociaciones con sus proveedores: algunos conocen bien a sus proveedores y sus productos; otros no se han visto nunca las caras y se comunican siempre mediante correspondencia escrita y algunas llamadas telefónicas breves.

Se contradicen a menudo: quieren todo para ayer y gratis. A menudo, el producto se ve sometido a las propias contradicciones del cliente.

La siguiente lista de comprobación de riesgos genéricos La siguiente lista de comprobación de riesgos genéricos asociados con diferentes clientes: asociados con diferentes clientes:

¿Ha trabajado con el cliente anteriormente?

¿Tiene el cliente una idea formal de lo que se requiere?, ¿Se ha molestado en escribirlo?

¿Aceptará el cliente gastar su tiempo en reuniones formales de requisitos para identificar el ámbito de proyecto?

¿Está dispuesto el cliente a establecer una comunicación fluida con el desarrollador?

¿Está dispuesto el cliente a participar en la revisiones?

¿Está dispuesto el cliente a dejar su personal  hacer el trabajo?

¿Entiende el cliente el proceso del software?

Si la respuesta alguna de esas preguntas es no, se deberían hacer una investigación más profunda para valorar el potencial de riesgo.

Riesgos de Proceso (Capers Jones)

Preguntas de aspectos del proceso:

¿Apoyan sus Administradores unas normas escritas que hagan hincapié en la importancia de un proceso estándar para desarrollo del software?

¿Ha desarrollado la organización una descripción escrita del proceso del  software a emplear en este proyecto?

¿Están de acuerdo los miembros del personal con el proceso del software tal y como está documentado y están dispuestos a usarlo?

¿A desarrollado la organización cursos de formación de ingeniería de software para jefes de proyecto y personal técnico?

¿Se ha proporcionado una copia de los estándares de ingeniería de software publicados a cada desarrollador y administrador de software?

¿Se han desarrollado diseños de documentos y ejemplos para todas las entregas definidas como parte del proceso de software?

Riesgos del Entorno de Desarrollo(Capers Jones)

Lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el entorno de desarrollo:

¿Tenemos disponible una herramienta de administración de proyectos de software?

¿Tenemos disponible una herramienta de administración del proceso del software?

¿Existen herramientas de análisis y diseño disponibles?

¿Proporcionan las herramientas de análisis y diseño, métodos apropiados para el producto a construir?

¿Existen expertos disponibles para resolver todas las preguntas que surjan sobre las herramientas?

¿Es adecuada la ayuda en línea y la documentación de las herramientas?

Si sé a contestado negativamente a la mayoría de las preguntas anteriores, el entorno de desarrollo es débil y el riesgo es alto.

Riesgos Tecnológicos(Capers Jones)

Alcanzar los límites de la tecnología es un reto excitante. Es el sueño de casi todos los técnicos porque fuerza al profesional a emplear su talento al máximo. Pero también es muy arriesgado.

La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con la técnica a construir:

¿Es nueva para su organización la tecnología a construir?

¿Demandan los requisitos del cliente de la creación de nuevos algoritmos o tecnología de entrada o salida?

¿Interactúa el software a construir con productos software suministrados por el vendedor que no se hayan probado?

¿Interactúa el software a construir con un sistema de base de datos cuyo funcionamiento y rendimiento no se ha comprobado en esta área de aplicación?¿Demandan los requisitos del producto una interfaz de usuario especial?

Riesgos Relacionados con el Tamaño de la Plantilla del Personal y su Experiencia

(Capers Jones)

Lista de Comprobación para valorar los riesgos asociados con el tamaño de la plantilla de personal y su experiencia:

¿Disponemos de la mejor gente?

¿Tiene el personal todos los conocimientos adecuados?

¿Tenemos suficiente personal?

¿Se ha asignado personal para toda la duración del proyecto?

¿Dispone el personal de las expectativas correctas sobre trabajo?

¿Será mínimo el movimiento del personal para permitir la continuidad?

Si la respuesta a alguna de esas preguntas es no, se debería hacer una investigación más profunda para valorar el potencial de riesgo.