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