HELER: HERRAMIENTA LIBRE PARA LA ESPECIFICACIN DE REQUISITOS BASADA EN EL PROCESO UNIFICADO HELER: A Free Tool to the Required Specifications

Based Upon the Unified Process Luz Yadira Castillo Estupin

Investigadora Grupo GIS, yadiracastillo@gmail.com, Proyecto Software Libre Escuela de Ingeniera de Sistemas y Computacin UPTC.
Ruby Mnica Fernndez lvarez

Investigadora Grupo GIS, rmoniquillafalvarez@gmail.com, Proyecto Software Libre Escuela de Ingeniera de Sistemas y Computacin UPTC.
Grupo de Investigacin en Software GIS-

RESUMEN Presenta el resultado de la investigacin realizada sobre Ingeniera de Requisitos (IR), la cual se bas en la metodologa de desarrollo de software denominada Proceso Unificado (UP) y tuvo como propsito desarrollar la herramienta HELER (Herramienta Libre para la Especificacin de Requisitos), que permite dar soporte a las actividades de Ingeniera de Requisitos contempladas en la fase de entendimiento del problema, enmarcada dentro del Proceso Unificado. Se presenta la descripcin de la herramienta HELER, en cuanto a sus mdulos de proyecto, de stakeholder, de actores y casos de uso y, finalmente, de requisitos. Palabras claves: Ingeniera de requisitos, Proceso Unificado, Heler.

ABSTRACT It presents the result of a research carried out on the Engineering of Requirements (ER), based on the development of a software methodology called Unified Process (UP), with the purpose to develop the tool called HELER (Free Tool for the Requirement Specifications), which allows to support the activities of the Engineering of Requirements, contained in the phase of the problems understanding, framed in the Unified Process. A description of the HELER tool is shown, in the modules of the project, such as the stakeholder, the actors, the cases of use and finally the requirements module. Key Words: Requirements Engineering, Unified Process, Heler.

1. INTRODUCCIN El trabajo de investigacin realizado sobre Ingeniera de Requisitos (IR) se bas en la metodologa de desarrollo de software denominada Proceso Unificado (UP). La IR cumple un papel primordial en el proceso de produccin de software, ya que se enfoca en la definicin de lo que se desea producir; su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades y en forma consistente y compacta el comportamiento del sistema. Como resultado de la investigacin se desarroll la herramienta HELER (Herramienta Libre para la Especificacin de

Requisitos), con el objeto de brindar soporte en las actividades del entendimiento del problema en el flujo de requisitos del UP. A continuacin se har una breve descripcin de los conceptos bsicos y de los temas primordiales utilizados en el proyecto, de algunas herramientas existentes y de investigaciones realizadas en el rea; posteriormente se hace una descripcin general de los resultados obtenidos del proyecto, y, finalmente, se presentan algunas conclusiones.

2. TEORAS APLICADAS 2.1 Ingeniera de Requisitos La Ingeniera de Requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente; con ella se analizan necesidades, se confirma la viabilidad de estas, se negocia una solucin razonable, se especifica la solucin sin ambigedad, se valida la especificacin y se gestionan los requisitos para que se transformen en un sistema operacional [1].

Conceptos bsicos Requerimiento: es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo [2]. Requisito1: (a) una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo; (b) una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal; (c) una representacin en forma de documento de una condicin o capacidad como las expresadas en (a) o en (b) [3]. Tipos de requisitos. Bsicamente, existen dos tipos de requisitos [4]: Funcionales: Describen los servicios o funciones del sistema. Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementacin. No funcionales: Describen las restricciones del sistema o del proceso de desarrollo.

Stakeholder: son personas que sern afectadas por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema [5]. Entre los roles de stakeholders pueden incluirse los siguientes: cliente, usuario, director del proyecto, arquitecto, desarrollador e ingeniero de mantenimiento.

Actividades en el proceso de Ingeniera de Requisitos Las cinco actividades en el proceso de IR son: la elicitacin, en la que se extraen, de cualquier fuente de informacin, las necesidades del usuario; el anlisis, que se centra en descubrir problemas con los requisitos; la especificacin de requisitos, en la que se documentan los requisitos; la validacin de
1

En el documento se usa la palabra requisito como sinnimo del termino ingls requirement.

requisitos, en la que se verifica que todos los requisitos que aparecen en el documento de especificacin son los que realmente quiere el cliente, y la gestin de requisitos, que es el proceso de entender y controlar los cambios de los requisitos en un sistema [6-7].

Trazabilidad de requisitos La trazabilidad se puede definir como la capacidad de describir y seguir la vida de un requisito [7], ya que permite conocer el impacto de un cambio, al poder saber a qu elementos afecta. Un elemento importante es la matriz de trazabilidad entre objetivos y requisitos. La utilidad de esta matriz est en que permite tener una visin rpida de las relaciones de dependencia entre objetivos y requisitos, y realizar una rpida comprobacin para saber si todos los objetivos tienen algn requisito asociado y si todos los requisitos estn justificados por un determinado objetivo; adems permite estudiar el impacto de posibles cambios en los requisitos [3].

2.2 Proceso Unificado (UP) El Proceso Unificado es una metodologa para el proceso de desarrollo de software; contiene un conjunto de actividades que transforman los requisitos de usuario en un sistema software. El UP es un proceso dirigido por casos de usos, centrado en la arquitectura, iterativo e incremental. El ciclo de vida del proceso est constituido por fases y flujos de trabajo; cada flujo de trabajo es un conjunto de actividades y est asociado a un artefacto. El flujo de trabajo de los requisitos, segn el Proceso Unificado, cuenta con las actividades de entendimiento del problema, definicin del sistema y revisiones. En la actividad de entendimiento del problema, objeto de esta investigacin, se identifican y elicitan los requisitos de los stakeholder, se encuentran los actores y casos de uso, se refinan y estructuran los requisitos [8].

2.3 UML El Lenguaje Unificado de Modelado (UML Unified Modeling Language) es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. UML est conformado de smbolos con su respectiva semntica, fundamentada en el paradigma orientado a objetos [9]. Diagramas UML: los diagramas tratados en las diferentes fases del desarrollo de software y modelados por UML son: Diagramas de Clase, de Objetos, de Secuencias, de Componentes, de Objetos, de Estados, de Estructura Compuesta, de Casos de Uso, de Despliegue, entre otros; para el objeto de esta investigacin se tomaron en cuenta los diagramas de Caso de Uso. Estos describen la funcionalidad del sistema y a los usuarios que los emplean, capturando as los requisitos funcionales del sistema. Para su diagramacin se utilizan los actores y los casos de uso: - Actor: conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con estos [9]. - Caso de uso: un caso de uso especifica una secuencia de acciones, que incluye variantes que ejecuta un sistema para producir un resultado observable, de valor para sus actores [9].

3. TRABAJOS PREVIOS En los ltimos aos ha ganado importancia la Ingeniera de Requisitos (IR); sus mtodos, metodologas, procesos y herramientas han llegado a resolver inconvenientes que se pueden presentar en la fase inicial de cualquier proyecto de desarrollo de software. A continuacin se mencionan algunas herramientas e investigaciones existentes relacionadas con el rea de IR. TCP Sistemas e Ingeniera desarroll en el 2006 la nueva versin de la herramienta IRQA versin 3.5.1 [10]; soporta los procesos de captura, anlisis y construccin de especificacin de requisitos. IBM Rational Software saca al mercado, en el 2006, la nueva versin Requisite Pro [11], herramienta que permite que los requisitos se encuentren documentados bajo estndares recomendados por IEEE, ISO, CMM y RUP. Telelogic desarroll la herramienta para administracin de Requisitos Doors [12]; esta herramienta permite capturar, relacionar, analizar y administrar un rango de informacin para asegurar el cumplimiento del proyecto en materia de requisitos. Clayton Vieira Fraga Filho, en el 2005, en Brasil, desarroll la herramienta denominada CONTROLA 1.0 [13], que permite la identificacin de los requisitos, sus detalles, la administracin de los cambios a travs de la matriz de rastreabilidad y control de versiones. En la Universidad de Sevilla (Espaa), Amador Durn Toro, en septiembre de 2004, desarroll, siguiendo la metodologa de su tesis de doctorado, una herramienta experimental denomina REM versin 1.2.2 (Requisite Management) [14], que soporta la actividad de IR. En la Universidad Politcnica de Valencia (Espaa), en el 2004, Ericc J. Frechina Egea y Eduardo Aguilar Hernndez crearon una versin acadmica de la herramienta RETO-UPV versin 2.0 (Requirements Engineering Tool) [15]. Esta permite la definicin de la misin del sistema, la construccin del rbol de refinamiento de funciones y el desarrollo del modelo de casos de uso. En cuanto a trabajos de investigacin, la Universidad Politcnica de Valencia cuenta con el trabajo llamado La identificacin de stakeholders en la Ingeniera de Requisitos [16], realizado por Carla Leninca Pacheco Agero; tuvo por objeto definir criterios que permitieran realizar un anlisis comparativo de las metodologas existentes utilizadas en la identificacin de los stakeholders en la Ingeniera de Requisitos. En la Universidad de Sevilla, Amador Durn Toro, en el ao 2000, desarroll la tesis Un entorno metodolgico de Ingeniera de Requisitos para sistemas de informacin que est compuesta por un modelo de proceso iterativo de elicitacin, anlisis y validacin [3]. En la Universidad del Cauca (Colombia), en el ao 2003, el Grupo Ingeniera de Telemtica realiz un trabajo titulado AMIR-ST: Propuesta de una aproximacin metodolgica para la Ingeniera de Requisitos de Sistemas Telemticos [17], en el que propone una aproximacin metodolgica flexible y adaptable a cualquier paradigma de desarrollo de software; la propuesta fue diseada para guiar los procesos de la captura de requisitos de sistemas telemticos. En la universidad EAFIT de Medelln (Colombia), en el ao 2002, el Grupo de Ingeniera de Software y sus investigadores Alberto Restrepo, Mnica Henao y Raquel Anaya aplicaron el modelo de Ingeniera de Requisitos propuesto en la Universidad de Sevilla a un caso real, haciendo

uso de la herramienta REM [14], que implementa este modelo. Y en el mismo ao, Rafael Rincn y Juan Guillermo Henao desarrollaron el proyecto de investigacin Modelos y herramientas de mtricas para Ingeniera de Requisitos [18], que es un estudio de modelos y propuesta de una herramienta para Ingeniera de Requisitos.

4. RESULTADOS Como resultado del trabajo de investigacin se desarroll una herramienta libre, monousuario, bajo ambiente Windows y bajo licencia GPL [19] con apoyo de la metodologa del proceso unificado de desarrollo de software (UP); la arquitectura tomada como base para el funcionamiento de la aplicacin est dada por el patrn de diseo Modelo Vista Controlador (MVC) [20-21], y se program bajo el entorno de desarrollo NetBeans 5.0, usando el gestor de bases de datos PostgreSQL versin 8.2 y la herramienta para el modelado de los diagramas UML Poseidon 4.0.1 community edition.

4.1 Estructura de HELER En la figura 1 se puede observar la ventana principal de la herramienta HELER, donde se encuentran los mens de archivo, edicin, proyecto, artefacto, ventana y ayuda, as como una barra de herramientas con conos para realizar las operaciones ms comunes.

Figura 1: Pantalla principal de HELER. A continuacin se describen los principales mdulos que integran a HELER. 4.1.1 Mdulo Proyecto Este mdulo rene las funcionalidades de registro, actualizacin, consulta, historial y fuente del proyecto, la visin y el glosario.

La figura 2 muestra la pantalla donde se registran los datos generales del proyecto, con el nombre del proyecto, nombre de la organizacin a la que se le desarrollar el sistema, direccin, telfono y e-mail. Esta pantalla tambin cuenta con una serie de pestaas en donde se puede hacer una descripcin general del proyecto, asignar fuentes de informacin, manejo de historial y comentarios.

Figura 2: Pantalla principal del Mdulo Proyecto En la figura 3 se observa la pantalla en la que se describen los objetivos del proyecto; a cada objetivo se le asigna un estado, urgencia y prioridad. Tambin hay una opcin para listar los objetivos existentes.

Figura 3: Pantalla general de objetivos del proyecto

En la figura 4 se muestra la pantalla en la que se debe describir la visin del proyecto por desarrollar; esta cuenta con varias pestaas en las que se registra la introduccin del artefacto visin, el alcance del artefacto, el posicionamiento del proyecto, estereotipos, referencias cruzadas con otros artefactos y un resumen del documento. Tiene la opcin de asignar algn tipo de fuente de donde se obtuvo informacin (documento, entrevista, encuesta, stakeholder y otros).

Figura 4: Pantalla general de la visin. En la figura 5 se presenta la pantalla que gestiona el glosario; esta cuenta con varias pestaas en las que se registra la introduccin del artefacto glosario, el alcance del artefacto, estereotipos, referencias cruzadas con otros artefactos, un resumen del documento. Se pueden agregar nuevos trminos con su respectiva definicin, as como generar el reporte de todos los trminos o la opcin de buscar un determinado trmino.

Figura 5: Pantalla general del glosario

La figura 6 representa la pantalla en la cual se listan las fuentes existentes en el proyecto; se busca por el tipo de fuente y se selecciona la fuente que se va a asignar, modificar o eliminar.

Figura 6: Pantalla general de asignacin de fuentes.

4.1.2 Mdulo Stakeholder El propsito de este modulo es identificar los stakeholder [22] que intervienen en el proyecto; aqu se determina qu personas actan como stakeholders. En la figura 7 se observa la pantalla en la que se registran los datos generales para crear un stakeholder; estos datos son nombre, direccin, telfono y email.

Figura 7: Pantalla principal Mdulo Stakeholder. En la figura 8 se muestra la informacin concentrada en la pestaa detalle del stakeholder, donde se asigna un rol al nuevo stakeholder, se selecciona o se crea un nuevo rol especfico y se muestran las actividades de cada rol especfico; adems, se pueden agregar nuevas actividades.

Figura 8: Pantalla de asignacin de rol, rol especfico y actividades. 4.1.3 Mdulo Actores y Casos de Uso Agrupa las funcionalidades relacionadas con creacin, modificacin y eliminacin de actores y casos de uso del negocio; se especifican detalladamente los casos de uso, describiendo las actividades que se ejecutan en cada uno de estos y la interaccin con los actores por medio de un flujo de eventos. En la pantalla de la figura 9 se identifican los actores, dndoles un nombre y asignndoles un rol especfico de los presentados en la pantalla.

Figura 9: Pantalla general actor. En la pantalla de la figura 10 se registra el nombre del caso de uso y su descripcin general, y se asignan prioridades de estado, riesgo y urgencia. Se puede ver el listado con todos los casos de uso creados en el proyecto.

Figura 10: Pantalla general del caso de uso. En la pantalla de la figura 11 se registran el tipo de accin que realizar el caso de uso, la condicin (opcional) y una breve descripcin de la accin; se puede registrar un nuevo flujo en el escenario del caso de uso, as como modificarlo o eliminarlo.

Figura 11: Pantalla especificacin caso de uso

4.1.4 Mdulo de Requisitos Este mdulo tiene que ver con las funciones de registro, modificacin, consulta y eliminacin de los requisitos funcionales y no funcionales. A cada requisito creado se le asigna el tipo de requisito, su especificacin, prioridad, estado, riesgo y urgencia; se valida si los requisitos satisfacen los objetivos mediante la matriz de trazabilidad.

En la pantalla que se muestra en la figura 12 se registra el nombre del requisito no funcional, se asigna un tipo de requisito no funcional y la descripcin del requisito; en la pestaa de prioridad se asigna el estado, riesgo, urgencia y la prioridad que tiene el requisito. Tambin cuenta con una opcin de ver el listado de los requisitos no funcionales existentes.

Figura 12: Pantalla general de Requisito no funcional.

En la ventana que se muestra en la figura 13 se registra el nombre del requisito funcional y su descripcin, y en la pestaa de prioridad se asigna el estado en el que se encuentra el requisito, el riesgo, la urgencia y la prioridad. Se pueden consultar todos los requisitos del proyecto.

Figura 13: Pantalla general de Requisito funcional.

5. TRABAJOS FUTUROS El grupo de investigacin que viene trabajando con el tema de ingeniera de requisitos, ha planteado la posibilidad de integrar un equipo interinstitucional, con el fin de hacer crecer la herramienta HELER, en sus fases de definicin del sistema y revisiones; as como tambin continuar creando mdulos de las dems etapas propuesto por el Proceso Unificado para el desarrollo de software.

6. CONCLUSIONES El desarrollo de la herramienta surgi gracias al conocimiento del estado del arte en el rea de IR, que permiti identificar los requisitos para su implementacin. Con el desarrollo de HELER se puede soportar la realizacin de las actividades involucradas en la fase de entendimiento del problema de acuerdo al UP. La utilizacin de la herramienta permite al usuario realizar la actividad de elicitacin de requisito de forma organizada y documentada. La herramienta est dirigida principalmente a brindar soporte a ingenieros de software, organizaciones desarrolladoras de software y acadmicos en el rea.

7. REFERENCIAS

[1] Roger S. Pressman. Software Engineering: A Practitioner's Approach, ISBN: 0072853182. New York: MacGraw-Hill, 2005. [2] Lizka Johany Herrera. Ingeniera de Requerimientos, http://www.frsf.utn.edu.ar/matero/visitante/bajar_repositorio.php?id_catedra=117&id_reposito rio=73, Agosto de 2007. [3] Amador Duran Toro. Un Entorno Metodolgico de Ingeniera de Requisitos para Sistemas de Informacin, http://www.lsi.us.es/~amador/publicaciones/tesis.pdf.zip, Agosto de 2007. [4] Bernd Bruegge, Allen H. Dutoit. Ingeniera de Software Orientado a Objetos, ISBN: 97026-0010-3. Mxico: Pearson Educacin, 2002. [5] Aybke Aurum, Claes Wohlin. Engineering And Managing Software Requirements, ISBN: 3540250433. New York: Springer, 2005. [6] Lizka Johany Herrera. La ingeniera de Requerimientos y su relacin con la ingeniera del software, http://www.willydev.net/descargas/articulos/general/IngReq.PDF, Agosto de 2007. [7] Grupo Arcos, Departamento de Informtica, Universidad Carlos III. Ingeniera de Requisitos: conceptos, procesos y estado de la investigacin, http://arcos.inf.uc3m.es/~ii_si/IngReqCIII.pdf, Agosto de 2007.

[8] Grady Booch, Ivar Jacobson, James Rumbaugh. El Proceso Unificado de Desarrollo de Software, ISBN: 84-7829-036-2. Mxico: Pearson Educacin, 2000. [9] Grady Booch, Ivar Jacobson, James Rumbaugh. El Lenguaje Unificado de Modelado, ISBN: 84-7829-076-1. Madrid: Pearson Educacin, 2006. [10] TCP Sistemas e Ingeniera. http://www.irqaonline.com/, Agosto de 2007. IRQA Integral Requisite Analycer.

[11] IBM International Business Machines Corp. Rational Requisite Pro. http://www306.ibm.com/software/awdtools/reqpro/, Agosto de 2007. [12] Telelogic AB. Gestin de requisitos para equipos http://www.telelogic.es/products/doors/index.cfm, Agosto de 2007. en colaboracin.

[13] Codeline Tecnologa en Informtica Ltda. Controla: Ferramenta de Apoio ao Processo de Desenvolvimento de Software em pequenas empresas. http://www.linhadecodigo.com.br/artigos.asp?id_ac=784&pag=1, Agosto de 2007. [14] Universidad de Sevilla, Requirements Management Tool. http://www.lsi.us.es/descargas/descarga_programas.php?id=3&lang=en, Agosto de 2007. [15] Universidad Politcnica de Valencia, Requirements http://reto.dsic.upv.es/reto/home.aspx, Agosto de 2007. Engineering Tool.

[16] Carla Leninca Pacheco Agero. La Identificacin de Stakeholders en la Ingeniera de Requisitos. http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Pacheco_Aguero.pdf, Agosto de 2007. [17] Mario Fernando Solarte Sarasty. AMIR-ST: Propuesta de una Aproximacin Metodolgica para la Ingeniera de Requisitos de Sistemas Telemtico. http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r52_art5_c.pdf, Agosto de 2007. [18] Grupo de Investigacin Ingeniera de Software. Universidad EAFIT. Coleccin de informacin de grupos de investigacin, http://www.eafit.edu.co/NR/rdonlyres/5ADDB84A146C-48B7-94AF-CC0FEA8CDA75/0/Cuaderno12.pdf, Agosto de 2007. [19] GNU General Public License. http://www.gnu.org/licenses/gpl-3.0.html, Agosto de 2007. [20] Cristina Gmez. Diseo de sistemas software en UML, ISBN: 8483017245. Barcelona: Edicions UPC, 2003. [21] Ann Winblad, Luis Joyanes Aguilar, Samuel Edwards. Software orientado a objetos, ISBN 0201601176. Wilmington: Addison-Wesley, 1993 [22] Dines Bjrner. Software Engineering, ISBN: 3540211519. New York: Springer, 2005.