Actas de Ingeniera

Vol. 1, pp. 6-10, 2015

http://fundacioniai.org/actas

Methodology for software development integrating SOA, BPM, and TOGAF

Metodologa para el desarrollo de software integrando SOA, BPM y TOGAF
Lourdes De vila Gutirrez

Ldeavila(AT)itsa.edu.co
Instituto Tecnolgico de Soledad Atlntico Colombia
Artculo de investigacin
ABSTRACT
The need to generate new paradigms in software engineering requires the development of models and methodologies that properly
use innovations, personalized services, and information technologies to integrate different models. This makes interactivity and access
to vital information easier for the organization through the development of quality software, such as attempts to avoid software chaos
with new proposals that could be integrated with existing methods. With this in mind a new methodology was developed which
integrates Service Oriented Architecture (SOA) and Business Process Management (BPM), through the software life cycle and the Open
Group Architecture framework (TOGAF). This allows the use of SOA in each phase. The development team will provide the enterprise
an architecture which will serve as a guide to reach business objectives, thus bringing it closer to the BPM model which focuses in the
services supplied to the business. Besides using tools to make access and project documentation easier, it also allows the business to
have the same language and meet project requirements.
Keywords: SOA, BPM, TOGAF
RESUMEN
La necesidad de generar nuevos paradigmas en la ingeniera de software, requiere el desarrollo de modelos y metodologas que
utilicen adecuadamente las innovaciones, los servicios personalizados y las tecnologas informticas para integrar diferentes
modelos que facilitan la interactividad y el acceso a la informacin vital para las organizaciones mediante el desarrollo de software
de calidad, es decir, las nuevas propuestas puedan integrarse con las metodologas existentes para tratar de evitar el caos en el
software. Teniendo en cuanta lo anterior se desarroll una metodologa en la cual se integra la Arquitectura Orientada a Servicio
(SOA) y la Gestin de Procesos de Negocio (BPM), de tal forma que a travs del ciclo de vida del software y las fases utilizadas por el
framework Arquitectura o esquema de Open Group (TOGAF) permita que utilizando SOA en cada fase, el equipo desarrollador le
provea a la empresa una arquitectura tecnolgica, que en cada uno de sus proyecto se oriente a los objetivos de su negocio,
acercndolo al modelo BPM que tendr en cuenta los servicios que presta el negocio. Adems de utilizar herramientas de fcil
acceso y documentacin del proyecto, para que la organizacin tenga el mismo lenguaje y cumpla con los requisitos del proyecto
Palabras clave: SOA, BPM, TOGAF
2015. IAI Allrightsreserved

Introduccin

Actualmente, la tendencia en las organizaciones es

hacia un paradigma orientado a procesos, donde las
aplicaciones abarcan la actividad global de la empresa y
las herramientas son los BPMS [11]. Pero los modelos
resultan insuficientes porque no se integran
adecuadamente y se orientan a describir datos y
transacciones. El cambio de enfoque en el modo de
disear aplicaciones e implementar soluciones radica en:

Explicitar el conocimiento de un proceso de negocio

ayudando
a
documentarlo,
definirlo
e
implementarlo
Proveer interoperabilidad de las soluciones
Resolver la dinmica de los problemas en trminos
declarativos y cubriendo todas las etapas del ciclo
de vida del software

Por su parte, la comunidad del software est

interesada en proveer sistemas robustos y escalables.
Adems, debido a que los procesos de negocios se
realizan en espacios de informacin tecnolgica
compleja, la integracin de los Sistemas de Informacin
existentes se convierte en una base importante para la
implementacin tcnica de los procesos de negocio.

Segn Weske Mathias [4], la herramienta BPM se

basa en la observacin de cada producto que la compaa
provee al mercado, lo que genera como resultado un
nmero de actividades ejecutadas. Los procesos de
negocio son la clave para organizar esas actividades y
mejorar el entendimiento de sus interrelaciones. Otra de
estas herramientas es SOA, que segn Delgado [10]
permite disear, construir, desplegar e integrar los
servicios independientes de los lenguajes en los que
estn codificados y de las plataformas en las que se
ejecutan. Estos servicios estn vinculados entre s y se
definen a travs de procesos de negocio formando
servicios compuestos que llevan a cabo las funciones
empresariales. Los servicios pueden compartirse y
reutilizarse en varios procesos de negocio. El resultado
es un entorno altamente adaptable, con menores costos
para el desarrollo de aplicaciones, mejoras en la
integracin y despliegue rpido.
El desarrollo de software orientado a servicios y a
gestin de procesos est vinculado con el manejo de flujo
de trabajo, segn lo demuestra Bazn [17] en su tesis. Un
sistema de manejo de workflow permite definir, crear y
manejar la ejecucin de flujos de trabajo a travs del uso
6

de software, puede correr en uno o ms motores y es

capaz de interpretar la definicin del proceso,
interactuar con los participantes del workflow, y donde
sea requerido invocar el uso de herramientas y
aplicaciones de tecnologas de la informacin. Lo que
buscan alcanzar estos flujos de trabajo es la
representacin de las estructuras de los procesos a
travs de modelos, y el control de estos basndose en los
modelos SOA y BPM. La aproximacin a travs del
manejo de modelos facilita un mayor grado de
flexibilidad, debido a que estos pueden ser adaptados a
los requerimientos, y las modificaciones resultantes se
pueden utilizar inmediatamente para representar los
procesos de negocio.

facilitar su visualizacin, pero su descripcin se

considera de manera conjunta modeladas en un BPMS.
2.1 Organizacin y plan estratgico
Esta etapa cubre toda la vida del proyecto y al igual
que la ltima de las etapas, siempre est presente en cada
una de las etapas sucesivas. En esta etapa la empresa se
prepara para iniciar el desarrollo del proyecto
definiendo los equipos de trabajo, los principios que
regirn la arquitectura y los marcos y herramientas de
trabajos requeridos, adems se establece el alcance, las
restricciones y expectativas sobre el desarrollo del
proyecto.

De acuerdo con Robledo [9], para obtener

verdaderos beneficios de los enfoques SOA y BPM se
deben reformular roles y responsabilidades en la
definicin, especificacin e implementacin de los
proyectos dentro de la organizacin. El equipo tcnico
debe reorientarse a resolver el trabajo en forma nomonoltica, identificando componentes verticales.
Aparece la figura de arquitecto, que ensambla cada una
de las piezas e interacta con el analista de negocios, otro
actor preponderante en este escenario que debe
participar activamente en todas las etapas de la
concrecin del proyecto.
2

Propuesta integrando SOA y BPM utilizando

framework TOGAF

Esta propuesta metodolgica se define como un

conjunto de etapas, la determinacin de su alcance, la
forma de interaccin de las mismas y su aplicacin a la
resolucin de problemas en trminos de procesos y
servicios. Est dirigida a proyectos, trascendiendo los
aspectos tecnolgicos y aportando una visin diferente
para resolver los problemas, a la luz de la identificacin
transversal de procesos de negocio. Estos procesos se
transforman en consumidores de servicios que pueden
tener o no una implementacin tecnolgica.
El objetivo es comprender a la organizacin y
establecer claramente una serie de fases que ordenen las
actividades a llevar a cabo de manera permanente, para
alcanzar el propsito de contar con un ciclo de mejora
continua de procesos, capaces de absorber los cambios
que propone la realidad. Se describen a continuacin las
etapas propuestas, las actividades y el alcance de las
mismas para el desarrollo de proyectos con enfoque en
los procesos de negocio, como se muestra en la Figura 1.

Figura 2: Metodologa: Etapa superpuesta en cada ciclo

La organizacin del proyecto debe incluir los

objetivos, el alcance, una consideracin de alternativas
de solucin, el anlisis financiero, patrocinadores y
participantes, acuerdos de entendimiento, aprobaciones
necesarias, un plan de proyecto y una revisin de los
riesgos asumidos. Para llegar a esta organizacin se tiene
en cuenta lo trabajado por Bazn [8].
2.2 Identificacin, especificacin de requisitos y
diseo de proceso de negocio
Esta etapa incluye el anlisis de requisitos como una
actividad importante en el desarrollo de todo el ciclo de
vida del software, que las metodologas tradicionales
solamente consideran parcialmente, para lo cual es
importante aclarar el trmino requisitos que desde el
punto de vista de los usuarios simbolizan los problemas
que deben ser solucionados por medio de la construccin
de una aplicacin [10]. Se incluye en esta propuesta una
metodologa basada en la idea del diseo participativo de
procesos. Asimismo se inicia una iteracin del proceso de
arquitectura, debido a que se afianza el alcance, las
limitaciones y las expectativas de la organizacin:
tambin se inicia la creacin de la visin de la
arquitectura y se vlida el contexto del negocio, tal como
se desarrolla en la fase de visin del negocio en el
framework TOGAF [7], donde se integra el desarrollo de
procesos con los servicios prestados en la organizacin,
de tal forma que tengan una alta relacin con los
procesos del negocio. En consecuencia, se desarrollan las
siguientes actividades:

Figura 1: Metodologa: Etapa superpuesta en cada ciclo

En la Figura 2 se muestra el modo de interaccin de

estas etapas. Se grafican de manera independiente para

Diseo del proceso de flujos de trabajo de negocio.

Para esta actividad se debe realizar un cronograma
de trabajo para recolectar la informacin sobre la
temtica, clientes, posibles usuarios de la
organizacin o sector productivo, donde se
desarrollar el nuevo sistema. Adems se describe
la estructura organizacional de los procesos de
7

negocios, los sistemas de planeacin y control, los

mecanismos de gobierno y la administracin de
polticas y procedimientos [2]. Tambin se debe
obtener la informacin acerca del contexto de la
organizacin a nivel de la arquitectura tecnolgica,
y de esta forma crear la visin de la arquitectura
actual de la organizacin. Para esto se puede utilizar
fuentes primarias, tales como entrevistas,
encuestas, lluvia de ideas, entre otras, adems de
fuentes secundarias, tales como registros o
documentos importantes de la organizacin para el
sistema a desarrollar. Una vez se culmine estas
actividades se debe realizar un diagrama de flujo de
trabajo de negocio, donde se observe claramente el
alcance, las limitaciones, los objetivos del negocio y
su entorno. Para esto se utiliza el diagrama de flujo
de trabajo de UML. Conjuntamente se desarrolla un
documento donde se construye una declaracin de
la arquitectura. En esta actividad se observa el uso
de la etapa de anlisis y diseo del ciclo de vida de
procesos.

se describen como un conjunto de tareas en las que los

actores participan segn un flujo de trabajo determinado
[25]. Estos procesos pueden organizarse en forma
jerrquica, hasta con dos o tres niveles de anidamiento.
Para modelar el negocio es necesario que la organizacin
identifique los componentes de negocio, en cuanto a la
estructura de la organizacin, los objetivos y las metas
del negocio. El modelado de procesos mediante
identificacin de componentes requiere detallar los
mismos componentes, tales como el conjunto de tareas o
actividades o funciones que se llevan a cabo, realizadas
en determinadas condiciones y bajo un determinado rol.
Dentro del conjunto de actividades existen tareas
automticas, manuales o mixtas y son unidades
indivisibles en trminos de modelado, adems de los
servicios que ofrece el negocio, los roles que desarrolla
cada servicio, actividad o tarea y la correlacin entre la
organizacin y sus funciones. Los subprocesos agrupan
tareas interrelacionadas que pueden ser realizadas por
varios roles y constituyen un producto intermedio para
el proceso.

Diseo del proceso de elicitacin de requisitos. En

esta actividad se debe seleccionar las personas que
participarn en el proceso de elicitacin de
requisitos. Adems se seleccionan las tcnicas de
recoleccin de informacin, entre las que se
encuentran:
entrevistas
y
cuestionarios,
braingstorming y reduccin de ideas, workshop,
JAD-JRD, puntos de vistas, casos de uso, prototipos,
storyboards, reuniones, entre otras. Se debe disear
los cuestionarios definiendo sus objetivos,
poblacin dirigida, tiempo de desarrollo y tipo de
pregunta (abiertas y cerradas). Tambin se elige un
modelo de ciclo de vida del proceso de elicitacin
(los ms usuales son el modelo de PoHL y en
espiral). El modelo de PoHL est compuesto por las
actividades de elicitacin, negociacin, validacin y
verificacin, especificacin y documentacin [29].
Finalmente, se elige una herramienta informtica
para dar soporte a la gestin, seguimiento, registro
y documentacin del proceso de elicitacin. Entre
las herramientas ms utilizadas se encuentran REM
y Enterprise Architect.

Cada proceso de negocio se representa como un

caso de uso del negocio, que inicialmente se describe en
forma textual. Para tener una visin general de los
diferentes procesos de negocio de la organizacin puede
construirse un diagrama de casos de uso del negocio, en
el cual aparece cada proceso como un caso de uso UML
[13]. Este diagrama permite mostrar los lmites y el
entorno de la organizacin bajo estudio y obtener un
mapa de proceso.

Elicitacin de requisitos. Para iniciar el proceso se

debe realizar una priorizacin de los requisitos,
para lo cual una de las tcnicas ms utilizada es la de
comparacin pair wise. Esta priorizacin de
requisitos brinda un instrumento claro para
seleccionar un conjunto optimizado de requisitos
para la implementacin, adems, ayuda a los
administradores del proyecto a predecir la
satisfaccin de los clientes antes que el sistema sea
puesto en produccin.

Como producto de esta etapa se genera un

documento donde se especifican los requisitos del
cliente, los usuarios y los desarrolladores. Estos
requisitos deben estar clasificados en funcionales y nofuncionales, es decir, el modelo de requisitos, y teniendo
en cuenta lo expresado por Fortune [28].
2.3 Modelado del negocio
En esta etapa se identifican los procesos de negocio
y sus principales restricciones. Los procesos de negocio

El resultado de esta etapa es un mapa de procesos y

la descripcin de los casos de uso con su respectivo
diagrama, para dar cuenta de la funcionalidad, es decir,
un diagrama de casos de uso para el modelado del
negocio, desarrollado en cualquier herramienta que
soporte UML, o bien valerse de formularios prediseados
para volcar dicha informacin. Adems, se debe definir la
arquitectura base y la arquitectura objetivo, para poder
realizar la documentacin con el visto bueno de la
arquitectura final de la aplicacin. En el proceso se debe
tener en cuenta dos aspectos importantes del proyecto:
1) el mapa de procesos, y 2) los requisitos definidos en el
sistema, teniendo como base la fase de arquitectura del
negocio implementada en el framework TOGAF [7] y la
fase B referente a la arquitectura del negocio. Esto hace
parte de la fase visin del sistema de informacin dentro
de la etapa de anlisis, diseo y configuracin para ciclo
de vida de procesos, en el desarrollo de procesos del
software, del cual se obtiene un documento avalado por
la organizacin [22].
2.4 Modelado de procesos
En esta etapa se modela cada uno de los procesos
identificados y detallados en los casos de uso del negocio,
obteniendo un diagrama del proceso de negocio que se
representa en el diagrama de clase de UML. Este
diagrama describir y estructurar los objetos de
informacin que fluyen entre las actividades de un
proceso de negocio y que representan datos del dominio.
Estos datos del domino constituyen una base para crear
el modelo de datos conceptual inicial. Este modelo
incluir las entidades y las relaciones entre cada uno y el
ambiente, lo cual se describir mediante un diagrama de
8

clases UML, en el que las entidades se representan

mediante clases (clases del dominio).

Este diccionario ser el insumo principal en el

desarrollo del diagrama de clases y permitir identificar
los atributos ms importantes de cada dato, adems de
garantizar su unicidad. Esto responde a la fase
denominada arquitectura del sistema de informacin
que hace parte de la fase visin del sistema de
informacin del framework TOGAF, dentro de la etapa de
configuracin del ciclo de vida del proceso [7, 31]

Tambin permite la definicin de componentes y

utiliza los conceptos para identificar y componer
servicios con el objetivo de dar respuesta a procesos de
negocio con alta reusabilidad. Adems de evaluar y
seleccionar las opciones de implementacin de los
componentes ms importantes de los modelos
identificados. Para esta etapa existen estndares como el
SCA, que marca una fuerte tendencia absorbida por la
mayora de los productos comerciales existentes, pero
tambin otorga un marco conceptual para el ensamblado
y composicin de servicios a nivel de diseo. UML
tambin posee un diagrama que describe los
componentes necesarios para el desarrollo de los
servicios, identificando la relacin entre ellos y los
elementos necesarios en cada componente segn las
necesidades de la arquitectura tecnolgica del proyecto,
el cual responde a la fase de oportunidades y soluciones
del framework TOGAF, y que hace parte de la fase de
infraestructura tecnolgica en la metodologa propuesta,
dentro de la etapa de promulgacin del ciclo de vida de
procesos. Por lo tanto, como resultado de esta etapa se
obtiene el diagrama de componentes de UML
desarrollado por el arquitecto y analista.

2.5 Modelado de servicios

2.7 Implementacin de los componentes

Aqu se definen los servicios y su especificacin y

categora. En esta etapa se incluye la investigacin de
servicios existentes y es el siguiente paso de
refinamiento en el modelado de procesos. Los elementos
de diseo que la guan estn dados por la utilizacin de la
metodologa basada en la notacin de crculos con
cordones [26], junto con la disciplina de diseo
propuesta por Delgado [10], que presenta una lista de
actividades a realizar en este proceso de diseo y
explicitando el objetivo de actividad, su entrada, su salida
y los roles involucrado en la misma. Adems, los servicios
de negocios son los servicios de tareas con lmites
funcionales directamente asociados con una tarea o
proceso de negocio. Es un servicio que tiene menos reuso
potencial y generalmente es responsable de controlar la
composicin de otros servicios, por lo tanto, entre sus
capacidades encapsula la lgica de negocio. Para
mantener su independencia los servicios deben
encapsular la lgica en un contexto, que puede ser una
tarea, entidad de negocio o algn otro agrupamiento [9].

En esta etapa se lleva a cabo el despliegue en la

plataforma elegida del resultado de las etapas anteriores.
En ella no pueden faltar el desarrollo de prototipos, la
retroalimentacin con los actores de las etapas
anteriores, la integracin con los sistemas existentes y
los aspectos no funcionales, tales como robustez y
rendimiento. Adems, describe cada uno de los
componentes existentes en la organizacin y que estn
disponibles para el desarrollo del servicio dentro de los
procesos escogidos en la empresa. Tambin establece
procedimientos para generar el cambio en la nueva
arquitectura, si es necesario, y proporciona monitoreo
continuo para asegurar la arquitectura.

Acompaando a este modelo de procesos se aplican

restricciones y objetos de informacin, que quedan en el
diagrama de clases y por lo tanto resulta conveniente que
se expliciten mediante un formulario genrico que
acompae el diagrama [22]. Este formulario incluir por
menos los siguientes tems:

Formulario para los objetos de informacin:

nombre del objeto de informacin, atributos,
restricciones y clase del dominio que lo representa.

Formulario para las actividades: nombre de la

actividad, origen, agente, pre-condiciones, postcondiciones, caso de uso que lo representa.

Lo ms importante de esta etapa est dado por la

definicin del grado de granularidad de la pieza diseada,
como para que se pueda considerar un servicio con
autonoma y atomicidad. Adems, se obtiene el diagrama
de casos de uso de servicios, el diagrama de secuencia de
los servicios definidos y el diagrama de actividades a
realizar en cada servicio.
2.6 Definicin de los componentes
En esta etapa se definen componentes de software
en trminos de los servicios identificados y su modo de
interaccin (orquestacin). Un componente es una pieza
de software lo suficientemente pequea para crear y
mantener, y lo suficientemente grande para distribucin
y soporte con interfaces estndar para interoperabilidad.
Claramente los web services y su modo de orquestacin
en una arquitectura SOA puede ser una solucin
tecnolgicamente vlida en esta etapa [30, 33].

2.8 Administracin y seguimiento

Esta etapa se vincula con las de promulgacin y
administracin del ciclo de vida de los procesos de
negocio. Los productos obtenidos sern ms fciles de
construir cuanto ms apropiada sea la solucin
tecnolgica adoptada. Los BPMS o bien los sistemas de
gestin de workflow proporcionan las salidas pertinentes
para poder realizar una adecuada lectura de indicadores.
3

Conclusiones

La construccin de soluciones con enfoque de

procesos y de servicios constituye una nueva manera de
abordar los problemas, fomentando ampliamente la
reusabilidad, la agilidad y flexibilidad para absorber los
cambios y la idea de mejora continua de los procesos
como consecuencia de lo anterior.
La descripcin de las etapas del marco
metodolgico propuesto, si bien conlleva una lectura
secuencial, fomenta una permanente realimentacin
entre ellas e incluso desde las etapas ms tempranas,
como la identificacin de requisitos, que tambin se
propone abordar desde un enfoque basado en el diseo
de procesos.
9

Otro objetivo del enfoque es el acortamiento de la

brecha entre el rea de negocios y el de tecnologa. Las
etapas descritas fomentan la conformacin de roles que
son capaces de intercambiar informacin en un lenguaje
comn, y que adems los compromete con el proyecto
como una solucin unificada e integrada a la
organizacin.

[15]

La propuesta metodolgica presentada beneficia la

presentacin de servicios, tanto nuevos como generados
a partir de activos de software, para ser consumidos por
procesos de negocios corporativos. Este modelo ayuda a
las organizaciones a integrarse con sus pares, con sus
clientes y con sus proveedores, ms all de las
tecnologas e infraestructuras subyacentes, pero
haciendo uso del valor que aportan las nuevas tendencias
en computacin.

[16]

Los trabajos futuros que se vislumbran son: 1) la

creacin de una herramienta CASE que utilice el modelo
de integrabilidad propuesto, debido a que en la presente
investigacin fue necesario utilizar diferentes
herramientas que solamente desarrollaron parte de la
documentacin del sistema.

[20]

La metodologa se puede mejorar teniendo en

cuenta los roles y actividades que se realizan utilizando
la integracin con otros frameworks que le d mayores
ventajas, beneficios y madurez en BPM a la organizacin.
Adems de socializarla en las empresas de desarrollo de
software con el fin de que se masifique si utilizacin.

[23]

Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]

[11]

[12]

[13]
[14]

Bennett, N. & Balaba, N. (2007). Transformation to SOA:

Part 1. From business process to service model
architecture. IBM. Online [Jan. 2014].
Oracle. BPEL Tutorial. Online [Dec. 2013].
Fiorano Software (2012). ESB Best Practices. Online [Dec.
2013].
Weske, M. (2012). Business process management:
Concepts, languages, architectures. USA: Springer.
OMG (2012). Service oriented architecture Modeling
Language (SoaML) Specification. Online [Jan. 2014].
The Open Group. Open SOA.
The Open Group (2013). TOGAF 9 Manual. USA: The Open
Group.
Bazn, P.; Giandini, R. & Diaz, F. (2010). Tecnologas para
implementar un marco integrador de SOA y BPM. Informe
Tcnico. UNLP, Buenos Aires.
Robledo, P. (2010). SOA y BPM: La combinacin perfecta
para alinear TI y negocio. Club-BPM.
Delgado, A.; Garca, I. & Ruiz, F. (2009). Desarrollo de
software orientado a servicios basado en procesos de
negocio. Memorias XII Conferencia Iberoamericana de
Ingeniera de Requisitos y Ambientes de Software, pp. 314. Medelln, Colombia.
De la Vara, J. et al. (2009). Modelado de requisitos de datos
para sistemas de informacin basados en procesos de
negocio. Memorias XII Conferencia Iberoamericana de
Ingeniera de Requisitos y Ambientes de Software, pp. 114. Medelln, Colombia.
Diaz J. et tal. (2009). Entornos para usar BPM en
aplicaciones JAVA: Un anlisis comparativo. Memorias XI
Workshop de Investigadores en Ciencias de la
Computacin, pp. 1-5. Universidad Nacional de San Juan,
Argentina.
OMG. Unified Modeling Language, version 2.2. The OMG.
Errecalde, G. & Marcos, C. (2009). Una ontologa de
aspectos para la ingeniera de requisitos. Memorias XII

[17]
[18]
[19]

[21]
[22]

[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]

[36]

[37]
[38]
[39]

Conferencia Iberoamericana de Ingeniera de Requisitos y

Ambientes de Software, pp. 239-252. Medelln, Colombia.
Bocanegra J.; Pea J. & Ruiz, A. (2009). Modelado de
negocio interorganizacional: Una aproximacin para la
trazabilidad entre objetivos, modelos organizacionales y
procesos de negocio. Memorias XII Conferencia
Iberoamericana de Ingeniera de Requisitos y Ambientes
de Software, pp. 1-14. Medelln, Colombia.
Kerrigan, M. et al. (2009). SemanticWeb Service
engineering for semantic business process management.
Proceedings 4th International Workshop on Semantic
Business Process Management, pp. 25-30. Crete, Greece.
Bazan, P. (2009). Un modelo de integrabilidad con SOA y
BPM. Tesis Maestra. Universidad Nacional La Plata.
Arsanjani, A. et al. (2008). SOMA: A method for developing
service-oriented solutions. IBM Systems Journal 47(3),
pp. 377-396.
Drake, J. (2008). Proceso de desarrollo de aplicaciones de
software. Computadores y tiempo real.
Garimella, K.; Lees, M. & Williams, B. (2008). Introduccin
a BPM. USA: Wiley.
Oracle (2008). Business process management, serviceoriented architecture, and web 2.0: Business
transformation or train wreck? An Oracle White Paper.
OMG (2009). Service oriented architecture modeling
language (SoaML). OMG Adopted Specification.
Sheina, D. (2008). Realising the promise of SOA and BPM.
Ovum.
Weske, M. (2008). Business process management:
Concepts, languages, architectures. USA: Springer.
Delgado, A. (2007). Desarrollo de software con enfoque en
el negocio. Memorias XII Jornadas de Ingeniera del
Software y Bases de Datos, pp. 1-8. Zaragoza, Espaa.
Erl, T. (2007). SOA Principles of Service Design. New York:
Prentice Hall.
Juric, M. et al. (2007). SOA Approach to Integration XML,
Web services, ESB, and BPEL in real-world SOA projects.
Boston: Packt Publishing.
Fortuna M. (2008). Un modelo integrado de requisitos con
casos de uso. PhD Tesis. Universidade Federal do Rio.
Hurtado, D. (2007). Tesis metodologa para el desarrollo
de sistemas basados en objetos de aprendizaje. Tesis
Maestra. Universidad del Norte.
McKorkle, S. (2007). Model-Driven SOA - achieve higher
productivity gains throughout the design process. USA:
Telelogic.
Oracle (2007). SOA Governance: Framework and Best
Practices. An Oracle Whitepapaer.
Brunswick, J. (2008). Extending the business value SOA
through business process management. Oracle.
NewComer, E. & Lomow, G. (2005). Understanding SOA
with web services. USA: Addison-Wesley.
Lau, D. & Mylopoulos, J. (2004). Designing web services
with tropos. Proceedings IEEE International Conference
on Web Services, pp. 306-313. San Diego, USA.
Aiello, M. & Giorgini, P. (2004). Applying the tropos
methodology for analysing web services requeriments
and reasoning about quality of services. Upgrade V(4), pp.
20-26.
Guo, L. et al. (2004). Mapping a business process model to
a semantic web service model. Proceedings IEEE
International Conference on Web Services, pp. 746-749.
San Diego, USA.
Giorgetti, G. (2003). Transformando - Prcticas de cambio
en empresas argentinas. Buenos Aires: Editorial Eudeba.
SCAMPI (2011). Appraisal Requirements for CMMI v1.1.
Technical Report CMU/SEI-2011-TR-006. Software
Engineering Institute.
Morgenthal, J. (2001). Enterprise application integration
with XML and Java. USA: Prentice Hall.

10