SlideShare una empresa de Scribd logo
1 de 10
Descargar para leer sin conexión
Miguel Ángel Guillen Reyes
ANÁLISIS DE RIESGOS DE UN PROYECTO DE SOFTWARE
Definiciones:
• Riesgo: medida de la probabilidad y gravedad de sufrir efectos adversos.
• Riesgo técnico en software: medida de la probabilidad y gravedad de sufrir efectos
adversos inherentes al desarrollo de software que no cumpla con sus requerimientos
funcionales y/o no funcionales.
Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos
preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasara? El cambio es nuestra
preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías
de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades
relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general?
Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos
emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad?
Peter Drucker dijo una vez: "Mientras que es inútil intentar eliminar el riesgo y
cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos
adecuados". Antes de poder identificar los "riesgos adecuados" que se pueden tomar en un
proyecto de software, es importante poder identificar todos los riesgos que sean obvios a
jefes de proyectos y profesionales del software.
Miguel Ángel Guillen Reyes
ANÁLISIS DE RIESGOS DE UN PROYECTO DE SOFTWARE
El análisis de riesgos informáticos es un proceso que comprende la identificación de activos
informáticos, sus vulnerabilidades y amenazas a los que se encuentran expuestos así como
su probabilidad de ocurrencia y el impacto de las mismas, a fin de determinar los controles
adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo.
El proceso de análisis de riesgo genera habitualmente un documento al cual se le conoce
como matriz de riesgo. En este documento se muestran los elementos identificados, la
manera en que se relacionan y los cálculos realizados.
Este análisis de riesgo es indispensable para lograr una correcta administración del riesgo.
La administración del riesgo hace referencia a la gestión de los recursos de la organización.
Existen diferentes tipos de riesgos como el riesgo residual y riesgo total así como también
el tratamiento del riesgo, evaluación del riesgo y gestión del riesgo entre otras.
La fórmula para determinar el riesgo total es: RT (Riesgo Total) = Probabilidad x Impacto
Promedio
Después de efectuar el análisis debemos determinar las acciones a tomar respecto a los
riesgos residuales que se identificaron. Las acciones pueden ser:
• Controlar el riesgo.- Fortalecer los controles existentes y/o agregar nuevos controles.
• Eliminar el riesgo.- Eliminar el activo relacionado y con ello se elimina el riesgo.
Compartir el riesgo.- Mediante acuerdos contractuales parte del riesgo se traspasa a un
tercero.
• Aceptar el riesgo.- Se determina que el nivel de exposición es adecuado y por lo tanto se
acepta.
Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por
ejemplo, no hay riesgos de un 100 por ciento 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.
Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del
proyecto se hacen realidad, es probable que la planificación temporal del proyecto se
retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas
potenciales de presupuesto, planificación temporal, personal (asignación y organización),
recursos, cliente y requisitos y su impacto en un proyecto de software.
Miguel Ángel Guillen Reyes
Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay
que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar
a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño,
implementación, de interfaz. Verificación y de mantenimiento. Además, las ambigüedades
de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta"
son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más
difícil de resolver de lo que pensábamos.
Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del
negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los
cinco principales riesgos del negocio 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.
4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de
personal (riesgo de dirección).
5. Perder presupuesto o personal asignado (riesgos de presupuesto).
Identificación del riesgo
La identificación del riesgo es un intento sistemático para especificar las amenazas al plan
del proyecto (estimaciones, planificación temporal, carga de recursos, etc). Identificando
los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para
evitarlos cuando sea posible y controlarlos cuando sea necesario.
Existen dos tipos diferenciados de riesgos para cada categoría presentada en el apartado
anterior: genéricos y específicos del producto. Los riesgos genéricos son una amenaza
potencial para todos los proyectos de software. Los específicos de producto sólo los pueden
identificar los que tienen una clara visión de la tecnología. el personal y el entomo
específico del proyecto en cuestión. Para identificar los riesgos específicos del producto se
examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una
respuesta a la siguiente pregunta: ¿Qué características especiales de este producto pueden
estar amenazadas por nuestro plan del proyecto'?"
Tanto los riesgos genéricos como los específicos del producto se deberían identificar
sistemáticamente. Tom Gilb tiene toda la razón cuando dice: "Si no atacas activamente a
los riesgos ellos te atacarán activamente a ti", Un método para identificar riesgos es crear
una lista de comprobación de elementos de riesgo. La lista de comprobación se puede
Miguel Ángel Guillen Reyes
utilizar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y
predecibles en las siguientes subcategorías genéricas:
• Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a
modificar.
• Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o
por el mercado.
• Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad
del desarrollador para comunicarse con el cliente en los momentos oportunos.
• Definición del proceso: riesgos asociados con el grado de definición del proceso del
software y su seguimiento por la organización de desarrollo.
• Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que se van a emplear en la construcción del producto.
• Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la
tecnología punta que contiene el sistema.
• Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de
proyectos de los ingenieros del software que van a realizar el trabajo.
La lista de comprobación de elementos de riesgo puede organizarse de diferentes maneras.
Se pueden responder a cuestiones relevantes de cada uno de los temas apuntados
anteriormente para cada proyecto de software. Las respuestas a estas preguntas permiten al
planificador del proyecto estimar el impacto del riesgo. Un formato diferente de lista de
comprobación de elementos de riesgo contiene simplemente las características relevantes
para cada subcategoría genérica. Finalmente, se lista un conjunto de "componentes y
controladores del riesgo" junto con sus probabilidades de aparición. Los controladores del
rendimiento, el soporte, el coste y la planificación temporal del proyecto se estudian como
respuesta a preguntas posteriores.
Riesgos del tamaño del producto
Pocos gestores experimentados discutirían la siguiente frase: El riesgo del proyecto es
directamente proporcional al tamaño dcl producto. La siguiente lista de comprobación de
elementos de riesgo identifica riesgos genéricos asociados con el tamaño del producto
(software):
• ¿Tamaño estimado del producto en LDC o FP?
• ¿Grado de seguridad en la estimación del tamaño?
Miguel Ángel Guillen Reyes
• ¿Tamaño estimado del producto en número de programas, archivos y transacciones?
• ¿Porcentaje de desviación en el tamaño del producto respecto a la medida de productos
anteriores?
• ¿Tamaño de la base de datos creada o empleada por el producto?
• ¿Número de usuarios del producto?
• ¿Número de cambios previstos a los requisitos del producto? ¿Antes de la entrega?
¿Después de la entrega?
• ¿Cantidad de software reutilizado?
En cada caso, la información del producto a desarrollar debe compararse con la experiencia
anterior. Si ocurre una gran desviación del porcentaje o si las magnitudes son similares,
pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande.
Miguel Ángel Guillen Reyes
Tabla de Gestión de Riesgo
RIESGO PROBABILIDAD IMPACTO ESTRATEGIA DE
RECOMPENSA.
Riesgo del Proyecto
Presupuesto 0.10 Ma Sumar el 20% al costo real del
software.
Planificación Temporal 0.08 Ma Realizar un descuento del 5 % por
cada mes de retraso.
Personal( Asignación y
Organización)
0.02 De Motivación, capacitación al
personal.
Recursos 0.10 Ma Optimizar los recursos.
Clientes y sus requisitos 0.18 Ma Entablar una buena comunicación
con el cliente.
Impacto 0.14 Ma Crear una buena campaña
publicitaria, promover en las
diferentes empresas.
Riesgo Técnico
Diseño 0.07 De Crear un buen diseño llamativo y
que cumpla con las necesidades
del cliente.
Implementación 0.11 Ma Brindar capacitación al usuario
del software.
Interfaz 0.04 De Atender las solicitudes del cliente.
Verificación 0.10 Ma Establecer un periodo de prueba
de un mes para realizar ciertas
validaciones.
Miguel Ángel Guillen Reyes
Mantenimiento 0.02 De Fijar una fecha para dar
mantenimiento al menos una vez
al mes.
Riesgo del Negocio
Riesgo de Mercadeo. 0.24 Cr Brindar un software de prueba
para mostrar la funcionalidad y
aceptación del mismo.
Riesgo Estratégico. 0.08 Ma Realizar modificaciones
requeridas por el cliente.
Riesgo de
Mercadotecnia
0.19 Cr Ofertar el software en los
distintos medios de publicidad
(Tv, radio, internet, etc.)
Riesgo de perder
contacto con el personal
del negocio.
0.20 Ma Firmar contrato con
representante jurídico del
negocio.
Cierre del negocio.
0.34 Ca Ofrecerlo a otras empresas y
realizar modificaciones
requeridas por el nuevo cliente.
Miguel Ángel Guillen Reyes
El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después de
haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos están
típicamente asociados con las consecuencias del fallo del software una vez en el mercado.
Aunque la probabilidad de fallo de un sistema de alta ingeniería es pequeña, un defecto no
detectado en un sistema de control y supervisión basados en ordenador podría provocar unas
pérdidas económicas enormes, o peor, daños físicos significativos o pérdida de vidas humanas.
Pero el coste y beneficios funcionales del control y supervisión basados en computadora a
rnenudo superan al riesgo. Hoy en día, se emplean regularmente hardware y software para el
control de sistemas de seguridad crítica.
Cuando se emplea software como parte del sistema de control, la complejidad puede aumentar
del orden de una magnitud o más. Sutiles defectos de diseño inducidos por error humano -algo
que puede descubrirse y eliminarse con controles convencionales basados en hardware- se
convierten en mucho más difíciles de descubrir cuando se emplea software.
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.
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. A continuación se expone un esquema del Plan RSGR.
I. Introducción
1. Alcance y propósito del documento.
2. Visión general de los riesgos principales.
3. Responsabilidades.
a. Gestión.
b. Personal técnico.
II. Tabla de riesgo del proyecto.
1. Descripción de todos los riesgos por encima de la línea de corte.
2. Factores que influyen en la probabilidad e impacto
Miguel Ángel Guillen Reyes
III. Reducción, supervisión y gestión del riesgo
1. Riesgo #n
a. Reducción
i.Estrategia general.
ii. Pasos específicos.
b. Supervisión
i. Factores a supervisar.
ii. Enfoque de supervisión.
c. Gestión
i. Plan de contingencia.
ii. Consideraciones especiales.
IV. Planificación temporal de revisión del Plan RSGR.
V. Resumen.
Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los
procedimientos de reducción y supervisión del riesgo Como ya hemos dicho antes, la reducción
del riesgo es una actividad para evitar problemas La supervisión del riesgo es una actividad de
seguimiento del proyecto con tres objetivos principales:
1) Valorar cuando un riesgo previsto ocurre de hecho
2) Asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestión
se están aplicando apropiadamente
3) Recoger información que pueda emplearse en el futuro para analizar riesgos.
En muchos casos, los problemas que ocurren durante un proyecto pueden afectar a más de un
riesgo. Otro trabajo de la supervisión de riesgos es intentar determinar el "origen" (qué riesgos
ocasionaron tal problema) a lo largo de todo el proyecto.
Miguel Ángel Guillen Reyes
Bibliografía
Murcia, U. d. (13 de diciembre de 2002). Universidad de Murcia. Recuperado el 20 de mayo de 2014, de
http://dis.um.es/~barzana/Informatica/IAGP/IAGP_riesgos.html
Vargas, A. (18 de octubre de 2010). Blog: Ingeniería del software. Recuperado el 20 de mayo de 2014, de
http://arielvargasu.blogspot.mx/2010/10/analisis-y-gestion-de-riesgo_18.html
Wikipedia. (s.f.). Recuperado el 20 de mayo de 2014, de
http://es.wikipedia.org/wiki/An%C3%A1lisis_de_riesgo_inform%C3%A1tico

Más contenido relacionado

La actualidad más candente

54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-softwarecristina_devargas
 
Presentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwarePresentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwareJose Ignacio Rojas Henriquez
 
Metricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionMetricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionJose Diaz Silva
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioSergio Sanchez
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareNelson Guanipa
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del softwareuniv of pamplona
 
Diagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegueDiagramas UML: Componentes y despliegue
Diagramas UML: Componentes y desplieguejoshell
 
Ingeniería de requisitos y de requerimientos
Ingeniería de requisitos y de requerimientosIngeniería de requisitos y de requerimientos
Ingeniería de requisitos y de requerimientosunrated999
 
calidad de los sistemas de informacion
calidad de los sistemas de informacioncalidad de los sistemas de informacion
calidad de los sistemas de informacionErika Vazquez
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionalesAngel Minga
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftChuyito Alvarado
 
Topicos de ingeniería de software
Topicos de ingeniería de softwareTopicos de ingeniería de software
Topicos de ingeniería de softwareAlex Hurtado
 
Gestión de riesgos de software
Gestión de riesgos de softwareGestión de riesgos de software
Gestión de riesgos de softwareOmar S. Gomez
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de softwareGeorgy Jose Sanchez
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosJosé Antonio Sandoval Acosta
 

La actualidad más candente (20)

54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software
 
Presentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwarePresentacion planificación de proyecto de software
Presentacion planificación de proyecto de software
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Metricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionMetricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccion
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
 
PLAN SQA
PLAN SQAPLAN SQA
PLAN SQA
 
Cocomo ii
Cocomo iiCocomo ii
Cocomo ii
 
Modelo cascada
Modelo cascadaModelo cascada
Modelo cascada
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de Software
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Diagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegueDiagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegue
 
Ingeniería de requisitos y de requerimientos
Ingeniería de requisitos y de requerimientosIngeniería de requisitos y de requerimientos
Ingeniería de requisitos y de requerimientos
 
calidad de los sistemas de informacion
calidad de los sistemas de informacioncalidad de los sistemas de informacion
calidad de los sistemas de informacion
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Topicos de ingeniería de software
Topicos de ingeniería de softwareTopicos de ingeniería de software
Topicos de ingeniería de software
 
Gestión de riesgos de software
Gestión de riesgos de softwareGestión de riesgos de software
Gestión de riesgos de software
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
 
Modelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiralModelos evolutivos. incremental y espiral
Modelos evolutivos. incremental y espiral
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 

Similar a Análisis de riesgos de un proyecto de software

Analisis y-gestion-de-riesgo
Analisis y-gestion-de-riesgoAnalisis y-gestion-de-riesgo
Analisis y-gestion-de-riesgodaniieMS
 
Ra semana 11 2
Ra semana 11 2Ra semana 11 2
Ra semana 11 2victdiazm
 
Gestion de riesgos
Gestion de riesgosGestion de riesgos
Gestion de riesgosjoselucho_89
 
Gestion De Riesgos
Gestion De RiesgosGestion De Riesgos
Gestion De Riesgospelusa
 
exposicionRiesgosauditoria
exposicionRiesgosauditoriaexposicionRiesgosauditoria
exposicionRiesgosauditoriazaira
 
Riesgosauditoria
RiesgosauditoriaRiesgosauditoria
Riesgosauditoriazaira
 
Exposición Riesgos de Auditoria
Exposición Riesgos de AuditoriaExposición Riesgos de Auditoria
Exposición Riesgos de AuditoriaYojana
 
Exposicion riesgos
Exposicion riesgosExposicion riesgos
Exposicion riesgoslucriman
 
Diapositivas silvia
Diapositivas silviaDiapositivas silvia
Diapositivas silviaflaca8
 
Analisis De Riesgo Sesion 4
Analisis De Riesgo Sesion 4Analisis De Riesgo Sesion 4
Analisis De Riesgo Sesion 4guest73516b
 
Analisisderiesgosesion4 090827205437-phpapp01
Analisisderiesgosesion4 090827205437-phpapp01Analisisderiesgosesion4 090827205437-phpapp01
Analisisderiesgosesion4 090827205437-phpapp01oscar91537867
 
Control De Riesgo Sesion 4
Control De Riesgo Sesion 4Control De Riesgo Sesion 4
Control De Riesgo Sesion 4Teresa Cossio
 

Similar a Análisis de riesgos de un proyecto de software (20)

Introducción
IntroducciónIntroducción
Introducción
 
Ppi t4 3
Ppi t4 3Ppi t4 3
Ppi t4 3
 
Ppi t4 3
Ppi t4 3Ppi t4 3
Ppi t4 3
 
Analisis y-gestion-de-riesgo
Analisis y-gestion-de-riesgoAnalisis y-gestion-de-riesgo
Analisis y-gestion-de-riesgo
 
Ra semana 11 2
Ra semana 11 2Ra semana 11 2
Ra semana 11 2
 
análisis y gestión del riesgo
análisis y gestión del riesgoanálisis y gestión del riesgo
análisis y gestión del riesgo
 
Gestion de riesgos
Gestion de riesgosGestion de riesgos
Gestion de riesgos
 
Gestion De Riesgos
Gestion De RiesgosGestion De Riesgos
Gestion De Riesgos
 
Trabajo analisisriesgo22
Trabajo analisisriesgo22Trabajo analisisriesgo22
Trabajo analisisriesgo22
 
Riesgos
RiesgosRiesgos
Riesgos
 
GESTION DEL RIESGO
GESTION DEL RIESGOGESTION DEL RIESGO
GESTION DEL RIESGO
 
exposicionRiesgosauditoria
exposicionRiesgosauditoriaexposicionRiesgosauditoria
exposicionRiesgosauditoria
 
Riesgosauditoria
RiesgosauditoriaRiesgosauditoria
Riesgosauditoria
 
Exposición Riesgos de Auditoria
Exposición Riesgos de AuditoriaExposición Riesgos de Auditoria
Exposición Riesgos de Auditoria
 
Exposicion riesgos
Exposicion riesgosExposicion riesgos
Exposicion riesgos
 
Diapositivas silvia
Diapositivas silviaDiapositivas silvia
Diapositivas silvia
 
Analisis De Riesgo Sesion 4
Analisis De Riesgo Sesion 4Analisis De Riesgo Sesion 4
Analisis De Riesgo Sesion 4
 
Analisisderiesgosesion4 090827205437-phpapp01
Analisisderiesgosesion4 090827205437-phpapp01Analisisderiesgosesion4 090827205437-phpapp01
Analisisderiesgosesion4 090827205437-phpapp01
 
3.5 tipos de riesgos
3.5 tipos de riesgos3.5 tipos de riesgos
3.5 tipos de riesgos
 
Control De Riesgo Sesion 4
Control De Riesgo Sesion 4Control De Riesgo Sesion 4
Control De Riesgo Sesion 4
 

Más de Angel Reyes

Sistemas de información
Sistemas de informaciónSistemas de información
Sistemas de informaciónAngel Reyes
 
Funciones de sql
Funciones de sqlFunciones de sql
Funciones de sqlAngel Reyes
 
Administración de unidades informáticas
Administración de unidades  informáticasAdministración de unidades  informáticas
Administración de unidades informáticasAngel Reyes
 
Sistemas expertos
Sistemas expertosSistemas expertos
Sistemas expertosAngel Reyes
 
Tabla de verbos irregulares
Tabla de verbos irregularesTabla de verbos irregulares
Tabla de verbos irregularesAngel Reyes
 
Infonavit y fovissste
Infonavit y fovisssteInfonavit y fovissste
Infonavit y fovisssteAngel Reyes
 

Más de Angel Reyes (8)

Sistemas de información
Sistemas de informaciónSistemas de información
Sistemas de información
 
Ethernet
EthernetEthernet
Ethernet
 
Funciones de sql
Funciones de sqlFunciones de sql
Funciones de sql
 
Administración de unidades informáticas
Administración de unidades  informáticasAdministración de unidades  informáticas
Administración de unidades informáticas
 
Sistemas expertos
Sistemas expertosSistemas expertos
Sistemas expertos
 
Tierra física
Tierra físicaTierra física
Tierra física
 
Tabla de verbos irregulares
Tabla de verbos irregularesTabla de verbos irregulares
Tabla de verbos irregulares
 
Infonavit y fovissste
Infonavit y fovisssteInfonavit y fovissste
Infonavit y fovissste
 

Análisis de riesgos de un proyecto de software

  • 1. Miguel Ángel Guillen Reyes ANÁLISIS DE RIESGOS DE UN PROYECTO DE SOFTWARE Definiciones: • Riesgo: medida de la probabilidad y gravedad de sufrir efectos adversos. • Riesgo técnico en software: medida de la probabilidad y gravedad de sufrir efectos adversos inherentes al desarrollo de software que no cumpla con sus requerimientos funcionales y/o no funcionales. Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasara? El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general? Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad? Peter Drucker dijo una vez: "Mientras que es inútil intentar eliminar el riesgo y cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados". Antes de poder identificar los "riesgos adecuados" que se pueden tomar en un proyecto de software, es importante poder identificar todos los riesgos que sean obvios a jefes de proyectos y profesionales del software.
  • 2. Miguel Ángel Guillen Reyes ANÁLISIS DE RIESGOS DE UN PROYECTO DE SOFTWARE El análisis de riesgos informáticos es un proceso que comprende la identificación de activos informáticos, sus vulnerabilidades y amenazas a los que se encuentran expuestos así como su probabilidad de ocurrencia y el impacto de las mismas, a fin de determinar los controles adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo. El proceso de análisis de riesgo genera habitualmente un documento al cual se le conoce como matriz de riesgo. En este documento se muestran los elementos identificados, la manera en que se relacionan y los cálculos realizados. Este análisis de riesgo es indispensable para lograr una correcta administración del riesgo. La administración del riesgo hace referencia a la gestión de los recursos de la organización. Existen diferentes tipos de riesgos como el riesgo residual y riesgo total así como también el tratamiento del riesgo, evaluación del riesgo y gestión del riesgo entre otras. La fórmula para determinar el riesgo total es: RT (Riesgo Total) = Probabilidad x Impacto Promedio Después de efectuar el análisis debemos determinar las acciones a tomar respecto a los riesgos residuales que se identificaron. Las acciones pueden ser: • Controlar el riesgo.- Fortalecer los controles existentes y/o agregar nuevos controles. • Eliminar el riesgo.- Eliminar el activo relacionado y con ello se elimina el riesgo. Compartir el riesgo.- Mediante acuerdos contractuales parte del riesgo se traspasa a un tercero. • Aceptar el riesgo.- Se determina que el nivel de exposición es adecuado y por lo tanto se acepta. Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento 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. Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software.
  • 3. Miguel Ángel Guillen Reyes Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz. Verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta" son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos. Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio 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. 4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección). 5. Perder presupuesto o personal asignado (riesgos de presupuesto). Identificación del riesgo La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario. Existen dos tipos diferenciados de riesgos para cada categoría presentada en el apartado anterior: genéricos y específicos del producto. Los riesgos genéricos son una amenaza potencial para todos los proyectos de software. Los específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología. el personal y el entomo específico del proyecto en cuestión. Para identificar los riesgos específicos del producto se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta: ¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto'?" Tanto los riesgos genéricos como los específicos del producto se deberían identificar sistemáticamente. Tom Gilb tiene toda la razón cuando dice: "Si no atacas activamente a los riesgos ellos te atacarán activamente a ti", Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista de comprobación se puede
  • 4. Miguel Ángel Guillen Reyes utilizar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: • Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar. • Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el mercado. • Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos. • Definición del proceso: riesgos asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo. • Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto. • Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología punta que contiene el sistema. • Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo. La lista de comprobación de elementos de riesgo puede organizarse de diferentes maneras. Se pueden responder a cuestiones relevantes de cada uno de los temas apuntados anteriormente para cada proyecto de software. Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del riesgo. Un formato diferente de lista de comprobación de elementos de riesgo contiene simplemente las características relevantes para cada subcategoría genérica. Finalmente, se lista un conjunto de "componentes y controladores del riesgo" junto con sus probabilidades de aparición. Los controladores del rendimiento, el soporte, el coste y la planificación temporal del proyecto se estudian como respuesta a preguntas posteriores. Riesgos del tamaño del producto Pocos gestores experimentados discutirían la siguiente frase: El riesgo del proyecto es directamente proporcional al tamaño dcl producto. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el tamaño del producto (software): • ¿Tamaño estimado del producto en LDC o FP? • ¿Grado de seguridad en la estimación del tamaño?
  • 5. Miguel Ángel Guillen Reyes • ¿Tamaño estimado del producto en número de programas, archivos y transacciones? • ¿Porcentaje de desviación en el tamaño del producto respecto a la medida de productos anteriores? • ¿Tamaño de la base de datos creada o empleada por el producto? • ¿Número de usuarios del producto? • ¿Número de cambios previstos a los requisitos del producto? ¿Antes de la entrega? ¿Después de la entrega? • ¿Cantidad de software reutilizado? En cada caso, la información del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviación del porcentaje o si las magnitudes son similares, pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande.
  • 6. Miguel Ángel Guillen Reyes Tabla de Gestión de Riesgo RIESGO PROBABILIDAD IMPACTO ESTRATEGIA DE RECOMPENSA. Riesgo del Proyecto Presupuesto 0.10 Ma Sumar el 20% al costo real del software. Planificación Temporal 0.08 Ma Realizar un descuento del 5 % por cada mes de retraso. Personal( Asignación y Organización) 0.02 De Motivación, capacitación al personal. Recursos 0.10 Ma Optimizar los recursos. Clientes y sus requisitos 0.18 Ma Entablar una buena comunicación con el cliente. Impacto 0.14 Ma Crear una buena campaña publicitaria, promover en las diferentes empresas. Riesgo Técnico Diseño 0.07 De Crear un buen diseño llamativo y que cumpla con las necesidades del cliente. Implementación 0.11 Ma Brindar capacitación al usuario del software. Interfaz 0.04 De Atender las solicitudes del cliente. Verificación 0.10 Ma Establecer un periodo de prueba de un mes para realizar ciertas validaciones.
  • 7. Miguel Ángel Guillen Reyes Mantenimiento 0.02 De Fijar una fecha para dar mantenimiento al menos una vez al mes. Riesgo del Negocio Riesgo de Mercadeo. 0.24 Cr Brindar un software de prueba para mostrar la funcionalidad y aceptación del mismo. Riesgo Estratégico. 0.08 Ma Realizar modificaciones requeridas por el cliente. Riesgo de Mercadotecnia 0.19 Cr Ofertar el software en los distintos medios de publicidad (Tv, radio, internet, etc.) Riesgo de perder contacto con el personal del negocio. 0.20 Ma Firmar contrato con representante jurídico del negocio. Cierre del negocio. 0.34 Ca Ofrecerlo a otras empresas y realizar modificaciones requeridas por el nuevo cliente.
  • 8. Miguel Ángel Guillen Reyes El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después de haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos están típicamente asociados con las consecuencias del fallo del software una vez en el mercado. Aunque la probabilidad de fallo de un sistema de alta ingeniería es pequeña, un defecto no detectado en un sistema de control y supervisión basados en ordenador podría provocar unas pérdidas económicas enormes, o peor, daños físicos significativos o pérdida de vidas humanas. Pero el coste y beneficios funcionales del control y supervisión basados en computadora a rnenudo superan al riesgo. Hoy en día, se emplean regularmente hardware y software para el control de sistemas de seguridad crítica. Cuando se emplea software como parte del sistema de control, la complejidad puede aumentar del orden de una magnitud o más. Sutiles defectos de diseño inducidos por error humano -algo que puede descubrirse y eliminarse con controles convencionales basados en hardware- se convierten en mucho más difíciles de descubrir cuando se emplea software. 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. 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. A continuación se expone un esquema del Plan RSGR. I. Introducción 1. Alcance y propósito del documento. 2. Visión general de los riesgos principales. 3. Responsabilidades. a. Gestión. b. Personal técnico. II. Tabla de riesgo del proyecto. 1. Descripción de todos los riesgos por encima de la línea de corte. 2. Factores que influyen en la probabilidad e impacto
  • 9. Miguel Ángel Guillen Reyes III. Reducción, supervisión y gestión del riesgo 1. Riesgo #n a. Reducción i.Estrategia general. ii. Pasos específicos. b. Supervisión i. Factores a supervisar. ii. Enfoque de supervisión. c. Gestión i. Plan de contingencia. ii. Consideraciones especiales. IV. Planificación temporal de revisión del Plan RSGR. V. Resumen. Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reducción y supervisión del riesgo Como ya hemos dicho antes, la reducción del riesgo es una actividad para evitar problemas La supervisión del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales: 1) Valorar cuando un riesgo previsto ocurre de hecho 2) Asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestión se están aplicando apropiadamente 3) Recoger información que pueda emplearse en el futuro para analizar riesgos. En muchos casos, los problemas que ocurren durante un proyecto pueden afectar a más de un riesgo. Otro trabajo de la supervisión de riesgos es intentar determinar el "origen" (qué riesgos ocasionaron tal problema) a lo largo de todo el proyecto.
  • 10. Miguel Ángel Guillen Reyes Bibliografía Murcia, U. d. (13 de diciembre de 2002). Universidad de Murcia. Recuperado el 20 de mayo de 2014, de http://dis.um.es/~barzana/Informatica/IAGP/IAGP_riesgos.html Vargas, A. (18 de octubre de 2010). Blog: Ingeniería del software. Recuperado el 20 de mayo de 2014, de http://arielvargasu.blogspot.mx/2010/10/analisis-y-gestion-de-riesgo_18.html Wikipedia. (s.f.). Recuperado el 20 de mayo de 2014, de http://es.wikipedia.org/wiki/An%C3%A1lisis_de_riesgo_inform%C3%A1tico