GESTIÓN DE RIESGOS DE PROYECTOS DE SOFTWARE PARTE I

Ing. Tatiana Gualotuña, PhD

PORQUE NECESITAMOS GESTIÓN DE RIESGOS

La historia de Paco y Lola:

1. Paco y Lola han diseñado su plan de proyecto siguiendo PMBOK. (Comienza
el proyecto).
2. La madre de Paco sufre un infarto al corazón y la hospitalizan.
3. Paco trabaja a media jornada, turnándose con sus hermanos para cuidar a
su madre.
4. Mientras tanto, Lola va a al banco a solicitar la renovación del préstamo.
5. Se lo niegan.
6. (Seis meses después, proyecto avanzado) El gerente de la empresa del
cliente es despedido y llega un nuevo gerente.
7. El nuevo gerente llama a la empresa de Paco y Lola. Quiere ver de que va la
aplicación encargada.
8. El nuevo gerente decide que la aplicación, tal como está, no es rentable para
la empresa.
9. Si no se cambia el 60 % de los requisitos, se cancela el proyecto

IMPORTANCIA DE LA GESTION DE RIESGO

La gestión de riesgos del proyecto, es el arte y ciencia de identificar, analizar y

responder al riesgo durante el ciclo de vida del proyecto y con el mejor interés de
alcanzar los objetivos del proyecto, en la tabla se indica los beneficios de la gestión
de riesgos en el software.

1
¿QUÉ ES RIESGO?

Según PMBOK, el Riesgo de un proyecto es un evento o condición incierta que, de

producirse, tiene un efecto positivo o negativo en uno o más de los objetivos del
proyecto, tales como el alcance, el cronograma, el costo y la calidad. Un riesgo
puede tener una o más causas y, si se produce, uno o más impactos.

La asociación (APM) usa una definición similar, definiendo riesgo como "Un evento
incierto o un conjunto de circunstancias que, si se producen, tendrán un efecto en
la consecución de los objetivos del proyecto".

La norma AS9100C define riesgo como “Una situación o circunstancia indeseable

que tiene tanto una probabilidad de ocurrir como una consecuencia
potencialmente negativa”.

Por su parte la ISO 31000, define riesgo como “Efecto de la incertidumbre sobre los
objetivos”, entendiendo el efecto como una desviación de aquello que se espera,
sea positivo, negativo o ambos, la incertidumbre como el estado, incluso parcial, de
deficiencia de información relacionada con la comprensión o el conocimiento de
un evento, su consecuencia o probabilidad y los objetivos pueden tener aspectos
diferentes (por ejemplo financieros, salud y seguridad, y metas ambientales) y se
pueden aplicar en niveles diferentes (estratégico, en toda la organización, en
proyectos, productos y procesos.

ESTRATEGIAS FRENTE AL RIESGO

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. éste es el método denominado a menudo "de bomberos". Este tipo
de estrategias se conoce como reactivas acarrea consecuencias negativas y pone al
proyecto en peligro.

Una estrategia considerablemente más inteligente para el control del riesgo es ser
proactivo. La estrategia proactiva empieza mucho antes de que comiencen los
trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad
y su impacto y se establece una prioridad según su importancia. Después el equipo
de software establece un plan para controlar el riesgo.

CARACTERÍSTICAS DEL RIESGO

Se han producido amplios debates sobre la definición adecuada para riesgo de

software, y hay acuerdo común en que el riesgo siempre implica dos
características:

2
  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.

ETAPAS PARA TRATAR LOS RIESGOS

La gestión de riesgos es un proceso iterativo que se aplica durante todo el proyecto

y se desarrolla en cuatro etapas:

 Identificación de riesgos.
 Análisis de riesgos.
 Planificación de riesgos.
 Supervisión de riesgos.

Los resultados de la administración de riesgos deben ser documentados en un plan

de administración de riesgos.

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.

RIESGOS DEL TAMAÑO DEL PRODUCTO

 ¿Tamaño estimado del producto en LDC o FP?

 ¿Grado de seguridad en la estimación del tamaño?
 ¿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?

RIESGOS DEL IMPACTO EN EL NEGOCIO

 ¿Efecto de este producto en los ingresos de la compañía?

 ¿Viabilidad de este producto para los gestores expertos?
 ¿Es razonable la fecha límite de entrega?

3
  ¿Número de clientes que usarán este producto y la consistencia de sus
necesidades relativas al producto?
 ¿Número de otros productos/sistemas con los que este producto debe tener
interoperabilidad?
 ¿Sofisticación del usuario final?
 ¿Cantidad y calidad de la documentación del producto que debe ser
elaborada y entregada al cliente?
 ¿Limitaciones gubernamentales en la construcción del producto?
 ¿Costos asociados por un retraso en la entrega?
 ¿Costos asociados con un producto defectuoso?

RIESGOS RELACIONADOS CON EL CLIENTE

 ¿Ha trabajado con el cliente anteriormente?

 ¿Tiene el cliente una idea formal de lo que se requiere? ¿Se ha molestado en
escribirlo?
 ¿Aceptará el cliente gastar su tiempo en reuniones formales de requisitos
para identificar el ámbito del proyecto?
 ¿Está dispuesto el cliente a establecer una comunicación fluida con el
desarrollador?
 ¿Está dispuesto el cliente a participar en las revisiones?
 ¿Es sofisticado técnicamente el área del producto?
 ¿Está dispuesto el cliente a dejar a su personal hacer el trabajo? Es decir, ¿
resistirá la tentación de mirar por encima del hombro durante el trabajo
técnico?
 ¿Entiende el cliente el proceso del software?

RIESGOS DEL PROCESO

 ¿Apoyan sus gestores senior unas normas escritas que hagan hincapié en la
importancia de un proceso estándar para el desarrollo del software?
 ¿Ha desarrollado su organización una descripción escrita del proceso del
software a emplear en este proyecto?
 ¿Están de acuerdo los miembros del personal con el proceso del software
tal y como está documentado y están dispuestos a usarlo?
 ¿Se emplea este proceso del software para otros proyectos?
 ¿Ha desarrollado o adquirido su organización cursos de formación de
ingeniería del software para jefes de proyecto y personal técnico?
 ¿Se ha proporcionado una copia de los estándares de ingeniería del
software publicados a cada desarrollador y gestor de software?
 ¿Se han desarrollado diseños de documentos y ejemplos para todas las
entregas definidas como parte del proceso del software?
 ¿Se llevan a cabo regularmente revisiones técnicas formales de las
especificaciones de requisitos, diseño y código?
 ¿Se llevan a cabo regularmente: revisiones técnicas de los procedimientos
de prueba y de los casos de prueba?
 ¿Se documentan todos los resultados de las revisiones técnicas, incluyendo
los errores encontrados y recursos empleados?

4
  ¿Existe algún mecanismo para asegurarse de que el trabajo realizado en un
proyecto se ajusta a los estándares de ingeniería del software?
 ¿Se emplea una gestión de configuración para mantener la consistencia
entre los requisitos del sistema/software, diseño, código y casos de prueba?
 ¿Hay algún mecanismo de control de cambios de los requisitos del cliente
que impacten en el software? ¿Hay alguna declaración de trabajo
documentada, una especificación de requisitos software y un plan de
desarrollo del software para cada subcontratación?
 ¿Se sigue algún procedimiento para hacer un seguimiento y revisar el
rendimiento de las subcontraciones?

RIESGOS TECNOLÓGICOS

 ¿Demandan los requisitos del cliente la creación de nuevos algoritmos o

tecnología de entrada o salida?
 ¿El software interactúa con hardware nuevo o no probado?
 ¿Interactúa el software a construir con productos software suministrados
por el vendedor que no se hayan probado?
 ¿Interactúa el software a construir con un sistema de base de datos cuyo
funcionamiento y rendimiento no se han comprobado en esta área de
aplicación?
 ¿Demandan los requisitos del producto una interfaz de usuario especial?
 ¿Demandan los requisitos del producto la creación de componentes de
programación distintos de; los que su organización haya desarrollado hasta
ahora?
 ¿Demandan los requisitos el empleo de nuevos métodos de análisis, diseño
o pruebas?
 ¿Demandan los requisitos el empleo de métodos de desarrollo del software
no convencionales, tales como los métodos formales, enfoques basados en
IA y redes neuronales?
 ¿Imponen excesivas restricciones de rendimiento los requisitos del
producto?
 ¿No está seguro el cliente de que la funcionalidad pedida sea factible?

RIESGOS DEL ENTORNO DE DESARROLLO

 ¿Disponemos de la mejor gente?

 ¿Tiene el personal todos los conocimientos adecuados?
 ¿Tenemos suficiente personal?
 ¿Se ha asignado al personal para toda la duración del proyecto?
 ¿Habrá parte del personal de proyecto que trabaje sólo durante parte de él?
 ¿Dispone el personal de las expectativas correctas sobre el trabajo?
 ¿ Ha recibido el personal la formación adecuada?
 ¿Será mínimo el movimiento del personal para permitir la continuidad?

5
TAREA 1

Usted es jefe de proyecto de un equipo de desarrollo compuesto por un consultor,

dos analistas senior, dos analistas junior , 6 desarrolladores y un DBA. El proyecto
consiste en el desarrollo de una aplicación web para la gestión de recursos
humanos de una empresa. Por diversos motivos, uno de los principales riesgos que
usted ha identificado es la alta rotación del personal senior ¿Qué medidas (o pasos
de gestión) pondrá en marcha para mitigar la incidencia de dicho riesgo en el
proyecto antes y durante la ejecución del mismo?

TAREA 2

El proceso de progresiva globalización que está sufriendo la industria en general

ha alcanzado a la ingeniería del software. Por esto, ha surgido un nuevo modelo de
desarrollo de software, en el que los participantes se encuentran distribuidos, a
veces en varios países e incluso en continentes distintos y que se conoce como
desarrollo global de software. Centrándonos en el proceso de ingeniería de
requisitos, ¿qué posibles riesgos se identifican en un proyecto de desarrollo global
de software?

TAREA 3

Una organización va a abordar un nuevo proyecto de desarrollo de software con

las siguientes características:
 En la organización el lenguaje de programación utilizado en el 90% de los
proyectos es Java y es el que se usará en el nuevo proyecto.
 Acaban de incorporarse dos nuevos técnicos al equipo de desarrollo que no
tienen experiencia en Java.
 En la organización hay además 8 técnicos con más de 2 años de experiencia
disponibles para el proyecto.
 Las estimaciones del proyecto son: duración = 12 meses y esfuerzo = 3000
t-d.
 Se han incorporado dos nuevas empresas en el sector que tienen alta
competitividad en el mercado y que desarrollan productos similares.
 El cliente estará muy involucrado en el proyecto.
 Se ha detectado un fallo en el compilador usado que afecta directamente al
proyecto.
Se le pide:
 Identifique los dos riesgos más importantes que se pueden identificar en
este proyecto, clasifíquelos como técnicos, del proyecto o del negocio.