Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Administración de proyectos (continuación)

2 Riesgos ¿ Qué es un Riesgo ?
Un riesgo es un problema o suceso que todavía no llegó Un problema es un riesgo que se manifestó Es la medida de la probabilidad y la consecuencia de no lograr un objetivo del proyecto Es parte de toda actividad y nunca puede ser eliminado por completo No es malo en si mismo, esencial para progresar Si no existiesen los riesgos siempre haríamos lo mismo Los errores son parte esencial del aprendizaje En fin, un riesgo es un problema que podría ocurrir, y, de ocurrir, tendría un impacto

3 Riesgos ¿ Qué es un Riesgo ? (Según SEI)
Es la posibilidad de sufrir una pérdida En un proyecto de desarrollo, esa pérdida puede verse de la sig. forma: Disminución de la calidad del producto final Incremento en el costo estimado Finalización fuera de la fecha establecida Falla

4 Riesgos ¿ Cuál es la situación actual con respecto a la Adm. de Riesgos ? En muchas organizaciones hay muy poca experiencia de todo lo que está relacionado con la Adm. de Riesgos No se tiene claro: Cómo identificarlos ? Cómo medirlos ? Cómo se los gestiona ? La única técnica utilizada es la propia experiencia, mediante procesos ad-hoc Incompletos No Documentados

5 Administración de riesgos
Involucra todas las tareas relacionadas con la identificación, la resolución y comunicación de los riesgos Se basa en tomar decisiones bajo niveles de incertidumbre No involucra decisiones futuras Incluye todas las decisiones presentes que tienen incidencia en el futuro No es una actividad aislada, debe acompañar a todo el ciclo de vida de desarrollo de SW

6 Administración de riesgos

7 Identificación Los riesgos deber ser identificados para poder ser controlados Brainstormings Cuestionario de Identificación Taxonómica de Riesgos Lista con los Riesgos más comunes Una vez identificados hay que documentarlos Los riesgos más comunes son: Productos que no hacen lo que se pretende (o están incompletos, o fallan) Productos que poseen baja calidad (recordad atributos de la calidad) Proyectos que se excedieron en el costo Proyectos que sufren retrasos

8 Identificación El SEI propone una taxonomía de riesgos

9 Identificación Representación de Glutch

10 Análisis Convertir la información de riesgos que se identificó en información que permita tomar decisiones Cada riesgo debe estar lo suficientemente claro para permitir decidir  acerca de él Esta actividad es la que les permite a los gerentes concentrarse en los riesgos mas críticos Para ello se debe: Estimar probabilidad e impacto Estudiar causas y acciones correctivas Identificar causas comunes Identificar tiempos de ocurrencia

11 Análisis

12 Planificación La información de riesgos se transforma en decisiones y acciones La priorización se hace en función del grado de exposición y de la urgencia que demande la acción correctiva Un plan de acción puede tener la siguiente forma: Plan de mitigación: Evitar el riesgo (por ejemplo, cambiando el diseño del producto final) Reducir la probabilidad de ocurrencia con planes de mitigación Atacar el impacto con planes de contingencia Recordar de establecer el “trigger” del plan (Para ello hay que ir midiendo !!!) Aceptar el riesgo sin tomar acciones, aceptando las consecuencias derivadas de su posible ocurrencia En la práctica es imposible tratar todos los riesgos

13 Seguimiento Monitorear que las acciones que fueron definidas en el plan de ejecuten Aplicar las métricas sobre presupuesto, calendario y consideraciones técnicas Informar las desviaciones respecto de los objetivos Identificar nuevos riesgos permanentemente

14 Control Realizar las correcciones de las desviaciones producidas sobre las acciones que fueron planificadas Analiza las desviaciones y tendencias Decide si se replanifica, se recurre a la contingencia, se continua con el tracking, etc. Ejecuta las decisiones tomadas

15 Comunicación Provee el feedback sobre las actuales actividades sobre riesgos Para poder ser analizados y administrados, los riesgos deben ser comunicados a los niveles adecuados de la organización

16 Adquisición de un Paquete de SW
La incorporación de un SW comercial a un sistema es visto como una forma de reducir el riesgo Disminución de tiempos de diseño, desarrollo y testing Software ya maduro Debemos identificar los riesgos asociados al uso de un SW comercial Velocidad de aprendizaje Costos de implementación Rechazo por parte del equipo de desarrollo. Podemos comparar la funcionalidad de cada producto candidato disponible en el mercado con los requerimientos del usuario Podemos hacernos las siguientes preguntas: Podemos comparar la funcionalidad de cada producto candidato disponible en el mercado con los requerimientos del usuario ¿ Es factible utilizar el producto para satisfacer el requerimiento ? ¿ Qué pasa si el producto no satisface algunos requerimientos ? ¿ Cuán flexible es el producto ante cambios en los requerimientos ? Si el proveedor modifica el producto, ¿ Cómo afectará al sistema completo ? ¿ Qué pasa si el proveedor no entrega el producto en la fecha pactada ?

17 Para finalizar Tom Gilb dijo: “ ... Si uno no ataca los riesgos activamente, los riesgos lo atacarán a uno ...” Tenemos que aprender a balancear las consecuencias negativas de los riesgos contra el potencial beneficio de las oportunidades asociadas Los riesgos de hoy son los problemas de mañana La comunicación es muy importante !!! El riesgo final siempre es del cliente !!!

18 SCM (Software Configuration Management)

19 Preguntas

20 Sugerencias

21 Aplausos