Documentación de la trazabilidad de requerimientos utilizando

Documentación de la trazabilidad de requerimientos
utilizando y relacionando Rational RequistePro y
Rational Rose 2003
Master Maria Marta Sandoval Carvajal, PMP
Universidad Nacional, Escuela de
Informática, Costa Rica.
[email protected]
Master Maria Adilia García Vargas
Universidad Nacional, Escuela de
Informática, Costa Rica.
[email protected]
Resumen
denominado “Automatización de la Trazabilidad en el
proceso unificado de desarrollo de software utilizando RUP
TM de IMB
.
Se presentan aspectos básicos sobre el concepto de
ingeniería de requerimientos, tipos de requerimientos y
trazabilidad, continuando con una muestra en forma
práctica de los pasos para su documentación de en el
Proceso Unificado de Desarrollo de Software (PU) a través
del uso de dos herramientas del RUP:
Rational
RequisitePro y Rational Rose. Si bien el conocer las
herramientas no es el factor de éxito en la gestión de la
trazabilidad, puede servir de guía a aquellos usuarios y
desarrolladores que deseen llevar a cabo cambios en su
forma de trabajo, en la búsqueda de una mejora continua en
los proyectos de desarrollo de sistemas. Finalmente se
muestran algunas reflexiones finales que pueden
complementar los aspectos aquí mostrados.
Dentro de los aspectos más débiles que presenta el
desarrollo de sistemas, es obtener la satisfacción del cliente,
uno de las causas principales de esta situación, es la
inadecuada definición y documentación de los
requerimientos. Como parte del Plan de mejoramiento de la
Escuela de Informática de la Universidad Nacional de Costa
Rica, se han orientado los esfuerzos al aumento en las
investigaciones que beneficien al desarrollo del plan de
estudios y que además promuevan la vinculación externa
con la sociedad costarricense. Este artículo resume una de
las actividades iniciales del proyecto de investigación
denominado “Automatización de la trazabilidad, utilizando
el Rational Unified Process (RUP) aplicando el Proceso
Unificado a través del desarrollo de un Sistema de
Información Administrativo”.Esta actividad consiste en
llevar a cabo un proceso de documentación de la
trazabilidad utilizando dos de las herramientas del RUP:
Rational Requisite Pro y Rational Rose 2003, las cuales
permiten de manera automática definir las trazas entre los
requerimientos, de forma que se facilite el proceso de
administración de necesidades. Se muestran de manera
ilustrada los pasos para lograr esta documentación, así
como los documentos necesarios para sistematizar la
trazabilidad, utilizando como metodología de desarrollo el
Proceso Unificado de Desarrollo de Software (PU).
1. INTRODUCCIÓN
Uno de los principales problemas asociados al desarrollo de
aplicaciones, es el cumplimiento de los requisitos para
satisfacer a los involucrados. La definición de los
requerimientos, es un proceso de comunicación que
requiere no solo de retroalimentación, sino de formalización
y de administración del conocimiento.
Conocer los requerimientos no es suficiente, el proceso de
levantamiento, definición, validación de requerimientos une
al menos dos mundos muy distintos, el del usuario en su
campo de acción y el del Ingeniero de Sistemas, la
trazabilidad podría minimizar la brecha existente entre estos
mundos. Permite seguirle la pista a los requerimientos de
manera que el proceso de cambio intrínsico en la ingeniería
de requerimientos, facilite los análisis de impacto de
manera que se converja en el logro de la satisfacción de
los stakeholders y en beneficio de la organización.
Este artículo, resume uno de las actividades del proyecto de
investigación, llevado a cabo por las autoras en la Escuela
de Informática de la Universidad Nacional de Costa Rica,
2.
FUNDAMENTOS TEÓRICOS
2.1. Ingeniería de requerimientos
Un requerimiento es una necesidad que un sistema debe de
satisfacer. Las actividades relacionadas con su definición,
análisis, validación, gestión y documentación se denominan
Ingeniería de Requerimientos. El proceso relacionado con
estas actividades es uno de los más débiles en los proyectos
de desarrollo de software de la actualidad, implica no solo
elementos técnicos, sino gerenciales y principalmente
humanos. El levantamiento y validación de requerimientos
no son en la mayoría de los proyectos llevados cabo de una
manera sistemática y los resultados no son los esperados,
demandando grandes desviaciones en los tiempos y
presupuestos iniciales. La trazabilidad facilita el complejo
proceso de los requerimientos.
2.2. Trazabilidad
La trazabilidad define la relación que existe entre dos
requerimientos. Esta relación se visualiza sin que se
especifique, necesariamente en la misma relación el tipo de
dependencia, como relación jerárquica o subordinación,
descomposición, etc.
En RUP se definen dos formas de mostrar la relación de
trazabilidad:
A Trace to
B
B Trace from A
La diferencia principal entre ellas, es la forma en que lee la
relación de A a B o de B desde A, el aspecto a enfatizar es
que si un cambio sucede en A podría tener implicaciones en
B, pero no necesariamente al revés.
2.3. Importancia de la trazabilidad
Se ha demostrado que la trazabilidad de requerimientos es
una técnica efectiva en el desarrollo de software,
particularmente en aquellos sistemas en las que las fallas
del software no son una opción. [1]
La trazabilidad no solo facilita la administración de los
requerimientos en las etapas de desarrollo sino que es útil
durante la operación del sistema, donde es inminente el
cambio de los requerimientos. La trazabilidad permite
seguir la pista de los requerimientos desde su origen. Su
documentación apoya el trabajo en equipo y facilita a
través del uso de las herramientas, mejorar la forma en que
se gestionan los requerimientos.
Administración de los Requerimientos, desarrollando el
plan de requerimientos, donde precisamente se definen,
entre otras cosas, los lineamientos de la documentación que
se describen mas adelante. Además deben de quedar claros
los roles y las responsabilidades de los stakeholder y el
equipo de desarrollo con relación al este proceso.
4. DOCUMENTACIÓN DE LA TRAZABILIDAD.
Se
resumen tres aspectos fundamentales: definir la
estructura de documentación, documentar la visión del
proyecto y especificar los requerimientos, y por último
definir las relaciones de trazabilidad.
4.1. Definir la estructura de documentación
En la Ilustración 1. Estructura de documentación de la
trazabilidad, se muestra la distribución de documentación
que se ha definido para este caso particular. Además es
necesario una nomenclatura para nombrar los documentos y
archivos.
Ilustración 1. Estructura de documentación de la
trazabilidad
2.4. Problemas para la aplicación de la trazabilidad
Tradicionalmente durante el desarrollo de software, no se
le ha dado la
importancia debida a los procesos
relacionados con los requerimientos, igualmente el esfuerzo
que puede significar la documentación de la trazabilidad
puede no considerarse una opción costo/beneficio adecuada
para algunos proyectos. Además los beneficios del uso de la
trazabilidad se muestran más en las etapas finales del
desarrollo (pruebas) y provocan desatención por parte de
los desarrolladores en las etapas tempranas de
conceptualización y análisis.
2.5. Herramientas utilizadas
A través de convenio realizado entre la Escuela de
Informática y GBM de Costa Rica, se cuenta con un
laboratorio equipado con 15 máquinas donde se encuentran
instaladas herramientas del ambiente RUP de IBM, para
este caso específico las herramientas utilizadas son:
Rational RequistePro 2003: es una herramienta para la
administración de los requerimientos, basada en RUP, entre
otras cosas la herramienta promueve la motivación para el
desarrollo de los procesos de sistematización de la gestión
de requerimientos y facilita la comunicación entre los
involucrados del proyecto. Utiliza el MS WORD como
procesador de texto facilitando el proceso de
documentación.
Rational Rose 2003: es una herramienta que apoya
principalmente las etapas de análisis y diseño de sistemas,
como son desarrollo de modelos, objetos, clases, casos de
uso, diagramas, etc. Además se vincula de manera
automática con Rational RequistePro lo que mejora la
gestión de los requerimientos, principalmente en la
administración del cambio.
3. DEFINIR LA GESTIÓN DEL PROYECTO
Como todo proyecto de desarrollo de software debe ser
llevado a cabo de acuerdo a las mejores prácticas de
Administración de Proyectos, aspectos a resaltar por la
temática de este artículo es la definición de
la
4.1.1.
Definir tipos de requerimientos
Los tipos de requerimientos definidos en este esquema, se
muestran en la ilustración anterior y resumen la Tabla 1.
Tipos de requerimientos y documentos
.:
4.1.2.
Documentos definidos en Rational
RequisitePro:
Visión y características: donde se documenta el
alcance del proyecto, la definición del problema, ambiente
y perfil de usuarios y stakeholder, las características
funcionales y no funcionales de alto nivel.
Especificación de casos de uso: donde se describe el
caso de uso en forma breve, detallada, incorporando flujo
principal y alternos, además de otros aspectos que se
consideren necesarios.
Glosario : Se definen los términos relevantes del
proyecto, se considera un diccionario de datos del proyecto.
Especificación de necesidades de stakeholder: donde
se documenta el análisis realizado en torno a la necesidad
como ambiente, supuestos, origen de la necesidad, entre
otros, en un lenguaje de alto nivel.
Especificación de requerimientos suplementarios:
incluye necesidades de usabilidad, confiabilidad,
rendimiento, soporte, interfase, implementación, aspectos
legales, etc.
Tabla 1. Tipos de requerimientos y documentos
Tipo de
Se documenta en
requerimientos
Forma
Forma detallada
general
Necesidad
de • Visión
• Especificación
Stakeholder
de necesidades de
(STRQ): se definen
stakeholder
como el requisito de
alto
nivel
generalmente
establecido por un
stakeholder clave en
el proyecto.
Características del • Visión
producto (FEAT):
corresponden a los
requisitos
funcionales
Requerimientos
• Visión
• Especificación
Suplementarios
de
(SS) : se define como
Requerimientos
los requisitos no
suplementarios.
funcionales
del
sistema.
Glosario: incluye los
• Glosario
términos
significativos
del
proyecto
Casos de uso (UC): Diagramas
• Especificación
descripción
de de caso de
de casos de uso
requerimientos.
uso
Diagramas de secuencia y colaboración: donde se
muestran los escenarios de casos de uso: los escenarios son
instancias de un caso de uso, definen un flujo particular de
eventos y son parte del proceso de análisis y diseño del
sistema.
4.2. Documentar la visión del proyecto
El documento Visión contiene los aspectos de alto nivel del
producto, la definición del problema, las necesidades de los
stakeholder, las características principales del sistema,
requerimientos funcionales y no funcionales descritos a un
alto nivel. Además especifica aspectos relacionados con el
alcance del sistema, así como sus limitaciones y principales
supuestos, es un documento que se empieza a desarrollar
en la Fase de Inicio y se refina en las siguientes fases,
quedando casi definido en la de Elaboración.
4.2.1.
Especificar las necesidades de stakeholder
(Stakeholder request)
Las necesidades de stakeholders (STRQ) se especifican
inicialmente y de una manera resumida, en la plantilla
Visión
Se muestra el explorador de RequisitesPro donde se
visualizan estos documentos:
4.1.3.
Documentos definidos en Rational Rose:
Diagrama de casos de uso del sistema: donde se
representan gráficamente los actores, los casos de uso y sus
respectivas relaciones.
Una vez definida y guardada la necesidad de stakeholder en
el documento Visón, automáticamente se genera un
requerimiento de tipo STRQ en el RequistePro y puede
visualizarse desde el explorador del proyecto. Para crear un
documento relacionado con este requerimiento se procede a
través de la barra de herramientas de RequistePro en
WORD:
El documento se genera a partir de este requerimiento,
donde se especifican sus propiedades a través del cuadro de
diálogo correspondiente:
Este documento se puede ubicar en el Explorador de
RequisitePro y queda enlazado con su correspondiente
requerimiento.
4.2.4.
Definir y especificar casos de uso
Los casos de uso se definen primeramente en Rational
RequisitePro creando el documento correspondiente, luego
en el documento se crea el caso de uso y se detallan
aspectos como la descripción breve, el flujo principal del
caso de uso, los flujos alternos y flujos de excepción, cada
uno de ellos con su nombre respectivo, el cual se creará en
el proyecto y se mostrará en explorador.
4.2.2.
Especificar las características del sistema
(Features)
Igualmente que las necesidades de Stakeholder, las
características se definen inicialmente en la plantilla Visión
insertando el nuevo requerimiento tipo FEAT, el cual se
creará automáticamente en el RequisitePro y es posible
visualizarlo en el explorador del proyecto.
La jerarquía de los casos de uso, para definir el flujo básico,
flujos alternos y de excepción, se especifica a través de la
pestaña correspondiente en el cuadro de diálogo de las
propiedades del requerimiento.
4.2.3.
Definir requerimientos suplementarios o no
funcionales (SUPL)
De la misma forma se definen los requisitos suplementarios
en el documento visión del proyecto, y es posible crear
también un documento donde se detalle la descripción de
estos requerimientos.
4.2.5.
Crear casos de uso en Rational Rose
4.3.3.
Especificar la trazabilidad relacionando los
elementos a través de las herramientas RequisitePro y
Rose.
A través del cuadro de diálogo Requirement, en
RequisitePro, es posible asociar un requerimiento con un
modelo en el Rational Rose
4.3. Definir las relaciones de trazabilidad
4.3.1.
Especificar la trazabilidad a través de Matrices
o vistas
Una forma de especificar la trazabilidad es utilizando las
vistas o tablas, que inclusive se pueden personalizar, la
trazabilidad se representa gráficamente de la siguiente
forma
A
(Trace to)
(Trace from)
B
y
A
B
En las matrices o vistas definidas, es posible especificar la
trazabilidad
visualizando las filas y columnas
correspondientes y asignando la trazabilidad establecida.
La relación se crea en el Rational Rose y es posible
visualizarla en el explorador, además se muestra en el
cuadro de dialogo de las propiedades del modelo o
elemento correspondiente:
4.3.2.
Especificar la trazabilidad en la caja de diálogo
de propiedades del requerimiento
Además en la especificación de cada requerimiento, puede
definirse de manera individual, la relación de trazabilidad:
Los pasos mostrados no necesariamente se realizan de
manera secuencial, de acuerdo a lo planeado y las diferentes
5.
REFLEXIONES FINALES
• Considerando que el PU es un proceso iterativo
incremental, el trabajo requerido para la realización de
cambios a través de las iteraciones, se facilita con la
utilización de herramientas como las presentadas en este
artículo, las anotaciones, avisos e información histórica
administrados de manera digital ofrecen posibilidades
para la sistematización del proceso.
• Cada herramienta muestra una forma de documentar la
trazabilidad y además es posible realizar de manera
automática las relaciones entre el RequisitePro y Rational
Rose facilitando la trazabilidad en el desarrollo de las
disciplinas de requerimientos, análisis y diseño
• Aún cuando se cuente con herramientas que faciliten la
documentación de la trazabilidad, debe existir una
adecuada administración del proyecto, trabajo en equipo,
una formalizada administración del los requerimientos,
así como adecuados estándares de documentación.
• La utilización de un procesador de texto junto con la
herramienta facilita el uso de plantillas generales para el
proyecto, así como el mantenimiento de las mismas.
• El proceso de comunicación de cambios se centraliza a
través del uso de los documentos respectivos.
• El hecho de utilizar las herramientas no es por sí misma
la solución a los problemas relacionados con los
requerimientos y especialmente con la trazabilidad, sin
embargo permiten documentar de manera sistemática la
trazabilidad, así como los cambios realizados en los
requerimientos y sus especificaciones.
6. BIBLIOGRAFÍA
[1]. Leffingwell Dean. Widrig Don. “The Role of
Requirements Traceability in System Development”,
The Rational Edge, September 2002.
[2]. Rational Software Corporation. Rational RequisitePro
2003.
[3]. Rational Software Corporation. Rational Rose 2003.
[4]. Reiber, L. ¿Why Requirement Traceability?. Software
Requirement Inc.
[5]. Spence, I.Probasco, L. Traceability Strategies for
Managing Requirements with Use Cases. Rational
.com. 2002.
[6]. Stout. G. Requirements Traceability and the Effect on
the SDLC. Departamento de Sistemas Informáticos y
Computación. Universidad Politécnica de Valencia.
2001
[7]. Zielczynski, P. Traceability from Use Case to Test
Case. Rational User Conference 2003