Gestión de los requisitos
de un proyecto software
En la
actualidad persisten problemas en el desarrollo de software, entre ellos, un inadecuado entendimiento de las
necesidades de los usuarios, incapacidad de absorber cambios en los requisitos
e insatisfacciones de los clientes por inaceptable o bajo desempeño del software. Las principales causas
son la administración insuficiente de requisitos; los
problemas que afectan la comunicación; las inconsistencias no detectadas
entre requisitos, diseño y programación; las validaciones tardías de
requisitos; el enfrentamiento reactivo de riesgos y la propagación de cambios sin control.
Los modelos de proceso de Ingeniería de Requisitos (IR), a pesar de su evolución, aún presentan carencias. Por tanto,
para obtener un producto de calidad, se requiere una mejora en los procesos de IR. El objetivo del trabajo es proporcionar un procedimiento para efectuar la gestión de los requisitos de un proyecto de software basado en la integración de las mejores prácticas, con un
enfoque holístico, proactivo y estratégico que potencie de manera efectiva el
desempeño del proceso de gestión de desarrollo del proyecto de software y la
satisfacción del cliente.
Palabras
claves:
requisitos, gestión del cambio, gestión de requisitos.
A pesar
de la creciente participación del software en el mundo actual y de los avances
producidos, su proceso aun no es adecuado.
El
desarrollo de software aun no responde a las exigencias de estos tiempos. Las
necesidades y expectativas de los clientes y usuarios no son captadas
satisfactoriamente. De ahí que gran cantidad de proyectos de software que no llegan a cumplir sus
objetivos, y como consecuencia de esto, los altos
por cientos de rechazo entre ellos. Es otra problemática importante la
incapacidad de absorber cambios en esos requisitos.
Las
principales causas de estos problemas son la administración insuficiente de requisitos,
comunicación ambigua e imprecisa, inconsistencias no detectadas entre
requerimientos, diseño y programación, validaciones tardías de los requisitos,
enfrentamiento tardío de riesgos y propagación de cambios sin control [Minasi,
2000], [García, 2000]. En este sentido, es necesario recordar que los errores
más comunes y más costosos de reparar, así como los que más tiempo consumen, se deben a una inadecuada
Ingeniería de Requisitos (IR). Actividades propias de esta área, como la
especificación de requisitos o la gestión de requisitos del usuario, son
algunas de las consideradas más críticas en el desarrollo y la producción del software.
La
relación no lineal entre la ingeniería de requisitos y el resto del ciclo de vida del desarrollo del software ha sido
detectada desde antaño y propuestas metodológicas como el Modelo en Espiral [Boehm, 1988] y el Proceso
Unificado de Racional [Jacobson, et al., 1998], incorporan estrategias iterativas dentro de sus procesos de
desarrollo para facilitar la ejecución de actividades propias de la ingeniería
de requisitos, una vez iniciado el resto del proceso de desarrollo, al
detectarse en éste la necesidad de renegociar algunos requisitos de difícil
implementación o porque aparecen nuevos requisitos durante el proceso de
desarrollo, entre otros. Debe tenerse en cuenta que la IR continúa durante todo
el proceso de desarrollo [Sawyer y Kontoya 1999].
En [DoD,
1994] se ofrece una definición muy precisa de requisito, se dice que es
la característica del sistema que es una condición para su aceptación
por el cliente.
Si
partimos de la definición anterior, entonces será necesario no sólo descubrir y
especificar correcta y claramente los requisitos, sino que, además, será
necesario seguirlos a lo largo de todo el ciclo de vida del proyecto, hasta su
implementación, y mantener un control adecuado de los cambios. Así la gestión
de los requisitos puede contribuir a reducir el tiempo del proyecto y disminuir
los recursos implicados, facilitando la reutilización
de requisitos y la implicación del usuario final en todo el proceso.
Otro
aspecto importante a considerar es la línea base de requisitos, estructura dinámica que se genera durante el proceso de
ingeniería de requisitos que evoluciona junto al proceso de desarrollo de
software y que acompaña las tareas de mantenimiento.
Es
importante enfatizar la importancia de la capacidad de referencias cruzadas
entre la línea base de requisitos y el proceso de desarrollo y mantenimiento.
Esto permite el seguimiento de los requisitos en cualquier punto durante el
desarrollo y el mantenimiento hacia su punto de origen [García, 1999].
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 requisitos
acordados, de forma que se garantice la satisfacción del cliente.
Los principios para realizar la gestión de los
requisitos del software son:
- El acuerdo de los requisitos es el puente entre el desarrollo de requisitos y la gestión de requisitos.
- La gestión de requisitos incluye todas las actividades para mantener la integridad, exactitud y difusión de los acuerdos de los requisitos durante la vida del proyecto.
- Cambios tecnológicos;
- Cambios en las estrategias o prioridades del negocio;
- Modificaciones en leyes y/o regulaciones;
- Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas;
- Porque cambió el problema que se estaba resolviendo;
- Porque los usuarios cambiaron su forma de pensar o sus percepciones;
- Porque cambió el ambiente de negocios;
- Porque cambió el mercado en el cual se desenvuelve el negocio.
Procedimiento de gestión de cambios en los requisitos
Desde el inicio hay que establecer la conformación de la línea base de requisitos, como un canal simple para el control de cambios, que se podrá usar para "capturar" nuevos cambios.Línea base de requisitos
Es el conjunto de requisitos funcionales y no-funcionales que el equipo del proyecto se ha comprometido a implementar en una release específica. Es una versión aprobada de la especificación de requisitos del software.
Los requisitos antes de entrar en la Línea Base deben ser sometidos a un procedimiento de revisión formal (con su aprobación para ser incluido en la línea base). Una vez entrado el requisito en la línea base cualquier cambio debe someterse al procedimiento de control de cambios.
Es adecuado que el documento de requisitos que se esté elaborando previo a entrar en la línea base esté sometido a un procedimiento de control de versión (para distinguir versiones borradores de versión aprobada).
Canal y control de cambios
En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.
La identificación del cambio se inicia desde el análisis de requisitos, nuevas necesidades del cliente, problemas operacionales; después se realiza el análisis del cambio y evaluación de costos, debiendo quedar claro cuántos requisitos se verán afectados y cuánto costará (tiempo y recursos); sólo después se toma la decisión de la implementación del cambio, que será documentado al ser realizado.
Proceso de control de cambio:
No hay comentarios:
Publicar un comentario