6.-aNÁLISIS Y GESTIÓN DEL RIESGO

Slides:



Advertisements
Presentaciones similares
ADAPTABILIDAD AL CAMBIO
Advertisements

IDENTIFICAR NECESIDADES, PROBLEMAS U OPORTUNIDADES
Administración moderna de la seguridad
UNIVERSIDAD "ALONSO DE OJEDA"
ANALISIS DE RIESGOS.
Ingeniería del Software
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
METRICAS DE PROCESO Y PROYECTO
Gestión de proyectos Es la primera etapa de Ingeniería del Software.
Mantenimiento basado en el Riesgo (Inspección basada en el Riesgo)
COSTOS ESTANDAR DEFINCIÓN
Riesgo en la gestión de proyectos de software
Planificación de Proyectos Informáticos
. Cap.9 GESTION DE LA CONFIGURACION DEL SOFTWARE ( GCS/SCM.
Procesos de la Ingeniería
Universidad Loyola Pacífico
U I B 3/10/2001 Gestión de riesgos Ingeniería del Software III Octubre
Electivo Integración Normas de Calidad, Seguridad, Medio Ambiente y Riesgos en la Gestión de la Empresa. Profesor : Fernando Vargas Gálvez Ingeniero Civil.
GESTION NIVELES DE SERVICIO.
Diseño del Software Diseño de datos Diseño arquitectónico
UNA HERRAMIENTA PARA AGREGAR VALOR
DISEÑO DE LA INTERFAZ DE USUARIO
Ciclo de Vida del Software Paradigmas de Desarrollo
REQUERIMIENTOS DE SOFTWARE
Aplicaciones de Ingeniería de Software
Actividad 14. Riesgos en los proyectos de software M.C. Juan Carlos Olivares Rojas Syllabus June, 2009.
AUDITORIAS DE SEGURIDAD
Juan Antonio del Valle Flores
Métricas de calidad de software
ANTEPROYECTOSEN INGENIERIA
GESTION DEL CAMBIO Los presencia continua de competencia, la internacionalización económica y la aparición de nuevas tecnologías de información e informática.
Ingeniería de Software
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Planificación y modelado
Gestión de la Continuidad del negocio BS BCI
Ingeniería de Software
Plan de Sistemas de Información (PSI)
Ingeniería de Software
Análisis de Riesgo en la Planificación
Tema 1: Introducción a la Ingeniería de Software
Ingeniería del Software III Octubre
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
SUBTEMA 2.4 FUNDAMENTOS DE DESARROLLO DE SISTEMAS
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
ANTEPROYECTOSEN INGENIERIA
INTRODUCCIÓN AL PROCESO UNIFICADO DE DESARROLLO DESOFTWARE
Ing. Ana Elena Murgas Vargas
INGENIERÍA DEL SOFTWARE GESTIÓN DE PROYECTOS
Medición y Métricas del Software
Alexander Aristizabal Ángelo flores herrera
A DMINISTRACIÓN DE R IESGOS Plan de contingencia.
Ciclo de vida de un sistema
Métricas de calidad de software
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Conceptos sobre GESTIÓN DE PROYECTOS
Introducción al proceso de verificación y validación.
Salir de la presentación
ROL DE FORTALECIMIENTO DE LA CULTURA DEL CONTROL.
Aplicar los conceptos y las herramientas para la administración de la calidad y gestión de riesgos del plan del proyecto. MTRA. VERÓNICA NOHEMI TAVERNIER.
Ingeniería del Software Lic. Marisa Gouget UCSA
Mata Moran Mireya Gabriela Alejandra
Proceso de desarrollo de Software
6.6 Administración de defectos
Análisis de Riesgos Ambientales.
Planificación de Sistemas de Información
Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad.
Tema 7: Ingeniería del software Definición de software El software es: 1. instrucciones (programas de computadora) que cuando se ejecutan proporcionan.
“ El riesgo se halla de forma implícita asociado a toda actividad”
Verificación y Validación del Software
GESTIÓN DE PROYECTOS.
Transcripción de la presentación:

6.-aNÁLISIS Y GESTIÓN DEL RIESGO

ANÁLISIS Y GESTIÓN DEL RIESGO Son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre. Es una buena idea identificar, evaluar la probabilidad de aparición de un problema, estimar su impacto, y establecer un plan de contingencia. Lo hacen todos los que estén involucrados en el proceso del software: gestores, ingenieros de software y clientes. El software es una empresa difícil. Muchas cosas pueden ir mal, a menudo van mal. Esta es la razón para estar preparados comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o gestionarlo es un elemento clave de una buena gestión de proyectos de software.

PASOS A SEGUIR El reconocimiento de que algo puede ir mal : identificación del riesgo. Analizar para determinar la probabilidad de que pueda ocurrir y el daño que puede causar si ocurre. Priorizar los riesgos, en función de la probabilidad y del impacto. Por último, se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto. Se obtiene: un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe de riesgos. Uno se asegura que todo este marchando bien, REVISANDO constantemente. Los planes de contingencia para la gestión del riesgo deben ser realistas.

ESTRATEGIAS DE RIESGO PROACTIVAS VS. REACTIVAS ESTRATEGIAS DE RIESGO REACTIVAS. Supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo «de bomberos». Cuando falla, «la gestión de crisis» entra en acción y el proyecto se encuentra en peligro real. ESTRATEGIA INTELIGENTE PARA EL CONTROL DEL RIESGO ES SER PROACTIVO. Empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia.

RIESGO DEL SOFTWARE Tiene dos características: INCERTIDUMBRE: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad. PÉRDIDA: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

IDENTIFICACION DEL RIESGO Intento sistemático para especificar las amenazas al plan del proyecto. Hay dos tipos: Los riesgos genéricos son una amenaza potencial para todos los proyectos de software. Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Forma de identificar los riesgos La lista de comprobación y se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: Tamaño del producto Impacto en el negocio Características del cliente Definición del proceso Entorno de desarrollo Tecnología a construir Tamaño y experiencia de la plantilla

COMPONENTES Y CONTROLADORES DEL RIESGO Son rendimiento, coste, soporte y planificación temporal Riesgo de Rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido. Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto. Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado; Riesgo de la planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo. El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto: despreciable, marginal, crítico y catastrófico.

Riesgos y relevancia para la gestión PROYECCION DEL RIESGO Desarrollo de una tabla de riesgo: proporciona al jefe una sencilla técnica para la proyección del riesgo Riesgos y relevancia para la gestión

Evaluación del impacto del riesgo: Tres factores afectan a las consecuencias probables de un riesgo si ocurre: su naturaleza, su alcance y cuando ocurre. Se recomiendan los siguientes pasos para determinar las consecuencias generales de un riesgo: Determinar la probabilidad media de que ocurra un valor para cada componente de riesgo. Empleando la Figura 6.1, determinar el impacto de cada componente basándose en los criterios mostrados. Completar la tabla de riesgo y analizar los resultados como se describe en las secciones precedentes. La exposición al riesgo en general, ER, se determina utilizando la siguiente relación ER=PxC donde P es la probabilidad de que ocurra un riesgo, y C es el coste del proyecto si el riesgo ocurriera.

Evaluación del riesgo: En este punto del proceso de gestión del riesgo, hemos establecido un conjunto de temas de la forma: [ri , li , xi 1 donde ri es el riesgo, li es la probabilidad del riesgo y xi es el impacto del riesgo. Durante la evaluación del riesgo, se sigue examinando la exactitud de las estimaciones que fueron hechas durante la proyección del riesgo, se intenta dar prioridades a los riesgos que no se habían cubierto y se empieza a pensar las maneras de controlar y/o impedir los riesgos que sea más probable que aparezcan. Para que sea útil la evaluación, se debe definir un nivel de referencia de riesgo. Para la mayoría de los proyectos, los componentes de riesgo estudiados anteriormente rendimiento, coste, soporte y planificación temporal también representan niveles de referencia de riesgos.

REFINAMIENTO DEL RIESGO Una forma de hacer esto es presentar el riesgo de la forma condición- transición-consecuencia (CTC). Es decir, el riesgo se presenta de la siguiente forma: Dada esta <condición> entonces existe preocupación por (posiblemente) <consecuencia>. Utilizando el formato CTC para volver a utilizar el riesgo presentado en la Sección 6.4.2, podemos escribir: La condición general que acabamos de destacar puede ser refinada de la siguiente manera: Subcondición 1: Ciertos componentes reutilizables fueron desarrollados por terceras personas sin el conocimiento de los estándares internos de diseño. Subcondición 2: El estándar de diseño para interfaces de componentes no ha sido asentado y puede no ajustarse a ciertos componentes reutilizables existentes. Subcondición 3: Ciertos componentes reutilizables han sido implementados en un lenguaje no soportado por el entorno para el que el sistema ha sido construido.

REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: Evitar el riesgo. Supervisar el riesgo, y Gestionar el riesgo y planes de contingencia

Supervisar los siguientes factores: Actitud general de los miembros del equipo basándose en las presiones del proyecto; Grado de compenetración del equipo; Relaciones interpersonales entre los miembros del equipo; Problemas potenciales con compensaciones y beneficios; Disponibilidad de empleo dentro y fuera de la compañía.

RIESGOS Y PELIGROS PARA LA SEGURIDAD La seguridad del software y el análisis del peligro son actividades para garantizar la calidad del software que se centra en la identificación y evaluación de peligros potenciales que pueden impactar al software negativamente y provocar que falle el sistema entero. Si se pueden identificar los peligros al principio del proceso de ingeniería del software, se pueden especificar características de diseño software que eliminen o controlen esos peligros potenciales. Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se podrían organizar los pasos de gestión del riesgo en un Plan diferente de reducción, supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del análisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general. Plan RSGR

EL PLAN RSGR Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se podrían organizar los pasos de gestión del riesgo en un Plan diferente de reducción, Supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del análisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general.

Poner el sentido común nos aconseja realizar un análisis de riesgo y debemos hacerlo formal identificando, analizando y gestionando el riesgo. Merece la pena para evitar trastornos durante el proyecto.