Re

Gestión del riesgo
Ing. Felipe Ramírez Herrera
Jefe, Unidad de InformáticaJefe, Unidad de Informática
Instituto 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 g
deben 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 ) y
si é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 j
proyecto/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 p
organizacional 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 g
para 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 g
deben 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 g
dominante" 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 Risk
Management) del Instituto de
Ingeniería de Software (SEI, CMU):
– Identificar
– Analizar
– Planear
– SeguirSeguir
– Comunicar

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 y
formación necesarios, ejecutadas de un modo
sistemático, universal y uniforme
(institucionalizadas) medidas y finalmente(institucionalizadas), medidas y, finalmente,
verificadas.

Gestión de RiesgosGestión de Riesgos
• Incluye maximizar la probabilidad y
consecuencias de eventos positivos y p y
minimizar 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 p
llevados 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 g
determinar cuáles riesgos pueden
afectar un proyecto [o proceso] y p y [ p ] y
documentar 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 q
los 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.

en taxonomía
– 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.

en taxonomía
• Personas:
– Clientes
– Usuarios finales
– Patrocinadores
– Participantes
– Personal
– Organización
– Conocimientos
– Políticas
– Moral

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

en taxonomía
• Tecnología:
– Seguridadg
– Entorno de desarrollo y prueba
Herramientas– Herramientas
– Implementación
– Soporte técnico
– Entorno operativop
– Disponibilidad

en taxonomía
• 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 p
consecuencias.

• Pueden identificarse los factores que
afectan a las consecuencias y y
probabilidades.
• 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 p
informació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 g
adversos, la magnitud de una pérdida o el
costo potencial de la oportunidad si el p p
riesgo 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 Menor
Tratamiento de primeros auxilios, liberado
localmente se contuvo inmediatamente,
perdida financiera media.
Requiere tratamiento médico, liberado
3 Moderado
q ,
localmente pero contenido con asistencia
externa, pérdida financianera alta.
Perjuicios extensivos pérdida de capacidad de
4 Mayor
Perjuicios extensivos, pérdida de capacidad de
producción, liberación externa, sin efectos
nocivos, pérdida financiera mayor.
5 Catastrófico
Muerte, liberación tóxica externa con efectos
nocivos, 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 g
asignació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 q
100% 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 de
las circunstancias.
B Probable
Probablemente ocurrirá en la mayoría
de las circunstancias.
C Posible Podría ocurrir en algun momento.
D Improbable Pudo ocurrir en algun momento.
P d i i i
E Raro
Puede ocurrir en circunstancias
excepcionales.

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 g
multiplicando la probabilidad de riesgo por el
impacto.

PROBABILIDAD:
CONSECUENCIAS:
Insignificantes Menores Moderadas Mayores Catastróficasg
1 2 3
y
4 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 existan
controles para este riesgo y estén
ti
controles
operativos.
Debe ser mitigado con controles
de ingeniería o administrativos
Alto Indeseable
dentro de un período mínimo de
12 meses.
Extremo Inaceptable
Debe ser mitigado con controles
dentro de un período mínimo de 6
meses.

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 p
prioridades 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 p
servicios, 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 q
quiere 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 p
acciones tendientes a controlar su
frecuencia o probabilidadfrecuencia o probabilidad.

MitigarMitigar
• Esta posición implica acciones y
actividades que se realizan con q
anticipació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 g
sobre 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 g
Los 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 p
en 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 g
decisiones 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 q
apropiada.
• 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ón
Pl 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 y
revisió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 p
para 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.

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

• 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 q
valor que aportará el producto que está siendo desarrollado y puede definir las prioridades de
los requerimientos.
• 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.

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

MatrizMatriz
RIESGO: 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
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 ftusuarios
impacto 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
(mediante reuniones) para
lograr la identificación y
tratamiento de los riesgos
no identificados o
emergentes durante el
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 g
continua 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 p
las 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 contexto
d ifi ió d f d i– Identificación de fuentes de riesgo
– Identificación de riesgos
Aná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 g
mú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 tratamiento
Responsabilidades– 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 p
funcionarios en la identificación y
tratamiento de los riesgos.g

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; Ray
C. 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 for
Software 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 Analysis
Protocol (MAAP): Assessing Risk in Complex
Environments, 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 Risk
Identification 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 Discovered
Through Architecture Evaluations, Bass, Len;
Nord, Robert; Wood, William; and Zubrow, , ; , ; ,
David, CMU/SEI‐2006‐TR‐012, October 2006
• Technical Report ‐ Techniques for Developing
A 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 Risk
Management Key Process Area (KPA):
A Guidebook, Version 1.02. Gallagher,
Brian, CMU/SEI‐99‐HB‐002, October
1999
• An Experiment in Software p
Development Risk Information
Analysis Monarch, Ira, CMU/SEI‐95‐TR‐Analysis Monarch, Ira, CMU/SEI 95 TR
014

Re

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Re

Similar a Re (20)

Re