Marco Duees Intriago

Mara Cabrales Jaquez

Resumen capitulo 6
Ingeniera del software

Anlisis y gestin de riesgo

Estrategias de riesgo proactivas vs reactivas
Una estrategia considerablemente ms inteligente para el control del riesgo es ser
proactivo. La estrategia proactiva empieza mucho antes de que comiencen los
trabajos tcnicos. Se identifican los riesgos potenciales, se evala su probabilidad
y su impacto y se establece una prioridad segn su importancia. Despus, el
equipo de Software establece un plan para controlar el riesgo. El primer objetivo
es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo
trabaja para desarrollar un plan de contingencia que le permita responder de una
manera eficaz y controlada. A lo largo de lo que queda de este captulo,
estudiamos la estrategia proactiva para el control de riesgos.

Riesgo del software

Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de
software, hay acuerdo comn en que el riesgo siempre implica dos caractersticas:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no

puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de
probabilidad'.

Prdida: si el riesgo se convierte en una realidad, ocurrirn consecuencias

no deseadas o prdidas. Cuando se analizan los riesgos es importante
cuantificar

El nivel de incertidumbre y el grado de prdidas asociado con cada riesgo.

Para hacerlo, se consideran diferentes categoras de riesgos.

Qu tipo de riesgos es probable que nos encontremos en el software que

se construye?

Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del
proyecto se hacen realidad, es probable que la planificacin temporal del proyecto
se retrase y que los costes aumenten. Los riesgos del proyecto identifican los
problemas

potenciales

de

presupuesto,

planificacin

temporal,

personal

(asignacin y organizacin), recursos, cliente y requisitos y su impacto en un

proyecto de software. En el Captulo 5, la complejidad del proyecto, tamao y el
grado de incertidumbre estructural fueron tambin definidos como factores (y
estimados) de riesgo del proyecto. Los riesgos tcnicos amenazan la calidad y la
planificacin temporal del software que hay que producir. Si un riesgo tcnico se
convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los
riesgos tcnicos identifican problemas potenciales de diseo, implementacin, de
interfaz, verificacin y de mantenimiento. Adems, las ambigedades de
especificaciones, incertidumbre tcnica, tcnicas anticuadas y las tecnologas
punta son tambin factores de riesgo.

Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo

que pensbamos. 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 3 principales riesgos del negocio son:

Construir un producto o sistema excelente que no quiere nadie en realidad

(riesgo de mercado)

Construir un producto que no encaja en la estrategia comercial general de

la compaa (riesgo estratgico)

Construir un producto que el departamento de ventas no

Identificacin del riesgo

La identificacin del riesgo es un intento sistemtico para especificar las
amenazas al plan del proyecto (estimaciones, planificacin 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 categora presentada en la
Seccin 6.2:

Riesgos genricos: son una amenaza potencial para todos los proyectos de
software.

Los riesgos especficos de producto slo los pueden identificar los que
tienen una clara visin de la tecnologa, el personal y el entorno especfico
del proyecto en cuestin.

Para identificar los riesgos especficos del producto, se examinan el plan del
proyecto y la declaracin del mbito del software y se desarrolla una respuesta a
la siguiente pregunta:
Qu caractersticas especiales de este producto pueden estar amenazadas por
nuestro plan del proyecto?
Un mtodo para identificar riesgos es crear una lista de comprobacin de
elementos de riesgo. La lista de comprobacin se puede utilizar para identificar
riesgos y se centra en un subconjunto de riesgos conocidos y predecibles en las
siguientes sub-categoras genricas:

Tamao del producto: riesgos asociados con el tamao general del

software a construir o a modificar.

Impacto en el negocio: riesgos asociados con las limitaciones impuestas

por la gestin o por el mercado.

Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente

y la habilidad del desarrollador para comunicarse con el cliente en los
momentos oportunos.

Definicin del proceso: riesgos asociados con el grado de definicin del

proceso del software y su seguimiento por la organizacin de desarrollo.

Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de

las herramientas que se van a emplear en la construccin del producto.

Tecnologa a construir: riesgos asociados con la complejidad del sistema a

construir y la tecnologa punta que contiene el sistema.

Tamao y experiencia de la plantilla: riesgos asociados con la experiencia

tcnica y de proyectos de los ingenieros del software que van a realizar el
trabajo.

Proyeccin del riesgo

La proyeccin del riesgo, tambin denominada estimacin del riesgo, intenta medir
cada riesgo de dos maneras la probabilidad de que el riesgo sea real y las
consecuencias de los problemas asociados con el riesgo, si ocurriera.

Desarrollo de una tabla de riesgos

Una tabla de riesgo le proporciona al jefe del proyecto una sencilla tcnica para la
proyeccin del riesgo.
La tabla de riesgo debera implementarse como un modelo de hoja de clculo.
Esto permite un fcil manejo y ordenacin de las entradas.

Ingeniera del software. Un enfoque practico

Un equipo de proyecto empieza por listar todos los riesgos (no importa lo remotos
que sean) en la primera columna de la tabla. Se puede hacer con la ayuda de la
lista de comprobacin de elementos de riesgo presentada en la Seccin 6.3. Cada
riesgo es categorizado en la segunda columna (por ejemplo: PS implica un riesgo
del tamao del proyecto, BU implica un riesgo de negocio). La probabilidad de
aparicin de cada riesgo se introduce en la siguiente columna de la tabla. El valor
de la probabilidad de cada riesgo puede estimarse por cada miembro del equipo
individualmente. Se sondea a los miembros del equipo individualmente de un
modo rotativo (round-robin) hasta que comience a converger su evaluacin sobre
la probabilidad del riesgo.

Evaluacin del impacto de riesgo Tres factores afectan a las consecuencias

probables de un riesgo si ocurre: su naturaleza, su alcance y cuando ocurre. La
naturaleza del riesgo indica los problemas probables que aparecern si ocurre.
Por ejemplo, una interfaz externa mal definida para el hardware del cliente (un
riesgo tcnico) impedir un diseo y pruebas tempranas y probablemente lleve a
problemas de integracin ms adelante en el proyecto. El alcance de un riesgo
combina la severidad (cmo de serio es el problema?) con su distribucin
general (qu proporcin del proyecto se ver afectado y cuantos clientes se
vern perjudicados?).
Finalmente, la temporizacin de un riesgo considera cundo y por cunto tiempo
se dejar sentir el impacto. En la mayora de los casos, un jefe de proyecto
prefiere las malas noticias cuanto antes, pero en algunos casos, cuanto ms
tarden, mejor.

Evaluacin del riesgo

En este punto del proceso de gestin 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 evaluacin del riesgo, se sigue examinando la exactitud de las
estimaciones que fueron hechas durante la proyeccin del riesgo, se intenta dar
prioridades a los riesgos que no se haban cubierto y se empieza a pensar las
maneras de controlar y/o impedir los riesgos que sea ms probable que
aparezcan.
Para que sea til la evaluacin, se debe definir un nivel de referencia de riesgo.
Para la mayora de los proyectos, los componentes de riesgo estudiados
anteriormente rendimiento, costo, soporte y planificacin temporal- tambin
representan niveles de referencia de riesgos. Es decir, hay un nivel para la
degradacin del rendimiento, exceso de coste, dificultades de soporte o retrasos
de la planificacin temporal (o cualquier combinacin de los cuatro) que provoquen

que se termine el proyecto. Si una combinacin de riesgos crea problemas de

manera que uno o ms de estos niveles de referencia.

Se excedan, se parar el trabajo. En el contexto del anlisis de riesgos del

software, un nivel de referencia de riesgo tiene un solo punto, denominado punto
de referencia o punto de ruptura, en el que la decisin de seguir con el proyecto o
dejarlo (los problemas son demasiado graves) son igualmente aceptables.

Refinamiento del riesgo

Durante las primeras etapas de la planificacin del proyecto, un riesgo puede ser
declarado de un modo muy general. Con el paso del tiempo y con el aprendizaje
sobre el proyecto y sobre el riesgo, es posible refinar el riesgo en un conjunto de
riesgos ms detallados, cada uno algo ms fcil de reducir, supervisar y gestionar.
La condicin general que acabamos de destacar puede ser refinada de la
siguiente manera:

Subcondicin 1: Ciertos componentes reutilizables fueron desarrollados

por terceras personas sin el conocimiento de los estndares internos de
diseo.

Subcondicin 2: El estndar de diseo para interfaces de componentes no

ha sido asentado y puede no ajustarse a ciertos componentes reutilizables
existentes.

Subcondicin

3:

Ciertos

componentes

reutilizables

han

sido

implementados en un lenguaje no soportado por el entorno para el que el

sistema ha sido construido.

Las consecuencias relacionadas con estas subcondiciones refinadas siguen

siendo las mismas (por ejemplo, el 30 por 100 de los componentes del software
deben ser construidos de un modo personalizado), pero el refinamiento ayuda a
aislar los riesgos sealados y puede conducir a un anlisis y respuesta ms
sencilla.

Reduccin, supervisin y gestin de riesgo

Todas las actividades de anlisis 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

Gestionar el riesgo y planes de contingencia.

Riesgos y peligros para la seguridad

Pueden aparecer riesgos despus de haber desarrollado con xito el software y de
haberlo entregado al cliente.
Estos riesgos estn tpicamente asociados con las consecuencias del fallo del
software una vez en el mercado. En los comienzos de la informtica, haba un
rechazo al uso de las computadoras (y del software) para el control de procesos
crticos de seguridad como por ejemplo reactores nucleares, control de vuelos de
aviones, sistemas de armamento y grandes procesos industriales.
Aunque la probabilidad de fallo de un sistema de alta ingeniera es pequea, un
defecto no detectado en un sistema de control y supervisin basados en
computadora podra provocar unas prdidas econmicas enormes o, peor, daos
fsicos significativos o prdida de vidas humanas. Pero el coste y beneficios
funcionales del control y supervisin basados en computadora a menudo superan
al riesgo. Hoy en da, se emplean regularmente hardware y software para el
control de sistemas de seguridad crtica.

El plan rsgr
Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de
software o se podran organizar los pasos de gestin del riesgo en un Plan
diferente de reduccin, supervisin y gestin del riesgo (Plan RSGR). Todos los
documentos del plan RSGR se llevan a cabo como parte del anlisis de riesgo y
son empleados por el jefe del proyecto como parte del Plan del Proyecto general.