2. Estándar
• El estándar de gestión de riesgos se
q g
basa en la noción de que los riesgos
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
debe considerarse como una iniciativa
b
positiva.
3. Referencias
• Software Engineering Institute:
• Continuous Risk Management (proceso)
• Team Risk Management (implementación
conjunta de proceso)
• Instituto Australiano de
Estandarización:
• AS/NZS 4360 Risk Management Standard
• S b
Sarbanes‐Oxley Act, Section 404
O l A t S ti 404
• ISO/IEC Guide 73:2002
/
4. Riesgo
• 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 del
o negativo en los objetivos del
proyecto.
• Un riesgo tiene una causa y, en caso de
ocurrencia, también implica una
consecuencia” (PMBOK® 2004).
5. Riesgo
• Un riesgo implica simultáneamente
j
amenazas a los objetivos de un
proyecto/proceso y a la vez
oportunidades para mejorar dichos
oportunidades para mejorar dichos
objetivos.
• Los riesgos tienen su origen en la
l
incertidumbre que está presente en
todos los proyectos/procesos.
6. Riesgos
• Á
Ámbitos:
– Estratégicos (objetivos, visión)
g ( j , )
– Operativos (procesos, misión)
– Proyectos
7. Riesgo
• Los riesgos conocidos son aquellos que
i id ll
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 en
de contingencia basado en
experiencias.
8. Riesgo
• A i l
A nivel organizacional, los riesgos son vistos
i i l l i i
como amenazas al éxito de los proyectos.
• L i
Los riesgos que son considerados como
id d
amenazas pueden ser aceptados si estos
están en balance con un beneficio que se
está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 el
como oportunidades se persiguen para el
beneficio de los objetivos del proyecto.
9. Riesgo
• Para el éxito, la organización debe
lé i l i ió d b
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 los
reunir datos detallados sobre los
riesgos y su caracterización.
10. Definiciones
• De acuerdo con Project Management
y f g ( )
Body of Knowledge (PMBOK® 2004), la
gestión del riesgo es:
“el proceso sistemático de identificar
el proceso sistemático de identificar,
analizar y responder a un riesgo de un
proyecto, proceso o programa”. ”
11. Definiciones
• El estándar ISO/IEC 73 utiliza el
g
término de Gestión de Riesgo tanto
para la gerencia (proceso de diseño,
organización y coordinación de las
organización y coordinación de las
actividades) como para la gestión
propiamente dicha (ejecución material
propiamente dicha (ejecución material
de dichas actividades).
12. Gestión del riesgo
Gestión del riesgo
• Debe visualizarse como:
b i li
– Política: Declaración realizada por la
organización, de sus intenciones y principios
i ió d i t i i i i
con relación a un determinado tema que
provee un marco para la acción y para
provee 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.
13. Principios
• El estándar de gestión de riesgos se
q g
basa en la noción de que los riesgos
deben tratarse de forma proactiva,
que la gestión de los riesgos forma
que la gestión de los riesgos forma
parte de un proceso formal y
sistemático que debe considerarse
sistemático que debe considerarse
como una iniciativa positiva.
14. Principios
• Principios:
– Adaptabilidad
p
– Agilidad (proactividad)
– Potenciar la comunicación
Potenciar la comunicación
– Aprender de todas las experiencias
– Responsabilidad compartida
– Proceso Integrado
g
– Proceso Continuo
15. Paradigma
• Un paradigma es un conjunto de
di j d
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ía
creencias compartidas o de sabiduría
convencional acerca de las cosas”.
16. Paradigma
• Proceso de Administración Continua
d d i i ió i
del Riesgo (CRM, Continuous Risk
Management) del Instituto de
Ingeniería de Software (SEI, CMU):
– Identificar
– Analizar
– Planear
– Seguir
– Comunicar
18. Capability Maturity Model
Capability Maturity Model
• M
Marco de referencia prescriptivo d l
d f i i ti del proceso
de negocio y establece un conjunto de
p
prácticas o procesos clave que se agrupan en
p q g p
áreas clave de proceso.
• En cada área de proceso se define un
conjunto de buenas prácticas que deben
j t d b á ti d b
definirse en un procedimiento documentado,
p
proveer a la organización de los medios y
g y
formación necesarios, ejecutadas de un modo
sistemático, universal y uniforme
(institucionalizadas), medidas y, finalmente,
(institucionalizadas) medidas y finalmente
verificadas.
20. Gestión de Riesgos
Gestión de Riesgos
• Incluye maximizar la probabilidad y
p
consecuencias de eventos positivos y y
minimizar la probabilidad y
consecuencias de eventos adversos a
consecuencias de eventos adversos a
los objetivos de:
–PProyectos
– Procesos
– Programas
21. Gestión de riesgos
Gestión de riesgos
• Es una parte integral del proceso de
i ld l d
administración.
• Es un proceso multifacético, aspectos
p p
apropiados del cual son a menudo
llevados a cabo mejor por un equipo
p
multidisciplinario.
• Es un proceso iterativo de mejora
continua.
continua
22. Proceso
Establecer el
contexto
Identificar los
riesgos
Analizar los
riesgos
Evaluar los riesgos
Tratar los riesgos
23. Establecer el contexto
Establecer el contexto
• El proceso de gestión del riesgo ocurre
l d ió d l i
dentro de la estructura del contexto
estratégico, organizacional y de
t té i i i l d
administración de una organización.
• Define los parámetros básicos dentro de
los cuales deben administrarse los riesgos
y proveen una guía para las decisiones.
í l d ii
• Establece el alcance para el resto del
proceso de gestión de riesgos.
24. Identificación de los riesgos
Identificación de los riesgos
• Este paso busca identificar los riesgos
b id ifi l i
a administrar.
• Según el PMBOK® 2004, “la
g
identificación de los riesgos involucra
determinar cuáles riesgos pueden
p y [ p ]y
afectar un proyecto [o proceso] y
documentar sus características”.
• Resultados: Riesgos Síntomas y
Resultados: Riesgos, Síntomas y
Consecuencias
25. Identificación de los riesgos
Identificación de los riesgos
• Debe ejecutarse un proceso
p q
sistemático, bien estructurado, porque
los riesgos potenciales que no se
identifican en esta etapa son excluidos
identifican en esta etapa son excluidos
de un análisis posterior.
• La identificación debería incluir todos
f ó b í l
los riesgos, estén o no bajo control de
la organización.
26. Clasificación de los riesgos basada
en taxonomía
• S
Se pueden utilizar las clasificaciones o
d ili l l ifi i
categorías de los riesgos, denominadas
también taxonomías de riesgos, para varios
tambié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
distintas áreas del proyecto.
d á d l
– Durante la puesta en común de ideas, aligeran la
complejidad de trabajar con grandes cantidades
complejidad de trabajar con grandes cantidades
de riesgos porque los riesgos parecidos pueden
incluirse en un mismo grupo.
27. Clasificación de los riesgos basada
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.
28. Clasificación de los riesgos basada
en taxonomía
• Personas:
– Clientes
– Usuarios finales
– Patrocinadores
– Participantes
– Personal
– Organización
– Conocimientos
– Políticas
– Moral
29. Clasificación de los riesgos basada
en taxonomía
• Proceso:
– Misión y metas
– Toma de decisiones
– Características del proyecto
p y
– Presupuesto, costo y programación
– Requerimientos
– Diseño
– Creación
– Pruebas
30. Clasificación de los riesgos basada
en taxonomía
• Tecnología:
– Seguridad
g
– Entorno de desarrollo y prueba
– Herramientas
– Implementación
– Soporte técnico
– Entorno operativo
p
– Disponibilidad
32. Hitos de la identificación
Hitos de la identificación
• Riesgos: Un riesgo constituye un
i i i
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 un
alarma” y son indicadores de que un
riesgo está apunto de ocurrir.
33. Análisis de riesgos
Análisis de riesgos
• L
Los objetivos de análisis son:
bj ti d áli i
– Separar los riesgos menores aceptables
de los riesgos mayores.
de los riesgos mayores
– Proveer datos para asistir en la
evaluación y tratamiento de los riesgos.
evaluación y tratamiento de los riesgos
• El análisis de riesgos involucra prestar
consideración a las fuentes de riesgos,
consideración a las fuentes de riesgos
sus consecuencias y las probabilidades
de que puedan ocurrir esas
q p
consecuencias.
34. Análisis de riesgos
Análisis de riesgos
• Pueden identificarse los factores que
y
afectan a las consecuencias y
probabilidades.
• Se analiza el riesgo combinando
Se analiza el riesgo combinando
estimaciones de consecuencias y
probabilidades en el contexto de las
b bl l l
medidas de control existentes.
35. Análisis de riesgos
Análisis de riesgos
• Puede ser llevado con distintos grados
p
de refinamiento dependiendo de la
información de riesgos y datos
disponibles.
disponibles
• Dependiendo de las circunstancias, el
análisis puede ser cualitativo,
ál l
semicuantitativo o cuantitativo o una
combinación de estos.
36. Tipos de análisis
Tipos de análisis
• El análisis de riesgos puede ser llevado
l áli i d i d ll d
con distintos grados de refinamiento
dependiendo de la información de
riesgos y datos disponibles.
• Dependiendo de las circunstancias, el
p
análisis puede ser:
– Cualitativo
– Semi‐cuantitativo
– Cuantitativo
37. Análisis cualitativo
Análisis cualitativo
• Utili f
Utiliza formatos de palabras o escalas
t d l b l
descriptivas para describir la magnitud
de las consecuencias potenciales y la
de las consecuencias potenciales y la
probabilidad de que esas
consecuencias ocurran.
consecuencias ocurran
• Las escalas se pueden modificar o
ajustar para adaptarlas a las
ajustar para adaptarlas a las
circunstancias, y se pueden utilizar
distintas descripciones para riesgos
distintas descripciones para riesgos
diferentes.
38. Análisis cualitativo
Análisis cualitativo
• 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
p y
proyecto.
39. Análisis cualitativo
Análisis cualitativo
NIVEL DESCRIPTOR EJEMPLO DE DESCRIPCIÓN DETALLADA
1 Insignificante Sin perjuicios, baja pérdida financiera.
Tratamiento de primeros auxilios liberado
auxilios,
2 Menor localmente se contuvo inmediatamente,
perdida financiera media.
Requiere
q tratamiento médico, , liberado
3 Moderado localmente pero contenido con asistencia
externa, pérdida financianera alta.
Perjuicios extensivos pérdida de capacidad de
extensivos,
4 Mayor producción, liberación externa, sin efectos
nocivos, pérdida financiera mayor.
Muerte, liberación tóxica externa con efectos
5 Catastrófico
nocivos, enorme pérdida financiera.
40. Análisis cualitativo
Análisis cualitativo
• P b bilid d d i
Probabilidad de riesgo:
– Es una medida que calcula la probabilidad de
que las consecuencias de los riesgos lleguen a
que 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).
–LLa probabilidad de un riesgo debe ser mayor que
b bilid d d i d b
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.
41. Análisis cualitativo
Análisis cualitativo
NIVEL DESCRIPTOR DESCRIPCIÓN
Se espera que ocurra en la mayoría de
A Casi certeza
las circunstancias.
Probablemente ocurrirá en la mayoría
B Probable
de las circunstancias.
C Posible Podría ocurrir en algun momento.
D Improbable Pudo ocurrir en algun momento.
Puede
P d ocurrir
i en circunstancias
i i
E Raro
excepcionales.
42. Análisis cualitativo
Análisis cualitativo
• E
Exposición al riesgo:
i ió l i
– Calcula la amenaza general que supone el riesgo
combinando la información que expresa la
combinando 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 riesgos.
exposició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.
43. Análisis cualitativo
Análisis cualitativo
CONSECUENCIAS:
PROBABILIDAD:
Insignificantes
g Menores Moderadas Mayores
y Catastróficas
1 2 3 4 6
A (C i certeza)
(Casi t ) Alto
Alt Alto
Alt Extremo
E t Extremo
E t Extremo
E t
B (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
44. Análisis cualitativo
Análisis cualitativo
NIVEL: CATEGORÍA: DESCRIPCIÓN:
Bajo
j Aceptable tal cual
p No requiere mitigación.
q g
Se debe verificar que existan
Aceptable con
Medio controles para este riesgo y estén
controles
operativos.
ti
Debe ser mitigado con controles
de ingeniería o administrativos
Alto Indeseable
dentro de un período mínimo de
12 meses.
Debe ser mitigado con controles
de ingeniería o administrativos
Extremo Inaceptable
dentro de un período mínimo de 6
meses.
45. Análisis cuantitativo
Análisis cuantitativo
• Utiliza valores numéricos para las
ili l éi l
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 valores
precisión e integridad de los valores
numéricos utilizados.
46. Análisis semi‐cuantitativo
Análisis semi cuantitativo
• En el análisis semi‐cuantitativo, a las
escalas cualitativas, tales como las
descritas anteriormente, se les asignan
valores.
valores
• Se generan funciones heurísticas
basadas en umbrales para determinar
b b l
el nivel de exposición del riesgo.
47. Evaluar los riesgos
Evaluar los riesgos
• Comparar niveles estimados de riesgos
i l i d d i
contra los criterios preestablecidos.
• Posibilita que los riesgos sean
p
ordenados como para identificar las
prioridades de administración.
• Si los niveles de riesgo establecidos
Si los niveles de riesgo establecidos
son bajos, los riesgos podrían caer en
una categoría aceptable y no se
una categoría aceptable y no se
requeriría un tratamiento para estos.
48. Tratar los riesgos
Tratar los riesgos
• Aceptar y monitorear los riesgos de
j p
baja prioridad.
• Para otros riesgos, desarrollar e
implementar un plan de
implementar un plan de
administración específico.
49. Opciones de Tratamiento
Opciones 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
educ o co o a as co secue c as
• Reducir o controlar las consecuencias
• Transferir los riesgos
• Retener los riesgos
Retener los riesgos
• Aceptar los riesgos
50. Evitar
• Esta posición implica decidir, donde
p p
sea práctico, no proceder con
servicios, proyectos, procesos y/o
actividades que podrían generar
actividades que podrían generar
riesgos inaceptables, buscando con
ello eludir el riesgo inherente asociado
ello eludir el riesgo inherente asociado
a esos objetos.
51. Aceptar
• La posición ante este riesgo implica no
q
lidiar con el mismo debido a que no se
quiere afectar el rendimiento o
cambiar la planificación actual o se
cambiar la planificación actual o se
desconoce un plan de tratamiento
implementable para este riesgo.
implementable para este riesgo
53. Mitigar
• Esta posición implica acciones y
q
actividades que se realizan con
anticipación para evitar que se
produzca un riesgo o para reducir el
produzca un riesgo o para reducir el
impacto o las consecuencias a un nivel
aceptable.
aceptable
54. Dispersar
• La posición ante el riesgo implica
g j g
decidir segmentar el objeto de negocio
sobre el cual recae la amenaza o
distribuir la localización de los objetos
distribuir la localización de los objetos
de negocio para que se vean menos
afectados.
afectados
55. Transferir
• Esta posición involucra que otra parte
p p p g
soporte o comparta parte del riesgo.
Los mecanismos incluyen el uso de
contratos, arreglos de seguros y/o
contratos arreglos de seguros y/o
referirlo a otras estructuras
organizacionales.
organizacionales
56. Comunicar y consultar
Comunicar y consultar
• Comunicar y consultar con interesados
y g p
internos y externos según corresponda
en cada etapa del proceso de
administración de riesgos y
administración de riesgos y
concerniendo al proceso como un
todo.
todo
57. Monitoreo y revisión
Monitoreo y revisión
• E
Es necesario monitorear los riesgos, la
i i l i l
efectividad del plan de tratamiento de los
riesgos, las estrategias y el sistema de
riesgos las estrategias y el sistema de
administración que se establece para
controlar la implementación.
controlar la implementación
• Los riesgos y la efectividad de las medidas
de control necesitan ser monitoreadas para
de control necesitan ser monitoreadas para
asegurar que las circunstancias cambiantes
no alteren las prioridades de los riesgos.
p g
• Pocos riesgos permanecen estáticos.
58. Monitoreo y revisión
Monitoreo 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 factores
de 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
plan de tratamiento de la administración de
l d t t i t d l d i i t ió d
riesgos.
59. Comunicación y consulta
Comunicación y consulta
• L
La comunicación y la consulta son una
i ió l lt
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
de información en un sólo sentido del tomador de
d i f ió ól tid d l t d d
decisión hacia los interesados.
60. Comunicación y consulta
Comunicación y consulta
• La comunicación efectiva interna y
i ió f i i
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.
61. Comunicación y consulta
Comunicación y consulta
• L
Las percepciones de los riesgos
i d l i
pueden variar debido a diferencias en
los supuestos, conceptos, las
los supuestos conceptos las
necesidades, aspectos y
preocupaciones de los interesados,
preocupaciones 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 riesgos
juicios de aceptabilidad de los riesgos
basados en su percepción de los
mismos.
62. Comunicación y consulta
Comunicación y consulta
• Dado que los interesados pueden
p g
tener un impacto significativo en las
decisiones tomadas, es importante
que sus percepciones de los riesgos,
que sus percepciones de los riesgos
así como, sus percepciones de los
beneficios, sean identificadas y
beneficios sean identificadas y
documentadas y las razones
subyacentes para las mismas
comprendidas y tenidas en cuenta.
63. Documentación
• Debería documentarse cada etapa del
p
proceso de administración de riesgos.
g
• La documentación debería incluir los
supuestos, los métodos, las fuentes de
supuestos los métodos las fuentes de
datos y los resultados.
64. Documentación
• Para administrar correctamente el
g q
riesgo, se requiere una documentación
apropiada.
• Debe ser completa para satisfacer a
Debe ser completa para satisfacer a
una auditoria independiente.
65. Instrumentos
• Pl
Planes Estratégicos, Planes Operativos, Mapas
E é i Pl O i M
de procesos y planes de proyectos (WBS).
• F
Formularios de identificación y declaración
l i d id tifi ió d l ió
del riesgo
• Taxonomía de riesgo
Taxonomía de riesgo
• Modelo de evaluación
• Pl
Planes de contingencia y aplicación de
d ti i li ió d
opciones de tratamiento
• Matriz de riesgo
Matriz de riesgo
• Diagrama de riesgo (mapa de riesgo)
66. Documentos
Registro de riesgos
R it d i
• Por cada riesgo identificado el registro de
riesgo comprende:
riesgo comprende
– Declaración.
– Ubicación en el contexto organizacional.
Ubicación en el contexto organizacional
– Síntomas/Disparadores
– Consecuencias
Consecuencias
– Probabilidad e Impacto.
– Nivel de exposición.
p
– Opciones de tratamiento y respuesta /
controles existentes.
67. Documentos
Programa de tratamiento de riesgos y plan de
P d t t i t d i l d
acción
• Un tratamiento de riesgos y plan de acción
Un 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.
68. Declaración del riesgo (1)
Declaración del riesgo (1)
• 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:
• Proceso de captura de requerimientos bajo un esquema de validación y retroalimentación
P d t d i i t b j d lid ió t li t ió
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.
69. Declaración del riesgo (2)
Declaración del riesgo (2)
• 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:
• La metodología de desarrollo de software es orientada a la agilidad y la entrega
L t d l í d d ll d ft i t d l ilid d l t
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.
70. Declaración del riesgo (3)
Declaración del riesgo (3)
• 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 q
valor 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.
71. Declaración del riesgo (4)
Declaración del riesgo (4)
• Riesgo:
• R04 ‐ Gestión de riesgos insuficiente
• Tipo:
• 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 organizacional.
en 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.
73. Matriz
RIESGO: RESPUESTA: PLAN DE ACCIÓN: RESPONSABLE(S):
Proceso de captura de requerimientos
Mitigar bajo un esquema de validación y
retroalimentación constante de la
Esta posición implica acciones y
especificación actual de
Cambio constante de los actividades que se realizan con Equipo de Análisis de
requerimientos del sistema. Se
anticipación para evitar que se Requerimientos
requerimientos técnicos generarán prototipos funcionales y no
produzca un riesgo o para reducir
funcionales para dotar al usuario de
el impacto o las consecuencias a
una vista preliminar del producto de
una vista preliminar del producto de
un nivel aceptable.
cada etapa del proceso.
Reforzar el proceso de planificación y
Mitigar seguimiento (control) de forma
eficiente, siguiendo un modelo de
Esta posición implica acciones y
planificación orientada a la
Planificación ambiciosa del actividades que se realizan con
complejidad, asumiendo adaptabilidad Administrador de Proyectos
anticipación para evitar que se
calendario de trabajo y gestión integrada del riesgo durante
produzca un riesgo o para reducir
cada etapa de desarrollo e
el impacto o las consecuencias a
implementado medidas de control
un nivel aceptable.
detalladas.
74. Matriz
Promover la participación
activa del usuario final en el
proceso de planificación y
todas las iteraciones del
proceso de software para
Mitigar
Miti
proveer la retroalimentación
oportuna al equipo de Patrocinador
Implicación y Esta posición implica acciones y
actividades que se realizan con desarrollo para garantizar el
participación de los anticipación para evitar que se
Administrador de Proyectos
cumplimiento de los
usuarios produzca un riesgo o para reducir el
requerimientos solicitados y Arquitecto de Software
requerimientos solicitados y A it t d S ft
impacto o las consecuencias a un
suministrar al mismo de la
nivel aceptable.
visibilidad permanente del
estado del proyecto que
asegurará su compromiso
para terminarlo
exitosamente.
Mitigar Fortalecer la comunicación
(mediante reuniones) para
Esta posición implica acciones y
lograr la identificación y
Gestión de riesgos actividades que se realizan con
tratamiento de los riesgos Administrador de Proyectos
anticipación para evitar que se
insuficiente no identificados o
produzca un riesgo o para reducir el
impacto o las consecuencias a un emergentes durante el
g
nivel aceptable. proceso de desarrollo.
75. Matriz
Generar un plan de pruebas
unitarias y de integración para
asegurar que el código se
comporta según lo esperado.
Mitigar
Asumir la propiedad colectiva del
Esta posición implica acciones código para que todo el equipo
ód d l
Problemas y actividades que se realizan de trabajo sea responsable por
inesperados en la con anticipación para evitar su correctitud y efectividad y Arquitecto de software
que se produzca un riesgo o añadir o modificar porciones al
etapa de integración
p
para reducir el impacto o las
p
mismo.
mismo
consecuencias a un nivel
aceptable.
Procurar la integración continua
para reducir el impacto de la
incorporación de nuevas
incorporación de nuevas
funcionalidades.
76. Caso de Estudio
Sistema Integrado de Gestión y
Medición Adaptativas
(SIGMA/SEVRI|P)
Instituto Costarricense sobre Drogas
77. Gestión del Riesgo
Gestión del Riesgo
• En el Instituto Costarricense sobre
g
drogas involucra:
– Normativa
– Política
– Marco orientador (metodología)
– Software
78. Normativa
• 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 órganos
República y las entidades y órganos
sujetos a su fiscalización.
• Di t i
Directrices Generales para el
G l l
Establecimiento y Funcionamiento del
Sistema Específico de Valoración del
Si ífi d l ió d l
Riesgo Institucional (SEVRI).
79. Política
• “P
“Procurar el cumplimiento efectivo y
l li i t f ti
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 trabajo
constitució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 monitoreo
tratamiento, la comunicación y el monitoreo
en curso de los riesgos”.
80. Responsabilidades
• La gestión del riesgo es una
p p p
responsabilidad compartida por todas
las unidades funcionales del Instituto
Costarricense sobre Drogas.
Costarricense sobre Drogas
• La coordinación del desarrollo y
mantenimiento del marco de trabajo y
l b
orientador será responsabilidad de la
Comisión Institucional del Riesgo
81. Responsabilidades
• Los Jefes de Unidad, dirigen la gestión de
f d id d di i l ió d
riesgos en cada uno de los procesos y son
los responsables por la implementación
l bl l i l t ió
de controles y mecanismos de evaluación
de su efectividad.
de su efectividad
• Todos los funcionarios son responsables
de la reducción de los riesgos y de velar
d l d ió d l i d l
por la eficacia de los controles integrados
en los procesos, actividades y tareas a su
l ti id d t
cargo.
82. Comisión
• Representante del Consejo Directivo.
R t t d lC j Di ti
• Representante de la Dirección.
• Planificador(a) institucional.
( )
• Jefe de la unidad administrativa /
financiera.
fi i
• Jefe de la unidad de tecnología de la
información.
i f ió
• Jefe representante de las unidades
sustantivas.
sustantivas
• Asesor(a) legal.
84. Marco orientador
Marco orientador
• P i i i bá i
Principios básicos
• Conceptos
• Descripción del proceso
– Establecimiento del contexto
– Identificación de fuentes de riesgo
d ifi ió d f d i
– Identificación de riesgos
– Análisis
– Tratamiento
– Monitoreo y Revisión
Monitoreo y Revisión
– Comunicación
85. Software
• Contexto
– Ejecución: Procesos / Proyectos
j / y
• Etapas (hitos)
• Artefactos
– Actividades
» Procedimientos (tareas)
» Roles y responsabilidades
» Elementos de incertidumbre
86. Software
• 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)
87. Software
• Administra riesgos
d i i i
– Declaraciones
– Síntomas
– Consecuencias
– Respuestas
– Relaciones
– Planes de tratamiento
– Responsabilidades
– Autoevaluación
88. Software
• 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
– Consola del riesgo
l d l i
– Riesgo Inherente vs. Residual
89. Modelo
• Definir formalmente los procesos de cada
fi i f l l d d
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.
p
• Participación activa de todos los
funcionarios en la identificación y
g
tratamiento de los riesgos.
109. Bibliografía
• R
Ronald P. Higuera y Yacov Y. Haimes,
ld P Hi Y YH i
“Software Risk Management”, SEI Technical
Report CMU/SEI 96 TR 012 ESC 96 012
Report CMU/SEI‐96‐TR‐012 ESC‐96‐012
(Pittsburgh, PA: Software Engineering
Institute—Universidad Carnegie Mellon,
1996.
1996
• Marvin J. Carr y otros, “Taxonomy‐Based
Risk Identification SEI Technical Report
Risk Identification”, SEI Technical Report
CMU/SEI‐93‐TR‐6 ESC‐TR‐93‐183
(Pittsburgh, PA: Software Engineering
Institute—Universidad Carnegie Mellon,
1993.
110. Bibliografía
• G
Gary Stoneburner y otros. “Risk
S b “Ri k
Management Guide for Information
Technology Systems Recommendations of
Technology Systems”. Recommendations of
the National Institute of Standards and
Technology SP 800 30. National Institute of
Technology SP 800–30 National Institute of
Standards and Technology. 2002
• Project Management Institute Inc
Project 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.
111. Bibliografía
• 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 lN t AP
Technical Note ‐ A Proposed T
d Taxonomy ffor
Software Development Risks for High‐
p g( )
Performance Computing (HPC) Scientific‐
Engineering Applications, Kendall, Richard P.;
Post, Douglass E.; Carver, Jeffrey C.;
Henderson, Dale B.; and Fisher, David A.,
Henderson Dale B ; and Fisher David A
CMU/SEI‐2006‐TN‐039, April 2007
112. Bibliografía
• T h i l N t Ri k M
Technical Note ‐ Risk Management t
Considerations for Interoperable Acquisition,
Meyers, B. Craig, CMU/SEI‐2006‐TN‐032,
y , g, / ,
March 2007.
• Technical Note ‐ Common Elements of Risk,
Alberts, Christopher J., CMU/SEI‐2006‐TN‐
Alb t Ch i t h J CMU/SEI 2006 TN
014, April 2006
• Technical Note ‐ Mission Assurance Analysis
Note ‐
Protocol (MAAP): Assessing Risk in Complex
Environments, Alberts, Christopher and
Dorofee, Audrey, CMU/SEI‐2005‐TN‐032,
D f A d CMU/SEI 2005 TN 032
October 2005
113. Bibliografía
• T h i lN t AT
Technical Note ‐ A Taxonomy of Operational Ri k
fO ti l 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 Risk
View of Risk
Identification and Analysis, Williams, Ray C.;
Ambrose, Kate; and Bentrem, Laura, CMU/SEI‐
2004‐TN‐002, September
2004 TN 002 September 2004
• Risk Based Diagnostics, Williams, Ray C.;
Ambrose, Kate; Bentrem, Laura; and Merendino,
Tom, CMU/SEI‐2004‐TN‐013, September 2004
114. Bibliografía
• T h i lR
Technical Report ‐ Ri k Th
t Risk Themes DiDiscoveredd
Through Architecture Evaluations, Bass, Len;
Nord, Robert; Wood, William; and Zubrow,
, ; , ; ,
David, CMU/SEI‐2006‐TR‐012, October 2006
• Technical Report ‐ Techniques for Developing
an A i iti St t
Acquisition Strategy b P fili S ft
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 ‐
Version 2.0, Williams, R.C.; Pandelios, G.P.;
V i 2 0 Willi R C P d li G P
and Behrens, S.G., CMU/SEI‐99‐TR‐029
115. Bibliografía
• Handbook‐ Software Acquisition Risk
db k f iii ik
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‐
Monarch, Ira, CMU/SEI 95 TR
014
