Gestión del riesgo en la fase de ingeniería de requisitos de un proyecto software

1. Resumen
3. Propuesta de la actividad de gestión de riesgos en la etapa de IR
4. Gestión de Riesgos
5. Conclusiones
6. Referencias bibliográficas

RESUMEN

La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de ellos, desde la fase se ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

Palabras claves: riesgos, requisitos, gestión de riesgos.

Abreviaturas o acrónimos utilizados con significado

IR: Ingeniería de Requisitos

ERS: Especificación de Requisitos del Software (documento)

INTRODUCCIÓN

La ingeniería de requisitos es un área de investigación que procura atacar un punto fundamental en el proceso, que es la definición de lo que se quiere producir. Jackson afirma que la ingeniería de requisitos se ubica en el punto de encuentro entre lo informal y lo formal del desarrollo de software [Jackson, 2001].

Para lograr producir aquello que el cliente requiere, en el plazo solicitado y ajustados al presupuesto asignado, se necesita desarrollar un proceso que incluya desde la etapa más temprana la gestión de los riesgos asociados a los requisitos, de forma que se contribuya al mejoramiento gradual del proceso de desarrollo y la gestión de un proyecto de software que logre la satisfacción del cliente en estas organizaciones.

La gestión de riesgos en el ámbito del software procura formalizar conocimiento orientado a la minimización o evitación de riesgos en proyectos de desarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista [Roppponen, 2000]. Hasta el momento se ha propuesto y utilizado diferentes enfoques de gestión del riesgo desde que Boehm [Boehm, 1988] atrajo a la comunidad de ingeniería del software hacia la gestión del riesgo. Sin embargo, es evidente que pocas organizaciones utilizan todavía de una forma explícita y sistemática métodos específicos para gestionar los riesgos en sus proyectos software.

En [Pressman, 2002] se presenta la definición de riesgo dada por Robert Charette en [Charette, 1989] donde plantea que en primer lugar, el riesgo afecta a los futuros acontecimientos. En segundo lugar, el riesgo implica cambios. En tercer lugar, el riesgo implica elección, y la incertidumbre que entraña esta. Cuando se considera el riesgo en el contexto de la ingeniería de software, los tres pilares de Charette se hacen continuamente evidentes. Es indiscutible que están presentes permanentemente las características de incertidumbre (acontecimiento que caracteriza al riesgo y que puede o no ocurrir) y de pérdida (si el riesgo se convierte en una realidad ocurrirán consecuencias no deseables o pérdidas).

Están definidas las categorías de riesgos: los riesgos del proyecto, que amenazan el plan; los riesgos técnicos, que amenazan la calidad y la planificación temporal; y los riesgos del negocio, que amenazan la viabilidad del proyecto o del producto. Otra categorización a considerar a partir del conocimiento que se tenga de ellos: los riesgos conocidos (los que se descubren en las evaluaciones); los riesgos predecibles (se extrapolan de la experiencia) y los riesgos impredecibles (pueden ocurrir, pero es muy difícil identificarlos de antemano).

También son claras las estrategias frente al riesgo. Por un lado están las reactivas, cuyo método es evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Este tipo de estrategias acarrea consecuencias negativas, al poner el proyecto en peligro. Y por el otro las preactivas, que aplican el método de evaluación previa y sistemática de los riesgos y sus posibles consecuencias, a la par que conforman planes de contingencias para de evitar y minimizar las consecuencias. Consecuentemente, este tipo de estrategias permite lograr un menor tiempo de reacción ante la aparición de riesgos impredecibles.

La autora defiende a los partidarios de la aplicación de estrategias preactivas y coincide con [Pressman, 2002] y [Gallagher, 1999] en la necesidad de la realización de los análisis de riesgos de forma temprana, sistemática, formal y profunda.

De acuerdo con [Pressman, 2002], la administración o gestión de riesgos es un proceso iterativo que se aplica durante todo el proyecto y se desarrolla en cuatro etapas. Los resultados de la administración de riesgos deben ser documentados en un plan de administración de riesgos. La figura 1 refleja el procedimiento.

En [Gallagher, 1999] se define el paradigma de la gestión del riesgo del SEI, con un proceso de seis actividades, como se observa en la figura 2, que deben ser desarrolladas de forma continua a lo largo de todo el ciclo de vida del proyecto.