Gestión del riesgo en la fase de ingeniería de requisitos de un proyecto software (página 2)

Otra diferencia con el proceso de
gestión
propuesto en [Pressman, 2002], es que en este son incluidas las
actividades de vigilancia y comunicación, que mantendrá información y retroalimentación acerca del proceso de
gestión de
riesgos, del estado de los
riesgos
atenuados, vigilados y emergentes (nuevos). Considera que las
fuentes de
información de riesgos pueden ser internas o externas
al proyecto.

La Gestión, Monitorización y
Mitigación de Riesgos (RMMM) tienen como objetivo
marcar las estrategias y
formas de actuar del equipo de trabajo frente
a los riesgos: cómo evitarlos, monitorizarlos,
gestionarlos y actuar ante contingencia. Escuetamente podemos
establecer las tareas principales de cada una.

Para evitar el riesgo hay que
definir las estrategias necesarias para que este no se produzca y
tomar las medidas encaminadas para que, aún cuando se
produzca, se minimicen sus efectos. Para el monitoreo del riesgo
hay que definir los indicadores
que influyen en la probabilidad de
que este se produzca y revisar periódicamente dichos
factores, además de vigilar la efectividad real de las
acciones
encaminadas a evitarlo.

La gestión del riesgo y plan de
contingencia asumen que la evitación y la
monitorización han fallado y el riesgo se ha producido.
Por ello se definen las estrategias y acciones a tomar para
lograr que los efectos se minimicen. Nunca se podrá
reducir a cero el coste del plan de contingencia, ya que
él puede implicar algunos costes en sí mismo, por
lo cual se ha de valorar el beneficio que se espera obtener de
éste.

Para la autora queda claro que cuanto antes se comience
el proceso de gestión de riesgos en un proyecto mayores
serán las probabilidades de éxito
del mismo, por tanto está convencida de que es en la etapa
de la IR donde debe comenzar, lo que se dificulta por estar poco
tratado el tema para las actividades que componen el proceso de
IR.

DESARROLLO

Propuesta de la ACTIVIDAD DE GESTIÓN DE
RIESGOS en la etapa de IR

Un riesgo es aquel factor que influye negativamente en
el éxito del proyecto. El riesgo en un proyecto de
desarrollo de
software incluye
componentes técnicos y de conocimiento
del mismo. Los temas de naturaleza
organizacional constituyen los factores dominantes de los riesgos
del proyecto, a la vez que son los que se tratan
satisfactoriamente en menos de la tercera parte de los proyectos de
desarrollo, entre ellos los conflictos
entre departamentos, entre usuarios, el cambio del
responsable ejecutivo del proyecto, volatilidad del personal,
número de unidades de la
organización implicadas y proyectos que involucran a
múltiples proveedores.

Es premisa de esta propuesta que el riesgo se halla, de
forma implícita, asociado a toda actividad. El riesgo
acompaña a todo cambio porque implica elección e
incertidumbre. Si a la vez que se inicia la actividad de
elicitación de los requisitos del software a construir, se
inicia la identificación de los riesgos asociados a los
requisitos individuales y a grupos de ellos,
será posible gestionarlos tempranamente para minimizarlos,
evadirlos y controlarlos. El jefe o administrador de
proyectos anticipa riesgos que pueden afectar al desarrollo o a
la calidad de los
requisitos y emprende acciones para evitarlos.

Esta actividad garantiza que, desde el inicio del
proceso de desarrollo del software, se realicen las tareas
encaminadas a garantizar la calidad del producto.

Basado en el modelo dado
por [Pressman, 2002], descrito anteriormente y representado en la
figura 1, se define el procedimiento
siguiente:

Paso 1: Identificación de
riesgos. Problemas
potenciales que pueden ocurrir en el proceso de IR o en los
requisitos, o en la Especificación de los Requisitos del
Software (ERS), como de presupuesto, de
personal, del usuario, de organización, técnicos, de
comunicación u otros. Debe comenzar con el análisis de los riesgos genéricos,
que constituyen una amenaza potencial para todos los proyectos de
software, que puedan estar presentes en el proyecto en curso.
Después se deben identificar los riesgos
específicos, que implican un conocimiento profundo del
proyecto, y están relacionados con el entorno de
desarrollo, la tecnología, la
experiencia y el tamaño del equipo.

Para los requisitos y ERS se debe comenzar esta tarea
dando respuesta a la pregunta: ¿qué
características especiales tiene este requisito, o
grupo de
ellos, que pueden estar amenazadas?

Un método
probadamente efectivo para identificar riesgos es la
creación de una lista de comprobación de
elementos de riesgo. Esta lista debe centrarse en los riesgos
relacionados con: tamaño del producto, impacto en el
proyecto y en la organización, características del
cliente,
definición del proceso, el entorno de desarrollo, la
tecnología a construir, el tamaño del equipo y la
experiencia del personal.

En esta actividad del procedimiento se establece crear
una lista de comprobación para los requisitos individuales
y otra para la ERS. Los resultados se vierten en tablas para
facilitar el análisis posterior. Los riesgos serán
considerados a partir del comportamiento
de sus características individuales y grupales
(ambigüedad, claridad, completitud, consistencia,
rastreabilidad, entre otras.). En dependencia de la intensidad de
ese comportamiento de la característica de calidad del
requisito, podrá controlarse de forma efectiva el riesgo
en el propio proceso de IR, antes de que pase a la siguiente
etapa del ciclo de vida
del proyecto de desarrollo del software. De no gestionarse el
riesgo en esta etapa inicial, puede hacerse difícil su
control efectivo
una vez iniciado el proceso de desarrollo. Desequilibrios en el
comportamiento de las características de calidad de los
requisitos se traducen en que la aparición de riesgos haga
vulnerable el proyecto e impráctica la aplicación
de cualquier plan de calidad, razón por la cual conviene
su detección y tratamiento temprano. En esta
situación, se recomienda la redefinición de los
requisitos afectados (o la ERS), que es posible por iteraciones
en este procedimiento.

Un ejemplo de la aplicación de este
instrumento es:

Característica del requisito:
ambigüedad. Pregunta: ¿es ambiguo el
requisito?

Aplicada a todos los requisitos especificados, una tabla
1 puede mostrar el resultado.

Tabla 1 Identificación de
riesgos.

En este procedimiento se establece definir y listar los
riesgos que pueden afectar al propio proceso de ingeniería de requisitos como aparece en
las tablas 2, 3 y 4.

Tabla 2 Lista de riesgos y
clasificación.

Tabla 3 Riesgos por
requisitos.

Tabla 4 Riesgos por
tipos.

Algunos riesgos que pueden afectar el desarrollo del
proceso de IR son:

• Sobrepasar los límites
  de los recursos
  asignados.
• Finalización fuera de plazos originales (a
  veces ni se finaliza).
• Pobre o descontrolada gestión de los
  requisitos.
• Incompatibilidad con el entorno.
• Riesgo más grave: que no se comprendan y no se
  satisfagan las necesidades de los usuarios.
• Problemas en la
  comunicación entre clientes y proveedores, entre
  usuarios, u otros grupos.

Paso 2: Evaluación de los
riesgos. Determinar en qué indicador se verá
reflejado que un problema se presente, se deben establecer puntos
de referencia para cada riesgo, que permita decidir si el riesgo,
según su prioridad de atención, se sale del manejo aceptable.
Obsérvese en la figura 3 un ejemplo de un punto de
referencia.

Proyección de los riesgos. Consiste en
determinar la probabilidad de que un riesgo ocurra y las
consecuencias que puede tener, por ejemplo: incremento de
costos,
cancelación del proyecto, insatisfacción del
cliente. Implica ordenar la lista de riesgos teniendo en cuenta
la probabilidad de que ocurra y el impacto de cada riesgo. Se
asigna el nivel de probabilidad, que puede ser alta, media o
baja. Se valora el impacto (consecuencias) en cuanto al alcance
(cuánto se afecta) y la duración (por cuánto
tiempo se manifiesta).

En el análisis de riesgos se considera cada
riesgo por separado y se valora en intervalos su probabilidad e
impacto:

• probabilidad del riesgo valorada como muy bajo
  (<10%), bajo (10-25%), moderado (25-50%),
  alto (50-75%) o muy alto (>75%)
• efectos del riesgo valorados como
  catastrófico, serio, tolerable o
  insignificante

El resultado se registra en una tabla ordenada por la
probabilidad o por el efecto del riesgo. Se decide del total,
cuáles son los más importantes, considerados
entonces como riesgos claves durante el proyecto -debe ser
un número manejable.

Por ejemplo, todos los serios o catastróficos con
cualquier probabilidad. Obsérvese la tabla 5.

Tabla 5 Riesgos ordenados por
efectos.

Paso 3:
Planificación de riesgos. Este
paso tiene como objetivo desarrollar una estrategia para
tratar los riesgos. Si el equipo de trabajo adopta un enfoque
proactivo frente al riesgo, evitarlo será siempre la mejor
estrategia. Esto se consigue desarrollando los planes de
reducción del riesgo y de contingencia.

En la planificación de riesgos se considera cada
uno de los riesgos claves identificados y las estrategias para
administrarlos, que vendrán dadas por el juicio y la
experiencia del administrador del proyecto.

Las estrategias de anulación intentan reducir la
probabilidad de que surja el riesgo, las estrategias de
disminución: intentan reducir el impacto del riesgo. Los
planes de contingencia se elaboran para estar preparados por si
el riesgo ocurre poder actuar
con una estrategia determinada. Obsérvese la tabla
6.

Tabla 6 Estrategias por
riesgos.

Paso 4: Supervisión
de los riesgos. Consiste en hacer el plan de supervisión, dado el caso de que se acepte
continuar con el proyecto. Indicar que acciones y decisiones se
tomarán ante un problema que ya ha sido identificado,
proyectado y evaluado.

La supervisión de riesgos valora cada uno de los
riesgos identificados para decidir si es más o menos
probable y cuándo han cambiado sus posibles efectos. Hay
que controlar factores que pueden indicar cambios en la
probabilidad y el impacto. Obsérvese la tabla
7.

Tabla 7 Indicadores potenciales
por riesgos.

Gestión de Riesgos

• La tarea principal del administrador consiste en
  minimizar riesgos. Involucrar a todos los implicados/afectados
  y al equipo de desarrollo del proyecto en la
  identificación de los riesgos.
• El riesgo inherente en una actividad se mide en base
  a la incertidumbre que presenta el resultado de esa actividad.
  Las actividades con alto riesgo elevan los costos.
• Comunicar los riesgos a todos los niveles de la
  organización.
• El riesgo es proporcional al monto de la calidad de
  la información disponible. Cuanto menos
  información, mayor el riesgo.
• Monitorear constantemente los factores que propician
  la materialización de los riesgos y la efectividad de
  las acciones definidas encaminadas a su prevención y/o
  minimización.
• Definir plantillas o tablas de riesgos valorados para
  diferentes tipos de proyecto que puedan servir como punto de
  partida para un nuevo proyecto.

Las salidas de esta actividad son las
listas (tablas o taxonomías) de riesgos en sus diferentes
acepciones, el plan de supervisión de riesgos y el plan de
contingencia.

CONCLUSIONES

Un adecuado proceso de ingeniería de requisitos
tiene implicaciones positivas en la calidad del producto final,
por ende, en la satisfacción del cliente. Debido a esto el
proceso de IR tiene que estar bien definido y ser desarrollado de
forma disciplinada, coherente y repetitiva, garantizando la
obtención de experiencias que permitan aplicar las mejores
prácticas.

El tratamiento proactivo de los riesgos asociados a los
requisitos del software permite al gestor adoptar, desarrollar e
implementar adecuadamente las actividades de gestión de
estos, en función de
obtener productos de
calidad que satisfagan las necesidades del cliente, manteniendo
el equilibrio de
plazo y costo del
proyecto en virtud de lograr un mejor desempeño del proceso de IR en la
pequeña y mediana empresa de
software. El manejo de los riesgos asociados a los requisitos,
organizados y gestionados a través de las diferentes
taxonomías propuestas puede constituirse en una
útil herramienta para los gestores y equipos de
desarrollo.

REFERENCIAS BIBLIOGRÁFICAS

Ing. Leidy Fernández
Sánchez.

leidy[arroba]cfg.etecsa.cu

Empresa de Telecomunicaciones de Cuba S. A.
Cuba

Dra. Lourdes García
Ávila.

Dpto. Ing. Industrial.Universidad
Central "Martha Abreu" de Las Villas. Cuba