You are on page 1of 22

 Los objetivos de la

gestión de riesgo son identificar, controlar y eliminar las fuentes de riesgo antes de que empiecen a afectar el cumplimiento de los objetivos del proyecto

2

estimar el impacto y establecer un plan de contingencia en caso de que el problema se presente”. El análisis y la gestión del riesgo son una serie de pasos que ayudan a un equipo de desarrollo de software a comprender y manejar la incertidumbre. PREVENIR -> RIESGO 3 . “No olvide identificar.  Un riesgo es un problema potencial que puede ocurrir o no. evaluar la probabilidad de que ocurra.

Estrategias de riesgo reactivas y proactivas  Reactivo  El equipo de desarrollo no hace nada hasta que sucede algo mal. 4 . valorando su probabilidad e impacto  Se clasifican según su importancia  Establecer un plan.  Identificar los riesgos potenciales.  Modo Bombero → Tratar de remediar el problema al apuro   ¿¿Y si falla el bombero ??? R: Aparece la Gestión de Crisis para tomar el control. y es cuando el proyecto esta en verdadero peligro  Ser proactivo  Inicia antes del trabajo técnico.

Riesgos de Negocios (Amenaza la viabilidad del software que se construirá) 5 . “Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y de perdida asociado con el riesgo”  Tipos de riesgos que se encuentran: 1. Riesgos Técnicos (Amenaza la calidad y actualidad del software que se producirá) 3. Riesgos del Proyecto (Amenazan el plan del proyecto) 2.  Pérdida: El riesgo se convierte en realidad.Riesgos del Software  Los riesgos involucran dos características:  Incertidumbre: Se desconoce si puede suceder.

Posibles Riesgos del Software Riesgo Rotación del personal Cambio de gestión Tipo Proyecto Proyecto Descripción Personal con experiencia abandona el proyecto antes de que finalice Habrá un cambio de gestión organizacional con diferentes prioridades El HW esencial para el proyecto no será entregado a tiempo Habrá mas cambios en los requerimientos de lo esperado Las especificaciones de las interfaces esenciales no estarán a tiempo El tamaño del proyecto se ha subestimado Las herramientas CASE que ayudan al proyecto no tienen el rendimiento esperado Un producto competitivo se pone en venta antes de que el sistema se complete La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología No disponibilidad de HW Cambio de requerimientos Retrasos en la especificación Subestimación del tamaño Bajo rendimiento de la herramienta CASE Cambio de tecnología Competencia del producto Proyecto Proyecto y producto Proyecto y producto Proyecto y producto Producto Negocio Negocio 6 .

el producto y los negocios 2. Análisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos. ya sea para evitarlos y minimizar sus efectos en el proyecto 4. Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible 7 . Identificación de riesgos: Identificar los posibles riesgos para el proyecto.Etapas: 1. 3. Planeación de riesgos: Crear planes para abordar los riesgos.

R. “Qué características especiales de este producto podrían amenazar el plan del proyecto” 8 . Proyectos. Negocios)  Riesgos Genéricos: Amenaza potencial para todo el proyecto de software  Riesgos específicos del producto: Se los puede identificar con un buen conocimiento de tecnología.  Al identificarlos se puede estar un paso adelante.  ¿¿¿Como??? Examinando el plan del proyecto y la declaración del ámbito.Identificación de riesgos  Identificar los riesgos es una tarea sistemática orientándose a especificar las amenazas al plan del proyecto. Técnicos y R. el personal y el entorno especifico del software.  Dos tipos de riesgos para (R.

Tipos de riesgos que pueden aparecer  Riesgos de tecnología  Riesgos de personal  Riesgos organizacionales  Riesgos de herramientas  Riesgos de requerimientos  Riesgos de estimación 9 .

 Sub categorías de riesgos:  Tamaño del Producto: Riesgos asociados con el tamaño global del software. El método para identificar es crear una lista de verificación de riesgos.  Definición del proceso: Riesgos con el grado en que se ha definido el proceso  Entorno de desarrollo: se construirá.  Impacto en el Negocio: Asociados con las restricciones que impone la gerencia o el mercado.  Tecnología que construir: Asociado con la complejidad del sistema que  Tamaño y experiencia de la plantilla de personal: Relacionado con la experiencia técnica del personal. Asociado con disponibilidad y calidad de las herramientas.  Características del cliente: Asociados con la satisfacción del cliente. 10 .

 Riesgo de soporte: Grado de incertidumbre de que el SW resultante será fácil de corregir. adaptar y mejorar.  Riesgo de costo: Grado de incertidumbre de que se mantenga el presupuesto del proyecto. 11 .Componentes y controladores del riesgo  El gestor debe identificar los controladores del riesgo que afectan los componentes de riesgo del software como:  Riesgo de desempeño: Grado de incertidumbre de que el producto satisfaga los requisitos y se ajuste y se ajuste al uso que se pretende darle.  Riesgo de calendarización: Grado de incertidumbre de que se mantenga la calendarización del proyecto y de que el producto se entregue a tiempo.

Recortes financieros significativos. posibles excesos Posible deslizamiento en el COI 2 1 Marginal El fracaso para satisfacer los requisitos resultaría en degradación de la misión secundaria Mínima o pequeña reducción en le desempeño técnico Respuesta de soporte de SW Deslizamiento de costos. impactos o calendarización recuperable con valor esperado de 1K a 100K dólares Suficientes financieros recursos Calendarización alcanzable y realistas 2 Despreciable 1 2 El fracaso al satisfacer los requisitos crearía inconvenientes o impactos no operativos Ninguna reducción en le desempeño técnico SW al que fácilmente se le da soporte El error resulta en costo menor o impacto en la calendarización con valores esperado de menos de 1K dólares Posible superávit presupuestal COI facialmente alcanzable 12 . probable superación del presupuesto COI inalcanzable 2 1 Critica El fracaso para satisfacer los requisitos resultaría en un desempeño degradado del sistema hasta un punto donde el éxito de la misión es cuestionable Cierta reducción en el desempeño técnico Demoras menores en las modificaciones del SW El fracaso resulta en demoras operativas o incrementos de costos con valor esperado de 100K a 500K dólares Cierto recorte de recursos financieros. Cierta reducción en el desempeño técnico SW que no responde o no se puede soportar El fracaso resulta en el aumento de costos y en demoras en la calendarización con valores esperados que superan 500K día.Componentes Categoría Desempeño Soporte Costo Calendarización 1 Catastrófico El fracaso en la satisfacción de los requisitos resultaría en un fracaso de la misión.

Delineado de las consecuencias del riesgo. “La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al establecimiento de prioridades”. 4.Proyección del Riesgo ó Estimación del Riesgo  Intenta clasificar el riesgo de dos formas:  La posibilidad que el riesgo sea real  Las consecuencias de los problemas asociados con el riesgo en caso de que ocurra. Tomar nota de la precisión global de la proyección del riesgo de modo que no haya malas interpretaciones.  El planificador del proyecto con los gestores y personal técnico. 13 . Establecimiento de una escala que refleje la posibilidad percibida de un riesgo. Estimación del impacto del riesgo en el proyecto y el producto. 1. realizan 4 pasos en la proyección del riesgo. 2. 3.

. El cliente cambiara requisitos. Personal inexperto. Riegos La estimación del tamaño puede ser significativamente baja. Elevada movilidad del personal. 1: catastrófico 2: crítico 3: marginal 4: despreciable Categoría TP TP TP CO CO Probabilidad 60 % 30 % 70 % 40 % 50 % Impacto 2 3 2 3 2 RSGR CL TP RT ED PE PE 40 % 80 % 30 % 80 % 30 % 60 %| 1 2 1 3 2 2 14 . …… Valores de impacto: …. Falta de entrenamiento acerca de las herramientas. Los usuarios finales se resisten al sistema. Mayor numero de usuarios de los previstos. Pérdida de fondos. La fecha limite de entrega estará muy ajustada. La tecnología no satisfará las expectativas. Menos reutilización que la prevista.Desarrollo de tabla de riesgos  La tabla de riesgos ofrece al gestor de un proyecto una técnica simple para la proyección de riesgos.

Empleando los Componentes y controladores del riesgo.Evaluación del impacto de riesgo  3 factores afectan las consecuencias que son probables si un riesgo ocurre:  Naturaleza (indica los problemas que son probables si ocurre)  Ámbito (combinación de la severidad con su distribución global)  Tiempo (consideración de cuándo y durante qué periodo se sentirá el impacto)  ¿Cómo se valoran las consecuencias de un riesgo? 1. Determinar el valor promedio de la probabilidad de que ocurra para cada componente de riesgo. con base en los criterios mostrados. 2. determinar el impacto para cada componente. 3. Completar la tabla de riesgos y analizar los resultados 15 .

Cuándo desistir y finalizar el proyecto  Se debe definir un punto de referencia  Se debe marcar la relación entre cada factor de riesgo enumerado y el punto de referencia  Definir el área de incertidumbre. donde será tan válido continuar como interrumpir el trabajo  Predecir cómo la combinación de riesgos afectará a los niveles de referencia 16 .

17 .  Una buena forma de describir un riesgo es:  Representar el riesgo en formato de Condición-Transición– Consecuencia.Refinamiento del riesgo  Durante las primeras etapas se generan descripciones de riesgos muy superficiales y a medida que se avanza en el proyecto se los va detallando de mejor manera. lo que resulta en la necesidad de ingeniería personalizada para el restante 30% de componentes. entonces existe una preocupación de que (posiblemente) sólo 70% de los módulos reutilizables planeados pueden en realidad integrarse al sistema que se construirá.  Dado que <condición> entonces existe una preocupación de que (posiblemente) <consecuencia>  Dado que los componentes de software reutilizables deben ajustarse con estándares de diseño específicos y como algunos no lo hace.

supervisión y gestión del riesgo  Una estrategia para luchar con el riesgo debe considerar:  Evitar el riesgo  Supervisar el riesgo  Gestionar el riesgo y los planes de contingencia. Es un pecado capital dejar pasar el riesgo por alto luego de haberlo identificado y no tratarlo 18 .Reducción.

3. 19 . La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos: 1. Supervisión y Gestión del Riesgo  El plan de RSGR documenta todo el trabajo realizado como parte del     análisis del riesgo y el gestor del proyecto lo emplea como parte del plan global del proyecto. Algunos equipos de software no elaboran un documento RSGR formal. se inician los pasos de reducción y supervisión del riesgo. 2. Una vez documentado el plan de RSGR y que el proyecto ha comenzado. En su lugar cada riesgo se documenta individualmente mediante una hoja de información del riesgo.El plan RSGR Reducción. Valorar si los riesgos predichos de hecho ocurren Asegurar que los pasos para evitar el riesgo definidos para éste se están aplicando con propiedad Recopilar información que pueda usarse en futuros análisis de riesgo. La reducción del riesgo es una actividad encaminada a evitar el problema.

Contactar con el tercer participante para determinar la concordancia con los estándares de diseño. Asignar esta cantidad dentro del costo de contingencia del proyecto. Disparador: Los pasos de reducción son improductivos al 1/7/04. Gagne Asignado a : B. 3. considerar la estructura del componente cuando se decida acerca del protocolo de la interfaz. 2. Desarrollar una calendarización revisada suponiendo que se tendrán que construir 18 componentes adicionales. Verificar para determinar el numero de componentes en la categoría 3 de subcomisión. Gestión/plan de contingencia/disparador: La ER se calcula en $ 20 200. La funcionalidad restante tendrá que desarrollarse de manera personalizada. Laster 20 . asignar el personal en concordancia.Hoja de información del riesgo ID de riesgo: PO2 – 4-32 Fecha: 9/5/04 Prob: 80% Impacto: alto Descripción: Solo el 70% de los componentes del SW calendarizados para reutilización de hecho se integraran a la aplicación. Reducción/supervisión: 1. Estado Actual: 12/5/04: Inicia los pasos de reducción Elaboró: D. Presionar para completar los estándares de interfaz. verificar para determinar si se puede adquirir el soporte para el lenguaje. Subcomisión 2: El estándar de diseño para los componentes de interfaces no ha sido solidificado y tal vez no concuerdan con ciertos componentes reutilizables existentes. Subcomisión 3: Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino. Refinamiento/contexto: Subcomisión 1: Ciertos componentes de reutilización fueron desarrollados por un tercer participante sin conocimiento de los estándares de diseño interno.

21 .  El gestionar los riesgos implica identificar todos los factores que pueden llevar al proyecto al fracaso  El plan RSGR debe revisarse conforme el proyecto avanza  Recordar que los riesgos se relacionan con los acontecimientos futuros.Conclusiones  La gestión del riesgo es crucial en el proyecto de software.

ECC 22 . Procesos de Ingeniería de Software . Ian Sommerville. 7ma ed  INGENIERIA DEL SOFTWARE. Roger Pressman. UN ENFOQUE PRACTICO. 6ta ed.Bibliografía  INGENIERÍA DEL SOFTWARE.