Gestion Riesgo

Gestión del Riesgo Ingenieria de Software

Company

LOGO

Introducción Gestión de Riesgo

 Robert Charette en su definición de riesgo lo divide en tres bases: -El riesgo se relaciona con los acontecimientos futuros. -El riesgo implica cambios. -El riesgo implica elección y la incertidumbre que ésta conlleva.  Cuando el riesgo se considera en el contexto de la Ingeniería de Software las tres bases se evidencian. -El futuro es una preocupación de primer orden. -El cambio es una preocupación central. -Es necesario enfrentar las opciones.  Peter Drucker en su opinión menciona: “Aunque es en vano intentar eliminar el riesgo, y cuestionablemente intentar minimizarlo, es esencial que los riesgos tomados sean los correctos”.  Antes de identificar los riesgos correctos es importante identificar los riesgos que son obvios para los gestores y profesionales.

Introducción Gestión de Riesgo

   



Gestión de riesgos. El análisis y la gestión son una serie de pasos ayudan a un equipo de software a comprender y manejar la incertidumbre. Lo realizan todos los involucrados en el proceso del software. Es importante por que estar preparados es un elemento clave de una buena gestión de proyectos de software. Los pasos para análisis y gestión de riesgos son: -Reconocer que puede salir mal. -Analizar cada riesgo y determinar la probabilidad de que ocurra . -Clasificar los riesgos por probabilidad e impacto. -Desarrollar un plan para gestionar aquellos riesgos con gran probabilidad y alto impacto. El análisis y gestión de riesgos produce un plan de reducción, supervisión y gestión del riesgo.

Estrategias de Riesgo Reactivas y Proactivas Gestión de Riesgo

Estrategias de Riesgo Reactivas y Proactivas


 Estrategias Reactivas. -Se denominan “escuela Indiana Jones de Gestión de riesgo”. -No se recomiendo su uso. -Los riesgos son apartados para tratarlos. -Usualmente no se hace nada acerca de los riesgos hasta que algo sale mal. -Cuando algo sale mal el equipo se precipita en la acción para corregir el problema rápidamente (modo bombero). -Cuando falla el modo bombero, la gestión de crisis asume el control y el proyecto esta en un verdadero peligro.

“No se preocupen pensare en algo” Indiana Jones.


 Estrategias Proactivas -Es una estrategia mas inteligente y recomendable. -Comienza mucho antes de que se inicie el trabajo técnico. -En esta estrategia se identifican riesgos potenciales, se valoran su probabilidad e impacto y se clasifican según su importancia. -El equipo de software establece un plan para gestionar el riesgo. -El objetivo principal es evitar el riesgo. -Se desarrolla un plan de contingencia que le permita responder de una forma controlada y efectiva cuando un riesgo no puede evitarse.

“Equipo de Software Precavido, vale por dos”

Riesgos del Software Gestión de Riesgo

Riesgos del Software


El riesgo siempre involucra dos características

Incertidumbre

Perdidas

Es importante cuantificar el grado de incertidumbre y el grado de perdida de cada riesgo.


Riesgos del software

Riesgos del proyecto

Identifican

Potenciales problema en presupuesto, calendarización, personal, recursos, participantes y su impacto sobre un proyecto de software.

Se dividen en categorías

Riesgos técnicos

Riesgos de negocio

Están orientados

Descubren Potenciales problema en diseño, implementación, interfaz, verificación y mantenimiento.

A la administración, contabilidad y mercadotecnia del negocio software.


Los riesgos técnicos afectan la calidad y actualidad del software, imposibilita o hace mas difícil la implementación Los riesgos del proyecto alteran la calendarización del proyecto y propicia que los costos aumenten

Efectos de las categorías de riesgos cuando se vuelven reales

Los riesgos del negocio amenazan la viabilidad del software, ponen en peligro el proyecto o el producto


Ejemplos:

•El director no apoya el proyecto. •Se diseño un software que nadie quiere. •Perdida de presupuesto o personal •Construcción de un producto que ventas no pude vender. •Un producto que no encaja en la estrategia comercial de la compañía.

•El cliente no especifico bien las requisitos. •Los equipos de trabajo creados no son los adecuados. •Se excede el presupuesto obtenido. •No se cumple con las fechas especuladas. •Falta de comunicación entre el personal.

•Se tienen ambigüedad en las especificaciones. •Perdida de la datos. •Problemas en la interfaz del usuario. •Desconocimientos de tecnologías de punta. •Dudas o de la técnica utilizadas. •Las técnicas utilizadas se encuentran en desuso.


Charette ha propuesto otra categorización de los riesgos. Conocidos

Se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del medio ambiente comercial y técnico y otras fuentes de información fiables.

Predecibles

Se calculan u obtienen con la experiencia de proyectos anteriores.

Impredecibles

Pueden ocurrir, pero son muy difíciles de identificar por adelantado.


Ejemplos:

•Cambios en el personal •Mala comunicación con el cliente. •Disminución del esfuerzo del personal.

•???????????

•Fecha de entrega irreales. •Falta de requisitos documentados •Pobre entorno de desarrollo •Falta de requisitos en el ámbito del software.

Identificación de riesgos Gestión de Riesgo

Identificación de Riesgos Evaluación del riesgo global del proyecto. Componentes y controladores del riesgo.


“La identificación de los riesgos es un intento sistematizado y encaminado a especificar las amenazas al plan del proyecto”. Con el fin

Evitar los riegos cuando es posible.

Controlar los riegos cuando es necesario.

Cada una de las categorías de riesgos se dividen en dos tipos: •Riesgos genéricos: Amenazan a todo el proyecto de software. •Riesgos específicos del producto: Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión.


Riesgos específicos del producto

•Se identifican examinando el plan del proyecto y la declaración del ámbito del software. •Se busca responder al siguiente cuestionamiento: ¿Qué características especiales de este producto podrían amenazar el plan del proyecto?. •Un método para identificarlos es crear una lista de verificación de riesgos. •Con la lista de verificación se pueden identificar riesgos y enfocarse a un subconjunto de riesgos conocidos y predecibles en las subcategorías genérica enseguida mencionadas.


•Tamaño del producto: riesgos asociados al tamaño global del software que se construirá o modificara. •Impacto en el negocio: riesgos asociados a las restricciones que imponen la gerencia o el mercado. •Características del cliente: riesgos asociados a la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos. •Definición del proceso: riesgos asociados al grado en que se ha definido el proceso del software y en que le da seguimiento la organización que lo desarrolla. •Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se usaran en la construcción del producto. •Tecnología que construir: riesgos asociados con la complejidad del sistema a construir y la tecnología de punta que contiene el sistema. •Tamaño y experiencia de la plantilla del personal: Riesgos asociados con la experiencia técnica y de proyectos de los ingenieros de software que van a realizar el trabajo.


Lista de verificación de riesgos

•Puede organizarse de diferentes formas. •Las preguntas relevantes se pueden responder para cada proyecto de software. •Permite que el planificador estime el impacto del riesgo. •También se pueden mencionar las características relevantes para cada subcategoría genérica. •Al final se debe de mencionar un conjunto de componentes y controladores de riesgo junto con su probabilidad de ocurrencia. •Los controladores del desempeño, soporte, costo y calendarización se estudian en las ultimas respuestas.


EVALUACION DEL RIESGO GLOBAL DEL PROYECTO. Esta se puede realiza mediante un cuestionario basados en datos de riesgo. El siguiente cuestionario se basa en los datos de riesgo de gestores de proyecto de software experimentados. 1. Los altos ejecutivos del software y del cliente se han comprometido formalmente. 2. Los usuarios finales están comprometidos con el proyecto y el producto que se construirá. 3. Los requisitos han sido entendidos por el equipo de ingenieros y sus clientes. 4. Los clientes estuvieron completamente involucrados en la definición de requisitos. 5. Los usuarios finales tienen expectativas realistas. 6. El ámbito del proyecto es estable. 7. El equipo tiene la mezcla de correcta de actividades. 8. Los requisitos del proyecto son estables. 9. El equipo tiene experiencia con la tecnología que se implementara. 10. El numero de personas es adecuado para realizar el proyecto. 11. Todos los involucrados están de acuerdo en la importancia del proyecto y los requisitos del sistema.


COMPONENTES y CONTROLADORES DEL TIEMPO. En este enfoque se requiere que el gestor del proyecto identifique los controladores del riesgo que afectan los componentes de riesgo del software.

Riesgo de desempeño: el grado de incertidumbre de que el producto satisfaga y se ajuste al uso que se pretende. Riesgo de costo: El grado de incertidumbre que mantendrá el presupuesto del proyecto. Riesgo de soporte: El grado de incertidumbre de que el software final será fácil de corregir, adaptar y mejorar. Riesgo de calendarización: El grado de incertidumbre de que se respete la calendarización y entrega a tiempo del software.


www.themegallery.com

25.4 PROYECCIÓN DEL RIESGO

Company Logo

25.4 Proyección del riesgo www.themegallery.com

En la proyección o estimación de riesgos se intenta clasificar cada riesgo en 2 formas:

La probabilidad de que el riesgo sea real

las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra

Company Logo


1. Establecimiento de una escala que refleje la posibilidad percibida de un riesgo.

4 pasos en la proyección del riesgo, realizados por el planificador del proyecto, otros gestores y personal técnico

Priorizar los Riesgos para

2. Delineado de las consecuencias del riesgo. 3. Estimación del impacto del riesgo en el proyecto y el producto.

Finalidad:

que el equipo pueda asignar

los recursos donde tengan el

mayor impacto. 4. Tomar nota de la precisión global de la proyección del riesgo de modo que no haya malas interpretaciones. Company Logo


25.4.1 Desarrollo de una tabla de riesgos

Una tabla de riesgos ofrece al gestor de un proyecto una técnica simple para la proyección de riesgos

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo



Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cuán remotos sean) con la ayuda de la lista de verificación de riesgos.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo



Cada riesgo se clasifica (por ejemplo, TP implica un riesgo de tamaño del proyecto, NE implica un riesgo de negocios).

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo



El valor de la probabilidad de cada riesgo lo pueden estimar individualmente los miembros del equipo. Éstos se encuestan en una forma de "todos contra todos", desarrollando un solo valor de consenso.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo


25.4.1 Desarrollo de una tabla de riesgos Los controladores de riesgo se pueden evaluar sobre una escala de probabilidad cualitativa que tiene los siguientes valores: imposible, improbable, probable y frecuente. Entonces se asocia la probabilidad matemática con cada valor cualitativo (por ejemplo, una probabilidad de 0.7 a 0.95 implica un riesgo enormemente probable).

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo



Se evalúa el impacto de cada riesgo. Cada componente de riesgo se evalúa y se determina una categoría de impacto. Las categorías para cada uno de los cuatro componentes de riesgo (desempeño, soporte, costo y calendarización) se promedian para determinar un valor de impacto global.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Valores de impacto: 1. catastrófico 2. crítico 3. marginal 4.despreciable Company Logo


Ejemplo . . . Riesgos

Categoría

Probabilidad

Impacto

La estimación del tamaño puede ser significativamente baja.

TP

60%

2

Mayor numero de usuarios de los previstos

TP

30%

3

Los usuarios finales se resisten al sistema

CO

40%

3

La fecha limite de entrega estará muy ajustada

CO

50%

2

Perdida de fondos

CL

40%

1

El cliente cambiara los requisitos

TP

80%

2

La tecnología no satisfará las expectativas

RT

30%

1

Falta de entrenamiento acerca de las herramientas

ED

80%

3

Personal inexperto

PE

30%

2

Elevada movilidad del personal

PE

60%

2

RSGR

Company Logo Valores de impacto: 1. catastrófico 2. crítico 3. marginal 4.despreciable



Una vez completadas las cuatro primeras columnas de la tabla de riesgos, ésta se ordena según la probabilidad y el impacto. Los riesgos de alta probabilidad y alto impacto se filtran hacia lo alto de la tabla , y los riesgos de baja probabilidad caen al fondo. Esto logra una priorización del riesgo de primer orden.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo



Riesgos

Categoría

Probabilidad

Impacto

RSGR

Se estudia la tabla ordenada resultante y define una línea de corte.

Company Logo



Los riesgos ubicados sobre la línea tendrán una atención posterior y todos deben gestionarse.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Los riesgos debajo de la línea se reevalúan para lograr una priorización de segundo orden.

Company Logo


25.4.1 Desarrollo de una tabla de riesgos Contiene una referencia que apunta hacia un Plan de reducción, supervisión y gestión de riesgo o, alternativamente, una colección de hojas de infamación de riesgo desarrolladas para todos los riesgos que están sobre el corte.

Riesgos

Categoría

Probabilidad

Impacto

RSGR

Company Logo


25.4.2 Evaluación del impacto del riesgo. Tres factores afectan las consecuencias que son probables si un riesgo ocurre:

Su naturaleza Ámbito Tiempo

Indica los problemas que son probables si ocurre. ¿cuán serio es? ¿cuánto del proyecto se afectará, o cuántos clientes resultarán dañados? Cuándo y durante qué periodo se sentirá el impacto

Company Logo


25.4.2 Evaluación del impacto del riesgo. La exposición al riesgo global, ER, se determina mediante la siguiente relación:

ER = P x C P es la probabilidad de que ocurra un riesgo. C el costo al proyecto en caso de que ocurra el riesgo.

Company Logo


25.4.2 Evaluación del impacto del riesgo. Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la forma siguiente: Identificación del riesgo. Sólo 70 % de los componentes de sw calendarizados para reutilización se integra en la aplicación.

Probabilidad de riesgo. 80 % (quizá). Impacto del riesgo. •Se planificaron 60 componentes de sw reutilizables, solo se usaran el 70% •18 componentes tendrían que desarrollarse desde cero. •El componente promedio es 100 LDC y el costo por cada LCD es de 14.00 dólares

Costo (impacto) global del desarrollo de los componentes = 18 x 100 x 14 = 25 200 dólares. Exposición al riesgo = 0.80 x 25 200 dólares = 20 200 dólares. Company Logo


25.4.2 Evaluación del impacto del riesgo. La exposición al riesgo total para todos los riesgos (sobre la línea de corte en la tabla) puede ofrecer un medio con que ajustar la estimación del costo final de un proyecto.

Se emplea para predecir el aumento probable en los recursos de personal que se requieran en varios puntos durante la calendarización del proyecto.

La proyección del riesgo y las técnicas de análisis se aplican de manera iterativa conforme avanza el proyecto de software, el equipo del proyecto debe revisar de nuevo la tabla de riesgos en intervalos regulares.

Company Logo


25.4.2 Evaluación del impacto del riesgo.

Consejo Compárese la ER de todos los riesgos con la estimación de costos para el proyecto. Si la ER es mayor de 50% del costo del proyecto, la viabilidad del proyecto debe reevaluarse.

Company Logo

www.themegallery.com

25.5 REFINAMIENTO DEL RIESGO

Company Logo

25.5 Refinamiento del riesgo www.themegallery.com

Es posible refinar el riesgo en un conjunto de riesgos más detallados, cada uno un poco más sencillo de refinar, supervisar y gestionar.

Una forma de hacer esto es representar el riesgo en el formato condición-transición-consecuencia

Dado que entonces existe una preocupación de que (posiblemente)

Company Logo


Ejemplo...

Dado que todos los componentes de software reutilizables deben ajustarse con estándares de diseño especificas, y como algunos no 10 hacen, entonces existe una preocupación de que (posiblemente) sólo 70 % de los módulos reutilizables planeados puedan en realidad integrarse al sistema que se construirá, por lo que resulta en la necesidad de ingeniería personalizada para el restante 30 % de componentes.

Company Logo


Ejemplo... Esta condición general se puede refinar en la forma siguiente: Subcondición 1 . Ciertos componentes reutilizables fueron desarrollados por terceras personas sin conocimiento de los estándares de diseño internos.

Subcondición 2. El estándar de diseño para el componente de interfases no se ha concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes. Subcondición 3. Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino.

Las consecuencias asociadas con estas subcondiciones refinadas siguen siendo las mismas , pero el refinamiento ayuda a aislar los riesgos

subyacentes y puede conducir a un análisis y respuestas más sencillos. Company Logo

25.6.-Reducción, Supervisión y Gestión del Riesgo

Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: •Evitar o Reducir el riesgo. •Supervisar el riesgo. •Gestionar el riesgo y planes de contingencia.


•Evitar o Reducir el riesgo. Si un equipo de software adopta un enfoque proactivo hacia el riesgo, evitarlo siempre es la mejor estrategia. Esto ser logra desarrollando un plan para reducir el riesgo.


•Supervisar el riesgo. A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. El jefe del proyecto supervisa factores que pueden proporcionar una indicación sobre si el riesgo se está haciendo más o menos probable.


•Gestionar el riesgo y planes de contingencia. La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad.


•Ejemplo: Asuma que se ha detectado mucha movilidad del personal como un riesgo del proyecto, r1. Basándose en casos anteriores y en la intuición de administrativa, la probabilidad, l1, de mucha movilidad se estima en un 0.70 (70 por ciento, bastante alto) y el impacto, x1, se proyecta como crítico. Esto es un gran cambio, puede tener un impacto crítico en el costo y planificación temporal del proyecto.


Este riesgo se reduce si el gestor del proyecto desarrolla una estrategia para reducir la movilidad. Entre los posibles casos se toman en cuenta: •Reunirse con el personal actual y determinar las causas de la movilidad (por ejemplo: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo). •Actuar para reducir esas causas que estén al alcance de nuestro control antes de que comience el proyecto. •Una vez que comienza el proyecto, asumir que habrá movilidad y desarrollar técnicas que aseguren la continuidad cuando se vaya la gente. •Organizar los equipos del proyecto de manera que la información sobre cada actividad de desarrollo esté ampliamente dispersa. •Definir estándares de documentación y establecer mecanismos para estar seguro de que los documentos se cumplimentan puntualmente.


En este caso se pueden supervisar los siguientes factores: •Actitud general de los miembros del equipo basándose en las presiones del proyecto.

•Grado de compenetración del equipo. •Relaciones interpersonales entre los miembros del equipo. •Problemas potenciales con compensaciones y beneficios. •Disponibilidad de empleo dentro y fuera de la compañía.


Continuando con el ejemplo, el proyecto va muy avanzado y un número de personas anuncia que renunciaran. Si se ha seguido la estrategia de reducción, tendremos copias de seguridad disponibles, la información está documentada y el conocimiento del proyecto se ha dispersado por todo el equipo. Además, el jefe del proyecto puede temporalmente volver a reasignar los recursos (y reajustar la calendarización temporal del proyecto) hacia aquellas funciones completamente estructuradas, así permite que

los nuevos elementos que deben agregarse al equipo "tomen el ritmo".


Es importante advertir que los pasos reducción, supervisión y gestión del riesgo (RSGR) provocan aumentos del costo del proyecto. Parte de la gestión de riesgos es evaluar cuando los beneficios obtenidos por los pasos RSGR superan los costes asociados con su implementación. En esencia, el planificador del proyecto realiza un clásico análisis costo-beneficio.

Si los pasos RSGR para evitar un riesgo, aumentan lo siguiente en nuestro proyecto:

Para un proyecto grande se pueden identificar unos 30 ó 40 riesgos. Si se pueden identificar entre tres y siete pasos de gestión de riesgo para cada uno, la gestión del riesgo puede convertirse en un proyecto por sí misma! Por este motivo, adaptamos

la regla de Pareto 80/20 al riesgo del software. La experiencia dice que:

80% del riesgo total de un proyecto, se puede explicar solo con 20% de los riesgos identificados.

El trabajo realizado durante procesos de análisis de riesgo anteriores ayudará al jefe de proyecto a determinar qué riesgos pertenecen a ese 20% (por ejemplo,

riesgos que conducen a una mayor exposición al riesgo). Algunos riesgos no se incluyen en el RSGR porque no se ubican en el crítico 20%.


El riesgo no está limitado al proyecto de software. Los riesgos pueden ocurrir después de que el software se ha desarrollado exitosamente y entregado al cliente. Estos riesgos están típicamente asociados con las consecuencias de la falla de software en el campo.

El análisis de seguridad y peligros de software son actividades de aseguramiento de la calidad del software (capítulo 26) que se enfocan en la identificación y evaluación de los peligros potenciales que pudieran afectar al software negativamente y provocar una falla en todo el sistema. Si los peligros se pueden identificar temprano en el proceso de ingeniería del software, las características de diseño de software se pueden especificar de modo que eliminen o controlen los peligros potenciales.

25.7.-El plan RSGR

Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se podrían organizar los pasos de gestión del riesgo en un Plan diferente de reducción, supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del análisis de riesgo y son empleados por el gestor del proyecto como parte del Plan Global del Proyecto.

Algunos equipos de software no desarrollan un documento RSGR formal. Más bien, cada riesgo se documenta utilizando una Hoja de Información de Riesgo (HIR). En la mayoría de los casos, la HIR se mantiene utilizando un sistema de base de datos, por lo que la creación y entrada de información, ordenación por prioridad, búsquedas y otros análisis pueden ser realizados con facilidad.


25.7.-El plan RSGR

Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reducción y supervisión del riesgo. Como ya hemos dicho antes:

-La reducción del riesgo es una actividad para evitar problemas.

- La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales: 1.-Valorar si los riesgos predichos de hecho ocurren. 2.-Asegurarse de que los procedimientos para reducir el riesgo definidos para el riesgo en cuestión se están aplicando apropiadamente.

3.-Recoger información que pueda emplearse en el futuro para analizar riesgos.

25.7.-El plan RSGR

HERRAMIENTAS DE SOFTWARE El objetivo de las herramientas de gestión del riesgo es ayudar al equipo del proyecto a definir los riesgos, valorar su impacto y probabilidad, y seguir los riesgos a través de

todo el proyecto del software.

25.8.-Resumen

Siempre que en un proyecto de software esté mucho en Juego, el sentido común dicta el análisis de riesgos. Sin embargo, muchos gestores de proyecto de software lo hacen informal y superficialmente, si es que lo hacen. El tiempo empleado en identificar, analizar y gestionar el riesgo paga por si mismo dividendos en muchas formas: menos trastornos durante el proyecto, una mayor habilidad para seguir y controlar un proyecto, y la confianza que llega cuando se planifican los problemas antes de que ocurran.

25.8.-Resumen

Para citar a Sun Tzu, el general chino que vivió hace 2 500 años: “Si usted conoce al enemigo y se conoce a si mismo, no necesita temer el resultado de cien batallas". El enemigo del gestor del proyecto de software es el riesgo.

25.-GESTION DEL RIESGO

Gestion Riesgo

Recommend Documents