Gestión de los requisitos de un proyecto software (página 2)

Los requisitos cambian y esto persiste a lo largo de la vida del sistema. Los cambios ocurren por:

• 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.

Los cambios deben controlarse y documentarse. Hay que convivir con el cambio. Por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. Por tanto la gestión de los requisitos del software, de su evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

La Gestión de Requisitos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. O sea, básicamente, consiste en gestionar los cambios a los requisitos acordados, las relaciones entre ellos, las dependencias entre la Especificación de Requisitos del Software (ERS) y otros documentos producidos por el proceso de desarrollo de software. Esta actividad asegura la consistencia entre los requisitos y el sistema construido (o en construcción). Consume grandes cantidades de tiempo y esfuerzo. Abarca todo el ciclo de vida del producto. Es una actividad necesaria porque:

• Los requisitos son volátiles:

• Mutantes o cambiantes: sufren ligeras variaciones.
• Emergentes: surgen al ir analizando el sistema en profundidad.
• Colaterales: surgen como efecto de la inclusión de otros requisitos.
• Por compatibilidad: se añaden para adaptar el sistema a su entorno, debido a que el entorno físico cambia, o sea, trasladar un sistema de un entorno a otro siempre requiere modificaciones. El entorno organizacional también cambia, las políticas cambian, se producen cambios en las reglas y en los procesos del negocio, provocando cambios en el sistema.

• La propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios.

La gestión de requisitos implica:

• Definir procedimientos que establezcan los pasos y los análisis que se realizarán antes de aceptar los cambios propuestos.
• Cambiar los atributos de los requisitos afectados.
• Mantener la trazabilidad hacia atrás, hacia delante y entre requisitos.
• Controlar las versiones del documento de requisitos.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la gestión de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones.

Como ya se ha expuesto, es vital planificar los cambios, de acuerdo a las prioridades que los clientes determinen durante la identificación. Hay que aprobar los mecanismos para la configuración del cambio y las políticas de trazabilidad.

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. Obsérvense las figuras 1 y 2.

Figura 1 Canal de cambios.

Figura 2 Proceso de control de cambios.

La gestión de los cambios se realiza de acuerdo a las prioridades, debiéndose identificar problemas y causas por los que se produce el cambio; analizar el impacto y el costo del cambio y finalmente, tomada la decisión, ejecutar (proceder con) el cambio.

Aspectos a considerar para la aprobación de un cambio solicitado:

• Impacto del cambio en el costo y funcionalidades del sistema.
• Impacto para el cliente y stakeholders externos.
• Desestabilización potencial del sistema que pudiera ocasionar un cambio.

Las solicitudes de cambios, desde el momento en que son comunicadas hasta su implementación, transitan por diferentes estados en el que intervienen los implicados asumiendo diferentes roles. Obsérvense la figura 3 y la tabla 1.

Ejecución de los cambios

Aprobado el cambio se procede a su implementación, de acuerdo a la fase del proyecto a que corresponda. En caso de que los cambios aprobados:

• impliquen el desarrollo de un nuevo sistema, entonces será necesario comenzar un nuevo proceso de IR.
• impliquen la implementación de nuevos requisitos, entonces será necesario comenzar por la actividad de elicitación o educción de requisitos.
• afecten otras fases del proceso de desarrollo del proyecto, entonces se implementan en esas.

Trazabilidad

Los requisitos deben ser "rastreables": por su origen (¿quién lo propuso?); necesidad (¿por qué existe?); por su relación con otros requisitos; por su relación con elementos del diseño y/o la implementación. Esta información es útil para saber qué afecta un cambio en un requisito. Para resolver esta necesidad se usan las matrices para el seguimiento de los requisitos, entre ellas:

• Matriz de seguimiento de características (definidas por el cliente).
• Matriz de seguimiento de orígenes: identifica el origen de cada requisito.
• Matriz de seguimiento de dependencias: indica cómo se relacionan los requisitos entre sí.
• Matriz de seguimiento de subsistemas: vincula a los requisitos con los subsistemas (o módulos) que los manejan.
• Matriz de seguimiento de interfases: muestra cómo los requisitos están vinculados a las interfases internas y externas del sistema.

Figura 3 Posibles estados de una petición de cambio

Tabla 1 Posibles roles en el procedimiento de control de cambios.

En [Edwards, 1991] la trazabilidad está definida como una técnica usada para "proveer una relación entre requisitos, el diseño y la implementación final del sistema". En [Palmer, 1997] se establece que "la trazabilidad da asistencia esencial en el entendimiento de las relaciones que existen entre y a través los requisitos, el diseño y la implementación".

Estas relaciones permiten mostrar que el diseño cumple con los requisitos funcionales y ayudan al reconocimiento temprano de aquellos requisitos que no son satisfechos por el diseño.

Control de versiones (evolución en el tiempo de la ERS)

Habitualmente la ERS necesitará ser modificada a medida que progresa el producto software, como resultado de los cambios aprobados en requisitos individuales o grupos de ellos. En la medida en que la especificación sea más completa, como consecuencia de que sus requisitos fueron especificados lo más completamente posible, menos versiones de la ERS habrá que producir.

Entre algunos de los beneficios que proporciona el control de versiones están:

• Prevenir cambios no autorizados.
• Guardar revisiones de los documentos de requerimientos.
• Recuperar versiones previas de los documentos.
• Administrar una estrategia de "releases".
• Prevenir la modificación simultánea a los requisitos.

Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto.ç

Para la trazabilidad y el control de versiones se realiza la identificación y almacenamiento de requisitos. Cada requisito y cada versión de ERS aprobada tendrán un identificador único.

Cuando la Gestión de los Requisitos no se hace bien, de inmediato aparecen síntomas:

• Altos niveles de re-trabajo a lo largo del proyecto.
• Los requisitos se aceptan por el personal desde cualquier fuente que consideren fidedigna.
• Se incrementa de forma desmesurada las peticiones de requisitos.
• Incapacidad para probar que el producto cumple los requisitos aprobados.

¿Por qué se debe tener cuidado? Porque:

• La falta de acuerdo entre los afectados sobre cuáles son los requisitos "reales" incrementa el tiempo y el costo del proyecto.
• Hay altas probabilidades de entregar un producto incompleto o incorrecto.
• Volver a revisar cambios en los requisitos, una y otra vez, es un derroche de recursos muy visibles para el cliente.

Buenas prácticas de la actividad de gestión de requisitos.

• Definir un proceso de control de cambios.
• Establecer un grupo (o comité) de control de cambios.
• Realizar análisis del impacto sobre los cambios.
• Crear líneas base y controlar las versiones de los requisitos.
• Mantener la historia de los cambios.
• Seguir el estado de los requisitos.
• Medir la volatilidad de los requisitos.
• Usar herramientas de gestión de requisitos.
• Crear matrices de trazabilidad de los requisitos.

El proyecto puede responder frente a petición de nuevos requisitos o petición de cambios en los requisitos de diferentes maneras:

• Diferir los requisitos de baja prioridad.
• Obtener recursos adicionales.
• Ordenar realizar más horas de trabajo (preferiblemente durante un periodo corto de tiempo y pagado).
• Retrasar el calendario para acomodarse a la nueva funcionalidad.
• Permitir reducir el nivel de calidad bajo la presión de mantener la fecha original (frecuentemente esta es la reacción por defecto).

Ninguna aproximación es universalmente correcta porque cada uno de los proyectos es diferente (características, presupuesto, calendario, recursos y calidad).

Independientemente a cómo se responda a los cambios de los requisitos, lo que realmente importa es ajustar las expectativas y los compromisos cuando sea necesario.

Las gestión de requisitos tiene como salidas los cambios aprobados y no aprobados, informes acerca del estado del proceso, de actividades o requisitos, resultados de análisis de matrices y otros.

CONCLUSIONES

El procedimiento propuesto en este artículo está diseñado para ser desarrollado durante todo el ciclo de vida del proyecto software y permite gestionar la obtención incremental de los requisitos y los inevitables cambios a los que están sujetos desde la fase de IR y en el resto del ciclo de vida del proyecto

También se establecen mecanismos que garantizan la trazabilidad de los requisitos a lo largo de todo el ciclo de vida, hacia atrás, hacia delante y entre ellos.

Esto permite proveer una relación entre requisitos, diseño e implementación del sistema y el reconocimiento temprano de aquellos que no son satisfechos.

Constituye un instrumento estratégico con enfoque proactivo, que permite al gestor del proyecto adoptar, desarrollar e implementar adecuadamente las actividades de gestión de los requisitos de una forma disciplinada, coherente y repetitiva.

Una eficiente gestión de requisitos a lo largo de todo el ciclo de vida del proyecto contribuye eficazmente a la calidad del producto final y al grado de satisfacción del cliente.

REFERENCIAS BIBLIOGRÁFICAS

[Boehm, 1988]: Boehm, B.: "A Spiral Model of Software Development and Enhancement". IEEE Computer. Vol. 21, # 5. 1988.

[DoD, 1994]: DoD. Military Standard 498: Software Development and Documentation. Departament of Defense of the United States of America, 1994.

[Durán, 2002]: Durán, A., Bernández, B.: "Metodología para la Elicitación de Requisitos de Software", Universidad de Sevilla. 2002.

[Edwards, 1991]: Edwards M., Howell S.: A methodology for system requirements specification and traceability for large real- time complex systems. Technical Report, Naval Surface Warfare Center, 1991.

[García, 2000]: García Ávila, Lourdes. Modelo para la evaluación de la calidad del análisis y diseño orientados a objetos de sistemas informáticos (CADOOSI). Tesis de doctorado. Universidad Central de Las Villas, 2000.

[Jacobson, et al., 1998]: Jacobson, I., Booch, G., Rumbaugh, J.: "The Unified Software Process". Adison- Wesley. 1998.

[Leffingwell y Widrig, 2003]: Leffingwell, Dean, Widrig, Don. "Managing Software Requirements". Second Edition. Addison-Wesley 2003.

[Minasi, 2000]: Minasi, Mark: The Software Conspiracy: Why Sftware Companies Put Out Faulty Products, How They Can Hurt You, and What You Can Do. McGraw-Hill, 2000.

[Palmer, 1997]: Palmer J. D.: Traceability in Software Requirements Engineering, R.H. Thayer and M. Dorfman (Eds), IEEE Computer Society Press, 1997. (364:374).

[Pressman, 2002]: Pressman, Roger S.: "Ingeniería de Software. Un enfoque práctico." Quinta edición. McGraw-Hill. Madrid. 2002.

[Rational, 2001]: Rational Unified Process. Rational Software Corporation. "Rational Unified Process". Version 2001A.04.00, Copyright 1987-2001.

[Sawyer y Kontoya, 1999]: Sawyer, P. y Kontoya, G.: SWEBOK: "Software Requirements Engineering Knowledge Area Description". Informe Técnico Versión 0.5, SWEBOK Project, 1999. Disponible en http://www.swebok.org.

[Sommerville, 2005]: Sommerville, Ian: "Software Engineering". 7th. Edition. Addison-Wesley 2005.

[SWEBOK, 2004]: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society Order Number C2330, ISBN 0-7695-2330-7, Library of Congress Number 2005921729. 2004.

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