Diapositivas realizadas para una presentacion de ingenieria del software sobre la gestion de riesgos, lo hice en un par de horas por lo que no tiene tanta calidad, habla sobre las formas de detectar un riesgo, las consecuencias que pueden traer y las formas de solucionarlas.

1. Republica Bolivariana de Venezuela.
Ministerio dePoder Popular para la Educación.
Vicerrectorado Académico.
Carrera:Ingenieríaen Informática.
Gestión de riesgos
Diciembre 2016

2. Definición
Son acciones que ayudan al equipo de software a entendery
manejar la incertidumbre.

3. Quien lo hace?
Todos los involucrados en elproceso de software (gerentes,
ingenieros de software y otros interesados).

4. Importancia
El software es una empresa difícil. Muchascosas pueden salir mal
y, francamente,
Muchas con frecuencialo hacen.

5. Pasos
1) Identificar elriesgo
2) Clasificar los riesgos
3) Establecer un plan de contingencia

6. Producto Final
Se produce un plan para mitigar,monitorear y manejarelriesgo o
un conjunto de hojas de información de riesgo.

7. Estrategias deriesgo
Estrategiareactiva: Estrategiaproactiva:
Las estrategias reactivas de riesgo se han llamado
usualmente la “escuela de gestión de riesgo. Sin
embargo, la mayoría de los equipos de software se
apoyan exclusivamente en estrategias reactivas de
riesgo.
Una estrategia proactiva comienza mucho antes de
iniciar el trabajo técnico. Los riesgos potenciales se
identifican, su probabilidad e impacto se valoran y se
clasifican por importancia.

8. Riesgo de software
Los riesgos del proyecto amenazan el plan del proyecto, es decir, si los riesgos del proyecto se vuelven
reales,esprobablequeel calendariodelproyectosedeslice y queloscostosaumenten.
Los riesgos del proyecto identifican potenciales problemas de presupuesto, calendario, personal (Tanto
técnico como en la organización), recursos, participantes y requisitos, así como su impacto sobre un
proyectodesoftware.

9. 7 Principiosde la administraciónde riesgos
Manteneruna perspectiva Global Alentarla comunicaciónabiertaTomaruna visión deprevisión
Enfatizar un proceso continuo Alentarel trabajo en equipoDesarrollar unavisión del producto
compartida
Integrar

10. Identificaciónde riesgos
Esun intentosistemáticoporespecificaramenazasalplandel proyecto
(Estimaciones, calendario, carga de recursos, etc.). Al identificar los riesgos conocidos y predecibles, el
gerente de proyecto da un primer paso para evitarlos cuando es posible y para controlarlos cuando es
necesario.
Riesgos genéricos Riesgos específicos del producto
Todo el
software en
general
Área detallada
del software

11. Componentes y promotores del riesgo
El enfoque requiere que el gerente del proyecto identifique los promotores de riesgo que afectan los
componentesderiesgodesoftwaresegún su impacto.
Por su rendimiento Por su
apoyo
Sedefinen:
Por su calendario
Impacto Despreciable Impacto Marginal
Impacto Critico Impacto Catastrófico
Por su
costo

12. Proyecciónde riesgo
Intenta calificar cada riesgo en dos formas: una es la posibilidad o probabilidad de que el riesgo sea
real y la segunda son las consecuencias de los problemas asociados con el riesgo, en caso de que
ocurra.
Consta de cuatropasos
Establecer una escala que refleje la probabilidad percibida de unriesgo.
Delinear las consecuencias del riesgo.
Estimar el impactodel riesgo sobre el proyectoy el producto.
Valorarla precisión global de la proyección del riesgo de modo queno habrá malos entendidos.

13. Valoracióndel impactode riesgo
Seidentifica por factoresde riesgos
Su naturaleza:
La probabilidad delos problemas.
Su ámbito:
Combina su severidad (cuan serio
es) con su distribución global.
Su temporización:
Cuandoypor cuantotiempo se
sentirá el impacto.

14. Refinamientodel riesgo
Durante las primeras etapas de la planificación del proyecto, un riesgo puede enunciarse de manera
muy general. Conforme pasa el tiempo y se aprende más acerca del proyecto y de los riesgos, es posible
refinarel riesgo en unconjuntoderiesgosmásdetallados,cadaunoun poco
mássencillo demitigar,monitorearymanejar.
Condición – Transición – Consecuencia
Dado que <condición> entonces hay preocupación porque (posiblemente) <consecuencia>
El refinamiento ayuda a aislar los riesgos subyacentes y puede conducir a análisis y respuestas más
Sencillos.
Subcondición 1. Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimientode los estándares de diseño internos.
Subcondicion 1
Ciertoscomponentesreutilizableslosdesarrollóuna
tercerapersonasin conocimientode losestándares
de diseñointernos.
Subcondicion 2
El estándarde diseñoparainterfacesde componente
todavíanoseconsoliday puedenoapegarsea
ciertoscomponentesreutilizablesexistentes.
Subcondicion 3
Ciertoscomponentesreutilizablesseimplementaron
en un lenguajequenosesoportaenel entorno
blanco.

15. Mitigación,monitoreo y manejo de riesgo
Subcondición 1. Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimientode los estándares de diseño internos.
Mitigaciónderiesgo
Si un equipo desoftware adopta
un enfoqueproactivo anteel
riesgo, evitarlo siempre esla
mejor estrategia. Esto se logra
desarrollando unplan para
mitigación del riesgo.
Monitoreo deriesgo
El gerentede proyecto monitorea
factores quepueden proporcionar
un indicio de si el riesgo se vuelve
más o menosprobable.
Manejo deriesgo
El manejo del riesgo y la
planificación decontingencia
suponen que los esfuerzos de
mitigación
Fracasaron yque el riesgo se
convirtió en realidad.

16. EL PLAN MMMR
En el plan de proyecto del software puede incluirse una estrategia de administración del riesgo, o los
pasos de administración del riesgo pueden organizarse en un plan de mitigación, monitoreo y manejo
de riesgo (MMMR) por separado. El plan MMMR documenta todo el trabajo realizado. Como parte del
análisisderiesgosy el gerente delproyectolousacomo partedel plandeproyectoGlobal.
Subcondición 1. Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimientode los estándares de diseño internos.

17. Gracias!
Subcondición 1. Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimientode los estándares de diseño internos.

18. Gracias!
Subcondición 1. Ciertos componentes reutilizables los desarrolló una tercera persona sin conocimientode los estándares de diseño internos.