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

CITATIONS READS

0 1,686

6 authors, including:

Carlos Arias Méndez Gabriela Vilanova

University of Magallanes Universidad Nacional de la Patagonia Austral
6 PUBLICATIONS   23 CITATIONS    14 PUBLICATIONS   19 CITATIONS   

SEE PROFILE SEE PROFILE

Silvia Gabriela Rivadeneira Molina María Miranda

Universidad Nacional de la Patagonia Austral Universidad Nacional de la Patagonia Austral
12 PUBLICATIONS   8 CITATIONS    5 PUBLICATIONS   5 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Innovación en procesos de enseñanza aprendizaje en ambientes mediados por tecnologías de la información y la comunicación 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.

 Construcción de Modelos de Requerimientos a partir de Modelos de Procesos de
Negocio
Carlos Arias Méndez
Departamento de Ingeniería en Computación
Universidad de Magallanes, UMAG
Punta Arenas, Chile
e-mail: carlos.arias@umag.cl
Gabriela Vilanova
Departamento de Ciencias Exactas y Naturales
Universidad Nacional de la Patagonia Austral, UNPA
Santa Cruz, Argentina
e-mail: vilanova@uolsinectis.com.ar
Silvia Rivadeneira Molina
Departamento de Ciencias Exactas y Naturales
Universidad Nacional de la Patagonia Austral, UNPA
Santa Cruz, Argentina
e-mail: grivadeneira@uart.unpa.edu.ar
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.
María Miranda
Departamento de Ciencias Exactas y Naturales
Universidad Nacional de la Patagonia Austral, UNPA
Santa Cruz, Argentina
e-mail: gmiranda@uaco.unpa.edu.ar
Diana Cruz
Departamento de Ciencias Exactas y Naturales
Universidad Nacional de la Patagonia Austral, UNPA
Santa Cruz, Argentina
e-mail: dianalrcruz@gmail.com
Juan Fontana
Departamento de Ciencias Exactas y Naturales
Universidad Nacional de la Patagonia Austral, UNPA
Santa Cruz, Argentina
e-mail: jefontana30@yahoo.com.ar
 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 el mismo cliente pueden encontrarse físicamente
habitantes de su zona de influencia. distribuidos. [24]
UART posee distintos sectores que reciben y envían
documentación: expedientes, instrumentos legales, AGRADECIMIENTOS
circulares, memorándums y notas. Algunos de los sectores El grupo de investigación agradece el apoyo y
intervinientes son: Decanato, Vice Decanato, Consejo de financiamiento de Ministerio de Ciencia y Tecnología e
Unidad, Secretaría de Administración, Secretaría de innovación productiva de Nación vía SeCyT (Secretaría de
Extensión, Secretaría de Investigación y Posgrado, Secretaría Ciencia y Técnica) de la Universidad Nacional de la
Académica, Departamento de Ciencias Sociales, Patagonia Austral. (Res 0025/12-R-UNPA)
Departamento de Ciencias Exactas y Naturales, Programa de
Acceso, Permanencia y Bienestar Universitario, Programa de REFERENCIAS
Educación a Distancia, Plan de Acción de Mantenimiento,
Biblioteca y las subáreas que dependen de las anteriores. [1] IEEE CS, Guide to the Software Engineering Body of Knowledge,
SWEBOK, 2004.
Definir temario [2] IIBA, A Guide to the Business Analysis Body of Knowledge,
BABOK, Versión 2.0, 2009.
[3] P. Loucopoulos y V. Karakostas, System Requirements Engineering,
Mc Graw Hill, 1995.
Secretario
[4] L. Antonelli y A. Oliveros, Fuentes utilizadas por desarrolladores de
Registrar sesión software en Argentina para elicitar requerimientos. WER. 2002.
[5] M. Sandoval, M. García y F. Madriz, Experiencias exitosas en la
aplicación de técnicas de elicitación de requerimientos.
[6] L. Antonelli y A. Oliveros, Revisión de las fuentes usadas para
elicitar requerimientos. 2003.
Generar instrumento legal [7] ISO/IEC 25030, Software Engineering – Software quality
requirements and evaluation (SQuaRE) – Quality Requirements,
2007.
Figure 2. Caso de uso extraido de BPD. [8] A. Delgado, Desarrollo de software enfocado en el negocio.
[9] A. Rodríguez, E. Fernández y M. Piattini, Hacia la obtención de
La UNPA ha modificado su estatuto e incorporado en clases de análisis y casos de uso desde modelos de proceso de
este último año Escuelas e Institutos a su estructura negocio.
organizacional, por lo que, en un futuro cercano existirán [10] OMG, Business Process Model and Notation (BPMN), Versión 2.0,
autoridades por cada uno de esos institutos y escuelas que, 2011.
por consiguiente, enviarán y recibirán documentación [14]. [11] S. White, Introduction to BPMN, IBM Corporation.
[12] J. Pérez, F. Ruíz y M. Piattini, Model Driven Engineering aplicado a
V. CONCLUSIONES Y TRABAJOS FUTUROS Business Process Management, Informe técnico UCLM, 2007.
A través de este artículo se ha presentado un plan de [13] 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
trabajo para desarrollar un modelo de requerimientos, basado requerimientos, II EIPA, 2012.
en casos de uso considerando los procesos de negocio como [14] UNPA, Estatuto UNPA, Res. 013/10-AU-UNPA, 2010.
punto de partida para la toma de requerimientos. Durante la
[15] J. García, M. Ortín, B. Moros, J. Nicolás y A. Toval, De los procesos
ejecución de este plan, se espera encontrar un método de negocio a los casos de uso, 2000.
adecuado para generar casos de uso a partir del BPD, [16] C. Larman, UML y Patrones. Una introducción al análisis y diseño
considerando desde un inicio, el desarrollo de sistemas de orientado a objetos y al proceso unificado, Pearson Educación, 2003.
información en forma integrada. [17] U. Ibarra, F. Alvarez y M. Vargas, Use Process – Modeling
Creemos que BPMN es comprendido por los Requirements Based on Elements of BPMN and UML Use Case
responsables de procesos, aunque al complicarse los Diagrams, 2° ICSTE, 2010.
procesos, los diagramas se complejizan [22] y UML ayuda [18] Introducción sobre BPM, Disponible en:
una mejor interpretación por parte de todos los interesados. http://www.willydev.net/InsiteCreation/v1.0/WillyCrawler/
Como próxima línea de investigación a abordar se [19] 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.
considera la incorporación de algún servicio web que
optimice el modelo de los procesos de negocio [20] Oracle, Gestión de procesos de negocio, Arquitectura orientada a
servicios y Web 2.0 ¿transformación de negocios o problemática
orientándonos a dominios complejos y/o críticos. Así como global?, 2008.
la integración de BPM y SOA (Service Oriented [21] F. Zorzan y D. Riesco, Transformación de procesos BPMN a su
Architecture) es factible de trabajar en detalle siguiendo implementación en BPEL utilizando QVT, WICC XII Workshop de
trabajos como [19, 20] y otros. Otra línea interesante a Investigadores en Ciencias de la Computación, 2010.
estudiar corresponde a analizar enfoques que integren la [22] N. Pérez, J. Martínez, H. Muñoz y D. De Francisco, Gestión de
especificación de requerimientos a partir de modelos de procesos de negocios semánticos, TELOS Cuadernos de
negocio bajo un paradigma de trabajo colaborativo, Comunicación e innovación, 2008
considerando que en la actualidad los equipos de desarrollo y [23] 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 [25] Bizagi Process Modeler.
in the Era of Outsourcing, Distributed Development, and Open http://www.bizagi.com/docs/BizAgi+Allianz%5BColombia%5D.pdf
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