Está en la página 1de 158

TABLA DE CONTENIDO

12

1
2
2.1
3
4
4.1
4.2
5
5.1
5.1.1
5.1.2
5.2
5.3
5.3.1
5.3.2
5.3.3
5.3.3.1
5.3.3.2
5.3.3.3
5.3.3.4
5.3.3.5
5.3.4
5.3.4.1
5.3.4.2
5.3.4.3
5.3.4.4
5.3.4.5
5.3.4.6
5.3.5
5.3.5.1
5.3.5.2
5.3.5.3
5.3.5.4
5.3.6
5.3.6.1
5.3.6.2
5.3.6.3
5.4

Resumen
Abstract
Introduccin
Ttulo
Planteamiento del problema
Formulacin del problema
JUSTIFICACIN
OBJETIVOS
Objetivo general
Objetivos especficos
MARCO DE REFERENCIA
Antecedentes cientficos y tecnolgicos
Antecedente nacional
Antecedente internacional
Resea histrica
BASES TERICAS
Proceso de desarrollo de software
Metodologa de desarrollo de software
Metodologas tradicionales
Cascada
Construccin de prototipos
Incremental
Espiral
Basado en componentes
Metodologas giles
Programacin extrema-xp
Scrum
Crystal
Dynamic systems development method (DSDM)
Adaptive software development (ASD)
Feature driven development (FDD)
Modelado de Procesos de Negocio (BPM)
Generalidades
Aplicaciones de BPM
Beneficios y ventajas BPM
Dimensiones articuladoras de procesos en la implementacin
De la tecnologa BPM
Arquitectura Orientada a Servicios (SOA)
Generalidades
Principios de los servicios
Beneficios
MARCO CONCEPTUAL
13

15
16
17
18
19
20
21
23
23
23
24
24
24
24
25
29
29
29
29
30
33
34
35
37
38
39
40
41
42
44
45
46
46
47
50
52
54
54
60
62
64

RESUMEN

El objetivo principal de este proyecto es definir una metodologa para el desarrollo


de aplicaciones de software integrando dos arquitecturas de software: Gestin de
procesos de negocio (BPM) y Arquitectura Orientada a Servicios (SOA). Esta
metodologa se plantea a raz de la necesidad de mejorar la capacidad de los
sistemas para alcanzar nuevos requerimientos, realizar cambios rpidos en sus
procesos de negocio, agregar nuevas interfaces, remplazar viejas aplicaciones
con nuevas, optimizar los procesos de negocio. SOA permite un mejor
alineamiento de las tecnologas de la informacin con las necesidades del
negocio, permitiendo a empleados, clientes y socios comerciales responder de
forma ms rpida y adaptarse adecuadamente a las presiones del mercado. BPM
por su parte presenta una visin sistmica de la organizacin y sus procesos, lo
que facilita y mejora su direccin y gobernabilidad. El desarrollo de la presente
metodologa transita por las etapas tradicionales del ciclo de vida, iniciando con la
recopilacin

de

informacin,

anlisis,

diseo,

construccin,

pruebas

implementacin, incorporando en cada fase tcnicas y herramientas que faciliten


el modelado conceptual. Se analiza un caso de estudio del proceso citas mdicas
de la Institucin Prestadora de Servicios de salud de la Universidad Popular del
Cesar, aplicando las fases de la metodologa propuesta, para as demostrar las
ventajas que se obtienen integrando SOA y BPM.

14

ABSTRACT

The main objective of this project is to define a methodology for the development of
software applications integrating two software architectures: business process
management (BPM) and Service Oriented Architecture (SOA). This approach
arises from the need to improve the capacity of systems to meet new
requirements, make rapid changes in their business processes, add new
interfaces, replace old applications with new, optimize business processes. SOA
allows better alignment of information technology with business need, allowing
employees, customers and business partners more quickly respond and adapt
appropriately to market pressures. BPM in turn presents a systemic view of the
organization and its processes, which facilitates and improves its management and
governance. The development of this methodology goes through the traditional
stages of the life cycle, starting with information gathering, analysis, design,
construction, testing and implementation, at every stage incorporating techniques
and tools that facilitate conceptual modeling. We analyze a case study of the
appointments process of the institution Health Services Provider of the Popular
University of Cesar, using the phases of the proposed methodology in order to
demonstrate the advantages gained by integrating SOA and BPM.

INTRODUCCIN
15

La correcta administracin de la informacin a travs de Tecnologas de


Informacin es imprescindible para el xito del negocio y la obtencin de ventajas
competitivas. Las organizaciones automatizan sus procesos con el objetivo de
responder oportunamente a las necesidades y cambios del

mercado. La

implementacin de las herramientas informticas y tecnolgicas crean nuevas


formas de trabajo, permitiendo el rediseo creativo de la organizacin,
optimizando la utilizacin de los recursos, mejorando la calidad del servicio,
creando un ambiente de trabajo propicio para que el empleado se desempee con
la calidad que el usuario demanda y a la vez encuentre en su trabajo las mejores
condiciones posibles.

El principal objetivo de las tecnologas de informacin es el aprovechamiento


estratgico de la informacin. A partir de esto, surge la idea de disear una
metodologa para el desarrollo de aplicaciones integrando dos arquitecturas de
software: Arquitectura Orientada a Servicios SOA y Gestin de Procesos de
Negocio BPM, las cuales permiten el alineamiento de los objetivos del negocio con
las tecnologas de la informacin.

BPM y SOA son complementarios. BPM se centra en analizar los objetivos


estratgicos para crear procesos de negocios bien definidos y optimizados,
monitorizando su rendimiento para una mejora continua. Los procesos de negocio
se modelizan con tareas de proceso que se implantan normalmente como
servicios. La dificultad del BPM radica en la complejidad de las diferentes
plataformas tecnolgicas, los diferentes tipos de aplicaciones existentes y los
distintos protocolos de comunicacin, es decir, la problemtica de la integracin de
sistemas y aplicaciones, solucin aportada por SOA.

1. TITULO
16

METODOLOGA DE DESARROLLO DE APLICACIONES DE SOFTWARE


INTEGRANDO LAS ARQUITECTURAS ORIENTADA A SERVICIOS (SOA) Y
GESTIN DE PROCESOS DE NEGOCIOS (BPM), APLICADO AL PROCESO
CITAS MEDICAS DE LA INSTITUCION PRESTADORA DE SERVICIOS DE
SALUD (IPS) DE LA UNIVERSIDAD POPULAR DEL CESAR.

2.

PLANTEAMIENTO Y FORMULACIN DEL PROBLEMA

En el comienzo de la era de la ciencia, la tecnologa y la computacin, el desafo


era desarrollar sistemas que automatizaran actividades que se llevaban a cabo
manualmente. En la actualidad, ya han surgido nuevas necesidades entre ellas la
17

tarea de mejorar la capacidad de los sistemas para alcanzar nuevos


requerimientos: agregar nuevas interfaces, combinar mltiples fuentes de datos en
una sola, interactuar con dispositivos mviles y remplazar viejas aplicaciones con
nuevas.
Hoy en da, el problema ms crtico en cualquier tipo de empresa es realizar
cambios rpidos en sus procesos de negocio. Anteriormente los sistemas,
software, bases de datos, eran inflexibles, se resistan al cambio, por lo que las
organizaciones no realizaban mejoras para competir en el entorno global, sino
para sobrevivir.
La facultad para responder de manera rpida ante los cambios y optimizar los
procesos de negocio es un elemento clave para la competitividad y el desarrollo
de las organizaciones, dicha agilidad depende directamente de la flexibilidad o no
de sus entornos TI (Tecnologa de Informacin), lo cual afecta la actividad del
negocio.
La Arquitectura Orientada a Servicios (SOA, Service Oriented Architecture) es una
filosofa de diseo que permite un mejor alineamiento de las Tecnologas de
Informacin (TI) con las necesidades de negocio, permitiendo a empleados,
clientes y socios comerciales responder de forma ms rpida y adaptarse
adecuadamente a las presiones del mercado.
La arquitectura Gestin de procesos de negocios

(BPM, Business Process

Management) es una disciplina de gestin de procesos dirigida mediante


Tecnologas de Informacin (TI), capaz de mejorar la agilidad organizativa y la
capacidad de las personas para introducir cambios en los procesos e innovar de
forma rpida. Por consiguiente, BPM permite el alineamiento de las tecnologas de
informacin con las actividades de negocio, tanto en el seno de la propia
organizacin como fuera de ella, con socios comerciales, proveedores y clientes.

18

Se requiere del modelado de procesos de negocio, y de los beneficios que brinda


SOA, como posible solucin a la inflexibilidad de los procesos de negocio de las
organizaciones. A su vez se busca la reutilizacin de cdigo, la mejora continua de
los procesos y la especificacin de requerimientos, comprometiendo todo el ciclo
de vida de los proyectos e integrando funcionalidades nuevas y existentes.

2.1

Formulacin del Problema

De qu forma contribuir esta metodologa basada en las arquitecturas Orientada


a Servicios (SOA) y Gestin de Procesos de Negocios (BPM) en el desarrollo de
aplicaciones de software?

3. JUSTIFICACIN
El presente proyecto pretende crear una metodologa de desarrollo de
aplicaciones, basada en la ingeniera de software, integrando la arquitectura BPM
(Gestin de Procesos de Negocios) con SOA (Arquitectura Orientada a Servicios),
19

con el propsito de darle solucin a la inflexibilidad de los procesos de negocio de


las organizaciones, en este caso se aplicar a un proceso de la Institucin
Prestadora de Servicios de salud (IPS) de la Universidad Popular del Cesar.
El enfoque que se busca con esta metodologa, est encaminado al diseo de
procesos y servicios, promoviendo la reutilizacin de cdigo, la mejora continua de
los procesos y la especificacin de requerimientos, comprometiendo todo el ciclo
de vida de los proyectos e integrando funcionalidades nuevas y existentes. El
marco metodolgico propuesto se orienta a servicios y a procesos de negocio,
gestionado por tecnologas SOA Y BPM.
SOA es una solucin tecnolgica. Existe un punto de convergencia entre el
negocio y la tecnologa, este punto es la internet y asociado a las tecnologas
actuales, han dado como resultado arquitecturas, en donde, la tecnologa no es la
respuesta a la necesidad del negocio, la integracin de la misma debe ser
alineada bajo los objetivos del negocio en cualquier organizacin o empresa.
Esta metodloga incorpora conceptos de nuevos paradigmas, que buscan el
alineamiento del negocio con la tecnologa a travs de la flexibilidad y agilidad,
permitiendo mayor colaboracin e integracin con entidades externas o internas,
reutilizando componentes tecnolgicos que faciliten la gestin de la tecnologa de
informacin.
El desarrollo de la presente metodologa transita por las etapas tradicionales del
ciclo de vida, iniciando con la recopilacin de informacin, anlisis, diseo,
construccin, pruebas e implementacin, incorporando en cada fase tcnicas y
herramientas que faciliten el modelado conceptual hasta llegar al modelo fsico de
la arquitectura.
Con esta investigacin se pretende desarrollar una metodologa basada

en

ingeniera de software, integrando las arquitecturas orientada a servicios (SOA) y


20

gestin de procesos de negocios (BPM), para contribuir a la agilizacin y


flexibilidad del desarrollo de software en el anlisis de procesos de negocios, y
aplicarla a un proceso de la Institucin Prestadora de Servicios de Salud (IPS) de
la Universidad Popular del Cesar.

4. OBJETIVOS
4.1 Objetivo general
Definir una metodologa de desarrollo de aplicaciones de software integrando las
arquitecturas orientada a servicios (SOA) y gestin de procesos de negocios
21

(BPM), y aplicarla a un proceso de la Institucin Prestadora de Servicios De Salud


(IPS) de la Universidad Popular del Cesar.

4.2 Objetivos especficos

Realizar un estudio detallado de la arquitectura orientada a servicios (SOA,


Service Oriented Architecture) y arquitectura gestin de procesos de
negocios (BPM, Business Process Management).

Proponer un marco metodolgico para el desarrollo de aplicaciones


integrando BPM (Gestin de procesos de negocios) y SOA (Arquitectura
orientada a servicios), detallando las fases, actividades, roles y artefactos.

Aplicar la metodologa planteada a un proceso de la Institucin Prestadora


de Servicios de Salud (IPS) de la Universidad Popular del Cesar.

5 MARCO DE REFERENCIA
5.1 ANTECEDENTES CIENTIFICOS Y TECNOLOGICOS
5.1.1 Antecedente Nacional:

22

A nivel nacional se han realizado investigaciones similares a este proyecto, han


integrado las arquitecturas Gestin de procesos de negocio BPM con Arquitectura
orientada a servicios.
Jaime Orlando Moreno y Jorge Humberto Arias, en el ao 2005 desarrollaron el
Caso de Estudio: Proyecto SIREP2 Estructura, rol e importancia de un ESB en un
proyecto Empresarial centrado en procesos de negocio (BPM) y soportados en
reusabilidad de Servicios (SOA), con el cual lograron transformar el modelo de
gestin de la Cmara de Comercio de Bogot; de ser una organizacin que se
gestionaba por funciones, pas a ser una organizacin orientada a la gestin por
procesos.
5.1.2 Antecedente Internacional
Patricia Bazn, desarroll en el ao 2009 la tesis Un modelo de integrabilidad con
SOA y BPM, con el que obtuvo el ttulo de Maestra en Redes de Datos de la
Universidad de la Plata en Argentina. Con la metodologa desarrollada plante un
modelo de Ventanilla nica Empresarial para una organizacin pblica, que
permitiera gestionar el asesoramiento, registro de la actividad econmica, permiso
de funcionamiento y fiscalizacin de empresas comerciales, industriales y de
servicios, con el objeto de promover el desarrollo econmico local en un marco de
legalidad y formalidad a travs de la facilitacin y simplificacin de trmites
empresariales y del fortalecimiento del poder de contralor de la regin.

Andrea Delgado Caleverie, present en el ao 2007 Tesis de Maestra en


Informtica en la Universidad de la Repblica de Montevideo. Su proyecto
denominado Metodologa de desarrollo para aplicaciones con enfoque SOA
(Service Oriented Architecture), dedica una seccin especial a la integracin de
las dos arquitecturas de software: Gestin de Procesos de Negocio BPM y
Arquitectura Orientada a Servicios SOA. La metodologa fue probada en el marco
23

del curso Proyecto de Ingeniera de Software para la construccin de una


aplicacin de Help-Desk para el proyecto Link-all del InCo, y ajustada y mejorada
en base a los resultados obtenidos.
La metodologa de Delgado cubre nicamente el modelado de procesos e
identificacin de servicios, no considerando ni la especificacin de requisitos ni la
etapa de implementacin de los servicios.
5.2 RESEA HISTRICA
Un lenguaje de programacin es una serie de comandos que permiten codificar
instrucciones de manera que sean entendidas y ejecutadas por una computadora.
Estructurados vs no estructurados: A partir de C el gran lenguaje, y Pascal; se
dividen los lenguajes en estructurados (aquellos que en su codificacin usaban
una estructura jerrquica de procedimientos y funciones), en contraposicin a los
lenguajes no estructurados como el Basic cuya codificacin se basaba en lneas
de programacin, permitiendo al programador "saltar" de una lnea de instruccin
a otra, haciendo que el cdigo fuera algunas veces inentendible y muy difcil de
mantener (modificar) porque no segua una estructura.
Basic de todos modos evolucion, primero con el ahora primitivo GW Basic,
teniendo su mxima expresin con el Quick Basic del D.O.S. 5.0, el cual ya inclua
algunos conceptos ms de avanzada a lo que eran sus contrapartes
estructuradas.
1985-1990 y el nacimiento del Xbase: dBase fue el gran desarrollo para base de
datos de los aos 80. Bajo la batuta de la firma AshtonTate, empresa que dio
origen a un intrprete de bases de datos muy sencillos y poderosos: dBbase II.
Luego vinieron el dBase III+ que hizo furor, y la etapa de la decadencia para
dBase: el dBase IV, ya bajo la direccin de Borland.
24

.
Los primeros aos, 1990-1995: Las bases de datos relacionales, se destaca la
evolucin de los lenguajes de programacin. En forma profesional y aplicaciones
de alto nivel, el lenguaje preferido era C.
Para el aprendizaje se usaba Pascal, que permita inculcar el concepto de
programacin estructurada.
Tambin Basic, era un lenguaje utilizado, no en pocas ocasiones en forma
profesional, aunque con ciertas limitaciones; su reinado estuvo en los aos 80.
En lenguaje C, fue y todava es el gran artfice de la computacin actual.
1995-2000: La orientacin a objetos: A medida que los aos van pasando el
concepto de Bases relacionales empieza a decaer relativamente, surge entonces
una variante que se aplica a todos los lenguajes: La orientacin a objetos. Ya no
solo se habla de programacin estructurada, sino que los mdulos de
programacin son vistos como objetos, las estructuras representan objetos y/o
funciones que se adaptan en forma general a procesos especficos es la
maximizacin de la programacin modular.
El modelo de objetos engloba los conceptos de encapsulacin, herencia y
polimorfismo, el cual se aplica a los datos y al tipo de bases de datos que
almacena la informacin. La orientacin a objetos significa la agrupacin de
entidades de datos de forma global, de tal manera que puedan ser interpretados
de una forma comn por una misma estructura de programacin.
El fin de los lenguajes D.O.S.: Windows 95: Windows 95 marca el comienzo del fin
de la programacin D.O.S. y por lo tanto de los lenguajes basados en este. Este
proceso no fue enrgico, todava hoy (2000), estamos viviendo esta etapa.
Todava hay numerosos y excelentes sistemas desarrollados bajo entorno D.O.S.
ejecutndose pero cada vez son los menos. Los nicos "sobrevivientes" al menos

25

en esencia son Visual Fox (Microsoft), Visual Basic (Microsoft), Delphi (Borland) y
Visual C (Microsoft).
2000 y ms all: lenguajes visuales, Con la llegada de Windows todo es Visual,
todo es iconos, todo es botones, todo es Ventanas. Las incursiones cada vez ms
innovadoras de Microsoft parecen imponer a la web como el centro de desarrollo
de aplicaciones: Microsoft .NET.
Una visin a la WEB y al futuro: HTML, Perl, PHP, Pithon, Java y otros: Internet ha
sido el disparador de nuevos lenguajes tales como el HTML que es el lenguaje de
programacin de las pginas WEB para hipertexto. El mismo constituye una
codificacin bastante simple, basada en marcadores (TAGs). Por otra parte Java,
bajo la direccin de SUN, constituye la idea de la programacin abierta y universal
para las aplicaciones de escritorio, pero todava los estndares visuales (C, Basic
y Delphi), son demasiado poderosos como para desplazarlos, a pesar de que Java
promete tambin ser un lenguaje de excelentes prestaciones.
Las nuevas tecnologas WEB inundan el mercado: PHP, ASP, XML, DHTML, lo
cual enriquecen la forma de manejar la informacin y su presentacin al usuario
final.
SOA no es un concepto nuevo. Los ingenieros de software entendieron sus
principios a mediados de los 80 cuando llegaron al mercado la computacin
distribuida y las llamadas a procedimientos remotos. Gartner describe la
arquitectura orientada a servicios por primera vez en 1996, pero el inters en la
misma se vio aumentado por la aparicin de una tendencia importante del
mercado: los servicios web. En 2003, SOA entra al fin por completo en el mundo
de las TI empresariales, a travs de los servicios web.
Los primeros esbozos de realizar reingeniera de procesos fueron un aporte
importante en el sentido de que se basaban en la idea de la mejora de los mismos,
26

no dejaban de enfocarse en la automatizacin de la tarea y no en la optimizacin


de la misma. Adems tenan la particularidad de que los procesos se gestionaban
por herramientas construidas ad-hoc.
La evolucin natural fue entonces hacia la definicin de una estrategia para
gestionar y mejorar el rendimiento de un negocio a travs de la optimizacin
contina de sus procesos dentro de un ciclo de modelado, ejecucin y medida.
BPM es tal estrategia o disciplina. BPMS (Sistemas o Suite para BPM) proveen un
conjunto de herramientas integradas que soportan el diseo, media, monitoreo,
anlisis y mejoras continuas al proceso de negocio.
BPM es el complemento natural de SOA, y un mecanismo a travs del cual una
organizacin puede aplicar SOA a sus procesos de negocio. BPM aporta valor en
el mundo real mientras que SOA facilita la integracin de soluciones y provee
tecnologas para gestionar los componentes tcnicos de un proceso de negocio.
Los analistas de procesos de negocio usan BPM para crear y optimizar modelos
de procesos de negocio, encontrar servicios de negocio que implementen las
actividades modeladas, volcndolos en un BPMS. Lo deseable es que el resultado
de esta produccin culmine en procesos desplegados como servicios, registrados
en un repositorio y expuestos a los consumidores.
El modelo de integracin que se presenta y que surge de un anlisis del estado
del arte en trminos de integracin de aplicaciones, define un conjunto de
componentes tanto tecnolgicos como de negocios, que dan una visin unificada e
integradora de la solucin alcanzada.
5.3 BASES TEORICAS

5.3.1 PROCESO DE DESARROLLO DE SOFTWARE

27

Es un conjunto de actividades y resultados asociados que producen un producto


de software. Existen cuatro actividades fundamentales de procesos que son
comunes para todos los procesos del software. Estas actividades son:
1. Especificacin del software donde los clientes e ingenieros definen el software a
producir y las restricciones sobre su operacin.
2. Desarrollo del software donde el software se disea y programa.
3. Validacin del software donde el software se valida que es lo que el cliente
requiere.
4. Evolucin del software donde el software se modifica para adaptarlos a los
cambios requeridos por el cliente y el mercado.
Un proceso de desarrollo de software tiene como propsito la produccin eficaz y
eficiente de un producto software que rena los requisitos del cliente.

Figura Proceso de desarrollo de software

5.3.2 METODOLOGA DE DESARROLLO DE SOFTWARE1

1 Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

28

En ingeniera de software es un marco de trabajo usado para estructurar, planificar


y controlar el proceso de desarrollo en sistemas de informacin. Se refiere a
un framework que es usado para estructurar, planear y controlar el proceso de
desarrollo en sistemas de informacin.
El marco metodolgico desarrollado en este proyecto est basado dos puntos: Por
un lado, el carcter ortogonal de los servicios respecto de los procesos y
viceversa; por el otro, la convivencia de un modelo de ciclo de vida iterativo con
uno en cascada, correspondientes a la gestin de procesos de negocio y los
servicios respectivamente, que comparten caractersticas comunes. La nocin de
ortogonalidad de los procesos respecto de los servicios se fundamenta en el
hecho de que los procesos atraviesan las reas funcionales de la organizacin y
alcanzan el objetivo para el que fueron definidos, como una coordinacin de las
funcionalidades que cada rea resuelve. Los servicios, por su parte, son
elementos que se comprenden por la utilidad que brindan y, por lo tanto, no
pueden apartarse del problema que resuelven. Los servicios resuelven
funcionalidades concretas de cada unidad funcional y cuando esta coordinacin se
realiza dentro de una misma organizacin, se habla de orquestacin y cuando
trasciende la organizacin para integrarse con otra, estamos en presencia de
coreografa.
El ciclo de vida de los procesos de negocio se caracteriza porque cada etapa es
recorrida en forma cclica, sin tener un orden temporal, aunque s un orden lgico.
Este ciclo puede recorrerse entrando en cualquier fase, pero una vez dentro del
ciclo, se debe continuar con la prxima etapa, sin contar necesariamente con una
condicin de finalizacin. Es muy similar a un ciclo de vida en espiral.
Por otro lado, el ciclo de vida de los servicios como el del software, en general
tiende a tener un comportamiento en cascada. Si bien las nuevas metodologas de
desarrollo de software, incluso giles, han marcado una evolucin en la manera de
construir software, su resistencia a la absorcin de cambios sigue siendo una
29

caracterstica. Sin ir ms lejos, es difcil entrar al ciclo en cualquier etapa por la


sencilla razn de que dicho ciclo no est girando en forma permanente.
5.3.3 METODOLOGAS TRADICIONALES
Las Metodologas tradicionales en el desarrollo de software dividen el proceso de
desarrollo en etapas, de una manera secuencial, son ms un resultado de una
urgencia por dotar al desarrollo de software de orden para poder completar los
objetivos deseados.
Este tipo de metodologas proveen de un alto grado de ordenamiento, de disciplina
pero son resistentes al cambio, los cambios son vistos con recelo y son
rechazados, se pierde entre tanta disciplina el objetivo del proyecto, el hacer
software til, importan ms los procesos que las personas, el cliente puede llegar
a ser relegado.
Estas metodologas tradicionales imponen una disciplina de trabajo sobre el
proceso de desarrollo del software, con el fin de conseguir un software ms
eficiente. Para ello, se hace nfasis en la planificacin total de todo el trabajo a
realizar y una vez que est todo detallado, comienza el ciclo de desarrollo del
producto software. Se centran especialmente en el control del proceso, mediante
una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones
para el modelado y documentacin detallada. Adems, las metodologas
tradicionales no se adaptan adecuadamente a los cambios, por lo que no son
mtodos adecuados cuando se trabaja en un entorno, donde los requisitos no
pueden predecirse o bien pueden variar.
5.3.3.1 Cascada2

2 Ciclo de vida del software, www.carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc

30

Enfoque metodolgico que ordena rigurosamente las etapas del proceso para el
desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la
finalizacin de la etapa anterior.
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo afectado,
aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la
metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases ms avanzadas de un proyecto tal como se muestra en la
Figura 1.
Figura 1. Cascada

Inge

Fuente: Ciclo de vida del software, www.carolina.terna.net/ingsw2/Datos/CascadaModeloV.doc


Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de
un sistema mayor el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algn subconjunto de estos requisitos al
software.
Anlisis de los requisitos del software: el proceso de recopilacin de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
31

software (Analistas) debe comprender el mbito de la informacin del software, as


como la funcin, el rendimiento y las interfaces requeridas.
Diseo: el diseo del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los
requisitos en una representacin del software con la calidad requerida antes de
que comience la codificacin.

Codificacin: el diseo debe traducirse en una forma legible para la mquina. El


paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera
detallada la codificacin puede realizarse mecnicamente.
Prueba: una vez que se ha generado el cdigo comienza la prueba del programa.
La prueba se centra en la lgica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.
Mantenimiento: el software sufrir cambios despus de que se entrega al cliente.
Los cambios ocurrirn en el caso de que hayan encontrado errores, a que el
software deba adaptarse a cambios del entorno externo (sistema operativo o
dispositivos perifricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.
Desventajas:

Los proyectos reales raramente siguen el flujo secuencial que propone el


modelo, siempre hay iteraciones y se crean problemas en la aplicacin del
paradigma.

32

Normalmente, es difcil para el cliente establecer explcitamente al principio


todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.

El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estar disponible una versin operativa del programa. Un error
importante no detectado hasta que el programa est funcionando puede ser
desastroso.

La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
5.3.3.2 Construccin De Prototipos3
La figura 2 muestra un patrn de construccin de prototipos. Un prototipo es una
versin preliminar de un sistema con fines de demostracin o evaluacin de
ciertos requisitos. El uso de los prototipos implica un mtodo menos formal de
desarrollo, donde su fundamento es hacer comprender las especificaciones del
producto final.

El prototipo debe ser construido en poco tiempo, usando los programas


adecuados y no se debe utilizar muchos recursos.

El diseo rpido se centra en una representacin de aquellos aspectos del


software que sern visibles para el cliente o el usuario final. Este diseo conduce a
la construccin de un prototipo, el cual es evaluado por el cliente para una
retroalimentacin; gracias a sta se refinan los requisitos del software que se
desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las
3 Ciclo de vida del software, www.carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc

33

necesidades del cliente. Esto permite que al mismo tiempo el desarrollador


entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Un prototipo usado durante un desarrollo software de estas caractersticas puede


formar parte del producto final o bien puede ser desechado. Las fases que se dan
en la construccin de los distintos prototipos de un desarrollo son:

1. Identificacin de Requisitos que debe de cumplir el prototipo.


2. Disear e implementar el prototipo.
3. Utilizar el prototipo con el fin de probar que cumple los requisitos para los que
fue diseado.
4. Revisar y mejorar el prototipo.
Figura 2. Construccin de prototipos

34

Fuente: Ciclo de vida del software, www.carolina.terna.net/ingsw2/Datos/CascadaModeloV.doc

5.3.3.3 Incremental
Definido por primera vez por Barry Boehm en 1986, combina elementos del
modelo en cascada aplicado en forma iterativa, como se muestra en la figura
aplica secuencias lineales escalonada conforme avanza el tiempo en el
calendario. Cada secuencia lineal produce incrementos del software. 4
En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo
y Prueba. Sin embargo, para la produccin del Software, se usa el principio de
trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin.
Con esto se mantiene al cliente en constante contacto con los resultados
obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha
4 Roger, Pressman. Ingeniera del software, 6ta ed. McGraw Hill. 2006, Pags 48, 77, 767.

35

elementos al final de cada incremento a fin de que el software se adapte mejor a


sus necesidades reales. El proceso se repite hasta que se elabore el producto
completo como se muestra en la figura 3.
Figura.3 Incremental

Fuente: Ciclo de vida del software, www.eici.ucm.cl/Academicos/R.../


ModelosProcesoSoftware.pdf
5.3.3.4 Espiral
Conjuga la naturaleza iterativa de la construccin de prototipos con los aspectos
controlados y sistemticos del modelo en cascada.5
Caractersticas:

Trata de mejorar los ciclos de vida clsicos y prototipos.

Permite acomodar otros modelos

Incorpora objetivos de calidad y gestin de riesgos

Elimina errores y alternativas no atractivas al comienzo

Permite iteraciones, vuelta atrs y finalizaciones rpidas

Cada ciclo empieza identificando:

5 Roger, Pressman. Ingeniera del software, 6ta ed. McGraw Hill. 2006, Pags 48, 77, 767.

36

-Los objetivos de la porcin correspondiente


-Las alternativas
-Restricciones

Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y
el plan para el siguiente.
Figura 4. Espiral

Fuente: Desarrollo y Gestin de Proyectos Informticos. Steve McConnell, McGraw Hill.

Cada ciclo de desarrollo se divide en cuatro fases:

1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones


del proceso y del producto. Se realiza un diseo detallado del plan administrativo.
Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de
estos.

37

2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada


riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de
requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la
evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales,
evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente
fase del proyecto.
5.3.3.5 Basado en Componentes
Figura 5. Basado en Componentes

Fuente: Sommerville, Ian. Ingenieria de software, 7ma ed. Prentice Hall, 2005.

El desarrollo de software basado en componentes (Figura 5) consiste en construir


sistemas mediante ensamblado de mdulos de software reutilizables
(Componentes), que hayan sido desarrollados previamente por terceros con
independencia de la aplicacin en la que vayan a ser utilizados. Emergi como
una importante solucin al problema del desarrollo de sistemas grandes y
complejos.
5.3.4 METODOLOGAS AGILES

38

En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino


gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17
expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de metodologas de software (Figura 6). Su objetivo fue esbozar los
valores y principios que deberan permitir a los equipos desarrollar software
rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas. 6
Figura 6. Esquema general de una metodologa gil para desarrollo de software

Fuente: Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el
Desarrollo de Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

5.3.4.1 Programacin Extrema - Xp


La programacin extrema XP (Figura 7) es una metodologa de desarrollo de la
ingeniera de software formulada por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el ms
6 Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el Desarrollo de Software,
http://www.willydev.net/descargas/prev/TodoAgil.pdf.

39

destacado de los procesos giles de desarrollo de software. Al igual que stos, la


programacin

extrema

se

diferencia

de

las

metodologas

tradicionales

principalmente en que pone ms nfasis en la adaptabilidad que en la


previsibilidad. Ser capaz de adaptarse a los cambios de requisitos en cualquier
punto de la vida del proyecto es una aproximacin mejor y ms realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos
despus en controlar los cambios.
Se puede considerar la programacin extrema como la adopcin de las mejores
metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. 7
El ciclo de vida de XP consiste en cinco fases: Exploracin, planificacin, iteracin,
implementacin y prueba de aceptacin. Los elementos que interactan dentro del
ciclo de vida son: Roles, prcticas y productos. 8
Figura 7. Programacin Extrema - Xp

Planificacin
Planificacin

XP
XP
(Xtreme
(Xtreme
Programing)
Programing)

Diseo
Diseo

Codificacion
Codificacion

Pruebas
Pruebas

T
est de
de
Test
aceptacin
aceptacin

Fuente: Elaboracin propia


7 Amaro Caldern, Sarah Dmaris, Valverde Rebaza. Jorge Carlos, Metodologas agiles.
http://www.seccperu.org/files/Metodologias%20Agiles.pdf.

8 Parada Gelvez Hugo Alexander, Contribucin a la gestin de los procesos de pruebas de software y servicios.
http://oa.upm.es/4019/1/ HUGO_ALEXER_PARADA_GELVEZ.pdf, enero de 2011

40

5.3.4.2 Scrum9
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prcticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su
seleccin tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est
especialmente indicado para proyectos en entornos complejos, donde se necesita
obtener resultados pronto, donde los requisitos son cambiantes o poco definidos,
donde la innovacin, la competitividad, la flexibilidad y la productividad son
fundamentales.
Scrum tambin se utiliza para resolver situaciones en que no se est entregando
al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reaccin ante la competencia, cuando la moral de los equipos es baja y la rotacin
alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o
cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de
producto.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es
definida por el equipo), el equipo crea un incremento de software potencialmente
entregable (utilizable), ellos determina la cantidad de trabajo que pueden
comprometerse a completar durante el siguiente sprint. Scrum permite la creacin
de equipos auto-organizados impulsando la co-localizacin de todos los miembros
del equipo, y la comunicacin verbal entre todos los miembros y disciplinas
involucrados en el proyecto.

9 Amaro Caldern, Sarah Dmaris, Valverde Rebaza. Jorge Carlos, Metodologas agiles.
http://www.seccperu.org/files/Metodologias%20Agiles.pdf

41

Figura 8. Scrum

Fuente: Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el
Desarrollo de Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

5.3.4.3 Crystal
Se trata de un

conjunto de metodologas para el desarrollo de software

caracterizadas por estar centradas en las personas que componen el equipo y la


reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas
por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo
de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de
desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus
habilidades y destrezas, as como tener polticas de trabajo en equipo definidas.
Estas polticas dependern del tamao del equipo, establecindose una
42

clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal


Orange (25 a 50 miembros).10
La familia Crystal dispone un cdigo de color para marcar la complejidad de una
metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto
ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a
una forma tabular elaborada por Cockburn que se usa en muchas metodologas
giles para situar el rango de complejidad al cual se aplica una metodologa. En la
Figura N6 se muestra una evaluacin de las prdidas que puede ocasionar la
falla de un sistema y el mtodo requerido segn este criterio. Los parmetros son
Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras
palabras, la cada de un sistema que ocasione incomodidades indica que su nivel
de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los
nmeros del cuadro indican el nmero de personas afectadas a un proyecto.
5.3.4.4 Dynamic Systems Development Method (DSDM)
Define el marco para desarrollar un proceso de produccin de software. Nace en
1994 con el objetivo de crear una metodologa RAD (Rapid Application
Development) unificada. Sus principales caractersticas son: es un proceso
iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.
Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional,
diseo y construccin, y finalmente implementacin. Las tres ltimas son
iterativas, adems de existir realimentacin a todas las fases. 11
Principios del DSDM:
La implicacin activa de los usuarios es imprescindible.
Los miembros de los equipos de desarrollo DSDM deben tener la autonoma y
potestad necesarias para tomar decisiones.
10 Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el Desarrollo de
Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

11 Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el Desarrollo
de Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

43

Entrega frecuente de incrementos operativos del producto.


El principal criterio de prioridad, desarrollo y validacin de las entregas
incrementales es el objetivo y la salud del negocio.
El desarrollo iterativo o incremental hace posible obtener la solucin ms
adecuada a las necesidades del negocio.
Todos los cambios realizados en el desarrollo son reversibles.
Los requisitos se establecen a un nivel general
Las pruebas forman parte del ciclo de desarrollo
Es imprescindible trabajar con espritu de colaboracin con todos los agentes
implicados en el sistema que se desarrolla.
Figura 9. Principios del DSDM

Fuente: Amaro Caldern, Sarah Dmaris, Valverde Rebaza. Jorge Carlos, Metodologas agiles.
http://www.seccperu.org/files/Metodologias%20Agiles.pdf.

44

5.3.4.5 Adaptive Software Development (ASD)


Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo,
orientado a los componentes software ms que a las tareas y tolerante a los
cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin,
colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se
planifican las caractersticas del software; en la segunda desarrollan las
caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al
cliente. La revisin de los componentes sirve para aprender de los errores y volver
a iniciar el ciclo de desarrollo.12
ASD presupone que las necesidades del cliente son siempre cambiantes. La
iniciacin de un proyecto involucra definir una misin para l, determinar las
caractersticas y las fechas y descomponer el proyecto en una serie de pasos
individuales, cada uno de los cuales puede abarcar entre cuatro y ocho semanas.
Los pasos iniciales deben verificar el alcance del proyecto; los tardos tienen que
ver con el diseo de una arquitectura, la construccin del cdigo, la ejecucin de
las pruebas finales y el despliegue.

Figura10. Adaptive Software Development (ASD)

12 Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el Desarrollo
de Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

45

Fuente: Amaro Caldern, Sarah Dmaris, Valverde Rebaza. Jorge Carlos, Metodologas agiles.
http://www.seccperu.org/files/Metodologias%20Agiles.pdf.

5.3.4.6 Feature -DrivenDevelopment (FDD)

Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas
(hasta 2 semanas). Se centra en las fases de diseo e implementacin del sistema
partiendo de una lista de caractersticas que debe reunir el software. Sus
impulsores son Jeff De Luca y Peter Coad.13
FDD, es un mtodo gil, iterativo y adaptativo. A diferencia de otras metodologas
giles no cubre todo el ciclo de vida sino slo las fases de diseo y construccin
y se considera adecuado para proyectos mayores y de misin crtica. A diferencia
de otras metodologas giles no cubre todo el ciclo de vida sino slo las fases de
diseo y construccin y se considera adecuado para proyectos mayores y de
misin crtica.
Los principios de FDD son pocos y simples:
Se requiere un sistema para construir sistemas si se pretende escalar a
proyectos grandes.
Un proceso simple y bien definido trabaja mejor.
Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio
para cada miembro del equipo.
Vanagloriarse del proceso puede impedir el trabajo real.

13 Jos H. Cans, Patricio Letelier y Maria Carmen Penads, Mtodologas giles en el Desarrollo
de Software, http://www.willydev.net/descargas/prev/TodoAgil.pdf.

46

Figura11. Feature -DrivenDevelopment (FDD)

Fuente: Amaro Caldern, Sarah Dmaris, Valverde Rebaza. Jorge Carlos, Metodologas agiles.
http://www.seccperu.org/files/Metodologias%20Agiles.pdf.

5.3.5 MODELADO DE PROCESOS DE NEGOCIO (BPM)

5.3.5.1

Generalidades

Un proceso es un conjunto de actividades o eventos (coordinados u organizados)


que

se

realizan

o suceden (alternativa

simultneamente)

bajo

ciertas

circunstancias con un fin determinado. Un proceso de negocio es una serie de


tareas relacionadas lgicamente llevadas a cabo para lograr un resultado de
negocio definido. Cada proceso de negocio tiene sus entradas, funciones y
salidas. Las entradas son requisitos que deben tenerse antes de que una funcin
pueda ser aplicada. Cuando una funcin es aplicada a las entradas de un mtodo,
se tendrn ciertas salidas resultantes.

47

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o


bien puede incluir otros procesos de negocio que deban ser incluidos en su
funcin. En este contexto un proceso de negocio puede ser visto a varios niveles
de granularidad. El enlace entre procesos de negocio y generacin de valor lleva a
algunos practicantes a ver los procesos de negocio como los flujos de trabajo que
efectan las tareas de una organizacin. Los procesos poseen las siguientes
caractersticas:
1. Pueden ser medidos y estn orientados al rendimiento
2. Tienen resultados especficos
3. Entregan resultados a clientes o stakeholders
4. Responden a alguna accin o evento especfico
5. Las actividades deben agregar valor a las entradas del proceso.
6. Un modelo es una representacin de una realidad compleja. Modelar es
desarrollar una descripcin lo ms exacta posible de un sistema y de las
actividades llevadas a cabo en l.
Los procesos de negocio pueden clasificarse utilizando diversos enfoques.
Describimos en esta seccin una taxonoma planteada por M. Weske (2008) que
aborda una gama bastante amplia de casos.
Tabla 1. Clasificacin de los procesos
SEGN EL NIVEL DE GRANULARIDAD
ORGANIZACIONALES
OPERACIONALES
Cuando describen en el mbito global Presentan un mayor nivel de detalle y
los procesos de la organizacin y suelen concluir en un modelo completo
marcan o delinean grandes objetivos.
del proceso de negocio.
Representan el primer nivel de
abstraccin posible en el anlisis
SEGN EL ALCANCE CORPORATIVO
48

INTERORGANIZACIONALES
INTRAORGANIZACIONALES
Implementados o desplegados como un Implementados o desplegados como un
conjunto de servicios ejecutados bajo conjunto de servicios ejecutados bajo
un motor de orquestacin.
un motor de coreografa.
.
SEGN EL GRADO DE ESTRUCTURACION
ESTRUCTURADOS
NO ESTRUCTURADOS
Prescribe las actividades a realizar y Permite llevar a cabo la ejecucin de
las restricciones de ejecucin de una diferentes
maneras,
salteando
nica manera. Las decisiones que se actividades, incluyendo algunas no
toman durante la promulgacin del previstas.
proceso fueron tomadas en tiempo de
diseo. No permiten saltear actividades
no
requeridas
o
ejecutar
concurrentemente actividades definidas
como secuenciales.
SEGN EL GRADO DE AUTOMATIZACION
TOTALMENTE
PARCIALMENTE
MANUALES
AUTOMATIZADOS
AUTOMATIZADOS
Requiere menor grado de Requiere mediano grado Requiere mayor grado de
interaccin humana.
de interaccin humana.
interaccin humana.
SEGN EL GRADO DE REPETICION
ALTO
BAJO
Cuando el grado de repeticin es alto, En el caso en que no exista un alto
la inversin hecha en su modelizacin y grado de repeticin, como puede
promulgacin est justificada ya que suceder con los procesos de diseo de
habr muchas instancias que cumplen un avin, es difcil justificar la inversin
el mismo modelo.
que requieren la modelizacin.
Fuente: Weske Mathias, Business Process Management: Concepts, Languages,
Architectures. Springer. ISBN 978-3-540-73521-2. 2008

Cuando un proceso es modelado, con ayuda de una representacin grfica


(diagrama de proceso), pueden apreciarse con facilidad las interrelaciones
existentes entre distintas actividades, analizar cada actividad, definir los puntos de
contacto con otros procesos, as como identificar los subprocesos comprendidos.
Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto
claramente dando la oportunidad al inicio de acciones de mejora.

49

Hay tres tipos de procesos de negocio:

Procesos estratgicos - Estos procesos dan orientacin al negocio, soportan la


estrategia institucional en busca del direccionamiento de esfuerzos aislados. Por
ejemplo, "Planeacin estratgica". (ej., Internacionalizacin, consecucin de
recursos).

Procesos sustantivos, clave o de generacin de valor - Estos procesos dan el


valor al cliente, son la parte principal del negocio. Por ejemplo, "Entregar el
paquete" (empresa de paquetera y mensajera); "Preparar la comida y servirla"
(restaurante); "Transportar al viajero" (aerolnea)

Procesos de apoyo vertical u horizontal - Estos procesos dan soporte a los


procesos centrales. Por ejemplo, "Contratar personal", "Dar soporte/servicio
tcnico".

BPM se concentra en la administracin de los procesos de negocio. Se entiende


como tal a la metodologa que orienta los esfuerzos para la optimacin de los
procesos de la empresa, en busca de mejorar la eficiencia y la eficacia por medio
de la gestin sistemtica de los mismos. Estos procesos deben ser modelados,
automatizados, integrados, monitoreados y optimizados de forma continua.

5.3.5.2 Beneficios y ventajas BPM 14


La tecnologa BPM permite a las empresas el crecimiento empresarial a partir de
la habilidad en la modelacin, administracin y optimizacin de los procesos de
14 Flor Nancy Daz Piraquive, 2008. Gestin de procesos de negocio BPM (Business Process
Management), TICs y crecimiento empresarial

50

negocio, aumentando significativamente las ganancias o beneficios representados


en su rol, as como manteniendo el control de la organizacin y tomando las
acciones necesarias para el mejoramiento continuo de la misma.
Segn Flor Nancy Daz Piraquive (2008), Las empresas han identificado que las
actividades y procesos de su negocio deben fluir de manera articulada de principio
a fin. Por tal motivo, despus de haber realizado inversiones en soluciones
parciales que no dieron respuesta eficiente ni efectiva, y que no permitieron la
flexibilidad y agilidad requeridas, han identificado que la tecnologa BPM es un
factor clave y estratgico que no solo garantiza la automatizacin de sus procesos,
sino que articula las actividades entre las personas, la coordinacin y la
orquestacin de los procesos del negocio, optimizando as el uso de los recursos
de la organizacin. Es por esta razn que cada vez ms se estn imponiendo en
las mismas. A continuacin, se har un listado de las ventajas de implementar
dicha tecnologa:
Mejora de la velocidad de realizacin de los procesos de negocio, BPM puede
reducir los tiempos reduciendo las demoras y las duraciones de las tareas
mediante la automatizacin de ciertos pasos, permitiendo que varias etapas se
den en paralelo e imponiendo lmites de tiempo en la terminacin de las tareas.
Incremento de la satisfaccin del cliente, acelerando los procesos y asegurando
que nada falla, tanto los clientes internos como los externos obtienen la
informacin y las respuestas que necesitan ms rpida y fcilmente.
Responsabilidad e integridad, BPM asegura que todas las reglas de negocio
requeridas son satisfechas y todos los pasos completados.
Optimizacin y eliminacin de tareas innecesarias: Simplemente modelando los
procesos, las organizaciones pueden frecuentemente encontrar oportunidades y
eliminar trabajo innecesario. Adems usando un BPMS, se pueden proporcionar
51

medidas de los procesos que se estn gestionando facilitando el seguimiento y


control de los mismos, as como su mejora y optimizacin.
Inclusin de clientes y socios de mercado en los procesos de negocio. BPM
permite a clientes y socios participar activamente en los procesos de negocio de
una organizacin. Esto hace que las posibilidades de colaboracin aumenten,
haciendo que la distancia fsica no sea un impedimento.
Agilidad organizacional: BPM proporciona un excelente medio para conseguir
agilidad organizacional. Cuando un proceso cambia, es relativamente fcil cambiar
las reglas, los roles y las relaciones que definen ese proceso. La implementacin
de BPM involucra la articulacin de la estrategia, los procesos y la tecnologa de
una empresa para generar valor al negocio. BPM se concentra en la articulacin
de las iniciativas estratgicas con los procesos de negocio, apalancados.
Mayor retorno sobre las inversiones realizadas en tecnologa e informacin.
Mayor sensibilidad a las demandas del mercado a un menor costo.
Motor de cambio cultural en la organizacin al combinar la innovacin
tecnolgica con el capital intelectual.
Integracin de personas, procesos y tecnologa.
Mejora el rendimiento y la productividad de todos los involucrados en el
desarrollo de los procesos de negocio.
Reduccin en el nmero de pasos al desarrollar las actividades y los
procedimientos.
Reduccin en los ciclos de error, por la automatizacin de tareas administrativas.
Reduccin de tiempos de respuesta y aumento en la calidad y eficiencia.
Reduccin en el nmero de trabajadores requeridos.
5.3.5.3 Dimensiones articuladoras de procesos en la implementacin de la
tecnologa BPM

52

La implementacin de la tecnologa BPM en las empresas garantiza la articulacin


de la estrategia teniendo en cuenta los tres grandes pilares de la gestin de
procesos de negocio: La estrategia, los procesos y la tecnologa, con el propsito
de generar valor. Dicha articulacin fluye con base en el desarrollo de una serie de
procesos que alinean, de manera controlada, los aspectos estratgicos del
negocio con la asociacin de los componentes tecnolgicos que permitan
flexibilizar los cambios.
Pensar en procesos de negocio significa que las acciones de cambio que se
ejercen sobre el proceso son evaluadas y planeadas teniendo en cuenta las
diferentes dimensiones que interactan en la dinmica del mismo, de tal forma que
permiten la optimizacin de los recursos y el incremento en los niveles de
rendimiento empresarial. Estas dimensiones son:
El talento humano: la tecnologa BPM permite el desarrollo de las habilidades y
competencias necesarias para la operacin del proceso. Esto se constituye en uno
de los pilares fundamentales al momento de abordar el proceso de mejoramiento
empresarial.
Las polticas, normas y reglas: cada proceso se evala revisando las
actividades que se llevan a cabo, buscando eliminar aquellas que no adicionan
valor e identificando el cumplimiento de las polticas, normas y reglas de negocio
para la toma de decisiones acertadas acerca del proceso.
Las condiciones de la infraestructura fsica: influyen en el desarrollo delos
procesos, ya que las condiciones ambientales y geogrficas pueden determinar
mejoras o reducciones en la generacin de valor en determinada actividad del
negocio. La infraestructura implementada en tecnologas de informacin y
comunicaciones: facilita la operacin de repositorios de informacin y de
secuencia en el desarrollo de las actividades del proceso modelado bajo BPM, ya
que articula todos los sistemas de gestin con que opera la empresa.
53

Adicionalmente, la tecnologa permite integrar los trabajos y roles que la empresa


destina al desarrollo del proceso, con el fin de gestionarlas barreras culturales,
paradigmas, conocimientos y competencias requeridas para su realizacin.
Por ltimo, la tecnologa analiza la dimensin relacionada con la estructura de la
organizacin, con el propsito de optimizar la coordinacin de las diferentes
reas, jerarquas y dependencias que influyen en su desempeo.

54

Figura 14. Dimensiones articuladoras de procesos en la implementacin de la


tecnologa BPM

Fuente: http://www.cio.com.co/2008/articulos/Articulando.pdf
5.3.5.4 BPMN (Business Process Modelling Notation)
El objetivo principal de BPMN es ofrecer una notacin entendible por todos los
participantes en los procesos de negocio y su automatizacin, desde los analistas
de negocio que crean los primeros borradores de los procesos, hasta los

55

desarrolladores responsables de implementar la tecnologa que lleva a cabo los


procesos.
BPMN ha sido diseado para ser fcil de usar y de entender, pero tambin
proporciona la capacidad de modelar procesos de negocio complejos. Ha sido
diseado teniendo en cuenta la tecnologa de Servicios Web.
BPMN sirve para especificar diagramas de procesos de negocio (DPN). El BPD
(Business Process Diagram) o DPN fue creado con los lenguajes de ejecucin de
procesos y los Web Services en mente. Notaciones especiales han sido
agregadas al diagrama para describir eventos basados en mensajes y paso de
mensajes entre organizaciones, permitiendo el modelado de B2B (Business to
business) y B2C (Bussines to consumer).15
5.3.5.4.1 Resea histrica BPMN

La primera versin de la Business Process Modeling Notation (BPMN) fue


desarrollada por el instituto Business Process Management Initiative (BPMI)
principalmente bajo la tutela de Sthephan A. White profesional de la IBM en 2004.
Desde un principio, el principal objetivo fue disponibilidad una notacin grfica,
estandarizada, que permitiera automatizar los procesos a partir del diseo grfico.
En el ao 2005 fue trasladado el proyecto a la Object Management Group (OMG),
debido a que el BPMI no era un instituto que administra estndares. La OMG es
muy conocida en el mundo informtico porque administra, entre otros, el estndar
del lenguaje para el diseo del software llamado Unified Modeling Languaje
(UML). A travs de la OMG, de la cual son miembros la mayora de los
proveedores ms importantes de TI, BPMN se difundi rpidamente a nivel

15 Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

56

mundial y casi todos los proveedores sean grandes o pequeos, acadmicos o


consultores empezaron a adoptar este estndar.
La ltima versin oficial 1.2 fue publicada en enero de 2009 [OMG09]. La versin
2.0, completamente nueva y ampliada, se termin a mediados del ao 2010 y a
finales de este, el equipo de la OMG encargado de revisar y finalizar la nueva
versin, llamada Finalization Task Force (FTF), dio la recomendacin al gremio de
decisin de oficializar la versin 2.0. A partir de la versin 2.0 la sigla BPMN
cambia levemente de nombre a: Business Process Model and Notation.
Paradojamente hasta la versin 1.2 no se podan mapear los modelos
directamente en un entorno tcnico, porque an no estaban definidos los atributos
tcnicos. Debido a esta falencia existieron muchos problemas en convertir
(mapear) los modelos a lenguajes de ejecucin como BPEL (Business Process
Execution Language). Recin con la

versin 2.0 existe un meta modelo que

permite ejecutar directamente los modelos de BPMN.


Estos dos hechos importantes de la nueva versin, es decir de la estandarizacin
y habilidad de ejecucin directa conlleva a los siguientes beneficios:

Para las organizaciones aumenta el grado de independencia de las


herramientas de BOM, porque si cambian de herramientas no tienen que
volver a capacitar en otras notaciones. Al 2011 existen ms de 70
herramientas de modelacin de BPMN (tendencia en aumento) y muchas
de ellas se pueden adquirir gratis.

La comunicacin con otros socios de negocio que hayan aprendido BPMN


(clientes, consultores, proveedores, etc.) ser ms rpida, fluida y
expresiva.

Se puede esperar que nuevo personal traiga el conocimiento de BPMN.

Institutos de capacitacin, universidades y empresas consultoras van a


invertir recursos para formar profesionales en esta notacin. Empresas
57

privadas van a desarrollar soluciones basadas en este estndar, y


proveedores de tecnologa se encuentran desarrollando herramientas para
ejecutar directamente el cdigo grfico de BPMN.
Figura 15. Historia BPMN

Fuente: Gua de Referencia y Modelado BPMN - Stephen A. White, phd - Derek Miers

5.3.5.4.2 Diferencia de BPMN con otras notaciones


Muchos lectores que se interesan en BPMN conocen algunas otras notaciones
para modelar procesos. Seguramente tambin se preguntarn si tiene sentido
cambiarse a BPMN qu aspectos hay que considerar en esta nueva tcnica de

58

modelamiento. Segn la regin donde est radicado el lector y la escuela por la


que ha pasado, habr aplicado o conocido diferentes notacin es.
Cuando se empez a desarrollar BPMN se revisaron muchas otras notaciones de
modelamiento. Los miembros de la OMG aportaron con sus conocimientos y
experiencias con muchas notaciones existentes, de las cuales algunas de ellas
influyeron en el desarrollo del estndar, como por ejemplo UML Activity Diagram,
IDEEF, Activity-Decision Flow (ADF) Diagram, y Event-Process Chains (EPCs).
Algunas de estas notaciones que de revisaron son de carcter tcnico e influyeron
en el desarrollo del concepto de colaboracin y coreografa (UML EDOC, ebXML
BPSS, RosettaNet). Otras notaciones ms orientadas al negocio se revisaron para
extraer ideas en la parte conceptual del modelamiento de procesos de negocio,
como EPC, EDEF Y UML Activity Diagram.
La mayor debilidad de las notaciones comparadas con BPMN, es la insuficiencia
estructural para modelar la lgica entre los participantes autnomos de los
procesos, colaboracin entre los procesos. Este aspecto conceptual de
colaboracin y coreografa se convierte hoy en da en un factor crtico, si
pensamos que los desafos actuales tienden a un grado cada vez mayor de
integracin de los procesos en una organizacin y sobre todo con sus agentes
externos (proveedores, clientes, entes gubernamentales, entes reguladores, etc.)
Algunas de las ventajas que tiene BPMN sobre las otras notaciones de modelado
de procesos de negocio son:
BPMN es un estndar internacional de modelado de procesos aceptado por la
industria (vigencia a largo plazo).
Es independiente de cualquier metodologa de procesos, de cualquier
herramienta y por tanto de cualquier fabricante (es portable).
Es una notacin rica en elementos, con los que se pueden representar todo tipo
de procesos, desde procesos negocio hasta procesos de TI (fomenta la
59

colaboracin).
Introduce el concepto de evento para simplificar los diagramas.

Tabla 2. UML & EPC & BPMN


UML

(Unified

UML & EPC & BPMN


Modeling EPC
(Event-driven BPMN (Business Proces

Languaje)
Process Chain)
Se enfoca principalmente Se emplea para

Modeling Notation)
el Se enfoca principalmente

del diseo de sistemas modelado de procesos de al diseo de sistemas


de software.
negocio.
BPMS.
No logr posicionarse Domin el mercado en la Quiere cerrar la brecha
como estndar de diseo dcada de los 90 hasta para
de procesos.

el 2005.

el

diseo

de

procesos en las capas de

negocio y TI.
Fuente: Curso BPMN 2.0 Dpto. Informtica Universidad Tcnica Federico
Santa Mara

Un DPN est compuesto por un grupo de elementos grficos que se organizan en


cuatro categoras bsicas:

Objetos de flujo: eventos, actividades y gateways.

Objetos conectores: flujo de secuencia, flujo de mensaje, asociacin.

Swimlanes: pool, lane.

Artefactos: objetos de datos, grupo y anotacin

Un DPN modela un flujo de procesos de negocio, indicando los eventos que


ocurren al comenzar el proceso, las actividades que son llevadas a cabo y los
60

resultados finales del flujo de proceso. Las decisiones de negocio y las


ramificaciones de los flujos son modeladas usando pasarelas (gateways). Adems,
el flujo un proceso puede contener subprocesos, los cuales pueden ser mostrados
grficamente mediante otro diagrama de procesos de negocio. Si un proceso no
se descompone en subprocesos, es considerado como una tarea.
Tabla 2. Elementos rotacionales de BPM

61

Fuente: Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

Figura 20. Ejemplo de Notacin de modelo de proceso de negocio.


62

Fuente: Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM


El proceso graficado en la Figura 20 representa el proceso de recepcin del pago
de un cliente. El proceso se inicia con la actividad de Identificar la forma de pago.
Se prevn dos posibles formas de pago: en efectivo o con tarjeta de crdito. En
cada caso se aplica la actividad de aceptar el pago segn la forma del mismo y se
pasa a la actividad de empaque de la mercadera, finalizando as el proceso.
Figura 21. Segmento de un proceso con detalle

Fuente: Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

63

En la Figura 21, se representa una porcin del proceso de evaluacin de


presupuestos, mostrando el lazo iterativo de anlisis de cada proveedor. Como se
ve, se detallan las sub-actividades consideradas dentro del proceso de anlisis
del proveedor que encierra las actividades Enviar requerimientos, Recibir
cotizacin y Agregar cotizacin. Adems intervienen eventos intermedios que
consideran el tiempo dentro de dicho proceso.
Mediante BPMN tambin se puede modelar quin hace qu, simplemente
colocando los eventos y los procesos dentro de reas sombreadas, llamadas
piscinas (pools), la cuales especifican quien est llevando a cabo el proceso. Esas
piscinas, adems, pueden ser divididas en calles (lanes), las cuales representan
normalmente los distintos departamentos o unidades de una organizacin,
mientras que la piscina representa a la organizacin entera.
En BPMN existen dos tipos bsicos de modelos que pueden ser creados con BPD:

Procesos colaborativos B2B (pblicos): describen las interacciones,


relaciones y transacciones entre dos o ms negocios. Estos BPD son
especificaciones generales en las que no se tienen en cuenta los detalles
de los procesos de un participante en particular, sino que se muestran las
interacciones entre los participantes. Las interacciones son descritas como
una secuencia de actividades y el intercambio de patrones de mensajes
entre participantes.

Procesos de negocio internos (privados): el concepto de proceso y de


cadena de valor difcilmente permite un proceso interno sin interaccin con
el mundo exterior (aunque existen), sin embargo para los procesos o
subprocesos que se desarrollan internamente se deben definir las
actividades que generalmente no son visibles al pblico y son por ende,
actividades privadas.

64

7.1.7 BPMN Vs. UML


El advenimiento de BPMN, BPMS y sus lenguajes de ejecucin no deja obsoleta la
necesidad de desarrollos de sistemas, como los que se logran utilizando UML
(UnifiedModelingLanguaje). Los desarrollos de sistemas siguen teniendo un rol
importante en la arquitectura de procesos en el mbito empresarial. UML es un
lenguaje que facilita a los desarrolladores la especificacin, visualizacin y
documentacin de modelos de sistemas de software. Est dirigido en lneas
generales a los arquitectos de software e ingenieros de software. Fue desarrollado
como un medio para mejorar el proceso de desarrollo de software, desde el diseo
de la arquitectura hasta la implementacin de la aplicacin, para ser utilizado por
personas con conocimientos tcnicos (analistas de sistemas y programadores). 16
BPMN est dirigido a los analistas de negocio, arquitectos de sistemas e
ingenieros de software. Fue desarrollado para mejorar todo el ciclo de vida del
desarrollo de procesos desde el diseo de los mismos. Por su parte, UML es un
lenguaje desconocido para la mayora de los analistas de negocio. UML define un
nmero de diagramas que se pueden clasificar en las siguientes categoras:
estructura esttica de la aplicacin, comportamiento dinmico y administracin y
organizacin

de

soluciones de

software.

De

estas

tres

categoras,

el

comportamiento dinmico es el utilizado para modelar los procesos de negocio;


los diagramas asociados son el de actividad UML y los de casos de uso.
BPMN est emparentado con UML por el hecho que ambos definen una notacin
grfica para los procesos de negocio similar a los diagramas de comportamiento
16 Unified Modeling Language (UML), version 2.2 OMG
http://www.omg.org/technology/documents/formal/uml.htm. 2009. (al 16/10/2009)

65

de UML. Sin embargo, BPMN y UML usan enfoques muy diferentes para modelar
procesos de negocio. Si bien los diagramas de actividad constituyen la
herramienta UML para modelar actividades de procesos, UML, en general, ofrece
un enfoque orientado a objetos para modelar aplicaciones. Mientras que BPMN
toma un enfoque centrado en los procesos. Este enfoque es mucho ms natural e
intuitivo para los analistas de negocios. Con BPMN, el control y los mensajes de
flujo

entre

procesos

son

primeramente

modelados.

Luego,

se

definen

implcitamente los modelos de objetos para los procesos en vez de hacerse


explcitamente como en UML.
BPMN tambin ofrece la opcin de explicitar el modelado de objetos de negocio
que pueden ser expuestos a travs de servicios de negocio en el flujo del proceso.
Otro aspecto que marca una fuerte diferencia es que UML no posee una vista de
implementacin de los modelos de negocios. UML es un ensamblado de
diagramas que conforman un conjunto de buenas prcticas colectivas.
Desafortunadamente, esto significa que sus diagramas no fueron diseados
especficamente para trabajar conjuntamente unos con otros. Como consecuencia,
los desarrolladores slo pueden modelar una parte de sus aplicaciones con UML,
el nivel de implementacin detallado no est cubierto. En contraste, BPMN define
un nico tipo de diagrama que posee mltiples vistas derivadas del mismo metamodelo de ejecucin del proceso. Como resultado, la implementacin es una vista
lgica del proceso en un lenguaje de ejecucin de procesos de negocio.

66

5.3.5.2 Aplicaciones de BPM


Un proceso de seguimiento de orden de compra simple. En tal proceso, se recibe
la orden, se emite la factura, se recibe el pago y se envan los productos
comprados.
Esta representacin textual de actividades no otorga un orden a las mismas
siendo ms apropiado representar este ordenamiento grficamente. Esta
representacin grfica del proceso muestra un conjunto de actividades realizada
en forma coordinada. La coordinacin entre las actividades se realiza por una
representacin explcita del proceso usando las restricciones de ejecucin. Para
representar esta situacin es preciso acordar una notacin posible de modo que
cada smbolo tenga un significado unvoco. Esta notacin se conoce como BPMN
(Business Process Modeling Notation).
Esta representacin grfica constituye un molde para el proceso de negocio.
Todos los procesos de rdenes de compra se instanciarn con este molde.
Figura 12. Representacin grfica de un proceso de compra simple

Fuente: Weske Mathias, Business Process Management: Concepts, Languages,


Architectures. Springer, Pag 3-67. ISBN 978-3-540-73521-2. 2008

67

Siguiendo con las definiciones dadas por M.Weske, un modelo de proceso de


negocio constituye un conjunto de modelos de actividades y las restricciones de
ejecucin entre ellas. Una instancia de proceso de negocio representa un caso
concreto dentro de los procesos operativos de una compaa. Estos procesos se
componen de un conjunto de instancias de actividades.
Cada modelo de proceso de negocio es un molde para mltiples instancias de
tales procesos y cada modelo de actividad, lo es tambin para mltiples instancias
de actividades.
Por abuso de lenguaje suele denominarse proceso de negocio y actividad tanto al
modelo como a la instancia de cada uno de ellos. Un modelo de proceso de
negocio, como se muestra en la Figura puede usarse para configurar un BPMS
que asegurar que todas las instancias del modelo se ejecuten segn la
especificacin del mismo. Muchas organizaciones plasman en un BPMS todas sus
actividades como un componente de software centralizado.

Este control

centralizado es conocido como orquestacin de procesos.


La figura 13 representa las actividades del proceso que lleva a cabo un vendedor
cuando recibe la orden de compra. El proceso de negocio del comprador se inicia
con la ubicacin de una orden de compra. Luego, en paralelo, se recibe la factura
y el producto. A continuacin de la recepcin de la factura se abona la misma.
Los procesos de negocio pueden interactuar entre s. La Figura siguiente muestra
la interaccin entre los procesos llamados distribuidor y comprador, representados
cada uno de ellos por sus respectivos swimlanes o andariveles.
Figura 13. Representacin grfica de un proceso de compra y venta

68

Fuente: Weske Mathias, Business Process Management: Concepts, Languages,


Architectures. Springer, Pag 3-67. ISBN 978-3-540-73521-2. 2008

La interaccin entre los distintos procesos de negocio se denomina coreografa.


Este trmino indica la ausencia de un agente central que controle las actividades
involucradas en el proceso. La interaccin solamente enva y recibe mensajes.
Para realizar una interaccin correcta los procesos deben acordar la coreografa
La realizacin de los procesos de negocio vistos desde el punto de vista de sus
participantes, permiten aplicar cambios a sus actividades sin que cambie el
proceso en s mismo.
Por ejemplo: supongamos que se quiere aplicar como regla del negocio para el
proceso de orden de compra del vendedor, el hecho de que el producto no es
enviado hasta tanto se abone la factura. En este caso, el modelo de proceso del
vendedor y su interaccin con el comprador, prcticamente no cambian. Lo que
cambia es la orquestacin interna del proceso del vendedor.

5.3.6 ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

69

5.3.6.1 Generalidades
SOA es una arquitectura de software donde todas las tareas y procesos de
software son implementados como servicios para ser consumidos sobre una red.
Un servicio web es un sistema de software diseado para mantener interacciones
interoperables de mquina a mquina sobre una red.
La arquitectura orientada a servicios (SOA) no se trata de software o de un
lenguaje de programacin, es un marco de trabajo conceptual que permite a las
organizaciones unir los objetivos de negocio con la infraestructura de TI integrando
los datos y la lgica de negocio de sus sistemas separados.
SOA es una respuesta directa a las necesidades de las reas de negocios que
desean disponer de ms exibilidad en los sistemas de la empresa para poder
modicar ms rpidamente los

procesos como consecuencia de peligros u

oportunidades que surgen en el entorno, puesto que establece un marco de


diseo para la integracin de aplicaciones independientes de manera que desde la
red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios.
La forma ms habitual de implementarla es mediante Servicios Web, una
tecnologa basada en estndares e independiente de la plataforma, con la que
SOA puede descomponer aplicaciones monolticas en un conjunto de servicios e
implementar esta funcionalidad en forma modular.
Servicio
Un servicio es una funcionalidad concreta que puede ser descubierta en la red y
que describe tanto lo que puede hacer como el modo de interactuar con ella.
Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede
corresponder a un proceso de negocio tan sencillo como introducir o extraer un
dato como Cdigo del Cliente. Pero tambin los servicios pueden acoplarse
70

dentro de una aplicacin completa que proporcione servicios de alto nivel, con un
grado de complejidad muy superior por ejemplo, introducir datos de un pedido-,
un proceso que, desde que comienza hasta que termina, puede involucrar varias
aplicaciones de negocio.
La estrategia de orientacin a servicios permite la creacin de servicios y
aplicaciones compuestas que pueden existir con independencia de las tecnologas
subyacentes. En lugar de exigir que todos los datos y lgica de negocio residan en
un mismo ordenador, el modelo de servicios facilita el acceso y consumo de los
recursos de TI a travs de la red. Puesto que los servicios estn diseados para
ser independientes, autnomos y para interconectarse adecuadamente, pueden
combinarse y recombinarse con suma facilidad en aplicaciones complejas que
respondan a las necesidades de cada momento en el seno de una organizacin.
Las aplicaciones compuestas (tambin llamadas dinmicas) son lo que permite a
las empresas mejorar y automatizar sus procesos manuales, disponer de una
visin consistente de sus clientes y socios comerciales y orquestar sus procesos
de negocio para que cumplan con las regulaciones legales y polticas internas. El
resultado final es que las organizaciones que adoptan la orientacin a servicios
pueden crear y reutilizar servicios y aplicaciones y adaptarlos ante los cambios
evolutivos que se producen dentro y fuera de ellas, y con ello adquirir la agilidad
necesaria para ganar ventaja competitiva.
Servicios Web
Son servicios que tienen dos caractersticas fundamentales, primero que se
comunican por internet a travs de protocolos HTTP y segundo que enva y recibe
datos en formato XML. Las tecnologas utilizadas proporcionan una descripcin
del servicio y transportan documentos XML sobre el protocolo SOAP.
Adicionalmente un servicio web puede actuar como consumidor o como proveedor
de un servicio, y deber ser localizable para lo cual es necesario registrarlo.
71

La adopcin de una solucin de diseo basada en SOA no exige implantar


servicios Web. No obstante, como ya comentamos anteriormente, los servicios
Web son la forma ms habitual de implementar SOA. Los servicios Web son
aplicaciones que utilizan estndares para el transporte, codificacin y protocolo de
intercambio de informacin, permiten la intercomunicacin entre sistemas de
cualquier plataforma y se utilizan en una gran variedad de escenarios de
integracin, tanto dentro de las organizaciones como con partners de negocios.
Clasificacin de Servicios
Los servicios Web se basan en un conjunto de estndares de comunicacin, como
son XML para la representacin de datos, SOAP (Simple Object Access Protocol)
para el intercambio de datos y el lenguaje WSDL (Web Services Description
Language) para describir las funcionalidades de un servicio Web.
Una primera clasificacin de SOA es en dos niveles: aplicaciones frontend y
backend. Las aplicaciones frontend si bien no son servicios, son elementos activos
que inician los procesos de negocio y reciben los resultados, los servicios del
backend se clasifican en: bsicos, intermediarios, centrados en procesos y
empresariales pblicos.
Los servicios bsicos son los fundamentos de SOA. Son proveedores puros y no
mantienen un estado conversacional. Se dividen en servicios centrados en los
datos y centrados en la lgica, donde los primeros tienen como propsito manejar
los datos persistentes, almacenamiento, recuperacin y gestin transaccional, y
los segundos proveen encapsulamiento para clculos complejos o reglas de
negocio, tradicionalmente encapsulados en bibliotecas o frameworks.
Los servicios intermediarios son servicios sin estado que hacen de puente entre
las inconsistencias tcnicas o discrepancias conceptuales en el diseo. Son tanto
72

consumidores como proveedores, mediando entre los distintos elementos que


deben funcionar juntos. Se dividen a su vez en technology gateways, adapters,
facades y funcionality-adding.
Los servicios centrados en procesos encapsulan el conocimiento de los
procesos de negocio de la Organizacin y controlan y mantienen el estado del
proceso en ejecucin. Son tanto consumidores como proveedores y desde el
punto de vista tcnico son la clase de servicios ms sofisticada. Una de las
principales ventajas que presentan estos servicios es que separan la lgica de los
procesos, definiendo los procesos de negocio y su control, en base a orquestacin
de servicios existentes. Es en este tipo de servicios donde aparecen los BPMS y
los lenguajes de modelado de procesos como BPML (Business Process Modeling
Language) y BPEL4WS (Business Process execution Language for Web Services)
para orquestar servicios.
Los servicios empresariales pblicos a diferencia de los anteriores son
servicios que una empresa ofrece a socios y clientes externos. Estos servicios
tienen requerimientos especficos de facturacin de uso, interfaz, desacoplamiento
y seguridad ya que las empresas deben acordar claramente cmo se realiza el
uso de los mismos.
SOA permite unir los objetivos de negocio con la infraestructura de TI integrando
los datos y la lgica de negocio de sus sistemas que no estn integrados.
Establece un marco de trabajo para servicios de red o tareas comunes de
negocios para identificar el uno del otro. De esta manera los usuarios pueden ver
de una manera clara los objetivos y estrategias de negocio.
Permite la creacin de sistemas altamente escalables que reflejan el negocio de la
organizacin, brinda una forma estndar de exposicin e invocacin de servicios
(comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin
entre diferentes sistemas propios o de terceros.
73

Tipos bsicos de Servicios


Servicios controladores: Son los encargados de recibir las peticiones de los
clientes y realizar las llamadas necesarias a otros servicios (en la secuencia
adecuada) para devolver una respuesta. Es decir, son los servicios encargados de
coordinar al resto de servicios. Analizando bien este tipo de servicios, estos
representan a los procesos de negocio que se quieren implementar, ya que un
proceso de negocio no es ms que un conjunto de tareas ejecutadas en una
determinada secuencia para obtener un objetivo.
Servicios de negocio: Son los servicios que representan una tarea de negocio, y
que forman parte de un proceso de negocio. Este tipo de servicios suelen ser poco
reutilizables porque estn orientados a resolver una tarea muy puntual.
Servicios de utilidad: Son aquellos servicios que se caracterizan por representar
una tarea altamente reutilizable. Existen dos tipos, los servicios orientados al
negocio que representan una tarea de negocio altamente reutilizable entre
aplicaciones y los servicios tecnolgicos encargados de encapsular una
determinada tecnologa y por tanto altamente reutilizables.
Una aplicacin SOA se puede dividir en tres capas. La capa de recepcin de
peticiones (servicios controladores), la capa de tareas (servicios de negocio) la
capa de lgica reutilizables (servicios de utilidad).
Figura 15. Tipos de servicio SOA

74

Fuente: Artculos JAVIER URRUTIA, Publicado por Antonio Barco

5.3.6.2 Principios de los servicios


Los Servicios deben ser reusables: Todo servicio debe ser diseado y
construido pensando en su reutilizacin dentro de la misma aplicacin, dentro del
dominio de aplicaciones de la empresa o incluso dentro del dominio pblico para
su uso masivo.
Los Servicios deben proporcionar un contrato formal: Todo servicio
desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del
servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de
cada una de las funcionalidades y los datos de salida. De esta manera, todo
consumidor del servicio, acceder a este mediante el contrato, logrando as la
independencia entre el consumidor y la implementacin del propio servicio. En el
caso de los Servicios Web, esto se lograr mediante la definicin de interfaces con
WSDL.
75

Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen
que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento,
lo que se har es que cada vez que se vaya a ejecutar un servicio, se acceder a
l a travs del contrato, logrando as la independencia entre el servicio que se va a
ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los
servicios podrn ser totalmente reutilizables.
Los Servicios deben permitir la composicin: Todo servicio debe ser construido
de tal manera que pueda ser utilizado para construir servicios genricos de ms
alto nivel, el cual estar compuesto de servicios de ms bajo nivel. En el caso de
los Servicios Web, esto se lograr mediante el uso de los protocolos para
orquestacin (WS-BPEL) y coreografa (WS-CDL).

Los Servicios deben de ser autnomos: Todo Servicio debe tener su propio
entorno de ejecucin. De esta manera el servicio es totalmente independiente y
permite asegurar que as podr ser reutilizable desde el punto de vista de la
plataforma de ejecucin.
Los Servicios no deben tener estado: Un servicio no debe guardar ningn tipo
de informacin. Esto es as porque una aplicacin est formada por un conjunto de
servicios, lo que implica que si un servicio almacena algn tipo de informacin, se
pueden producir problemas de inconsistencia de datos. La solucin, es que un
servicio slo contenga lgica, y que toda informacin est almacenada en algn
sistema de informacin sea del tipo que sea.
Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser
descubierto de alguna forma para que pueda ser utilizado, consiguiendo as evitar
la creacin accidental de servicios que proporcionen las mismas funcionalidades.

76

En el caso de los Servicios Web, el descubrimiento se lograr publicando los


interfaces de los servicios en registros UDDI.
Una caracterstica muy importante de los Principios de la Orientacin a Servicios,
es que todos ellos se inter-relacionan. El siguiente grfico muestra la inter-relacin
de los diferentes principios:
Como se puede observar en el grfico, el objetivo de la Orientacin a Servicios es
obtener software totalmente reutilizable a travs de un conjunto de tcnicas y
principios como los descritos anteriormente.

Figura 16. Principios de los servicios

Fuente: Artculos JAVIER URRUTIA, Publicado por Antonio Barco

77

5.3.6.3 Beneficios17
Segn el artculo La Arquitectura Orientada a Servicios (SOA) aplicada al mundo
real, publicada por Microsoft en diciembre del 2006, los beneficios que puede
obtener una organizacin que adopte SOA son:

Mejora en los tiempos de realizacin de cambios en procesos.

Ahorro de dinero, tiempo y esfuerzo: debido a la reutilizacin de


componentes y la flexibilidad.

Acorta los tiempos de despliegue de soluciones.

Permite justificar ms claramente las inversiones en TI, ya que stas estn


ms alineadas al negocio.

Proporciona una visin ms alineada de lo que hace TI, y su valor asociado.

Permite la creacin y cambio de servicios de forma incremental, evitando


proyectos de larga duracin y alto coste.

Facilidad

para

evolucionar

modelos

de

negocios

basados

en

tercerizacin.

Facilidad para abordar modelos de negocios basados en colaboracin con


otros entes (socios, proveedores).

17 Microsotf, Diciembre 2006, La Arquitectura Orientada a Servicios (SOA) aplicada al mundo real.

78

Poder para remplazar elementos de la capa aplicativa SOA sin disrupcin


en el proceso de negocio.

Facilidad para la integracin

Racin de tecnologas dismiles.

Reutilizacin de servicios en mltiples aplicaciones.

Creacin de nuevos servicios de manera rpida y sencilla a partir de


servicios existentes.

Abstraccin del entorno de ejecucin, concentrndose en el desarrollo del


servicio.

Divisin de tareas, asignando responsabilidades particulares a cada grupo


de desarrollo.

Escalabilidad

Robustez

Homogeneidad

Facilidad en la adaptacin de nuevos servicios

Facilidad en la reestructuracin de sistemas

79

Aplicar lgica en el middleware pudiendo implementar procesos de


negocio.

Recoger informacin y procesarla para obtener resultados ms tiles.

Ahorro en tiempos de implantacin

Ahorro en tiempos de mantenimiento y operacin.

Reutilizacin de servicios en mltiples aplicaciones.

Creacin de nuevos servicios de manera rpida y sencilla a partir de


servicios existentes.

Abstraccin del entorno de ejecucin, concentrndose en el desarrollo del


servicio.

Divisin de tareas, asignando responsabilidades particulares a cada grupo


de desarrollo.

5.4 MARCO CONCEPTUAL


Proceso de negocio: Es un conjunto de tareas relacionadas lgicamente llevadas
a cabo para lograr un resultado de negocio definido. Cada proceso de negocio
tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben
tenerse antes de que una funcin pueda ser aplicada. Cuando una funcin es
aplicada a las entradas de un mtodo, tendremos ciertas salidas resultantes.

80

BPM Y SOA: Son disciplinas complementarias, que cuando se abordan de forma


conjunta aportan grandes beneficios ya que ambas persiguen el mismo objetivo:
incrementar la agilidad de las organizaciones.
Ventajas que aporta BPM a SOA: BPM aporta visibilidad ayudando a identificar
necesidades que estn presentes en varios procesos de negocio de la
organizacin. La identificacin de estos requisitos comunes permite disear
servicios SOA multi-funcionales y por tanto reutilizables, que pueden ser llamados
desde varios procesos de negocio.
De esta forma, cuando se requiere hacer cambios en un proceso de negocio
determinado, basta con cambiar el orden de llamada de los servicios, desarrollar
nuevos servicios o sustituir unos por otros para dar respuesta a las nuevas
necesidades. Este cambio resulta muy gil y suele tardar das en vez de meses,
como ocurrira con enfoques diferentes a SOA.
Ventajas que aporta SOA a BPM: Desde el punto de vista del negocio, SOA es un
habilitador de las iniciativas BPM.BPM ayuda a tener una perspectiva comn
sobre el papel que juegan las diferentes funciones de la organizacin y cul es su
contribucin a los procesos de negocio. Asimismo permite identificar aquellos
procesos que pueden cambiar con ms frecuencia y por qu razones.
La perspectiva comn que aporta BPM fomenta que negocio y tecnologa estn
alineados:

BPM ayuda a identificar y priorizar los servicios SOA con los que la
organizacin debe contar.

SOA ayuda a que los sistemas que automatizan los procesos de negocio
sean ms flexibles y respondan con agilidad a las expectativas de cambio
que demanda el negocio.

81

Workflow: Consiste en la automatizacin de un proceso de negocio, en su


totalidad o en parte, y en el cual se intercambian documentos, informacin o
tareas de un participante a otro, para provocar la accin de acuerdo a un conjunto
de reglas procedimentales. Un sistema de manejo de workflow permite definir,
crear y manejar la ejecucin de flujos de trabajo a travs del uso 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 tecnologa de la informacin.
ESB: Bus de servicios de empresa consiste en un combinado de arquitectura de
software que proporciona servicios fundamentales para arquitecturas complejas a
travs de un sistema de mensajes (el bus) basado en las normas y que responde
a eventos. Plataforma de software que da soporte a muchas funcionalidades
resueltas a nivel de la capa de aplicacin en los enfoques tradicionales de
construccin de aplicaciones. Los desarrolladores normalmente implementan un
ESB utilizando tecnologas de productos de infraestructura de middleware que se
basan en normas reconocidas.
HTTP: (HyperText Transfer Protocol) es un protocolo de comunicacin basado en
el intercambio de archivos que tiene sus races en el FTP y que constituy la
evolucin ideal de dicho protocolo para sostener el esquema de comunicacin de
los servidores Web, dando origen a la posibilidad de desarrollos de aplicaciones
basadas en Web que dotaron de dinamismo a la estaticidad del cdigo HTML.
BPMN:

Business

ProcessModelingNotation (en

espaol Notacin

para

el

Modelado de Procesos de Negocio) es una notacin grfica estandarizada que


permite el modelado de procesos de negocio, en un formato de flujo de trabajo
(workflow). Provee una notacin estndar que sea fcilmente legible y entendible
por parte de todos los involucrados e interesados del negocio (stakeholders).

82

BPD: En BPMN se definen Business ProcessDiagrams (BPD). Un BPD est


formado por un conjunto de elementos grficos que facilitan el desarrollo de
diagramas de flujos de procesos. Estos elementos grficos estn categorizados:
Objetos de flujo, objetos conectores, swimlanes, artefactos.
BPEL: Es un ambiente de ejecucin basado en XML que intenta habilitar
definiciones simples o complejas de negocios, cada proceso tiene un conjunto de
actividades e interacciones con colaboradores de servicio web, por lo que el
proceso central que se encarga de la orquestacin es tambin un servicio web.
5.5 BASES LEGALES
5.5.1 Ley 30 de 1992
Instituciones de Educacin Superior 18
Las Instituciones de Educacin Superior (IES) son las entidades que cuentan, con
arreglo a las normas legales, con el reconocimiento oficial como prestadoras del
servicio pblico de la educacin superior en el territorio colombiano.
Clasificacin de las Instituciones de Educacin Superior (IES)
Las IES se clasifican en: A, segn su carcter acadmico, y B, segn su
naturaleza jurdica.
Clasificacin A:
El carcter acadmico constituye el principal rasgo que desde la constitucin de
una institucin de educacin superior define y da identidad respecto de la
competencia o campo de accin que en lo acadmico le permite ofertar y
desarrollar programas de educacin superior, en una u otra modalidad acadmica.

18http://www.mineducacion.gov.co/1621/w3-article-231240.html

83

Segn su carcter acadmico, las Instituciones de Educacin Superior (IES) se


clasifican en:

Instituciones Tcnicas Profesionales


Instituciones Tecnolgicas
Instituciones Universitarias o Escuelas Tecnolgicas
Universidades

Las modalidades de formacin a nivel de pregrado en educacin superior son:

Modalidad de Formacin Tcnica Profesional (relativa a programas

tcnicos profesionales)
Modalidad de Formacin Tecnolgica (relativa a programas tecnolgicos)
Modalidad de Formacin Profesional (relativa a programas profesionales)

De acuerdo con el carcter acadmico, y como est previsto en la Ley 30 de 1992,


y en el artculo 213 de la Ley 115 de 1994, las Instituciones tcnicas tienen la
capacidad legal para desarrollar los programas acadmicos as:
Instituciones tcnicas profesionales:

a nivel de pregrado: programas tcnicos profesionales.


a nivel de posgrado: especializaciones tcnicas profesionales.

Es importante sealar que con fundamento en la Ley 749 de 2002, y lo dispuesto


en el Decreto 2216 de 2003, las instituciones tcnicas profesionales y las
instituciones tecnolgicas pueden ofrecer y desarrollar programas acadmicos por
ciclos propeduticos y hasta el nivel profesional, en las reas del conocimiento
sealadas en la ley, mediante el trmite de Redefinicin Institucional, el cual se
adelanta ante el Ministerio de Educacin Nacional y se realiza con el apoyo de
pares acadmicos e institucionales y con los integrantes de la Comisin Nacional
Intersectorial para el Aseguramiento de la Educacin Superior (CONACES), y
termina con una resolucin ministerial que las autoriza para hacerlo.
Clasificacin B:
84

Segn la naturaleza jurdica, la cual define las principales caractersticas que


desde lo jurdico y administrativo distinguen a una y otra persona jurdica y tiene
que ver con el origen de su creacin. Es as que con base en este ltimo aspecto
las instituciones de educacin superior son privadas o son pblicas.
5.5.2 Derechos de Autor

Colombia ha adoptado un rol protagnico en la defensa de los derechos de autor y


la propiedad intelectual, desarrollando un conjunto de normas que regulan,
protegen y penalizan a aquellas personas que violen estos derechos.
La Ley 44 de 1993 especifica penas entre dos y cinco aos de crcel, as como el
pago de indemnizaciones por daos y perjuicios a quienes comentan el delito de
piratera de software. Se considera delito el uso o reproduccin de un programa de
computador de manera diferente a como est estipulado en la licencia. Los
programas que no tengan licencia son ilegales y es necesaria una licencia por
cada

copia

instalada

en

los

computadores. 19

A partir del mes de julio de 2001, y gracias a la reforma hecha al Cdigo de


procedimiento penal, quien sea encontrado usando, distribuyendo o copiando
software sin licencia tendr que pagar con crcel hasta por un perodo de 5 aos. 20
Sin embargo, uno de los logros ms importantes de la legislacin colombiana en
materia de proteccin de derechos de autor fue la Ley 603 de 2000, en la cual
todas las empresas deben reportar en sus Informes Anuales de Gestin el
cumplimiento de las normas de propiedad intelectual y derechos de autor. La
Direccin de Impuestos y Aduanas Nacionales (DIAN) qued encargada de
supervisar el cumplimiento de estas leyes, mientras que las Superintendencias
quedaron responsables de vigilar y controlar a estas empresas. 21
19http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=3429
20http://www.corteconstitucional.gov.co/inicio/CUADRO%20CODIGO%20DE%20PROCEDIMIENTO%20PENAL.php
21http://www.secretariasenado.gov.co/senado/basedoc/ley/2000/ley_0603_2000.html

85

CAPTULO I
DISPOSICIONES ESPECIALES

Artculo l. Los empleados y funcionarios pblicos que sean autores de obras


protegidas por el Derecho de Autor podrn disponer contractualmente de ellas con
cualquiera entidad de derecho pblico.
Artculo 2. El artculo 29 de la ley 23 de 1982 quedar as:
Los derechos consagrados a favor de 105 artistas intrpretes o ejecutantes, de los
productores de fonogramas y de los organismos de radiodifusin tendrn la
siguiente duracin:
Cuando el titular sea persona natural la proteccin se dispensar durante su vida y
ochenta aos ms a partir de su muerte.
Cuando el titular sea persona jurdica, el trmino de proteccin ser de cincuenta
aos, contados a partir del ltimo da del ao en que tuvo lugar la interpretacin o
ejecucin, la primera publicacin del fonograma o, de no ser publicado, de su
primera fijacin, o la emisin de su radiodifusin.
CAPTULO II
DEL REGISTRO NACIONAL DEL DERECHO DE AUTOR

Artculo 3. Se podrn inscribir en el Registro Nacional del Derecho de Autor:


a) Las obras literarias, cientficas y artsticas;
b) Los actos en virtud de los cuales se enajene el Derecho de autor, as como
cualquier otro acto o contrato vinculado con los derechos de autor o los derechos
conexos;
c) Los fonogramas;
86

d) Los poderes de carcter general otorgados a personas naturales o jurdicas


para gestionar ante la Direccin Nacional del Derecho de Autor, o cualquiera de
sus dependencias, asuntos relacionados con la Ley 23 de 1982.
Artculo 4. El Registro de las obras y actos sujetos a las formalidades del artculo
anterior tiene por objeto:
a) Dar publicidad al derecho de los titulares y a los actos y contratos que
transfieran o cambien ese domino amparado por la ley;
b) Dar garanta de autenticidad y seguridad a los ttulos de derechos de autor y
derechos conexos y a los actos y documentos que a ellas se refieren.
Artculo 5. El Registro de las obras y actos deben ajustarse, en lo posible, a la
forma y trminos preestablecidos por el derecho comn para el registro de
instrumentos pblicos.
Tal diligencia ser firmada en el libro o libros correspondientes por el funcionario
competente.
Artculo 6. Todo acto en virtud del cual se enajene el Derecho de Autor, o los
Derechos Conexos as como cualquier otro acto o contrato vinculado con estos
derechos deber ser inscrito en el Registro Nacional del Derecho de Autor como
condicin de publicidad y oponibilidad ante terceros.
Artculo 7. El editor, el productor de obras audiovisuales, el productor fonogrfico
y videograbador, establecidos en el pas, de toda obra impresa, obra audiovisual
fonograma o video grama, o el importador de libros, fonogramas o video gramas
que circulen en Colombia deber cumplir, dentro de los 60 das hbiles siguientes
a su publicacin, transmisin pblica, reproduccin o importacin, con el depsito
legal de las mismas ante las entidades y en la cantidad definida en el reglamento
que para el efecto expedir el Gobierno Nacional.

87

La omisin del depsito legal ser sancionada por la Direccin Nacional del
Derecho de Autor con una multa igual a diez (10) veces el valor comercial de cada
ejemplar no depositado.
Artculo 8. Toda obra que sea presentada como indita para efectos de la
inscripcin en el Registro Nacional del Derecho de Autor, solo podr ser
consultada por el autor o autores de la misma (sic).
Artculo 9. El Gobierno Nacional establecer los requisitos y procedimientos de
inscripcin en el Registro Nacional del Derecho de Autor.
Ley de la propiedad intelectual 22
TTULO VII.
PROGRAMAS DE ORDENADOR.
Artculo 96. Objeto de la proteccin.

1. A los efectos de la presente Ley se entender por programa de ordenador toda


secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o
indirectamente, en un sistema informtico para realizar una funcin o una tarea
o para obtener un resultado determinado, cualquiera que fuere su forma de
expresin y fijacin.
A los mismos efectos, la expresin programas de ordenador comprender tambin
su documentacin preparatoria. La documentacin tcnica y los manuales de uso
de un programa gozarn de la misma proteccin que este Ttulo dispensa a los
programas de ordenador.
2. El programa de ordenador ser protegido nicamente si fuese original, en el
sentido de ser una creacin intelectual propia de su autor.

22http://noticias.juridicas.com/base_datos/Admin/rdleg1-1996.l1t7.html

88

Artculo 97. Titularidad de los derechos.


1. Ser considerado autor del programa de ordenador la persona o grupo de
personas naturales que lo hayan creado, o la persona jurdica que sea
contemplada como titular de los derechos de autor en los casos expresamente
previstos por esta Ley.
2. Cuando se trate de una obra colectiva tendr la consideracin de autor, salvo
pacto en contrario, la persona natural o jurdica que la edite y divulgue bajo su
nombre.
3. Los derechos de autor sobre un programa de ordenador que sea resultado
unitario de la colaboracin entre varios autores sern propiedad comn y
correspondern a todos stos en la proporcin que determinen.
Impactos en el rea tecnologa por el TLC entre Colombia y Canad
Con la entrada en vigor del TLC entre Colombia y Canad, se prevn impactos
positivos, en el rea Tecnolgica y Servicios se establecieron condiciones de
certidumbre y transparencia para los proveedores de servicios de ambas partes,
con el fin de generar oportunidades que permitan que Colombia se convierta en
una plataforma exportadora de servicios hacia el mercado de Canad el cual es de
33 millones de consumidores con alto nivel de ingresos, ya sea mediante el
desplazamiento fsico del prestador o consumidor, o sin necesidad de desplazarse
(servicios de consultora, call centers, traduccin en lnea, telemedicina,
telecomunicaciones, servicios de procesamiento de datos, servicios de informtica
y otros servicios relacionados con software y servicios de diseo, entre otros). Lo
anterior abre una ventana de oportunidades para aumentar el potencial exportador
colombiano de servicios profesionales.

5.6 DELIMITACION

89

5.6.1 Delimitacin espacio- temporal


El proyecto se realiz en la ciudad de Valledupar, y se aplic sobre el caso de
estudio citas mdicas de la IPS (Institucin Prestadora de Servicios de Salud) de
la Universidad Popular del Cesar.
5.6.2 Delimitacin conceptual
Con la creacin de una metodologa de desarrollo de software empleando las
arquitecturas BPM y SOA, se desea facilitar y darle solucin a los procesos
inflexibles de las organizaciones y en este caso a la Institucin Prestadora de
Servicios de Salud (IPS) de la Universidad Popular del Cesar, de la ciudad de
Valledupar, buscando garantizar el ptimo funcionamiento de los mismos y prestar
un servicio oportuno y confiable que permita satisfacer las necesidades de los
trabajadores y estudiantes.
Metodologa: Un marco metodolgico debe proveer un conjunto de etapas y sus
actividades, que acompaen el ciclo de vida de los procesos y el ciclo de vida del
software con miras a reducir la brecha entre la conceptualizacin del problema (en
las etapas iniciales del ciclo de vida) y la pieza de software que resuelve dicho
problema. Para definir este marco metodolgico se deben tener presentes dos
puntos que pueden resultar diferentes: por un lado, el carcter ortogonal de los
servicios respecto de los procesos y viceversa; por el otro, la convivencia de un
modelo de ciclo de vida iterativo con uno en cascada, correspondientes a la
gestin de procesos de negocio y los servicios respectivamente, que comparten
caractersticas comunes.
.
Aplicacin de software23: Programa informtico creado por medio de un lenguaje
de programacin, que facilita a un usuario realizar diversas actividades. Permite la
23 Concepto Personal JaidyMarjorie Jcome Lindarte

90

automatizacin de procesos, se adquiere, se instala, se administra y se retira.


Arquitectura: Diseo que indica la estructura, funcionamiento e interaccin entre
las partes del software. Se selecciona y disea con base en objetivos y
restricciones. Los objetivos pueden ser de tipo funcional, mantenibilidad,
auditabilidad, flexibilidad e interaccin con otros sistemas de informacin. Son
prefijados para el sistema de informacin. Las restricciones son aquellas
limitaciones derivadas de las tecnologas disponibles para implementar sistemas
de informacin.
Arquitectura Orientada a Servicios (SOA): Permite la creacin de sistemas de
informacin altamente escalables que reflejan el negocio de la organizacin, a su
vez brinda una forma bien definida de exposicin e invocacin de servicios
(comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin
entre diferentes sistemas propios o de terceros.
Gestin de Procesos de Negocios (BPM): Metodologa corporativa cuyo objetivo
es mejorar el desempeo (Eficiencia y Eficacia) de la Organizacin a travs de la
gestin de los procesos de negocio, que se deben disear, modelar, organizar,
documentar y optimizar de forma continua. El Modelo de Administracin por
Procesos, se refiere al cambio operacional de la empresa al migrar de una
operacin funcional a una operacin de administrar por procesos.
Institucin Prestadora de Servicios de Salud (IPS) 24: Son los hospitales,
clnicas, laboratorios, consultorios, etc. que prestan el servicio de salud. Pueden
ser pblicas o privadas. Para efectos de clasificacin en niveles de complejidad y
de atencin se caracterizan segn el tipo de servicios que habiliten y acreditan, es
decir su capacidad instalada, tecnologa y personal y segn los procedimientos e
intervenciones que estn en capacidad de realizar.
24 [On-line] Tomado de: http://enfermeria.unicesar.edu.co/index.php?
option=com_content&view=article&id=91&Itemid=110

91

Universidad Popular del Cesar: Universidad oficial del orden nacional adscrita al
Ministerio de Educacin Nacional de Colombia. Se encuentra ubicada en la ciudad
colombiana de Valledupar, capital del departamento del Cesar. Cuenta con 23
programas acadmicos de pregrado y 14 de postgrado.

6. ASPECTOS METODOLOGICOS
6.1 LINEA DE INVESTIGACION
6.1.1 Ingeniera de software
Este proyecto pertenece a la lnea de investigacin de: Lnea de Metodologas y
mtodos de construccin de software. La investigacin se centra en bsqueda de
metodologas, mtodos herramientas adecuada para producir software de calidad
en cualquier contexto de desarrollo. Para ello se estudian procesos de desarrollo,
mecanismos de especificacin y arquitecturas de software que permitan construir
aplicaciones robustas, extensibles y confiables con el presupuesto asignado y en
los plazos estipulados.
Sus objetivos son:

Descubrir los mtodos y metodologas de desarrollo de software, y sus

aplicaciones en la programacin y en la Ingeniera de Software.


Apropiar las bases conceptuales de las tecnologas y metodologas
promisorias de desarrollo de software, para adecuarlas y utilizarlas en

nuestro contexto.
Adoptar los mtodos y metodologas descubiertos a la enseanza de la

Programacin y la Ingeniera de Software.


Buscar arquitecturas que permitan construir aplicaciones flexibles que
puedan responder a una estructura de requisitos cada vez ms cambiante
y dinmica.
92

6.2 Tipo De Investigacin


El tipo de estudio que se aplic para desarrollar este proyecto es el exploratorio,
debido a que el presente tema de investigacin (integracin de BPM con SOA) es
bastante reciente.
Los estudios exploratorios permiten realizar aproximaciones a fenmenos no muy
conocidos con el fin de aumentar el grado de familiaridad. Con el propsito de que
estos estudios no se constituyan en prdida de tiempo y recursos, es
indispensable aproximarse a ellos, con una adecuada revisin de la literatura. En
pocas ocasiones constituyen un fin en s mismos, establecen el tono para
investigaciones posteriores y se caracterizan por ser ms flexibles en su
metodologa, son ms amplios y dispersos, implican un mayor riesgo y requieren
de paciencia, serenidad y receptividad por parte del investigador. El estudio
exploratorio se centra en descubrir.
6.3 METODO DE INVESTIGACIN
El mtodo de investigacin con

el que se desarroll este proyecto fu el

documental, el cual hace referencia a la obtencin y anlisis de datos provenientes


de materiales impresos u otros tipos de documentos, es decir apoyndose en
fuentes de carcter documental, esto es, en documentos de cualquier especie
tales como, las obtenidas a travs de fuentes bibliogrficas, hemerogrficas o
archivsticas.
6.4 POBLACION
La poblacin objeto de estudio est constituida por la Universidad Popular del
Cesar, la cual se encuentra localizada en Campus Sabana de la ciudad de
Valledupar.

93

6.5 MUESTRA
La muestra seleccionada corresponde al proceso de negocio: citas mdicas de la
Institucin Prestadora de Servicios de Salud (IPS) de la Universidad Popular del
Cesar
6.6 TCNICAS DE RECOLECCIN DE INFORMACIN
La tcnica utilizada para el desarrollo del proyecto de grado parte del proceso de
observacin, recoleccin, procesamiento de informacin sobre el proceso de
negocio citas mdicas de la Institucin Prestadora de Servicios de Salud (IPS) de
la Universidad Popular del Cesar
6.6.1 FUENTES DE DATOS
6.6.1.1 Fuentes primarias
La informacin primaria se obtuvo a travs de documentos originales, tesis de
grados, investigaciones previamente publicadas.
6.6.1.2 Fuentes secundarias
Las fuentes secundarias son textos basados en fuentes primarias, e implican
generalizacin,

anlisis,

sntesis,

interpretacin

evaluacin. Una

fuente

secundaria contrasta con una primaria, que es una forma de informacin que
puede ser considerada como un vestigio de su tiempo. Una fuente secundaria es
normalmente un comentario o anlisis de una fuente primaria. Es decir, se utiliza
con un propsito que es secundario con respecto a su funcin original.
Las fuentes secundarias utilizadas para la obtencin de informacin relevante
fueron:
Diccionarios
94

Consultas On Line
Revistas
Libros de ingeniera de software
Manuales de Funciones
Manual de Convivencia de la Institucin

7. INTEGRACIN ENTRE GESTIN DE PROCESOS DE NEGOCIO


(BPM) Y ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
7.1 Gestin de Procesos de Negocio BPM
7.1.1 Arquitectura BPM

95

Figura 17. Arquitectura BPM

Fuente: Chong, J.; Macas, V.; Marchan, K. & Villacres, M. (2006). BPM: Business
Process Modeling. Escuela Superior Politcnica del Litoral. Maestra en Sistemas de Informacin
Gerencial [documento pdf].

De acuerdo con Chong (2006), en la anterior ilustracin se muestran las


principales partes de una arquitectura BPM y las relaciones entre ellas. El centro
del sistema es la mquina de ejecucin, la cual realiza los procesos escritos en
BPEL. Los analistas tcnicos y del negocio disean los procesos usando un editor
grfico que soporta notacin BPMN.
El editor incluye una herramienta de exportacin que genera cdigo BPEL XML a
partir de los diagramas BPMN. Las interacciones entre las computadoras y el ser
humano gobiernan la ejecucin de los procesos en la mquina. Las personas que
participan en el proceso poseen aplicaciones grficas de workflow que se
conectan a la mquina a travs de interfaces programadas.
96

La interfaz permite que el usuario pueda revisar y ejecutar las actividades


pendientes. Hay dos tipos de interacciones de computadoras: internas y externas.
Las segundas son tpicamente comunicaciones con los procesos de otras
empresas,

travs

de

web

services,

gobernadas

por

coreografas

colaboraciones B2B.
Los administradores de un sistema BPM usan una consola grfica para
administracin y monitoreo, para chequear el estado de los procesos de la
mquina. La mquina de ejecucin mantiene de forma persistente el estado de los
procesos, usando una base de datos; la consola se conecta a esta de forma
directa, en lugar de usar lenguaje de administracin, para realizar queries con
propsitos particulares.
BPMN bsico que captura las comunicaciones requeridas del proceso local; esta
herramienta puede desempear una validacin o chequeo de seguimiento de la
coreografa para ese modelo generado. Las aplicaciones internas residen en la red
de la empresa, pero estn fuera del espacio de direcciones en que se encuentra la
mquina; acceden usando tecnologas de integracin tales como J2EE, XML,
Java, Web Services.
7.1.2 Etapas de la gestin de procesos con la tecnologa BPM
De acuerdo con Smith (2003)25, los negocios han sido organizados alrededor de s
mismos o de un natural concepto de aplicacin de software. Esta afirmacin queda
desvirtuada una vez que las empresas implementan la tecnologa BPM para la
gestin de los procesos de negocio, ya que para el ptimo desarrollo e integracin
de los mismos, se fundamentan en la definicin del ciclo de vida, el cual tiene

25 Smith, H. & Fingar, P. (2003). Business Process Management. The Third Ware.

Tampa. Florida, USA: Meghan-Kiffer Press.


97

como principal elemento la innovacin implcita, que se manifiesta en el desarrollo


de sus etapas; estas son:
Diseo: Significa modelar, manipular y redisear procesos para luego capacitar y
dar a conocer a la organizacin sobre los posibles descubrimientos o mejoras
sugeridas. Este proceso integra actividades, reglas, participantes y sus
interacciones. Sus caractersticas son: composicin, descomposicin, combinacin
reestructuracin y transformacin.
Despliegue: Consiste en la socializacin del conocimiento hacia todos los
participantes, incluyendo los conceptos de gente, aplicaciones y otros procesos
empresariales.
Interaccin: Usa los procesos de escritorio y los de portal, en los cuales la gente
puede interactuar completamente con los procesos de negocio. Esto incluye la
administracin entre la interface, el trabajo manual (tradicionalmente llamado
workflow) y la automatizacin. En esta administracin el trabajo recae sobre la
alocucin, administracin de tareas y la forma en que los datos son integrados.
Monitoreo y control: Integra ambos procesos con el sistema de gestin de
procesos sobre el que se est ejecutando. Este incluye las tareas necesarias para
mantener el desarrollo ptimo de los procesos, tanto desde una perspectiva
tcnica como en la utilizacin de los recursos.
Optimizacin: Combina el proceso de diseo y el de anlisis para retroalimentar
la ejecucin de los procesos con respecto a la situacin actual.
Anlisis: Controla la presentacin del proceso para proveer la mtrica, anlisis y
la inteligencia de negocio necesaria para manejar las mejores prcticas y
estrategias, y descubrir oportunidades innovadoras.

98

Ejecucin: Asegura que el nuevo proceso es desarrollado por todos los


participantes (gente, sistemas de informacin, otras organizaciones y otros
procesos). Es responsable del sistema de gestin del proceso. Muchas
caractersticas de la tecnologa BPM estn combinadas, total o parcialmente, para
satisfacer el ciclo de vida de BPM, el cual es conducido directamente por metas
organizativas. Esta fusin de tecnologas en un transparente entorno de diseo
integrado (IDE), proporcin a el nivel de abstraccin necesario para que tanto el
especialista de tecnologa como el de negocio hablen un mismo idioma.
7.1.3 Roles Bpm26
Director de procesos: ejecutivo que habilita y define la arquitectura de procesos
y fomenta la cultura empresarial basada en procesos.
Arquitecto de procesos: Disea y construye los modelos de procesos (flujo de
trabajo, indicadores de desempeo y planes de control).
Propietario de procesos: Son los responsables del rendimiento de los procesos.
Ingeniero de procesos: Construyen procesos ejecutables (creacin de servicios,
orquestacin con otros servicios, creacin de aplicaciones compuestas, sistemas
de medida, notificacin y control).
Analista de procesos (Psiquiatra de procesos): Experto que define los eventos
a supervisar, diagnostica problemas y prescribe soluciones al rendimiento.
Actor del proceso (Trabajador del proceso): Trabaja dentro del proceso y
comprende cmo encaja dentro del flujo de valor.

26 Kiran Garimella, Michael Lees, and Bruce WilliamsBPM (2008), Basics For Dummies, Software
AG Special Edition Published by Wiley Publishing, Inc.

99

7.1.4 Sistemas de Gestin de Procesos de Negocio BPMS


Figura 18. Sistemas de Gestin de Procesos de Negocio BPMS

Fuente: http://www.cio.com.co/2008/articulos/Articulando.pdf
Un BPMS (Business Process Management System) es una nueva plataforma TI
construida para gestionar procesos de negocio. Inicialmente y de manera general
un BPMS puede ser definido como un conjunto de utilidades de software para
definir, implementar y mejorar procesos de negocio que cumplen con un grupo de
caractersticas tcnicas necesarias para aplicar el concepto. 27
Con los BPMS se espera conseguir:
Integracin de sistemas. Integrar sistemas existentes conectando bases de
datos y la mejor clase de paquetes de soluciones en procesos de negocio
27 Jos Manuel Prez, Francisco Ruiz, Mario Piattini (2007). Model Driven Engineering Aplicado a
Business Process Management, http://www.uclm.es/dep/tsi/pdf/UCLM-TSI-002.pdf

100

flexibles.
Automatizar actividades rutinarias. Se ejecutarn y optimizarn procesos de
negocio automticos.
Gestionar todas las fases de los procesos. Ayudarn a descubrir, disear,
desplegar, operar y analizar los procesos de negocio, dentro de un entorno
integrado.
Desplegar procesos. Permitirn ser diseados on-line por los usuarios de
negocio y por los ingenieros de procesos juntos.
Proporcionar visibilidad y control total. Permitirn a los procesos ser
concebidos, desplegados, optimizados y analizados completamente, a travs de
mltiples aplicaciones. Proporcionarn una visin y control global de la
organizacin completa.
Las tecnologas que un BPMS cubre e integra son, entre otras, las siguientes:
Sistemas de Workflow (flujos de trabajo), Enterprise Application Integration (EAI),
servidores de aplicaciones, productos B2B, servicios web, etc. Ya existen estudios
que muestran las ventajas reales para las empresas cuando se utiliza un BPMS.
De hecho, se ha comprobado que se puede reducir el tiempo de desarrollo de
sistemas de informacin hasta un 75% y los costes de integracin con otros
sistemas hasta un 85%. 28

Un proceso es ejecutado por un BPMS y por los diferentes participantes en el


proceso. El BPMS es el responsable de la coordinacin de las transacciones

28 Jose Manuel Prez, Francisco Ruiz, Mario Piattini (2007), Model Driven Engineering Applicator
a Business Process Management

101

definidas por el proceso, de manejar las instancias de los procesos, y de procesar


las transacciones distribuidas.
Las transacciones de negocio (como un pedido de compra) y las transacciones de
sistemas (como una transaccin procesada en una tabla de una base de datos)
pueden ser definidas mediante un proceso. Normalmente, las transacciones de
negocio implican dos o ms participantes, mientras que las transacciones de
sistemas pueden implicar mltiples sistemas (transacciones distribuidas).
Hacer que un modelo se convierta en un proceso ejecutable requiere de varias
tecnologas habilitantes, cuando estas tecnologas se proveen juntas se le llama
BPMS, las principales son:
Motores de Orquestacin: permiten coordinar la secuencia de actividades segn
los flujos y reglas del modelo de procesos.

Herramientas de Anlisis y Business Intelligence: permiten analizar la


informacin producto de la ejecucin del proceso en tiempo real.

Motores de Reglas: (Rule Engines) ejecuta reglas que permiten abstraer las
polticas y decisiones de negocio de las aplicaciones subyacentes.

Repositorios:

mantiene

los

componentes

recursos

de

los

procesos

(definiciones, modelos, reglas, etc.) disponibles para su reutilizacin en mltiples


procesos.

Herramientas de Simulacin y Optimizacin: permite a los administradores del


negocio, comparar los nuevos diseos de procesos con el desempeo operacional
actual.

102

Herramientas de Integracin: permiten integrar el modelo con otros sistemas,


con los sistemas legados de la empresa.
7.1.4.1

Etapas de BPMS

BPMS presta apoyo en todo el ciclo de vida de los procesos de negocio, el cual se
compone de las siguientes etapas:
Figura 19. Etapas de BPMS

Fuente: Espinoza Bustamante Luis Alberto, Administracin SOA,


http://soaagenda.com/journal/articulos/category/bpm/

Modelamiento de los Procesos de Negocio: en esta etapa se crea o


modela un proceso de negocio, tambin es aqu donde se definen mejoras,
o cambios a los procesos para optimizarlos. En esta etapa el principal
103

involucrado es el Analista de Negocios. Los artefactos que se obtienen en


esta fase son: BPA, BPMN, Portal de procesos + Repositorio de procesos,
Mapa de procesos.

Implementacin: en esta etapa se integran los componentes necesarios


para implementar el proceso. El principal involucrado en esta etapa es el
Ingeniero de TI para el caso de que los procesos se implementen como
soluciones tecnolgicas. Estos componentes son: Servicios Web, las
Reglas del negocio y BPEL.

Ejecucin de Procesos: esta es la etapa en donde se explota el proceso


desarrollado previamente, en esta etapa los principales involucrados son
los Participantes del proceso. Adems aqu es cuando se recolecta la
informacin para control, y seguimiento.

Control y Gestin: esta es la etapa donde se le da seguimiento a los


procesos, y donde se analiza la informacin de su ejecucin, por ejemplo:
indicadores de desempeo, cuellos de botella, caminos crticos, carga de
trabajo, etc., su principal caractersticas es que la informacin se analiza en
tiempo real. En esta etapa los principales involucrados son los
Supervisores, y la Gerencia.

7.1.4.2

Mdulos de BPMS 29

Los mdulos principales que componen la plataforma BPMS, y que apoyan las
etapas del ciclo son:

Modelador Grfico de Procesos: (Business Modeler) que permite modelar


los procesos de negocio, simular su ejecucin, definir mtricas para el

29 Espinoza Bustamante Luis Alberto, Administracin SOA,


http://soaagenda.com/journal/articulos/category/bpm/

104

monitoreo, y exportar a BPEL (lenguaje estndar de procesos). Tiene un


diseador grfico de procesos, que permite fcilmente crear los modelos.

Ambiente Integracin y Desarrollo: (Integration Developer) es la


herramienta que permite implementar los procesos, y servicios. Esta
herramienta permite integrar las pantallas (para interaccin de un
participante), y los servicios (interaccin con sistemas legados).

Servidor de Procesos de Negocio: (Process Server) es el motor que


permite ejecutar los procesos de negocio, aqu se ejecutan las Aplicaciones
Compuestas (flujos BPM), los Workflows tradicionales, y la Orquestacin de
Servicios (procesos compuestos solo por servicios). Este servidor tambin
es el encargado de generar los datos de las mtricas, y de monitoreo.
Permite intervenir los procesos en tiempo real: balancear carga, cambiar
flujo de negocio, y realizar acciones correctivas (segn reglas de negocio).

Monitor de Actividades de Negocio: (BAM, Business Activity Monitor) esta


es una aplicacin de administracin que permite gestionar los procesos y
servicios, grficamente se pueden ver indicadores de performance, y SLA
(ServiceLevelAgreements, niveles de servicio a cumplir). Se puede adems
definir alertas y triggers de acuerdo a eventos de negocio que sucedan en
el proceso. Tambin puede proveer datos reales a los modelos (Business
Modeler) para ajustar las simulaciones (y lograr mejoramiento continuo).

7.1.5 Estndares de BPM


La normalizacin o estandarizacin es la redaccin y aprobacin de normas que
se establecen para garantizar el acoplamiento de elementos construidos
independientemente.

La

definicin

de

estndares

el

desarrollo

de

implementaciones que hagan uso de los mismos, son un aspecto imprescindible

105

para la interoperabilidad de productos y fabricantes que garantizan la amortizacin


y evolucin de los desarrollos realizados.
En esta seccin se mostrarn los distintos estndares existentes actualmente para
abordar el modelado y la implementacin de procesos de negocio.

Tabla 1.Principales estndares BPM

Fuente: Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

7.1.7 BPML (Business Process Modelling Language)


BPML es un metalenguaje para el modelado de procesos de negocio, de la misma
manera que XML es un metalenguaje para el modelado de datos de negocio.
BPML proporciona un modelo de ejecucin abstracto para procesos de negocio
colaborativos y transaccionales basados en el concepto de una mquina de
estados finitos transaccional.

106

BPML puede manejar participantes de diferentes clases. Desde sistemas gestores


de bases de datos y componentes software hasta usuarios y socios de negocio
(clientes y suministradores).
7.1.8 BPEL (Lenguaje de Ejecucin de Procesos de Negocio)
BPEL es un lenguaje de programacin a un nivel de abstraccin que permite a los
desarrolladores componer mltiples Servicios Web sncronos y asncronos en un
flujo de negocio, de principio a fin. Es decir, BPEL est diseado para permitir
compartir tareas en un ambiente de computacin distribuido, inclusive entre
mltiples organizaciones, usando una combinacin de servicios Web.
La especificacin de BPEL4WS fue codesarrollada por Microsoft, IBM, Siebel
Systems, BEA y SAP. Esta especificacin modela el comportamiento de los
diversos SW que puedan participar en la interaccin de un proceso de negocio.
Adems, suple la integracin con interfaces humanas
Permite modelar los procesos de negocio de dos maneras:
a) Mediante procesos de negocio ejecutables se modela el comportamiento de un
participante en una interaccin de negocio.
b) Mediante procesos de negocio abstracto (protocolos de negocio), por el
contrario, se usan descripciones de procesos que especifican el comportamiento
del intercambio visible de mensajes de cada parte involucrada en el protocolo, sin
revelar su comportamiento interno. Las descripciones de procesos para protocolos
de negocios son llamados procesos abstractos.
La diferencia entre los procesos ejecutables y los abstractos, es que mientras que
los procesos ejecutables modelan la orquestacin, los procesos abstractos
modelan la coreografa de los servicios.

107

BPEL es un lenguaje de orquestacin: coordina y administra los servicios web. Un


proceso de BPEL, est compuesto de una actividad, la cual a su vez est
conformada por varias subactividades. BPEL define un SW que coordina e invoca
otros servicios web. Es un lenguaje para implementar esta composicin de SW. La
interfaz de servicio se compuesto se describe con una coleccin de tipos de puerto
WSDL, tal como el resto de los servicios web. La composicin (llamada procesos)
indica como la interfaz del servicio forma parte de toda la ejecucin de la
composicin.
Figura 22. Vista de un servicio web implementado por un proceso BPEL$WS

Fuente: http://bpm business_process_modeling_resumen.pdf


BPEL provee de una sintaxis en XML para la descripcin de la lgica de control
necesaria para coordinar los Servicios Web que participen en un flujo de proceso.
Esta gramtica es ejecutada por un motor de orquestacin que coordina todas las
actividades y compensa el proceso global cuando ocurre algn error. BPEL puede
considerarse como una capa que se tiende sobre WSDL, ya que este ltimo define
las operaciones disponibles, mientras que BPEL define como secuenciarlas. [23]
La especificacin de BPEL incluye soporte tanto para actividades bsicas como
para actividades estructuradas. Una actividad bsica consiste en una instruccin
que interacta con algo externo al proceso en s, mientras que las actividades

108

estructuradas gestionan todo el flujo de procesos, especificando la secuencia para


los SW referenciados.
Dos elementos importantes en BPEL son las variables y los partner Links, donde:
Una variable identifica el dato especfico que se intercambia en un flujo de
mensaje. Cuando un proceso BPEL recibe un mensaje, se guarda en la variable
apropiada, de forma que sucesivas peticiones puedan acceder a los datos. De
esta forma, las variables permiten gestionar la persistencia de los datos a travs
de las sucesivas peticiones de los SW.
Un partner Link puede ser cualquier servicio al que el proceso invoque, o por el
contrario, cualquier servicio que invoque al proceso. Cada partner Link se traduce
a un rol especfico que se desempea en el proceso de negocio. A fin de agrupar
en una nica transaccin un conjunto de actividades, BPEL usa una etiqueta
scope. Esta etiqueta, indica que los pasos que estn dentro de la misma, debern
realizarse de forma atmica. Dentro de este alcance, los desarrolladores pueden
definir distintos manejadores de compensacin que el motor de orquestacin
BPEL pueda invocar en caso de error.

7.2 Arquitectura Orientada a Servicios SOA


7.2.1 Componentes SOA

Figura 23. Componentes SOA

109

COMPONENTES SOA

OPERACIONES

ROLES

Proveedo
r de
servicios:

Solicitant
e de
servicios

Registro
de
servicios

Publicar

Ligar
(bind)

Encontrar

Fuente: Elaboracin propia


Roles
Proveedor de servicios: Una entidad que hostea un servicio web accesible a
travs de una red es un proveedor de servicios.
1) Crea una descripcin de servicios
2) Entrega un servicio en un entorno de ejecucin para hacerlo disponible a otras
entidades sobre una red
3) Publica la descripcin del servicio en uno o ms registros de servicios
4) Recibe mensajes invocando servicios de los solicitantes de servicios
Solicitante de servicios: Un solicitante de servicios puede ser cualquier
consumidor de un servicio web.
1) Encuentra una descripcin de servicio publicada en un registro de servicios
110

2) Aplica la descripcin del servicio para ligar e invocar el servicio web hosteado
en un proveedor de servicios.
Registro de servicios: El rol del registro de servicios es permitir el match entre
los proveedores de servicios y los solicitantes de servicios. Una vez que se
encontr el servicio buscado, las interacciones se llevan a cabo directamente entre
el solicitante del servicio y el proveedor del servicio.
1) Acepta las solicitudes de los proveedores de servicios para publicar y publicitar
las descripciones de servicios
2) Permite a los solicitantes de servicios buscar en la coleccin de descripciones
de servicios contenida en el registro de servicios.
Operaciones
Publicar: La operacin de publicar es un acto de registracin o publicacin de
servicios. Cuando un proveedor de servicios publica su servicio web en un registro
de servicios, est publicitando el servicio a toda la comunidad de potenciales
solicitantes del servicio. Los detalles de la operacin de publicar dependen de
cmo el registro de servicios est implementado.
Encontrar: La operacin de encontrar es un acto de buscar un servicio que
satisface ciertas condiciones:
1) el solicitante del servicio establece un criterio de bsqueda, tal como: el tipo de
servicio, la calidad, etc.
2) El registro de servicios empareja los criterios de bsqueda con las
descripciones de servicio publicadas. El resultado es una lista de descripciones de
servicios que relacionan el criterio de seleccin.
Los detalles de la operacin dependen de la implementacin del registro de
servicio.

111

Ligar: La operacin de ligar crea la relacin cliente-servidor entre el solicitante del


servicio y el proveedor del servicio. La operacin puede ser:
1) dinmica creando un proxy del lado del cliente onthefly- basado en la
descripcin del servicio para invocar el servicio web.
2) esttica el desarrollador hard-codea la forma en que el cliente invoca el
servicio web.
Figura 24. Operaciones SOA

7.2.2 Propiedades de SOA

SOA es una forma de arquitectura de sistemas distribuidos, caracterizada


por:
1) Visin lgica un servicio es una abstraccin, es lo que los programas,
bases de datos, procesos de negocios, etc. actuales son capaces de
hacer.

112

2) Intercambio de mensajes un servicio est definido en trminos de los


mensajes intercambiados entre los agentes proveedores y solicitantes y
no en trminos de las propiedades de los agentes en s mismos.
3) Abstraccin SOA esconde los detalles de implementacin de los lenguajes de
implementacin, procesos, estructuras de bases de datos, etc.
4) Meta-datos un servicio es descripto va meta-datos procesables por una
mquina
5) Nmero pequeo de operaciones un servicio tiende a tener un nmero
pequeo de operaciones con mensajes relativamente grandes y complejos.
6) Orientado a redes los servicios estn orientados a ser usados sobre una red.
7) plataforma neutral los mensajes son enviados en un formato estandarizado
entregado a travs de interfaces. Se usa XML.
7.2.3 Ciclo de vida SOA

Determinar cmo el proyecto SOA ser puesto en produccin, controlado y


consumido desde otras aplicaciones.

Desarrollar e implementar las prcticas correctas para alcanzar la


interoperabilidad.

Asegurar el crecimiento del proyecto y promover la reutilizacin de


servicios.

Definir la granularidad correcta de los servicios.


Figura 25. Ciclo de vida SOA

113

7.2.4 Capas de software SOA


Las capas de software que define SOA son:

Aplicaciones bsicas - Sistemas desarrollados bajo cualquier arquitectura o


tecnologa, geogrficamente dispersos y bajo cualquier figura de propiedad.

De exposicin de funcionalidades - Donde las funcionalidades de la capa


aplicativa son expuestas en forma de servicios (generalmente como
servicios web).

De integracin de servicios - Facilitan el intercambio de datos entre


elementos de la capa aplicativa orientada a procesos empresariales
internos o en colaboracin.

De composicin de procesos - Que define el proceso en trminos del


negocio y sus necesidades, y que vara en funcin del negocio.

114

De entrega - donde los servicios son desplegados a los usuarios finales.

7.2.5 ANTES Y DESPUES DE SOA


Antes de SOA, las aplicaciones eran monolticas, separadas en silos, no
integradas, cerradas, Frgiles y vulnerables. En las arquitecturas de TI
tradicionales, las actividades del proceso de negocios, las aplicaciones y los datos
con frecuencia estn encerrados en silos independientes e incompatibles que son
caros de mantener y dejan a los usuarios la necesidad de navegar entre redes,
aplicaciones y bases de datos independientes para realizar tareas de negocios
concretas.
Figura 26. Antes y despus del SOA.

Al aparecer SOA, se incluye el concepto de servicios compartidos, cooperativo,


Interoperable, Integrado. Con una Arquitectura Orientada a Servicios (SOA), los
usuarios ya no tienen que iniciar sesin en varios sistemas, buscar los datos
115

relevantes e integrar los resultados manualmente. Los datos de las actividades de


los procesos de negocios se entregan como un servicio integrado, en una sola
aplicacin, en una sola pantalla, con un solo inicio de sesin.
7.2.6 Plataformas de soporte SOA
Un elemento clave del modelo de programacin SOA y de las herramientas de
apoyo al desarrollo es permitir que los roles no tradicionales no implementen
servicios y ensamblen soluciones para usarlos.
Estndares Bsicos
Las organizaciones crean sus procesos y disean sus servicios por reas
funcionales, algunas apoyan otras reas dentro de la organizacin y otras forman
parte de reas estratgicas de la organizacin. Se necesita un conjunto de
herramientas, aplicaciones y tecnologas para facilitar el desarrollo y la integracin
de la arquitectura en la empresa.
XML (Extensible MarkupLanguage)
Es un meta lenguaje basado en el estndar genrico de los lenguajes de etiquetas
SGML, que surge para alentar a las organizaciones a tomar el control de su
informacin incluyendo mecanismos para que esta pueda ser transmitida a travs
de la web.
Los

servicios

web

por

ser

multiplataforma,

debido

su

organizacin

arquitectnica, utiliza XML que es uno de los estndares de la red ms


importantes, ya que al no tener un formato propietario y reducirse simplemente a
cadenas de caracteres, constituye el medio de comunicacin multiplataforma por
excelencia, aportando esa neutralidad tan deseable en la red. As que se puede
asegurar que XML supone una de las bases de la Arquitectura de SW. Otra
propiedad importante de XML es que al ser un meta-lenguaje, permite distinguir
dentro de los mensajes entre los datos tiles y los datos referentes al protocolo

116

que se est utilizando. Esto ltimo, es til, entre otras cosas, para agilizar y hacer
ms sencillas algunas de las tareas de procesamiento. XML, como tecnologa, se
apoya sobre otros estndares y especificaciones, tales y como pueden ser la
especificacin

de

XML

(sus

diferentes

versiones),

XML

SchemaDescriptionLanguage, XML DTD, XPath, etc. Aunque la base tecnolgica


de la Arquitectura de SW slo contempla las especificaciones de XML, XML
SchemaDescriptionLanguage y la especificacin Base de XML.
WSDL (Web Service Description Language) 30
Es el mecanismo utilizado por los servicios web para exponer su funcionalidad por
medio de un documento en el cual se define toda la informacin relativa a esta.
Las definiciones del servicio WSDL proveen documentacin destinada a los
sistemas distribuidos y hace las veces de especificacin para automatizar los
detalles involucrados en las aplicaciones de comunicacin.
Un documento en WSDL define los servicios como una coleccin de nodos de red
o puertos. En WSDL, las definiciones abstractas de los nodos y los mensajes se
separan del uso concreto en la red o del formato de datos al que estn ligados, ya
que se describe de manera genrica. De esta forma, podemos reutilizar las
definiciones abstractas: como messages, que son las descripciones abstractas de
los datos que estn siendo intercambiados, y los tipos de puerto (porttypes), que
son las colecciones abstractas de operaciones. El protocolo concreto y las
especificaciones del formato de los datos para un tipo de puerto en concreto,
constituyen una vinculacin que se puede reutilizar en funcin de nuestro
contexto. Un puerto se define asociando una direccin de red a una vinculacin
reutilizable, y una coleccin de estos puertos definen un servicio.

30 Ignacio Garca, Macario Polo, Francisco Ruiz, Mario Piattini (2005), Servicios Web.

Universidad de Castilla-La Mancha, Espaa.

117

Figura 27. Definicin de un servicio con WSDL

Fuente: Ignacio Garca, Macario Polo, Francisco Ruiz, Mario Piattini (2005), Servicios
Web.

SOAP (Simple Object Access Protocol)


SOAP es un protocolo que proporciona un mecanismo estndar de empaquetar
mensajes. Este protocolo est pensado para el intercambio de informacin en
entornos descentralizados y distribuidos. Usa las tecnologas relacionadas con
XML a fin de definir un marco de trabajo extensible para los mensajes. Provee una
estructura de mensajes capaz de ser intercambiada sobre una gran cantidad de
protocolos de soporte. Este marco ha sido diseado con el fin de que fuera
independiente del cualquier modelo de programacin y otras implementaciones de
semnticas.

118

Figura 28. Composicin de un mensaje SOAP sobre HTTP

Los mensajes utilizados por SOAP se componen de dos partes: La cabecera y el


cuerpo. En la primera encontramos meta datos con informacin sobre
enrutamiento, transacciones u otra informacin sin limitaciones de ningn tipo. En
la segunda, tambin conocida como carga til del mensaje SOAP se encuentra un
mensaje XML estndar que contiene la informacin a transmitir. Por ltimo, todo el
mensaje ser transmitido a su vez como carga de otro protocolo superior que
normalmente es HTTP.
UDDI (Universal Description, Discovery, and Integration)
UDDI provee un mtodo estandarizado para la publicacin y el descubrimiento de
informacin sobre los SW. Esta iniciativa parte de la industria, que pretenda crear
una plataforma independiente, un marco de trabajo abierto para la descripcin de
servicios, descubrimiento de organizaciones y la integracin de servicios de
negocio. UDDI se centra en el proceso de descubrimiento dentro de la arquitectura
orientada a servicios.
Los SW se estn convirtiendo en la base del comercio electrnico en muchos
sentidos, y en este sentido, las organizaciones invocan los servicios creados por
otras compaas para realizar sus transacciones de negocio. Para descubrir y
encontrar los SW que se pudieran necesitar para la organizacin, hay que utilizar
algn medio que permita realizar la bsqueda y descubrimiento de los SW.
Afrontar esta empresa por si mismos se convertira en una labor titnica y en la
que seguramente se dejaran sectores y compaas sin explorar.
119

UDDI es un nico registro conceptual distribuido a lo largo de multitud de nodos


que replican la informacin unos de otros. UDDI pretende ser la solucin al
descubrimiento y la integracin de SW, que de otra forma, sera una labor
inabordable.
UDDI constituye un registro en el que las empresas dan de alta los SW que
desarrollan, a fin de que posibles usuarios interesados en hacer uso de esos
servicios para realizar determinadas acciones en sus negocios, puedan
encontrarlos sin demasiada dificultad.31

7.2.7 Tecnologas para desarrollo


Las plataformas ms utilizadas para desarrollar soluciones basadas en SOA, y las
mejores alternativas, son J2EE y .Net. Cada una de ellas posee sus ventajas y
desventajas, depende sobre qu restricciones tenga el negocio y qu atributos de
calidad son los que deben ser tomados como prioritarios; partiendo de esa
informacin se puede tomar una decisin.
La arquitectura .NET es un proyecto desarrollado por Microsoft que da nfasis en
transparencia de red, es decir que sus protocolos tienen la capacidad de transmitir
datos a travs de la red de manera que sea transparente para aquellos que estn
usando el protocolo. Est dividida en tres capas que son: presentacin, negocio y
acceso a datos.
El Framework de .NET es un conjunto de servicios de programacin diseados
para simplificar el desarrollo de aplicaciones en el entorno altamente distribuido de
Internet. .NET Framework incluye CLR (entorno en tiempo de ejecucin de
lenguaje comn) y bibliotecas de clases. Cuando se compila cualquier cdigo
fuente soportado por .NET en realidad se compila a MSIL. Para poder ejecutar
31 Patricia Bazn (2009), Un modelo de integrabilidad con SOA y BPM

120

MSIL se debe convertir mediante un compilador JIT o jitter a cdigo de mquina


que se ejecuta en la plataforma del cliente.14
J2EE es la arquitectura creada por Sun para el desarrollo de todo tipo de
aplicaciones para empresas y usuarios en general. Sun lo define como un
estndar para el desarrollo de aplicaciones empresariales multicapa. A diferencia
de la plataforma .NET, J2EE solamente soporta el lenguaje Java. Las aplicaciones
Java estn tpicamente compiladas en un lenguaje intermedio llamado bytecode,
que es normalmente interpretado o compilado a cdigo nativo mediante la JVM. La
JVM se sita en un nivel superior al hardware del sistema, y este acta como un
puente que entiende tanto el bytecode, como el sistema sobre el que se pretende
ejecutar.
Las aplicaciones realizadas en J2EE se pueden dividir en 2, 3 o ms capas. En la
primera capa es donde se encuentran las interfaces como pginas JSP, Servlet y
Applet. En la segunda capa se encuentra los componentes EJB, los servicios Web
y toda la lgica de negocio. La ltima capa es para acceder a Bases de Datos.
Cada una de estas capas pueden subdividirse en subcapas.

121

8. METODOLOGIADE DESARROLLO DE APLICACIONES INTEGRANDO LAS


ARQUITECTURAS ORIENTADA A SERVICIOS (SOA) Y GESTION DE
PROCESOS DE NEGOCIO (BPM).
La presente metodologa se crea con el propsito de abordar problemas que
involucren la interoperabilidad de procesos con servicios, un marco metodolgico
debe proveer un conjunto de etapas y sus actividades, que acompaen el ciclo de
vida de los procesos y el ciclo de vida del software, buscando reducir la brecha
entre la conceptualizacin del problema (en las etapas iniciales del ciclo de vida) y
la pieza de software que resuelve dicho problema.
Este marco metodolgico consiste en una serie de fases basadas en los ciclos de
vida de las arquitecturas SOA y BPM.
8.1 FASE 1: Anlisis del Negocio
El anlisis del negocio es la primera etapa, consiste en estudiar detalladamente el
funcionamiento de la organizacin. Esta fase va dese el principio hasta el final de
la metodologa, cubriendo todas las dems fases, pues a medida que se analizan
los procesos, servicios, componentes se alcanza una mayor comprensin del
negocio.
Analizar el negocio permite tener una visin global, un panorama positivo o
negativo de la organizacin, una idea sobre las posibilidades de TI a implementar
como parte de la solucin.
Recurriendo al lenguaje matemtico, esta primera fase otorga el poder de analizar
si el alcance del impacto deseado

id

supera el alcance del impacto logrado

, cuando se haya aplicado la metodologa completamente.

122

il

i d +i l=100

Es de mucha ventaja llevar a cabo el anlisis del negocio, esto garantiza que toda
la organizacin hable en un mismo idioma, y que clientes, usuarios,
desarrolladores y todos los involucrados entiendan sobre el funcionamiento del
negocio.
8.1.1 Subfases
El negocio debe estar soportado en un sistema de informacin, el cual brinda
estabilidad a los procesos, para que las personas puedan llevar a cabo las
diferentes actividades y de esta manera se puedan cumplir los objetivos de la
organizacin: ofrecer sus productos a los clientes por medio de servicios.
Figura 29. Anlisis del Negocio

Fuente: Elaboracin propia


A partir de lo anterior se construyeron 3 subfases claves en el anlisis del negocio:

123

Tabla 3. Anlisis del negocio


Anlisis del Negocio
Identificacin Procesos

Anlisis del contexto

Identificacin Sistemas

- Objetivos negocio

- Actividades

de Informacin
- Detallar las tecnologas

- Productos y servicios

- Roles/Personas

de la informacin (TI)

- Clientes/ usuarios

- Recursos Tecnolgicos
-

Necesidades

del

negocio
Fuente: Elaboracin propia
Anlisis del contexto:
Los procesos giran en torno a los objetivos del negocio, por lo cual son los
primeros en analizarse. De esta forma se eliminan aquellos que no dan un valor
agregado, y se verifica el cumplimiento de las polticas, normas y reglas del
negocio.
Se analizan tambin los productos y servicios que brinda la organizacin, con sus
caractersticas y el tipo de cliente al que van dirigidos.
Identificacin procesos:
Un proceso de negocio es un conjunto de tareas o actividades relacionadas
lgicamente, llevadas a cabo para lograr un resultado de negocio definido. En
esta subfase se procede a identificar cada proceso, con sus respectivas entradas,
funciones, salidas y persona encargada (Roles), relaciones entre procesos y
secuencia entre los mismos.

124

Cuando se analiza la estructura de los procesos, se extrae la informacin de cmo


est dividido el trabajo, y de las competencias de talento humano que desarrolla
cada proceso.
Tabla 4. Identificacin de Procesos
Proceso#

Identificacin de procesos
Nombre_Proceso
Descripci Encargado
n
(Rol)
Fuente: Elaboracin propia

Entrada

Salida

Identificacin Sistemas de Informacin:


Figura 30. Identificacin Sistema de informacin
Objetivo
s

reas
de
mejora

Productos

Anli
sis
del
Nego
cio

Recurs
os

Clientes
/
usuarios

Activida
des

TI
Roles/
persona
s

Fuente: Elaboracin propia


Identificar el estado del sistema de informacin (hardware, software, redes) sobre
el cual estn soportados los procesos de negocio, permite sacar conclusiones
sobre la organizacin. Un buen sistema de informacin articula todos los sistemas
de gestin con que opera la empresa, integra los procesos y roles facilitando as la
125

operacin de repositorios de informacin y de secuencia en el desarrollo de las


actividades del proceso modelado bajo BPM/SOA.
El anterior esquema muestra los elementos

que deben identificarse en esta

primera fase, para tener un diagnstico claro del estado de la organizacin:


8.1.2 Resultados Esperados
Al concluir la primera fase: Anlisis del negocio, se espera haber alcanzado lo
siguiente:
Visin general y especfica del negocio
Establecimiento de objetivos
Identificacin clientes/usuarios actuales y potenciales
Portafolio de productos y servicios
Identificacin de reas con falencias
Diagnstico tecnolgico de la organizacin

8.1.3 Actividades, Roles y Productos


126

Tabla 5. Actividades, roles y productos.


Actividades
Anlisis del contexto

Roles
Analista
Arquitecto del
negocio
Arquitecto de
sistemas

Productos
Documento con:
-Objetivos

generales

especficos del negocio.


- Listado de Productos y
servicios.
- Base de datos Clientes/
usuarios

Identificacin de
procesos

Arquitecto de
procesos

Documento con:
- Actividades
-Roles/Personas
-Relacin actividades /
roles personas

Identificacin de sistemas
de informacin

Analista de
sistemas

Documento con
- Listado Recursos
tecnolgicos:
*hardware
*software
*redes

Fuente: Elaboracin propia


8.2 FASE 2: ANALISIS DEL PROCESO DE NEGOCIO
Una vez analizado el negocio, se procede a estudiar los procesos que componen
el negocio, con el propsito de resaltar debilidades y fortalezas para mejorar el
rendimiento de stos.
Un anlisis de procesos de negocios puede identificar las fallas y a su vez la
pronta correccin de stas, puede reducir los costos y mejorar la calidad de sus
rendimientos.

127

El anlisis de los procesos de negocio permite medir la inteligencia del negocio,


identificar falencias, responsables, fallas tecnolgicas, pero tambin proporcionara
informacin para cortar la raz de los problemas y tomar acciones correctivas para
mejorar los procesos.
Todo proceso contiene unas entradas, y unas salidas. Es de suma importancia
analizar detalladamente su funcionamiento para la prevencin, deteccin y
correccin de fallas. En esto consiste el estudio de los procesos, en una forma
integral de modelar, optimizar, controlar y realizar mejora continua de ellos en la
organizacin.
8.2.1 Subfases
Se han construido las siguientes 4 subfases (en orden ascendente) para el anlisis
de los procesos de negocio.

128

Figura 31. Subfases para el anlisis de los procesos de negocio

Implementacin y
auditora del proceso
de negocio
Modelado del proceso
de negocio
Rediseo del proceso
de negocio
Identificacin del
Proceso de Negocio

Fuente: Elaboracin propia

Tabla.6 Subfases del Anlisis del proceso de negocio


Anlisis del Proceso de Negocio
Implementaci
Identificacin del

Rediseo del

Modelado del

n y auditora

proceso de negocio

proceso de negocio

proceso de

del proceso de

negocio

negocio

- Nombre Proceso

- Situacin actual

- Responsable

- Descripcin de la - Modelado BPMN

- Funciones

modificacin

- Actividades

- Ventaja de la
129

-Mapa procesos

- Bpa

- Nivel Repeticin

modificacin

- Nivel
Automatizacin
Fuente: Elaboracin propia
Subfases del Anlisis del proceso de negocio
Identificacin del proceso de negocio: con el objetivo de clarificar la primera
Subfase, se presenta la tabla 7. Donde se especifica cada aspecto a tener en
cuenta al analizar un proceso de negocio. Es de suma importancia conocer el
nombre del proceso, subprocesos, el perfil de la persona encargada, la frecuencia
con la que se lleva a cabo semanal, el objetivo del proceso, funciones, actores o
personas involucradas, si cuenta o no con tecnologas de apoyo, sobre que
normas operacionales funciona, riesgos, entre otras.

Tabla 7. Identificacin del proceso de negocio


N Proceso:
N Subproceso:

Identificacin del proceso de negocio


Nombre Proceso:
Nombre

Responsable:

Subproceso:
Fecha:

Perodo
:

Nivel Repeticin:
Objetivo:

rea:

Producto:
Tecnologas de apoyo:

130

Actividades:
Riesgos:
Observaciones:
Fuente: Elaboracin propia
Rediseo del proceso de negocio: El propsito principal de analizar los
procesos de negocio es poder tomar medidas correctivas sobre las falencias de la
organizacin. La idea es identificar las debilidades operativas y organizativas de
los procesos, sus posibles riesgos, para poder implementar soluciones que
contribuyan al buen funcionamiento de los procesos de negocio de la empresa.
Se recomienda realizar el anlisis del proceso de negocio, y su respectivo
rediseo conjuntamente con el talento humano que participa en cada proceso, y
los especialistas en procesos, y sistemas de informacin para integrar de manera
eficiente cada rea con los objetivos estratgicos de la organizacin.
Tabla 8. Rediseo del proceso de negocio

Fuente: Elaboracin propia

131

MEJORA
Virtualizacin

MODIFICACIN

Modelado del proceso de negocio:

DE LA

MODIFICACIN

Automatizacin

DE LA

Agilizacin

ACTUAL

NATURALEZA

Simplificacin

REDISEO DEL PROCESO DE NEGOCIO


SITUACIN DESCRIPCIN
VENTAJA DE LA

Unificacin

PROCESO

Un modelo es una representacin de una realidad compleja. Modelar es


desarrollar una descripcin lo ms exacta posible de un sistema y de las
actividades llevadas a cabo en l.
Segn Mahecha (2012), Los mapas de proceso permiten identificar claramente los
individuos que intervienen en el proceso, la tarea que realizan, si son paralelas o
secuenciales, a quin afectan cuando su trabajo no se realiza correctamente, y el
valor de cada tarea o su contribucin al proceso.

Cuando se haya analizado el negocio y sus procesos, y se haya rediseado


aquellos que presentaron inconsistencias se procede a realizar los mapas de
procesos para luego emplear el estndar BPMN.

Se busca modelar el proceso de negocio, en trminos de los servicios ofrecidos


por las aplicaciones existentes, y de las tareas de usuarios interactivos. El modelo
de procesos de negocio describe todos aquellos procesos transversales a las
reas de la organizacin que producen bienes y servicios que son de valor para
los clientes. Los macro procesos se describen y descomponen utilizando una
notacin. La lgica de los procesos se puede describir con las notaciones BPMN
(Business Process Management Notation).
Se usar el modelado del proceso de negocio BPMN como estndar de notacin
para su especificacin y para su ejecucin el esquema de procesos BPEL. Los
procesos de negocio especificados en BPMN y traducidos a BPEL sern entonces
ejecutados por motores de procesos BPMS. El motor de ejecucin BPMS permite
elaborar el modelado de los flujos de trabajo, efectuar simulaciones, integrar

132

aplicaciones, ejecutar los procesos, recabar mediciones respecto a dichas


ejecuciones y efectuar mejoras nuevamente a travs del modelado.
Implementacin y auditora del proceso de negocio
Luego de modelado el proceso de negocio, est listo para implementarse en un
lenguaje de programacin, y proseguir con el monitoreo del comportamiento de
estos para obtener mtricas resultantes y comparar los avances logrados. BAM o
Monitoreo de la Actividad del negocio, fue inicialmente presentada por GartnerInc
y se refiere a la recopilacin, anlisis y presentacin de informacin en tiempo real
sobre las actividades al interior de las empresas y que involucra a los clientes y a
los socios de negocios.
8.2.2 Resultados Esperados
Al concluir la segunda fase (Anlisis del proceso de negocio), se espera haber
alcanzado lo siguiente:
Documento identificacin del proceso de negocio
Documento rediseo del proceso de negocio
Mapa de procesos
Modelado BPM
Diagramas de procesos
Identificacin de soluciones y estrategias a implementar
Anlisis de riesgos y seguridad
Informe de monitoreo y seguimiento de los procesos
8.2.3 Actividades, Roles y Productos
Tabla 9. Actividades, Roles y Productos
Actividades

Roles
133

Productos

Identificacin del
proceso de negocio

Analista/Arquitecto
del negocio.
Arquitecto sistemas
Arquitecto de
procesos

Documento con Datos


del proceso de negocio:
- Nombre Proceso
- Responsable
- Funciones
- Actividades
- Nivel Repeticin
- Nivel Automatizacin

Rediseo del proceso


de negocio

Arquitecto del
negocio
Arquitecto de
sistemas

Documentos con:
- Debilidades
- Fortalezas
- Correcciones a
implementar

Modelado del proceso


de negocio

Implementacin y
auditora del proceso de
negocio

Arquitecto del
negocio
Arquitecto de
sistemas
Arquitecto del
negocio
Arquitecto de
sistemas

-Casos de uso del


sistema
-Mapa de procesos
-Diagrama BPMN
-Mtricas de los
procesos.

Fuente: Elaboracin propia


8.3 FASE 3: Anlisis y diseo de servicios
Analizar los servicios, permite emitir un dictamen sobre el estado de los procesos
de negocio. Una aplicacin SOA est formada por un conjunto de servicios
interconectados entre s, cuyo objetivo es automatizar uno o varios procesos de
negocios. Cumplir con esta fase implica realizar un estudio detallado de los
servicios, identificando las caractersticas, relacin y la manera como estn
integrados. Esto nos permite asignar servicios a componentes, y emplear la
reutilizacin, orquestacin y coreografa de servicios.

134

El poder de SOA reside en su capacidad para brindar agilidad al negocio a travs


de la integracin y la reutilizacin de los procesos de negocios. SOA logra este
objetivo de dos maneras: alentando soluciones organizadas en torno a servicios
reutilizables que encapsulan capacidades funcionales independientemente de su
implementacin y brindando facilidades para gestionar el acoplamiento de las
capacidades funcionales. El modelado puede servir para cerrar la brecha que
existe entre los requerimientos de negocios y la solucin basada en servicios
implementada.
8.3.1 Subfases
Tabla 10. Subfases del Anlisis y Diseo de servicios
Anlisis y diseo de servicios
Identificacin de
Asignar servicios a
Orquestacin
servicios
- Portafolio servicios

componentes
-Identificacin

de servicios
-Secuencia de

actuales

componentes

servicios

-Relacin entre

-Integracin

servicios

servicios con

-Integracin

componentes

servicios
Fuente: Elaboracin propia
Identificacin de servicios: Se analizan uno a uno los servicios con el propsito
de constituir un portafolio de servicios. Este inventario contendr los servicios
actuales y nuevos o a implementar. Es de gran importancia identificar la relacin
que hay entre ellos, para luego integrarlos con los objetivos de la empresa, de esta
manera se evita caer en duplicidad o inconsistencias en nuevos servicios, y as los
datos mantengan su integridad. Puede ser que se deban implementar servicios
intermediarios para reutilizar otros servicios que no se adapten totalmente a los
requerimientos de la aplicacin. En lugar de promover nuevos servicios, se debe
favorecer la reutilizacin de servicios y aplicaciones ya existentes.

135

Asignar servicios a componentes: Luego de contar con la lista de servicios,


estos se asignan a componentes, los cuales deben implementarse para que
proporcionen los servicios correspondientes. En otras palabras, a cada
componente se le deben especificar los servicios que provee.
Para cada componente se indicarn las reglas del Negocio y servicios que
implementa, as como otros componentes que utiliza.
Orquestacin Servicios: Consiste en establecer la secuencia de interaccin
entre servicios que es necesaria para realizar los procesos del Negocio
identificados. Se busca describir la interaccin entre todos los servicios
involucrados.
La orquestacin de servicios para la implementacin de procesos de negocio se
muestra para cada proceso en un diagrama de secuencia que describa la
interaccin entre los distintos servicios involucrados. Se utilizar preferiblemente
una herramienta BPMS para definir, ejecutar y gestionar la orquestacin de dicho
servicio.
8.3.2 Resultados esperados
Al culminar esta fase Anlisis de Servicios, se espera haber alcanzado lo
siguiente:
Portafolio de servicios vigentes y a implementar.
Tabla que muestre la relacin entre servicios
Esquema sobre integracin de los servicios
Documento identificacin de componentes y servicios
8.3.3 Actividades, Roles y Productos
Tabla 11. Actividades, Roles y Productos
Actividades

Roles
136

Productos

Analista/ Arquitecto
del negocio
Arquitecto Sistemas
Desarrollador

Identificacin de
servicios

- Portafolio servicios
actuales
-Portafolio servicios a
implementar
-Relacin entre servicios
-Descripcin de

Creacin nuevos
servicios

Arquitecto Sistemas
Desarrollador

Integracin servicios
- Lista servicios faltantes
- Creacin nuevos
servicios
- Seleccin servicios a

Asignar servicios a
componentes

Arquitecto Sistemas
Desarrollador

reutilizar
-Identificacin
componentes
-Integracin servicios

Orquestacin de

Arquitecto Sistemas
Desarrollador

servicios

con componentes
-Descripcin de la
interaccin entre los
servicios.
-Ejecutar y gestionar la
orquestacin del servicio

Fuente: Elaboracin propia


8.4 FASE 4: Desarrollo
La eleccin del lenguaje de programacin y el ambiente de desarrollo determinar
la forma fsica del servicio y los procesos de negocio orquestados de acuerdo con
sus diseos.
Tecnologas para desarrollo

137

Las plataformas ms utilizadas para desarrollar soluciones basadas en SOA, y las


mejores alternativas, son J2EE y .Net. Cada una de ellas posee sus ventajas y
desventajas, depende sobre qu restricciones tenga el negocio y qu atributos de
calidad son los que deben ser tomados como prioritarios; partiendo de esa
informacin se puede tomar una decisin.
La arquitectura .NET es un proyecto desarrollado por Microsoft que da nfasis en
transparencia de red, es decir que sus protocolos tienen la capacidad de transmitir
datos a travs de la red de manera que sea transparente para aquellos que estn
usando el protocolo. Est dividida en tres capas que son: presentacin, negocio y
acceso a datos.
El Framework de .NET es un conjunto de servicios de programacin diseados
para simplificar el desarrollo de aplicaciones en el entorno altamente distribuido de
Internet. .NET Framework incluye CLR (entorno en tiempo de ejecucin de
lenguaje comn) y bibliotecas de clases. Cuando se compila cualquier cdigo
fuente soportado por .NET en realidad se compila a MSIL. Para poder ejecutar
MSIL se debe convertir mediante un compilador JIT o jitter a cdigo de mquina
que se ejecuta en la plataforma del cliente.
J2EE es la arquitectura creada por Sun para el desarrollo de todo tipo de
aplicaciones para empresas y usuarios en general. Sun lo define como un
estndar para el desarrollo de aplicaciones empresariales multicapa. A diferencia
de la plataforma .NET, J2EE solamente soporta el lenguaje Java. Las aplicaciones
Java estn tpicamente compiladas en un lenguaje intermedio llamado bytecode,
que es normalmente interpretado o compilado a cdigo nativo mediante la JVM. La
JVM se sita en un nivel superior al hardware del sistema, y este acta como un
puente que entiende tanto el bytecode, como el sistema sobre el que se pretende
ejecutar.

138

Las aplicaciones realizadas en J2EE se pueden dividir en 2, 3 o ms capas. En la


primera capa es donde se encuentran las interfaces como pginas JSP, Servlet y
Applet. En la segunda capa se encuentra los componentes EJB, los servicios Web
y toda la lgica de negocio. La ltima capa es para acceder a Bases de Datos.
Cada una de estas capas pueden subdividirse en subcapas.

Anlisis comparativo J2EE vs .Net

En un artculo publicado en la Revista Colombiana se hizo un estudio el cual


consisti en comparar J2EE y .Net. Se trabaj con el IDE Netbeans 6.5 por parte
de J2EE y Visual Studio 2008 por parte de .Net. Se partieron de esas
herramientas por su robustez y se seleccionaron esas versiones porque fueron las
ms recientes para su tiempo. Los criterios de comparacin que se han
seleccionado son: seguridad, portabilidad, interoperabilidad y desempeo. En la
siguiente tabla se muestra las diferencias entre cada uno:

J2EE vs .Net en tecnologas SOA


Criterio
Seguridad

Tabla 12. Comparacin entre Tecnologas SOA


J2EE
.NET
Resultado
La
plataforma WSIT es una En el momento
J2EE a travs de especificacin de de implementar
sus servidores de tecnologas
ambas
aplicaciones,
abiertas
de plataformas
soporta
varias servicios
Web muestran cierto
especificaciones
pensada
para grado
de
de
seguridad, interoperar
en simplicidad,
entre
estas forma
eliminando
en
especificaciones
transparente con ese aspecto la
139

Portabilidad

Interoperabilidad

se
encuentra tecnologa trata
WS-Security.
aspectos claves
de
interoperabilidad
como: arranque y
configuracin,
mensajera
confiable, manejo
de transacciones
y seguridad a
nivel
de
mensajes.
Generalmente los A travs de CLR
proyectos
de se
consigue
servicios
Web que .NET sea
realizado
en una
plataforma
estos
IDE de
ejecucin
generan
una independiente del
extensin (.WAR) lenguaje,
o
que contiene toda comnmente
la aplicacin; este conocido
como
archivo se puede multilenguaje, lo
transportar
a que
permite
diferentes
integrar
sistemas
desarrolladores
operativos y es de
distintos
posible
perfiles. Aunque
desplegarlo para esto
en
ser
accedido ocasiones
mediante
un presenta ciertas
cliente, utilizando ventajas en otras
algn servidor de se convierte en
aplicacin
que una desventaja,
soporte
las ya que, mantener
caracterstica con un proyecto en
que se cre el mltiples
servicio Web.
lenguajes
es
costoso.
-----

140

ventaja de una
plataforma frente
a la otra.

La portabilidad de
.NET a travs del
PE
(Ejecutable
Portable
que
contiene MSIL y
los
metadatos
requeridos)
es
mucho menor a
la obtenida con
J2EE, ya que, no
existen versiones
del CLR para la
mayora de los
sistemas
operativos, solo
para
las
versiones
de
Windows.

Ambos
son
interoperables
siempre y cuando
no se utilicen
libreras
especficas
de
.net, tal como el
dataset, para los

tipos de datos
que se enviarn
como mensajes
SOAP.
Desempeo
La prueba se La prueba se El rendimiento de
realiz con 25 realiz con 25 bytes/s
usuarios virtuales usuarios virtuales presentado
en
con repeticiones con repeticiones GlassFish
fue
por usuarios de por usuarios de menor que el
500.
500.
presentado en el
J2EE
recibi .NET que aunque IIS, ya que se
12500 peticiones respondi 12500 presentaron
que equivalen a peticiones,
valores mximos
los 25 usuarios recibi ms de aproximados de
virtuales
esa cantidad, ya 21000 bytes/s y
activados
con que,
se de 72000 bytes/s
repeticiones por generaron
respectivamente.
cada uno de 500, algunos errores El
estudio
el cual respondi de denegacin de concluye que un
todas
las IP (error 403), WS
.NET
peticiones
que
trae
por responde
ms
generando
defecto IIS para rpido que un
respuesta
para defenderse
de servicio
Web
cada usuario.
ataque DoS.
EJB.
Fuente: MSc. Luz Marina Santos Jaimes, Ing. Jorge Omar Portilla Jaimes e Ing.
John Jairo Mndez, plataformas j2ee y .net en el desarrollo de servicios web

Herramientas para desarrollo


Para cada tecnologa existe todo un kit de herramientas que permiten facilitar el
trabajo de creacin y/o modificacin de web services. Desde el punto de vista de
lgica asociada (funciones de los servicios) y tambin la manera en que manipula
los XML (SOAP, WSDL, UDDI, XSD, WS-BPEL, etc.).
Para la tecnologa J2EE se presentan algunos ejemplos segn la siguiente tabla:

141

Tabla 13. IDEs para J2EE que proveen herramientas SOA


IDE
Netbeans
Eclipse
JDeveloper
Web Sphere Studio

Plug-in/Herramienta
Netbeans SOA
SOAPUI
Oracle SOA
Rational SOA lifecycle

8.5 FASE 5: Pruebas


La fase de pruebas permite definir los elementos a probar, para luego revisar
formalmente el cdigo para asegurase que cumple con los requisitos del negocio.
Aplicar prueba a los servicios, ayudar a detectar defectos o fallos en el software,
asegurar que la secuencia de llamadas a servicio, realizada a diversos sistemas
no deje a ninguno de los sistemas en un estado incoherente. Se debe probar la
seguridad del software, verificar temas de interoperabilidad entre marcas,
lenguajes y sistemas operativos.
En esta fase se aplican las siguientes pruebas a los elementos de servicios, los
procesos de negocio, las interacciones entre los procesos y las conexiones entre
servicios:
Figura 32. Implementacin y ejecucin de pruebas

142

143

Figura 33. Pruebas No Funcionales


Fuente: Elaboracin propia
Esta fase probar que la solucin tcnica de la arquitectura
SOA ha dado los requerimientos del negocio definido y ha
sido aceptado por el usuario.

De sistema
Unitarias

Se prueban los componentes de servicios y se verifica que la


funcionalidad bsica de los componentes y funciones dentro de
un servicio estn trabajando como lo especificado. Cada
componente es probado por separado antes de integrarlo
dentro de un servicio o servicios.

De
servicio

Garantiza que el servicio no solo cumpla los requisitos del


proyecto actual, sino tambien los requerimientos operacionales
y de negocio de los otros procesos que estn usando ese
servicio.

De
Integraci
n

Determina si el comportamiento de la interfaz y la informacin


compartida entre los servicios, est trabajando como lo
especificado, que se cumpla con las normas, validacin del
formato y datos.

De
Orquestaci
n

Aseguran que los servicios estn funcionando (disponibles)


colectivamente como lo especificado. Cubre la lgica del
negocio, la ordenacin en secuencia, manipulacin de
excepciones y descomposicin de procesos

144

Fuente: Elaboracin propia


Las diferentes plataformas y herramientas de desarrollo
a nivel de empresa, hace que los desarrolladores utilicen
diferentes herramientas para generar los contratos de
servicios y modificar el proceso. Por esto se requiere
verificar temas de interoperabilidad entre marcas,
lenguajes y sistemas operativos (virtualizaciones),
adems, dejar muy claras las plataformas involucradas.

De
interoberabili
dad
De Agilidad

Se requiere de una comprensin completa de los


requisitos para el cual el servicio es diseado. Se
identifica nlas partes cambiantes de los requisitos, ya
que la agilidad abarca todo acerca de ellos a travs de la
configuracin de los parmetros, las normas y polticas.
Se aplica stress de servicios y el stress de procesos de
negocio.

De
Seguridad

La exposicin de servicios a consumidores y de servicios


de al mundo exterior abre una serie de vulnerabilidades,
como ataques, grandes volmenes de datos de spam,
etc. Por tanto las polticas de seguridad se deben aplicar
a nivel de red, nivel intermedio y en el punto de nivel
final para crear las pruebas

9. APLICACIN DE LA METODOLOGIA PLANTEADA A UN PROCESO DE LA


INSTITUCION PRESTADORA DE SERVICIOS DE SALUD (IPS) DE LA
UNIVERSIDAD POPULAR DEL CESAR
La seccin de servicios mdicos asistenciales (IPS) de la Universidad Popular del
Cesar, tiene como misin coordinar las actividades y programas orientados a la
promocin de la salud y prevencin de la enfermedad, as como programar las
actividades de salud ocupacional, cultivar hbitos y estilos de vida saludables para
mejorar las condiciones fsicas y psquicas de toda la comunidad acadmica; para
ello brinda servicios bsicos tales como: medicina general, odontologa, psicologa
y examen de laboratorio a travs de un laboratorio clnico, permitiendo adems la
remisin a centros de especialistas en: optometra, ginecologa, oftalmologa,
ortopedia, dermatologa, urologa, neurologa, ortodoncia, oncologa, ciruga
general, citologa, terapia fsica y respiratoria, electrocardiograma, ecografa y
radiologa.
La metodologa planteada se desea aplicar al proceso de Citas Mdicas de la IPS
de la Universidad Popular del Cesar, desarrollando paso a paso cada fase
diseada como lo indica la siguiente tabla.
Tabla 14. Fases de la metodologa
FASES
Anlisis del negocio
Anlisis del proceso de negocio
Anlisis y diseo de servicios
Desarrollo
Pruebas
Fuente: Elaboracin propia

FASE 1: Anlisis del negocio


145

Anlisis del contexto:


-Objetivos del negocio:
Objetivo General:
Contribuir al mejoramiento de la calidad de vida y salud de la poblacin estudiantil,
integrando la perspectiva de salud pblica como componente esencial de la
prestacin de los servicios de salud por parte de las IPS, para lograr dinmicas
accesibles, flexibles, participativas y que respondan a las necesidades de la
poblacin.
Objetivos Especficos:
*Brindar servicio odontolgico a los estudiantes de la universidad
promoviendo la salud oral.
*Ofrecer atencin medica psicolgica a los estudiantes que lo necesiten.
*Atender las emergencias, casos especiales y citas programadas en pro del
mejoramiento y prevencin de salud de la poblacin estudiantil.
-Productos y servicios:
*Servicios de primeros auxilios.
*Servicios medicina general.
*Servicios odontolgicos.
*Servicios psicolgicos
*Servicios de laboratorio clnico.
*Promocin y prevencin de la salud.
146

*Salud ocupacional.
*Carnet de seguro estudiantil.
*Medicamentos
-Clientes/Usuarios: La institucin prestadora de servicios de salud IPS, brinda su
servicio a la comunidad de estudiantes y colaboradores que hacen parte de la
Universidad Popular del Cesar.
Identificacin Procesos:
En este proyecto solo se estudia el proceso de las citas mdicas conformado por
varios subprocesos que se analizarn en la siguiente seccin.
Tabla 15. Identificacin Procesos
Proceso

Identificacin de procesos
Nombre_Proceso Descripcin Encargado

#
1

Citas_Mdicas_ip
s

Entradas

Salidas

Proceso

(Rol)
Secretaria,

Datos del Fecha,

mediante el

Estudiante

estudiant

hora y

cual se le

mdico

presta el

Mdico

que

servicio de

atender

salud a los

la cita

estudiantes,

mdica

y
colaboradores de la
universidad.
Fuente: Elaboracin propia

-Roles/personas:
147

Tabla 16. Roles/personas


Secretaria:

Persona
estudiante,

Usuario:
Mdico:

encargada
atender

de
su

recibir

el

solicitud

asignar la cita mdica.


Estudiante que solicita la cita mdica
Persona encargada de brindar el
servicio de salud
Fuente: Elaboracin propia

Identificacin Sistemas de Informacin: 32


-Tecnologas de Informacin TI, Recursos y reas de mejora:
Actualmente, los procesos de la Seccin de Servicios Mdicos con excepcin del
registro de citas mdicas son completamente manuales apoyados nicamente con
la utilizacin de herramientas ofimticas (Word y Excel). Dentro las principales
limitaciones en la organizacin y administracin de la informacin estn:
No existe un sistema que controle los recursos por contrato externo para cada uno
de los servicios mdicos en modalidad de remisin. Se requiere una solucin
donde se puedan registrar, clasificar y organizar las remisiones a centros de
especialistas; dnde dichos centros (IPS) puedan acceder en lnea y asignar las
respectivas citas y donde se lleve un estricto control en el presupuesto por servicio
asignado a cada contrato de prestacin de servicios mdicos.

Las historias clnicas de los pacientes atendidos en medicina general, odontologa


y psicologa, (estudiantes, docentes, administrativos e hijos de funcionarios) son
completamente manuales, lo que dificulta a los profesionales que prestan el
servicio tener a la mano la informacin mdica de cada uno de sus pacientes e
32Sistema de informacin para la gestin de los servicios mdicos asistenciales prestados en la ips de la universidad popular del cesar,
Jessica Pautt y Sandra Bracho 2013

148

igualmente los registros de evolucin, las formulas, los diagnsticos, entre otros.
La informacin se consigna en planillas y registros fsicos que se acumulan en
carpetas, las cuales son archivadas sin los requisitos mnimos de conservacin, y
a la vez, impide acceder con facilidad a dicha informacin el da de la cita mdica,
generando traumatismo para la eficiente prestacin del servicio, puesto que se
requiere las carpetas que contienen las historias clnicas para ser entregadas a los
especialistas.
Los servicios mdicos en las diferentes especialidades que se ofrecen no generan
ningn tipo de registro sistematizado que permita seguimiento.

Esto dificulta

tambin la generacin de indicadores para el Sistema Universitario Estatal


(indicadores SUE) y el Ministerio de Educacin Nacional (MEN). En las jornadas
que se generan de promocin y prevencin no es posible llevar un estricto control
de la participacin individual de cada miembro de la comunidad universitaria de tal
forma que se pueda medir el impacto de stas acciones en la poblacin
beneficiada. Cuando se requieren estadsticas por programa acadmico para
apoyar los procesos de autoevaluacin y registro calificado desde las variables de
bienestar universitario es casi imposible entregar esta informacin de los registros
manuales que utilizan. Como no existen estadsticas tampoco es posible analizar
datos que permitan tomar decisiones y adelantar acciones e inversiones para
mejorar el bienestar de la comunidad universitaria desde los servicios mdicos
asistenciales.
FASE 2: Anlisis del proceso de negocio
Identificacin del proceso de negocio
El proceso Citas_Mdicas_ips; cuenta con varios subprocesos, los cuales se
detallan a continuacin:
Tabla 17. Proceso Citas_Mdicas_ips
Identificacin del proceso de negocio
149

N Proceso:
N Subproceso:

01
01

Nombre Proceso:
Nombre

Citas_Mdicas_ips
Solicitud_Cita_Mdic

Responsable:

Estudiante/

Subproceso:
Fecha: 15/10/201

a
Perodo:

01

Secretaria
3
Nivel Repeticin: n veces
rea: Citas Mdicas Unicesar
Objetivo: Contemplar las diversas posibilidades de horarios y mdicos disponibles
para atender la cita mdica.
Producto: Se obtienen los diferentes horarios y mdicos disponibles para atender
la cita mdica.
Tecnologas de apoyo: Un equipo, herramientas ofimticas (Excel/word), ningn
sistema de informacin implementado.
Actividades: Estudiante debe presentarse con cdula o carnet, solicitar la cita
mdica, especificar si es medicina general, odontolgica o psicolgica.
Riesgos: No existe sistematizacin de estos procesos, lo cual genera muchos
errores manuales que pueden ocasionar que dos personas tengan una misma cita
a una misma hora, que no se le d la informacin real y exacta de los horarios y
mdicos disponibles
Observaciones: Proceso no cuenta con tecnologa, ni sistemas de informacin
implementados para brindar este servicio eficientemente a la comunidad upecista.
Fuente: Elaboracin propia

Tabla 18. Proceso Citas_Mdicas_ips


N Proceso:
N Subproceso:

01
02

Identificacin del proceso de negocio


Nombre Proceso:
Citas_Mdicas_ips
Nombre
Asignacin_Cita_Mdic
Subproceso:
150

Responsable:
Nivel

Secretaria

Fecha:

15/10/201

Perodo:

n veces

3
rea: Citas MdicasUnicesar

01

Repeticin:
Objetivo: Asignar cita mdica a estudiante de acuerdo al tope mximo de citas por
da, disponibilidad de horario y mdico.
Producto: Se obtiene la fecha exacta, y mdico asignado.
Tecnologas de apoyo: Un equipo, herramientas ofimticas (Excel/word), ningn
sistema de informacin implementado.
Actividades: Estudiante debe presentarse con cdula o carnet, solicitar la cita
mdica, especificar si es medicina general, odontolgica o psicolgica.
Riesgos: No existe sistematizacin de estos procesos, lo cual genera muchos
errores manuales que pueden ocasionar que dos personas tengan una misma cita
a una misma hora, que no se le d la informacin real y exacta de los horarios y
mdicos disponibles.
Observaciones: Proceso no cuenta con tecnologa, ni sistemas de informacin
implementados para brindar este servicio eficientemente a la comunidad upecista.

Fuente: Elaboracin propia

Tabla 19. Proceso Citas_Mdicas_ips


N Proceso:
N

Identificacin del proceso de negocio


01
Nombre Proceso:
Citas_Mdicas_ips
03
Nombre
Cancelacin_Cita_Mdic

Subproceso:
Responsable:

Estudiante/

Subproceso:
Fecha: 15/10/201

Nivel

Secretaria
n veces

3
rea: Citas Mdicas Unicesar
151

a
Perodo:

01

Repeticin:
Objetivo: Cancelar la cita mdica solicitada con anticipo, debido a que no podr
asistir por algn motivo.
Producto: Cita mdica cancelada
Tecnologas de apoyo: Un equipo, herramientas ofimticas (Excel/word), ningn
sistema de informacin implementado.
Actividades: Estudiante debe presentarse con cdula o carnet, solicitar cancelar la
cita mdica reservada anteriormente.
Riesgos: No existe sistematizacin de estos procesos, lo cual genera muchos
errores manuales que pueden ocasionar que dos personas tengan una misma cita
a una misma hora, que no se le d la informacin real y exacta de los horarios y
mdicos disponibles.
Observaciones: Proceso no cuenta con tecnologa, ni sistemas de informacin
implementados para brindar este servicio eficientemente a la comunidad upecista.

Fuente: Elaboracin propia

Tabla 20. Proceso Citas_Mdicas_ips


N Proceso:
N Subproceso:

Identificacin del proceso de negocio


01
Nombre Proceso:
Citas_Mdicas_ips
04
Nombre Subproceso: Cumplimiento_Cita
_

Responsable:

Estudiante/

Fecha:

15/10/201

Mdica
Perodo:

Medico
3
Nivel Repeticin: n veces
rea: Citas Mdicas Unicesar
Objetivo: cumplir con la cita solicitada
Producto: Diagnstico, frmula mdica.
152

01

Tecnologas de apoyo: Un equipo, herramientas ofimticas (Excel/word), ningn


sistema de informacin implementado.
Actividades: Estudiante debe presentarse con cdula o carnet para ser atendido
por el mdico, se le abre historia clnica en caso de no tenerla, sino se busca en
archivo, se le entrega un diagnstico y una frmula mdica en caso de necesitar
medicamentos, o remisin a algn especialista.
Riesgos: No existe sistematizacin de estos procesos, lo cual genera muchos
errores manuales que pueden ocasionar que dos personas tengan una misma cita
a una misma hora, que no se le d la informacin real y exacta de los horarios y
mdicos disponibles.
Observaciones: Proceso no cuenta con tecnologa, ni sistemas de informacin
implementados para brindar este servicio eficientemente a la comunidad upecista.
Fuente: Elaboracin propia

Rediseo del proceso de negocio:


Tabla 21. Rediseo del proceso de negocio
REDISEO DEL PROCESO DE NEGOCIO Citas_Mdicas_ips
NATURALEZA
PROCESO SITUACIN
DESCRIPCIN
VENTAJA DE LA

153

Virtualizacin

Automatizacin

MEJORA
Agilizacin

MODIFICACIN

DE LA

MODIFICACIN

Simplificacin

DE LA

Unificacin

ACTUAL

Solicitud_Cit
a_Mdica

Ips no cuenta

Se debe crear un

Se evita que el estudiante

con

portal

se desplace hasta la ips a

automatizaci

permita el acceso a

solicitar

n de procesos.

los estudiantes para

prestar el servicio de

Estudiante

solicitar

debe

solicitar

mdicas.

cita

mdica

web

que

su

cita.

X X

Se

sus

citas

salud ms eficientemente.

software

debe

Se agilizar el proceso, y

presencialmen
Asignacin_
Cita_Mdica

te
La encargada

El

de asignar las

mostrar las opciones

se

citas mdicas,

de

mdicos

posibilidades de error de

pierde tiempo

disponibles

al

asignar ms citas del tope

verificando

escoger determinado

establecido, o de estipular

horario, y descartar

ms de una cita con un

aquellos cuyo tope

mismo

mximo por da haya

mismo horario.

que

no

se

hayan
cumplido

los

topes

sido completado.

mximos
da

los

por

en

buscar mdico
disponible
para
determinado
horario.

154

disminuirn

mdico

las

en

un

X X X

Cumplimient

La informacin

El

o_Cita_

se

informacin

Mdica

en planillas y

contar

registros

seccin de historias

evita

fsicos que se

clnicas

documentacin, se pasa

acumulan

en

guarde un registro de

de

carpetas,

lo

todos

sistematizado.

consigna

que

impide

acceder

con

facilidad

sistema

de

Con la automatizacin de

debe

las historias clnicas se

con

una

donde

se
los

agiliza

X X

el proceso, se
la

lo

prdida
manual

de
lo

tratamientos,
enfermedades,
diagnsticos,

dicha

frmulas mdicas del

informacin el

paciente.

da de la cita
mdica.
Cancelacin

El

_Cita_Mdic
a

estudiante

En el portal web,

Se

debe

debe estar la opcin

espacio,

presentarse

de

de

estudiante. Y se evita el

mdicas,

quitarle la oportunidad a

documento de

evitando as que el

otro estudiante de tener

identificacin

estudiante

acceso a esa cita mdica.

para

desplazarse a la ips

con

su

solicitar

cancelacin

citas

la cancelacin

de

solicitud.

su

cita

deba

cancelar

ahorra

tiempo,

dinero

X X X X

al

su

mdica.

Fuente: Elaboracin propia


Modelado del proceso de negocio
-Mapa de Procesos: En la siguiente imagen se observa el mapa del proceso citas
mdicas de la institucin prestadora de salud de la Universidad Popular del Cesar.

155

Figura 34. Mapa de procesos, Citas mdicas IPS Unicesar

Fuente: Elaboracin propia


Figura 35. Diagrama caso de uso inicio de sesin usuario

Fuente: Elaboracin propia


156

Figura 36. Diagrama BPMN Iniciar sesin

Fuente: Elaboracin propia

Figura 37. Diagrama BPMN Solicitar Cita Mdica

Fuente: Elaboracin propia


157

FASE 3: Anlisis y diseo de servicios


Identificacin de servicios:
La identificacin de servicios y operaciones consiste en definir y especificar los
servicios a partir de los procesos de negocios, estableciendo la manera como se
relacionan e integran. Este modelo no representa un sistema funcional. No existe
el sentido de flujo, ni descripcin de eventos y reglas de negocios. Se han descrito
cuatro servicios esenciales en el proceso de citas mdicas de la ips.

Figura 38. Diagrama de identificacin de servicios

Inicio de
sesin
-Validar usuario
-Validar contrasea

Validar cita
mdica
-Validar hora
-Validar mdico
-Validar tipo de cita

Asignar
mdico
-Validar registro de mdico
-Validar especialidad
-Validar disponibilidad

Datos
-Validar datos
-Validar historia clnica
-Validar frmula mdica

Fuente: Elaboracin propia

158

Asignar servicios a componentes

El objetivo de un componente es dividir funcionalidad de TI en unidades mximas de


cohesin y mnimo acoplamiento; cada componente tiene exactamente un dueo y
responsabilidades para cada uno las cuales deben ser definidas tan precisamente
como sea posible. Esas responsabilidades son los puntos de partida para identificar
servicios.

El beneficio que tiene es que simplifica considerablemente la deteccin de servicios.


El esfuerzo ya se hizo en el momento en que se analiz como iban a ser organizados
los componentes. El problema es que muchos componentes solo contienen lgica que
concierne nicamente a TI lo cual desva los servicios de su enfoque principal, el cual
es dar soporte al negocio.
En la figura 23 se puede observar un diagrama de componentes de las citas mdicas
de la ips Unicesar.

Figura 39. Diagrama de componentes

Fuente: elaboracin propia.

159

Cada componente cumple una o ms responsabilidades. Por ejemplo, los


componentes rol y usuarios tienen la responsabilidad

gestin de usuarios y

permisos; los componentes de citas mdicas, clientes, datos e historias clnicas


cumplen con la responsabilidad de citas mdicas.
Diagrama de Cooperacin de aplicaciones

Figura 40: Diagrama de cooperacin de aplicaciones

Fuente: Elaboracin propia

160

Diagrama de estructuras de aplicaciones


Figura 41. Diagrama de estructuras de aplicaciones

Fuente: Elaboracin propia

161

Tabla 24. Listado de aplicaciones


ID

NOMBRE

AP1

Portal

AP2

Ingreso al Sistema

AP3

ESB

AP4

Data Warehouse

AP5

Minera de Datos

AP6

Seguridad

AP7

ERP

AP8

CRM

AP9

ACADEMUSOFT

AP10

Sistema Gestin Citas


Mdicas

162

DESCRIPCION
Aplicacin que provee un
canal web para que los
estudiantes
tengan
acceso a solicitar las citas
mdicas
Aplicacin que conecta
con
un
LDAP
( Lightweight Directory Ac
cess Protocol)
para
autenticar los usuarios de
la universidad
Bus utilizado para facilitar
la comunicacin entre los
componentes de TI de la
Universidad
Sistema que maneja el
registro de los histricos
Aplicacin que provee
informacin
requerida
para asignar a cada
mdico de acuerdo a su
especialidad, y horarios
disponible.
Aplicacin que lleva la
auditoria de todos los
procesos del proceso
citas mdicas ips.
Aplicacin de manejo de
recursos que se encarga
de la gestin financiera y
de recursos humano de la
Universidad
Aplicacin para el manejo
de clientes y producto de
la Universidad
Aplicacin que maneja la
gestin acadmica de la
Universidad (Estudiantes,
Matriculas, Notas, etc.)
Aplicacin que maneja la
gestin de citas mdicas
de la Universidad.

Estructura de la solucin
Zonas de la solucin
Zona de canales: Esta zona contiene los canales que provee la seccin para
comunicarse con sus usuarios. Brinda la informacin de los servicios que presta la
seccin citas mdicas a los estudiantes de la universidad popular del cesar.

Zona de BPM: Definida en trmino de los procesos que maneja la seccin. Para la
implementacin de esta zona se emple el enfoque BPM para los procesos de
negocio. Esta zona se encarga de obtener informacin activa y pasiva de los
procesos de negocio en curso para su monitoreo y control.

Zona SOA: Contiene los servicios lgicos para la operacin de los procesos de
negocio de la seccin. En esta zona se definen el portafolio de servicios, derivado
de las funcionalidades del negocio. Estos servicios son reutilizables.

Zona de aplicaciones: Agrupa todas las aplicaciones que apoyan la operacin


backend de la seccin. Contienen las aplicaciones que proveen los servicios y
funcionalidades en las que se soportan los procesos de negocio de la seccin. Lo
que se visiona, es integrar el sistema de gestin de citas mdicas de la ips con
ACADEMUSOFT, plataforma donde los estudiantes, facilitadores, graduados y
administrativos, pueden realizar sus procesos acadmicos y administrativos.

Figura 41. Estructura de la solucin


163

Fuente: Elaboracin propia

10. TRABAJOS A FUTURO


164

Con esta investigacin, se ha logrado demostrar que SOA y BPM son adecuadas
para lograr los objetivos de una organizacin, logrando altos beneficios y
formulacin de estrategias. La metodologa propuesta permite entre otras cosas:
descubrir las actividades del negocio que necesitan ser soportadas, descubrir los
servicios existentes, reutilizarlos y disear nuevos, orquestarlos; satisfacer las
necesidades del negocio, asegurar la calidad, adaptarse a los cambios.

Como trabajo futuro se plantea la aplicacin del marco metodolgico propuesto,


aplicndolo a diferentes organizaciones, implementando el software y realizando
las pruebas correspondientes, con el objeto de encontrar fortalezas y debilidades,
obteniendo por tanto las mejoras correspondientes.

Por otra parte, las redes sociales se han transformado en uno de los fenmenos
tecnolgicos ms dinmicos siendo sin duda Internet quien lo facilita. Si bien
comenz como un fenmeno meramente social, las organizaciones ya lo estn
vislumbrando como una herramienta poderosa para compartir informacin y
favorecer el trabajo en grupo. Las redes sociales tradicionales carecen del aspecto
de coordinacin siendo BMP y los workflow mecanismos vlidos para aportar
este aspecto a las redes sociales.

Se espera incursionar en otras reas donde sea posible usar la metodologa


planteada, innovando de esta manera con nuevas aplicaciones y modificaciones
al presente proyecto.

11. CONCLUSIONES
165

En este proyecto se ha realizado una investigacin basada en la integracin de dos


arquitecturas de software, Gestin de Procesos de Negocio (BPM) y Arquitectura
Orientada a Servicios (SOA), desarrollando as una metodologa para la creacin de
aplicaciones de software, que comprende el estudio de los negocios, sus respectivos
procesos de negocio, servicios y componentes, contribuyendo de esta manera a un
mejor alineamiento de las Tecnologas de Informacin (TI) con las necesidades de
negocio.
Se tom el proceso de citas mdicas de la institucin prestadora de servicios de salud
de la Universidad Popular del Cesar como caso de uso a estudiar, para aplicarle la
metodologa desarrollada, y demostrar que la integracin SOA y BPM son adecuadas
para lograr los objetivos del negocio, soportndolos en aplicaciones orientadas a
servicios.
El desarrollo de esta metodologa constituye una manera de abordar los problemas de
las organizaciones, ya que un unifica los conceptos de procesos y servicios, buscando
fomentarla reutilizacin, agilidad y flexibilidad para absorber los cambios. SOA
permiti un mejor alineamiento de las Tecnologas de Informacin (TI) con las
necesidades de negocio, permitiendo a empleados, y usuarios responder de forma
ms rpida.
Con esta investigacin, se ha logrado exponer que SOA y BPM son adecuadas para
lograr que los objetivos del negocio estn reflejados en sus procesos, logrando altos
beneficios en la organizacin. BPM se centra en analizar los objetivos estratgicos
para crear procesos de negocios bien definidos y optimizados, monitorizando su
rendimiento para una mejora continua. La dificultad de BPM radica en la complejidad
de las diferentes plataformas tecnolgicas, los diferentes tipos de aplicaciones
existentes y los distintos protocolos de comunicacin, es decir, la problemtica de la
integracin de sistemas y aplicaciones, solucin aportada por SOA.

12. BIBLIOGRAFIA
166

Bazn Patricia. (2009) Un modelo de integralidad con SOA y BPM. Tesis de


Maestra en Redes de Datos. Facultad de Informtica. Universidad Nacional
de La Plata.

Delgado, Andrea, (2009), Desarrollo de Software orientado a servicios


basado en procesos de Negocio. Memorias de la XII Conferencia
Iberoamericana de Ingeniera de Requisitos y Ambientes de Software
(IDEAS 2009). ISBN 978-958-44-5028-9.
Delgado, Andrea (2007), Desarrollo de Software con enfoque en el
Negocio, Taller sobre Procesos de Negocio e Ingeniera de Software
(PNIS07). Zaragoza, Espaa Workshop realizado en el marco de las XII
Jornadas de Ingeniera del Software y Bases de Datos (JISBD07) en el II
Congreso Espaol de Informtica (CEDI).
Maribel Romero Mestre (2012), Metodologa para el desarrollo de
soluciones de tecnologas de informacin bajo modelado de procesos de
negocio, arquitectura empresarial y arquitectura orientada al servicio.
Jorge Leonel Maldonado Martnez (2013), Guatemala. Integracin de SOA y
BPM como una solucin a las necesidades del negocio
Microsoft, (dic 2006) La Arquitectura Orientada a Servicios (SOA) de
Microsoft aplicada al mundo real.
Edith Hernndez (2009), Arquitectura de negocios orientada a servicios
(SOBA-UIA).
Miguel Snchez (2007), Una recomendacin basada en MDA, BPM y SOA
para el desarrollo de software a partir de procesos del negocio en un
contexto de Negocio Bajo Demanda. Universidad Pontificia de Salamanca.
Jorge A. Villalobos (2009), Estructuracin de soluciones SOA a partir de una
visin de Arquitectura Empresarial, Universidad de los Andes.
Ciclo de vida del software (2005), http://carolina.terna.net/ingsw2/Datos/
Cascada-ModeloV.doc
Roger Pressman (2006). Ingeniera del software, 6ta ed. McGraw Hill. Pags
48, 77, 767.
Thomas Erl (2004) , Service-Oriented Architecture A Field Guide to
Integrating XML and Web Services - Pearson Education.
167

Jos H. Cans, Patricio Letelier y Maria Carmen Penads (2003),


Mtodologas
giles
en
el
Desarrollo
de
Software,
http://www.willydev.net/descargas/prev/TodoAgil.pdf.
Amaro Caldern, Sarah Dmaris, Valverde Rebaza, Jorge Carlos, (2007).
Metodologas agiles.
Parada Gelvez Hugo Alexander (2010), Tesis Doctoral: Contribucin a la
gestin de los procesos de pruebas de software y servicios.
http://oa.upm.es/4019/1/HUGO_ALEXER_PARADA_GELVEZ.pdf.
Weske Mathias (2008), Business Process Management: Concepts,
Languages, Architectures. Springer, Pag 3-67. ISBN 978-3-540-73521-2.
Chong, J.; Macas, V.; Marchan, K. & Villacres, M. (2006). BPM: Business
Process Modeling. Escuela Superior Politcnica del Litoral. Maestra en
Sistemas
de
Informacin
Gerencial
[documento
pdf].
http://www.msig.espol.edu.ec/descargas.html.
Flor Nancy Daz Piraquive, (2008). Gestin de procesos de negocio BPM
(Business Process Management), TICs y crecimiento empresarial.
Smith, H. & Fingar, P. (2003). Business Process Management. The Third
Ware. Tampa. Florida, USA: Meghan-Kiffer Press.
Jos Manuel Prez, Francisco Ruiz, Mario Piattini (2007). Model Driven
Engineering
Aplicado
a
Business
Process
Management,
http://www.uclm.es/dep/tsi/pdf/UCLM-TSI-002.pdf
Kiran Garimella, Michael Lees, and Bruce Williams BPM (2008), Basics for
Dummies, Software AG Special Edition Published by Wiley Publishing, Inc.
Espinoza Bustamante Luis Alberto (2008), Administracin
http://soaagenda.com/journal/articulos/category/bpm/

SOA,

Jose Manuel Prez, Francisco Ruiz, Mario Piattini (2007), Model Driven
Engineering Applicator a Business Process Management
Martin Owen and Jog Raj (2003), BPMN and Business Process
Management Introduction to the New Business Process Modeling
Standard. Popkin Software.
Unified Modeling Language (UML), 2009. Version
http://www.omg.org/technology/documents/formal/uml.htm.
168

2.2

OMG

Stephen A.White, (2004) Introduction to BPMN. IBM Corporation.


http://www.omg.org/bpmn/Documents/Introduction_to_BPMN.pdf.
Jaime Orlando Moreno, Jorge Humberto Arias (2007), Caso de Estudio:
Proyecto SIREP2 Estructura, rol e importancia de un ESB en un proyecto
Empresarial centrado en procesos de negocio (BPM) y soportados en
reusabilidad
de
Servicios
(SOA),
http://paradigma.uniandes.edu.co/media/articulos/jor-arias-1.pdf
Armando Maldonado, Adalberto Velzquez, Un Mtodo para definir la
Arquitectura de Procesos, La arquitectura de procesos.pdf.

Laengle, S, S. (2007). Business Process Management (BPM). Desafos de


los procesos de negocio y de las tecnologas de informacin. Santiago de
Chile
[documento
pdf]:
http://
sigifredo.laengle.googlepages.
com/20070512-Lectura-BPM.pdf.

169