gr 004.pdf

Gestión del riesgo

Ing. Felipe Ramírez HerreraJefe, Unidad de InformáticaJefe, Unidad de InformáticaInstituto Costarricense sobre Drogas

EstándarEstándar

• El estándar de gestión de riesgos se basa en la noción de que los riesgos q gdeben tratarse de forma proactiva.

• La gestión de riesgos forma parte de• La gestión de riesgos forma parte de un proceso formal y sistemático que

bdebe considerarse como una iniciativa positiva.

ReferenciasReferencias

• Software Engineering Institute:• Continuous Risk Management (proceso)

• Team Risk Management (implementación conjunta de proceso)

• Instituto Australiano de Estandarización:Estandarización:

• AS/NZS 4360 Risk Management Standard

S b O l A t S ti 404• Sarbanes‐Oxley Act, Section 404

• ISO/IEC Guide 73:2002/

RiesgoRiesgo

• Un riesgo constituye “un evento (o condición) con cierta incertidumbre y ) ysi éste ocurre tiene un efecto positivo o negativo en los objetivos delo negativo en los objetivos del proyecto.

• Un riesgo tiene una causa y, en caso de ocurrencia, también implica una consecuencia” (PMBOK® 2004).

RiesgoRiesgo

• Un riesgo implica simultáneamente amenazas a los objetivos de un jproyecto/proceso y a la vez oportunidades para mejorar dichosoportunidades para mejorar dichos objetivos.

l• Los riesgos tienen su origen en la incertidumbre que está presente en todos los proyectos/procesos.

RiesgosRiesgos

Á• Ámbitos:– Estratégicos (objetivos, visión)g ( j , )

– Operativos (procesos, misión)

Proyectos– Proyectos

RiesgoRiesgo

i id ll• Los riesgos conocidos son aquellos que han sido identificados y analizados, es posible establecer un plan específico para atenderlos.

• Los riesgos desconocidos no pueden ser administrados, no obstante, , ,pueden atenderse mediante un plan de contingencia basado ende contingencia basado en experiencias.

RiesgoRiesgo

A i l i i l l i i• A nivel organizacional, los riesgos son vistos como amenazas al éxito de los proyectos. L i id d• Los riesgos que son considerados como amenazas pueden ser aceptados si estos están en balance con un beneficio que seestán en balance con un beneficio que se obtiene al tomar dichos riesgos (ej. reducción de tiempos y costos)reducción de tiempos y costos).

• Por su parte, los riesgos que se perciben como oportunidades se persiguen para elcomo oportunidades se persiguen para el beneficio de los objetivos del proyecto.

RiesgoRiesgo

l é i l i ió d b• Para el éxito, la organización debe estar comprometida a aplicar la administración de riesgos a lo largo de todos sus proyectos y en todos sus procesos.

• Una medida del compromiso porganizacional es su dedicación a reunir datos detallados sobre losreunir datos detallados sobre los riesgos y su caracterización.

DefinicionesDefiniciones

• De acuerdo con Project Management Body of Knowledge (PMBOK® 2004), la y f g ( )gestión del riesgo es:

“el proceso sistemático de identificarel proceso sistemático de identificar, analizar y responder a un riesgo de un

”proyecto, proceso o programa”.

DefinicionesDefiniciones

• El estándar ISO/IEC 73 utiliza el término de Gestión de Riesgo tanto gpara la gerencia (proceso de diseño, organización y coordinación de lasorganización y coordinación de las actividades) como para la gestión propiamente dicha (ejecución materialpropiamente dicha (ejecución material de dichas actividades).

Gestión del riesgoGestión del riesgo

b i li• Debe visualizarse como:– Política: Declaración realizada por la

i ió d i t i i i iorganización, de sus intenciones y principios con relación a un determinado tema que provee un marco para la acción y paraprovee un marco para la acción y para establecer objetivos y metas respecto del mismo.

– Doctrina: Compromiso y difusión de la metodología.

– Disciplina: Proceso continuo e integrado (transversal) al modelo de gestión.

PrincipiosPrincipios

• El estándar de gestión de riesgos se basa en la noción de que los riesgos q gdeben tratarse de forma proactiva, que la gestión de los riesgos formaque la gestión de los riesgos forma parte de un proceso formal y sistemático que debe considerarsesistemático que debe considerarse como una iniciativa positiva.

PrincipiosPrincipios

• Principios:– Adaptabilidadp

– Agilidad (proactividad)

Potenciar la comunicación– Potenciar la comunicación

– Aprender de todas las experiencias

– Responsabilidad compartida

– Proceso Integradog

– Proceso Continuo

ParadigmaParadigma

di j d• Un paradigma es un conjunto de teorías generales, suposiciones, leyes o técnicas del que se vale una escuela de análisis o comunidad científica para evaluar todas las cosas.

• Thomas Kuhn habla del "paradigma p gdominante" como el “conjunto de creencias compartidas o de sabiduríacreencias compartidas o de sabiduría convencional acerca de las cosas”.

ParadigmaParadigma

d d i i ió i• Proceso de Administración Continua del Riesgo (CRM, Continuous RiskManagement) del Instituto de Ingeniería de Software (SEI, CMU):– Identificar– Analizar– Planear– SeguirSeguir– Comunicar

ParadigmaParadigma

Capability Maturity ModelCapability Maturity Model

M d f i i ti d l• Marco de referencia prescriptivo del proceso de negocio y establece un conjunto de prácticas o procesos clave que se agrupan en p p q g páreas clave de proceso.

• En cada área de proceso se define un j t d b á ti d bconjunto de buenas prácticas que deben

definirse en un procedimiento documentado, proveer a la organización de los medios y p g yformación necesarios, ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas) medidas y finalmente(institucionalizadas), medidas y, finalmente, verificadas.

CMM y CRMCMM y CRM

Gestión de RiesgosGestión de Riesgos

• Incluye maximizar la probabilidad y consecuencias de eventos positivos y p yminimizar la probabilidad y consecuencias de eventos adversos aconsecuencias de eventos adversos a los objetivos de:

P– Proyectos

– Procesos

– Programas

Gestión de riesgosGestión de riesgos

i l d l d• Es una parte integral del proceso de administración.

• Es un proceso multifacético, aspectos apropiados del cual son a menudo p pllevados a cabo mejor por un equipo multidisciplinario. p

• Es un proceso iterativo de mejora continuacontinua.

ProcesoProceso

Establecer el contexto

Identificar los riesgos

Analizar los riesgos

Evaluar los riesgos

Tratar los riesgos

Establecer el contextoEstablecer el contexto

l d ió d l i• El proceso de gestión del riesgo ocurre dentro de la estructura del contexto t té i i i l destratégico, organizacional y de

administración de una organización. • Define los parámetros básicos dentro de los cuales deben administrarse los riesgos

í l d i iy proveen una guía para las decisiones. • Establece el alcance para el resto del proceso de gestión de riesgos.

Identificación de los riesgosIdentificación de los riesgos

b id ifi l i• Este paso busca identificar los riesgos a administrar.

• Según el PMBOK® 2004, “la identificación de los riesgos involucra gdeterminar cuáles riesgos pueden afectar un proyecto [o proceso] y p y [ p ] ydocumentar sus características”.

• Resultados: Riesgos Síntomas y• Resultados: Riesgos, Síntomas y Consecuencias

Identificación de los riesgosIdentificación de los riesgos

• Debe ejecutarse un proceso sistemático, bien estructurado, porque p qlos riesgos potenciales que no se identifican en esta etapa son excluidosidentifican en esta etapa son excluidos de un análisis posterior.

f ó b í l• La identificación debería incluir todos los riesgos, estén o no bajo control de la organización.

Clasificación de los riesgos basada en taxonomía

S d ili l l ifi i• Se pueden utilizar las clasificaciones o categorías de los riesgos, denominadas también taxonomías de riesgos para variostambién taxonomías de riesgos, para varios propósitos: – Durante la identificación de riesgos pueden– Durante la identificación de riesgos, pueden utilizarse para estimular el pensamiento sobre los riesgos que pueden producirse en las d á d ldistintas áreas del proyecto.

– Durante la puesta en común de ideas, aligeran la complejidad de trabajar con grandes cantidadescomplejidad de trabajar con grandes cantidades de riesgos porque los riesgos parecidos pueden incluirse en un mismo grupo.


– Para proporcionar una terminología unificada que el equipo de trabajo puede utilizar para supervisar y notificar el estado de los riesgos a lo largo del proyecto.

– Son muy útiles para establecer las bases de conocimiento de riesgo para empresas e industrias porque proporcionan la base para indexar nuevas contribuciones y buscar y recuperar información existente.


• Personas:– Clientes

– Usuarios finales

– Patrocinadores

– Participantes

– Personal

– Organización

– Conocimientos

– Políticas

– Moral


• Proceso:– Misión y metas– Toma de decisiones– Características del proyectop y– Presupuesto, costo y programación– RequerimientosRequerimientos– DiseñoCreación– Creación

– Pruebas


• Tecnología:– Seguridadg

– Entorno de desarrollo y prueba

Herramientas– Herramientas

– Implementación

– Soporte técnico

– Entorno operativop

– Disponibilidad


• Entorno:– Legalg

– Normativo

Competencia– Competencia

– Económico

– Tecnología

– Organizacionalg

Hitos de la identificaciónHitos de la identificación

i i i• Riesgos: Un riesgo constituye un evento (o condición) con cierta incertidumbre y si éste ocurre tiene un efecto positivo o negativo en los objetivos del proyecto o proceso.

• Disparadores: Se les llama a menudo p“síntomas del riesgo” o “señales de alarma” y son indicadores de que unalarma y son indicadores de que un riesgo está apunto de ocurrir.

Análisis de riesgosAnálisis de riesgos

L bj ti d áli i• Los objetivos de análisis son:– Separar los riesgos menores aceptables de los riesgos mayoresde los riesgos mayores.

– Proveer datos para asistir en la evaluación y tratamiento de los riesgosevaluación y tratamiento de los riesgos.

• El análisis de riesgos involucra prestar consideración a las fuentes de riesgosconsideración a las fuentes de riesgos, sus consecuencias y las probabilidades de que puedan ocurrir esas q pconsecuencias.


• Pueden identificarse los factores que afectan a las consecuencias y yprobabilidades.

• Se analiza el riesgo combinando• Se analiza el riesgo combinando estimaciones de consecuencias y

b b l l lprobabilidades en el contexto de las medidas de control existentes.


• Puede ser llevado con distintos grados de refinamiento dependiendo de la pinformación de riesgos y datos disponiblesdisponibles.

• Dependiendo de las circunstancias, el ál lanálisis puede ser cualitativo,

semicuantitativo o cuantitativo o una combinación de estos.

Tipos de análisisTipos de análisis

l áli i d i d ll d• El análisis de riesgos puede ser llevado con distintos grados de refinamiento dependiendo de la información de riesgos y datos disponibles.

• Dependiendo de las circunstancias, el análisis puede ser:p– Cualitativo– Semi‐cuantitativoSemi‐cuantitativo– Cuantitativo

Análisis cualitativoAnálisis cualitativo

Utili f t d l b l• Utiliza formatos de palabras o escalas descriptivas para describir la magnitud de las consecuencias potenciales y lade las consecuencias potenciales y la probabilidad de que esas consecuencias ocurranconsecuencias ocurran.

• Las escalas se pueden modificar o ajustar para adaptarlas a lasajustar para adaptarlas a las circunstancias, y se pueden utilizar distintas descripciones para riesgosdistintas descripciones para riesgos diferentes.


• Impacto del riesgo:– Calcula la gravedad de los efectos gadversos, la magnitud de una pérdida o el costo potencial de la oportunidad si el p priesgo llega a producirse dentro del proyecto. p y


NIVEL DESCRIPTOR EJEMPLO DE DESCRIPCIÓN DETALLADA

1 Insignificante Sin perjuicios, baja pérdida financiera.

Tratamiento de primeros auxilios liberado

2 MenorTratamiento de primeros auxilios, liberadolocalmente se contuvo inmediatamente,perdida financiera media.

Requiere tratamiento médico, liberado

3 Moderadoq ,

localmente pero contenido con asistenciaexterna, pérdida financianera alta.

Perjuicios extensivos pérdida de capacidad de

4 MayorPerjuicios extensivos, pérdida de capacidad deproducción, liberación externa, sin efectosnocivos, pérdida financiera mayor.

5 Catastrófico Muerte, liberación tóxica externa con efectosnocivos, enorme pérdida financiera.


P b bilid d d i• Probabilidad de riesgo:– Es una medida que calcula la probabilidad de que las consecuencias de los riesgos lleguen aque las consecuencias de los riesgos lleguen a producirse de verdad.

– Para clasificar los riesgos es recomendable la gasignación de un valor numérico a la probabilidad (Análisis Cuantitativo). L b bilid d d i d b– La probabilidad de un riesgo debe ser mayor que cero o el riesgo no representa una amenaza. Asimismo, la probabilidad debe ser menor que , p q100% o el riesgo es una certeza, en otras palabras, es un problema identificado.


NIVEL DESCRIPTOR DESCRIPCIÓN

A Casi certeza Se espera que ocurra en la mayoría delas circunstancias.

B Probable Probablemente ocurrirá en la mayoríade las circunstancias.

C Posible Podría ocurrir en algun momento.

D Improbable Pudo ocurrir en algun momento.

P d i i iE Raro Puede ocurrir en circunstanciasexcepcionales.


E i ió l i• Exposición al riesgo:– Calcula la amenaza general que supone el riesgo combinando la información que expresa lacombinando la información que expresa la probabilidad de una pérdida real con información que indica la magnitud de la pérdida potencial en un único valor numérico.

– El equipo puede usar la magnitud de la exposición al riesgo para clasificar los riesgosexposición al riesgo para clasificar los riesgos.

– En el caso más simple de análisis de riesgo cuantitativo, la exposición al riesgo se calcula , p gmultiplicando la probabilidad de riesgo por el impacto.


PROBABILIDAD:

CONSECUENCIAS:

Insignificantes Menores Moderadas Mayores Catastróficasg1 2 3

y4 6

A (C i t ) Alt Alt E t E t E tA (Casi certeza) Alto Alto Extremo Extremo Extremo

B (Probable) Medio Alto Alto Extremo ExtremoB (Probable) Medio Alto Alto Extremo Extremo

C (Posible) Bajo Medio Alto Extremo Extremo( )

D (Improbable) Bajo Bajo Medio Alto Extremo

E (Raro) Bajo Bajo Medio Alto Alto


NIVEL: CATEGORÍA: DESCRIPCIÓN:

Bajo Aceptable tal cual No requiere mitigación.j p q g

Medio Aceptable con controles

Se debe verificar que existancontroles para este riesgo y estén

ticontroles operativos.

Debe ser mitigado con controlesde ingeniería o administrativosAlto Indeseable de ingeniería o administrativosdentro de un período mínimo de12 meses.

Extremo Inaceptable

Debe ser mitigado con controlesde ingeniería o administrativosdentro de un período mínimo de 6meses.

Análisis cuantitativoAnálisis cuantitativo

ili l é i l• Utiliza valores numéricos para las consecuencias y probabilidades (en lugar de las escalas descriptivas utilizadas en los análisis cualitativos y semicuantitativos) utilizando datos de distintas fuentes.

• La calidad del análisis depende de la precisión e integridad de los valoresprecisión e integridad de los valores numéricos utilizados.

Análisis semi cuantitativoAnálisis semi‐cuantitativo

• En el análisis semi‐cuantitativo, a las escalas cualitativas, tales como las descritas anteriormente, se les asignan valoresvalores.

• Se generan funciones heurísticas b b lbasadas en umbrales para determinar el nivel de exposición del riesgo.

Evaluar los riesgosEvaluar los riesgos

i l i d d i• Comparar niveles estimados de riesgos contra los criterios preestablecidos.

• Posibilita que los riesgos sean ordenados como para identificar las pprioridades de administración.

• Si los niveles de riesgo establecidosSi los niveles de riesgo establecidos son bajos, los riesgos podrían caer en una categoría aceptable y no seuna categoría aceptable y no se requeriría un tratamiento para estos.

Tratar los riesgosTratar los riesgos

• Aceptar y monitorear los riesgos de baja prioridad. j p

• Para otros riesgos, desarrollar e implementar un plan deimplementar un plan de administración específico.

Opciones de TratamientoOpciones de Tratamiento

• Evitar el riesgo decidiendo no proceder con la actividad que probablemente generaría el riesgo (cuando esto es practicable).

• Reducir o controlar la probabilidad de la ocurrencia

• Reducir o controlar las consecuenciaseduc o co o a as co secue c as

• Transferir los riesgos

• Retener los riesgos• Retener los riesgos

• Aceptar los riesgos

EvitarEvitar

• Esta posición implica decidir, donde sea práctico, no proceder con p pservicios, proyectos, procesos y/o actividades que podrían generaractividades que podrían generar riesgos inaceptables, buscando con ello eludir el riesgo inherente asociadoello eludir el riesgo inherente asociado a esos objetos.

AceptarAceptar

• La posición ante este riesgo implica no lidiar con el mismo debido a que no se qquiere afectar el rendimiento o cambiar la planificación actual o secambiar la planificación actual o se desconoce un plan de tratamiento implementable para este riesgoimplementable para este riesgo.

ReducciónReducción

• La reducción o prevención del riesgo a través de la implementación de pacciones tendientes a controlar su frecuencia o probabilidadfrecuencia o probabilidad.

MitigarMitigar

• Esta posición implica acciones y actividades que se realizan con qanticipación para evitar que se produzca un riesgo o para reducir elproduzca un riesgo o para reducir el impacto o las consecuencias a un nivel aceptableaceptable.

DispersarDispersar

• La posición ante el riesgo implica decidir segmentar el objeto de negocio g j gsobre el cual recae la amenaza o distribuir la localización de los objetosdistribuir la localización de los objetos de negocio para que se vean menos afectadosafectados.

TransferirTransferir

• Esta posición involucra que otra parte soporte o comparta parte del riesgo. p p p gLos mecanismos incluyen el uso de contratos arreglos de seguros y/ocontratos, arreglos de seguros y/o referirlo a otras estructuras organizacionalesorganizacionales.

Comunicar y consultarComunicar y consultar

• Comunicar y consultar con interesados internos y externos según corresponda y g pen cada etapa del proceso de administración de riesgos yadministración de riesgos y concerniendo al proceso como un todotodo.

Monitoreo y revisiónMonitoreo y revisión

E i i l i l• Es necesario monitorear los riesgos, la efectividad del plan de tratamiento de los riesgos las estrategias y el sistema deriesgos, las estrategias y el sistema de administración que se establece para controlar la implementacióncontrolar la implementación.

• Los riesgos y la efectividad de las medidas de control necesitan ser monitoreadas parade control necesitan ser monitoreadas para asegurar que las circunstancias cambiantes no alteren las prioridades de los riesgos. p g

• Pocos riesgos permanecen estáticos.

Monitoreo y revisiónMonitoreo y revisión

• Es esencial una revisión sobre la marcha• Es esencial una revisión sobre la marcha para asegurar que el plan de administración se mantiene relevante.

• Pueden cambiar los factores que podrían afectar las probabilidades y consecuencias de un resultado, como también los factoresde un resultado, como también los factores que afectan la conveniencia o costos de las distintas opciones de tratamiento.

• En consecuencia es necesario repetir• En consecuencia, es necesario repetir regularmente el ciclo de administración de riesgos. La revisión es una parte integral del l d t t i t d l d i i t ió dplan de tratamiento de la administración de

riesgos.

Comunicación y consultaComunicación y consulta

L i ió l lt• La comunicación y la consulta son una consideración importante en cada paso del proceso de administración de riesgos.

• Es importante desarrollar un plan de comunicación para los interesados internos y externos en la etapa más temprana del proceso. p p

• Este plan debería encarar aspectos relativos al riesgo en si mismo y al proceso para administrarlo.

• La comunicación y consulta involucra un diálogo en• La comunicación y consulta involucra un diálogo en ambas direcciones entre los interesados, con el esfuerzo focalizado en la consulta más que un flujo d i f ió ól tid d l t d dde información en un sólo sentido del tomador de decisión hacia los interesados.


i ió f i i• La comunicación efectiva interna y externa es importante para asegurar que aquellos responsables por implementar la gestión de riesgos, y aquellos con intereses creados comprendan:– la base sobre la cual se toman las decisiones

– por qué se requieren ciertas acciones en particular.


L i d l i• Las percepciones de los riesgos pueden variar debido a diferencias en los supuestos conceptos laslos supuestos, conceptos, las necesidades, aspectos y preocupaciones de los interesadospreocupaciones de los interesados, según se relacionen con el riesgo o los aspectos bajo discusión. p j

• Los interesados probablemente harán juicios de aceptabilidad de los riesgosjuicios de aceptabilidad de los riesgos basados en su percepción de los mismos.


• Dado que los interesados pueden tener un impacto significativo en las p gdecisiones tomadas, es importante que sus percepciones de los riesgosque sus percepciones de los riesgos, así como, sus percepciones de los beneficios sean identificadas ybeneficios, sean identificadas y documentadas y las razones subyacentes para las mismas comprendidas y tenidas en cuenta.

DocumentaciónDocumentación

• Debería documentarse cada etapa del proceso de administración de riesgos. p g

• La documentación debería incluir los supuestos los métodos las fuentes desupuestos, los métodos, las fuentes de datos y los resultados.

DocumentaciónDocumentación

• Para administrar correctamente el riesgo, se requiere una documentación g qapropiada.

• Debe ser completa para satisfacer a• Debe ser completa para satisfacer a una auditoria independiente.

InstrumentosInstrumentos

Pl E é i Pl O i M• Planes Estratégicos, Planes Operativos, Mapas de procesos y planes de proyectos (WBS).F l i d id tifi ió d l ió• Formularios de identificación y declaración del riesgo

• Taxonomía de riesgo• Taxonomía de riesgo• Modelo de evaluaciónPl d ti i li ió d• Planes de contingencia y aplicación de opciones de tratamiento

• Matriz de riesgo• Matriz de riesgo• Diagrama de riesgo (mapa de riesgo)

DocumentosDocumentos

R i t d iRegistro de riesgos • Por cada riesgo identificado el registro de riesgo comprenderiesgo comprende:– Declaración.Ubicación en el contexto organizacional– Ubicación en el contexto organizacional.

– Síntomas/Disparadores– ConsecuenciasConsecuencias – Probabilidad e Impacto.– Nivel de exposición.p– Opciones de tratamiento y respuesta / controles existentes.

DocumentosDocumentos

P d t t i t d i l dPrograma de tratamiento de riesgos y plan de acción

• Un tratamiento de riesgos y plan de acciónUn tratamiento de riesgos y plan de acción documenta los controles gerenciales a adoptar y lista la siguiente información:– Responsables de la implementación del plan.– Recursos requeridos.Asignación de presupuesto– Asignación de presupuesto.

– Calendario de implementación.– Detalles del mecanismo y frecuencia de la yrevisión de cumplimiento del plan de tratamiento.

Declaración del riesgo (1)Declaración del riesgo (1)• Riesgo:• Riesgo:• R01 ‐ Cambio constante de los requerimientos técnicos• Tipo:• Organizacional• Fase:

– Análisis de Requerimientos – Impacto Mayor, Probabilidad Posible, Exposición: Alta– Diseño – Impacto: Mayor, Probabilidad: Posible, Exposición: Alta– Implementación – Impacto Moderado, Probabilidad Improbable, Exposición: Baja

• Descripción:• Debido a que el proceso de desarrollo de software se concibe bajo una metodología ágil se

presume la inestabilidad de los requerimientos. Además el usuario final tiene el poder de cambar de idea continuamente, sin importar el estado actual de los requerimientos pactados , p q ppara el sistema.

• Respuesta al riesgo:• Mitigar• Estrategia recomendada:

P d t d i i t b j d lid ió t li t ió• Proceso de captura de requerimientos bajo un esquema de validación y retroalimentación constante de la especificación actual de requerimientos del sistema. Se generarán prototipos funcionales y no funcionales para dotar al usuario de una vista preliminar del producto de cada etapa del proceso.

Declaración del riesgo (2)Declaración del riesgo (2)• Riesgo:• Riesgo:• R02 ‐ Planificación ambiciosa del calendario de trabajo• Tipo:• Organizacional• Fase:

– Gestión de Proyectos • Impacto Mayor, Probabilidad Improbable, Exposición: Media

• Descripción:L t d l í d d ll d ft i t d l ilid d l t• La metodología de desarrollo de software es orientada a la agilidad y la entrega constante de productos. El tiempo de entrega del producto final para cada proyecto es corto lo que predispone a que el proyecto falle por falta de tiempo para ejecutar las actividades críticas del proyecto, lo que supone excesiva presión para el equipo de trabajo.

• Respuesta al riesgo:– Mitigar

• Estrategia recomendada:• Reforzar el proceso de planificación y seguimiento (control) de forma eficiente, p p y g ( ) ,

siguiendo un modelo de planificación orientada a la complejidad, asumiendo adaptabilidad y gestión integrada del riesgo durante cada etapa de desarrollo e implementado medidas de control detalladas.

Declaración del riesgo (3)Declaración del riesgo (3)• Riesgo:• Riesgo:• R03 ‐ Implicación y participación de los usuarios.• Tipo:• Organizacional.• Fase:

– Elicitación de requerimientos: Impacto Mayor, Probabilidad Posible, Exposición: Alta– Análisis de requerimientos: Impacto Moderado, Probabilidad Improbable, Exposición: Baja– Diseño: Impacto Moderado, Probabilidad Improbable, Exposición: Baja– Implementación: Impacto Moderado, Probabilidad Posible, Exposición: Media

• Descripción:p• Durante un proceso de desarrollo de software la participación del usuario final es crucial para la

finalización exitosa del mismo. El usuario debe participar activamente en el proceso de desarrollo y no solo al inicio o al final, debe aportar ideas y retroalimentar al equipo de trabajo del proyecto, de lo contrario se producirá un alto grado de insatisfacción usuario al no obtener el producto con las especificaciones solicitadas. El usuario final es el que realmente conoce el p p qvalor que aportará el producto que está siendo desarrollado y puede definir las prioridades de los requerimientos.

• Respuesta al riesgo:• Mitigar• Estrategia recomendada:Estrategia recomendada:• Promover la participación activa del usuario final en el proceso de planificación y todas las

iteraciones del proceso de software para proveer la retroalimentación oportuna al equipo de desarrollo para garantizar el cumplimiento de los requerimientos solicitados y suministrar al mismo de la visibilidad permanente del estado del proyecto que asegurará su compromiso para terminarlo exitosamente.terminarlo exitosamente.

Declaración del riesgo (4)Declaración del riesgo (4)• Riesgo:• Riesgo:• R04 ‐ Gestión de riesgos insuficiente• Tipo:• Organizacional• Organizacional• Fase:

– Gestión de Proyectos – Impacto Moderado, Probabilidad Improbable, Exposición: Bajo

• Descripción:• El proceso de gestión de riesgos es relativamente está definido en la

Unidad de Informática y todavía está en proceso de implementación en el ámbito organizacionalen el ámbito organizacional.

• Respuesta al riesgo:• Mitigar• Estrategia recomendada:Estrategia recomendada:• Fortalecer la comunicación (mediante reuniones) para lograr la

identificación y tratamiento de los riesgos no identificados o emergentes durante el proceso de desarrollo.

Mapa de riesgosMapa de riesgos

MatrizMatrizRIESGO: RESPUESTA: PLAN DE ACCIÓN: RESPONSABLE(S):

Mitigar

Esta posición implica acciones y

Proceso de captura de requerimientos

bajo un esquema de validación y

retroalimentación constante de la

Cambio constante de los

requerimientos técnicos


actividades que se realizan con

anticipación para evitar que se

produzca un riesgo o para reducir

el impacto o las consecuencias a

especificación actual de

requerimientos del sistema. Se

generarán prototipos funcionales y no

funcionales para dotar al usuario de

una vista preliminar del producto de

Equipo de Análisis de

Requerimientos

un nivel aceptable.una vista preliminar del producto de

cada etapa del proceso.

Planificación ambiciosa del

Mitigar



Reforzar el proceso de planificación y

seguimiento (control) de forma

eficiente, siguiendo un modelo de

planificación orientada a la

calendario de trabajo anticipación para evitar que se

produzca un riesgo o para reducir

el impacto o las consecuencias a

un nivel aceptable.

complejidad, asumiendo adaptabilidad

y gestión integrada del riesgo durante

cada etapa de desarrollo e

implementado medidas de control

detalladas.

Administrador de Proyectos

MatrizMatriz

Miti

Promover la participación

activa del usuario final en el

proceso de planificación y

todas las iteraciones del

proceso de software para

Implicación y

participación de los

usuarios

Mitigar




produzca un riesgo o para reducir el

proveer la retroalimentación

oportuna al equipo de

desarrollo para garantizar el

cumplimiento de los

requerimientos solicitados y

Patrocinador


A it t d S ftusuariosimpacto o las consecuencias a un

nivel aceptable.

requerimientos solicitados y

suministrar al mismo de la

visibilidad permanente del

estado del proyecto que

asegurará su compromiso

Arquitecto de Software

para terminarlo

exitosamente.

Mitigar Fortalecer la comunicación

Gestión de riesgos

insuficiente




produzca un riesgo o para reducir el

impacto o las consecuencias a un

(mediante reuniones) para

lograr la identificación y

tratamiento de los riesgos

no identificados o

emergentes durante el


impacto o las consecuencias a un

nivel aceptable.

g

proceso de desarrollo.

MatrizMatriz

Generar un plan de pruebas

Mitigar

unitarias y de integración para

asegurar que el código se

comporta según lo esperado.

Asumir la propiedad colectiva del

ód d l

Problemas

inesperados en la

etapa de integración

Esta posición implica acciones

y actividades que se realizan

con anticipación para evitar

que se produzca un riesgo o

para reducir el impacto o las

código para que todo el equipo

de trabajo sea responsable por

su correctitud y efectividad y

añadir o modificar porciones al

mismo

Arquitecto de software

p p

consecuencias a un nivel

aceptable.

mismo.

Procurar la integración continua

para reducir el impacto de la

incorporación de nuevasincorporación de nuevas

funcionalidades.

Caso de Estudio

Sistema Integrado de Gestión y Medición Adaptativas(SIGMA/SEVRI|P)

Instituto Costarricense sobre Drogas

Gestión del RiesgoGestión del Riesgo

• En el Instituto Costarricense sobre drogas involucra:g– Normativa

Política– Política

– Marco orientador (metodología)

– Software

NormativaNormativa

• Ley General de Control Interno.

• Manual de Normas Generales de Control Interno para la Contraloría General de la República y las entidades y órganosRepública y las entidades y órganos sujetos a su fiscalización.

Di t i G l l• Directrices Generales para el Establecimiento y Funcionamiento del Si ífi d l ió d lSistema Específico de Valoración del Riesgo Institucional (SEVRI).

PolíticaPolítica

“P l li i t f ti• “Procurar el cumplimiento efectivo y eficiente de la misión y objetivos institucionales mediante una estrategia gcontinua e integrada de gestión de riesgos en todos los procesos institucionales y la constitución de un marco de trabajoconstitución de un marco de trabajo sistematizado y estandarizado, permanente, proactivo y sustentable que involucre el establecimiento del contexto organizacional, la identificación, el análisis, la evaluación, el tratamiento, la comunicación y el monitoreotratamiento, la comunicación y el monitoreo en curso de los riesgos”.

ResponsabilidadesResponsabilidades

• La gestión del riesgo es una responsabilidad compartida por todas p p plas unidades funcionales del Instituto Costarricense sobre DrogasCostarricense sobre Drogas.

• La coordinación del desarrollo y l bmantenimiento del marco de trabajo y

orientador será responsabilidad de la Comisión Institucional del Riesgo

ResponsabilidadesResponsabilidades

f d id d di i l ió d• Los Jefes de Unidad, dirigen la gestión de riesgos en cada uno de los procesos y son l bl l i l t iólos responsables por la implementación de controles y mecanismos de evaluación de su efectividadde su efectividad.

• Todos los funcionarios son responsables d l d ió d l i d lde la reducción de los riesgos y de velar por la eficacia de los controles integrados

l ti id d ten los procesos, actividades y tareas a su cargo.

ComisiónComisión

R t t d l C j Di ti• Representante del Consejo Directivo.• Representante de la Dirección.

( )• Planificador(a) institucional.• Jefe de la unidad administrativa / fi ifinanciera.

• Jefe de la unidad de tecnología de la i f ióinformación.

• Jefe representante de las unidades sustantivassustantivas.

• Asesor(a) legal.

ImplementaciónImplementación

Marco orientadorMarco orientador

P i i i bá i• Principios básicos• Conceptos• Descripción del proceso

– Establecimiento del contextod ifi ió d f d i– Identificación de fuentes de riesgo

– Identificación de riesgosAnálisis– Análisis

– Tratamiento– Monitoreo y Revisión– Monitoreo y Revisión– Comunicación

SoftwareSoftware

• Contexto– Ejecución: Procesos / Proyectosj / y

• Etapas (hitos)

• ArtefactosArtefactos– Actividades

» Procedimientos (tareas)

» Roles y responsabilidades

» Elementos de incertidumbre

SoftwareSoftware

• Administra las fuentes de riesgo– Modelo de clasificación del riesgo en gmúltiples “sabores” de taxonomías:

• General (ICD)General (ICD)

• Operativo (SEI)

• Software (SEI)Software (SEI)

• Proyectos (PMI)

SoftwareSoftware

d i i i• Administra riesgos– Declaraciones– Síntomas– Consecuencias– Respuestas– RelacionesRelaciones– Planes de tratamientoResponsabilidades– Responsabilidades

– Autoevaluación

SoftwareSoftware

• Visualización de niveles de exposición– Por unidad, proceso, etapa o actividad, p , p

– Representación icónica (metáfora: estado del tiempo)del tiempo).

– Árbol o mapa del riesgo

l d l i– Consola del riesgo

– Riesgo Inherente vs. Residual

ModeloModelo

fi i f l l d d• Definir formalmente los procesos de cada una de las Unidades.

• Implementa en 2007 un modelo de proceso de gestión del riesgo integrado a todos los procesos institucionales.

• Utilizar una herramienta informática para la gestión y control del riesgo.

• Participación activa de todos los pfuncionarios en la identificación y tratamiento de los riesgos.g

¡Gracias!

BibliografíaBibliografía

R ld P Hi Y Y H i• Ronald P. Higuera y Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report CMU/SEI‐96‐TR‐012 ESC‐96‐012Report CMU/SEI 96 TR 012 ESC 96 012 (Pittsburgh, PA: Software Engineering Institute—Universidad Carnegie Mellon, 19961996.

• Marvin J. Carr y otros, “Taxonomy‐Based Risk Identification” SEI Technical ReportRisk Identification , SEI Technical Report CMU/SEI‐93‐TR‐6 ESC‐TR‐93‐183 (Pittsburgh, PA: Software Engineering Institute—Universidad Carnegie Mellon, 1993.


G S b “Ri k• Gary Stoneburner y otros. “Risk Management Guide for Information Technology Systems” Recommendations ofTechnology Systems . Recommendations of the National Institute of Standards and Technology SP 800–30 National Institute ofTechnology SP 800 30. National Institute of Standards and Technology. 2002

• Project Management Institute IncProject Management Institute Inc. (www.pmi.org). “A guide to project management body of knowledge (PMBOK® g y g (Guide)”. Edición 2004. Pennsylvania, EUA. 2004.


Ri h d L M h Ch i t h J Alb t R• Richard L. Murphy; Christopher J. Alberts; RayC. Williams; Ronald P. Higuera; Audrey J. Dorofee; & Julie A. Walker. Continuous Risk;Management Guidebook, SEI, Carnegie Mellon University, 2008.T h i l N t A P d T f• Technical Note ‐ A Proposed Taxonomy forSoftware Development Risks for High‐Performance Computing (HPC) Scientific‐p g ( )Engineering Applications, Kendall, Richard P.; Post, Douglass E.; Carver, Jeffrey C.; Henderson Dale B ; and Fisher David AHenderson, Dale B.; and Fisher, David A., CMU/SEI‐2006‐TN‐039, April 2007


T h i l N t Ri k M t• Technical Note ‐ Risk Management Considerations for Interoperable Acquisition, Meyers, B. Craig, CMU/SEI‐2006‐TN‐032, y , g, / ,March 2007.

• Technical Note ‐ Common Elements of Risk, Alb t Ch i t h J CMU/SEI 2006 TNAlberts, Christopher J., CMU/SEI‐2006‐TN‐014, April 2006

• Technical Note ‐Mission Assurance AnalysisTechnical Note ‐Mission Assurance AnalysisProtocol (MAAP): Assessing Risk in ComplexEnvironments, Alberts, Christopher and D f A d CMU/SEI 2005 TN 032Dorofee, Audrey, CMU/SEI‐2005‐TN‐032, October 2005


T h i l N t A T f O ti l Ri k• Technical Note ‐ A Taxonomy of Operational Risks, Gallagher, Brian P.; Case. Pamela J.; Creel, Rita C.; Kushner, Susan; and Williams, Ray C., CMU/SEI‐2005‐TN‐036, September 2005

• A Roadmap of Risk Diagnostic Methods: Developing an Integrated View of RiskDeveloping an Integrated View of RiskIdentification and Analysis, Williams, Ray C.; Ambrose, Kate; and Bentrem, Laura, CMU/SEI‐2004 TN 002 September 20042004‐TN‐002, September 2004

• Risk Based Diagnostics, Williams, Ray C.; Ambrose, Kate; Bentrem, Laura; and Merendino, Tom, CMU/SEI‐2004‐TN‐013, September 2004


T h i l R t Ri k Th Di d• Technical Report ‐ Risk Themes DiscoveredThrough Architecture Evaluations, Bass, Len; Nord, Robert; Wood, William; and Zubrow, , ; , ; ,David, CMU/SEI‐2006‐TR‐012, October 2006

• Technical Report ‐ Techniques for DevelopingA i iti St t b P fili S ftan Acquisition Strategy by Profiling Software

Risks, Ward, Mary Catherine; Elm, Joseph P.; and Kushner, Susan, CMU/SEI‐2006‐TR‐002, , , / ,August 2006

• Software Risk Evaluation Method Description ‐V i 2 0 Willi R C P d li G PVersion 2.0, Williams, R.C.; Pandelios, G.P.; and Behrens, S.G., CMU/SEI‐99‐TR‐029


db k f i i i i k• Handbook‐ Software Acquisition RiskManagement Key Process Area (KPA): A Guidebook, Version 1.02. Gallagher, Brian, CMU/SEI‐99‐HB‐002, October1999

• An Experiment in Software pDevelopment Risk InformationAnalysis Monarch, Ira, CMU/SEI‐95‐TR‐Analysis Monarch, Ira, CMU/SEI 95 TR014

gr 004.pdf

Documents