sesion 14 gestion de riesgos
DESCRIPTION
sesión 14: Gestión de Riesgos en proyectos telemáticosTRANSCRIPT
26/10/2009Ambientes de Desarrollo
GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE
Universidad del Cauca
Departamento de Telemática
26/10/2009
Consideraciones Generales
• El riesgo del proyecto tiene su origen en la
incertidumbre que está presente en todos los
proyectos.
• Amenaza al éxito de todo proyecto.
• Gestión de riesgos = serie de pasos que ayudan a
comprender y manejar la incertidumbre que
implica el desarrollo de todo proyecto.
26/10/2009
El Fracaso y sus Causas
Los proyectos Informáticos fracasan por:
o El SW nunca llega a funcionar.
o No se cumplen los plazos de entrega.
o No cumple con las funcionalidades esperadas.
Razones:
o La complejidad era muy alta
(comunicaciones, interrelación con otros
sistemas, etc..)
o Incertidumbre. No se tenia una idea clara de lo que
se quería obtener.
26/10/2009
Causas Comunes de fracaso
o Ambigüedad del objetivo.
o Requerimientos Cambiantes.
o Tardó demasiado para el mercado.
o Estimaciones inadecuadas.
o Oficinas de trabajo muy llenas.
o Salarios inadecuados.
o Fricciones: * Contratistas y Clientes * Directores
Empresa y SW.
26/10/2009
Causas Comunes de fracaso
o El proceso del software no está bien definido, según
los la satisfacción de los usuarios.
o El análisis, diseño y pruebas se realizan sobre la
marcha.
o La calidad es un concepto que todo el mundo estima
importante, pero nadie actúa para alcanzarla.
o Experiencia inadecuada de los desarrolladores.
o Costes altos de mantenimiento.
o Herramientas y métodos inadecuados.
26/10/2009
Definición de Riesgo
Evento o condición incierta que, en caso de ocurrir, tiene
un efecto positivo o negativo sobre los objetivos de un
proyecto.
o Habitualmente se gestionan los riesgos con efecto
negativo, es decir, aquellos que suponen una amenaza para
el éxito del proyecto.
o Un riesgo tiene una o más causas y si se produce tiene uno
o más impactos
o Algunos riesgos son simplemente imposibles de predecir.
o El riesgo acompaña a todo cambio
26/10/2009
Características del Riesgo
Incertidumbre Probabilidad de que ocurra; no hay riesgos de
un 100% de probabilidad, si los hay son restricciones.
Pérdida Si el riesgo se hace realidad => pérdidas.
• Producto (Rendimiento, Poder dar mantenimiento)
• Proceso de producción (Tiempo de desarrollo, Costo)
“EL NIVEL DE RIESGO SE ESTABLECE CON UNA
CONJUGACION DE AMBOS FACTORES”
26/10/2009
¿Porque hacer Gestión de Riesgos?
Proceso formal de identificar y analizar los riesgos y la
consecuente gestión para eliminar, reducir o abordar dichos
riesgos.
“Incrementar las posibilidades de éxito de un proyecto”
Maximizar las probabilidades y consecuencias de eventos
positivos.
Minimizar las probabilidades y consecuencias de eventos
negativos.
“Si no atacas activamente a los riesgos, ellos te atacarán
activamente a ti” Tom Gilb
26/10/2009
Estrategias de riesgo
Reactivas
El equipo software no hace nada respecto a los riesgos hasta
que algo va mal (Técnica de los bomberos)
Actuar en consecuencia => Proyecto en peligro.
Proactivas
Evaluación previa (antes de los trabajos técnicos) y
sistemática de riesgos, y sus consecuencias.
Plan de contingencia => Evasión del riesgo y menor
tiempo de reacción
26/10/2009
Tipos de Riesgos en el software
• Conocidos
Se descubren en la evaluación del
plan del proyecto, del entorno
técnico y comercial.
• Predecibles
Se extrapolan de la experiencia
en proyectos anteriores.
• Impredecibles
No se conocen ni se pueden
predecir se solucionan solo de
forma reactiva.
• Riesgos del proyecto
Incremento en el costo
Desbordamiento organizativo
• Riesgos técnicos
• Riesgos del negocio
* De mercado * De estrategia
* De ventas * De gestión
* De presupuesto
26/10/2009
Riesgos del software: Técnicos
Amenazan la calidad y la planificación temporal del software
a construir.
Identifican problemas potenciales de:
o Diseño, implementación, interfaz.
o Verificación y mantenimiento.
o Ambigüedades de especificaciones, incertidumbre técnica,
técnicas anticuadas y las "tecnologías punta”.
Ocurren porque el problema es más difícil de resolver de lo
que pensábamos.
26/10/2009
Riesgos del software: Negocio
Amenazan la viabilidad del software a construir. Los 5 riesgos son:
1. Construir un producto o sistema excelente que no quiere nadie
en realidad (riesgo de mercado).
2. Construir un producto que no encaja en la estrategia comercial
general de la compañía (riesgo estratégico),
3. Construir un producto que el departamento de ventas no sabe
cómo vender (riesgo ventas).
4. Perder el apoyo de una gestión experta debido a cambios de
enfoque o a cambios de personal (riesgo de gestión)
5. Perder presupuesto o personal asignado (riesgos de
presupuesto).
26/10/2009
Gestión de riesgos
ACTIVIDADES
1. Identificación
2. Análisis
3. Planeación
4. Seguimiento
5. Control
6. Soporte
7. Comunicación y
Documentación
Plan RSGR o RMMM
26/10/2009
1. Identificación del riesgo
Objetivo: especificar los riesgos al plan del proyecto
Para identificarlos se examina el plan del proyecto y la
declaración del ámbito del software.
Tipos de riesgos:
Genéricos son para todos
los proyectos de software.
Específicos de producto
(tecnología, el personal y
el entorno)
Plan RSGRo RMMM
26/10/2009
1. Identificación del riesgo
Crear una lista de comprobación de elementos de riesgo
conocidos y predecibles para cada una de las categorías:
1. Tamaño
del
producto
2. Impacto
en el
negocio
3. El cliente
4. Definición
del proceso
7. Tamaño y
experiencia
del equipo
6. Tecnología
a construir
5. Entorno
de
desarrollo
26/10/2009
1. Identificación del riesgo:
Categoría I
Riesgos del tamaño del producto
o Grado de seguridad en la estimación del proyecto
o Número de programas, archivos y transacciones
o Tamaño de la base de datos
o Número de usuarios
o Número de cambios de requisitos previstos antes y después
de la entrega
o Cantidad de software reutilizado
26/10/2009
1. Identificación del riesgo:
Categoría II
Riesgos del impacto en el negocio
o Efecto del producto en los ingresos de la compañía
o Fecha límite de entrega razonable
o Número de clientes que usarán el producto
o Límites legales y gubernamentales
o Costos asociados por retrasos en la entrega o producto
defectuoso
o Número de otros productos/sistemas con los que este producto
debe tener interoperatividad
o Cantidad y calidad de la documentación del producto que debe
ser elaborada y entregada al cliente.
26/10/2009
Riesgos relacionados con el cliente
No todos los clientes son iguales y tienen la misma personalidad.
o Algunos saben lo que quieren; otros saben lo que no quieren.
Algunos desean saber todos los detalles, mientras que otros
quedan satisfechos con vagas promesas.
o Un "mal" cliente puede tener un profundo impacto en la
habilidad del equipo de software para completar el proyecto a
tiempo y dentro de presupuesto.
o Un mal cliente representa una amenaza significativa al plan del
proyecto y un sustancial riesgo para el jefe del proyecto
1. Identificación del riesgo:
Categoría III
26/10/2009
o ¿Ha trabajado con el cliente anteriormente?
o ¿Tiene el cliente una idea formal de lo que se requiere?¿Se ha
molestado en escribirlo?
o ¿Aceptará el cliente gastar su tiempo en reuniones formales de
requisitos para identificar el ámbito del proyecto?
o ¿Está dispuesto el cliente a establecer una comunicación fluida
con el desarrollador?
o ¿Está dispuesto el cliente a participar en las revisiones?
o ¿Es sofisticado técnicamente el área del producto?
o ¿Entiende el cliente el proceso del software?
1. Identificación del riesgo:
Categoría III
26/10/2009
Riesgos del proceso: Aspectos del proceso
o ¿Ha desarrollado su organización una descripción escrita del
proceso del software a emplear en este proyecto?
o ¿Se documentan todos los resultados de las revisiones técnicas,
incluyendo los errores encontrados y recursos empleados?
o ¿Ha desarrollado o adquirido su organización cursos de
formación de ingeniería del software para jefes de proyecto y
personal técnico?
o ¿Se llevan a cabo regularmente revisiones técnicas formales de
las especificaciones de requisitos, diseño, código y pruebas ?
o ¿Se emplea este proceso del software para otros proyectos?
1. Identificación del riesgo:
Categoría IV
26/10/2009
Riesgos del proceso: Aspectos técnicos
o ¿Se emplean técnicas de especificación de aplicaciones para
ayudar en la comunicación entre el cliente y el desarrollador?
o ¿Está escrito su código en más de un 90% en lenguaje de alto
nivel?
o ¿Se emplean herramientas de software para apoyar los procesos
de análisis, diseño, pruebas y gestión de la documentación?
o ¿Se emplean herramientas de software de gestión de
configuración para controlar y seguir los cambios a lo largo de
todo el proceso del software?
o ¿Se han establecido métricas de calidad y productividad
para todos los proyectos de software?
1. Identificación del riesgo:
Categoría IV
26/10/2009
Riesgos tecnológicos
o ¿Es nueva para su organización la tecnología a construir?
o ¿Demandan los requisitos del cliente la creación de nuevos
algoritmos o tecnología de entrada o salida?
o ¿Demandan los requisitos del producto una interfaz de usuario
especial y el empleo de nuevos métodos de análisis, diseño o
pruebas?
o ¿El software interactúa con hardware nuevo o no probado?
o ¿Imponen excesivas restricciones de rendimiento los requisitos
del producto?
o ¿No está seguro el cliente de que la funcionalidad pedida
sea factible ?
1. Identificación del riesgo:
Categoría V
26/10/2009
Riesgos del entorno de desarrollo
o Las herramientas inapropiadas o ineficaces pueden estropear los
esfuerzos de incluso un experimentado profesional, dado que el
entorno soporta al equipo del proyecto, al proceso y al producto.
o ¿Tenemos disponible herramientas de gestión de proceso,
proyectos, configuración y pruebas apropiadas para el producto?
o ¿Proporcionan las herramientas de análisis y diseño, métodos
apropiados para el producto a construir?
o ¿Existen expertos disponibles para responder todas las preguntas
que surjan sobre las herramientas?
o ¿ Se ha formado al equipo del proyecto en todas las
herramientas y estas están todas integradas entre si?
1. Identificación del riesgo:
Categoría VI
26/10/2009
Riesgos en el tamaño y experiencia del equipo
o ¿Disponemos de la mejor gente?
o ¿Tiene el personal todos los conocimientos adecuados?
o ¿Tenemos suficiente personal?
o ¿Se ha asignado al personal para toda la duración del
proyecto?
o ¿ Ha recibido el personal la formación adecuada?
o ¿Será mínimo el movimiento del personal para permitir la
continuidad?
?
1. Identificación del riesgo:
Categoría VII
26/10/2009
Objetivo
Convertir la información de riesgos en
información de decisión.
Actividades:
o Evaluación: establece la probabilidad
de ocurrencia y el daño que causará si
ocurre.
o Clasificación: según su probabilidad de
ocurrencia y el impacto que pudiesen
causar
o Priorización.
2. Análisis de riesgos
C Y D
26/10/2009
2. Análisis de riesgos: Evaluación
Se identifican cuatro componentes del riesgo:
Rendimiento: incertidumbre de si el producto cumplirá
sus requisitos.
Soporte: incertidumbre de la facilidad del software para
corregirse, adaptarse y ser mejorado.
Planificación: incertidumbre de mantener la planificación
temporal y de que el producto se entregue a tiempo.
Costo.
Impacto: despreciable, marginal, crítico, catastrófico
Probabilidad: porcentaje
26/10/2009
2. Análisis de riesgos: Ejemplo
Categoría
Riesgos
0,n
0,n
Componente
n
n
Impacto
Indicadores n 1
26/10/2009
2. Análisis de riesgos: Ejemplo
Equipo
Huida del personal sin el proyecto finalizado
0,n
0,n
Planificación
n
n
Crítico
Perspectivas poco claras
Poca motivaciónContratos bajos
n 1
26/10/2009
o Tabla de riesgos
2. Análisis de riesgos
Riesgo Categoría Proba- bilidad
Impacto RMMM
Tamaño estimado demasiado pequeño Proyecto 40 % Planificación Crítico
Mayor número de usuarios de lo planificado Proyecto 30 % Rendimiento Marginal
Cliente cambie los requerimientos Proyecto 80 % Costes
Crítico
Falta de experiencia en herramientas Entorno Desarrollo
80 % Planificación Marginal
Rotación demasiado alta Equipo 60 % Planificación Crítica
26/10/2009
1. Ordenar por probabilidad y prioridad los riesgos
2. Despreciar riesgos poco probables y los medianamente
probables con poco impacto.
2. Análisis de riesgos: Priorización
Riesgo Categoría Proba- bilidad
Impacto RMMM
Cliente cambie los requerimientos Proyecto 80 % Crítico Falta de experiencia en herramientas Entorno
Desarrollo 80 % Marginal
Rotación demasiado alta Equipo 60 % Crítica Tamaño estimado demasiado pequeño Proyecto 40 % Crítico Mas número de usuarios de lo planificado Proyecto 30 % Marginal
3. Planeación
Objetivo
o Marcar las estrategias y formas de
actuar del equipo de trabajo frente a
los riesgos identificados:
• Cómo evitarlos
• Cómo supervisarlos
• Cómo gestionarlos y plan de
contingencia
Estrategias* Actuar * Aceptar * Eliminar * Mitigar * Transferir * Delegar * Investigar * Poner bajo observación
26/10/2009
Plan RSGRo RMMM
Plan RSGR (Reducción, Supervisión y Gestión del Riesgo) o RMMM
Introducción
• Ámbito y propósito del doc.
• Descripción de los principales
riesgos
• Responsabilidades
• Gestores
• Personal técnico
Tabla de evaluación de riesgos
• Descripción de todos los riesgos
• Factores que influyen en la
probabilidad e impacto
26/10/2009
RSGR: Riesgo X
o Evitación
Estrategia general
Pasos para mitigar el riesgo
o Monitorización
Factores a monitorizar
Modo de monitorización
o Gestión
Plan de contingencias
Consideraciones especiales
Objetivo
Adquirir, compilar y reportar datos
acerca del estado de los riesgos.
o Se miden los indicadores de
riesgo.
o Se evalúa el progreso del plan
de mitigación.
o Mantiene la búsqueda de
nuevos riesgos.
26/10/2009
4. Seguimiento
C Y D
5. Control
Objetivo
Tomar decisiones acerca de los
riesgos y su plan de mitigación.
o Analizar reportes de estado
del proyecto.
o Decidir como proceder.
o Implementar la decisión.
26/10/2009
Decisiones
* Cerrar el riesgo * Ejecutar plan contingencia
* Seguir con el plan actual. * Re-planear
C Y D
6.Comunicación y Documentación
Todos deben entender los riesgos del proyecto y las
alternativas de mitigación.
o Comunicación abierta.
o Documentación formal.
o Convocar reuniones de revisión
26/10/2009
Conclusiones
o El Proceso de Análisis y Gestión de Riesgos debe ser
aplicado a todos los proyectos grandes y chicos
o Si un equipo de software adopta un enfoque proactivo hacia
el riesgo, evitarlo siempre es la mejor estrategia.
o Es importante señalar que los pasos de reducción, supervisión
y gestión del riesgo (RSGR) generan costos adicionales en el
proyecto.
oAnalizar lecciones aprendidas.
“Cuando un proyecto tienen éxito, no es porque no haya tenido
problemas, sino porque se han superado.”
26/10/2009
Conclusiones
El riesgo de un proyecto es producto de su grado de
innovación, su complejidad, viabilidad de los plazos
exigidos y en que medida el producto cambiará el
negocio.
Una persona ilustrada no debe buscar más precisión que
la que permita la naturaleza misma del objeto de estudio.
Aristóteles
26/10/2009
¿Preguntas?