Administración de Riesgos de Software

Presentación del tema: "Administración de Riesgos de Software"— Transcripción de la presentación:

1 Administración de Riesgos de Software
Sergio Zapata Instituto de Informática Universidad Nacional de San Juan 2010

2 Definición Riesgo: Evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto. 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. 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.

3 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?)

4 ¿Qué ejemplos de riesgos me puedes dar?

5 Categorías de Riesgos Riesgos del Proyecto Riesgos Técnicos
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.

6 Otra clasificación Riesgos Conocidos Riesgos Predecibles
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

7 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 Cambiar o adoptar herramientas a mitad del proyecto Falta de control de configuración del sw

8 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

9 Los diez riesgos potencialmente más peligrosos (Capers Jones)
Uso de métricas inadecuadas de productividad y avance; 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.

10 Actividades de Administración del Riesgo
Identificación Supervisión Aplicación del plan de contingencia Identificación de oportunidades de mejora.

11 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

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

13 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

14 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.

15 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%

16 Plan de Mitigación y Plan de Contingencia
Tabla de Riesgos Riesgo Categoría Probabilidad Impacto Costo Exposición Plan de Mitigación y Plan de Contingencia

17 Exposición al riesgo Exposición a riesgos: la probabilidad de
ocurrencia del riesgo multiplicada por la magnitud 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.

18 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 BU CU TE DE ST 60% 30% 70% 40% 50% 80% 2 3 1

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

20 Estrategia de administración del riesgo
Evitar el riesgo Supervisar el riesgo Comunicar el riesgo Aplicar planes de contingencia Mejora Continua

21 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 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

22 Instituto de Informática Universidad Nacional de San Juan
POR FIN SE TERMINÓ!!! Pero, hay algo mas!!! 05/04/2017 Instituto de Informática Universidad Nacional de San Juan

23 Lista de Comprobación de Riesgos (capers jones)

24 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 los momentos oportunos. Definición del proceso: asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo. Entorno de desarrollo: asociados con la disponibilidad y calidad de las herramientas 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 de proyectos de los ingenieros de software que van a realizar el trabajo.

25 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.

26 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.

27 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.

28 La siguiente lista de comprobación de riesgos genéricos 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.

29 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?

30 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.

31 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?

32 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.