You are on page 1of 60

UNIVERSIDAD TECNOLOGICA DEL PERU

FACULTAD DE SIENCIAS Y TECNOLOGIAS

DISEO DE UN MODELO DE INTEROPERABILIDAD TECNOLOGICA BASADO


EN LA ARQUITECTURA SOA PARA LAS MUNICIPALIDADES DE LIMA
METROPOLITANA ORIENTADO A MAXIMIZAR LA SATISFACCION DEL
CIUDADANO.
PLAN DE TESIS PRESENTADO POR:
-Jaramillo Ruiz, Pedro Alonso
-Santiago Romero, Cesar Deyvis
Bachiller en Ingeniera de Sistemas de la Facultad de Ingeniera Industrial y de
Sistemas Para optar el Ttulo Profesional de
INGENIERO DE SISTEMAS
EN LA
UNIVERSIDAD TECNOLOGICA DEL PERU

2012
1

RESUMEN
En la ciudad de Lima Metropolitana esta centralizado la mayor parte de la poblacin
del Per, donde cada ciudadano que desea realizar algn trmite en su municipio
se tiene que acercar personalmente al local del municipio a realizar dicho trmite
perdiendo tiempo en el traslado al local y en la misma atencin de parte del
municipio, donde en muchos casos se tiene que regresar ms de una vez para
realizar el mismo tramite adems de la demora en la culminacin del mismo que en
la ciudad de Lima Metropolitana es de 12 das como promedio.
Todo se debe a que los procesos para realizar los diferentes trmites municipales
en la ciudad de Lima Metropolitana son muy burocrticos y en algunos casos
depende de otra entidad para la culminacin de los mismos.
Dado estas circunstancias algunos de los municipios de Lima como Santiago de
Surco, La Victoria, Miraflores entre otros realizan diferentes trmites municipales a
travs de un portal Web de manera Online, pero cada municipio de acuerdo a su
presupuesto y a su evolucin en Gobierno Electrnico elige la mejor manera de
presentar estos trmites online con diferente tecnologa y tipo de solucin.
Tomando en cuenta la importancia de las TICs en la gestin pblica la ONGEI
(Oficina Nacional de Gobierno Electrnico e Informtica) tiene como principal
proyecto la realizacin de la PIDE (Plataforma de Interoperabilidad de Estado) que
consiste en la integracin total de las entidades pblicas en la que tambin
participa los municipios y que ante lo mencionado anteriormente sera muy difcil la
integracin de los municipios a este proyecto dado que cada municipio ofrece
diferentes tipos de solucin para la realizacin del mismo tramite . Entonces en el
presente proyecto se elaborar el modelo de una plataforma de interoperabilidad
tecnolgica entre los municipios de Lima Metropolitana haciendo uso de de la
Arquitectura Orientada a Servicios (SOA) beneficiando a la solucin con procesos
estandarizados ofreciendo un repositorio de servicios reutilizables.

Captulo I
INTRODUCCIN

1.1

MOTIVACION Y JUSTIFICACION

El presente proyecto se realiza por que actualmente existe un desarrollo


desordenado de las soluciones tecnolgicas de los diferentes municipios, adems
cada municipio crece de forma independiente, con diferentes tecnologas. Lo que
ocasiona que el nivel de satisfaccin del ciudadano no sea ptimo, ya que para
realizar un trmite deben hacer largas colas o perder tiempo en ir de un lugar a
otro segn el tipo de trmite que se desee.
Es por ello que se plantea esta solucin, para mejorar la satisfaccin del
ciudadano y la accesibilidad a los servicios que ofrecen los municipios,
estandarizando los procesos para la realizacin de los trmites mediante una
plataforma de interoperabilidad tecnologa.

1.2

OBJETIVOS

1.2.1 Objetivo General


Elaborar un modelo de interoperabilidad tecnolgica entre los municipios de Lima
Metropolitana para maximizar la satisfaccin de los ciudadanos, donde puedan
acceder a realizar su tramites online desde un nico portal para servicios y trmites
municipales.
1.2.2 Objetivos Especficos
- Tener la Arquitectura Orientada a Servicios (SOA) bien definida y
estructurada

que

municipalidades
-

permita
de

Lima

la

comunicacin

Metropolitana

de
as

las

diferentes

conseguir

la

interoperabilidad tecnolgica deseada.


Hacer uso del Cloud Computing como un servicio como plataforma para
reducir los costos de infraestructura y de administracin de la aplicacin

de parte de los municipios.


Hacer uso de la metodologa BPM para mejorar el control y
administracin de los procesos y la automatizacin de los mismos.

1.3

HIPOTESIS
4

1.3.1 Hiptesis General


El modelo de interoperabilidad tecnolgica entre los municipios permitir maximizar
la satisfaccin del cliente.

1.3.2 Hiptesis Especifica


El modelo de interoperabilidad tecnolgica entre los municipios no podr maximizar
la satisfaccin del cliente.

Captulo II
MARCO TEORICO

2 MARCO TEORICO
2.1

ARQUITECTURA ORIENTADA A SERVICIOS

Las Arquitecturas Orientadas a Servicios (Service Oriented Architecture) estn


formadas por servicios de aplicacin dbilmente acoplados y altamente
interoperables. Para comunicarse entre s, estos servicios se basan en una
definicin formal independiente de la plataforma y del lenguaje de programacin.
La definicin de la interfaz encapsula las particularidades de una implementacin,
lo que la hace independiente del fabricante, del lenguaje de programacin o de la
tecnologa de desarrollo
2.1.1 Elementos de SOA
En la actualidad no existe una definicin formal de la estructura en la que se rige
SOA, por lo tanto lo que se va a proporcionar son un conjunto de principios que
estn asociados con la Orientacin a Servicios y que todo proyecto basado en
SOA debe tener en cuenta estos principios segn Thomas Erl 1 son:

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

1 Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design pag.


37

implementacin del propio servicio. En el caso de los Servicios Web, esto


se lograr mediante la definicin de interfaces con WSDL.

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 nos podemos 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. En el caso de los Servicios Web, el descubrimiento se


lograr publicando los interfaces de los servicios en registros UDDI.

Contrato
formal

Bajo
Acoplamient
o

Descubrimie
nto

Reusabilid
ad

Sin estado

Composicin

Autonoma

Figura 1: Elaboracin propia: Elementos de Soa


SOA se compone de mensajes, operaciones, servicios y procesos (e instancias de
procesos). Un mensaje representa los datos que son requeridos para completar
alguna o todas las partes de una unidad de trabajo. Los Message Exchange
Patterns (MEPs) definen patrones de intercambios de mensajes comnmente
utilizados. Una operacin representa la lgica requerida para procesar los
mensajes de forma de completar una unidad de trabajo.
Un servicio representa una agrupacin lgica de un conjunto de operaciones
capaz de realizar unidades de trabajo relacionadas.
Un proceso contiene las reglas del negocio que determinan que operaciones de
servicio son utilizadas para completar una unidad de automatizacin, en otras
palabras, un proceso representa una pieza ms grande de trabajo que requiere
que se completen unidades de trabajo ms pequeas.
9

Adicionalmente los servicios adhieren a un acuerdo de comunicacin, definido en


forma colectiva por una o ms descripciones de servicios y documentos
asociados, llamados contratos de servicios. Los servicios tienen control sobre la
lgica que encapsulan y minimizan la retencin de informacin especfica de una
actividad, siendo generalmente, sin estado. Son diseados para ser descriptivos
de forma que puedan ser encontrados y evaluados va mecanismos de
descubrimiento disponibles, por ejemplo registro de servicios. 2
Los servicios son unidades de lgica independientes. Para retener su
independencia, los servicios encapsulan lgica dentro de un contexto distinto. Este
contexto puede ser especfico a una tarea del negocio, a una entidad del negocio,
o alguna otra agrupacin de lgica. El inters tratado por un servicio puede ser
pequeo o grande. Por lo tanto, el tamao y alcance de la lgica representada por
el servicio puede variar. Lo que es ms, la lgica de un servicio puede contener la
lgica provista por otros servicios. En ese caso, uno o ms servicios se componen
en uno colectivo.
Por ejemplo, las soluciones de automatizacin del negocio son tpicamente una
implementacin de un proceso del negocio. Este proceso se compone de lgica
que dicta las acciones realizadas por la solucin. La lgica se descompone en una
serie de pasos que se ejecutan en una secuencia predefinida de acuerdo a reglas
del negocio y condiciones de ejecucin. Al construir una solucin automatizada
que consiste en servicios, cada servicio puede encapsular una tarea realizada por
un paso individual o un subproceso compuesto de un conjunto de pasos.

2 Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and


Design, Pag 44
10

Figura 2: Los servicios como encapsulamiento de la lgica


Fuente: Thomas Erl, Service-Oriented Architecture
2.1.2 Servicios Web
Actualmente una forma para publicar y acceder servicios ampliamente aceptada y
utilizada por las Organizaciones, y soportada por la mayora de los kits de
herramientas de desarrollo, son los Web Services.
Un Web Service es un sistema de software diseado para soportar interaccin
interoperable de mquina a mquina sobre una red. Tiene una interface descrita
en formato procesable por mquina (especficamente WSDL). Otros sistemas
interactan con el Web Service en una forma que se prescribe en su descripcin
utilizando mensajes SOAP, tpicamente utilizando HTTP con una serializacin XML
en conjuncin con otros estndares Web relacionados. 3
3 Definicin de Web Services extrada de Worl Wide Web Consortium <
http://www.w3.org/ >, consultado el 27 de Diciembre del 2012
11

Por lo general, los servicios incluyen tanto lgica de negocios como manejo de
datos, relevantes a la solucin del problema para el cual fueron diseados. Un
servicio funciona como una aplicacin independiente, teniendo sus propias reglas
de negocio, datos, procedimientos de administracin y operacin, polticas de
escalabilidad,

seguridad,

tolerancia

fallos,

manejo

de

excepciones

configuracin. Expone toda su funcionalidad utilizando una interfaz basada en


mensajes, por lo que la comunicacin con el servicio, es realizada mediante
mensajes y no llamadas a mtodos. Estos mensajes deben contener o referenciar
toda la informacin necesaria para ser entendidos.
Los servicios web comunican aplicaciones, lo cual permite que se comparta
informacin independientemente de cmo se hayan creado, cul sea el sistema
operativo o la plataforma en que se ejecutan y cules sean los dispositivos
utilizados para obtener acceso a ellas. La comunicacin se caracteriza por el
intercambio de mensajes XML y por ser independientes del protocolo de
comunicacin. Para lograr esta independencia, el mensaje XML se envuelve de
manera apropiada para cada protocolo gracias a la creacin del protocolo de
transporte SOAP (Simple Object Access Protocol: Protocolo de Acceso a Objetos
Simples).
El Lenguaje de Descripcin de los Servicios Web (WSDL: Web Services
Description Languaje), expresado en XML, describe cmo acceder al servicio, de
qu funciones dispone, qu argumentos necesita y qu devuelve cada uno.
La otra tecnologa fundamental implicada es la de Descripcin Universal,
Descubrimiento e Integracin (UDDI: Universal Description, Discovery, and
Integration). UDDI es un directorio de servicios web donde se puedan publicar los
servicios ofrecidos, dar caractersticas del tipo de servicio, y realizar bsquedas.
En resumen, SOAP define un protocolo XML para la interoperabilidad bsica entre
servicios, WSDL introduce un lenguaje comn para describir servicios y UDDI
provee

la

infraestructura

requerida

para

publicar

descubrir

servicios

programticamente. Juntas, estas especificaciones permiten a las aplicaciones

12

interactuar siguiendo un modelo dbilmente acoplado e independiente de la


plataforma subyacente. 4
2.1.2.1 Tecnologas Asociadas5
WSDL: El lenguaje de descripcin de servicios web, naci en septiembre
de 2000 de la mano de Microsoft, IBM y Ariba, y constituye un estndar
para la descripcin de servicios del World Wide Web Consortium (W3C),
organizacin que gua el desarrollo en la web.
En esencia, WSDL es un contrato entre el proveedor del servicio y el cliente
mediante el que el proveedor del servicio indica
-Qu funciones que se pueden invocar
-

Qu tipos de datos utilizan esas funciones

Qu protocolo de transporte se utilizar para el envo y recepcin de

los mensajes (tpicamente, pero no nicamente, mensajes SOAP).


-

Cmo acceder a los servicios. En esencia, mediante qu URL se

utilizan los servicios.

SOAP: Es un protocolo simple para el intercambio de informacin


estructurada en un entorno distribuido y descentralizado. Define como dos
objetos en diferentes procesos pueden comunicarse por medio del
intercambio de datos XML. Utiliza XML para definir un framework extensible
de mensajera proveyendo un formato de mensaje que puede ser
intercambiado sobre una variedad de protocolos subyacentes. El framework
fue diseado para ser independiente de cualquier modelo de programacin
o cualquier semntica especfica de alguna implementacin.
El hecho de que SOAP use XML tiene sus ventajas como la facilidad de
comprensin por las personas, pero a la vez tiene sus inconvenientes
debido a que los mensajes son ms largos.

4 Pablo Alvez, Patricia Foti, Marco Scalone. Proyecto Batuta, Pag. 9


5 Pablo Alvez, Patricia Foti, Marco Scalone. Proyecto Batuta, Pag. 10-11
13

UDDI: Es un elemento central del grupo de estndares involucrados en la


tecnologa servicios web. Es el mediador a travs del cual se conocen los
posibles clientes con los proveedores de los servicios. Define un mtodo
estndar para publicar y descubrir servicios en el contexto SOA.
La especificacin de UDDI naci casi a la vez que la de WSDL, de la mano
de las mismas compaas. La versin actual es la 3.0, especificacin que
data de agosto de 2003, siendo gestionada por Organization for the
Advancement

of

Structured

Information

Standards

(OASIS).

La

implementacin de estas especificaciones se denomina Registro UDDI, el


cual proporciona un conjunto de servicios web de registro y consulta va
SOAP.
El propsito funcional de un registro UDDI es la representacin de datos y
metadatos acerca de servicios web. Tanto para ser usado en una red
pblica como dentro de la infraestructura interna de una organizacin, un
registro UDDI ofrece un mecanismo basado en estndares para clasificar,
catalogar y manejar servicios web de forma de que puedan ser
descubiertos y consumidos por otras aplicaciones.
2.1.3 Composicin de Servicios
En situaciones en las que un sistema de software, para completar un proceso de
negocio, tiene que interactuar con otros sistemas independientemente de su
distribucin fsica y heterogeneidad, las Arquitecturas Orientadas a Servicios son
ms que tiles.
De las Arquitecturas Orientadas a Servicios y ms precisamente del uso de
servicios web surge un nuevo concepto denominado composicin de servicios.
Esta composicin no solo permite modelar el proceso de negocio sino que tambin
maximiza las potencialidades que SOA brinda a travs de la integracin de datos y
aplicaciones.
La composicin de servicios implica encontrar un mecanismo que permita a dos o
ms de ellos cooperar entre s para resolver requerimientos que van ms all del
alcance de sus capacidades individuales. Algunos de los requisitos bsicos que se
deben cumplir son:

14

Interacciones asincrnicas con servicios: de manera de dar la posibilidad de


crear procesos que transcurran durante largos perodos de tiempo.

Interacciones simultneas entre servicios: esto introduce el procesamiento


en paralelo lo cual redunda en un aumento considerable de la eficiencia.

Manejo de excepciones: un proceso basado en mltiples servicios puede


fallar en su ejecucin si al menos uno de sus componentes falla. Se debe
tener en cuenta la ocurrencia de errores y proveer mecanismos para
manejarlos.

Integridad

transaccional:

un

proceso

de

larga

duracin

puede

eventualmente fallar, en este caso puede requerirse que parte de las


acciones ya efectuadas se deshagan.
Dos trminos comnmente usados para referirse a la colaboracin entre servicios
son orquestacin y coreografa. Ambos estn directamente relacionados con la
composicin pero se enfocan en aspectos complementarios de la interaccin entre
servicios.
2.1.3.1 Orquestacin6
Un proceso se puede considerar una orquestacin de servicios cuando es
controlado totalmente por una nica entidad. Este proceso define completamente
las interacciones con los servicios componentes y la lgica requerida para
conducir correctamente esas interacciones. Este tipo de proceso puede
entenderse como privado y ejecutable ya que solo la entidad que est
orquestando el proceso conoce el flujo de control e informacin que sigue el
proceso que se est orquestando. De esta manera se crea un proceso que utiliza
diferentes servicios manipulando la informacin que fluye entre ellos, convirtiendo,
por ejemplo, los datos de salida de algunos servicios en datos de entrada de otro.
Aqu, cada entidad que participa implementa y controla su propio proceso.

6 Composicin Semntica de Servicios Web


www.cintel.org.co/media/temacentral_3_14.pdf , citado el 16 de Noviembre
15

2.1.3.2 Coreografa 7
Un proceso es una coreografa de servicios cuando define las colaboraciones
entre cualquier tipo de aplicaciones componentes, independientemente del
lenguaje o plataforma en el que estn definidas las mismas. Un proceso de
coreografa no es controlado por uno solo de los participantes. A diferencia de la
orquestacin, la coreografa puede verse como un proceso pblico y no
ejecutable. Pblico porque define un comportamiento comn que todas las
entidades participantes deben conocer, y no ejecutable porque est pensado para
verse ms bien como un protocolo de negocio que dicta las reglas para que dichas
entidades puedan interactuar entre s.

2.2

BUSINESS PROCESS MANAGMENT (BPM)

El BPM, que va ms all del aspecto tecnolgico, es un sistema de gestin


enfocado a perseguir la mejora continua del funcionamiento de las actividades de
una organizacin, mediante la identificacin y seleccin de procesos y la
descripcin, documentacin y mejora de los mismos, partiendo del despliegue de
la estrategia de la organizacin, asegurando la misin empresarial y alineada a la
visin de la empresa. El BPM debe estar alineado con la estrategia, con la gestin
de recursos humanos, con la gestin financiera, con la gestin de la informacin,
con la gestin de la calidad y con las disciplinas tradicionales de gestin. La
Gestin por Procesos es impulsada y hecha realidad por un conjunto de
tecnologas totalmente maduras y que aportan excelentes resultados 8.

7 Composicin Semntica de Servicios Web


www.cintel.org.co/media/temacentral_3_14.pdf , citado el 16 de Noviembre
8 Articulo Club BPM, BPM ms que tecnologa. El desconocido paradigma de
gestin empresarial http://www.club-bpm.com/Noticias/art00151.htm,
consultado el 12 de Noviembre del 2012.
16

Business Process Management Initiative (BPMI) 9 promueve tres estndares:


Business Process Modeling Notation (BPMN) para modelado de procesos, como
estndar de notacin para especificarlos; Business Process Modeling Language
(BPML) para ejecucin de procesos, como estndar de Business Process
Execution Language (BPEL) y Business Process Query Language (BPQL) para
distribucin y ejecucin de procesos de e-Business, como interface de gestin
estndar. BPMN ha sido adoptado en febrero de 2006 como estndar del OMG.
2.2.1 Business Process Modeling Notation (BPMN)
Business Process Modeling Notation (BPMN) BPMN proporciona a los negocios la
capacidad de definir y entender sus procedimientos de negocios internos y
externos mediante un Diagrama de Procesos de Negocio, facilitando a las
organizaciones la habilidad para comunicar esos procedimientos en una manera
estndar.
BPMN provee un nmero de ventajas para modelar procesos del negocio sobre
UML. Primero, ofrece una tcnica de modelado del flujo de los procesos que es
ms propicia a la forma de modelado de los analistas del negocio. Segundo, su
base matemtica slida est expresamente diseada para mapear a Business
Process Execution Languages (BPEL), mientras UML no. BPMN puede mapear a
UML, y proveer un frontend de modelado del negocio slido para sistemas
diseados con UML10.
BPMN define un Diagrama de Procesos de Negocio que est basado en la tcnica
de diagramas de flujo y adaptado para crear modelos grficos de las operaciones
de los procesos de la organizacin.
9 Business Process Management Initiative (BPMI) es un institucin sin fines de
lucro que existe para promover y desarrollar el uso de BPM
10 Andrea Delgado Cavaliere, Tesis de Maestra - Universidad de la repblica Uruguay
Metodologa de desarrollo para aplicaciones con enfoque SOA, pag. 97

17

Est compuesto de un conjunto de elementos grficos que facilitan el desarrollo de


un solo diagrama entendible tanto por analistas de negocios como por arquitectos
de sistemas e ingenieros.

Figura 3: Ejemplo Bsico de un diagrama BPMN


Fuente: Stephen A. White, Derek Miers, BPMN Gua de referencia y modelado,
pag. 151
2.2.2 Business Process Modeling Language (BPML)
Business Process Modeling Language (BPML) es un estndar para lenguajes de
ejecucin de procesos (BPEL) basado en XML. Establece un formato estndar
para expresin e intercambio de procesos independiente de la implementacin.
BPMN se mapea directamente a Business Process Modeling Language (BPML) y
tambin a Business Process Execution Language for Web Services (BPEL4WS).
BPML es una especificacin tanto para modelar procesos del Negocio como para
construir sistemas de gestin de procesos. Provee el modelo abstracto para todos
los procesos, junto con sintaxis y XML- Schema basados en estndares para
expresar y gestionar procesos de Negocio. ... Un aspecto clave de BPML es que
es directamente ejecutable en una infraestructura de TI.

18

BPML es ejecutado por una mquina virtual de procesos en el BPMS. Esto es


comparable a la forma en que un programa Java es ejecutado en una mquina
virtual java provista por el sistema operativo. ... hay una correspondencia uno a
uno entre BPML y BPMN. El diagrama representa el cdigo y el cdigo representa
el diagrama. No hay prdida de informacin al moverse de uno al otro 11.

Figura 4: Relacin uno a uno entre BPMN y BPML


fuente: H.Smith, P.Fingar, Business Process Management: The third wave
2.2.3 Business Process Management Systems (BPMS)
Los Business Process Management Systems (BPMS) o sistemas de BPM, entran
entonces en juego para permitir el modelado y ejecucin de los procesos del
negocio. Un BPMS debe permitir a los analistas del negocio, desarrolladores de
software y administradores de sistemas, modelar y distribuir (deploy) procesos del
negocio (en tiempo de desarrollo) e interactuar, monitorear y analizar instancias de
procesos (en tiempo de ejecucin).
11 H.Smith, P.Fingar, Business Process Management: The third wave
19

Un BPMS puede ser visto de dos formas distintas: como una nueva plataforma
sobre la cual ser construida la nueva generacin de aplicaciones de negocios, o
como una nueva capacidad embebida en las categorias actuales de sistemas de
negocios. En cada caso la analoga es entre los RDBMS existentes y los nuevos
BPMS, entre los datos relacionales y los procesos, entre el ciclo de vida de gestin
de los datos y el ciclo de vida de gestin de los procesos. Agrega que Los
sistemas legados existentes, sin embargo, permanecen valiosos tanto para el
desarrollo interno o externo basado en procesos, porque su funcionalidad,
actualmente embebida, puede ser encapsulada por el BPMS como componentes
de software, que contribuyen a diseos nuevos o mejorados de procesos del
Negocio.
Los BPMS permiten una metodologa de tres pasos hacia la integracin de los
procesos de Negocio, en la cuya aplicacin se vern involucrados distintos roles,
principalmente los analistas del negocio durante todo el proceso, pero tambin
desarrolladores de software y administradores de sistemas. El primer paso
involucra el modelado del proceso del Negocio mediante una interface grfica
(GUI) y los patrones de diseo de procesos subyacentes son almacenados en un
repositorio de procesos, accesible a varios usuarios en la red. En segundo lugar
los procesos almacenados en el repositorio son instalados en el servidor de
procesos mediante herramientas automticas, para lo cual el servidor de procesos
no tiene porqu ser interrumpido, permitiendo entonces agregado y modificacin
de procesos del negocio en forma dinmica. Mediante herramientas provistas
tambin se puede consultar el estado de cualquier instancia de procesos y del
servidor de procesos. En tercer lugar los analistas del negocio y administradores
de sistemas pueden gestionar los procesos que se estn ejecutando, utilizando
lenguajes de consulta de procesos estndares. En [OMG] se puede encontrar una
extensa lista de herramientas con enfoque BPM.
2.3

INCLUSION DE BPM EN SOA12

12 Andrea Delgado Cavaliere, Metodologa de desarrollo para aplicaciones con


enfoque SOA, pag. 100
20

La visin de BPM es una visin fuerte, en vez de incluir directamente en el cdigo


informacin y reglas sobre procesos del Negocio importantes, esta informacin es
retirada de los sistemas de aplicacin y puesta bajo el control de un BPMS. BPM
facilita la modificacin, reconfiguracin, y optimizacin de definiciones de procesos
con herramientas grficas que pueden ser utilizadas por analistas del negocio con
menor orientacin tecnolgica.
SOA provee la funcionalidad del backend que es requerida por un BPMS para
implementar la funcionalidad de sus procesos. Todos los conceptos discutidos
previamente respecto a SOA, incluyendo el desarrollo evolutivo de capas bica,
intermediaria y de procesos, tienen en sentido en este contexto. SOA se convierte
en la infraestructura que permite la Organizacin orientada a procesos. En la
figura se muestra como encajan juntos los enfoques BPM y SOA.

Figura 5: SOA provee la infraestructura para BPM


Fuente: Andrea Delgado Cavaliere, Metodologa de desarrollo para aplicaciones
con enfoque SOA
El modelo presentado se puede ver como el paso final en la adopcin de SOA,
donde las Organizaciones, luego de atravesar los niveles de SOA planteados,
podrn contar con una base de servicios definidos e implementados, que permitan
21

la introduccin de BPM incluyendo BPMS que permitan el modelado grfico de los


procesos del Negocio con BPMN, que sern traducidos en forma automtica a
BPEL que podr ser ejecutado directamente en los motores de procesos que estos
sistemas proveen. Esto permitir cerrar la brecha entre los analistas del negocio y
los desarrolladores de software, donde cada uno podr enfocarse en su rea de
conocimiento manteniendo a la vez un objetivo comn: la Organizacin centrada
en procesos del Negocio que reacciona gilmente a los cambios originados en
ambas partes.
La capa de orquestacin de servicios, que sera entonces realizada en el motor de
procesos de un BPMS, permite absorber rpidamente los cambios originados
tanto en los procesos del Negocio como en las tecnologas subyacentes,
facilitando la reconversin de procesos existentes y la introduccin de nuevos
procesos por parte de los analistas del negocio, a la vez que las actualizaciones
de la implementacin de los servicios subyacentes (software implementado)
originadas por cambios de tecnologa o requerimientos de actualizacin de
plataformas o nuevas posibilidades que se incorporan a las plataformas
existentes.
Queda claro que las ideas anteriores son atractivas a las Organizaciones y a los
involucrados en el rea de TI en las mismas, as como a los analistas del Negocio.
Sin embargo, no debe subestimarse el esfuerzo que implica para una
Organizacin, sobre todo si es de gran tamao, el compromiso de incorporar el
enfoque SOA con BPM, y el software requerido. Otra lnea abierta de trabajo en la
conjuncin de estos enfoques, es el proceso de desarrollo a seguir para poder
partir desde el rea del Negocio para el modelado de los procesos del Negocio de
la Organizacin, definiendo la interface del rea del Negocio con el rea de TI, y el
trabajo en el rea de TI para la definicin, modelado, implementacin, despliegue
y mantenimiento de los servicios que realicen los procesos del Negocio
modelados.
2.4

METODOLOGA RUP/SOMA

22

El mtodo SOMA se desarroll como modelo de compromiso dentro del grupo de


Servicios empresariales globales de IBM, y aunque se dispona pblicamente de
descripciones y artculos fue principalmente un mtodo usado por los consultores
y no disponible para clientes de IBM. Por otro lado, el RUP es un producto
comercial ofrecido por IBM que los clientes utilizan para desarrollar sus propios
procesos de desarrollo de software. Esta oferta de mtodo integrado ha sido
desarrollada por RUP/SOMA para aportar los aspectos nicos de SOMA al mtodo
comercial RUP y ponerlos a disposicin de los clientes comerciales.
En la siguiente figura se aprecia las fases del ciclo de vida de SOMA aplicadas a la
Metodologa RUP tradicional.

Figura 6: Integracin de RUP en SOMA


Fuente: Elaboracin propia en base a IBM
Al reunir el contenido SOA de RUP y de SOMA, se junto los mtodos, tcnicas y
productos de trabajo o entregables de ambas metodologas, dando como
resultado un mtodo igualmente iterativo, que las actividades de identificacin,
especificacin y realizacin a menudo suceden en varias, y a menudo solapadas,
iteraciones centradas en distintos servicios o en servicios de distintos dominios.

23

Figura 7: RUP para SOMA.


Fuente: http://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/index.htm#soa.rup_soma
2.4.1 Integracin entre SOMA y RUP
El enfoque principal en la identificacin, especificacin y realizacin del servicio es
comn en SOMA y RUP, aunque existan algunas diferencias y algunas de ellas
han aparecido en el mtodo integrado resultante. En la medida de lo posible se
han conservado los nombres de SOMA, salvo en casos en los que el material de
RUP tena una procedencia ms fuerte.

Identificacin de servicio

La identificacin de servicio es principalmente un conjunto de actividades de


tiempo de elaboracin centrado en la identificacin de servicios candidatos del
conjunto de activos tanto empresariales como de TI. El flujo de trabajo de la
identificacin de servicio es el siguiente:

Figura 8: Actividades Identificacin de servicio


Fuente:
http://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/index.htm#soa.rup_soma

24

Las tareas identificadas dentro de este conjunto de actividades son:

Tarea: Anlisis de rea funcional

Tarea: Ajustar un guin de uso empresarial

Tarea: Anlisis de proceso empresarial

Tarea: Anlisis de guin de uso empresarial

Tarea: Identificar objetivos empresariales y KPI

Tarea: Identificar y asociar servicios con objetivos

Tarea: Anlisis de activos existentes

Tarea: Anlisis de modelos de datos

Tarea: Anlisis de reglas empresariales

Tarea: Construir arquitectura de prueba de conceptos

Especificacin de servicios

La especificacin de servicio es principalmente un conjunto de actividades de


tiempo de elaboracin centrado en la seleccin de servicios candidatos que se
desarrollarn en servicios completos. Estos servicios se asignan luego a
subsistemas tambin identificados a continuacin y posteriormente
descompuestos en conjuntos de componentes para su implementacin. El flujo
de trabajo para la especificacin de servicio es el siguiente:

Figura 8: Actividades Especificacin de servicios


Fuente:
http://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/index.htm#soa.rup_soma

Las tareas identificadas dentro de este conjunto de actividades son:

Tarea: Aplicar pruebas decisivas de servicios

25

Tarea: Especificacin de servicio

Tarea: Diseo de mensaje

Tarea: Identificar patrones de seguridad

Tarea: Diseo de subsistemas

Tarea: Especificacin de componentes

Realizacin de servicios

La realizacin de servicios es principalmente un conjunto de actividades de


tiempo de construccin centrado en la realizacin del diseo de componentes
listo para la implementacin de componentes. El flujo de trabajo para la
especificacin de servicio es el siguiente:

Figura 9: Actividades Realizacin de servicios


Fuente:
http://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/index.htm#soa.rup_soma
Las tareas identificadas dentro de este conjunto de actividades son:

Tarea: Decisiones de realizacin de servicios de documentos

Tarea: Especificacin de componentes

Tarea: Construir arquitectura de prueba de conceptos

2.4.2 Principales Artefactos


Modelo de Anlisis de procesos del negocio
Consiste en la elaboracin del modelado del negocio actual(as - is).
Documento de arquitectura de software
El documento de arquitectura de software proporciona una visin general
completa de la arquitectura del sistema de software. Sirve como medio de
26

comunicacin entre el arquitecto de software y otros miembros del equipo de


proyectos respecto a las decisiones significativas para la arquitectura que se
llevan a cabo en el proyecto.

Modelo de anlisis

El modelo de anlisis contiene las clases de anlisis y cualquier producto de


trabajo asociados. El modelo de anlisis puede ser un producto de trabajo
temporal, como cuando evoluciona hacia un modelo de diseo, o puede
permanecer durante algunos o todos los proyectos, y quizs ms, sirviendo
como visin general conceptual del sistema.

Modelo de diseo

El modelo de diseo es una abstraccin de la implementacin del sistema. Se


utiliza para concebir y para documentar el diseo del sistema de software. Es
un producto de trabajo integral y compuesto que abarca todas las clases de
diseo, subsistemas, paquetes, colaboraciones y las relaciones entre ellos.

Modelo de servicios de objetivo

El modelo de servicio de objetivos se utiliza para garantizar las relaciones


directas entre los objetivos empresariales, como articulacin de la estrategia
empresarial, y los servicios que representan las funciones de TI suministradas
a la empresa para cumplir los objetivos propuestos. Este modelo es por tanto
una captura de la rastreabilidad entre la estrategia empresarial y las funciones
de TI.

Componente de servicio

Este artefacto est pensado para su utilizacin en la descripcin de la


realizacin de una especificacin de servicio. Un componente de servicio
puede ofrecer la realizacin de uno o ms servicios mediante la realizacin de
varias especificaciones de servicio. El conjunto de elementos de modelo del
componente representa la realizacin concreta del contrato estructural, de
comportamiento y de polticas descrito por estas especificaciones de servicio.

Modelo de servicio

El modelo de servicio es una abstraccin de los servicios de TI de una


empresa y dan soporte al desarrollo de una o ms soluciones orientadas a
27

servicios. Se utiliza para concebir y documentar el diseo de los servicios de


software. Se trata de un producto de trabajo compuesto completo que engloba
todos los servicios, proveedores, especificaciones, particiones, mensajes,
colaboraciones y relaciones entre ellos. Es necesario para:
-

Identificar servicios candidatos y capturar decisiones sobre qu servicios


sern realmente expuestos

Especificar el contrato entre el proveedor de servicios y el cliente de los


mismos

Asociar servicios con los componentes necesarios para realizar estos


servicios

El modelo de servicio captura los detalles de un conjunto de servicios a travs


de varias iteraciones, elaborando progresivamente el detalle. El modelo de
servicio se puede utilizar para distintos niveles de mbito:
-

Desarrollo de mbito de servicio: el mbito del proyecto es desarrollar el


servicio independientemente (en la medida de lo posible) de otros
servicios. El modelado abarca pues los modelos de guiones de uso,
arquitectura, diseo e implementacin como una porcin vertical del
servicio uno.

Desarrollo de mbito de proyecto: un proyecto implica la especificacin


de un nmero de servicios en apoyo de un conjunto de requisitos de
aplicacin, en este caso, el mbito se ampla al nivel de aplicacin y
puede entraar diversos servicios. En efecto, existe un conjunto de
modelos de nivel de aplicacin para guiones de uso y arquitectura y
luego un conjunto de modelos de diseo e implementacin especficos
del servicio.

Desarrollo de mbito empresarial, o gestin de cartera de servicios, en


el que el mbito es slo capturar las especificaciones de servicio y el
particionamiento lgico pero en el mbito de toda la empresa. Esto
permite a los diseadores y arquitectos tomar decisiones de un, incluso
proyectos independientes que son necesarios para desarrollar los

28

modelos de diseo e implementacin de los servicios identificados (y


aplicaciones de cliente).
El siguiente diagrama muestra los aspectos clave del modelo de servicio, en
abstracto, y la relacin entre ellos y las actividades Identificacin,
Especificacin y Realizacin.

Figura 10: Entregable modelado de servicio


Fuente:
http://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/index.htm#soa.rup_soma

2.5

SOAML

El Lenguaje de Modelado para Arquitecturas Orientadas a Servicios (Service


Oriented Architecture Modeling Language, SoaML) de OMG provee un perfil UML
y un metamodelo que extiende el metamodelo UML para disear servicios en
SOA, la versin actual del estndar es la V1.0.1. En SoaML se define un servicio
como una oferta de valor segn una o ms capacidades (abstraccin de la
habilidad de actuar y producir una salida y resultado) que tiene interface/s y un
contrato asociados.
29

Las interfaces pueden ser de tipo Interface de Servicio (ServiceInterface) o


Interface simple (Interface) UML. Un Contrato de Servicios (ServiceContract)
define los trminos, condiciones, interfaces y coreografa en que los participantes
acuerdan para utilizarlo, esta ltima puede expresar con cualquier diagrama de
comportamiento

(Behavior)

UML,

generalmente

uno

de

secuencia.

Una

Arquitectura de Servicios (ServiceArchitecture) es una colaboracin UML que


presenta los participantes, contratos de servicios y roles en los mismos, brindando
una visin global de los servicios provistos y requeridos. Los Participantes
(Participants) pueden ser componentes de software, organizaciones, o sistemas
que proveen y usan stos servicios, ofreciendo capacidades en puntos de servicio
(Service) y requiriendo servicios en puntos de solicitud (Request), siendo ambos
(puntos de servicios y solicitud) especializaciones de Port UML (en la versin
anterior

beta

2:

ServicePoint

RequestPoint).

Un

canal

de

servicios

(ServiceChannel) modela la comunicacin entre proveedores y consumidores de


servicios, el tipo de mensaje (MessagesType) especifica la informacin
intercambiada.

Figura 11: Simbologa SoaML


Fuente: http://www.omg.org/spec/SoaML/1.0.1/
30

Captulo III
DISEO DE LA SOLUCION

31

DISEO DE LA SOLUCION

3.1

ANALISIS DEL PROBLEMA

-Desarrollo desordenado de las soluciones tecnolgicas de los diferentes


municipios: en el siguiente grafico se observa claramente que cada municipio
ofrece el acceso de diferentes tramites online, tambin se sabe que cada
municipio tiene diferentes soluciones en lo que a software se refiere, con
diferentes tecnologas y nivel de satisfaccin al ciudadano haciendo muy
complicado la integracin a la Plataforma de Interoperabilidad del Estado.

Figura 12: Desarrollo desordenado de soluciones tecnolgicas de los municipios


Fuente: Elaboracin propia
32

-El nivel de atencin de los municipios es muy bajo debido a la alta


burocracia en sus procesos:

Figura 13: Nivel de atencin de los municipios.


Fuente: Ranking CAD Noviembre 2010
Segn la encuesta los ciudadanos de la ciudad de Lima Metropolitana tienen como
principales dificultades la lentitud en resolver tramites as como los excesivos
requisitos exigidos para cada tramite, esto es debido a la complejidad y burocracia
de los procesos dentro de los municipios
Como se observa en el grfico el tiempo promedio invertido en trmites en los
municipios de Lima Metropolitana es de 12 das, incluso llegando a promedios por
encima de los 20 das en municipios como Comas, Puente Piedra, San Isidro y
San Juan de Miraflores.
El tiempo promedio que tarda un ciudadano en cada visita a su municipio desde
que sale de su domicilio, es atendido, realiza su gestin y retorna a su domicilio es
de 74 minutos y que en su mayora tienen que regresar ms de una vez para
realizar su trmite.

33

Figura 14: Tiempo promedio de cada visita


Fuente: Ranking CAD Noviembre 2010
3.1.1 PLANTEAMIENTO DEL PROBLEMA
Todos los ciudadanos tienen derecho de participar en la gestin municipal de su
distrito presentando sugerencias y reclamos, solicitar orientacin, formular
consultas, y que el mismo municipio le de la facilidad de realizar transacciones o
acceder a diferentes servicios como lo son: el pago de arbitrios, licencias de
funcionamiento, licencias de edificacin, etc.

Figura 15: Estadsticas de trmites burocrticos


Fuente: Encuesta Universidad de Lima

34

Pero que ocurre en realidad, los municipios segn el grafico, muestra que son la
institucin en donde se realizan los trmites ms burocrticos a pesar de ser la
segunda institucin pblica en donde se realizan mas tramites siendo relegada
solo de la Reniec, esto refleja el bajo nivel de servicios que prestan los municipios
a los ciudadanos.
Pero la burocracia en los trmites municipales, el acceso a la informacin y la
transparencia de la accin gubernamental en los municipios se gestionan de una
mejor manera cuando se hace uso de las TICs en la gestin pblica permitiendo
que los ciudadanos dispongan de la infraestructura y recursos tecnolgicos
necesarios para poder interactuar adecuadamente con su municipio, ese es el
caso de municipios como: Santiago de Surco, Miraflores, La Victoria, San Isidro,
que proveen a sus ciudadanos la posibilidad de realizar pagos online de diferentes
tramites y de acceder al trmite de licencias de funcionamiento como es el caso de
Santiago de Surco y Miraflores, pero que pasa con los municipios como Lince, Los
Olivos, Rimac que no realizan el trmite de licencias de funcionamiento, o que
pasa con los municipios como Barranco, El Agustino que no realizan ningn
trmite online.
Entonces si se trata de los mismos tramites, de los mismos servicios Porque
existe tanta diversidad de soluciones?
Se evidencia claramente el crecimiento desordenado en lo que a tecnologa se
refiere en los diferentes municipios distritales de la ciudad de Lima Metropolitana
que se deben a varios factores como que el presupuesto es diferente para cada
municipio, o que no han adoptado correctamente uso de las TICs en la gestin de
su municipio, o que la inversin en TICs es muy costosa, o que existen otras
prioridades que el desarrollo tecnolgico.
Los ciudadanos de la ciudad de Lima Metropolitana tienen acceso a realizar
trmites municipales pero va a depender del distrito donde viva para que tenga
acceso a realizar sus trmites municipales online, sin necesidad de acercarse
35

fsicamente al municipio, sin hacer colas y realizar el tramite facilmentente sin


llenar tantos documentos burocrticos, para esto es necesario que los procesos
estn debidamente esquematizados.
La Oficina Nacional de Gobierno Electrnico e Informtica (ONGEI) tiene como
uno de sus principales proyectos la Plataforma de Interoperabilidad del Estado
(PIDE) que consiste en la integracin total de las entidades pblicas en la que
tambin participa los municipios.

Figura 16: Proyecto PIDE


Fuente: www.ongei.gob.pe/
Pero existen muchas complicaciones en lo que respecta a la integracin de los
municipios en la PIDE porque cada municipio cuenta con su propia estructura
tecnolgica y difieren en las soluciones de servicios y tramites online.

36

3.1.2 Limites
El proyecto tiene como finalidad realizar la integracin e interoperabilidad
tecnolgica entre los municipios de Lima Metropolitana que accedan al contrato
del servicio y de los trmites a implementar en el proyecto que son: trmite de
pago de arbitrios y pagos en general, licencia de funcionamiento y licencia de
construccin.
3.1.3 variables.

Variable Independiente:
El modelo de interoperabilidad tecnolgica entre municipios
Indicador:
- Tiempo de Respuesta en las transacciones.
- Ahorro en Costos de los municipios

Variable Dependiente:
Satisfaccin del Ciudadano
Indicador:
- Cantidad de Reclamos
- Tiempo usado en sus operaciones

3.2

ANALISIS DE LA SOLUCION

3.2.1 Trmites a realizar en el portal

37

Los trmites a realizar en el portal integrado de municipios van hacer primero


obtener un catalogo de todas las transacciones que ya se realizan en los
diferentes municipios que son:
-

Pagos de arbitrios e impuestos

Compra de partidas de nacimiento

Compra de partidas de matrimonio

Compra de partidas de defuncin

Solicitud de acceso a la informacin publica

Consulta estado de tramite

Fraccionamiento de deuda

Y tambin tramites esenciales que aun no se realizan en los municipios que son:
- Licencias de funcionamiento
- Licencias de edificacin
- seguridad en las transacciones con encriptacin de claves, plataforma de pago
electrnico que disponga de Paypal, verifide by visa y la pgina corra bajo
certificado SSL.
3.2.2 Arquitectura General de la aplicacin
Capa de sistemas operacionales y componentes del negocio
En esta capa se va a tener todas las aplicaciones de las diferentes municipios
tales como ERPs, CRM`s, aplicaciones legadas, aplicaciones de BI, etc.
Estos sistemas de informacin en su interior tienen implementados las
funcionalidades de negocio que posteriormente son publicadas como servicios,
a partir de los cuales se componen y estructuran procesos de negocio.
As tambin se encuentran los componentes que se encargan de brindar la
funcionalidad que exponen los servicios, todas estas aplicaciones y
componentes son los que se van a integrar a travs de SOA.
38

Capa de integracin

Esta capa es fundamental en la arquitectura del proyecto porque es la que se


va a encarga de integrar las aplicaciones existentes descritas en la capa
anterior. La infraestructura de software a utilizar va a ser un ESB (Enterprise
Service Bus) que como puede verse en la figura es una pieza estructural y
angular que soporta la arquitectura total del proyecto ya que todos los
mensajes que fluyen entre los ERP`s, CRM`s, aplicaciones legadas y las
aplicaciones responsables de la funcionalidad de los municipios van a pasar
por esta pieza intermedia.
El ESB ofrece robustez y confiabilidad en la entrega de mensajes a los
escenarios de negocio que consideran el flujo de informacin entre varias
aplicaciones y/o plataformas tecnolgicas, gracias a la naturaleza asncrona
sobre la que se encuentra implementada la comunicacin de los diferentes
elementos estructuradores del Bus.

Capa de servicios

La capa de servicios se compone de todas las funcionalidades implementadas


por las plataformas de negocio de los municipios que se publican como
servicios reutilizables a partir de los cuales se pueden componer procesos de
negocio como se observa en la figura.

39

Figura 17: Arquitectura de proyecto


Fuente: Elaboracin propia
Es en esta capa tambin se constituye lo que llamamos el portafolio de
servicios que no es ms que el agrupamiento de todas las transacciones y
servicios que vamos a ofrecer en nuestro portal, publicadas bajo estndares
abiertos, tipos de datos estandarizados, lineamientos de seguridad y manejo
transaccional que faciliten su reutilizacin, y proveen flexibilidad a la hora de
componer procesos de negocio. La gestin y gobernabilidad del portafolio de
servicios se realiza de manera centralizada para evitar problemas de
duplicidad de servicios, evolucin o extensin no controlada y/o versionada de
servicios, y asegurar la reusabilidad de los mismos.
40

Capa de procesos

Est definida en trminos de los procesos de negocio que estructuran la lnea


de negocio de los municipios, y que fueron necesarios orquestar va un
enfoque de servicios, y monitorear va eventos de negocio generadores de
KPIs (Key Performance Indicator). Es importante anotar, que para los
Municipios un proceso de negocio no es ms que la orquestacin ordenada y
bien definida de un conjunto de funcionalidades de negocio que se encuentran
publicadas como servicios. Dicha orquestacin durante el tiempo genera
eventos de negocio a partir de los cuales se pueden tomar definiciones
centradas en un tablero de control o DashBoard.
Para la implementacin de esta capa se emplear la metodologa BPM para
los procesos de negocio, con esta metodologa vamos a poder implementar el
conocido BPM 360 que consiste en el modelado, automatizacin, integracin,
y monitorizacin y todo esto ser aplicado en una suite BPM (BPMS).

Capa de presentacin

Esta es la capa que permite manejar la interaccin de los ciudadanos con los
servicios que prestar la aplicacin. Es decir el portal municipal integrado
publica los servicios que presta como procesos de negocio, los cuales implican
atravesar diferentes reas funcionales y sistemas de informacin. Esto debido
a que el portal municipal integrado ms que ser una aplicacin orientada a
funciones y procedimientos de negocio es una aplicacin orientada a procesos
de negocio.
El canal empleado para presentar el servicio es el internet a travs de web
services, As el ciudadano va a poder consumir el servicio en su laptop,
computadora de escritorio o hasta de un celular porque tambin se va a
realizar la aplicacin para dispositivos mviles. Con la utilizacin de web
sevices se garantiza que independientemente del canal, se presta el mismo
servicio, con los mismos datos, y con las mismas reglas de negocio.
41

Finalmente, desde esta capa se encuentra el tablero de control, el cual es el


lugar donde se publican los indicadores de negocio KPI que se calculan a partir
de los eventos de negocio generados por el BPM durante la orquestacin de
un proceso de negocio. Este tablero de control ser publicado en un portal al
grupo ejecutivo de los municipios para que este ltimo pueda conocer en un
tiempo cercano al real (NRT: Near to Real Time) como se estn prestando los
servicios que ofrece el portal municipal integrado y cmo van los trmites
realizados en su municipio en general.
3.2.3 Beneficios de la propuesta
En el grfico se muestra cmo va a funcionar el sistema planteado donde los
ciudadanos de Lima Metropolitana acceden a un nico portal donde pueda realizar
sus trmites

y que estos trmites sean un mismo proceso debidamente

confeccionados y monitorizados.

Figura 18: Funcionamiento de la solucin


Fuente: Elaboracin propia

42

En este grfico se ve la diferencia entre la situacin actual y la situacin deseada,


en la situacin actual muchos de los trmites son muy burocrticos y necesitan de
uno a dos trmites y visitar ms de una entidad para su finalizacin. Esta situacin
cambiaria con la plataforma de interoperabilidad planteada donde los ciudadanos
accedern al portal donde se va a realizar todos los documentos necesarios para
el trmite en un nico portal.

Figura 19: Situacin actual y situacin deseada


Fuente: Elaboracin propia

En este grfico se observa uno de los grandes beneficios en lo que a servicio al


ciudadano se refiere dado que en la actualidad cada municipio ofrece distintas
soluciones dependiendo de su presupuesto y de la inversin que hacen en TICs
para un mismo trmite, evidenciando la distincin que tienen los ciudadanos a
acceder al mismo tramite.

43

Figura 20: Tramites nicos y estandarizados.


Fuente: Elaboracin propia
3.3

Estudio de Viabilidad

3.3.1 Viabilidad econmica


El presente anlisis pretende medir si nuestro proyecto es rentable o no, para ello
haremos el anlisis costo-beneficio y calcularemos el VAN y el TIR.
COSTOS
Para la creacin de nuestra plataforma de integracin necesitamos profesionales
que tengan conocimientos de SOA. El lenguaje de programacin a usar ser Java.
Por lo tanto necesitaremos para el proyecto:
(2) Analista Programador Java SOA. (S/ 2250)
(1) Analista Funcional SOA (1). (S/ 3000)
(1) Jefe del Proyecto. (S/ 3500)
Adems necesitamos contar con Hardware y Software (Libre) para realizar las
pruebas respectivas. En total ser 4 computadoras para los colaboradores y tres
servidores: Servidor Web, Servidor de Aplicaciones y Servidor de Base de Datos.
(4) PC Intel Core 2 Duo. (S/ 1500)
44

(3) Servidores. (S/2000)


Software Windows Server 2008. (S/ 1200) 3 Licencias (Servidores).
Tambin necesitaremos implementar una oficina con los muebles necesarios para
trabajar con comodidad.
(4)Muebles para Computadoras Vidrio. (S/ 300)
(1) Telfono IP Cisco. (S/ 100)
(3) Rack de Servidores. (S/ 900)
Finalmente, nuestros costos totales sern:
Recursos Humanos

S/ 11 000 (Mensual)

Hardware

S/ 13 200

Capacitacin SOA

S/

Electricidad

S/

500 (Mensual)

Telfono e Internet

S/

250 (Mensual)

Equipos de Oficina

S/

4 000

Reserva de Emergencia

S/

1 000

5 000 (Solo Primer Mes, una vez por

ao)

Costo Total:

S/ 35 000.00

VENTAS.
Se espera vender el producto en S/150 000 valido por un ao finalizado este
periodo, y realizar un contrato de soporte tcnico por 3 aos, en el cual la
ganancia por mes ser de S/15 000.
Se estima que el tiempo de programacin ser de 8 meses. A partir del 9no mes
empieza a ingresar monto por el contrato de soporte.
CALCULO DEL PRECIO DE VENTA Y SOPORTE DEL PRODUCTO.
Para el clculo de la venta del producto se tomo como base el presupuesto que
tienen asignado dos distritos: Municipalidad de Santiago de Surco y Municipalidad
de Magdalena.

45

Considerando que la municipalidad de Santiago de Surco tiene un presupuesto


para adquisicin de software de S/ 1367,000 Nuevos Soles 13, y para la
municipalidad de Magdalena es de S/ 113,000 Nuevos Soles. 14
Estos costos no consideran gastos de servidores (S/ 1200,000 Nuevos Soles para
Santiago de Surco y S/ 100,000 Nuevos Soles para Magdalena) ni tampoco gastos
de recursos humanos(S/ 1000,000 Nuevos Soles para Santiago de Surco y S/
99,600 Nuevos Soles para Magdalena). Este costo nuestro aplicativo pretende
reducirlos drsticamente, por las razones ya explicadas en apartados anteriores.
En cuanto, para la construccin del software se obtuvo un costo de 117,200 mil
Nuevos soles.
Entonces, se tomo como ganancia el monto de 32,800 Nuevos soles, el cual
puede variar de acuerdo al presupuesto de la municipalidad.
Por ello, el precio de venta que hemos asignado a nuestro producto es de S/
150,000 Nuevos Soles.
Para el clculo del monto por el soporte ofrecido se toma como base el costo del
servicio (RRHH) ms un margen de ganancia elegido por nosotros el cual ser de
4 mil soles, el cual puede variar de acuerdo al presupuesto de la municipalidad.
ANALISIS COSTO BENEFICIO.
VAN = 146.55
TIR = 208%
TEA = 23% es el inters que cobra el banco para el prstamo, en este caso el
BCP cobra el 23%15 para prstamos mayores a 2,000 mil nuevos soles y 28% para
menores a este.
Como el TIR es mayor a la TEA, entonces el proyecto es rentable.

13 Plan Operativo Informtico. Gerencia de Tecnologas de Informacin. Pgina


15. Municipalidad de Santiago de Surco.
14 Plan Operativo Informtico. Departamento de Informtica. Pgina 26.
Municipalidad de Magdalena.
15 Tasa de Efectividad Anual (TEA) BCP. Anexo1.
46

3.3.2 Viabilidad operativa


El Dr. Jeffrey Poulin en su libro Measuring Software Reuse dice:
El costo de hacer un componente reutilizable tiene un costo del 60% sobre el
desarrollo normal.
El reutilizar un componente tiene un ahorro del 80%

Figura 21: Viabilidad operativa


Fuente: elaboracin propia
En resumen, este cuadro detalla los dos puntos mencionados, es decir el
desarrollo de una aplicacin reutilizable tiene un costo del 60% sobre el costo de
realizar la aplicacin, y la reutilizacin de un componente tiene un ahorro del 80%
sobre el costo.
Finalmente obtenemos que en la cuarta reutilizacin obtenemos un ahorro de S/
189,120 Nuevos Soles.

47

48

Captulo IV
VALIDACION DEL MODELO

49

4
4.1

VALIDACION DEL MODELO


INSTRUMENTOS Y TECNICAS

4.2 DISEO DEL PROTOTIPO


4.2.1 Modelado empresarial
4.2.1.1 Identificar Objetivos de Negocio.
Los objetivos de negocios identificados dentro de un municipio se
representan en los siguientes diagramas.

Fuente: Elaboracin Propia.

50

AUTOMATIZAR SERVICIOS
MUNICIPALES A TRAVES DE LA WEB

DISMINUIR COSTOS EN TRAMITES

DISMINUIR TIEMPOS EN ATENCION

MAYOR ACCESIBILIDAD DE TRAMITES A CIUDADANOS

MEJORAR GESTION DE TRAMITES Y SERVICIOS

SIMPLIFICAR T RAMITE LICENCIA FUNCIONAMIENTO

SINPLIFICAR TRAMITE LICENCIA DE CONSTRUCCION

ACCESO A PAGOS ONLINE

Descomposicin de los objetivos de Negocio referente a los servicios y


trmites municipales
Fuente: Elaboracin Propia.

4.2.1.2 Anlisis de rea funcional


Es importante como parte del anlisis del negocio modelar la estructura del
municipio y de cmo se divide funcionalmente un municipio.

Definicin: Un Sistema de Actividad Humana que tiene por objetivo brindar servicios
de calidad (en trmites, servicios mdicos, Seguridad, Cuidado del medio ambiente,
etc.) para la satisfaccin del ciudadano

Gerente municipal

Ciudadano
MUNICIPIO

Fuente: Elaboracin Propia.

Tambin es importante recalcar que un municipio tiene muchas gerencias y


sub gerencias, nosotros nos basamos para esta divisin agrupando los
grandes grupos de subsistemas que tiene un municipio en general.

51

subsistemas de un
municipio

Ciudadano
(f rom Use Case View)

Servicios y trmites municipales

Gestin de rentas y recaudaciones

Presupuesto y proyectos de Inversin

Gerente municipal
(f rom Use Case View)

Fuente: Elaboracin Propia.

SSN

Subsistema de Servicios y Trmites Municipales

Subsistema que comprende los procesos relacionados con los servicios y


trmites que ofrece un municipio desde su planificacin, gestin y
administracin. Subsistema Servicios y Trmites Municipales
SSN

Defensa Civil
Acceso a Trmite y/o Servicio

Evaluacin del trmite y/o Servicio

Seguridad Ciudadana.

Ciudadano
(f rom U se Case View)

Gerente municipal
(f rom Use Case View)

Transporte Urbano

Gestin de Tram ites y Servicios

Fuente: Elaboracin Propia.

52

4.2.1.3 Definir Casos de uso de Negocio


En esta etapa de detalla los diagramas de casos de uso identificados en el
anlisis del subsistema

Diagrama de casos de uso: Acceso a trmite y/o servicios.


DCU

Pedir Informacin
Orientador

Ciudadano

Realizar Tramite

(from Use Case View)

Pagar trmite y/o Servicio

Cajero

Fuente: Elaboracin Propia.

Diagrama de casos de uso: Evaluacin del trmite y/o servicios.


DCU

Tcnico

Inspeccin Tcnica

Defensa Civil

Gerente municipal

(f rom Serv icios y trmites municipales)

(f rom Use Case View)

Aceptar y/o Cancelar Trmite


Evaluar Trmite

Registrar Trmite

Secretaria

Fuente: Elaboracin Propia.

53

Diagrama de casos de uso: Gestin de trmites y/o servicios


DCU

Gestionar Procesos de Trmites

Gerente municipal

Tecnico (Especialista)

(from Use Case View)

Gestionar TUPA

Fuente: Elaboracin Propia.

4.2.2 Anlisis y diseo


4.2.2.1 Identificacin del servicio
La metodologa RUP/SOMA es flexible a los diferentes enfoques para la
identificacin del servicio, ante este contexto se pueden usar los enfoques Top
Down, Button Up y Meet in the Middle en los diferentes mtodos que define la
metodologa para realizar esta actividad cuyo objetivo principal es obtener el
repositorio de todos los posibles servicios posibles a implementar.
4.2.2.1.1 Identificar factores comunes y variabilidad
Los procesos de negocio difieren mucho entre uno y otro municipio, de la
forma de gestin de las actividades gerenciales de cada municipio y depende
mucho del presupuesto del municipio.
Si bien los procesos internos dentro de un municipio difieren respecto a otro,
no lo es los servicios y tramites que ofrecen, en todo municipio se ofrece al
ciudadano acceso a diferentes servicios y trmites que son los mismos en todo
municipio, tal como la realizacin del trmite de licencia de funcionamiento,
licencia de construccin, pago de arbitrios, etc.
Adems cada municipio est obligado a la publicacin del TUPA (Texto nico
de Procedimientos Administrativos), donde hemos realizado un anlisis de
estos textos a mas de 15 municipios obteniendo como resultado la verificacin
en la similitud de los tramites a nivel de proceso, variando solo en las reglas de

54

negocio que define cada municipio como lo es el precio, los das de espera,
etc.
4.2.2.1.2 Identificar patrones de seguridad
Durante el anlisis hecho en los municipios existen en la actualidad muchos
municipios que ofrecen la realizacin de diferentes trmites a travs de la web,
pero no cuentan con una interfaz segura de comercio electrnico, no cuentan
con una plataforma confiable para que los ciudadanos puedan realizar sus
pagos de forma segura.
4.2.2.1.3 Identificar y asociar patrones con objetivos
Teniendo el anlisis de los objetivos de negocio y siguiendo el enfoque Top
Down para la identificacin de servicios en esta tarea se descompone los
objetivos encontrados para identificar los servicios que puedan realizar estos
objetivos.
Objetivo o Sub
objetivo
Disminuir costos
en trmites

Mayor
accesibilidad de
tramites a
ciudadanos
Disminuir
tiempos en
atencin
Mejorar gestin
de trmites y
servicios
Simplificar
trmite licencia
de
funcionamiento
Simplificar
trmite licencia
de construccin
Acceso a pagos

Medida

Servicios

Monto de gastos en
personal, infraestructura, y
locales para la gestin de
trmites municipales.
Medio por el que se izo el
trmite

Control de gastos.

Tiempo de espera de
ciudadanos para atencin
en municipios
Tiempo de demora de la
realizacin de trmites
municipales
Tiempo de demora en
realizacin de trmite de
funcionamiento
Tiempo de demora en
realizacin de trmite de
funcionamiento

Brindar

licencia

de

funcionamiento.
Brindar

licencia

de

construccin.
Brindar

servicio

de
55

online

pagos online.
Fuente: Elaboracin Propia.

4.2.2.1.4 Anlisis del proceso empresarial


Hasta este punto se ha visto el anlisis del sistema en forma general para la
identificacin de los servicios pero en esta tarea se analiza cada uno de los
procesos de negocio, procesos de control, procesos de administracin,
procesos de trmites, procesos de servicios basicamente como funcionan en la
actualidad (As - Sis) y realizando el enfoque Top Down se detallar el proceso
encontrado para identificar los servicios pertenecientes a este proceso. Esta
tarea termina con el modelado del proceso pero de cmo funcionara con la
implementacin del sistema (to be), para plasmar en el documento se analizar
el proceso de realizacin del trmite de licencia de construccin y los dems
procesos estarn de anexo.
La obtencin de las licencias de construccin (segn flujo de la municipalidad
de magdalena) se da de la siguiente forma:

El cual, se resume como proceso de negocio a la siguiente imagen:

Fuente: Elaboracin Propia.

56

Crear prestaciones que representan servicios candidatos


Siguiendo el enfoque Top Down vamos a identificar mediante el diagrama de
Capacidades los prosibles servicios del proceso de tramite de licencia de
construccin.
Diagrama de Capacidades.
Este diagrama SoaML descompone un proceso de negocio BPMN en una
entidad abstracta que permite identificar los posibles servicios.

Fuente: Elaboracin Propia.

4.2.2.2 Especificacin del servicio.


Una vez identificado los posibles servicios se necesita modelar los detalles de
las interfaces de servicios para poder especificar todos los potenciales
consumidores y proveedores de servicios.
Diagramas de interfaz de Servicios.
Estos diagramas nos permiten detallar los posibles servicios de cada
Capacidad identificada del diagrama BPMN.
Diagrama de interfaz de servicio de la capacidad Gestionar Tramite de licencia
de construccin.

Fuente: Elaboracin Propia.

Diagrama de interfaz de servicio de la capacidad Mdulo informativo.

57

Fuente: Elaboracin Propia.

Diagrama de interfaz de servicio de la capacidad Mdulo informativo.

Fuente: Elaboracin Propia.

Diagrama de interfaz de servicio de la capacidad Oficina Obras Privadas

Fuente: Elaboracin Propia.

Diagrama de interfaz de servicio de la capacidad Gerencia de Desarrollo


Urbano
58

Fuente: Elaboracin Propia.

Diagrama de participantes.
El diagrama de participantes es una abstraccin que modela todo tipo de
entidad, usuario o proveedores de servicios o ambas cosas, los participantes
interactan entre s para automatizar los procesos de negocio.

Fuente: Elaboracin Propia.

Diagrama de Ensamblado de los participantes


Si bien los componentes descritos en el diagrama de participantes esta
completo es necesario que los participantes se conecten con otros
participantes que sean capaces de cumplir con sus solicitudes.

59

Fuente: Elaboracin Propia.

60

You might also like