Download
1 / 21
210 likes | 330 Views
Ingeniería de Software. Administración de proyectos (continuación). 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
E N D
Ingeniería de Software Administración de proyectos (continuación)
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
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
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
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
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
Identificación • El SEI propone una taxonomía de riesgos
Identificación • Representación de Glutch
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
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
Seguimiento • Monitorear que las acciones que fueron definidas en el plan de ejecuten • Aplicar las métricas sobre presupuesto, calendario y consideracionestécnicas • Informar las desviaciones respecto de los objetivos • Identificar nuevos riesgos permanentemente
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
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
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 losrequerimientos 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 ?
Para finalizar • Tom Gilb dijo:“ ... Si uno no ataca los riesgos activamente, los riesgos loatacarán a uno ...” • Tenemos que aprender a balancear las consecuencias negativas de losriesgos 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 !!!
