anÁlisis y gestiÓn del riesgo oscar javier fabra suarez

ANÁLISIS Y GESTIÓN DEL RIESGOOscar Javier Fabra Suarez

ANÁLISIS Y GESTIÓN DEL RIESGO

AGENDA1. INTRODUCCIÓN

2. RIESGO DEL SOFTWARE

3. IDENTIFICACIÓN DEL RIESGO

4. ANÁLISIS DEL RIESGO

5. PLANIFICACIÓN DEL RIESGO

6. SUPERVISIÓN DEL RIESGO

7. EL PLAN RSGR

1. INTRODUCCIÓN



1. INTRODUCCIÓN Definición de riesgo:

Es un problema potencial –puede o no ocurrir. El riesgo afecta futuros acontecimientos -¿qué riesgos

podrían hacer que nuestro proyecto fracasara? El riesgo implica cambio. ¿Cómo afectarán los cambios en

los requisitos del cliente, en las tecnologías de desarrollo, al cumplimiento de la planificación y al éxito en general?

El riesgo nos enfrenta a elecciones. ¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, cuánta importancia hay que darle a la calidad?


1. INTRODUCCIÓN Análisis y gestión del riesgo:

¿Qué es?Una serie de pasos que ayudan al equipo del software a comprender y gestionar la incertidumbre.

¿Quién lo hace?Todos los que están involucrados en el proceso del software –gestores , ingenieros y clientes.

¿Por qué es importante? El SW es una empresa difícil. Muchas cosas pueden ir mal y a menudo salen mal. Estos problemas pueden tener un impacto significativo en la fecha de entrega o en el presupuesto.



¿Cómo se hace?Proactivamente.

Reactivas

Proactivas

Estrategiasde riesgo

Bomberos

Antes de los trabajos técnicos



¿Cuáles son los pasos?

Identificación de riesgos


Análisis de riesgos


Planeación de riesgos


Supervisión de riesgos


Listado deriesgos

potenciales

Listado deriesgos

potenciales

Listado depriorizaciónde riesgos


Planes deprevención ycontingencia


Valoraciónde riesgos




¿Cuál es el producto obtenido?Se realiza un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe de riesgos.

¿Cómo podemos estar seguros de que lo hemos hecho correctamente?El RSGR debe ser revisado mientras el proyecto se realiza para asegurar que los riesgos están siendo controlados. Los planes de contingencia deben ser realistas.


2. RIESGO DEL SOFTWARE Características del riesgo de SW

1. Incertidumbre: Puede o no ocurrir, no hay riesgos del 100% de probabilidad.

2. Pérdida: Si el riesgo ocurre, hay pérdidas.

Categorías de riesgos de software

1. Riesgos del proyecto:

2. Riesgos del producto:

3. Riesgos del negocio:

Amenazan al plan del proyecto; la planificación temporal y los costos. Ej: Pérdida de un diseñador experimentado.

Amenazan la calidad y la planificación temporal del SW; la implementación puede llegar a ser difícil o imposible. Ej: Rendimiento de un componente menor al esperado.

Amenazan la viabilidad del software a construir. Ej: Un competidor introduzca un nuevo producto.



Riesgosdelnegocio

1. Riesgo del mercado:

2. Riesgo estratégico:

3. Riesgo de ventas:

Construir un producto o sistema que nadie quiere comprar.

El producto no encaja en la estrategia comercial general de la compañía.

El departamento de ventas no sabe vender el producto.



4. Riesgo de dirección:

5. Riesgo de presupuesto:

Perder el apoyo de un gerente experto adecuado.

Perder presupuesto o personal asignado.

Categorizacióngeneral delos riesgos de SW

1. Riesgos conocidos:

2. Riesgos predecibles:

3. Riesgos impredecibles:

Los que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial.

Se extrapolan de la experiencia en proyectos anteriores.

Son muy difíciles de identificar por adelantado.



3. IDENTIFICACIÓN DEL RIESGO






Listado deriesgos

potenciales





3. IDENTIFICACIÓN DEL RIESGO Es un intento sistemático para especificar las amenazas al

plan del proyecto. Hay dos tipos de riesgo para cada categoría de riesgo de SW

(proyecto, producto y negocio). Riesgos genéricos: Amenaza potencial para todos los

proyectos de SW. Riesgos específicos: De la tecnología, el personal y el

entorno específico del proyecto en cuestión.


3. IDENTIFICACIÓN DEL RIESGO Nos basamos en una lista de comprobación de elementos de

riesgo. Es un subconjunto de riesgos conocidos y predecibles de las siguientes categorías:

Tamaño del producto. Tamaño del SW a construir.Ejemplos: • ¿Tamaño estimado del producto en LDC o FP?• ¿Grado de seguridad en la estimación del tamaño? • ¿Tamaño estimado del producto en número de programas,

archivos y transacciones? Impacto en el negocio. Limitaciones impuestas por la

gestión o por el mercado.• ¿Efecto de este producto en los ingresos de la compañía?• ¿Sofisticación del usuario final? • ¿Limitaciones gubernamentales en la construcción del

producto?


3. IDENTIFICACIÓN DEL RIESGO Nos basamos en una lista de comprobación de

elementos de riesgo. Características del cliente. Sofisticación del cliente.

• ¿Hemos trabajado con el cliente anteriormente?• ¿Está dispuesto el cliente a participar en las revisiones? • ¿Entiende el cliente el proceso del software?

Definición del proceso. Grado de uso de metodologías de la organización. ¿Ha desarrollado su organización una descripción escrita

del proceso del software a emplear en este proyecto? ¿Se llevan a cabo regularmente revisiones técnicas

formales de las especificaciones de requisitos, diseño y código?


3. IDENTIFICACIÓN DEL RIESGO Nos basamos en una lista de comprobación de elementos de

riesgo. Entorno de desarrollo. Disponibilidad y calidad de

herramientas de desarrollo de software. ¿Tenemos disponible una herramienta de gestión de proyectos de

software? ¿Existen herramientas de análisis y diseño disponibles? ¿Proporcionan las herramientas de análisis y diseño, métodos

apropiados para el producto a construir?

Tecnología a construir. Complejidad del sistema a construir. ¿Es nueva para su organización la tecnología a construir? ¿Demandan los requisitos del cliente la creación de nuevos

algoritmos o tecnología de entrada o salida? ¿El software interactúa con hardware nuevo o no probado?


3. IDENTIFICACIÓN DEL RIESGO Nos basamos en una lista de comprobación de

elementos de riesgo. Tamaño y experiencia de la plantilla. Experiencia

técnica y documentación anterior de los ingenieros de SW que van a realizar el trabajo. ¿Disponemos de la mejor gente? ¿Tiene el personal todos los conocimientos adecuados?

¿Ha recibido el personal la formación adecuada?


3. IDENTIFICACIÓN DEL RIESGO Luego, en un grupo, se utiliza un enfoque de tormenta de ideas

para responder a las cuestiones de las listas de comprobación de elementos de riesgo.

Tambien se usa la experiencia de proyectos anteriores.


3. IDENTIFICACIÓN DEL RIESGO• Factores principales de daño o cancelación de Proyectos de

software (Fuente: Standish Group, “The Chaos Report”, 2003)

Factores de Daño o cancelación % Requerimientos incompletos 13.1 Deficiencia en el involucramiento del usuario 12.4 Deficiencia de recursos 10.6 Expectativas no realistas 9.9 Deficiencia en soporte ejecutivo 9.3 Cambios en los requerimientos y especificaciones 8.7 Deficiencia en la planeación 8.1 Ya no se necesita más 7.5 Deficiencia en administración de TI 6.2 Desconocimiento en tecnología 4.3 Otros 9.9







Listado deriesgos

potenciales






Estimación del riesgo

Estimación del riesgo

Análisis del riesgo

Análisis del riesgo

Priorización delriesgo

Priorización delriesgo

ProbabilidadProbabilidad

Magnitud de pérdida


Exposición al riesgo (ER)Exposición al riesgo (ER)

Riesgos más importantes

Riesgos más importantes


4. ANÁLISIS DEL RIESGO• Estimación del riesgo:

Ejemplo de tabla de estimación de riesgos:

Riesgo Categoría Probabilidad de pérdida

Magnitud de la pérdida (semanas)

Exposición al riesgo (semanas)

RSGR

Planificación demasiado optimista TP 50% 5 2,5 A.1.1

Añadir un requisito para la actualización automática desde el mainframe

PR 5% 20 1,0 A.2.1

Añadir nuevas características desde marketing (sin conocer las características específicas)

NE 35% 8 2,8 A.3.2

La interfaz del subsistema de gráficos es inestable

PR 25% 4 1,0 B.2.1

Diseño inadecuado (hay que volver a diseñar) PR 15% 15 2,25 B.3.1

Los recursos no están disponibles en su momento

TP 10% 2 0,2 B.4.2

Los informes de estado a nivel de directiva necesitan más tiempo del previsto

TP 10% 1 0,1 B.2.1



1. Establecer una escala que refleje la probabilidad percibida del riesgo; cualitativa y/o cuantitativa. Por ejemplo:• <10% muy bajo• 10-25% bajo• 25-50% moderado• 50-75% alto• >75% muy alto

2. Estimar la probabilidad.Consejos: Técnica Delphi: Cada quien hace una estimación individual. Luego se

discute el origen de cada estimación, hasta hacer converger las estimaciones.

Utilizar <<calibración mediante adjetivos>>. Definir un valor cualitativo y luego establecer un valor cuantitativo.



3. Estimar la magnitud de la pérdida.Cuantitativamente, la pérdida puede ser medida en unidades de tiempo o de costo. Para determinar la magnitud en tiempo se recurre a la experiencia o se

toma la medida de algo pequeño y se combina para hallar la magnitud total (por ejemplo, para LCDs).

Para determinar la magnitud en costo: Si es código, se estima cuántas LDC o FP se requieren, se averigua el valor promedio de cada una y se multiplica.



4. Estimar la exposición al riesgo (ER). La ER es el valor esperado de pérdida. Es la probabilidad de pérdida (P) multiplicada por la magnitud de la pérdida (C).

ER = P.C El valor de la exposición al riesgo se utiliza posteriormente para

priorizar los riesgos.

5. Retraso total del proyecto: Se suman todas las exposiciones al riesgo para determinar el riesgo total del proyecto.

La planificación total del proyecto se puede cambiar para reflejar el retraso total esperado calculado en plan de gestión de riesgos.


4. ANÁLISIS DEL RIESGO• Priorización de riesgos:

Se ordenan los riesgos de mayor a menor exposición al riesgo. Se establece una línea de corte, se descartan los riesgos por debajo

de esa línea. En proyectos grandes se utiliza el principio de Pareto: El 20% de los

riesgos principales consumiran el 80% de su tiempo o de su dinero.


Probabilidad

0baja

1,0

Alto

Relevancia para la gestión

Muy alta

5. PLANIFICACIÓN DEL RIESGO






Listado deriesgos

potenciales





5. PLANIFICACIÓN DEL RIESGO Se establece un plan de gestión del riesgo para cada uno de los

riesgos clave identificados. Depende del conocimiento y la experiencia del gestor del

proyecto. Estrategias para atacar los riesgos:

1. Prevención. Reducir la probabilidad.

2. Minimización. Reducir el impacto.

3. Planes de contingencia. Estar preparado para lo peor y planificar como solucionar la pérdida.


5. PLANIFICACIÓN DEL RIESGO Resolución de riesgos:

Evite el riesgo. Traslade el riesgo de una parte del sistema a otra. Consiga información acerca del riesgo. Elimine el origen del riesgo. Asuma el riesgo. Comunique el riesgo. Controle el riesgo (plan de contingencia). Recuerde el riesgo.

6. SUPERVISIÓN DEL RIESGO






Listado deriesgos

potenciales





6. SUPERVISIÓN DEL RIESGO Valor cada riesgo: decidir si han cambiado sus efectos. Se hace una valoración después de alcanzar cada hito principal. Encargado de riesgos:

Alertar sobre los riesgos del proyecto y evitar que los admin. y desarrolladores los ignoren en la planificación.

Buscar todas las razones por las cuales el proyecto puede fallar. Supervisar la efectividad de los planes de reducción de riesgos.

Realizar el clásico análisis costo-beneficio para la prevención o el plan de contingencia del riesgo.

7. EL PLAN DE REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO (RSGR)



7. EL PLAN DE REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO (RSGR).

I. Introducción1. Alcance y propósito del documento2. Visión general de los riesgos principales3. Responsabilidades

a. Gestiónb. Personal técnico

II. Tabla de riesgo del proyecto.1. Descripción de todos los riesgos por encima de la línea de corte2. Factores que influyen en la probabilidad e impacto

III. Reducción, supervisión y gestión del riesgon. Riesgo # na. Reducción

i.Estrategia general.ii. Pasos específicos.

b. Supervisióni. Factores a supervisarii. Enfoque de supervisión

c. Gestióni. Plan de contingenciaii. Consideraciones especiales.

IV. Planificación temporal de revisión del Plan RSGRV. Resumen


7. EL PLAN DE REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO (RSGR).

HOJA DE INFORMACIÓN DEL RIESGO

ID Riesgo Fecha Probabilidad Magnitud de pérdida Exposición al riesgo

Descripción

Refinamiento/contexto.

1

2

Reducción/Supervisión

1

2

Gestión/Plan de Contingencia:

Estado Actual:

Autor: Asignado a:

8. Ejemplo de fracaso y posterior recuperación de implantación de un sistema ERP - Compañía: Nestlé



8. Ejemplo de fracaso y posterior recuperación de implantación de un sistema ERP - Compañía: Nestlé

Nestlé firmó un contrato con SAP para la implantación de un sistema ERP.

Pretendía integrar y centralizar sus más de 200 compañías y subsidiarias en 80 países.

Hasta 1991: Muchas marcas dispersas. Se unificaron, pero seguían funcionando independientemente.

En 1997: se descubrió redundancia masiva. Nestlé USA estaba comprando vainilla al mismo

vendedor a 29 precios distintos.

ANÁLISIS Y GESTIÓN DEL RIESGO8. Ejemplo de fracaso y posterior recuperación de

implantación de un sistema ERP - Compañía: Nestlé

El proyecto presentado por Dunn se llamaba One Nestlé, under SAP.

En 1997, 50 top ejecutivos y 10 profesionales seniors de la tecnología de la información, encargados de implantar el proyecto de SAP.

Meta: alcanzar una metodología de procesos optima para aplicar a todos los departamentos.

La crisis: comenzó antes de que instalaran los módulos de SAP a finales de 1999.

• Ninguno de los grupos que serian afectados directamente por el sistema fueron representados en el comité del proyecto.



La crisis:• Los trabajadores no sabían manejar los nuevos

sistemas y tampoco entendían los nuevos procesos.

• Nadie quería utilizar el nuevo sistema.

• Algunos módulos quedaron desconectados por la prisa por contrarestar el efecto 2000.

• Ejemplo: El depto de ventas introducía un descuento y no quedaba reflejado en el de contabilidad.



La mitigación:

• Implantar dos módulos mas de SAP e integrarlos entre si.

• Costó 5% más del costo total del proyecto

• Tom James: director de cambios de proceso Crear la comunicación entre los departamentos y el equipo del proceso.

• Encuestas a los empleados ¿Cómo va el nuevo sistema? El resultado final:

• Proyección de demanda muy exacta para sus productos.• Homogenidad de datos en todos los departamentos.• Reducción de inventarios y costos de distribución.• Cantidad ahorrada por Nestlé tras la implantación del sistema de SAP asciende a 325

millones de dólares.


BIBLIOGRAFÍA Pressman, Roger S. Ingeniería del software : un enfoque práctico.

Editorial McGraw Hill, (2002). Capítulo 6: “Análisis y Gestión del Riesgo”. Sommerville, Ian. Ingeniería del software. Editorial Pearson, (2005). Sección

5.4 “Gestión de riesgos”. McConnell, Steve. Desarrollo y gestion de proyectos informáticos.

Editorial McGraw Hill, (1997). Capítulo 5: “Gestión de riesgos”. Bruegge, Bernd. Ingeniería de software orientado a objetos. Editorial

Pearson (2002). Sección 11.4.4 “Administración del riesgo”. Menéndez-Barzanallana Asensio, Rafael. Gestión de riesgos en

ingeniería del software. http://www.solocursos.net/gestion_de_riesgos_en_ingenieria_del_software-slccurso1113601.htm

Zavala Ruiz, J. Jesús María. ¿Por qué fracasan los proyectos de software? Postgrado en Estudios Organizacionales. Universidad Autónoma Metropolitana-Iztapalapa. http://www.consol.org.mx/2004/material/63/por-que-fallan-los-proy-de-soft.pdf

Sistemas informáticos de gestión. El Rincón del Vago. http://html.rincondelvago.com/sistemas-informaticos-de-gestion.html

http://www.solocursos.net/gestion_de_riesgos_en_ingenieria_del_software-slccurso1113601.htm

http://www.solocursos.net/gestion_de_riesgos_en_ingenieria_del_software-slccurso1113601.htm

http://www.consol.org.mx/2004/material/63/por-que-fallan-los-proy-de-soft.pdf

http://www.consol.org.mx/2004/material/63/por-que-fallan-los-proy-de-soft.pdf

http://html.rincondelvago.com/sistemas-informaticos-de-gestion.html

anÁlisis y gestiÓn del riesgo oscar javier fabra suarez

Documents