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