See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/233529267 Construcción de Modelos de Requerimientos a partir de Modelos de Procesos de Negocio Conference Paper · November 2012 CITATION READS 1 3,399 6 authors, including: Carlos Arias Méndez Gabriela Vilanova University of Magallanes Universidad Nacional de la Patagonia Austral 6 PUBLICATIONS 31 CITATIONS 14 PUBLICATIONS 41 CITATIONS SEE PROFILE SEE PROFILE Silvia Gabriela Rivadeneira Molina María Miranda Universidad Nacional de la Patagonia Austral Universidad Nacional de la Patagonia Austral 17 PUBLICATIONS 16 CITATIONS 5 PUBLICATIONS 11 CITATIONS SEE PROFILE Some of the authors of this publication are also working on these related projects: Diseño y desarrollo de sistema de control para un VANT View project Improve web Accesibility View project All content following this page was uploaded by Silvia Gabriela Rivadeneira Molina on 05 June 2014. The user has requested enhancement of the downloaded file. SEE PROFILE Construcción de Modelos de Requerimientos a partir de Modelos de Procesos de Negocio Carlos Arias Méndez María Miranda Departamento de Ingeniería en Computación Universidad de Magallanes, UMAG Punta Arenas, Chile e-mail: [email protected] Departamento de Ciencias Exactas y Naturales Universidad Nacional de la Patagonia Austral, UNPA Santa Cruz, Argentina e-mail: [email protected] Gabriela Vilanova Diana Cruz Departamento de Ciencias Exactas y Naturales Universidad Nacional de la Patagonia Austral, UNPA Santa Cruz, Argentina e-mail: [email protected] Departamento de Ciencias Exactas y Naturales Universidad Nacional de la Patagonia Austral, UNPA Santa Cruz, Argentina e-mail: [email protected] Silvia Rivadeneira Molina Juan Fontana Departamento de Ciencias Exactas y Naturales Universidad Nacional de la Patagonia Austral, UNPA Santa Cruz, Argentina e-mail: [email protected] Departamento de Ciencias Exactas y Naturales Universidad Nacional de la Patagonia Austral, UNPA Santa Cruz, Argentina e-mail: [email protected] Resumen—La elicitación de requerimientos es un proceso primordial para conocer la realidad de una organización. Aún se sigue trabajando para encontrar técnicas que permitan adquirir las necesidades relevantes que permitan a los desarrolladores construir un software de calidad. En este trabajo presentamos una propuesta que permite combinar y derivar a partir del modelado de procesos de negocios (utilizando el estándar BPMN) en un modelo de requerimientos conformado por diagramas de casos de uso, diagramas de interacción y diagrama de clases preliminar. Palabras claves: Elicitación de requerimientos; modelado de procesos de negocio; modelado de requerimientos I. INTRODUCCIÓN El área de conocimiento de requerimientos de software está compuesta por los procesos elicitación, análisis, especificación y validación de requerimientos de software [1]. La elicitación es una de las áreas de conocimiento de [2] que describe como los analistas de negocio trabajan con los interesados para identificar y entender sus necesidades y preocupaciones, comprendiendo el entorno en el cual ellos trabajan. Coincidimos con [3] en que la elicitación de requerimientos es el proceso de adquirir todo el conocimiento relevante necesario para producir un modelo de requerimientos de un dominio del problema. Entre las técnicas de elicitación que sugieren las guías [1, 2], se encuentran: Brainstorming. Análisis de documentos. Focus Group. Interface Analysis. Entrevistas. Encuestas / Cuestionarios. Escenarios. Prototipos. Taller de Requerimientos / Reuniones facilitadas. Observación. Aunque [4] nos brinda un análisis sobre las técnicas de elicitación que los desarrolladores argentinos utilizan mayormente, donde el 100% utiliza técnicas tradicionales, tales como: entrevistas, cuestionarios, encuestas y análisis de formularios; el 29% utiliza técnicas grupales como focus group y brainstorming, pero también el prototipado se encuentra con el mismo porcentaje; el 16% utiliza técnicas contextuales, así como observación de participantes, etnometodología, análisis de conversación; un 3% utiliza técnicas dirigidas por modelos como goals-based o escenarios; dejando de lado aquellas que son denominadas cognitivas como análisis de protocolo, laddering, card sorting o repertory grids. En [5] presentan experiencias exitosas en la enseñanza respecto al uso de escenarios, brainstorming y taller de requerimientos. En [3] mencionan las siguientes seis fuentes de elicitación: expertos del dominio, literatura sobre el dominio, software existente acerca del dominio, software de otros dominios, estándares nacionales e internacionales, y otros interesados del sistema. En [1] encontramos una visión más amplia donde se establece que las fuentes de los requerimientos pueden ser: los objetivos, el conocimiento de dominio, los interesados en el sistema, el entorno de operación y el entorno de la organización. Analizando la literatura, encontramos que las fuentes de los requerimientos, para la gran mayoría de los autores, son las personas, aunque diferencian los roles que estas cumplen. También se menciona que las personas no son las fuentes más adecuadas por una serie de inconvenientes, tales como [6]: Las personas y los ingenieros de software utilizan lenguajes distintos. La dificultad de expresar claramente sus ideas. Falta de consenso entre los interesados. Falta de interés o aversión hacia el nuevo sistema. Dentro de las actividades que se deben cumplir en la elicitación de requerimientos se encuentran: la identificación de los interesados, la obtención de requerimientos funcionales, la identificación de las restricciones, la definición de los escenarios y la caracterización de los requerimientos de calidad [7]. Este trabajo se organiza de la siguiente manera: en la Sección 2 desarrollaremos la motivación que nos llevó a experimentar la conjunción de los estándares BPMN (Business Process Model and Notation) y UML (Unified Modeling Language) para complementar las técnicas de elicitación de requerimientos tradicionales y no tan tradicionales, en la Sección 3 se presenta la metodología de implementación que llevaremos a cabo, en la Sección 4 se plantea el caso de estudio que consideramos como base para la aplicación de los estándares antes mencionados, finalmente en la Sección 5 se presentan las conclusiones finales y trabajos futuros que nos interesa abordar en próximos estudios a realizar por el grupo de investigación. II. MOTIVACIÓN El desarrollo de un sistema de información es un proceso complejo que involucra no solo resolver problemas tecnológicos, sino también aspectos organizacionales y sociales. En el contexto de toda metodología de desarrollo de software, la obtención, análisis, especificación y validación de requerimientos, así como su gestión, son la base de un proceso organizado con el único fin de obtener un sistema informatizado que responda a las necesidades de una organización. En estos últimos tiempos, los paradigmas de desarrollo han evolucionado [8], se han creado nuevas metodologías y enfoques de desarrollo que repercuten en las organizaciones, pero también los requerimientos de las organizaciones han cambiado y requieren adaptarse constantemente, influyendo en el desarrollo de software. Cada día en la industria del software se incrementan las habilidades requeridas de los profesionales. Nuevos desafíos en el desarrollo de software como el offshore (puntos de desarrollo en distintas localidades geográficas) y desarrollo de software distribuido requieren profesionales con nuevas habilidades. [23,24] El análisis de negocio es el conjunto de tareas y técnicas utilizadas para trabajar como enlace entre los interesados con el fin de entender la estructura, políticas y operaciones de una organización para recomendar soluciones que permitan a la misma alcanzar sus metas [2] mediante la reingeniería de los procesos de negocio o en menor escala a la optimización de algunas tareas. Lo anterior nos permite tener una visión holística sobre la operación de la empresa, que se refleja a través de sus procesos y a su vez permite considerar, desde un principio, el desarrollo de sistemas informáticos de una forma integrada, facilitando el desarrollo de sistemas de gestión, y por ende, la gestión de la empresa. Hoy en día, hay una gran necesidad de integrar sistemas de información que históricamente se han ido desarrollando en forma vertical, generando silos de aplicaciones, y la preocupación por integrarlos de alguna forma, para facilitar la alineación de la operación y gestión de la empresa con su plan estratégico. Por lo tanto, el dominio del problema no puede aislarse de la organización en la que está inserto y por ende la obtención de requerimientos debe considerar las necesidades del negocio. Un dominio es el área objeto de estudio, que puede corresponder con los límites de la organización, unidades organizacionales, así como a los interesados que se encuentren dentro o fuera de las fronteras y/o en la interacción con esos interesados [2]. Los procesos de negocio han adquirido importancia en las organizaciones como un recurso que les permite diferenciarse y lograr ventajas competitivas. Para la ingeniería de software representa una fuente de requerimientos que permite complementar las tareas de elicitación de requerimientos [9]. Utilizamos BPMN porque su principal objetivo es proporcionar una notación que sea fácilmente comprensible por todos los usuarios de negocios, desde los analistas que crean los borradores iniciales de los procesos hasta los desarrolladores técnicos responsables de la aplicación de la tecnología que llevará a cabo esos procesos, y por último la gente de negocios que controla y monitorea estos procesos [10, 11]. Y especialmente porque fue diseñado teniendo en cuenta la tecnología de servicios web [12]. Este trabajo pertenece al proyecto de investigación 29/B134-1 “Modelado de Requerimientos y Diseño de Sistemas Complejos” que se encuentra radicado en la Unidad Académica Caleta Olivia, Provincia de Santa Cruz. Argentina (UACO) de la Universidad Nacional de la Patagonia Austral (UNPA) y está integrado por docentes investigadores y estudiantes de carreras de pre-grado, grado y posgrado de informática. III. METODOLOGÍA DE IMPLEMENTACIÓN Las técnicas de elicitación que utilizaremos son: entrevistas; análisis de documentos; observación; Léxico Extendido del Lenguaje (LEL); escenarios y modelado de procesos mediante el estándar BPMN. Los productos resultantes del uso de las técnicas mencionadas formarán parte del documento de especificación de requerimientos. En las asignaturas de carreras de pre-grado en informática habitualmente se aplica el estándar IEEE Std 830-1998. La herramienta que está siendo utilizada para modelar los diagramas de procesos es Bizagi Process Modeler v2.3 [25] ya que permite exportar los diagramas como archivos de imagen, o archivos de Visio, aunque también publicar en Word, Pdf, Web y Wiki. En el caso de la herramienta para los diagramas de casos de uso, de interacción y de clases se trabaja con StarUML v5.0. Se han seleccionado herramientas libres por la disponibilidad y simplicidad de implementación en nuestra y otras organizaciones que formen parte de este proyecto. A. Modelado de procesos En este trabajo nos enfocaremos en el modelado de procesos mediante BPMN, entendiendo que construiremos una red de objetos gráficos, denominados actividades (tareas) y los controles de flujo que definen su orden de actuación [11]. Se especifica un único tipo de diagrama, Business Process Diagram (BPD), con un conjunto de elementos núcleo y un conjunto de elementos completo, donde el conjunto núcleo servirá para modelar la mayoría de los procesos de negocio [8]. Las decisiones de negocio y las ramificaciones de los flujos son modeladas utilizando pasarelas (gateway). Se puede modelar quien hace las tareas, simplemente colocando eventos y actividades dentro de áreas sombreadas, denominadas contenedores (pools), los cuales pueden ser divididos en calles (lanes) que representan a otros departamentos o áreas, o cargos de la organización, mientras que el contenedor representa la organización entera [12]. Actualmente BPMN es un estándar de la Object Management Group (OMG), al igual que UML, y se encuentra en la versión 2.0. Descubiertos los procesos de negocio (Fig. 1), y antes de desarrollar el modelo de procesos en detalle se priorizan los mismos junto al cliente. Asimismo, siguiendo con la metodología deberemos definir junto al cliente que actividades se informatizarán [13]. Ya que entendemos que la participación y la implicación de los clientes y usuarios en el desarrollo de software aumenta la probabilidad de su satisfacción [17]. En el modelado de procesos de sistemas complejos, donde la probabilidad de cambios en las especificaciones funcionales son muy elevadas, una opción efectiva es la combinación SOA (Service Oriented Architecture) para permitir la flexibilidad de cambios necesarios en la organización y así poder reutilizar los componentes de procesos de negocio como servicios. Así, el modelado de procesos de negocios es la base para comprender mejor la operación de una organización, mientras que SOA brinda capacidad de añadir, modificar y optimizar fácilmente los procesos de negocio mediante el aprovechamiento de las sinergias de servicios. Una de las arquitecturas orientadas a servicios más popular es el Web Service que nos permite diseñar aplicaciones distribuidas basadas en Web y así pensar en el diseño independientemente de la tecnología utilizada por la organización. Otro estándar importe a considerar corresponde a BPEL (Business Process Execution Language) que proporciona facilidades para la orquestación de servicios, combinación de servicios web para conseguir un flujo de negocio. Existen frameworks que facilitan la creación de flujos de procesos de negocio, tal es el caso de jBPM (JBoss Business Process Model) [18] que soporta dos lenguajes de proceso JPDL (jBPM Process Definition Language, enfocado a la definición de flujos de procesos en Java) y BPEL. JBPM enfoca su filosofía hacia GOA. Mediante un gráfico se diseña el flujo y posteriormente se le dota de la lógica necesaria mediante mapeos con clases de Java. De este modo se crea un nexo entre el analista o diseñador y el programador. Otro trabajo [21] define la transformación desde el metamodelo BPMN al metamodelo del lenguaje BPEL para ser ejecutado en un motor workflow, utilizando también QVT (Query/View/Transformation) como un lenguaje de consultas para definir transformaciones entre los metamodelos. En definitiva, la automatización es una de las líneas donde más se invierte actualmente [22]. B. Modelado de requerimientos Si bien, [15] observa algunos problemas en la utilización de los casos de uso como la falta de consenso sobre su organización y manejo, nosotros adherimos al enfoque propuesto por Larman en [16]. En un BPD cada actividad tiene asignada quien la ejecuta, para derivar un caso de uso se tendrá en cuenta [13]: Quien ejecuta la actividad será un actor. Las acciones que se describan dentro de la actividad corresponden a los casos de uso (Fig. 2). Una vez extraídos los casos de uso se generan los diagramas de secuencia que describan cada uno de los escenarios de los casos de uso. Luego se diseña el primer Diagrama de Clases de la etapa de análisis, y a partir del diagrama de clase preliminar se genera el diagrama de comunicación (colaboración), definiendo conjuntamente los requerimientos no funcionales. Figure 1. BPD de una sesión de Consejo de Unidad. IV. CASO DE ESTUDIO Nuestro caso de estudio es principalmente el área de Investigación donde se requiere de un Sistema que permita llevar adelante la Gestión de Documentos de la Unidad Académica Río Turbio (UART) de UNPA y todas las áreas y sectores que intervienen en el circuito de seguimiento de los documentos. UART es una de las cinco unidades de gestión que conforman la UNPA. Al igual que toda Universidad, tiene como misión brindar educación superior universitaria a los habitantes de su zona de influencia. UART posee distintos sectores que reciben y envían documentación: expedientes, instrumentos legales, circulares, memorándums y notas. Algunos de los sectores intervinientes son: Decanato, Vice Decanato, Consejo de Unidad, Secretaría de Administración, Secretaría de Extensión, Secretaría de Investigación y Posgrado, Secretaría Académica, Departamento de Ciencias Sociales, Departamento de Ciencias Exactas y Naturales, Programa de Acceso, Permanencia y Bienestar Universitario, Programa de Educación a Distancia, Plan de Acción de Mantenimiento, Biblioteca y las subáreas que dependen de las anteriores. Definir temario el mismo cliente distribuidos. [24] REFERENCIAS [1] [2] [4] [5] [6] Figure 2. Caso de uso extraido de BPD. La UNPA ha modificado su estatuto e incorporado en este último año Escuelas e Institutos a su estructura organizacional, por lo que, en un futuro cercano existirán autoridades por cada uno de esos institutos y escuelas que, por consiguiente, enviarán y recibirán documentación [14]. V. CONCLUSIONES Y TRABAJOS FUTUROS A través de este artículo se ha presentado un plan de trabajo para desarrollar un modelo de requerimientos, basado en casos de uso considerando los procesos de negocio como punto de partida para la toma de requerimientos. Durante la ejecución de este plan, se espera encontrar un método adecuado para generar casos de uso a partir del BPD, considerando desde un inicio, el desarrollo de sistemas de información en forma integrada. Creemos que BPMN es comprendido por los responsables de procesos, aunque al complicarse los procesos, los diagramas se complejizan [22] y UML ayuda una mejor interpretación por parte de todos los interesados. Como próxima línea de investigación a abordar se considera la incorporación de algún servicio web que optimice el modelo de los procesos de negocio orientándonos a dominios complejos y/o críticos. Así como la integración de BPM y SOA (Service Oriented Architecture) es factible de trabajar en detalle siguiendo trabajos como [19, 20] y otros. Otra línea interesante a estudiar corresponde a analizar enfoques que integren la especificación de requerimientos a partir de modelos de negocio bajo un paradigma de trabajo colaborativo, considerando que en la actualidad los equipos de desarrollo y físicamente El grupo de investigación agradece el apoyo y financiamiento de Ministerio de Ciencia y Tecnología e innovación productiva de Nación vía SeCyT (Secretaría de Ciencia y Técnica) de la Universidad Nacional de la Patagonia Austral. (Res 0025/12-R-UNPA) Registrar sesión Generar instrumento legal encontrarse AGRADECIMIENTOS [3] Secretario pueden [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] IEEE CS, Guide to the Software Engineering Body of Knowledge, SWEBOK, 2004. IIBA, A Guide to the Business Analysis Body of Knowledge, BABOK, Versión 2.0, 2009. P. Loucopoulos y V. Karakostas, System Requirements Engineering, Mc Graw Hill, 1995. L. Antonelli y A. Oliveros, Fuentes utilizadas por desarrolladores de software en Argentina para elicitar requerimientos. WER. 2002. M. Sandoval, M. García y F. Madriz, Experiencias exitosas en la aplicación de técnicas de elicitación de requerimientos. L. Antonelli y A. Oliveros, Revisión de las fuentes usadas para elicitar requerimientos. 2003. ISO/IEC 25030, Software Engineering – Software quality requirements and evaluation (SQuaRE) – Quality Requirements, 2007. A. Delgado, Desarrollo de software enfocado en el negocio. A. Rodríguez, E. Fernández y M. Piattini, Hacia la obtención de clases de análisis y casos de uso desde modelos de proceso de negocio. OMG, Business Process Model and Notation (BPMN), Versión 2.0, 2011. S. White, Introduction to BPMN, IBM Corporation. J. Pérez, F. Ruíz y M. Piattini, Model Driven Engineering aplicado a Business Process Management, Informe técnico UCLM, 2007. C. Monserrat, A. Páez, C. Arias, S. Rivadeneira, G. Vilanova y G. Miranda, El modelado de procesos como técnica de elicitación de requerimientos, II EIPA, 2012. UNPA, Estatuto UNPA, Res. 013/10-AU-UNPA, 2010. J. García, M. Ortín, B. Moros, J. Nicolás y A. Toval, De los procesos de negocio a los casos de uso, 2000. C. Larman, UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado, Pearson Educación, 2003. U. Ibarra, F. Alvarez y M. Vargas, Use Process – Modeling Requirements Based on Elements of BPMN and UML Use Case Diagrams, 2° ICSTE, 2010. Introducción sobre BPM, Disponible en: http://www.willydev.net/InsiteCreation/v1.0/WillyCrawler/ P- Bazán, R. Giandini y F. Díaz, Tecnologías para implementar un marco integrador de SOA y BPM, Informe Técnico,UNLP, 2010. Oracle, Gestión de procesos de negocio, Arquitectura orientada a servicios y Web 2.0 ¿transformación de negocios o problemática global?, 2008. F. Zorzan y D. Riesco, Transformación de procesos BPMN a su implementación en BPEL utilizando QVT, WICC XII Workshop de Investigadores en Ciencias de la Computación, 2010. N. Pérez, J. Martínez, H. Muñoz y D. De Francisco, Gestión de procesos de negocios semánticos, TELOS Cuadernos de Comunicación e innovación, 2008 Favela, J., Peña-Mora, F. (2001) An Experience in Collaborative Software Engineering Education. IEEE Software, 18(2), pp. 47- 53. [24] Hawthorne, M., Dewayne, E. (2005) Software Engineering Education in the Era of Outsourcing, Distributed Development, and Open Source Software: Challenges and Opportunities. Proc. of the 27th Int. Conf. on Software Engineering (ICSE). St. Louis, USA. Pages: 643 644. 2005. View publication stats [25] Bizagi Process Modeler. http://www.bizagi.com/docs/BizAgi+Allianz%5BColombia%5D.pdf
