GESTION DEL RIESGO
-
Upload
luis-castillo -
Category
Education
-
view
79.941 -
download
2
description
Transcript of GESTION DEL RIESGO
PROCESOS DE INGENIERÍA DE SOFTWAREDocente: Ing. Armando Cabrera Alumnos: Luis Enrique Castillo
Luis Eduardo Cuenca Mayo/2008
Universidad Técnica Particular de Loja
PreviewLos objetivos de la
gestión de riesgo son identificar, controlar y eliminar las fuentes de riesgo antes de que empiecen a afectar el cumplimiento de los objetivos del proyecto
Procesos de Ingeniería de Software - ECC 2
FUENTE: http://tinyurl.com/4u4owq
!!!!RIESGO¡¡¡¡
Procesos de Ingeniería de Software - ECC 3
Procesos de Ingeniería de Software - ECC 4
Estrategias de riesgo reactivas y proactivasReactivo
El equipo de SW no hace nada hasta que sucede algo mal.
Modo Bombero → Tratar de remediar el problema al apuro ¿¿Y si falla el bombero ??? R: Aparece la Gestión de Crisis para tomar el control, y es cuando el
proyecto esta en verdadero peligro
Ser proactivoInicia antes del trabajo técnico.Identificar los riesgos potenciales, valorando su probabilidad e
impactoSe clasifican según su importanciaEstablecer un plan.
Procesos de Ingeniería de Software - ECC 5
Riesgos del SoftwareLos riesgos involucran dos características:
Incertidumbre: Se desconoce si puede suceder.Pérdida: El riesgo se convierte en realidad.
“Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y de perdida asociado con el riesgo”
Tipos de riesgos que se encuentran:1.Riesgos del Proyecto (Amenazan el plan del proyecto)
2.Riesgos Técnicos (Amenaza la calidad y actualidad del SW que se producirá)
3.Riesgos de Negocios (Amenaza la viabilidad del SW que se construirá)
Procesos de Ingeniería de Software - ECC 6
Procesos de Ingeniería de Software - ECC 7
Riesgo Tipo Descripción
Rotación del personal Proyecto Personal con experiencia abandona el proyecto antes de que finalice
Cambio de gestión Proyecto Habrá un cambio de gestión organizacional con diferentes prioridades
No disponibilidad de HW
Proyecto El HW esencial para el proyecto no será entregado a tiempo
Cambio de requerimientos
Proyecto y producto
Habrá mas cambios en los requerimientos de lo esperado
Retrasos en la especificación
Proyecto y producto
Las especificaciones de las interfaces esenciales no estarán a tiempo
Subestimación del tamaño
Proyecto y producto
El tamaño del proyecto se ha subestimado
Bajo rendimiento de la herramienta CASE
Producto Las herramientas CASE que ayudan al proyecto no tienen el rendimiento esperado
Cambio de tecnología Negocio Un producto competitivo se pone en venta antes de que el sistema se complete
Competencia del producto
Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología
Posibles Riesgos del SW genéricos
INGENIERÍA DEL SOFTWARE, Ian Sommerville, 7ma ed, Pag: 96
Procesos de Ingeniería de Software - ECC 8
Etapas:1.Identificación de riesgos: Identificar los posibles riesgos para el proyecto, el producto y los negocios2.Análisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos.3.Planeación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos i minimizar sus efectos en el proyecto4.Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible
INGENIERÍA DEL SOFTWARE, Ian Sommerville, 7ma ed, Pag: 97
Identificación de riesgosIdentificar los riesgos es una tarea sistemática
orientándose a especificar las amenazas al plan del proyecto.Al identificarlos se puede estar un paso adelante.
Dos tipos de riesgos para (R. Proyectos, R. Técnicos y R. Negocios)
Riesgos Genéricos: Amenaza potencial para todo el proyecto de SW
Riesgos específicos del producto: Se los puede identificar con un buen conocimiento de tecnología, el personal y el entorno especifico del SW. ¿¿¿Como???
Examinando el plan del proyecto y la declaración del ámbito del SW. “Qué características especiales de este producto podrían
amenazar el plan del proyecto”Procesos de Ingeniería de Software - ECC 9
Tipos de riesgos que pueden aparecerRiesgos de tecnologíaRiesgos de personalRiesgos organizacionalesRiesgos de herramientasRiesgos de requerimientosRiesgos de estimación
Procesos de Ingeniería de Software - ECC 10
El método para identificar es crear una lista de verificación (Check list) de riesgos.
Sub categorías de riesgos:Tamaño del Producto: Riesgos asociados con el tamaño global del
SW.Impacto en el Negocio: Asociados con las restricciones que impone la
gerencia o el mercado.
Características del cliente: Asociados con la satisfacción del cliente.
Definición del proceso: Riesgos con el grado en que se ha definido el proceso
Entorno de desarrollo: Asociado con disponibilidad y calidad de las herramientas.
Tecnología que construir: Asociado con la complejidad del sistema que se construirá.
Tamaño y experiencia de la plantilla de personal: Relacionado con la experiencia técnica del personal.
Procesos de Ingeniería de Software - ECC 11
Identificación de riesgos (Cont…)
1. ¿Los altos ejecutivos de SW y del cliente se han comprometido formalmente para apoyar el proyecto?
2. ¿Los usuarios finales están comprometidos con el proyecto y el sistema/producto que se construirá?
3. ¿Los requisitos los han entendido completamente el equipo de ingeniería de SW y sus clientes?
4. ¿Los clientes estuvieron completamente involucrados en la definición de los requisitos?
5. ¿Los usuarios finales tienen expectativas realistas?6. ¿El ámbito del proyecto es estable?7. ¿El equipo de ingeniería del SW tiene la mezcla correcta de habilidades?8. ¿Los requisitos del proyecto son estables?9. ¿El equipo del proyecto tiene experiencia con la tecnología que se
implementara?10. ¿El numero de personas en el equipo de proyecto es adecuado para
realizar el trabajo?11. ¿Todos los votantes del cliente/usuario están de acuerdo en la
importancia del proyecto y en los requisitos para el sistema/producto que se construirá?
Procesos de Ingeniería de Software - ECC 12
Identificación de riesgos (Cont…)Evaluación del riesgo
Componentes y controladores del riesgo
El gestor debe identificar los controladores del riesgo que afectan los componentes de riesgo del SW como:Riesgo de desempeño: Grado de incertidumbre de
que el producto satisfaga los requisitos y se ajuste y se ajuste al uso que se pretende darle.
Riesgo de costo: Grado de incertidumbre de que se mantenga el presupuesto del proyecto.
Riesgo de soporte: Grado de incertidumbre de que el SW resultante será fácil de corregir, adaptar y mejorar.
Riesgo de calendarización: Grado de incertidumbre de que se mantenga la calendarización del proyecto y de que el producto se entregue a tiempo.
Procesos de Ingeniería de Software - ECC 13
Identificación de riesgos (Cont…)
Procesos de Ingeniería de Software - ECC 14
Componentes Categoría
Desempeño Soporte Costo Calendarización
Catastrófico
1 El fracaso en la satisfacción de los requisitos resultaría en un fracaso de la misión.
El fracaso resulta en el aumento de costos y en demoras en la calendarización con valores esperados que superan 500K día.
2 Cierta reducción en el desempeño técnico
SW que no responde o no se puede soportar
Recortes financieros significativos, probable superación del presupuesto
COI inalcanzable
Critica
1 El fracaso para satisfacer los requisitos resultaría en un desempeño degradado del sistema hasta un punto donde el éxito de la misión es cuestionable
El fracaso resulta en demoras operativas o incrementos de costos con valor esperado de 100K a 500K dólares
2 Cierta reducción en el desempeño técnico
Demoras menores en las modificaciones del SW
Cierto recorte de recursos financieros, posibles excesos
Posible deslizamiento en el COI
Marginal
1 El fracaso para satisfacer los requisitos resultaría en degradación de la misión secundaria
Deslizamiento de costos, impactos o calendarización recuperable con valor esperado de 1K a 100K dólares
2 Mínima o pequeña reducción en le desempeño técnico
Respuesta de soporte de SW
Suficientes recursos financieros
Calendarización alcanzable y realistas
Despreciable
1 El fracaso al satisfacer los requisitos crearía inconvenientes o impactos no operativos
El error resulta en costo menor o impacto en la calendarización con valores esperado de menos de 1K dólares
2 Ninguna reducción en le desempeño técnico
SW al que fácilmente se le da soporte
Posible superávit presupuestal
COI facialmente alcanzable
INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed., PAG: 753
Proyección del Riesgo ó Estimación del RiesgoIntenta clasificar el riesgo de dos formas:
La posibilidad que el riesgo sea real Las consecuencias de los problemas asociados con el
riesgo en caso de que ocurra.El planificador del proyecto con los gestores y personal
técnico, realizan 4 pasos en la proyección del riesgo.1.Establecimiento de una escala que refleje la posibilidad
percibida de un riesgo.2.Delineado de las consecuencias del riesgo.3.Estimación del impacto del riesgo en el proyecto y el
producto.4.Tomar nota de la precisión global de la proyección del
riesgo de modo que no haya malas interpretaciones.
“La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al establecimiento de
prioridades”.Procesos de Ingeniería de Software - ECC 15
Desarrollo de tabla de riesgosLa tabla de riesgos ofrece al gestor de un proyecto una
técnica simple para la proyección de riesgos.
Procesos de Ingeniería de Software - ECC 16
Riegos Categoría
Probabilidad Impacto RSGR
La estimación del tamaño puede ser significativamente baja.Mayor numero de usuarios de los previstos.Menos reutilización que la prevista.Los usuarios finales se resisten al sistema.La fecha limite de entrega estará muy ajustada.Pérdida de fondos.El cliente cambiara requisitos.La tecnología no satisfará las expectativas.Falta de entrenamiento acerca de las herramientas.Personal inexperto.Elevada movilidad del personal.
………..
TP
TPTPCOCO
CLTPRTED
PEPE
60 %
30 %70%40 %50 %
40 %80 %30 %80 %
30 %60 %|
2
3232
1213
22
INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed.: PAG: 754
Valores de
impacto:
1: catastrófico
2: crítico
3: marginal
4: despreciable
Línea de Corte implica que solo los riesgos ubicados sobre la línea tendrán
una atención posterior
Evaluación del impacto de riesgo3 factores afectan las consecuencias que son
probables si un riesgo ocurre:Naturaleza (indica los problemas que son probables si ocurre)
Ámbito (combinación de la severidad con su distribución global)
Tiempo (consideración de cuándo y durante qué periodo se sentirá el impacto)
¿Cómo se valoran las consecuencias de un riesgo?1.Determinar el valor promedio de la probabilidad de
que ocurra para cada componente de riesgo.2.Empleando los Componentes y controladores del
riesgo, determinar el impacto para cada componente, con base en los criterios mostrados.
3.Completar la tabla de riesgos y analizar los resultados
Procesos de Ingeniería de Software - ECC 17
Cuándo desistir y finalizar el proyecto
Se debe definir un punto de referenciaSe debe marcar la relación entre cada factor
de riesgo enumerado y el punto de referenciaDefinir el área de incertidumbre, donde será
tan válido continuar como interrumpir el trabajo
Predecir cómo la combinación de riesgos afectará a los niveles de referencia
Procesos de Ingeniería de Software - ECC 18
ER = P x C
EXPOSICIÓN AL RIESGOEXPOSICIÓN AL RIESGO global ER, donde P es la probabilidad de que ocurra un riesgo y C el costo al proyecto en caso de que ocurra el riesgo.
Procesos de Ingeniería de Software - ECC 19
Como define un equipo de SW un riesgoIdentificación del riesgo: Solo 70% de los componentes de SW calendarizados para reutilización se integra en la aplicación.Probabilidad de riesgo: 80%Impacto del riesgo: Se planificaron 60 componentes de SW reutilizables. Si sólo se puede emplear el 70%, 18 componentes tendrán que desarrollarse desde cero. Puesto que el componente promedio es 100 LDC y los datos locales indican que el costo de ingeniería de SW para cada uno es de 14000USD, el costo(impacto) global del desarrollo de los componentes sería de 18 x 100 x 14 = 25200USD.Exposición al riesgo: ER = 0.80 x 25200 dólares ~ 20 200 dólares.
Refinamiento del riesgoDurante las primeras etapas se generan
descripciones de riesgos muy superficiales y a medida que se avanza en el proyecto se los va detallando de mejor manera.
Una buena forma de describir un riesgo es:Representar el riesgo en formato de Condición-Transición–
Consecuencia. Dado que <condición> entonces existe una
preocupación de que (posiblemente) <consecuencia>
Dado que los componentes de SW reutilizables deben ajustarse con estándares de diseño específicos y como algunos no lo hace, entonces existe una preocupación de que (posiblemente) sólo 70% de los módulos reutilizables planeados pueden en realidad integrarse al sistema que se construirá, lo que resulta en la necesidad de ingeniería personalizada para el restante 30% de componentes.
Procesos de Ingeniería de Software - ECC 20
Reducción, supervisión y gestión del riesgo
Una estrategia para luchar con el riesgo debe considerar:Evitar el riesgoEvitar el riesgoSupervisar el riesgoSupervisar el riesgoGestionar el riesgo y los planes de Gestionar el riesgo y los planes de
contingenciacontingencia..
Es un pecado capital dejar pasar el riesgo por alto luego de haberlo identificado y no tratarlo
Procesos de Ingeniería de Software - ECC 21
RSGR [Reduciendo el riesgo]El gestor del proyecto debe recurrir una estrategia
para reducir la movilidad.Los posibles pasos que se puede seguir son:
Reunirse con el personal actual para determinar las causas de la movilidad
Reducir aquellas causas que se controlan antes de que comience el proyecto.
Una vez iniciado el proyecto suponer que la movilidad ocurrirá y entonces desarrollar técnicas que aseguren la continuidad cuando la gente se aleje.
Organizar equipos de proyectos de modo que la información acerca de cada actividad de desarrollo se disperse con amplitud.
Definir estándares de documentación y establecer mecanismos que aseguren que los documentos se desarrollen en una forma oportuna.
Llevar a cabo revisiones por pares de todo el trabajo.Asignar un miembro de respaldo para las actividades
criticas. Procesos de Ingeniería de Software - ECC 22
RSGR [1 paso adelante]
La gestión del riesgo y los planes de contingencia suponen que los esfuerzos de reducción han fracasado y que el riesgo se ha vuelto una realidad.No hay problema si se hizo las actividades de la reducción
Hay el personal de respaldo
El gestor puede reenfocar los recursos hacia aquellas funciones completamente estructuradas.
Los individuos a salir se les pide que traspasen el conocimiento
Los pasos de reducción, supervisión y gestión del riesgo generan costos adicionales en el proyecto.
El riesgo no está limitado al proyecto de SW. Los riesgos pueden ocurrir después de que el SW se ha
desarrollado exitosamente y entregado al cliente. Estos riesgos están típicamente asociados con las
consecuencias de la falla de SW en el campo.Procesos de Ingeniería de Software - ECC 23
El plan RSGREl plan de RSGR documenta todo el trabajo realizado como
parte del análisis del riesgo y el gestor del proyecto lo emplea como parte del plan global del proyecto.
Algunos equipos de SW no elaboran un documento RSGR formal. En su lugar cada riesgo se documenta individualmente mediante una hoja de información del riesgo.
Una vez documentado el plan de RSGR y que el proyecto ha comenzado, se inician los pasos de reducción y supervisión del riesgo.
La reducción del riesgo es una actividad encaminada a evitar el problema.
La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos:1. Valorar si los riesgos predichos de hecho ocurren2. Asegurar que los pasos para evitar el riesgo definidos para
éste se están aplicando con propiedad3. Recopilar información que pueda usarse en futuros análisis de
riesgo.Procesos de Ingeniería de Software - ECC 24
Procesos de Ingeniería de Software - ECC 25
Hoja de información del riesgoID de riesgo: PO2 – 4-32 Fecha: 9/5/04 Prob: 80% Impacto: alto
Descripción:Solo el 70% de los componentes del SW calendarizados para reutilización de hecho se integraran a la aplicación. La funcionalidad restante tendrá que desarrollarse de manera personalizada.
Refinamiento/contexto:Subcomisión 1: Ciertos componentes de reutilización fueron desarrollados por un tercer participante sin conocimiento de los estándares de diseño interno.Subcomisión 2: El estándar de diseño para los componentes de interfaces no ha sido solidificado y tal vez no concuerdan con ciertos componentes reutilizables existentes.Subcomisión 3: Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino.
Reducción/supervisión:1.Contactar con el tercer participante para determinar la concordancia con los estándares de diseño.2.Presionar para completar los estándares de interfaz; considerar la estructura del componente cuando se decida acerca del protocolo de la interfaz.3.Verificar para determinar el numero de componentes en la categoría 3 de subcomisión; verificar para determinar si se puede adquirir el soporte para el lenguaje.
Gestión/plan de contingencia/disparador:La ER se calcula en $ 20 200. Asignar esta cantidad dentro del costo de contingencia del proyecto. Desarrollar una calendarización revisada suponiendo que se tendrán que construir 18 componentes adicionales; asignar el personal en concordancia,Disparador: Los pasos de reducción son improductivos al 1/7/04.
Estado Actual:12/5/04: Inicia los pasos de reducción
Elaboró: D. Gagne Asignado a : B. Laster
INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRACTICO, Roger Pressman, 6ta ed. PAG: 762
ConclusionesLa gestión del riesgo es crucial en el proyecto
de SW.El gestionar los riesgos implica identificar
todos los factores que pueden llevar al proyecto al fracaso
Elaborar los planes de RSGREl plan RSGR debe revisarse conforme el
proyecto avanzaRecordar que los riesgos se relacionan con
los acontecimientos futuros.Procesos de Ingeniería de Software - ECC 26
BibliografíaINGENIERÍA DEL SOFTWARE, Ian
Sommerville, 7ma edINGENIERIA DEL SOFTWARE, UN
ENFOQUE PRACTICO, Roger Pressman, 6ta ed.
Procesos de Ingeniería de Software - ECC 27
Luis Enrique CastilloE-mail:
http://lecastillox.blogspot.com Luis Eduardo Cuenca
E-mail: [email protected]
Procesos de Ingeniería de Software - ECC 28