Ingeniería de Software: Riesgos

Expositores: Adrián Guevara- Marcos Gonzalez

Profesor: Esteban López Belcuore

Temario:
 Conceptos básicos.
 Clasificación de riesgos.
 Proceso de Gestión de riesgos.
 Identificación de riesgos.
 Análisis.
 Planeación.
 Supervisión.

Desarrollo:

 Conceptos Básicos

Riesgo: Es cualquier eventualidad que provoque que un sistema informático no se desarrolle en

tiempo, con el presupuesto asignado, que no se atienda las necesidades del negocio ni cumpla con las
expectativas del cliente, que no esté alineado con las metas y el contexto organizacional.
Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir.
Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.
Gestión de Riesgo: Los objetivos de la gestión de riesgos son identificar, dirigir y eliminar las fuentes de
riesgo antes de que empiecen a afectar a la finalización satisfactoria de un proyecto software. La
gestión continuada de los riesgos permite aumentar su eficiencia. Es decir evaluar continuamente lo
que pueda ir mal, determinar qué riesgos son importantes, implementar estrategias para resolverlos,
asegurar la eficacia de las estrategias.

 Clasificación de Riesgos

De acuerdo a aquello que afectan en caso de presentarse:

 Riesgos del proyecto: son aquellos riesgos que alteran al proceso de desarrollo del proyecto.
Identifican problemas potenciales de presupuesto, calendario, personal, recursos, cliente,
etc. Afectan a la planificación temporal, al coste y calidad del proyecto. Por ejemplo, la
renuncia del líder del proyecto.
  Riesgos del producto: son los riesgos que afectan la calidad o el rendimiento del software a
desarrollar. Identifican posibles problemas de incertidumbre técnica, ambigüedad en la
especificación, diseño, implementación, obsolescencia técnica o tecnología puntera,
interfaz, verificación y mantenimiento, etc. Por ejemplo, la adquisición de un componente
software cuyo desempeño se desconoce.
 Riesgos del negocio: estos riesgos son los que afectan a la organización en la que se
desenvuelve el software. Por ejemplo, el cambio de un directivo que puede no estar de
acuerdo con el proyecto, o tener otras prioridades. Los principales riesgos de negocio son:
o Riesgo de mercado: producto demasiado bueno.
o Riesgo estratégico: producto que no encaja.
o Riesgo de ventas: producto poco vendible.
o Riesgo de presupuesto: producto fuera de presupuesto.

En función de su facilidad de detección:

 Riesgos conocidos: son aquellos que se pueden predecir después de una evaluación del plan
del proyecto, del entorno técnico y otras fuentes de información fiables.
 Riesgos predecibles: se extrapolan de la experiencia de proyectos anteriores.
 Riesgos impredecibles: pueden ocurrir, pero es extremadamente difícil identificarlos por
adelantado.

 Proceso de Gestión de Riesgos

 Identificación de riesgos
La identificación del riesgo es una tarea que depende, en gran medid, de la experiencia y del
juicio de quien esté encargado de la identificación. Éste suele ser el administrador del proyecto
aunque también puede ser una actividad en equipo.
Un método para identificar los riesgos es crear una lista de comprobación de elementos de
riesgo que podría contener dos categorías de riesgos:
o Riesgos específicos del producto: para identificarlos se examina el plan del proyecto
y la declaración del ámbito del software.
o Riesgos genéricos: Son comunes a todos los proyectos de software. Para
identificarlos se crean las siguientes subcategorías:
 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 del personal.

En base a esas categorías se presentan diferentes tipos de riesgos más específicos:

 o Riesgos tecnológicos: derivados del software y hardware utilizados.
o Riesgos personales: asociados a las personas involucradas en el desarrollo.
o Riesgos organizacionales: relacionados a la organización.
o Riesgos de herramientas: resultantes de las herramientas de software utilizadas.
o Riesgos de requerimientos: surgen de los cambios en los requerimientos.
o Riesgos de estimación: proceden de las estimaciones de costes y recursos.

 Análisis de Riesgos
Es el proceso de examinar los riesgos en detalle para determinar su impacto, su probabilidad y el
periodo de tiempo en el que es posible atenuar el riesgo.

ATRIBUTO VALOR DESCRIPCIÓN

Impacto Insignificantes No merecen ser tenidos en cuenta.
Tolerables Están dentro de un margen de aceptación,
por lo cual no comprometen ni el
proyecto, ni el producto, ni la
organización.
Graves Comprometen gravemente el proyecto o
el producto o la organización.
Catastrófica Amenazan la supervivencia del proyecto o
del producto o de la organización.
Probabilida Muy baja <10%
d Baja del 10 al 25%
Moderada del 25 al 50%
Alta del 50 al 75%
Muy alta >75%
Marco de Corto plazo 30 días
tiempo Medio plazo 1 a 4 meses
Largo plazo Más de 4 meses

Técnicas de Análisis:
o Análisis no cuantitativo: ésta es la técnica más intuitiva. No cuantifica el riesgo y se
basa en la experiencia y el buen juicio del analista para determinar el impacto y la
probabilidad de ocurrencia de cada riesgo.
o Análisis de ratios: se basa en la comparación de datos de proyectos anteriores con el
actual y en base al criterio de analista incluir un ratio para calcular valores del nuevo
proyecto. Por ejemplo, suponga que no tiene un generador eléctrico. Si para un
proyecto anterior hubo problemas con la empresa de energía y sufrieron dos cortes
semanales, y para la época del proyecto actual la venta de aires acondicionados
superó las espectativas, puede aplicar un ratio de un 50% al riesgo de cortes
semanales, es decir 1,5. Calculando 2 (cortes semanales) * 1,5 (ratio) = 3 cortes
semanales.
o Métodos de análisis híbridos: si bien el contar con números es importante, también
es cierto que las decisiones deben tomarse en función de los números pero
complementadas con la experiencia y conocimiento del decisor. Por eso los métodos
 híbridos aparte de brindar la formalidad de los cálculos, aprovechan la experiencia y
conocimiento del analista.
o Análisis de probabilidad: métodos que utilizan el estudio probabilístico para estimar
riesgos.
o Análisis de sensibilidad: es un método en el que se definen las variables que pueden
afectar al proyecto. Utilizando alguna herramienta o el cálculo matemático se valúan
estas variables para ir presentando las consecuencias de los cambios a todo el
proyecto, es decir, se analiza la sensibilidad del proyecto al cambio en las variables
definidas, lo que permite cuantificar los riesgos.
Con esta información se puede confeccionar una tabla (o matriz) listando los riesgos, detallando
impacto y probabilidad y ordenarlos por prioridad.

 Planeación de Riesgos
Una vez analizados los riesgos podemos determinar una planificación donde se prepare al equipo
para responder de forma adecuada ante éstos. Este plan debe indicar:
o Responsabilidades asignadas por cada riesgo.
o Resultados del análisis de riesgos (probabilidad, impacto, exposición), incluyendo su
priorización.
o Planes de contingencia.
o Respuestas previstas para aquellos riesgos que se han considerado prioritarios y que
serán planificados.
Grupo de estrategias de respuesta al riesgo:
o Evitar o eliminar el riesgo: por ejemplo, si pretende adquirir una herramienta de
desarrollo poco conocida, que presenta altos riesgos de retrasar el calendario, pues
no la compre e inclínese por una herramienta que sí conozca.
o Transferir el riesgo: un ejemplo muy habitual en nuestra industria cordobesa, es la
del riesgo de rotación de personal y de problemas con los empleados, como juicios
laborales, indemnizaciones, etc. En la actualidad las empresas transfieren ese riesgo
a las consultoras. Existen empresas consultoras informáticas que brindan personal a
las grandes empresas para sus proyectos, y asumen los riesgos de contratar los
recursos humanos.
o Atenuar el riesgo: por ejemplo, si existe el riesgo de que el volumen de datos exceda
la capacidad del servidor de base de datos, compre servidores con mayor capacidad
para minimizar este riesgo.
o Aceptación pasiva: no se hace nada. Esta respuesta es aceptable para aquellos
riesgos con muy baja probabilidad de ocurrencia.
o Aceptación activa: si no se puede ser proactivo frente al riesgo, se tiene que estar
preparado para reaccionar. Esta respuesta se da aceptando lo peor y especificando
 un plan para actuar cuando el riesgo se haga realidad, es decir, se definen planes de
contingencia. Por ejemplo, si existe el riesgo de que un servidor se rompa, se dispone
de un plan de restauración, posiblemente mediante la virtualización de servidores y
backups diarios. En los planes de contingencia se debe tener en cuenta:
 Nivel de riesgo residual esperado después de que aplique la respuesta
prevista. La respuesta a un riesgo genera riesgos nuevos.
 Acciones específicas para implementar la estrategia de respuesta a
cambios. Estas acciones deben estar documentadas y compartidas con
todos los participantes del plan. Dado que una contingencia es
inesperada, los involucrados en el plan deberían poder abandonar sus
tareas habituales para atender la contingencia, esto debe ser conocido
y previsto por todos.
 Presupuesto y tiempos para las respuestas.

 Supervisión de Riesgos
Deben controlarse regularmente todos y cada uno de los riesgos considerados para determinar si el
impacto o la probabilidad han cambiado. Si han surgido nuevos riesgos, que no se han detectado
anteriormente o que son resultado de la ocurrencia de los que sí se han identificado (riesgos
residuales). Y en aquellos casos donde el riesgo se presentó poder determinar: si se presentó con la
probabilidad y el impacto esperado; si el plan se llevó adelante según las políticas y procedimientos
adecuados; si las respuestas del plan, más allá de haberse ejecutado correctamente, son efectivas.
Ejemplo de software de medición de riesgos: