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.