1 / 21

Ingeniería de Software

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

bary
Télécharger la présentation

Ingeniería de Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 consideracionesté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 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 ?

  17. 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 !!!

  18. SCM (Software Configuration Management)

  19. Preguntas

  20. Sugerencias

  21. Aplausos

More Related