Gestion Riesgo

Company

LOGO

Gestión del Riesgo

Ingenieria de Software

Introducción

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 deSoftware 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 vanointentar eliminar el riesgo, y cuestionablemente intentarminimizarlo, es esencial que los riesgos tomados sean loscorrectos”.

Antes de identificar los riesgos correctos es importante identificarlos riesgos que son obvios para los gestores y profesionales.

Gestión de Riesgo

Gestión de riesgos.

El análisis y la gestión son una serie de pasos ayudan a un equipode 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 deuna 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 granprobabilidad y alto impacto.

El análisis y gestión de riesgos produce un plan de reducción,supervisión y gestión del riesgo.

Gestión de Riesgo

Introducción

Estrategias de Riesgo Reactivas y Proactivas

Estrategias de Riesgo Reactivas y

Proactivas

Gestión de Riesgo

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 algosale mal.

-Cuando algo sale mal el equipo se precipita en la acción paracorregir el problema rápidamente (modo bombero).

-Cuando falla el modo bombero, la gestión de crisis asume elcontrol y el proyecto esta en un verdadero peligro.

“No se preocupen pensare en algo” Indiana Jones.

Gestión de Riesgo


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”

Gestión de Riesgo


Riesgos del Software


Gestión de Riesgo

El riesgo siempre involucra dos

características

Incertidumbre Perdidas

Gestión de Riesgo


Es importante cuantificar el

grado de incertidumbre y el

grado de perdida de cada

riesgo.

Riesgos del software

Potenciales problema

en presupuesto,

calendarización,

personal, recursos,

participantes y su

impacto sobre un

proyecto de software.

Potenciales problema

en diseño,

implementación,

interfaz, verificación y

mantenimiento.

A la administración,

contabilidad y

mercadotecnia del

negocio software.

Se dividen en

categorías

Riesgos del proyecto

Riesgos técnicos

Riesgos de negocio

Identifican

Descubren

Están orientados

Gestión de Riesgo


Efectos de las

categorías de

riesgos cuando se

vuelven reales

Los riesgos del

proyecto alteran la

calendarización del

proyecto y propicia

que los costos

aumenten

Los riesgos técnicos

afectan la calidad y

actualidad del

software, imposibilita

o hace mas difícil la

implementación

Los riesgos del

negocio

amenazan la

viabilidad del

software, ponen

en peligro el

proyecto o el

producto

Gestión de Riesgo


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.

Gestión de Riesgo


Charette ha propuesto otra categorización de los riesgos.

Conocidos

Predecibles

Impredecibles

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.

Se calculan u obtienen con la experiencia de proyectos

anteriores.

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

adelantado.

Gestión de Riesgo


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.

Gestión de Riesgo


Identificación de riesgos

Identificación de Riesgos

Evaluación del riesgo global del proyecto.

Componentes y controladores del riesgo.

Gestión de Riesgo

“La identificación de los riesgos es un intento sistematizado y encaminado a

especificar las amenazas al plan del proyecto”.

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.

Con el fin

Evitar los riegos cuando es

posible.

Controlar los riegos

cuando es necesario.

Gestión de Riesgo


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.

Gestión de Riesgo


•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.

Gestión de Riesgo


Gestión de Riesgo

•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.

Lista de verificación de riesgos


Gestión de Riesgo

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.


Gestión de Riesgo

COMPONENTES y CONTROLADORES DEL TIEMPO.

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.

En este enfoque se requiere que el gestor del proyecto identifique los

controladores del riesgo que afectan los componentes de riesgo del

software.


Gestión de Riesgo


www.themegallery.com

Company Logo

25.4 PROYECCIÓN DEL

RIESGO


Company Logo

La probabilidad de que

el riesgo sea real

las consecuencias de los

problemas asociados con el

riesgo, en caso de que

ocurra

25.4 Proyección

del riesgo

En la proyección o estimación de riesgos se

intenta clasificar cada riesgo en 2 formas:


Company Logo

25.4 Proyección

del riesgo

4 pasos

en la

proyección

del riesgo,realizados por el

planificador del

proyecto,

otros gestores y

personal técnico

1. Establecimiento de una

escala que refleje la

posibilidad percibida de

un riesgo.

2. Delineado de las consecuencias

del riesgo.

3. Estimación del impacto del

riesgo en el proyecto y el

producto.

4. Tomar nota de la precisión

global de la proyección del riesgo

de modo que no haya malas

interpretaciones.

Priorizar los

Riesgos para

que el equipo

pueda asignar

los recursosdonde tengan el

mayor impacto.

Finalidad:


Company Logo

25.4 Proyección

del riesgo

Riesgos Categoría Probabilidad Impacto RSGR

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


Company Logo

25.4 Proyección

del riesgo



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.


Company Logo

25.4 Proyección

del riesgo



Cada riesgo se clasifica (por ejemplo, TP

implica un riesgo de tamaño del proyecto, NE

implica un riesgo de negocios).


Company Logo

25.4 Proyección

del riesgo



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.


Company Logo

25.4 Proyección

del riesgo



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).


Company Logo

25.4 Proyección

del riesgo



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.

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


Company Logo

Ejemplo . . .

25.4 Proyección

del riesgo


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

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


Company Logo

25.4 Proyección

del riesgo



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.


Company Logo

25.4 Proyección

del riesgo



Se estudia la tabla

ordenada resultante y

define una línea de

corte.


Company Logo

25.4 Proyección

del riesgo



Los riesgos ubicados

sobre la línea tendrán

una atención posterior y

todos deben gestionarse.

Los riesgos debajo de la

línea se reevalúan para

lograr una priorización

de segundo orden.


Company Logo

25.4 Proyección

del riesgo



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.


Company Logo

25.4 Proyección

del riesgo

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 Proyección

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 Proyección

del riesgo


Identificación del riesgo. Sólo 70 % de los componentes de sw calendarizados para

reutilización se integra en la aplicación.

Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en

la forma siguiente:

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 Proyección

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 Proyección

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

25.5 REFINAMIENTO DEL

RIESGO


Company Logo

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 <condición> entonces existe

una preocupación de que (posiblemente)

<consecuencia>

25.5 Refinamiento

del riesgo


Company Logo

25.5 Refinamiento

del riesgo

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.

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.

25.5 Refinamiento

del riesgo

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.

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.


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.7.-El plan RSGR

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

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

Documents

Gestion Riesgo